Administración de Base de Datos Con SQL Server

Active Directory (AD) es un servicio de directorio desarrollado por Microsoft para redes de dominio de Windows. Su principal función es gestionar y almacenar información sobre los recursos de la red, como usuarios, grupos y dispositivos, y facilitar su administración y seguridad.

Uso de Active Directory en SQL Server

Autenticación

Active Directory permite la autenticación centralizada de usuarios en SQL Server. Esto significa que los usuarios pueden iniciar sesión en SQL Server utilizando sus credenciales de dominio de Windows, en lugar de tener que gestionar cuentas de usuario separadas en SQL Server. Aquí hay algunos beneficios clave:

1. Seguridad Mejorada:

   • Autenticación Integrada de Windows: SQL Server puede utilizar la autenticación integrada de Windows, lo que significa que los usuarios autenticados en el dominio de Windows pueden acceder a SQL Server sin necesidad de ingresar credenciales adicionales.

   • Políticas de Seguridad: Las políticas de seguridad de AD, como la complejidad de contraseñas y la expiración, se aplican automáticamente a las cuentas de usuario que acceden a SQL Server.

2. Gestión Simplificada:

   • Grupos de Seguridad: Puedes utilizar grupos de seguridad de AD para gestionar permisos en SQL Server. Por ejemplo, puedes asignar permisos a un grupo de AD y cualquier usuario añadido a ese grupo heredará esos permisos automáticamente.

   • Inicio de Sesión Único (SSO): Los usuarios pueden acceder a múltiples recursos en la red, incluido SQL Server, con una sola autenticación, mejorando la experiencia del usuario y reduciendo la carga administrativa.

Autorización

Active Directory también facilita la autorización, que es el proceso de determinar qué recursos puede acceder un usuario autenticado y qué acciones puede realizar. En SQL Server, esto se gestiona mediante roles y permisos asignados a usuarios y grupos de AD.

1. Roles de Base de Datos:

   • Puedes asignar roles de base de datos a usuarios y grupos de AD, lo que simplifica la administración de permisos. Por ejemplo, puedes crear un rol de “Lectura” y asignarlo a un grupo de AD que contiene todos los usuarios que necesitan acceso de solo lectura.

2. Permisos Granulares:

   • SQL Server permite definir permisos granulares en objetos específicos de la base de datos, como tablas, vistas y procedimientos almacenados. Estos permisos pueden ser asignados a usuarios y grupos de AD, proporcionando un control detallado sobre el acceso a los datos.

Configuración Básica

1. Habilitar la Autenticación de Windows:

   • En SQL Server Management Studio (SSMS), ve a las propiedades del servidor y asegúrate de que la autenticación de Windows esté habilitada.

2. Crear Inicios de Sesión Basados en AD:

   • Puedes crear inicios de sesión en SQL Server para usuarios y grupos de AD utilizando T-SQL o SSMS. Por ejemplo:SQL

     CREATE LOGIN [DOMINIO\Usuario] FROM WINDOWS;

     CREATE LOGIN [DOMINIO\Grupo] FROM WINDOWS;

     
     

     Código generado por IA. Revisar y usar cuidadosamente. Más información sobre preguntas frecuentes.

3. Asignar Permisos:

   • Asigna roles y permisos a los inicios de sesión de AD según sea necesario. Por ejemplo:SQL

     ALTER SERVER ROLE [db_datareader] ADD MEMBER [DOMINIO\Grupo];

     
     

     Código generado por IA. Revisar y usar cuidadosamente. Más información sobre preguntas frecuentes.

   
   

SQL Server Data Tools (SSDT) es un conjunto de herramientas de desarrollo que se integran con Visual Studio. Estas herramientas están diseñadas para facilitar la creación, administración y despliegue de bases de datos SQL Server, bases de datos de Azure SQL, modelos de datos de Analysis Services (AS), paquetes de Integration Services (IS) e informes de Reporting Services (RS).

¿Qué puedes hacer con SSDT?

1. Desarrollo de Bases de Datos:

   • Puedes crear y modificar esquemas de bases de datos utilizando un enfoque basado en proyectos. Esto significa que puedes tratar tu base de datos como un proyecto de desarrollo de software, con control de versiones y despliegue automatizado.

2. Modelos de Datos de Analysis Services:

   • SSDT te permite diseñar y desplegar modelos de datos que se utilizan para análisis y minería de datos. Estos modelos pueden ser tabulares o multidimensionales.

3. Paquetes de Integration Services:

   • Puedes crear paquetes de ETL (Extract, Transform, Load) para mover y transformar datos entre diferentes sistemas. Esto es útil para la integración de datos de múltiples fuentes.

4. Informes de Reporting Services:

   • SSDT facilita la creación de informes interactivos y visualizaciones de datos que se pueden desplegar en un servidor de Reporting Services.

Ventajas de Usar SSDT

• Integración con Visual Studio: Al estar integrado con Visual Studio, puedes aprovechar todas las características de este entorno de desarrollo, como el control de versiones, la depuración y la colaboración en equipo1.

• Automatización: Puedes automatizar el despliegue y las pruebas de tus proyectos de base de datos utilizando pipelines de CI/CD (Integración Continua/Despliegue Continuo)1.

• Consistencia: Al tratar las bases de datos como proyectos de software, puedes asegurar que los cambios se implementen de manera consistente y controlada.

  
  

Descargar en https://www.microsoft.com/en-us/sql-server/sql-server-editions-express

SQL Server está disponible en una amplia variedad de ediciones. Estos tienen diferentes precios y diferentes niveles de capacidad.

Cada edición de SQL Server está dirigida a un caso de uso comercial específico, como se muestra en la siguiente tabla:

• Enterprise: Brinda capacidades integrales de centros de datos de alta gama e incluye inteligencia de negocios de extremo a extremo.

• Business Intelligence: Proporciona una plataforma para construir soluciones de BI seguras, escalables y manejables.

• Estándar: Brinda capacidades básicas de administración de datos y BI.

• Developer:Incluye todas las capacidades de la edición Enterprise, con licencia para su uso en entornos de desarrollo y prueba. No se puede usar como servidor de producción.

• Express: Edición gratuita que permite aprender y crear pequeñas aplicaciones basadas en datos de escritorio.

• Web: Otorga una opción de bajo costo total de propiedad para proporcionar capacidades de base de datos a propiedades web de pequeña y gran escala.

• Azure: Facilita la creación de aplicaciones de base de datos en una plataforma en la nube escalable y sólida.

SQL Server Express

SQL Server Express ofrece toda la potencia de las ediciones Enterprise y Standard pero con las limitaciones en cuanto a tamaño y escala.

Ventajas:

• Permite crear N numero de base de datos cada uno con un máximo de 10 GB

• Soportar tantas conexiones como sea posible con el hardware donde la hayamos instalado

• Es posible instalar mas de una instancia de SQL Express en el servidor

Limitaciones:

• 1 procesador, con 4 núcleos como máximo, sin importar su velocidad o rendimiento

• 1 GB de memoria RAM para almacenar cachés de información, lo cual limita su rendimiento si manejamos conjuntos de datos muy grandes.

• 10 GB de tamaño máximo por cada base de datos.

Aunque estas restricciones limitan su escalabilidad, que es de lo que se trata, son bastante generosas y permiten crear aplicaciones de un tamaño bastante grande, considerandolas aptas para la pequeña y mediana empresa.

Se ofrecen tres variantes de SQL Server Express:

• LocalDB: muy útil durante el desarrollo. De hecho viene integrada con Visual Studio. Es una edición ligera del gestor de datos que se lanza bajo demanda en lugar de estar todo el tiempo funcionando y ocupando memoria, con menos requisitos que la edición real y con una instalación directa (sin necesidad de configurar nada). Trae lo estrictamente necesario por lo que ni siquiera tiene herramientas de administración, pero podemos conectarnos a ella con Visual Studio o con SQL Server Management Studio si lo tenemos instalado por otro lado. Descarga esta si vas a desarrollar.

• Express: es una versión esencial del motor que no incluye herramientas. Es decir, es como la anterior pero ya pensada para ser instalada en un entorno de producción, donde funcionará todo el rato. Como está pensada para producción no incluye tampoco herramientas de gestión ni nada accesorio: el motor de bases de datos puro y duro y listo para ser usado en una aplicación real. Descarga esta si vas a poner en producción una aplicación que ya has desarrollado.

• Express with Advanced Services: este es el paquete completo: el motor de bases de datos anterior y las herramientas de gestión, generación de informes y el añadido de permitir los servicios de búsqueda de texto completo. Descárgala tanto para desarrollar (pero teniendo herramientas de gestión en la descarga, sin recurrir a otras), o bien incluso para producción si quieres gestionarla desde el propio servidor en algún momento.

Azure SQL Database es un servicio de base de datos relacional basado en la nube proporcionado por Microsoft como parte de la plataforma Azure. Es una variante de Microsoft SQL Server diseñada para la nube, ofreciendo una solución gestionada y de alta disponibilidad para almacenar y administrar datos. Azure SQL Database permite a las empresas aprovechar las capacidades de SQL Server sin tener que gestionar la infraestructura subyacente.

Características Principales de Azure SQL Database

1. Servicio Gestionado: Azure SQL Database es un servicio completamente gestionado, lo que significa que Microsoft se encarga de las actualizaciones, parches, copias de seguridad y el mantenimiento general de la infraestructura.

2. Alta Disponibilidad: Ofrece alta disponibilidad incorporada con opciones de redundancia geográfica y recuperación ante desastres. La replicación automática asegura que los datos estén siempre disponibles.

3. Escalabilidad: Proporciona escalabilidad elástica tanto vertical (aumentando el tamaño de la base de datos) como horizontal (fragmentación de bases de datos), permitiendo ajustar el rendimiento y el almacenamiento según las necesidades de la carga de trabajo.

