Недавно я унаследовал очень большую и очень грязную базу данных, и мне нужно ее очистить. Чтобы дать некоторое представление о размере, основная база данных в настоящее время содержит 3 большие таблицы, каждая из которых содержит около 300 миллионов строк, и занимает около 225 ГБ дискового пространства. Каждый день добавляется более 5 миллионов строк.
Из-за критической нехватки дискового пространства (предшественник не архивировал старые данные и вообще не управлял их размером) я был вынужден удалить около 280 миллионов строк из самой большой таблицы. Этот процесс занял более 25 часов, и на это время необходимо было отключить базу данных от приложений, ориентированных на клиентов.
Теперь мне нужно переиндексировать таблицу, потому что выбор и вставка занимают очень много времени. Однако я не могу просто отключить базу данных на неопределенный срок, мне нужно иметь возможность оценить количество времени, необходимое для выполнения переиндексации. Я никогда раньше не переиндексировал такую большую таблицу, поэтому у меня нет никаких хороших ориентиров, на которые можно было бы опираться.
Основная таблица включает кластеризованный, монотонно увеличивающийся первичный ключ, а также неуникальный некластеризованный ключ. У меня достаточно места на диске для выполнения переиндексации.
Итак, мой вопрос таков: сколько времени люди на это у меня уйдут? Какое практическое правило для оценки времени переиндексации?
Вы действительно проверили, насколько фрагментированы ваши таблицы / индексы? Попробуйте выполнить следующий запрос к базе данных (запрос выполняется на SQL2005 или выше). Обратите внимание, что этот запрос повлияет на ваш сервер и должен выполняться в тихое время:
SELECT OBJECT_NAME(i.OBJECT_ID) AS TableName,
i.name AS IndexName,
indexstats.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') indexstats
INNER JOIN sys.indexes i ON i.OBJECT_ID = indexstats.OBJECT_ID
AND i.index_id = indexstats.index_id
Вы можете выборочно переиндексировать таблицы / индексы, которые наиболее фрагментированы.
Любая операция с базой данных сильно зависит от оборудования, на котором она работает.
Поскольку вы говорите, что уже вырезали очень большое количество строк, запускать его в непиковые часы не должно быть проблемой.
Вы можете настроить репликацию и предложить эту базу данных своим клиентам, пока вы очищаете старую и устанавливаете ее в режиме только для чтения, чтобы они по-прежнему могли получать любые данные, которые могут им понадобиться.
Невозможно оценить, сколько времени это займет - так много разных вещей будет иметь влияние. Подобно тому, что Пол пишет о длине CHECKDB, очень похожие вещи повлияют на индексацию и многое другое. Лучший ответ: сколько времени это длилось в прошлом? Если вы не можете это определить, следующим лучшим вариантом будет, вероятно, попробовать его в аналогичной непроизводственной среде, но даже это не обязательно совпадет (например, проблемы параллелизма и т. Д. Будут другими).
В качестве примечания, вы можете изучить ОПЕРАЦИИ ОНЛАЙН-ИНДЕКСА в Sql 2005 и более поздних версиях ... Я не могу добавить вторую гиперссылку, но Google "сервер sql операций с онлайн-индексом" и щелкните верхнюю ссылку.
После первоначального перестроения таблицы вы захотите настроить задания обслуживания для периодической дефрагментации / перестроения индексов. У Мишель Аффорд, также известной как @SQLFool, есть отличный набор скриптов для этого:
http://sqlfool.com/2009/06/index-defrag-script-v30/
Вы устанавливаете пороги, когда вы хотите дефрагментировать или перестраивать. Он автоматически определяет, какие индексы можно перестроить в интерактивном режиме, и делает это, что дает вам некоторое преимущество в работе.
Имейте в виду, что операции с индексами могут привести к большой активности в журнале транзакций, что действительно может замедлить зеркальное отображение базы данных и резервное копирование журнала транзакций.