Discussion :

[ZashOne]

Bonjour

J'ai herité de l'administration d'une base oracle 10.2.0.2 (migrée depuis oracle 8) sous windows server 2003 entreprise dont les types de champs des tables ne peuvent être modifiés et dont je n'ai pas de licence pour le partitionning (donc non implémenté). Le serveur contient 4 G ram et 2 processeurs Xeon et l'os doit rester un windows .

J'ai 3 tables qui me posent probleme dont voici la config

Tables 1 :

Varchar2 Varchar2
--------- ---------
ID1 Données1

Cle primaire = ID1
Nombre de lignes : +- 1 millions

Tables 2 :

Varchar2 Varchar2 Varchar2
-------- -------- ---------
ID1 ID2 Données2

cle primaire = (ID1,ID2)
Nombre de lignes :+- 25 millions
Tables 3 :

Varchar2 Varchar2 Long_Raw
-------- -------- ----------
ID1 ID3 Données3

cle primaire = (ID1,ID3)
Nombre de lignes : +- 5 millions
Taille moyenne Données3 : 15K

Il n'y a pas de cle etrangere definies entre les tables.

En utilisation normale , tout se passe bien mais lorsque je doit faire en maintenance des requetes croisée entre les tables ci dessus (ex select * from table1 where ID1 in (select ID1 from tables 2 where ... , ou des join),
alors Windows pagine et la base de donnée devient extremement lente et ce jusqu'au redemarage de l'instance (+ os).

J' ai testé avec differentes valeurs des parametres SGA_target ( >800M actuellement), pga_target, index_Caching , ..... mais rien ne resoud le probleme.

J'ai egalement regardé les explain_plan pour plusieurs requetes differentes (select in , join, exists) avec differentes combinaisons de Hints mais ceux généres par le CBO sont les meilleures.

Je voulai savoir si passer à windows Datacenter pour pouvoir utiliser le parametre LOCK_SGA= TRUE et/ou implementé le partitionning pourrait résoudre le problème , ou si tout simplement il y a une petite chose qui à echapé au yeux de tout le monde et que l'un d'entre vous connaisse (perso win server connait pas mieux que XP).

Les stat systèmes et sur tables sont effectuées correctement.

Merci d'avoir lu jusque la , en esperant trouver une solution, mon avis perso est que Oracle est bien plus adequat sur un système *nix que sur un système Windows pour des gros stockage voir en général.

[pifor]

Il faudrait au moins nous donner le résultat des EXPLAIN PLAN avec la description des tables et index concernées ainsi que la façon de calculer les statistiques. Si ces plans sont corrects mais donnent des mauvais résultats, alors il faudrait avoir la trace SQL des requêtes concernées analysées par TKPROF pour comparer les 2 plans(voir le tutoriel).

[ZashOne]

Pierre,

Pour les statistiques , on en realise deux types environ tout les mois

-Les stats systèmes via

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

EXECUTE dbms_stats.gather_system_stats('Start');

et Stop durant une journée de travail.

Les stat du schema qui contient toutes nos tables via une procedure similaire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
begin
   dbms_stats.gather_schema_stats(
      ownname          => 'MONSCHEMA', 
      estimate_percent => dbms_stats.auto_sample_size, 
      method_opt       => 'for all columns size auto', 
      degree           => 7
   );
end;
/

-Les indexs sont juste ceux associés à la cle primaire et chaque objet , table ou index a sont propre tablespace

-Pour le explain plan voici celui d'un requete de type

delete from table2 where id in (select id from table_temp);

et table_temp contient les Id issu d'un select sur table3

---------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------
| 0 | DELETE STATEMENT | | 15051 | 352K| 45 (3)| 00:00:01 |
| 1 | DELETE | tables2 | | | | |
|* 2 | HASH JOIN | | 15051 | 352K| 45 (3)| 00:00:01 |
| 3 | INDEX FAST FULL SCAN| tables_temp _PK | 300 | 2700 | 2 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL | tables2 | 35670 | 522K| 43 (3)| 00:00:01 |
---------------------------------------------------------------------------------------------

En tout cas deja un grand merci pour ton conseil de comparer celui-ci avec les traces via TKPROF, ca me donne une bonne piste je pense