Issuu on Google+

Plan de Contingencia Tecnología

Fecha:

Junio de 2011

Versión:

4

Magda Herrera

Fredy Parroquiano

Jefe de Sistemas

Elaboró

Revisó

Aprobó

Fecha: Octubre 2012

Fecha: Febrero 2012

Fecha: Junio 2011


Plan de Contingencia Tecnología Página 1 de 21

Tabla de Contenido 1

INTRODUCCIÓN .............................................................................. 2

2

DESARROLLO DEL PLAN DE CONTINGENCIA ................................. 2

3

INFORMACIÓN DE SOPORTE .......................................................... 2 3.1

Introducción ........................................................................................................2

3.2

Propósito ............................................................................................................2

3.3

Aplicabilidad .......................................................................................................2

3.4

Definiciones ........................................................................................................3

3.5

Alcance ...............................................................................................................3

3.5.1 3.5.2

3.6 3.6.1 3.6.2 3.6.3

4

Conceptos de operación ......................................................................................3 Descripción del sistema ........................................................................................................ 3 Línea de sucesión .................................................................................................................. 4 Responsabilidades ................................................................................................................ 4

FASE DE NOTIFICACIÓN Y ACTIVACIÓN ........................................ 5 4.1 4.1.1

5

Requerimiento ...................................................................................................................... 3 Registro de cambios ............................................................................................................. 3

Plan de notificación .............................................................................................5 Árbol de llamada................................................................................................................... 5

4.2

Evaluación de daños ............................................................................................6

4.3

Activación del plan ..............................................................................................6

FASE DE RECUPERACIÓN EN SITIO ALTERNO ............................... 6 5.1

Secuencia de actividades de recuperación ............................................................7

5.2

Diagrama de flujo de recuperación en sitio alterno. ..............................................8

5.3

Procedimientos de recuperación ..........................................................................8

5.3.1 Direcciones de Red ............................................................................................................... 9 5.3.2 Obtener claves ...................................................................................................................... 9 5.3.3 Validar requerimientos de RED ............................................................................................ 9 5.3.4 Validar Requerimientos de operación alterna ...................................................................... 9 5.3.5 Validar acceso remoto a servidores de contingencia ......................................................... 10 5.3.6 Suspender operaciones del sistema de información en el sitio principal .......................... 10 5.3.7 Procedimiento de Switchover ............................................................................................ 10 5.3.8 Procedimientos para procesos batch ................................................................................. 16 Verificar la disponibilidad del servicio y liberar ................................................................................ 16 5.3.9 Hacer failover si el switchover no es posible ...................................................................... 16

6

FASE DE RETORNO AL SITIO PRINCIPAL ..................................... 17

7

ANEXOS ......................................................................................... 18 7.1

Anexo A- Creando un scripts del archivo de control ............................................ 18

7.2

Anexo B- Copiando Archivos fuera y dentro del ASM .......................................... 19

Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 2 de 21

1 INTRODUCCIÓN Este documento especifica los procedimientos a seguiren el momento de activar el esquema de contingencia para el sistema de la base de datos FIDUCIAR con el fin de recuperarse en el menor tiempo y costo posible.

2

DESARROLLO DEL PLAN DE CONTINGENCIA

El plan de contingencia consta de los siguientes componentes: • • • • •

Información de soporte Fase de notificación y activación Fase de recuperación en sitio alterno Fase de retorno en sitio principal Apéndices del plan

3 3.1

INFORMACIÓN DE SOPORTE

Introducción

Este componente del plan es introductorio, provee la información que permite entender la globalidad del plan y definir acciones y procedimientos a ejecutar en caso de fallas. 3.2

Propósito

Este plan permite activar la contingencia en sitio remoto. Incluye activación de base de datos en las máquinas instaladas en Claro. Se incluye los procedimientos técnicos de recuperación y de vuelta al sitio principal. 3.3

Aplicabilidad

La activación se llevará a cabo si la disponibilidad del servidor de BD que soportan el sistema de información en el sitio principal se ve comprometida y no se puede recuperar dentro de los tiempos tolerables para el sistema de información.

Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 3 de 21

