Discussion :

[Wurlitzer]

J'ai une base qui tout d'un coup (évolution de l'applicatif) est passé d'un log switch par heure à 10 log switch par heure.

Si je fais un statspack, je confirme ce resultat au niveau de la ligne "redo size per Second" à bien été multiplié par 10 aussi.

J'en deduit que j'ai une grosse augmentation de l'activité de mise à jour (INSERT, UPDATE, DELETE). Est ce correcte ? Y a t il autre chose qui peut générer du Redo.

Ma vrai question est comment peut on faire pour retrouver les sessions qui générent le plus de redo ?

Merci,

[orafrance]

déjà un switch par heure c'est très insuffisant.

[Jaouad]

déjà un switch par heure c'est très insuffisant.

Cad ???

[Wurlitzer]

Oui je veux bien croire... mais j'en ai eu juqu'a 300 et là ca fait quand meme beaucoup avec bien sur des incomplete checkpoint dans les Wait event.

A combien se situe l'optimun ? Sur quel critère ?

[orafrance]

Cad ???

bah c'est à dire qu'une heure d'activité dans les redos courant ça fait mal quand tu les perds

[orafrance]

A combien se situe l'optimun ? Sur quel critère ?

de mémoire c'est entre 10 et 20 minutes d'après Oracle

[Débéa]

Bonjour,

Je profite de cette discussion pour vous poser une question.

Existe-t-il un paramètre qui forcerais Oracle à générer une Archive toutes les N minutes même si le redo log n'est pas rempli ?


Merci

[aline]

Bonjour,

Je profite de cette discussion pour vous poser une question.

Existe-t-il un paramètre qui forcerais Oracle à générer une Archive toutes les N minutes même si le redo log n'est pas rempli ?


Merci

oui , et il est très utile, c'est archive_lag_target.
si tu le met à 600, il switch tout les 10 minutes ou quand ton redo est rempli

[Débéa]

oui , et il est très utile, c'est archive_lag_target.
si tu le met à 600, il switch tout les 10 minutes ou quand ton redo est rempli

Il existe depuis quelle version ?

[Jaouad]

Tout les paramétres Target sont dispo à partir de la 9i .

Oracle conseille de switcher tous les 1/4 d'heure. Mais je suis un peu moins d'accord avec Fred. Le plus important n'est pas de pedre une heure de transaction mais de savoir combien de transaction on a perdu.

je préfère perdre un REDO de 6 Mo génère en 1 heure, qu'un REDO de 750 Mo tout les 1/4 d'heures. D'autant plus qu'il existe la multiplexation des REDO en renfort du mirroring pour éviter la perte irreversible.


le statspack te donne les requêtes qui ont consommé le plus de REDO

[Wurlitzer]

Ou ca dans le statspack ?!? J'ai rien trouvé de ce genre.

[Jaouad]

Code :

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

SQL ordered by Gets

Ici on va avoir tous les ordres SQL qui ont consommé bcp de buffer. Si ce sont des ordres journalisés ( insert - delete - update ...) ces buffers se retrouvent dans les REDO.

[pifor]

On peut aussi avoir la taille du redo généré sous SQLPLUS en exécutant la requête manuellement précédée par:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SET AUTOTRACE ON;
...

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        117  consistent gets
          0  physical reads
          0  redo size
     135843  bytes sent via SQL*Net to client
        949  bytes received via SQL*Net from client
         98  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       1441  rows processed

[Jaouad]

Juste une petite précision que je penses qu'il est nécessaire de faire ( on vient de me pourrir ma base a cause de ca )

Lorsque on fait un set autotrace , Oracle execute bel et bien les requêtes et donc génère de l'activité. C'est comme ca que l'on récupére la taille des REDO, le tri ...

Mais lorsque l'on quitte sa session Oracle par un exit Oracle fait un commit t non pas un rollback ...