Administración de Base de Datos Con SQL Server | Discount Coupon for Udemy Course
Aprende a crear respaldos y restaurarlos, tareas de mantenimiento, soporte y monitoreo de SQL Server | Discount Coupon for Udemy Course
- 9.5 hours hours of on-demand video
- Full lifetime access
- Access on mobile and TV
- Certificate of completion
- 6 additional resources
- Comprender la autenticación del SQL Server
- Asignar roles de servidor y base de datos
- Autorizar a los usuarios a acceder a los recursos
- Describir modelos de recuperación y estrategias de respaldo
- Copia de seguridad de las bases
- Restaurar bases de datos de SQL Server
- Automatizar la administración del SQL Server
- Administrar alertas y notificaciones
- Importar y exportar datos
- Auditar el SQL Server
- Monitoreo del SQL Con procedimientos extendidos
- Crear bases de datos reflejadas
- Replicación de Base de Datos
Acerca de este cursoEste curso está dirigido a profesionales de bases de datos que realizan tareas de instalación, mantenimiento y configuración. Otras responsabilidades son: configuración de sistemas de bases de datos, comprobación del funcionamiento eficaz de dichos sistemas y almacenamiento, copia de seguridad y protección de los datos contra el acceso no autorizado. Además, será de utilidad para las personas que desarrollan aplicaciones que entregan contenido desde las bases de datos de SQL Server.Perfil del usuario objetivoEste curso esta dirigido a las personas que administran y mantienen las bases de datos de SQL Server. Estas personas realizan la administración y el mantenimiento de la base de datos como su principal área de responsabilidad, o trabajan en entornos donde las bases de datos desempeñan un papel clave.También aplica a personas que desarrollan aplicaciones que almacenan sus datos en SQL Server, dándoles un panorama sobre las tareas de mantenimiento y soporte de la base de datos .Después de completar este curso, los estudiantes podrán:Autenticar y autorizar a los usuariosAsignar roles de servidor y base de datosUsar de auditoríaDescribir modelos de recuperación y estrategias de respaldoRealizar Copias de seguridad de las basesRestaurar bases de datos de SQL ServerAutomatiza la administración de basesAdministrar alertas y notificacionesAdministrar SQL Server usando PowerShellRastrear actividad en el SQL ServerImportar y exportar datosInstalación y Configuración del Reporting ServicesRealizar reflejo de base de datosCrear replicación de Base de DatosHacer Trasvase de RegistrosGrupos de Alta Disponibilidad.Who this course is for:Publico general apasionado por las bases de datosPersonas que administran y dan soporte a las bases de datos de SQL ServerDesarrolladores de Base de Datos
Course Content:
Sections are minimized for better readability, click the section title to view the course content
- Introducción a la administración de SQL Server04:44
- Instaladores a utilizar en el curso07:11
- Antes de Empezar-Creando un equipo virtual con HyperV16:37
- Creando un equipo virtual con VirtualBox (Alternativo a Hyper-V)14:25
- Asignando nombre, dirección ip y roles a los equipos virtuales12:33
- Instalando el Servicio de Active Directory Domain Service10:06
- Instalando SQL Server en un entorno empresarial29:04
- Instalación de las SQL Data Tools09:21
- Instalación de SQL Server Express17:31
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.
- Implementación de una Base de Datos con SQL Azure17:04
- Instalación de SQL Server en Linux14:30
- Instalación de SQL Server en Clúster de Conmutación por Error49:28
- Estructura de una base de datos en el SQL Server (Capsula)01:02
- Creación de una Base de Datos28:45
- Autenticación29:36
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 Vinculados20:53
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.
- Renombrar un Servidor06:23
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
gosp_dropserver 'old_name'
go
sp_addserver 'new_name', 'local'
goEl 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>;
gosp_addserver <new_name\instancename>, local;
go - Backups y Restore30:58
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
- Configuración de Database Mail10:08
SQL Server Database Mail se introdujo en SQL Server 2005, es un componente que puede enviar correos electrónicos utilizando el motor de base de datos del SQL Server. Al usar el Correo electrónico de base de datos, un administrador o un desarrollador pueden enviar resultados de consultas a un usuario final.
Los DBA pueden configurarlo para recibir alertas y notificaciones por correo electrónico. El Correo electrónico de base de datos usa SMTP (Protocolo simple de transferencia de correo) para entregar correos electrónicos a los destinatarios.
- SQL Server Agent21:00
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.
- Importar y Exportar datos e introducción a Integration Services24:58
- Usar el Asistente de Planes de Mantenimiento12:41
- Auditoría del SQL Server20:57
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 Extendidos16:18
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.
- Introducción a la administración con PowerShell16:58
- Reparar una base de datos cuando esta en modo Sospechosa06:21
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_USERAhora 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.
- Instalación y Configuración de Reporting Services20:39
- Habilitar conectividad hacia el SQL Server08:49
- Replicación de Base de Datos27:49
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.
- Trasvase de Registros13:21
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:
Realizar una copia de seguridad del registro de transacciones en la instancia del servidor principal.
Copiar el archivo de registro de transacciones en la instancia del servidor secundario.
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:
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.
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.
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.
- Espejo de Base de Datos11:25
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.
- Grupos de Alta Disponibilidad26:48
JOIN OUR WHATSAPP GROUP TO GET LATEST COUPON AS SOON AS UPDATED
JOIN WHATSAPPJOIN OUR TELEGRAM CHANNEL TO GET LATEST COUPON
JOIN TELEGRAMJOIN OUR FACEBOOK GROUP TO GET LATEST COUPON
JOIN FACEBOOKFree Online Tools And Converters for your use
URL Encoder
Input a string of text or a URL and encode the entered string
Try itURL Decoder
Input an encoded string of text or a URL and decode the entered string
Try itColor Contrast Checker (WCAG)
Calculate the color contrast ration for your website (WCAG)
Try itXML Formatter
Paste or upload an XML and have it formatted to a beautiful XML format
Try itURL Slug Generator
Convert any title or sentence into a variety of slugs for your pages URL
Try itE-Signature
Draw an e-signature or type a signature for your online signature
Try it