4. Seguridad: Incluye características avanzadas de seguridad como cifrado de datos en reposo y en tránsito, autenticación multifactor, y control de acceso basado en roles. También ofrece protección contra amenazas y auditoría.

5. Compatibilidad y Herramientas: Es compatible con la mayoría de las características de SQL Server y funciona con las herramientas familiares de SQL Server como SQL Server Management Studio (SSMS), Visual Studio y Azure Data Studio.

6. Modelos de Despliegue: Admite diferentes modelos de despliegue como bases de datos individuales, bases de datos elásticas (elastic pools) y bases de datos administradas (managed instances) para cubrir diferentes escenarios de uso.

Modelos de Servicio

1. Base de Datos Única (Single Database):

   • Es una base de datos aislada y completamente gestionada con su propia garantía de rendimiento mediante DTU (Database Transaction Unit) o vCore (Virtual Core).

2. Elastic Pool:

   • Un conjunto de bases de datos que comparten recursos como CPU y memoria. Ideal para aplicaciones con múltiples bases de datos que tienen patrones de uso impredecibles.

3. Managed Instance:

   • Una instancia completa de SQL Server administrada en la nube, que proporciona compatibilidad casi completa con las capacidades de SQL Server en las instalaciones, incluyendo soporte para más características de SQL Server.

Beneficios de Azure SQL Database

1. Reducción de Costos: Al ser un servicio gestionado, reduce los costos operativos y de mantenimiento. Solo se paga por los recursos utilizados, y no es necesario invertir en hardware.

2. Automatización: Automatiza muchas tareas administrativas como las actualizaciones de software, la gestión de parches y las copias de seguridad.

3. Flexibilidad: Ofrece múltiples opciones de escalabilidad y modelos de servicio para adaptarse a diferentes necesidades de aplicaciones y cargas de trabajo.

4. Seguridad: Incorpora prácticas de seguridad de vanguardia, incluyendo cifrado de datos, protección contra amenazas y auditoría.

5. Alta Disponibilidad y Recuperación Ante Desastres: Proporciona redundancia incorporada y opciones de recuperación ante desastres para garantizar que los datos estén siempre disponibles y protegidos.

Crear una base de datos de SQL Server utilizando una máquina virtual en Azure, conocido como Infraestructura como Servicio (IaaS), implica desplegar SQL Server en una VM (Virtual Machine) gestionada en la nube de Azure. Esta configuración permite a las organizaciones tener un control total sobre el sistema operativo, las configuraciones del servidor y la instalación de SQL Server, ofreciendo la flexibilidad y el control de una implementación on-premises, pero con las ventajas de la nube.

Ventajas de Usar una Máquina Virtual en Azure para SQL Server

1. Control Completo:

   • Personalización: Permite personalizar completamente la configuración del sistema operativo, las instalaciones de SQL Server y las aplicaciones.

   • Administración: Proporciona control total sobre el entorno del servidor, incluyendo el acceso al sistema operativo, los parches y las configuraciones de seguridad.

2. Compatibilidad y Flexibilidad:

   • Compatibilidad: Total compatibilidad con todas las características y versiones de SQL Server, incluyendo las ediciones y configuraciones específicas que podrían no estar disponibles en los servicios gestionados.

   • Flexibilidad de Configuración: Se puede ajustar la configuración del servidor según las necesidades de la aplicación, incluyendo el uso de instancias múltiples, configuraciones de alta disponibilidad personalizadas, y más.

3. Escalabilidad y Disponibilidad:

   • Escalabilidad: Escalar verticalmente aumentando la capacidad de la VM (CPU, memoria, almacenamiento) según las necesidades.

   • Alta Disponibilidad: Implementar soluciones de alta disponibilidad y recuperación ante desastres como Always On Availability Groups, replicación log shipping, y otras configuraciones de respaldo y recuperación.

4. Costo-Efectividad:

   • Modelos de Pago: Pago por uso, lo que permite optimizar los costos operativos al escalar recursos según sea necesario y apagar recursos cuando no se usan.

   • Licencias Flexibles: Uso de licencias existentes bajo el modelo de licencia híbrida de Azure, lo cual puede reducir costos si ya se poseen licencias de SQL Server.

5. Seguridad y Cumplimiento:

   • Seguridad de Nivel Empresarial: Implementar políticas de seguridad personalizadas, incluyendo firewalls, cifrado de datos y gestión de identidad y acceso.

   • Cumplimiento: Asegurar el cumplimiento de normativas específicas de la industria mediante configuraciones y políticas de seguridad específicas.

6. Integración con Otros Servicios de Azure:

   • Monitorización y Gestión: Uso de servicios como Azure Monitor, Log Analytics y Azure Security Center para la supervisión y gestión centralizada del entorno.

   • Almacenamiento y Redes: Integración fácil con otros servicios de Azure como Azure Storage, Azure Virtual Network, y Azure Backup.

Crear una base de datos en una instancia de SQL Server es una tarea fundamental para cualquier administrador de bases de datos. Este proceso implica varios pasos y consideraciones importantes para garantizar que la base de datos se configure correctamente y esté optimizada para su uso. A continuación, se detallan los pasos y consideraciones clave:

Pasos para Crear una Base de Datos en SQL Server

1. Planificación de la Base de Datos:

   • Propósito y Requisitos: Definir el propósito de la base de datos y sus requisitos, como el tamaño estimado, el crecimiento, el número de usuarios, y los tipos de datos que almacenará.

   • Estructura: Diseñar la estructura de la base de datos, incluyendo tablas, índices, claves primarias y foráneas, y otros objetos como vistas, procedimientos almacenados y funciones.

2. Seleccionar el Motor de Base de Datos:

   • Versión y Edición: Asegurarse de que la instancia de SQL Server cumple con los requisitos necesarios en términos de versión y edición.

3. Crear la Base de Datos:

   • T-SQL: Utilizar comandos T-SQL para crear la base de datos.

   • SQL Server Management Studio (SSMS): Utilizar la interfaz gráfica de SSMS para crear la base de datos.

Ejemplo de Creación de una Base de Datos usando T-SQL

CREATE DATABASE MiBaseDeDatos

ON PRIMARY (

    NAME = MiBaseDeDatos_dat,

    FILENAME = 'C:\MisDatos\MiBaseDeDatos.mdf',

    SIZE = 50MB,

    MAXSIZE = 500MB,

    FILEGROWTH = 10MB

)

LOG ON (

    NAME = MiBaseDeDatos_log,

    FILENAME = 'C:\MisDatos\MiBaseDeDatos_log.ldf',

    SIZE = 20MB,

    MAXSIZE = 200MB,

    FILEGROWTH = 5MB

);

Ejemplo de Creación de una Base de Datos usando SSMS

1. Abrir SQL Server Management Studio (SSMS) y conectarse a la instancia de SQL Server.

2. En el Explorador de Objetos, hacer clic derecho en la carpeta "Bases de datos" y seleccionar "Nueva base de datos...".

3. Rellenar los detalles de la base de datos en la ventana que aparece, incluyendo el nombre de la base de datos, y las propiedades de los archivos de datos y de log.

4. Hacer clic en "Aceptar" para crear la base de datos.

Consideraciones al Crear una Base de Datos en SQL Server

1. Ubicación de los Archivos:

   • Archivos de Datos y Log: Elegir ubicaciones adecuadas para los archivos de datos (.mdf) y log (.ldf) para optimizar el rendimiento y la recuperación ante desastres.

   • Almacenamiento: Asegurarse de que el almacenamiento tiene suficiente capacidad y rendimiento para manejar la carga esperada.

2. Configuraciones de Crecimiento Automático:

   • Filegrowth: Configurar el crecimiento automático de los archivos de datos y log de manera adecuada para evitar fragmentación y problemas de rendimiento.

   • Tamaño Inicial: Establecer un tamaño inicial razonable para los archivos para minimizar la necesidad de expansiones frecuentes.

3. Opciones de Recuperación:

   • Modelo de Recuperación: Seleccionar el modelo de recuperación adecuado (SIMPLE, FULL o BULK-LOGGED) según los requisitos de recuperación y rendimiento.

4. Consideraciones de Rendimiento:

   • Índices: Diseñar y crear índices adecuados para optimizar el rendimiento de las consultas.

   • Fragmentación: Implementar estrategias para minimizar la fragmentación de los índices.

   • Estadísticas: Asegurarse de que las estadísticas se actualizan regularmente para mantener la eficiencia de las consultas.

5. Seguridad:

   • Permisos y Roles: Configurar los permisos y roles de usuario para proteger los datos y garantizar el acceso adecuado.

   • Cifrado: Considerar el uso de cifrado para proteger datos sensibles en reposo y en tránsito.

6. Mantenimiento:

   • Plan de Mantenimiento: Crear un plan de mantenimiento que incluya tareas de respaldo, verificación de integridad de la base de datos, actualización de estadísticas y reindexación.

   • Monitoreo: Implementar herramientas de monitoreo para supervisar el rendimiento y la salud de la base de datos.

Descripción general de la seguridad de SQL Server

