« ORACLE no es lo mismo que OracleHacer un tracer con el evento 10046 : Trace Event 10046 »

Parámetro ARCHIVE_LAG_TARGET : Más que un simple parámetro



Imagínense la siguiente situación

"
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

"



La forma de solucionar eso , es mediante la modificación del parámetro ARCHIVE_LAG_TARGET , este parámetro esta orientado a bases de datos con una StandBy , pues forzan el Switch de Redo según la cantidad de segundos especificado en ese parámetro.

Lo principal es saber la cantidad de switch que se provocan en la base de datos, para eso podemos analizar la siguiente nota

Analizando la cantidad de Switch de Redo

Si se fijan no hay actividad en los switch de redo, al momento de la ejecución , pero eso no indica que no haya transacciones que estén pendientes de ser almacenadas en los archives, por ende hay transacciones pendientes de ser pasadas a mi base de datos StandBy (eventualmente)
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

by Ligarius
08.02.10. 09:56:35. 782 words, 6474 views. Categories: Base de datos, Tuning / Performance ,