ORA-01034 Y ORA-27101 por registro del LISTENER

Un cliente me dice que no se puede conectar a la base de datos, y lo que le sale es:

oracle 42> sqlplus pepe@bbdd1

SQL*Plus: Release 10.2.0.4.0 - Production on Tue Feb 2 15:18:02 2010

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Enter password:

ERROR:

ORA-01034: ORACLE not available

ORA-27101: shared memory realm does not exist

HPUX-ia64 Error: 2: No such file or directory

Lo primero que piensas es que el fichero $ORACLE_HOME/bin/oracle puede que no tenga los permisos adecuados. Después de verificarlo como estás en HP-UX piensas en IPC y verificas que el directorio /var/tmp/.oracle tiene los permisos adecuados. Vas a revisar también que segmentos de memoria compartida pueden estar bloqueando algo (ipcs –m). Lo siguiente es revisar el LISTENER, y tanto el SID_NAME como el ORACLE_HOME están bien. Bueno lo que siempre dice Oracle es que debes revisar el LISTENER. Bajar y subir el LISTENER no es suficiente, ver que tu fichero tnsnames.ora también está bien tampoco.

Puede llegar a ser un tontería como la siguiente, y es que cuando pasas de 9i a 10g hay pequeño cambio. El caso es que en 9i con levantar el LISTENER aunque que sea no el de por defecto, el puede realizar la conexión si tienes el ORACLE_HOME y el SID_NAME bien, mientras que en la 10g no. Entonces olvidar poner el parámetro LOCAL_LISTENER y crear la entrada en el fichero TNSNAMES.ORA puede ser el problema.

Aunque ejecutando " lsnrctl services list_X" aparece en las 2 versiones como estado UNKNOWN en la 9i si que puedes conectarte. En teoría el PMON se encargaría de registrar la base de datos en el LISTENER que aparece en el LOCAL_LISTENER, y cuando se tiene LISTENER que no es de por defecto, y si no estoy mal, el PMON también hace 2 búsquedas, la primera es que se llame "LISTENER" (por defecto) y la segunda buscar un "LISTENER_xxx". Lo que significa que cuando encuentra el segundo tipo de entrada es decir la palabra listener y algo más, verifica si está en la dirección local TCP/IP en el puerto 1521, y si todo se cumple lo registra. Esto si no hay un valor en LOCAL_LISTENER, si existe ese valor pues lo registra en el nombre de la entrada en el tnsnames.ora que le asignes.

Entonces conclusión, si te aparecen estos errores, puede ser simplemente porque no tengas LOCAL_LISTENER.

Espero que no pierdan tanto tiempo como yo, intentando encontrar algo más raro o complicado.

Tablas con FULL SCAN en la Buffer Cache

Feliz 2010 a los posible lectores :D

La verdad este año tengo el propósito de escribir un poco más a menudo (Siempre digo lo mismo, jejeje). Bueno, empiezo con algo muy rapidito. Buscando y buscando y buscando en google, encontré la descripción de la columna flag.x$bh. Interesante, y encontré que:

FLAG
KCBBHFSQ 0x80000 sequential scan only flag

KCB = Kernel Cache Buffer.

El objetivo es conocer todos los objetos que están en la buffer cache que se suben de forma secuencial, esto "PUEDE" implicar que si son tablas, se un FULL SCAN forma de acceso.
¿Para qué sirve?
Pues para conocer las POSIBLES tablas que están en la Buffer Cache con FULL SCAN, importante por temas de rendimiento y esas cosas :D. Por aquello de "menos CR mejor", aunque como todo "depende", pero en general o porque no, menos I/O mejor.

¿Cómo puedo entonces sacar la lista de esas tablas?
Aquí está una consulta, ya después es a gusto del consumidor lo que hagan con ella. Yo excluyo los las tablas de los objetos, propios de algunos componentes de Oracle.

