J'aimerai savoir s'il existe une contre indication particulière à lancer
des ordres DBCC DBREINDEX en parallèle sur une même base de données. Le
contexte : SQL Server 2000 SP4, 8 CPU, 8Go RAM, base d'environ 60Go sur
disques en SAN 2Gb/s, 4000 tables.
Nous devons faire des réindexations régulières (sur préconisation de
l'éditeur du progiciel) mais la fenêtre de maintenance étant
relativement courte, je cherche à optimiser la procédure. Pendant cette
période, aucun autre accès n'est effectué sur la base.
J'ai pu tester la réindexation simultanée de deux index ordonnés en
cluster sur deux tables différentes, à priori pas de problèmes en vue,
mais je préfère avoir un avis sur la question si vous avez déjà été
confronté à ce cas de figure.
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
Med Bouchenafa
A partir du moment que c'est sur des tables differentes, je ne vois pas ce qui peut poser probléme
-- Bien Cordialement Med Bouchenafa
"Alexandre Auguet" a écrit :
Bonjour à tous.
J'aimerai savoir s'il existe une contre indication particulière à lancer des ordres DBCC DBREINDEX en parallèle sur une même base de données. Le contexte : SQL Server 2000 SP4, 8 CPU, 8Go RAM, base d'environ 60Go sur disques en SAN 2Gb/s, 4000 tables.
Nous devons faire des réindexations régulières (sur préconisation de l'éditeur du progiciel) mais la fenêtre de maintenance étant relativement courte, je cherche à optimiser la procédure. Pendant cette période, aucun autre accès n'est effectué sur la base.
J'ai pu tester la réindexation simultanée de deux index ordonnés en cluster sur deux tables différentes, à priori pas de problèmes en vue, mais je préfère avoir un avis sur la question si vous avez déjà été confronté à ce cas de figure.
Merci d'avance, Alexandre.
A partir du moment que c'est sur des tables differentes, je ne vois pas ce
qui peut poser probléme
--
Bien Cordialement
Med Bouchenafa
"Alexandre Auguet" a écrit :
Bonjour à tous.
J'aimerai savoir s'il existe une contre indication particulière à lancer
des ordres DBCC DBREINDEX en parallèle sur une même base de données. Le
contexte : SQL Server 2000 SP4, 8 CPU, 8Go RAM, base d'environ 60Go sur
disques en SAN 2Gb/s, 4000 tables.
Nous devons faire des réindexations régulières (sur préconisation de
l'éditeur du progiciel) mais la fenêtre de maintenance étant
relativement courte, je cherche à optimiser la procédure. Pendant cette
période, aucun autre accès n'est effectué sur la base.
J'ai pu tester la réindexation simultanée de deux index ordonnés en
cluster sur deux tables différentes, à priori pas de problèmes en vue,
mais je préfère avoir un avis sur la question si vous avez déjà été
confronté à ce cas de figure.
A partir du moment que c'est sur des tables differentes, je ne vois pas ce qui peut poser probléme
-- Bien Cordialement Med Bouchenafa
"Alexandre Auguet" a écrit :
Bonjour à tous.
J'aimerai savoir s'il existe une contre indication particulière à lancer des ordres DBCC DBREINDEX en parallèle sur une même base de données. Le contexte : SQL Server 2000 SP4, 8 CPU, 8Go RAM, base d'environ 60Go sur disques en SAN 2Gb/s, 4000 tables.
Nous devons faire des réindexations régulières (sur préconisation de l'éditeur du progiciel) mais la fenêtre de maintenance étant relativement courte, je cherche à optimiser la procédure. Pendant cette période, aucun autre accès n'est effectué sur la base.
J'ai pu tester la réindexation simultanée de deux index ordonnés en cluster sur deux tables différentes, à priori pas de problèmes en vue, mais je préfère avoir un avis sur la question si vous avez déjà été confronté à ce cas de figure.
Merci d'avance, Alexandre.
[FritesClub] TheKâMaster
On 22 mar, 10:27, Med Bouchenafa wrote:
A partir du moment que c'est sur des tables differentes, je ne vois pas ce qui peut poser probléme
Merci. C'est bien ce que je pense également, je ne vois qu'une éventuelle contention au niveau des accès disques. Mais des avis supplémentaires sont toujours les bienvenus, il peut toujours y avoir un piège quelque part.
On 22 mar, 10:27, Med Bouchenafa <com.hotmail@bouchenafa> wrote:
A partir du moment que c'est sur des tables differentes, je ne vois pas ce
qui peut poser probléme
Merci. C'est bien ce que je pense également, je ne vois qu'une
éventuelle contention au niveau des accès disques. Mais des avis
supplémentaires sont toujours les bienvenus, il peut toujours y avoir
un piège quelque part.
A partir du moment que c'est sur des tables differentes, je ne vois pas ce qui peut poser probléme
Merci. C'est bien ce que je pense également, je ne vois qu'une éventuelle contention au niveau des accès disques. Mais des avis supplémentaires sont toujours les bienvenus, il peut toujours y avoir un piège quelque part.
Fred BROUARD
Alexandre Auguet a écrit :
Bonjour à tous.
J'aimerai savoir s'il existe une contre indication particulière à lancer des ordres DBCC DBREINDEX en parallèle sur une même base de données. Le contexte : SQL Server 2000 SP4, 8 CPU, 8Go RAM, base d'environ 60Go sur disques en SAN 2Gb/s, 4000 tables.
Nous devons faire des réindexations régulières (sur préconisation de l'éditeur du progiciel) mais la fenêtre de maintenance étant relativement courte, je cherche à optimiser la procédure. Pendant cette période, aucun autre accès n'est effectué sur la base.
J'ai pu tester la réindexation simultanée de deux index ordonnés en cluster sur deux tables différentes, à priori pas de problèmes en vue, mais je préfère avoir un avis sur la question si vous avez déjà été confronté à ce cas de figure.
Merci d'avance, Alexandre.
come le dit med c'est ok si table différente car pose de verrous. REINDEX est une méthode agressive alors que DEFRAG ne l'est pas.
En revanche il serait peut être plus judicieux de ne pas tout réindexr à l'aveugle mais : 1) ne reindexer que les index réellement fragmentés 2) ne reindexer que les index de plus d'une extension 3) ne faire les stats que sur des échantillon sie les index dépassent certains volumes 4) compte tenu de votre fenêtre d'exec, optimiser le choix des index restructuré par tirage aléatoire.
Si cela vous intéresse j'ai écrit une telle proc pour des VLDB qui est en exploit chez de grands comptes du web.
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 ***********************
Alexandre Auguet a écrit :
Bonjour à tous.
J'aimerai savoir s'il existe une contre indication particulière à lancer
des ordres DBCC DBREINDEX en parallèle sur une même base de données. Le
contexte : SQL Server 2000 SP4, 8 CPU, 8Go RAM, base d'environ 60Go sur
disques en SAN 2Gb/s, 4000 tables.
Nous devons faire des réindexations régulières (sur préconisation de
l'éditeur du progiciel) mais la fenêtre de maintenance étant
relativement courte, je cherche à optimiser la procédure. Pendant cette
période, aucun autre accès n'est effectué sur la base.
J'ai pu tester la réindexation simultanée de deux index ordonnés en
cluster sur deux tables différentes, à priori pas de problèmes en vue,
mais je préfère avoir un avis sur la question si vous avez déjà été
confronté à ce cas de figure.
Merci d'avance,
Alexandre.
come le dit med c'est ok si table différente car pose de verrous.
REINDEX est une méthode agressive alors que DEFRAG ne l'est pas.
En revanche il serait peut être plus judicieux de ne pas tout réindexr à
l'aveugle mais :
1) ne reindexer que les index réellement fragmentés
2) ne reindexer que les index de plus d'une extension
3) ne faire les stats que sur des échantillon sie les index dépassent
certains volumes
4) compte tenu de votre fenêtre d'exec, optimiser le choix des index
restructuré par tirage aléatoire.
Si cela vous intéresse j'ai écrit une telle proc pour des VLDB qui est
en exploit chez de grands comptes du web.
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 ***********************
J'aimerai savoir s'il existe une contre indication particulière à lancer des ordres DBCC DBREINDEX en parallèle sur une même base de données. Le contexte : SQL Server 2000 SP4, 8 CPU, 8Go RAM, base d'environ 60Go sur disques en SAN 2Gb/s, 4000 tables.
Nous devons faire des réindexations régulières (sur préconisation de l'éditeur du progiciel) mais la fenêtre de maintenance étant relativement courte, je cherche à optimiser la procédure. Pendant cette période, aucun autre accès n'est effectué sur la base.
J'ai pu tester la réindexation simultanée de deux index ordonnés en cluster sur deux tables différentes, à priori pas de problèmes en vue, mais je préfère avoir un avis sur la question si vous avez déjà été confronté à ce cas de figure.
Merci d'avance, Alexandre.
come le dit med c'est ok si table différente car pose de verrous. REINDEX est une méthode agressive alors que DEFRAG ne l'est pas.
En revanche il serait peut être plus judicieux de ne pas tout réindexr à l'aveugle mais : 1) ne reindexer que les index réellement fragmentés 2) ne reindexer que les index de plus d'une extension 3) ne faire les stats que sur des échantillon sie les index dépassent certains volumes 4) compte tenu de votre fenêtre d'exec, optimiser le choix des index restructuré par tirage aléatoire.
Si cela vous intéresse j'ai écrit une telle proc pour des VLDB qui est en exploit chez de grands comptes du web.
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 ***********************
Alexandre Auguet
, Le 24/03/2007 09:42 :
come le dit med c'est ok si table différente car pose de verrous. REINDEX est une méthode agressive alors que DEFRAG ne l'est pas.
En revanche il serait peut être plus judicieux de ne pas tout réindexr à l'aveugle mais : 1) ne reindexer que les index réellement fragmentés 2) ne reindexer que les index de plus d'une extension 3) ne faire les stats que sur des échantillon sie les index dépassent certains volumes 4) compte tenu de votre fenêtre d'exec, optimiser le choix des index restructuré par tirage aléatoire.
Si cela vous intéresse j'ai écrit une telle proc pour des VLDB qui est en exploit chez de grands comptes du web.
Bonjour et merci pour cette réponse.
Actuellement le script de réindexation été développé en VBScript et fait déjà un premier tri dans les index en récupérant les informations renvoyées par DBCC SHOWCONTIG sur chaque index (pas complètement en fait, suite à une limitation du VBScript sur certaines méthodes SQLDMO).
Les différents points que vous citez sont ou seront pris en compte dans le prochain développement (exécutable en .NET cette fois-ci, pour différentes raisons dont le multi-threading pour une réindexation simultanée de plusieurs index), le but étant de réindexer au mieux et au plus vite les bases.
La défragmentation est aussi possible, cela est déjà fait pour des bases où nous ne disposons pas de fenêtre de maintenance sans accès utilisateur, mais ce n'est pas le souhait pour le moment de notre maitrise d'oeuvre pour le cas spécifié ici.
Par contre, je serai intéressé par votre méthode de sélection des index utilisée par votre procédure, cela pourra certainement m'être utile.
Cordialement, Alexandre.
, Le 24/03/2007 09:42 :
come le dit med c'est ok si table différente car pose de verrous.
REINDEX est une méthode agressive alors que DEFRAG ne l'est pas.
En revanche il serait peut être plus judicieux de ne pas tout réindexr à
l'aveugle mais :
1) ne reindexer que les index réellement fragmentés
2) ne reindexer que les index de plus d'une extension
3) ne faire les stats que sur des échantillon sie les index dépassent
certains volumes
4) compte tenu de votre fenêtre d'exec, optimiser le choix des index
restructuré par tirage aléatoire.
Si cela vous intéresse j'ai écrit une telle proc pour des VLDB qui est
en exploit chez de grands comptes du web.
Bonjour et merci pour cette réponse.
Actuellement le script de réindexation été développé en VBScript et fait
déjà un premier tri dans les index en récupérant les informations
renvoyées par DBCC SHOWCONTIG sur chaque index (pas complètement en
fait, suite à une limitation du VBScript sur certaines méthodes SQLDMO).
Les différents points que vous citez sont ou seront pris en compte dans
le prochain développement (exécutable en .NET cette fois-ci, pour
différentes raisons dont le multi-threading pour une réindexation
simultanée de plusieurs index), le but étant de réindexer au mieux et au
plus vite les bases.
La défragmentation est aussi possible, cela est déjà fait pour des bases
où nous ne disposons pas de fenêtre de maintenance sans accès
utilisateur, mais ce n'est pas le souhait pour le moment de notre
maitrise d'oeuvre pour le cas spécifié ici.
Par contre, je serai intéressé par votre méthode de sélection des index
utilisée par votre procédure, cela pourra certainement m'être utile.
come le dit med c'est ok si table différente car pose de verrous. REINDEX est une méthode agressive alors que DEFRAG ne l'est pas.
En revanche il serait peut être plus judicieux de ne pas tout réindexr à l'aveugle mais : 1) ne reindexer que les index réellement fragmentés 2) ne reindexer que les index de plus d'une extension 3) ne faire les stats que sur des échantillon sie les index dépassent certains volumes 4) compte tenu de votre fenêtre d'exec, optimiser le choix des index restructuré par tirage aléatoire.
Si cela vous intéresse j'ai écrit une telle proc pour des VLDB qui est en exploit chez de grands comptes du web.
Bonjour et merci pour cette réponse.
Actuellement le script de réindexation été développé en VBScript et fait déjà un premier tri dans les index en récupérant les informations renvoyées par DBCC SHOWCONTIG sur chaque index (pas complètement en fait, suite à une limitation du VBScript sur certaines méthodes SQLDMO).
Les différents points que vous citez sont ou seront pris en compte dans le prochain développement (exécutable en .NET cette fois-ci, pour différentes raisons dont le multi-threading pour une réindexation simultanée de plusieurs index), le but étant de réindexer au mieux et au plus vite les bases.
La défragmentation est aussi possible, cela est déjà fait pour des bases où nous ne disposons pas de fenêtre de maintenance sans accès utilisateur, mais ce n'est pas le souhait pour le moment de notre maitrise d'oeuvre pour le cas spécifié ici.
Par contre, je serai intéressé par votre méthode de sélection des index utilisée par votre procédure, cela pourra certainement m'être utile.
