ORA-07445 dbgrlrReadAlertMsg

Nos hemos mudado a bloger!
El contenido actualizado de esta entrada lo tienes en:

http://dba.pamplona.name/2014/01/ora-07445-dbgrlrreadalertmsg.html

Hoy vamos a ver como solucionar un problema que puede ser bastante frecuente en las versiones 10,11 y 12 .
En estas versiones el fichero alert.log se encuentra en formato xml esta «mejora» puede provocar también que, en caso de tener algún problema con el formato del xml recibamos varios errores en el alert.

Uno de los errores que podemos encontrar es este:

ORA-07445: caught exception [ACCESS_VIOLATION] at [dbgrlrReadAlertMsg()+2695] [0x0000000001855989]

Hay varias acciones y parches que se pueden tomar al respecto, pero , la mas sencilla de ellas es

  • Para la base de datos
  • Mueve todos los ficheros .xml del directorio donde está el alert.xml
  • Arranca la base de datos

Ya se que, normalmente los workarrounds que implican parada de bases de datos no son muy cómodos o aconsejables, pero , la sencillez de este hace que sea mucho mas fácil de ejecutar que cualquier otra acción.

Como siempre, en soporte de Oracle podremos encontrar una nota al respecto
ORA-7445 [dbgrlrReadAlertMsg] on SELECT FROM X$DBGALERTEXT or a view based of it (Doc ID 1433214.1)

Crear un diskgoup desde asmca

Nos hemos mudado a bloger!
El contenido actualizado de esta entrada lo tienes en:

http://dba.pamplona.name/2013/12/crear-un-diskgoup-desde-asmca.html

Vamos a ver como crear un diskgroup en nuestro grid.

Lo primero que haremos será conectarnos como el usuario propietario del grid control (grid) y cargar las variables de entorno.

[oracle@rac1 grid]$ . oraenv
ORACLE_SID = [oracle] ? +ASM1
The Oracle base has been set to /oracle/11.2.0/grid
[oracle@rac1 grid]$ 

Una vez tenemos cargadas las variables, ejecutaremos el comando que lanza la interfaz gráfica asmca

Nosotros iremos a la pestaña de grupo de discos y pulsaremos en crear . Para este ejemplo crearemos el grupo DATA con los dos primeros discos con redundancia normal. tras esto, haremos lo mismo con los dos últimos (los mas pequeños) y llamaremos a el grupo INDICES

Como podemos ver, el uso de la herramienta gráfica que gestiona el ASM es bastante sencilla, en la siguiente entrada crearemos un grupo y le asignaremos discos desde la línea de comandos.

Instalacion de RAC II , instalacion de grid infraestructure

Repasando las entradas anteriores he podido comprobar como , tas la entrada de RAC I Preparativos no teníamos las siguientes entradas de instalación del RAC, así pues, vamos a hacer de nuevo la instalación para dejarla documentada.

Partimos de la base de la configuración de entorno y máquinas del post RAC I Preparativos
Como recordatorio rápido tenemos que los directorios a utilizar serán:

  • GI_HOME=/oracle/11.2.0/grid
  • ORACLE_BASE=/oracle/app/grid

    grid

Y la configuración de red de los servidores será

# Direcciones para nuestros equipos
# HOST y publica  eth0
10.0.2.2  exodar.pamplona.name   exodar
10.0.2.3  rac1.pamplona.name     rac1
10.0.2.4  rac2.pamplona.name     rac2
10.0.2.5  rac3.pamplona.name     rac3
10.0.2.6  rac4.pamplona.name     rac4
10.0.2.24 plantilla.pamplona.name        plantilla


#Virtual  Eth1  direcciones de la red sobre la que se da el servicio 
192.168.1.1  exodar-vip.pamplona.name   exodar-vip
192.168.1.2  rac1-vip.pamplona.name     rac1-vip
192.168.1.3  rac2-vip.pamplona.name     rac2-vip
192.168.1.4  rac3-vip.pamplona.name     rac3-vip
192.168.1.5  rac4-vip.pamplona.name     rac4-vip
192.168.1.24 plantilla-vip.pamplona.name        plantilla-vip

