Назад | Перейти на главную страницу

Призрачная уборка

Насколько я понимаю, процесс очистки призрачных данных состоит в том, что каждые пять секунд он будет искать удаленные призрачные записи в индексе. и поэтому он не будет перегружать систему, он будет «очищать» только примерно десять страниц за раз.

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

Итак, допустим, я выполняю удаление, возможно, миллиона строк, и записи индекса для этих миллионов строк имеют размер примерно 8 ГБ. так что примерно в 100000 раз разница в 80к. Означает ли это, что процесс очистки от призраков займет 500 000 или почти шесть дней?

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

[этот вопрос вызван проблемами с производительностью, которые мы наблюдали в OpsMgrDW, и мы хотели узнать больше об этом процессе]

Я написал два подробных сообщения в блоге, в которых объясняется очистка от призраков (это единственное место, где подробно объясняется где-либо, в печати или в Интернете).

Первый Внутри Storage Engine: тщательная очистка от призраков а второй Сокращение очистки призрака. Да, 10 страниц каждый раз, и задача очистки от фантомов может никогда не догнать большое количество непрерывных удалений.

Очистка призраков, за исключением 10 страниц каждые 5 секунд, может быть запущена агрессивно, если подсистема хранения «видит» призрачные записи. Заставьте сканировать затронутую таблицу или индекс, используя что-то вроде

выберите * из [таблицы-проблем] с помощью (индекс = индекс-проблемы)

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

Надеюсь это поможет.

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

Пару лет назад я столкнулся с этой проблемой и не смог исправить ее с помощью конфигурации, запуска очистки от призраков или чего-то в этом роде. Я работал с базой данных, в которой постоянно выполнялись вставки и удаления, и SQLServer периодически блокировался из-за запуска очистки призрака.

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

у нас похожая ситуация. В одной из наших таблиц много записей-призраков, и эти записи не очищаются процессом очистки призраков. DB Shrinking, DBCC Cleantable, Rebuilding the index и Reorganizing index бесполезны. Чтобы решить эту проблему, мы переносим данные во временную таблицу, затем обрабатываем таблицу и переносим данные обратно в усеченную таблицу. Эта таблица содержит данные LOB (2 столбца nvarchar (max)). Есть ли другой способ исправить это?