El trasvase de registros es una de baja tecnologa, de forma robusta pero de bajo costo para lograr una alta disponibilidad

y proteccin ante desastres en el entorno de SQL Server. De trasvase de registros de forma automtica de los buques-copia y restaura-a registros de transacciones del servidor de produccin a un servidor de reserva, el cual est dispuesto a tomar el lugar de un servidor de produccin fracasado. Si se mantiene la copia de su servidor en espera de la corriente de datos de produccin (a pocos minutos de los datos de produccin), tiene una reserva en caliente. Relacionado : Escribir consultas distribuidas heterogneas en SQL Server 7.0 Durante aos, los desarrolladores de SQL Server y los administradores de bases han tenido que crear scripts personalizados para implementar el trasvase de registros. Sin embargo, con SQL Server 7.0, Microsoft proporciona ganchos indocumentados en el procedimiento almacenado xp_sqlmaint extendida para ayudar a automatizar el trasvase de registros. Xp_sqlmaint llama a la utilidad sqlmaint.exe, al igual que los trabajos que el Asistente para mantenimiento de bases de datos crea. De hecho, el Kit de recursos de Microsoft BackOffice 4.5 (BORK) utilidad de Trasvase de registros consiste en secuencias de comandos y las instrucciones que utilizan estos ganchos en xp_sqlmaint para crear una solucin de inicio de sesin del envo mayormente automatizado. Este artculo cubre el trasvase de registros en SQL Server 7.0, como BORK define el proceso. Usted puede obtener BORK de Microsoft Press por $ 250 al por menor (unos 130 dlares precio de venta). Microsoft desarroll el BORK utilidad trasvase de registros, como lo haca todas sus utilidades del kit de recursos, para uso interno de Microsoft; Soporte tcnico de Microsoft no admite la utilidad. Y usted encontrar la BORK spera utilidad trasvase de registros en los bordes. A pesar de que automatiza gran parte del proceso de inicio de sesin del envo, la utilidad requiere una buena cantidad de configuracin manual y la administracin. Sin embargo, SQL Server 2000 Enterprise Edition es totalmente compatible con el envo de registro y proporciona una interfaz ms pulida que la BORK utilidad. Para un resumen de la funcionalidad de inicio de sesin de SQL Server del envo 2000, consulte la barra lateral"trasvase de registros con SQL Server 2000 . " Est pendiente de un prximo artculo de la revista SQL Server que cubre el trasvase de registros de SQL Server 2000 en detalle.

Cmo trasvase de registros Obras

En una aplicacin de inicio de sesin del envo, la conmutacin por error al servidor de reserva es un proceso manual. Si usted requiere de conmutacin por error automatizada, la mejor solucin es Microsoft Cluster Services (MSCS), que conmuta por error automticamente un nodo de clster a otro nodo del clster. Sin embargo, la solucin de clustering cuesta ms que el trasvase de registros, requiere hardware especializado adicional, y fuerza una vinculacin ms estrecha, o la dependencia, de los servidores primario y secundario. Para configurar el trasvase de registros, todo lo que necesita es elBORK utilidad, suficiente espacio en disco en su produccin y servidores de reserva para almacenar los archivos de copia de seguridad de base de datos y registro de transacciones, y una conexin de red entre los servidores. Antes de saltar en la forma de configurar el trasvase de registros, echemos un vistazo rpido a los cinco pasos bsicos del proceso de trasvase de registros, que la figura 1muestra. Realice una copia de seguridad completa de la base de datos de produccin.Para inicializar el trasvase de registros, primero debe realizar una copia de seguridad completa de la base de datos de produccin. La base de datos de produccin debe tener elTruncar registro en punto de control y seleccione en copia / granel opciones de base de datos de modo que SQL Server registrar todos los cambios de datos. Las copias de seguridad de registro de transacciones son imposibles de realizar cuando se tienen estas opciones de base de datos sobre. Restaurar la copia de seguridad completa al servidor en espera y sin recuperacin. Debe restaurar la copia de seguridad completa al servidor de reserva sin recuperacin-es decir, ya sea con el NORECOVERY o la opcin de ESPERA. El modo NORECOVERY impide a los usuarios leer los datos de la base de datos durante la restauracin. Pero el modo de espera permite a los usuarios leer los datos que ya estn en el servidor de reserva. Utilizando el modo de espera cuando se restaura la copia de seguridad completa al servidor de reserva est muy bien. Sin embargo, cualquier registro de transacciones de restauracin requiera el uso exclusivo de la base de datos, por lo que permite a los usuarios consultar una base de datos standby puede retrasar el registro de transacciones log-shipping restauracin. . Realice copias de seguridad de registro de transacciones a los archivos en el servidor de produccin Cuando se utiliza el BORK utilidad trasvase de registros, debe nombrar a los archivos de copia de seguridad del registro de

