Msg*8909, Niveau*16, État*1, Ligne*1
Erreur de TABLE : Objet ID = 0, INDEX ID*=*0, page ID = (1:22988). ID de page de l'en-tête
de page = (0:0).
CHECKDB a trouvé 0 erreurs d'allocation et 1 erreurs de cohérence non associées à un
quelconque objet UNIQUE.
Msg*8928, Niveau*16, État*1, Ligne*1
Objet ID = 574885365, INDEX ID = 0 : La page (1:22988) ne peut pas être traitée. Pour
plus d'informations, consultez les autres erreurs.
Msg*8976, Niveau*16, État*1, Ligne*1
Erreur de table : Objet ID = 574885365, index ID = 1. Page (1:22988) n'a pas été trouvé
dans l'analyse bien que ses parents (1:22930) et (1:22987) précédents y font référence.
Contrôlez toutes les erreurs précédentes.
Msg*8978, Niveau*16, État*1, Ligne*1
Erreur de table : Objet ID = 574885365, index ID = 1. La page (1:22989) n'a pas de référence
dans la page précédente (1:22988). Possibilité d'un problème de liaison de chaîne.
CHECKDB a trouvé 0 erreurs d'allocation et 3 erreurs de cohérence dans la TABLE
'XXXXXXXX' (objet ID = 574885365).
CHECKDB a trouvé 0 erreurs d'allocation et 4 erreurs de cohérence dans la base de
données 'xxxxxxx'.
repair_allow_data_loss est le minimum de niveau de réparation pour les erreurs trouvés
par DBCC CHECKDB (chantier ).

Outre le fait qu’un problème matériel empêche tout bonnement la lecture d’une page depuis le disque, le CHECKDB indique deux autres erreurs 8978 et 8976, parlant d’un problème de liaison de page. On rappelle que chaque page de données ou d’index hors pages spéciales (IAM, DBINFO, SGAM, GAM, PFS, ML, DM,…) est liée à la page qui la précède et à la page qui la suit dans le plan d’allocation, mais aussi à une page parente dans un index.

Lorsqu’une page parente référence une page à un niveau inférieur du B-tree et que cette page n’est pas trouvée, alors DBCC CHECKDB renvoie une erreur 8976. Lorsqu’une page référence une page Next et que cette page n’est pas trouvée, alors DBCC CHECKDB renvoie une erreur 8978. Mais ces messages n’indiquent pas s’il ne s’agit que d’une corruption de l’entête de la page, ou aussi des données.

Ce qui veut dire que les données peuvent être bonnes alors que DBCC CHECKDB nous oriente vers un repair_allow_data_loss comme méthode de résolution, avec les conséquences que l’on sait (désallocation de la page qui pose problème et perte des données).

Dans le cas évoqué sur developpez.net, la personne ne dispose pas de backup, la question est de savoir quelles données il risque de perdre, et si les données ne sont pas endommagées, comment peut-il les récupérer.

Repro pour ce problème

Nous allons créer une base linkcorrupt et modifier la valeur du pointeur prevPageID dans une page de niveau feuille d’un index cluster pour forcer des erreurs 8976 et 8978.

create database linkcorrupt
GO
use linkcorrupt
GO
create table T1(
     a numeric identity,
     b char(4000) default replicate('b',4000),
     c bigint default round(rand()*100,0))
GO
insert into T1 default values
GO 1000
create unique clustered index IDX_T1C on T1(a)
GO

On va choisir une page du niveau feuille de l’index cluster (le dbcc ind a été purgé de certaines colonnes pour une meilleure lisibilité)

dbcc ind('linkcorrupt','T1',-1)

 PageFID PagePID     PageType  IndexLevel NextPageFID NextPagePID PrevPageFID PrevPagePID
 ------- ----------- --------  ---------- ----------- ----------- ----------- -----------
 1       90          10        NULL       0           0           0           0
 1       110         2         1          1           115         0           0
 1       115         2         1          0           0           1           110
 1       121         2         2          0           0           0           0
 1       672         1         0          1           673         0           0
 1       673         1         0          1           674         1           672
 1       674         1         0          1           675         1           673
 1       675         1         0          1           676         1           674
 1       676         1         0          1           677         1           675
 1       677         1         0          1           678         1           676
 1       678         1         0          1           679         1           677
 1       679         1         0          1           680         1           678
 1       680         1         0          1           681         1           679
 ...

