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:

 

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

Reconfigurando el Enterprise Manager Console en la Oracle10g

Cambiar el nombre de una máquina después de una instalación
correcta debería de estar prohibido.

Si bien, instalar un servidor oracle10g en una máquina de pruebas ya no es especialmente complicado. Los problemas saltan cuando se debe manipular la configuración manualmente.

Caso típico, alguien decide que la máquina recién instalada debe cambiar de nombre para que quede bien con la nomenclatura del resto de los equipos. ¡Gran problema!

Configurar el Listener y el propio servidor no es difícil, el método es el mismo desde casi el principio de los tiempos. Adivinar como se puede cambiar la configuración del nuevo Enterprise Manager Console tipo web es otro cantar.

En encontrado esta referencia en la web que explica como realizar todo el proceso como antes de que existiesen los instaladores.

En mi particular caso, debo obviar el repositorio que ya fue creado, pasamos directamente al punto

emca-config dbcontrol db

Antes de empezar, por favor, confirmar que tenemos todas las contraseñas y parametros de configuracion.

Buena caza