AA2-Ev4 - Plan de Configuración y Recuperación Ante Desastres para El SMBD

AA2-Ev4- Plan de configuracin y
recuperacin ante desastres para

el SMBD
RECUPERACIN ANTE DESASTRES
ALCALDIA SAN ANTONIO DEL SENA
7 de julio de 2016
Autor: BARBARA MILENA SANCHEZ
DIEGO FERNANDO CALDERON
AA2-Ev4- Plan de configuracin y

recuperacin ante desastres para el SMBD
INTRODUCCION
En la mayora de empresas se han ido implantando durante los ltimos aos planes de
recuperacin ante desastres o DR (Disaster Recovery). Estos planes comprenden un conjunto de
recursos hardware, software y procedimientos que deben permitir a una empresa continuar
ofreciendo sus servicios (o los considerados mnimos) en caso de que ocurran problemas graves en
los sistemas informticos.
En el caso de Oracle y para intentar minimizar este tipo de problemas, existen configuraciones de
DR data guard que nos permiten mantener en ubicaciones fsicamente separadas sistemas de
contingencia denominados standby que podrn seguir dando servicio en caso de cada de los
AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016
sistemas principales.
El concepto de Alta disponibilidad o HA (High Availability) es indispensable en una empresa por lo

que DR. puede disponer de discos, o tarjetas de red duplicados en un servidor es una solucin de
alta disponibilidad (HA), disponer de un segundo servidor en otra ciudad replicado con el primero
es proteccin ante desastres (DR).
Finalmente existen las soluciones que nos aporta Oracle: las BDD Standby y el producto DataGuard
(que ya viene integrado en las BDD EE) .Solo aplicable para Enterprise Edition
Una BDD Standby fsica (existen Standby lgicas de las que hablaremos en otra ocasin) es una
copia bit a bit de nuestra BDD productiva, separada de sta varias decenas, centenares o miles
de kilmetros. Los cambios se trasmiten de la principal a la Standby y se aplican posteriormente en
sta.
Las trasmisiones de datos se realizan de manera comprimida y optimizada ocupando un mnimo de
ancho de banda, y los datos pueden aplicarse en la standby al momento o con un cierto retardo,
de manera que en caso de errores lgicos (modificacin o borrado por error de gran cantidad de
datos en la principal) se pueda ir a consultar los datos del pasado en la standby.
La arquitectura de un SGBD hace referencia al modelo interno de funcionamiento del sistema. Es

decir a las estructuras internas/fsicas que proporciona para el almacenamiento y su relacin con
las estructuras lgicas/conceptuales. Como es lgico, cada SGBD propone diferentes arquitecturas.
1.1 ESTRUCTURAS LGICAS DE LA BASE DE DATOS

En todas las bases de datos relacionales disponemos de estas estructuras lgicas para organizar la
informacin:
Tablas. Compuestas de filas y columnas en las que se almacenan los datos relevantes de
cada base de datos. La mayora de SGBD usan distintos tipos de tablas, pero en general
cuando se habla de tablas se habla del elemento lgico encargado de almacenar los datos.
Restricciones. Se definen al crear las tablas, pero se almacenan aparte. Estn disponibles
en el diccionario de datos y marcan las reglas que han de cumplir los datos para que se
consideren vlidos.
ndices. Se trata de una lista ordenada de claves que permite acceder a los valores de una
o ms columnas de una tabla de forma veloz.
Vistas. Son consultas almacenadas que nos permiten mostrar de forma personalizada los
datos de una o varias tablas.
Procedimientos y funciones. Cdigo del lenguaje procedimental de la base de datos

utilizado para ejecutar acciones sobre las tablas (incluidos los triggers).
1. ARQUITECTURA
1.2 ESTRUCTURAS FSICAS E INTERNAS DE LA BASE DE DATOS

Al final todos los elementos lgicos se deben almacenar en archivos cuyo tamao, direccin,... etc.
debe de ser controlado por el DBA. En los distintos tipos de SGBD hay variaciones sobre las
estructuras lgicas, en el caso de las fsicas su diferencia puede ser total, lo que obliga a conocer
muy bien la parte interna del sistema concreto que estemos utilizando.
Las estructuras internas permiten analizar un nivel intermedio entre estructuras lgicas (como las
tablas) y las fsicas (como los archivos). Por ejemplo, Oracle proporciona espacios de tabla o
tablespaces para aglutinar distintos elementos lgicos con distintos elementos fsicos a fin de
optimizar el rendimiento de la base de datos.
1.3 INSTANCIAS DE BASES DE DATOS

Los usuarios que deseen conectarse a una base de datos, se conectan a lo que se conoce como la
instancia de la base de datos (del ingls instance). En el modo ms sencillo de trabajo, el usuario
dispone de un software en su mquina local, por lo que se encuentra en el lado del cliente, capaz
de conectar con el SGBD. En ese momento se lanza un proceso de usuario. Ese proceso deber
comunicarse (a travs de las redes apropiadas) con el proceso de servidor, un programa lanzado
en el lado del servidor que est permanentemente en ejecucin.
El proceso de servidor comunica a su vez con la instancia de la base de datos, otro proceso en
ejecucin a travs del cual se accede a la base de datos.
Ilustracin 1, Proceso de trabajo con la instancia de una base de datos
En el caso de bases de datos distribuidas, habr varias instancias de base de datos con capacidad
de atender concurrentemente ms usuarios.
1.4 QU ES UN SERVIDOR ORACLE?

Un servidor Oracle se considera al conjunto formado por la base de datos y la instancia de la
misma. Entender la comunicacin de estos dos elementos, es conocer el funcionamiento del
servidor.
Ilustracin 2, Arquitectura interna de Oracle
I n st a n c i a D e O r a c l e
Es el conjunto de procesos del servidor que permiten el acceso a la base de datos. Es un conjunto
de estructuras de datos y procesos en memoria. Est formado por:
S G A . A r e a g l ob a l d e si s t e m a . Se trata de la zona de memoria comn para todos los
procesos de servidor, contien las siguientes estructuras de datos fundamentales:
B u f f e r d e c a c h d e b a se de da t os . Almacena bloques de datos ledos de la base

de datos a fin de que las prximas consultas no necesiten acudir a disco y se las pueda
servir de estos datos en la cach.
B u f f e r r e d o l og . Estructura que almacena los datos anteriores y posteriores a cada

instruccin y as facilitar tanto su anulacin, como su realizacin en caso de problemas.
1.4.1 A rquitectura en memoria del servidor Oracle
L a r g e p ool . rea de la memoria que proporciona espacio para los datos necesarios para
realizar operaciones de backup y restauracin, as como los datos de sesin y otros que
permitan aliviar el trabajo de la instancia.
S h a r e d p o ol . Consta de la cach del diccionario de datos y de la cach de instrucciones

SQL, PL/SQL. De esa forma se acelera la ejecucin de consultas e instrucciones que
utilicen los mismos metadatos o bien que se traten de instrucciones parecidas a otras
anteriormente ejecutadas.
J a v a P o ol . Slo se usa si hemos instalado Java para agilizar el proceso de las

instrucciones en ese lenguaje.
P r oc e s o s
en
se g u n d o
p l a n o.
Programas
en
ejecucin
que
realizan
las
tareas
fundamentales sonre la base de datos, entre ellos:
D B W R . Escribe los datos del buffer de cache de la base de datos de la SGA a la base de
datos en disco (a los archivos de datos). Eso no ocurre en todo momento, sino cuando se
produce un evento de tipo checkpoint. Un checkpoint ocurre cuando se ha consumido un
tiempo determinado por el DBA, que se establece para que cada cierto tiempo los datos
pasen a grabarse en ficheros de datos y as asegurarles en caso de problemas. El hecho de
que esto se haga solo cada cierto tiempo (el tiempo establecido para el checkpoint) se
debe a que, de otro modo, el funcionamiento sera muy lento si se accediera ms a
menudo al disco.
L G W R . Es el proceso que genera escrituras secuenciales en los redo logs (archivos log de
rehacer) que son los archivos que guardan la informacin necesaria para poder recuperar
un estado anterior en los datos. Las instrucciones DML estn limitadas por la velocidad de
este proceso al guardar los datos. LGWR escribe desde el buffer del cach redo en el SGA
hacia los archivos redo en disco.
C K P T . Proceso encargado de comunicar la llegada de un checkpoint, punto de control que

ocurre cclicamente (y que se puede modificar poe el DBA) tras el cual se deben de escribir
los datos de memoria a los archivos de datos.
S M O N . System Monitor. Proceso encargado de monitorizar el sistema para que funcione

correctamente tras un error grave. Adems se encarga de la optimizacin del sistema
mejorando el espacio en disco y elimando definitivamente (mediante rollbacks) datos
irrecuperables.
P M O N . Process Monitor. Se encarga de la comunicacin con la PGA y especialmente con

el proceso servidor para manejar la conexin con el cliente, eliminado transacciones de
usuarios errneas (por desconexin por ejemplo) y liberando la memoria que se reserv
para los usuarios.
A R C n . Proceso de archivado de los archivos Redo. Sirve para que esos datos siempre
estn disponibles. Slo funciona en modo ARCHIVELOG de la base de datos, se explica ms
adelante.
PGA
La Program Globasl Area o rea global de programa, es la memoria que se reserva por cada
usuario para almacenar los datos necesarios para la conexin de un usuario con la base de datos.
Cada conexin tiene su propia PGA con los datos a los que accede el proceso servidor. Entre los
datos que almacena estn:
La informacin sobre la sesin con el cliente
El estado de procesamiento de la instruccin SQL actual
Datos de cach para acelerar algunas instrucciones SQL (como por ejemplo ndices
temporales)
P r oc e s o S e r v i d o r y P r oc e s o C l i e n t e
El proceso cliente es el programa en la memoria de la mquina en la que el usuario ha conectado
con Oracle. Este proceso se comunica con un proceso servidor que es lanzado cuando el cliente
establece conexin con Oracle.
compartida de proceso servidor. Cuando el proceso cliente y el servidor establecen conexin, se

crea la sesin de usuario, que es manejada por el proceso servidor. El proceso de usuario no puede
acceder directamente a la base de datos.
Ilustracin 3, Funcionamiento del proceso servidor y de usuario
1.4.2 ARQUITECTURA EN DISCO DE ORACLE

E s t r u c t u r a s l g i c a s d e a l m a c e na m i e nt o de O r a c l e
tablespaces
Los espacios de tabla o tablespaces, son una organizacin lgica interna de datos de Oracle que
puede aglutinar varios archivos de datos.
Puede haber un mismo proceso servidor para ms de un cliente en caso de una configuracin
Los datos que un usuario de la base de datos ve en tablas, al final proceden de algn archivo de
datos en disco. Entre una ptica (la lgica de las tablas) y otra (la fsica de los archivos de datos),
est el elemento que Oracle denomina tablespace (espacio para tablas).
Ilustracin 4, Esquema bsico de funcionamiento de los tablespaces de Oracle
Por defecto Oracle proporciona los espacios de tabla USERS (para los usuarios) SYSTEM (para los
objetos del sistema) y SYSAUX (apoyo a SYSTEM); pero, lgicamente, podemos crear otros y
asignarles los archivos de datos que deseemos.
Segmentos
En cada archivo de datos existen segmentos, que estn relacionados directamente con un objeto
de la base de datos y que sera reconocible por un usuario de la base de datos. Hay cuatro tipos de
segmentos: de datos, de ndice, temporales y de anulacin (ste ltimo slo disponible en el
espacio de tabla SYSTEM).
El mismo segmento puede estar presente en ms de un archivo de datos (como en la Ilustracin 4
ocurre con el segmento que almacena la tabla 3)
E x t e n si o n e s
Los segmentos se dividen en extensiones, que es el espacio que crece de golpe en un archivo
cuando el objeto que se almacena en el segmento. Una extensin no puede ocupar ms de un
archivo.
Bloques
Es el elemento de datos ms pequeo distinguible por Oracle. Cada extensin se compone de una
serie de bloques. EL tamao de bloque se puede configurar por parte del DBA para optimizar el
rendimiento. Cada bloque de datos de Oracle equivale a uno o ms bloques de datos del Sistema
Operativo. Es decir si en un disco concreto, el Sistema Operativo tiene un tamao de bloque de
16KB, slo podremos asignar en Oracle tamaos de bloque de 16, 32, 48, 64 etc. Kilobytes.
Ilustracin 6, Correspondencia entre los distintos elementos fsicos y lgicos de Oracle
Archivos de Oracle
A r c h i v o s d e d a t os
Son los archivos que almacenan los datos en s de la base de datos. Su estructura est comentada
en la ilustracin anterior.
A r c h i v o s d e l r e g i s t r o r e h a c e r ( r e do l o g)
Los redo log son dos o ms archivos que almacenan los cambios que se van registrando en la base
de datos. Graban las instrucciones ejecutadas y los datos necesarios para volver a realizarlas. Son
Ilustracin 5, Arquitectura de los tablespaces
al menos dos, para asegurar que uno siempre recoge los cambios de la base de datos mientras el
otro se almacena en disco.
Su funcionamiento es circular. Es decir se graba la informacin en uno y cuando se llena se pasa al
siguiente. Tras llenar el ltimo, comenzaremos de nuevo por el primero. Su nmero y
funcionamiento se puede configurar
A r c h i v o s d e l r e g i s t r o r e h a c e r a r c hi v a do s ( a r c hi v e r e d o l o g)
La base de datos puede funcionar en modo ARCHIVELOG o NOARCHIVELOG. La razn es que al
serlos archivos redo log una estructura circular, podemos perder datos por ello en modo
ARCHIVELOG la base de datos va copiando los archivo redo a medida que se llenan y as
aseguramos que no perdemos datos. Estos archivos con copia de los redo son los archivos redo
archivados o rehacer archivados.
A r c h i v o s d e c o n t r ol
Se trata de archivos binarios y de tamao pequeo que contienen la estructura de la base de
datos, es decir los metadatos. Este archivo tambin se puede multiplexar, con lo que puede haber
varios.
Nombre de la base de datos
Fecha y hora de la creacin de la base de datos
Informacin sobre checkpoints y redo logs.
Modo de archivado de la base de datos.
Nmero de secuencia del redo log actual.
Metadatos para backup y recuperacin de datos.
Archivos de parmetros
Comentados en el tema uno. Contienen los parmetros generales de configuracin de la base de
datos
Archivos de contraseas
Contienen la lista de contraseas cifradas, en caso de que sta sea la forma de autentificar
usuarios (segn lo comentado en el tema uno).
Archivos de traza
Permiten establecer el seguimiento de los errores de procesos como PMON o SMON o para
conexiones concretas.
A r c h i v o s d e c o p i a d e se g u r i d a d
Imprescindibles para la recuperacin de la base de datos en caso de desastre.
2. INSTALACIN DE SGBD
A la hora de instalar el Sistema Gestor de la Base de Datos necesitamos primero hacer un
planteamiento de necesidades a fin de encontrar el ms apropiado para resolver el problema.
2.1 PASO 1: SELECCIN POR REQUISITOS

Se trata de analizar qu necesitamos del SGBD. En este sentido algunas cosas a tener en cuenta
pueden ser:
T a m a o d e l a b a se d e da t o s. Un gran tamao de base de datos requiere se

software muy potente para la gestin de la misma, adems podra plantear el hecho de
separar los datos en distintas unidades de disco o incluso mquinas lo que podra requerir
clsteres o sistemas distribuidos.
C o ne c t i v i d a d . Si necesitamos que la base de datos sea accesible desde Internet, una

Intranet o incluso si bastara con un solo equipo de acceso.
N m e r o d e u s u a r i o s . Un nmero grande de usuarios requiere controles avanzados de

seguridad.
N m e r o d e c on e x i o n e s si m ul t n e a s. Suele ser el punto lgido de requisitos, ya
que un gran nmero de conexiones simultneas implica SGBD con grandes capacidades de
trabajo concurrente y pocos Sistemas seran capaces de aceptarlo.
A p r ov e c h a m i e n t o d e h a r d wa r e . Puede ser que sea el propio hardware de la

empresa el que predetermine la seleccin al estar limitados por el mismo.
P ol t i c a d e e m p r e sa . Por ejemplo si la empresa tiene una poltica de impulso de

software libre o acuerdos con empresas concretas de software.
2.2 PASO 2: COMPROBAR REQUERIMIENTOS

Una vez seleccionado el SGBD ahora tenemos que asegurarnos de cumplir nosotros los requisitos
que exige. Todos los sistemas indican qu requisitos necesitan en cuanto a:
S i s t e m a s o p e r a t i v o s . No todos los SGBD son multiplataforma, lo normal es que sean

compatibles con unas cuantas plataformas: Windows, Linux, Unix,
P a q u e t e s o a p l i c a c i o n e s p r e i n st a l a da s . A veces se requiere que el sistema

posea algn software previo a la instalacin del SGBD. En el mundo Linux se suele requerir
de paquetes (como por ejemplo el compilador de C, o libreras especiales de entrada
salida,); en Windows es alguna actualizacin (como sus clsicos Service Pack) o software
de terceros que se requiere (como la mquina Java, el Framework .Net o un servidor web
concreto).
M e m o r i a R A M . Es el requisito que ms importa: ms RAM, ms ligero funciona el

sistema. Oracle en su versin 11g aconseja al menos 1 GB de RAM
P r oc e s a d o r . Se suele exigir un modelo y una velocidad mnima en el mismo.
D i s c o d u r o. Se exige un espacio mnimo de disco.
10
R e q u i si t o s d e r e d . Se puede exigir que el equipo tenga una funcin concreta como

