Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur Tous les jours un DBCC UpdateUsage (0) With Count_Rows !!!

Tous les jours un DBCC UpdateUsage (0) With Count_Rows !!!

5 réponses
Avatar
Sebastien
Bonjour,

Il y a quelques jours, je disais que le nombre de lignes renvoyés par
sp_spaceused était parfois incorrect, idem dans Entreprise Manager ou dans
la table sysindexes.

Med Bouchenafa m'avait alors très bien conseillé en m'indiquant d'utiliser
DBCC UPDATEUSAGE .... WITH COUNT_ROWS.

Mais est-ce normal de devoir l'utiliser en permanence pour avoir des nombres
de lignes exacts dans sp_spaceused ou sysindexes, surtout que le problème a
lieu sur SQL2000SP3 (et WS2003) mais n'était pas présent sur SQL2000SP1 (et
W2000) ?
Est-ce un bug ou le serveur qui yoyote ?

Sebastien
Signaler un problème avec ce contenu

5 réponses

Supprimer
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
Avatar
Fred BROUARD
C'est tout à fait normal !!!!

Les processus d'administration interne sont des processus à déclenchement lents.

En effet, pour assurer le maximum de vitesse de traitement à l'information, donc
aux SELECT INSERT UPDATE et DELETE... SQL Server comme tout bon SGBDR C/S
(Oracle, IBM DB2, etc...) relègue en tâche de fond tout travail administratif.
Par exemple savoir dans les stats que l'indice de dispersion d'une colonne est
exactement 0,89498752 à l'instant T et non 0,89567 a l'instant T-n n'a aucune
incidence sur les perf de la base...

En conclusion tu utilise un processus administratif et tu voudrait qu'il agisse
aussi promptement qu'un SELECT !

Si SQL Server passait son temps à chaque modif de recalculer ses stats et ses
tailles de fichiers, alors il n'aurait plus le temps de traiter le moindre
UPDATE ou DELETE !

Il n'y a donc pas le moindre bug là dedans, et cela ne sera jamais corrigé par
un patch.
En revanche il serait peu être intéressant de "patcher" ton cerveau ;-) avec une
petite formation... par exemple d'admin SQL Server !

A +


--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Sebastien a écrit:
Bonjour,

Il y a quelques jours, je disais que le nombre de lignes renvoyés par
sp_spaceused était parfois incorrect, idem dans Entreprise Manager ou dans
la table sysindexes.

Med Bouchenafa m'avait alors très bien conseillé en m'indiquant d'utiliser
DBCC UPDATEUSAGE .... WITH COUNT_ROWS.

Mais est-ce normal de devoir l'utiliser en permanence pour avoir des nombres
de lignes exacts dans sp_spaceused ou sysindexes, surtout que le problème a
lieu sur SQL2000SP3 (et WS2003) mais n'était pas présent sur SQL2000SP1 (et
W2000) ?
Est-ce un bug ou le serveur qui yoyote ?

Sebastien







--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Avatar
Sebastien
Donc d'après ton explication détaillée, mon problème est normal.
Ce ne serait donc pas un problème puisque sans solution... à part me
"patcher" le cerveau à coup de formation. Dommage pour moi, j'en ai déjà eu
il y a quelques années pour SQL7. Ca ne devait pas être la bonne ou alors je
n'ai pas bien écouté.
Par contre, je ne vois aucun début de réponse à l'une de mes interrogations
qui était : pourquoi j'ai ce problème "normal" sur un serveur SQL2000SP3
mais pas sur un autre uniquement SP1.

Mais bon, je vais réviser mes cours et je verrai bien si un truc évident m'a
échappé ou si je trouve quelques pistes.

Sur ce, A+
Sébastien


Fred BROUARD a écrit :

C'est tout à fait normal !!!!

Les processus d'administration interne sont des processus à
déclenchement lents.

En effet, pour assurer le maximum de vitesse de traitement à
l'information, donc aux SELECT INSERT UPDATE et DELETE... SQL Server
comme tout bon SGBDR C/S (Oracle, IBM DB2, etc...) relègue en tâche
de fond tout travail administratif. Par exemple savoir dans les stats
que l'indice de dispersion d'une colonne est exactement 0,89498752 à
l'instant T et non 0,89567 a l'instant T-n n'a aucune incidence sur
les perf de la base...

En conclusion tu utilise un processus administratif et tu voudrait
qu'il agisse aussi promptement qu'un SELECT !

Si SQL Server passait son temps à chaque modif de recalculer ses
stats et ses tailles de fichiers, alors il n'aurait plus le temps de
traiter le moindre UPDATE ou DELETE !

