Solución a Problemas Frecuentes en Replication Server

Tabla de Contenido

• Introducción
• Conceptos Básicos
• ¿Cómo identificar típicos problemas en un sistema de replicación y qué hacer?
• ¿Qué hacer cuando un mensaje "loss detected" aparece en el log de errores de un servidor de replicación?
• El Transaction Cache Size es muy pequeño
• ¿Qué hacer cuando se llena el log de transacciones de una base de datos que pertenece a un sistema de Replicación?
• ¿Cómo identificar y limpiar la información de una cola (stable queue) en un sistema de replicación?
• ¿Cómo eliminar un servidor de replicación de un sistema de replicación, cuando éste ya no está disponible?
• ¿Cómo recuperar la base de datos RSSD con un backup de último minuto?
• ¿Cómo recuperar la base de datos RSSD sin un backup de último minuto?
• ¿Cómo restablecer un sistema de replicación, después de ejecutar la carga de un backup en la base de datos primaria?
• ¿Qué hacer cuando un dispositivo (stable device) de un servidor de replicación se daña?
• Bibliografía

Introducción

Replication Server provee una arquitectura que permite construir un ambiente de replicación a partir de sistemas y aplicaciones ya existentes, con la finalidad de mantener datos replicados en múltiples bases de datos, mientras se asegura la integridad y consistencia de los mismos. Un ambiente de replicación esta conformado por uno o varios servidores de datos, agentes de replicación y servidores de replicación.

Este documento examina diferentes dificultades que se pueden presentar en un sistema de replicación, desde complicaciones a nivel de los servidores de replicación como a nivel del servidor de datos y para cada situación muestra los pasos a seguir para restablecer el ambiente.

Es importante anotar que este documento no busca reemplazar los cursos avanzados y manuales de replicación, ni tampoco el soporte técnico que debe solicitarse cuando se encuentran situaciones de riesgo para el sistema de replicación. El presente texto pretende ser una guía rápida para aquellos administradores de un sistema de replicación que tienen una capacitación y conocimientos suficientes para asumir la responsabilidad de ejecutar algunas de las tareas aquí mencionadas cuando una situación de recuperación o daño afecta de alguna manera el sistema de replicación.

Conceptos Básicos

• Servidores de Bases de Datos – Administran las bases de datos que contienen los datos primarios o replicados.

Se llaman datos primarios, a aquellos datos que se desean replicar y datos replicados a aquellos que fueron consignados a través de un servidor de replicación. Un servidor de replicación se conecta a los servidores de bases de datos replicados como un usuario de la base de datos.

• Servidor de Replicación – Servidor que coordina las actividades de replicación de datos entre servidores de base de datos y/o de intercambio de datos con otros servidores de replicación que se encuentren en otros sitios.

La información que recibe un servidor de replicación puede provenir de: 1. Transacciones de datos originadas en una base de datos primaria, para ser distribuidas a los sitios con subscripciones a ella; 2. Transacciones enviadas por otro servidor de replicación para que ser aplicadas a sus bases de datos locales.

• ID Server – Es un servidor de replicación que registra todos los servidores de replicación y todos los servidores de bases de datos en el sistema de replicación. El ID Server debe estar corriendo cada vez que un nuevo servidor de replicación es instalado, una ruta es creada, una conexión a la base de datos es creada o borrada, por tanto el primer servidor de replicación que usted crea cuando instala un sistema de replicación tendrá las funciones de ID Server.

• RSSD ó ERSSD – Las tablas del sistema de replicación están almacenadas en una base de datos Adaptive Server Enterprise o Adaptive Server Anywhere llamada Replication Server System Database ó Embedded Replication Server System Database (RSSD ó ERSSD) respectivamente. Una RSSD o ERSSD es asignada a cada servidor de replicación.

Las tablas del sistema de un servidor de replicación almacenan la información necesaria para ejecutar sus tareas, incluyendo descripciones de los datos replicados y objetos de replicación, definiciones de replicación y subscripciones, registros de seguridad para usuarios del servidor de replicación, información de rutas para otros sitios, métodos de acceso para las base de datos locales e información administrativa.

