Oracle y yo

De Lunes a Viernes la cantidad de Switch en mi base de datos es 4 por hora, o sea, cada 15 minutos se generá un archive, por ende cada 15 minutos se actualiza mi base de datos StandBy , por lo tanto, si se llegase a producir un error o corrupción de mi base de datos principal, a lo más, perdería 15 minutos (por la información de redo que queda en los grupos de redologs) .

Pero el fin de semana, no se hace ningún Switch , o sea, el grupo current será durante todo el fin de semana el mismo grupo, y no puedo darme el lujo de perder el grupo current del fin de semana, pues son pocas transacciones , pero críticas.

¿Podría colocar un cron el fin de semana para que se ejecute cada 30 minutos y efectúe un Switch de Redo? , si.. pero sería poco elegante

¿Cómo lo soluciono? ... mmmmm

Log Switch on hour basis

DIA              10  11  12  13  14  15  16  17  18  19  20  21  22  23  TOTAL
---------------- --- --- --- --- --- --- --- --- --- --- --- --- --- --- -----
WED, 28-OCT-2009 -   -   -   -   -   -   -   -   -   -   2   -   -   -       2

Ahora, procedemos a cambiar el parámetro ARCHIVE_LAG_TARGET , con lo cual aceleramos los Switch de Redo y provocaremos un gran impacto ¿cuál? , pues el de minimizar la información pérdida si se llega a corromper nuestro Grupo de Redo current, ¿por qué? , pues porque la información será pasada de forma más rápida a mi base de datos StandBy

Ejemplo práctico :

Modificamos el ARCHIVE_LAG_TARGET y lo dejamos en 2 minutos

SQL> alter system set archive_lag_target=120 scope=both;

System altered.

Con lo anterior , si analizamos el archivo de alerta , veremos que efectivamente se producen Switch de Redo cada 2 minutos

Sun Jan 31 22:45:58 2010
Thread 1 cannot allocate new log, sequence 18
Current log# 1 seq# 17 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo01.log
Thread 1 advanced to log sequence 18
Current log# 2 seq# 18 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo02.log
Sun Jan 31 22:49:02 2010
Thread 1 advanced to log sequence 19
Current log# 3 seq# 19 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo03.log
Sun Jan 31 22:53:57 2010
Thread 1 advanced to log sequence 20
Current log# 1 seq# 20 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo01.log
Sun Jan 31 22:59:01 2010
Thread 1 advanced to log sequence 21
Current log# 2 seq# 21 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo02.log
Sun Jan 31 23:01:05 2010
Thread 1 advanced to log sequence 22
Current log# 3 seq# 22 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo03.log
Sun Jan 31 23:03:05 2010
Thread 1 advanced to log sequence 23
Current log# 1 seq# 23 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo01.log
Sun Jan 31 23:05:03 2010
Thread 1 cannot allocate new log, sequence 24
Current log# 1 seq# 23 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo01.log
Thread 1 advanced to log sequence 24
Current log# 2 seq# 24 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo02.log

Miramos la actividad de nuestra instancia , en cuanto a Switch por horas, y claro... se refleja efectivamente el cambio

DIA              10  11  12  13  14  15  16  17  18  19  20  21  22  23  TOTAL
---------------- --- --- --- --- --- --- --- --- --- --- --- --- --- --- -----
WED, 28-OCT-2009 -   -   -   -   -   -   -   -   -   -   2   -   -   -       2
SUN, 31-JAN-2010 -   -   -   -   -   -   -   -   -   -   -   -   19  2      21

En resumidas cuentas el parámetro ARCHIVE_LAG_TARGET nos permite acelerar los Switch de Redo, ¿para qué nos puede servir eso? , pues para mantener una sincronización eficaz con nuestra base de datos StandBy o simplemente para que la cantidad de información que podríamos perder en un crash , siempre sea la mínima

Esto es aplicable tanto para bases de datos primarias (con StandBy) , como para base de datos StandAlone

Pues bien , la información que todo mortal necesita

Archive_lag_target en Oracle9i
Archive_lag_target en Oracle10g
Archive_lag_target en Oracle11gr1
Archive_lag_target en Oracle11gr2