Antes de aprender a configurar la seguridad en SQL Server, será útil explorar algunos conceptos básicos de seguridad e identificar cómo se relacionan con SQL Server. La seguridad es una característica importante de todos los sistemas de software empresarial; Muchos de los conceptos relacionados con la seguridad son similares en múltiples sistemas. Asegurables, directores y permisos La seguridad generalmente se preocupa por permitir que alguien o algo acceda a un recurso y realice una o más acciones en él. Por ejemplo, un administrador de red puede necesitar dar acceso a los usuarios para ver el contenido de una carpeta. En términos más generales, el recurso sobre el que se realizará la acción se denomina asegurable; el "alguien o algo" que necesita realizar la acción se denomina director o principal; y la configuración que permite realizar la acción se conoce como un permiso. En el ejemplo anterior, la carpeta es asegurable, el usuario es el principal o director y el administrador debe otorgarle al usuario el permiso de "lectura" en la carpeta. Jerarquías de seguridad Las arquitecturas de seguridad son a menudo jerárquicas, principalmente para simplificar la administración de permisos. En una arquitectura de seguridad jerárquica, los asegurables pueden contener otros asegurables; por ejemplo, una carpeta puede contener archivos, y los principales pueden contener otros principales, donde los usuarios se agregan a un grupo, por ejemplo. Los permisos generalmente se heredan, tanto por las jerarquías de los asegurables (por ejemplo, otorgar permiso de "lectura" en una carpeta otorga implícitamente el permiso de "lectura" en los archivos que contiene), como por las jerarquías de los principales (por ejemplo, otorgar permiso de "lectura" a un grupo otorga implícitamente permiso de lectura a todos los usuarios que son miembros de ese grupo). En general, los permisos heredados se pueden anular explícitamente en diferentes niveles de jerarquía, para ajustar el acceso.

Esta disposición jerárquica simplifica la administración de permisos de varias maneras:

· Se deben otorgar menos permisos individuales, lo que reduce el riesgo de una configuración incorrecta. Puede establecer los permisos generales que se requieren en el nivel más alto de la jerarquía, y solo aplicar permisos de anulación explícitos más abajo en la jerarquía, para manejar casos excepcionales.

· Una vez establecidos los permisos, se pueden controlar a través de la pertenencia a grupos. Esto facilita la administración de permisos en entornos donde llegan nuevos usuarios y los usuarios existentes abandonan o cambian roles.

Mejores prácticas: cuando planifique una solución de seguridad, considere las siguientes mejores prácticas:

· Proporcione a cada director o principal solo los permisos que realmente necesita.

· Utilice la herencia asegurable para minimizar la cantidad de permisos implícitos que deben establecerse para habilitar el nivel de acceso requerido.

· Use contenedores principales, como grupos o roles, para crear una capa de abstracción entre principales y permisos para acceder a los asegurables. Luego puede usar la membresía de estos grupos para controlar el acceso a los recursos a través de los permisos que ha definido. Los cambios en el personal no deberían requerir cambios en los permisos.

Autenticación de SQL Server

La autenticación es el proceso de validación para garantizar que un director o principal sea él, es como cuando presentamos nuestro documento de identificación personal para validar que somos nosotros mismos, para poder usar uno o más servicios. Para conectarse al Motor de base de datos de SQL Server, el principal debe proporcionar información de autenticación que coincida con su credencial almacenada.

¿Quién realiza la autenticación?

Cuando configura SQL Server, debe elegir un modo de autenticación para el motor de base de datos. Puede elegir entre Windows® y el modo mixto. La autenticación de Windows siempre se usa, pero puede agregar más autenticación de SQL Server; esto se conoce como modo mixto.

Autenticación de Windows

SQL Server comprueba el nombre de usuario y la contraseña proporcionados con los detalles del usuario de Windows. SQL Server no requiere una contraseña. Este es el modo de autenticación predeterminado. La seguridad del usuario de Windows controla el acceso a SQL Server. El acceso se otorga en función de un token de acceso emitido cuando el usuario inició sesión en la sesión de Windows.

Debido a que se pueden crear grupos de usuarios en Windows, la administración del acceso al dominio se simplifica.

Autenticación de SQL Server (modo mixto)

El modo mixto es la adición de la autenticación de SQL Server a la autenticación de Windows. La autenticación de SQL Server requiere un inicio de sesión cuando se inicia la aplicación. El nombre de usuario y la contraseña se almacenan en las tablas de la base de datos y, por lo tanto, están separados de la autenticación de Windows. Se pueden aplicar las siguientes políticas opcionales:

· Cambiar contraseña en el siguiente inicio de sesión. Esta característica está habilitada en SSQ Server Management Studio.

· Caducidad de la contraseña. Puede establecer una política de edad máxima para las contraseñas.

· Política de contraseña de Windows. Puede hacer cumplir las políticas de Windows para contraseñas. Por ejemplo, longitudes de contraseña mínimas y máximas, y otras reglas que definen estándares mínimos para las contraseñas. Por ejemplo, obligar al usuario a incluir mayúsculas, números y signos de puntuación en sus contraseñas.

Servidores vinculados

Puede ejecutar consultas distribuidas en orígenes de datos OLE DB que son externos a la instancia actual de SQL Server, es decir ejecutar una consulta de datos en su servidor a partir de datos de otro servidor o fuente. Por ejemplo, es posible que desee ejecutar una consulta Transact-SQL tomando datos de fuentes externas como otro SQL Server, Microsoft Excel®, Access® u otros productos de bases de datos, como MySQL u Oracle.

Para esto se utiliza la tecnología OLE para gestionar conexiones entre diversas fuentes de datos. Como las fuentes de datos pueden estar fuera de su dominio de seguridad, debe asegurarse de comprender cómo funcionan los servidores vinculados y cómo proteger las conexiones entre ellos.

Los beneficios de los servidores vinculados son los siguientes:

· Acceso a datos externos. Permite el acceso a datos externos a la instancia de SQL Server.

· Diversas fuentes de datos externos. Puede trabajar con muchos tipos de fuentes de datos dentro de su organización.

· Método estandarizado. La forma en que interactúa con otras fuentes de datos está estandarizada.

Objetivo de un servidor vinculado

Los siguientes objetos son necesarios para habilitar servidores vinculados utilizando OLE DB:

· Proveedor. Este es un archivo de biblioteca de vínculos dinámicos (DLL) que administra las conexiones a una fuente de datos específica.

· Fuente de datos. El objeto que contiene los datos con los que desea trabajar. Suelen ser bases de datos, pero también pueden ser otras fuentes de datos, como hojas de cálculo, el proveedor OLE DB de Native Client es el proveedor de SQL Server.

· SQL Server ha sido probado con el proveedor OLE DB Native Client y otros proveedores.

El proveedor de Open Database Connectivity (ODBC) puede habilitar conexiones seguras a muchas otras fuentes de datos.

Un problema bastante común en SQL Server es cambiar el nombre del equipo o servidor donde está instalado nuestro SQL, esto provoca varios conflictos en nuestra instancia de SQL, no trabajan los asistentes, la replicación entre servidor no trabajan, no podemos hacer referencia al nombre de la instancia porque esta ya no tiene el nombre correcto.

La explicación es sencilla es que durante la instalación de SQL Server se graba en la base de datos del sistema, master, el nombre del servidor. Este nombre lo podemos consultar a través de la variable global @@SERVERNAME.

Cuando cambiamos el nombre del servidor, estos datos no se actualizan de forma automática en la base de datos master, con lo que la información se desfasa.

Luego de cambiar nombre del servidor entonces debemos en nuestro SQL Management Studio cambiar el nombre de nuestra instancia, para esto borramos el nombre del servidor anterior, nombre obtenido con consultar la variable @@SERVERNAME con un simple SELECT @@SERVERNAME, y luego agregamos nuevamente nuestro servidor con el nombre actual, el script es el siguiente:

Select @@SERVER
go

sp_dropserver 'old_name'

go

sp_addserver 'new_name', 'local'
go

El nombre actual del servidor se obtiene de escribir en la linea de comandos de Windows la instrucción Hostname

Si se trata de una instancia con nombre las instrucciones deberían de ser:

sp_dropserver <old_name\instancename>;   
go   

sp_addserver <new_name\instancename>, local;   
go   

Copias de seguridad de SQL Server

Puede realizar copias de seguridad en SQL Server utilizando la instrucción BACKUP de Transact-SQL o la interfaz gráfica en SQL Server Management Studio (SSMS).

También puede usar Windows PowerShell® para realizar una copia de seguridad mediante el cmdlet Backup-SqlDatabase en el módulo SQLPS.

Existen diferentes tipos de back-up esto por si se necesita hacer back-up de la base de datos o del log de transacciones, en cuanto a la base de datos se pueden hacer back-ups completos, incrementales o incluso parciales es decir solo de ciertos grupos o archivos de la base de datos.

Copia de seguridad completa de la base de datos

Una copia de seguridad completa de la base de datos hará una copia de seguridad de todas las páginas de datos en la base de datos y también guardará la parte activa del registro de transacciones, de acuerdo al tamaño de la base de datos pude demorar tiempos prolongados en realizarse.

Copia de seguridad diferencial de la base de datos

Aunque las copias de seguridad completas de la base de datos son ideales, a menudo el tiempo necesario para realizar una puede superar los beneficios que proporciona. Esto es particularmente cierto cuando solo un pequeño porcentaje de la base de datos cambia entre cada copia de seguridad. En este escenario, las copias de seguridad diferenciales son una consideración sensata. Puede realizar una copia de seguridad diferencial utilizando SSMS o utilizando la opción DIFERENTIAL de la instrucción BACKUP. Un back-up diferencial hace una copia de seguridad de los cambios realizados con respecto al último back-up completo realizado.

Cómo funcionan las copias de seguridad diferenciales

SQL Server mantiene un mapa de extensiones modificadas llamado página de mapa de bits diferencial. Se mantiene una página de mapa de bits diferencial para cada sección de 4 GB de cada archivo de datos. Cada vez que se crea una copia de seguridad completa de la base de datos, SQL Server borra el mapa.

A medida que cambian los datos en los archivos de datos, SQL Server actualiza el mapa y, cuando se ejecuta una copia de seguridad diferencial, solo se respaldan las extensiones que han cambiado desde la última copia de seguridad de la base de datos completa. Si ejecuta dos copias de seguridad diferenciales consecutivas, la segunda contendrá todas las extensiones que han cambiado desde la última copia de seguridad completa de la base de datos, no solo las que se han realizado desde la primera copia de seguridad diferencial.

