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

ALTER SYSTEM SET SQL_TRACE=TRUE;

Esta forma es una manera sencilla de tracer una sesión , pero existe otra mucho más potente, la activación del evento 10046

Acá va una pequeña explicación

El Trace Event 10046 es una forma de generar trace de una consulta en partícular, muy parecida a SQL_TRACE, pero esta última adolece de un problema que es la necesidad de ejecutar el comando desde la misma sesión que esta provocando el evento de espera.

Puede tracear procesos background de Oracle y los archivos resultantes los deja en la carpeta BDUMP (pre 11gr1) , si estamos traceando procesos de usuarios, los achivos de trace resultantes los deja en la carpeta UDUMP

Nota : Cuando se indica BDUMP , se está haciendo mención a la carpeta que esta mencionada en el parámetro background_dump_dest
Y cuando se indica UDUMP , el parámetro asociado es el user_dump_dest.

¿Qué es lo que hace tan potente esta herramienta?, pues bien , este evento proporciona muchos más detalles del comportamiento de una sentencia SQL (o de varias) , para esto , se pueden setear niveles de traceo.

¿Qué niveles de traceo están disponibles?

Level 0 : El traceo está deshabilitado
Level 1 : Traceo standar , tal cual lo crea SQL_TRACE
Level 4 : Genera un Level 1 + información de las variables bind
Level 8 : Genera un Level 1 + información de los eventos de espera
Level 12 : Genera un Level 8 + información de las variables bind

El tema de los niveles hay que tomarlo con mucha calma, pues se puede generar muchísima información con un nivel 12, aunque muchísima de esa información es de un nivel muy bajo y nos puede dar pistas de lo que está sucediendo con una sentencia o un grupo de sentencias en partìcular.

¿Qué parámetros son necesarios para utilizar el Trace Event 10046?

Para que el Trace Event 10046 pueda ser utilizado de forma óptima, debiesen setearse los parámetros TIMED_STATISTICS en TRUE y tener especial cuidado en el parámetro MAX_DUMP_FILE_SIZE, pues este parámetro es el que controla el tamaño máximo de los archivos de trace.

¿Cómo usar este evento?
Pues existen muchas formas de utilizarlo, aquí mencionaremos la más sencilla y en posteriores post , indicaremos unas más avanzadas.

Para una sesión en partícular

SQL> alter session set timed_statistics = true;
SQL> alter session set max_dump_file_size = unlimited;
SQL> alter session set events '10046 trace name context forever, level 12';

REM Se ejecutan todos los scripts , consultas y programas habidos y por haber y se desactiva el Trace Event

SQL> alter session set events '10046 trace name context off';

Nota : Cabe mencionar lo potente y agresivo que es el nivel 12, se debe manejar con precaución.

Ejemplo práctico

SQL> conn / as sysdba
Connected.
SQL>
SQL>
SQL>
SQL>
SQL> alter system set timed_statistics=TRUE;
System altered.

SQL>
SQL> alter system set max_dump_file_size = unlimited;
System altered.

SQL> alter session set events '10046 trace name context forever, level 12';
Session altered.

Y si queremos ver como avanza nuestra trace , pues en otra pantalla de Sql*Plus, mostramos el contenido del parámetro user_dump_dest

SQL> show parameter user_dump

Nos vamos a ese directorio y al último trace generado , le colocamos un tail -f para apreciar la cantidad de información que genera.

Después de eso, en nuestra sesión traceada , ejecutamos algunos comandos

SQL> select * from v$instance;
SQL> create table ejemplo as select * from dba_objects;
SQL> drop table ejemplo;

Al archivo generado , le aplicamos tkprof

[oracle@oracle10g udump]$ tkprof orcl_ora_2238.trc salida.txt

Y ya tenemos , un archivo formateado , con absolutamente toda la información del proceso que acabamos de realizar

¿Qué información se visualiza?

La información que se muestra , es muy parecida al SQL_TRACE , pero mucho más potente , podríamos hablar entonces de un DON SQL_TRACE

********************************************************************************

select obj#,type#,ctime,mtime,stime,status,dataobj#,flags,oid$, spare1,
spare2
from
obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null
and linkname is null and subname is null

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 4 0.00 0.00 0 0 0 0
Execute 81 0.03 0.02 0 0 0 0
Fetch 81 0.03 0.11 7 237 0 75
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 166 0.06 0.14 7 237 0 75

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)

