ORA-00201: control file version 10.2.0.4.0 incompatible with ORACLE version 10.2.0.3.0

DSCN0023

Image by Gianluca d'Arcangelo ☁ via Flickr

Problemas de compatibilidad entre versiones.

Cuando restoreamos un backup generado en una version superior ( en nuestro caso 10.2.0.4 ) y lo desplegamos en un ambiente que está en la misma versión , podemos incurrir en un problema si no tenemos en cuenta que los parametros esten bien configurados.

[oracle@linuxdat128 diario]$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Thu Nov 18 17:58:19 2010

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: ABAP (not mounted)

RMAN> startup nomount

database is already started

RMAN> restore controlfile from '/ch01/tsm/prepro/20101118_ABAP_DIARIO_DBID2419644494_s15541_p1_ctl';

Starting restore at 18-NOV-10
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=168 devtype=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:27
output filename=+SAPA_DG1/sapa/controlfile/current.432.735415149
Finished restore at 18-NOV-10

RMAN> alter database mount;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 11/18/2010 17:59:55
ORA-00201: control file version 10.2.0.4.0 incompatible with ORACLE version 10.2.0.3.0
ORA-00202: control file: '+SAPA_DG1/sapa/controlfile/current.432.735415149'

RMAN> quit

Sigue leyendo

Clean Logs with RMAN

Algunas veces nos encontramos con que backupeamos los archivelog y estos siguen permaneciendo en el storage debido a que nuestra politica de retención en mayor a 2 días.

Algunas aplicaciones tiene mucho movimiento y generan una cantidad importante de archive diario.

Como podemos aplicar una depuración ?

Yo tendría en cuenta algunos aspectos:

  • Que los archives que voy a deletear esten resguardados si esa es la politica.
  • Que si tengo una politica mayor a dos días y hay mucho archive, dejar lo vigente al día corriente y borrar todo hacia atras.
  • Si nos quedamos sin espacio de flashback y es urgente depurar, tomar un backup de archive (en caso de contar con algo de margen) y depurar acorde a  un punto en el tiempo, correspondiente al día corriente.

Con la query que pongo a continuación podemos ver el espacio ocupado, reclamable y cual es el tamaño total de flashback.

Con ello puedo saber con que espacio cuento y depurar acorde al escenario que poseo.

SQL> select space_limit/1024/1024 "Limit MB", space_used/1024/1024 "Used MB",
	space_reclaimable/1024/1024 "Reclaimable MB"
	from v$recovery_file_dest;  2    3  

  Limit MB    Used MB Reclaimable MB
---------- ---------- --------------
     40960	38990	       35818

Sigue leyendo