Bonjour,
 
 
je débute dans les bases de données et j'aurai besoin de vos conseils, une partie de mon boulot actuel est de sortir des rapports a partie d'une datawarehouse oracle9i, il se trouve que la personne qui est censée etre le dba n'est ni communicatif ni extremement compétent et donc je dois aller dans le cambouis moi-meme.
 
 
Pour accélerer la sortie de rapports j'ai crée toute une série de table de travail qui regroupent des tables et sur lesquels j'effectue des traitements que je devais systématiquement faire dans mes rapports, j'arrive au résultat que je veux mais avec mes connaissances restreintes d'sql c'est vraiment fait a la grosse louche, du coup j'ai quelques questions:
 
 
 
 
 
- dans un scenario ou j'ai une table1 dont: la seule modification est l'ajout d'enregistrement, il n'y a jamais de suppression d'enregistrement, jamais de modification d'enregistrement existant; comment mettre a jour une table 2 qui fait un insert de champ de la table1 de maniere optimisée, sachant également que la table1 a plus de 7millions d'enregistrement et qu'il y a des traitements a effectuer lors de ces insert.
 
 
 
 
 
- pourriez vous me donner 4-5 éléments a vérifier ou tester pour que je puisse m'assurer que oracle délivre bien toute sa puisance, j'ai peur que l'install ait été faite du style next,next,next
 
 
 
 
 
merci de votre aide  

1) rien compris
2) j'aime pas les tables temporaires. pourquoi t'utilises pas des vues et des PS ? à moins à la limite que ces tables temporaires constituent un "infocentre" (extract d'une base de données sous forme de données transformées prêtes à être interrogées par éditeurs de raport tels que BO), mais à ce moment elles n'ont rien à foutre dans la même base.
3) C'est justement parceque le boulot de DBA c'est pas fait "next next" si copier/coller le config.ini d'un autre serveur que c'est difficile. Une base, ça se paramètre et optimise selon la base elle-même, et surtout l'utilisation qu'on en a. Entre deux serveurs, on peut avoir deux configurations diamétralement opposées et obtenir de très bonnes performances sur les deux, parcequ'on n'en a pas la même utilisation. Donc pour tes "4-5 trucs à vérifier" tu trouveras pas de réponse. De toute façon : t'es pas DBA si ? Donc laisse ton DBA faire son boulot, et tant-pis s'il est pas bon, dans le pire des cas il sera pas moins bon, et c'est pas parcequ'il n'est pas d'accord avec toi qu'il est incompétant.
 
Bref. En tout cas, un Oracle qui ramme avec 7 millions de lignes, ça a trois explication :
- Moins de 2 Go de mémoire sur un serveur SGBD, t'as qu'à installer Access, ça sert à rien de t'emmerder avec des outils professionnels
- Les index, faut pas hésiter à en avoir 10 dans la même table. Chaque requête de tes application doivent pouvoir utiliser un index qui répond le mieu à leur besoins. Sinon, même chose, installe Access, ça sera pas pire.
- Evite tant que possible les triggers (ils gèrent ligne à ligne plutôt que de faire des lot, et gèrent une transaction à chaque fois : pas bon pour les mises à jour de masse), et groupe tes transactions, en les imbriquant le moins possible (ça bouffe un max ces bêtes là, donc dès que ça porte sur un grand volume, ça chie dans la colle). Vu que c'est des tables de travail, n'hésite pas à faire des lock dessus lors des traîtements, ça évitera le SGBD d'en faire et défaire entre chaque transaction.

merci de ta réponse.
 
pour le 1)
pour le moment cela se passe comme ceci, les db en production sont sur un as400 en db2, chaque nuit il y a une importation de ces données vers un datawarehouse en oracle9i qui tourne sur solaris, mes tables qui font "infocentre" se trouve sur un autre serveur oracle9i ou tourne également les produits de rapport, cognos reportnet, donc chaque soir je voudrais mettre a jour mon "infocentre" par rapport a la datawarehouse, et donc je me demandais si il y avait des instructions spécialisées pour faire cela, sachant qu'il ne s'agit toujours que d'insert supplémentaires
 
pour le 2)
il s'agit bien d'infocentre (encore que je ne connaissais pas le mot ), indexés a mort et avec des champs calculés que je devais faire auparavant au niveau du rapport, donc a chaque éxécution de rapport.
 
pour le 3)
il ne s'agit pas d'etre d'accord ou pas avec lui, mais je vois bien qu'il ne maitrise pas grand chose, en fait il est devenu 'dba' par la force des choses, ils ont décidé d'implementer une datawarehouse il y a +/- 2 ans et c'est retombé sur lui, a priori sa seule expérience en base de donnée se limite a dbase. Et a coté de cela j'ai la direction qui me met la pression pour sortir des rapports rapidement.
Je sais bien que j'y allais peut-etre un peu fort dans mon premier post, mais je voudrais juste pouvoir un peu avancer dans mon job, a cote de cela je suis un graduat en cours du soir en gestion de base de donnée, mais ce n'est pas avec 4 mois dans les jambes que je vais pouvoir approcher oracle, j'en suis parfaitement conscient.

Ben si c'est entre deux Oracle, utilise simplement le SQL Loader, tu ne trouveras pas plus rapide.
 
Sinon, il n'y a pas de secret à ma connaissance.
Je suis par contre étonné de voir que vous bossez avec un AS400 et des serveurs Oracle, et qu'il n'y ait pas un seul DBA qualifié dans la boîte ()
Il flippe pas trop le gars chargé de ça ?

pour le moment j'ai créé un "lien de base de donnée" donc je rapatrie via un select from tblxxx@datawarehouse,  
mais ma question était de savoir quel est la requete la plus optimisée pour faire la mise a jour de ma table? faire un insert des enregistrements dont la clé primaire est différente, ou bien y a t'il moyen de jouer sur le rowid, ou une autre méthode.
j'ai déja pas mal googelé mais difficile de trouver des criteres de recheche qui ne me renvoie pas des liens vers des update classique de table.
 
je sais la situation est aberrante, je suis relativement nouveau dans la boite donc je ne connais pas encore parfaitement la situation, mais ils marchent par contrat de maintenance avec des firmes externes, la mise en place de la datawarehouse, tout le travail conceptuel, les scripts d'import on été fait par une personne externe.  
Alors dans le cas présent ca me permet d'en profiter et de manipuler un peu oracle et son environnement.
 
merci pour tes réponses en tout cas

Typiquement, chez GE où j'étais prestataire ces derniers temps, on faisait un truc simple :
- delete dans "infocentre" de toutes les données ayant moins d'une semaine.
- récupération de toutes les données de l'ERP ayant moins d'une semaine et copie dans infocentre.
 
=> Ce système nous garantissait :
1) De pas faire de check ligne à ligne sur tout le volume des données.
2) De ne pas devoir faire de jointure entre les données distantes et locales.
3) De garantir que les données sont rafraîchies, y compris s'il y a eu une correction dans les données des jours précédents.
 
Pour les données très sensibles, on remontait même à 1 mois.
 
Ca augmente évidement le volume des données traîtées. Mais tu gagnes énormément au niveau de l'import. A bencher donc, pour voir si les traîtements que tu fais sur les données ne sont pas trop handicapés par le volume supplémentaire.