que sea un servidor de dominio, o que tenga una conectividad particular (como una
direccin IP fija).
I n c o m p a t i b i l i d a d e s . A veces se indican productos con los que existen problemas de
compatibilidad.
11
3. CONFIGURACIN DE ORACLE
Al igual que MySQL, los comandos de Oracle tienen parmetros posibles para enviar. Normalmente
los parmetros se configuran en archivos especiales que son ledos por la instancia de Oracle antes
de iniciarse, para as hacerlo con la configuracin que indica el archivo (o archivos) de parmetros.
El archivo de parmetros puede ser:
1. Un archivo de texto (PFILE, acrnimo de Parameters File
2. Un archivo binario (SPFILE), acrnimo de Server Parameter File.
La recomendacin actual es utilizar un archivo binario, de hecho en la versin 11g estamos
obligados a que as sea. La razn es que permite su modificacin mediante el comando SQL: ALTER
SYSTEM y porque en binario la configuracin queda ms oculta.
En Oracle 11g el archivo de parmetros SPFile (que es el que se usa por defecto), est en:
L i n u x / U n i x . En ORACLE_HOME/dbs/spfileSID.ora, donde el SID es el identificador de la

base de datos.
W i n d o w s. En ORACLE_HOME/database/spfileSID.ora, donde el SID es el identificador de

la base de datos
En el caso de no disponer de SPFile, Oracle puede utilizar un archivo de texto para almacenar
parmetros. Su ubicacin sera:
L i n u x / U n i x . Est en ORACLE_HOME/dbs/initSID.ora. Por ejemplo:

/ u 0 1 / a p p / o r a c l e / 1 1 . 2 . 1 / db _ 1 / db s/ i ni t b b d d. o r a
W i n d o w s. Est en ORACLE_HOME\database\initSID.ora
3.2 ALGUNOS PARMETROS

En estos archivos los parmetros (en los binarios no se ve) se marcan as:
parmetro=valor
El valor puede ser una lista de valores separados por comas. Los comentarios se ponen con el
smbolo #. Algunos parmetros muy utilizados son:
d b _ n a m e = n o m b r e . Identificador de la base de datos
3.1 UBICACIN DEL ARCHIVO DE PARMETROS
12
d b _ d o m a i n = d om i n i o . Dominio al que pertenece la base de datos
c o n t r ol _ f i l e s= r u t a . Ruta a los archivos de control que se indique. Si no se indicara

alguno, se crea en el directorio del archivo de parmetros
p r o c e ss e s = n m e r o. Mximo nmero de procesos que podr lanzar la base de datos.
se s si o n s= n m e r o . Mximo nmero de sesiones concurrentes que se permiten.
s oc k e t = r u t a . Fichero o nombre de socket a usar en las conexiones locales.
l o g _ a r c h i v e _ d e s t _ n . Permite indicar el destino del archivos LOG de tipo REDO. n

puede ser un valor entre 1 y 31 (nmeros de archivo) y despus se puyeden indicar un
rosario de opciones para controlar exactamente lo que se graba.
d b _ r e c ov e r y _ f i l e _ d e st = r u t a . Permite indicar un directorio para la recuperacin de

la base de datos.
3.3 GESTIN DE LOS ARCHIVOS DE PARMETROS
Para gestionar archivos SPFILE usa esta instruccin:
13
Con esa instruccin se crea un archivo SPFILE usando los parmetros en uso actualmente (opcin
MEMORY) o a partir de los contenidos de un archivo de parmetros de texto (opcin PFILE). El
archivo SPFILE por defecto (si no se indica ruta) estar en el mismo directorio que el de texto, solo
que ahora en lugar de llamarse por ejemplo initdb1.ora sera spfiledb1.ora. El archivo SPFile por
defecto es el que usa Oracle al iniciar la base de datos. Ejemplos de uso:
Si en la instruccin anterior se indica destino para el SPFILE, entonces se tomar como copia de
seguridad, ya que el que acta es el archivo SPFILE por defecto.
Tambin se puede crear un archivo de texto de parmetros a partir de un archivo SPFile (de hecho
se usa mucho como copia de seguridad). Sintaxis:
Ejemplo
Crea un archivo de parmetros a partir de los parmetros en uso
3.4 MODIFICACIN DE PARMETROS EN CALIENTE

Los parmetros que se desea modificar, mientras se ejecuta la base de datos, se configuran con la
instruccin ALTER SYSTEM SET; algunos son dinmicos (su efecto se produce inmediatamente) y
S C O P E controla cuando se produce el efecto del parmetro:
S P F I L E . Significa que el comando modifica el archivo de parmetros SPFILE y sus efectos

se vern en el siguiente arranque.
M E M O R Y . El cambio se graba en memoria y se produce inmediatamente; pero como no

toca el archivo SPFILE, su efecto no ser inmediato.
B O T H . Hace ambas cosas.
El comando SHOW PARAMETERS muestra los parmetros que actan en la sesin actual; SHOW
SPPARAMETERS muestra los del archivo SPFILE que sea el actual. La vista V$PARAMETER contiene
los parmetros actuales de la sesin, V$SYSTEM_PARAMETER contiene los parmetros del sistema
y V$SPFILE los del archivo SPFILE se usen o no.
otros estticos (su efecto se produce tras el arranque). La sintaxis es:
14
4. FICHEROS LOG EN ORACLE

Hay mltiples archivos LOG para monitorizar los distintos aspectos de Oracle. Entre ellos:
A l e r t L O G . Registra sucesos de la gestin general de la BD.
LOG de
p r o c e s o s e n b a c k g r ou n d. Registra los sucesos provocados por los
procesos en ejecucin de Oracle.
L O G d e u s u a r i o s . Monitoriza la actividad de los usuarios.
Se gestionan normalmente con el Enterprise Manager, pero es posible hacerlo con las vistas del
diccionario de datos, como V$DIAG_INFO para el alert log.
15
5. RECUPERACIN ANTE DESASTRES

Las mejores prcticas de recuperacin ante desastres (DR) empresarial consisten, principalmente,
en el diseo y la implementacin de sistemas de software y hardware con tolerancia a fallos que
pueden sobrevivir a un desastre (continuidad empresarial) y reanudar las operaciones normales
(reanudacin empresarial) con una intervencin mnima y, en condiciones ideales, sin prdida de
datos. Construir entornos con tolerancia a fallos para cumplir con los objetivos de DR empresarial y
las limitaciones presupuestarias reales puede resultar costoso y demorar mucho tiempo; adems,
exige un fuerte compromiso de la empresa.
Los planes de DR suelen abordar uno o ms de los siguientes tipos de desastres:
Daos significativos de las instalaciones de TI debido a un desastre natural (terremoto,

huracn, inundacin, etc.) u otras causas (incendio, vandalismo, hurto, etc.).
Prdida significativa de servicios crticos de las instalaciones de TI, por ejemplo, prdida de
alimentacin, refrigeracin y acceso a la red.
Prdida de personal clave.
El proceso de planificacin de DR comienza con la identificacin y la caracterizacin de los tipos de

desastres a los que debe sobrevivir una empresa para, luego, reanudar sus operaciones. El proceso
de planificacin identifica requisitos de alto nivel de continuidad empresarial (BC) y reanudacin
empresarial (BR), entre ellos, el nivel necesario de tolerancia a fallos. A partir de la planificacin de
DR se genera una arquitectura de recuperacin y reanudacin para sistemas, aplicaciones y datos
con tolerancia a fallos, a fin de satisfacer estas necesidades sujetas a limitaciones establecidas.
Normalmente, las limitaciones de DR son el objetivo de tiempo de recuperacin (RTO), el objetivo
de punto de recuperacin y el presupuesto disponible. La arquitectura de DR junto con las
limitaciones empresariales favorecen la creacin de procedimientos de DR que integran todos los
elementos del sistema de una manera verdaderamente integral para garantizar resultados
predecibles en relacin con el proceso completo de DR.
Los sistemas con tolerancia a fallos, por lo general, alcanzan la solidez y la capacidad de
recuperacin mediante la redundancia. Un sistema completamente redundante, que suele lograrse
a un alto costo, no tiene un solo punto de fallo dentro de su arquitectura y puede funcionar durante
las operaciones y reanudarlas a partir del peor desastre posible dentro de sus lmites. Los sistemas
de control de vuelo de aviones y transbordadores espaciales son buenos ejemplos de sistemas
completamente redundantes. Las aplicaciones de TI menos crticas, por lo general, utilizan
sistemas menos resistentes y menos redundantes. La construccin de estos sistemas es menos
costosa, pero necesariamente implicar una interrupcin del servicio despus del desastre. Durante
esta interrupcin, la empresa trabajar para restablecer sus datos, aplicaciones y sistemas
recuperables.
16
En ltima instancia, la naturaleza de una empresa, las necesidades de los clientes y el presupuesto
disponible para DR son los factores clave para la determinacin de los requisitos de DR. Una
solucin integral de DR puede ser muy costosa, pero es necesario disearla. No puede tirar el
dinero, el hardware ni el software ante un posible desastre y tener la esperanza de sobrevivir y
reanudar sus operaciones empresariales. No obstante, aunque realice una planificacin y un diseo
inteligentes, es posible que se vea afectado por interrupciones ms prolongadas del servicio, un
servicio degradado, o ambos, hasta que se puedan reanudar todos los servicios, pero, de todas
maneras, puede contar con una solucin limitada y confiable de DR.
De todas maneras, debe entender que quizs no exista ningn nivel de planificacin que permita
anticipar todos los posibles escenarios de DR o responder a ellos. Por ejemplo, lo que comienza
como un problema aparentemente trivial de un sistema se puede propagar, con el transcurso del
tiempo, y afectar a otros sistemas de distintas maneras y, finalmente, causar un desastre para el
cual no hay una posible recuperacin. De manera similar, la capacidad de una empresa para
cumplir con los acuerdos de servicio puede verse afectada si las suposiciones clave no resultan
ciertas, por ejemplo, si el servicio o las piezas clave no se encuentran disponibles, o si la capacidad
de prestacin del servicio del proveedor de DR no es tan slida como se promociona. No obstante,
lo ms importante que se debe tener en cuenta es que si ocurre un desastre que supera el peor
17
escenario para el cual usted se prepar, quizs la recuperacin no sea posible.
5.1 DEFINICIN DEL OBJETIVO DE TIEMPO DE RECUPERACIN

(RTO)
RTO es un objetivo de nivel de servicio del tiempo que lleva lograr la capacidad operativa deseada
despus de que ocurre un desastre. Por ejemplo, las necesidades de la empresa pueden
determinar un RTO en el que todos los sistemas de produccin funcionen al 80 % de la capacidad
previa al desastre en el plazo de los 30 minutos posteriores a una interrupcin no planificada del
servicio de ms de una hora (si no existiera capacidad de DC). El tiempo de procesamiento de RPO,
la disponibilidad de personal calificado de TI y la complejidad de los procesos manuales de TI
necesarios despus de un desastre son ejemplos de limitaciones que pueden determinar el RTO. El
RTO no se aplica a los sistemas con tolerancia completa a fallos, porque estos sistemas se
recuperan implcitamente durante un desastre y despus de l, sin interrupcin del servicio.
Los planificadores de DR pueden establecer distintos RTO para algunos o todos los requisitos de BC
definidos. Los diversos tipos de operaciones empresariales pueden exigir distintos RTO, por
ejemplo, RTO diferentes para sistemas en lnea que para ventanas de lotes. Adems, se pueden
aplicar distintos RTO en las diversas etapas de un plan de DR en fases, en el cual cada fase tiene
un RTO definido. Incluso una aplicacin recuperable puede tener distintos RTO para cada uno de
sus diversos niveles de servicio.
Los requisitos de disponibilidad de los datos de BC son sumamente importantes para la

planificacin de RTO. Cuando los datos que se deben introducir en el proceso de DR no estn
presentes en el sitio de recuperacin ante desastres, el tiempo que lleve recuperar los datos en el
sitio demorar el RTO. Por ejemplo, llevar tiempo recuperar los datos que residen en almacenes
fuera del sitio. La recuperacin puede continuar rpidamente si los datos de entrada actualizados
estn duplicados en el sitio de recuperacin antes del comienzo de las operaciones de recuperacin
ante desastres.
5.2 DEFINICIN DEL OBJETIVO DE PUNTO DE RECUPERACIN

(RTO)
El RPO es un objetivo de continuidad empresarial que indica el estado o el nivel de actividad de la
empresa, y que se logra despus de que el proceso de recuperacin ante desastres ha restablecido
todos los sistemas recuperables. Conceptualmente, el RPO es un estado de sincronizacin objetivo
o una "reversin" que se conoce antes de que ocurra un desastre. Es decir, que el RPO es el punto
de recuperacin posterior a un desastre a partir del cual las aplicaciones recuperables
interrumpidas pueden reanudar el procesamiento. Todas las transacciones que ocurren durante el
sistemas con tolerancia completa ante fallos porque el desastre no afecta la continuidad
empresarial de estos sistemas.
En Figura 1-1, se ilustran los conceptos de RPO. En la imagen, se sugieren diversos puntos de
recuperacin para que tengan en cuenta los planificadores de DR. La planificacin debe garantizar
que el RPO deseado sea factible frente al RTO elegido y viceversa. Por lo general, los planes de
recuperacin ante desastres que exigen los RPO ms prximos al momento de un desastre
requieren una mayor tolerancia ante fallos y son ms costosos de implementar, en comparacin
con los RPO ms lejanos. Al igual que con los RTO, los planificadores de DR pueden establecer
distintos RPO para diferentes requisitos de BC, fases de los planes de DR o niveles de servicio de
las aplicaciones.
Figura 1-1 Objetivos de punto de recuperacin
intervalo entre el RPO y el momento del desastre son irrecuperables. El RPO no se aplica a
18
De
manera
ms
amplia,
la
planificacin
de
RPO
debe
identificar
todos
los
elementos
complementarios que deben estar presentes para restablecer cada sistema recuperable, incluidos
los datos, los metadatos, las aplicaciones, las plataformas, las instalaciones y el personal. La
planificacin tambin debe garantizar que estos elementos estn disponibles en el nivel deseado de
actividad de la empresa para recuperacin. Los requisitos de actividad de los datos de BC son
especialmente cruciales para la planificacin de RPO. Por ejemplo, si segn los requisitos de BO, se
requiere un RPO de una hora, cualquier dato o metadato que alimente el proceso de recuperacin
debe estar actualizado hasta el RPO, de lo contrario, no se puede alcanzar el RPO. Los procesos de
DR de la organizacin especificarn los procedimientos necesarios para alcanzar todos los RPO
definidos en el plazo de los RTO establecidos.
Los metadatos del sistema necesarios para la recuperacin del RPO incluyen estructuras de
catlogo de OS e informacin del sistema de gestin de cintas. Estos elementos de deben
actualizar durante el proceso de recuperacin ante desastres para activar todos los RPO elegidos.
Por ejemplo, para garantizar la coherencia entre las diversas entradas de metadatos en el proceso
de DR, los juegos de datos existentes que se recrearn en el RPO se deben descatalogar; los
juegos de datos actualizados entre el RPO y el momento del desastre se deben restaurar a la
versin que exista en el RPO o antes de este; y cualquier cambio de catlogo relacionado con
19
cintas debe estar sincronizado con el sistema de gestin de cintas.
5.3 MANEJO DE INTERRU PCIONES TEMPORALES

La recuperacin ante desastres ofrece reparacin para interrupciones muy prolongadas que pueden
dejar a un sitio de produccin inutilizable durante un perodo prolongado. Si bien el resto de esta
introduccin trata las prcticas de recuperacin ante desastres, sera igualmente importante
desarrollar procedimientos para mitigar las interrupciones relativamente breves que podran afectar
negativamente la produccin si no se controlan. Considere, por ejemplo, una interrupcin del
servicio en que ciertas funciones de hardware o de red permanecen no disponibles durante una o
dos horas, pero la produccin puede continuar durante esta interrupcin en modo degradado con
unos pocos y rpidos ajustes temporales. Un procedimiento de interrupcin temporal debe
documentar cmo aislar el problema, qu cambios realizar, a quin notificar y cmo regresar al
entorno operativo normal despus del restablecimiento del servicio.
5.4 CONCEPTO
SINCRONIZACIN
CLAVE:
RECUPERACIN
DE
PUNTO
DE
El reinicio de las aplicaciones de produccin en los RPO definidos es una actividad clave que se
realiza durante una verdadera recuperacin ante desastres y durante las pruebas de DR. Los
entornos de DR con mayor capacidad de recuperacin garantizan que cada aplicacin recuperable,
ya sea de terceros o desarrollada internamente, aplique un requisito clave de DR, a saber: que la
aplicacin est diseada para reiniciarse de un momento planificado denominado "punto de
sincronizacin", a fin de mitigar los efectos de una interrupcin no programada durante su
ejecucin. Cuando una aplicacin interrumpida se reinicia en un punto de sincronizacin, los

resultados son los mismos que si la aplicacin no hubiera sido interrumpida.
El procedimiento de reinicio para una aplicacin recuperable depende de la naturaleza de la
aplicacin y sus entradas. A menudo, el procedimiento de reinicio de una aplicacin para una
verdadera recuperacin ante desastres o pruebas de DR es el mismo procedimiento de que utiliza
para reiniciar la aplicacin en caso de que falle durante una ejecucin de produccin normal. En los
casos en que es posible, la reutilizacin de los procedimientos de reinicio de produccin para una
verdadera recuperacin ante desastres o pruebas de DR simplifica la creacin y el mantenimiento
de los procedimientos de DR, y aprovecha estos procedimientos probados. En el caso ms sencillo,
una aplicacin recuperable constituye un paso de trabajo nico con un solo punto de
sincronizacin, que es el comienzo del programa invocado por ese paso. En ese caso, el
procedimiento de recuperacin puede ser tan sencillo como volver a ejecutar el trabajo
interrumpido. Un procedimiento de inicio levemente ms complejo podra implicar que la aplicacin
deba descatalogar todos los juegos de datos de salida durante su ltima ejecucin y que, luego,
deba reiniciar la aplicacin.
entre los cuales se puede elegir pueden no ser tan sencillos. Las aplicaciones que usan tcnicas de
punto de control/reinicio para implementar estos puntos de sincronizacin registran peridicamente
su progreso y pueden, por ejemplo, usar la informacin registrada del punto de control para
reiniciarse en el ltimo punto de sincronizacin interna registrado antes de una interrupcin. Los
procedimientos de reinicio cumplirn con los requisitos de cada punto de sincronizacin. Mientras
los puntos de control estn en uso, los juegos de datos asociados con un punto de control no deben
caducar, no se deben descatalogar ni se deben reutilizar mientras el punto de control sigue siendo
vlido para la recuperacin de aplicaciones. Una manera sencilla de establecer un punto de
sincronizacin para un paso de trabajo que modifica sus juegos de datos existentes es hacer una
copia de seguridad de cada juego de datos modificable antes de ejecutar el paso. Estos juegos de
datos de entrada modificables se pueden identificar fcilmente al buscar el atributo de JCL
DISP=MOD en sentencias DD o en solicitudes de asignacin dinmica. Si un paso de trabajo falla o
se interrumpe, simplemente, deseche los juegos de datos de entrada modificados, restaure esos
juegos de datos de entrada de las copias de seguridad y reinicie el paso a partir de las copias
restauradas. Estas copias de seguridad tambin son tiles para reiniciar un paso de trabajo que
fall o se interrumpi, el cual haba caducado, descatalogado o reutilizado los originales.
5.5 RELACIN DE RPO CON LA RECUPERACIN DE PUNTO DE

SINCRONIZACIN
Cuando el RPO se alinea con un punto de sincronizacin, al realizar el procedimiento de reinicio de
la aplicacin que se desarroll para este punto de sincronizacin, se reanudar la aplicacin a partir
de este origen como si no se hubiera producido una interrupcin (Figura 1-2). Se supone que todas
las transacciones procesadas despus de este RPO hasta el desastre son irrecuperables.
Los procedimientos de reinicio para aplicaciones que tienen varios puntos de sincronizacin interna
20
Figura 1-2 El RPO en el punto de sincronizacin
En otros momentos, los requisitos de BC pueden justificar la ubicacin del RPO entre los puntos de
sincronizacin. En estos casos, la recuperacin de punto de intersincronizacin se basa en datos
complementarios que describen cualquier cambio o evento crtico relativo al estado de la aplicacin
que ocurre despus del establecimiento del punto de sincronizacin ms reciente. Considere, por
ejemplo, el RPO de un minuto antes de un desastre. Suponga que se disea una aplicacin
recuperable para usar puntos de control para registrar su progreso, pero suponga que la
sobrecarga que implica el uso de estos puntos de control a intervalos de un minuto no se puede
21
tolerar. Una solucin sera tomar estos puntos de control con menor frecuencia y registrar todas las
transacciones confirmadas entre los puntos de control. El log de esta transaccin se convierte,
luego, en datos de entrada complementarios utilizados por el proceso de recuperacin del punto de
control que se reiniciarn a partir de un RPO ms all del punto de sincronizacin ms reciente. En
este ejemplo, el procedimiento de reinicio de la aplicacin accede a los datos ms recientes del
punto de control y aplica el log de la transaccin complementaria para restablecer todas las
transacciones confirmadas procesadas despus del punto de control y antes del RPO (Figura 1-3).
De esta manera, la recuperacin de punto de sincronizacin puede alcanzar un RPO objetivo
mediante los datos de entrada de varios orgenes. Se supone que todas las transacciones
procesadas despus del RPO hasta el desastre son irrecuperables.
Figura 1-3 RPO entre puntos de sincronizacin
5.6 PLANIFICACIN PARA LA ALTA DISPONIBILIDAD DE DATOS (D HA)

Los datos suelen ser uno de los activos ms valiosos de una empresa. La mayora de las compaas
cuidan rigurosamente los datos empresariales crticos y realizan inversiones adicionales para
protegerlos contra la prdida y para garantizar que los datos estn disponibles para su objetivo
previsto cuando sea necesario. Una empresa que no puede hacer frente a la prdida de datos
crticos puede sufrir consecuencias desastrosas. Quizs la manera ms habitual de proteger los
datos contra la prdida es almacenar copias de datos crticos en distintos subsistemas o medios de
almacenamiento, y almacenar algunas de estas copias en distintas ubicaciones fsicas. Las copias
almacenadas en medios de almacenamiento extrables, entre ellas, las cintas de cartuchos
magnticos, los CD-ROM y los DVD suelen almacenarse en ubicaciones de almacenamiento
externas. Las copias adicionales tambin suelen almacenarse en el sitio, en instalaciones de TI en
que las aplicaciones pueden procesar los datos. La creacin y el almacenamiento de copias de
datos crticos aumentan la redundancia de los datos y mejora la tolerancia a fallos. Para los medios
extrables y, en particular, para las cintas de cartuchos magnticos, el solo hecho de aumentar la
redundancia de los datos no suele ser suficiente para garantizar que los datos tambin tengan alta
cintas virtuales de mainframe almacena datos en volmenes de cintas virtuales denominados MVC.
El sistema VSM puede hacer copias automticamente para mejorar la redundancia de los datos y
reducir el riesgo debido a un fallo de medios fsicos o a un cartucho de cintas mal colocado. Un
sistema de produccin VSM utiliza varios componentes de hardware especializados para recuperar
datos almacenados en un MVC, incluido un dispositivo de buffer de VTSS, una biblioteca de cintas
automatizada y unidades de cinta conectadas a bibliotecas (denominadas RTD), que tambin se
conectan al dispositivo de buffer de VTSS. Las aplicaciones host dependen de todos estos
componentes de VSM que funcionan juntos para recuperar datos de los MVC. Si bien la mayora de
las personas no considerara el simple fallo de un componente como un desastre equiparable a la
prdida de un centro de datos entero en un terremoto, ciertamente, podra ser imposible recuperar
datos de un MVC si un nico componente crtico de VSM falla sin una copia de seguridad,
independientemente de cuantas copias redundantes de MVC existan. Por lo tanto, si bien la
creacin de copias de MVC es una de las mejores prcticas comprobadas para mitigar la
vulnerabilidad y los riesgos, no siempre garantiza de forma suficiente la alta disponibilidad de los
datos (D-HA) en la presencia de fallos. Los requisitos de D-HA son requisitos clave de continuidad
empresarial para la planificacin de DR. Por lo general, la D-HA se logra aumentando las
redundancias para eliminar los puntos nicos de fallo que no permiten a las aplicaciones acceder a
los datos durante los fallos del sistema. Por ejemplo, un sistema VSM que incluye componentes
redundantes mejora la tolerancia a fallos del sistema VSM. La instalacin de varios dispositivos
VTSS, handbots redundantes de SL8500 y varias RTD tiene el propsito de eliminar los puntos
nicos de fallo de VSM de la ruta de datos de la aplicacin a los datos crticos almacenados en un
MVC. La arquitectura de VSM est diseada para admitir la agregacin de componentes
redundantes para aumentar la tolerancia a fallos promover la D-HA.
disponibilidad para las aplicaciones que los utilizarn. Por ejemplo, el sistema VSM de Oracle para
22
C i n t a f si c a d e a l t a d i sp o n i b i l i d a d
Las soluciones de automatizacin de cintas de mainframe de Oracle activan la D-HA para
aplicaciones de cinta fsicas mediante el almacenamiento de copias redundantes de datos en
distintos ACS dentro de un sistema TapePlex, es decir, dentro de un complejo de cintas asignado
por un solo CDS. Por ejemplo, las aplicaciones que se ejecutan en instalaciones de TI con un solo
sistema TapePlex pueden almacenar fcilmente copias duplicadas de juegos de datos de cintas en
uno o ms ACS dentro de ese TapePlex. Esta tcnica mejora la D-HA mediante la agregacin de
medios redundantes, transportes de cinta y bibliotecas de cintas automatizadas. En un caso simple,
una aplicacin almacena copias redundantes de juegos de datos crticos en dos cintas de cartuchos
distintas en una sola biblioteca SL8500 con electrnica redundante, handbots duales en cada gua y
dos o ms transportes de cinta conectados a la biblioteca en cada gua, que son compatibles con
los medios del juego de datos. Para eliminar la biblioteca SL8500 como un punto potencial nico de
fallo, se agrega una segunda SL8500 al ACS para almacenar copias aun ms redundantes del juego
de datos crticos. Para eliminar las instalaciones de TI como punto nico de fallo, las copias de
juegos de datos redundantes se pueden almacenar fuera del sitio o crear en un ACS remoto con
transportes de cintas mediante una extensin de canal (Figura 1-4).
23
Figura 1-4 Configuracin de cinta fsica FD-HA
Tambin puede hacer dos o ms copias de cintas fsicas en distintas ubicaciones fsicas cuando una
ubicacin tiene su propio CDS independiente, es decir, cuando el hardware de cada ubicacin
representa un TapePlex independiente. Al usar la funcin de cliente/servidor del SMC y definir
polticas para dirigir copias de juegos de datos a un TapePlex remoto, los trabajos pueden crear
copias de cintas en un ACS de otro TapePlex sin cambios en JCL.
C i n t a v i r t u a l d e a l t a d i sp o n i b i l i d a d
VSM ofrece tecnologas de agrupacin en clusters y creacin de varios complejos para replicacin
en MVC para activar la D-HA para cinta virtual de mainframe. La creacin de varios complejos para
replicacin en VSM implica la creacin de varias copias de MVC (por ejemplo, duplicados,
cuadruplicados) en uno o ms ACS para mayor redundancia (Figura 1-5). Los ACS que reciben
copias de las que se crean varios complejos para replicacin pueden ser bibliotecas locales o ACS
remotos con transportes de cinta mediante una extensin de canal. Las polticas de migracin de
VSM controlan el movimiento de VTV que residen en el buffer de VTSS a MVC locales o remotos,
Figura 1-5 Configuracin de creacin de varios complejos para replicacin en VSM para D-HA
Un cluster de VSM comprende dos o ms dispositivos VTSS (nodos) conectados en red para
intercambio de datos en un enlace de comunicaciones (CLINK). Los CLINK son canales
unidireccionales o bidireccionales. La configuracin de cluster de VSM ms sencilla consiste en dos
nodos VTSS en el mismo TapePlex enlazado con un CLINK unidireccional, pero, habitualmente, se
implementan CLINK bidireccionales (Figura 1-6). Cada nodo de cluster se puede ubicar en un sitio
distinto. Las polticas de almacenamiento unidireccional de VSM controlan la replicacin automtica
de volmenes de cintas virtuales (VTV) de VTSS A a VTSS B en un CLINK unidireccional. Las
polticas de almacenamiento bidireccional y los CLINK bidireccionales permiten que VTSS A se
replique en VTSS B y viceversa.
que pueden ser trasladados a almacenes externos.
24
Figura 1-6 Configuracin de cluster de VSM de D-HA
La agrupacin en clusters ampliada de VSM permite la conectividad de varios a varios entre tres o
ms dispositivos VTSS en un TapePlex para alcanzar niveles de disponibilidad de datos aun ms
25
altos (Figura 1-7). Como se muestra, la instalacin de dispositivos de cluster de VTSS en uno o
ms sitios dentro de un TapePlex aumenta la redundancia, ya que elimina cada sitio como punto
nico de fallo.
Figura 1-7 Configuracin de cluster ampliado de D-HA (no se muestran los almacenes externos)
La LCM de Oracle simplifica los procesos de almacenamiento en sitios externos para volmenes de
MVC mediante la gestin del proceso de reciclaje entre los almacenes y las bibliotecas de
produccin. La funcin de almacenamiento de LCM programa la devolucin de volmenes de MVC
almacenados cuando la cantidad de datos caducados supera un umbral especificado.
Un cluster de replicacin cruzada entre sistemas TapePlex (cluster CTR) de VSM permite que los
dispositivos de cluster de VTSS residan en distintos TapePlex y ofrece la capacidad de replicar VTV
de un TapePlex a uno o ms TapePlex distintos, lo que permite modelos de replicacin de clusters
de varios a varios en CLINK unidireccionales o bidireccionales (Figura 1-8). El envo y la recepcin
de TapePlex puede estar ubicado en distintos sitios. Los VTV replicados se introducen en el CDS del
TapePlex receptor como volmenes de solo lectura. Esto ofrece una proteccin de datos segura
contra la alteracin que pueden causar las aplicaciones que se ejecutan en el TapePlex receptor. El
CDS del TapePlex receptor tambin indica que las copias de VTV replicadas por CTR son propiedad
del TapePlex emisor y, como proteccin adicional, la CTR garantiza que un TapePlex no pueda
Figura 1-8 Configuracin de replicacin cruzada entre sistemas TapePlex de VSM de D-HA
D - H A y r e c u p e r a c i n d e p u n t o de si nc r o ni z a c i n
La creacin de varias copias de volmenes fsicos (MVC o distintos de MVC) mejora la redundancia
de los datos; no obstante, estas copias requieren consideraciones especiales para la recuperacin
de punto de sincronizacin. Lo ms importante de la recuperacin de punto de sincronizacin es
garantizar que los datos creados en un punto de sincronizacin se mantengan en un estado de solo
lectura mientras siguen siendo vlidos para uso en recuperacin ante desastres. Esto significa que
las copias de volmenes de cinta fsicos que se pueden usar para recuperacin ante desastres se
deben mantener en el estado de solo lectura. Una manera de hacer esto es enviar estas copias a
una ubicacin de almacn externo donde no hay capacidad de procesamiento de cintas. Es
importante tener en cuenta que las copias no protegidas que sufren alteraciones no se pueden
utilizar para recuperacin de punto de sincronizacin, porque el contenido actualizado deja de
reflejar el punto de sincronizacin asociado. Los entornos de cintas virtuales agregan una
dimensin adicional a la gestin de copias de varios volmenes para recuperacin de punto de
sincronizacin. Pueden existir copias de VTV en varios buffers de VSM y en varios MVC al mismo
tiempo. Incluso cuando todos los MVC de un determinado VTV se almacenan en un sitio externo,
modificar ningn VTV que no le pertenezca.
26
las copias de VTV que permanecen en el sitio en buffers de VSM pueden modificarse. No es posible
usar una copia actualizada de un VTV que reside en un buffer para recuperacin de punto de
sincronizacin, a menos que este VTV pertenezca a un nuevo punto de sincronizacin que invalide
las copias externas almacenadas para uso durante la recuperacin ante desastres.
5.7 REALIZACIN DE UNA VERDADERA RECUPERACIN ANTE

DESASTRES
El xito de una operacin de verdadera recuperacin ante desastres yace en contar con un sitio de
DR adecuado, personal capacitado, un procedimiento de DR comprobado, una carga de trabajo de
produccin recuperable con puntos de sincronizacin para cumplir con los RPO definidos y todos los
datos de entrada y metadatos del sistema necesarios para cumplir con estos RPO. Los datos de
entrada y los metadatos del sistema deben estar accesibles en el sitio de DR cuando se los necesita
y deben estar disponibles en los niveles de actividad necesarios. Con una planificacin minuciosa,
una preparacin rigurosa y una ejecucin de comprobada eficacia, las operaciones de verdadera
recuperacin ante desastres pueden fluir sin inconvenientes segn lo planificado para lograr los
RPO y los RTO definidos. Los datos de produccin generados en el sitio de DR deben estar
protegidos de manera adecuada mientras el sitio de DR funciona como sitio de produccin.
27
Suponga, por ejemplo, que la arquitectura de D-HA requiere una carga de trabajo de produccin
para replicar copias de datos redundantes en tres sitios remotos, y suponga que el sitio de DR es
uno de estos sitios de replicacin remotos antes de un desastre. Cuando el sitio de produccin
experimenta un desastre y su carga de trabajo se traslada al sitio de DR, este sitio ya no puede
funcionar como sitio de replicacin remoto para la carga de trabajo de produccin que ahora se
ejecuta localmente en dicho sitio. Para cumplir con el requisito de D-HA de tres sitios de replicacin
remotos, se debe agregar un nuevo tercer sitio de replicacin remoto durante el perodo en que la
produccin se mantenga en el sitio de DR. Este ejemplo ilustra de qu manera un anlisis
exhaustivo de los requisitos de D-HA permite a los planificadores de DR abordar todos los
requisitos crticos de D-HA que se deben cumplir cuando la produccin se traslada a un sitio de DR.
Un plan integral de DR comprende no solamente las actividades para restablecer la produccin en
el sitio DR, sino que tambin incluye el proceso de desocupacin del sitio de DR mientras el sitio de
produccin se encuentra en reparacin y hasta que quede listo para volver a usarse, si
consideramos al sitio de DR solamente como un sustituto temporal para produccin. Por ejemplo,
cuando el sitio de produccin est listo para reanudar las operaciones, los datos de produccin se
deben restablecer en dicho sitio. Los mtodos incluyen la agrupacin en clusters bidireccional entre
el sitio de DR y el sitio de produccin, lo que permite tiempo suficiente para que el trabajo de
produccin que se ejecuta en el sitio de DR vuelva a rellenar el sitio de produccin anterior
mediante la replicacin de datos. No obstante, puede ser necesario, u oportuno o eficaz,
simplemente transportar los MVC fsicos nuevamente al sitio de produccin restablecido. Los
mtodos elegidos dependern de las necesidades de recuperacin posteriores al desastre.
5.8 PLANIFICACIN DE PRUEBAS DE DR

La preparacin para una verdadera recuperacin ante desastres se evala probando la eficacia y la
eficiencia de los procedimientos y sistema de DR para recuperar una carga de trabajo de
produccin en un sitio de prueba de DR designado. El entorno de prueba de DR debe ser un
entorno de prueba de DR dedicado, pero, normalmente, es ms econmico compartir recursos
entre los sistemas de prueba de DR y de produccin. Las pruebas de DR que se realizan
simultneamente con la produccin y que comparten el uso de recursos con la produccin se
conocen como "pruebas concurrentes de DR". Si una aplicacin debe ejecutarse en paralelo en
sistemas prueba de DR y de produccin, los planificadores de DR deben garantizar que estas dos
instancias de la aplicacin no interfieran entre s mientras se ejecutan de manera simultnea. El
aislamiento de los sistemas de prueba de DR y de produccin en LPAR independientes y la
limitacin del acceso a los datos de produccin desde el sistema de prueba de DR suele
proporcionar una separacin suficiente. Las pruebas de DR se suelen realizar en etapas para
permitir la realizacin de pruebas especficas de distintas aplicaciones en distintos momentos, en
lugar de realizarse una prueba de recuperacin de todo el entorno de produccin de una vez. Las
pruebas especficas son clave para reducir la cantidad de recursos de hardware dedicado que se
recuperable requieren solo un pequeo subconjunto de recursos de VSM, esos recursos se pueden
compartir entre los sistemas de prueba de DR y de produccin, y se pueden reasignar al sistema
de prueba de DR para el ciclo de prueba de DR. Este enfoque reduce el costo de hardware para el
sistema de DR a riesgo de afectar el rendimiento del sistema de produccin mientras se ejecuta la
prueba de DR. No obstante, por lo general, un ciclo de prueba de DR dedica solo un pequeo
porcentaje de recursos compartidos a la prueba de DR, y el entorno de produccin disminuido no
se ve afectado en gran medida por las pruebas simultneas de DR. Sin embargo, algunas
organizaciones tienen polticas que impiden afectar o alterar la produccin para facilitar las pruebas
de DR. Es posible que los auditores exijan una coincidencia exacta entre los resultados de pruebas
de DR y de produccin para certificar el proceso de DR. Una manera de cumplir con este requisito
consta en establecer un punto de sincronizacin justo delante de una ejecucin programada de
produccin, guardar una copia de los resultados de produccin, recuperar la ejecucin de
produccin en este punto de sincronizacin en el sitio de prueba de DR y comparar el resultado con
los resultados de produccin guardados. Cualquier diferencia entre los resultados destacar una
brecha que se deber investigar. La imposibilidad de detectar estas brechas oportunamente podra
en
riesgo
poner
la
capacidad
de
recuperacin
ante
desastres
de
una
organizacin.
Independientemente de si una prueba de DR est diseada para recuperar una carga de trabajo
compleja o una aplicacin nica, el proceso de prueba de DR se debe realizar con los mismos
procedimientos que se utilizaran para una verdadera recuperacin ante desastres. Esta es la nica
manera segura de comprobar la realizacin correcta de la prueba de DR.
M ov i m i e n t o d e d a t o s p a r a p r u e b a s de D R
Hay dos mtodos para organizar los datos de aplicacin para pruebas de DR en un sitio de prueba
de DR: movimiento fsico de datos y movimiento electrnico de datos. El movimiento fsico de
necesita para el sistema de prueba de DR. Por ejemplo, si las pruebas de DR de una aplicacin
28
datos implica el transporte de cartuchos de cinta fsicos al sitio de prueba de DR en un proceso que
se describe a continuacin y que se conoce como "importacin/exportacin fsica". El movimiento
electrnico de datos utiliza unidades de cinta remotas, RTD remotas y tcnicas de cluster de VSM
para crear copias de los datos de aplicacin en un sitio de prueba de DR. Ambos mtodos de
movimiento de datos permiten la realizacin de pruebas de DR; no obstante, el movimiento
electrnico de datos evita la transferencia fsica de los datos y los posibles problemas de la prdida
de cintas, entre otros. La transferencia electrnica tambin mejora el tiempo de acceso a los datos,
ya que los coloca donde se los necesita para una verdadera recuperacin ante desastres o los
almacena provisionalmente en un buffer de VSM antes de un ciclo de prueba de DR. El movimiento
electrnico de datos para volmenes virtuales se puede realizar dentro de un solo TapePlex
mediante el uso de una agrupacin en clusters ampliada de VSM, o entre dos TapePlex mediante la
replicacin cruzada entre sistemas TapePlex. Para los datos que se encuentran dentro de un solo
TapePlex, el software de prueba concurrente de recuperacin ante desastres (CDRT) de Oracle
simplifica las pruebas de DR.
5.9 PRUEBAS DE DR CON EXPORTACIN/IMPORTACIN FSICA

Suponga que desea realizar pruebas de DR para una aplicacin de produccin que utiliza cinta
29
virtual y fsica. Su objetivo es probar esta aplicacin en el sitio de prueba de DR repitiendo una
ejecucin de produccin reciente y verificando que el resultado de la prueba coincida con el
resultado de la produccin reciente. Como parte de la preparacin, deber guardar copias de los
juegos de datos de entrada utilizados por la ejecucin de produccin y una copia del resultado de la
produccin para comparacin. Suponga que el sitio de prueba de DR est aislado y no comparte
equipos con la produccin. Usted podra realizar la prueba de DR mediante este proceso de
exportacin/importacin fsica.
Sitio de produccin:
1. Haga una copia de los VTV y los volmenes fsicos requeridos.
2. Exporte esas copias de VTV.
3. Expulse las copias asociadas de MVC y las copias de volmenes fsicos del ACS de produccin.
4. Transporte los MVC y los volmenes fsicos expulsados al sitio de prueba de DR.
Sitio de prueba de DR:
1. Introduzca los volmenes transportados en el ACS de DR.
2. Sincronice los catlogos de OS y el sistema de gestin de cintas con los volmenes
introducidos.
3. Importe los datos de VTV/MVC.
4. Ejecute la aplicacin.
5. Compare los resultados.
6. Expulse todos los volmenes introducidos para esta prueba.
7. Transporte los volmenes expulsados nuevamente al sitio de produccin.
Sitio de producci n:
1. Introduzca los volmenes transportados nuevamente en el ACS de produccin.
Este proceso permite que las pruebas de DR continen de forma segura y en paralelo con la
produccin, ya que el sistema de prueba de DR est aislado del sistema de produccin. El sistema
de prueba de DR tiene su propio CDS, y el proceso de prueba de DR, como se indica
anteriormente, introduce informacin de los volmenes en el CDS de prueba de DR a modo de
preparacin para la prueba de DR. Esto permite que la aplicacin recuperada se pruebe con los
mismos nombres de juegos de datos y volmenes que utiliza en produccin. Para los juegos de
datos de cintas virtuales, la funcin de almacenamiento del software LCM de Oracle simplifica la
colocacin de los VTV en los MVC y agiliza los pasos circulares que requieren exportar y expulsar
volmenes en el sitio de produccin, importar esos volmenes en el sitio de prueba de DR y
expulsar
dichos
volmenes
para
moverlos
nuevamente
al
sitio
de
produccin.
La
exportacin/importacin fsica le genera gastos al sitio por la manipulacin de cintas fsicas y

gastos de mensajera por el transporte de cartuchos de cinta entre los sitios de produccin y de
prueba de DR. Los datos confidenciales que se transportan mediante servicio de mensajera se
deben transportar en cartuchos de cinta cifrados. Los plazos de las pruebas de DR se ven afectados
5.10 PRUEBAS DE DR CON CDRT

Si se planifica y se cuenta con recursos suficientes de hardware en los sitios de produccin y de
DR, la CDRT combinada con el movimiento electrnico de datos puede eliminar la necesidad de
transportar cartuchos de cinta fsica al sitio de DR y permite la realizacin concurrente de pruebas
de DR de una manera ms econmica que si se mantiene un sitio de prueba de DR dedicado y
aislado. La CDRT permite la realizacin de pruebas de DR de prcticamente cualquier carga de
trabajo, configuracin, RPO o RTO imaginable. El proceso de prueba de DR incluir unos pocos
pasos adicionales para iniciar la CDRT y una limpieza despus de la prueba de DR. Antes de
ejecutar una prueba de DR con CDRT, debe mover electrnicamente todos los datos de aplicacin y
metadatos del sistema (informacin de catlogo de OS e informacin del sistema de gestin de
cintas) necesarios para la prueba al sitio de prueba de DR. Puede mover datos de aplicacin
electrnicamente mediante la agrupacin en clusters de VSM o la migracin de copias de VTV a los
MVC del sitio de prueba. A continuacin, puede usar la CDRT para crear un CDS especial para el
sistema de prueba de DR que refleje el CDS de produccin. Los sistemas de produccin y de
prueba de DR son entornos separados, y el entorno de prueba de DR utilizar el CDS especial de
prueba de DR en lugar del CDS de produccin. Debido a que la CDRT crea el CDS de prueba de DR
a partir de informacin del CDS de produccin, contiene metadatos de todos los volmenes que se
movieron electrnicamente al sitio de prueba de DR antes de la prueba de DR. Esto permite a las
aplicaciones de DR utilizar los mismos nmeros de serie de volmenes y nombres de juegos de
datos utilizados en la produccin. La CDRT aplica restricciones operativas sobre el sistema de
prueba de DR para evitar que el entorno de DR interfiera en el entorno de produccin. Puede
reforzar estas protecciones mediante las capacidades VOLPARM/POOLPARM de ELS para definir
por el tiempo que se dedica a transportar y manipular los cartuchos de cinta entre los sitios.
30
rangos de volser separados para los MVC y reutilizar los VTV para uso exclusivo de CDRT. La CDRT
permite al sistema de prueba de DR leer los MVC de produccin y escribir en su propia agrupacin
dedicada de MVC, que se borra lgicamente despus de cada prueba de DR. Para aplicaciones de
cinta virtual, la CDRT requiere al menos un dispositivo VTSS dedicado durante el ciclo de prueba de
DR. Estos VTSS dedicados se pueden reasignar temporalmente desde la produccin para facilitar
una prueba de DR, y la prueba de DR y el sistema VSM pueden acceder a los ACS de produccin en
paralelo con la carga de trabajo de produccin. En Figura 1-9 y Figura 1-10, se muestra la divisin
de un cluster de produccin de VSM para prestar un dispositivo de cluster al sistema de prueba de
DR de la CDRT, en este caso, VTSS2, en el sitio de prueba de DR. Cuando este cluster se divide,
debe modificar las polticas de produccin para sustituir la migracin por la replicacin, de modo
que VTSS1 cree copias redundantes de VTV en el sitio de DR en ACS01, y de modo que VTSS1 no
se llene hasta el lmite de su capacidad mientras el cluster se divide. VTSS2 se deja fuera de lnea
para la produccin y se coloca en lnea para la LPAR de prueba de DR. En Figura 1-9, CDRT ha
creado el CDS de prueba de DR a partir de una copia remota del CDS de produccin. Solo el
sistema de produccin puede acceder a los volmenes de VTSS1 y ACS00 durante el ciclo de
prueba de DR, y solo el sistema de prueba de DR puede acceder a VTSS2. Los sistemas de
produccin y de prueba de DR comparten el acceso concurrente a volmenes de ACS01. En Figura
1-9 y Figura 1-10, se mantiene una copia remota del CDS de produccin en el sitio de prueba de
31
DR, por ejemplo, mediante reflejo remoto, para garantizar que un CDS de produccin actualizado
est disponible en el sitio de DR para el uso de una verdadera recuperacin ante desastres. No
obstante, se debe tener en cuenta que el CDS de prueba de DR creado por la CDRT a partir de la
copia remota de CDS es una versin especial de la prueba de DR del CDS de produccin que solo
puede usar la CDRT. Antes de volver a conformar el cluster de produccin, despus de la
finalizacin del ciclo de prueba de DR, el VTSS de DR se debe purgar para evitar la prdida de
datos de produccin, como sucedera si VTSS2 tuviera una versin ms reciente de un VTV que
tambin existiera en VTSS1. Tambin debe modificar las polticas de produccin para realizar una
reversin de una migracin a una replicacin cuando se vuelve a conformar el cluster. Si no es
posible dividir un cluster de produccin como se muestra aqu, otra posibilidad es mantener un
VTSS independiente en el sitio de DR exclusivamente para la realizacin de pruebas de DR. En este
caso, los VTV necesarios para la prueba para se recuperarn a partir de las copias de MVC.
Figura 1-10 Configuracin de produccin con un VTSS2 prestado para pruebas de DR de CDRT
Figura 1-9 Cluster de produccin con un VTSS2 de nodo de cluster remoto en el sitio de prueba de DR
32
5.11 PRUEBAS DE DR CON REPLICACIN CRUZADA DE SISTEMAS

TAPE DE VSM
La replicacin cruzada entre sistemas TapePlex de VSM permite diseos de TapePlex de produccin
simtricos y en cluster que facilitan la realizacin de pruebas de DR sin el uso de CDRT, sin la
necesidad de hardware de VTSS dedicado exclusivamente a las pruebas de DR y sin alterar el
entorno de produccin para realiza las pruebas de DR. Por ejemplo, CTR permite a cada TapePlex
de produccin replicar datos en los otros TapePlex de produccin en el mismo cluster de CTR. Los
clusters de punto a punto de CTR de produccin pueden eliminar la necesidad de un sitio de prueba
de DR dedicado. CTR permite distintos tipo de diseos de TapePlex en cluster y facilita las pruebas
de DR de cualquier configuracin o carga de trabajo de produccin, con cualquier RPO o RTO
factible. En un ejemplo simple, un cluster bidireccional de CTR une dos sistemas TapePlex
simtricamente y cada TapePlex replica datos en el otro TapePlex (Figura 1-11). Un TapePlex
receptor introduce un VTV replicado en su CDS en el estado de solo lectura y marca el VTV para
indicar que es de propiedad del TapePlex emisor. En este ejemplo, las pruebas de DR para una
aplicacin de TapePlex A implican la replicacin de datos de aplicacin en el TapePlex B y la
recuperacin de la aplicacin en el TapePlex B.
33
Figura 1-11 Cluster de CTR de produccin simtrica para pruebas de DR
La simetra del diseo de este cluster de punto a punto significa que la aplicacin recuperada que
se est probando en el sitio del mismo nivel se ejecuta de la misma manera durante una prueba de
DR que durante la produccin. El CDS del mismo nivel contiene toda la informacin replicada de
volmenes necesaria para las pruebas de DR, que continan en paralelo con la produccin, y el
mismo hardware de VTSS admite el uso concurrente de las cargas de trabajo de prueba de DR y
produccin. Los clusters de produccin de VTSS pueden existir dentro de cada TapePlex, y no es
necesario dividirlos para compartir el uso del hardware en distintos sistemas TapePlex para
pruebas de DR. El TapePlex de produccin en el cual se realiza la prueba de DR de la aplicacin no
puede modificar ningn VTV replicado por CTR; por lo tanto, todos los datos de produccin
replicados se mantienen completamente protegidos durante el ciclo de prueba de DR. Ms
importante an, las pruebas de DR basadas en CTR garantizan que un procedimiento de prueba de
DR validado tendr idnticos resultados durante una verdadera recuperacin ante desastres. El
software de host de SMC emitir un mensaje si se realiza un intento de actualizar un VTV replicado
por CTR, lo cual permite identificar la aplicacin como aquella que modifica un juego de datos de
entrada existente. Mediante el seguimiento de las mejores prcticas para la gestin de puntos de
sincronizacin que se indican anteriormente, debe poder garantizar que el entorno de produccin
guarde una copia de este juego de datos antes de que la aplicacin lo modifique, en caso de que se
necesite una copia de seguridad para la recuperacin de punto de sincronizacin.
34
6. REALIZACIN DE EXPORTACIONES E IMPORTACIONES FSICAS

Las funciones EXPORT e IMPORT le proporcionan las herramientas para crear MVC fsicamente
porttiles. En el sitio de origen, utiliza EXPORT para consolidar los VTV en los MVC (si es necesario)
y genera un archivo de manifiesto que describe el contenido del MVC (VTV en el MVC). A
continuacin, expulsa los MVC del sitio de origen, los transporta fsicamente al sitio de destino y,
luego, mediante IMPORT, los importa con el archivo de manifiesto para actualizar el CDS con
informacin en los MVC y VTV importados. Tenga en cuenta que puede importar los VTV en un CDS
sin necesidad de que el VTCS est activo. A continuacin, introduce los MVC en el sitio de destino.
N ot a :
Si decide devolver los MVC exportados al sistema de origen, no se requiere ningn

procesamiento especial del VTCS, simplemente, introduzca los MVC en un LSM en el
sistema de origen.
Por cada VTV importado, las nicas copias de MVC que se crearn sern copias de los MVC
que hayan sido exportados e importados mediante las mismas sentencias. Esto tiene una
importancia especial al importar VTV duplicados. Dicho VTV solo tendr copias en ambos
35
MVC despus de la importacin si ambos MVC estn presentes en el mismo archivo de

manifiesto y se importan como resultado de la misma sentencia IMPORT.
Puede realizar la exportacin mediante alguno de los siguientes mtodos generales:
Exportacin por VTV o clase de gestin, que consolida los VTV seleccionados en un nuevo
conjunto de MVC. Dado que la consolidacin lleva tiempo y necesita recursos de VTSS, la
opcin preferida consiste en realizar la exportacin por MVC o clase de almacenamiento.
Para obtener ms informacin, consulte "Exportacin e importacin por clase de gestin."
Exportacin por MVC o clase de almacenamiento. Una exportacin por clase de

almacenamiento o MVC no requiere el procesamiento posterior de la consolidacin de los
VTV, y no requiere movimiento de datos. La exportacin, simplemente, crea un archivo de
manifiesto que describe el contenido del MVC seleccionado. Para obtener ms informacin,
consulte "Exportacin e importacin por clase de almacenamiento."
N ot a :
Si exporta por:
V ol se r s d e V T V : use un informe de TMS, LCM o VTVRPT para identificar los

VTV necesarios.
V ol se r s d e M V C : use un informe de LCM o MVCRPT para identificar los MVC

necesarios.
C l a se d e g e s t i n : revise las definiciones de su clase de gestin para identificar

las clases de gestin necesarias.
C l a se s
de
a l m a c e n a m i e n t o : revise
las
definiciones
de
su
clase
de
almacenamiento para identificar las clases de almacenamiento necesarias.
6.1 EXPORTACIN E IMPORTACIN POR CLASE DE GESTIN

En los siguientes ejemplos, se muestran exportaciones e importaciones de MVC por clase de
gestin.
Ejemplo: exportacin por clase de gestin a partir del sistema VSM de origen
Esta es la fase de "envo" de la exportacin/importacin, donde se empaquetan los datos deseados
y se mueven fuera del sistema VSM de origen.
P a r a r e a l i z a r u n a e x p o r t a c i n a pa r t i r de u n si s t e m a V S M de o r i ge n, h a g a
l o si g u i e n t e :
2. Exporte por clase de gestin:

//EXPORT EXEC PGM=SLUADMIN,PARM='MIXED' REGION=6M
//STEPLIB
DD DSN=hlq.SEALINK,DISP=SHR
//MOVE1
DD DSN=hlq.REMOTE2,DISP=(,CATLG,DELETE),
//
UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),
//
DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
//SLSPRINT DD SYSOUT=*
//SLSIN
DD *
EXPORT MGMT (PAY,ACCOUNT) MANIFEST(MOVE1)