SELECT distinct o.owner,o.object_name,o.object_type,o.owner
FROM dba_objects o,x$bh x
WHERE x.obj=o.object_id
AND o.object_type='TABLE'
AND standard.bitand(x.flag,524288)>0
AND o.owner not in ('SYS','PATROL','FLASHBACKSTATS','INVENTORY', 'SCOTT'
,'OUTLN','TSMSYS','EXFSYS','SYSMAN','SYSTEM', 'MDSYS', 'DMSYS', 'CTXSYS'
,'DBSNMP','WMSYS','SMSEXP', 'ORDPLUGINS', 'ORDSYS', 'PUBLIC', 'OLAPSYS');

El 524288 es el decimal del hexadecimal 80000, por tanto, la columna FLAG contiene muchísima información. Hasta la 9i se de 38 datos sobre el estado del bloque en la buffer cache.

Nota:
Según un compi mío, del cual no quiero dar el nombre porque se cabrea :). Él me dijo que si la cantidad de bloques de la consulta son mayores que el 10% del tamaño de la buffer cache (se puede contralar por parámetro oculto, creo) entonces Oracle protege la SGA y no va a memoria esta cantidad de bloques sino directamente a la UGA. Así bien para server processes dedicados, sería su PGA, pero cuando usan Shared Server, en teoría debería ir a la Large Pool, pero esto todavía lo tendría que confirmar :), si alguien ya lo ha probado me gustaría verlo.

Esta bien esta utilidad (mopatch)

Hola de nuevo. Voy a empezar a escribir más seguido, con cosas sencillas y aunque no me parezcan muy interesantes, pero que igual se que pueden servir a quien posiblemente lea, o busque en este información.
Un cliente con el que trabajo tiene SAP. El caso es que estaba instalando el software de Oracle que va a usar SAP, y me encontré con algo bastante curioso.
MOPatch, que es un shell script muy sencillo, que lo puedes bajar desde Metalink, y que te ahorra tiempo en la “tediosa” instalación de los interim patchsets.
Este MOPatch NO SIRVE PARA CPU (Critical Patch Updates). De todos modos, no veo necesario usa MOPatch para los CPU. Los CPU son muy cómodos por la forma de usar las moléculas, que me parece muy interesantes. Pero sigamos con MOPatch.
Mi historia. Tengo 48 iterim_patch que instalar, lo puedo hacer por la forma tradicional del optach:

$> cd {PATCHSET_SPACE}
$> unzip p_{PATCHSET_NUMBER}_{RELEASE}.zip
$> cd {PATCHSET_NUMBER}
$> optach apply

Y empieza, tarda un rato y acaba. Imaginen hacerlo 48 veces. Puff, mucho tiempo consumido, para esta labor. Encontré que los buenos de SAP (Notas de SAP) junto con Oracle crearon este shell script, para hacerlo más fácil. Ello tiene controlados, todos los interim_patchset que necesita cada versión de Oracle, para que su producto no tenga problemas. Problemas que tienen detectados, y que te dan ya desde su página un ZIP, para que lo descargues. Además este “shell script” te “ayuda” con el tema del espacio que consumes. Así que si tienes una instalación por hacer, y en tu empresa tienen por norma no copiar el software de Oracle y recompilarlo. Este es un modo que te ayuda un poco en el tiempo, y además en la tarea de instalar un mundo de parches.
La nota de Metalink donde te puedes descargar este script es:

Doc Id. 814845.1
Patching of Oracle Databases and Real Application Clusters with Shared Oracle Homes using EM Deployment procedures integrated with MOPatch

Es muy fácil de usar, tienes que dejar en el zip mopatch-1_9.zip en el $ORACLE_HOME. Después lo descomprimes. El te crea el directorio $ORACLE_HOME/MOPatch. En ese directorio te deja dos ficheros:

mopatch.sh
readme.txt

Y bueno, si quieres te lees el readme.txt porque tiene muchas opciones. Pero los pasos son:

• Ir al directorio donde están todos los parches comprimidos que bajaste de Metalink, En mi caso los que estaban en SAP de la versión 10.2.0.4.
• Y ejecutar :
$> $ORACLE_HOME/MOPatch/mopatch –v –s {PATCHSET_SPACE}