De ce résultat on déduit que:

• La page 1:90 est la page IAM pour T1.
• La page 1:121 est la page racine de l’index cluster
• Les pages 1:110 et 1:115 sont des pages de niveau intermédiaire pour l’index cluster (on aura volontairement casé deux lignes par page pour augmenter le feuillage de l’index).
• Les autres pages sont les pages du niveau feuille de l’index cluster. On choisira de corrompre le pointeur prevPagePID dans la page 1:674. Comme l’index vient juste d’être construit, il est parfaitement clusterisé et les pages avant et après sont respectivement 1:673 et 1:675. On passe la base hors-ligne et on ouvre le fichier MDF dans xvi32.

alter database linkcorrupt set offline

La page 1:674 se trouve à l’offset 0×544000 dans le fichier mdf  (674*8192). Il est alors aisé de repérer les offset où sont stockés les pointeurs prev et next:

Le trait rouge représente l’offset 0 de la page 1:674. Les 96 premiers octets constituent l’entête de la page. x86 étant en little-endian, l’octet de poids faible est en premier donc il faut lire à l’envers. 02A1 représente notre page prev 1:673, 02A3 notre page next 1:675 et 02A2 notre PageID. On décide de zéro-initialiser l’octet de poids faible de 673 :

On repasse alors la base en ligne et on contrôle notre base pour vérifier qu’elle se trouve bien dans l’état attendu:

alter database linkcorrupt set online
GO
dbcc checkdb ('linkcorrupt') with no_infomsgs, all_errormsgs
GO

Msg 8928, Niveau 16, État 1, Ligne 1
ID d'objet 2073058421, ID d'index 1, ID de partition 72057594038386688,  ID d'unité d'allocation 72057594043367424 (type In-row data) :
impossible de traiter la page (1:674). Pour plus d'informations,  consultez les autres erreurs.
Msg 8939, Niveau 16, État 98, Ligne 1
Erreur de table : ID d'objet 2073058421, ID d'index 1, ID de partition  72057594038386688, ID d'unité d'allocation 72057594043367424
(type  In-row data), page (1:674). Échec du test (IS_OFF (BUF_IOERR,  pBUF->bstat)). Valeurs 12716041 et -4.
Msg 8976, Niveau 16, État 1, Ligne 1
Erreur de table : ID d'objet 2073058421, ID d'index 1, ID de partition  72057594038386688, ID d'unité d'allocation 72057594043367424
(type  In-row data). La page (1:674) n'a pas été détectée lors de l'analyse  alors que sa page parent (1:110) et les (1:673) pages précédentes
la  référencent. Vérifiez les erreurs précédentes.
Msg 8978, Niveau 16, État 1, Ligne 1
Erreur de table : ID d'objet 2073058421, ID d'index 1, ID de partition  72057594038386688, ID d'unité d'allocation 72057594043367424
(type  In-row data). Une référence de la page précédente (1:674) est manquante à  la page (1:675). Un problème de liaison de chaîne s'est
peut-être  produit.
CHECKDB a trouvé 0 erreurs d'allocation et 4 erreurs de cohérence dans la table 'T1' (ID d'objet 2073058421).
CHECKDB a trouvé 0 erreurs d'allocation et 4 erreurs de cohérence dans la base de données 'linkcorrupt'.
repair_allow_data_loss est le niveau minimum de réparation pour les erreurs trouvées par DBCC CHECKDB (linkcorrupt).

Identifier les plages de valeurs concernées par la corruption:

Une des questions qu’on peut se poser, comment savoir ce qu’il y a à récupérer (si les données ne sont pas touchées) ou ce qu’on va potentiellement perdre (si les données sont touchées).

