Иногда во время обслуживания нашего индекса задание завершается с ошибкой SEV 17, когда не может быть выделено достаточно места для объекта, который он восстанавливает. База данных выложена так:
Data_file1 PRIMARY 0 growth 0% free Max Size UNLIMITED
Data_file2 PRIMARY 0 growth 0% free Max Size UNLIMITED
Data_file3 PRIMARY 0 growth Less than 1% free Max Size UNLIMITED
Data_file4 PRIMARY 250 MB growth Less than 1% free Max Size UNLIMITED
По сути, 3 из 4 файлов данных заполнены и не имеют возможности расти, четвертый заполнен и имеет возможность расти. Файлы распределены по разным LUN (и причина того, почему это грязно). Поэтому, когда начинается перестроение онлайн-индекса, я понимаю, что если потребуется какое-то дополнительное пространство, оно превратится в Data_file4 и будет в порядке, но, очевидно, оно пытается вырасти в другой файл, в котором рост не разрешен и терпит неудачу. Я не могу воспроизвести эту ошибку, но мне было интересно, если кто-нибудь понял, почему это происходит.
Полная версия SQL Server - 2008 R2 Enterprise, SP2 CU 4 (10.50.4270). Мы используем сценарии перестройки Олы Хелленгрен, где мы перестраиваем онлайн, но не сортируем tempdb
.
источник
If max_size is not specified, the file size will increase until the disk is full.
Разрешено», если автоматическое увеличение отключено, его не следует пытаться выделить из этих файлов (A value of 0 indicates that automatic growth is set to off and no additional space is allowed.
), но может быть ошибка, поэтому было бы неплохо попробовать, если она не установлена.max_size is
в настоящее время установлен на UNLIMITED, даже на те, которые 0 роста. Я сейчас исследую это в моем репро тесте.Ответы:
По моему опыту, он всегда собирается перестроить онлайн в файловой группе, в которой находится индекс. Он должен отображать существующий индекс и содержать достаточно места, по сути, для одной копии.
Вы должны получать ошибку только тогда, когда индекс, который слишком велик для размещения отображений (копия), перестраивается - например, один раз он может быть достаточно фрагментирован, чтобы соответствовать сценарию Олы, а в следующий раз - нет.
Есть отличная статья http://technet.microsoft.com/en-us/library/ms179542(v=sql.105).aspx, которую мне приходилось читать несколько раз при столкновении с проблемами дискового пространства с индексами.
источник