Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a:SQL Server
Los problemas físicos, del sistema operativo o de SQL Server pueden provocar un error en una sesión de creación de reflejo de la base de datos. El reflejo de la base de datos no comprueba regularmente los componentes de los que depende Sqlservr.exe para verificar si funcionan correctamente o han fallado. Sin embargo, para algunos tipos de fallos, el componente afectado informa de un error a Sqlservr.exe. Cuando otro componente informa del error, éste se denomina error de hardware. Para detectar otros fallos que, de otro modo, pasarían desapercibidos, la duplicación de la base de datos implementa su propio mecanismo de tiempo de espera. Cuando se produce un tiempo de espera en la duplicación, la duplicación de la base de datos considera que se ha producido un error y declara un error leve. Sin embargo, algunos fallos que se producen en la instancia de SQL Server no provocan que la duplicación exceda el tiempo de espera y pueden pasar desapercibidos.
Importante
Los fallos en bases de datos distintas de la base de datos reflejada no se pueden detectar en una sesión de creación de reflejo de la base de datos. Además, no es probable que se detecte un error en el disco de datos, a menos que la base de datos se reinicie por el error de un disco de datos.
La rapidez de detección de errores y, por tanto, el tiempo de reacción de la sesión de duplicación ante un fallo dependen de si el error es grave o leve. En el caso de algunos errores de hardware, como los errores de red, se informa de inmediato. Sin embargo, en algunos casos, los períodos de espera específicos de cada componente pueden retrasar la notificación de algunos errores graves. En los errores de software, la longitud del período de tiempo de espera de la creación de reflejo determina la rapidez en la detección del error. De manera predeterminada, este valor es 10 segundos. Éste es el valor mínimo recomendado.
Problemas debidos a errores de hardware
Las posibles causas de errores de hardware incluyen (sin limitarse a) las siguientes condiciones:
Una conexión interrumpida o un cable roto
Una tarjeta de red en mal estado
Un cambio de enrutador
Cambios en el firewall
Reconfiguración del punto de conexión
Pérdida de la unidad en que reside el registro de transacciones
Errores de proceso o errores del sistema operativo
Por ejemplo, cuando la unidad de registro de la base de datos principal deja de responder y se produce un error, el sistema operativo informa a Sqlservr.exe de que se ha producido un error grave.
Algunos componentes, como los componentes de red y ciertos subsistemas de E/S, tienen sus propios tiempos de espera para determinar errores. Esos tiempos de espera son independientes de la duplicación de la base de datos, que no tiene conocimiento de ellos y desconoce por completo su comportamiento. En estos casos, el tiempo de espera aumenta el intervalo entre un error y el momento en que la creación de reflejo de la base de datos recibe el error grave resultante.
Nota:
La única comprobación activa de errores que se realiza para la creación de reflejo de la base de datos se produce en casos de errores no graves. Para obtener más información, vea "Problemas debidos a errores de software", más adelante en este tema.
Para ayudarle a interpretar las situaciones de error que tienen lugar en su red, pregunte al ingeniero de red qué mensajes de error se envían a un puerto cuando tienen lugar los siguientes eventos en una conexión TCP:
DNS no funciona
Los cables están desconectados
Microsoft Windows tiene un firewall que bloquea un puerto específico.
Se ha producido un error en la aplicación que está supervisando un puerto
Se cambia el nombre de un servidor basado en Windows.
Se reinicia un servidor basado en Windows.
Nota:
La duplicación no protege contra problemas específicos del acceso del cliente a los servidores. Por ejemplo, imagine un caso en el que un adaptador de red pública controla las conexiones de los clientes a la instancia de servidor principal, mientras una tarjeta de interfaz de red privada controla todo el tráfico de creación de reflejo entre las instancias de servidor. En este caso, el fallo del adaptador de red pública impediría que los clientes accedieran a la base de datos, aunque la base de datos seguiría replicándose.
Problemas debidos a errores de software
Las condiciones que pueden provocar el agotamiento del tiempo de espera en la creación de reflejo incluyen (sin limitarse a) lo siguiente:
Errores de red, como el agotamiento del tiempo de espera de las conexiones TCP, los paquetes descartados o corruptos, o los paquetes que están en un orden incorrecto.
Un sistema operativo, un servidor o una base de datos que no responde.
Se ha agotado el tiempo de espera de un servidor de Windows.
Recursos informáticos insuficientes, como una sobrecarga de la CPU o del disco, que se llene el registro de transacciones, o que el sistema se quede sin memoria o sin subprocesos. En estos casos, debe aumentar el tiempo de espera, reducir la carga de trabajo o cambiar el hardware para soportar la carga de trabajo.
El mecanismo de tiempo de espera de la duplicación
Debido a que los errores de software no son detectables directamente por una instancia de servidor, un error de software podría provocar que una instancia de servidor esperara de manera indefinida. Para evitarlo, la creación de reflejo de la base de datos implementa su propio mecanismo de tiempo de espera basado en que cada instancia de servidor de una sesión de creación de reflejo hace ping en cada conexión abierta con un intervalo fijo.
Para mantener una conexión abierta, una instancia de servidor debe recibir un ping en dicha conexión dentro del período de tiempo de espera definido, además del tiempo de espera necesario para enviar otro ping. La recepción de un ping durante el período de tiempo de espera indica que la conexión todavía está abierta y que las instancias de servidor se comunican a través de ella. Al recibir un ping, una instancia de servidor restablece su contador de tiempo de espera en dicha conexión.
Si no se recibe ningún ping en una conexión durante el período de tiempo de espera, una instancia de servidor considera que la conexión ha agotado el tiempo de espera. La instancia de servidor cierra la conexión que ha superado el tiempo de espera y controla el evento de tiempo de espera según el estado y el modo de funcionamiento de la sesión.
Aunque el otro servidor esté procesando correctamente, una expiración del tiempo de espera se considera un fallo. Si el valor de tiempo de espera de una sesión es demasiado corto para la capacidad de respuesta habitual de cualquiera de las dos partes, pueden producirse fallos falsos. Un error falso se produce cuando una instancia de servidor se pone en contacto correctamente con otra cuyo tiempo de respuesta es tan lento que sus comandos ping no se reciben antes de que expire el período de tiempo de espera.
En sesiones con el modo de alto rendimiento, el tiempo de espera siempre es de 10 segundos. Normalmente, esto es suficiente para evitar errores falsos. En sesiones con el modo de alta seguridad, el período de tiempo de espera predeterminado es de 10 segundos, pero puede cambiar su duración. Para evitar falsos fallos, recomendamos que el tiempo de espera de la duplicación sea siempre de al menos 10 segundos.
Para cambiar el valor del tiempo de espera (solo modo de alta seguridad)
Para visualizar el valor del tiempo de espera actual
- Consulte mirroring_connection_timeout en sys.database_mirroring.
Responder a un error
Independientemente del tipo de error, una instancia de servidor que detecta un error responde apropiadamente según el rol de la instancia, el modo de funcionamiento de la sesión y el estado de las demás conexiones de la sesión. Para obtener información acerca de lo que ocurre en caso de pérdida de un asociado, vea Database Mirroring Operating Modes.
Consulte también
Calcular la interrupción del servicio durante la conmutación de roles (creación de reflejo de la base de datos)
Modos de operación del reflejo de bases de datos
Conmutación de roles durante una sesión de creación de reflejo de la base de datos (SQL Server)
Creación de reflejo de la base de datos (SQL Server)