En este ejemplo, el archivo de manifiesto de salida es MOVE1 y se necesita para la importacin.
Dado que export por clase de gestin, EXPORT consolida (hace copias de) los VTV seleccionados
en los MVC de exportacin. Los MVC de exportacin se marcan como de solo lectura y se exportan
al CDS; a partir de entonces, se encuentran disponibles para expulsin desde un sistema LSM de
origen. Estas copias consolidadas del VTV son copias adicionales y no se registran en el CDS. Por
ejemplo, si el VTV se duplic antes de la exportacin, el CDS registra ambas copias duplicadas,
pero la tercera copia adicional usada para consolidacin no se registra en el CDS. Por lo tanto, los
VTV originales siguen estando disponibles para el sistema de origen. Puede usar los datos de los
VTV originales o almacenarlos temporalmente para, luego, reutilizarlos.
1. Identifique la clase de gestin que se utiliza para exportacin.
36
Atencin:
Programe la exportacin para un momento en que los datos exportados no se estn actualizando.
3. Elimine los MVC para exportacin de la agrupacin de MVC. Para obtener ms informacin,
consulte Gestin de HSC y VTCS.
4. Expulse los MVC para exportacin del LSM de un sistema VSM de origen. Para obtener ms
informacin, consulte Gestin de HSC y VTCS.
5. Si lo desea, reutilice los VTV exportados en el sistema de origen, djelos en estado no
disponible, o reutilice los datos que contienen.
Despus de la exportacin, el sistema de origen conserva los registros del CDS de los VTV y los
MVC exportados. Los MVC de exportacin se marcan como exportados y como de solo lectura en el
CDS del sistema de origen. En este momento, tiene dos opciones, segn el motivo por el cual ha
exportado los VTV:
S i e x p o r t l o s V T V pa r a pr o p or c i on a r u na c o pi a de se g u r i d a d a
u n se g u n d o si t i o , deje los VTV en modo de solo lectura en el CDS del sistema
de origen, de modo que no se puedan actualizar.
37
Si
mover
de
forma
de f i ni t i v a
los
VTV
e x p o r t a do s
un
se g u n d o si t i o , reutilcelos o djelos en estado no disponible de alguna otra

