ERROR EJECUTANDO SYSREV

ERROR EJECUTANDO SYSREV

Hola, esto es una problemilla simple y muy tonto que es cuando SYSRESV y aparece :

oracle@mybd:/home/oracle $ sysresv

/usr/lib/hpux64/dld.so: Unable to find library 'libclntsh.so.10.1'.

Killed

 

Y se arregla exportando las variables de entorno de las librerías de Oracle, por ejemplo para HP-UX viene a ser SHLIB_PATH, o en Linux LIBRARY_PATH con $ORACLE_HOME/lib, por ejemplo:

oracle@mybd:/home/oracle $ export SHLIB_PATH=$ORACLE_HOME/lib

oracle@mybd:/home/oracle $ sysresv

 

IPC Resources for ORACLE_SID "MYDB" :

Shared Memory:

ID KEY

21 0x7cdca070

Semaphores:

ID KEY

360486 0xe36a4220

Oracle Instance alive for sid " MYDB "

oracle@mybd:/home/oracle $

 

Particularmente uso SYSRESV para ver los "cachos" de memoria compartida de la que hace uso la SGA, y también de los semáforos. Otra opción es usa IPCS, pero este comando no te muestra el nombre de la instancia, y si tú maquina tiene más de una instancia, no lo sabes que es para quien. Con SYSRESV solo tienes que exportar el ORACLE_SID y te da la dirección de la memoria compartida y los semáforos de esa instancia solamente.

Si un SHUTDOWN ABORT no elimina la memoria compartida y tienes muchas instancias arriba, es otra opción de eliminar ese cacho de memoria.

Es BASTANTE improbable que falle un "SHUTDOWN ABORT", o que la maquina quede con cacho de memoria compartida con el nombre de la instancia, y que no desees hacer un ipcrm, y no sabes cual instancia es y no puedas bajar el resto de instancias, sino que solamente esa es la que es necesaria bajar. Pero si todas estas desgracias en cadena suceden una opción es SYSRESV.

 

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.