CRS-2640: Required resource ‘ora.FRA.dg’ is missing

No deja de sorprenderme la simpleza de funcionamiento del crs de Oracle. En la última versión 11.2.0.2 me he encontrado con un error un poco tonto.

Tras hacer una pruebas con un diskgroup FRA en el ASM en un RAC de 3 nodos, decidimos eliminarlo.
Desde el ASM no hubo más problemas ya que el diskgroup estaba limpio y no tenía ningun tipo de dependencia con objetos de la bbdd. Hasta aquí todo correcto.

Lamentablemente el OCR no se había enterado de la eliminación del diskgroup y al hacer una simple prueba rutinaria de parada y subida del servicio este falló por no encontrar las dependencias de recursos DG que se habían eliminado.

Comprobando las dependencias de recursos se podía observar como todavía estaba en las subida y bajada

Un nuevo error, al validar la configuración del servicio, al no existir el recurso en el CRS, también fallaba el estado.

Tras investigar un poco opte por forzar la dependencias nuevamente. Algo que probablemente debería haber hecho automáticamente al recibir el cambio de estado de ASM.

Tras esta operativa se podía validar que ningún recurso volvía a depender de la FRA.

Levantamos el servicio de bbdd y todo funciona correctamente:

Finalmente el comando devuelve la configuración correcta:

 

Agregar un día a una fecha

Para agregar un día a una fecha en oracle basta con sumar “1” a la variable o columna que nos interese.

select trunc(sysdate +1) from dual;

El trunc es para garantizar que pone las 00:00 de ese día. Si interesa justo un día quitar este trunc.

Si es tal día como hoy dentro de una semana:

select trunc(sysdate +7) from dual;

Recuperar un datafile almacenado sobre un volumen raw

En una bbdd de pruebas tenemos sus datafiles almacenados en volúmenes RAW.

Este tipo de almacenamiento se emplea por motivos históricos por que cuando los discos eran otros, mejoraba ligeramente rendimiento al eliminar capas de software. Sin embargo la tendencia es ir avandonándolo, ya que exige un esfuerzo extra de administración que prácticamente ya no compensa con las nuevas cabinas de almacenamiento. De hecho Oracle lo desaconseja en sus Papers recientes e incluso no garantiza que se soporte en futuras versiones.

Supongamos que en una versión 10g accidentalmente desaparece uno de los volúmenes que contiene/es un datafile de tablespace USERS.


SQL> startup
ORACLE instance started.


Total System Global Area 285212672 bytes
Fixed Size 1218992 bytes
Variable Size 92276304 bytes
Database Buffers 188743680 bytes
Redo Buffers 2973696 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/dev/raw/raw9'

Lástima, no encuentra el fichero 5, afortunadamente tenemos una copia de seguridad reciente y todos los archivelog generados desde entones. Inicio RMAN y muevo el datafile a otra ubicación.


RMAN> run
2> {
3> set newname for datafile 5 to '/u02/oradata/test/user02.dbf';
4> restore datafile 5;
5> }

Y el resultado de este bloque RUN es:

executing command: SET NEWNAME

Starting restore at 27-APR-09
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00005 to /u02/oradata/test/user02.dbf
channel ORA_DISK_1: reading from backup piece /u02/oradata/flash_recovery_area/TEST/backupset/2009_04_27/o1_mf_nnndf_TAG20090427T171253_4zclvocj_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u02/oradata/flash_recovery_area/TEST/backupset/2009_04_27/o1_mf_nnndf_TAG20090427T171253_4zclvocj_.bkp tag=TAG20090427T171253
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 27-APR-09

He recuperado el media en la nueva dirección pero el fichero de control de la bbdd todavia apunta a la direccion vieja.


SQL> alter database rename file '/dev/raw/raw9' to '/u02/oradata/test/user02.dbf';

RMAN> recover database;

RMAN> alter database open;

Se recupera la bbdd, y se abre para los usuarios. Ya está la bbdd dando servicio.

De momento el datafile está montado en un filesystem, pero se puede volver a la situación de partida en RAW. Se repasa el volumen o se provisiona otro y fácilmente, con una operativa similar, se puede pasar a un almacenamiento como están el resto de los datafiles.

Muy sencillo.

Fechas en formato Epoch

Recientemente he tenido que juguetear con el formato de fecha EPOCH que es el número de segundos desde el 1 de enero de 1970. Este formato se emplea generalmente en sistemas unix como formato nativo de fecha y como era mi caso fecha en ficheros de intercambio entre sistemas.

