Discussion :

[orafrance]

tu oublies que tu as 3 contextes d'utilisation... faut avoir une vision globale des 3 contextes...
amha, je vois pas comment faire un tel réglage via le forum...

certes... surtout sans élément sur les 3 contextes comme par exemple 3 rapports statspack

[farenheiit]

je dois faire une formation TUNING fin janvier. J'espere qu'après je comprendrais de quoi vous parlez parceque là je suis noyé

[orafrance]

patientes gentillement jusque fin janvier alors

Cette formation devrait être obligatoire, elle est vraiment très bien

[wondersonic]

La formation Tuning est effectivement très bien, mais il faut mieux venir avec un peu d'expérience ou sinon des questions très précises pour en tirer pleinement profit.

Par exemple, elle t'enseignera que ta base se comporte en mode :
- DSS pour l'activité 1
- DSS pour l'activité 2
- OLTP pour l'activité 3 (OLTP mesuré selon le nombre d'utilisateurs concurrents)

Tu as donc une base de données hybride (le mode DSS étant aux antipodes du mode OLTP).

Définitions sur wikipedia :

- DSS :
"L'informatique décisionnelle (en anglais : DSS pour Decision Support System ..) désigne les moyens, les outils et les méthodes qui permettent de collecter, consolider, modéliser et restituer les données d'une entreprise en vue d'offrir une aide à la décision et de permettre aux responsables de la stratégie d'une entreprise d’avoir une vue d’ensemble de l’activité traitée.
Ce type d’application utilise en règle générale un datawarehouse (ou entrepôt de données) pour stocker des données transverses provenant de plusieurs sources hétérogènes et fait appel à des traitements lourds de type batch pour la collecte de ces informations.
..."

- OLTP :
Online transaction processing, or OLTP, refers to a class of systems that facilitate and manage transaction-oriented applications,
...
OLTP has also been used to refer to processing in which the system responds immediately to user requests.
..."

Les bases de données Hybride sont généralement plus difficiles à optimiser car tu dois configurer ta base et créer un MPD performant pour ces deux types d'utilisations opposés.

Donc questions :
- quel est le nombre d'utilisateurs en parallèle (pour l'activité 3) ?
- tu es en dedicated server ou en shared server ?
- qu'entends-tu par

un moteur de calcul développé en JAVA qui se connecte à la base et qui va faire des select massifs au début puis des inserts massifs à la fin.

Par massifs, tu entends en nombre de select et d'insert (en parallèle ou non ?) ou bien en nombre de lignes récupérées / insérées ?
- concernant l'utilisation de sql loader, il existe un mode de fonctionnement en parallèle (mais qui a ses restrictions). Lien utile ici. A noter que le parallélisme est géré côté client (lancement de plusieurs process sqlldr parallel=true ... par l'utilisateur, le script etc...)

Enfin, pour accélérer ton chargement (je vais sûrement répéter ce qui a déjà été dit) :
- atention aux triggers !
- supprimes éventuellement tes index avant le chargement et reconstruit les après
- passe en mode direct de sqlldr (si possible) (bypass le log writer et donc l'archive log)
- vérifie que tu as autant de process database writer que de CPU (donc 4 ici)
- si tu ne peux pas te passer du mode archivelog => augmente le log buffer (128Mo) et augmente la taille des redo à 1Go (l'idée est de n'avoir qu'un à deux switchs de redo log par heure), répartis les fichiers de redo log sur des axes différents, essaie de passer sur du RAID 1+0 (au lieu de RAID 5 par exemple, mais cela a un coût)
- est-ce que le chargement des données passe par un réseau ? si oui, gigabit ?
- renseigne toi comme te l'a indiqué orafrance sur les événements d'attente les plus courants (avec statspack par exemple)

En tout cas, si la première activité est pure sql loader, rajouter du cache ne sera pas d'une grande utilité.

Par contre, la taille de la PGA peut influencer les perfs de la partie 2 et de la partie 3. (compte 1Mo par connexion cliente).


Bon courage !

[farenheiit]

merci beaucoup pour toutes ces infos. Effectivement j'ai l'intention d'aller à ma formation avec plein de questions à poser.

pou répondre à tes questions:
- nombre d'utilisateurs en parallèle: une dizaine (essentiellement du select)
- ma base est en mode serveur dédié
- j'entends par "massif" le nombre de lignes et d'insert effectués par le moteur de calcul
- le chargement de données ne passe pas par le réseau


sinon sur la partie SQL loader je suis déjà en mode direct ce qui fait que la partie SQLLOADER de mon chargement de prend que 10 min.

je prend bien en note ce que tu m'as dit sur la taille du log buffer et des redo logs car effectivement je ne peux pas désactiver l'archivage des redo log pendant le chargement.

Je compte surtout sur ma formation pour utiliser statspacks et référencer ainsi mes requêtes les plus consommatrices pour pouvoir les optimiser.

[orafrance]

Loin de moi l'idée de vouloir dénigrer cette réponse très complète, mais il convient d'être prudent quand on lance des informations alors même que les hypothèses de travail sont très insuffisante.

augmente le log buffer (128Mo)

c'est une GROSSE bêtise que de dire cela, au moins avant la 10g. Une taille supérieur à 10Mo n'est jamais intéressante (sauf cas TRES exceptionnel)... déjà 10Mo c'est énorme, selon la version d'Oracle c'est 5Mo maximum avant de déverser le log dans les redos. Oracle recommande au moins 8Mo pour les plus grosses bases.

Pour rappel, le log_bugger est vidé selon ces règles :
o every 3 seconds
o every commit
o when 1/3 full

Rappelons aussi que plus le buffer est gros plus le commit est long. En tout cas, sans wait de type "redo buffer allocation retries" on ne touche pas au log.

Pour info : http://download.oracle.com/docs/cd/B...ory.htm#i29756

l'idée est de n'avoir qu'un à deux switchs de redo log par heure

Attention, il faut s'assurer que c'est compatible avec les délais d'indisponibilité autorisés. On préconise en général des switches tous les 1/4 d'heure maximum.

vérifie que tu as autant de process database writer que de CPU (donc 4 ici)

Encore faut-il s'assure qu'il y a bien 4 canaux sur le RAID et qu'on peut bien paralléliser les écritures sans créer de latchs. Encore une fois, on ne peut pas être aussi péremptoire.

à lire : http://download.oracle.com/docs/cd/B...htm#sthref1002

Par contre, la taille de la PGA peut influencer les perfs de la partie 2 et de la partie 3. (compte 1Mo par connexion cliente).

1Mo seulement ?

http://download.oracle.com/docs/cd/B...htm#PFGRF01401

Good initial values for the parameter PGA_AGGREGATE_TARGET might be:

* For OLTP: PGA_AGGREGATE_TARGET = (total_mem * 80%) * 20%
* For DSS: PGA_AGGREGATE_TARGET = (total_mem * 80%) * 50%