Rows Row Source Operation
------- ---------------------------------------------------
0 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=2 pr=0 pw=0 time=246 us)
0 INDEX RANGE SCAN I_OBJ2 (cr=2 pr=0 pw=0 time=234 us)(object id 37)

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 7 0.05 0.10

Referencias :
EVENT: 10046 "enable SQL statement tracing (including binds/waits)" [ID 21154.1]
Recommended Method for Obtaining 10046 trace for Tuning [ID 376442.1]

Espero les haya servido

PD : A quienes se pregunten , ¿que relación hay entre Darth Vader y el evento 10046? , en realidad ninguna.. pero se ve bien ..

sqlplus usuario/password@string_conexion @archivo.sql

3.- En el script va a aparecer una consulta con respecto al nombre del usuario

Ingrese usuario a crear con solo roles de lectura :

4.- Además aparece una pregunta si es VoC ,

V = Implica que se mostrará el comando (Visualizar)
C = Implica que se ejecutará el comando (Crear)

Desea visualizar o crear (V o C)? :

5.- Con lo anterior se crearán roles con el prefijo ROLSER_nombre_de_esquema

6.- Se creará el usuario con grant de connect y se le asignarán todos los roles generados

En resumidas cuentas, un comando , para esa ingrata tarea ... de enrolar

Espero les sirva

SQL> r
1 select to_char(BEGIN_TIME,'dd-mm-yyyy hh24:mi:ss') "Fecha Inicio" ,
2 to_char(END_TIME,'dd-mm-yyyy hh24:mi:ss') "Fecha Termino" ,
3 INTSIZE_CSEC ,
4 GROUP_ID ,
5 METRIC_ID ,
6 METRIC_NAME ,
7 VALUE ,
8 METRIC_UNIT
9 from v$sysmetric
10* where metric_name like '%Buffer Cache Hit Ratio%'

Y podríamos recopilar información como la que sigue

Fecha Inicio Fecha Termino INTSIZE_CSEC GROUP_ID METRIC_ID METRIC_NAME VALUE METRIC_UNIT
------------------- ------------------- ------------ ---------- ---------- ------------------------- ------- ----------------------------------------
11-11-2009 20:11:15 11-11-2009 20:12:15 6000 2 2000 Buffer Cache Hit Ratio 100.00 % (LogRead - PhyRead)/LogRead
11-11-2009 20:12:45 11-11-2009 20:13:00 1500 3 2000 Buffer Cache Hit Ratio 100.00 % (LogRead - PhyRead)/LogRead

El problema principal (si se le puede llamar problema) es que sólo muestra 2 puntos y con eso, claramente no sabremos la tendencia de nuestra base de datos , por ende necesitamos más puntos, ¿de dónde obtenerlos?, pues del historial de esa vista , la V$SYSMETRIC_HISTORY

1 select to_char(BEGIN_TIME,'dd-mm-yyyy hh24:mi:ss') "Fecha Inicio" ,
2 to_char(END_TIME,'dd-mm-yyyy hh24:mi:ss') "Fecha Termino" ,
3 INTSIZE_CSEC ,
4 GROUP_ID ,
5 METRIC_ID ,
6 METRIC_NAME ,
7 VALUE ,
8 METRIC_UNIT
9 from v$sysmetric_history
10 where metric_name like '%Buffer Cache Hit Ratio%'
11* order by 1

Acá nos muestra la última hora de las métricas que necesitamos visualizar , lo cual ya se puede sentir como algo más elaborado , o sea, "les presentamos el comportamiento del Database Buffer Cache durante la última hora" , suena bien , está vista nos entrega información de la última hora con un total de registros de 74

Y si queremos tener una curva algo más prolongada, quizás, el último mes del Database Buffer Cache, pues allí debemos consultar la vista DBA_HIST_SYSMETRIC_HISTORY

La información viaja así ...... después de una hora en memoria en las vistas V$SYSMETRIC y V$SYSMETRIC_HISTORY , el proceso Background MMON descarga la información de estás vistas al diccionario de datos , esa información la encontramos en la vista DBA_HIST_SYSMETRIC_HISTORY