3.4

Definiciones • •

3.5

Sitio Principal: Sitio geográfico donde se encuentra el centro de cómputo en Fiduciaria Central. Sitio Secundario: Sitio geográfico donde se encuentra el centro de cómputo alterno de Claro.

Alcance

El alcance de este plan incluye la falta de disponibilidad en los siguientes componentes del sistema de información: •

Servidor de base de datos

Este plan supone la disponibilidad de la infraestructura de contingencia en Claro. No se incluye dentro de este plan acciones a seguir en caso de falta de disponibilidad de los servidores de contingencia en Claro. 3.5.1 Requerimiento Este plan responde al requerimiento de la organización sobre garantizar la continuidad de la operación de los sistemas críticos. 3.5.2 Registro de cambios FECHA DEL CAMBIO

RESPONSABLE

DESCRIPCIÓN DEL CAMBIO

20 de Octubre de 2009

Rubén Darío Parra

Emisión

Rubén Darío Parra

Modificación

Harold Castro

Modificación

21 Junio de 2011 20 Octubre de 2012

3.6 Conceptos de operación 3.6.1 Descripción del sistema En términos generales el sistema SIFI consta de una base de datos (FIDUCIAR), en cada máquina se tiene instalado el runtime de forms&reports y los binarios de la aplicación se encuentran en un servidor los cuales son compartidos por una carpeta compartida para su ejecución. Para la contingencia se replica la BD enel servidorClaro donde se encuentra instalada la aplicación, no tendrá contingencia en el sitio secundario. Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 4 de 21

3.6.2 Línea de sucesión Se ilustran a continuación los responsables y suplentes para desempeñar los diferentes roles dentro de este plan. ROL Coordinador

PRINCIPAL

CARGO Jefe de Sistemas

Harold Castro Consultor

DBA

AsesoftwareLtda Jefe de Sistemas

Administrador Harold Castro de WAN/LAN Administrador Sistema(HW yHarold Castro SO) Contacto Claro Coordinador de SIFI

Jefe de Sistemas

Centro deAsesor Soporte Coorp. Ing. De Redes y Eduardo García Telecomunicaciones

SUPLENTE

CARGO Ing. De Fredy Gestión de Parroquiano Servicios Informáticos Ing. De Fredy Gestión de Parroquiano Servicios Informáticos Ing. De Fredy Gestión de Parroquiano Servicios Informáticos Ing. De Fredy Gestión de Parroquiano Servicios Informáticos Juan JoseAsesor Villalba

3.6.3 Responsabilidades El siguiente cuadro ilustra las responsabilidades para cada uno de los roles dentro del plan. ROL Coordinador

DBA

Elaboró: Magda Herrera Fecha: Junio de 2012

    

RESPONSABILIDADES Definir la activación y desactivación del plan. Contactar y supervisar el trabajo de los equipos. Informar a los usuarios sobre los eventos de la recuperación del sistema de información. Participar en la evaluación de los daños. Ejecutar los procesos técnicos de base de datos para activar la contingencia y la recuperación.

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 5 de 21

Administrador LAN/WAN

de

Administrador Sistema(HW y SO)

Contacto Claro Coordinador de SIFI

 Participar en la evaluación de daños.  Garantizar las necesidades de conectividad del sistema de información.  Monitorear los canales de contingencia.  Apoyar las labores de contingencia y recuperación en lo relacionado con las comunicaciones  Participar en la evaluación de los daños.  Garantizar la operación tanto de HW como del SO requerido por el sistema de información.  Apoyar las labores de activación de contingencia y recuperación en lo relacionado con HW y SO.  Proveer los servicios de manos remotas y apoyar la activación del sistema de información en el sitio remoto.  Coordinar pruebas del sistema. Informar a los usuarios la necesidad de suspender o reanudar operaciones.  Apoyar las tareas de recuperación en caso de necesidad.

