Archives for: December 2009
Oracle PTS : En un curso sobre buenas prácticas de 11gr2
La verdad , no soy muy amigo de criticar a diestra y siniestra , pero cuando las cosas no cumplen aunque sea un mínimo de eficiencia , la verdad ... hay que comentarlo
Ayer y hoy (14 y 15 de Diciembre) , estaré en una "clase magistral" sobre migración hacía 11gr2 , las buenas prácticas, o sea , era lo que yo esperaba , por fin alguién del HeadQuarters de Oracle me iba a dar una gran charla... ya que he hecho migraciones hacía 11gr2 y quiero saber los secretos

Lo que me encontré me decepciono...
Los porque....
1.- El instructor es una persona que no sabía lo que estaba hablando , incluso diciendo que el ASH servía para hacer los resize de memoria , en realidad el ASH no está relacionado con el ASMM (o sí?? jaja), técnicamente estaba en un nivel muy bajo , muy , muy bajo.
2.- No venía con una preparación y fue total y absoluta improvisación
3.- Yo ya lo había tenido de instructor , y fue tanta la desazón en ese momento , que me retire en medio de su charla, pues no puede decir que el CKPT es el que hace la encriptación de los datos en los datafiles, quizás no sabía que CKPT es Background Checkpoint y no tienen relación con la criptografía.
4.- Aunque no tenga experiencia, pero traté de pasar las PPT de una forma más amena,casi era como una carrera desenfrenada por llegar al último slide
Esta persona es de Oracle PTS con sede en Sao Paulo , Brasil , el principal objetivo de esta entidad es mantener al día y capacitar a los Partners de toda Latinoamerica, son 6 personas para todo el LAD , eso significa :
- Hotel
- Viajes
- charlas
- Conocer culturas y lugares
Y todo para que una persona que no sabe "casi" nada , traté de vendernos algo falso .. la verdad , es decepcionante
Amigo Oracle, asesorese mejor , no puede ser que este tipo de personas sean nuestras guías , es inverósimil , pierden credibilidad ante los ojos del público..
En todo caso... sigo con Oracle , muera Microsoft
Más información del Oracle PTS
QUIERO TRABAJAR EN ORACLE PTS !!!!

Espero les sirva...
![]()
![]()
15.12.09. 08:27:43. 374 words, 2341 views. Categories: Eventos Oracle , Leave a comment » • Send a trackback »
Oracle11gr1 y Oracle11gr2 : Ha ocurrido un error , ¿Dónde están los logs y traces?
Imagínense el siguiente error
[oracle@SQL]$ sqlplus usuario/password
SQL*Plus: Release 11.2.0.1.0 Production on Thu Dec 10 20:58:22 2009
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing optionsSQL> start file
select COUNT(*)
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 887
Session ID: 134 Serial number: 162SQL>

