Erreur 8645 - Délai dépassé. Comment identifier son origine ?

**deltro40** · 29/04/2016, 12h11

Bonjour,
Je rencontre chez un client cette erreur, qui survient lors sur des périodes d'activités précises (périodes de facturation).
Erreur (8645) : Le délai a été dépassé pendant l'attente de ressources mémoire pour exécuter la requête dans le pool de ressources 'default' (2). Réexécutez la requête.
Nous sommes éditeurs de leur solution de gestion (modulaire : facturation / planning / modules métiers etc.).
Cela survient tous les mois et cela correspond à une période où ils utilisent intensivement un module spécifique (facturation). L'erreur survient sur des périodes de quelques minutes, durant lesquelles l'application est trèe lente, voire inutilisable.

Le serveur me semble bien dimensionné (par rapport à nos autres clients qui ne rencontrent pas le problème) : 64 Go de RAM, 50 dédiés.
Grâce aux DMV j'ai fait toutes les optimisations possibles (analyses des requêtes consommatrices, ajouts d'index manquants, suppression des index inutiles coûteux en maintenance, mise en place des plans de maintenance etc.).
Je dois avoir une requête sur un traitement de ce module qui génère cela mais je ne sais pas comment l'identifier. J'ai mis en place des sondes perfmon sur les principaux indicateurs SQLServer qui mettent en évidence des pics sur les indicateurs suivants :
- Memory Grants Timeout / sec
- Connections reset / sec

Je sèche un peu et ne vois plus comment avancer. Auriez vous une idée pour identifier les causes possibles?
Merci d'avance

**SQLpro** · 29/04/2016, 12h49

Mettez en place le "blocked process report" avec un seuil proche des 30 secondes (par exemple 25). Et associez une tache du profiler. Puis visitez cette trace dès que le problème survient.

Voici le script que j'utilise en clientèle :

1) activation :

Code :

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

1
2
3
EXEC sp_configure 'blocked process threshold', 25
go
reconfigure

2) mise en place d'une session du profiler SQL traçant le "blocked process report" et les verrous mortels

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
/****************************************************
SETTING Blocked Process Report in SQL Profiler
****************************************************/
exec sp_configure 'xp_cmdshell',1 ;
Go
RECONFIGURE ;
go
 
exec xp_cmdshell 'mkdir "C:\Trace_block\"'
go
 
exec sp_configure 'xp_cmdshell',0 ;
Go
RECONFIGURE ;
go
 
EXEC sp_configure 'blocked process threshold', 10
go
RECONFIGURE;
GO
 
declare @fp VARCHAR(256);
declare @rc int;
declare @TraceID int;
declare @maxfilesize bigint;
set @maxfilesize = 50;
set @fp = N'C:\Trace_block\BlockReport_' 
 
exec @rc = sp_trace_create @TraceID output, 2, @fp, @maxfilesize, NULL, 25
if (@rc != 0) goto error
 
