Discussion :

[nookie67]

Bonjour à tous,

Je travaille actuellement sous SQL Server 2008 R2, et dans les traitements nocturnes, j'effectue un traitement de vérification d'intégrité de mes bases de données avec la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC CHECKDB ([MaBDD])

Pour l'une d'entre elles, j'obtiens régulièrement (pas systématiquement) le message d'erreur suivant :
"L'instruction de vérification a été abandonnée. La base de données n'a pas pu être vérifiée, car un instantané de base de données n'a pas pu être créé et la base de données ou la table n'a pas pu être verrouillée."

La BDD n'est à priori sollicitée par aucun autre processus bloquant, et même en faisant au préalable un "ALTER DATABASE MaBDD SET SINGLE_USER" pour fermer toutes les connexions en cours, rien n'y fait.

Quelqu'un aurait-il une idée à ce sujet ?

[mikedavem]

Il est très probable que SQL Server n'ait pas la place suffisante pour créer un snapshot de la base de données concernée. DBCC CHECKDB crée par défaut un snapshot de la base de données avant de procéder aux différentes vérifications sur le même disque où réside cette dernière.

La première chose à vérifier est donc l'espace libre restant sur le disque concerné. Ensuite tu peux éviter la création du snapshot en utilisant l'option TABLOCK. Cependant DBCC CKECDB devra verrouiller les objets pour opérer.

Il te reste également une dernière solution qui est de créer toi même un snapshot de bases de données (si tu es en édition Enterprise) sur un disque où il y a de la place et de lancer DBCC CHECKDB sur ce snapshot.

++

[nookie67]

Il me semble que j'avais déjà tenté l'option "WITH TABLOCK", mais ça ne me coûte pas grand chose de réessayer.

La piste de l'espace disque est bonne. La question est : à quel emplacement est effectué le snapshot ? si c'est au même endroit que les fichiers de BDD, alors il s'agit d'autre chose.

Je suis en version Enterprise, donc je vais tenter le snapshot "manuel".

Petite précision : ma BDD possède plusieurs groupes de fichiers, et une table partitionnée. Les plus anciens (en M-2) sont mis en lecture seule.
Si l'erreur n'était pas "ponctuelle", j'aurais pensé que ça venait de là, mais en général, ça fonctionne, donc..

Merci pour ton aide en tous cas.
Je reviendrais dire ce qu'il en est !

[mikedavem]

La piste de l'espace disque est bonne. La question est : à quel emplacement est effectué le snapshot ? si c'est au même endroit que les fichiers de BDD, alors il s'agit d'autre chose.

C'est cela. Est-ce que tu aurais éventuellement plus d'information sur l'erreur quand cela arrive ?

As-tu éventuellement essayer avec un DBCC CHECKFILEGROUP pour voir si cela venait d'une partition en particulier ? (je suppose ici qu'une partition = un FG)

++

[nookie67]

En effet, une partition = 1 FG. Mais je n'ai pas plus d'information dans mon log.

Je viens de tomber sur un article intéressant de la MSDN :

Aucune capture instantanée de base de données interne n'est créée lors de l'exécution d'une commande DBCC :

[...]
* Sur une base de données autre que master, si cette base de données a été placée en mode mono-utilisateur à l'aide de la commande ALTER DATABASE.

* Sur une base de données en lecture seule.
[...]
* Si l'option WITH TABLOCK est utilisée. Dans ce cas, DBCC satisfait la demande en ne créant pas de capture instantanée de la base de données.

Les commandes DBCC utilisent des verrous de table au lieu de captures instantanées internes de base de données lorsque la commande est exécutée sur les bases de données suivantes :

* un groupe de fichier en lecture seule ;

* un système de fichiers FAT ;

* un volume qui ne prend pas en charge les « flux nommés » ;

* un volume qui ne prend pas en charge les « flux de remplacement ».

Source : http://msdn.microsoft.com/fr-fr/libr...ql.100%29.aspx

Donc l'option "TABLOCK" est systématiquement utilisée lorsque j'effectue un CHECKDB sur ma base.
Je continue les investigations

Merci

[SQLpro]

