Нужно ли перестраивать табличные индексы после миграции базы данных с SQL Server 2000 на 2005 - PullRequest
Новая
       12

Нужно ли перестраивать табличные индексы после миграции базы данных с SQL Server 2000 на 2005

6 голосов
/ 07 октября 2009

Мне поручено выполнить миграцию с SQL Server 2000 на 2005. Я буду выполнять параллельную миграцию.

После восстановления из резервной копии я планирую сделать следующее: 

ALTER DATABASE <database_name> SET COMPATIBILITY_LEVEL = 90;

DBCC CHECKDB(<database_name>) WITH NO_INFOMSGS

DBCC UPDATEUSAGE(<database_name>) WITH NO_INFOMSGS

exec sp_updatestats ‘resample’

Стоит ли перестраивать индексы таблиц перед использованием DBCC UPDATEUSAGE и sp_updatestats?

Я что-то упустил очевидное, что должно быть выполнено после миграции?

За любую помощь будет тепло проголосовано.

Спасибо

Ответы [ 3 ]

5 голосов
/ 07 октября 2009

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

Кому-то это может показаться «излишним», но какая лучшая возможность перебалансировки и переупаковки индексов / таблиц, предоставляя новый коэффициент заполнения, соразмерный с ожидаемым использованием CRUD, и в целом утверждая, что база данных здоровья в новом хозяине.

На практике я бы ... 

ALTER DATABASE <database_name> SET COMPATIBILITY_LEVEL = 90;

DBCC CHECKDB(<database_name>)
   -- WITH NO_INFOMSGS  (I'd take the messages, I'm curious by nature ;-)

Как вы предлагаете, но тогда я бы перестроил все индексы для всех / большинства таблиц, даже (может быть, в частности ...) для очень больших таблиц. Чтобы быть уверенным, следует оценить время и относительный риск, связанный с такой операцией, но в большинстве случаев, даже с базами данных в 100+ миллионов строк, общие накладные расходы составляют порядка нескольких часов, время инвестировано, поскольку это может отложить будущие перестройки индекса. Что касается фактора риска, у вас, похоже, есть резервная копия ...

Что само собой разумеется ... Когда базовая таблица имеет кластеризованный индекс, и если необходимо также перестроить его, удалите все остальные индексы ранее, чтобы не тратить много времени на обновление некластеризованный индекс (без перестроения всерьез), а затем, конечно, воссоздать эти некластеризованные индексы.

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

0 голосов
/ 07 октября 2009

Добавление в ваш список CheckDB до того, как база данных выйдет из SQL 2000 - вы хотите быть как можно более уверенными, что никакое повреждение с 2000 года не будет перенесено, если кто-то начнет освобождать вещи в системных таблицах вместо использования соответствующих команд, вы получите однажды кобыла мигрировала.

Если вы перестраиваете индексы, то exec sp_updatestats «resample» даст вам худшую статистику для ваших индексов, поскольку они уже были обновлены перестроениями. Дополнительные статистические данные вполне могут нуждаться в обновлении, но делайте это по отдельности, не убивайте для них индексную статистику.

0 голосов
/ 07 октября 2009

«Я что-то упустил очевидное, что должно быть выполнено после миграции?»

  • Убедитесь, что у вас установлена ​​последняя версия пакета обновления SS 2005.
  • Я удивлен, что вы не упомянули о том, что протестировали все свои SP и UDF в SS 2005, чтобы доказать, что они преуспевают одинаково и предсказуемо терпят неудачу повсюду. Это может занять некоторое время, но дает вам отличный шанс значительно повысить надежность вашей системы.
...