Problématique SQL 2005
Le
Forum Microsoft
Bonjour à toutes et à tous,
Un de mes clients rencontre le problème suivant avec SQL Server 2005
Standard (côté serveur) et parfois côté clients avec SQL 2005 Express.
Il y a quelques mois, ils avaient dû réinstaller le serveur SQL 2005
et les postes clients (versions express) avec tous les bons droits, les
bons comptes et services, ainsi que l'optimisation des requêtes sous
l'oeil attentif d'un consultant MS, mais il existe toujours ces
problèmes récurrents, qui sont souvent aléatoires:
Les requêtes passées en Insert, Update, Delete sont très simples (au
max: 2 à 3 valeurs modifiées par requêtes) et avec une fréquence d'une
dizaine de requêtes à la minute.
" Nous rencontrons des problèmes sur la base de données des droits
Global_DP. Les requêtes INSERT, UPDATE et DELETE echouent pendant un
moment puis réussissent à nouveau sans explications. Côté SQL, l'erreur
récurrente est:
2007-01-16 03:14:01.55 spid59 Autogrow of file 'GlobalDP_log' in
database 'GlobalDP' was cancelled by user or timed out after 2109
milliseconds. Use ALTER DATABASE to set a smaller FILEGROWTH value for
this file or to explicitly set a new file size.
En fait, le fichier GlobalDP_Log est à croissance limitée à 5000Mo avec
une croissance de 10% et atteint actuellement 3000Mo.
TRACES de l'applicatif au moment des erreurs
11/01/07:14:59:12;[Info ] SQL : DELETE T_AFF_PRI FROM T_AFF_PRI AS AP
INNER JOIN T_AFF AS A ON AP.AFFPRI_AFFNUM = A.AFF_NUM WHERE
A.AFF_STATION='CDM-P3BCIN11';CDPDatabase::ADORead()
11/01/07:14:59:14;[Error ] _com_error [80040e31] Message: IDispatch
error #3121. Source: Microsoft SQL Native Client Description: Délai
d'attente de requête expiré;CDPDatabase::ADOCatchDBException()
OU ENCORE
11/01/07:14:59:14;[Info ] SQL : UPDATE T_UPDATE_GTMH SET UPDATE_GTMH =
1;CDPDatabase::ADORead()
11/01/07:14:59:16;[Error ] _com_error [80040e31] Message: IDispatch
error #3121. Source: Microsoft SQL Native Client Description: Délai
d'attente de requête expiré;CDPDatabase::ADOCatchDBException()
Si vous aviez une idée
Merci de votre aide.
Cordialement,
Forum
Un de mes clients rencontre le problème suivant avec SQL Server 2005
Standard (côté serveur) et parfois côté clients avec SQL 2005 Express.
Il y a quelques mois, ils avaient dû réinstaller le serveur SQL 2005
et les postes clients (versions express) avec tous les bons droits, les
bons comptes et services, ainsi que l'optimisation des requêtes sous
l'oeil attentif d'un consultant MS, mais il existe toujours ces
problèmes récurrents, qui sont souvent aléatoires:
Les requêtes passées en Insert, Update, Delete sont très simples (au
max: 2 à 3 valeurs modifiées par requêtes) et avec une fréquence d'une
dizaine de requêtes à la minute.
" Nous rencontrons des problèmes sur la base de données des droits
Global_DP. Les requêtes INSERT, UPDATE et DELETE echouent pendant un
moment puis réussissent à nouveau sans explications. Côté SQL, l'erreur
récurrente est:
2007-01-16 03:14:01.55 spid59 Autogrow of file 'GlobalDP_log' in
database 'GlobalDP' was cancelled by user or timed out after 2109
milliseconds. Use ALTER DATABASE to set a smaller FILEGROWTH value for
this file or to explicitly set a new file size.
En fait, le fichier GlobalDP_Log est à croissance limitée à 5000Mo avec
une croissance de 10% et atteint actuellement 3000Mo.
TRACES de l'applicatif au moment des erreurs
11/01/07:14:59:12;[Info ] SQL : DELETE T_AFF_PRI FROM T_AFF_PRI AS AP
INNER JOIN T_AFF AS A ON AP.AFFPRI_AFFNUM = A.AFF_NUM WHERE
A.AFF_STATION='CDM-P3BCIN11';CDPDatabase::ADORead()
11/01/07:14:59:14;[Error ] _com_error [80040e31] Message: IDispatch
error #3121. Source: Microsoft SQL Native Client Description: Délai
d'attente de requête expiré;CDPDatabase::ADOCatchDBException()
OU ENCORE
11/01/07:14:59:14;[Info ] SQL : UPDATE T_UPDATE_GTMH SET UPDATE_GTMH =
1;CDPDatabase::ADORead()
11/01/07:14:59:16;[Error ] _com_error [80040e31] Message: IDispatch
error #3121. Source: Microsoft SQL Native Client Description: Délai
d'attente de requête expiré;CDPDatabase::ADOCatchDBException()
Si vous aviez une idée
Merci de votre aide.
Cordialement,
Forum
Poser une question
Bonjour,
Peut-être un effet de LOCK_TIMEOUT (SELECT @@LOCK_TIMEOUT pour voir s'il y
a une valeur), ou du Query Wait (propriétés du serveur) ?
En tout cas, l'autogrow en pourcentage n'est pas une bonne idée, cela
provoque une augmentation proportionnelle. Il vaudrait mieux mettre une
valeur fixe, par exemple 100 MB, ce qui diminuerait le temps d'autogrow et
réglerait probablement le problème de délai.
Mais le défaut est que cela va séparer le log en multiples VLF, et diminuer
les performances. Pourquoi ne pas mettre directement la taille du log à 5
GB ?
--
Rudi Bruchez
Consultant indépendant SQL Server
MCDBA, MCT, SCJP2
http://www.babaluga.com/
Votre consultant aurait du vous dire qu'utiliser des fichiers à taille
variable avec croissance automatique est très contre performant, surtout
sur de grosses bases de données.
En effet, posez-vous la question de savoir, lorsque le fichier est
presque plein, si la demande de grossissement du fichier interviendra
lorsqu'il n'y a aucune activité ou lorsqu'il y a de nombreuses demandes
d'insertion....
Bien évidemment ce sera lorsque de nombreuses demande d'insertions
arrivent que le fichier aura besoin de grossir. Or les opérations de
croissance de fichiers sont des opéraion à la fois à haut risque mais
aussi très lente en regard des vitesses nécessaire à un traitement
optimal des données.
Il est donc fortement déconseillé d'utiliser ce mode pour des bases de
données importante dans lesquelles vous voulez des performnces.
Le time out est donc normal car faire croitre de 10% de 3 Go un fichier,
demande d'allouer 300 Mo ce qui n'est pas rien et prends beaucoup de
temps. Cela allonge donc d'autant de temps toutes les transactions en
cours (un INSERT, UPDATE, DELETE ou SELECT est une transaction).
C'est donc particulièrement exécrable...
La solution consiste à créer tout vos fichiers de taille fixe, avec une
dimension prévue pour quelques années d'exploitation.
Veillez aussi à ne jamais dépasser un taux de remplissage disque de
l'ordre de 70%.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
(...)
(...)
Comment peut on estimer la taille à allouer aux fichiers dans ce cas ?