Para convertir el clásico SYSDATE de Oracle a este formato es muy sencillo, basta con restarle la fecha de referencia y pasarlos a segundos:


SELECT to_number(
sysdate - to_date('01/01/1970','DD/MM/YYYY')
) * (24 * 60 * 60)
FROM DUAL

uptime en oracle

Existe una manera muy sencilla de saber cuanto tiempo lleva una instancia de bbdd dando servicio, dos sencillas consultas:

O bien consultando la primera sesión de la tabla v$session.

select min(logon_time) from v$session;

O bien consultando la tabla de información de la instancia:

select * from v$instance;

Duda resuelta.

Instalando Oracle SQL Developer en Ubuntu

Siempre he sido un poco rústico instalando SQL Developer de Oracle. De hecho, siempre bajaba el package genérico lo descomprimia y lo lanzaba sin preocuparme de más en Windows y MacOS.

Sin embargo en Ubuntu me percaté que no era forma de proceder OS-Friendly. Investigué un poco y llegué a la conclusion que la mejor manera es descargar la versión de RedHat (rpm) sqldeveloper-1.XXX.noarch.rpm y convertir este rpm en un package Debian. Es una operación basica pero que yo nunca había necesitado emplear. Veamos los pasos:

  1. Instalamos la Linux Standard Base (lsb) que permite compatibilizar la estructura entre distintas versiones linux
  2. sudo apt-get install lsb

  3. Instalamos el JRE de Sun, si no lo tememos ya…
  4. sudo apt-get install sun-java6-jre

  5. Y por último Alien que nos permite convertir packages RPM en DEB entre otras opciones.
  6. sudo apt-get install alien

  7. Convertimos el rpm a deb
  8. sudo alien --scripts sqldeveloper*rpm

  9. y finalmente instalamos el deb que hemos obtenido.
  10. sudo dpkg -i sqldeveloper*deb

Ya está, ya tenemos correctamente instalado Oracle SQL Developer, con sus entradas de menú y todo.

EM_SEVERITY, para inconscientes

Durante un periodo de vacaciones se nos llenó el area de archiver de una 10g de desarrollo. En un par de dias se generaron más de trescientos mensajes de alerta que no leimos hasta nuestro despreocupado regreso.

Trescientas alertas son muchas para ir limpiándolas una a una y más desde una interfaz web, así que investigué un poco sobre el mecanismo de notificaciones.

Existen llamadas desde un package oracle para gestionar este sistema, EM_SEVERITY, pero decidí hacerlo a lo inconsciente, borrando directamente de esta tabla, estaba en desarrollo, ¿no?

  • El listado en la pagina principal del EM es una consulta sobre la tabla.
  • sysman.mgmt_current_severity

  • Las notificaciones se graban y borran desde una tabla principal que se llama
  • sysman.mgmt_severity

  • Hay un trigger que directamente elimina los registros de la primera relacionados con los de esta ultima. Luego borrando una tenia la otra.
  • DELETE
    FROM sysman.mgmt_severity
    WHERE MESSAGE LIKE '%archi%';

Y funcionó. Todo parece trabajar correctamente. No me hago responsable de lo que pueda pasar en vuestros sistemas.

Instalar Oracle SQL Developer Data Modeling en Macosx

Ya va por la segunda release del Oracle SQL Developer Data Modeling. Una herramienta que de momento es curiosa pero que le queda mucho para ser una alternativa a ERWIN, en cualquier casi hay que probarla.

La primera version la instale hace ya unos meses sin especiales problemas. Tan sencillo como descargar el *.zip, localizar los *.sh y validar que tienen permisos de ejecución. No es especialmente complicado.

En esta nueva version “Early Adopter Release 2” del 26 Nov 08 se queja para que le indiquemos donde esta la instalación J2SE, en concreto las lineas son:


[Carbono]$ pwd
/Applications/sqldeveloper-modeler
[Carbono]$ ./datamodeling.sh

Oracle SQL Developer Data Modeling
Copyright (c) 2008, Oracle. All rights reserved.

Type the full pathname of a J2SE installation (or Ctrl-C to quit), the path will be stored in jdk.conf

Bueno no hace otra cosa que pedir un HOME de java que en Leopard lo podemos encontrar en:


/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home

Y ya está, ya tenemos el fichero de configuracion cerrado y listo para funcionar.

Apple ha ido actualizando las maquinas virtuales pero no lo he probado con otra versión, no obstante Oracle no suele utilizar las ultimas versiones de Java, la version 1.5 es más que suficiente.