ben non si vous faites un DBCC CHECKDB (mabase) c'est bien un snapshot qu'il fait.
Vous ne pouvez pas faire un snapshot manuel, car ce ne sont pas les mêmes types de snapshot.

A +

[mikedavem]

Donc l'option "TABLOCK" est systématiquement utilisée lorsque j'effectue un CHECKDB sur ma base.

Après vérification non. DBCC CHECKDB utilisera un snapshot interne mais les données du / des FG en readonly ne seront pas pris en compte (sans avoir précisé l'option TABLOCK).

++

[dbaffaleuf]

La piste de l'espace disque est bonne. La question est : à quel emplacement est effectué le snapshot ? si c'est au même endroit que les fichiers de BDD, alors il s'agit d'autre chose.

Le database snapshot pour CHECKDB est matérialisé sous la forme d'un ou plusieurs alternate data streams NTFS par fichier de données nommés Fic.mdf:MSSQL_DBCC##:$DATA ou Fic.ndf:MSSQL_DBCC##:$DATA.

Ils sont visibles lors du passage de la commande en utilisant un dir /R. Il sont toujours créés sous le même répertoire que leur fichier origine.

[nookie67]

Merci pour vos retours.

J'ai tenté de lancer la vérification avec/sans différentes options :
DBCC [CHECKFILEGROUP] WITH TABLOCK, ALL_ERRORMSGS, ESTIMATEONLY

Toujours le même message d'erreur, même pour une simple estimation (je n'arrive pas avoir plus de détails) :
"Message 5030, gravité 16, état 12, ligne 5*: La base de données ne peut pas être verrouillée de façon exclusive pour effectuer cette opération. [SQLSTATE 42000]
Message 7926, gravité 16, état 1, ligne 5*: L'instruction de vérification a été abandonnée. La base de données n'a pas pu être vérifiée, car un instantané de base de données n'a pas pu être créé et la base de données ou la table n'a pas pu être verrouillée. Consultez la documentation en ligne pour savoir quand ce comportement se produit et connaître les solutions de contournement qui existent. Consultez également les erreurs précédentes pour plus de détails. [SQLSTATE 42000]"

J'ai néanmoins lancé la commande avec l'option ESTIMATEONLY sur un environnement de Pré-Production pour connaître la taille du snapshot créé sur tempdb, résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Estimated TEMPDB space needed for CHECKALLOC (KB)
98932
(1*ligne(s) affectée(s))
 
Estimated TEMPDB space needed for CHECKTABLES (KB)
2
(1*ligne(s) affectée(s))
 
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système.

96 Mo, c'est rien du tout et j'ai largement assez d'espace disque pour ça.
En revanche : mon fichier tempdb.mdf fait actuellement 24Mo environ
[EDIT]24Go ! pas 24Mo[/EDIT]
et est configuré pour une croissance auto "Par 10%, croissance illimitée".

Est-ce que selon vous le type de croissance configuré peut jouer sur la possibilité de créer le snapshot ? (qui en l'occurence ferait grossir temporairement la BDD de 500% env.)

Encore merci pour votre aide.

[nookie67]

Bon, voici un article intéressant que j'ai trouvé :
http://beyondrelational.com/modules/...-trust-it.aspx

On comprend donc que dans certains cas le DBCC ESTIMATEONLY ne renvoie pas une estimation juste...
Quand bien même, je dispose de 1.4To de libre là où est stockée tempdb, donc...

[dbaffaleuf]

J'ai tenté de lancer la vérification avec/sans différentes options BCC [CHECKFILEGROUP] WITH TABLOCK, ALL_ERRORMSGS, ESTIMATEONLY

Il y a une typo dans la commande.

J'ai néanmoins lancé la commande avec l'option ESTIMATEONLY sur un environnement de Pré-Production pour connaître la taille du snapshot créé sur tempdb, résultat :

Il n'y a pas de snapshot créé dans tempdb. Le snapshot utilisé par CHECKDB est un alternate stream de chaque fichier de la base sur disque. Ce qui est utilisé dans tempdb, ce sont des allocations pour les facts, ce sont des informations concernant ce que checkdb doit trouver en vérifiant les pages d'un objet donné, et qui sont utilisées ensuite pour comparaison.

Pour ton erreur cf http://support.microsoft.com/kb/928518/en-us