La reconstrucción del índice de SQL Server 2008 R2 falla con gravedad 17

Ocasionalmente durante nuestro mantenimiento de índice, el trabajo fallará con un error SEV 17 donde no se puede asignar suficiente espacio para el objeto que está reconstruyendo. La base de datos se presenta como tal:

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

Esencialmente, 3 de los 4 archivos de datos están llenos y no pueden crecer, el cuarto está lleno y puede crecer. Los archivos están distribuidos en diferentes LUN (y la razón de por qué es desordenada). Entonces, cuando comienza la reconstrucción del índice en línea, entiendo que si se necesita espacio adicional, crecerá en Data_file4 y estará bien, pero aparentemente está tratando de crecer en un archivo diferente donde el crecimiento no está permitido y falla. No puedo reproducir este error, pero me preguntaba si alguien tenía idea de por qué sucede esto.

La versión completa de SQL Server es 2008 R2 Enterprise, SP2 CU 4 (10.50.4270). Usamos los scripts de reconstrucción de Ola Hallengren, donde reconstruimos en línea pero no los clasificamos tempdb.

sql-server sql-server-2008-r2 maintenance

— Mike Fal
fuente

¿Se especifica el tamaño máximo de archivo? Los documentos dicen If max_size is not specified, the file size will increase until the disk is full.Concedido, si el crecimiento automático está desactivado, eso no debería ser intentar asignar desde esos archivos ( A value of 0 indicates that automatic growth is set to off and no additional space is allowed.), pero puede haber un error, por lo que no estaría de más intentarlo si no está configurado.

— Jon Seigel

max_size isactualmente establecido en ILIMITADO, incluso en los que tienen un crecimiento de 0. Estoy investigando esto en mi prueba de repro en este momento.

— Mike Fal

¿Estás registrando los resultados? Si mantiene registros históricos, ¿se produce el error en el mismo índice cada vez que falla?

— Cougar9000

¿Cuántas páginas tiene el índice en cuestión?

— Mark Wilkinson

Además, ¿es este un error generado por el script o un error real de SQL Server? Le pregunto porque me pregunto si tal vez está alcanzando un límite de tamaño del registro de transacciones, a diferencia del límite de tamaño del archivo de datos, y el script está manejando el error incorrectamente.

— Mark Wilkinson

Mi experiencia es que siempre va a hacer una reconstrucción en línea en el grupo de archivos en el que vive el índice. Tiene que mapear el índice existente y mantener suficiente espacio para, esencialmente, una copia.

Solo debería recibir el error cuando se reconstruye un índice que es demasiado grande para contener asignaciones (la copia); por ejemplo, una vez puede estar lo suficientemente fragmentado como para calificar en el script de Ola y la próxima vez puede que no lo sea.

Hay un gran artículo http://technet.microsoft.com/en-us/library/ms179542(v=sql.105).aspx que tuve que leer varias veces cuando me encontré con problemas de espacio en disco con índices.

— Rottengeek
fuente