declare @on bit
set @on = 1
exec sp_trace_setevent @TraceID, 137, 1, @on
exec sp_trace_setevent @TraceID, 137, 3, @on
exec sp_trace_setevent @TraceID, 137, 4, @on
exec sp_trace_setevent @TraceID, 137, 12, @on
exec sp_trace_setevent @TraceID, 137, 13, @on
exec sp_trace_setevent @TraceID, 137, 14, @on
exec sp_trace_setevent @TraceID, 137, 22, @on
exec sp_trace_setevent @TraceID, 137, 15, @on
exec sp_trace_setevent @TraceID, 137, 24, @on
exec sp_trace_setevent @TraceID, 137, 26, @on
exec sp_trace_setevent @TraceID, 137, 32, @on
exec sp_trace_setevent @TraceID, 137, 41, @on
exec sp_trace_setevent @TraceID, 137, 51, @on
exec sp_trace_setevent @TraceID, 137, 60, @on
exec sp_trace_setevent @TraceID, 137, 64, @on
exec sp_trace_setevent @TraceID, 148, 1, @on
exec sp_trace_setevent @TraceID, 148, 41, @on
exec sp_trace_setevent @TraceID, 148, 4, @on
exec sp_trace_setevent @TraceID, 148, 12, @on
exec sp_trace_setevent @TraceID, 148, 11, @on
exec sp_trace_setevent @TraceID, 148, 51, @on
exec sp_trace_setevent @TraceID, 148, 14, @on
exec sp_trace_setevent @TraceID, 148, 26, @on
exec sp_trace_setevent @TraceID, 148, 60, @on
exec sp_trace_setevent @TraceID, 148, 64, @on
exec sp_trace_setevent @TraceID, 25, 1, @on
exec sp_trace_setevent @TraceID, 25, 9, @on
exec sp_trace_setevent @TraceID, 25, 2, @on
exec sp_trace_setevent @TraceID, 25, 66, @on
exec sp_trace_setevent @TraceID, 25, 10, @on
exec sp_trace_setevent @TraceID, 25, 3, @on
exec sp_trace_setevent @TraceID, 25, 4, @on
exec sp_trace_setevent @TraceID, 25, 6, @on
exec sp_trace_setevent @TraceID, 25, 7, @on
exec sp_trace_setevent @TraceID, 25, 8, @on
exec sp_trace_setevent @TraceID, 25, 11, @on
exec sp_trace_setevent @TraceID, 25, 12, @on
exec sp_trace_setevent @TraceID, 25, 13, @on
exec sp_trace_setevent @TraceID, 25, 14, @on
exec sp_trace_setevent @TraceID, 25, 15, @on
exec sp_trace_setevent @TraceID, 25, 22, @on
exec sp_trace_setevent @TraceID, 25, 25, @on
exec sp_trace_setevent @TraceID, 25, 26, @on
exec sp_trace_setevent @TraceID, 25, 32, @on
exec sp_trace_setevent @TraceID, 25, 35, @on
exec sp_trace_setevent @TraceID, 25, 41, @on
exec sp_trace_setevent @TraceID, 25, 49, @on
exec sp_trace_setevent @TraceID, 25, 51, @on
exec sp_trace_setevent @TraceID, 25, 52, @on
exec sp_trace_setevent @TraceID, 25, 55, @on
exec sp_trace_setevent @TraceID, 25, 56, @on
exec sp_trace_setevent @TraceID, 25, 57, @on
exec sp_trace_setevent @TraceID, 25, 58, @on
exec sp_trace_setevent @TraceID, 25, 60, @on
exec sp_trace_setevent @TraceID, 25, 64, @on
exec sp_trace_setevent @TraceID, 59, 1, @on
exec sp_trace_setevent @TraceID, 59, 25, @on
exec sp_trace_setevent @TraceID, 59, 2, @on
exec sp_trace_setevent @TraceID, 59, 3, @on
exec sp_trace_setevent @TraceID, 59, 4, @on
exec sp_trace_setevent @TraceID, 59, 12, @on
exec sp_trace_setevent @TraceID, 59, 14, @on
exec sp_trace_setevent @TraceID, 59, 22, @on
exec sp_trace_setevent @TraceID, 59, 21, @on
exec sp_trace_setevent @TraceID, 59, 26, @on
exec sp_trace_setevent @TraceID, 59, 32, @on
exec sp_trace_setevent @TraceID, 59, 35, @on
exec sp_trace_setevent @TraceID, 59, 41, @on
exec sp_trace_setevent @TraceID, 59, 49, @on
exec sp_trace_setevent @TraceID, 59, 51, @on
exec sp_trace_setevent @TraceID, 59, 52, @on
exec sp_trace_setevent @TraceID, 59, 55, @on
exec sp_trace_setevent @TraceID, 59, 56, @on
exec sp_trace_setevent @TraceID, 59, 57, @on
exec sp_trace_setevent @TraceID, 59, 58, @on
exec sp_trace_setevent @TraceID, 59, 60, @on
exec sp_trace_setevent @TraceID, 59, 64, @on
 
