Archivo de 2/10/07

h1

Borrar catálogo RMAN

octubre 2, 2007

No es algo habitual, pero puede ser un procedimiento que se deba aplicar en algún momento en alguna de nuestras bases de datos: después de una migración, después de realizar pruebas de recuperación, cuando se va a eliminar la base de datos definitivamente.

Es bastante más simple que crear el catálogo. En primer lugar, nos conectamos al catálogo de recuperación:

$ rman target=/ catalog rman_user@cadena_conexión

Hay que borrar todas las copias antes de eliminar el catálogo de recuperación. Para ello se hace un crosscheck de los backups, seguido de un delete obsolete y un delete expired, con la intención de compactar el repositorio de copias y que no se quede nada en el tintero (la intención es liberar todo el espacio posible):

RMAN> crosscheck backup;

RMAN> delete obsolete;

RMAN> delete expired;

Se borran los backups restantes:

RMAN> delete backup;

Para comprobar que los deletes han hecho efecto, se puede ejecutar:

RMAN> list backup;

Esta consulta no debería devolver ningún fichero.

Finalmente, se borra el catálogo:

RMAN> drop catalog;

El sistema nos avisará entonces de que estamos intentando borrar el catálogo de recuperación, y nos pedirá que insertemos otra vez la orden para confirmarlo.

Otras entradas en mi blog relacionadas con RMAN:

h1

Reducir tablespace TEMP en ORACLE 10g

octubre 2, 2007

Esta semana nos hemos encontrado a una de nuestras bases de datos con un tablespace temporal (TEMP) que había crecido hasta los 32Gb. Evidentemente, habíamos cometido un error en la postinstalación de la base de datos, al no modificar el parámetro MAXSIZE, y alguna aplicación (esta base de datos da soporte a varias aplicaciones) había hecho que este tablespace crezca hasta ese tamaño.

Para más inri, la base de datos está en un entorno de producción, con lo cual el prodedimiento a aplicar debería minimizar la pérdida de servicio (o sea, o que no hubiese que parar la base de datos, o que la parada fuese en una franja horaria en el que la perdida de servicio no fuese muy apreciable; ésto último es complicado puesto que las aplicaciones que hacen uso de esta base de datos deben estar activas las 24 horas del día).

Otro problema a priori era el de los esquemas creados en la base de datos; pero éste fué descartado rápidamente, puesto que al tratarse de una versión 10.2, en la creación de un esquema no se indica un tablespace temporal, el esquema hace uso del tablespace temporal por defecto de la base de datos.

La solución que se contempló, y que no implicaba parada de la base de datos, consistía en crear un nuevo tablespace temporal, configurarlo como tablespace temporal por defecto de la base de datos y borrar el antiguo tablespace de 32Gb. El procedimiento aplicado fué el siguiente:

Read the rest of this entry ?

Seguir

Get every new post delivered to your Inbox.