Discussion :

[greg75]

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]

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]

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]

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

[Fabien Celaia]

Et le partitionnement ?
Et la parallélisation ?

[greg75]

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