Il n'y a donc pas le moindre bug là dedans, et cela ne sera jamais
corrigé par un patch.
En revanche il serait peu être intéressant de "patcher" ton cerveau
;-) avec une petite formation... par exemple d'admin SQL Server !

A +


--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Sebastien a écrit:
Bonjour,

Il y a quelques jours, je disais que le nombre de lignes renvoyés par
sp_spaceused était parfois incorrect, idem dans Entreprise Manager
ou dans la table sysindexes.

Med Bouchenafa m'avait alors très bien conseillé en m'indiquant
d'utiliser DBCC UPDATEUSAGE .... WITH COUNT_ROWS.

Mais est-ce normal de devoir l'utiliser en permanence pour avoir des
nombres de lignes exacts dans sp_spaceused ou sysindexes, surtout
que le problème a lieu sur SQL2000SP3 (et WS2003) mais n'était pas
présent sur SQL2000SP1 (et W2000) ?
Est-ce un bug ou le serveur qui yoyote ?

Sebastien




Avatar
Fred BROUARD
bonjour

Sebastien a écrit:
Donc d'après ton explication détaillée, mon problème est normal.
Ce ne serait donc pas un problème puisque sans solution... à part me
"patcher" le cerveau à coup de formation. Dommage pour moi, j'en ai déjà eu
il y a quelques années pour SQL7. Ca ne devait pas être la bonne ou alors je
n'ai pas bien écouté.



Certains formateurs ne font *que* de la formation. Ils n'ont jamais été dba ou
développeurs de solutions à forte charge en exploitation. D'ou un manque
d'expérience qui les font _réciter_ un cours sans y apporter de valeur ajoutée.

Par contre, je ne vois aucun début de réponse à l'une de mes interrogations
qui était : pourquoi j'ai ce problème "normal" sur un serveur SQL2000SP3
mais pas sur un autre uniquement SP1.



1) quel OS ? et quel patch
2) quelle config machine ?
3) quel volume de données dans les bases ?
4) quel nombre d'utilisateurs simultanés ?
etc...

A +


Mais bon, je vais réviser mes cours et je verrai bien si un truc évident m'a
échappé ou si je trouve quelques pistes.

Sur ce, A+
Sébastien


Fred BROUARD a écrit :


C'est tout à fait normal !!!!

Les processus d'administration interne sont des processus à
déclenchement lents.

En effet, pour assurer le maximum de vitesse de traitement à
l'information, donc aux SELECT INSERT UPDATE et DELETE... SQL Server
comme tout bon SGBDR C/S (Oracle, IBM DB2, etc...) relègue en tâche
de fond tout travail administratif. Par exemple savoir dans les stats
que l'indice de dispersion d'une colonne est exactement 0,89498752 à
l'instant T et non 0,89567 a l'instant T-n n'a aucune incidence sur
les perf de la base...

En conclusion tu utilise un processus administratif et tu voudrait
qu'il agisse aussi promptement qu'un SELECT !

Si SQL Server passait son temps à chaque modif de recalculer ses
stats et ses tailles de fichiers, alors il n'aurait plus le temps de
traiter le moindre UPDATE ou DELETE !

Il n'y a donc pas le moindre bug là dedans, et cela ne sera jamais
corrigé par un patch.
En revanche il serait peu être intéressant de "patcher" ton cerveau
;-) avec une petite formation... par exemple d'admin SQL Server !

A +


--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Sebastien a écrit:

Bonjour,

Il y a quelques jours, je disais que le nombre de lignes renvoyés par
sp_spaceused était parfois incorrect, idem dans Entreprise Manager
ou dans la table sysindexes.

Med Bouchenafa m'avait alors très bien conseillé en m'indiquant
d'utiliser DBCC UPDATEUSAGE .... WITH COUNT_ROWS.

Mais est-ce normal de devoir l'utiliser en permanence pour avoir des
nombres de lignes exacts dans sp_spaceused ou sysindexes, surtout
que le problème a lieu sur SQL2000SP3 (et WS2003) mais n'était pas
présent sur SQL2000SP1 (et W2000) ?
Est-ce un bug ou le serveur qui yoyote ?

Sebastien









--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Avatar
Sebastien
Bonjour

"Fred BROUARD" a écrit dans le message de
news:
bonjour

Sebastien a écrit:
> Donc d'après ton explication détaillée, mon problème est normal.
> Ce ne serait donc pas un problème puisque sans solution... à part me
> "patcher" le cerveau à coup de formation. Dommage pour moi, j'en ai déjà


