Comment dimensionner les redo

Bonjour, nous utilisons zabbix pour surveiller les bases oracle et pour certaines d'entre elles zabbix nous informe que 3 redo ont ete generes en moins de 5 minutes ?

Est ce grave ? que faut il faire selon vous ? grossir les redo en ajouter ?

le message que nous avons est le suivant :
"Oracle number of redo logs available for switching is too low (Less 3 for 5 mn)"

merci

Bonjour,

Le message ne veut pas dire cela (je ne connais pas Zabbix, je me base sur la phrase uniquement)
"Oracle number of redo logs available for switching is too low (Less 3 for 5 mn)" => "Le nombre de redolog disponibles pour un "switch" (switch logfile) est trop bas (moins de 3 pendant 5 min)
Ca dépend du nombre de redolog, de leur taille et de la fréquence à laquelle ils y a un switch. Soit le paramétrage Zabbix est trop restrictif, soit la base nécessite un redimensionnement, soit rien à faire si c'était lors d'un traitement exceptionnel ou un problème d'archivage.

A un moment AskTom préférait augmenter le nombre de redolog que d'augmenter leur taille (je dis à un moment car ça date, il a pu changer d'opinion avec les nouvelles versions).

Donc il faut vérifier le nombre de redolog de la base, leur taille, et si la base est en archive log.
Vérifier aussi le nombre de switch générés depuis x semaines

Code:

---

SELECT * FROM sys.V_$ARCHIVED_LOG

---

Le plus facile est de rajouter des redologs, car changer la taille implique de recréer tous les redologs à la même taille.

Bonjour,

il faut voir le nombre de group de redolog et leur taille

Code:

---

select group#,MEMBERS,BYTES/1024/1024 "SIZE MB" from v$log;

---

et le nombre de switch par heure

Code:

---

1 2 3 4 5

select to_char(first_time,'YYYY-MM-DD HH24'), count(*) from v$log_history where first_time between (sysdate - 1) and sysdate group by to_char(first_time,'YYYY-MM-DD HH24') order by to_char(first_time,'YYYY-MM-DD HH24');

---

Oracle recommande d'avoir un switch toutes les 20 minutes donc moins de 5 par heure.

si tu a des pics avec beaucoup de switch il faut augmenter la taille de tes redolog pour diminuer le nombre de switch par heure à une valeur de l'ordre de 5 et avoir 6 group de redolog au lieu de 3 ne fait pas de mal.

Citation:

---

Envoyé par a.presles

...Oracle recommande d'avoir un switch toutes les 20 minutes donc moins de 5 par heure....

---

Je ne sais pas si c'est toujours le cas (quel est le document "officiel" qui le dit, et de quand date-t-il ?), mais dans la pratique, cette recommandation est inutilement exigeante, et ne doit pas concentrer inutilement les préoccupations.

La grande question, c'est "est-ce que le rythme de rotation de mes fichiers redo logs provoque des attentes significatives dans ma base " ?
Je vois pas mal de bases où on est, de façon régulière, à 20 ou 30 par heure, sans que ça pose le moindre problème.
J'ai même fait un test dernièrement (qui vaut ce qu'il vaut) où j'ai constaté que les attentes devenaient vraiment pénalisantes à partir de plusieurs rotations par minute.

Donc pas de dogmatisme là-dessus, regardons les attentes éventuelles.

Citation:

---

Envoyé par Pomalaix

Donc pas de dogmatisme là-dessus, regardons les attentes éventuelles.

---

100% d'accord. Mieux vaut regarder les "checkpoint not complete"

Je suis totalement d'accord pour les 20 minutes mais c'est pour avoir un repère en générale moins de 1 switch par minute suffit a ne pas avoir d'attente. Je ne sais plus ou j'ai trouvé ces 20 minute mais je l'ai vu plusieurs fois dans les doc oracle.