No puede crear una copia de seguridad de base de datos diferencial a menos que primero se haya realizado una copia de seguridad completa de la base de datos.

Copias de seguridad del registro de transacciones

Antes de que se pueda realizar una copia de seguridad del registro de transacciones, la base de datos debe estar en modo de recuperación completa o de registro masivo. Además, una copia de seguridad del registro de transacciones solo puede ocurrir cuando se ha realizado previamente una copia de seguridad completa de la base de datos. A menos que una base de datos esté configurada en modo de recuperación de registro masivo, una copia de seguridad del registro de transacciones no guarda ninguna página de datos de la base de datos.

Una copia de seguridad del registro de transacciones encuentra el MaxLSN de la última copia de seguridad del registro de transacciones exitosa y guarda todas las entradas de registro más allá de ese punto en el MaxLSN actual. Luego, el proceso trunca el registro de transacciones tanto como sea posible (a menos que se especifique la opción COPY_ONLY o NO_TRUNCATE). La transacción activa de más larga duración debe conservarse, en caso de que la base de datos deba recuperarse después de una falla.

Antes de poder restaurar una base de datos mediante el uso de copias de seguridad de registros de transacciones, debe estar disponible una cadena ininterrumpida de registros de registros, desde la última copia de seguridad completa de la base de datos hasta el punto de restauración deseado. Si hay una interrupción, solo puede restaurar hasta el punto donde se rompe la cadena de respaldo. Por ejemplo, imagine un escenario en el que cree una base de datos y luego realice una copia de seguridad completa. En este punto, la base de datos se puede recuperar. Si el modelo de recuperación de la base de datos se cambia a simple y posteriormente se vuelve a cambiar por completo, se ha producido una interrupción en la cadena del archivo de registro. Aunque existe una copia de seguridad de la base de datos completa anterior, la base de datos solo se puede recuperar hasta el punto de la última copia de seguridad del registro de transacciones, antes del cambio al modo de recuperación simple.

Después de cambiar del modelo de recuperación simple al completo, debe realizar una copia de seguridad de la base de datos completa para crear un punto de partida para las copias de seguridad del registro de transacciones.

Copia de seguridad de la cola del registro

Para recuperar una base de datos hasta el punto de falla, debe realizar una copia de seguridad de la cola del registro antes de comenzar una restauración en una base de datos existente. Esto garantiza que todas las transacciones se escriban en al menos una copia de seguridad, antes de que se puedan sobrescribir. La copia de seguridad del registro de cola evita la pérdida de trabajo y mantiene intacta la cadena de registro. Cuando está recuperando una base de datos hasta el punto de una falla, la copia de seguridad del registro de cola suele ser la última de interés en el plan de recuperación. Si no puede hacer una copia de seguridad de la cola del registro, solo puede recuperar una base de datos hasta el final de la última copia de seguridad que se creó antes de la falla.

No todos los escenarios de restauración requieren una copia de seguridad del registro de cola. No necesita tener una copia de seguridad de registro de cola si el punto de recuperación está contenido en una copia de seguridad de registro anterior o si está moviendo o reemplazando (sobrescribiendo) la base de datos y no tiene que restaurarla a un punto posterior al más reciente apoyo.

Al realizar una copia de seguridad del registro de cola de una base de datos que está actualmente en línea, puede usar la opción NO_RECOVERY para colocar inmediatamente la base de datos en un estado de restauración, evitando que se produzcan más transacciones hasta que se restablezca la base de datos. Si la base de datos está dañada, puede usar la opción NO_TRUNCATE, que hace que el motor de la base de datos intente la copia de seguridad, independientemente del estado de la base de datos. Esto significa que una copia de seguridad tomada mientras se usa la opción NO_TRUNCATE podría tener metadatos incompletos. Si no puede hacer una copia de seguridad de la cola del registro utilizando la opción NO_TRUNCATE cuando la base de datos está dañada, puede intentar una copia de seguridad del registro de cola especificando la opción CONTINUE_AFTER_ERROR.

Realizar copias de seguridad parciales y de grupos de archivos

Al administrar una base de datos extremadamente grande, el tiempo necesario para realizar copias de seguridad completas (y restaurarlas en caso de falla) puede tener un efecto perjudicial en las operaciones comerciales en curso. Si bien las copias de seguridad del registro de transacciones y las copias de seguridad diferenciales pueden aliviar este problema, para bases de datos extremadamente grandes que utilizan el modelo de recuperación simple (para el que no se pueden realizar copias de seguridad del registro de transacciones), puede optar por hacer una copia de seguridad solo de los archivos y grupos de archivos que contienen datos volátiles, sin incluidos archivos de solo lectura y grupos de archivos en la copia de seguridad. Hay dos técnicas utilizadas para implementar este tipo de solución de respaldo:  Respaldo parcial. Una copia de seguridad parcial solo realiza una copia de seguridad del grupo de archivos primario y los grupos de archivos configurados para lectura-escritura. También puede incluir grupos de archivos específicos de solo lectura si es necesario. El propósito de una copia de seguridad parcial es facilitarle la copia de seguridad de las partes de una base de datos que cambian, sin tener que planificar la copia de seguridad de archivos o grupos de archivos específicos. Puede realizar una copia de seguridad parcial o diferencial completa

SQL Server puede enviar correos electrónicos utilizando el Servicio de Correo de Base de Datos (Database Mail). Esta funcionalidad es muy útil para notificaciones automáticas, como alertas de trabajos (jobs) fallidos, informes automáticos y otros eventos.

Configuración de Database Mail

1. Habilitar Database Mail:

   • Primero, asegúrate de que Database Mail esté habilitado en tu servidor SQL.

   • Abre SQL Server Management Studio (SSMS).

   • En el Explorador de Objetos, expande "Management" (Administración).

   • Haz clic con el botón derecho en "Database Mail" y selecciona "Configure Database Mail".

2. Crear un Perfil de Correo:

   • En el asistente de configuración de Database Mail, crea un nuevo perfil.

   • Asigna un nombre al perfil y agrega una cuenta de correo electrónico.

   • Configura los detalles de SMTP (dirección del servidor SMTP, puerto, autenticación, etc.).

3. Configurar las Opciones de Seguridad:

   • Configura qué usuarios pueden enviar correos utilizando este perfil de correo.

   • Completa la configuración y guarda los cambios.

Uso de sp_send_dbmail

Una vez configurado Database Mail, puedes utilizar la función sp_send_dbmail para enviar correos electrónicos. Aquí tienes un ejemplo de cómo se usa:

EXEC msdb.dbo.sp_send_dbmail    @profile_name = 'PerfilCorreo',    @recipients = 'destinatario@example.com',    @subject = 'Notificación de Job Fallido',    @body = 'El job X ha fallado. Por favor, revisa los detalles en el servidor.',    @body_format = 'HTML'; -- Puede ser 'TEXT' o 'HTML'

Detalles Adicionales y Ejemplo Completo

Para ilustrarlo de manera más clara, supongamos que tienes un trabajo que debe ejecutarse diariamente para actualizar los datos de ventas y deseas recibir una notificación por correo si este trabajo falla. Podrías configurar una alerta en SQL Server para que esto ocurra automáticamente.

1. Crear una Alerta:

   • En SSMS, ve a "SQL Server Agent" y expande "Jobs".

   • Haz clic derecho en el trabajo para el cual deseas configurar la alerta y selecciona "Properties".

   • Ve a la pestaña "Notifications" (Notificaciones).

   • Marca "Email" y selecciona el perfil de correo y destinatarios.

2. Enviar Correo Manualmente con sp_send_dbmail:

BEGIN TRY   

-- Código del trabajo, por ejemplo, actualizar tabla de ventas   

UPDATE Ventas    SET Total = Total * 1.1   

WHERE Fecha = CAST(GETDATE() AS DATE);

END TRY

BEGIN CATCH   

-- Si ocurre un error, envía un correo electrónico   

EXEC msdb.dbo.sp_send_dbmail       

@profile_name = 'PerfilCorreo',       

@recipients = 'admin@example.com',       

@subject = 'Error en el Job de Actualización de Ventas',       

@body = 'Ha ocurrido un error durante la actualización de la tabla de ventas. Por favor, revisa el servidor para más detalles.';   

-- Manejo adicional de errores si es necesario

END CATCH;

Beneficios y Aplicaciones

Utilizar sp_send_dbmail no solo te permite estar al tanto de los fallos en los trabajos, sino que también puede ser utilizado para notificaciones rutinarias, informes diarios, alertas de rendimiento, y más. Esta funcionalidad es especialmente útil en ambientes de análisis de datos y negocios, donde necesitas mantener un flujo constante de información y asegurarte de que los procesos críticos se ejecuten correctamente.

Implementar una solución de este tipo es una parte fundamental de mantener la infraestructura de datos eficiente y confiable, lo que te permite enfocarte en el análisis y la inteligencia de negocios sin preocuparte por los problemas operativos.

El Agente SQL Server funciona como un servicio de Windows y permite ejecutar trabajos programados o como respuesta a un evento específico. Por ejemplo, si deseamos realizar un Backup de todos los servidores de la empresa todos los días después del horario de trabajo, puede automatizar esta tarea con el SQL Server Agent y evitar el error humano de asignar esta tarea a una persona.

Para esto el Agente se vale de Trabajos, Alertas, Operadores y Proxys

· Los Trabajos o Jobs: Son una serie de tareas definidas, con secuencia lógica, se programan en un horario y frecuencia.

· Alertas o Alert: Es una respuesta automática a un evento específico, que puede ser de un objeto de SQL o ocasionado por el rendimiento del Servidor.

· Operador u Operators: es el usuario al que se le envía la notificación disparada por una alerta o por una acción de un trabajo.

· También se cuenta con las cuentas Proxy que permiten que una tarea de un trabajo que deba ejecutarse fuera de SQL como llamar a un EXE en sistema operativo, por ejemplo, se ejecute a través de estas cuentas Proxy, asociando una cuenta de windows con una de sql.

