Администратор базы данных, который обеспокоен реорганизацией или перестройкой индексов, может привести к потере данных?

У нас есть несколько баз данных с фрагментацией индекса> 95%. Насколько я могу судить, индексы никогда не перестраивались, а тем более реорганизованы. Годами.

(Справедливости ради, в этих таблицах, по-видимому, разрешено автоматическое обновление статистики. Также, честно говоря, он старательно работает с резервными копиями: полными ежедневными и ежеквартальными журналами.)

Когда я спросил, администратор БД сказал, что он не хочет перестраивать или реорганизовать индексы. Когда я спросил, почему, он не смог сформулировать это. В конце концов он сказал, что обеспокоен возможной потерей данных. Например, одна из баз данных используется нашим бухгалтерским приложением в Great Plains Dynamics, и он, похоже, очень обеспокоен этим.

Я не администратор, но из того, что я прочитал, его беспокойство кажется ... трудным для меня.

Я не уверен, что делать дальше. Предложения, как мне поступить?

sql-server maintenance

— Грег Хендершотт
источник

Если эта база данных не пострадает 24/7, и мир придет к концу, если он выйдет в автономный режим, нет оправдания для такого поведения. Я пишу перестановки и статистику каждую неделю для более чем 12 000 баз данных, не задумываясь. За 16 лет у меня был только один испорченный из-за плохого контроллера.

— Brain2000

Ответы:

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

Паранойя - это хорошая вещь для администратора баз данных - если они беспокоятся о потере данных, я бы попросил их провести надлежащий тест резервных копий (восстановить их в отдельной системе и убедиться, что все данные там есть), и если они Тем не менее, разумная предосторожность - выполнение полного резервного копирования перед перестройкой индексов.

— voretaq7
источник

+1 для Паранойи - это хорошая черта DBA

— Джоэл Коэль

Я полностью понимаю и ценю здоровую паранойю. Измерьте дважды, отрежьте один раз. То, где я сбит с толку, - это, кажется, отсутствие понимания, а не осторожность. И вместо того, чтобы «давайте определимся, как попробовать это, осторожно», это «да, не случится». Мы могли бы (скажем) спулинировать тестовый экземпляр EC2 с копией данных, перегруппировать индексы, рассчитать их время, пересечь строки таблицы результатов, чтобы убедиться, что данные не были повреждены. Такой план был бы осторожностью ... в отличие от бездействия?

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

Просто напоминание о том, что реорганизация индекса всегда активна (все индексы доступны во время дефрагментации), и перестроение индекса можно выполнять также онлайн ( WITH (ONLINE=ON)если индекс не содержит столбцы BLOB.

— Remus Rusanu

@Greg Да, менталитет «Давайте просто не трогать индексы, которые настолько фрагментированы, что, вероятно, снижают производительность», меня тоже смущает - случайное REINDEX«профилактическое обслуживание» таблиц, в которых содержание индекса сильно меняется, довольно Распространенный в моем опыте (если индекс в основном статический, это менее

— важно

Хороший совет @Remus - это уменьшает влияние на производительность (у вас все равно будет высокий дисковый ввод-вывод, что замедлит некоторые, но по крайней мере вещи, которые будут использовать индекс, все равно могут его использовать, а не прибегать к последовательному сканированию )

— voretaq7

Нет риска потери данных при перестроении или дефрагментации индексов.

— mrdenny
источник

Если у вас уже есть некоторая степень повреждения данных или неисправное оборудование. Но в любом из этих случаев фрагментация индекса - это меньше всего!

— db2

Но это будет не повреждение из-за перестройки индекса, а из-за другой проблемы.

— Мрденный

Реорганизация индексов займет меньше времени и меньше усилий со стороны сервера SQL, поэтому их можно выполнять в экземплярах типа «еженедельная ночь». Если то, что вы говорите, верно, даже реорганизация индексов, которые никогда не были, может также оказать большее влияние на сервер. Перестройка индексов потребует значительных усилий со стороны сервера SQL, поскольку они отбрасываются и перестраиваются. Выполнение перестроения в рабочие дни не стоит того, чтобы сервер был занят индексами и не обслуживал людей, которые его используют.

Я согласен с voretaq7: если его беспокоит работа с индексами, сначала попробуйте его на серверах разработки или тестирования, чтобы увидеть, как на это отреагируют.

— битпоток
источник

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

— voretaq7

Я почти уверен, что удаление и повторное создание ненужно на SQL Server.

— Джастин Даринг

@Justin Я почти уверен, что вы правы (фактически из моих дней в Sybase я вспоминаю, что поведение переиндексации - это, по сути, drop / create, поэтому здесь нет странностей с блокировкой индекса, как в Postgres)

— voretaq7

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

— Мрденный