redo size dans statspack 9i

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,

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

Citation:

---

Envoyé par Fred_D

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

---

Cad ???

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 ?

Citation:

---

Envoyé par Jaouad

Cad ???

---

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

Citation:

---

Envoyé par Wurlitzer

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

---

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

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

Citation:

---

Envoyé par 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

---

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

Citation:

---

Envoyé par aline

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 ?

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

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

Code:

---

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.

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:

---

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

---

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 :aie: )

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 ...