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
Precaución
Esta característica se quitará en una versión futura de SQL Server. Evite utilizar esta característica en nuevos trabajos de desarrollo y tenga previsto modificar las aplicaciones que actualmente la utilizan. Para lograr una alta disponibilidad, use grupos de disponibilidad AlwaysOn en su lugar.
Importante
La duplicación de bases de datos en SQL Server es una tecnología distinta de la duplicación de bases de datos de Microsoft Fabric. La creación de reflejo en Fabric proporciona un mejor rendimiento analítico, la capacidad de unificar el patrimonio de datos con OneLake en Fabric y abrir el acceso a los datos en formato Delta Parquet.
Con el reflejo en Microsoft Fabric, puede replicar continuamente su ecosistema de datos existente directamente en OneLake dentro de Fabric, incluidos los datos de SQL Server 2016+, Azure SQL Database, Azure SQL Managed Instance, Cosmos DB, Oracle, Snowflake y más.
Al actualizar una instancia reflejada de SQL Server a una nueva versión, a un nuevo Service Pack o actualización acumulativa de SQL Server, o a un nuevo Service Pack o actualización acumulativa de Windows, puede reducir el tiempo de inactividad de cada base de datos reflejada a solo una conmutación por error manual si realiza una actualización gradual (o dos conmutaciones por error manuales si conmuta por recuperación a la base de datos primaria original). Una actualización gradual es un proceso de varias etapas que, en su forma más simple, implica actualizar la instancia de SQL Server que actualmente actúa como servidor espejo en una sesión de creación de reflejo, realizar manualmente la conmutación por error de la base de datos reflejada, actualizar la que antes era la instancia principal de SQL Server y reanudar la creación de reflejo. En la práctica, el proceso exacto dependerá del modo de funcionamiento y del número y diseño de la sesión de creación de reflejo que se ejecute en las instancias de SQL Server que va a actualizar.
Para obtener más información sobre cómo usar la duplicación de la base de datos con el envío de registros durante una migración, descargue este informe técnico sobre la duplicación de la base de datos y el envío de registros.
Requisitos previos
Antes de empezar, revise la siguiente información importante:
Actualizaciones de ediciones y versiones admitidas: compruebe que puede actualizar a SQL Server desde su versión del sistema operativo Windows y de su versión de SQL Server. Por ejemplo, no puede actualizar directamente desde una instancia de SQL Server 2005 a la versión de SQL Server más reciente.
Elegir un método de actualización del motor de base de datos: seleccione el método y los pasos de actualización adecuados en función de la revisión de versiones admitidas y actualizaciones de ediciones, y también teniendo en cuenta otros componentes instalados en el entorno con el fin de actualizar los componentes en el orden correcto.
Planeación y prueba del plan de actualización del motor de base de datos: revise las notas de la versión y los problemas conocidos de actualización, así como la lista de comprobación previa a la actualización, y desarrolle y pruebe el plan de actualización.
Requisitos de hardware y software para instalar SQL Server 2016: revise los requisitos de software para instalar SQL Server. Si se requiere software adicional, puede instalarlo en cada nodo antes de comenzar el proceso de actualización para reducir los posibles tiempos de inactividad.
Preparación recomendada (prácticas recomendadas)
Antes de iniciar una actualización gradual, es recomendable que:
Realice una conmutación por error manual de prueba en al menos una de las sesiones de creación de reflejo:
Nota
Para obtener información sobre cómo funciona la conmutación por error manual, consulte Cambio de roles durante una sesión de duplicación de la base de datos (SQL Server).
Proteja los datos:
Realice una copia de seguridad completa de cada base de datos principal:
Creación de una copia de seguridad completa de base de datos (SQL Server)
Ejecute el comando DBCC CHECKDB en cada base de datos principal.
Etapas de una actualización gradual
Los pasos específicos de una actualización gradual dependen del modo de funcionamiento de la configuración de creación de reflejo. No obstante, las etapas básicas son las mismas.
Nota
Para obtener información sobre los modos de funcionamiento, consulte Modos de funcionamiento de la creación de reflejo de la base de datos.
La ilustración siguiente es un diagrama de flujo en el que se muestran las etapas básicas de una actualización gradual para cada modo de funcionamiento. Los procedimientos correspondientes se describen después de la ilustración.
Importante
Una instancia del servidor podría estar realizando roles de creación de reflejo distintos (servidor principal, servidor reflejado o testigo) en sesiones de creación de reflejo simultáneas. En este caso, deberá adaptar el proceso básico de actualización continua en consecuencia. Para obtener más información, vea Conmutación de roles durante una sesión de creación de reflejo de la base de datos (SQL Server).
Nota
En muchos casos, una vez completada la actualización continua, volverá a conmutar al servidor principal original.
Para cambiar una sesión del modo de alto rendimiento al modo de alta seguridad
Si una sesión de reflejo se está ejecutando en modo de alto rendimiento, antes de realizar una actualización progresiva, cambie el modo de funcionamiento a seguridad alta sin conmutación por error automática.
Importante
Si el servidor reflejado está geográficamente distante del servidor principal, puede no ser conveniente realizar una actualización gradual.
En SQL Server Management Studio: cambie la opción Modo de funcionamiento a Seguridad alta sin conmutación automática por error (sincrónica) mediante la página Reflejo del cuadro de diálogo Propiedades de la base de datos. Para obtener información sobre cómo acceder a esta página, consulte Iniciar el Asistente para configurar la seguridad de la creación de reflejo de la base de datos (SQL Server Management Studio).
En Transact-SQL: establezca la seguridad de transacciones en FULL. Para obtener más información, vea Cambiar la seguridad de las transacciones en una sesión de creación de reflejo de la base de datos (Transact-SQL).
Para quitar un testigo de una sesión
Si una sesión de creación de reflejo conlleva un testigo, recomendamos que lo quite antes de realizar una actualización gradual. De lo contrario, cuando se actualiza la instancia del servidor espejo, la disponibilidad de la base de datos depende del testigo que permanece conectado a la instancia del servidor principal. Después de quitar un testigo, puede actualizarlo en cualquier momento durante el proceso de actualización gradual sin aumentar el tiempo de inactividad de la base de datos.
Nota
Para más información, consulte Cuórum: cómo un testigo afecta la disponibilidad de la base de datos (Duplicación de la base de datos).
Para realizar la actualización gradual
Para reducir al mínimo el tiempo de inactividad, recomendamos lo siguiente: inicie la actualización gradual actualizando primero cualquier asociado de creación de reflejo que sea actualmente el servidor espejo en todas sus sesiones de creación de reflejo. Podría tener que actualizar varias instancias del servidor en este momento.
Nota
Un testigo se puede actualizar en cualquier momento del proceso de actualización gradual. Por ejemplo, si una instancia de servidor es un servidor reflejo en la sesión 1 y un testigo en la sesión 2, puede actualizar ahora esa instancia de servidor.
La instancia del servidor que se debe actualizar en primer lugar depende de la configuración actual de las sesiones de creación de reflejo, como se indica a continuación:
Si alguna instancia del servidor ya es el servidor espejo en todas sus sesiones de creación de reflejo, actualice la instancia del servidor a la nueva versión.
Si todas las instancias del servidor son actualmente el servidor principal en cualquier sesión de creación de reflejo, seleccione una instancia del servidor para actualizarla primero. A continuación, realice manualmente la conmutación por error de cada una de sus bases de datos principales y actualice esa instancia del servidor.
Una vez que se ha actualizado, una instancia del servidor vuelve a unirse automáticamente a cada una de sus sesiones de creación de reflejo.
En cada sesión de creación de reflejo cuya instancia del servidor reflejado se acaba de actualizar, espere a que la sesión se sincronice. A continuación, conéctese a la instancia del servidor principal y realice una conmutación manual por error de la sesión. Tras la conmutación por error, la instancia de servidor actualizada se convierte en el servidor principal de esa sesión, y el anterior servidor principal se convierte en el servidor espejo.
El objetivo de este paso consiste en que otra instancia de servidor se convierta en el servidor espejo en cada sesión de reflejo en la que actúe como socio.
Restricciones después de la conmutación por error a una instancia del servidor actualizada.
Después de realizar la conmutación por error desde una instancia anterior del servidor hasta una instancia actualizada de SQL Server, la sesión de base de datos se suspende. No se puede reanudar hasta que se actualice el otro socio. Sin embargo, el servidor principal sigue aceptando conexiones, y permitiendo acceso y modificaciones a datos en la base de datos principal.
Nota
El establecimiento de una nueva sesión de creación de reflejo requiere que todas las instancias del servidor se ejecuten en la misma versión de SQL Server.
Después de la conmutación por error, recomendamos que ejecute el comando DBCC CHECKDB en la base de datos principal.
Actualice cada instancia de servidor que ahora es el servidor espejo en todas las sesiones de creación de reflejo en las que participa como asociado. Podría tener que actualizar varios servidores en este momento.
Importante
En una configuración de creación de reflejo compleja, alguna instancia de servidor podría seguir siendo el servidor principal original en una o varias sesiones de creación de reflejo. Repita los pasos 2 a 4 para esas instancias de servidor hasta que se actualicen todas las instancias implicadas.
Reanude la sesión de creación de reflejo.
Nota
La conmutación automática por error no funcionará hasta que el testigo se haya actualizado y agregado de nuevo a la sesión de creación de reflejo.
Actualice cualquier instancia de servidor restante que actúe como testigo en todas las sesiones de duplicación en las que participe. Cuando un testigo actualizado se reincorpora a una sesión de duplicación, la conmutación automática por error vuelve a ser posible. Podría tener que actualizar varios servidores en este momento.
Para devolver una sesión al modo de alto rendimiento
Si lo desea, vuelva al modo de alto rendimiento utilizando uno de los métodos siguientes:
En SQL Server Management Studio: cambie la opción Modo de funcionamiento a Rendimiento alto (asincrónico) mediante la página Creación de reflejo del cuadro de diálogo Propiedades de la base de datos.
En Transact-SQL: use ALTER DATABASE para establecer la seguridad de las transacciones en OFF.
Para volver a agregar un testigo a una sesión de duplicación
Si lo desea, en el modo de alta seguridad, restablezca el servidor testigo en cada sesión de creación de reflejo.
Devolver un testigo
Consulte también
Actualización a SQL Server 2016 mediante el Asistente para instalación (programa de instalación)
Instalar SQL Server 2016 desde el símbolo del sistema
ALTER DATABASE Reflejo de la base de datos (Transact-SQL)
BACKUP (Transact-SQL)
Ver el estado de una base de datos reflejada (SQL Server Management Studio)
Creación de reflejo de la base de datos (SQL Server)
Conmutación de roles durante una sesión de creación de reflejo de la base de datos (SQL Server)
Forzar el servicio en una sesión de duplicación de base de datos (Transact-SQL)
Iniciar el Monitor de creación de reflejo de la base de datos (SQL Server Management Studio)
Modos de operación del reflejo de bases de datos