Tuning Grupos de Redologs

Estimados,

En mi carrera, varias veces me toco ver situacion y discusiones sobre cuando y como crear nuevos grupos de Redologs en una BD Oracle.

Como ejemplo sitare una situacion que ocurrio en 2 grandes proyectos de Chile (No citare nombres para no causar problemas con algunos colegas). Mi idea de recurir a este tema no es causar discusiones y si plantear mi vision y solucion para problemas de este tipo.

Cuando se descubre un gran volumen de contecion (Wait) en redologs, en las mayoria de las veces al ver el numero de log switches se descubre que hay un gran numero de cambio de redologs por hora o en algunos casos en pequenas ventanas de tiempo.

Ejemplo:

En la BD en question ocurrian mas de 110 log switches por hora y en algunas situaciones, llegaba a casi 600.

Esta BD tenia 10 grupos de redo con dos miembros de 10 MB cada uno. Una BD de 800 GB de tamano y muy transaccional.

Debido a esto, esta BD se pisaba la cola muchas veces durante el dia causando seria contencion en ese sentido. Ese fue el motivo de mi discucion con ciertos Gurus de Oracle en Chile. La solucion de ellos era crear mas grupos de redo de 10MB, por ejemplo de 10 a 50 grupos para disminuir las veces que se pisaba la cola el log switch. Esto en mi opinion no solucionaba el problema ya que el numero de log switches por hora continuaria igual que antes. Es como por ejemplo, estar en un bote que se esta hundiendo, y para evitar esto utilizas una cuchara de sopa para sacar el agua. Por mas que te esfuerces el agua que entra es mayor al que sale. Puedes hacerlo mas rapido y solo lograras hundirte y cansarte como loco. Pero si en vez de una cuachara usaras un balde de 5 litros, podrias sacar el agua mas rapido de lo que entra y evitar que se hunda, caso sea necesario, utilizarias un balde mayor caso el monto de agua que entra es mas grande. Lo mismo se aplica en este sentido. Por eso, yo discutia que habia que aumentar el tamano de los miembros de cada grupo para controlar esta situacion. Es correcto que aumentar el tamano de los miembros de los grupos de Redolog aumentara el tamano de cada archive log, y consequentemente demorara mas el tiempo de recuperacion en caso de falla ya que la cantidad de transacciones a ser aplicada por cada archive sera mayor. Pero que es mejor?

En esta situacion se generan mas de 1000 archives de 10MB cada uno diariamente, sera mejor aplicar 1000 archives en caso de ser necesaria una recuperacion de la BD por falla fisica o logica 24 hrs despues del ultimo respaldo o aplicar 100 archives de 100MB? o 10 de 1GB? Aumentar el tamano de los miembros de los grupos de Redologs ayuda a evitar que se llenen muy rapido y que causen contencion a nivel de I/O y del LGWR y ARC.

Para saber el numero de log switches en su BD puede ejecutar el siguiente script:

spool logs.log
set echo on
set linesize 150
set pagesize 500
column day format a16  heading ‘Dia’
column d_0 format a3  heading ‘00′
column d_1 format a3  heading ‘01′
column d_2 format a3  heading ‘02′
column d_3 format a3  heading ‘03′
column d_4 format a3  heading ‘04′
column d_5 format a3  heading ‘05′
column d_6 format a3  heading ‘06′
column d_7 format a3  heading ‘07′
column d_8 format a3  heading ‘08′
column d_9 format a3  heading ‘09′
column d_10 format a3  heading ‘10′
column d_11 format a3  heading ‘11′
column d_12 format a3  heading ‘12′
column d_13 format a3  heading ‘13′
column d_14 format a3  heading ‘14′
column d_15 format a3  heading ‘15′
column d_16 format a3  heading ‘16′
column d_17 format a3  heading ‘17′
column d_18 format a3  heading ‘18′
column d_19 format a3  heading ‘19′
column d_20 format a3  heading ‘20′
column d_21 format a3  heading ‘21′
column d_22 format a3  heading ‘22′
column d_23 format a3  heading ‘23′
column  Total   format 9999
column status  format a8
column member  format a40
column archived heading ‘Archived’ format a8
column bytes heading ‘Bytes|(MB)’ format 9999
Ttitle  ‘Log Info’  skip 2
select l.group#,f.member,l.archived,l.bytes/1078576 bytes,l.status,f.type
  from v$log l, v$logfile f
 where l.group# = f.group#
/
Ttitle off
prompt =========================================================================================================================
Ttitle  ‘Log Switch on hour basis’  skip 2

select to_char(FIRST_TIME,’DY, DD-MON-YYYY’) dia,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’00′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’00′,1,0))) d_0,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’01′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’01′,1,0))) d_1,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’02′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’02′,1,0))) d_2,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’03′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’03′,1,0))) d_3,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’04′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’04′,1,0))) d_4,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’05′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’05′,1,0))) d_5,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’06′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’06′,1,0))) d_6,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’07′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’07′,1,0))) d_7,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’08′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’08′,1,0))) d_5,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’09′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’09′,1,0))) d_9,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’10′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’10′,1,0))) d_10,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’11′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’11′,1,0))) d_11,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’12′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’12′,1,0))) d_12,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’13′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’13′,1,0))) d_13,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’14′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’14′,1,0))) d_14,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’15′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’15′,1,0))) d_15,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’16′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’16′,1,0))) d_16,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’17′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’17′,1,0))) d_17,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’18′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’18′,1,0))) d_18,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’19′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’19′,1,0))) d_19,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’20′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’20′,1,0))) d_20,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’21′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’21′,1,0))) d_21,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’22′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’22′,1,0))) d_22,
       decode(sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’23′,1,0)),0,’-',sum(decode(substr(to_char(FIRST_TIME,’HH24′),1,2),’23′,1,0))) d_23,
       count(trunc(FIRST_TIME)) Total
 from v$log_history
 group by to_char(FIRST_TIME,’DY, DD-MON-YYYY’)
 order by to_date(substr(to_char(FIRST_TIME,’DY, DD-MON-YYYY’),5,15) )
/
Ttitle off
prompt
spool off
 

Espero que esta nota ayude a algunos de uds a detectar este tipo de situaciones, es muy comun encontrar esto en muchas Bases de Datos. Es increible lo que ayuda cuando se detecta y se soluciona este problema.

Para finalizar acuerdense que cada vez que ocurre un log switch, ocurre un checkpoint o sea imaginense que si esta ocurriendo un log switch 100 veces en una hora, 100 veces el oracle limpio el buffer a disco, 100 veces actualizo los header (encabezados) de todos los archivos de la BD ,100 veces genero archives y mucho mas cosas que ocurren por debajo a nivel de procesos, consultas,etc. En estos casos dejamos el pobre DBWR que es el encargado de hacer esto con la lengua afuera y empiezan a ocurrir los “incomplete checkpoints” en el alert.log. Ya pueden imaginarse la cantidad de I/O generada tambien.

Espero haberles ayudado a entender este importante proceso de tuning de una BD.

Muchos Saludos,

Francisco Munoz Alvarez