declare @intfilter int
declare @bigintfilter bigint
 
exec sp_trace_setstatus @TraceID, 1
 
-- display trace id for future references
select TraceID=@TraceID
goto finish
 
error: 
select ErrorCode=@rc
 
finish: 
go
/*
--> tops it (if the trace has id = 2)
exec sp_trace_setstatus 2, 0;
go
exec sp_trace_setstatus 2, 2;
go
*/

3) lors de la survenance de l'événement, utilisez la requête suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
SELECT TOP 50 TextData, StartTime, EventClass, e.name AS EventName
FROM   sys.fn_trace_gettable('C:\Trace_block\BlockReport_.trc', 25) AS t
       LEFT OUTER JOIN (SELECT * FROM sys.trace_events 
	                   UNION ALL
					   SELECT 65534, 0, 'TraceStart'
					   UNION ALL
					   SELECT 65533, 0, 'TraceStop'
					   UNION ALL 
					   SELECT 65528, 0, 'FirstFile'
					   UNION ALL
					   SELECT 65527, 0, 'NextFile') AS e
	         ON EventClass = trace_event_id
ORDER  BY StartTime DESC;

A +

**deltro40** · 29/04/2016, 14h26

Bonjour Frédéric, et merci pour votre réponse (pleine d'espoir pour moi).
J'ai mis en place la trace, j'espère (!) que le phénomène va se produire rapidement...
J'ai adapté la requête de création de trace (seuil de déclenchement à 25 au lieu de 10).
Je ne pense pas que cela ait d'incidence mais pour être précis le serveur SQL est en version 2012 (SP2 CU3) et pas 2014 comme dit dans le titre.

Pas de risque d'activer ceci en production ?
Merci de votre aide, je reviens vers vous dès que j'aurai de nouveaux éléments.

**SQLpro** · 29/04/2016, 15h11

Envoyé par deltro40

Pas de risque d'activer ceci en production ?
Merci de votre aide, je reviens vers vous dès que j'aurai de nouveaux éléments.

Non, et vous avez pas le choix !!!!

Sauf si vous avez 1234 deadlock par seconde !!!!!

A +

**elsuket** · 03/05/2016, 21h30

Bonjour,

Pour le paramètre blocked processed threshold en production à 5, et je n'ai jamais rencontré de problèmes.
En mettant moins par contre, les utilisateurs le remarquent

Ceci étant dit, l'erreur suggère une pression mémoire :

Erreur (8645) : Le délai a été dépassé pendant l'attente de ressources mémoire pour exécuter la requête dans le pool de ressources 'default' (2). Réexécutez la requête.

Lors de la compilation d'une requête, le moteur lui attribue une certaine quantité de mémoire pour s'exécuter, qui se trouve parfois être largement sur- ou sous-évaluée.

Il serait intéressant d'analyser les attentes de cette instance, si la base est la seule à y être hébergée, ou en tous la plus largement utilisée.
Il suffit pour cela de s'aider de la requête de Paul Randal sur la DMV sys.dm_os_wait_stats.

Vous avez alors deux solutions :

soit vous remettez les statistiques à zéro (DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR))
soit vous stockez des "photos" de cette requête, et vous les comparez les uns avec les autres pour voir leur évolution

C'est une vue que l'on peut auditer à intervalles régulier de façon à avoir une baseline

@++

**deltro40** · 20/06/2016, 15h09

Bonjour,
après plus d'un mois de fonctionnement normal, nous avons de nouveau rencontré le problème (la semaine dernière, deux jours de suite).
Malheureusement, les traces mises en place n'ont rien remonté. Dois je baisser le seuil (25 secondes actuellement) ?