Avant cela, il faut déjà récupérer tout le reste de la table en injectant les données jusqu’à la page 1:673 comprise et à partir de la page 1:675 comprise, puis d’inspecter la page 1:674 pour voir si les données qui y sont contenues sont lisibles. On sait que les pages sont classées physiquement dans l’ordre de notre clé clusterisée, donc il suffit pour exclure l’intervalle compris dans la page 1:674, de connaître la dernière valeur de ‘a’ dans la page 1:673 et la première valeur de ‘a’ dans la page 1:675.

On créé deux tables temporaires pour stocker le résultat des dbcc page sur les deux pages prev et next:

CREATE TABLE #recover673 (parentobject varchar(50), Object varchar(100), Field varchar(50), Value varchar(max))
GO
INSERT INTO #recover673  exec ('dbcc page(10,1,673,3) with tableresults')
GO

CREATE TABLE #recover675 (parentobject varchar(50), Object varchar(100), Field varchar(50), Value varchar(max))
GO
INSERT INTO #recover675  exec ('dbcc page(10,1,675,3) with tableresults')
GO

C’est la table d’offset de ligne qui permet de retourner les lignes dans l’ordre, dans les faits les lignes ne sont pas nécessairement classées physiquement dans la page. On se sert des slots pour connaître la dernière valeur de ‘a’ dans la page 1:673 et la première dans la page 1:675 (on rappelle qu’on n’a que deux lignes par page).

select Object, Value FROM #recover673 where Field='a'
Object                                    Value
--------------------------------------  ---------
Slot 0 Column 0 Offset 0x4 Length 9        3
Slot 1 Column 0 Offset 0x4 Length 9        4

select Object, Value FROM #recover675 where Field='a'

Object                                    Value
--------------------------------------  ---------
Slot 0 Column 0 Offset 0x4 Length 9        7
Slot 1 Column 0 Offset 0x4 Length 9        8

Il s’agit donc des valeurs de clé 5 et 6 qui sont dans la page qui pose problème. On créé une table à l’identique et on injecte les deux plages de valeurs [0;4] et [7;1000]:

select * into T1_backup from T1 where 1=2
GO
insert into T1_backup select a,b from T1 with (index = IDX_T1C) where a in (1,2,3,4)
GO
insert into T1_backup select a,b from T1 with (index = IDX_T1C) where a >=7
GO

En vert, un hint qui permet de forcer un seek sur l’index clusterisé. En effet, un Clustered Index Scan aurait tenté de lire les pages 1:673 -> 1:674 et aurait remonté une erreur de chaînage et une erreur 824.

Il ne reste plus qu’à essayer de lire le contenu de la page endommagée pour voir ce qu’il peut y avoir de récupérable:

CREATE TABLE #recover674 (parentobject varchar(50), Object varchar(100), Field varchar(50), Value varchar(max))
GO
insert into #recover674  exec ('dbcc page(17,1,674,3) with tableresults')
GO

Si la page est lisible alors une requête simple permet de ramener les valeurs au format de T1:

