Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
J'ai des milliers de requêtes COPY qui sont en cours d'exécution (en ce moment je suis toujours sur la même table). Elles sont lancées à travers Business Objects Data Integrator (mes requêtes COPY sont générées via un Script).
Problème : plus le temps passe et plus le temps d'exécution de chaque requête est long.
N'y aurait-il pas un paramétrage quelconque à modifier ? Paramétrage qui peut être modifié à chaud cela va de soit ! 
Je ne peux bien évidemment pas arrêter mon traitement BODI pour le relancer, car il doit être fini d'ici demain soir.
Gôm
PS : J'entends parfois parler des statistiques sur les tables dont on peut "forcer" le rafraîchissement manuellement, mais je ne sais pas du tout si c'est la solution dans mon cas et je sais encore moins si cette manipulation est réalisable dans mon cas.
Dernière modification par gom (20/12/2009 00:37:00)
Hors ligne
Pour COPY, les statistiques n'ont aucune importance. Si les performances de COPY se dégradent, c'est rarement à cause de la table elle même. Il peut s'agir des index par exemple (rajouter des données peut entraîner des fragmentations d'index au bout d'un moment si les ajouts se font 'au milieu' de l'index). COPY peut aussi déclencher des triggers, s'il y en a.
Dernière possibilité que je vois comme ça à froid, des COPY qui avortent et laissent plein d'espace non utilisé dans la table… c'est le genre de cas où autovacuum ne va pas se déclencher, et celà pourrait entraîner des ralentissements.
Marc.
Hors ligne
Bonjour,
Je pencherais donc pour ta 1ère proposition : la fragmentation des index.
Un palliatif possible pour accélérer l'exécution de la fin de mes requêtes ?
Gôm
Hors ligne
Les dropper et les recréer après le chargement.
Idéalement, les tables sur lesquelles tu fais ton COPY ne devraient pas avoir d'index du tout. Par contre le DROP INDEX prend un verrou sur la table. Il va donc bloquer tous les nouveaux COPY tant qu'il n'aura pas pu s'exécuter, et devoir attendre la fin de tous les COPY en cours.
Dernière modification par Marc Cousin (20/12/2009 10:35:23)
Marc.
Hors ligne
Je n'ai pas le choix concernant les index sur ces tables, je suis obligé de les garder, car ils sont indispensables pour d'autres utilisations de ces tables.
Au final le reste des requêtes COPY s'est terminé entre temps, donc je n'ai pas eu à les dropper.
Par contre, je me suis dit qu'il serait bien de lancer ce script avant de relancer un nouveau traitement :
VACUUM ANALYZE VERBOSE
REINDEX DATABASE "MaBaseDeDonnees"Ai-je eu raison ? De toute façon le temps d'exécution final me le dira ! ;-)
Gôm
Dernière modification par gom (20/12/2009 20:29:52)
Hors ligne
C'est difficile à dire. On peut limiter les fragmentations d'index en modifiant leur remplissage, mais malgré tout, ça n'est que statistique (on a moins de 'chances' de fragmenter les index). La réindexation l'aura toujours optimisé, ce qui sera bon pour les séléctions, mais ça n'apportera probablement rien pour l'insertion.
Marc.
Hors ligne
Pages : 1