Tratamos de hacer un trace, se cae, tratamos de generar un evento de traceo , se cae y así , por siempre y para siempre..
Lo mejor es abrir un caso en Oracle, ellos debiesen solucionarlo
(no siempre es así, pero les tengo fé)
Y cuando vamos al ORACLE_BASE, nos damos cuenta
de que no existe, claro estamos en 11gr2 
Nos colocamos el machete en la boca y nos metemos a los directorios de log y trace (llamado diag) y nos encontramos con muchos de ellos
[oracle@SQL]$ ls -ltr
total 136
drwxr-x--- 2 oracle oinstall 4096 Nov 6 00:17 hm
drwxr-x--- 2 oracle oinstall 4096 Nov 6 00:17 alert
drwxr-x--- 2 oracle oinstall 4096 Dec 10 20:37 metadata
drwxr-x--- 2 oracle oinstall 4096 Dec 10 20:37 ir
drwxr-x--- 4 oracle oinstall 4096 Dec 10 20:58 incident
drwxr-x--- 8 oracle oinstall 12288 Dec 10 20:58 cdump
drwxr-x--- 2 oracle oinstall 4096 Dec 10 20:58 sweep
drwxr-x--- 2 oracle oinstall 20480 Dec 10 20:58 stage
drwxr-x--- 2 oracle oinstall 4096 Dec 10 20:58 lck
drwxr-x--- 4 oracle oinstall 4096 Dec 10 21:09 incpkg
drwxr-x--- 4 oracle oinstall 69632 Dec 10 21:20 trace
[oracle@SQL]$ pwd
/u01/app/oracle/diag/rdbms/inst1/inst1
[oracle@SQL]$
Es ahora donde nos entra la desesperación y nos preguntamos ¿Qué #$"°| le envíamos a Oracle?
Pues bien , allí es donde ingresa el ADRCI, el utilitario para hacernos la vida más fácil con la nueva estructura de diagnóstico que nos provee Oracle
He aquí un pequeño ejercicio
1.- Nos conectamos al adrci
[oracle@SQL]$ adrci
ADRCI: Release 11.2.0.1.0 - Production on Thu Dec 10 21:03:05 2009
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
ADR base = "/u01/app/oracle"
adrci>
2.- Verificamos los ORACLE_HOME existente (son mas de 1 ya que estamos trabajando con el DIAG)
adrci> show homes
ADR Homes:
diag/tnslsnr/maq1/listener
diag/rdbms/inst1/inst1
adrci>
3.- Para poder trabajar con el adrci, se debe por obligación seleccionar uno de estos ORACLE HOMES
adrci> set homepath diag/rdbms/inst1/inst1
adrci>
adrci> show homes
ADR Homes:
diag/rdbms/inst1/inst1
adrci>
4.- Una vez seleccionado nuestro ORACLE_HOME, procedemos a ver los "problemas" e "incidentes"
Sólo como introducción , pues generaré un post al respecto, un problema genera múltiples incidentes y un problema es casi siempre crítico, o sea, solucionando el problema se acaban los incidentes (suena a ITIL
)
adrci> show problem
ADR Home = /u01/app/oracle/diag/rdbms/inst1/inst1:
*************************************************************************
PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME
-------------------- ----------------------------------------------------------- -------------------- ----------------------------------------
1 ORA 7445 [_intel_fast_memcmp()+30] 275 2009-12-10 20:58:26.261000 -03:00
1 rows fetched
5.- Aparece claramente el problema, un error ORA-07445, ahora queremos ver los incidentes que ha originado ese problema
adrci> show incident
ADR Home = /u01/app/oracle/diag/rdbms/inst1/inst1:
*************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
-------------------- ----------------------------------------------------------- ----------------------------------------
251 ORA 7445 [_intel_fast_memcmp()+30] 2009-12-10 20:41:07.496000 -03:00
275 ORA 7445 [_intel_fast_memcmp()+30] 2009-12-10 20:58:26.261000 -03:00
2 rows fetchedadrci>
Como se puede apreciar, ha generado varios incidentes , pero sólo necesitamos uno de ellos como para comenzar a procesar la información y poder "empaquetar" todos los archivos necesarios.
6.- Para ello , tomamos el INCIDENT_ID que necesitamos y ejecutamos el siguiente comando
adrci> ips pack incident 275 in /home/oracle
Generated package 2 in file /home/oracle/ORA7445_i_20091210210936_COM_1.zip, mode complete
adrci>
7.- Una vez ejecutado el comando , tenemos un zip con TODA LA INFORMACIÓN necesaria para soporte Oracle y casi ... no nos despeinamos ![]()
Más información del ADRCI
Espero les sirva...
![]()
![]()
14.12.09. 07:39:59. 610 words, 5724 views. Categories: Oracle 11g, Tuning / Performance, Oracle11gR2 , Leave a comment » • Send a trackback »
Strace : Comando para hacer debug a bajo nivel en Linux...
strace es un utilitario que sirve para hacer un trace a un comando en partícular, suena sencillo... pero es un potente amigo
Disponible en ambientes Linux, es una gran herramienta para buscar el porque algún comando en partícular falla.
Cada vez que strace ejecuta algún comando , puede registrar todos los archivos utilizados y el comando ejecutado en un stack, el cual puede ser ubicado en un archivo de salida.

Para generar cualquier salida con strace lo ejecutamos de la siguiente forma.
Eje:
[oracle@oracle10g oracle]$ strace -o salida.txt lsnrctl start LISTENR
[oracle@oracle10g oracle]$ ls -ltr salida.txt
-rw-r--r-- 1 oracle oinstall 65910 Dec 6 09:26 salida.txt
Cada vez que sucede un error casi siempre aparece un -1 con la descripción del error dentro del archivo generado en el punto anterior.
Eje:
2236 stat64("/u01/app/oracle/product/10.1.0/db_1/lib/tls", 0xbfff8bf0) = -1 ENOENT (No such file or directory)
Incluso se le puede agregar la fecha del día a cada línea de salida de strace
Eje:
strace -t -o salida.txt lsnrctl start LISTENR
more salida.txt
09:29:54 execve("/u01/app/oracle/product/10.1.0/db_1/bin/lsnrctl", ["lsnrctl", "start", "LISTENR"], [/* 29 vars */]) = 0
09:29:54 uname({sys="Linux", node="oracle10g.inmotion.cl", ...}) = 0
09:29:54 brk(0) = 0x8f75000
Incluso con microsegundos
Eje:
[oracle@oracle10g oracle]$ strace -tt -o salida.txt lsnrctl start LISTENR
[oracle@oracle10g oracle]$ more salida.txt
09:30:46.284985 execve("/u01/app/oracle/product/10.1.0/db_1/bin/lsnrctl", ["lsnrctl", "start", "LISTENR"], [/* 29 vars */]) = 0
09:30:46.286140 uname({sys="Linux", node="oracle10g.inmotion.cl", ...}) = 0
09:30:46.286579 brk(0) = 0x928d000
Si se quiere saber en microsegundos la duración de cada proceso interno ejecutado por el strace (según el comando ingresado)
Eje:
[oracle@oracle10g oracle]$ strace -tt -T -o salida.txt lsnrctl start LISTENR
09:31:36.680126 execve("/u01/app/oracle/product/10.1.0/db_1/bin/lsnrctl", ["lsnrctl", "start", "LISTENR"], [/* 29 vars */]) = 0 <0.000425>
09:31:36.681208 uname({sys="Linux", node="oracle10g.inmotion.cl", ...}) = 0 <0.000073>
09:31:36.681608 brk(0) = 0x9b6e000 <0.000072>
Incluso se puede fitrar por tipo de ejecución del comando ejecutado por el strace
Eje:
Para saber sólo los comandos asociados a la red
strace -tt -T -e trace=network -o salida.txt lsnrctl start LISTENR
Para saber sólo los comando ejecutados, pero que reciban como parámetro un archivo
Eje:
strace -tt -T -e trace=file -o salida.txt lsnrctl start LISTENR
Incluso se le puede indicar algún PID de sistema operativo que ya se encuentre en ejecución
Eje:
strace -tt -T -p 18909 -o salida.txt lsnrctl start LISTENR
Espero les sirva
![]()
![]()
10.12.09. 07:30:08. 414 words, 5141 views. Categories: Base de datos, Tuning / Performance, Linux , Leave a comment » • Send a trackback »
Oracle10gr2 : Disminuyendo el LOG FILE SYNC con COMMIT NOWAIT
Para comenzar la charla , les pido disculpas por el tiempo alejado de las canchas, pero fue única y exclusivamente por la carga de trabajo que tenía en mi empresa, de hecho hoy en día me encuentro dictando dos cursos por día :
- Horario de tarde : WorkShop II Ed 3 de Oracle10g
- Horario de noche : Oracle Reports Builder 11g
Así que imagínense el tiempo que tengo, pero bueno... a lo que vinimos...

