Monitorizar el alert.log desde una sql remota

El fichero de alertas de oracle alert.log es uno de los ficheros que tradicionalmente revisamos en busca de errores de la base de datos.
Hasta la versión 11g esta monitorización se hacía por medio del scripts que interactuaban con ficheros del sistema operativo, lo que nos llevaba a tener que mantener estos scripts para las distintas versiones de shells de sistema, o tener que instalar algún tipo de interprete en el sistema que nos lo gestionara de manera multiplataforma.

Una de las grandes ventajas de la 11g es que Oracle nos ha obsequiado con una tabla de base de datos que mapea esta información del alert.log dentro de la base de datos . Estamos hablando de la tabla x$dbgalertext;

Mediante la tabla x$dbgalertext podemos obtener toda la informacion que está en el alert.log, su contenido es:

SQL> desc X$DBGALERTEXT

           Name                            Null?    Type
           ------------------------------- -------- -------------------------
    1      ADDR                                     RAW(4)
    2      INDX                                     NUMBER
    3      INST_ID                                  NUMBER
    4      ORIGINATING_TIMESTAMP                    TIMESTAMP(3) WITH TIME ZONE
    5      NORMALIZED_TIMESTAMP                     TIMESTAMP(3) WITH TIME ZONE
    6      ORGANIZATION_ID                          VARCHAR2(64)
    7      COMPONENT_ID                             VARCHAR2(64)
    8      HOST_ID                                  VARCHAR2(64)
    9      HOST_ADDRESS                             VARCHAR2(16)
   10      MESSAGE_TYPE                             NUMBER
   11      MESSAGE_LEVEL                            NUMBER
   12      MESSAGE_ID                               VARCHAR2(64)
   13      MESSAGE_GROUP                            VARCHAR2(64)
   14      CLIENT_ID                                VARCHAR2(64)
   15      MODULE_ID                                VARCHAR2(64)
   16      PROCESS_ID                               VARCHAR2(32)
   17      THREAD_ID                                VARCHAR2(64)
   18      USER_ID                                  VARCHAR2(64)
   19      INSTANCE_ID                              VARCHAR2(64)
   20      DETAILED_LOCATION                        VARCHAR2(160)
   21      PROBLEM_KEY                              VARCHAR2(64)
   22      UPSTREAM_COMP_ID                         VARCHAR2(100)
   23      DOWNSTREAM_COMP_ID                       VARCHAR2(100)
   24      EXECUTION_CONTEXT_ID                     VARCHAR2(100)
   25      EXECUTION_CONTEXT_SEQUENCE               NUMBER
   26      ERROR_INSTANCE_ID                        NUMBER
   27      ERROR_INSTANCE_SEQUENCE                  NUMBER
   28      VERSION                                  NUMBER
   29      MESSAGE_TEXT                             VARCHAR2(2048)
   30      MESSAGE_ARGUMENTS                        VARCHAR2(128)
   31      SUPPLEMENTAL_ATTRIBUTES                  VARCHAR2(128)
   32      SUPPLEMENTAL_DETAILS                     VARCHAR2(128)
   33      PARTITION                                NUMBER
   34      RECORD_ID                                NUMBER

Ahora bien, ¿como accedemos a ella?

La tabla no puede ser accedida directamente desde un usuario que no sea sys, así que, lo que haremos será el crear una vista sobre esta tabla (a la que llamaremos por ejemplo ficheroalert ) y permitirle que lo vea a nuestro usuario de monitorizacion.


create view ficheroalert as select  * from sys.x$dbgalertext;
grant select on sys.ficheroalert to MONITORIZACION;

A partir de aquí, solamente tenemos que jugar con los campos descritos arriba y podremos obtener la informacion que deseemos.
En mi caso , por ejemplo, me gustaría saber si ha habido algún mensaje ORA- o ERROR en los ultimos 5 munitos.

La consulta que ejecutaré para obtenerlo es:


select to_char(ORIGINATING_TIMESTAMP, 'dd-mon-yyyy hh24:mi:ss'),
      substr(MESSAGE_TEXT, 1, 300) message_text
    from sys.ficheroalert
    where (MESSAGE_TEXT like '%ORA-%'
            or upper(MESSAGE_TEXT) like '%ERROR%')
     and 
           cast(ORIGINATING_TIMESTAMP as DATE) > sysdate - 5/1440;
            - X/1440 es la X en minutos 