#ScaN  comentadas ya que estan dada de alta en round robin dns
# estas son las verdaderas direcciones de servicio 
#192.168.1.20  ractest.pamplona.name  ractest
#192.168.1.21  ractest.pamplona.name  ractest
#192.168.1.22  ractest.pamplona.name  ractest

#Private ETH2 red privada de los nodos
192.168.2.1  exodar-priv.pamplona.name  exodar-priv
192.168.2.2  rac1-priv.pamplona.name    rac1-priv
192.168.2.3  rac2-priv.pamplona.name    rac2-priv
192.168.2.4  rac3-priv.pamplona.name    rac3-priv
192.168.2.5  rac4-priv.pamplona.name    rac4-priv
192.168.2.24 plantilla-priv.pamplona.name   plantilla-priv

Así pues, lanzamos la instalación del grid control:
En nuestro caso omitiremos la información de soporte, en el caso de una instalación real de RAC es muy recomendable el incluirla ya que facilitará mucho el uso del área de soporte así como la descarga de los últimos parches para llevar a cabo la instalación de la ultima versión disponible.
rac_pantalla1
En la siguiente pantalla indicaremos que queremos instalar la versión del grid infraestructure que aplica a un cluster
tac_pantalla2
Nosotros elegiremos la instalación avanzada para poder afinar mas las opciones de instalación.
rac_pantalla3
rac4
En este punto comenzamos con la instalación específica del rac.
Aquí tendremos que introducir las direcciones de servicio y privadas del RAC.
Hemos de tener en cuenta que, nosotros ya teníamos comprobado y solucionado el tema de la conexión ssh entre los nodos, en caso de no estar claro ese tema, podremos comprobarlo desde la opción conectividad ssh
Captura de pantalla 2013-12-28 a la(s) 17.56.41
rac_pantalla7
rac_pantalla8
Si la configuración de las tarjetas con los nombres es correcta, pasamos a la pantalla en la que indicamos cual van a ser las direcciones de red.
Como las traducciones las carga el diablo,vamos a detallar unpoco que es cada cosa:

  • privada:van a ser las interfaces de interconexión del rac, esta debe de ser una conexión dedicada para la sincronización de las caches.
  • públicaEs las interfaces vip que serán sobre las que posteriormente Oracle levantará las interfaces de scan

rac_pantalla9
La version 11.2 del Grid nos permite tener el OCR y el Quorum en un disco en ASM, nosotros vamos a elegir este tipo de instalacion
rac_pantalla10

Estamos en el momento en el que ASM nos muestra los discos disponibles, en nuestro caso lo hacemos mediante asmlib ( ver RAC I Preparativos ) , en la imagen tenemos que vamos a crear el grupo de discos OCRQUORUM y vamos a usar 1 disco de los que tenemos con la redundancia EXTERNAL.
En un entorno de producción real, será más aconsejable el uso de varios discos de 1 Gb con redundancia SUPERIOR.
Que el nombre del grupo de datos sea distinto a DATA (por defecto), llamándose OCRQUORUM no es un standard o buena práctica de Oracle, sino una modificación mía para que sirva para distinguirlo fácilmente del nombre del diskgroup que usaré en las bases de datos
Captura de pantalla 2013-12-28 a la(s) 17.58.20

rac_pantalla12
El IPMI podríamos decir que es lo que tradicionalmente se ha llamado fencing , para tener mas infiormación del mismo podemos mirar en la documentación de Oracle Configuring IPMI for Failure Isolation, en nuestro caso, no lo vamos a activar.
rac_pantalla13
rac_pantalla14
Indicamos los directorios que teníamos planificados
rac_pantalla16
Finalmente, vemos las opciones y el resumen

Captura de pantalla 2013-12-28 a la(s) 18.33.06
Y la tipica ventana de ejecución de los comandos como root.
Aquí hemos de ser pacientes y ejecutar los scripts en orden, primero siempre en el nodo en el que estamos llevando a cabo la instalacón, y, solamente cuando hallan acabado de manera correcta ejecutarlos en el otro nodo
rac_pantalla20

Tras esto, continuamos con la instalación dando a «siguiente» hasta que finalice.
rac_panbtalla21
rac_pantalla_22

