SQL Server

Obtención de alta disponibilidad para SQL Server

Zach Nichter

Resumen:

• Creación de reflejos
• Instantáneas de base de datos
• Trasvase de registros
• Clústeres
• Réplica

Descargar el código de este artículo: NichterHA2007_03.exe (151KB)

La alta disponibilidad es un concepto que todos los administradores de bases de datos deben entender. Se refiere a la capacidad de respuesta y la accesibilidad de un sistema. A veces, tener una alta disponibilidad significa un tiempo de respuesta en segundos, mientras que otras situaciones requieren tiempos de respuesta en

fracciones de segundo. En una ocasión asesoré a una compañía donde los servidores web requerían consultas SQL para tener tiempos de respuesta de retorno en milisegundos; si la respuesta excedía este límite, el sistema de base de datos se consideraba inactivo y el servidor web debía volver a conectarse al siguiente servidor de base de datos disponible.

Con usuarios que demandan aplicaciones cada vez más rápidas, saber cómo lograr una alta disponibilidad y obtener tiempos de respuesta rápidos le ayudarán a planear las aplicaciones que dependen de datos con buen juicio.

Afortunadamente, SQL Server™ 2005 incluye varias opciones para mejorar la disponibilidad, incluidas la réplica, los clústeres, la creación de reflejos de la base de datos, las instantáneas de base de datos y el trasvase de registros de base de datos. Examinaré estas características y le ayudaré a decidir lo que es apropiado para su entorno. Comencemos con la figura 1, que describe las opciones de disponibilidad en SQL Server 2005.

Figure 1 Opciones de alta disponibilidad

Definición de alta disponibilidad

Uno de los primeros objetivos al planear una aplicación de alta-disponibilidad consiste en definir lo que significa en su entorno específico. Para algunas organizaciones, una alta disponibilidad significa que debe haber hardware redundante igual al hardware de producción, de forma que los datos y el hardware deben tener un tiempo productivo y una disponibilidad del 99,995 por ciento o superior. Es posible que otras organizaciones requieran que sólo los datos tengan una alta disponibilidad y que les preocupe menos el rendimiento a nivel de producción en caso de que se necesite una conmutación por error. Es muy importante definir en qué consiste la alta disponibilidad para determinar la solución más correcta para su situación.

También es necesario identificar los tipos de interrupción que puede experimentar e indicar cómo estos afectan a los contratos de nivel de servicio. Las interrupciones que pueden afectar a su disponibilidad incluyen un rendimiento planeado, imprevisto y reducido.

Una interrupción planeada suele ser un período de mantenimiento programado sobre el que se notifica a los usuarios de los sistemas con antelación. Una interrupción imprevista suele ser el resultado de un error de hardware o software que impide el acceso a los datos. La reducción del rendimiento también puede causar interrupciones y, por lo general, se mide en el tiempo de respuesta del usuario final que la empresa y la organización de TI suelen acordar de antemano en algún contrato de nivel de servicio.

Además de identificar los posibles orígenes de las interrupciones, también debe determinar el nivel de actividad de los datos y si siempre debe establecerse una conexión en línea o si en ocasiones puede ser cerca de línea o fuera de línea. Asimismo, debe decidir también si la opción de disponibilidad va a estar en la misma ubicación geográfica o en una ubicación remota. Las limitaciones de presupuesto probablemente también desempeñarán un papel decisivo en la decisión que tome. Analicemos ahora cada una de las opciones de disponibilidad.

Creación de reflejos de bases de datos

Antes de examinar la creación de reflejos de base de datos, debería definirse la terminología.

La entidad principal es el servidor de producción principal que aloja la base de datos que envía sus registros de transacción continuamente al servidor reflejado y la base de datos.

La entidad reflejada es el servidor secundario que aloja la copia de seguridad de la base de datos. La copia reflejada se sincroniza de forma coherente con la base de datos principal.

La función indica el propósito de un determinado servidor, tanto si funciona como la entidad principal o la reflejada.