4 FASE DE NOTIFICACIÓN Y ACTIVACIÓN 4.1 Plan de notificación En el evento de desastre o daño en el sistema de información se seguirán los siguientes lineamientos de notificación: •

Quien detecte el problema llamará al Coordinador y le suministrará la información disponible sobre el daño.

El coordinador Pre-evalúa la dimensión del evento y determina cuales de los miembros del equipo deben ser requeridos.

La comunicación con los miembros del equipo se hará vía telefónica según los horarios o disponibilidad de las personas (Teléfono de oficina, Teléfono Celular, Teléfono de residencia).

4.1.1 Árbol de llamada El método común de notificación es un árbol de llamada. Donde se ve la asignación de funciones de notificación a los roles involucrados en este plan, que a su vez se encargan de informar a los demás la recuperación del sistema. Coordinador

Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 6 de 21 Coordinador Suplente

Líder de Recuperación de Base de Datos

Administrador de LAN/WAN

Administrador Sistemas (HW y SO)

Coordinador de SIFI

Técnico de Comunicaciones Claro

4.2 Evaluación de daños El equipo de evaluación de daños está conformado por los siguientes miembros del equipo: • • • • •

Coordinador DBA Administrador de LAN/WAN Administrador de Sistema(HW y SO) Coordinador de SIFI (Opcional)

Cada uno debe evaluar el impacto del daño en su área de influencia y entregar un informe sobre los siguientes aspectos: • • • • • • •

Causa de la emergencia Potencial de generar daños adicionales Áreas afectadas Estado de la infraestructura Tipo de daño en la infraestructura Ítems a ser restaurados o remplazados Tiempo estimado para restaurar los servicios

4.3 Activación del plan Una vez evaluados los daños se establecerá si fueron comprometidos los componentes de Base de Datos y servidor de Terminal Server de SIFI. Si la evaluación indica que la operación en el sitio principal no se puede reanudar en los tiempos de recuperación definidos por la matriz de tiempos críticos, por sistema se debe activar este plan de contingencia.

5 FASE DE RECUPERACIÓN EN SITIO ALTERNO La recuperación se centra en la ejecución de medidas de contingencia y la capacidad de procesamiento para reparar los daños causados al sistema original, y restablecer la capacidad operacional en el sitio alterno. Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 7 de 21

5.1 Secuencia de actividades de recuperación Esta es la secuencia de acciones a ejecutar para activar la contingencia: Coordinador: El coordinador informará al Líder de SIFI sobre el momento de la suspensión de la operación (si esta no se ha dado o es una suspensión planeada). DBA – Administrador Sistema: Obtener claves para acceder al sitio remoto: Sistema operativo, usuarios privilegiados de BD. DBA: Validar con los administradores de LAN y WAN los requerimientos de operación para la contingencia del sistema de información de SIFI. DBA: Validar con el administrador del sistema (Sistema Operativo y Hardware) los requerimientos de operación para la contingencia del sistema de información de SIFI. DBA: Validar el acceso remoto a los servidores del sitio de contingencia. Coordinador: Notificar al Coordinador de SIFI sobre la activación de la contingencia y el momento esperado de restauración de la operación del sistema de información. DBA: Suspender operaciones del sistema de información en nodo principal si alguna sigue vigente. DBA: Hacer switchover de BD a sitio de contingencia. DBA: Hacer failover de BD si el Switchover no fue posible. DBA: Activar cambios a los clientes para conexión a sitio alterno. DBA: Actualizar componentes de otros sistemas que tengan dependencias con el actual. DBA: Activar procedimientos para procesos batch. Coordinador: Notifica a los usuarios finales la normalización de la operación utilizando la infraestructura alterna.

Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 8 de 21

5.2

Diagrama de flujo de recuperación en sitio alterno.

RECUPERACIÓN EN SITIO ALTERNO Coordinador

Administración HW Y SW

DBA

Administración LAN/WAN

Seguridad Informática

Informar al líder de FIDUCIAR la suspensión de la operación Obtener claves de: Sistema operativo y Usuarios BD

Proveer claves sitio alterno