Bonjour,
les redologs ne devraient pas switcher trop fréquemment pour ne pas entraver la performance du read/write database.Une base qui switch trop a certainement un problème avec une configuration mémoire.Il est possible aussi qu'une base switch trop sans problème de performance,surtout si elle évolue dans un environnement système hautement tuné,le système masque alors les manquements de la base.Cela n'est pas fréquent mais je l'ai expérimenté chez des clients.


Cordialement

Citation:

---

Envoyé par Pomalaix

" Citation Envoyé par a.presles Voir le message
...Oracle recommande d'avoir un switch toutes les 20 minutes donc moins de 5 par heure...."
Je ne sais pas si c'est toujours le cas (quel est le document "officiel" qui le dit, et de quand date-t-il ?), mais dans la pratique, cette recommandation est inutilement exigeante, et ne doit pas concentrer inutilement les préoccupations.

---

Ici, pour une Oracle 18c, on parle d'un switch toutes les 30 minutes comme étant une valeur typique : https://docs.oracle.com/en/database/...8-B1BAE5BBD13E
Même chose pour Oracle 10g : https://docs.oracle.com/cd/B19306_01...onlineredo.htm

"The following initialization parameter setting sets the log switch interval to 30 minutes (a typical value)."

Vous parlez ici de ARCHIVE_LAG_TARGET (avec une valeur typique de 30 minutes), qui est un sujet assez différent.

Assez couramment, l'activité est irrégulière dans la journée: il y a des pics transactionnels, où les redo logs se remplissent très vite, et il y a des moments plus calmes.
Comme les changements de redo logs (switch) peuvent poser des problèmes de performances s'ils sont trop fréquents, on a tendance à les surdimensionner pour que la fréquence reste raisonnable pendant les pics. Disons alors qu'ils se remplissent en 5 minutes.
Ce problème de performances pourrait même exister pour une base qui n'est pas en archivelog.


En revanche, dans les moments creux, il faut beaucoup plus longtemps pour qu'ils se remplissent. Disons 2 heures.
Il se pose alors un problème qui n'a rien à voir avec les performances, mais qui touche à la garantie de restaurabilité.
Je fais l'hypothèse que j'ai une sauvegarde tous les soirs, et que les archivelogs ont une copie externalisée (log_archive_dest_2).
J'ai un engagement de service qui dit : même si le serveur flambe, on doit pouvoir restaurer sans perdre plus de 30 minutes de transactions.
La configuration actuelle ne le permet pas : mon serveur a flambé à 2h45, et le dernier archivelog a été produit à 1h00.
C'est pour ce genre de scénario qu'on fait intervenir ARCHIVE_LAG_TARGET=1800, qui forcera un archivage si nécessaire, de sorte qu'il ne s'écoule pas plus de 30 minutes entre la production de 2 archives, même en période creuse.


En résumé, si on est en période de pic, on aura un SWITCH naturel toutes les 5 minutes, et si on est en période creuse, on aura un SWITCH provoqué toutes les 30 minutes.
La taille appropriée des redo logs garantit les performances, et ARCHIVE_LAG_TARGET garantit une limite à la perte de données en cas de sinistre.

Je me disais bien que ce paramètre était "particulier" et pas le plus adapté à la discussion... mais au moins j'ai appris quelque chose :mrgreen:

Sinon, dans ma doc perso j'ai compilé ceci :
Oracle recommande 12 minutes max:
"Every DBA knows that the size of their redo logs is very important. Too small, and the frequent log switches tie-up the LGWR,
ARCH and DBWR background processes. Too large and you risk losing data during an instance crash.
As a general rule of thumb, Oracle recommends that you size your online redo logs not to switch more then 5 times per hour
during peak DML times."

Livre Karl DUHN p110 : 10 minutes max
"Try to size the online redo logs so that they switch anywhere from two to six times per hour. The V$LOG_HISTORY
contains a history of how frequently the online redo logs have switched."

Dimensionnement (livre Razvan BIZOI Oracle 11g p13.9 et 13.10) :
"un redo log switch ne pas pas arrivé avant 15 minutes : le membre doit donc contenir 15 minutes de données écrites par
LGWR"