• Particiones y Colas – Los servidores de replicación almacenan los mensajes en disco para asegurar que ellos puedan ser entregados después de una falla. Cuando usted instala un servidor de replicación, usted asigna una partición inicial o disk partition que el servidor de replicación usa para su almacenamiento en disco. Usted puede agregar particiones adicionales una vez instalado el servidor de replicación.

El servidor de replicación asigna colas o stable queues a partir de sus particiones de disco para las rutas y conexiones que atiende. Los mensajes se guardan en las colas por lo menos hasta que los mensajes sean confirmados como recibidos por su destinatario.

• Agente de Replicación – El Agente de Replicación o Replication Agent transfiere la información del log de transacciones de una base de datos primaria, a un servidor de replicación para distribución a otras bases de datos.

• Conexión – Componente que permite enviar comandos desde un servidor de replicación a una base de datos. Cuando se adiciona una base de datos a un sistema de replicación, se crea una conexión.

• Ruta – Componente en una sola vía que permite enviar requerimientos a través de mensajes desde un servidor de replicación a otro servidor de replicación. Si se tienen más de un servidor de replicación en un sistema de replicación, se debe de crear una ruta entre ellos para permitir que las transacciones fluyan.

Para poder replicar datos desde una base de datos a otra, usted debe establecer rutas y conexiones que permitan al servidor de replicación mover datos desde una fuente a un destino (Ver la Figura 1).

Figura1 – Rutas y Conexiones en Replicaton Server

• Replication Commmand Language (RCL) – Es el lenguaje que permite desarrollar, administrar y monitorear ambientes de replicación.

• Replication Manager (RM) – Es un plug-in para Sybase Central que permite desarrollar, administrar y monitorear ambientes de replicación con una interfaz gráfica.

En un ambiente, sistema o dominio de replicación todos los componentes de un sistema usan el mismo ID Server y cada base de datos puede ser administrada por solamente un Servidor de Replicación. En otras palabras, una base de datos solo puede pertenecer a un sistema de replicación o ID Server, lo que significa que usted no puede crear múltiples conexiones a la misma base de datos desde diferentes dominios.

¿Cómo identificar típicos problemas en su sistema de replicación y qué hacer?

1. Inicie identificando en su sistema todos sus servidores de replicación.

2. Verifique que los servidores de replicación identificados en el punto anterior se encuentren en ejecución. Esto lo puede realizar usando la herramienta isql e intentando conectarse al servidor, o listando los procesos del sistema operativo (use ps en UNIX o el Task Manager en Windows).

Si su servidor de replicación no se está ejecutando puede ser porque el servidor de base de datos que contiene la base de datos RSSD no fue iniciado primero. Si es así, el mensaje que usted observará en el log de errores de su servidor de replicación es:

#31083 "Cannot connect to RSSD Server"

En éstos casos usted debe iniciar el servidor de base de datos que contiene la base de datos RSSD y luego iniciar el servidor de replicación.

Otra posible causa puede ser que la contraseña del usuario primario de la base de datos RSSD haya cambiado. En este caso usted observará el mensaje anterior, más el siguiente mensaje:

#1028 "Message from server: Message: 4002, State 1, Severity 14 -- 'Login Failed'

En ésta situación usted podría cambiar la contraseña a nivel de base de datos para regresar a la anterior o ejecutar el programa rs_init y a través de la opción Alter a Replication Server Configuration file password actualizar la nueva contraseña.

3. Revise el log de errores de los servidores de replicación. Si no recuerda donde se encuentra éste archivo puede conectarse al servidor de replicación y ejecutar el siguiente comando para hallar su localización exacta:

1> admin log_name 2> go

4. Verifique si hay algún hilo no iniciado (es estado down). Esto lo puede hacer ejecutando el siguiente comando en el servidor de replicación:

1> admin who_is_down 2> go

Si la salida es vacía indica, que no hay ningún hilo abajo; si aparece algún hilo, significa que éste está no iniciado o abajo y generalmente indica que hay problemas.

Cada hilo DSI generalmente tiene su correspondiente hilo DSI EXEC. Ambos representan la conexión existente entre el servidor de replicación y la base de datos replicada y cuando alguno de estos dos hilos tiene el estado de suspended indica una conexión suspendida, lo que puede ocurrir por dos causas:

1. Se ejecutó el comando suspend Connection... Para subir el hilo ejecute el siguiente comando en el servidor de replicación:

1> resume connection to dataserver.database 2> go

2. El servidor de replicación no pudo ejecutar un comando sobre la base de datos, por que este último generó algún tipo de error; un caso común son los errores generados por llaves duplicadas. Para ver el comando SQL que generó el error, ejecute el siguiente comando en el servidor de replicación:

1> sysadmin log_first_tran, dataserver, database 2> go

La transacción quedará almacenada en las tablas rs_exceptshdr, rs_exceptscmd y rs_systext de su base de datos RSSD. Una vez identificado el error usted puede corregirlo en su servidor de base de datos o saltar la transacción ejecutando en el servidor de replicación un comando como:

1> resume connection to dataserver.database skip transaction 2> go

Existe otro hilo llamado RepAgent que representa la conexión del ASE RepAgent para la correspondiente base de datos primaria; si su estado es down, usted puede intentar iniciar el hilo corriendo, desde la base de datos primaria, el siguiente comando:

1> sp_start_rep_agent dbname 2> go

Si el RepAgent no inicia, revise el log de errores del servidor de base de datos para encontrar el problema. Si el hilo aparece con el estado suspended, es porque el comando suspend log transfer fue ejecutado, entonces ejecute un comando como el siguiente en el servidor de replicación:

1> resume log transfer from dataserver.database 2> go

5. Compruebe que el log de la base de datos RSSD no esté lleno. Todas las transacciones de modificación en su sistema de replicación pueden llegar a llenar el log de transacciones de una base de datos y esto puede causar que la actividad del servidor de replicación se suspenda. Sin embargo, usted puede limpiar el log ejecutando el comando dump tran regularmente o implementando umbrales o thresholds de espacio libre en el servidor de bases de datos. Recuerde que el las áreas de log y de datos de la RSSD se pueden llenar muy rápido si usted ejecuta frecuentemente los comandos sysadmin log_first_tran o sysadmin dump_queue. Para limpiar estas transacciones use el procedimiento almacenado rs_delexception en el servidor de bases de datos.

6. Revise que los stable device no estén llenos. Use el siguiente comando en el servidor de replicación para ver el tamaño y el espacio libre de estos dispositivos:

1> admin disk_space 2> go

En caso de que considere que el espacio libre es insuficiente, puede adicionar otra partición ejecutando un comando el siguiente:

1> add partition nombre_logico on nombre_fisico with sizetamaño 2> go

¿Qué hacer cuando un mensaje "loss detected" aparece en el log de errores de un servidor de replicación?

Cuando el servidor de replicación detecta que algunos mensajes se han perdido, genera un mensaje en el log de errores. Cuando esto pasa, las transacciones que vienen desde su servidor de datos primario no pueden ser aplicadas a su base de datos replicada; estas transacciones se acumulan en las stable queue, sin embargo, si usted ejecuta el comando admin who en el servidor de replicación, todos los hilos se verán arriba.

La única vía para encontrar éste estado es verificando el log de errores y verificando que no aparezcan mensajes "loss detected...". Para corregir esta situación ejecute el siguiente comando en el servidor de replicación:

1> ignore loss from dataserver.database to dataserver.database 2> go

Hay casos en que la instrucción anterior no funciona. Si es así, verifique el contenido de la tabla rs_exceptslast y si hay algún registro cuyo valor para la columna status es 2, actualice este valor a 0 manualmente. También verifique la tabla rs_oqid; si existe alguna fila en donde el valor para la columna valid es 2, actualícela a 0.

El Transaction Cache Size es muy pequeño

Han sido reportados problemas en donde todo parece estar bien, todos los hilos activos (arriba) y no hay mensajes en el log de errores, pero sin embargo las transacciones no son replicadas. Examine el hilo SQT ejecutando un comando como el siguiente en el servidor de replicación:

1> sysadmin sqt_dump_queue, XXX, 1, 0 2> go

XXX representa el identificador del hilo SQT; encuentre este valor ejecutando admin who y/o admin who, sqt.

Verifique si obtiene el siguiente mensaje:

Msg 6024, Level 12, State 0; Server.... Block read failed for queue "XXX:1", segment xxxx, block xx. OS dependent error is "could not initiate aioread errno = 14....