Validar requerimientos de operación de LAN y WAN Garantizar la comunicación a servidores de BD y aplicaciones de contingencia Validar requerimientos de operación de Hardware y Software Garantizar el espacio, capacidad y disponibilidad de los servidores de BD y aplicaciones de contingencia

Validar requerimientos del servidor de aplicaciones de contingencia

Suspender operaciones en sitio principal

Hacer Switchover de BD a sitio de contingencia

Switchover fue posible?

No Hacer Failover de BD

Si Activar cambios para conexión a sitio alterno

Actualizar componente que tengan dependencias

Notificar a usuarios finales la normalización de la operación

5.3 Procedimientos de recuperación Se incluyen a continuación los procedimientos técnicos de recuperación relativos al servidor de base de datos.

Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 9 de 21

5.3.1 Direcciones de Red SERVIDOR

NOMBRE SERVIDOR IP

PRODUCCIÓN FCBDP03 CONTINGENCIA FCBDC01

192.168.123.55 192.168.7.2

5.3.2 Obtener claves Para ejecutar los procedimientos de recuperación se debe tener disponibilidad de la siguiente lista de claves: RESPONSABLE

DBA DBA DBA DBA

CLAVE SERVIDOR

USUARIOS

Servidor de BD principal“Usuario Oracle” Servidor de BD remoto “Usuario Oracle” BD principal Sys, system BD remota Sys, system

TIEMPO (MIN)

0.2 0.2 0.2 0.2

5.3.3 Validar requerimientos de RED El Administrador de LAN/WAN garantizará la disponibilidad de los recursos de red necesarios para el sistema de información. RESPONSABLE

ACCIÓN

Administrador de Garantizar el acceso a servidor de contingencia: LAN/WAN BD IP:192.168.7.2 Puertos: 3389, 1521, 21 Para garantizar el acceso desde cualquier maquina agregar la ruta 192.168.7.2 por la puerta 192.168.123.253 Administrador de Conexión desde un cliente al servidor de BD de LAN/WAN contingencia: Ping 192.168.7.2 Administrador de Garantizar un ancho de banda entre la red de los LAN/WAN usuarios finales y el centro de cómputo alterno.

TIEMPO (MIN)

1

0.5 0.5

5.3.4 Validar Requerimientos de operación alterna

RESPONSABLE

Administrador y SO) Elaboró: Magda Herrera Fecha: Junio de 2012

ACCIÓN

Sistema(HW Espacio disponible para crecimiento de la BD Revisó: Fredy Parroquiano Fecha: Octubre de 2012

TIEMPO (MIN)

2

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 10 de 21

Administrador y SO) Administrador y SO)

Sistema(HW Capacidad de procesamiento del nuevo servidor Sistema(HW Disponibilidad de memoria RAM

2 2

5.3.5 Validar acceso remoto a servidores de contingencia RESPONSABLE

ACCIÓN

DBA

Verificar que se puede acceder a las consolas remotas (ssh) utilizando las claves facilitadas por seguridad informática.

DBA

TIEMPO (MIN)

1

Verifique la conectividad de la red entre el sitio principal y el de secundario. Realice un ping desde el sitio principal al secundario.

0.5

5.3.6 Suspender operaciones del sistema de información en el sitio principal RESPONSABLE

DBA

DBA

ACCIÓN

TIEMPO (MIN)

Verificar que no haya ninguna sesión de los usuario en la base de datos, de otro modo eliminarlas. Para esta labor utilizar Toad: Select „Alter System Kill Session („ || Sid || „,‟ || Serial# ||‟) Immediate;‟ From v$session Where Username Not In („SYS‟, „SYSTEM‟‟) And Type <> „BACKGROUND‟; Habilitar en modo restringido la BD sitio principal SHUTDOWN STARTUP RESTRICT

5

0.20

5.3.7 Procedimiento de Switchover En una operación de switchover las bases de datos principal y de contingencia invierten sus roles. Los pasos descritos a continuación permitirían regresar al sitio principal la operación de la base de datos sin mayor esfuerzo.

Nota: para las siguientes operaciones tener en cuenta las definiciones del numeral 3.4. N o

1

RESPONSAB LE

DBA

TIEMP O (MIN)

ACCIÓN

Verificar que la bases de datos del sitio primario y secundario están sincronizadas. Para esto validar la copia de los archive log y su aplicación. Select sequence#, first_time from v$log_history;

Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012

2


Plan de Contingencia Tecnología Página 11 de 21

2

DBA

2

DBA

3

DBA

4

DBA

5

DBA

6

DBA

7

DBA

Abrir el alert log de la base de datos para mantener un control sobre los mensajes del sistema. Verifique que la instancia en el sitio principal este abierta. SELECT STATUS FROM V$INSTANCE; La salida debe ser OPEN Verifique que la instancia en el sitio secundario este montada. SELECT STATUS FROM V$INSTANCE; La salida debe ser MOUNT Verificar que los LISTENER se encuentren arriba en el sitio principal y secundario. En la línea de comandos $ lsnrctl status $ lsnrctl status LISTENER_FID Verifique la configuración del modo archivelog de la BD del sitio secundario (debe estar en modo archivelog). SQL>SELECT LOG_MODE FROM V$DATABASE;

LOG_MODE -------------------ARCHIVELOG (está en modo archivado)

Archive los redo actuales en producción: SQL>alter system archive log current; Este comando archiva todos los grupos de redo. Detener los procesos de copia de archive log del sitio primario al secundario. Para realizar este paso se debe comentariar el archivo de crontab, en la línea que envía el proceso de copia.

DBA

0.5

0.5

0.5

0.5

0.5

$crontab –e

1

Agregar un # al principio de la línea */8 * * * /home/oracle/scripts/bin/copiar_archive.sh

8

1

Detener el proceso los archivos de contingencia. Para realizar este archivo de crontab, de copia.

*

de sincronización el cual aplica archivelog, en el sitio de paso se debe comentariar el en la línea que envía el proceso

$crontab –e Agregar un # al principio de la línea Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012

1


Plan de Contingencia Tecnología Página 12 de 21

*/15 * * * * /home/oracle/scripts/bin/sincronizar.sh

9

DBA

Crear un archivo de control y enviarlo al sitio remoto. SQL>alter database backup controlfile to trace noresetlogs; Este archivo de trace genera el script para generar el archivo de control1 en el sitio primario, el cual debe estar disponible a sitio remoto. Y se crea en la ruta:

1

$ORACLE_BASE/admin/FIDUCIAR/udump Con el comando ls –ltr se verifica cuales fueron los últimos archivos creados. Para saber cual archivo es que buscamos.

1 0

DBA

Shutdownimmediate o normal a la base de datos del sitio principal. SQL>shutdownimmediate; Verifique que se bajo exitosamente la base de datos validando el archivo de alert_ FIDUCIAR.log, que se encuentra en $ORACLE_BASE/admin/FIDUCIAR/bdump:“Complete

1

d: ALTER DATABASE CLOSE NORMAL” 1 1

DBA

1 2

DBA

1 3

DBA

1 4

DBA

1 2

Copie los archivos de redo del sitio primario al sitio remoto a la adecuada ubicación. Los anteriores se renombran con mv. Asegure que todos los archivos son enviados a la standby.2 Copiar los últimos archive logs del sitio primario al secundario. scp archive oracle@192.168.7.2:/archive/FIDUCIAR

log

Copiar el scripts del archivo de control de la base de datos primaria a la standby. Verificar la ruta de los control file: sqlplus> show parameter control Verificar parámetros log_file_name_convert y DB_FILE_NAME_CONVERT , que tengas la rutas correctas. Sqlplus> show parameterconvert Aplicar los últimos archives con cualquiera de las dos opciones y cancele la recuperación.

60

10

1

0.5

Ver anexo A de creación de archivo de control. Ver anexo B copia de archivos dentro y fuera del ASM Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 13 de 21

1 5

DBA

SQL> recover standby database; SQL> recover automatic standby database; Cancelar con cualquiera de las dos opciones: SQL> alter database recover managed standby database cancel; SQL> cancel; Shutdownimmediate o normal a la base de datos standby. SQL>shutdownimmediate; Verifique que se bajo exitosamente la base de datos validando el archivo de alert_SID.log: “Completed:

1

ALTER DATABASE CLOSE NORMAL and ALTER DATABASE DISMOUNT”

Ejecute la creación del archivo de control (Ver anexo A). Modificar el archivo generado eliminando todos los comandos que estén fuera del comando CREATE CONTROL FILE.

Startupnomount( automatico)

1 6

DBA

no

es

necesario,

lo

hace

Createcrontrolfile. Eliminar el comando Recoverdatabase. Eliminar alter database open Eliminar los comandos después de alter database

1

open.

Es necesario modificar las rutas de los archivos de Base de Datos, con el editor vi en Linux ejecutar el siguiente comando

1 7

DBA

1 8

DBA

1 9

DBA

2 0

DBA

:%s/\+DATA/fiduciar/\/u02\/oradata\/FIDUCIAR/g Valide el estatus y la existencia de todos los archivos de datos y de redo. La base de datos queda montada, verificar con SQL>select open_mode from v$database; SQL>select name from v$datafile; SQL>select member from v$logfile; Se recuperan los cambios de los archivos de redo SQL>Recoverdatabase Iniciar la base de datos como la base de datos de producción SQL>alter database open; Validar la disponibilidad del archivo del tablespace temporal en el sitio secundario: Ejecutar: select file_name from dba_temp_files;

1

0.5 0.5

Si no retorno nada agregar el archivo temporal: Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012

1


Plan de Contingencia Tecnología Página 14 de 21

Ejecutar: ALTER TABLESPACE TEMP2 ADD TEMPFILE '/u02/oradata/FIDUCIAR/temp2_01.dbf' SIZE 20480M REUSE AUTOEXTEND OFF; 2 1

DBA

2 2

DBA

2 3

DBA

2 4

DBA

Conectar los clientes a la base de datos standby. Acá ya está abierta la base de datos de contingencia como producción. Crear un archivo de control para la standby , ejecutando: SQL>alter database create standby controlfile as „/tmp/switch/standby.ctl‟ Hacer un backup de los archivos de control de la base de datos primaria en una ruta alterna. Modificar las rutas del archivo de control generado en el paso anterior, según las ruta de los archivos de la base de datos del sitio primario (tener en cuenta que está en ASM) y copiar el nuevo archivo de control al sitio primario y renombrarlos de acuerdo al archivo de parámetros3:

2

0.5 1

+DATA /FIDUCIAR/control01.ctl +DATA /FIDUCIAR/control02.ctl +DATA /FIDUCIAR/control03.ctl

2

Verificar en el init que las rutas estén los parámetros: DB_FILE_NAME_CONVERT='u02/oracle/FIDUCIAR','+DATA/fidu ciar' LOG_FILE_NAME_CONVERT='u02/oracle/FIDUCIAR','+DATA/fid uciar'

Validar la existencia de todos los archivos de datos, redos y archivos de control para standby.

2 5

DBA

2 6

DBA

2 7

DBA

1

SQL>select name from v$datafile; SQL>select member from v$logfile; Iniciar y montar la base de datos primaria como la nueva base de datos standby SQL>alter database mount standby database pfile=‟ /u01/app/oracle/product/10.2.0/db_1/dbs/initFIDUCI AR.ora‟; Iniciar el paso de los archivos de log generados en la Base de datos Standby a la base de datos primaria.

1

5

scparchivelogoracle@192.168.123.55:/archive/FIDUCIAR 2 8

DBA

2 9

DBA

3

Verifique que la instancia en el sitio principal este montada. SELECT * FROM V$INSTANCE; Iniciar la recuperación SQL>recover standby database o recover managed

0.5 0.5

Tener en cuenta el procedimiento para copiar archivos desde y hacia ASM, del anexo B. Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 15 de 21

standby database. 3 0

DBA

Elaboró: Magda Herrera Fecha: Junio de 2012

Activar los procesos de copia y sincronización de los archive log.

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012

1


Plan de Contingencia Tecnología Página 16 de 21

5.3.8 Procedimientos para procesos batch Verificar la disponibilidad del servicio y liberar TIEMPO (MIN)

RESPONSABLE

ACCIÓN

Coordinador

Modificar el TNSNAMES.ora de los clientes. Notifica a los usuarios finales la normalización de la operación utilizando la infraestructura alterna.

Coordinador

15 5

5.3.9 Hacer failover si el switchover no es posible Si la operación de “switchover” no fue posible por falta de disponibilidad del nodo principal será necesario ejecutar un failover. Un “failover” implica usualmente perdida de información debido a que las últimas transacciones ejecutadas en el nodo principal no pueden ser transmitidas al nodo remoto RESPONSABLE

DBA

DBA

TIEMPO (MIN)

ACCIÓN Revise si fueron transmitidos todos los archivos de archive. En caso contrario: Ejecutar de ser posible “ALTER SYSTEM LOG CURRENT” en la BD primaria. Y mover los archivos faltantes al nodo secundario. En la base de datos del sitio alterno ejecutar: SQL> ALTER DATABASE RECOVER STANDBY DATABASE CANCEL;

1

MANAGED 5

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY Activar la base de datos del sitio alterno:

DBA

SQL>ALTER DATABASE ACTIVATE STANDBY DATABASE; Reiniciar la base de datos SQL>SHUTDOWN IMMEDIATE SQL> STARTUP La base de datos is abierta como base de datos primaria.

Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012

1


Plan de Contingencia Tecnología Página 17 de 21

DBA

Validar la disponibilidad del archivo del tablespace temporal en el sitio secundario: Ejecutar: Select file_name from dba_temp_file; Si no retorno nada agregar el archivo temporal: Ejecutar:

1

ALTER TABLESPACE TEMP2 ADD TEMPFILE

'/u02/oradata/FIDUCIAR/temp02.dbf' SIZE 20480M

5.4 Procedimientos de recuperación agencia Medellin. En caso de realizar el plan de contingencia asociado a pérdida total de los servicios de datos en la ciudad de Bogota se debe ejecutar el siguiente plan de acción: TIEMPO RESPONSABLE ACCIÓN (MIN) Comunicarse con el centro de soporte corporativo del proveedor de comunicaciones (CLARO). Solicitar el Admon Red. direccionamiento de los paquetes de datos de la red 10 192.168.1.0 de la ciudad de Medellín al centro de datos alterno de CLARO. (192.168.7.0) DBA

Ejecutar el procedimiento definido en el numeral 5.3

6 FASE DE RETORNO AL SITIO PRINCIPAL Se contempla en esta sección el proceso para restaurar la operación en el nodo principal. Hay múltiples posibles escenarios a considerar entre los que se debe evaluar si hubo pérdida de datos en el sitio principal y la base de datos sigue operando como Standby. Realizar “switchback” de la BD acorde a las actividades descritas en el numeral 5.3.7.

Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 18 de 21

7 ANEXOS 7.1 Anexo A- Creando un scripts del archivo de control Se puede crear el script para crear el archivo de control mediante el comando alter databasebackupcontrolfileto trace noresetlogsen la base de datos de producción. Este genera un archivo de trace en el directorio de userdump. La salida del archivo de trace necesita ser editada y enviada a la base de datos standby. Ejemplo de script creado con alter databasebackupcontrolfileto trace noresetlogs de la base de datos de producción se nombro controlfile.sql4 controlfile.sql STARTUP NOMOUNT pfile=„/u01/app/oracle/product/10.2.0/db_1/dbs/ initFIDUCIAR.ora‟ CREATE CONTROLFILE REUSE DATABASE "FIDUCIAR" NORESETLOGS ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 2920 LOGFILE GROUP 1 '+DATA/fiduciar/redo08.log' SIZE 50M, GROUP 2 '+DATA/fiduciar/redo09.log' SIZE 50M, GROUP 3 '+DATA/fiduciar/redo10.log' SIZE 50M DATAFILE '+DATA/fiduciar/system01.dbf', '+DATA/fiduciar/undotbs01.dbf', '+DATA/fiduciar/sysaux01.dbf', '+DATA/fiduciar/users01.dbf', '+DATA/fiduciar/ts_index_g_01.dbf', '+DATA/fiduciar/ts_index_m_01.dbf', '+DATA/fiduciar/ts_index_p_01.dbf', '+DATA/fiduciar/ts_pao_data.dbf', '+DATA/fiduciar/ts_pao_index.dbf', '+DATA/fiduciar/ts_table_g_01.dbf', '+DATA/fiduciar/ts_table_m_01.dbf', '+DATA/fiduciar/ts_table_p.dbf', '+DATA/fiduciar/ts_table_g_02.dbf', '+DATA/fiduciar/ts_table_m_02.dbf', 4

Este archivo debe ser modificado por los cambios de rutas entre los dos servidores. Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 19 de 21

'+DATA/fiduciar/ts_index_m_02.dbf' CHARACTER SET WE8MSWIN1252 ; MODIFICAR LAS RUTAS NECESARIAS HACIA CONTINGENCIA PUES NO TIENE ASM. Verificar parámetros log_file_name_convert y DB_FILE_NAME_CONVERT, que tengas la rutas correctas. 7.2 Anexo B- Copiando Archivos fuera y dentro del ASM Como los archivos de base de datos, se encuentran dentro del ASM, y la base de datos de contingencia esta sobre filesystem, se deben copiar los archivos de Redolog a filesystem primero dentro del servidor de producción y luego si copiarlos al servidor de contingencia. Para ello el proceso es el siguiente: Exportar las variables de entorno: $. oraenv Cuando pregunte por el SID de la base de datos ingresar $ +ASM Ejecutar ASMCMD $asmcmd Ubicarse en: asmcmd> +DATA/FIDUCIAR/ Ejecutar: asmcmd>cp asmcmd>cp asmcmd>cp asmcmd>cp asmcmd>cp asmcmd>cp

redo8.log /tmp/switch/redo8.log redo8a.log /tmp/switch/redo8a.log redo9.log /tmp/switch/redo9.log redo9a.log /tmp/switch/redo9a.log redo10.log /tmp/switch/redo10.log redo10a.log /tmp/switch/redo10a.log

Esto copiara los redologs a /tmp/switch, luego salir de ASMCMD con: asmcmd>exit

Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


Plan de Contingencia Tecnología Página 20 de 21

Por último copiar los archivos generados, con el siguiente comando para todos los archivos. scp /tmp/switch/redo*.log oracle@192.168.7.2:/home/oracle/switch Para copiar los archivos desde de filesystem a ASM, el proceso es: $. oraenv Cuando pregunte por el SID de la base de datos ingresar $ +ASM Ejecutar ASMCMD $asmcmd Ubicarse en: Asmcmd>cd +DATA/FIDUCIAR/ Ejecutar: asmcmd>cp asmcmd>cp asmcmd>cp asmcmd>cp asmcmd>cp asmcmd>cp

/tmp/switch/redo08.log +DATA/FIDUCIAR/redo08.log /tmp/switch/redo08a.log +DATA/FIDUCIAR/redo08a.log /tmp/switch/redo09.log +DATA/FIDUCIAR/redo09.log /tmp/switch/redo09a.log +DATA/FIDUCIAR/redo09a.log /tmp/switch/redo10.log +DATA/FIDUCIAR/redo10.log /tmp/switch/redo10a.log +DATA/FIDUCIAR/redo10a.log

Elaboró: Magda Herrera Fecha: Junio de 2012

Revisó: Fredy Parroquiano Fecha: Octubre de 2012

Aprobó: Jefe de Sistemas Fecha: Febrero 2012


anexo_1_plan_de_contingencia_tecnologia