Entrada en ingles en Monitoring the alert.log from a remote sql

Funcionamiento de las variables NLS

Hoy vamos a ver una de las cosas mas simples que hay en Oracle y de las que mas quebraderos de cabeza traen, la globalizacion.

Las variables que definen el idioma, numeros,fechas, ordenacion… de Oracle son las llamadas variables de globalización de Oracle o  mas comumente parámetros NLS.

Para evitar problemas con los acentos, eñes, puntos/comas,fechas…. deberias de tener claro cual es el NLS_LANG que tienes/quieres . Pero vamos a dejar este NLS_LANG para un poco mas adelante

Las principales variables para un entorno de oracle son:
•    NLS_LANGUAJE: Se usa para los mensajes (incluidos los de error)
•    NLS_DATE_LANGUAJE: Para los nombres de día y mes
•    NLS_SORT: (Binary) para la ordenación lingüística
Adicionalmente, tenemos una variable de entorno que nos define un amplio número de variables , este prámetro es NLS_TERRITORY , esta variable define las  siguientes subvariables
•    NLS_CURRENCY
•    NLS_DUAL_CURRENCY
•    NLS_ISO_CURRENCY
•    NLS_DATE_FORMAT
•    NLS_NUMERICA_CHARACTERS
•    NLS_TIMESTAMP_FORMAT
•    NLS_TIMESTAMP_TZ_FORMAT

Una vez visto esto, volvemos a NLS_LANG que se define como:
NLS_LANG=<language>_<territory>.<character set>  (por ejemplo export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 o en español  export NLS_LANG=SPANISH_SPAIN.WE8MSWIN1252 )
Así pues, si definimos correctamente nuestra variable NLS_LANG tendremos practicamente todas las variables de entorno definidas y conseguiremos que nuestras consultas tengan los caracteres que queremos.

Las variables de globalización de una base de datos se pueden fijar a 5 niveles:

  • Database
  • Instancia
  • Cliente
  • Sesión
  • Sentencia

Cada nivel inferior anula a un superior, es decir, si yo fijo una variable de entorno en una sentencia esta variable prevalecerá sobre las variables de base de datos, instancia o sesion.

Llegados a este punto, sabemos que queremos, pero, no sabemos que tenemos. ¿Como podemos saber que parámetros NLS tenemos definidos en nuestro cliente/aplicacion?

La solucion es muy sencilla, solamente tenemos que conectarnos y preguntar.

Para ver todas las variables de nuestra conexion de cliente

SQL> set pagesize 200;
column parameter format a25;
column value format a40;
select * from v$nls_parameters;

PARAMETER                 VALUE
------------------------- ----------------------------------------
NLS_LANGUAGE              SPANISH
NLS_TERRITORY             SPAIN
NLS_CURRENCY              
NLS_ISO_CURRENCY          SPAIN
NLS_NUMERIC_CHARACTERS    ,.
NLS_CALENDAR              GREGORIAN
NLS_DATE_FORMAT           DD/MM/RR
NLS_DATE_LANGUAGE         SPANISH
NLS_CHARACTERSET          WE8MSWIN1252
NLS_SORT                  SPANISH
NLS_TIME_FORMAT           HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT      DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT        HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT   DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY         
NLS_NCHAR_CHARACTERSET    AL16UTF16
NLS_COMP                  BINARY
NLS_LENGTH_SEMANTICS      BYTE
NLS_NCHAR_CONV_EXCP       FALSE

19 rows selected.

o la variable languaje exportada del entorno

 SQL> SELECT USERENV ('language') FROM DUAL;

USERENV('LANGUAGE')
----------------------------------------------------
SPANISH_SPAIN.WE8MSWIN1252

Con esto seguramente encontremos la explicación de por que las fechas no nos salen como queremos, vemos caracteres extraños en las ñ o nos fallan las inseciones por culpa de los . y ,

Sqlplus para dummies III ( Bloqueos )

Otra de las cosas que mas amenudo tenemos que hacer es el encontrar quien nos está bloqueando y que bloquea.

Para ello, la consulta mas sencilla que podemos hacer es:

SELECT
     a.session_id , username ,type , mode_held, mode_requested 
     lock_id1,lock_id2
FROM
     sys.v_$session b,
     sys.dba_blockers c,
     sys.dba_lock a
WHERE
     c.holding_session=a.session_id AND
     c.holding_session=b.sid

