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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Rudi Bruchez
Forum Microsoft a écrit:
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.
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 ?
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.
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 ?
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.
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 ?
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.
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 +
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
-- 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 ***********************
Forum Microsoft a écrit :
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.
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 +
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
--
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 ***********************
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.
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 +
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
-- 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 ***********************
Pierre Goiffon
Fred BROUARD wrote:
" Nous rencontrons des problèmes sur la base de données des droits Global_DP.
(...)
En fait, le fichier GlobalDP_Log est à croissance limitée à 5000Mo avec une croissance de 10% et atteint actuellement 3000Mo.
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.
(...)
La solution consiste à créer tout vos fichiers de taille fixe, avec une dimension prévue pour quelques années d'exploitation.
Comment peut on estimer la taille à allouer aux fichiers dans ce cas ?
Fred BROUARD wrote:
" Nous rencontrons des problèmes sur la base de données des droits
Global_DP.
(...)
En fait, le fichier GlobalDP_Log est à croissance limitée à 5000Mo
avec une croissance de 10% et atteint actuellement 3000Mo.
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.
(...)
La solution consiste à créer tout vos fichiers de taille fixe, avec une
dimension prévue pour quelques années d'exploitation.
Comment peut on estimer la taille à allouer aux fichiers dans ce cas ?
" Nous rencontrons des problèmes sur la base de données des droits Global_DP.
(...)
En fait, le fichier GlobalDP_Log est à croissance limitée à 5000Mo avec une croissance de 10% et atteint actuellement 3000Mo.
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.
(...)
La solution consiste à créer tout vos fichiers de taille fixe, avec une dimension prévue pour quelques années d'exploitation.
Comment peut on estimer la taille à allouer aux fichiers dans ce cas ?
