DBA, який переживає, що реорганізація чи перекомпонування індексів може спричинити втрату даних?

У нас є деякі бази даних з фрагментацією індексу, що становить> 95%. Як найкраще я можу сказати, що індекси ніколи не відбудовувались, а не реорганізовувались. У роках.

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

Коли я запитав, DBA сказав, що він не хоче відновлювати або переробляти індекси. Коли я запитав чому, він насправді не міг сформулювати це. Врешті-решт він сказав, що стурбований можливою втратою даних. Наприклад, одна з баз даних використовується нашою програмою бухгалтерського обліку Great Plains Dynamics, і він здався дуже занепокоєним з цього приводу.

Я не DBA, але з того, що я прочитав, його тривога здається ... мені важко зрозуміти.

Я не впевнений, що робити далі. Пропозиції, як мені діяти?

sql-server maintenance

— Грег Хендершот
джерело

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

— Brain2000

Відповіді:

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

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

— voretaq7
джерело

+1 для Paranoia - це хороша ознака DBA

— Joel Coel

Я цілком розумію і ціную здорову параноїю. Виміряйте двічі, поріжте один раз. Там, де мене вражають, це, мабуть, мало розуміння, а не обережність. І замість того, щоб "давайте визначимо спосіб спробувати це обережно", це "так, не відбудеться". Ми могли б (скажімо) згорнути тестовий екземпляр EC2 з копією даних, перезарядити індекси, час, дельтувати рядки таблиці результатів, щоб підтвердити, що дані не були пошкоджені. Такий план був би обережним ... на відміну від бездіяльності?

— Грег Хендершот

Лише нагадування про те, що реорганізація індексу завжди в Інтернеті (усі індекси доступні під час дефрагментації), а перебудову індексу можна проводити також і в Інтернеті ( WITH (ONLINE=ON)доки індекс не містить стовпців BLOB.

— Remus Rusanu

@Greg Так, "Давайте просто не торкаємось до нього настільки фрагментарних індексів, що вони, мабуть, ПІДНУЮТЬ продуктивність", менталітет також бентежить мене. - Іноді, REINDEXяк "профілактичне обслуговування" на таблицях, де вміст індексу багато змінюється, досить поширений у моєму досвіді (якщо індекс здебільшого статичний, то менше речі)

— voretaq7,

@Remus хороша порада - Це зменшує вплив на продуктивність (у вас все ще буде високий диск вводу / виводу, який сповільнить вас деякі, але принаймні речі, які використовуватимуть індекс, все-таки можуть використовувати його, а не вдаватися до послідовних сканувань )

— voretaq7

Не існує ризику втрати даних від відновлення або дефрагментації індексів.

— мрденний
джерело

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

— db2

Але це було б не корупцією внаслідок перебудови індексу, а з якоїсь іншої проблеми.

— мрденний

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

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

— RateControl
джерело

Інший підхід може бути явним DROP INDEXі повторним CREATE INDEX- я не впевнений у SQL Server, але я знаю, що PostgreSQL іноді краще здуває індекс і починає з нуля, а не намагатися відновити його ( REINDEX).

— voretaq7

Я впевнений, що скидання та відтворення на SQL Server непотрібні.

— Justin Dearing

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

— диваку, що блокує

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

— мрденний