Compartir a través de

Elegir un método de actualización del motor de base de datos

  • Artículo

Se aplica a: SQL Server: solo Windows

Existen varios métodos que se deben considerar a la hora de planear la actualización del Motor de base de datos de una versión previa de SQL Server si se pretende reducir al mínimo el tiempo de inactividad y los riesgos. Puede realizar una actualización local, migrar a una nueva instalación o efectuar una actualización gradual. El siguiente diagrama le ayuda a elegir uno de estos enfoques. Cada enfoque del diagrama también se describe en el artículo. Si quiere obtener ayuda para tomar las decisiones que se le presentan en el diagrama, consulte también Planear y probar el plan de actualización del Motor de base de datos.

Diagrama en el que se muestra un árbol de decisión del método de actualización del motor de base de datos.

Descargar

  • Para descargar SQL Server 2016, visite el Centro de evaluación.

  • ¿Tiene una cuenta de Azure? A continuación, vaya a Azure Marketplace para poner en marcha una máquina virtual con la edición de SQL Server Developer ya instalada.

Opciones de actualización de Azure SQL

También puede plantearse actualizar su base de datos Azure SQL, la instancia administrada Azure SQL o virtualizar su entorno SQL Server como parte de su plan de actualización. Para obtener más información acerca de dichas opciones, consulte los enlaces siguientes:

Actualización local

Con este método, el programa de instalación de SQL Server actualiza la instalación de SQL Server existente reemplazando los bits de SQL Server existentes por los nuevos bits de SQL Server y, después, actualiza cada una de las bases de datos de usuario y del sistema.

El enfoque de actualización local es el más sencillo, conlleva la menor cantidad de tiempo de inactividad, tarda más en tiempo en revertirse (si esto fuera necesario) y no se admite en todos los casos. Para más información sobre los escenarios de actualización local que se admiten y los que no, vea Actualizaciones de ediciones y versiones admitidas.

Este enfoque se suele usar en los escenarios siguientes:

  • Un entorno de desarrollo sin una configuración de alta disponibilidad.

  • Un entorno de producción no esencial que pueda tolerar el tiempo de inactividad y que ejecute hardware y software recientes. La cantidad de tiempo de inactividad depende del tamaño de la base de datos y la velocidad de su subsistema de E/S. Se necesitará un poco más de tiempo a la hora de actualizar SQL Server 2014 (12.x) cuando se estén usando tablas optimizadas para memoria. Para obtener más información, consulte Planeación y prueba del plan de actualización del motor de base de datos.

En un nivel alto, los pasos necesarios para una actualización local del Motor de base de datos son los siguientes:

Diagrama en el que se muestra una actualización local no de alta disponibilidad del motor de base de datos.

Para más información detallada, vea Actualización a SQL Server mediante el Asistente para instalación (programa de instalación).

Consideraciones

El programa de instalación de SQL Server se detiene y reinicia la instancia de SQL Server como parte de las comprobaciones previas a la actualización.

Cuando actualice a SQL Server, la instancia anterior de SQL Server se sobrescribe y ya no está en el equipo. Antes de actualizar, realice una copia de seguridad de las bases de datos de SQL Server y de otros objetos asociados con la instancia anterior de SQL Server .

Migración a una nueva instalación

Con este método, conserva el entorno actual a la vez que crea un entorno de SQL Server, con frecuencia en nuevo hardware y con una nueva versión del sistema operativo. Después de instalar SQL Server en el nuevo entorno, debe realizar varios pasos a fin de prepararlo para poder migrar las bases de datos de usuario existentes desde el entorno antiguo al nuevo y minimizar el tiempo de inactividad. En estos pasos se incluye la migración de los siguientes elementos:

  • Objetos del sistema: Algunas aplicaciones dependen de información, entidades u objetos que se encuentran fuera del ámbito de una base de datos de usuario único. Normalmente, una aplicación depende de las bases de datos master y msdb, así como de la base de datos de usuario. Cualquier elemento almacenado fuera de la base de datos de usuario que sea necesario para el funcionamiento correcto de dicha base de datos debe estar disponible en la instancia de servidor de destino. Por ejemplo, los inicios de sesión de una aplicación se almacenan como metadatos en la base de datos master y se deben volver a crear en el servidor de destino. Si una aplicación o un plan de mantenimiento de bases de datos dependen de trabajos del Agente SQL Server, cuyos metadatos se almacenan en la base de datos msdb, dichos trabajos se deben volver a crear en la instancia del servidor de destino. De forma similar, los metadatos de un desencadenador de nivel de servidor se almacenan en master.

    Si mueve la base de datos de una aplicación a otra instancia de servidor, debe volver a crear todos los metadatos de las entidades y los objetos dependientes de las bases de datos master y msdb en la instancia de servidor de destino. Por ejemplo, si una aplicación de la base de datos usa desencadenadores de servidor, no basta con adjuntar o restaurar la base de datos en el nuevo sistema. La base de datos no funcionará según lo previsto a menos que se vuelvan a crear manualmente los metadatos para dichos desencadenadores en la base de datos master. Para más información detallada, vea Administrar los metadatos cuando una base de datos pasa a estar disponible en otra instancia del servidor (SQL Server)

  • Paquetes de Integration Services almacenados en msdb: si almacena paquetes en msdb, debe incluirlos en un script mediante la utilidad dtutil o volver a implementarlos en un nuevo servidor. Antes de usar los paquetes en el nuevo servidor, debe actualizarlos a SQL Server. Para obtener más información, consulte Upgrade Integration Services Packages.

  • Claves de cifrado de Reporting Services: Una parte importante de la configuración del servidor de informes es la creación de una copia de seguridad de la clave simétrica utilizada para cifrar información confidencial. La copia de seguridad de la clave se necesita para varias operaciones rutinarias y, además, permite volver a utilizar una base de datos del servidor de informes existente en una nueva instalación. Para obtener más información, vea Hacer copia de seguridad y restaurar claves de cifrado de Reporting Services y Upgrade y Migrate Reporting Services