Cuenta cuantos patchsets va a instalar y te va diciendo si los ha instalado. Si falla por algún motivo, diferente a los que tiene controlados como que es un CPU, no sigue. Esto es lo único que no me pareció. Al final hace te crea un link.sh, que el mismo ejecuta, si todo va bien.
Yo sin embargo, después que aplico los parches, generalmente hago un:
$> $ORACLE_HOME/bin relink –all
Quiero recordar que si es AIX, hay que ejecutar anets como root slibclean.
Espero que usen esto y me digan si les ahorra o no tiempo.

Ellas no tienen la culpa...

Buenas,

He estado de vacaciones. Les recomiendo ir a visitar antes de morir, alguna isla griega, bueno, Grecia en general.
Estoy preparando otro examen de los de Oracle, pero no quiero dejar pasar la oportunidad de decirles algo, que he venido pensando desde hace tiempo, y que hoy quiero compartir. Si alguien leé este blog :).
Las bases de datos que administran, crean o afinan, no tienen que ser las afectadas directas de sus personalidades.
Si eres inteligente, tarado, amargado, alegre, egosita, generoso, petulante, humilde, etc. Como sea que seas. Las bases de datos, son las que se ven altamente perjudicadas por tu forma de se; si no tienes un método a seguir, en tu trabajo contidiano con ellas.
Si eres una persona descuidada, te dejaras cosas sin analizar, sin revisar. Si eres demasiado obstinado, te enfocas en un solo objetivo y no tendras una visión holística de esa bases de datos. Si eres charlatan, buscas cualquier excusa para decir que no es la base de datos, y que es la aplicación, el sistema operativo, la red, ó lo que sea. Si eres un holganzán, simplemente no investigas el error.
Todo esto, es una de las causas reales del mal funcionamiento de los sistemas, por tanto las bases de datos. Y además, porque también chocamos frontalmente y a diario con otras mentalidades ó personalidades, y como conclusión las grandes perjudicadas son ellas, las bases de datos.
Esto es matemática, es informática, y por tanto, una ciencia. No es en ningun momento un arte.
En una cadena de producción (gracias Ford), hay un tiempo en el que se hace cada labor. Así bien, debemos intentar llegar a un punto cercano.
Creo fielmente que debemos buscar ese objetivo, y no es más, que ser objetivos.
Cuando te piden resolver un problema matemático, simplemente buscas la fórmula que aplica, y lo intentas solucionar.
¿Quien no se queja de algunos médicos?
Pues esto, es algo parecido. Cuando vas al doctor, si el doctor de turno está de mal genio, ó el doctor de turno es una persona "demasiado alegre", ó no es objetivo. Probablemente no haga su labor, y esto lleva a tu enfado ó molestia, con la posibilidad que la enfermedad se agrave.
Este trabajo ó profesión, la informática, tiene mucho en común. Pero las que sufren son maquinas, y ellas no se quejan. Simplemente dejan de funcionar, ó tienen un rendimiento paupérrimo
Por favor, recuerden SIEMPRE una fórmula muy simple, pero bastante efectiva, de muchos documentos oficiales de Oracle:

Tiempo de respuesta = Tiempo de Servicio + Tiempo de espera

A diferencia de los médicos, aquí en las bases de datos 1 + 1, si que es igual a 2. Si haces un FULL SCAN, ó RANGE SCAN, ó UNIQUE INDEX, deberías saber cuantos bloques usas (No en todos los casos ;).
Si tarda 50 segundos en ejecutar una consulta, tarda eso 50 segundos. Son números. Para los médicos, 1 + 1 no son 2, así que ellos lo tienen más complicado, y su ciencia sigue en pie, creciendo, y en la que muchos confiamos.
Existen muchos documentos públicos y gratis, donde explican razonamientos metódicos de resolución de problemas. Ahora está de moda el troubleshooting. También bastantes documentos de tuning, algo que es bastante más complicado que el troubleshooting.
Espero algún día no muy lejano, sintetizar varios de los documentos de lo que les hablo y que he medio leído, y regalarlo. Si, regalarlo aquí, en este blog. Por si a alguien le sirve.
Así, si están de mal genio, si tienen hambre, si tienen frio, si están contentos, si están nerviosos. Estén como estén, sus bases de datos no sufren sus cambios temporales de humor, y tampoco de sus respectivas personalidades. Porque podrán seguir un guión, para cada una de las situaciones correspondientes a sus diversos problemas diarios con las bases de datos, no con sus vidas.
Personalmente intento a diario aplicarme este pensamiento. En ocasiones lo consigo, pero en muchas otras, me dejo llevar de mi pasión por mi profesión.

