INF: Disaster Recovery Planning para SQL Server

Seleccione idioma Seleccione idioma
Id. de artículo: 169039 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

Resumen

Este artículo proporciona dos ejemplos de desastres simple planes de recuperación que un sitio puede tener en cuenta al planear forma proactiva para la recuperación de datos de una catástrofe. El primer ejemplo está destinado a sitios con ventanas de mantenimiento del sistema disponibles; el segundo ejemplo está diseñado para los sitios en una base de 24 horas.

La intención de este artículo es proporcionar un punto de partida para planear los esfuerzos de recuperación de desastres. Este artículo no es su plan de recuperación de desastres. Es para que poder considerar la luz de su propio entorno, modifique, especificar y comprobar.

Más información

Supongamos que se produce un incendio y borra fuera de su centro de datos de 24 horas. ¿Está seguro que puede recuperar? ¿Cuánto se tarda recuperar y que el sistema disponible? ¿Cuánto pérdida de datos pueden tolerar los usuarios? Estos deben algunas de las preocupaciones claves de cada administrador del sistema (SA) y Administrador de base de datos (DBA) encargados de mantener datos del sistema muy valiosa. Recuperación de desastres es el proceso por qué información se recuperan los sistemas en el caso de una catástrofe: un desastre natural o manmade, como un incendio o desastre técnico, como un error de disco de dos en una matriz RAID-5. Planeamiento de recuperación de desastres es el trabajo dedicado a preparar todas las acciones que se producirán en respuesta a un suceso catastrófico. Evaluación de la recuperación de desastres es la simulación de un evento catastrófico y la evaluación de capacidad de los desastres recuperación plan para entregar las necesidades de recuperación especificada.

Idealmente, el plan de recuperación de desastres debe indicar cuánto recuperación deben toman y la base de datos final estado pueden esperar que los usuarios. Por ejemplo, "después de la adquisición de hardware especificado, recuperación debe completarse en 48 horas y datos se puede garantizar que sólo hasta el final de la semana anterior." Es normalmente importante administración mantenerse informado claramente de estas especificaciones. Evaluación de la recuperación de desastres debe poder corroborar la especificación.

Un plan de recuperación de desastres pueden estructurarse de muchas maneras diferentes y puede contener muchos tipos de información (cómo obtener el hardware, que va a comunicarse, quiénes son las personas de contacto en el caso de desastre, cómo son ponerse en contacto con, propietario de la administración de plan etc.). En este artículo está destinada sólo a propone algunos vías iniciales para la recuperación técnica de SQL Server.

El siguiente es un ejemplo de sitios que no funcionan en función de 24 horas (es decir, los sitios que tienen ventanas de mantenimiento disponibles):

Para preparar para un desastre, siga este procedimiento cada día (o siempre que es la ventana de mantenimiento):
  1. Cerrar SQL Server.
  2. Copiar todos los archivos de dispositivo de base de datos, preferably a otro equipo en otro edificio (pero tenga cuidado de carga de red) y también para un dispositivo de cinta (con el servidor hacia abajo, el dispositivo puede copiarse al igual que cualquier otro archivo).
  3. Mantener registros del sistema de forma segura. Registrar el directorio en que todos los archivos de SQL Server están ubicados, especialmente en el archivo Master.dat. Mantenga registros de todos los service packs instalados para Windows NT Server y SQL Server. Mantener registros de bibliotecas de red utilizadas, el modo de seguridad y la contraseña de SA.
  4. Mantener una secuencia de comandos funcionalidad base para evaluar rápidamente la capacidad mínima (consulte la nota al final de este artículo).
  5. Para minimizar la cantidad de datos perdidos durante el día, realizar volcados de registro de transacciones y de base de datos mientras el sistema está activo. Vea los Server libros en pantalla de SQL para obtener más información sobre los procedimientos de volcado, carga y recuperación.
  6. Evalúe los pasos de recuperación de desastres siguientes de antemano en otro servidor y modificar los pasos según sea necesario.