El testigo es la instancia que supervisa los servidores principal y reflejado cuando estos realizan sus tareas y puede iniciar una conmutación por error automática.

Un asociado puede ser el servidor principal o el servidor reflejado.

En un entorno típico, se realizará una copia de seguridad de la base de datos principal en la instancia principal, y dicha copia de seguridad se restaurará en la instancia reflejada (consulte la figura 2). Una vez que se restaure la base de datos, se debe configurar la creación de reflejos en el servidor principal a través de la ventana de propiedades de la base de datos principal en SQL Server Management Studio (SMSS) o mediante secuencias de comandos T-SQL.

Figura 2** Arquitectura de la creación de reflejos de base de datos **(Hacer clic en la imagen para ampliarla)

Una vez que se ha configurado la creación de reflejos y se ha establecido la sesión de la creación de reflejos, se sincronizarán las bases de datos principal y reflejada. La base de datos principal enviará su registro de transacciones correspondiente a los eventos producidos desde el momento en que se aplicó la última copia de seguridad en el reflejo. La base de datos reflejada recibirá el registro e intentará aplicarlo del modo más rápido posible. Si utiliza SQL Server 2005 Enterprise Edition, este proceso incluye varios subprocesos; de lo contrario, se trata de una operación de un solo subproceso. En cuanto se aplican estos registros a la entidad reflejada, las bases de datos se consideran sincronizadas y permanecerán sincronizadas hasta que se interrumpa la sesión reflejada.

Cuando los clientes ejecutan nuevas transacciones, el servidor principal ejecuta las transacciones con respecto a la base de datos principal y, mientras realiza esta operación, envía los registros de transacciones de la base de datos principal al registro de rehacer (o a las colas de registro) de la base de datos reflejada, desde donde se selecciona y se aplica a la base de datos reflejada. Una vez que se aplica la transacción y queda confirmada en la base de datos reflejada, se envía una respuesta a la entidad principal para notificar que la transacción se ha confirmado en la entidad reflejada. La entidad principal no confirmará ninguna transacción nueva que pueda entrar en el sistema hasta recibir una confirmación de la entidad reflejada.

En caso de error, la entidad reflejada puede iniciar un error automático y el testigo admite el proceso determinando si la base de datos principal está disponible. Cuando se produce un error, se debe resolver la cuestión de lo que es ahora el asociado reflejado antes de convertirse de nuevo en el asociado principal. Después de resolver los problemas relativos al asociado reflejado, se inicia la vuelta al servidor del asociado reflejado y las bases de datos se sincronizan de nuevo. Una vez que estén sincronizadas, la sesión de la creación de reflejos puede empezar otra vez.

Este modo específico de la creación de reflejos es un modo de alta seguridad que ofrece operaciones de transacción sincrónicas al activar la seguridad de transacción, pero no requiere un testigo porque no saca provecho de la conmutación por error automatizada; todas las conmutaciones por error se inician manualmente. Hay otro tipo de modo de creación de reflejos que ofrece operaciones de transacción sincrónicas: el modo de alta disponibilidad. No sólo requiere la activación de la seguridad de transacción, sino también que se utilice un testigo para la conmutación por error automatizada en caso de que se produzca error.

El tercer y último modo disponible para la creación de reflejos es el de alto rendimiento. Requiere la desactivación de la seguridad de transacción para permitir la compatibilidad con el funcionamiento asincrónico que, a su vez, permite que las transacciones del asociado principal se confirmen sin tener que esperar que el registro de transacciones se escriba en la entidad reflejada. El modo de alto rendimiento no requiere un testigo para la configuración.

Tenga en cuenta que la creación de reflejos requiere la misma edición de SQL Server en la entidad de seguridad y en la reflejada, pero no en el testigo, que puede ser SQL Server Express Edition. Además, es importante que la base de datos principal se encuentre en modo de recuperación completa.