Tu, administrador, eres solo otro tipo de operador

Hablando con un buen administrador de Unix me comentó, en un día un poco aburrido para él, que iba a cambiar en su firma de “Administrador Unix” a “Operador nivel 2”, que al final muchas veces se siente que hace justo eso. Y me hizo pensar en escribir sobre esto, sobretodo por varios comentarios entre los diversos clientes en los que he estado, acerca del trabajo de los operadores. Sin ir más lejos, yo mismo, cuando me dijeron en un proyecto que las migraciones se llevaban con solo operadores, contratados para darle a al botón de “Press Button to Migrate” de una herramienta que migraba de 8i y 9i a 10g (Que realmente con ejecutar un par de comandos, mentira gorda), el caso es que yo mismo pensé “¿Un operador puede hacer eso? Vaya herramienta”. Al final creo que estaba siendo un poco despectivo con los operadores, y la verdad “Yo soy también un operador”.
Y esa es la cruel realidad, somos “operadores” de “alto” nivel, de herramientas como Unix, Oracle, Veritas, SAP, etc. Entonces al final, creo que muchos deberían replantearse el tratar despectivamente a los operadores y a los programadores, por que, los primeros son como nosotros pero con algo menos de conocimiento (algunos administradores ni eso). Y ellos, al igual que nosotros, cogen su “manual de operaciones” para resolver ciertas incidencia, y las incidencias que no se pueden apuntar en ese manual, son las hacemos nosotros.
Los administradores también tiene su “manual de operaciones”, y un ejemplo es el “SQL Reference” ó el manual del administrador ó el de “Tuning de Unix” ó el de “Backup & Recover Advance”, pero al final si la analizas bien, siguen siendo unos manuales de operaciones, más extensos, eso si. Y para bajarnos un poco más de la nube, los programadores si que son los importantes en todo esto, ya que sus programitas hacen que nuestra vida sea más o menos fácil. Si ellos se equivocan tenemos un “BUG” y a consultar parches, ó si ellos lo hacen bien y su analista también lo hace bien, pues tienes amplias opciones para configurar y optimizar una base de datos, un sistema operativo ú otro producto. Pero al final son ellos los buenos, así que replanteemos ¿Qué voy a hacer cuando un operador te llama a las 4 de la mañana a reportarte un problema que para ti no es problema? Pensar que no encontró la solución en “su manual” y que te llama por ese motivo, así como te puede pasar a ti, cuando los manuales súper avanzados, no te dan la respuesta.
Otro tema que está dentro de éste, es lo que Oracle llama DBA 2.0. Interesante, para los que no tienen idea de lo que es esto, pues simplemente como Oracle ya tiene un Oracle Linux Enterprise 4 y 5, como además tienes Clusterware y ASM, pues para ellos el administrador a “dado un paso adelante” en lo que es el ”todo” de los sistemas, porque estas incluyendo para los roles de un “ operador avanzado de Oracle” un sistema operativo, el almacenamiento y el clustering. Pero además te mete herramientas “avanzadas” de optimización, como son todos los “..ADVICE” (las vistas que terminan en eso), también tienes el replay (a partir de la 10.2.0.4), también tenemos el ADDM y todos los “automatic managemente” (UNDO, SGA, PGA, MEMORY) y que quede claro que no estoy en contra de estas opciones, de lo que estoy en contra es de no saber al final lo que realmente está pasando “dentro” de la base de datos. Y todo porque no te da tiempo a leer como montar ó como manejar en todo lo nuevo que están introduciendo Oracle.
Hace un tiempo le dije a un cliente que revisara el almacenamiento de una tabla, y me contesta que el “Segment Advisor” no le da ninguna recomendación, y que por eso no va a hacer nada, y me preguntó que más hacía con esa tabla. Y es esto, es precisamente a lo que me refiero, el DBA 2.0, sin querer te va a llevar hasta esta situación. Si damos un par de pasos atrás, ser OCP 8i era todo un reto, y ahora ser OCP 10g hasta hace poco no te exigían ni el examen de SQL (lo cambiaron en diciembre de 2008). Antes eran 5 exámenes, el de SQL, PL/SQL, Administración I y II, y tuning. Después quitaron la parte de PL/SQL, y por último pasaron a solo 2 exámenes (Primero OCA y después OCP), y es algo en lo que estoy de acuerdo, porque ASM, FLASHBACK, RMAN, Advisors, los nuevos tipos de segmentos, etc. es mucho material, pues si, si quieres saber que hay por dentro. Pero entonces con todo esto ¿Donde queda tu “control” o el control de lo que haces? La verdad, personalmente (y otros amigos también me lo comentan) prefiero al DBA 1.1 y si puede ser el DBA 0.7, ese que pasó de la versión 7.3.3 a la 8.1.4 y después se deslumbró con la 9.2.0.4. Prefiero a ese que sabía en la 9i como iban los rollback segments, ese que también conocía como tratar los diferentes parámetros para la PGA en dedicado (bitmap, sort, hash y merge), ese que hacia el examen de tuning.
Con la 10g, tienes un mundo inmenso por conocer, y es realmente impresionante todo lo nuevo que hay. Pero no le daría “tanta” importancia a las herramientas que te “facilitan” la vida. Le daría más importancia a saber ó intentar entender, que es lo que se cuece por dentro. Para realmente decirle a los clientes que es lo que realmente necesitan, y de acuerdo a cada situación implementar justo lo necesario. Si que hay muchas cosas que ver y conocer, es más, ejemplo clarísimo, sql_id, que para mi es un alivio, ver mis consultas completas (sql_fulltext.v$sqlstats), y que también puedo ver con las DBA_HIST_% (Es una licencia aparte en la 10g y en la 11g viene incluidas, según lo leído en otros blogs) información de varios días atrás para intuir algunos problemas.
En conclusión, los administradores no debemos ponernos muchas más medallas que los operadores, porque al final lo somos. Y además, creo que es bonito seguir intentando entender como va la LRU y la LRUW del buffer cache, saber como van los latch, mutex, enqueues, ó saber todos los parámetros que hay por ejemplo en el log_archive_dest_n ó como intentar hacer que una consulta tenga menos lecturas lógicas, prefiero estos antes que saber como sacar un reporte ADDM ó como se usa el DBMS_SQLTUNE. Que repito, está bien conocerlos y probarlos, pero no basar tu vida de operador nivel 2 en ellos.