manera en el CDS del sistema de origen. Use las utilidades de reutilizacin del HSC
o la funcin SYNCVTV del LCM para reutilizar los VTV exportados.
Ejemplo: importacin por clase de gestin en el sistema VSM de destino
Ya ha pasado un mes y, finalmente, est listo para la parte de "recepcin" (importacin) de la
operacin de exportacin/importacin.
P a r a r e a l i z a r u n a i m p o r t a c i n e n u n si st e m a V S M de de st i n o, h a g a l o
si g u i e n t e :
1. Si los VTV y los MVC que importa no estn en el CDS del sistema de destino, vuelva a
establecer las definiciones POOLPARM/VOLPARM para agregar estos volsers, como se
describe en Configuracin de HSC y VTCS.
Si es necesario, aumente el tamao del CDS en el sistema VSM de destino. Para obtener ms
informacin, consulte Configuracin de HSC y VTCS o Gestin de HSC y VTCS.
Qu ocurrira si hubiera volsers de VTV duplicados en los sistemas de origen y destino? En
general, debe hacer lo siguiente:
Si el sistema de origen tiene ms VTV actuales con los mismos volsers que en el
sistema de destino, especifique REPLACE(ALL).
Si est moviendo los VTV del sistema de origen al de destino (primera

exportacin/importacin), especifique REPLACE(NONE). En este caso, debe decidir
qu hacer con los VTV duplicados caso por caso.
2. Introduzca los MVC para importacin en el LSM de un sistema VSM de destino.

Para obtener ms informacin, consulte Gestin de HSC y VTCS. Se recomienda ubicar los MVC
fsicamente antes de usar IMPORT para indicarle al CDS que tiene nuevos MVC y VTV.
3. De manera opcional, realice una ejecucin de "validacin" de IMPORT:
//IMPORT EXEC PGM=SLUADMIN,PARM='MIXED' REGION=6M
//STEPLIB
//REMOTE1
DD DSN=hlq. SEALINK,DISP=SHR
D D D S N = h l q. R E M O T E 1 , D I S P = S H R
IMPORT MANIFEST(MOVE1) NOUPDATE

En este ejemplo, se muestra un JCL que ejecuta la utilidad IMPORT, donde:
El archivo de manifiesto es el manifiesto de exportacin especificado en el paso 2.
REPLACE(NONE) (el valor predeterminado) especifica que el VTCS no sobrescribe

los VTV duplicados.
IMMDRAIN(NO) (el valor predeterminado) especifica que el VTCS no drena todos

los VTV importados al espacio del VTSS.
NOUPDATE especifica que el CDS no se actualiza (ejecucin de validacin

nicamente).
INACTCDS no se especifica; por lo tanto, el HSC est activo.
La realizacin de una ejecucin de validacin es opcional, pero se recomienda enfticamente,

porque usted realmente desea saber qu ocurrir antes de pulsar el botn. Revise minuciosamente
el informe de importacin. Le gusta lo que ve? Contine con el paso 4.
N ot a :
IMPORT es vlido nicamente si FEATures VSM(ADVMGMT) est especificado.
Asegrese de que el CDS de "destino" cuente con las mismas caractersticas

(activadas en funcin del nivel de CDS) que el CDS de "origen". Por ejemplo, si el
CDS de "origen" tiene activados tamaos de pginas grandes de VTV y se han
//SLSIN DD *
38
creado VTV de 2/4 Gb, el CDS de "destino" debe tener las mismas capacidades, de
lo contrario, la importacin falla.
4. Realice una ejecucin real de IMPORT:
//STEPLIB
//REMOTE1
//SLSIN DD *
IMPORT MANIFEST(MOVE1) REPLACE(ALL)
En este ejemplo, se muestra un JCL que ejecuta la utilidad IMPORT, donde, al igual que en la
ejecucin de "validacin", REPLACE(NONE) (el valor predeterminado) especifica que el VTCS no
sobrescribe los VTV duplicados.
39
Nota:
Qu
ocurre
si
desea
devolver
los
MVC
al
sistema
de
origen?
De
ser
as,
puede
especificar IMMDRAIN(YES) para drenar los MVC de importacin.

5. Ajuste las definiciones del VTV segn sea necesario. Por ejemplo, debe definir nuevos VTV
en el TMS del sistema de destino.
6. Realice una de las siguientes acciones:
Opcionalmente,
ejecute MVCMAINT para
que
los
MVC
importados
admitan
escritura. El VTCS importa los MVC en modo de solo lectura. Para que admitan
escritura, debe ejecutar MVCMAINT y especificar READONLY OFF. Lo ms probable
es que desee usar los nuevos MVC en el sistema de destino, y este es el primer
paso para poder hacerlo.
A continuacin, agregue los MVC importados a la nueva agrupacin de MVC, como se describe
en Gestin de HSC y VTCS. En este momento, los MVC se pueden recuperar y drenar, y se pueden
realizar migraciones hacia ellos.
Si especific IMMDRAIN(YES) en el paso 4, puede devolver los MVC al sistema de

origen.
Exportacin e importacin por clase de almacenamiento

En los siguientes ejemplos, se muestran operaciones de exportacin e importacin por clase de
almacenamiento a partir de un VSM de origen.
Ejemplo: exportacin por clase de almacenamiento a partir del sistema VSM de origen
Esta es la fase de "envo" de la exportacin/importacin, donde se empaquetan los datos deseados
y se mueven fuera del sistema VSM de origen.
P a r a r e a l i z a r u n a e x p o r t a c i n a pa r t i r de u n si s t e m a V S M de o r i ge n, h a g a
l o si g u i e n t e :
1. Identifique la clase de almacenamiento que se utiliza para exportacin.
2. Exporte por clase de almacenamiento:
//STEPLIB
//MOVE2
DD DSN=hlq.REMOTE2,DISP=(,CATLG,DELETE),
//
UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE),
//
DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
//SLSIN DD *
EXPORT STOR(OFF1,OFF2) MANIFEST(M OVE2)
En este ejemplo, el archivo de manifiesto de salida es MOVE2 y se necesita para la importacin.
Dado que export por clase de almacenamiento, el sistema crea un archivo de manifiesto, pero no
se produce la consolidacin del VTV. Los MVC de exportacin se marcan como de solo lectura y se
exportan al CDS; a partir de entonces, se encuentran disponibles para expulsin desde un sistema
LSM de origen. Los VTV que residan en los MVC eliminados del LSM se pueden seguir usando,
siempre que residan en otros MVC.
Atencin:
Programe la exportacin para un momento en que los datos exportados no se estn actualizando.
3. Elimine los MVC para exportacin de la agrupacin de MVC. Para obtener ms informacin,
consulte Gestin de HSC y VTCS.
4. Expulse los MVC para exportacin del LSM de un sistema VSM de origen. Para obtener ms
informacin, consulte Gestin de HSC y VTCS.
5. Si lo desea, reutilice los VTV exportados en el sistema de origen, djelos en estado no
disponible, o reutilice los datos que contienen.
Despus de la exportacin, el sistema de origen conserva los registros del CDS de los VTV y los
MVC exportados. Los MVC de exportacin se marcan como exportados y como de solo lectura en el
//EXPORT EXEC PGM=SLUADMIN,PARM='MIXED' REGION=6M
40
CDS del sistema de origen. En este momento, tiene dos opciones, segn el motivo por el cual ha
exportado los VTV:
S i e x p o r t l o s V T V pa r a pr o p or c i on a r u na c o pi a de se g u r i d a d a
u n se g u n d o si t i o , deje los VTV en modo de solo lectura en el CDS del sistema
de origen, de modo que no se puedan actualizar.
Si
mover
de
forma
de f i ni t i v a
los
VTV
e x p o r t a do s
un
se g u n d o si t i o , reutilcelos o djelos en estado no disponible de alguna otra

manera en el CDS del sistema de origen. Use las utilidades de reutilizacin del HSC
o la funcin SYNCVTV del LCM para reutilizar los VTV exportados.
Ejemplo: importacin por clase de almacenamiento en el sistema VSM de destino
Ya ha pasado un mes y, finalmente, est listo para la parte de "recepcin" (importacin) de la
operacin de exportacin/importacin.
P a r a r e a l i z a r u n a i m p o r t a c i n e n u n si st e m a V S M de de st i n o, h a g a l o
si g u i e n t e :
41
1. Si los VTV y los MVC que importa no estn en el CDS del sistema de destino, vuelva a
establecer las definiciones POOLPARM/VOLPARM para agregar estos volsers, como se
describe en Configuracin de HSC y VTCS.
Si es necesario, tambin aumente el tamao del CDS en el sistema VSM de destino. Para obtener
ms informacin, consulte Configuracin de HSC y VTCS oGestin de HSC y VTCS.
Qu ocurrira si hubiera volsers de VTV duplicados en los sistemas de origen y destino? En
general, debe hacer lo siguiente:
Si el sistema de origen tiene ms VTV actuales con los mismos volsers que en el
sistema de destino, especifique REPLACE(ALL).
Si est moviendo los VTV del sistema de origen al de destino (primera

exportacin/importacin), especifique REPLACE(NONE). En este caso, debe decidir
qu hacer con los VTV duplicados caso por caso.
2. Introduzca los MVC para importacin en el LSM de un sistema VSM de destino.

Para obtener ms informacin, consulte Gestin de HSC y VTCS. Puede ver lo que est ocurriendo
aqu? Se recomienda ubicar los MVC fsicamente antes de usarIMPORT para indicarle al CDS que
tiene nuevos MVC y VTV.
3. De manera opcional, realice una ejecucin de "validacin" de IMPORT.
//STEPLIB
//REMOTE1
//SLSIN DD *
IMPORT MANIFEST(REMOTE1) NOUPDATE
En este ejemplo, se muestra un JCL que ejecuta la utilidad IMPORT, donde:
El archivo de manifiesto es el manifiesto de exportacin especificado en el paso 2.
REPLACE(NONE) (el valor predeterminado) especifica que el VTCS no sobrescribe

