[ASE] Duree de creation d'index trop longue [Résolu]

greg75 · 09/02/2007, 09h35

Bonjour,

Je dois dorenavant pouvoir utiliser le champ (existant) d'une table comme critere de recherche dans mon appli.

Apres avoir realise des tests dans un environnement de copie, la creation de l'index a pris 10h. C'est bcp trop car je ne peux pas couper la base autant de tps.

Est-ce qqn a une idee ?

D'avance merci.

dbafranck · 09/02/2007, 09h48

Bonjour,
Voici qqu idées :
- Si tu crées un index cluster, vérifie les temps que tu obtiens en créant plutôt un index non cluster.
- Tes deux environnements sont-ils bien les mêmes (mémoire, cpu, charge, ...). Sinon, il se peut que la création de ton index ne dure pas 10h sur l'autre environnement.

dbafranck · 09/02/2007, 13h48

Sinon, voici une petite méthode (il existe peut être plus simple) qui pourrait réduire pas mal le temps d'arrêt de la base. Je n'ai pas testé la méthode qui demande quand même un certain travail.

- Création d'une table tab ayant la même structure que la table à indexer (ne pas créer d'index pour le moment, donc pas de contraintes d'unicité ou de clé primaire non plus)

- Création de triggers sur la table à indexer permettant d'alimenter une table de travail afin de récupérer les lignes de la table à indexer mises à jour (insert/update/delete) à partir de maintenant (créer une seule table avec un champ permettant de faire la différence entre les trois opérations ; ou alors créer trois tables de travail...).

- Insertion des lignes dans tab par insert/select.

- Création de tous les index (ne pas oublier les contraintes d'unicité et primaire si c'est le cas) dans tab, y compris le nouvel index.

- Stopper l'activité sur la base (mettre la base en single user par exemple)

- Dropper la table à indexer ( copier avant les lignes dans une table temporaire au cas ou mais cela va rallonger le temps d'arrêt).

- Renommer la table tab avec le nom de la table qui vient d'être droppée (sp_rename)

- Puis appliquer les lignes de la table de travail à la table renommée de telle sorte à obtenir un résultat cohérent (attention au doublon qui auraient pu apparaitre dans la table tab causés par la durée de l'insertion des lignes dans tab par insert/select).

- Redémarrer l'activité sur la base

Attention à bien tester cette méthode pour vérifier qu'il n'y a pas d'impactes non souhaités sur les données.
Attention en particulier s'il y avait déjà des triggers sur la table à index et d'éventuelles contraintes d'intégrité référentielles entre cette table et d'autres objets.
Bien faire une sauvegarde de la base avant.

greg75 · 12/02/2007, 09h58

Merci pour toutes ces réponses. Je me suis orienté vers la seconde solution et puis finalement changement de programme ce matin, je vais pouvoir arrêter la base

fadace · 13/02/2007, 08h14

Et le partitionnement ?
Et la parallélisation ?

greg75 · 14/02/2007, 09h23

Là ca dépasse mon domaine de compétences...je ne suis pas DBA...ce n'est que temporaire

09/02/2007, 09h35	#1
greg75 Invité régulier Inscription : février 2007 Messages : 13 Détails du profil Informations forums : Inscription : février 2007 Messages : 13 Points : 7 Points : 7	[ASE] Duree de creation d'index trop longue Bonjour, Je dois dorenavant pouvoir utiliser le champ (existant) d'une table comme critere de recherche dans mon appli. Apres avoir realise des tests dans un environnement de copie, la creation de l'index a pris 10h. C'est bcp trop car je ne peux pas couper la base autant de tps. Est-ce qqn a une idee ? D'avance merci.
	00

13/02/2007, 08h14	#5
fadace Rédacteur/Modérateur Fabien Celaia Administrateur de base de données Inscription : octobre 2002 Messages : 3 779 Détails du profil Informations personnelles : Nom : Fabien Celaia Âge : 41 Localisation : Suisse Informations professionnelles : Activité : Administrateur de base de données Secteur : Service public Informations forums : Inscription : octobre 2002 Messages : 3 779 Points : 8 124 Points : 8 124	Et le partitionnement ? Et la parallélisation ? __________________ Sr DBA Oracle / Sybase / MS-SQL / DB2 / Informix / Postgresql Administrateur SAP Mes articles Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums !
	00

09/02/2007, 09h48	#2
dbafranck Membre du Club Inscription : décembre 2005 Messages : 48 Détails du profil Informations forums : Inscription : décembre 2005 Messages : 48 Points : 48 Points : 48	Bonjour, Voici qqu idées : - Si tu crées un index cluster, vérifie les temps que tu obtiens en créant plutôt un index non cluster. - Tes deux environnements sont-ils bien les mêmes (mémoire, cpu, charge, ...). Sinon, il se peut que la création de ton index ne dure pas 10h sur l'autre environnement.
	00

09/02/2007, 13h48	#3
dbafranck Membre du Club Inscription : décembre 2005 Messages : 48 Détails du profil Informations forums : Inscription : décembre 2005 Messages : 48 Points : 48 Points : 48	Sinon, voici une petite méthode (il existe peut être plus simple) qui pourrait réduire pas mal le temps d'arrêt de la base. Je n'ai pas testé la méthode qui demande quand même un certain travail. - Création d'une table tab ayant la même structure que la table à indexer (ne pas créer d'index pour le moment, donc pas de contraintes d'unicité ou de clé primaire non plus) - Création de triggers sur la table à indexer permettant d'alimenter une table de travail afin de récupérer les lignes de la table à indexer mises à jour (insert/update/delete) à partir de maintenant (créer une seule table avec un champ permettant de faire la différence entre les trois opérations ; ou alors créer trois tables de travail...). - Insertion des lignes dans tab par insert/select. - Création de tous les index (ne pas oublier les contraintes d'unicité et primaire si c'est le cas) dans tab, y compris le nouvel index. - Stopper l'activité sur la base (mettre la base en single user par exemple) - Dropper la table à indexer ( copier avant les lignes dans une table temporaire au cas ou mais cela va rallonger le temps d'arrêt). - Renommer la table tab avec le nom de la table qui vient d'être droppée (sp_rename) - Puis appliquer les lignes de la table de travail à la table renommée de telle sorte à obtenir un résultat cohérent (attention au doublon qui auraient pu apparaitre dans la table tab causés par la durée de l'insertion des lignes dans tab par insert/select). - Redémarrer l'activité sur la base Attention à bien tester cette méthode pour vérifier qu'il n'y a pas d'impactes non souhaités sur les données. Attention en particulier s'il y avait déjà des triggers sur la table à index et d'éventuelles contraintes d'intégrité référentielles entre cette table et d'autres objets. Bien faire une sauvegarde de la base avant.
	00

12/02/2007, 09h58	#4
greg75 Invité régulier Inscription : février 2007 Messages : 13 Détails du profil Informations forums : Inscription : février 2007 Messages : 13 Points : 7 Points : 7	Merci pour toutes ces réponses. Je me suis orienté vers la seconde solution et puis finalement changement de programme ce matin, je vais pouvoir arrêter la base
	00

14/02/2007, 09h23	#6
greg75 Invité régulier Inscription : février 2007 Messages : 13 Détails du profil Informations forums : Inscription : février 2007 Messages : 13 Points : 7 Points : 7	Là ca dépasse mon domaine de compétences...je ne suis pas DBA...ce n'est que temporaire
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email