A reconstrução do índice do SQL Server 2008 R2 falha com a gravidade 17

Ocasionalmente, durante a manutenção do índice, a tarefa falha com um erro SEV 17, em que não é possível alocar espaço suficiente para o objeto que está sendo reconstruído. O banco de dados é organizado da seguinte maneira:

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

Essencialmente, 3 dos 4 arquivos de dados estão cheios e não podem crescer, o quarto está cheio e pode crescer. Os arquivos estão espalhados por diferentes LUNs (e o motivo é complicado). Portanto, quando a reconstrução do índice online for iniciada, entendo que, se for necessário espaço adicional, ele crescerá em Data_file4 e ficará bom, mas aparentemente ele está tentando crescer em um arquivo diferente, onde o crescimento não é permitido e está com falha. Não consigo reproduzir esse erro, mas estava me perguntando se alguém tinha informações sobre o porquê disso acontecer.

A versão completa do SQL Server é 2008 R2 Enterprise, SP2 CU 4 (10.50.4270). Usamos os scripts de reconstrução de Ola Hallengren, onde reconstruímos online, mas não fazemos nenhum tipo tempdb.

sql-server sql-server-2008-r2 maintenance

— Mike Fal
fonte

O tamanho máximo do arquivo está especificado? Os documentos dizem que If max_size is not specified, the file size will increase until the disk is full.Concedido, se o crescimento automático estiver desativado, isso não deveria estar tentando alocar a partir desses arquivos ( A value of 0 indicates that automatic growth is set to off and no additional space is allowed.), mas pode haver um erro, por isso não faria mal tentar se não estiver definido.

— Jon Seigel

max_size isatualmente definido como ILIMITADO, mesmo naqueles com 0 crescimento. Estou investigando isso no meu teste de reprodução agora.

— Mike Fal 26/02

Você está registrando os resultados? Se você mantiver registros históricos, o erro ocorre no mesmo índice sempre que falha?

— Cougar9000

Quantas páginas está o índice em questão?

— Mark Wilkinson

Além disso, isso é um erro gerado pelo script ou um erro real do SQL Server? Eu pergunto, porque me pergunto se talvez você esteja atingindo um limite de tamanho do log de transações, em vez de um limite de tamanho do arquivo de dados, e o script está lidando com o erro incorretamente.

— Mark Wilkinson

Minha experiência é que ele sempre fará uma reconstrução on-line no grupo de arquivos no qual o índice vive. Ele precisa mapear o índice existente e manter espaço suficiente para, essencialmente, uma cópia.

Você só deve receber o erro quando um índice que é muito grande para armazenar mapeamentos (a cópia) é reconstruído - por exemplo, uma vez pode ser fragmentado o suficiente para se qualificar no script de Ola e na próxima vez que não.

Há um ótimo artigo http://technet.microsoft.com/en-us/library/ms179542(v=sql.105).aspx que eu tive que ler várias vezes ao encontrar problemas de espaço em disco com índices.

— rottengeek
fonte