La instalación del Grid Infraestructure no es (desde mi punto de vista) algo muy limpio, y , tiene bastantes papeletas de fallar en algún punto, por lo que, es muy recomendable el tener a mano las notas específicas de soporte Oracle que nos ayudarán a solucionar estos problemas.
Estas notas son:

Estado del Cluster/Rac/Grid tabulado

Nos hemos mudado a bloger!
El contenido actualizado de esta entrada lo tienes en:
http://dba.pamplona.name/2013/12/estado-del-clusterracgrid-tabulado.html

Hoy vamos a ver una entrada de esas sencillas para hacernos la vida mas fácil.

Cuando ejecutamos el comando para ver el estado de un cluster, nos solemos encontrar con esto :

grid@rac1:/opt/oracle/10.2/CRS/bin$ crs_stat -t
Name Type Target State Host
------------------------------------------------------------
ora....SM1.asm application ONLINE ONLINE oradb1
ora....D1.lsnr application ONLINE ONLINE oradb1
ora.oradb1.gsd application ONLINE ONLINE oradb1
ora.oradb1.ons application ONLINE ONLINE oradb1
ora.oradb1.vip application ONLINE ONLINE oradb1
ora....SM2.asm application ONLINE ONLINE oradb2
ora....D2.lsnr application ONLINE ONLINE oradb2
ora.oradb2.gsd application ONLINE ONLINE oradb2
ora.oradb2.ons application ONLINE ONLINE oradb2
ora.oradb2.vip application ONLINE ONLINE oradb2
ora....robd.db application ONLINE ONLINE oradb1
ora....dmin.cs application OFFLINE OFFLINE
ora....bd1.srv application OFFLINE OFFLINE
ora....ckup.cs application OFFLINE OFFLINE
ora....bd2.srv application OFFLINE OFFLINE
ora....atch.cs application OFFLINE OFFLINE
ora....bd2.srv application OFFLINE OFFLINE
ora....oltp.cs application OFFLINE OFFLINE
ora....bd1.srv application OFFLINE OFFLINE
ora....bd2.srv application OFFLINE OFFLINE
ora....d1.inst application ONLINE ONLINE oradb1
ora....d2.inst application ONLINE ONLINE oradb2

Realmente no nos sirve de mucho ya que queda todo apiñado,y no nos permite saber que componente está arrancado y cual eta parado.
Navegando por internet vi en un par de webs (perdón pero no recuerdo el lugar) el siguiente scipt en ksh

!/usr/bin/ksh
#
#  $GRID_HOME debe de estar definido en el entorno 
#
RSC_KEY=$1
QSTAT=-u
AWK=/bin/awk
# Table header:echo ""
$AWK \
'BEGIN {printf "%-45s %-10s %-18s\n", "HA Resource", "Target", "State";
printf "%-45s %-10s %-18s\n", "-----------", "------", "-----";}'
# Table body:
$GRID_HOME/bin/crs_stat $QSTAT | $AWK \
'BEGIN { FS="="; state = 0; }
$1~/NAME/ && $2~/'$RSC_KEY'/ {appname = $2; state=1};
state == 0 {next;}
$1~/TARGET/ && state == 1 {apptarget = $2; state=2;}
$1~/STATE/ && state == 2 {appstate = $2; state=3;}
state == 3 {printf "%-45s %-10s %-18s\n", appname, apptarget, appstate; state=0;}'

Este script nos devuelve una salida limpia al estilo de :