ADO.NET 2.0 está integrado con SQL Server 2005 e incluye compatibilidad con la creación de reflejos de la base de datos, además de ofrecer una conmutación por error transparente para realizar la aplicación en el entorno reflejado. De este modo se da a la aplicación ADO.NET una manera de realizar automáticamente la conmutación por error sin codificación ni configuración adicionales, en el caso de que no se pueda realizar una conexión a la base de datos principal. La configuración es tan fácil como especificar un usuario común entre los dos entornos y el asociado de la conmutación por error en la cadena de conexión. A continuación se ofrece un ejemplo de una cadena de conexión de ADO.NET que identifica al asociado de la conmutación por error del entorno de la base de datos reflejada:

"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
 Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"

La creación de reflejos de la base de datos quizás sea una opción buena para su empresa en función de los requisitos de datos y aplicaciones, pero hay una serie de cuestiones que debe considerar a fin de obtener un rendimiento óptimo. Por ejemplo, ¿cuál es el nivel de la tasa de transacciones del sistema o el volumen de cambio de datos? Al tener en consideración la creación de reflejos de la base de datos, es fundamental determinar si la velocidad de la red y el ancho de banda son suficientes para soportar el volumen de datos y la tasa de procesamiento de transacciones. Asimismo, debe considerarse la saturación del vínculo. Esta cuestión es especialmente importante si la entidad reflejada se encuentra en otra ubicación geográfica. La supervisión del sistema de antemano es esencial para determinar si hay limitaciones en el entorno que impedirían el funcionamiento eficaz de la creación de reflejos.

La creación de reflejos de base de datos puede ser una opción especialmente buena si se intenta mantener un nivel bajo de costos. De hecho, la arquitectura de la creación de reflejos de la base de datos no requiere discos compartidos ni ninguna habilidad avanzada o especializada para ejecutar el entorno. Y, a diferencia de los clústeres, la creación de reflejos de la base de datos no necesita que ambos asociados tengan el mismo hardware. Además, la creación de reflejos es sencilla de implementar mediante el asistente de instalación que se encuentra en la ficha de creación de reflejos de la ventana de propiedades de base de datos (consulte la figura 3). También se recomienda leer el artículo técnico "Database Mirroring Best Practices and Performance Considerations" (en inglés) en go.microsoft.com/fwlink/?LinkId=80897 para obtener más información útil.

Figura 3** Asistente de instalación para la creación de reflejos **(Hacer clic en la imagen para ampliarla)

Instantáneas de base de datos

Las instantáneas de la base de datos constituyen una nueva tecnología que se ofrece en SQL Server 2005 Enterprise Edition, pero no se consideran una opción de alta disponibilidad. Las instantáneas de la base de datos se deben utilizar como una opción de recuperación o de generación de informes viable cuando se usa con otras tecnologías. Una instantánea es una vista de sólo lectura de una base de datos en un determinado punto en el tiempo.

Se crea una instantánea con el comando CREATE DATABASE del siguiente modo:

CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME = 
    'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO

Cuando se crea la instantánea de la base de datos, utiliza uno o varios archivos (archivos dispersos), en lugar de archivos de datos, como haría una base de datos típica. Estos archivos dispersos esencialmente son ubicaciones de almacenamiento virtual que inicialmente no consumen datos. Se utilizan para almacenar datos, sólo si dichos datos se cambian o eliminan en la base de datos de origen. Los datos se escriben en los archivos dispersos en una página de datos cada vez, y la instantánea de la base de datos sólo muestra datos que han cambiado desde que se tomó la instantánea. El resto de los datos proceden de las páginas de datos de la base de datos de origen.

Los archivos de instantánea de base de datos se asignan al tamaño de la base de datos al tomar la instantánea. El tamaño asignado no indica la cantidad de datos que realmente almacenan. Para obtener esta información, ejecute una instrucción de T-SQL como la siguiente:

SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
    2030'), 1);
GO