transacciones de acuerdo con la convencin: dbname_tlog_yyyymmddhhmm.trn (el valor predeterminado para planes de mantenimiento de bases de datos) . La marca de tiempo en el nombre del archivo permite que el proceso de log-shipping restaurar los archivos de registro de transacciones en la secuencia. Copie los archivos de copia de seguridad del registro de transacciones para el servidor de reserva. Un trabajo del Agente SQL que se ejecuta en el servidor en espera utiliza xp_sqlmaint para copiar los archivos al servidor de reserva. (Te dir cmo configurar este trabajo ms adelante.) Restaurar los archivos de copia de seguridad de registro de transacciones para el servidor en espera y sin recuperacin. Otro trabajo del Agente SQL que se ejecuta en el servidor en espera utiliza xp_sqlmaint para restaurar los registros de transacciones. El trasvase de registros es muy fiable. Una vez que tenga los pasos anteriores en el lugar-y siempre y cuando la cadena de copia de seguridad del registro de transacciones se mantiene intacto-el trasvase de registros se ejecutar de forma indefinida. Sin embargo, la instalacin de service Pack de SQL y recuperar la base de datos standby interrumpir el proceso y que requieren para reiniciar el servidor en espera y vuelva a iniciar el trasvase de registros. Para bases de datos ms pequeas, el proceso de reinicializacin va rpidamente, pero para las bases de datos ms grandes, el proceso puede llevar mucho tiempo. An as, despus de tener el proceso de trasvase de registros de funcionamiento, puede seguir realizando copias de seguridad de bases de datos completas y diferenciales de la base de datos de produccin, de acuerdo con su horario habitual de copia de seguridad, sin interferir con el trasvase de registros. A continuacin, puede archivar estas copias de seguridad de bases de datos sin restaurar al servidor en espera. Slo importante vulnerabilidad de trasvase de registros se encuentra en la cadena de registro de transacciones. Debe solicitar los registros de transacciones en secuencia, y todas las restauraciones deben tener xito, o el proceso fallar y tendrs que reiniciar el servidor en espera. Asegurarse de que sus prcticas de copia de seguridad y restauracin de proteger el proceso de trasvase de registros continua es vital.

Instalacin de trasvase de registros

Ahora que usted ha visto una visin general de cmo iniciar trabajos de envo, vamos a ir de nuevo al principio. Para instalar el trasvase de registros, siga los seis pasos siguientes. Realice una copia de seguridad completa. Como seal anteriormente, debe asegurarse de que la base de datos del servidor de produccin tiene las opciones de base de datos Truncar registro en punto de comprobacin y SELECT INTO / copia masiva fuera.A continuacin, deber realizar una copia de seguridad completa, de preferencia en un archivo de disco. Aplique la copia de seguridad completa al servidor de reserva. Restaurar la copia de seguridad completa de la base de datos de servidor de reserva sin recuperacin.Por ejemplo, si usted est restaurando una base de datos llamada Pubscopy a un servidor en espera, puede especificar Dejar base de datos no operativa; permitir restaurar registros de transacciones adicionales o Dejar base de datos de slo lectura y permitir restaurar registros de transacciones adicionales en el encargado de la empresa de restauracin base de datos de cuadro de dilogo, como Figura 2 muestra. La base de datos no operativa Dejar opcin es equivalente al comando T-SQL
RESTORE DATABASE Pubscopy DE 'd: \ Mssql7 \ backup \ pubscopy.bak' WITH NORECOVERY