Pero,  seguramente queramos saber mas cosas, como que tipo de bloqueos y que objetos están implicados, para ello podemos usar esta consulta en la que aparecen  datos de la sesión, del proceso tanto en el server como en el cliente y de los objetos y tipo de bloqueo que lleva a cabo

 

SELECT 
substr(to_char(l.sid),1,4) "SID", 
s.serial# "SERIAL",
P.spid "Server  PID", 
s.USERNAME,
s.type, 
s.process "Client  PID", 
MACHINE, 
l.type, 
DECODE(L.TYPE,'MR','File_ID: '||L.ID1, 
'TM', LO.NAME, 
'TX','USN: '||to_char(TRUNC(L.ID1/65536))||' RWO: '||nvl(RWO.NAME,'None'),L.ID1) LOCK_ID1, 
decode(l.lmode, 
0, 'None', 
1, 'Null', 
2, 'Row-S (SS)', 
3, 'Row-X (SX)', 
4, 'Share', 
5, 'S/Row-X (SSX)', 
6, 'Exclusive', 
substr(to_char(l.lmode),1,13)) "Locked Mode", 
decode(l.request, 
0, 'None', 
1, 'Null', 
2, 'Row-S (SS)', 
3, 'Row-X (SX)', 
4, 'Share', 
5, 'S/Row-X (SSX)', 
6, 'Exclusive', 
substr(to_char(l.request),1,13)) "Requested", 
l.ctime, 
l.block ,
s.logon_time
FROM v$process P, 
v$session S, 
v$lock l, 
sys.obj$ lo, 
sys.obj$ rwo 
WHERE l.sid = S.sid (+) 
AND S.paddr = P.addr (+) 
AND LO.OBJ#(+) = L.ID1 
AND RWO.OBJ#(+) = S.ROW_WAIT_OBJ#
and S.type!='BACKGROUND'
order by SID;

Que version tengo de oracle ?

Hoy vamos a añadir una nueva entrada «para dummies».

La respuesta a la pregunta del título es muy facil, podemos obtenerla de la  tabla PRODUCT_COMPONENT_VERSION , o bien mirando simplemente la vista dinámica v$version .

Si quremos mirar la primera desde sqlplus, lo mejor será el dar formato previamente a las columnas,  la consulta sería algo similar a .

set linesize 120;
column PRODUCT format a60;
column VERSION format a20;
column STATUS format a20;
select * from product_component_version;

También podemos obtener información de que hay instalado y la version con


set linesize 120;
column comp_name format a60;
column VERSION format a20;
column STATUS format a20;
SELECT comp_name, version, status
FROm dba_registry
ORDER BY 1;

Si con esto no estais satisfechos, podeis  hurgar en el inventory de Oracle y ver con mas detalle que se ha puesto, especialmente los parches instalados .

Esto puedes hacerlo con

$ORACLE_HOME/OPatch/opatch lsinventory

 

Hay un caso en el que  esto no puede servirnos, y es cuando tenemos una 10g,11g que no ha sido creado desde el DBCA, en ese caso puede que el banner de la version de oracle no nos indique si es una version Estandard o Enterprise.

Para averiguarlo en ese caso modemos mirarlo en el fichero

$ORACLE_HOME/inventory/Components21/oracle.server/*/context.xml

En este fichero xml podemos mirar la propiedad s_serverInstallType donde nos dira si es estandard (SE) o Enterprise (EE).

En la version 11g el fichero a buscar es el
$ORACLE_HOME/inventory/globalvariables/oracle.server/globalvariables.xml
y tenemos que buscar la variable oracle_install_db_InstallType

Generar un fichero separado por comas

Que ocurre cuando queremos obtener la salida de una consulta en un formato facil de transportar a alguna otra aplicacion (normalmente la dichosa excel)?

La solucion mas sencilla es hacer un fichero separado por comas.

set heading off
set termout off
spool fichero_por_comas.txt
select machine
||chr(44)||
count(*) numero
from v$session where type != 'BACKGROUND'
and status='ACTIVE'
group by machine order by numero desc;
exit;

El truco aqui se encuantra en el ||chr(44)||, con esa concatenacion estamos diciendole al SQLplus que concatene con el caracter 44, conde el caracter 44 es una coma.
Al igual que hemos utilizado una coma podíamos haber usado cualquier otro caracter que nos interese.

Nota: la tabla de caracteres se puede encontrar en :http://www.asciitable.com/