Este error indica que hay una transacción que es muy grande y que el servidor de replicación no la puede manejar, causando que ésta no pueda ser movida desde la cola de entrada (inbound) a la cola de salida (outbound). En este caso la solución es incrementar el parámetro de configuración "sqt_max_cache_size" del servidor de replicación. Para aumentar el valor de dicho parámetro use un comando como el siguiente en el servidor de replicación:

1> configure replication server set 2> sqt_max_cache_size to 'valor_en_bytes' /* 1048576 representa 1 Mb */ 3> go

¿Qué hacer cuando se llena el log de transacciones de una base de datos que pertenece a un sistema de Replicación?

Cuando su sistema de replicación está ejecutándose y por alguna circunstancia, una transacción muy grande o una transacción errónea es enviada, se puede dar lugar a que el log de transacciones de una base de datos se llene. En este caso, un DBA podría decidir remover el punto secundario del log de transacciones para permitir eliminar el log de transacciones en el servidor de base de datos primario y continuar trabajando.

Aunque lo anterior puede ser una solución desde el punto de vista de la base de datos, hay que tener en cuenta que ésta operación puede afectar seriamente el sistema de replicación, ya que al eliminar el log se eliminan transacciones que aún no han sido replicadas, lo que hará que el sistema pierda su sincronización forzando a una sincronización manual del sistema de replicación, lo cual puede ser, aún, más dispendioso.

Antes de eliminar el log de transacciones, considere si puede asignar un poco de espacio extra para las colas del servidor de replicación ejecutando el comando add partition en el servidor de replicación, o adicionar dispositivos de log a la base de datos. Sin embargo, si usted decide eliminar el log de transacciones, estos son los pasos a seguir en el servidor de bases de datos:

1. Detenga el hilo de replicación para la base de datos en problemas:

1> sp_stop_rep_agent dbname 2> go

2. Ignore el segundo punto de truncamiento:

1> use dbname 2> go   1> dbcc settrunc(ltm, ignore) 2> go

3. Ejecute el vaciado del log, ya sea a un dispositivo de backup o con la opción truncate_only:

1> dump tran dbname with truncte_only 2> go

4. Verifique que el log de transacciones ha sido liberado:

1> sp_helpdb dbname 2> go

5. Active el segundo punto de truncamiento:

1> use dbname 2> go   1> dbcc settrunc(ltm, valid) 2> go

6. Limpie la información de la tabla locator:

1> use rssddb 2> go   1> rs_zeroltm dataserver, dbname 2> go

7. Por último, reinicie el hilo de replicación:

1> sp_start_rep_agent dbname 2> go

¿Cómo identificar y limpiar la información de una cola (stable queue) en un sistema de replicación?

En algunas ocasiones el administrador del sistema de replicación, puede decidir limpiar una cola, sin embargo es importante precisar que eliminar los mensajes de una cola, puede resultar en perdida de datos, debido a que el servidor de replicación no puede enviar los mensajes eliminados a la base de datos destino o a otro servidor de replicación y esto puede causar inconsistencias en el sistema de replicación.

Sin embargo, si usted decide eliminar la información de una stable queue, siga los siguientes pasos:

1. Identifíquela, ejecutando los siguientes comandos en el servidor de replicación:

1> admin who 2> go   1> admin who, sqm 2> go   1> admin who, sqt 2> go

2. Reinicie el servidor de replicación con la opción "-M" en el RUN_FILE (archivo de arranque) o coloque el servidor en estado de "hibernación", ejecutando los siguientes comandos:

1> sysadmin hibernate_on, [String_ID] 2> go

3. Elimine la información de la stable queue, ejecutando:

1> sysadmin sqm_purge_queue, q_number, q_type 2> go

4. Reinicie el servidor de replicación en modo normal o apague el estado de hibernación, ejecutando:

1> sysadmin hibernate_off, [String_ID] 2> go

¿Cómo eliminar un servidor de Replicación de un sistema de replicación, cuando este ya no esta disponible?

En algunas ocasiones, por daños de hardware, Sistema Operativo, virus, etc., la máquina donde se encontraba un servidor de replicación ya no está disponible y es necesario eliminar la información de este sitio dentro del sistema de replicación. Para esto se debe hacer uso del ID Server y de todos los servidores que tengan rutas asociadas al servidor de replicación que se va a eliminar. Siga estos pasos:

En cada uno de los servidores que tienen una ruta asociada con el servidor de replicación a eliminar (incluyendo el ID Server, si con este se definió alguna ruta hacia este servidor):

1. Elimine todas las rutas asociadas a este servidor, ejecutando:

1> drop route to rep_server with nowait 2> go

2. Purgue la ruta del servidor de replicación, ejecutando:

1> sysadmin purge_route_at_replicate, rep_server 2> go

Luego, en el ID Server:

1. Elimine el servidor de replicación de la lista mantenida por el ID Server, ejecutando:

1> sysadmin droprs, rep_server 2> go

2. Elimine todas las bases de datos administradas por el servidor de replicación a eliminar, de la lista mantenida por el IDServer, ejecutando:

1> sysadmin dropdb, dataserver, dbname 2> go

¿Cómo recuperar la base de datos RSSD con un backup de último minuto?

Debido a situaciones de corrupción lógica de los datos o daños de hardware, algunas veces se hace necesario recuperar el servidor de base de datos y la base de datos RSSD. Si se tiene un backup de último minuto de la base de datos RSSD, se deben seguir los siguientes pasos para reestablecer el sistema de replicación:

1. Detenga todos los agentes de replicación (Rep Agent) que se conectan al servidor de replicación:

1> exec sp_stop_rep_agent dbname 2> go

2. Detenga el servidor de replicación, ejecutando:

1> shutdown 2> go

3. Vuelva a crear la RSSD, borrando la base de datos con drop database o dbcc dbrepair, según corresponda y cree la nueva base de datos RSSD con la opción for load.

4. Restaure los backups de la base de datos RSSD, incluyendo los incrementales (si se tienen) y el backup de último minuto. Coloque la base de datos "online" con el comando online database.

5. Si la RSSD tiene agente de replicación (Rep Agent):

1. Recupere el segundo punto de truncamiento, ejecutando:

1> exec dbcc settrunc(ltm,valid) 2> go

2. Inicie el Agente de replicación (Rep Agent), de la base de datos RSSD:

1> exec sp_start_rep_agent rssd_name 2> go

6. Reinicie el servidor de replicación, e inicie todos los Agentes de replicación (Rep Agent), que se pararon en el punto 1.

1> exec sp_start_rep_agent dbname 2> go

¿Cómo recuperar la base de datos RSSD sin un backup de último minuto?

Si es necesario recuperar un backup de la base de datos RSSD, pero no se cuenta con un backup de último minuto, reestablecer el sistema de replicación puede ser un poco complejo.

Es importante anotar que habrá perdida de apuntadores de las colas por lo que es necesario reconstruirlas y que componentes del sistema de replicación como subscripciones, definiciones de replicación y rutas que hayan sido creadas después de la toma del backup que se está recuperando, deberán ser sincronizadas manualmente.

Los pasos a seguir son los siguientes:

1. Detenga todos los agentes de replicación (Rep Agent) que se conectan al servidor de replicación, ejecutando:

1> exec sp_stop_rep_agent rssd_name 2> go

2. Detenga el servidor de replicación, ejecutando:

1> shutdown 2> go

3. Vuelva a crear la RSSD, borre la base de datos con drop database o dbcc dbrepair, según corresponda y cree la nueva base de datos RSSD con la opción for load.

4. Restaurare los backups de la base de datos RSSD, incluyendo incrementales si se tienen y deje la base de datos online con el comando online database.

5. Inicie el servidor de replicación, revise el log de errores y verifique si existen procesos suspendidos.

6. Si la base de datos RSSD tiene agente de replicación (Rep Agent)

1. Recupere el segundo punto de truncamiento, ejecutando:

1> dbcc settrunc(ltm, valid) 2> go

2. Reinicie el Agente de replicación (Rep Agent), de la base de datos RSSD.

1> exec sp_stop_rep_agent rssd_name 2> go   1> exec sp_start_rep_agent rssd_name 2> go

7. Si la base de datos RSSD tiene agente de replicación (Rep Agent), obtenga el GenID de la siguiente manera:

1. Reinicie el servidor de replicación.

2. Reinicie el Rep Agent de la base de datos RSSD:

1> exec sp_stop_rep_agent rssd_name 2> go   1> exec sp_start_rep_agent rssd_name 2> go

3. Obtenga el GenID:

1> admin get_generation, dataserver, rssd_name 2> go

4. Detenga el servidor de replicación.

8. Inicie el servidor de replicación en modo monousuario con la opción "-M" en el RUN_FILE (archivo de arranque).

9. Verifique con el comando sp_who si existe algún hilo DSI suspendido, y si es así, reinicie las conexiones que se encuentren suspendidas, ejecutando:

1> resume connection to dataserver.database 2> go

10. Reconstruya todas las colas para re-sincronizar los apuntadores de las colas en el servidor de replicación, para esto, conectado al servidor de replicación, ejecute:

1> rebuid queues 2> go

11. Inicie todos los agentes de replicación de bases de datos primarias (que fueron bajados en el punto 1) en modo recuperación, ejecutando en el servidor de bases de datos primario los siguientes comandos:

1> use primary_dbname 2> go   1> exec sp_start_rep_agent database, recovery 2> go

12. Examine el log de errores y verifique si aparecen mensajes de "loss detected"; si es así, entonces:

1. Compare la base de datos primaria y la base de datos replicada y si es posible sincronice los datos.

2. Ejecute el siguiente comando en el servidor de replicación:

1> ignore loss from dataserver.dbname to dataserver.dbname 2> go

13. Si la base de datos RSSD tiene agente de replicación (Rep Agent):

1. Elimine el segundo punto de truncamiento, ejecutando:

1> dbcc settrunc(ltm, ignore) 2> go

2. Mueva el primer punto de truncamiento a otra pagina. Esto se puede llevar a cabo corriendo alguna transacción dummy no-replicada, es decir una transacción que no involucre las tablas marcadas para replicación, como crear una tabla e insertar datos en ella, ejecutar commit y finalmente borrar la tabla.

3. Trunque el log de transacciones, ejecutando:

1> dump tran rssd_name with truncate_only 2> go

4. Restablezca el segundo punto de truncamiento:

1> dbcc settrunc(ltm, valid) 2> go

5. Incremente el GenID capturado en el punto 7 y aplíquelo, ejecutando:

1> dbcc settrunc(ltm, gen_id, nuevo_numero) 2> go

14. Reinicie el servidor de replicación.

1. Detenga el servidor de replicación, ejecutando:

1> shutdown 2> go

2. Detenga todos los agentes de replicación (Rep Agent) que se conectan al servidor de replicación (los mismos del punto 1). Para eso, ejecute:

1> sp_stop_rep_agent dbname 2> go

3. Suba el servidor de replicación en modo normal, es decir, sin el parámetro "-M" del RUN_FILE (archivo de arranque).

4. Inicie los agentes de replicación en modo normal (los mismos bajados en el punto 1).

1> exec sp_start_rep_agent dbname 2> go

¿Cómo restablecer un sistema de replicación, después de ejecutar la carga de un backup en la base de datos primaria?

Si una base de datos primaria fue restaurada a partir de un backup, el sistema de replicación debe ser restablecido. Como en casos anteriores los pasos a seguir difieren si se dispone o no de un backup de último minuto.

Para restablecer el sistema de replicación seguir los siguientes pasos:

1. Vuelva a crear la base de datos. Dependiendo del daño sufrido el administrador deberá borrar la base de datos con drop database o dbcc dbrepair y/o los dispositivos correspondientes con sp_dropdevice, y luego crear los dispositivos y la base de datos según corresponda y usando los scripts originales de la base de datos.

2. Cargue el backup total de la base de datos y todos los backups transaccionales que se tengan, incluido el backup de último minuto.

3. Ponga la la base de datos en línea, usando online database. Si usted recuperó con un backup de último minuto, continué al paso 11.

4. Elimine el segundo punto de truncamiento, ejecutando la siguiente instrucción sobre la base de datos primaria que fue restaurada:

1> dbcc settrunc(ltm, ignore) 2> go

5. Mueva el primer punto de truncamiento a otra página. Esto se puede llevar a cabo corriendo alguna transacción dummy no- replicada, es decir una transacción que no involucre las tablas marcadas para replicación, como crear una tabla en insertar datos en ella, ejecutar commit y borrar la tabla.

6. Trunque el log de transacciones de la base de datos primaria, ejecutando:

1> dump tran dbname with truncate_only 2> go