J'ai exécuté la requête DMV de Paul Randal. Je n'ai qu'un type d'attente qui remonte : ASYNC_NETWORK_IO (98%). J'ai les mêmes résultats chez d'autres clients pour qui je ne rencontre pas le problème.
Je comprends qu'il s'agit d'une stat cumulative, d'où l'utilité de remettre à zéro les compteurs, mais je ne vois pas trop comment stocker cela et comment l'interpréter. Avez vous des pistes ?
Merci pour votre aide!

**elsuket** · 21/06/2016, 17h32

Bonjour,

Malheureusement, les traces mises en place n'ont rien remonté. Dois je baisser le seuil (25 secondes actuellement) ?

Vous pouvez le mettre à 5 sans que cela ne pose de problème de performances.
En revanche attention à l'interprétation de la trace : si la situation de blocage dure par exemple 11 secondes, vous aurez deux événements pour la même situation de blocage.

La requête de Paul Randal est intéressante si l'on analyse le nombre d'attentes et leur durée moyenne. Si vous avez 98% de ASYNC_NETWORK_IO, et que leur nombre est élevé, mais que leur durée moyenne est très courte, ce n'est certainement pas un problème : c'est simplement l'application qui consomme les jeux de données en sortie de SQL Server. Si en revanche ceux-ci sont peu nombreux mais que leur durée moyenne se chiffre en secondes, c'est peut-être que l'application ne parvient pas à consommer le résultat de certaines requêtes suffisamment rapidement.

Je comprends qu'il s'agit d'une stat cumulative, d'où l'utilité de remettre à zéro les compteurs, mais je ne vois pas trop comment stocker cela et comment l'interpréter. Avez vous des pistes ?

Vous pouvez prendre des captures régulières de la DMV, ou de la requête que propose Paul Randal, et les stocker dans une base de données dédiée à l'audit / baseline.
En numérotant les captures, vous pouvez alors mesurer de combien chaque type d'attentes a augmenté. Il n'est donc pas nécessaire de ré-initialiser cette DMV. Par ailleurs elle l'est automatiquement au redémarrage de l'instance, qui peut se faire lorsqu'on applique les patchs Microsoft mensuellement. D'où l'intérêt d'en stocker le contenu régulièrement

Pour en revenir à votre problème, je pense plutôt à un problème de pression mémoire.
Est-ce que par exemple la valeur du compteur de performance Page Life Expectancy de la catégorie SQL Server : Buffer Manager chute lors de l’occurrence des tels problèmes ?
Notez que vous pouvez corréler une trace PerfMon avec un trace SQL Trace nativement à l'aide de l'interface de SQL Profiler

Tout ceci est détaillé dans le livre en référence dans ma signature

@++

**deltro40** · 27/06/2016, 11h53

Bonjour,
merci pour ce retour.
Je vais mettre en place le plan d'action évoqué :
- Baisse du seuil à 5 secondes.
- Historisation des DMV

Concernant la pression mémoire, j'ai collecté tous les compteurs SQL durant le phénomène de lenteur. Voici les valeurs significatives :
Nom : Capture.PNG
Affichages : 468
Taille : 22,2 Ko

Nom : Capture.PNG
Affichages : 468
Taille : 22,2 Ko

Les évènements 8645 ont générés sur deux périodes de quelques secondes, correspondant aux pics de l'indicateur bleu : Memory grant timeouts / sec
Je n'ai pas relevé d'autres indicateurs en pic sur la période.

Le page life expectancy est en jaune. Je n'avais effectivement pas remarqué mais il est en augmentation constante et chute à zéro à 22h :
Nom : Capture2.PNG
Affichages : 447
Taille : 21,4 Ko

Nom : Capture2.PNG
Affichages : 447
Taille : 21,4 Ko

Il y a le plan de maintenance qui s'exécute à 21h30 mais je ne vois rien qui pourrait expliquer cela. (pas de redémarrage de l'instance d'après l'analyse des journaux d'évènements)