El evento de espera LOG FILE SYNC se da cuando una sesión de usuario ejecuta un final de transacción por ejemplo un COMMIT o un ROLLBACK , la información almacenada en el Log Buffer para esa transacción necesita ser envíada a disco , especificamente a los archivos de redolog, cuando está finaliza , la sesión recién comienza a generar otras actividades, en otras palabras, cuando se ejecuta un término de transacción la sesión entra en un evento de espera, que está relacionado al tiempo que demora el LGWR en escribir las entradas del log buffer (en realidad son vectores, pero es materia de otro Post) hacía los redologs, cuando eso finaliza .. la transacción se acepta como válida.
A veces , cuando la aplicación es muy transaccional , el LOG FILE SYNC , aparece como un Top 5 dentro del Statspack o dentro un AWR Rpt, cuando sucede eso, hay formas de mejorar esos tiempos de respuesta.
Observación : No se recomienda llevar a cabo estos cambios sin la visación de Oracle Support
Ejecución de commit asincrónico
Como ya vimos el proceso del commit y como se vaciaban los registros desde el Log Buffer , pasamos a señalar el como ejecutar el commit asincrónico para solucionar el evento de espera LOG FILE SYNC
El comando commit posee variaciones , las cuales se pueden apreciar en el siguiente detalle
WAIT : No se retorna el mensaje de commit exitoso hasta que las entradas del LogBuffer hayan sido escritas a los redo logs
NOWAIT : El commit puede retornar el control a la aplicación aunque aún la sentencia no este registrada a los archivos de redologs, lo cual puede resultar algo peligroso.
IMMEDIATE : El proceso LGWR escribe de forma inmediata la entrada de la transacción presente en los log buffer hacía los redo logs, en otras palabras , se fuerza un I/O
BATCH : Este modo le indica a Oracle que a pesar de haber finalizado la transacción con un commit, la bajada de los vectores desde el log buffer se produzca en el ciclo normal del log buffer , por ejemplo , cuando se llena a un tercio
Por defecto , cuando ustedes ejecutan el commit se ejecuta con WAIT IMMEDIATE , pero esto se puede modificar ejecutando la siguiente sentencia
COMMIT WRITE NOWAIT IMMEDIATE , o sea, no espera a que se escriba la información del log buffer a los redo logs, entrega el control a la aplicación y hace la bajada de la información del log buffer de forma inmediata a los redo logs
Es una opción que hay que manejar con cuidado , pues puede haber pérdida de datos , por ejemplo este comando
COMMIT WRITE NOWAIT BATCH , puede dejar mucha información en memoria , indicarles que se hizo el commit exitoso y ante una caída quedar con información inconsistente.
Todo lo anterior también se puede setear mediante el parámetro de incialización correspondiente
COMMIT_WRITE
Y analizando toda esta información , para solucionar en parte el evento de espera LOG FILE SYNC , se podría cambiar el modo del commit para los procesos batch de la siguiente forma
COMMIT WRITE NOWAIT BATCH
Espero que les haya servido
Documentación necesaria
Parámetro COMMIT_WRITE
Evento de espera LOG FILE SYNC
![]()
![]()
02.12.09. 13:23:18. 632 words, 1876 views. Categories: Oracle 11g, Oracle 10g, SQL / Programación, Tuning / Performance , Leave a comment » • Send a trackback »