7. Restaure el segundo punto de truncamiento, ejecutando:

1> dbcc settrunc(ltm, valid) 2> go

8. Actualice la localización del segundo punto de truncamiento en la tabla rs_locator de la base de datos RSSD para la base de datos primaria que fue restaurado a través de backup, ejecutando:

1> use rssd_name 2> go   1> rs_zeroltm dataserver, dbname 2> go

9. Incremente el Gen ID. Esto es necesario ya que el timestamp database ha sido restaurado con el valor del tiempo del último backup recuperado y este podría ser menor al último enviado por el servidor de replicación en el Origin Queue ID de la última transacción replicada. Si usted no incrementa el Gen ID, las siguientes transacciones serán consideradas por el sistema de replicación como transacciones duplicadas y no serán replicadas. Para incrementarlo, ejecute los siguientes pasos:

1. Recupere el Gen id actual:

1> admin get_generation dataserver, dbname 2> go

2. Incremente el Gen id obtenido en el punto anterior y fíjelo de la siguiente manera:

1> dbcc settrunc(ltm, gen_id, numero_nuevo) 2> go

10. Recupere las transacciones perdidas. Esta es la parte más crítica de todo el proceso, ya que los sitios replicados pueden tener transacciones que no existen en la base de datos primaria debido a que se recuperó de un backup que no fue el de último minuto. Para sincronizar las bases de datos se tienen las siguientes opciones:

1. Rematerializar desde su sitio replicado.

2. Usar la utilidad rs_subcmp.

3. Reingresar las transacciones.

11. Inicie la conexión de la base de datos primaria, recuperada por backup, ejecutando en el servidor de replicación:

1> resume connection dataserver.dbname 2> go

12. Reinicie el agente de replicación (Rep Agent) desde el servidor de base de datos de la base de datos primaria recuperada por backup:

1> sp_stop_rep_agent dbname 2> go   1> sp_start_rep_agent dbname 2> go

13. Examine el log de errores del servidor de replicación y verifique que no aparezcan errores.

¿Qué hacer cuando un dispositivo (stable device) de un servidor de replicación se daña?

Cuando no se puede acceder un stable device, un mensaje es escrito en el log de errores y el procedimiento a seguir es el siguiente:

1. Borre la partición corrupta usando el siguiente comando, ejecutado desde el servidor de replicación:

1> drop partition partition_name 2> go

2. Adicione una partición para reemplazar la borrada, de la siguiente manera:

1> sp_addpartition partition_name on localizacion_física with size tamaño 2> go

3. Verifique el espacio en disco, ejecutando:

1> admin disk_space 2> go

La partición dañada debe aparecer en status dropped. La nueva partición debe aparecer en status online.

4. Reconstruya las colas, usando el comando:

1> rebuild queues 2> go

Este comando limpia y vuelve a poblar las colas, adicionalmente detectará cualquier transacción perdida y si las hay mensajes de "loss detected" aparecerán en el log de errores.

5. Reinicie cualquier conexión que se encuentre abajo, ejecutando:

1> resumen connection to dataserver.dbname 2> go

6. Reinicie los agentes de replicación de las bases de datos primarias, correspondientes al servidor de replicación, ejecutando desde el servidor de base de datos correspondiente:

1> sp_start_rep_agent dbname 2> go

7. Verifique si existe algún hilo down en el servidor de replicación, ejecutando:

1> admin who_is_down 2> go

8. Revise el log de errores para detectar mensajes. Si la reconstrucción terminó con éxito, debe aparecer el siguiente mensaje:

Rebuild Queues: Complete

Verifique si aparecen mensajes de "loss detected": "DSI: detecting loss for database servidor.basedatos" (revise la sección ¿Qué hacer cuando un mensaje "loss detected" aparece en el log de errores de un servidor de replicación?).

9. Si es necesario recuperar datos perdidos, puede re-materializar o usar el comando rs_subcmp.

10. Verifique nuevamente el espacio en disco:

1> admin disk_space 2> go

Si la partición dañada ya no es desplegada, ya puede borrar el file system o la raw partition.

Bibliografía

• Replication Server 12.6 Reference Manual

• Replication Server Version 12.6 Troubleshooting Guide

• Curso "Advanced Replication Server Administration: Recovery and Performance"

• Solved Cases de Sybase