y la base de datos de slo lectura Dejar opcin es equivalente al comando T-SQL

RESTORE DATABASE Pubscopy DE 'd: \ Mssql7 \ backup \ pubscopy.bak' WITH STANDBY

Cree un trabajo que respalda peridicamente los registros de transacciones de bases de datos de produccin. Creacin de un trabajo en el servidor de produccin para copias de seguridad de registros de transacciones en el disco. La forma ms fcil de hacer esto (y el mtodo de la BORK utilidad Log Shipping apoya) es crear un plan de mantenimiento de base de datos para realizar copias de seguridad de los registros de transacciones de la base de datos de produccin en un intervalo deseado. Recuerde anotar en qu directorio se guarda las copias de seguridad para y si ha especificado un directorio para el archivo de copia de seguridad del registro de transacciones de cada base de datos. Si usted tiene muchas bases de datos que participan en el proceso de inicio de sesin del envo, especificando un subdirectorio para los archivos de cada base de datos (como la Figura 3 shows) puede

ayudarle a administrar los archivos de la copia de seguridad de muchos el sistema producir. Asegrese de dar el plan de mantenimiento de bases de datos de forma clara, descriptiva nombre-algo ms que el plan de mantenimiento de base de datos por defecto 1-tales comoel trasvase de registros Pubscopy. Puede especificar que el trabajo funcione tan a menudo como una vez por minuto, pero ese ajuste significa 60 transacciones los archivos de registro por hora, por base de datos. Aunque usted puede estar tentado a ejecutar el trabajo de copia de seguridad con frecuencia para mantener su servidor lo ms caliente posible, para grandes bases de datos activas, un ajuste de la frecuencia de trabajo en el rango de 5 - a intervalos de 15 minutos es ms manejable. Aplicar los BORK guiones trasvase en el servidor de reserva. Utilizando el Analizador de consultas o OSQL, ejecute el BORK trasvase de registros instalar scripts en la base de datos msdb en el servidor de reserva. El primer guin, instlog.sql, crea tres tablas de msdb y tambin crea dos procedimientos almacenados: uno para crear la copia de seguridad (log-shipping) Plan y otro para agregar una base de datos especfica para el plan. El segundo guin, log_ship_sprocs.sql, crea procedimientos almacenados para el trasvase de registros de monitoreo (Cubro estos procedimientos almacenados un poco ms tarde). El guin instlog.sql crea tres tablas:. Planes backup_movement_, backup_movement_plan_databases y backup_movement_plan_history Figura 4 , pgina 48, muestra columnas y relaciones de las tablas. Backup_movement_plans contiene un nombre de plan, que debe ser el mismo que el nombre del plan de mantenimiento de base de datos que cre anteriormente. La clave principal de la tabla es un asigna automticamente ID nico global (GUID) llam la identificacin del plan. La tabla tambin contiene los nombres de los directorios de origen y de destino para los archivos de registro de transacciones. Backup_movement_plan_databases contiene la identificacin del plan junto con los nombres de origen y la base de datos de destino y la informacin de estado acerca de la ltima copia y ltima carga. (Tenga en cuenta que la tabla backup_movement_plan_databases no tiene una clave principal.) La tercera tabla, backup_movement_plan_history, contiene una historia de la copia y de carga de eventos para un plan especfico, incluyendo las duraciones y los mensajes de error.