Auditoría de SQL Server

SQL Server Audit es la herramienta principal de auditoría en SQL Server. Puede usarla para rastrear eventos a nivel de servidor y de nivel de base de datos en una instancia de SQL Server, y luego registrar estos eventos en archivos de auditoría o registros de eventos. Todas las ediciones de SQL Server admiten auditorías a nivel de servidor, pero la edición Enterprise, la edición Developer y la edición Evaluation también admiten auditorías a nivel de base de datos.

Debido a que se basa en eventos extendidos, la terminología de Auditoría de SQL Server es similar a la terminología de eventos extendidos:

· Auditoría de servidor: define dónde almacenar los datos de auditoría.

· Especificación de auditoría del servidor: recopila muchos grupos de acción a nivel de servidor generados por eventos extendidos. Uno por auditoría.

· Especificación de auditoría de base de datos: Recopila acciones de auditoría a nivel de base de datos generadas por Extended Events. Uno por base de datos por auditoría.

· Acciones: acciones específicas que pueden generar eventos y agregarse a la auditoría. Por ejemplo, SELECT operations on a table.

· Grupos de acciones: grupos lógicos de acciones para simplificar la creación de especificaciones de auditoría. Por ejemplo, BACKUP_RESTORE_GROUP, que incluye cualquier comando de copia de seguridad o restauración.

· Objetivo: recibe y almacena los resultados de la auditoría. Puede ser un archivo, un registro de eventos de seguridad de Windows o un registro de eventos de aplicaciones de Windows.

Servidor de Auditoría

Un servidor de auditoría define dónde y cómo se registran los eventos auditados. Cada auditoría de servidor define una ubicación de almacenamiento u objetivo (como un archivo o un registro de eventos de Windows), el intervalo de tiempo antes de que se escriban los eventos y la acción que SQL Server debe tomar si el destino se queda sin espacio en disco.

Puede crear auditorías mediante la instrucción CREATE SERVER AUDIT o mediante la interfaz gráfica del SQL Server Management Studio (SSMS). Hay varias opciones que puede configurar, que incluyen:

· Nombre. Nombre fácil de usar para referirse a la auditoría.

· Retraso en la cola. Tiempo en milisegundos en que SQL Server puede almacenar los resultados de la auditoría antes de enjuagarlos al destino.

· En caso de falla. Acción a tomar si el registro de auditoría no está disponible: continuar, apagar el servidor o fallar las operaciones auditables.

· Destino de auditoría. Ubicación del objetivo.

· Tamaño máximo de archivo. Tamaño máximo de cada archivo de auditoría (en MB).

· Reserva de espacio en disco. Indica si se debe reservar espacio en disco para los archivos de auditoría por adelantado.

El valor que configure para el retraso de la cola debe ser una compensación entre seguridad y rendimiento. Un valor bajo asegura que los eventos se registren rápidamente y evita el riesgo de perder elementos de la pista de auditoría en caso de falla, pero puede resultar en una sobrecarga de rendimiento significativa.

Cuando cree una auditoría, estará en un estado deshabilitado.

Objetivos de auditoría

Las auditorías se pueden enviar a uno de los siguientes tres objetivos:

· Archivo binario. La salida de archivos proporciona el mayor rendimiento y es la opción más fácil de configurar.

· Registro de eventos de aplicaciones de Windows. Evite enviar demasiados detalles a este registro ya que a los administradores de red no les gustan las aplicaciones que escriben demasiado contenido en cualquiera de los registros de eventos. No utilice este objetivo para datos confidenciales porque cualquier usuario autenticado puede ver el registro.

· Registro de eventos de seguridad de Windows. Esta es la opción más segura para auditar datos, pero debe agregar la cuenta de servicio de SQL Server a la política Generar auditorías de seguridad antes de usarla. Debe revisar el contenido del objetivo que usa y archivar su contenido periódicamente.

Acciones y grupos de acción

Una vez que haya definido un servidor de auditoría, puede especificar los eventos que desea que la auditoría realice; Estos eventos pueden ser a nivel de servidor, de base de datos o de auditoría.

Los eventos de nivel de auditoría se activan cuando se agrega, elimina o cambia un objeto de auditoría. Los eventos de nivel de auditoría pueden rastrearse a nivel de servidor o de base de datos.

Puede agregar eventos para que una auditoría los rastree a nivel de eventos individuales, denominados acciones, como una instrucción SELECT en una tabla específica, o en grupos de acciones predefinidos que recopilan acciones relacionadas juntas, como SUCCESSFUL_LOGIN_GROUP, que incluye todas Las acciones conectadas a un inicio de sesión exitoso. Las acciones y los grupos de acciones están vinculados a una auditoría a través de una especificación de auditoría. Los grupos de acción predefinidos están disponibles a nivel de servidor, nivel de base de datos y nivel de auditoría. Las acciones solo están disponibles a nivel de base de datos.

Especificaciones de auditoría del servidor

Después de crear una auditoría, puede agregar especificaciones de auditoría del servidor para incluir uno o más grupos de acción en la auditoría. Cuando crea una especificación de auditoría del servidor, se deshabilita automáticamente, por lo que debe recordar habilitarla cuando esté listo para que comience. Una especificación de auditoría del servidor detalla las acciones a auditar. Las acciones a nivel de servidor se agrupan en grupos de acciones predefinidos, que incluyen:

Nombre del grupo de acción

Descripción

APPLICATION_ROLE_CHANGE_PASSWORD_GROUP

Este evento se genera cada vez que se cambia una contraseña para un rol de aplicación. Equivalente a la clase de evento Audit App Role Change Password .

AUDIT_CHANGE_GROUP

Este evento se genera cada vez que se crea, modifica o elimina una auditoría. Este evento se genera cada vez que se crea, modifica o elimina cualquier especificación de auditoría. Cualquier cambio en una auditoría se audita en esa auditoría. Equivalente a la clase de evento de auditoría de cambio de auditoría .

BACKUP_RESTORE_GROUP

Este evento se genera siempre que se emite un comando de copia de seguridad o restauración. Equivalente a la clase de evento Audit Backup and Restore .

BATCH_COMPLETED_GROUP

Este evento se genera cada vez que se completa la ejecución de cualquier texto por lotes, procedimiento almacenado u operación de administración de transacciones. Se genera después de que se completa el lote y auditará todo el lote o el texto del procedimiento almacenado, tal como lo envió el cliente, incluido el resultado. Agregado en SQL Server 2019.

BATCH_STARTED_GROUP

Este evento se genera cada vez que se inicia la ejecución de cualquier texto por lotes, procedimiento almacenado o operación de administración de transacciones. Se genera antes de la ejecución y auditará todo el lote o el texto del procedimiento almacenado, tal como lo envía el cliente. Agregado en SQL Server 2019.

BROKER_LOGIN_GROUP

Este evento se genera para informar mensajes de auditoría relacionados con la seguridad del transporte de Service Broker. Equivalente a la clase de evento de inicio de sesión del agente de auditoría .

DATABASE_CHANGE_GROUP

Este evento se genera cuando se crea, modifica o elimina una base de datos. Este evento se genera cada vez que se crea, modifica o elimina una base de datos. Equivalente a la clase de eventos Gestión de base de datos de auditoría .

DATABASE_LOGOUT_GROUP

Este evento se genera cuando un usuario de una base de datos contenida se desconecta de una base de datos.

DATABASE_MIRRORING_LOGIN_GROUP

Este evento se genera para informar de los mensajes de auditoría relacionados con la seguridad del transporte de la creación de reflejo de la base de datos. Equivalente a la clase de evento de inicio de sesión de creación de reflejo de la base de datos de auditoría .

DATABASE_OBJECT_ACCESS_GROUP

Este evento se genera cada vez que se accede a objetos de la base de datos como tipo de mensaje, ensamblado, contrato. Este evento se genera para cualquier acceso a cualquier base de datos. Nota: Esto podría generar grandes registros de auditoría.

Equivalente a la clase de evento Audit Database Object Access .

DATABASE_OBJECT_CHANGE_GROUP

Este evento se genera cuando se ejecuta una instrucción CREATE, ALTER o DROP en objetos de base de datos, como esquemas. Este evento se genera cada vez que se crea, modifica o elimina cualquier objeto de la base de datos. Nota: Esto podría dar lugar a una gran cantidad de registros de auditoría.

Equivalente a la clase de eventos Gestión de objetos de base de datos de auditoría .

DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP

Este evento se genera cuando cambia el propietario de los objetos dentro del alcance de la base de datos. Este evento se genera para cualquier cambio de propiedad del objeto en cualquier base de datos del servidor. Equivalente a la clase de evento Adquisición de propiedad de objeto de base de datos de auditoría .

DATABASE_OBJECT_PERMISSION_CHANGE_GROUP

Este evento se genera cuando se ha emitido un GRANT, REVOKE o DENY para objetos de base de datos, como ensamblados y esquemas. Este evento se genera para cualquier cambio de permiso de objeto para cualquier base de datos en el servidor. Equivalente a la clase de evento GDR de objeto de base de datos de auditoría .

DATABASE_OPERATION_GROUP

Este evento se genera cuando se producen operaciones en una base de datos, como un punto de control o una notificación de consulta de suscripción. Este evento se genera en cualquier operación de base de datos en cualquier base de datos. Equivalente a la clase de evento de operación de base de datos de auditoría .

DATABASE_OWNERSHIP_CHANGE_GROUP

Este evento se genera cuando usa la instrucción ALTER AUTHORIZATION para cambiar el propietario de una base de datos y se verifican los permisos necesarios para hacerlo. Este evento se genera para cualquier cambio de propiedad de la base de datos en cualquier base de datos del servidor. Equivalente a la clase de evento Audit Change Database Owner .