with TA as (select cast(Object as char(6)) SlotID, Value from #recover674 where Field='a'),
TB as (select cast(Object as char(6)) SlotID, Value from #recover674 where Field='b')
insert into T1_backup select TA.Value as 'a', TB.value as 'b' from TA inner join TB on TA.SLotID = TB.SlotID

a      b
-------------------------------
5      bbbbbbbbbbbbbbbbbbb(...)
6      bbbbbbbbbbbbbbbbbbb(...)

Dans le cas où les données ne sont pas lisibles, on a au moins l’information de la plage qui est perdue, information que ne donne pas le repair_allow_data_loss.

A+. David B.Continuez votre lecture sur le blog :

• Msg 2508, Level 16, State 1: the In-Row data %% for object %% is incorrect (David BAFFALEUF) [SQL Server]
• Regénérer le DDL des indexes FULL TEXT (David BAFFALEUF) [SQL Server]
• Suppression accidentelle de ligne : comment retrouver le coupable ? (David BAFFALEUF) [SQL Server]
• Alter table rebuild (Louis HOCHBERG) [SQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]

Globalement, ASE utilise des threads pour supporter toutes les tâches qu’il exécute: requêtes, IO réseau ou disque, connexions utilisateur, tâches internes… en conjonction avec son propre planificateur de tâche.

Le rôle du planificateur de tâche sur tout système est de partager le temps d’un CPU entre plusieurs unités d’exécution (tâches). Il existe deux grandes familles de planificateurs, les préemptifs, et les coopératifs.

Le planificateur préemptif a le pouvoir de planifier et d’interrompre les tâches selon des règles qui lui sont propres et sans tenir compte du type de tâche en cours d’exécution. One size fits all, comme on dit. Ce mécanisme, qui garantit qu’aucune tâche ne va monopoliser les ressources CPU, permet à chaque programme de pouvoir avoir la main sur la CPU à un moment où un autre. Sur la plupart des OS (linux, UNIX System V et Windows NT à partir de la 4.0), le planificateur alloue au thread un bail d’exécution ou un quantième. Si la tâche n’a pas terminé son travail dans le temps imparti, elle est interrompue. Lorsqu’il interrompt la tâche en cours, le planificateur sauvegarde son contexte dans un coin (c’est à dire les structures process + thread qui la représentent en mémoire), et planifie une nouvelle tâche sur la CPU. Ce qu’on appelle un changement de contexte.

Le planificateur coopératif, lui, va au contraire laisser à la tâche le soin de se terminer toute seule. C’est là la plus grosse différence, il n’interrompt pas une tâche qui n’a pas terminé son travail. C’est à la charge de la tâche de rendre la main pour laisser de la place aux autres, c’est donc à elle de prévoir un mécanisme de relâche (to yield = « céder »). Windows 3.1 employait un scheduler coopératif, les Windows 98 et 95 aussi pour assurer la compatibilité avec les programmes 16 bits.

Maintenant, on imagine facilement le risque d’employer un tel système de planification: une tâche qui part en vrille ne libèrera jamais la CPU, ça n’a donc plus été employé pour faire des operating systems.

Micheal Stonebraker avait publié un article de quelques pages au début des années 80* expliquant en gros que les ’services’ apportés par UNIX system V n’étaient pas adaptés au monde de la base de données, et notamment en matière de planification. Les tâches typiques issues des SGBD prennent plus de temps à s’effectuer car il ne s’agit pas de calcul mais d’IOs, et le mode préemptif n’est pas adapté car il ‘coupe’ la dynamique et l’efficacité du SGBD en produisant de nombreux changements de contexte.

Donc les développeurs chez Sybase ont répondu en créant un scheduler coopératif ‘on top‘ **, propre à Adaptive Server et par dessus le planificateur de l’OS, de telle manière à ce qu’il masque les choses vis à vis de celui-ci et limite au maximum les changements de contexte.

- Les tranches de temps:
ASE va donc fonctionner comme un OS, mais avec ses règles à lui: il gère sa propre planification, son propre partage du temps CPU, ses propres valeurs de quantième. Car bien que coopératif, il doit pouvoir stopper une tâche qui ne répond plus et éviter la saturation d’un engine. Lorsqu’il planifie une tâche, il va lui allouer un bail. Ce bail n’est pas une valeur temporelle, c’est un nombre de ticks d’horloge qui est décrémenté. Il est calculé en divisant le paramètre ‘timeslice’ par ’sql server clock tick length’. Comme les deux valeurs sont à 100 ms par défaut, le nombre de ticks d’horloge autorisé est de 1. Dans le déroulement de son exécution, une tâche va passer par des parties de code qu’on appelle des yield points, au cours desquels elle va prendre une seconde pour vérifier qu’elle n’a pas dépassé son bail. Si elle découvre que le bail est excédé (bail < 0), elle va demander à ASE de lui accorder une grace supplémentaire (cpu grace time), qui peut aller jusqu’à 500 ticks (soit 50 secondes). Si elle n’a pas terminé au delà de cette valeur, alors ASE sort les gros moyens, termine la tâche, annule ses transactions et affiche une stacktrace dans l’errorlog:

00:00000:00005:2007/04/02 22:09:24.07 kernel  timeslice -501, current process infected
00:00000:00005:2007/04/02 22:09:24.75 kernel  ************************************
00:00000:00005:2007/04/02 22:09:24.77 kernel  curdb = 1 tempdb = 2 pstat = 0x200
00:00000:00005:2007/04/02 22:09:24.77 kernel  lasterror = 0 preverror = 0 transtate = 1
00:00000:00005:2007/04/02 22:09:24.77 kernel  curcmd = 0 program =
...

Tout ceci se passe toujours sans que l’OS ne sache rien, car de son côté, le processus dataserver est toujours en exécution. C’est le but: l’OS ne doit pas interrompre le processus dataserver puisque celui-ci semble toujours travailler.

- Runnable Process search count:
Toujours dans le souci de préserver son exécution vis à vis de l’OS, lorsqu’il a terminé d’exécuter des tâches, et plutôt que de rendre la main tout de suite, Adaptive Server va entrer dans une boucle de vérification des IOs en attente côté réseau puis côté disque. S’il ne trouve rien, il va tourner (spinning) pour rechercher de nouvelles tâches en attente d’exécution, puis de nouvelles IOs réseau, puis de nouvelles IOs disques, etc… tout ça 2000 fois par défaut (runnable process search count), même s’il n’y a rien à traiter dans aucune file d’attente. Ce qui donne une apparente sensation d’hyperactivité côté OS, alors que côté Adaptive Sever, l’électro-encéphalo est plutôt plat.

Pour illustrer tout ça, une petite explication de la section ‘kernel’ de sp_sysmon:

Kernel Utilization
------------------

Your Runnable Process Search Count is set to 5000
and I/O Polling Process Count is set to 10

Engine Busy Utilization        CPU Busy   I/O Busy       Idle
------------------------       --------   --------   --------
Engine 0                       80.0 %      7.5 %     12.5 %
Engine 1                       80.8 %      6.0 %     13.2 %
Engine 2                       82.5 %      5.7 %     11.9 %
Engine 3                       84.0 %      6.7 %      9.3 %
Engine 4                       79.0 %      6.8 %     14.2 %
Engine 5                       80.0 %      7.3 %     12.7 %
Engine 6                       79.6 %      8.3 %     12.0 %
------------------------       --------   --------   --------
Summary           Total         565.9 %     48.4 %     85.7 %
Average                         80.8 %      6.9 %     12.2 %

Avant de commencer, il faut bien rappeler le cheminement de la boucle:

Chaque engine tient le compte de ticks reçus de l’OS (par le biais de signaux SIGALRM) tous les 100ms, et les répertorie selon trois catégories:

CPU Busy: représente le temps (en fait le nombre de ticks ramené en pourcentage) passé par l’engine à exécuter une tâche sur l’intervalle.
Idle: représente le temps passé par l’engine à n’exécuter aucune tâche sur l’intervalle.
I/O Busy: est une soustraction de Idle. Il s’agit du temps passé par l’engine à n’exécuter aucune tâche (donc Idle) mais où il y avait au moins une IO disque en attente dans la file. Elle représente donc la quantité de temps où l’engine n’a pas pu exécuter une tâche parce qu’il y avait au moins une IO disque en attente.

On peut retrouver ces valeurs brutes en interrogeant les variables globales @@cpu_busy, @@idle, et @@io_busy. La durée d’un tick peut être retrouvée avec @@timeticks.

A+. [ David B. ]

*: Michael Stonebraker, Operating System Support for Database Management, CACM 24(7), p412-418 (1981).
**: et Microsoft fit de même en dotant SQL Server 7.0 de son propre scheduler coopératif (UMS), toujours bien présent en version 2008 sous une autre dénomination (SQLOS).

Continuez votre lecture sur le blog :

• Formation Optimisation de requêtes (David BAFFALEUF) [SQL Server]
• Voucher certification SQL Server 70-432 offert ! (David BAFFALEUF) [SQL Server]
• Scruter les journaux d’évènements Windows avec LogParser (David BAFFALEUF) [SQL Server]
• Abonnez-vous au blog de la CapData team ! (Cédric PEINTRE) [GénéralMySQLOracleSQL ServerSybase]
• Intérêt de créer des indexes cluster uniques (David BAFFALEUF) [SQL Server]