Oracle Base de données de performance liées

Question

Je travaille actuellement sur la base de données Oracle 9.2.0.8.I J'ai quelques questions liées à Performace de base de données que trop lié à Redo journaux verrous & contention. Les réponses de la pratique réelle seront très appréciées. aidez s'il vous plaît.

1. Mes données contiennent actuellement 25 fichiers journaux redo avec 2 membres dans chaque fichier. Chaque membre est de taille 100m. Donc cela vaut-il la peine de conserver 25 fichiers de journalisation chacun avec 2 membres (100 Mo chacun).
2. Ma base de données est 24 * 7 avec un utilisateur min de 275 & Max de 650. Ma base de données est en majorité SELECT mais très moins INSERT/UPDATE/DELETE. Et depuis 1 mois j'ai commencé à observer que ma base de données génère des archives sur une moyenne de 17GB min à 28Go chez MAX. Mais le LOGSWITCH se déroule en moyenne toutes les 5-10 min. quelques fois plus fréquemment. Et même quelques fois 3 fois dans un min. Mais mon fichier SPFILE indique log_checkpoint_timeout = 1800 (30 min).

3. Et A propos Redo log verrous & contention, quand j'isssue: - SELECT name, value DE v $ sysstat WHERE nom = 'Refaire enregistrer les requêtes de l'espace'; Sortie: -

   NAME                VALUE 
       -------------------------------------------------------------------- ---------- 
       redo log space requests            20422 
   (This value is getting increased day by day) 
   

4. Où comme Oracle recommened d'avoir de la demande d'espace de journalisation proche de zéro.
5. Donc, je veux savoir pourquoi ma base de données va fréquemment changer de journal. Est-ce à cause de données Ou Becoze de quelque chose d'autre.
6. Mon doute était, Si j'augmente REDO LOG Buffer le problème peut résoudre. Et j'ai augmenté redo journal tampon de 8 Mo à 11 Mo. Mais je n'ai pas trouvé beaucoup de différence.
7. Si j'augmente la taille de REDO LOG FILE de 100MB à 200MB, cela aidera-t-il. Est-ce que cela m'aidera à réduire le temps de commutation du journal & pour ramener la valeur de REDO LOG SPACE REQUEST à zéro.

Answer 1

17GB de fichiers journaux par minute me semble assez élevé. Peut-être que l'un des espaces de table de votre base de données est toujours en mode de sauvegarde en ligne.

Answer 2

Il serait probablement utile de regarder quelles sessions génèrent beaucoup de refaire, et quelles sessions attendent le plus sur l'espace de journalisation.

SQL> l 
    1 select name, sid, value 
    2 from v$sesstat s, v$statname n 
    3 where name in ('redo size','redo log space requests') 
    4 and n.statistic# = s.statistic# 
    5 and value > 0 
    6* order by 1,2 

Answer 3

Quelque chose au sujet des informations que vous avez fournies ne correspond pas - si vous vraiment générer environ 20 g/min de journaux d'archive, vous transfèrerait vos 100M fichiers journaux au moins 200 fois par minute - pas 3 fois/minute le pire cas que vous avez mentionné. Cela ne correspond pas non plus à votre description de "... surtout SELECT".

Dans le monde réel, je ne m'inquiéterais pas des commutateurs de journal toutes les 5-10 minutes en moyenne. Avec autant de reprises, aucun des paramètres d'initialisation n'entrent en jeu pour la commutation - cela est dû au remplissage des journaux de redondance en ligne. Dans ce cas, le seul moyen de contrôler la vitesse de commutation est de redimensionner les journaux, par ex. doubler la taille du journal réduira la fréquence de commutation de moitié.