DATABASE_PERMISSION_CHANGE_GROUP

Este evento se genera cada vez que se emite un GRANT, REVOKE o DENY para un permiso de declaración por parte de cualquier principal en SQL Server (esto se aplica a eventos solo de base de datos, como otorgar permisos en una base de datos).

Este evento se genera para cualquier cambio de permiso de base de datos (GDR) para cualquier base de datos en el servidor. Equivalente a la clase de evento GDR de alcance de base de datos de auditoría .

DATABASE_PRINCIPAL_CHANGE_GROUP

Este evento se genera cuando los principales, como los usuarios, se crean, modifican o eliminan de una base de datos. Equivalente a la clase de evento de gestión principal de base de datos de auditoría . (También equivalente a Audit Add DB Principal Event Class, que se produce en los procedimientos almacenados sp_grantdbaccess, sp_revokedbaccess, sp_addPrincipal y sp_dropPrincipal obsoletos).

Este evento se genera cada vez que se agrega o elimina una función de base de datos mediante los procedimientos almacenados sp_addrole, sp_droprole . Este evento se genera cada vez que se crea, modifica o elimina cualquier entidad de seguridad de la base de datos. Equivalente a la clase de evento Audit Add Role .

DATABASE_PRINCIPAL_IMPERSONATION_GROUP

Este evento se genera cuando hay una operación de suplantación en el ámbito de la base de datos, como EXECUTE AS <principal> o SETPRINCIPAL. Este evento se genera para las suplantaciones realizadas en cualquier base de datos. Equivalente a la clase de evento Suplantación principal de la base de datos de auditoría .

DATABASE_ROLE_MEMBER_CHANGE_GROUP

Este evento se genera cada vez que se agrega o se elimina un inicio de sesión de un rol de base de datos. Esta clase de evento se genera para los procedimientos almacenados sp_addrolemember, sp_changegroup y sp_droprolemember. Este evento se genera en cualquier cambio de miembro de función de la base de datos en cualquier base de datos. Equivalente a la clase de evento Agregar miembro de auditoría a función de base de datos .

DBCC_GROUP

Este evento se genera cada vez que un principal emite cualquier comando DBCC. Equivalente a la clase de eventos Audit DBCC .

FAILED_DATABASE_AUTHENTICATION_GROUP

Indica que un principal intentó iniciar sesión en una base de datos contenida y falló. Los eventos de esta clase son provocados por nuevas conexiones o por conexiones que se reutilizan desde un grupo de conexiones. Equivalente a la clase de evento Audit Login Failed .

FAILED_LOGIN_GROUP

Indica que un principal intentó iniciar sesión en SQL Server y falló. Los eventos de esta clase son provocados por nuevas conexiones o por conexiones que se reutilizan desde un grupo de conexiones. Equivalente a la clase de evento Audit Login Failed . Esta auditoría no se aplica a Azure SQL Database.

FULLTEXT_GROUP

Indica que ocurrió un evento de texto completo. Equivalente a la clase de evento Audit Fulltext .

LOGIN_CHANGE_PASSWORD_GROUP

Este evento se genera cada vez que se cambia una contraseña de inicio de sesión mediante la instrucción ALTER LOGIN o el procedimiento almacenado sp_password. Equivalente a la clase de evento Auditoría de cambio de contraseña de inicio de sesión .

LOGOUT_GROUP

Indica que un principal ha cerrado sesión en SQL Server. Los eventos de esta clase son provocados por nuevas conexiones o por conexiones que se reutilizan desde un grupo de conexiones. Equivalente a la clase de evento Audit Logout .

SCHEMA_OBJECT_ACCESS_GROUP

Este evento se genera siempre que se ha utilizado un permiso de objeto en el esquema. Equivalente a la clase de evento Audit Schema Object Access .

SCHEMA_OBJECT_CHANGE_GROUP

Este evento se genera cuando se realiza una operación CREATE, ALTER o DROP en un esquema. Equivalente a la clase de evento de gestión de objetos de esquema de auditoría .

Este evento se genera en objetos de esquema. Equivalente a la clase de evento de permiso derivado de objeto de auditoría .

Este evento se genera cada vez que cambia el esquema de cualquier base de datos. Equivalente a la clase de evento de permiso de declaración de auditoría .

SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP

Este evento se genera cuando se verifican los permisos para cambiar el propietario del objeto de esquema (como una tabla, un procedimiento o una función). Esto ocurre cuando se usa la instrucción ALTER AUTHORIZATION para asignar un propietario a un objeto. Este evento se genera para cualquier cambio de propiedad de esquema para cualquier base de datos en el servidor. Equivalente a la clase de evento Adquisición de propiedad de objeto de esquema de auditoría .

SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP

Este evento se genera cada vez que se realiza una concesión, denegación o revocación contra un objeto de esquema. Equivalente a la clase de evento GDR de objeto de esquema de auditoría .

SERVER_OBJECT_CHANGE_GROUP

Este evento se genera para operaciones CREATE, ALTER o DROP en objetos de servidor. Equivalente a la clase de eventos de gestión de objetos del servidor de auditoría .

SERVER_OBJECT_OWNERSHIP_CHANGE_GROUP

Este evento se genera cuando se cambia el propietario de los objetos en el ámbito del servidor. Equivalente a la clase de evento Adquisición de propiedad de objetos del servidor de auditoría .

SERVER_OBJECT_PERMISSION_CHANGE_GROUP

Este evento se genera cada vez que cualquier principal en SQL Server emite un GRANT, REVOKE o DENY para un permiso de objeto de servidor. Equivalente a la clase de evento GDR del objeto del servidor de auditoría .

SERVER_OPERATION_GROUP

Este evento se genera cuando se utilizan operaciones de auditoría de seguridad, como la modificación de la configuración, los recursos, el acceso externo o la autorización. Equivalente a la clase de evento de operación del servidor de auditoría .

SERVER_PERMISSION_CHANGE_GROUP

Este evento se genera cuando se emite un GRANT, REVOKE o DENY para permisos en el ámbito del servidor. Equivalente a la clase de evento GDR del alcance del servidor de auditoría .

SERVER_PRINCIPAL_CHANGE_GROUP

Este evento se genera cuando se crean, modifican o eliminan los principales del servidor. Equivalente a la clase de eventos de gestión principal del servidor de auditoría .

Este evento se genera cuando un principal emite los procedimientos almacenados sp_defaultdb o sp_defaultlanguage o las instrucciones ALTER LOGIN. Equivalente a la clase de eventos Audit Addlogin .

Este evento se genera en los procedimientos almacenados sp_addlogin y sp_droplogin. También es equivalente a la clase de evento Audit Login Change Property .

Este evento se genera para los procedimientos almacenados sp_grantlogin o sp_revokelogin. Equivalente a la clase de eventos Audit Login GDR .

SERVER_PRINCIPAL_IMPERSONATION_GROUP

Este evento se genera cuando hay una suplantación dentro del ámbito del servidor, como EXECUTE AS <login>. Equivalente a la clase de evento de suplantación principal de Audit Server .

SERVER_ROLE_MEMBER_CHANGE_GROUP

Este evento se genera cada vez que se agrega o elimina un inicio de sesión de una función de servidor fija. Este evento se genera para los procedimientos almacenados sp_addsrvrolemember y sp_dropsrvrolemember. Equivalente a la clase de evento Audit Add Login to Server Role .

SERVER_STATE_CHANGE_GROUP

Este evento se genera cuando se modifica el estado del servicio de SQL Server. Equivalente a Audit Server Starts and Stops Event Class .

SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP

Indica que un principal ha iniciado sesión correctamente en una base de datos contenida.

SUCCESSFUL_LOGIN_GROUP

Indica que un principal ha iniciado sesión correctamente en SQL Server. Los eventos de esta clase son provocados por nuevas conexiones o por conexiones que se reutilizan desde un grupo de conexiones. Equivalente a la clase de evento Audit Login .

TRACE_CHANGE_GROUP

Este evento se genera para todas las declaraciones que comprueban el permiso ALTER TRACE. Equivalente a la clase de evento Alter Trace del servidor de auditoría .

TRANSACTION_GROUP

Este evento se genera para las operaciones BEGIN TRANSACTION, ROLLBACK TRANSACTION y COMMIT TRANSACTION, tanto para llamadas explícitas a esas instrucciones como para operaciones de transacción implícitas. Este evento también se genera para operaciones UNDO para extractos individuales provocados por la reversión de una transacción.

USER_CHANGE_PASSWORD_GROUP

Este evento se genera cada vez que se cambia la contraseña de un usuario de base de datos contenida mediante la instrucción ALTER USER.

USER_DEFINED_AUDIT_GROUP

Este grupo supervisa los eventos generados mediante sp_audit_write (Transact-SQL) . Normalmente, los desencadenadores o procedimientos almacenados incluyen llamadas a sp_audit_write para habilitar la auditoría de eventos importantes.

Eventos extendidos

La auditoría del SQL Server se basa en un motor de supervisión controlado por eventos llamado Eventos extendidos o en ingles “Extended Events” . Al igual que una traza del SQL Server Profiler, los eventos extendidos es una herramienta de monitoreo de actividad basada en eventos; sin embargo, intenta abordar algunas de las deficiencias en el diseño del SQ Server Profiler siguiendo un patrón de diseño suelto. Los eventos y sus objetivos no están estrechamente unidos; cualquier evento puede vincularse a cualquier objetivo. Esto significa que el procesamiento y el filtrado de datos pueden llevarse a cabo independientemente de la captura de datos; en la mayoría de los casos, esto tiene como resultado que los Eventos Extendidos tienen menor sobrecarga de rendimiento que una traza del SQL Server Profiler.