Mas del 4031 y sub-pools

Se va a hacer de rogar el post de CPU Costing de Ricardo, pero es que tengo un pequeño detalle que intenté dejarle a un comentario a Tanel Poder del post que puso hace unos días, pero al final no pude. Así que primero, incentivarlos leer el blog de Tanel Poder que me parece genial, y decirles que allí hay un buen post sobre los errores 4031 y de la shared pool y los sub-pools en:

ORA-04031 errors and monitoring shared pool subpool memory utilization with sgastatx.sql

El caso es que se habla de una sub-pool 0, y que es memoria que no se le da al resto de las sub-pools de la shared pool. Bueno solo añadir que este espacio de memoria que describe Tanel en su blog no existe cuando está desactivado el manejo automático de memoria conocido como ASMM (Automatic Shared Memory Management), que pasa cuando tienes el parámetro SGA_TARGET a 0 ó el parametro STATISTICS_LEVEL en “BASIC”. Realicé una pequeña prueba y este fue el resultado:

El gran misterio del log_buffer

Buenas de nuevo, escribo algo muy sencillo, pero que he visto que está extendido en varias bases de datos que he tocado. Lo llamaré “El gran misterio log_buffer”. Y es que he visto en más de una ocasión que el valor de este parámetro está puesto a 10M y hasta 32M. Y me pregunto ¿Por qué y para qué?
He notado que algunos administradores tienden a aumentar el tamaño de este valor cada vez que aumentan el tamaño de su SGA, pero esto sin duda alguna, es una “mala” práctica, y ahora les explico porqué. Para ello primero me pregunto ¿Para que uso ese pedacito de memoria y como funciona? Cada vez que realizo hago cambios (Insert, Delete, Update, y más cosas) estos cambios se guardan en memoria temporalmente, justo ahí, en el redo log buffer, y el tamaño de este buffer lo determina el parámetro log_buffer. Si ocurren ciertos eventos, un proceso llamado Log Writer (LGWR) “escribe” la información que está en esa parte de la memoria a los Online Redo logs, mejor, realmente “vuelca” (flush en ingles) la información de memoria a disco, y reutiliza ese espacio. Con esto se esta intentando guardar la integridad de los datos y de la base de datos (a groso modo).
Pero ¿Cada cuanto vuelco esta información que está en la memoria a disco?
Existen varios eventos por los que se producen estas escrituras. Quien lo describe perfectamente es Tom Kyte en su libro “Expert Oracle database architecture” en la página 176, donde dice que estos eventos (LGWR despierta para trabajar) se ejecutan cada:

- Tres segundos
- “COMMIT” de cualquier transacción
- Cuando se llega a un tercio del tamaño del redo log buffer
- Cuando llega a 1M de información

También pueden encontrar esta información en METALINK en la nota “Tuning the Redolog Buffer Cache and Resolving Redo Latch Contention” con id 147471.1, ó también esto mismo lo podemos leer en el documento "Performance Tuning Guide " ya sea 9i ó 10g, en el capitulo de "Memory Configuration and Use" en la parte de "Configuring and using the Redo Log Buffer".

Entonces teniendo en cuenta que se va a realizar un volcado de esta información cada vez que llegue a 1M, ¿Por qué tengo 14M ó incluso 30M de redo log buffer? La verdad, no lo se y no lo entiendo, el caso es que he encontrado estos “detalles” en muchísimas bases de datos. Y los argumentos de algunos son : que es un OLTP (gran volumen de transacciones), o que su SGA es muy grande, y otra razón que también escucho es que como tienen muchas CPU pues deducen (ejemplo: 32*512K dan 16M de log_buffer) tal y como dice el DBA Reference. Pero realmente creo que muchos DBAs no ven normal que el resto de “pools” de la SGA vayan creciendo según la carga y/o el tipo de uso de la base de datos y que esta parte de la memoria no lo crezca también, y simplemente la aumentan por si acaso, creo.

Pero es cierto es una “mala” practica, sino pruébenlo, pasen de 14M (si lo tienen) a 3M, en sus base de datos (8i, 9i ó 10g), miren si el rendimiento de su base de datos decrece.
Realmente no importa mucho si tienes 32 Gigas de memoria y de SGA tienes 24. Al final lo único que estas haciendo es desperdiciar unos pocos megas, tal y como lo dice Tom.
Este pequeño espacio de memoria le viene muy bien a otras partes de la SGA, y no veo conveniente desperdiciar ni bloque del sistema para nada, solo por un mal mito repartido en muchos sitios.
Si después de esta prueba ven que el rendimiento decrece o es malo por este cambio, por favor envíenme la demostración "real" que estoy deseoso de verla, ya que confío y creo que esto no se produce.

Por cierto, si realmente consumen menos de 300K de información de redo por segundo (el dato aparece en los reportes AWR), no es necesario ni siquiera llegar hasta los 3M, con menos de esto valor nos vale (calcúlalo con lo antes explicado ;). Es poco común, pero este mundo es muy grande. Claro, que tampoco es correcto poner un valor muy pequeño, y ese es el momento donde posiblemente tengas algún problema, reduciéndolo demasiado.