Para recuperar después de producirse un desastre, siga estos pasos después de adquirir hardware de reemplazo adecuado:
  1. Instale a Windows NT Server y cargue el service pack apropiado. Compruebe que exista funcionalidad de dominio apropiado. Por ejemplo, comprobar que archivos compartidos funciona correctamente.
  2. Instalar a SQL Server y cargue el service pack apropiado. Coloque el dispositivo de base de datos master en el mismo directorio como se instaló inicialmente. Seleccionar también la misma red-biblioteca, modo de seguridad y contraseña de SA como antes.
  3. Confirme que SQL Server se está ejecutando correctamente. Si Windows NT Server ha cambiado el nombre, utilice sp_dropserver y sp_addserver para hacer coincidir el nombre Windows NT Server.
  4. Detenga SQL Server.
  5. Mover todos los archivos de dispositivo de base de datos vuelve a sus ubicaciones originales, incluido el archivo Master.dat.
  6. Reinicie SQL Server.
  7. Si los registros de transacción de base de datos o están disponibles después de este tiempo, cargarlas.
  8. Compruebe la disponibilidad del sistema. Ejecutar un script de funcionalidad para garantizar el adecuado funcionamiento. Idealmente, antes de los usuarios lanzamiento en el sistema, se debe proporcionar tiempo para ejecutar DBCC CHECKDB y NEWALLOC en cada base de datos, DBCC TEXTALL y TEXTALLOC en dichas bases de datos y tablas que contienen campos de texto. Esto es asegurarse de que el proceso de migración no modificó los archivos de forma no deseado.
  9. Después de ejecutar las instrucciones DBCC muestra la base de datos coherente y se realiza correctamente el script de prueba de funcionalidad, permiten a los usuarios reanudar.
El siguiente es un ejemplo para los sitios que no tienen ventanas de mantenimiento en línea y que ejecutará siete días a la semana, 24 horas al día:

Para preparar un desastre, realice lo siguiente:
  1. Periódicamente volcar todas las bases de datos, preferably en un disco en otro equipo en otro edificio (pero tenga cuidado de carga de red) y también a un dispositivo de cinta. Registros de transacciones pueden controlarse de forma similar.
  2. Mantener registros del sistema de forma segura. Registrar el directorio en que todos los archivos de SQL Server están ubicados, especialmente en el archivo Master.dat. Mantenga registros de todos los service packs instalados para Windows NT Server y SQL Server. Mantener registros de bibliotecas de red utilizadas, el modo de seguridad y la contraseña de SA. Mantenga registros de las opciones de base de datos especificada.
  3. Registrar en secuencias de comandos todos los cambios de tamaño para todos los dispositivos y bases de datos. Esto es crucial para simplificar la recuperación en esta situación!
  4. Mantener una secuencia de comandos funcionalidad base para evaluar rápidamente la capacidad mínima (consulte la nota al final de este artículo).
  5. Evalúe los pasos de recuperación de desastres siguientes de antemano en otro servidor y modificar los pasos según sea necesario.
Para recuperar tras un desastre se ha producido después de adquirir el hardware adecuado:
  1. Instale a Windows NT Server y cargue el service pack apropiado. Compruebe que exista funcionalidad de dominio apropiado. Por ejemplo, comprobar que archivos compartidos funciona correctamente.
  2. Instalar a SQL Server y cargue el service pack apropiado. Asegúrese de colocar el dispositivo de base de datos master en el mismo directorio que antes. Seleccionar también la misma red-biblioteca, modo de seguridad y contraseña de SA como antes.
  3. Confirme que SQL Server se está ejecutando correctamente. Si el servidor de Windows NT ha cambiado el nombre, ejecutar sp_dropserver y sp_addserver coincide con el nombre Windows NT Server.
  4. Crear o modificar todos los dispositivos y bases de datos de secuencias de comandos realizados en el paso 3 de la anterior sección anterior. Bases de datos pueden crearse para LOAD.
  5. Después de que todos los archivos de dispositivo y las bases de datos se mide como estaban al tiempo del último volcado, si la información de inicio de sesión de usuario o la información de inicio de sesión del servidor remoto es significativa de la base de datos maestra volcada, continúe con el paso 5a. En caso contrario, si no son cruciales, continúe con el paso 6.

    1. Detenga SQL Server.
    2. Iniciar SQL Server en modo de usuario único desde la línea de comandos "SQLSERVR - c -m".
    3. Se produjo la carga de la base de datos master desde el último volcado de ella antes la catástrofe.
    4. Después de éxito, detenga y reinicie SQL Server normalmente. Continúe con el paso 6.
  6. Cargar cada una de las bases de datos de usuario desde los archivos volcados (y el registro de transacciones se vuelca demasiado, si procede).
  7. Detenga y reinicie SQL Server.
  8. Compruebe la disponibilidad del sistema. Si no se vuelve a cargar la base de datos principal en el paso c de 5, establezca las opciones base de datos para cada base de datos. Ejecutar una secuencia de comandos de funcionalidad para garantizar el funcionamiento adecuado de SQL Server. Idealmente, antes los usuarios se publican en el sistema, se debe proporcionar tiempo para ejecutar DBCC CHECKDB y NEWALLOC en cada base de datos y DBCC TEXTALL TEXTALLOC en las bases de datos y tablas de texto que contiene campos. Esto es asegurarse de que el proceso de migración no modificó los archivos de forma no deseado.
  9. Después de ejecutar las instrucciones DBCC muestra la base de datos coherente y se realiza correctamente el script de prueba de funcionalidad, permiten a los usuarios reanudar.