los VTV duplicados.
IMMDRAIN(NO) (el valor predeterminado) especifica que el VTCS no drena todos

los VTV importados al espacio del VTSS.
NOUPDATE especifica que el CDS no se actualiza (ejecucin de validacin
INACTCDS no se especifica; por lo tanto, el HSC est activo.
La realizacin de una ejecucin de validacin es opcional, pero se recomienda enfticamente,

porque usted realmente desea saber qu ocurrir antes de pulsar el botn. Revise minuciosamente
el informe de importacin. Le gusta lo que ve? Contine con el paso 4.
N ot a :
IMPORT es vlido nicamente si FEATures VSM(ADVMGMT) est especificado.
Asegrese de que el CDS de "destino" cuente con las mismas caractersticas

(activadas en funcin del nivel de CDS) que el CDS de "origen". Por ejemplo, si el
CDS de "origen" tiene activados tamaos de pginas grandes de VTV y se han
creado VTV de 2/4 Gb, el CDS de "destino" debe tener las mismas capacidades, de
lo contrario, la importacin falla.
4. Realice una ejecucin real de IMPORT:

//STEPLIB
//REMOTE1
//SLSIN DD *
nicamente).
42
IMPORT MANIFEST(REMOTE1)
En este ejemplo, se muestra un JCL que ejecuta la utilidad IMPORT, donde, al igual que en la
ejecucin de "validacin", REPLACE(NONE) (el valor predeterminado) especifica que el VTCS no
sobrescribe los VTV duplicados.
N ot a :
Qu
ocurre
si
desea
devolver
los
MVC
al
sistema
de
origen?
De
ser
as,
puede
especificar IMMDRAIN(YES) para drenar los MVC de importacin.

5. Ajuste las definiciones del VTV segn sea necesario.
6. Realice una de las siguientes acciones:
Opcionalmente,
ejecute MVCMAINT para
que
los
MVC
importados
admitan
escritura. El VTCS importa los MVC en modo de solo lectura. Para que admitan
escritura, debe ejecutar MVCMAINT y especificar READONLY OFF. Lo ms probable
es que desee usar los nuevos MVC en el sistema de destino, y este es el primer
paso para poder hacerlo.
43
A continuacin, agregue los MVC importados a la nueva agrupacin de MVC, como se describe
en Gestin de HSC y VTCS. En este momento, los MVC se pueden recuperar y drenar, y se pueden
realizar migraciones hacia ellos.
Si especific IMMDRAIN(YES) en el paso 4, puede devolver los MVC al sistema de

origen.
7. USO DEL SOFTWARE DE

PRUEBA
CONCURRENTE
DE
El posible que los clientes que usan o mantienen un sitio de recuperacin ante desastres (DR)
como parte de un plan de continuidad empresarial deseen validar peridicamente su capacidad
para continuar el procesamiento normal de la produccin antes de que ocurra un desastre real;
otros clientes no tienen opcin y deben probar de forma peridica la preparacin de su modelo de
continuidad empresarial para cumplir con los requisitos de seguro y/o de los auditores.
Mediante el uso de la funcin de prueba concurrente de recuperacin ante desastres (CDRT), que
ahora es una funcin integrada al software de StorageTek ELS, las empresas que actualmente usan
las bibliotecas de cintas StorageTek Streamline y/o Nearline (hardware real), VSM (hardware
virtual) y software asociado (HSC, VTCS) pueden validar su capacidad de continuidad empresarial
de cintas reales y virtuales sin necesidad de comprar hardware o software adicional.
CDRT admite una prueba paralela de aplicaciones y hosts de produccin con acceso simultneo a
los datos de produccin, mediante los sistemas de prueba de DR y produccin.
Mediante el uso de CDRT, una prueba de DR puede ejecutarse con hardware real, virtual o
ambos.
CDRT, HSC y VTCS aplican de forma programtica algunas restricciones funcionales

durante la preparacin de CDS y la prueba real de DR en un intento por garantizar la
integridad del sistema.
CDRT separa de forma lgica una porcin de hardware real y virtual y agrupaciones de
volmenes de cintas de produccin existentes para el perodo de la prueba de DR.
Esto permite probar la configuracin de DR y, al mismo tiempo, ejecutar el trabajo de produccin,

adems, permite garantizar la integridad de los datos de produccin y minimizar los conflictos para
los volmenes de cinta y los recursos de hardware.
La CDRT crea una copia de prueba del CDS de produccin. Por lo tanto, el subsistema de
produccin de ELS y los subsistemas de prueba de DR de ELS no se comunican entre s.
Los cambios que se producen en el CDS de prueba de DR no se reflejan en la copia del CDS
de produccin y viceversa. Los hosts de prueba de DR ejecutan el hardware separado de
forma lgica nicamente. Los hosts de produccin siguen usando todo el hardware con una
excepcin: los hosts de DR usan exclusivamente los VTSS separados de forma lgica
durante la prueba de DR. Otros recursos, como las RTD, los cartuchos de varios volmenes
(MVC) y las cintas reutilizables reales se deben controlar mediante la definicin de
agrupaciones separadas para cada conjunto de hosts.
Una prueba de DR se puede realizar solo con recursos locales o con una combinacin de
recursos locales y remotos; tambin se admiten las configuraciones que constan de un sitio
Los conceptos clave de CDRT son:
44
remoto con hardware real y virtual solamente, o que constan de hardware real y virtual con
un procesador de mainframe.
El hardware de prueba de DR puede incluir cualquier combinacin de ACS, VTSS y VLE.
Despus de una prueba de DR, la copia de prueba de CDS y todos los datos creados a
partir de la prueba de DR, por lo general, se desechan, y el hardware separado lgicamente
se vuelve a desplegar en el entorno de produccin normal.
N ot a :
Para satisfacer las necesidades de recuperacin de un verdadero desastre, es fundamental

que los trabajos en un flujo de trabajos de prueba de DR no actualicen los volmenes
creados en la produccin, ya sea mediante DISP=MOD o mediante la sobrescritura de estos
volmenes. El uso de dichas prcticas significa que si ocurri un verdadero desastre, el
estado de estos volmenes ser impredecible.
Para la ejecucin de la prueba de DR, se recomienda enfticamente que los volmenes de

produccin que se pudieron modificar durante la prueba de DR se copien a nuevos
volmenes al comienzo de la prueba y que los volmenes copiados sean actualizados por la
prueba de DR, en lugar de los volmenes originales. Adems, el JCL se debe modificar, de
45
ser posible, de modo que se conozca el estado de todos los volmenes de cinta en el
momento de un desastre.
7.1. CONSIDERACIONES SOBRE METADATOS

Un factor fundamental para realizar una prueba de DR exitosa mediante CDRT es contar con una
copia coherente del estado de todos los volmenes de cinta gestionados por el software de ELS y el
hardware real y virtual. La coherencia en el estado de los volmenes de cinta entre los hosts de
produccin y los hosts de DR al comienzo de la prueba de DR es lo que permite el procesamiento
paralelo de las aplicaciones del cliente. Dado que el CDS refleja el estado de todos los recursos y
volmenes de cinta en el hardware real y virtual, la CDRT cumple parcialmente con este requisito
de coherencia cuando hace la copia de prueba del CDS.
No obstante, en un entorno de volmenes de cintas, muchas veces, algunos de los datos del
estado de estos volmenes de cintas (metadatos) se conservan y se gestionan fuera del
subsistema de ELS y el hardware real y virtual. Por lo general, los metadatos de los volmenes de
cintas (VOLSER, DSN, fecha de caducidad, estado reutilizable, designacin real o virtual, etc.) se
almacenan en uno o ms catlogos de gestin de cintas (TMC), en uno o ms catlogos de z/OS y
en el CDS.
Debe coordinar la creacin de copias de metadatos conservados y gestionados fuera del ELS (y el
hardware real y virtual) con la creacin de la copia de prueba del CDS que realiza la CDRT.
7.2. DNDE OBTIENE LA CDRT LOS DATOS DEL VTV?

La CDRT obtiene los datos de VTV de uno o ms de los siguientes recursos del sitio de DR:
MVC
VLE
VTSS
Debido a que el CDS de produccin es la fuente de informacin de los VTV disponibles para la
prueba de DR, es importante asegurarse de que el ciclo de sincronizacin de volmenes
reutilizables permita que los volmenes utilizados en la prueba de DR no se coloquen en el estado
reutilizable antes del comienzo de la prueba. StorageTek tambin recomienda que cambie el VTSS
de prueba a fuera de lnea antes de realizar la DRTEST CREATE.
Tenga en cuenta que la ejecucin de la reutilizacin durante la prueba no afecta al contenido del
VTSS de prueba de DR ni los de los MVC, si este se establece en READONLY mediante la utilidad
ACTMVCGN.
ubicacin, por lo general, se encuentra en los MVC o las VLE. No obstante, en ocasiones, puede
optar por usar copias de VTV en un VTSS que existe en el sitio de prueba.
En general, puede hacer esto en las siguientes situaciones:
Define su VTSS de DR con la palabra clave SHARE, que impide actualizaciones del
contenido de cualquier VTV de produccin.
Tiene dos VTSS en cluster: uno en el sitio de produccin y uno en el sitio de DR; y su
prueba de DR no modifica el contenido de ningn VTV de produccin.
Tiene dos VTSS en cluster: uno en el sitio de produccin y uno en el sitio de DR; y desea
dedicar tiempo, despus de la prueba de DR, a identificar y migrar manualmente cualquier
VTV que actualiz la prueba de DR.
N ot a :
Puede usar la utilidad DRMONitr para garantizar que los datos crticos de DR lleguen a la ubicacin
de recuperacin designada antes de ejecutar una prueba de DR.
7.2.1. QU OCURRE CON LOS DATOS CUANDO FINALIZA LA

PRUEBA?
Los datos creados por la prueba de DR se reflejan nicamente en el CDS de prueba de DR (que se
desecha despus de la prueba) y en los MVC de prueba de DR, que se encuentran en un rango
separado de volmenes de los MVC de produccin. Adems, los VTV creados por la prueba de DR
La copia de CDS del sitio de DR proporciona la ubicacin de los VTV en el momento de la copia, y la
46
permanecen en el VTSS de prueba de DR despus de la prueba, a menos que realice una de las
siguientes acciones:
1. Use la utilidad SLUADMIN SCRATCH en el entorno de prueba de DR para reutilizar (con
MGMTCLAS DELSCR(YES)) todos los VTV en el rango de la subagrupacin de prueba de DR.
Esta opcin requiere el uso de la caracterstica POOLPARM/VOLPARM.
2. Asegrese de que todos los VTV de produccin que fueron modificados por la prueba de DR
se migren a los MVC de prueba de DR mediante el comando MIGRATE con DELETE(YES) a
partir del sistema de prueba de DR. Si no puede hacer esto, el sistema de produccin
recoge los datos que fueron modificados por la prueba de DR.
3. Solictele al CSE de StorageTek CSE o a otro QSP que "limpie" el VTSS de prueba de DR
despus de la prueba para eliminar todos los datos del VTSS.
N ot a :
Si elige la opcin 2 o la opcin 3, el contenido del VTSS no coincidir con el sistema de
produccin, porque los VTV estarn ausentes del CDS de prueba de DR cuando este se devuelva a
la produccin. Si bien es el software el que controla esta situacin, el rendimiento de su produccin
47
puede degradarse.
7.3. GESTIN DE LOS RECURSOS DE CDRT

En las siguientes secciones, se indica cmo gestionar los recursos de CDRT.
7.3.1. RECURSOS DE VOLMENES

El primer paso para gestionar los recursos de CDRT consiste en definir los volmenes de su sistema
mediante la utilidad POOLPARM/VOLPARM. La funcin simplifica la gestin general de sus
volmenes y agrupaciones de cintas, y proporciona un mtodo de segregacin de volmenes que
se escriben en una configuracin de CDRT. El uso de POOLPARM/VOLPARM es necesario cuando se
comparten los VTSS de prueba de DR y se recomienda enfticamente para otros escenarios.
N ot a :
La utilidad SLUADMIN SET VOLPARM se debe ejecutar mediante el CDS de produccin y debe
definir las agrupaciones de produccin y prueba de DR. La utilidad SET VOLPARM no es vlida para
un CDS de prueba de DR.
Subagrupaciones reutilizables
Las subagrupaciones reutilizables son aplicables a todos los escenarios de prueba de DR. La
siguiente sintaxis muestra el uso de las definiciones POOLPARM/VOLPARM para definir las
subagrupaciones reutilizables de produccin y prueba de DR. Al usar los mismos nombres para las
subagrupaciones de produccin y prueba de DR (con distintos rangos de volumen), no es necesario
cambiar las polticas de produccin cuando ejecuta la prueba de DR, como se muestra en el
siguiente ejemplo.
* SCRATCH POOLS
POOLPARM NAME(SCRP1) TYPE(SCRATCH)
VOLPARM VOLSER(T11000 -T11999) MEDIA(T10000T1)
RECTECH(T1AE)
POOLPARM NAME(SCRP1) TYPE(SCRATCH) DRTEST
RECTECH(T1AE)
POOLPARM NAME(SCRVTV1) TYPE(SCRATCH)
VOLPARM VOLSER(V1000-V1999) MEDIA(VIRTUAL)
POOLPARM NAME(SCRVTV1) TYPE(SCRATCH) DRTEST
Cuando define subagrupaciones reutilizables mediante la utilidad POOLPARM/VOLPARM, puede usar

la utilidad SLUADMIN SCRATCH de HSC para reutilizar volmenes de salida de prueba de DR dentro
del entorno de prueba de DR. Junto con una clase de gestin que especifica DELSCR(YES), la
ejecucin de la utilidad de reutilizacin elimina los VTV creados por la prueba de DR a partir del
VTSS.
R e c u r s os d e M V C
Los recursos de MVC se utilizan para todos los escenarios de prueba de DR, excepto para cinta real
nicamente y VSM sin cinta. En el siguiente ejemplo, se muestra el uso de las definiciones
POOLPARM/VOLPARM para definir las agrupaciones de MVC de produccin y prueba de DR.
* MVC POOLS
POOLPARM NAME(MVCP1) TYPE(MVC) MVCFREE(40) MAXMVC(4)
THRESH(60) +
START(70)
RECTECH(T1AE)
POOLPARM NAME(MVCP1) TYPE(MVC) MVCFREE(40) MAXMVC(4)
THRESH(60) +
START(70) DRTEST
RECTECH(T1AE)
VOLPARM VOLSER(V2000-V2999) MEDIA(VIRTUAL)
48
Conserve el contenido de los MVC de produccin para utilizarlo en un escenario de prueba de DR

con lo siguiente:
Use la utilidad ACTMVCGN para definir los MVC que se utilizarn como entrada para la
prueba de DR en READONLY, como se muestra en el siguiente ejemplo.
//ACTMVCG1 EXEC PGM=SLUADMIN,PARM='MIXED'

