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 UNLIMITEDEssencialmente, 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.
fonte
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.max_size isatualmente definido como ILIMITADO, mesmo naqueles com 0 crescimento. Estou investigando isso no meu teste de reprodução agora.Respostas:
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.
fonte