Los eventos extendidos permiten definir filtros sofisticados en los datos capturados. Además de los filtros de valor, los eventos se pueden filtrar por muestreo. Los datos se pueden agregar en el punto en que se capturan. Los eventos extendidos se pueden administrar a través de una interfaz gráfica en SQL Server Management Studio o mediante instrucciones Transact-SQL.

Los eventos extendidos se pueden integrar con el marco de seguimiento de eventos para Windows (ETW), lo que significa que la actividad de SQL Server se puede monitorear junto con otros componentes de Windows®.

Los eventos extendidos son importantes porque la auditoría del SQL Server se basa en la infraestructura de los eventos extendidos. El motor de eventos extendidos no está vinculado a tipos particulares de eventos: el motor está escrito de tal manera que puede procesar cualquier tipo de evento.

Estos querys son de diagnóstico y monitoreo en SQL Server, y cada uno cumple una función muy útil para revisar el estado, rendimiento y actividad del servidor.

1. Consultar la hora de inicio del servicio de SQL Server

SELECT sqlserver_start_time AS Inicio_SQL

FROM sys.dm_os_sys_info;

Qué hace:

• Consulta la vista de administración dinámica sys.dm_os_sys_info.

• El campo sqlserver_start_time indica la fecha y hora exacta en que se inició el servicio de SQL Server.
  Sirve para saber desde cuándo el servidor está en ejecución (último reinicio del motor, no del sistema operativo).

2. Ver el registro de errores (error log)

EXEC xp_readerrorlog;

Qué hace:

• Muestra el contenido del error log de SQL Server (el archivo principal donde el motor registra eventos del sistema).

• Este log guarda eventos como:

  • Arranque y apagado del servicio.

  • Crecimientos automáticos de archivos (autogrow).

  • Mensajes de backup, errores, y warnings.

Si ves una línea como:
SQL Server is starting at... → confirma un reinicio reciente del servicio.

3. Consultar el tiempo de actividad (uptime) del servidor

SELECT
    sqlserver_start_time AS [Inicio_SQLServer],

    SYSDATETIME() AS [HoraActual],

    DATEDIFF(HOUR, sqlserver_start_time, SYSDATETIME()) AS [Horas_Uptime],

    DATEDIFF(DAY, sqlserver_start_time, SYSDATETIME()) AS [Dias_Uptime]

FROM sys.dm_os_sys_info;

Qué hace:

• Toma la hora actual (SYSDATETIME()).

• La compara con la hora en que inició SQL Server (sqlserver_start_time).

• Calcula cuántas horas y días ha estado encendido el servicio (uptime).

Es una forma rápida de saber hace cuánto se reinició el motor

4. Ver número de operaciones (lectura/escritura) en cada tabla

SELECT

    OBJECT_NAME(ios.object_id) AS Tabla,

    ios.index_id,

    ios.leaf_insert_count + ios.leaf_update_count + ios.leaf_delete_count AS NumOperaciones,

    ios.leaf_insert_count,

    ios.leaf_update_count,

    ios.leaf_delete_count

FROM sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) ios

WHERE ios.object_id > 100

ORDER BY NumOperaciones DESC;

Qué hace:

• Usa la función dinámica sys.dm_db_index_operational_stats para medir la actividad de índices y tablas en la base actual.

• Muestra:

  • leaf_insert_count: cuántas inserciones.

  • leaf_update_count: cuántas actualizaciones.

  • leaf_delete_count: cuántas eliminaciones.

• Suma total (NumOperaciones) para ordenar las tablas más activas.

Ideal para detectar tablas con alta actividad transaccional (por ejemplo, que podrían causar crecimiento del log).

5. Revisar cantidad de registros e índices en las tablas

SELECT

    t.name AS Tabla,

    ISNULL(SUM(p.rows),0) AS NumeroRegistros,

    COUNT(i.index_id) AS CantidadIndices

FROM sys.tables AS t

LEFT JOIN sys.indexes AS i

    ON t.object_id = i.object_id AND i.type > 0

LEFT JOIN sys.partitions AS p

    ON t.object_id = p.object_id

    AND p.index_id IN (0,1)

GROUP BY t.name

ORDER BY NumeroRegistros DESC;

Qué hace:

• Lista todas las tablas del esquema actual (sys.tables).

• Calcula:

  • NumeroRegistros: total estimado de filas (desde sys.partitions).

  • CantidadIndices: cuántos índices (clustered + nonclustered) tiene cada tabla.

• Ordena de mayor a menor número de registros.

Útil para dimensionar tablas grandes o revisar si tienen índices suficientes o excesivos.

6. Consultar índices faltantes (missing indexes)

SELECT 

    DB_NAME(mid.database_id) AS BaseDatos,

    OBJECT_NAME(mid.object_id, mid.database_id) AS Tabla,

    migs.user_seeks AS VecesBuscado,

    migs.user_scans AS VecesEscaneado,

    migs.last_user_seek AS UltimaVezUsado,

    ROUND(migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans), 0) AS ImpactoEstimado,

    mid.equality_columns AS Columnas_Igualdad,

    mid.inequality_columns AS Columnas_Desigualdad,

    mid.included_columns AS Columnas_Incluidas

FROM sys.dm_db_missing_index_groups mig

INNER JOIN sys.dm_db_missing_index_group_stats migs

    ON migs.group_handle = mig.index_group_handle

INNER JOIN sys.dm_db_missing_index_details mid

    ON mig.index_handle = mid.index_handle

WHERE mid.database_id = DB_ID() -- base actual

ORDER BY ImpactoEstimado DESC;

Qué hace:

• Lee las vistas dinámicas de índices faltantes (sys.dm_db_missing_index_*).

• SQL Server analiza las consultas ejecutadas y sugiere índices que podrían mejorar el rendimiento.

• Muestra:

  • Tabla afectada.

  • Columnas que se usan en condiciones de igualdad (=) o desigualdad (>, <).

  • Columnas que podrían incluirse en el índice (INCLUDE).

  • Frecuencia de búsqueda y escaneo (user_seeks, user_scans).

  • ImpactoEstimado: cálculo estimado del beneficio del índice.

Ideal para detectar consultas que escanean tablas completas y podrían optimizarse con un índice nuevo.

Los datos desaparecen si se reinicia el servicio SQL Server (no son persistentes).

Base de datos en estado SUSPECT

En las bases de datos se pueden presentar problemas por falla de hardware como por ejemplo mal funcionamiento en los controladores de discos o los discos duros en sí, también las interrupciones en el suministro de energía eléctrica ocasionan problemas ya que cuando detenemos los servicios del SQL Server de manera correcta se realiza un proceso interno para dar de baja las bases de datos, identificando las transacciones completas e incompletas para dejarlas en un estado consistente,  este proceso generalmente no pasa cuando el servidor se apaga inesperadamente lo que puede corromper las páginas de datos mediante escrituras incompletas que derivan en páginas de datos corruptas.

Relacionado con los antivirus, otra causa común que provoca corrupción en las páginas de datos es cuando SQL Server deja de tener acceso exclusivo a los archivos de datos y otros procesos los utilizan, por ejemplo cuando no se configuran las excepciones en los antivirus para excluir los archivos de las bases de datos, los proceso de verificación de virus cuando revisan los archivos de las bases de datos  eventualmente los corrompen.

Cuando se alcanza el umbral de 1000 páginas corruptas la base de datos se coloca en modo SUSPECT como mecanismo de autoprotección.

Para resolver este problema podemos ejecutar las siguientes sentencias:

EXEC SP_RESETSTATUS  [Base de Datos];
ALTER DATABASE [Base de Datos] SET EMERGENCYDBCC CHECKDB ([Base de Datos])
ALTER DATABASE [Base de Datos] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CHECKDB ([Base de Datos], REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE [Base de Datos] SET MULTI_USER

Ahora cual es la explicación de cada instrucción que usamos en el código anterior.

EXEC SP_RESETSTATUS  [Base de Datos];

Desactiva la marca de sospechoso de una base de datos. Este procedimiento actualiza las columnas de modo y estado de la base de datos con nombre en sys.databases. Se debe consultar el registro de errores de SQL Server y resolver todos los problemas antes de ejecutar este procedimiento. Después de ejecutar sp_resetstatus, detenga y reinicie la instancia de SQL Server

ALTER DATABASE [Base de Datos] SET EMERGENCY

Durante un proceso de recuperación de desastres, el estado de emergencia proporciona flexibilidad para realizar varias operaciones en una base de datos corrupta / sospechosa. Cuando se coloca una base de datos en el estado de emergencia, realiza tres cambios importantes en la configuración de la base de datos:

Set Emergency marca la base de datos como READ_ONLY, deshabilita el registro y el acceso está limitado a miembros del rol fijo de servidor sysadmin. Solamente los miembros del rol fijo de servidor sysadmin pueden establecer una base de datos en el estado EMERGENCY.

Aunque un estado sospechoso no es un requisito previo para poner una base de datos en un estado de emergencia, este es probablemente el momento más útil en el que se desea utilizar el estado de emergencia. Cuando una base de datos está en el estado de emergencia, puede acceder a sus datos, por lo que puede exportarla a otra base de datos e incluso puede ejecutar un DBCC CHECKDB en la base de datos para corregir la corrupción.

DBCC CHECKDB ([Base de Datos])

Comprueba la integridad física y lógica de todos los objetos de la base de datos especificada mediante la realización de las siguientes operaciones:

• Se ejecuta DBCC CHECKALLOC en la base de datos.

• Se ejecuta DBCC CHECKTABLE en cada tabla y vista en la base de datos.

• Se ejecuta DBCC CHECKCATALOG en la base de datos.

• Valida el contenido de cada vista indizada de la base de datos.

• Valida la coherencia de nivel de vínculo entre los archivos y directorios del sistema de archivos y metadatos de tabla al almacenar varbinary (max) datos del sistema de archivos con FILESTREAM.

• Valida los datos de Service Broker en la base de datos.

Esto significa que los comandos DBCC CHECKALLOC, DBCC CHECKTABLE o DBCC CHECKCATALOG no tienen que ejecutarse por separado de DBCC CHECKDB.

ALTER DATABASE [Base de Datos] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

El modo de usuario único se suele utilizar para operaciones de mantenimiento y especifica que solo un usuario puede tener acceso a la base de datos cada vez. La opción de terminación WITH ROLLBACK IMMEDIATE se especifica en la primera instrucción ALTER DATABASE . Esto hará que todas las transacciones incompletas se reviertan y que el resto de las conexiones a la base de datos se desconecten de inmediato.

DBCC CHECKDB ([Base de Datos], REPAIR_ALLOW_DATA_LOSS)

Especifica que DBCC CHECKDB repare los errores que encuentre, estas reparaciones pueden ocasionar alguna pérdida de datos. Utilice las opciones REPAIR solo como último recurso y tenga en cuenta que la base de datos especificada debe estar en modo de usuario único.

ALTER DATABASE [Base de Datos] SET MULTI_USER

Devuelve el acceso a la base de datos para todos los usuarios.

Replicación de SQL Server

La replicación es un conjunto de tecnologías destinadas a la copia y distribución de datos y objetos de base de datos desde una base de datos a otra, para luego sincronizar ambas bases de datos y mantener su coherencia. Utilice la replicación para distribuir datos entre diferentes ubicaciones y entre usuarios remotos o móviles mediante redes locales y remotas.

Existen tres tipos de replicación la replicación de instanteanea, replicación de mezcla y replicación transaccional.

La replicación transaccional se usa normalmente en escenarios servidor a servidor que requieren un alto rendimiento, como por ejemplo, la mejora de la escalabilidad y la disponibilidad, el almacenamiento de datos y la creación de informes, la integración de datos procedentes de varios sitios, la integración de datos heterogéneos, y la descarga del procesamiento por lotes. La replicación de mezcla se ha diseñado principalmente para las aplicaciones móviles o de servidores distribuidos que pueden encontrarse con conflictos de datos. Los escenarios más frecuentes son: el intercambio de datos con usuarios móviles, las aplicaciones de punto de venta (POS) a consumidores, y la integración de datos de varios sitios. La replicación de instantáneas se usa para proporcionar el conjunto de datos inicial para la replicación transaccional y de mezcla; también se puede usar cuando está indicada una actualización completa de los datos. Con estos tres tipos de replicación, SQL Server proporciona un sistema eficaz y flexible para la sincronización de datos en toda la organización.

La trasvase de registros permite enviar automáticamente copias de seguridad del registro de transacciones desde una base de datos principal de una instancia del servidor principal a una o varias bases de datos secundarias en instancias independientes del servidor secundario . Las copias de seguridad del registro de transacciones se aplican a cada una de las bases de datos secundarias de forma individual. En una tercera instancia de servidor opcional, denominado servidor de supervisión, se registra el historial y el estado de las operaciones de copias de seguridad y restauración y, opcionalmente, se activan alertas si estas operaciones no se producen según lo programado. 

Ventajas

• Proporciona una solución de recuperación ante desastres para una sola base de datos principal y una o más bases de datos secundarias, cada una en una instancia independiente de SQL Server.

• Admite acceso limitado de solo lectura a bases de datos secundarias (durante el intervalo entre los trabajos de restauración).

• Permite un retraso especificado por el usuario entre el momento en que el servidor principal realiza una copia de seguridad del registro de la base de datos principal y el momento en que los servidores secundarios deben restaurar (aplicar) la copia de seguridad de registros. Un retraso más largo puede ser útil, por ejemplo, si los datos se cambian en la base de datos principal de manera accidental. Si se detecta rápidamente el cambio accidental, un retraso puede permitirle recuperar los datos aún sin modificar de una base de datos secundaria antes de que el cambio se refleje en ella.

Términos y definiciones

servidor principal
La instancia de SQL Server que es el servidor de producción.

base de datos principal
La base de datos del servidor principal de la que desea realizar una copia de seguridad en otro servidor. Toda la administración de la configuración de trasvase de registros mediante SQL Server Management Studio se realiza en la base de datos principal.

servidor secundario
La instancia de SQL Server donde desea mantener una copia en estado de espera activa de la base de datos principal.

base de datos secundaria
La copia en estado de espera activa de la base de datos principal. La base de datos secundaria debe encontrarse en el estado RECOVERING o STANDBY, que deja la base de datos disponible para acceso limitado de solo lectura.

servidor de supervisión
Una instancia opcional de SQL Server que realiza un seguimiento de todos los detalles del trasvase de registros, como:

• Cuándo se realizó por última vez una copia de seguridad del registro de transacciones de la base de datos principal.

• Cuándo se realizó por última vez la copia y restauración de los archivos de copia de seguridad en los servidores secundarios.

• Información acerca de las alertas de error de copia de seguridad.

trabajo de copia de seguridad
Un trabajo del Agente de SQL Server que lleva a cabo la operación de copia de seguridad, registra el historial en el servidor local y el servidor de supervisión, y elimina los archivos de copia de seguridad y la información de historial antiguos. La categoría de trabajo "Copia de seguridad de trasvase de registros" se crea en la instancia del servidor principal al habilitar el trasvase de registros.

trabajo de copia
Un trabajo del Agente de SQL Server que copia los archivos de copia de seguridad del servidor principal en un destino configurable del servidor secundario y registra el historial en el servidor secundario y el servidor de supervisión. La categoría de trabajo "Copia de seguridad de trasvase de registros" se crea en cada servidor secundario en una configuración de trasvase de registros al habilitar el trasvase de registros.

trabajo de restauración
Un trabajo del Agente de SQL Server que restaura los archivos de copia de seguridad copiados en las bases de datos secundarias.Registra el historial en el servidor local y el servidor de supervisión, y elimina los archivos de copia de seguridad y la información de historial antiguos. La categoría de trabajo "Restauración de trasvase de registros" se crea en la instancia del servidor secundario al habilitar el trasvase de registros en una base de datos.

trabajo de alerta
Un trabajo del Agente de SQL Server que activa alertas para las bases de datos principal y secundaria cuando una operación de copia de seguridad o restauración no se completa correctamente según un umbral especificado. La categoría de trabajo "Alerta de trasvase de registros" se crea en la instancia del servidor de supervisión al habilitar el trasvase de registros en una base de datos.

Información general de trasvase de registros

El trasvase de registros consta de tres operaciones:

1. Realizar una copia de seguridad del registro de transacciones en la instancia del servidor principal.

2. Copiar el archivo de registro de transacciones en la instancia del servidor secundario.

3. Restaurar la copia de seguridad de registros en la instancia del servidor secundario.

   El registro se puede trasvasar a varias instancias del servidor secundario En ese caso, las operaciones 2 y 3 se repiten para cada instancia del servidor secundario.

   En una configuración de trasvase de registros no se realiza automáticamente la conmutación por error del servidor principal al servidor secundario. Si la base de datos principal deja de estar disponible, cualquiera de las bases de datos secundarias se puede poner en línea manualmente.

   Puede utilizar una base de datos secundaria para la generación de informes.

   Además, puede configurar alertas para la configuración de trasvase de registros.

Una configuración de trasvase de registros típica

La siguiente ilustración muestra una configuración de trasvase de registros con la instancia del servidor principal, tres instancias del servidor secundario y una instancia del servidor de supervisión. La ilustración presenta los pasos realizados por los trabajos de copia de seguridad, copia y restauración del siguiente modo:

1. La instancia del servidor principal ejecuta el trabajo de copia de seguridad del registro de transacciones en la base de datos principal. A continuación, esta instancia de servidor coloca la copia de seguridad del registro en un archivo principal de copias de seguridad de registros que se envía a la carpeta de copia de seguridad. En esta ilustración, la carpeta de copia de seguridad es un directorio compartido: el recurso compartido de copia de seguridad.

2. Cada una de las tres instancias del servidor secundario ejecuta su propio trabajo de copia para copiar el archivo principal de copia de seguridad de registros a su propia carpeta de destino local.

3. Cada instancia del servidor secundario ejecuta su propio trabajo de restauración para restaurar la copia de seguridad del registro desde la carpeta de destino local a la base de datos secundaria local.

   Las instancias del servidor principal y secundario envían su propio historial y estado a la instancia del servidor de supervisión.

Reflejo de base de datos

Reflejo de base de datos proporciona una alta disponibilidad a nivel de base de datos mediante el mantenimiento de copias de una base de datos en un servidor principal y un servidor de base de datos.

La creación de reflejo de base de datos está desfasada y en SQL Server 2012 y debe por lo general no se utiliza en los nuevos despliegues. En su lugar, puede utilizar una alternativa, como el trasvase de registros o grupos de disponibilidad AlwaysOn. Reflejo de base de datos se discute aquí sólo por compatibilidad hacia atrás.

Reflejo de base de datos es conceptualmente similar al trasvase de registros, pero se diferencia en varios aspectos:

• Utiliza un tercer servidor, el nombre del servidor testigo, para que la conmutación por error automática. Si usted no requiere conmutación automática por error, se puede omitir el servidor testigo de la configuración y utilizar sólo la conmutación por error manual.

• Las transacciones pueden ser cometidos de forma sincrónica en el servidor principal y el servidor reflejado, lo que le permite mantener copias idénticas de una base de datos de los dos servidores. También puede configurar commit asíncronos, que le permite obtener una ventaja de rendimiento en el servidor principal a expensas de la consistencia de los datos.

• Los datos en el servidor reflejado no está disponible para el acceso de lectura. Sin embargo, puede crear una instantánea de base de datos en el servidor espejo para permitir el acceso de lectura a la base de datos.

• Un servidor principal puede tener sólo un servidor espejo. En el trasvase de registros, un servidor primario puede tener varios servidores secundarios.