//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//* NOTE: MVCMAINT READONLY(ON) STATEMENTS
//SLUSMVON DD DSN=hlq.SLUSMVON,DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,1)
//* NOTE: MVCMAINT READONLY(OFF) STATEMENTS
//SLUSMVOF DD DSN=hlq.SLUSMVOF,DIS P=(NEW,CATLG,DELETE),
49
SPACE=(CYL,1)
//* NOTE: THE FOLLOWING STEP SELECTS ALL "ACTIVE" MVCS
//* IN ACS 01.
//SLSIN DD *
ACTMVCGN ACS(01)
/*
//* NOTE: EXEC MVCMAINT TO SET READONLY(ON)
Mediante VTCS CONFIG, asegrese de que no se ejecute la recuperacin en todos los hosts
de produccin:
C O N F I G H O S T N A M E ( h o st ) N O R E C L A M
7.3.2. RECURSOS DE VTSS

Hay dos tipos de recursos de VTSS: no compartidos y compartidos.
R e c u r s os d e V T S S n o c o m p a r t i d o s
En un entorno donde los VTV se migran a los MVC o a la VLE, los recursos de VTSS se separan
durante una prueba de DR. El sistema de prueba de DR tiene acceso solamente a los VTSS
definidos mediante las utilidades DRTEST PRIMEPRD/CREATE, y estos VTSS deben permanecer
fuera de lnea para la produccin. El comando DRTEST START se rechaza si un VTSS de DR est en
lnea en el entorno de produccin.
En algunos casos, puede haber dos VTSS con el mismo nombre, tanto en el sitio de prueba como
en el de produccin. En este caso, el parmetro SPARE de la utilidad DRTEST PRIMEPRD/CREATE
especifica que el VTSS de prueba de DR tiene el mismo nombre que un VTSS de produccin, pero
no es fsicamente el mismo dispositivo, lo que permite que el dispositivo de produccin permanezca
en lnea durante la prueba. Es importante que tenga en cuenta que no debe utilizar el parmetro
SPARE para ningn otro escenario.
VTSS en cluster en CDRT
En "Escenario 4: VTSS en cluster con sitios de produccin y prueba de DR", se utiliza VTSS en
la prueba de DR, porque el VTSS de prueba de DR se encuentra fuera de lnea para la produccin.
Si los VTV de produccin se modifican de alguna manera durante la prueba de DR, debe asegurarse
de que todos los VTV modificados se eliminen del VTSS antes de volver a colocar el VTSS de
prueba nuevamente en lnea para produccin. De lo contrario, el sitio de produccin puede recoger
los VTV modificados. Para evitar esta situacin, StorageTek recomienda enfticamente que la
prueba de DR se disee de manera tal que los VTV de produccin no sean alterados por la prueba.
En un escenario de VTSS en cluster puede no haber VTD en el VTSS de prueba accesible para el
host de produccin. Para permitir la comunicacin mediante ECAM de la produccin al VTSS de
prueba de DR, especifique lo siguiente en VTCS CONFIG:
VTD LOW=xxxx HIGH=xxxx NOVERIFY
P r e p a r a c i n d e u n c l u st e r d e V T S S pa r a u na pr ue ba de D R :
1. Cambie el estado del VTSS de prueba de DR a un estado inactivo. Por ejemplo:
VARY VTSS1 QUIESCED
El objetivo aqu es cerrar (de forma controlada) la replicacin para VTSS1, de modo que pueda
usarlo exclusivamente para la prueba de DR.
2. Supervise la replicacin hasta que finalice con Display REPLicat. Aqu, la replicacin todava
est activa:
VTSS HOST QDEPTHVTSS0 PRODUCTION 1
cluster para enviar datos al VTSS del sitio de DR. En este escenario, el cluster no funciona durante
50
Usted sabr que la replicacin ha finalizado cuando vea lo siguiente:

VTSS HOST QDEPTH
VTSS0 PRODUCTION 0
3. Realice una comprobacin cruzada para verificar que la replicacin haya finalizado
comprobando el estado del CLINK con Display CLINK (Visualizar CLINK). Aqu, el CLINK
todava est activo:
VTSS CLINK STATUS USAGE HOST
VTSS0 7 ONLINE REPLICATING PRODUCTION
VTSS0 8 ONLINE REPLICATI NG PRODUCTION
Y o u k n o w t h e C L I N K i s n o l o n ge r a c t i v e w he n y o u se e t hi s :
VTSS CLINK STATUS USAGE HOST
VTSS0 7 ONLINE FREE
51
VTSS0 7 ONLINE FREE

4. Cambie el estado del VTSS de prueba de DR a fuera de lnea:
VARY VTSS1 OFFLINE
G e s t i n d e l c o n t e n i d o d e V T S S a nt e s y de s pu s de l a p r ue b a de D R
Antes de comenzar una prueba de DR, debe:
1. Planificar la prueba de modo que la salida de la prueba no entre accidentalmente en la
produccin.
2. Preparar la prueba de modo que el CDS de prueba de DR coincida con el contenido del
VTSS de DR.
Adems, StorageTek recomienda enfticamente que todos los VTSS del sitio de prueba se
limpien tan pronto como sea posible despus de la prueba. Esta prctica garantiza que los VTSS
del sitio de prueba estn vacos al comienzo de la prxima prueba y que ningn dato de prueba de
DR permanezca en los VTSS que se devuelven a la produccin.
Para limpiar los VTSS de prueba, realice alguna de las siguientes acciones:
1. No permita que la prueba de DR realice ninguna actualizacin (sobrescritura o agregacin)
en los VTV de produccin y utilice POOLPARM/VOLPARM para definir las subagrupaciones
reutilizables de prueba de DR. Mediante este mtodo, puede ejecutar la utilidad de
reutilizacin para reutilizar todos los VTV del rango de prueba de DR, y estos se suprimen
automticamente del VTSS (si la clase de gestin especifica DELSCR(YES)).
2. Si la prueba de DR puede actualizar los VTV de produccin, debe asegurarse de que
cualquier VTSS que se utilice para la salida de prueba de DR se vace antes de que el VTSS
regrese a la produccin. Para hacer esto, debe migrar a cero en el entorno de prueba de
DR o debe solicitarle a un CSE de StorageTek o a otro QSP que "limpie" el VTSS.
Cuando ejecuta la utilidad DRTEST CREATE para crear un CDS de prueba de DR, los metadatos del
contenido de VTSS se propagan al entorno de prueba. Los VTV del VTSS de prueba de DR estn
disponibles para el entorno de prueba de DR.
Si el VTSS de prueba de DR se define como de reserva, el contenido del VTSS fsico de DR no
coincidir con los metadatos de CDS, que hacen referencia a la instancia de produccin del VTSS
de reserva. Para eliminar esta discrepancia, antes de crear el CDS de prueba de DR, migre la
instancia de produccin del VTSS de reserva a 0 en el entorno de produccin. Puede ejecutar VTCS
VTVRPT OPTION(UNAVAIL) para garantizar que todos los VTV se migren y estn disponibles para
otros VTSS. Si este paso no se realiza, los intentos de la prueba de DR por acceder a los VTV del
R e c u r s os d e c om p a r t i d o s
Si el entorno de cinta no incluye MVC de VLE o cinta real, puede ejecutar la CDRT en un entorno de
VTSS compartido. El parmetro DRTEST PRIMEPRD/CREATE SHARE especifica que la produccin y
la prueba de DR comparten un VTSS durante la prueba. Este entorno aplica las siguientes
restricciones:
1. DRTEST CREATE no puede definir tambin recursos DRACS o STORMNGR. Es decir, no se
pueden mirar datos del VTSS compartido a medios externos.
2. El sistema de produccin debe definir recursos de volmenes mediante la utilidad
POOLPARM/VOLPARM.
Los montajes de un VTV de una subagrupacin distinta de DRTEST en el entorno de prueba de DR
hacen que el VTV sea de solo lectura. Es decir, no se permite que la prueba de DR se sobrescriba o
se agregue a ningn VTV de produccin.
7.3.3. RECURSOS DE ACS

Los recursos de ACS se utilizan para los escenarios de prueba de DR con cinta real nicamente o
con cinta virtual sin VLE en un entorno de VSM sin cinta. Los recursos de ACS para CDRT se
especifican en el parmetro DRTEST PRIMEPRD/CREATE DRACS.
VTSS de repuesto ejecutarn mensajes SLS6680E a los montajes de VTV.
52
R e st r i c c i o n e s d e A C S s o b r e l a p r ue b a d e D R
Debe ejecutar el comando CAPPREF de HSC para establecer los CAP en modo manual antes de
ejecutar la utilidad DRTEST CREATE. El software garantiza que permanezcan en ese estado durante
la realizacin de la prueba. Despus de que introduce el comando DRTEST START, se aplican
restricciones de ACS sobre la prueba de DR, tanto en el entorno de produccin como en el de
prueba de DR, para garantizar la coherencia en el hardware y los respectivos CDS a fin de permitir
que ambos sitios accedan a los datos. El comando DRTEST START se rechaza si un CAP en un ACS
de prueba de DR est en modo automtico en el entorno de produccin.
El software aplica automticamente las siguientes restricciones.
R e q u i si t o s d e l h o st d e p r o d u c c i n de D R
Los requisitos del host de produccin de DR durante una prueba de DR activa para el ACS de DR
son los siguientes:
53
Los CAP deben permanecer en modo manual.
FLOAT(OFF) y EJCTAUTO(OFF) se aplican automticamente, independientemente de las

configuraciones del comando MNTD.
No puede ejecutar las utilidades de expulsin, movimiento, auditora y reutilizacin para el

ACS de prueba de DR.
R e q u i si t o s d e l h o st d e p r u e b a de D R
Los requisitos del host de prueba de DR durante una prueba de DR son los siguientes:
Ningn ACS distinto de los de prueba de DR se puede cambiar al estado en lnea.
Los CAP deben permanecer en modo manual.
FLOAT(OFF) y EJCTAUTO(OFF) se aplican automticamente y ningn otro valor es vlido en

el comando MNTD.
No puede ejecutar las utilidades de expulsin, movimiento, auditora y reutilizacin para el

ACS de prueba de DR.
Solo
se
permiten
actualizaciones
reutilizables
para
volmenes
definidos mediante
POOLPARM/VOLPARM como volmenes de subagrupaciones reutilizables de prueba de DR.
7.3.4. RECURSOS DE VLE

Puede definir recursos de VLE mediante el parmetro STORMNGR de los comandos PRIMEPRD y
CREATE de DRTEST. Por lo general, los recursos de prueba de DR son los ACS o las VLE, aunque no
hay ninguna restriccin sobre el uso de ambos.
Al igual que los MVC fsicos, los VMVC de VLE se definen mediante la utilidad POOLPARM/VOLPARM,
con un rango de VMVC reservado para la prueba de DR. La prueba de DR tambin tiene acceso de
lectura a los VMVC de produccin, como se muestra en el siguiente ejemplo.

/ / S L U S M V O N D D D S N = h l q. S L U S M V O N , D I S P = ( N E W , C A T L G , D E L E T E ) ,
// SPACE=(CYL, 1)
//* NOTE: MVCMAINT READONLY(OFF) STATEMENTS
/ / S L U S M V O F D D D S N = h l q. S L U S M V O F , D I S P = ( N E W , C A T L G , D E L E T E ) ,
SPACE=(CYL,1)
//* NOTE: THE FOLLOWING STEP SELECTS ALL "ACTIVE" MVCS
//* IN VLE1 AND MVCPOOL MVCP1.
ACTMVCGN STORMNGR=VLE1,MVCP=MVCP1
/*
//* NOTE: EXEC MVCMAINT TO SET READONLY(ON)
//SLSIN DD DSN=hlq.SLUSMVON,DISP=SHR
7.3.5. POLTICAS DE VTCS

Para minimizar las diferencias entre los entornos de produccin y de prueba de DR, la CDRT le
permite definir polticas para la gestin de VTV que tienen el mismo nombre en los entornos de
produccin y prueba de DR, pero distintas definiciones de polticas.
Tenga en cuenta que los sitios de produccin y de prueba pueden compartir un VTSS mediante el
parmetro DRTEST DRVTSS SHARE. Tambin se debe tener en cuenta que ya no es necesario
especificar un ACS ficticio de DR para un VTSS compartido o una prueba de DR que utiliza la VLE.
La especificacin de un VTSS compartido presenta las siguientes restricciones:
Un VTSS compartido de prueba de DR no debe tener conexiones de RTD activas del sitio de
produccin o de prueba de DR.
//SLSIN DD *
54
El CDS debe incluir definiciones VOLPARM para definir las subagrupaciones reutilizables de
prueba de DR.
Los VTV de produccin (los que no estn en una subagrupacin de prueba de DR) se deben
definir como de solo lectura cuando se montan, y no se pueden modificar.
D e f i n i c i n d e M G M T C L A S / S T O R C L A S pa r a V T S S n o c om pa r t i d os
Cuando define clases de gestin para un sistema de prueba de DR, normalmente, define solamente
una copia de MVC de los VTV de salida. Para permitir la limpieza del VTSS despus de la prueba, se
recomienda que se especifique DELSCR(YES) , como se muestra en el siguiente ejemplo.
STOR NAME(LOCAL) ACS(01) MVCPOOL(MVCP1)
MGMT NAME(CRITICAL) MIGPOL(LOCAL) IMMWAIT(0) DELSCR(YES)
D e f i n i c i n d e M G M T C L A S p a r a V T S S c om pa r t i d o s
Cuando usa un VTSS compartido para la prueba de DR, no se permiten copias de salida migradas.
Debe especificar DELSCR(YES) para permitir la limpieza despus de la prueba, como se muestra en
el siguiente ejemplo.
55
MGMT NAME(CRITICAL) DELSCR(YES)
7.3.6. OPTIMIZACIN DEL ACCESO A RECURSOS DE PRUEBA Y

PRODUCCIN
Durante una prueba de DR, se recomienda que aplique procedimientos para optimizar el acceso a
los recursos, tanto en el entorno de prueba como en el de produccin.
Especficamente:
Antes de comenzar la prueba de DR, defina clases de gestin de produccin que

especifiquen la migracin inmediata a los ACS de produccin y prueba de DR, de modo que
los VTV estn disponibles en los MVC accesibles para el sistema de prueba de DR y el
sistema de produccin.
Defina clases de gestin de prueba de DR que especifiquen una sola copia de migracin,
dado que un solo ACS est normalmente disponible para el sitio de prueba de DR.
Use la utilidad POOLPARM/VOLPARM para separar ambas subagrupaciones reutilizables y

las agrupaciones de MVC entre la produccin y la prueba de DR.
De ser posible, asegrese de que el procesamiento de la prueba de DR no actualice ningn

VTV preexistente (DISP=MOD o sobrescritura con DISP=OLD).
Minimice la contencin entre los trabajos de produccin que migran al ACS de prueba de
DR y los trabajos de prueba de DR que acceden a los VTV de los MVC en el ACS de prueba
de DR mediante la ejecucin de la utilidad ACTMVCGN para marcar los MVC activos como
de solo lectura en el entorno de produccin.
Desactive la recuperacin de espacio del MVC (mediante CONFIG HOST NORECLAM) en los
MVC de produccin durante la prueba de DR, a fin de preservar el contenido de volmenes
de MVC que est utilizando el sistema de prueba de DR.
7.3.7. EJECUCIN DE UNA PRUEBA DE DR

N ot a :
Para obtener ms informacin acerca de los comandos y las utilidades que se usan en este
procedimiento, consulte la Referencia de comandos, sentencia de control y utilidades de ELS.
Para ejecutar una prueba de DR:
1. Defina agrupaciones de volmenes en el CDS de produccin mediante el comando SET
VOLPARM y las sentencias POOLPARM/VOLPARM en SLSPARM DD.
Para obtener ms informacin, consulte " Recursos de volmenes."
Para obtener ms informacin, consulte:
"Recursos de ACS"
"Recursos de VTSS"
"Recursos de VLE"
3. Cree sentencias MGMTCLAS/STORCLAS para el entorno DRTEST.

Para obtener ms informacin, consulte:
"Definicin de MGMTCLAS/STORCLAS para VTSS no compartidos"
"Definicin de MGMTCLAS para VTSS compartidos"
4. Si es necesario, copie el catlogo de MVS para el sitio de prueba de DR.

5. De manera opcional, copie la base de datos de TMS (si se usa un TMS) para el sitio de
prueba de DR.
6. En el sitio de produccin, ejecute la utilidad DRTEST (mediante la palabra clave PRIMEprd)
para preparar el CDS de produccin para la prueba de DR.
Por ejemplo, consulte " JCL de muestra para el escenario 1."
Debe ejecutar PRIMEprd una vez en el entorno, independientemente de cuntas iteraciones de
DRTEST ejecute, a menos que la configuracin cambie. Si la configuracin de la prueba de DR
cambia de alguna manera, debe volver a ejecutar PRIMEprd. Tenga en cuenta tambin que no
debe ejecutar la utilidad DRTEST RESET despus de que la prueba de DR se ha completado. Si bien
2. Asegrese de que los recursos de prueba estn correctamente definidos.
56
los indicadores permanecen establecidos en el CDS de produccin, no afectan el procesamiento,

siempre que la prueba de DR no est activa.
7. En el sistema de produccin, use el comando CAPPREF de HSC para establecer todos los
CAP del ACS de prueba de DR en modo manual.
8. En el sitio de prueba de DR, ejecute la utilidad DRTEST (mediante la palabra clave CREATE)
en una copia de seguridad o reflejada del CDS de produccin para crear el nuevo CDS de
prueba de DR para la prueba de DR.
Cada escenario ofrece un ejemplo de DRTEST CREATE.
Los CDS se deben asignar utilizando las sentencias DD en la utilidad. Tenga en cuenta que cuando
se utiliza NOUPD, solo se necesita la sentencia SLSCNTL DD, y puede tratarse del CDS principal
real, una copia de seguridad o una copia reflejada.
Comience
la
prueba
de
DR
en
el
sitio
de
produccin,
apuntando
las
definiciones
MGMTCLAS/STORCLAS de DRTEST que cre en el paso 3.
57
Por ejemplo:
/PRIME EXEC PGM=SLUADMIN,PARM='MIXED'
//SLSIN DD *
DRTEST START
N ot a :
9. Tambin puede iniciar la prueba introduciendo el comando DRTEST START desde la
consola.
10. Inicie el sistema SMC en los hosts del cliente de DRTEST.
11. Inicie los sistemas SMC/HSC/VTCS (apuntando a los CDS que cre en el paso 8) en los
sistemas de prueba de DR.
12. Verifique que los VTD para los VTSS de prueba y las rutas estn en lnea.
13. Coloque los VTSS de DR en lnea para el sistema de DR.
14. Si corresponde, coloque las RTD de DR en lnea para el sistema de DR.
15. Ejecute las pruebas en el sitio de prueba de DR. Durante la prueba de DR, se aplican las
siguientes condiciones programticas:
Los ACS del sitio de produccin se desconectan de los hosts de prueba de DR.
Los VTSS del sitio de produccin estn fuera de lnea para los hosts de prueba de DR.
No se pueden producir desmontajes, expulsiones, movimientos, actualizaciones

reutilizables, auditoras ni redistribuciones reutilizables flotantes en el sitio de prueba
de DR.
No se pueden producir desmontajes, inserciones/expulsiones, movimientos, auditoras

ni redistribuciones reutilizables flotantes en el ACS de prueba de DR en el sitio de
produccin.
Todos los CAP del ACS de prueba de DR se encuentran en modo manual.
N ot a :
Puede introducir volmenes en el ACS de prueba de DR, pero una vez que la prueba ha finalizado,
debe expulsar los volmenes o auditar las celdas para sincronizar el CDS de produccin con los
volmenes de biblioteca reales.
7.4. LIMPIEZA DESPUS DE UNA PRUEBA DE DR

Como se describe al comienzo de este captulo, es fundamental que los trabajos de un flujo de
trabajo de prueba de DR no actualicen los volmenes creados en la produccin.
N ot a :
Para obtener informacin acerca del comando DRTEST y la utilidad DRTEST, consulte la Referencia
mensajes de CDRT, consulte los Mensajes y cdigos de ELS.
7.4.1. LIMPIEZA DESPUS DE UNA PRUEBA DE DR

N ot a :
Para ELS 7.1 y superiores, si tiene instalado SPE de mejora de limpieza de CDRT, no debe ejecutar
este procedimiento inmediatamente despus de la prueba de DR o antes de reanudar el entorno de
produccin normal. En cambio, puede ejecutarlo sin interrupciones (por ejemplo, antes de la
prxima prueba de DR).
1. Ejecute la utilidad SCRAtch de SLUADMIN para reutilizar todos los VTV posibles en las
agrupaciones de DRTEST.
Debido
a que
establece
DELSCR(YES)
en
la
clase
de
gestin,
los VTV
se
suprimirn
automticamente del buffer cuando los reutilice al final de la prueba.

ADVERTENCIA:
Si no utiliza SET VOLPARM y no establece agrupaciones reutilizables independientes,
correr el riesgo de perder datos.
2. Si la prueba de DR ha modificado o puede haber modificado cualquier VTV de produccin,
tambin debe hacer lo siguiente para asegurarse de que ningn dato de prueba de DR
permanezca en el VTSS de produccin:
de comandos, sentencia de control y utilidades de ELS. Para obtener informacin acerca de los
58
Ejecute un informe de VTV en el CDS de DRTEST y examine la salida para determinar si

algn VTV en los rangos de VTV de produccin se modificaron durante la prueba.
Tenga en cuenta que VTVRPT COPIES ahora indica con una "D" en la columna de DRT las copias de
VTV que son copias de prueba de DR.
Si se modific un VTV, debe realizar alguna de las siguientes acciones:

o
Realice una migracin bajo demanda de los VTV modificados en funcin del informe
de VTV.
Migre el VTSS de prueba de DR a 0.
Solictele a un CSE que "limpie" el VTSS de prueba.
3. Detenga el HSC/VTCS y el SMC en el sistema de MVC de PRUEBA de DR.

4. Si la utilidad ACTMVCGN se ejecut antes de la prueba para colocar los MVC en el estado
READONLY, ejecute SLUADMIN mediante la salida de la sentencia SLUSMVOF DD como
entrada para restablecer el estado READONLY.
7.4.2. REANUDACIN DE LAS OPERACIONES NORMALES
59
Siga este procedimiento para reiniciar las operaciones y detener la prueba de DR.
1. Detenga la prueba de DR en el sistema MVS de PRODUCTION.
Por ejemplo:
/STOP EXEC PGM=SLUADMIN,PARM='MIXED'
//SLSIN DD *
DRTEST STOP
Tenga en cuenta tambin que no debe ejecutar la utilidad DRTEST RESET despus de que la
prueba de DR se ha completado. Si bien los indicadores permanecen establecidos en el CDS de
produccin, no afectan el procesamiento, siempre que la prueba de DR no est activa.
2. Si lo desea, coloque los CAP en modo automtico.
7.5. ESCENARIOS OPERATIVOS

En esta seccin, se indica cmo usar el software de prueba de DR para configurar el entorno para
iniciar y detener las pruebas de DR. Esta seccin incluye la siguiente informacin:
"Escenario 1: Sitios de prueba y produccin, ACS en cada sitio, VTSS de reserva en el sitio de
prueba"
"Escenario 2: Sitios de prueba y produccin, ACS en cada sitio, toma de control del VTSS
en el sitio de prueba"
"Escenario 3: Sitios de prueba y produccin, ACS en cada sitio, sin VTSS"
"Escenario 4: VTSS en cluster con sitios de produccin y prueba de DR"
"Escenario 5: Sitios de prueba y produccin, ACS y VLE en cada sitio"
"Escenario 6: Sitios de prueba y produccin, solo VLE en cada sitio"
"Escenario 7: VTSS en cluster (sin cinta) con sitios de produccin y prueba de DR"
Para obtener informacin acerca del comando DRTEST y la utilidad DRTEST, consulte la Referencia
de comandos, sentencias de control y utilidades de ELS. Para obtener informacin acerca de los
mensajes de CDRT, consulte los Mensajes y cdigos de ELS.
Nota:
Para todos los escenarios, despus de la prueba, ejecute el procedimiento que se indica " Limpieza
7.5.1. ESCENARIO 1: SITIOS DE PRUEBA Y PRODUCCIN, ACS EN

CADA SITIO, VTSS DE RESERVA EN EL SITIO DE PRUEBA
En el escenario 1, hay un solo ACS en los sitios de prueba y produccin, y los VTSS de "reserva" en
el sitio de prueba se usan nicamente para la realizacin de pruebas (no hay requisitos que
establezcan que se debe migrar o restaurar el contenido de los VTSS de "reserva"). En las
operaciones normales, el sitio de produccin escribe los VTV y accede a ellos en los VTSS del sitio
de produccin, y los VTV de salida siempre se migran inmediatamente y se duplican en MVC
separados, uno en cada ACS. En Figura 7.1, Configuracin de VTSS de reserva: antes de la
ejecucin de la utilidad DRTEST, se muestra el sistema del escenario 1 antes de ejecutar la
utilidad DRTEST.
despus de una prueba de DR."
60
Figura 7.1. Configuracin de VTSS de reserva: antes de la ejecucin de la utilidad DRTEST

utilidad DRTEST
J C L d e m u e s t r a p a r a e l e sc e n a r i o 1
61
Paso PRIMEPRD:
//DRTPRIME EXEC PGM=SLUADMIN,PARM='MIXED'
//SLSIN DD *
DRTEST PRIMEPRD +
DRACS(01) DRVTSS(VTSS0) SPARE HOST(MVS1,MVS2)
Paso CREATE:
//DRTCREAT EXEC PGM=SLUADMIN,PARM='MIXED'
//SLSNEW1
DSN=hlq.DRTEST.SLSCNTL,DISP=(NEW,CATLG,DELETE),
DD
// UNIT=SYSDA,SPACE=(CYL,x)
//SLSNEW2
DSN=hlq.DRTEST.SLSCNTL2,DISP=(NEW,CATLG,DELETE),
DD
//SLSNEW3
DSN=hlq.DRTEST.SLSSTBY,DISP=(NEW,CATLG,DELETE),
DD
//SLSIN DD *
DRTEST CREATE NOUPDPRD +
DRACS(01) DRVTSS(VTSS0) SPARE HOST(MVS1,MVS2)
En Figura 7.2, Configuracin de VTSS de reserva: despus de la ejecucin de la utilidad DRTEST,
se muestra el sistema del escenario 1 (VTSS de reserva en el sitio de prueba) despus de la
Figura 7.2. Configuracin de VTSS de reserva: despus de la ejecucin de la utilidad DRTEST

utilidad DRTESTutilidad DRTEST

CADA SITIO, TOMA DE CONTROL DEL VTSS EN EL SITIO DE PRUEBA
En el escenario 2, hay un solo ACS, tanto en el sitio de produccin como en el de prueba, pero no
hay VTSS de "reserva" en el sitio de prueba para la realizacin de la pruebas. En las operaciones
normales, el sitio de produccin escribe los VTV y accede a ellos en los VTSS de ambos sitios, y los
VTV de salida siempre se migran inmediatamente y se duplican en MVC separados, uno en cada
ACS. En esta configuracin, debe realizar una migracin bajo demanda a cero de uno o ms VTSS
en el sitio de prueba y colocar estos VTSS en estado fuera de lnea para el sistema de produccin,
de modo que las pruebas puedan tomar el control de los recursos de VTSS necesarios. Adems, en
el sitio de prueba, una o ms LPAR funcionan como sistemas de produccin desplazados que se
ejecutan en paralelo con los sistemas de produccin reales. Ambos ACS estn en lnea para el sitio
de produccin.
ejecucin de la utilidad DRTEST.
62
En Figura 7.3, Configuracin de toma de control del VTSS: antes de la ejecucin de la utilidad
DRTEST, se muestra el sistema del escenario 2 (toma de control del VTSS en el sitio de prueba)
antes de la ejecucin de la utilidad DRTEST.
63
Figura 7.3. Configuracin de toma de control del VTSS: antes de la ejecucin de la utilidad DRTEST
de la utilidad DRTESTutilidad DRTESTutilidad DRTEST
J C L d e m u e st r a p a r a e l e s c e n a r i o 2 P a s o C R E A T E sol a m e nt e , P R I M E P R D
e j e c u t a d o a n t e r i or m e n t e :
//DRTCREAT EXEC PGM=SLUADMIN,PARM='MIXED '
//SLSNEW1 DD
//SLSNEW2 DD
//SLSNEW3 DD
//SLSIN DD *
DRACS(01) DRVTSS(VTSS1) HOST(MVS1,MVS2)

En Figura 7.4, Configuracin de toma de control del VTSS: despus de la ejecucin de la utilidad
DRTEST, se muestra el sistema del escenario 2 (toma de control del VTSS en el sitio de prueba)
Figura 7.4. Configuracin de toma de control del VTSS: despus de la ejecucin de la utilidad DRTEST

CADA SITIO, SIN VTSS
hay ningn VTSS en el sitio de prueba para la realizacin de la pruebas. En las operaciones
normales, el sitio de produccin escribe los juegos de datos de cinta y accede a ellos en ambos
sitios. En Figura 7.5, Configuracin real nicamente: antes de la ejecucin de la utilidad DRTEST,
se muestra el sistema del escenario 3 (configuracin real nicamente) antes de la ejecucin de la
utilidad DRTEST.
despus de la ejecucin de la utilidad DRTEST.
Figura 7.5. Configuracin real nicamente: antes de la ejecucin de la utilidad DRTEST
64
En Figura 7.6, Configuracin real nicamente: despus de la ejecucin de la utilidad DRTEST, se

muestra el sistema del escenario 3 (configuracin real nicamente) despus de la ejecucin de la
utilidad DRTEST.
Figura 7.6. Configuracin real nicamente: despus de la ejecucin de la utilidad DRTEST
65
Paso CREATE solamente, PRIMEPRD ejecutado anteriormente:
//SLSNEW1 DD
//SLSNEW2 DD
DSN=hlq.DRTEST.SLSCNTL2,DISP=(NEW,CATLG, DELETE),
//SLSNEW3 DD
//SLSIN DD *
DRTEST CREATE NOUPDPRD + DRACS(01) HOST(MVS1,MVS2)
7.5.4. ESCENARIO 4: VTSS

PRODUCCIN Y PRUEBA DE DR
EN
CLUSTER
CON
SITIOS
DE
Como se muestra en Figura 7.7, Configuracin de un VTSS principal/secundario en cluster:

operaciones normales, en las operaciones normales, el escenario 4 es una configuracin de VTSS
en cluster que se usa para DR, con los sitios de produccin y prueba de DR interconectados a los
ACS de produccin y prueba de DR. En el sitio de produccin, VTSS0 es el principal y VTSS1 es el
Figura 7.7. Configuracin de un VTSS principal/secundario en cluster: operaciones normales
//SLSNEW1 DD
//SLSNEW2 DD
DSN=hlq.DRTEST.SLSCNTL2,DISP=(NEW, CATLG,DELETE),
//SLSNEW3 DD
secundario en el sitio de prueba de DR.
66
//SLSIN DD *
DRACS(01) DRVTSS(VTSS1) SHARE HOST(MVS1,MVS2)
Qu ocurre si desea usar el sitio de prueba de DR para realizar pruebas? En Figura 7.8,
Configuracin de un VTSS principal/secundario en cluster: durante la prueba, se muestra el
sistema del escenario 4 durante la prueba de DR.
67
Figura 7.8. Configuracin de un VTSS principal/secundario en cluster: durante la prueba
7.5.5. ESCENARIO 5: SITIOS DE PRUEBA Y PRODUCCIN, ACS Y

VLE EN CADA SITIO
hay VTSS de "reserva" en el sitio de prueba para la realizacin de la pruebas. En las operaciones
normales, el sitio de produccin escribe los VTV y accede a ellos en los VTSS de ambos sitios, y los
VTV de salida siempre se migran inmediatamente y se duplican; una copia se migra a un MVC del
ACS y otra, a un VMVC de la VLE. En esta configuracin, debe realizar una migracin bajo demanda
a cero de uno o ms VTSS en el sitio de prueba y colocar estos VTSS en estado fuera de lnea para
el sistema de produccin, de modo que las pruebas puedan tomar el control de los recursos de
VTSS necesarios. Adems, en el sitio de prueba, una o ms LPAR funcionan como sistemas de
produccin desplazados que se ejecutan en paralelo con los sistemas de produccin reales. Tanto
los ACS como las VLE estn en lnea para el sistema de produccin.
En Figura 7.9, Configuracin de VLE y ACS: antes de la ejecucin de la utilidad DRTEST, se
muestra el sistema del escenario 5 antes de la ejecucin de la utilidad DRTEST.
Figura 7.9. Configuracin de VLE y ACS: antes de la ejecucin de la utilidad DRTEST

//SLSNEW1 DD
//SLSNEW2 DD
//SLSNEW3 DD
DSN=hlq.DRTEST.SLSSTBY,DI SP=(NEW,CATLG,DELETE),
//SLSIN DD *
DRACS(01) DRVTSS(VTSS1) HOST(MVS1,MVS2) STORMNGR(VLE1)
En Figura 7.10, Configuracin de VLE y ACS: despus de la ejecucin de la utilidad DRTEST, se
muestra el sistema del escenario 5 despus de la ejecucin de la utilidad DRTEST.
68
Figura 7.10. Configuracin de VLE y ACS: despus de la ejecucin de la utilidad DRTEST
7.5.6. ESCENARIO 6: SITIOS DE PRUEBA Y PRODUCCIN, SOLO

VLE EN CADA SITIO
69
En el escenario 6, hay un solo VTSS con una VLE conectada en cada sitio. El VTSS del sitio de
prueba no es de reserva y lo usa el sitio de produccin durante las operaciones normales. Los VTV
de salida siempre se migran inmediatamente y se duplican en VMVC independientes, uno en cada
VLE.
En esta configuracin, debe realizar una migracin bajo demanda a cero de uno o ms VTSS en el
sitio de prueba y colocar estos VTSS en estado fuera de lnea para el sistema de produccin, de
modo que las pruebas puedan tomar el control de los recursos de VTSS necesarios. Adems, en el
sitio de prueba, una o ms LPAR funcionan como sistemas de produccin desplazados que se
ejecutan en paralelo con los sistemas de produccin reales.
Ambas VLE estn en lnea para el sitio de produccin.
En Figura 7.11, Configuracin de solo VLE: antes de la ejecucin de la utilidad DRTEST, se
muestra el sistema del escenario 6 antes de la ejecucin de la utilidad DRTEST.
Figura 7.11. Configuracin de solo VLE: antes de la ejecucin de la utilidad DRTEST
//SLSNEW1 DD
//SLSNEW2 DD
//SLSNEW3 DD
//SLSIN DD *
STORMNGR(VLE1) DRVTSS(VTSS1) HOST(MVS1,MVS2)
En Figura 7.12, Escenario de solo VLE: despus de la ejecucin de la utilidad DRTEST, se muestra
el sistema del escenario 6 despus de la ejecucin de la utilidad DRTEST.
70
Figura 7.12. Escenario de solo VLE: despus de la ejecucin de la utilidad DRTEST
7.5.7. ESCENARIO 7: VTSS EN CLUSTER (SIN CINTA) CON SITIOS

DE PRODUCCIN Y PRUEBA DE DR
Como se muestra en Figura 7.13, Configuracin de un VTSS principal/secundario en cluster sin
cinta: antes de la ejecucin de la utilidad DRTEST, en las operaciones normales, el escenario 7 es
71
una configuracin de VTSS en cluster (sin cinta) utilizada para DR, con un sitio de produccin y uno
de prueba de DR. En el sitio de produccin, VTSS0 es el principal y VTSS1 es el secundario en el
sitio de prueba de DR.
Figura 7.13. Configuracin de un VTSS principal/secundario en cluster sin cinta: antes de la

ejecucin de la utilidad DRTEST
//SLSNEW1 DD
DSN=hlq.DRTEST.SLSCN TL,DISP=(NEW,CATLG,DELETE),
//SLSNEW2 DD
//SLSNEW3 DD
//SLSIN DD *
DRVTSS(VTSS1) SHARE HOST(MVS1,MVS2))
Configuracin de un VTSS principal/secundario en cluster sin cinta: durante la prueba, se

muestra el sistema del escenario 7 durante la prueba de DR.
Figura 7.14. Configuracin de un VTSS principal/secundario en cluster sin cinta: durante la prueba
Qu ocurre si desea usar el sitio de prueba de DR para realizar pruebas? En Figura 7.14,
72
8. CREACIN DE PUNTOS DE RECUPERACIN DEL SISTEMA EN

ENTORNOS DE VSM
Como se describe en " Definicin del objetivo de punto de recuperacin (RTO)," uno de los
aspectos ms importantes de una solucin de DR exitosa es la capacidad de establecer puntos de
control del sistema que garanticen que un juego coherente de datos se pueda usar como punto de
partida de DR.
En relacin con los entornos de VSM, un punto de partida vlido de DR es aquel donde:
Todos los datos empresariales crticos estn protegidos en la ubicacin de DR designada.
Se ha capturado una copia segura de los metadatos (CDS, catlogo de MVS, TMC).
Se garantiza una copia vlida de los metadatos cuando se declara un desastre (ya sea un
desastre real o una prueba).
El VTCS ofrece la capacidad de crear un punto de partida de DR mediante las siguientes funciones:
73
La utilidad DRMONitr supervisa los datos crticos de DR y garantiza que lleguen a la

ubicacin de recuperacin designada. Permite que el procesamiento del flujo de trabajo se
detenga, a la espera de que los datos lleguen a su destino. Una vez que se contabilizan
todos los datos, la utilidad termina. La utilidad DRMONitr se puede ejecutar como paso de
trabajo. Al finalizar el paso de trabajo, se garantiza que todos los datos supervisados se
han contabilizado y se encuentran protegidos en la ubicacin de DR designada.
La utilidad DRCHKPT se utiliza para garantizar que los datos a los que se acceda mediante
los metadatos del CDS sigan siendo vlidos durante un perodo establecido. Esto garantiza
que una copia de seguridad del CDS siga siendo vlida durante un perodo establecido y,
por lo tanto, puede restaurar un sistema VSM nuevamente a un punto de partida de DR. La
utilidad DRCHKPT establece un registro de fecha y hora en el CDS activo, que establece el
punto de recuperacin a partir del cual el contenido de MVC se puede recuperar. A partir de
este punto temporal de recuperacin, se garantiza el contenido de los datos durante algn
tiempo. Sin la utilidad DRCHKPT, una copia de seguridad del CDS no se puede usar para
restaurarla nuevamente al punto de partida de DR, ya que es posible que los elementos del
CDS (posicin de VTV en un MVC) ya no sean vlidos.
Para obtener ms informacin, consulte la Referencia de comandos, sentencia de control y

Utilidades de ELS.
Tambin, tenga en cuenta lo siguiente:
Para los VMVC, MVCDRAIN con el parmetro EJECT elimina fsicamente los VTV.
Atencin:
Si usa la utilidad DRCHKPT o el parmetro CONFIG GLOBAL PROTECT para proteger el contenido de
copia de seguridad del CDS para los VMVC, la especificacin de MVCDR EJECT invalida el contenido
del VMVC de la copia de seguridad del CDS.
Para ambos VMVC y MVC, MVCDRAIN sin el parmetro EJECT no suprime los VTV, pero
actualiza el registro del CDS para no mostrar VTV en el VMVC/MVC.
Para obtener ms informacin, consulte la Referencia de comandos, sentencia de control y

utilidades de ELS.
8.1. EJEMPLOS DE PUNTOS DE CONTROL
"Ejemplo 1: copias de MVC locales y copias de MVC remotas"
"Ejemplo 2: uso de CONFIG RECLAIM PROTECT"
8.1.1. EJEMPLO 1: COPIAS DE MVC LOCALES Y COPIAS DE MVC

REMOTAS
En este ejemplo:
Las utilidades DRMONitr y DRCHKPT garantizan que los datos de DR lleguen a su ubicacin
de recuperacin y que los metadatos asociados (copia de seguridad del CDS) recuperen los
datos del VTV de ser necesario.
Se muestra un sitio local con un VTSS ms un ACS (ACS 00) y un sitio remoto con un solo
ACS (ACS 01), como se puede ver en Figura 8.1, Ejemplo de puntos de recuperacin del
sistema VSM (locales y remotos).
El ejemplo es una estrategia simple de DR donde, diariamente, se protegen copias de datos crticos
en el sitio remoto junto con los metadatos. Las copias del VTV remoto son las copias de DR
designadas.
Despus de que finalizan los trabajos de produccin, se programa un trabajo para realizar lo
siguiente:
Supervisar que se hayan completado las copias remotas (DRMONitr).
Verificar los puntos de control del CDS (DRCHKPT).
Realizar una copia de seguridad de los metadatos (CDS, TMC, catlogo de MVS) y
protegerla en el sitio remoto. Se debe tener en cuenta que las copias de seguridad de
los metadatos son clave para la DR; se supone que se trasladan a una ubicacin conocida
o que su ubicacin se encuentra registrada en una ubicacin segura.
Se explican los siguientes ejemplos:
74
Esto proporciona un punto de control de DR sincronizado de forma diaria. En el caso de que se

declare una DR, el entorno de cintas se restaura nuevamente al punto de control, y los trabajos se
vuelven a ejecutar a partir de este estado conocido.
Figura 8.1. Ejemplo de puntos de recuperacin del sistema VSM (locales y remotos)
Para ejecutar este ejemplo con la configuracin que se muestra en Figura 8.1, Ejemplo de puntos
75
de recuperacin del sistema VSM (locales y remotos):

1. Cree las siguientes sentencias de poltica.
MGMT NAME(DR) MIGPOL( LOCAL,REMOTE) IMMDELAY(0)
STOR NAME(LOCAL) ACS(00)
STOR NAME(REMOTE) ACS(01)
N ot a :
Para lograr un entorno de DR eficaz, tambin se recomienda considerar la posibilidad de usar las
sentencias MIGRSEL y MIGRVTV, que puede usar para garantizar que las copias de DR se protejan
tan pronto como sea posible.
2. Para garantizar que los datos crticos se protejan en la ubicacin remota, se debe ejecutar
el siguiente ejemplo de paso de trabajo de DRMONitr.
//MONITOR EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB DD DSN=hlq.SE ALINK,DISP=SHR
//SYSIN DD UNIT=SYSDA,SPACE=(TRK,1)
//*
//SYSPRINT DD SYSOUT=*
//SLSIN DD *
DRMON MGMT(DR) STOR(REMOTE) MAXAGE(24) TIMEOUT(30)
En este ejemplo, la utilidad DRMONitr esperar hasta que todas las copias del VTV de DR de clase
de gestin que tengan menos de 24 horas se enven al ACS remoto. La utilidad se configura para
anular la operacin si el tiempo de ejecucin (o de espera) supera los 30 minutos.
3. Una vez que todas las copias del VTV se han entregado al ACS remoto, sealado por un
valor de RC igual a cero, DRCHKPT se ejecuta para establecer el punto de recuperacin,
como se muestra en el siguiente ejemplo.
//CHKPT EXEC PGM=SLUADMIN,PARM='MIXED'
//SLSIN DD *
DRCHKPT SET
En este ejemplo, la utilidad DRCHKPT establece un registro de hora o un punto de recuperacin en
el CDS activo. A partir de este punto temporal de recuperacin, se garantiza el contenido de la
copia de MVC durante algn tiempo (por ejemplo, hasta que se ejecute otra utilidad CHKPT).
4. Una vez que el punto de recuperacin se establece en el CDS activo, se debe realizar una
copia de seguridad del CDS de inmediato, como se muestra en el siguiente ejemplo.
//CHKPT EXEC PGM=SLUADMI N,PARM='MIXED'
//SYSIN DD UNIT=SYSDA,SPACE=(TRK,1)
//*
/ / S L S C N T L D D D S N = S H R , D S N = hl q. D B S E P R M
/ / S L S B K U P D D D S N = S H R , hl q . D B S E P R M . B K U P
//SLSIN DD *
BACKUP OPTION(COPY)
//SLSPRINT DD S YSOUT=*
76
Despus de realizar la copia de seguridad, se garantiza la validez de los metadatos o el contenido

del MVC durante algn tiempo (hasta que se establezca un punto de control o de recuperacin
posterior).
De esta manera, se completa el procedimiento. En caso de que se declare una situacin de DR (el
sitio de produccin local ya no est disponible) realice una de las siguientes acciones:
Transporte los MVC y todos los dems datos crticos (copias de metadatos, por ejemplo) a otra
ubicacin donde est disponible un reflejo del sitio de produccin local.
o
Genere una rplica del sitio de produccin local en la ubicacin remota.
Los metadatos se restauran (CDS, TMC, catlogo de MVS). Al reiniciar el entorno de cintas, todo
puede continuar (avanzar) a partir del punto de sincronizacin de DR.
8.1.2. EJEMPLO 2: USO DE CONFIG RECLAIM PROTECT
77
En este ejemplo, se realizan copias de seguridad del CDS cada 24 horas. El contenido del MVC o los
metadatos del CDS que se encuentran dentro de la copia de seguridad del CDS deben conservar su
validez hasta que se realice una copia de seguridad posterior del CDS.
En este ejemplo, se muestra la proteccin de MVC establecida en 28 horas. Para obtener ms
informacin sobre el parmetro CONFIG RECLAIM PROTECT, consulte Referencia de comandos,
sentencias de control y utilidades de ELS.
1. Defina CONFIG GLOBAL PROTECT = 28.
2. El da 1, realice una copia de seguridad del CDS.
Los MVC drenados/recuperados despus de esta copia de seguridad no se pueden

sobrescribir durante 28 horas.
Ahora, la copia de seguridad del CDS del da 1 es el punto de recuperacin hasta la

prxima copia de seguridad del CDS.
3. El da 2, realice una copia de seguridad del CDS.
Los MVC drenados/recuperados despus de esta copia de seguridad no se pueden

sobrescribir durante 28 horas.
Ahora, la copia de seguridad del CDS del da 2 es el punto de recuperacin hasta la

prxima copia de seguridad del CDS.
9. USO DE LA VLE PARA RECUPERACIN ANTE DESASTRES

El uso de la VLE (Virtual Library Extension) como solucin de recuperacin ante desastres
proporciona un mtodo simplificado y sin interrupciones de realizacin de pruebas de DR y de
recuperacin a partir de un evento de interrupcin de las actividades.
El sistema gestiona la VLE como una biblioteca (ACS). No obstante, debido a que la VLE usa
almacenamiento en disco en lugar de almacenamiento en cinta, y a que mantiene un inventario
interno de los VTV en su contenido, ofrece funciones que una biblioteca real no puede ofrecer:
La VLE es una solucin "sin cinta", que permite evitar los problemas de la gestin de
medios.
Los datos se envan a la VLE mediante IP y no requieren extensin de canal.
La VLE puede realizar una auditora de MVC en cuestin de segundos mediante su base de
datos interna, en comparacin con el montaje y la lectura de un cartucho MVC.
En este captulo, se describe el uso de la VLE en un entorno simple de dos sitios. No obstante, se
VLE en cada sitio. Adems, uno de los sitios puede ser un sitio exclusivo de DR, donde no se
ejecuten LPAR de MVS, excepto durante una prueba de DR o un desastre declarado.
El procedimiento que se indica a continuacin un entorno de dos sitios: SITE1 y SITE2.
Cada sitio tiene un VSM y una VLE. En este ejemplo, el SITE2 se describe como un sitio exclusivo
de DR, pero el SITE2 tambin puede ser un sitio de produccin definido como imagen reflejada de
SITE1.
N ot a :
El tamao del buffer de VLE en el SITE2 debe ser suficiente para alojar tanto los datos migrados de
produccin como los datos creados durante una prueba de DR.
9.1. MODO DE PRODUCCIN NORMAL

Durante la produccin normal se definen polticas en el SITE1 para migrar una copia de los datos al
SITE1 de la VLE local y una segunda copia al SITE2 de la VLE remota. Se pueden crear copias
adicionales, por ejemplo, ambas copias en otra VLE y copias de cinta.
A continuacin, se muestra un ejemplo de polticas definidas en el SITE1:
Las definiciones de SMC se usan para asignar un nombre MGMTCLAS de VLEPROD a los juegos de
datos con un cualificador de nivel superior de "PAYROLL".
debe tener en cuenta que la solucin admite cualquier cantidad de sitios con cualquier cantidad de
78
POLICY
NAME(VLEPOL)
SUBP(VIRTSCR)
MEDIA(VIRTUAL)
MGMT(VLEMGMT)
TAPEREQ DSN(PAYROLL.*) POLICY(VLEPOL)

Las definiciones POOLPARM/VOLPARM de HSC se usan para definir los volmenes de produccin:
POOLPARM TYPE(MVC) NAME(LOCAL)
VOLPARM VOLSER(VLL000 -VLL099)
POOLPARM TYPE(MVC) NAME(VAULT1)
VOLPARM VOLSER(VLV000-VLV099)
POOLPARM TYPE(SCRATCH) NAME(VIRTSCR)
VOLPARM VOLSER(V00000 -V99999) MEDIA(VIRTUAL)
N ot a :
Tenga en cuenta que los MVC en las agrupaciones LOCAL y VAULT1 son VMVC (MVC virtuales) en
79
el SITE1 y el SITE2 de las VLE, respectivamente, y no tienen un tipo de medio asociado a ellos.
VTCS STORCLAS y MGMTCLAS se usan para definir las polticas de VTCS:
STOR NAME(VLE1) STORMNGR( SITE1VLE) MVCPOOL(LOCAL)
STOR NAME(VLE2) STORMNGR(SITE2VLE) MVCPOOL(VAULT1)
MGMT NAME(VLEMGMT) DELSCR(YES) MIGPOL(VLE1,VLE2)
Cuando un trabajo se ejecuta con un juego de datos que comienza con el cualificador de nivel
superior "PAYROLL", SMC usa TAPEREQ y POLICY para asignar una MGMTCLAS de VLEPROD a la
solicitud de montaje. VTCS selecciona un volumen reutilizable virtual en la agrupacin LOCSCR
(rango V00000-V99999) y le asigna una MGMTCLAS de VLEPROD.
Despus de que el volumen se desmonta, se migra una copia a la VLE local (STORMNGR SITE1VLE)
y la segunda copia se migra a la VLE remota (STORMNGR SITE2VLE).
9.2. EJECUCIN DE UNA PRUEBA DE DR CON LA VLE

E proceso de configuracin para una prueba de DR en el SITE2 es simple y rpido, y requiere
restricciones mnimas en el SITE1.
Los pasos bsicos son los siguientes:
1. Cree un nuevo CDS en el SITE2 que incluya solamente datos de configuracin bsica.
2. Marque el VMVC del SITE1 como READONLY para evitar conflictos.
3. Realice una auditora de los MVC virtuales de produccin en la VLE del SITE2. En este paso,
se completan los CDS con los metadatos virtuales existentes. Segn la cantidad de VTV en
la VLE, este paso puede tardar desde unos pocos minutos hasta menos de una hora.
4. Ejecute la carga de trabajo de la prueba de DR con un rango de VTV y MVC que no se
superponga con los volmenes de produccin.
En el resto de esta seccin se proporcionan detalles acerca de la definicin de los parmetros en el
sitio de DR y se describen los pasos que se deben seguir para garantizar que el contenido de los
VMVC de produccin no se modifique durante la prueba.
1. Creacin del CDS de prueba de DR.
a. Utilice el proceso LIBGEN/SLICREAT para crear el CDS en el SITE2. Tenga en cuenta que debe
crear este CDS aunque ya est ejecutando trabajo de produccin en el SITE2. El nuevo CDS
contiene solamente datos de DR del SITE1. Tambin debe tener en cuenta que es necesario definir
al menos un ACS en las macros LIBGEN, aunque su configuracin no incluya cinta fsica.
POOLPARM TYPE(MVC) NAME(VAULT1)

VOLPARM VOLSER(VLV000-VLV099)
POOLPARM TYPE(EXTERNAL) NAME(PRODVTVS)
VOLPARM VOLSER(V00000 -V99999) MEDIA(VIRTUAL)
POOLPARM TYPE(MVC) NAME(DRMVC)
VOLPARM VOLSER(VLT000-VLT099)
POOLPARM TYPE(SCRATCH) NAME(VIRTSCR)
VOLPARM VOLSER(VT0000-VT9999) MEDIA(VIRTUAL)
Tenga en cuenta que las dos primeras agrupaciones definen volmenes creados por el SITE1 que
se utilizarn como entrada para la prueba en el SITE2. El tipo de agrupacin EXTERNAL indica que
estos son volmenes que no forman parte de una subagrupacin reutilizable. Las dos ltimas
agrupaciones son agrupaciones locales que se usarn como salida de la prueba en el SITE2.
c. Defina las MGMTCLAS y STORCLAS de VTCS que se usarn para la prueba de DR:
STOR NAME(DRVLE) STORMNGR(SITE2VLE) MVCPOOL(DRMVC)
MGMT NAME(VLEMGMT) DELSCR(YES) MIGPOL(DRVLE)
d. Tenga en cuenta que debido a que MGMTCLAS y las subagrupaciones reutilizables en el sistema
de DR del SITE2 tienen los mismos nombres que las polticas de produccin (pero distintas
b. Ejecute la utilidad SET VOLPARM para definir los volmenes para la prueba de DR:
80
definiciones), ahora puede usar las mismas sentencias POLICY y TAPEREQ de SMC para la prueba
de DR del SITE2 que las que usa en la produccin del SITE1.
e. Abra el HSC/VTCS en la LPAR de prueba de DR.
2. Marque los MVC de produccin como READONLY.
a. Este es un paso crtico del proceso y se debe realizar tanto en el SITE1 del CDS de produccin
como en el SITE2 del CDS de prueba de DR. Tenga en cuenta que una vez que los MVC se han
definido como READONLY en el CDS de produccin, puede continuar con el procesamiento normal,
que incluye:
RECLAIM. La recuperacin automtica
e st a d o R E A D O N L Y ( S O L O L E C T U R A ) .
no
se l e c c i o na
un
MVC
en
SCRATCH. Si bien los VTV se actualizarn en el CDS de produccin y quedarn en estado

reutilizable, es decir que se podrn reutilizar, la copia del MVC virtual de solo lectura de la VLE no
se ver afectada.
81
Procesamiento normal para agregar o sobrescribir los VTV en los VMVC. Las nuevas versiones de
VTV se migrarn a los nuevos VMVC, mientras que la copia del MVC virtual de solo lectura de la
VLE no se ver afectada.
N ot a :
No obstante, tenga en cuenta que no puede ejecutar la utilidad DRAIN en estos MVC, ya que
elimina la copia de la VLE de los metadatos virtuales de MVC.
b. Utilice la utilidad ACTMVCGN para seleccionar los MVC de produccin en el sitio de produccin
mediante el CDS de produccin. Esta utilidad genera sentencias de control para establecer el
indicador READONLY en los MVC que selecciona y sentencias de control para desactivar el indicador
READONLY una vez que la prueba ha finalizado. Al usar la palabra clave ALL en la sentencia de
control ACTMVCGN se garantiza que se seleccionen todos los MVC para procesamiento READONLY,
lo que permite que se ejecute la recuperacin automtica en el sistema de produccin sin afectar la
prueba de DR. La sentencia SLUSMAUD DD tambin se debe incluir para generar sentencias AUDIT
para los VMVC que se usarn en la prueba. Tenga en cuenta que, si lo desea, puede ejecutar la
utilidad ACTMVCGN en el sitio de produccin para crear las actualizaciones de produccin y en el
sitio de DR, en una copia reflejada del CDS, para crear las actualizaciones de CDS de la prueba de
DR. En el siguiente ejemplo, se muestra un JCL de muestra para ejecutar esta utilidad:
//ACTMVCGN JOB (ACCT),'ACTMVCGN',NOTIFY=&SYSUID
//* NOTE:
p r o d u c t i on
CDS
DD
st a t e m e n t s
are
op t i o n a l
if
r u n ni n g
at
t he
/ / * si t e w i t h a n a c t i v e H S C L P A R .
//SLSCNTL DD DSN=hlq.DBASEPRM,DISP=SHR
/ / S L S C N T L 2 D D D S N = h l q. D B A S E S E C , D I S P = S H R
//SLSSTBY DD DSN=hlq.DBASESBY,DISP=SHR
/ / S L U S M V O N D D D S N = h l q. S L U S M V O N , D I S P = ( N E W , C A T L G , D E L E T E ) ,
// SPACE=(CYL,1)
//* NOTE: MVCMAINT REA DONLY(OFF) STATEMENTS
/ / S L U S M V O F D D D S N = h l q. S L U S M V O F , D I S P = ( N E W , C A T L G , D E L E T E ) ,
//* NOTE: AUDIT MVC(VVVVVV) STATEMENTS

/ / S L U S M A U D D D D S N = h l q. S L U S M A U D , D I S P = ( N E W , C A T L G , D E L E T E ) ,
// SPACE=(CYL,1)
//* NOTE: THE FOLLOWING SELECTS ALL "NON -EMPTY" VMVCS
//SLSIN DD *
ACTMVCGN ALL MVCPOOL(VAULT1)
/*
3. En el sitio de produccin, ejecute la funcin de la utilidad MVCMAINT para marcar los VMVC
como READONLY.
//RDONLYON EXEC PGM=SLUADMIN,PARM='MIXED'
//SLSPRINT DD SYS OUT=*
/ / * N O T E : E X E C M V C M A I N T T O S E T R E A D O N L Y ( O N ) . O ut p ut of
//* ACTMVCGN utility.
4. Abra el HSC/VTCS en el sitio de DR.
// SPACE=(CYL,1)
82
5. Ejecute una autora de MVC de los VMVC de produccin en el SITE2 de la VLE con el CDS del
SITE2 recientemente creado y la salida de la utilidad ACTMVCGN. En este paso, se completan los
metadatos de CDS que contienen las relaciones entre los VTV y los VMVC.
//AUDIT EXEC PGM=SLUADMIN
//* NOTE: AUDIT CONTROL STATEMENTS FROM ACTMVCGN UTILITY
//SLSIN DD DSN=hlq.SLUSMAUD,DISP=SHR
De manera opcional, puede recuperar los VTV que se utilizarn en la prueba de DR en el buffer de
VTSS, mediante LCM u otro mtodo de seleccin de VTV para recuperacin.
No obstante, este paso no es necesario, ya que las recuperaciones a partir del buffer de la VLE son
relativamente rpidas.
83
6. Ejecute la utilidad MVCMAINT mediante la salida de ACTMVCGN READONLY(ON) para establecer

los VMVC de produccin en READONLY en el SITE2, en el CDS de DR.
//RDONLYON EXEC PGM=SLUADMIN,PARM='MIXED'
/ / * N O T E : E X E C M V C M A I N T T O S E T R E A D O N L Y ( O N ) . O ut p ut of
//* ACTMVCGN utility.
7. Opcional: Antes de comenzar la prueba de DR, puede ejecutar VTVRPT y MVCRPT para validar el
contenido del CDS de prueba de DR.
8. Ejecute la carga de trabajo de prueba de DR.
a. Abra SMC. Si us los mismos nombres en la MGMTCLAS y las subagrupaciones reutilizables que
en el sistema de produccin, puede usar sus sentencias de produccin TAPEREQ y POLICY. Se
recomienda, pero no es obligatorio, que utilice un nombre de TapePlex distinto para el TapePlex de
prueba de DR.
b. Ejecute la carga de trabajo de DR con el SMC y el nuevo CDS de HSC/VTCS.
c. No hay limitaciones sobre la actualizacin de volmenes de produccin de VTV durante las

pruebas de DR. Los datos de los VTV de produccin se pueden agregar
a (DISP=MOD) o sobrescribir (DISP=OLD). Estas actualizaciones no afectan el contenido de la
copia de VTV en el MVC de produccin virtual READONLY y, por lo tanto, no afectan la copia de
produccin de los datos.
9.3. LIMPIEZA DESPUS DE UNA PRUEBA DE DR CON VLE

Una vez que la prueba de DR ha finalizado, el objetivo de la limpieza es eliminar metadatos del
VTSS y de la VLE, de modo que la siguiente prueba de DR no vea estos datos. Tenga en cuenta
que el HSC/VTCS de la prueba de DR debe permanecer activo hasta que la limpieza haya
finalizado. Los pasos son los siguientes:
1. Ejecute la funcin de la utilidad SCRATCH para reutilizar todos los VTV creados durante la
prueba del VTSS y de los VMVC de la prueba de DR de la VLE. Cuando el parmetro DELSCR(YES)
se especifica en la prueba de DR MGMTCLAS, la ejecucin de la utilidad de reutilizacin hace que
//SCRATCH EXEC PGM=SLUADMIN

//SLSIN DD *
SCRATCH VOL(VT0000 -VT9999)
Tenga en cuenta que si modific cualquier VTV de produccin mediante DISP=MOD o DISP=OLD,
estos VTV permanecen en el buffer y en la VLE.
Al reutilizar los VTV de la subagrupacin de la prueba DR despus de la prueba, minimiza la
cantidad de tiempo que se necesita para limpiar el VTSS y la cantidad de datos que quedan en la
VLE despus de la finalizacin de la prueba.
2. Migre el VTSS a 0.
//MIGRTO0 EXEC PGM=SLUADMIN
//SLSIN DD *
MIGRATE VTSS(DRVTSS) THRESHLD(0)
los VTV se supriman de los metadatos de la VLE y del buffer.
84
Este paso se debe realizar solamente si la salida de su prueba de DR inclua nuevas versiones de
VTV de produccin.
3. Verifique que el VTSS de DR ahora est vaco.
//AUDVTSS EXEC PGM=SLUADMIN
//SLSIN DD *
AUDIT VTSS(DRVTSS)
Tenga en cuenta que si modific los VTV de produccin durante la prueba de DR, las copias de
estos datos y los metadatos permanecen en la VLE para la agrupacin de MVC de la prueba de DR
(VLT000-VLT099, VTV V00000-V99999). Durante la siguiente prueba de DR, estos VMVC se
escribirn a partir del comienzo lgico de la cinta, y cualquier dato que contengan se eliminar de
la VLE. Dado que el nuevo CDS de prueba de DR no tiene conocimiento de estos datos, no afectar
85
a la siguiente prueba de DR.

4. En el sitio de produccin, use las tarjetas de control READONLY(OFF) creadas por la utilidad
ACTMVCGN al comienzo de la prueba para colocar los VMVC de produccin nuevamente en un
estado que admita escritura.
//RDONLYOF EXEC PGM=SLUADMIN,PARM='MIXED'
//* NOTE: EXEC MVCMAINT TO SET READONLY(OFF)
//SLSIN DD DSN=hlq.SLUSMVOF,DISP=SHR
9.4. USO DE LA VLE PARA CONTINUIDAD EMPRESARIAL

Cuando se produce una interrupcin en el SITE1 que requiere que el SITE2 tome la carga de
trabajo del SITE1, el proceso es casi idntico al procedimiento de prueba de DR.
Si se est ejecutando una prueba de DR cuando se produce la interrupcin del SITE1, siga el
proceso que se describe anteriormente para realizar una limpieza despus de la prueba de DR y
detenga la prueba de DR.
Para comenzar a ejecutar la carga de trabajo del SITE1 en el SITE2, siga el procedimiento descrito
anteriormente para iniciar una prueba de DR. Obviamente, omitir el paso que consiste en marcar
los VMVC de produccin como READONLY en el CDS de produccin, ya que no hay un CDS de
"produccin" para actualizar. No obstante, utilizar la copia reflejada del CDS de produccin para
generar las tarjetas de control MVCMAINT READONLY para los MVC de produccin en la VLE.
Tambin tendr que usar las polticas de prueba de DR que separan los VTV que se estn creando y
los VMVC de salida en un rango separado, a fin de evitar cualquier posibilidad de daar los datos
de produccin hasta despus de que se haya verificado la continuidad empresarial.
N ot a :
Si los trabajos de produccin que realizan el procesamiento de DISP=MOD para datos de cinta no
tienen un punto de sincronizacin definido, puede que el contenido de un VTV en el momento de
una interrupcin sea impredecible. StorageTek recomienda revisar todos los procedimientos de
recuperacin ante desastres a fin de garantizar puntos de sincronizacin predecibles para los datos
de cinta.
86

AA2-Ev4 - Plan de Configuración y Recuperación Ante Desastres para El SMBD

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AA2-Ev4 - Plan de Configuración y Recuperación Ante Desastres para El SMBD

Uploaded by

Copyright:

Available Formats

AA2-Ev4- Plan de configuracin y

recuperacin ante desastres para

ALCALDIA SAN ANTONIO DEL SENA

AA2-Ev4- Plan de configuracin y

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

El concepto de Alta disponibilidad o HA (High Availability) es indispensable en una empresa por lo

La arquitectura de un SGBD hace referencia al modelo interno de funcionamiento del sistema. Es

1.1 ESTRUCTURAS LGICAS DE LA BASE DE DATOS

Procedimientos y funciones. Cdigo del lenguaje procedimental de la base de datos

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

1.2 ESTRUCTURAS FSICAS E INTERNAS DE LA BASE DE DATOS

1.3 INSTANCIAS DE BASES DE DATOS

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

Ilustracin 1, Proceso de trabajo con la instancia de una base de datos

1.4 QU ES UN SERVIDOR ORACLE?

Ilustracin 2, Arquitectura interna de Oracle

B u f f e r d e c a c h d e b a se de da t os . Almacena bloques de datos ledos de la base

B u f f e r r e d o l og . Estructura que almacena los datos anteriores y posteriores a cada

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

1.4.1 A rquitectura en memoria del servidor Oracle

S h a r e d p o ol . Consta de la cach del diccionario de datos y de la cach de instrucciones

J a v a P o ol . Slo se usa si hemos instalado Java para agilizar el proceso de las

fundamentales sonre la base de datos, entre ellos:

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

pasen a grabarse en ficheros de datos y as asegurarles en caso de problemas. El hecho de

C K P T . Proceso encargado de comunicar la llegada de un checkpoint, punto de control que

S M O N . System Monitor. Proceso encargado de monitorizar el sistema para que funcione

P M O N . Process Monitor. Se encarga de la comunicacin con la PGA y especialmente con

La informacin sobre la sesin con el cliente

El estado de procesamiento de la instruccin SQL actual

compartida de proceso servidor. Cuando el proceso cliente y el servidor establecen conexin, se

Ilustracin 3, Funcionamiento del proceso servidor y de usuario

1.4.2 ARQUITECTURA EN DISCO DE ORACLE

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

Ilustracin 4, Esquema bsico de funcionamiento de los tablespaces de Oracle

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

Ilustracin 6, Correspondencia entre los distintos elementos fsicos y lgicos de Oracle

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

Ilustracin 5, Arquitectura de los tablespaces

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

Nombre de la base de datos

Fecha y hora de la creacin de la base de datos

Informacin sobre checkpoints y redo logs.

Modo de archivado de la base de datos.

Nmero de secuencia del redo log actual.

Metadatos para backup y recuperacin de datos.

2.1 PASO 1: SELECCIN POR REQUISITOS

T a m a o d e l a b a se d e da t o s. Un gran tamao de base de datos requiere se

C o ne c t i v i d a d . Si necesitamos que la base de datos sea accesible desde Internet, una

N m e r o d e u s u a r i o s . Un nmero grande de usuarios requiere controles avanzados de

A p r ov e c h a m i e n t o d e h a r d wa r e . Puede ser que sea el propio hardware de la

P ol t i c a d e e m p r e sa . Por ejemplo si la empresa tiene una poltica de impulso de

2.2 PASO 2: COMPROBAR REQUERIMIENTOS

S i s t e m a s o p e r a t i v o s . No todos los SGBD son multiplataforma, lo normal es que sean

P a q u e t e s o a p l i c a c i o n e s p r e i n st a l a da s . A veces se requiere que el sistema

M e m o r i a R A M . Es el requisito que ms importa: ms RAM, ms ligero funciona el

P r oc e s a d o r . Se suele exigir un modelo y una velocidad mnima en el mismo.

D i s c o d u r o. Se exige un espacio mnimo de disco.

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

R e q u i si t o s d e r e d . Se puede exigir que el equipo tenga una funcin concreta como

I n c o m p a t i b i l i d a d e s . A veces se indican productos con los que existen problemas de

AA2-Ev4- Plan de configuracin y recuperacin ante desastres para el SMBD | 07/07/2016

L i n u x / U n i x . En ORACLE_HOME/dbs/spfileSID.ora, donde el SID es el identificador de la