Proporciona la comprobación del plan de evaluación de la recuperación de desastres y se consigue obteniendo hardware suficiente, proporcionando el desastre documentado instrucciones de recuperación y tener una copia de seguridad SA o administrador (alguien que no es complicado con el plan de desarrollo) recuperación el sistema en este equipo. Realizar evaluaciones de recuperación de desastres periódica para comprobar vitality del plan de recuperación de desastres actual.

Si los datos valiosos, no puede ser resaltada la importancia de evaluación de la recuperación de desastres. ¿Cuál es el riesgo de negocio si no se obtendrá los datos? ¿Cuál es el costo para retraso del cada hora en su sistema volver a poner en ejecución? Esto no es una situación que asuma que los datos están recuperables rápidamente; comprobarla! Comprender los pasos muy minuciosamente de antemano y reducirá el esfuerzo y la incertidumbre impuestas por las circunstancias del algunos catástrofe futura.

Este artículo se ha escrito como una expansión a la sección recuperación de base de datos en la página 48 de la Guía de implementación de Microsoft SQL Server 6.5 (se encuentra en el Web en http://www.microsoft.com/sql/deploy.htm). Puede encontrar información adicional sobre DUMP LOAD SQLSERVR base de datos maestra en Microsoft Knowledge Base y en los libros en pantalla de SQL Server.

Nota: "Un script de funcionalidad básica de" es un lote de código que puede utilizarse para mostrar rápidamente el funcionamiento correcto de la base de datos desde la perspectiva de una aplicación específica. Normalmente esto es un archivo .SQL con comandos SQL por lotes ejecutar en el servidor desde ISQL. Para otras aplicaciones, un archivo .bat es más adecuado porque puede contener comandos BCP y ISQL. Esta secuencia de comandos funcionalidad básica es muy específica de la aplicación y puede adoptar muchas formas diferentes. Por ejemplo, en un sistema Decision Support/informes, la secuencia de comandos puede ser simplemente una copia de un par de la clave consultas de informes; para una aplicación de (OLTP) de procesamiento de transacciones en línea puede ser la ejecución de un lote de procedimientos almacenados para ejecutar instrucciones INSERT, UPDATE y DELETE. El objetivo es confirmar, desde una perspectiva bruta, que todo funciona según lo previsto. La secuencia de comandos funcionalidad básica proporciona una herramienta útil para el SA o el administrador poder ver que la base de datos es nuevo en un estado viable, sin dependiendo de los usuarios finales para la comprobación.

Propiedades

Id. de artículo: 169039 - Última revisión: viernes, 14 de noviembre de 2003 - Versión: 3.0
La información de este artículo se refiere a:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Palabras clave: 
kbmt kbenv kbhowto kbusage KB169039 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 169039
Renuncia a responsabilidad de los contenidos de la KB sobre productos a los que ya no se ofrece asistencia alguna
El presente artículo se escribió para productos para los que Microsoft ya no ofrece soporte técnico. Por tanto, el presente artículo se ofrece "tal cual" y no será actualizado.

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com