Merci pour la référence à l'ouvrage, je regarde cela!

**elsuket** · 27/06/2016, 17h54

Petite chute du compteur : il est bizarre déjà que le compteur soit à 80, et chute ensuite. En tous cas il est clair que vous avez de la pression mémoire.
Ce compteur nous donne le nombre moyen de secondes qu'une page de la base de données (pour simplifier drastiquement, un espace de stockage de 8Ko) reste en RAM.
Évidemment, plus la valeur de ce compteur est élevée, meilleures sont les performances : cela signifie qu'il y a peu d'opérations de récupération des données sur disque, et d'aller-retours des pages entre les disques et la RAM.
En effet, toute opération de lecture ou d'écriture se fait exclusivement en RAM, qui est bien plus rapide que les disques, même SSD.

Je vous invite à lire ce petit article (les captures d'écran ont disparu, mais cela reste compréhensible) sur le sujet.

C'est donc soit que vous avez des requêtes qui lisent beaucoup de pages, soit parce qu'elles sont mal exprimées, soit pas manque d'index, soit par défaut de maintenance de ceux-ci et des statistiques de colonnes et d'index.
Visiblement la maintenance n'est pas le problème, puisque vous avez un plan, mais il faudrait le décortiquer pour savoir s'il fait bien le travail.

Il démarre à 22h, mais à quelle heure se termine-t-il ? Avez-vous pris une trace SQL Profiler pour la corréler avec celle du PerfMon ?
Cela vous aiderait à savoir quelle requête provoque ce problème.

@++

**deltro40** · 28/06/2016, 09h51

Bonjour,
je n'ai malheureusement pas sur ce créneau les traces profiler + compteurs perfmon, me permettant de superposer leur analyse.
Je mets cela en place et attends un nouveau phénomène de lenteur.
Concernant les plans de maintenance, voici la durée des opérations le 28/04, date des remontées communiquées dans mon précédent message.

la sauvegarde : 21h30 durée 05min
le checkdb : 22 minutes
réorganisation des index : 26 minutes
calcul des stats : 30 minutes

Je remarque quelque chose d'étonnant : depuis le 09 juin, la durée des plan de maintenance s'est allongée :

le checkdb : 22 minutes -> 50 minutes
réorganisation des index : 30 minutes -> 40 minutes
calcul des stats : 30 minutes -> 1 heure

Je n'ai aucune explication à ce ralentissement. Est ce une information intéressante pour ma problématique?

D'autre part merci pour l'article très clair.
Je comprends donc bien l'intérêt et je mets cet indicateur en surveillance. J'ai lu des témoignages de personnes ayant rencontré également une chute de PLE lors d'un checkdb. Possible?
Parallèlement je refais une analyse des index manquants et des requêtes à problème.

**elsuket** · 28/06/2016, 14h52

Je n'ai aucune explication à ce ralentissement. Est ce une information intéressante pour ma problématique?

C'est possible. Comme nous sommes à tâtons, il ne faut exclure aucune hypothèse.
Est-ce que quelque chose de spécial s'est passé ce jour là, par exemple : changement de hardware, changement des options de configuration de la base ou de l'instance, chargement massif de données, ...

J'ai lu des témoignages de personnes ayant rencontré également une chute de PLE lors d'un checkdb. Possible?

Tout à fait. Supposons que votre base fait 100Go et que vous avez octroyé 10Go de RAM à SQL Server.
Dans ce cas la base de données ne peut pas tenir entièrement en RAM, donc certaine requêtes vont nécessiter la copie des pages sur disque vers la RAM pour qu'elles soient ensuite traitées.
A ce moment là, la valeur du compteur PLE descend, puisqu'alors la durée de vie des pages en RAM diminue.

Dans le cas du DBCC CHECKDB, cette opération vérifie l'intégrité de toute la base. Donc il faut que le moteur copie toutes les pages en RAM. D'où la chute de la valeur de ce compteur.

@++

**SQLpro** · 28/06/2016, 15h45

Envoyé par deltro40

Je n'ai aucune explication à ce ralentissement. Est ce une information intéressante pour ma problématique?

Les allongements de durées peuvent avoir de multiples causes. Trois exemples parmi d'autres :

vous êtes en VM et cette VM et modifiée (son stockage a été déplacé sur un endroit de l'espace de stockage plus sollicité, on a baissé la RAM, le nombre de coeurs...)
vous avez ajouté une étape qui fait un SHRINK de la base
Vous êtes en VM et sur la machine hôte on a ajouté quelques VM upplémentaires...

Le fait que le page life expectansy tombe avec le CHECKDB est normal. Un CHECKDB remonte toutes les pages de la base en mémoire

Le fait d'avoir un page life expectansy aussi bas en production est catastrophique...
Le strict minimum serait d'avoir 600, mais en réalité bien plus : fonction du nombre de cœur et de la taille des données "actives"...

A +

**elsuket** · 28/06/2016, 17h03

Pour la PLE, je fais le calcul suivant :

(mémoire allouée à SQL Server / le nombre de nœuds NUMA ) * 300 / 8192.0

Si la valeur de la PLE pour chaque noeud NUMA est au-dessus du résultat de ce calcul, c'est bon.
La règle de trois * 300 / 8192 vient de la recommendation qu'avait fait MS pour SQL Server 2000, où je considère qu'à cette époque, les serveurs avaient 8Go de RAM en moyenne.

@++

**deltro40** · 28/06/2016, 17h05

Bonjour SQLpro, re-bonjour Elsuket

Est-ce que quelque chose de spécial s'est passé ce jour là, par exemple : changement de hardware, changement des options de configuration de la base ou de l'instance, chargement massif de données, ...

Pas à ma connaissance mais je valide cela. Effectivement c'est une VM et je n'ai pas la visu de l'hôte...

Le fait d'avoir un page life expectansy aussi bas en production est catastrophique...
Le strict minimum serait d'avoir 600, mais en réalité bien plus : fonction du nombre de cœur et de la taille des données "actives"...

Je lis peut être mal le perfmon mais j'ai une échelle à 0.001. Ramené aux vrais valeurs cela me fait donc 60000 en début de courbe, qui monte à 80000 avant le checkdb, chute à 100 (103 exactement selon la valeur mini perfmon).
C'est bien cela? Autrement dit est-ce vraiment catastrophique?

Merci à vous!

**deltro40** · 28/06/2016, 17h21

(mémoire allouée à SQL Server / le nombre de nœuds NUMA ) * 300 / 8192.0

OK ce qui me fait un PLE recommandé à 1912.5 si mes calculs sont exacts (51 Go dédiés, 1 noeud NUMA).
J'ai un doute sur le nombre de noeuds NUMA : dans les propriétés de mon instance, partie CPU, j'ai l'arborescence TOUT / NumaNode0 / liste des CPU. Cela me permet de valider que je n'ai qu'un seul NUMA ou rien à voir ?

**elsuket** · 29/06/2016, 14h57

Je lis peut être mal le perfmon mais j'ai une échelle à 0.001. Ramené aux vrais valeurs cela me fait donc 60000 en début de courbe, qui monte à 80000 avant le checkdb, chute à 100 (103 exactement selon la valeur mini perfmon).
C'est bien cela? Autrement dit est-ce vraiment catastrophique?

Le fait est que l'on ne voit pas le compteur PLE sur les captures d'écran que vous avez partagé

60000 secondes équivaut à 1000 minutes, soit 16 heures, donc c'est très bon. Durant le CHECKDB, comme nous vous l'avons expliqué avec SQLPro, c'est normal.
Ce qu'il faut observer, c'est la vitesse à laquelle cette valeur remonte. Vous pouvez corréler notamment avec le compteur Buffer Cache Hit Ratio.

51 Go dédiés

Est-ce la valeur de l'option max server memory ?

J'ai un doute sur le nombre de noeuds NUMA : dans les propriétés de mon instance, partie CPU, j'ai l'arborescence TOUT / NumaNode0 / liste des CPU. Cela me permet de valider que je n'ai qu'un seul NUMA ou rien à voir ?

Si effectivement vous ne voyez pas de NumaNode1, c'est que vous n'avez qu'un seul nœud NUMA.

@++

**deltro40** · 29/06/2016, 15h43

Bonjour Elsuket,

Le fait est que l'on ne voit pas le compteur PLE sur les captures d'écran que vous avez partagé

Si, le compteur PLE est un jaune sur les courbes (il est sélectionné sur la première courbe).

J'ai refait la courbe sur la même période (le jour des phénomènes de lenteurs), avec seulement PLE et Buffer Cache Hit Ratio :
Nom : Capture3.PNG
Affichages : 442
Taille : 19,3 Ko

Nom : Capture3.PNG
Affichages : 442
Taille : 19,3 Ko

Sur une période élargie, (7 jours), effectivement le PLE joue au yoyo (chute à chaque checkdb) :
Nom : Capture4.PNG
Affichages : 424
Taille : 29,7 Ko

J'ai lu avec intérêt votre billet concernant le checkdb. Ne serait-ce pas préférable de n'exécuter cette opération non pas quotidiennement mais de façon hebdomadaire pour éviter ces pics ? (Les sauvegardes sont bien faites avec historique

)

Sinon les 51Go sont bien dédiés à l'instance (51000 Mo en max server memory, 64 Go au total sur le serveur). L'instance contient 2 bases ( la base de prod et une base de recette, réplicat de la prod rarement rafraîchi ).

Merci!

**elsuket** · 30/06/2016, 00h29

J'ai lu avec intérêt votre billet concernant le checkdb. Ne serait-ce pas préférable de n'exécuter cette opération non pas quotidiennement mais de façon hebdomadaire pour éviter ces pics ?

Exécuter DBCC CHECKDB quotidiennement est peut-être un luxe. En fait, comme bien souvent, ça dépend.
Vous pouvez penser à subdiviser la vérification d'intégrité en lots, comme le décrit Mikedavem dans cet article.

Vous pouvez en plus :

- Ajouter des alertes de l'Agent SQL Server sur le numéros d'erreur 823 à 825 qui sont liées à la détection d'un défaut d'intégrité;
- Positionner, si ce n'est pas déjà fait, l'option PAGE_VERIFY à CHECKSUM pour la base de données;
- Prendre vos sauvegardes et les restaurer avec l'option CHECKSUM.

Ces trois éléments ne remplaçant en rien le contrôle complet de l'intégrité, notamment avec l'option DATA_PURITY, vous pouvez vous servir du dernier backup FULL de la base de données pour le restaurer sur une autre instance SQL Server peu ou pas utilisée, et exécuter DBCC CHECKDB sur cette copie de la base.

Éventuellement, la mise en mirroir ou dans une topologie AlwaysOn permet la copie d'une page corrompue sur la base écrite à partir du réplica en lecture seule, sous certaines restrictions (i.e. pas tout le temps).

Vous pouvez en sus demander à vos collègues administrateurs système d'ajouter des alertes pour le journal d'événement Windows sur détection de corruption.

@++

**olivtone** · 30/06/2016, 10h12

Salut

personnellement je fais un CHECKDB WITH PHYSICAL ONLY toutes les nuits et non un complet, et j'en lance un tous les dimanches en complet

Jamais eu de souci jusque la...

Erreur 8645 - Délai dépassé. Comment identifier son origine ?

Administration SQL Server

Discussions similaires

Partager

Partager