BORK tambin viene con 46 pginas de documentacin log-shipping, pero mucha gente se encuentra parte de la informacin redundante, confuso, o-en el caso de alguna salida sin formato en bruto intil. La documentacin contiene un ejemplo, sin embargo, el ejemplo muestra cmo configurar el trasvase de registros entre las diferentes bases de datos en el mismo servidor en lugar del escenario de produccin ms comn de tener un servidor de produccin que tiene una base de datos con el mismo nombre como una base de datos en un servidor en espera . Cree un plan de copia de seguridad de movimiento en el servidor de reserva.Usted crea un plan de copia de seguridad de movimiento en el servidor de reserva mediante la ejecucin del procedimiento almacenado sp_create_backup_movement_plan en la base de datos msdb. ( BORK guin instlog 's tambin proporciona este procedimiento almacenado.) El propsito del procedimiento almacenado es agregar el nombre del plan de copia de seguridad a la mesa backup_movement_plans y crear los trabajos de copia de registro de transacciones y de carga en el Agente SQL. Documentacin del Sp_create_backup_movement_plan puede ser engaosa y no distinguir los parmetros requeridos de los parmetros opcionales. He aqu una descripcin ms estndar de la sintaxis del procedimiento almacenado:
sp_create_backup_movement_plan \ [@ name = \] plan_name, \ [@ source_dir = \] source_directory_name, \ [@ dest_dir = \] destination_directory_name, \ [\ [@ sub_dir = \] subdirectory_flag (bit) \] \ [\ [@ load_job_freq = \] load_frequency (minutos) \] \ [\ [@ copy_job_freq = \] copy_frequency (minutos) \]

La sentencia siguiente aade un plan de copia de seguridad a la mesa para una base de datos llamada Pubscopy:
EXEC msdb .. sp_create_backup_movement_plan @ name = "el trasvase de registros Pubscopy", @ source_dir = "\ \ srv1 \ d $ \ mssql7 \ backup \ pubscopy", @ dest_dir = "\ \ srv2 \ d $ \ mssql7 \ backup \ pubscopy", @ sub_dir = 0

El nombre @, @ source_dir y @ dest_dir se requieren parmetros. El nombre del plan debe ser el mismo que el nombre del plan de mantenimiento de base de datos que ha creado en el servidor de produccin. Los directorios dicen sqlmaint.exe dnde encontrar los archivos de registro de transacciones y dnde copiarlos. Los directorios tambin suponer que el Agente SQL del servidor de reserva tiene permisos de lectura y escritura en cuestin a los directorios.

El parmetro @ sub_dir slo es til si no se proporciona la informacin subdirectorio en los parmetros de directorio. Los valores predeterminados de los parmetros a 1, y este ajuste se especifica que los trabajos del Agente SQL pueden encontrar registro de cada transaccin en, y copia de cada registro para, un subdirectorio con el nombre de la base de datos en los directorios especificados. La carga y copia las frecuencias por defecto de 5 minutos, lo cual es un buen lugar para empezar. En adicin el nombre del plan a la mesa backup_movement_plans, sp_create_backup_movement_plan obtiene un GUID para la columna plan_id y rellena la plan_name, source_dir, destination_dir y database_subdir columnas con la informacin se pasa al procedimiento almacenado como parmetros. Se utiliza el @ load_job_freq y parmetros @ copy_job_freq al crear la copia y de la carga del Agente SQL (restaurar) puestos de trabajo. Estos puestos de trabajo exigen el procedimiento almacenado extendido xp_sqlmaint, a continuacin, pasar al procedimiento el nombre del plan y un parmetro que identifica si la accin consiste en copiar o cargar. Xp_sqlmaint lee fila del plan en la tabla backup_movement_plans para determinar el origen y directorios de destino. Agregue la base de datos para el plan de movimiento de copia de seguridad.Despus de haber creado los trabajos del Agente SQL y la tabla backup_movement_plans tiene una fila en el mismo, se agrega una base de datos para el plan de movimiento mediante la ejecucin del procedimiento almacenado sp_add_db_to_backup_movement_plan (que el guin instlog tambin suministra) . Este procedimiento almacenado permite especificar los nombres de base de datos para el trasvase de registros en el servidor de origen y de destino. Por lo general, estos nombres de la base de datos ser el mismo, pero el procedimiento almacenado permite especificar diferentes nombres (por ejemplo, para implementar el trasvase de registros entre bases de datos en el mismo servidor). Tambin puede especificar un retraso de carga (el tiempo de espera antes de restaurar) y un perodo de retencin (cunto tiempo se debe mantener registros de transacciones restauradas antes de purgar ellos). La sintaxis del procedimiento almacenado es
msdb .. sp_add_db_to_backup_movement_plan \ [\ [@ plan_id = \] PlanID (uniqueidentifier) \] \ [\] \ [@ plan_name = \] PlanName, \ [@ tabla_diferencias = \] source_db_name, \ [@ dest_db = \] destination_db_name \ [\ [@ load_delay = \] load_delay (minutos) \] \ [\ [@ load_all = \] load_all_flag (bit) \] \ [\ [@ servidor_origen = \] source_servername \] \ [\ [ @ retention_period = \] retention_period (horas) \]

La sentencia siguiente aade la base de datos Pubscopy al plan de movimiento de respaldo:

EXEC msdb .. sp_add_db_to_backup_movement_plan @ plan_id = null, @ plan_name = "trasvase de registros Pubscopy", @ tabla_diferencias = "Pubscopy", @ dest_db = "Pubscopy", @ load_delay = 0, @ load_all = 1, @ servidor_origen = "srv1", @ retention_period = 6

El procedimiento almacenado requiere o bien la identificacin del plan o el nombre del plan. Estoy de acuerdo con la BORK documentacin, que recomienda especificar el nombre del plan en lugar del GUID para mayor claridad. Se requieren los nombres de las fuentes y bases de datos de destino, aunque el procedimiento almacenado no prueba explcitamente para ellos. El retardo de carga por defecto opcionales a 0 minutos, pero se puede forzar un retraso mayor antes de restaurar las copias de seguridad del registro de transacciones despus de una copia. Los valores predeterminados bandera load_all opcionales a 1, lo que significa que cada vez que se ejecuta el trabajo, intentar cargar todos los registros de transacciones disponibles. Esta opcin puede ayudar al sistema de ponerse al da con registro de transacciones restaura si se retrasa debido a que, por ejemplo, ha tenido que apagar los trabajos de copia y de la carga durante un tiempo o los puestos de trabajo tom ms tiempo del esperado. El nombre del servidor de origen proporciona informacin para la tabla backup_movement_plan_history, y el perodo de retencin especifica cunto tiempo debe mantener registros de transacciones restauradas. Afortunadamente, el proceso de inicio de sesin del envo no elimina ningn registros de transacciones que no se ha restaurado, no importa la edad que los registros son.

Solucin de problemas
Despus de haber ejecutado el procedimiento almacenado sp_add_db_to_backup_movement_plan, el trasvase de registros se iniciar-a menos que haya cometido un error en el proceso de instalacin. En mi experiencia, el error ms comn es el envo de nombres de parmetros imprecisos, tales como directorios o nombres de plan de mantenimiento, a los procedimientos almacenados. Pero el trasvase de registros de resolucin de problemas puede ser un reto, porque los mensajes de error de xp_sqlmaint no siempre son claras. Aqu hay un mensaje de error

crptico muestra del registro de transacciones de restauracin (es decir, la carga) del historial de trabajos:
<i> sqlmaint.exe fallado. \ [SQLSTATE 42000 \] (Error 22029). Error en el paso. </ I>

Por suerte, como BORK documentacin trasvase de registros 's dice, slo algunas cosas pueden ir mal con el trasvase de registros: el plan de copia de seguridad del registro de transacciones puede fallar, la tarea de copia puede fallar, o la carga (restauracin) de trabajo puede fallar. El BORK documentacin contiene una seccin til sobre el trasvase de registros solucin de problemas y la BORK utilidad proporciona procedimientos almacenados que le ayudan a supervisar y solucionar problemas de trasvase de registros. Despus de aplicar la BORKguin instlog.sql, es necesario aplicar el script log_ship_sprocs.sql, que crea cuatro procedimientos almacenados: log_ship_status, log_ship_entity_log, log_ship_history_purge y log_ship_alert. Aunque las secuencias de comandos no requieren que usted, crear y ejecutar estos procedimientos almacenados en msdb es ms seguro, ya que no corre el riesgo de la creacin accidental de los procedimientos en otra base de datos. Log_ship_status acepta parmetros del servidor primario y la base de datos primaria opcionales y devuelve un conjunto de valores de estado tiles acerca de sus planes de envo de registros. Valores de estado devueltos incluyen una columna llamada delta, lo que demuestra el retraso, en minutos, entre la hora actual y el ltimo registro de transacciones de restauracin para un plan determinado. Un gran delta puede indicar problemas, como una ruptura en el proceso de copia o de la carga. Log_ship_entity_log devuelve una instantnea de la tabla backup_movement_plan_history, filtrada por los parmetros que distinguen el servidor de origen y la base de datos y el servidor de destino y la base de datos.Log_ship_history_purge elimina filas de historial anteriores al nmero de das que se especifiquen en un parmetro, el valor del parmetro debe ser un nmero mayor que 1.Por ltimo, log_ship_alert genera un registro de errores de SQL Server y un mensaje de aplicacin de Windows Registro de sucesos cuando el delta log-shipping (menos el retraso de la carga) supera una longitud de alerta que especifique. Estos procedimientos almacenados pueden ayudar a localizar muchos problemas de inicio de sesin de envo. Por ejemplo, tras el trasvase de registros est en funcionamiento, es posible que tenga actividad en el servidor de produccin que hace

que su registros de transacciones tan grandes que no restablecen rpidamente en el servidor de reserva. Este problema podra aparecer como grandes valores delta del procedimiento log_ship_status almacenado o como alerta a gran delta del procedimiento log_ship_alert almacenado. Cuando apenas comience a usar el trasvase de registros, es probable que tenga que experimentar antes de que usted entiende completamente los parmetros involucrados y llegar a la mejor configuracin para su entorno. Y es probable que tenga que borrar sus planes de envo de registros errneos y empezar de nuevo. Por desgracia, el BORK utilidad no proporciona un procedimiento almacenado de eliminacin. Puede eliminar manualmente un plan de trasvase de registros al truncar las tablas (truncar backup_movement_plans ltima porque es parte de un contraint clave externa), a continuacin, eliminar manualmente los puestos de trabajo, pero ese mtodo puede llegar a ser tedioso. Listado 1 muestra un procedimiento almacenado simple de eliminar la copia de seguridad planes y sus puestos de trabajo. Para hacer la lista breve, me he dejado el tratamiento de errores despus de las instrucciones delete; usted querr aadir sus propias rutinas de control de errores en el procedimiento.

Una conmutacin por error

Tarde o temprano, tendr que utilizar el trasvase de registros de conmutacin por error.Fallos de servidor y las actualizaciones de hardware del servidor forzar una conmutacin por error. Incluso las instalaciones de Service Pack y otras actividades de diagnstico contra un servidor de produccin pueden hacer que usted confa en su servidor de reserva.Prueba de su proceso de conmutacin por error y documentar los pasos para que usted y otros puedan realizar el proceso en condiciones de estrs es esencial. Estos son los tres pasos bsicos para la conmutacin por error a una reserva en caliente. Captura de la ltima copia de seguridad buena transaccin de registro desde el servidor de produccin, a continuacin, aplicar la copia de seguridad al servidor de reserva con la recuperacin. Si usted puede conseguir una copia de seguridad de registro de transacciones del servidor de produccin antes de que vaya hacia abajo, es posible que pueda conmutar por error a la de espera del servidor con casi ninguna prdida de datos. Sin embargo, si el SQL Server es repentinamente inasequible, perder todas las transacciones que no fueron terminados antes de la ltima copia de seguridad correcta del registro de transacciones.

Aplicar los inicios de sesin del servidor y los permisos de base de datos en el servidor de reserva para que coincida con los del servidor de produccin.Primero, debe agregar los inicios de sesin de SQL Server en el sistema de espera o de asegurarse de que los inicios de sesin que ya estn all. Segn el entorno, puede probar a usar el procedimiento almacenado sp_change_users_login con la opcin AutoFix para vincular los usuarios de bases de datos en el servidor de reserva para los inicios de sesin.Sin embargo, Microsoft no recomienda este procedimiento almacenado en situaciones "sensibles a la seguridad". (Para obtener ms informacin acerca de los problemas potenciales, vea el artculo de Microsoft " FIX: sp_change_users_login con Auto_Fix falla cuando se ejecuta con la Base de datos cursor local Configurar Opcin "). Una manera segura de transferir inicios de sesin y los permisos es aplicar una secuencia de comandos slo para ese fin. El procedimiento sp_revokedbaccess almacenado, que SQL Server 7. 0 Service Pack 2 (SP2) fijo, elimina usuarios hurfanos de una base de datos. A continuacin, puede escribir una secuencia de comandos que utiliza el procedimiento almacenado sp_grantdbaccess junto con el comando GRANT para asignar permisos. No se olvide de probar las conexiones para asegurarse de que se pueden conectar y llegar a los datos en el servidor de reserva. Conectar con el servidor de reserva. A diferencia de un servidor en un clster, el servidor en espera tendr un nombre diferente y una direccin IP diferente del servidor de produccin fallado, as que tendrs que cambiar las fuentes de datos de las aplicaciones del cliente. Para realizar este cambio ms fcil, se puede utilizar un agente de conexin,que es una tabla o un archivo que permite a los clientes que el sistema SQL Server que deben conectarse.

Hablando desde la experiencia

He estado trabajando con una instalacin de trasvase de registros en la produccin durante ms de 9 meses en un conjunto de bases de datos de contenido superior a 300 GB de datos. Algunas de las bases de datos se acercan a 35 GB de tamao. Grandes bases de datos presentan los mayores desafos cuando usted est realizando tareas de gestin, incluyendo el trasvase de registros. Estas son algunas de las cosas que hemos aprendido a travs de la experiencia. El tamao importa. de datos de ms de, digamos, 20 GB puede tardar mucho tiempo para una copia de seguridad, copia y restauracin. Una base de datos de 30 GB

puede tardar ms de una hora para realizar copias de seguridad y se puede producir un archivo de copia de seguridad casi tan grande como la propia base de datos. Copia de un archivo de 30 GB para el servidor en espera puede durar horas a menos que tenga una conexin rpida entre los servidores. Restauracin de la base de datos a travs del mismo enlace puede tardar mucho ms tiempo de copia de seguridad de la base de datos y la copia o el proceso de restauracin puede generar carga de trabajo adicional para el subsistema de E / S del servidor de produccin. Hemos encontrado que, con el tiempo, la creacin de trasvase de registros para grandes bases de datos uno a uno era ms fcil que tratar de ponerlos en marcha a la vez. Con las bases de datos ms pequeas (unos pocos gigabytes o menos), la creacin de mltiples procesos de envo de registros va rpidamente y no es un problema. Evite las interferencias. copias de seguridad de larga duracin bloquean las copias de seguridad de registro de transacciones programadas, produciendo mensajes de error en los trabajos del Agente SQL. Decidimos programar copias de seguridad de registro de transacciones slo fuera de la ventana de copia de seguridad de base de datos. La base de datos como una etapa. La carga de grandes cantidades de datos en las bases de datos del servidor de produccin y realizar actualizaciones masivas en los datos cargados a menudo aumenta drsticamente el tamao de los archivos de copia de seguridad de registro de transacciones. Como resultado, cuando se realizaron las copias de seguridad del registro durante el proceso de carga de datos y el masaje, el servidor en espera tareas de restauracin pasaron mucho tiempo en un estado de retrotraccin, el manejo de las inserciones masivas y actualizaciones. Esta situacin provoc una acumulacin de tareas de respaldo en el servidor en espera y, a menudo retrasa el trasvase de registros por hasta 24 horas. Nuestras soluciones son para cargar los datos que necesitaban dar masajes en una base de datos provisional que no necesita conectarse copias de seguridad y para apagar las tareas de respaldo del registro de transacciones en otras bases de datos de inicio de sesin de envo durante grandes cargas de datos. No presentacin de informes, por favor! Usted puede restaurar manualmente los registros de base de datos y de transacciones en el servidor de reserva con ESPERA, que pone la base de datos en modo de slo lectura, o con NORECOVERY, lo que deja la base de datos en un modo no operativo. Sin embargo, en modo de espera, si algn usuario est consultando la base de datos o el mantenimiento de cualquier tipo de

conexin a la misma, el trabajo de carga de inicio de sesin del envo no puede restaurar los registros debido a la restauracin de un registro de transacciones requiere el uso exclusivo de la base de datos. Por lo tanto, usted puede tener la tentacin de restaurar la base de datos standby con NORECOVERY para evitar que los usuarios de la lectura de los datos. Por desgracia, cuando xp_sqlmaint restaura los registros de transacciones, se los restaura con ESPERA, haciendo las bases de datos de slo lectura. Debido a que nuestra frecuencia de copia de seguridad del registro de transacciones es de 5 minutos, tuvimos que poner en prctica una poltica que los usuarios (y desarrolladores) no pueden acceder a las bases de datos del servidor de reserva. Mltiples bases de datos con ESPERA. Cuando especifica una base de datos restaurar con la tecla STANDBY, tambin debe especificar un nombre de archivo para deshacer. Encontramos que si tratamos de restaurar ms de una base de datos a la vez, las bases de datos no podran utilizar el mismo nombre de archivo de deshacer. Si lo hicieran, las restauraciones fracasaron. Realizamos nuestra base de datos completa restaura con NORECOVERY en cambio, a pesar de que las bases de datos standby en ltima instancia terminan en modo de slo lectura cuando xp_sqlmaint restaura los registros de transacciones. Sin embargo, otro paquete de servicio. Cuando se instala un 7.0 Service Pack de SQL Server, todas las bases de datos deben estar en un modo de recuperar. En consecuencia, al aplicar un service pack, debe recuperar las bases de datos, aplique el Service Pack, vuelva a inicializar las bases de datos del servidor de espera de una copia de seguridad completa, a continuacin, reinicie el trasvase de registros. No separes. Usando sp_detach_db en una base de datos en espera de que se encuentra en modo NORECOVERY o STANDBY produce el mensaje de error
<i> Servidor: Mensaje 947, nivel 16, estado 1, lnea 0 </ i> . <i> Error al cerrar la base de datos 'pubscopy' limpiamente </ i> . <i> base de datos con xito independiente 'Pubscopy' </ i>

Cuando a continuacin, volver a adjuntar la base de datos, que ser en un modo de recuperacin. Los intentos posteriores por el trabajo de carga para aplicar las copias de seguridad de registro de transacciones se producir un error. En esencia, usando sp_detach_db en una base de datos en espera de que se encuentra en las pausas modo NORECOVERY o STANDBY trasvase de registros, y no he visto una explicacin a

Microsoft acerca del mensaje de error. Cuidado, porque el inicio de sesin que une la base de datos tambin ser propietaria la base de datos adjunta. Con un poco de trabajo de configuracin, se puede implementar el trasvase de registros como una solucin de alta disponibilidad de bajo costo y confiable para SQL Server 7.0 que proporciona recuperacin de desastres casi en tiempo real. Y el trasvase de registros es ms fcil de configurar y administrar en SQL Server 2000. Vea SQL Server Magazinepara un prximo artculo sobre mejoras envo de registros en SQL Server 2000.