Cuando el nuevo entorno de SQL Server cuente con los mismos objetos de sistema que el antiguo, deberá migrar las bases de datos de usuario desde el sistema existente a la instancia de SQL Server con un método que reduzca al mínimo el tiempo de inactividad en dicho sistema. Podrá realizar la migración de la base de datos por medio de una copia de seguridad y una restauración, o bien redirigiendo LUN si se encuentra en un entorno de SAN. Los pasos de ambos métodos se indican en los diagramas siguientes.

Precaución

La cantidad de tiempo de inactividad depende del tamaño de la base de datos y la velocidad de su subsistema de E/S. Se necesitará un poco más de tiempo a la hora de actualizar SQL Server 2014 (12.x) cuando se estén usando tablas optimizadas para memoria. Para obtener más información, consulte Planeación y prueba del plan de actualización del motor de base de datos.

Después de migrar las bases de datos de usuario, dirija a los nuevos usuarios a la nueva instancia de SQL Server mediante uno de los diversos métodos disponibles (por ejemplo, cambiar el nombre del servidor, usar una entrada DNS, y modificar las cadenas de conexión). El método de nueva instalación reduce los riesgos y el tiempo de inactividad (en comparación con una actualización local). Además, facilita que se actualice el hardware y el sistema operativo con la actualización a SQL Server.

Nota:

Si ya dispone de una solución de alta disponibilidad o de algún otro entorno con varias instancias de SQL Server, vaya a Actualización gradual. Si no cuenta con una solución de alta disponibilidad, puede plantearse configurar temporalmente la creación de reflejo de la base de datos a fin de minimizar el tiempo de inactividad y facilitar la actualización, o bien aprovechar esta oportunidad para configurar un grupo de disponibilidad AlwaysOn como solución de alta disponibilidad permanente.

Por ejemplo, puede utilizar este enfoque para actualizar los siguientes elementos:

  • Una instalación de SQL Server en un sistema operativo no compatible.
  • Una instalación x86 (32-bit) de SQL Server, ya que ni SQL Server 2016 (13.x) ni las versiones posteriores admiten este tipo de instalaciones.
  • SQL Server en hardware nuevo o una nueva versión del sistema operativo.
  • SQL Server con una consolidación de servidores.
  • SQL Server 2005 (9.x), ya que SQL Server 2016 (13.x) y las versiones posteriores no admiten la actualización in situ de SQL Server 2005 (9.x). Para obtener más información, vea la información para Actualizar desde una versión anterior de SQL Server.

Los pasos necesarios realizar una actualización mediante una nueva instalación varían ligeramente en función de si usa almacenamiento conectado o SAN.

  • Entorno de almacenamiento conectado: si tiene un entorno de SQL Server en el que se usa almacenamiento conectado, el diagrama siguiente y los vínculos que incluye le servirán de guía para seguir los pasos necesarios para realizar una actualización de Motor de base de datos a través de una nueva instalación.

    Diagrama en el que se muestra un método de actualización de instalación nuevo con copia de seguridad y restauración para el almacenamiento conectado.

  • Entorno de almacenamiento SAN: si tiene un entorno de SQL Server en el que se usa almacenamiento SAN, el diagrama siguiente y los vínculos que incluye le servirán de guía para seguir los pasos necesarios para realizar una actualización de Motor de base de datos a través de una nueva instalación.

    Diagrama en el que se muestra un método de actualización de instalación nuevo mediante Separar y Adjuntar para almacenamiento SAN.

Actualización gradual

Se requiere una actualización gradual en entornos de soluciones de SQL Server donde se deba actualizar varias instancias de SQL Server en un orden determinado para maximizar el tiempo de actividad, minimizar los riesgos y conservar determinada funcionalidad. Una actualización gradual es esencialmente la actualización de varias instancias de SQL Server en un orden determinado. Puede realizar una actualización en contexto en cada instancia de SQL Server existente, o bien una nueva actualización de la instalación para facilitar la actualización del hardware o el sistema operativo como parte del proyecto de actualización. Hay una serie de escenarios en los que deberá poner en práctica el enfoque de actualización gradual. Estos se documentan en los siguientes artículos: