Коли нормально скорочувати базу даних?

Я знаю, що скорочення - це диявол: воно змінює порядок сторінок і відповідає за рак шкіри, фрагментацію даних та глобальне потепління. Список продовжується ... При цьому, скажімо, я маю базу даних на 100 ГБ і видаляю 50 ГБ даних - не на одній таблиці, а на загальну обрізку старих даних на широкому рівні бази даних, яка охоплює 90% таблиці - чи це є відповідним випадком використання для зменшення бази даних?

Якщо ні, то які відповідні кроки потрібно зробити для прибирання будинку після видалення такого високого відсотка даних із бази даних? Я можу придумати два: Перебудувати індекси та оновити статистику. Що ще?

Реорганізовувати та зменшувати ніколи не рекомендується.

Якщо ви можете взяти програми, які базується в режимі офлайн, ви можете прискорити процес і зменшити фрагментацію індексу, видаливши всі індекси та обмеження первинного / зовнішнього ключа перед зменшенням (це означатиме, що менше даних потрібно переміщувати, як лише сторінки даних будуть перетасовані не зараз неіснуючими індексними сторінками, прискорюючи процес), а потім відтворити всі індекси та ключі.

Відтворення індексів після зменшення означає, що вони не повинні бути значно фрагментовані, а перехід їх під час скорочення означає відновлення їх не залишить багато невеликих «дірок» у розподілі сторінки у файлах, які можуть запросити фрагментацію пізніше.

Ще один варіант, якщо ви можете відключити програми в автономному режимі, - це перенести всі дані до нової бази даних тієї ж структури. Якщо процес збирання є надійним, ви повинні мати можливість швидко скласти цю порожню БД, якщо не створити її з поточної БД (відновіть резервну копію поточної, урізайте / видаліть весь вміст у таблицях та виконайте повну скорочення).

Ви все ще можете скинути всі індекси в пункт призначення та відтворити їх згодом, оскільки це може бути набагато ефективнішим при зміні великої кількості індексованих даних (100% - у цьому випадку). Щоб пришвидшити процес копіювання, надайте файл (и) даних бази даних призначення на різних фізичних накопичувачах до джерела (якщо ви не використовуєте SSD, в цьому випадку вам не потрібно піклуватися про зменшення рухів голови), ви можете перемістити їх до місця розташування джерела, коли ви закінчите.

Крім того, якщо створити пункт призначення як новий (замість того, щоб залишити копію джерела), створіть його з початковим розміром, який буде містити всі поточні дані плюс кількамісячне зростання, - це зробить копіювання даних знову трохи швидшим, оскільки вона не буде виділяти новий простір раз і знову протягом усього процесу.

Це може бути краще, ніж використання скорочення, оскільки переміщення даних у свіжу базу даних повторює заплановану дію операції скорочення, але, можливо, із значно меншою фрагментацією (що є ненавмисним наслідком реорганізації та скорочення). Стискання просто займає блоки з кінця файлу і ставить їх у перший простір ближче до початку, не докладаючи зусиль для збереження пов'язаних даних разом.

Я підозрюю, що результат також буде більш ефективним для простору, оскільки згодом, можливо, буде менше використаних сторінок. Скорочення просто перемістить використані частини, що використовуються, швидше за все переміщення даних призведе до повних сторінок, особливо якщо ви вставляєте цільове місце в порядку кластеризованого ключа / індексу таблиці (де в таблиці є один) та створюєте інші індекси після переміщення даних.

Звичайно, якщо ви взагалі не можете приймати програми в автономному режимі, єдиний варіант - просто виконати скорочення - тому, якщо вам справді потрібно повернути місце, перейдіть до цього. Залежно від ваших даних, шаблонів доступу, загального розміру робочого набору, скільки оперативної пам’яті має сервер тощо, додаткова внутрішня фрагментація може виявитися не такою істотною.

Для операцій з копіюванням добре працюватиме або SSIS, або базовий T-SQL (опція SSIS може бути менш ефективною, але потенційно простішою для обслуговування). Якщо ви створите відносини FK в кінці разом з індексами, ви можете зробити просте "для кожної таблиці, скопіювати" в будь-якому випадку. Звичайно для одноразової, скорочення + реорганізація, мабуть, теж добре, але я просто люблю лякати людей, коли вони не розглядають регулярні скорочення! (Я знаю, що люди планують їх щодня).

Чи буде база даних знову рости? Якщо так, то зусилля, які ви збираєтеся вкласти в операції скорочення, будуть просто марними, тому що, коли ви зменшите розмір файлу і потім додасте більше даних, файл просто повинен буде рости знову, і транзакції повинні чекати, коли це відбудеться. Якщо у вас є неоптимальні параметри автоматичного зростання та / або повільний рух, ця активність зростання буде досить болісною.

Якщо ви скорочуєте базу даних, для чого ви будете використовувати звільнений простір на диску? Знову ж таки, якщо ви просто збираєтеся звільнити цей простір у випадку, якщо ця база даних знову зросте, то ви просто крутите колеса.

Що ви можете подумати про те, що тепер у вас є весь вільний простір у файлі, це відновлення ваших індексів, щоб вони були краще оптимізовані (а це буде набагато менш болісно, ​​коли у вас є вільний простір для цього - подумайте про спробу змінити светр у крихітному шафі проти великої спальні).

Тож якщо це не була основна операція очищення, і ви насправді більше не будете збігатися до того самого рівня даних, я б просто залишив їх таким, який є, і зосередиться на інших областях оптимізації.

Якщо у вас не вистачає місця, і ваші дані не повинні набувати такої великої величини, то зменшіться, але відновіть свої індекси після відповідних коефіцієнтів заповнення, що дозволяє досягти типового зростання.

Якщо ваша кінцева мета полягає в тому, щоб зменшити розмір резервного копіювання, переконайтеся, що ви реалізуєте комплексну стратегію резервного копіювання, щоб очистити журнал транзакцій, і коли ви створюєте резервну копію db, використовуйте параметри стискання.

• Створення повної резервної бази даних (SQL Server)
• Резервні копії журналу транзакцій (SQL Server)

Я б не рекомендував автоматично зростати на 5 Гб, якщо зазвичай ви не будете сподіватися, що часто вони будуть рости 5 Гб У противному випадку у вас можуть виникнути непостійні проблеми з роботою. Ваш розмір даних спочатку слід встановити на те, що, на вашу думку, потрібно протягом року, скажімо, на рік, а автоматичний ріст має бути встановлений на розмір, який ви протестували, не впливає на ефективність роботи. Див. Не торкайтеся кнопки зменшення бази даних у SQL сервері! Майком Уолшем.

Перебудова індексів перед скороченням призводить до поганого розміщення індексів. Недоцільно відбудовувати, потім зменшувати. Зменшення призводить до того, що індекси можуть бути змінені, щоб відновити простір - тому попередньо перебудовувати, а потім зменшувати - безглуздо. Дивіться, коли використовувати Автоматичне скорочення від Thomas LaRock.

Я не знаю, чи спрацювало б це краще, ніж повторне встановлення після зменшення, але іншим варіантом було б створення нового файлу даних відповідного розміру та переміщення всіх даних до цього. У такому випадку я б спершу зробив реіндекс, щоб ви знали, що таке фактичний розмір даних. Одним із зауважень є те, що якщо це перший файл у первинному файлі даних, я не думаю, що ви можете його очистити. Ви повинні мати змогу зменшити їх, а потім перемістити дані згодом, що дозволить уникнути розвороту сторінки. Однак, якщо ви дивитесь на перехід на твердий стан, це все одно не має нічого різного.

Повернення до цього ШЛЯХУ пізно. Тим не менш, ми давно обмірковуємо і тестуємо використання термоусадок у наших тестових середовищах. Відповідно до теми, є випадки, коли скорочення є життєздатним варіантом. Але знання того, коли і як це застосувати, є життєво важливим для правильного виконання як довгострокової, так і короткострокової перспективи.

У нашому сценарії нещодавно ми додали численні зміни до нашої великої БД, включаючи стиснення, розділення, архівування та старе старе видалення зайвих даних. Як результат, використовувана частина нашого основного файлу даних зменшилась до менше половини того, що раніше. Але який сенс носити весь цей багаж? Тим більше, що всупереч деяким статтям в Інтернеті, розмір ваших файлів даних Прямо корегується з резервною копією / скороченням тривалості. Це тому, що, на відміну від багатьох статей, сценарії реального життя завантажують більше даних на будь-яку сторінку, ніж лише ті речі, які ви, можливо, видалили.

Більш того, це відкриває чудовий сценарій скорочення:

1. Створіть скрипт, який знайде всі об’єкти та їхні файлові групи у вашій базі даних (безліч прикладів в Інтернеті), використовуйте це для створення пунктів випаду, а також для створення визначень для кожного вашого індексу та обмежень.
2. Створіть новий файл і групу файлів і зробіть це за замовчуванням.
3. Відкиньте всі некластеризовані індекси (зауважте, деякі індекси можуть бути обмеженнями).
4. Створіть свої кластеризовані індекси у новій групі файлів за допомогою DROP_EXISTING = ON (що, btw, - це надзвичайно швидка операція, що мінімально реєструється, для початку, порівняно з багатьма альтернативами).
5. Відтворити некластеризовані індекси.
6. Нарешті, СТРУКТУЙТЕ свій старий файл даних (як правило, ПЕРШИЧНИЙ)

Таким чином, єдиними даними, що залишилися там, були б системні об'єкти, статистика, процедури та інше. Скорочення повинно бути значно, МНОГО швидше, і немає необхідності в подальшому обслуговуванні індексів на ваших основних об'єктах даних, які будуть створені акуратно для того, щоб з мінімальним ризиком для майбутньої фрагментації.