Si piensan un poco , lo anterior es lo que sucede cuando el MMON captura la información estadística desde la SGA , o sea, son los Snapshots del AWR , entre más Snapshots existan , la curva puede ser más amplia cuando analicemos información estadística, que interesante!!!

La forma en que pueden realizar los gráficos mediante la información proveniente de estas tablas, la pueden encontrar muy detallada, paso a paso en el siguiente artículo

Graficar en Excel información proveniente desde Statspack

Hay que extrapolar un poco , la información en este caso no viene del Statspack , proviene de las vistas de Oracle, pero para el caso, es aplicable 500%

¿Qué otra información es útil como métrica?

La verdad muchas otras, como por ejemplo

* CPU Usage Per Sec
* Disk Sort Per Sec
* Host CPU Utilization (%)
* Leaf Node Splits Per Sec
* Library Cache Hit Ratio
* Memory Sorts Ratio
* PGA Cache Hit %
* Physical Reads Per Sec
* Redo Generated Per Sec
* Soft Parse Ratio
* Etc,etc.

La información está , es llegar y graficar

Mayor descripción de la vista V$SYSMETRIC

De la vista V$SYSMETRIC_HISTORY

Y de la vista DBA_HIST_SYSMETRIC_HISTORY

Espero que les sirva

RMAN> catalog backuppiece '/respaldo/oracle/backupset_32181818_1.bkp';

cataloged backuppiece
backup piece handle=/respaldo/oracle/backupset_32181818_1.bkp recid=12469 stamp=707174130

RMAN>

Y procedemos a restaurar

RMAN> restore archivelog logseq=39753;

Starting restore at 01-JAN-10
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1

channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=39753
channel ORA_DISK_1: reading from backup piece /respaldo/oracle/backupset_32181818_1.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/respaldo/oracle/backupset_32181818_1.bkp tag=TAG20091210T025643
channel ORA_DISK_1: restore complete, elapsed time: 00:02:35
Finished restore at 01-JAN-10

RMAN>

Pero figura como channel ORA_DISK_1: starting archive log restore to default destination

¿Qué significa eso? , pues sencillamente que restaura a una posición por defecto que para nuestro caso es la FRA que se encuentra en ASM

¿Cómo averiguamos donde quedo?, pues ejecutando la misma restauración

RMAN> restore archivelog logseq=39753;

Starting restore at 01-JAN-10
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1

archive log thread 1 sequence 39753 is already on disk as file +DATA/instance1/archivelog/2010_01_01/thread_1_seq_39753.687.707174297
restore not done; all files readonly, offline, or already restored
Finished restore at 01-JAN-10

Ahora nos vemos enfrentados al hecho de sacar el archivelog desde la FRA, eso se hace mediante los siguientes comandos

RMAN> copy archivelog '+DATA/instance1/archivelog/2010_01_01/thread_1_seq_39753.687.707174297' to '/respaldo/oracle/logminer/archive_39753.arc';

Starting backup at 01-JAN-10
released channel: ORA_SBT_TAPE_1
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive copy
input archive log thread=1 sequence=39753 recid=157342 stamp=707174445
output filename=/respaldo/oracle/logminer/archive_39753.arc recid=157343 stamp=707176036
channel ORA_DISK_1: archivelog copy complete, elapsed time: 00:00:09
Finished backup at 01-JAN-10

RMAN>

Después de eso, simplemente borramos el archivelog que dejamos en la FRA

RMAN> delete archivelog '+DATA/instance1/archivelog/2010_01_01/thread_1_seq_39753.687.707174297';

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=521 instance=instance1 devtype=DISK

List of Archived Log Copies
Key Thrd Seq S Low Time Name
------- ---- ------- - --------- ----
157342 1 39753 A 09-DEC-09 +DATA/instance1/archivelog/2010_01_01/thread_1_seq_39753.687.707174297

Do you really want to delete the above objects (enter YES or NO)? YES
deleted archive log
archive log filename=+DATA/instance1/archivelog/2010_01_01/thread_1_seq_39753.687.707174297 recid=157342 stamp=707174445
Deleted 1 objects

RMAN>

Después de eso, podemos aplicar logminer sobre los archivelogs que se encuentran en sistema operativo

Como resumen , lo más interesante es el uso del comando COPY en RMAN, con lo cual podemos sacar los archivelogs desde la FRA en ASM hacía disco.