Oracle y yo

$ getconf -a | grep KERN

64bits : KERNEL_BITMODE: 64
32bits : KERNEL_BITMODE: 32

También puede ser utilizado el comando

$ file /usr/lib/boot/unix*

64bits : 64-bit XCOFF executable or object module not stripped
32bits : executable (RISC System/6000) or object module not stripped

En HP-UX

/usr/bin/ getconf KERNEL_BITS

Otro comando a utilizar

/usr/bin/file /stand/vmunix

64bits : stand/vmunix: ELF-64 executable object file - PA-RISC 2.0 (LP64)
32bits : /stand/vmunix: PA-RISC1.1 executable -not stripped

En Solaris

/usr/bin/isainfo -v
/usr/bin/isainfo -kv

64bits : 64-bit sparcv9 applications
32bits : sparc application

En Linux

getconf LONG_BIT

o se puede ejecutar el comando

uname -a

64bits : x86_64
64bits : ia64

Sino, indica 32 bits

En Windows (Wintendo)

Type "dxdiag" on the Start -> Run

Como todo tiene un orígen , he acá la nota de Oracle

How to Determine Whether the OS is 32-bit or 64-bit [ID 421453.1]

/ ORACLE vs. Oracle
/ -----------------
/ The word ORACLE in uppercase refers to the ORACLE server. Use the term
/ "ORACLE server" when referring to the server.
/
/ The word Oracle in lowercase with capitalized first letter refers to the
/ company. Use "Oracle Corp." when referring to the company.

O sea, cuando hablemos de base de datos , será ORACLE, cuando hablemos de la empresa será Oracle

¿no seremos demasiado cuadrado?

Para que lo tengan en cuenta, el archivo oraus.msg se guardan entre otras cosas los mensajes de error para los códigos ORA-

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 ..