Hablar sobre la reparación de fallas del sistema de SQL Server Los mejores consejos

SQL Server 2005 y 2008 tienen varias opciones de alta disponibilidad, como el envío de registros, la copia y la creación de reflejo de la base de datos. Todas estas tecnologías se pueden usar como un medio para mantener un servidor alternativo, y esta base de datos se puede poner en línea y utilizar como un nuevo servidor primario cuando surgen problemas con su base de datos primaria original. Sin embargo, debe recordar que reemplazar el servidor en espera con la línea es solo la mitad del trabajo de resolución de problemas realizado.

Hay muchas cosas que debe tener en cuenta fuera de la base de datos para que su aplicación funcione. Esto incluye información de inicio de sesión, usuarios de bases de datos, tareas de programación, paquetes DTS y SSIS, ejecutables, objetos en la base de datos del sistema, bases de datos del mismo nombre, servidores vinculados, y más.

A veces, estas pequeñas dependencias solo se descubren cuando se realiza una recuperación de falla de la base de datos, por lo que tiene que dedicar mucho tiempo a depurar y evaluar la causa raíz del problema. Además, debe permitir que el segundo servidor y la aplicación se conecten lo más rápido posible para reducir el tiempo de inactividad. Por lo tanto, es muy importante realizar ajustes de antemano.

Cuando se trata de la alta disponibilidad y la planificación de recuperación de desastres de SQL Server, debe tener en cuenta una jerga latina que me gusta: Si vis pacem, para bellum, que se traduce como "Si usted Para obtener la paz, primero tiene que prepararse para la guerra. Después de recordar esto, echemos un vistazo a algunos de los problemas que pueden surgir. También sugeriré varias tareas que se pueden hacer por adelantado para asegurar que el proceso de recuperación de fallas en la base de datos se complete de manera rápida y eficiente.

Usuarios de la base de datos y la información de inicio de sesión de SQL Server

Su Servidor de recuperación debe hacer una copia de seguridad de toda la información de inicio de sesión y los usuarios de la base de datos, incluidas las contraseñas. La información de inicio de sesión se puede crear en cualquier momento, pero si usa el envío de registros o la creación de reflejo de la base de datos, su base de datos manejará el estado de recuperación para que solo pueda completar el proceso de recuperación una vez que vuelvan a estar en línea.

Con la autenticación de Windows, la información de inicio de sesión se puede asignar fácilmente a los usuarios de la base de datos. Sin embargo, si está utilizando la autenticación SQL, deberá restablecer manualmente la información de inicio de sesión al usuario de la base de datos en la base de datos que obtuvo de otro servidor. Por lo tanto, pierde la conexión entre la información de inicio de sesión y el usuario de la base de datos cuando migra la base de datos.

Después de restaurar la base de datos en el segundo servidor, ejecute el código:

USE YourDatabaseName

EXEC sp_change_Users_Login 'UPDATE_ONE', YourDBUserName, YourLogin

Otra forma de mantener su información de inicio de sesión sincronizada es seguir los pasos en Microsoft Knowledge Base para obtener artículos sobre la transferencia de información de inicio de sesión y contraseñas entre instancias de SQL Server. Este artículo explica cómo hacer un script de información de inicio de sesión utilizando el SID original. Cuando estos inicios de sesión se crean en el servidor de la base de datos de conmutación por recuperación, la conexión entre la información de inicio de sesión y el usuario de la base de datos se guarda, por lo que no tiene que ejecutar el script anterior para reparar el usuario huérfano.