Если я восстанавливаю индексы таблицы после SQL Server 2000 к миграции базы данных 2005 года
Sun описывает, как получить базовый файл на Солярисе, HP-UX, Redhat и Windows здесь .
Солярис имеет gcore программу. HP-UX может иметь его. Иначе используйте gdb и его команду gcore. Windows имеет win-dbg-root\tlist.exe и win-dbg-root\adplus.vbs
3 ответа
авторитетных онлайн-материалов, содержащих подробные сведения, не так много. при миграции (помимо процедур, направленных на простое обеспечение структурной целостности базы данных на новом / обновленном хосте). Именно по этой причине, и поскольку эта миграция кажется вам запланированным / запланированным событием, я воспользуюсь возможностью перестроить все индексы, включая кластерные индексы .
Некоторым это может показаться "излишним", но что лучшая возможность повторной балансировки и переупаковки индексов / таблиц, обеспечение нового коэффициента заполнения, соизмеримого с ожидаемым использованием 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+ миллионов строк, общие временные накладные расходы составляют порядка нескольких часов, время хорошо инвестировано, поскольку это может отложить перестройку индекса в будущем. Что касается фактора риска, похоже, у вас есть резервная копия ...
Что само собой разумеется ... Когда базовая таблица имеет кластеризованный индекс, и если желательно также перестроить его, удалите все остальные индексы перед , чтобы не тратить много времени на обновление некластеризованного индекса (без того, чтобы они были перестроены всерьез), а затем, конечно, воссоздайте эти некластеризованные индексы.
В зависимости от ситуации. по количеству рассматриваемых таблиц и индексов может быть выгодно написать несколько небольших хранимых процедур для автоматизации удаления индекса (и повторного создания, хотя также может быть важно индивидуально проверить коэффициенты заполнения, пересчет и другие параметры ).
«Я пропустил что-нибудь очевидное, что должно быть выполнено после миграции?»
- Убедитесь, что вы используете последнюю версию SP SS 2005.
- Я удивлен, что вы не упомянули о тестировании всех ваших SP и UDF в SS 2005, чтобы доказать, что они одинаково успешны и предсказуемо терпят неудачу во всем. Это может занять некоторое время, но дает вам отличный шанс значительно повысить надежность вашей системы.
Дополнение к вашему list CheckDB до того, как база данных покинет SQL 2000 - вы хотите быть как можно более уверенными в том, что никакое повреждение из 2000 не принесет, если кто-то начнет освобождать данные из системных таблиц вместо использования соответствующих команд, после миграции вы получите кобылу.
Если вы перестроите индексы, то exec sp_updatestats 'resample' даст вам худшую статистику для ваших индексов, поскольку они уже были бы обновлены при перестроении. Добавленная дополнительная статистика может нуждаться в обновлении, но делайте их индивидуально, не убивайте статистику индекса для них.