Gracias al modo en que se almacenan los datos en los archivos dispersos y la base de datos de origen, cuando se tiene acceso a una instantánea de la base de datos, se recuperan las páginas de datos de los archivos de datos de la base de datos de origen y las páginas de datos de los archivos dispersos de la instantánea. Las instantáneas sólo pueden convivir en el servidor con la base de datos de origen de la que se tomó la instantánea debido a la necesidad de compartir páginas de datos. Como esta arquitectura no mejora la E/S de la base de datos de origen, las instantáneas no son una opción de informe válida, ya que no representarán el verdadero estado de la base de datos.

Analicemos una situación en la que la creación de reflejos de base de datos se utiliza junto con las instantáneas. De este modo es posible separar físicamente los datos del informe, la entidad reflejada y las bases de datos de instantáneas de la base de datos principal. La instantánea de la base de datos se programa mediante el agente de SQL Server y una secuencia de comandos personalizada para ofrecer instantáneas actualizadas en intervalos regulares. La secuencia de comandos de ejemplo de la figura 4 muestra el procedimiento almacenado empleado para alcanzar este objetivo. Se ha diseñado para utilizarlo en un trabajo con el objetivo de administrar la creación y la eliminación de instantáneas para una determinada base de datos del entorno. Esto permitiría una solución de creación de informes aceptable, porque los datos de informe estarían aislados de los datos de producción.

Figure 4 Procedimiento almacenado para programar instantáneas

use msdb;
GO
set nocount on
GO

CREATE PROCEDURE usp_snaprefresh 
     @database    sysname = NULL    --name of the database to snapshot
    ,@keepsnap    int        = 24   --# of hours to keep a snapshot 
                                    --after it was created 
                                    --use a value of '0' to keep all
                                    --existing snapshots
    ,@fileloc    sysname            --location for snapshot
        = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'    
AS

DECLARE 
     @dt            datetime        ,@cnt          int
    ,@databaseid    int             ,@snap         sysname
    ,@sql           nvarchar(1000)  ,@yy           varchar(4)
    ,@mm            varchar(2)      ,@dd           varchar(2)
    ,@h             varchar(2)      ,@m            varchar(2)
    ,@lname         sysname         ,@pname        sysname
    ,@file          sysname         ,@pos1         int
    ,@pos2          int

-- initialize variables
SELECT 
     @dt = getdate()
    ,@cnt = 0, @pos1 = 0, @pos2 = 0
    ,@databaseid = db_id(@database)

