Data">
Nothing Special   »   [go: up one dir, main page]

Como Generar Una Base de Datos Standby

Descargar como doc, pdf o txt
Descargar como doc, pdf o txt
Está en la página 1de 4

Una base de datos Standby se utiliza para mantener de forma sencilla una

copia duplicada de la base de explotación mediante la información de log


archivada.

Para montar una base de datos Standby debes:

1º Tu base de datos de explotación debe de trabajar en modo


Archivelog

2º Tienes que crear una estructura identica (o muy similar) en la


máquina de standby a la de producción.

3º Debes instalar el software de base de datos sin crear la base de


datos en la máquina de standby.

4º Paras la base de datos de producción y haces un backup offline.

5º Arrancas la base de datos y ejecutas la siguiente instrucción:

Alter database create standby controlfile as


_$HOME/ctlstby.ctl_ reuse;
Alter system archive log current;

Con esto creas un fichero de control especial para la


máquina de standby y provocas un archivado.

6º Se copian los datafiles del backup hecho en el punto 4 en los


mismos directorios en el servidor de backup.

7º Copias tú fichero Init.ora en el mismo directorio. Es conveniente


tener dos juegos de init uno para producción igual que el que ya
tienes y otro para standby con log_buffer grande y
shared_pool_size pequeño.

8º Copias el fichero de control de standby al servidor de backup.

9º Copias los Archivers generador del primario al secundario.

Para poner en marcha la base de datos de standby debes:

1º Ejecutar:

startup pfile=fichero_init_standby nomount;


alter database mount standby database;

2º Ahora unicamente tienes que montar algún mecanismo autómatico


(o manual) que transfiera los archivers de la máquina de
producción a la de standby y los aplique.
Para aplicarlos:

Recover standby database;

Puedes utilizar la opción auto ó la opción until cancel.


Yo personalmente uso el siguiente script:
svrmgrl << RECOVER
connect internal
recover standby database until cancel;

CANCEL
exit

NOTA: Las líneas en blanco que hay entre el recover y el CANCEL


es un Enter. Esto es debido a que si utilizas esta opción
de recuperación te pedira que introduzcas el nombre del
fichero a aplicar o presiones enter para aplicar el que
te pide.

Si en algún momento tienes que activar la base de datos de Standby


entonces automaticamente pasa a ser de producción y para volver a
tener una base en standby deberas volver a recrearla por completo.

Para activar la base de datos Standby debes ejecutar:

alter database activate standby database;

En ese momento pasa a ser de producción. Es recomendable pararla y hacer


un backup (si la has activado es porque ya no tienes la de producción).

Luego ya puedes arrancarla de nuevo (normalmente con startup)con el


init.ora de producción.

Ten cuidado con lo que haces en la de producción porque no todo se


propaga a la de respaldo. Es decir puede que hagas algo que no se propague a
la de respaldo y tendrás que recrearla de nuevo.

Yo he buscado que es lo que hay que hacer en estos casos y hasta ahora
tengo lo siguiente:

En general

Cualquier operación que utilice la opción UNRECOVERABLE:


sqlldr,alter index rebuild, create index, create table

* Reinicializar la bbdd standby (repetir el proceso de


instalación: copiar backup de la bbdd primaria y el
controlfile especial)

Cualquier operación que utilice la opción RESETLOGS

* Reinicializar la bbdd standby

Borrado de un tablespace
* Reinicializar la bbdd standby

Alter database

ADD LOGFILE y ADD LOGFILE MEMBER

* Refrescar el fichero ctrlstby, si es que se desea propagar


el cambio

CLEAR LOGFILE

* Reinicializar la bbdd standby

CREATE DATAFILE

* Crear el datafile en la bbdd standby manualmente (antes del


recover o una vez haya fallado el recover)

DISABLE/ENABLE THREAD

* Ejecutar la misma sentencia en la bbdd standby, si es que


se desea propagar

DROP LOGFILE GROUP y DROP LOGFILE MEMBER

* Ejecutar la misma sentencia en la bbdd standby, si es que se


desea propagar

NOARCHIVELOG MODE

* Reinicializar la bbdd standby

OPEN RESETLOGS

* Reinicializar la bbdd standby

RECOVER

* Si el recover se puede realizar completamente sin la opción


Resetlogs, no es necesario propagar manualmente. En caso
contrario, hay que reinicializar la bbdd standby

RENAME FILE

* Ejecutar Rename del fichero a nivel S.O primero, y después a


nivel bbdd, en el servidor secundario

RENAME GLOBAL_NAME

* Refrescar el fichero ctrlstby

RESET COMPATIBILITY
* Reinicializar la bbdd standby

Alter system

ARCHIVE LOG STOP

* Reinicializar la bbdd standby

Alter tablespace

ADD DATAFILE

* Añadir el datafile en la bbdd standby manualmente (antes del


recover o una vez haya fallado el recover)

RENAME DATAFILE

* Añadir el datafile en la bbdd standby manualmente (antes del


recover o una vez haya fallado el recover)

Create

CREATE CONTROLFILE

* Si no se utiliza la opción Resetlogs, es suficiente con


refrescar el fichero ctrlstby; en caso contrario, hay que
reinicializar la bbdd standby

CREATE TABLESPACE

* Crear el tablespace con el datafile correspondiente en la bbdd


standby manualmente (antes del recover o una vez haya fallado
el recover)

Ten en cuenta que la base de datos de respaldo va siempre retrasada con


respecto a la de producción, así que es conveniente ir provocando archivados
cada X minutos (Alter system archive log current) para no retrasarse
demasiado (yo lo hago cada 10, pero depende de si en tú máquina hay o no
contención de disco puedes hacerlo antes).

Por cierto si tienes 8i puedes abrir la base de datos standby en modo


consulta. Es muy util para comprobar que se esta archivando correctamente.

También podría gustarte