La reconstruction d'index SQL Server 2008 R2 échoue avec la gravité 17

Parfois, pendant notre maintenance d'index, le travail échoue avec une erreur SEV 17 où suffisamment d'espace ne peut pas être alloué pour l'objet qu'il reconstruit. La base de données est présentée comme telle:

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

Essentiellement, 3 des 4 fichiers de données sont pleins et ne peuvent pas croître, le quatrième est plein et peut croître. Les fichiers sont répartis sur différents LUN (et la raison pour laquelle est en désordre). Donc, lorsque la reconstruction de l'index en ligne commence, je comprends que si un espace supplémentaire est nécessaire, il se développera en Data_file4 et ira bien, mais il essaie apparemment de se développer dans un fichier différent où la croissance n'est pas autorisée et échoue. Je ne peux pas reproduire cette erreur, mais je me demandais si quelqu'un avait une idée de pourquoi cela se produit.

La version complète de SQL Server est 2008 R2 Enterprise, SP2 CU 4 (10.50.4270). Nous utilisons les scripts de reconstruction d'Ola Hallengren, où nous reconstruisons en ligne mais sans tri tempdb.

sql-server sql-server-2008-r2 maintenance

— Mike Fal
source

La taille de fichier maximale est-elle spécifiée? Les documents disent que If max_size is not specified, the file size will increase until the disk is full.si la croissance automatique est désactivée, cela ne devrait pas essayer d'allouer à partir de ces fichiers ( A value of 0 indicates that automatic growth is set to off and no additional space is allowed.), mais il peut y avoir un bogue, donc cela ne ferait pas de mal de l'essayer s'il n'est pas défini.

— Jon Seigel

max_size isactuellement défini sur UNLIMITED, même sur ceux qui ont une croissance de 0. J'étudie cela dans mon test de repro en ce moment.

— Mike Fal

Consignez-vous les résultats? Si vous conservez des enregistrements historiques, l'erreur se produit-elle sur le même index chaque fois qu'elle échoue?

— Cougar9000

Combien de pages l'index est-il en question?

— Mark Wilkinson

Est-ce également une erreur générée par le script ou une erreur SQL Server réelle? Je demande parce que je me demande si vous atteignez peut-être une limite de taille de journal des transactions, par opposition à une limite de taille de fichier de données, et le script gère l'erreur de manière incorrecte.

— Mark Wilkinson

D'après mon expérience, il va toujours effectuer une reconstruction en ligne dans le groupe de fichiers sur lequel réside l'index. Il doit mapper l'index existant et contenir suffisamment d'espace pour, essentiellement, une copie.

Vous ne devriez obtenir l'erreur que lorsqu'un index trop volumineux pour contenir les mappages (la copie) est reconstruit - par exemple, une fois, il peut être suffisamment fragmenté pour être qualifié dans le script d'Ola et la prochaine fois, il peut ne pas l'être.

Il y a un excellent article http://technet.microsoft.com/en-us/library/ms179542(v=sql.105).aspx que j'ai dû lire plusieurs fois lors de l'exécution de problèmes d'espace disque avec des index.

— rottengeek
source