Voil=E0 mon probl=E8me, ma base de donn=E9es commence =E0 avoir quelques
lenteurs. J'ai donc lanc=E9 un dbbc showcontig pour voir l'=E9tat de mes
index.
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
Dimitri a écrit:
Le Logical Scan me parait bon, mais qu'est ce qu'il en est du Scan Density ? ....
Une autre question, dbcc indexdefrag et dbcc dbreindex dégragmentent les indexes, mais existe t'il quelque chose pour les tables ? ....
Bonjour,
Le scan density montre que tu as une certaine fragmentation, pas dramatique mais tu peux en effet gagner en défragmentant la table, c'est à-dire en défragmentant l'index ordonné.
Défragmenter la table = défragmenter l'index ordonné. Tu devrais avoir un index ordonné sur chaque table, et vouloir défrgamenter une table sans index ordonné n'a pas beaucoup de sens : dans quel ordre faudrait-il mettre les pages ?
-- Rudi Bruchez Consultant indépendant modélisation, administration, optimisation, solutions MS SQL Server et informatique libre. MCDBA, SCJP2 http://www.babaluga.com/
Dimitri a écrit:
Le Logical Scan me parait bon, mais qu'est ce qu'il en est du Scan
Density ? ....
Une autre question, dbcc indexdefrag et dbcc dbreindex dégragmentent
les indexes, mais existe t'il quelque chose pour les tables ? ....
Bonjour,
Le scan density montre que tu as une certaine fragmentation, pas dramatique
mais tu peux en effet gagner en défragmentant la table, c'est à-dire en
défragmentant l'index ordonné.
Défragmenter la table = défragmenter l'index ordonné. Tu devrais avoir un
index ordonné sur chaque table, et vouloir défrgamenter une table sans
index ordonné n'a pas beaucoup de sens : dans quel ordre faudrait-il mettre
les pages ?
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Le Logical Scan me parait bon, mais qu'est ce qu'il en est du Scan Density ? ....
Une autre question, dbcc indexdefrag et dbcc dbreindex dégragmentent les indexes, mais existe t'il quelque chose pour les tables ? ....
Bonjour,
Le scan density montre que tu as une certaine fragmentation, pas dramatique mais tu peux en effet gagner en défragmentant la table, c'est à-dire en défragmentant l'index ordonné.
Défragmenter la table = défragmenter l'index ordonné. Tu devrais avoir un index ordonné sur chaque table, et vouloir défrgamenter une table sans index ordonné n'a pas beaucoup de sens : dans quel ordre faudrait-il mettre les pages ?
-- Rudi Bruchez Consultant indépendant modélisation, administration, optimisation, solutions MS SQL Server et informatique libre. MCDBA, SCJP2 http://www.babaluga.com/
Dimitri
Question bête , mais à quoi correspond le scan density ?
rudi bruchez a écrit :
Dimitri a écrit:
Le Logical Scan me parait bon, mais qu'est ce qu'il en est du Scan Density ? ....
Une autre question, dbcc indexdefrag et dbcc dbreindex dégragmentent les indexes, mais existe t'il quelque chose pour les tables ? ....
Bonjour,
Le scan density montre que tu as une certaine fragmentation, pas dramatique mais tu peux en effet gagner en défragmentant la table, c'est à-dire en défragmentant l'index ordonné.
Défragmenter la table = défragmenter l'index ordonné. Tu devrais avoir un index ordonné sur chaque table, et vouloir défrgamenter une table sans index ordonné n'a pas beaucoup de sens : dans quel ordre faudrait-il mettre les pages ?
Question bête , mais à quoi correspond le scan density ?
rudi bruchez a écrit :
Dimitri a écrit:
Le Logical Scan me parait bon, mais qu'est ce qu'il en est du Scan
Density ? ....
Une autre question, dbcc indexdefrag et dbcc dbreindex dégragmentent
les indexes, mais existe t'il quelque chose pour les tables ? ....
Bonjour,
Le scan density montre que tu as une certaine fragmentation, pas dramatique
mais tu peux en effet gagner en défragmentant la table, c'est à-dire en
défragmentant l'index ordonné.
Défragmenter la table = défragmenter l'index ordonné. Tu devrais avoir un
index ordonné sur chaque table, et vouloir défrgamenter une table sans
index ordonné n'a pas beaucoup de sens : dans quel ordre faudrait-il mettre
les pages ?
Question bête , mais à quoi correspond le scan density ?
rudi bruchez a écrit :
Dimitri a écrit:
Le Logical Scan me parait bon, mais qu'est ce qu'il en est du Scan Density ? ....
Une autre question, dbcc indexdefrag et dbcc dbreindex dégragmentent les indexes, mais existe t'il quelque chose pour les tables ? ....
Bonjour,
Le scan density montre que tu as une certaine fragmentation, pas dramatique mais tu peux en effet gagner en défragmentant la table, c'est à-dire en défragmentant l'index ordonné.
Défragmenter la table = défragmenter l'index ordonné. Tu devrais avoir un index ordonné sur chaque table, et vouloir défrgamenter une table sans index ordonné n'a pas beaucoup de sens : dans quel ordre faudrait-il mettre les pages ?
Fred BROUARD
Dimitri a écrit :
Bonjour,
Voilà mon problème, ma base de données commence à avoir quelques lenteurs. J'ai donc lancé un dbbc showcontig pour voir l'état de mes index.
ce paramètre est incorrect/ Vous devriez avoir dans une situation optimale 39151 commutations d'extension. Autrement dit lorsque vous faites une lecture vous lisez deux fois plus de données qu'il n'en faut pour traiter votre requête
- Avg. Pages per Extent........................: 8.0 - Scan Density [Best Count:Actual Count].......: 54.08% [39036:72179]
Mauvaise densité vous pouvez gagner 90 000 pages, soit près d'un tiers de pages en trop.
Le Logical Scan me parait bon, mais qu'est ce qu'il en est du Scan Density ? ....
Une autre question, dbcc indexdefrag et dbcc dbreindex dégragmentent les indexes, mais existe t'il quelque chose pour les tables ? ....
Vous pouvez aussi utiliser CREATE INDEX ... avec l'option DROP EXISTING et enfin DROP INDEX ... + CREATE INDEX.
merci cdlt Dimitri
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 ***********************
Dimitri a écrit :
Bonjour,
Voilà mon problème, ma base de données commence à avoir quelques
lenteurs. J'ai donc lancé un dbbc showcontig pour voir l'état de mes
index.
ce paramètre est incorrect/ Vous devriez avoir dans une situation
optimale 39151 commutations d'extension.
Autrement dit lorsque vous faites une lecture vous lisez deux fois plus
de données qu'il n'en faut pour traiter votre requête
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 54.08% [39036:72179]
Mauvaise densité vous pouvez gagner 90 000 pages, soit près d'un tiers
de pages en trop.
Le Logical Scan me parait bon, mais qu'est ce qu'il en est du Scan
Density ? ....
Une autre question, dbcc indexdefrag et dbcc dbreindex dégragmentent
les indexes, mais existe t'il quelque chose pour les tables ? ....
Vous pouvez aussi utiliser CREATE INDEX ... avec l'option DROP EXISTING
et enfin
DROP INDEX ... + CREATE INDEX.
merci
cdlt
Dimitri
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 ***********************
ce paramètre est incorrect/ Vous devriez avoir dans une situation optimale 39151 commutations d'extension. Autrement dit lorsque vous faites une lecture vous lisez deux fois plus de données qu'il n'en faut pour traiter votre requête
- Avg. Pages per Extent........................: 8.0 - Scan Density [Best Count:Actual Count].......: 54.08% [39036:72179]
Mauvaise densité vous pouvez gagner 90 000 pages, soit près d'un tiers de pages en trop.
Le Logical Scan me parait bon, mais qu'est ce qu'il en est du Scan Density ? ....
Une autre question, dbcc indexdefrag et dbcc dbreindex dégragmentent les indexes, mais existe t'il quelque chose pour les tables ? ....
Vous pouvez aussi utiliser CREATE INDEX ... avec l'option DROP EXISTING et enfin DROP INDEX ... + CREATE INDEX.
merci cdlt Dimitri
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 ***********************
Rudi Bruchez
Dimitri a écrit:
Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents (passage d'un extent à l'autre). Autrement dit : le contenu de ta table est dans 39152 extents. Pour lire toute la table, SQL Server doit changer 72178 fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stockage compact, il devrait faire seulement 39151 switches.
-- Rudi Bruchez Consultant indépendant modélisation, administration, optimisation, Solutions MS SQL Server et informatique libre. MCDBA, SCJP2 http://www.babaluga.com/
Dimitri a écrit:
Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents
(passage d'un extent à l'autre). Autrement dit : le contenu de ta table est
dans 39152 extents. Pour lire toute la table, SQL Server doit changer 72178
fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stockage
compact, il devrait faire seulement 39151 switches.
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents (passage d'un extent à l'autre). Autrement dit : le contenu de ta table est dans 39152 extents. Pour lire toute la table, SQL Server doit changer 72178 fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stockage compact, il devrait faire seulement 39151 switches.
-- Rudi Bruchez Consultant indépendant modélisation, administration, optimisation, Solutions MS SQL Server et informatique libre. MCDBA, SCJP2 http://www.babaluga.com/
Dimitri
Rudi Bruchez a écrit :
Dimitri a écrit:
> Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents (passage d'un extent à l'autre). Autrement dit : le contenu de ta table est dans 39152 extents. Pour lire toute la table, SQL Server doit changer 721 78 fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stoc kage compact, il devrait faire seulement 39151 switches.
-- Rudi Bruchez
Ok Merci de ces éclaircissements, mais est ce que DBCC REDINDEX ou DBCC NIDEXDEFRAG permettent de réduire les switchs ? sachants que ces extents sont dans la table, et non dans l'index ?
Dimitri
Rudi Bruchez a écrit :
Dimitri a écrit:
> Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents
(passage d'un extent à l'autre). Autrement dit : le contenu de ta table est
dans 39152 extents. Pour lire toute la table, SQL Server doit changer 721 78
fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stoc kage
compact, il devrait faire seulement 39151 switches.
--
Rudi Bruchez
Ok Merci de ces éclaircissements, mais est ce que DBCC REDINDEX ou
DBCC NIDEXDEFRAG permettent de réduire les switchs ? sachants que ces
extents sont dans la table, et non dans l'index ?
> Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents (passage d'un extent à l'autre). Autrement dit : le contenu de ta table est dans 39152 extents. Pour lire toute la table, SQL Server doit changer 721 78 fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stoc kage compact, il devrait faire seulement 39151 switches.
-- Rudi Bruchez
Ok Merci de ces éclaircissements, mais est ce que DBCC REDINDEX ou DBCC NIDEXDEFRAG permettent de réduire les switchs ? sachants que ces extents sont dans la table, et non dans l'index ?
Dimitri
Philippe T [MS]
Bonjour,
L'index cluster est la table elle même. Une reconstruction ou réindexation de cet index va permettre de régler les choses.
Phil. ________________________________________________________ Philippe TROTIN Microsoft Services France http://www.microsoft.com/france "Dimitri" wrote in message news:
Rudi Bruchez a écrit :
Dimitri a écrit:
> Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents (passage d'un extent à l'autre). Autrement dit : le contenu de ta table est dans 39152 extents. Pour lire toute la table, SQL Server doit changer 72178 fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stockage compact, il devrait faire seulement 39151 switches.
-- Rudi Bruchez
Ok Merci de ces éclaircissements, mais est ce que DBCC REDINDEX ou DBCC NIDEXDEFRAG permettent de réduire les switchs ? sachants que ces extents sont dans la table, et non dans l'index ?
Dimitri
Bonjour,
L'index cluster est la table elle même. Une reconstruction ou réindexation
de cet index va permettre de régler les choses.
Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Dimitri" <dimitri.fryc@gmail.com> wrote in message
news:1157620822.667906.48770@m79g2000cwm.googlegroups.com...
Rudi Bruchez a écrit :
Dimitri a écrit:
> Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents
(passage d'un extent à l'autre). Autrement dit : le contenu de ta table
est
dans 39152 extents. Pour lire toute la table, SQL Server doit changer
72178
fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un
stockage
compact, il devrait faire seulement 39151 switches.
--
Rudi Bruchez
Ok Merci de ces éclaircissements, mais est ce que DBCC REDINDEX ou
DBCC NIDEXDEFRAG permettent de réduire les switchs ? sachants que ces
extents sont dans la table, et non dans l'index ?
L'index cluster est la table elle même. Une reconstruction ou réindexation de cet index va permettre de régler les choses.
Phil. ________________________________________________________ Philippe TROTIN Microsoft Services France http://www.microsoft.com/france "Dimitri" wrote in message news:
Rudi Bruchez a écrit :
Dimitri a écrit:
> Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents (passage d'un extent à l'autre). Autrement dit : le contenu de ta table est dans 39152 extents. Pour lire toute la table, SQL Server doit changer 72178 fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stockage compact, il devrait faire seulement 39151 switches.
-- Rudi Bruchez
Ok Merci de ces éclaircissements, mais est ce que DBCC REDINDEX ou DBCC NIDEXDEFRAG permettent de réduire les switchs ? sachants que ces extents sont dans la table, et non dans l'index ?
Dimitri
Fred BROUARD
Dimitri a écrit :
Rudi Bruchez a écrit :
Dimitri a écrit:
Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents (passage d'un extent à l'autre). Autrement dit : le contenu de ta table est dans 39152 extents. Pour lire toute la table, SQL Server doit changer 72178 fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stockage compact, il devrait faire seulement 39151 switches.
-- Rudi Bruchez
Ok Merci de ces éclaircissements, mais est ce que DBCC REDINDEX ou DBCC NIDEXDEFRAG permettent de réduire les switchs ? sachants que ces extents sont dans la table, et non dans l'index ?
DBCC REDINDEX en principe à 100% DBCC NIDEXDEFRAG entre 90 et 60%
A +
Dimitri
-- 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 ***********************
Dimitri a écrit :
Rudi Bruchez a écrit :
Dimitri a écrit:
Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents
(passage d'un extent à l'autre). Autrement dit : le contenu de ta table est
dans 39152 extents. Pour lire toute la table, SQL Server doit changer 72178
fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stockage
compact, il devrait faire seulement 39151 switches.
--
Rudi Bruchez
Ok Merci de ces éclaircissements, mais est ce que DBCC REDINDEX ou
DBCC NIDEXDEFRAG permettent de réduire les switchs ? sachants que ces
extents sont dans la table, et non dans l'index ?
DBCC REDINDEX en principe à 100%
DBCC NIDEXDEFRAG entre 90 et 60%
A +
Dimitri
--
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 ***********************
Question bête , mais à quoi correspond le scan density ?
Le rapport entre le nombre d'extents et le nombre de switches d'extents (passage d'un extent à l'autre). Autrement dit : le contenu de ta table est dans 39152 extents. Pour lire toute la table, SQL Server doit changer 72178 fois d'extent, alors que comme dit Fred Brouard, dans l'idéal d'un stockage compact, il devrait faire seulement 39151 switches.
-- Rudi Bruchez
Ok Merci de ces éclaircissements, mais est ce que DBCC REDINDEX ou DBCC NIDEXDEFRAG permettent de réduire les switchs ? sachants que ces extents sont dans la table, et non dans l'index ?
DBCC REDINDEX en principe à 100% DBCC NIDEXDEFRAG entre 90 et 60%
A +
Dimitri
-- 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 ***********************
