Discussion :

[serge0934]

Bonjour,

nos bases étant assez grosses (x téras) et devant passer en dispo 24/24 7/7, nous n'avons plus la possibilité de faire le chekdb le dimanche;
je me demandais si l'on faisait un checktable de toutes les tables (ou un checkfilegroup) cela serait-il équivalent a un chekdb ?
je parle bien sûr des userdatabases pas des bases systèmes.

merci de vos réponses

[Boubou2020]

Bonjour

DBCC CHECKDB =DBCC CHECKTABLE + DBCC CHECKALLOC + DBCC CHECKCATALOG

Si tu veux optimiser utiliser le avec l'option WITH NO_INFOMSGS (Cette clause vous permets de supprimer des centaines de messages, et ne renvoie que les erreurs trouvées)

[serge0934]

Merci pour ta réponse,

nous utilisons déjà cette option et ce n'est pas le temps pris par les messages qui gênent, le chekdb prend 9h sur un serveur 64core avec 256Go de RAM !
la base contient 1500 tables dont certaines font 500Go

pour préciser, on comptait faire des checktable au fil de l'eau suivant l'utilisation du serveur (ex: grosses tables la nuit de 3 a 4h du matin, les petites pendant le TP)

[SQLpro]

Il serait beaucoup plus intéressant d'organiser votre base entre données froides sur certains filegroups et données chaudes sur d'autres afin de faire des DBCC CHECKFILEGROUPS à différentes périodes (une fois la semaine pour données froide et une fois par jour pour les chaudes.
En effet DBCC CHECKDB et DBCC CHECKFILEGROUPS lancent les commandes DBCC en parallèle (donc réduit le temps de traitement) ce que ne fait pas DBCC CHECKTABLE.

Dans ce même ordre d'idée, il faut aussi orgeaiser vos sauvegardes par groupe de fichier avec exactement les même fréquences pour les même FILEGROUPS.

A +

[serge0934]

Merci Frédéric,

la séparation est faite entre données chaudes et froides (filegroups sur baie EMC D5, c'est sa config qui gère où elle mets ses filegroup, disque SSD ou pas)
donc si on a du parallèle avec le checkfilegroup, cela me parait intéressant
de plus synchroniser le backup des FG après le check est aussi une bonne idée...

petite question subsidiaire, si l'on backupe après le check, a-t'on besoin de faire un contrôle sur le backup ?

[SQLpro]

petite question subsidiaire, si l'on backupe après le check, a-t'on besoin de faire un contrôle sur le backup ?

L'un n'exclus pas l'autre... DBCC CHECK relit les données sur le disque alors que le BACKUP avec CHECKSUM contrôle les pages lues qu'elles soient ne mémoire (dans le cache) ou pour celle qui n'y sont pas, sur le disque. En conclusion, un certain nombre de pages lues ne sont pas vérifiées du disque par le BACKUP !

A +

[StringBuilder]

Bonjour,

Je me demande vaguement à quoi servent ces fonctions ?

J'étais persuadé (visiblement à tort) qu'elles étaient réservées aux tentatives de réparation après caractrophe (disque défectueux, arrêt inopiné du serveur, etc.) et non pour de la maintenance quotidienne...

En effet, le R dans SGBD-R, c'est pas justement la garantie que si la couche logicielle ne renvoie pas d'erreur, alors obligatoirement c'est que la partie physique est bonne ?
A savoir que SQL Server ne vérifie-t-il pas lui-même quand il écrit des données sur le disque qu'elles sont bien écrites ?

Mise à par de la vérification (et éventuellement de la tentative de récupération), que font ces fonctions ?

[SQLpro]

A savoir que SQL Server ne vérifie-t-il pas lui-même quand il écrit des données sur le disque qu'elles sont bien écrites ?

Oui si vous avez mis ce qu'il fallait :
ALTER DATABASE ... PAGE_VERIFY { CHECKSUM | TORN_PAGE_DETECTION }

Mise à par de la vérification (et éventuellement de la tentative de récupération), que font ces fonctions ?

Les disques s'endommagent naturellement par vieillissement. tant que vous ne passez pas sur une page qui n'a pas fait l'objet depuis de nombreux jours d'une récupération depuis le disque, reine ne vous dit que cette page n'est pas abîmée......

C'est comme les nids de poule. Ils éclosent naturellement du au gel et autres conditions (micro fissure).

C'est en passant dessus que vous allez les voir. pas en restant chez vous avec la photo de la route !

A +

[StringBuilder]

Ok.

Actuellement, j'ai un plan de maintenance qui fait un backup FULL toutes les 24 heures, et un LOG toutes les 10 minutes.

Le FULL lit donc toutes les données sur le disque, non ?

Du coup, si un secteur de disque est perdu, le FULL plante, et je sais que j'ai juste à restaurer le dernier FULL plus tous les LOG depuis, non ?

[SQLpro]

Ok.

Actuellement, j'ai un plan de maintenance qui fait un backup FULL toutes les 24 heures, et un LOG toutes les 10 minutes.

Le FULL lit donc toutes les données sur le disque, non ?

Non. Il ne lit sur le disque que les pages qu'il ne trouve pas en cache...

Du coup, si un secteur de disque est perdu, le FULL plante, et je sais que j'ai juste à restaurer le dernier FULL plus tous les LOG depuis, non ?

Uniquement pour les pages lues du disque.

A +