eu
> il y a quelques années pour SQL7. Ca ne devait pas être la bonne ou


alors je
> n'ai pas bien écouté.

Certains formateurs ne font *que* de la formation. Ils n'ont jamais été


dba ou
développeurs de solutions à forte charge en exploitation. D'ou un manque
d'expérience qui les font _réciter_ un cours sans y apporter de valeur


ajoutée.

> Par contre, je ne vois aucun début de réponse à l'une de mes


interrogations
> qui était : pourquoi j'ai ce problème "normal" sur un serveur


SQL2000SP3
> mais pas sur un autre uniquement SP1.

1) quel OS ? et quel patch


Serveur A (sans problème) : W2000 SP2 / SQL 2000 SP1 FR
Serveur B (avec problème) : WS2003 / SQL 2000 SP3a FR

2) quelle config machine ?


A: 4CPU Xeon 700Mhz 2Go RAM
B: 4CPU Xeon HT 2,7Ghz 3Go RAM

3) quel volume de données dans les bases ?


A et B : 80Go mais même problème sur base plus petite.

4) quel nombre d'utilisateurs simultanés ?


A: environ 130
B: environ 10 car en test pour l'instant donc pas vraiment surchargé.

Les paramètres de mise à jour automatique des stats sont activés sur les 2.

A+
Sébastien

etc...

A +

>
> Mais bon, je vais réviser mes cours et je verrai bien si un truc évident


m'a
> échappé ou si je trouve quelques pistes.
>
> Sur ce, A+
> Sébastien
>
>
> Fred BROUARD a écrit :
>
>
>>C'est tout à fait normal !!!!
>>
>>Les processus d'administration interne sont des processus à
>>déclenchement lents.
>>
>>En effet, pour assurer le maximum de vitesse de traitement à
>>l'information, donc aux SELECT INSERT UPDATE et DELETE... SQL Server
>>comme tout bon SGBDR C/S (Oracle, IBM DB2, etc...) relègue en tâche
>>de fond tout travail administratif. Par exemple savoir dans les stats
>>que l'indice de dispersion d'une colonne est exactement 0,89498752 à
>>l'instant T et non 0,89567 a l'instant T-n n'a aucune incidence sur
>>les perf de la base...
>>
>>En conclusion tu utilise un processus administratif et tu voudrait
>>qu'il agisse aussi promptement qu'un SELECT !
>>
>>Si SQL Server passait son temps à chaque modif de recalculer ses
>>stats et ses tailles de fichiers, alors il n'aurait plus le temps de
>>traiter le moindre UPDATE ou DELETE !
>>
>>Il n'y a donc pas le moindre bug là dedans, et cela ne sera jamais
>>corrigé par un patch.
>>En revanche il serait peu être intéressant de "patcher" ton cerveau
>>;-) avec une petite formation... par exemple d'admin SQL Server !
>>
>>A +
>>
>>
>>--
>>Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
>>Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
>>Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
>>************************ www.datasapiens.com *************************
>>
>>Sebastien a écrit:
>>
>>>Bonjour,
>>>
>>>Il y a quelques jours, je disais que le nombre de lignes renvoyés par
>>>sp_spaceused était parfois incorrect, idem dans Entreprise Manager
>>>ou dans la table sysindexes.
>>>
>>>Med Bouchenafa m'avait alors très bien conseillé en m'indiquant
>>>d'utiliser DBCC UPDATEUSAGE .... WITH COUNT_ROWS.
>>>
>>>Mais est-ce normal de devoir l'utiliser en permanence pour avoir des
>>>nombres de lignes exacts dans sp_spaceused ou sysindexes, surtout
>>>que le problème a lieu sur SQL2000SP3 (et WS2003) mais n'était pas
>>>présent sur SQL2000SP1 (et W2000) ?
>>>Est-ce un bug ou le serveur qui yoyote ?
>>>
>>>Sebastien


Avatar
lionelp
Bonjour,

Le gestionnaire de statisques essaie de trquer les
insertions/suppressions mais est soumis aux contraintes de
performance (déclenchement des checkpoint, tailles des
transactions, accès concurrents, ...). C'est pour cela que
l'on peut observer des différences d'autant que les
mécanismes pré cités évoluent au fil des services packs.
C'est aussi pour cela que l'on a des outils comme
UPDATEUSDAGE, que l'on a la possibilité désactiver la mise
à jour automatique des statistiques ainsi que la création
automatique de statisques. Ou que l'on peut à sp_spaceused
ma_table, @updateusage = 'true'.

Cordialement,
LionelP

-----Message d'origine-----
Bonjour

"Fred BROUARD" a écrit dans


le message de
news:
bonjour

Sebastien a écrit:
> Donc d'après ton explication détaillée, mon problème




est normal.
> Ce ne serait donc pas un problème puisque sans




solution... à part me
> "patcher" le cerveau à coup de formation. Dommage




pour moi, j'en ai déjà
eu
> il y a quelques années pour SQL7. Ca ne devait pas




être la bonne ou
alors je
> n'ai pas bien écouté.

Certains formateurs ne font *que* de la formation. Ils




n'ont jamais été
dba ou
développeurs de solutions à forte charge en




exploitation. D'ou un manque
d'expérience qui les font _réciter_ un cours sans y




apporter de valeur
ajoutée.

> Par contre, je ne vois aucun début de réponse à l'une




de mes
interrogations
> qui était : pourquoi j'ai ce problème "normal" sur




un serveur
SQL2000SP3
> mais pas sur un autre uniquement SP1.

1) quel OS ? et quel patch


Serveur A (sans problème) : W2000 SP2 / SQL 2000 SP1 FR
Serveur B (avec problème) : WS2003 / SQL 2000 SP3a FR

2) quelle config machine ?


A: 4CPU Xeon 700Mhz 2Go RAM
B: 4CPU Xeon HT 2,7Ghz 3Go RAM

3) quel volume de données dans les bases ?


A et B : 80Go mais même problème sur base plus petite.

4) quel nombre d'utilisateurs simultanés ?


A: environ 130
B: environ 10 car en test pour l'instant donc pas


vraiment surchargé.

Les paramètres de mise à jour automatique des stats sont


activés sur les 2.

A+
Sébastien

etc...

A +

>
> Mais bon, je vais réviser mes cours et je verrai bien




si un truc évident
m'a
> échappé ou si je trouve quelques pistes.
>
> Sur ce, A+
> Sébastien
>
>
> Fred BROUARD a écrit :
>
>
>>C'est tout à fait normal !!!!
>>
>>Les processus d'administration interne sont des




processus à
>>déclenchement lents.
>>
>>En effet, pour assurer le maximum de vitesse de




traitement à
>>l'information, donc aux SELECT INSERT UPDATE et




DELETE... SQL Server
>>comme tout bon SGBDR C/S (Oracle, IBM DB2, etc...)




relègue en tâche
>>de fond tout travail administratif. Par exemple




savoir dans les stats
>>que l'indice de dispersion d'une colonne est




exactement 0,89498752 à
>>l'instant T et non 0,89567 a l'instant T-n n'a aucune




incidence sur
>>les perf de la base...
>>
>>En conclusion tu utilise un processus administratif




et tu voudrait
>>qu'il agisse aussi promptement qu'un SELECT !
>>
>>Si SQL Server passait son temps à chaque modif de




recalculer ses
>>stats et ses tailles de fichiers, alors il n'aurait




plus le temps de
>>traiter le moindre UPDATE ou DELETE !
>>
>>Il n'y a donc pas le moindre bug là dedans, et cela




ne sera jamais
>>corrigé par un patch.
>>En revanche il serait peu être intéressant




de "patcher" ton cerveau
>>;-) avec une petite formation... par exemple d'admin




SQL Server !
>>
>>A +
>>
>>
>>--
>>Frédéric BROUARD, MVP SQL Server. Expert SQL /




spécialiste Delphi, web
>>Livre SQL - col. Référence :




http://sqlpro.developpez.com/bookSQL.html
>>Le site du SQL, pour débutants et pros :




http://sqlpro.developpez.com
>>************************ www.datasapiens.com




*************************
>>
>>Sebastien a écrit:
>>
>>>Bonjour,
>>>
>>>Il y a quelques jours, je disais que le nombre de




lignes renvoyés par
>>>sp_spaceused était parfois incorrect, idem dans




Entreprise Manager
>>>ou dans la table sysindexes.
>>>
>>>Med Bouchenafa m'avait alors très bien conseillé en




m'indiquant
>>>d'utiliser DBCC UPDATEUSAGE .... WITH COUNT_ROWS.
>>>
>>>Mais est-ce normal de devoir l'utiliser en




permanence pour avoir des
>>>nombres de lignes exacts dans sp_spaceused ou




sysindexes, surtout
>>>que le problème a lieu sur SQL2000SP3 (et WS2003)




mais n'était pas
>>>présent sur SQL2000SP1 (et W2000) ?
>>>Est-ce un bug ou le serveur qui yoyote ?
>>>
>>>Sebastien




.