-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
    RAISERROR ('Missing database name. Rerun the procedure specifying a
       valid database name.',16,1)
    RETURN (0) 
END

--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
    -- determine if other snapshots exist for this server older than @
    -- keepsnap value hrs
    SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum], 
        name INTO #t1 
    FROM master.sys.databases 
    WHERE source_database_id = @databaseid
        AND create_date < dateadd(hh,-(@keepsnap),getdate())

    IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
    BEGIN
        WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
        BEGIN
            SELECT @snap = name FROM #t1 WHERE RowNum = @cnt

            PRINT 'Dropping snapshot ''' + @snap + ''''

            SET @sql = 'DROP DATABASE ' + @snap

            EXEC(@sql)
            SELECT @cnt = @cnt + 1
        END
    END
END

-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
   month(@dt))
    ,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
         datepart(hh,@dt)) 
    ,@m = convert(varchar(2), datepart(mi,@dt))

-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m

-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files 
WHERE file_id = 1'

EXEC(@sql)

--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1

-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
    SET @fileloc = @fileloc + '\'
END

-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database

EXEC(@sql)

-- cleanup
DROP TABLE tempdb..t1;
GO

Sin embargo, tenga presente que las instantáneas de base de datos se consideran temporales, porque no es posible realizar copias de seguridad de las instantáneas y no pueden existir sin su base de datos de origen. Si un archivo disperso se queda sin espacio, la instantánea se considerará dañada y deberá eliminarse.

Además, con las instantáneas de base de datos, el rendimiento del sistema puede disminuir durante las operaciones de modificación de datos en la base de datos de origen, porque las páginas de datos se escriben en el archivo disperso para cada instantánea de los archivos de datos de la base de datos de origen. A su vez, esto multiplica el número de escrituras por el número de instantáneas que tenga una base de datos.

Los permisos de lectura vienen definidos por la base de datos de origen en el punto de la instantánea y no se pueden cambiar. La instantánea debe residir en la misma instancia que la base de datos de origen porque comparten páginas de datos, así como la misma caché de búfer.

Sólo debe considerar el uso de instantáneas como una solución de generación de informes si también utiliza la creación de reflejos; de lo contrario, no se produce ningún aumento del rendimiento en su entorno. Las instantáneas de la base de datos posiblemente son la manera más rápida de conservar los datos antes de ejecutar una operación dudosa en un sistema. Una base de datos puede volver al estado de la instantánea o se pueden extraer los datos de la instantánea para reemplazar los datos de la base de datos de origen.

Será necesario determinar un estándar de nomenclatura para las bases de datos de instantáneas. El estándar que utilizo es originaldatabasename_date_time.snp. Especifica primero la base de datos de origen, a continuación el día y la hora (en el formato de 24 horas) en que se tomó la instantánea.

Trasvase de registros

El trasvase de registros es una opción limitada de alta disponibilidad que utiliza la copia de seguridad y la recuperación para establecer una solución muy económica. El trasvase de registros saca provecho de las copias de seguridad de los registros de transacciones en un intervalo programado para actualizar una base de datos secundaria.

El trasvase de registros en SQL Server 2005 utiliza los asistentes para realizar el proceso de instalación, programación, inicialización y supervisión (consulte la figura 5). El proceso es sencillo y puede finalizar en pocos minutos.

Figura 5** Asistente de instalación para el trasvase de registros **(Hacer clic en la imagen para ampliarla)

Después de identificar la base de datos principal, se crea una programación y se determina la antigüedad del archivo para los archivos de copia de seguridad. A continuación, se deben establecer los archivos de uso compartido para los archivos de copia de seguridad. Una vez que se han establecido los archivos de uso compartido, es necesario definir la ubicación del archivo de la base de datos secundaria y la base de datos se debe inicializar realizando una restauración de la base de datos principal. Por último, se deben establecer las programaciones para las copias de los archivos de copia de seguridad y las restauraciones de las copias de seguridad del registro de transacciones, junto con las alertas o los retrasos necesarios para cada paso.

Una vez que ha finalizado la instalación, el trasvase de registros realiza la copia de seguridad del registro de transacciones de una base de datos según una programación en una ubicación de red compartida. Después de enviar los archivos al recurso compartido, la copia de seguridad se aplica a la base de datos secundaria según una programación establecida.

El trasvase de registros funciona muy bien en diversas situaciones debido a su sencillez. Es una buena opción para alta disponibilidad que es económica y puede soportar un sistema de alta transacción. La base de datos secundaria que se emplea en el trasvase de registros se puede utilizar en modo de sólo lectura, algo muy útil en una base de datos de generación de informes. El trasvase de registros requiere una sobrecarga mínima pero necesita una directiva de alertas en caso de encargarse de errores.

Dos cosas que se deben tener en cuenta si tiene pensado utilizar el trasvase de registros en su entorno: su instalación y administración sencillas, y el hecho de que no requiere habilidades especiales. El trasvase de registros no es una solución de alta disponibilidad en tiempo real, sin embargo, puede combinarse con la creación de reflejos de base de datos con este fin. Está limitado por las programaciones, así como por operaciones tales como copias de seguridad, copias de archivo y restauraciones. También requiere una conmutación por error manual. Por estas razones, el trasvase de registros ofrece una solución sencilla para el entorno que no se centra especialmente en los requisitos de tiempo.

Clústeres de SQL Server

Los clústeres del servidor funcionan en el nivel del sistema operativo e implican la réplica del hardware, así como de recursos de disco compartido para que el clúster pueda obtener acceso a ellos. Los clústeres constituyen el método menos intrusivo para los usuarios finales, pero también es probable que sea el más costoso. Requiere por lo menos el doble de cantidad de hardware necesario para ejecutar una instancia sin agrupar.

El tema de los clústeres es bastante complicado, por lo que antes de analizar todos los detalles aquí, ofreceré una introducción general. Los clústeres requieren dos o varios servidores, que deben instalarse con la misma versión de Windows ® 2000 Advanced o Datacenter Edition, o Windows Server ® 2003 Enterprise o Datacenter Edition. También requiere la instalación de los Servicios de Cluster Server de Microsoft® (MSCS), que trata la propiedad de los recursos compartidos entre los servidores y administra las direcciones IP, los discos compartidos y los nombres de red. Los clústeres también requieren un recurso de disco compartido, generalmente en forma de una red de área de almacenamiento (SAN) o el almacenamiento conectado a una SCSI.

Una instancia de SQL Server también se considera un recurso, y las ediciones Standard y Enterprise de SQL Server 2005 se pueden instalar en configuración de clúster. Consulte "Feature Comparison Chart for SQL Server 2005" (en inglés) en microsoft.com/sql/prodinfo/features/compare-features.mspx para obtener una lista de las características compatibles con ambas ediciones de SQL Server 2005.

Una vez que se han establecido los recursos en el clúster, el nodo secundario del clúster mantiene una comunicación regular con el nodo principal del clúster a través de un latido establecido en una red privada entre los dos nodos del clúster. El latido es un punto de control del intervalo que se toma para determinar si se ha producido un error en el nodo principal.

En caso de que se produzca un error en el nodo principal, los recursos se mueven al nodo secundario al tiempo que se mantiene el estado del servidor lógico de forma local. De este modo, los clientes pueden continuar funcionando con sólo una pausa en la interacción. El proceso entero de conmutación por error puede tardar entre 5 segundos (o menos) y 30 segundos (o más en algunas ocasiones), en función del hardware, el software y los componentes de red implicados en el clúster.

Los clústeres pueden ser una tecnología costosa y compleja que requiere habilidades especializadas para resolver los errores del sistema; sin embargo, ofrece la conmutación por error más fluida para los usuarios finales que tengan cualquiera de las opciones automatizadas de conmutación por error. Todas las aplicaciones son diferentes y algunas de ellas pueden ser incompatibles o no admitir clústeres, lo que, en el peor de los casos, requiere que la aplicación se vuelva a conectar.

Réplica

La réplica de SQL Server 2005 también se puede utilizar en arquitecturas de alta disponibilidad. Ofrece cuatro tipos de réplica: de instantáneas, de transacciones, de punto a punto y de mezcla. El tipo punto a punto tan sólo es una forma de réplica de transacciones, por lo que no lo analizaremos aquí.

Con la réplica, obtiene la posibilidad de tener un sitio y una base de datos secundarios para una alta disponibilidad, tan funcional como la base de datos principal. Esto se puede alcanzar mediante la réplica de mezcla, que toma las transacciones de las bases de datos principal y secundaria y combina los cambios entre sí. Como puede imaginar, con esta configuración se necesita un procedimiento de resolución de conflictos.

La réplica de transacciones es similar en el diseño lógico a la creación de reflejos de base de datos. Las transacciones que se aplican a la base de datos principal se envían a la base de datos secundaria para garantizar que el entorno permanece coherente. Una vez que llegan las transacciones, se aplican a la base de datos secundaria, la cual espera a que se aplique la siguiente transacción en el sistema.

La réplica de instantáneas es muy parecida al trasvase de registros en que se ejecutan en intervalos programados y actualizan la base de datos secundaria con cambios masivos, en lugar de aplicar cada transacción a ambos sistemas cuando se confirman. Ambas tecnologías se utilizan aproximadamente de la misma manera.

La réplica requiere conocimientos especializados, una cuestión importante para los entornos que no disponen de un administrador de bases de datos dedicado. La réplica puede ser un tanto complicada en lo que respecta a la solución de problemas, y requiere un diseño más complejo si se va a utilizar como una opción de alta disponibilidad.

La réplica puede cumplir adecuadamente los requisitos de una solución de alta disponibilidad. Esta tecnología hace lo que las funciones de la creación de reflejos de base de datos pueden hacer en el nivel de registros con la réplica de transacciones, pero sin la opción de una conmutación por error automatizada. Con los recursos suficientes y un poco de creatividad, puede crear una solución de conmutación por error automatizada.

A diferencia de la creación de reflejos de base de datos, las bases de datos de origen y destino son completamente accesibles para las aplicaciones cliente. La réplica ofrece la misma funcionalidad que el trasvase de registros con el uso de la réplica de instantáneas.

Sin embargo, debe tener en cuenta que la tecnología de réplica está completamente comprobada y bien documentada. El uso de la réplica para una solución de alta disponibilidad tiene algunos inconvenientes y el rendimiento puede ser un problema, pero sólo tanto como pueda serlo la creación de reflejos de base de datos. Cualquier solución de alta disponibilidad que diseñe mediante la réplica probablemente tenga una arquitectura más complicada de administrar; no más avanzada necesariamente, pero sin duda más compleja. Asimismo, uno de los mayores obstáculos que hay que tener en cuenta es que si la estructura de tablas de base de datos cambia o, si desea agregar una tabla para la réplica, deberá interrumpir el proceso y volver a definir la publicación a fin de que los cambios se incluyan en las dos bases de datos.

En resumen

Ahora ya sabe por qué la creación de una solución de alta disponibilidad para su entorno requiere un toque de creatividad. Todas las tecnologías de alta disponibilidad de SQL Server 2005 tienen sus ventajas y sus inconvenientes, y cada una de ellas tiende a situaciones diferentes.

El trasvase de registros, la réplica de instantáneas e incluso la creación de reflejos de base de datos en modo de alto rendimiento son métodos adecuados cuando se separa geográficamente una base de datos web principal de los entornos de base de datos secundaria (especialmente si no requieren que los datos secundarios estén disponibles en tiempo real).

Por otro lado, si la base de datos secundaria requiere datos en tiempo real, la réplica de transacciones o la creación de reflejos de base de datos puede llevar la carga si las tasas de transacción en el servidor principal son bajas y el vínculo entre los dos sitios del entorno es rápido y no está saturado.

También debe tomar en consideración el nivel de comodidad que tiene con estas tecnologías. Si ya tiene experiencia con algunas de estas tecnologías, no tendrá problemas. Si no cuenta con un administrador de bases de datos dedicado, intente evitar las tecnologías más complejas, como la réplica donde hay muchos elementos en movimiento, ya que la solución de problemas puede ser una tarea compleja. Considere contratar a un consultor experimentado de SQL Server para que le ayude con el diseño, la implementación y un posible entrenamiento del personal a fin de administrar una nueva alta disponibilidad apropiada para su entorno.

Si en su organización la alta disponibilidad sólo requiere que los datos están disponibles un alto porcentaje de tiempo y el tiempo de inactividad de los datos se considera una cuestión grave, es posible que, en su caso, los clústeres sean la mejor opción.

La cuestión es que SQL Server 2005 ofrece una serie de nuevas opciones para implementar la alta disponibilidad que están hechas a medida para ajustarse a los distintos tipos de entorno. Posiblemente, una sola opción de disponibilidad satisfaga sus necesidades o puede optar por sacar provecho de una combinación de tecnologías pero, como ya sabe ahora, tiene a su disposición una amplia variedad de opciones.

Zach Nichter es un profesional de SQL Server con más de 10 años de experiencia. Ha desempeñado una serie de funciones de soporte técnico de SQL Server, entre las que se incluyen administrador de bases de datos, responsable de equipo, director y consultor. Actualmente, Zach trabaja para Levi Strauss &Co. como arquitecto de administración de bases de datos, y se centra en la supervisión, la arquitectura y el rendimiento de SQL Server, entre otras iniciativas

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.