grid@rac1:/opt/oracle/10.2/CRS/bin$ ./crsstat.sh
HA Resource                         Target     State
-----------                         ------     -----
ora.oradb1.ASM1.asm                ONLINE     ONLINE on oradb1
ora.oradb1.LISTENER_oradb1.lsnr    ONLINE     ONLINE on oradb1
ora.oradb1.gsd                     ONLINE     ONLINE on oradb1
ora.oradb1.ons                     ONLINE     ONLINE on oradb1
ora.oradb1.vip                     ONLINE     ONLINE on oradb1
ora.oradb2.ASM2.asm                ONLINE     ONLINE on oradb2
ora.oradb2.LISTENER_oradb2.lsnr    ONLINE     ONLINE on oradb2
ora.oradb2.gsd                     ONLINE     ONLINE on oradb2
ora.oradb2.ons                     ONLINE     ONLINE on oradb2
ora.oradb2.vip                     ONLINE     ONLINE on oradb2
ora.rac.db                         ONLINE     ONLINE on oradb1
ora.rac_admin.cs                   OFFLINE    OFFLINE
ora.rac_admin.rac1.srv             OFFLINE    OFFLINE
ora.rac_backup.cs                  OFFLINE    OFFLINE
ora.rac_backup.rac2.srv            OFFLINE    OFFLINE
ora.rac_batch.cs                   OFFLINE    OFFLINE
ora.rac_batch.rac2.srv             OFFLINE    OFFLINE
ora.rac_oltp.cs                    OFFLINE    OFFLINE
ora.rac_oltp.rac1.srv              OFFLINE    OFFLINE
ora.rac_oltp.rac2.srv              OFFLINE    OFFLINE
ora.rac.rac1.inst                   ONLINE     ONLINE on oradb1
ora.rac.rac2.inst                   ONLINE     ONLINE on oradb2

Nota posteriormente me he encontrado con que era un script documentado por Oracle en la nota 259301.1 :
CRS and 10g/11.1 Real Application Clusters (Doc ID 259301.1)

Como limpiar datapump fallidos ORA-31633

Hoy vamos a ver como solucionar el problema de relanzar algunos datapumps fallidos cuando nos devuelven el error ORA-31633

Una de las principales diferencias entre el export tradicional y el nuevo expdp es que el expdp crea un job en la base de datos que es quien se encarga de la labor de sacar los datos.

Cuando detenemos esta exportación de manera no controlada, puede ser que la definición del trabajo creada por el export quede dentro de la base de datos, con lo que, al volver a lanzar el trabajo del export recibamos un error «ORA-31633: unable to create master table XXX»

ORA-31626: job does not exist
ORA-31633: unable to create master table "SYSTEM.EXPORT_DIAR"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPV$FT", line 863
ORA-01031: insufficient privileges

Para solucionar este problema, lo primero que tenemos que hacer es comprobar que trabajos no se encuentran en estado RUNNING


SET lines 200
SELECT owner_name, job_name, operation, job_mode,
state, attached_sessions
FROM dba_datapump_jobs
ORDER BY 1,2;

Esta consulta nos devuelve la informacion de los trabajos de datapump que hay en la base de datos, el resultado es una tabla del tipo

OWNER_NAME JOB_NAME            OPERATION JOB_MODE  STATE       ATTACHED
———- ——————- ——— ——— ———– ——–
SCOTT      EXPORT_TABLA_1 EXPORT    TABLE     NOT RUNNING        0
SYSTEM     EXPORT_DIARIA  EXPORT    FULL      NOT RUNNING        0

Aquí podemos ver como tenemos dos trabajos, uno del usuario SCOTT y otro de SYSTEM que están en estado NOT RUNNING, con lo que podemos eliminarlos.

Ahora buscaremos cual es la «master table» del job con la consulta

SELECT o.status, o.object_id, o.object_type,
       o.owner||’.'||object_name “OWNER.OBJECT”
  FROM dba_objects o, dba_datapump_jobs j
 WHERE o.owner=j.owner_name AND o.object_name=j.job_name
   AND j.job_name NOT LIKE ‘BIN$%’ ORDER BY 4,2;

STATUS   OBJECT_ID OBJECT_TYPE  OWNER.OBJECT
——- ———- ———— ————————-
VALID        15223 TABLE        SCOTT. EXPORT_TABLA_1
VALID        15293 TABLE        SYSTEM.EXPORT_DIARIA

Ahora podemos eliminar las tablas de los trabajos con la consulta.

SQL> DROP TABLE SCOTT. EXPORT_TABLA_1;
SQL> DROP TABLE SYSTEM.EXPORT_DIARIA;

Con esto habremos limpiado la tabla de los jobs del datapump, con lo que podremos volver a lanzar nuestro script sin problemas