manual sqlserver2005 mantenimiento

Mantenimiento

- 2 -

MÓDULO 1: INSTALACIÓN Y CONFIGURACIÓN DE SQL SERVER 2005 - 10 -

1- Preparando la instalación - 11 - Ediciones de SQLServer 2005 - 11 - Requisitos de Hardware para SQL Server 2005 (32 bits) - 12 - Requisitos de Hardware para SQL Server 2005 (64 bits) - 13 - Requisitos de espacio en disco duro (32 y 64 bits) - 13 - Requisitos del sistema operativo (32 bits) - 14 - Requisitos del sistema operativo (64 bits) - 16 - Requerimientos adicionales de software - 18 - Requerimientos para la Edición Móbile - 18 - Instancias de SQL Server 2005: - 18 - Instancia por defecto - 18 - Instancias con nombre - 18 - Opciones de Licenciamiento para SQL Server 2005 - 19 - Consideraciones sobre seguridad para Servicios SQL Server - 19 - Usar una cuenta de usuario de dominio - 19 - Usar la cuenta de servicio local - 19 - Usar la cuenta de servicio de red - 19 - Intercalación (Collation) - 20 - Actualizar a SQL Server 2005 - 21 - Utilizando el Asesor de actualizaciones (Upgrade Adviser) para preparar las actualizaciones - 21 - Cómo funciona el Asesor de actualizaciones - 21 - Análisis del Asesor de actualizaciones - 22 - Compatibilidad de la base de Datos - 22 -

2- Instalación - 23 - Comprobador de Configuración del Sistema (System configuration checker) - 23 - Opciones para la instalación de Componentes: - 23 - Instalación Desatendida - 25 - Creación del archivo .ini - 25 - Comenzando una instalación desatendida - 25 -

3- Manejo de la instalación - 26 - Configuración de Superficie (Surface Area Configuration) - 26 - Manejador de Configuración (Configuration Manager) - 28 - Servicios SQL Server - 29 - Configuración del Servidor de Red - 29 - Configuración del Cliente de Red - 29 - SQL Server Management Studio - 29 - Nuevas funciones de las Secuencias de Comandos - 30 - Características del Explorador de objetos - 31 -

MÓDULO 2: RECUPERACIÓN DE DESASTRE - 32 -

1- Planeamiento - 33 - Planear la estrategia de copias de seguridad y restauración - 33 - Elegir el tipo de medio para la copia de seguridad - 33 - Administrar medios de copia de seguridad - 33 - Ejecutar una secuencia de comandos con la funcionalidad básica - 34 - Garantizar la disposición para afrontar desastres - 34 - Revisar y reducir los posibles errores del usuario - 34 - Modelos de recuperación - 35 - Recuperación simple - 37 - Recuperación completa - 37 -

- 3 -

Recomendaciones sobre modelos de recuperación para bases de datos del sistema - 38 -

2- Copias de Seguridad - 39 - Tipos de Copias de Seguridad - 39 - Copias de seguridad completas de bases de datos - 39 - Copia de seguridad en el modelo de recuperación completa - 39 - Minimizar el riesgo de pérdida de trabajo - 40 - Copias de Seguridad del Registro de Transacciones - 41 - La cadena de registros - 42 - Administración de registros de transacciones y modelos de recuperación - 42 - Truncamiento del registro con el modelo de recuperación completa y por medio de registros de operaciones masivas - 42 - Cómo funciona el truncamiento del registro - 43 - Cómo funcionan las copias de seguridad diferenciales - 44 - Copias de seguridad diferenciales de archivos - 45 - Copia de seguridad diferencial de grupos de archivos (filegroups) de sólo lectura en bases de datos de lectura y escritura - 46 - Copia de seguridad de un grupo de archivos (filegroups) principalmente de sólo lectura - 46 - Copias de seguridad diferenciales parciales - 47 - Crear una copia de seguridad diferencial de archivos - 47 -

3- Restauración de Bases de Datos de Usuario - 49 - Descripción de cómo funcionan la restauración y la recuperación de copias de seguridad en SQL Server - 49 - Conjunto de puestas al día - 49 - Secuencias de restauración - 49 - Fases de la restauración - 49 - Fase de copia de datos - 50 - Fase de rehacer (puesta al día) - 50 - Fase de deshacer (revertir) y recuperación - 51 - Opciones RECOVERY y NORECOVERY - 51 - Restaurar una base de datos cuando SQL Server no está conectado - 52 - Escenarios de restauración - 52 - Modelos de recuperación y operaciones de restauración admitidas - 53 - Restaurar una copia de seguridad completa de la base de datos - 54 - Restauración de base de datos completa (modelo de recuperación simple) - 54 - Restauración por etapas de la base de datos (modelo de recuperación completa) - 55 - Restauración por etapas para algunos grupos de archivos (modelo de recuperación simple) - 56 - Restauración por etapas para algunos grupos de archivos (modelo de recuperación completa) - 57 - Restauración con conexión de un archivo de sólo lectura (modelo de recuperación simple) - 58 - Aplicar copias de seguridad del registro de transacciones - 58 - Registros de transacciones y recuperación - 58 - Cómo restaurar a un momento dado (SQL Server Management Studio) - 59 - Restauración online - 61 - Copias de seguridad de registros para una restauración en línea - 62 - Desconectar una base de datos o un archivo - 62 -

MÓDULO 3: MANEJO DE SEGURIDAD - 64 -

1- Seguridad de Base - 65 - Proteger SQL Server - 65 - Protocolos de Red y Extremos TDS - 65 - Habilitar Protocolos de Servidor después de la Instalación - 65 - Definición de los Extremos TDS - 66 - Restringir el Acceso a la Red - 66 - Seguridad del Sistema Operativo - 67 -

2- Introducción a la Seguridad de SQL Server - 68 -

- 4 -

Entidades de Seguridad y Seguridad de objetos de base de datos - 68 - Entidades de Seguridad (Principals) - 68 - Inicio de Sesión sa de SQL Server - 68 - INFORMATION_SCHEMA y sys - 68 - Asegurables - 68 - Objetos - 69 - Funciones (Roles) de Nivel de Servidor (Server Fixed Roles) - 69 - La Función public - 70 - Funciones (Roles) en el Nivel de Base de Datos - 70 - Jerarquía de Permisos - 71 - Trabajar con Permisos - 72 - Permisos a Nivel de Servidor - 72 - Conceder Permisos - 73 - Permisos a Nivel de Base de Datos - 74 - Permisos a Nivel de Esquema - 77 - Cifrado y Certificados - 78 - Jerarquía de Cifrado - 78 - Llave Maestra de Servicio (Service Master Key) - 79 - Llave Maestra de Base de Datos (Database Master Key) - 79 - Certificados - 80 - Claves Asimétricas - 81 - Claves Simétricas - 82 -

3- Implementación de Seguridad en SQL Server 2005 - 83 - Seleccionar un Modo de Autenticación - 83 - Configurar el Modo de Autenticación - 83 - Conectar a través de la Autenticación de Windows - 84 - Conectar a través de la Autenticación de SQL Server - 84 - Ventajas de la Autenticación de SQL Server - 85 - Desventajas de la Autenticación de SQL Server - 85 - Cuándo utilizar el Modo de Autenticación de Windows - 85 - Ventajas del la Autenticación Windows - 85 - Cuándo utilizar el Modo Mixto - 85 - Directiva de Contraseñas - 85 - Aplicación de las Directivas de Contraseñas - 86 - Contraseñas Seguras - 87 - Inicios de Sesión en SQL Server (login) - 87 - Manejo de Inicios de Sesión - 87 - Modificación de Inicios de Sesión - 89 - Eliminación de Inicios de Sesión - 89 - Asignación de una cuenta de inicio de sesión a una función fija de servidor - 90 - Usuarios de SQL Server - 90 - Cómo crear un usuario de base de datos - 90 - Usuarios especiales de SQL Server - 92 - Delegación - 92 - Requerimientos para Delegación - 92 - Configurando Active Directory para Delegación - 93 - Configurando SQL Server para Delegación - 93 - Credenciales - 93 -

MÓDULO 4: MONITOREO DE SQL SERVER - 94 -

1- Monitorear la Actividad en Curso - 95 - Determinar la actividad de los usuarios - 95 - El Monitor de actividad (SQL Server Management Studio) - 95 - Monitor de actividad de trabajo - 96 - Para Ver la Actividad de Trabajo (SQL Server Management Studio) - 97 - Sesiones del Agente SQL Server - 98 - Funciones y Vistas de Administración Dinámica - 98 -

- 5 -

Vistas de Catálogo (Transact-SQL) - 99 - Consulta de una Vista de Administración Dinámica - 100 -

2- Monitor de Sistemas (Windows) - 101 - Usar Objetos de SQL Server - 101 - Consideraciones de Monitoreo de SQL Server - 103 - Monitorear la Actividad del Disco - 104 - Monitorear la E/S del Disco y Detectar la Paginación Excesiva - 104 - Aislar la Actividad del Disco creada por SQL Server - 105 - Monitorear el Uso de la CPU - 105 - Monitorear el Uso de la Memoria - 106 - Aislar la Memoria que utiliza SQL Server - 107 -

3- Analizador de SQL Server (SQL Server Profiler) - 108 - Introducción - 108 - Terminología del Analizador de SQL Server - 108 - Usar el Analizador de SQL Server - 109 - Plantillas del Analizador de SQL Server - 110 - Plantillas Predefinidas - 110 - Plantilla Predeterminada - 111 - Guardar Trazas y Plantillas de Traza - 112 - Guardar Trazas - 112 - Importar y Exportar Plantillas - 112 - Analizar el Rendimiento con Plantillas - 112 -

4- Desencadenadores DLL (DLL Triggers) - 114 - Definición - 114 - Usar Eventos de DDL con Desencadenadores DDL - 114 - Usar la Función EVENTDATA - 116 -

5- Notificaciones de Eventos - 119 - Introducción - 119 - Conceptos Básicos de las Notificaciones de Eventos - 119 - Descripción de Notificaciones de Eventos frente a Desencadenadores - 120 - Notificaciones de Eventos frente a Traza de SQL - 120 -

MÓDULO 5: AUTOMATIZANDO TAREAS ADMINISTRATIVAS - 123 -

1- Automatizar las tareas administrativas (Agente SQL Server) - 124 - Herramientas para Automatizar la Administración - 124 - Planes de Mantenimiento - 124 - Iniciar el Asistente para Planes de Mantenimiento (SQL Server Management Studio) - 126 - Editar y crear Planes de Mantenimiento Manualmente - 127 - Agente SQL Server (SQL Server Agent) - 127 - Componentes - 128 -

2- Configurar el Agente SQL Server - 130 - Establecer los Permisos Necesarios - 130 - Correo del Agente SQL Server - 131 - Correo Electrónico de Base de Datos con el Agente SQL Server - 132 - Cómo usar SQL Mail - 133 -

3- Trabajos y Operadores - 135 - Trabajos - 135 - Organizar trabajos - 135 - Propiedad de trabajos - 135 - Crear un trabajo - 135 -

- 6 -

Crear pasos de trabajo - 136 - Registros de Pasos de Trabajo - 137 - Programas Ejecutables y Comandos del Sistema Operativo como Pasos de Trabajo - 137 - Pasos de Trabajo Transact-SQL - 138 - Pasos de Trabajo de Secuencias de Comandos ActiveX - 138 - Controlar varios Pasos del Trabajo - 138 - Programar la Ejecución de un Trabajo - 139 - Operadores - 141 - Proporcionar Información de Contacto - 141 - Requisitos para Notificar a un Operador - 142 - Designar un Operador a Prueba de Errores - 142 - Supervisar la Actividad de Trabajo - 144 - Sesiones del Agente SQL Server - 144 - Monitor de Actividad de Trabajo - 144 -

4- Alertas - 146 - Alertas - 146 - Eventos - 146 - Seleccionar una Condición de Rendimiento - 147 - Seleccionar un Evento de WMI - 148 - Alertar a Operadores - 148 -

5- Manejo de Servidores Múltiples - 149 - Administración multiservidor - 149 - Consideraciones para Entornos Multiservidor - 149 - Procesar Trabajos Multiservidor - 149 -

6– Manejando la Seguridad del Agente SQL Server - 151 - Conceder Acceso al Agente SQL Server - 151 - Funciones Fijas de Base de Datos del Agente SQL Server - 151 - Permisos de las Funciones Fijas de Base de Datos del Agente SQL Server - 151 - Permisos de SQLAgentUserRole - 152 - Permisos de SQLAgentReaderRole - 153 - Permisos de SQLAgentOperatorRole - 154 - Asignar a los Usuarios varias Funciones - 156 - Crear Cuentas de Proxy del Agente SQL Server - 156 -

MÓDULO 6: IMPLEMENTANDO REPLICACIÓN - 157 -

1- Introducción a Réplica de SQL Server - 158 - Información General sobre los Tipos de Réplica - 158 - Réplica Transaccional - 158 - Réplica de Mezcla - 159 - Réplica de Instantáneas - 159 - Información General del Modelo de Publicación de Réplica - 160 - Publicador - 161 - Distribuidor - 161 - Suscriptores - 161 - Artículo - 161 - Publicación - 161 - Suscripción - 162 -

2- Implementar replicación - 163 - Implementación - 163 - Configurar la Réplica y Publicar Datos - 163 - Filtrar Datos Publicados - 163 - La Réplica ofrece cuatro Tipos de Filtros: - 164 - Procedimientos Almacenados de Réplica - 166 -

- 7 -

Crear e Inicializar Suscripciones - 167 - Suscriptores que no son de SQL Server - 168 - Crear Suscripciones - 168 - Sincronizar Datos - 168 - Asistentes para Réplica - 168 - Asistente para Nueva Publicación - 168 - Para Crear Publicaciones y Definir Artículos - 169 - Asistente para Nuevas Suscripciones - 171 - Asistente para Configurar la Distribución - 174 - Asistente para deshabilitar la publicación y distribución - 175 - Asistente de configuración de la topología punto a punto - 175 - Asistente para la sincronización Web - 176 -

3- Monitor de Réplica - 177 - Supervisión de la Réplica con el Monitor de Réplica - 177 - La interfaz del Monitor de réplica - 177 - Ver información de toda la topología - 178 - Ver información y realizar tareas relacionadas con publicadores - 178 - Ver información y realizar tareas relacionadas con suscripciones - 179 - Ver información y realizar tareas relacionadas con perfiles de agente - 180 - Supervisar estado de la suscripción y la publicación en el Monitor de réplica - 180 - Supervisar agentes de réplica - 181 - Para supervisar el Agente de instantáneas y el Agente de registro del LOG - 181 - Para supervisar el Agente de distribución y el Agente de mezcla (en el publicador) - 181 - Para supervisar el Agente de distribución y el Agente de mezcla (en el suscriptor) - 182 -

4- Configurar Replicación en algunos Escenarios Comunes - 183 - Replicar Datos en un Entorno de Servidor a Servidor - 183 - Replicar Datos entre un Servidor y los Clientes - 183 - Réplica Transaccional de Punto a Punto (Peer to Peer) - 183 - Topologías de Punto a Punto - 184 - Topología en la que participan dos bases de datos: - 184 - Topología en la que participan tres o más bases de datos - 185 - Implementar la Réplica por Internet - 187 - Configurar la Sincronización Web - 188 -

MÓDULO 7: MANTENIMIENTO DE ALTA DISPONIBILIDAD - 189 -

1- Introducción a Alta Disponibilidad - 190 - Factores que afectan la Disponibilidad: - 190 - Configurar una Alta Disponibilidad - 190 - Clúster de conmutación por error - 190 - Creación de reflejo de la base de datos - 191 - Trasvase de registros - 191 - Replicación - 192 - Seleccionar una Solución de Alta Disponibilidad - 192 -

2- Implementación de Server Clustering - 194 - Que es un Clúster? - 194 - Consideraciones antes de Instalar un Clúster de Conmutación por Error - 194 - Lista de comprobación previa a la instalación - 195 - Comprobar la Solución de Hardware - 195 - Comprobar la Configuración del Sistema Operativo - 196 - Configurar el Servicio de Cluster Server de Microsoft - 196 - Instalar el Coordinador de Transacciones Distribuidas de Microsoft - 197 - Otras Consideraciones de Software - 197 - Consideraciones Relativas a la Red - 198 - Otras Consideraciones - 198 -

- 8 -

Instalar un Clúster de Conmutación por Error - 199 - Elementos de una instancia de clúster de conmutación por error - 199 - Asignar nombre a una Instancia de Clúster de Conmutación por Error - 200 -

3- Implementando Reflejo de Base de Datos - 201 - Generalidades de la Creación de Reflejo de la Base de Datos - 201 - Ventajas de la creación de reflejo de la base de datos - 201 - Funcionamiento de la creación de reflejo de la base de datos - 201 - Modos de funcionamiento - 202 - Seguridad de las Transacciones y Modos de Funcionamiento - 203 - Extremo de Creación de Reflejo de Base de Datos - 204 - Cómo Crear un Extremo de Reflejo para la Autenticación de Windows - 204 - Para Crear un Extremo de Reflejo utilizando la Autenticación de Windows - 205 - Dirección de Red de Servidor - 206 - Sesiones de Creación de Reflejo de la Base de Datos - 207 - Sesiones Simultáneas - 208 - Requisitos Previos para una Sesión de Creación de Reflejo de la Base de Datos - 209 - Conmutación de Funciones durante una Sesión de Creación de Reflejo de la Base de Datos - 210 - Conmutación por Error Manual - 210 - Conmutación por Error Automática - 212 - Forzar Servicio (con posible pérdida de datos) - 212 -

4- Trasvase de Registros (Log Shipping) - 212 - Definición - 212 - Operaciones del Trasvase de Registros - 213 - Configurar el Trasvase de Registros - 213 - Cambiar las funciones entre el servidor primario y secundario - 217 -

- 10 -

Módulo 1

Instalación y Configuración de SQL

Server 2005

- 11 -

1- Preparando la instalación

Ediciones de SQLServer 2005 Los requisitos de instalación pueden variar mucho, dependiendo de las necesidades de las aplicaciones. Las diferentes ediciones de SQL Server 2005 satisfacen los requisitos de rendimiento, tiempo de ejecución y precio únicos de organizaciones y personas. Los diversos componentes de SQL Server 2005 que instale dependerá de las necesidades de las organizaciones y de las personas. Puede usar todas las ediciones de SQL Server 2005 en entornos de producción excepto para SQL Server 2005 Developer Edition y SQL Server 2005 Evaluation Edition. A continuación se describen las ediciones de SQL Server 2005:

SQL Server 2005 Enterprise Edition (32 bits y 64 bits): Enterprise Edition es

ampliable a los niveles de rendimiento necesarios para admitir el procesamiento de transacciones en línea (OLTP) de las empresas más grandes, análisis de datos de alta complejidad, sistemas de almacenamiento de datos y sitios web. Las completas capacidades de análisis y Business Intelligence, y sus características de alta disponibilidad como, por ejemplo, el clúster de conmutación por error, permiten controlar las cargas de trabajo empresarial de mayor importancia. Enterprise Edition es la edición más completa de SQL Server y es idónea para las organizaciones más grandes y para los requisitos más complejos.

SQL Server 2005 Standard Edition (32 bits y 64 bits): SQL Server 2005 Standard

Edition es la plataforma de análisis y administración de datos para organizaciones pequeñas y medianas. Incluye la funcionalidad básica necesaria para soluciones de línea de negocio, almacenamiento de datos y comercio electrónico. Las características de alta disponibilidad y de Business Intelligence integradas de Standard Edition proporcionan a las organizaciones las capacidades básicas que necesitan para realizar sus operaciones. SQL Server 2005 Standard Edition es idóneo para aquélla organización pequeña o mediana que necesite una plataforma completa de análisis y administración de datos.

SQL Server 2005 Workgroup Edition (sólo 32 bits): SQL Server 2005 Workgroup

Edition es la solución de administración de datos para pequeñas organizaciones que necesitan una base de datos sin límites de tamaño o número de usuarios. SQL Server 2005 Workgroup Edition se puede utilizar como servidor Web cliente o para operaciones de sucursales o departamentos. Incluye las características principales de base de datos de la línea de productos de SQL Server y es fácilmente actualizable a SQL Server 2005 Standard Edition o SQL Server 2005 Enterprise Edition. SQL Server 2005 Workgroup Edition es una base de datos idónea para comenzar que resulta confiable, sólida y fácil de administrar.

SQL Server 2005 Developer Edition (32 bits y 64 bits): SQL Server 2005 Developer Edition permite a los programadores crear cualquier tipo de aplicación sobre SQL Server. Incluye toda la funcionalidad de SQL Server 2005 Enterprise Edition, pero su licencia permite utilizarlo como sistema de desarrollo y prueba, no como un servidor de producción. SQL Server 2005 Developer Edition es una opción ideal para fabricantes independientes de software (ISV), asesores, integradores de sistemas, proveedores de soluciones y programadores corporativos que crean y prueban aplicaciones. Puede actualizar SQL Server 2005 Developer Edition para utilizarlo en producción.

SQL Server 2005 Express Edition (sólo 32 bits): La plataforma de bases de datos de

SQL Server Express se basa en SQL Server 2005. También sustituye a Microsoft Desktop Engine (MSDE). Gracias a su integración con Microsoft Visual Studio 2005, SQL Server Express facilita el desarrollo de aplicaciones controladas por datos que

- 12 -

tienen una gran capacidad, ofrecen un almacenamiento seguro y se implementan con rapidez. SQL Server Express es gratuito y puede redistribuirse (mediante un acuerdo); funciona como la base de datos de cliente, además de como una base de datos de servidor básica. SQL Server Express es la opción idónea para fabricantes independientes de software (ISV), usuarios de servidor, programadores no profesionales, programadores de aplicaciones Web, alojamientos de sitios Web y aficionados a crear aplicaciones cliente. Si necesita características de base de datos más avanzadas, SQL Server Express se puede actualizar sin problemas a versiones más sofisticadas de SQL Server. SQL Server Express también ofrece componentes adicionales que están disponibles como parte de SQL Server 2005 Express Edition with Advanced Services (SQL Server Express). Además de las características de SQL Server Express, SQL Server Express with Advanced Services ofrece lo siguiente: o SQL Server Management Studio Express (SSMSE), un subconjunto de SQL Server

Management Studio. o Compatibilidad con catálogos de texto. o Compatibilidad para ver informes mediante Reporting Services.

SQL Server 2005 Compact Edition (sólo 32 bits): Microsoft SQL Server 2005

Compact Edition es la base de datos compacta que amplía la funcionalidad de administración de datos corporativos a dispositivos. Microsoft SQL Server 2005 Compact Edition puede replicar datos con SQL Server 2005 y SQL Server 2000, lo que permite a los usuarios mantener un almacén de datos móvil que se sincroniza con la base de datos primaria. Microsoft SQL Server 2005 Compact Edition es la única edición de SQL Server que proporciona funcionalidad de administración de bases de datos relacionales para dispositivos inteligentes.

Requisitos de Hardware para SQL Server 2005 (32 bits) Cuando se planifica la instalación de SQL Server 2005 usted debe asegurarse de que la computadora en la que realizará la instalación cumple con los requerimientos mínimos y es adecuada para sus necesidades actuales y futuras. El hecho de no alcanzar los requerimientos mínimos puede ocasionar fallas en la instalación de algunos o de todos los componentes. En la tabla siguiente se muestran los requisitos de hardware para instalar y ejecutar SQL Server 2005 en la plataforma de 32 bits:

SQL Server 2005 (32 bits) Tipo de procesador Velocidad de procesador Memoria (RAM)

SQL Server 2005 Enterprise Edition

SQL Server 2005 Developer Edition

SQL Server 2005 Standard Edition

Procesador compatible con Pentium III o superior

Mínimo: 600 MHz

Recomendado: 1 GHz o más

Mínimo: 512 MB

Recomendado: 1 GB o más

Máximo: máximo del sistema operativo máximo

SQL Server 2005 Workgroup Edition


Mínimo: 600 MHz


Mínimo: 512 MB



SQL Server 2005 Express Procesador compatible Mínimo: 500 MHz Mínimo: 192 MB

- 13 -

Edition con Pentium III o superior Recomendado: 1 GHz o más

Recomendado: 512 MB o más


SQL Server 2005 Express Edition with Advanced Services


Mínimo: 600 MHz


Mínimo: 512 MB


Máximo: máximo del sistema operativo

Requisitos de Hardware para SQL Server 2005 (64 bits) En la siguiente tabla se muestran los requisitos de hardware para instalar y ejecutar SQL Server 2005 en la plataforma de 64 bits.

SQL Server 2005 (64 bits) Tipo de procesador

Velocidad de procesador Memoria (RAM)

SQL Server 2005 Enterprise Edition

SQL Server 2005 Developer Edition

SQL Server 2005 Standard Edition

IA64 mínimo: procesador Itanium o superior

x64 mínimo: AMD Opteron, AMD Athlon 64, Intel Xenon compatible con Intel EM64T, Intel Pentium IV compatible con EM64T

IA64 mínimo: 1 GHz

IA64 recomendado: 1 GHz o más

x64 mínimo: 1 GHz

x64 recomendado: 1 GHz o más

IA64 mínimo: 512 MB

IA64 recomendado: 1 GB o más

IA64 máximo: 32 TB

Máximo del sistema operativo

Mínimo: 512 MB

x64 recomendado: 1 GB o más

x64 máximo: máximo del sistema operativo

Requisitos de espacio en disco duro (32 y 64 bits) Los requisitos de disco duro actuales dependen de la configuración del sistema y las aplicaciones y características que haya decidido instalar. En la siguiente tabla se muestran los requisitos de espacio en disco de los componentes de SQL Server 2005.

Característica Requisito de espacio en disco

Database Engine (Motor de base de datos) y archivos de datos, Réplica y Búsqueda de texto

280 MB

Analysis Services y archivos de datos 90 MB

- 14 -

Reporting Services y Administrador de informes 120 MB

Componentes del motor de Notification Services, componentes de cliente y componentes de reglas

50 MB

Integration Services 120 MB

Componentes de cliente 850 MB

Libros en pantalla de SQL Server y Libros en pantalla de SQL Server Compact Edition 240 MB

Ejemplos y bases de datos de ejemplo. Tenga en cuenta que, de forma predeterminada, los ejemplos y las bases de datos de ejemplo no se instalan.

410 MB

Requisitos del sistema operativo (32 bits) En la siguiente tabla se muestran los sistemas operativos que ejecutan el software de servidor para cada versión de 32 bits de SQL Server 2005.

Enterprise Edition

1

Developer Edition

Standard Edition

Workgroup Edition

Express Edition y Express with Advanced Services

Evaluation Edition

Windows 2000 No No No No No No

SP4 de Windows 2000 Professional Edition

No Sí Sí Sí Sí Sí

SP4 de Windows 2000 Server

Sí Sí Sí Sí Sí Sí

SP4 de Windows 2000 Advanced Server


SP4 de Windows 2000 Datacenter Edition


Windows XP Embedded SP2 Feature pack 2007

No No No No Sí No

Windows Embedded for Point of Service

No No No No Sí No

SP2 de Windows XP Home Edition

No Sí No No Sí No

- 15 -

SP2 de Windows XP Professional Edition


SP2 de Windows XP Media Edition


SP2 de Windows XP Tablet Edition


SP1 de Windows Server 2003 Server


SP1 de Windows Server 2003 Enterprise Edition


SP1 de Windows Server 2003 Datacenter Edition


SP1 de Windows Server 2003 Web Edition

No No No No Sí No

SP1 de Windows Small Business Server 2003 Standard Edition


SP1 de Windows Small Business Server 2003 Premium Edition


Windows Vista Starter Edition

No No No No No No

Windows Vista Home Basic Edition

No Sí7 No No Sí Sí

Windows Vista Home Premium Edition

No Sí No No Sí Sí

Windows Vista Ultimate Edition

No Sí Sí Sí7 Sí Sí

Windows Vista Business Edition

No Sí Sí Sí7 Sí Sí

Windows Vista Enterprise Edition


SP1 de Windows Server 2003 64-Bit Itanium Datacenter

No No No No No No

- 16 -

Edition

SP1 de Windows Server 2003 64-Bit Itanium Enterprise Edition

No No No No No No

SP1 de Windows Server 2003 64-Bit x64 Standard Edition

WOW64 WOW64 WOW64 WOW64 WOW64 WOW64

SP1 de Windows Server 2003 64-Bit x64 Datacenter Edition

6


SP1 de Windows Server 2003 64-Bit x64 Enterprise Edition

6


Windows XP x64 Professional 2003

No WOW64 WOW64 WOW64 WOW64 No

Windows Vista Home Basic 64-Bit x64 Edition

No WOW64 No No WOW64 WOW64

Windows Vista Home Premium 64-Bit x64 Edition

No WOW64 No No WOW64 WOW64

Windows Vista Ultimate 64-Bit x64 Edition

No WOW64 WOW64 WOW64 WOW64 WOW64

Windows Vista Business 64-Bit x64 Edition


Windows Vista Enterprise 64-Bit x64 Edition


Requisitos del sistema operativo (64 bits) En la siguiente tabla se muestran los sistemas operativos que ejecutan el software de servidor para cada versión de 64 bits de SQL Server 2005.

Enterprise Edition

1(IA

64)

Enterprise Edition

1(X6

4)

Developer Edition (IA64)

2

Developer Edition (X64)

3

Standard Edition (IA64)

Standard Edition (X64)

Express Edition y Express with Advanced Services

Evaluation Edition (IA64)

Evaluation Edition (X64)

- 17 -

SP1 de Windows Server 2003 64-Bit Itanium Datacenter Edition

Sí No Sí No Sí No No Sí No

SP1 de Windows Server 2003 64-Bit Itanium Enterprise Edition

Sí No Sí No Sí No No Sí No

SP1 de Windows Server 2003 64-Bit x64 Standard Edition

5

No Sí No Sí No Sí WOW64 No Sí

SP1 de Windows Server 2003 64-Bit x64 Datacenter Edition

5


SP1 de Windows Server 2003 64-Bit x64 Enterprise Edition

5

No Sí No Sí No Sí4 WOW64 No Sí

Windows XP x64 Professional 2003


Windows Vista Home Basic x64 Edition de 64 bits

No No No Sí No No WOW64 No Sí

Windows Vista Home Premium x64 Edition de 64 bits

No No No Sí No No WOW64 No Sí

Windows Vista x64 Ultimate Edition de 64 bits

No No No Sí No Sí WOW64 No Sí

- 18 -

Windows Vista x64 Business Edition de 64 bits


Windows Vista x64 Enterprise Edition de 64 bits


Requerimientos adicionales de software SQL Server 2005 requiere también el siguiente software:

Microsoft Internet Explorer® 6.0 Service Pack 1 o superior (requerido para Microsoft

Management Console)

Internet Information Services (IIS) 5.0 o 6.0 (requerido para Reporting Services)

TCP/IP

Microsoft .NET Framework 2.0 (SQL Server lo instalará si es necesario.)

Microsoft Windows Installer 3.1 (SQL Server lo instalará si es necesario.)

Microsoft Data Access Components (MDAC) 2.8 Service Pack 1 o superior Requerimientos para la Edición Móbile SQL Server 2005 Mobile Edition está diseñada para dispositivos móviles más que para plataforma PC. SQL Server Mobile Edition soporta:

Plataforma Pocket PC 2003

Windows CE 5.0

Windows Mobile 5.0 para Pocket PC y Smartphone Instancias de SQL Server 2005: Una instalación de SQL Server 2005 consiste de una o más instancias. Una instancia del motor de base de datos (database engine) de SQL Server, sea por defecto o con nombre, tiene su propio conjunto de programas de instancia específicos y archivos de datos, así como un conjunto de archivos comunes compartidos con todas las instancias de la computadora. Las instancias de otros componentes como Analysis Services o Reporting Service también tienen su propio conjunto de programas y archivos de datos. Cada instancia opera independientemente de cualquier otra instancia de la misma computadora, y las aplicaciones pueden conectarse a cualquiera de las instancias. Instancia por defecto Esta instancia es identificada por el nombre de red de la computadora en la cual se está ejecutando. La instancia por defecto del servicio de SQL Server es MSSQLSERVER. Instancias con nombre Estas instancias son identificadas por el nombre de red de la computadora más un nombre de instancia con el formato: nombrecomputadora/nombreinstancia , como por ejemplo MiPC\SQLINSTANCE2 para una instancia llamada SQLINSTANCE2 en una computadora llamada MiPC. Una nueva instancia debe comenzar con una letra o guión bajo (_), y puede contener números, letras u otros caracteres.

- 19 -

Cada instancia con nombre está formada por un conjunto diferente de servicios y puede tener diferentes asignaciones para intercalado (collation), seguridad y otras opciones. Opciones de Licenciamiento para SQL Server 2005 Microsoft SQL Server 2005 está disponible en base a tres modelos de licencias:

Licencia de servidor más una licencia de acceso de cliente (CAL) por dispositivo. Requiere una licencia para el equipo que ejecuta el producto servidor de Microsoft, y una CAL para cada dispositivo cliente.

Licencia de servidor más una licencia de acceso de cliente (CAL) por usuario. Requiere una licencia para el equipo que ejecuta el producto servidor de Microsoft, y una CAL para cada usuario.

Licencia por procesador. Requiere una única licencia por cada CPU en el entorno del sistema operativo que ejecuta SQL Server. Esta licencia incluye un acceso ilimitado de dispositivos cliente.

Consideraciones sobre seguridad para Servicios SQL Server Para que SQL Server y el Agente SQL Server se ejecuten como servicios de Windows, SQL Server y el Agente SQL Server deben estar asignados a una cuenta de usuario de Windows. Las cuentas pueden ser: de usuario, de dominio o de sistema. Se puede asignar la misma cuenta de Windows a todos los servicios de SQL Server o bien configurar una cuenta para cada servicio. A continuación se describen recomendaciones en la utilización de los diferentes tipos de cuenta: Usar una cuenta de usuario de dominio Es posible que sea preferible una cuenta de usuario de dominio cuando el servicio debe interactuar con los servicios de red. Muchas actividades de servidor a servidor sólo se pueden realizar con una cuenta de usuario de dominio, por ejemplo:

Llamadas a procedimiento remoto. Réplica. Copias de seguridad en unidades de red. Combinaciones heterogéneas en las que intervienen orígenes de datos remotos. Características de correo del Agente SQL Server y SQL Mail. Esta restricción se aplica

si utiliza Microsoft Exchange. La mayoría de los otros sistemas de correo también requieren que los clientes (como el servicio SQL Server y el servicio del Agente SQL Server) se ejecuten con cuentas con acceso a la red.

Usar la cuenta de servicio local La cuenta de servicio local es una cuenta integrada especial parecida a una cuenta de usuario autenticado. La cuenta de servicio local tiene el mismo nivel de acceso a los recursos y objetos que los miembros del grupo Usuarios. Este acceso limitado ayuda a proteger el sistema si procesos o servicios individuales se ven afectados. Los servicios que se ejecutan como cuenta de servicio local tienen acceso a los recursos de red como una sesión nula sin credenciales. Usar la cuenta de servicio de red La cuenta de servicio de red es una cuenta integrada especial parecida a una cuenta de usuario autenticado. La cuenta de servicio de red tiene el mismo nivel de acceso a los recursos y objetos que los miembros del grupo Usuarios. Los servicios que se ejecutan como la cuenta de servicio de red tienen acceso a los recursos de red a través de las credenciales de la cuenta de equipo.

- 20 -

Intercalación (Collation) Una intercalación especifica los patrones de bits que representan a cada carácter de un conjunto de datos. Las intercalaciones también determinan las reglas que ordenan y comparan datos. SQL Server 2005 admite almacenamiento de objetos con distintas intercalaciones en una sola base de datos (cada columna de una base de datos de SQL Server puede tener su propia intercalación). En columnas que no sean Unicode, la configuración de intercalación especifica la página de códigos de los datos y, por ende, qué caracteres se pueden representar. Se pueden quitar datos entre columnas Unicode directamente. Los datos entre columnas que no sean Unicode no se pueden quitar directamente y debe convertirlos la página de códigos actual. El resultado de una instrucción Transact-SQL puede variar cuando la instrucción se ejecuta en el contexto de distintas bases de datos en las que cada una de ellas tenga una configuración de intercalación diferente. Las prácticas recomendadas incluyen el uso de una intercalación normalizada para la organización, siempre que sea posible. El uso de una configuración de intercalación estándar en todos los sistemas de su organización le ayudará a eliminar la necesidad de especificar de manera explícita la intercalación en cada carácter o expresión Unicode. Si tiene que trabajar con objetos que tienen configuraciones de intercalación y de página de códigos distintas, debe codificar sus consultas para que tengan en cuenta las reglas de prioridad de intercalación. Las características de una intercalación distinguen idiomas, mayúsculas de minúsculas, acento, Kana y ancho. Las intercalaciones de SQL Server 2005 incluyen las siguientes agrupaciones:

Intercalaciones de Windows: Las intercalaciones de Windows definen reglas para

almacenar los datos de caracteres basadas en la configuración regional de Windows asociada. En una intercalación de Windows, la comparación de datos no Unicode se implementa con el mismo algoritmo que la de los datos Unicode. Estas reglas de intercalación básicas de Windows especifican qué alfabeto o idioma se utiliza cuando se aplica un orden de diccionario, y la página de códigos que se utiliza para almacenar los datos de caracteres que no son Unicode. Tanto la ordenación Unicode y como la ordenación no Unicode son compatibles con comparaciones de cadenas de una determinada versión de Windows. Esto proporciona coherencia entre los tipos de datos de SQL Server y también ofrece a los programadores la posibilidad de ordenar cadenas en sus aplicaciones utilizando las mismas reglas utilizadas por SQL Server; es decir, llamando a la función CompareStringW de la API Win32 de Microsoft.

Intercalaciones binarias: Las intercalaciones binarias ordenan datos según la

secuencia de los valores codificados definidos por la configuración regional y los tipos de datos. Una intercalación binaria de SQL Server define la configuración regional de idioma y la página de códigos ANSI que se van a utilizar, aplicando un orden binario. Las intercalaciones binarias son útiles, gracias a su relativa simplicidad, para obtener un rendimiento mejorado de las aplicaciones. En tipos de datos no Unicode, las comparaciones de datos dependen de los puntos de código definidos en la página de códigos ANSI. En tipos de datos Unicode, las comparaciones de datos dependen de los puntos de código Unicode. En intercalaciones binarias de tipos de datos Unicode, la configuración regional no se tiene en cuenta a la hora de ordenar los datos. Por ejemplo, Latin_1_General_BIN y Japanese_BIN producen idénticos resultados de orden cuando se utilizan en datos Unicode. Las intercalaciones binarias anteriores de SQL Server realizaban una comparación de punto de código a punto de código incompleta para datos Unicode. En dichas intercalaciones binarias de versiones anteriores de SQL Server se comparaba el primer carácter como WCHAR, seguido de una comparación byte a byte. Por razones de compatibilidad con versiones anteriores, la semántica de intercalación binaria no se cambiará. Las intercalaciones binarias de esta versión de SQL Server incluyen un nuevo conjunto de intercalaciones de

- 21 -

comparación de puntos de código pura. Los clientes pueden elegir migrar a las intercalaciones binarias nuevas para aprovecharse de las comparaciones de puntos de código reales y deberían utilizar las nuevas intercalaciones binarias para el desarrollo de nuevas aplicaciones. El nuevo sufijo BIN2 identifica nombres de intercalación que implementan la nueva semántica de intercalación de punto de código. Además, se ha agregado un nuevo indicador de comparación correspondiente a BIN2 para el nuevo orden binario.

Intercalaciones de SQL Server: Las intercalaciones de SQL Server proporcionan

compatibilidad de orden con versiones anteriores de SQL Server. Las intercalaciones de SQL Server se basan en órdenes de SQL Server heredados para datos que no son Unicode (por ejemplo, tipos de datos char y varchar) definidos por SQL Server. Las

reglas de ordenación alfabética de datos no Unicode no son compatibles con ninguna rutina de ordenación suministrada por sistemas operativos Windows, pero la ordenación de datos Unicode es compatible con una versión particular de las reglas de ordenación de Windows. Como las intercalaciones de SQL Server utilizan reglas de comparación diferentes para datos no Unicode y para datos Unicode, puede ver resultados diferentes en las comparaciones de los mismos datos, dependiendo del tipo de datos subyacentes.

Intercalación por Defecto y reglas de ordenamiento: Si usted no designa una Intercalación y reglas de ordenamiento, SQL Server aplica las asignadas por defecto.

SQL Server selecciona lo siguiente:

La Intercalación de Windows basada en la configuración regional de Windows para la computadora en la que SQL es instalado.

La Intercalación de SQL que es compatible con versiones anteriores de SQL basada en la configuración regional detectada.

Cambie la configuración predeterminada de intercalación de Windows sólo si:

Su instalación de SQL Server debe coincidir con la configuración de intercalación utilizada por otra instancia de SQL Server.

Si la configuración de intercalación debe coincidir con la configuración regional del sistema Windows de otro equipo.

Actualizar a SQL Server 2005 Puede actualizar directamente las instancias de SQL Server 2000 Service Pack 3 (SP3) o posterior, e instancias de SQL Server 7.0 SP4 o posterior, a SQL Server 2005. Puede realizar la mayoría de las operaciones de actualización mediante el programa de instalación; no obstante, algunos componentes admiten o necesitan la migración de aplicaciones o soluciones una vez ejecutado el programa de instalación. Utilizando el Asesor de actualizaciones (Upgrade Adviser) para preparar las actualizaciones El Asesor de actualizaciones de Microsoft SQL Server 2005 ayuda a preparar las actualizaciones de SQL Server 2005. El Asesor de actualizaciones analiza los componentes instalados de SQL Server 2000 o SQL Server 7.0 y genera informes que identifican los problemas que han de solucionarse antes o después de la actualización a SQL Server 2005. Cómo funciona el Asesor de actualizaciones Al ejecutar el Asesor de actualizaciones, se mostrará la página de inicio del Asesor de actualizaciones. Desde la página Inicio, podrá ejecutar las siguientes herramientas:

Asistente para análisis del Asesor de actualizaciones

- 22 -

Visor de informes del Asesor de actualizaciones Ayuda del Asesor de actualizaciones

La primera vez que utilice el Asesor de actualizaciones, ejecute el Asistente para análisis del Asesor de actualizaciones para analizar los componentes de SQL Server. Una vez que el asistente haya finalizado el análisis, podrá ver los informes resultantes en el Visor de informes del Asesor de actualizaciones. Los informes incluyen vínculos a información de la Ayuda del Asesor de actualizaciones que le ayudará a solucionar los problemas conocidos o a paliar su efecto. Análisis del Asesor de actualizaciones El Asesor de actualizaciones analiza los siguientes componentes de SQL Server:

Database Engine (Motor de base de datos) Analysis Services Notification Services Reporting Services Integration Services, anteriormente conocido como Servicios de transformación de

datos (DTS) Un analizador dedicado se ejecuta en el contexto del Asesor de actualizaciones para cada componente de SQL Server. El análisis examina los objetos accesibles para los analizadores individuales, como secuencias de comandos, procedimientos almacenados, desencadenadores y archivos de traza. El Asesor de actualizaciones no puede analizar aplicaciones de escritorio ni procedimientos almacenados cifrados. La salida de cada analizador es un informe XML sobre dicho componente. Podrá ver el informe XML mediante el visor de informes del Asesor de actualizaciones. Compatibilidad de la base de Datos Algunos comportamientos en la base de datos SQL Server 2005 son diferentes a los utilizados en versiones anteriores de SQL Server. Si existen aplicaciones en uso que utilicen una versión anterior de SQL Server es necesario que usted asigne el nivel de compatibilidad de SQL Server 2005 para su correcto funcionamiento. Para signar un nivel de compatibilidad de una base de datos SQL Server debe hacerlo utilizando el comando ALTER DATABASE con la cláusula SET COMPATIBILITY_LEVEL .

- 23 -

2- Instalación Microsoft SQL Server 2005 se puede instalar mediante el Asistente para la instalación o desde el símbolo del sistema. El Asistente para la instalación proporciona una interfaz gráfica de usuario que le guía a través de cada decisión del proceso de instalación. El Asistente para la instalación proporciona instrucciones para la configuración inicial de SQL Server 2005, lo que incluye selección de características, reglas de nomenclatura de instancias, configuración de cuentas de servicio, directrices para contraseñas seguras y escenarios para establecer intercalaciones. Las instalaciones del símbolo del sistema son para escenarios avanzados como instalaciones silenciosas; se pueden ejecutar directamente desde el símbolo del sistema o a partir de una sintaxis del símbolo del sistema que haga referencia al archivo de instalación para especificar opciones de instalación. Comprobador de Configuración del Sistema (System configuration checker) Como parte de la instalación de SQL Server 2005, el Comprobador de configuración del sistema (SCC) examina el equipo en el que se haya instalado Microsoft SQL Server 2005. El SCC comprueba las condiciones que impiden una instalación correcta de SQL Server. Antes de que el programa de instalación inicie el Asistente para la instalación de SQL Server 2005, el SCC recupera el estado de cada elemento de comprobación, compara el resultado con las condiciones necesarias y proporciona instrucciones para eliminar los problemas de bloqueo. Todos los elementos de comprobación del SCC están habilitados por la red; las comprobaciones se pueden ejecutar en un equipo local, así como en situaciones remotas o de clúster. Opciones para la instalación de Componentes: El Asistente para la instalación proporciona una interfaz gráfica de usuario que le guía a través de cada decisión del proceso de instalación, así como instrucciones para la configuración inicial de SQL Server 2005, lo que incluye selección de características, reglas de nomenclatura de instancias, configuración de cuentas de servicio, directrices para contraseñas seguras y escenarios para establecer intercalaciones. Utilice la página Selección de características del Asistente para la instalación de SQL Server para seleccionar los componentes que se incluirá en la instalación de SQL Server 2005. Utilice las siguientes descripciones para determinar el conjunto de características que satisfagá sus necesidades. En el panel Componentes para instalar, se muestra una descripción de cada grupo de

componentes al seleccionarlo. Puede activar una combinación de casillas de verificación. Para seleccionar características individuales para la instalación, haga clic en Avanzadas. Para

instalar componentes en una carpeta de destino personalizada o para ver los requisitos de espacio en disco para un componente o característica individual, haga clic en Avanzadas.

Seleccione este grupo de componentes Para instalar estos componentes y características

Servicios de bases de datos de SQL Server

SQL Server Database Engine (Motor de base de datos de SQL Server) incluye las siguientes tecnologías:

Database Engine (Motor de base de datos) es el servicio principal para almacenar, procesar y proteger los datos.

- 24 -

La réplica 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.

La búsqueda de texto proporciona funcionalidad para realizar consultas de texto en datos simples basados en caracteres contenidos en tablas de SQL Server.

Herramientas para administrar datos relacionales y XML.

Analysis Services Analysis Services incluye las herramientas para crear y administrar aplicaciones de procesamiento analítico en línea (OLAP) y de minería de datos.

Reporting Services Reporting Services incluye componentes de servidor y de cliente para crear, administrar e implementar informes tabulares, matriciales, gráficos y de forma libre. Reporting Services también es una plataforma extensible que puede utilizarse para desarrollar aplicaciones de informes.

Notification Services Notification Services es una plataforma para desarrollar e implementar aplicaciones que envíen información personalizada puntualmente a los suscriptores de una gran variedad de dispositivos.

Integration Services Integration Services es un conjunto de herramientas gráficas y objetos programables para mover, copiar y transformar datos.

Componentes de la estación de trabajo, Libros en pantalla y herramientas de desarrollo

Instala componentes para la comunicación entre clientes y servidores, incluidas bibliotecas de red para DB-Library, OLEDB para OLAP, ODBC, ADODB y ADOMD+.

Herramientas de administración

SQL Server Management Studio (SSMS), nuevo en Microsoft SQL Server 2005, es un entorno integrado para obtener acceso, configurar, administrar y desarrollar todos los componentes de SQL Server. SSMS reúne las características del Administrador corporativo, el Analizador de consultas y Analysis Manager, herramientas incluidas en versiones anteriores de SQL Server, en un único entorno que proporciona acceso para SQL Server a los desarrolladores y administradores de todos los niveles de conocimiento.

El Administrador de configuración de SQL Server proporciona administración de configuración básica para los servicios, protocolos de servidor, protocolos de cliente y alias de cliente de SQL Server.

Analizador de SQL Server proporciona una interfaz gráfica de usuario para supervisar una instancia de Database Engine (Motor de base de datos) o una instancia de Analysis Services.

El Asistente para la optimización de Database Engine (Motor de base de datos) crea conjuntos óptimos de índices, vistas indizadas y particiones.

El Monitor de réplica permite realizar un seguimiento del estado y del rendimiento de las publicaciones y las suscripciones en una topología de réplica.

Características de cliente SQLXML

Documentación

Los Libros en pantalla de SQL Server son la documentación principal de SQL Server 2005.

Kits de desarrollo de software

Herramientas de desarrollo

Business Intelligence Development Studio es un entorno de desarrollo

- 25 -

integrado para las soluciones de Analysis Services, Reporting Services y Integration Services.

Instalación Desatendida Usted puede realizar una instalación desatendida creando un archivo .ini que contenga la información de setup y ejecutando el setup.exe desde la línea de comandos. Entender cómo realizar una instalación desatendida puede ayudarlo a distribuir múltiples instalaciones de SQL Server idénticas. Creación del archivo .ini Puede crear este archivo desde cualquier editor de texto, como por ejemplo el Notepad. El CD de SQL Server contiene un archivo modelo llamado template.ini que usted puede utilizar para comenzar a crear su propio archivo .ini. El archivo .ini está compuesto de una sección de Opciones que contiene múltiples parámetros, cada uno de los cuales hace referencia a un componente o configuración diferente. Comenzando una instalación desatendida Para comenzar una instalación desatendida utilice la siguiente sintaxis de comando: setup.exe /settings <path to .ini file> Por ejemplo, para llevar a cabo una instalación desatendida con un archivo .ini llamado installsettings.ini en la carpeta C:\setup folder, utilice el siguiente comando: setup.exe /settings c:\setup\installsettings.ini Adicionalmente, usted puede especificar /qn para instalación desatendida (sin cajas de diálogo) o /qb para especificar que sólo el diálogo de progreso será mostrado.

- 26 -

3- Manejo de la instalación Configuración de Superficie (Surface Area Configuration) La herramienta Configuración de superficie para características proporciona una sola interfaz para habilitar o deshabilitar muchas características del Motor de base de datos, Analysis Services y Reporting Services. Si se deshabilitan las características que no se utilizan, se pueden proteger las instalaciones de Microsoft SQL Server reduciendo la superficie de SQL Server. Usted puede utilizar la herramienta Configuración de Superficie para habilitar o deshabilitar los siguientes servicios y opciones de conectividad para cada instancia de SQL Server en la computadora. En las siguientes tablas se incluye el valor predeterminado para cada configuración:

Configuración Valor predeterminado

Consultas ad hoc distribuidas Deshabilitada en nuevas instalaciones.

Integración de CLR (Common Language Runtime)

Deshabilitada en nuevas instalaciones.

Conexión de administrador dedicada (DAC) Deshabilitada en nuevas instalaciones.

Correo electrónico de base de datos Deshabilitada en nuevas instalaciones.

Servicios Web XML nativos Los extremos no están configurados de forma predeterminada.

Procedimientos almacenados de automatización OLE


Service Broker Los extremos no están configurados de forma predeterminada.

SQL Mail Deshabilitada en nuevas instalaciones.

Procedimientos almacenados de Asistente para Web


xp_cmdshell Deshabilitada en nuevas instalaciones.

En las siguientes tablas se incluye el valor predeterminado para cada configuración de servicios y protocolos de red de Windows:

Servicio o protocolo Valor predeterminado

Servicio del Database Engine (Motor de base de datos)

El inicio puede establecerse en Automático o Manual durante la instalación.

Conexiones remotas del Database Engine Las conexiones remotas están deshabilitadas en las ediciones

- 27 -

(Motor de base de datos) Express, Evaluation y Developer de SQL Server 2005 y están habilitadas en otras ediciones.

Servicio de Analysis Services El inicio puede establecerse en Automático o Manual durante la instalación.

Conexiones remotas de Analysis Services Las conexiones remotas están deshabilitadas en las ediciones Express, Evaluation y Developer de SQL Server 2005 y están habilitadas en otras ediciones.

Servicio de Reporting Services El inicio puede establecerse en Automático o Manual durante la instalación.

Servicio del Agente SQL Server Si se encuentra instalado, el tipo de inicio está establecido en Manual y el servicio está detenido.

Servicio de búsqueda de texto Si se encuentra instalado, el inicio está establecido en Manual y el servicio está detenido.

Servicios de instancia de Notification Services

Servicios no instalados durante la instalación.

Servicio de Integration Services Si se encuentra instalado, el servicio está establecido en el modo de inicio Automático.

Servicio Explorador de SQL Server El inicio está establecido en Automático en las siguientes condiciones:

Cuando hay instancias con nombre del motor de base de datos o Analysis Services en el servidor

Cuando se encuentra instalado en un clúster

Cuando está instalado SQL Server 2000 al mismo tiempo

- 28 -

Manejador de Configuración (Configuration Manager) El SQL Server Configuration Manager es una herramienta que usted puede utilizar para manejar los servicios asociados a SQL Server, configurar los protocolos de red utilizados por SQL Server y manejar la configuración de conectividad de red desde computadoras cliente SQL Server.

- 29 -

Servicios SQL Server Usted puede utilizar SQL Server Configuration Manager para iniciar, pausar, detener o restaurar servicios Windows asociados a SQL Server. También puede configurar los servicios para que controlen sus modos de inicio y sus cuentas de servicio, así como propiedades avanzadas como por ejemplo parámetros de inicio. Importante: para cambiar las cuentas de servicio utilice SQL Server Configuration Manager en lugar de la consola de Windows Services porque SQL Server Configuration Manager aplica automáticamente los permisos de registro requeridos para la cuenta que usted especifique. Configuración del Servidor de Red Usted puede utilizar SQL Server Configuration Manager para configurar los protocolos de red utilizados por una instancia de SQL Server. Puede habilitar o deshabilitar un protocolo determinado y manejar los valores específicos para ese protocolo como el puerto TCP utilizado por el protocolo TCP/IP. Configuración del Cliente de Red Cuando se instala SQL Server Configuration Manager en una computadora cliente, usted puede utilizarlo para manejar la librería Cliente Nativo SQL (SQL Native Client) estableciendo el orden de prioridad de protocolos de red y alianzas de servidor. SQL Server Management Studio SQL Server Management Studio es un entorno integrado para obtener acceso a todos los componentes de SQL Server, configurarlos, administrarlos y desarrollarlos. Combina un amplio grupo de herramientas gráficas con una serie de editores de script para ofrecer acceso a SQL Server a programadores y administradores de todos los niveles de especialización. SQL Server Management Studio combina las características del Administrador corporativo, el Analizador de consultas y Analysis Manager, herramientas incluidas en versiones anteriores de SQL Server, en un único entorno. Además, SQL Server Management Studio funciona con

- 30 -

todos los componentes de SQL Server, como Reporting Services, Integration Services y SQL Server Compact 3.5. Los programadores obtienen una experiencia familiar y los administradores de bases de datos una única herramienta completa que combina herramientas gráficas fáciles de usar con funciones de script enriquecidos. SQL Server Management Studio incluye las siguientes características generales:

Compatibilidad con la mayoría de las tareas administrativas de SQL Server 2005 y SQL Server 2000.

Un entorno único integrado para administración y edición de SQL Server Database Engine (Motor de base de datos de SQL Server).

Nuevos cuadros de diálogo para la administración de objetos de SQL Server Database Engine (Motor de base de datos de SQL Server), Analysis Services, Reporting Services, Notification Services y Microsoft SQL Server 2005 Compact Edition, lo que permite ejecutar las acciones inmediatamente, enviarlas a un editor de código o escribirlas en secuencias de comandos para ejecutarlas posteriormente.

Cuadros de diálogo no modales y de tamaño variable que permiten obtener acceso a varias herramientas mientras un cuadro de diálogo está abierto.

Un cuadro de diálogo común de programación que permite realizar acciones de los cuadros de diálogo de administración en otro momento.

Exportación e importación del registro de servidor de SQL Server Management Studio desde un entorno de Management Studio a otro.

Guardado o impresión de archivos de plan de presentación XML o de interbloqueo generados por el Analizador de SQL Server, revisión posterior o envío a los administradores para su análisis.

Un nuevo cuadro de mensaje de error e informativo que presenta mucha más información, permite enviar a Microsoft un comentario sobre los mensajes, copiar mensajes en el Portapapeles y enviar fácilmente los mensajes por correo electrónico al equipo de soporte.

Un explorador Web integrado para una rápida exploración de MSDN o la ayuda en pantalla.

Integración de la ayuda de comunidades en línea. Un nuevo monitor de actividad con filtro y actualización automática. Interfaces de Correo electrónico de base de datos integradas.

Nuevas funciones de las Secuencias de Comandos El Editor de código de SQL Server Management Studio contiene editores de secuencias de comandos integrados para crear secuencias de comandos Transact-SQL, MDX, DMX, XML/A y XML. Ofrece las características siguientes:

Ayuda dinámica para el acceso inmediato a la información relevante mientras se

trabaja. Un amplio conjunto de plantillas y la posibilidad de crear plantillas personalizadas. Compatibilidad con la escritura y modificación de consultas o secuencias de comandos

sin necesidad de conexión a un servidor. Compatibilidad con secuencias de comandos para consultas y secuencias de

comandos SQLCMD. Una nueva interfaz para ver resultados XML. Control de código fuente integrado para proyectos de secuencias de comandos y

soluciones compatibles con el almacenamiento y la conservación de copias de secuencias de comandos a medida que evolucionan.

Compatibilidad de Microsoft IntelliSense con instrucciones MDX.

- 31 -

Características del Explorador de objetos El Explorador de objetos de SQL Server Management Studio es una herramienta integrada para ver y administrar objetos en todo tipo de servidores. Ofrece las características siguientes:

Filtrado por todo o parte de un nombre, esquema o fecha. Llenado asincrónico de objetos, con la posibilidad de filtrar objetos según sus

metadatos. Acceso al Agente SQL Server en los servidores de réplica para administración.

- 32 -

Módulo 2

Recuperación de desastre

- 33 -

1- Planeamiento

Planear la estrategia de copias de seguridad y restauración Al administrar una base de datos de SQL Server, es importante estar preparado para la recuperación de desastres potenciales. Es necesario un plan de restauración y de copia de seguridad correctamente diseñado y probado para poder recuperar las copias de seguridad de SQL Server de las bases de datos después de un desastre. Además, para garantizar que todos los sistemas y datos puedan recuperar rápidamente su funcionamiento normal en caso de un desastre natural, es necesario crear un plan de recuperación de desastres. Durante la elaboración de este plan es preciso tener en cuenta los escenarios de distintos tipos de desastres que pueden afectar a su negocio, incluidos los desastres naturales, como un incendio, y los desastres técnicos, como los errores en dos discos de una matriz RAID-5. Cuando cree un plan de recuperación de desastres, identifique y prepare todos los pasos necesarios para hacer frente a cada tipo de desastre. Debe realizar la comprobación práctica de los pasos de recuperación de cada escenario. Se recomienda que compruebe el plan de recuperación de desastres mediante la simulación de un desastre natural. Durante el diseño del plan de copia de seguridad y restauración, es necesario realizar el diseño del plan de recuperación de desastres según el entorno y las necesidades del negocio. Por ejemplo, supongamos que se produce un incendio y destruye el centro de datos disponibles 24 horas al día. ¿Está seguro de que es posible la recuperación? ¿Cuánto tiempo se puede tardar en llevar a cabo la recuperación y tener disponible el sistema? ¿Cuál es la cantidad de datos perdidos que pueden tolerar los usuarios? Lo ideal es que el plan de recuperación de desastres indique el tiempo que durará la recuperación y el estado final de las bases de datos que los usuarios pueden esperar. Por ejemplo, puede determinar que, tras la adquisición del hardware especificado, la recuperación debe completarse en 48 horas y sólo se garantizarán los datos hasta finales de la semana previa al incidente. Un plan de recuperación de desastres se puede estructurar de diferentes maneras y puede contener muchos tipos de información. Entre los tipos de planes de recuperación de desastres se incluyen los siguientes:

Un plan para adquirir el hardware. Un plan de comunicación. Una lista de las personas con las que ponerse en contacto si se produce un desastre. Instrucciones para ponerse en contacto con las personas implicadas en la respuesta al

desastre. Información acerca del propietario de la administración del plan. Una lista de comprobación de las tareas necesarias para cada escenario de

recuperación. Para facilitar la revisión de la evolución de la recuperación de desastres, ponga a cada tarea una inicial a medida que se vayan completando y anote la hora de finalización en la lista de comprobación.

Elegir el tipo de medio para la copia de seguridad SQL Server puede generar copias en discos rígidos o cintas. Los discos locales o a través de la red son el medio más común para guardar copias de seguridad. Cuando la copia se genera en cinta el dispositivo debe estar instalado localmente al servidor de SQL Server.

Administrar medios de copia de seguridad Se recomienda que el plan de copias de seguridad estipule cómo se han de administrar los medios de copia de seguridad, por ejemplo:

- 34 -

Un plan de seguimiento y administración para almacenar y reciclar conjuntos de copias de seguridad.

Una programación para sobrescribir el medio de copia de seguridad. En un entorno multiservidor, la decisión de utilizar copias de seguridad centralizadas o

distribuidas. Un modo de realizar un seguimiento de la vida útil del medio. Un procedimiento para minimizar los efectos de la pérdida de un conjunto o medio de

copia de seguridad, por ejemplo, la pérdida de una cinta. La decisión de guardar los conjuntos de copia de seguridad dentro o fuera del sitio, y

un análisis de cómo afectaría esta decisión al tiempo de recuperación. Ejecutar una secuencia de comandos con la funcionalidad básica Normalmente, las secuencias de comandos con la funcionalidad básica se incluyen en los planes de recuperación de desastres para confirmar que todo funciona como se espera. Una secuencia de comandos con la funcionalidad básica proporciona una herramienta confiable para que los administradores de sistemas o de bases de datos puedan comprobar que se ha recuperado la base de datos con un estado viable, sin tener que depender de los usuarios finales para llevar a cabo la comprobación. Una secuencia de comandos con la funcionalidad básica es específica de la aplicación y puede adoptar muchas formas diferentes. Por ejemplo, en un sistema de informes o ayuda a la toma de decisiones, la secuencia de comandos puede ser simplemente una copia de varias de las consultas para informes más importantes. Para una aplicación de procesamiento de transacciones en línea (OLTP), la secuencia de comandos puede ejecutar un lote de procedimientos almacenados que contengan instrucciones INSERT, UPDATE y DELETE. Por ejemplo, una secuencia de comandos con la funcionalidad básica puede ser tan simple como un archivo .sql que envía instrucciones SQL por lotes al servidor desde la utilidad sqlcmd. Otro ejemplo es usar un archivo .bat que contenga los comandos bcp y sqlcmd.

Garantizar la disposición para afrontar desastres Para asegurarse de que está preparado para hacer frente a desastres, se recomienda que realice las siguientes tareas de forma periódica:

Compruebe los procedimientos de copia de seguridad y recuperación antes de que se produzca un error real. Las comprobaciones le ayudan a asegurarse de que cuenta con las copias de seguridad necesarias para recuperarse de diversos errores, que sus procedimientos están perfectamente definidos y documentados y que cualquier operario cualificado puede ejecutarlos rápidamente y sin problemas.

Para que la cantidad de datos perdidos sea mínima, realice periódicamente copias de seguridad de las bases de datos y los registros de transacciones. Se recomienda realizar copias de seguridad del sistema y de las bases de datos de los usuarios.

Mantenga los registros del sistema de manera segura. Conserve registros de todos los Service Pack instalados en Microsoft Windows y SQL Server. Conserve registros de las bibliotecas de red usadas y del modo de seguridad. Asimismo, si SQL Server se ejecuta en autenticación de modo mixto (modo de autenticación de SQL Server y de Windows), registre la contraseña de sa.

En otro servidor, evalúe por anticipado los pasos que debe seguir para la recuperación de un desastre, modifíquelos según sea necesario para ajustarlos a su entorno de servidor local y compruebe los pasos modificados.

Conserve una secuencia de comandos con la funcionalidad básica a fin de evaluar rápidamente la capacidad mínima.

Revisar y reducir los posibles errores del usuario

- 35 -

Uno de los escenarios de recuperación más difíciles es recuperarse de un error de usuario importante, como quitar objetos de la base de datos de forma accidental. En esta sección se enumeran herramientas que le pueden ayudar a revisar y en algunos casos a regular los cambios efectuados a las bases de datos.

Desencadenadores del lenguaje de definición de datos (DDL): Estos

desencadenadores se pueden crear para revisar y regular algunos cambios del esquema de base de datos. Los desencadenadores DDL activan procedimientos almacenados en respuesta a una variedad de instrucciones DDL. Estas instrucciones son básicamente las que empiezan por CREATE, ALTER y DROP. El ámbito de un desencadenador DDL puede ser una base de datos determinada o una instancia de servidor completa.

Notificaciones de eventos: Las notificaciones de eventos se ejecutan en respuesta a

una variedad de instrucciones DDL de Transact-SQL y eventos de la traza de SQL, y envían información acerca de esos eventos a un servicio de Service Broker.

Se pueden programar notificaciones de eventos para muchos de los eventos capturados por Traza de SQL, pero, en lugar de usarlas para crear trazas, puede usar dichas notificaciones para realizar una acción en una instancia de SQL Server 2005 como respuesta a eventos. Dado que las notificaciones de eventos se ejecutan de forma asincrónica, estas acciones no consumen recursos definidos por la transacción inmediata.

Agente SQL Server: Se trata de un servicio de Windows que ejecuta tareas administrativas programadas, denominadas trabajos. El Agente SQL Server utiliza SQL Server para almacenar información de los trabajos. Entre otras cosas, el Agente SQL Server puede ejecutar un trabajo en respuesta a un evento concreto; por ejemplo, errores que tienen un nivel de gravedad o un número de mensaje específicos.

Traza de SQL (Trace): La traza de SQL proporciona procedimientos almacenados del sistema Transact-SQL para crear trazas sobre clases de eventos seleccionadas por el usuario en una instancia del Motor de base de datos de SQL Server. Puede utilizar estos procedimientos almacenados del sistema desde sus propias aplicaciones para crear trazas manualmente.

Modelos de recuperación Los modelos de recuperación se han diseñado para controlar el mantenimiento del registro de transacciones. Existen tres modelos de recuperación: simple (Simple), completa (Full) y por medio de registros de operaciones masivas (BULK_LOGGED). Normalmente, en las bases de datos se usa el modelo de recuperación completa o el modelo de recuperación simple. En la tabla siguiente se resumen estos modelos de recuperación.

Modelo de recuperación Descripción

Riesgo de pérdida de trabajo

¿Recuperación hasta un momento dado?

Simple Sin copias de seguridad de registros.

Recupera automáticamente el espacio de registro para mantener al mínimo los requisitos de espacio, eliminando, en esencia, la necesidad de administrar el espacio del registro de transacciones.

Los cambios realizados después de la copia de seguridad más reciente no están protegidos. En caso de desastre, es necesario volver a realizar dichos cambios.

Sólo se puede recuperar hasta el final de una copia de seguridad.

- 36 -

Completa Requiere copias de seguridad de registros.

No se pierde trabajo si un archivo de datos se pierde o resulta dañado.

Se puede recuperar hasta cualquier momento, por ejemplo, antes del error de aplicación o usuario.

Normalmente ninguno.

Si el final del registro resulta dañado, se deben repetir los cambios realizados desde la última copia de seguridad de registros.

Se puede recuperar hasta determinado momento, siempre que las copias de seguridad se hayan completado hasta ese momento.

Por medio de registros de operaciones masivas

Requiere copias de seguridad de registros.

Complemento del modelo de recuperación completa que permite operaciones de copia masiva de alto rendimiento.

Reduce el uso del espacio de registro mediante el registro masivo de la mayoría de las operaciones masivas.

Si el registro resulta dañado o se han realizado operaciones masivas desde la última copia de seguridad de registros, se pueden repetir los cambios desde esa última copia de seguridad.

En caso contrario, no se pierde el trabajo.

Se puede recuperar hasta el final de cualquier copia de seguridad. No admite recuperaciones a un momento dado.

- 37 -

Recuperación simple

Utilícelo si se dan todas las condiciones siguientes: La recuperación al momento del error no es necesaria. Si se pierde o se daña la base

de datos, no le importa perder todas las actualizaciones realizadas entre el error y la copia de seguridad anterior.

No le importa perder algunos datos del registro. No desea realizar copias de seguridad del registro de transacciones ni restaurarlo, y

prefiere confiar exclusivamente en las copias de seguridad completas y diferenciales.

Recuperación completa

Utilice este modelo y, opcionalmente, también el modelo de recuperación por medio de registros de operaciones masivas, si se da cualquiera de las condiciones siguientes:

Desea poder recuperar todos los datos. Si la base de datos incluye varios grupos de archivos y desea realizar una restauración

por etapas de los grupos de archivos secundarios de lectura y escritura, y opcionalmente, de los de sólo lectura.

Debe poder realizar una recuperación hasta el momento del error. Desea poder restaurar páginas individuales.

- 38 -

Le resulta aceptable incurrir en los costes administrativos de las copias de seguridad del registro de transacciones

Recomendaciones sobre modelos de recuperación para bases de datos del sistema En esta sección se resumen las recomendaciones para utilizar un modelo de recuperación con cada una de las bases de datos del sistema.

Base de datos del sistema

Modelo de recuperación Comentarios

master Simple Por compatibilidad con versiones anteriores de Microsoft SQL Server, el modelo de recuperación de master se puede establecer en FULL o BULK_LOGGED. No obstante, master no admite BACKUP LOG. Por lo tanto, incluso si el modelo de recuperación de master se cambia a completo o por medio de registros de operaciones masivas, la base de datos continúa funcionando como si estuviese usando el modelo de recuperación simple.

model Completa (valor predeterminado)

Las bases de datos de usuario recién creadas usan el mismo modelo de recuperación que la base de datos model. Si desea que las nuevas bases de datos usen el modelo de recuperación simple, cambie el modelo de recuperación de model a SIMPLE.

Recomendación: es aconsejable crear copias de seguridad completas de base de datos de model, sólo cuando sea necesario. Puesto que model es de pequeño tamaño y no suele cambiar, no es necesario realizar copia de seguridad del registro.

msdb Simple (valor predeterminado)

Si desea utilizar la información del historial de copias de seguridad y restauraciones que hay en msdb para recuperar las bases de datos de usuarios, se recomienda usar el modelo de recuperación completa para msdb. Además, debería considerar la posibilidad de situar el registro de transacciones msdb en un medio de almacenamiento con tolerancia a errores.

Resource — El modelo de recuperación es irrelevante. La copia de seguridad de SQL Server no puede realizar una copia de seguridad de la base de datos Resource.

Nota: Puede realizar una copia de seguridad basada en disco o en archivos de la base de datos Resource si trata a Mssqlsystemresource.mdf como si fuese un archivo binario (.exe). No obstante, no puede utilizar la restauración de SQL Server en estas copias de seguridad.

Tempdb Simple Requiere el modelo de recuperación simple, de forma que el espacio de registro tempdb se recupera siempre automáticamente. No se puede hacer una copia de seguridad de tempdb.

- 39 -

2- Copias de Seguridad

Tipos de Copias de Seguridad

Copias de seguridad completas de bases de datos

Copias de Seguridad del Registro de Transacciones Copias de Seguridad Diferenciales Copias de Seguridad de Archivos o Grupos de Archivos

Copias de seguridad completas de bases de datos Una copia de seguridad completa de la base de datos crea una copia de seguridad de toda la base de datos, que incluye parte del registro de transacciones para que se pueda recuperar la copia de seguridad completa de la base de datos. Las copias de seguridad completas representan la base de datos en el momento en que finalizó la copia de seguridad. Las copias de seguridad de bases de datos son fáciles de utilizar. Una copia de seguridad completa de una base de datos contiene todos los datos de la base de datos. Para las bases de datos pequeñas, de las que se puede hacer una copia de seguridad con rapidez, la práctica recomendada es utilizar copias de seguridad completas de la base de datos. Sin embargo, a medida que la base de datos aumenta de tamaño, las copias de seguridad completas requieren una mayor cantidad de tiempo y espacio de almacenamiento. Por ello, para una base de datos grande, puede que desee complementar las copias de seguridad completas con copias de seguridad diferenciales.

Copia de seguridad en el modelo de recuperación completa En el modelo de recuperación completa se usan copias de seguridad de registros para evitar la pérdida de datos en la mayor parte de los casos de error y es necesario realizar copias de seguridad y restaurar el registro de transacciones (copias de seguridad de registros). La ventaja de usar las copias de seguridad de registros reside en que permite restaurar una base de datos a cualquier momento de una copia de seguridad de registros (recuperación a un momento dado). Si consideramos que se puede realizar una copia de seguridad del registro

activo después de que ocurra un desastre, se podrá restaurar la base de datos al momento del error sin perder datos. Las desventajas de usar las copias de seguridad de registros son que requieren espacio de almacenamiento y aumentan la duración y la complejidad de las restauraciones. En las bases de datos en que se usa con frecuencia el modelo de recuperación completa, se pueden optimizar algunas operaciones masivas utilizando temporalmente el modelo de recuperación por medio de registros de operaciones masivas. El modelo de recuperación por medio de registros de operaciones masivas impone varias restricciones que hacen que no sea adecuado para su uso diario. Ejemplo: En la siguiente ilustración se muestra la estrategia de copia de seguridad más fácil con el modelo de recuperación completa. En la ilustración se han realizado una copia de seguridad de base de datos, Db_1, y dos copias de seguridad de registros rutinarias, Log_1 y Log_2. Algún tiempo después de la copia de seguridad de registros Log_2, se pierden datos de la base de datos. Antes de restaurar estas tres copias de seguridad, el administrador de la base de datos debe realizar una copia de seguridad del registro activo (el final del registro). Entonces, el administrador de la base de datos restaura Db_1, Log_1 y Log_2 sin recuperar la base de datos. A continuación, el administrador de la base de datos restaura y recupera la copia de seguridad de registros después del error (Tail). Así se recupera la base de datos al momento del error, incluidos todos los datos.

- 40 -

Minimizar el riesgo de pérdida de trabajo Una vez que finaliza la primera copia de seguridad completa de la base de datos y se inician las copias de seguridad periódicas de registros, el riesgo potencial de pérdida de trabajo se limita al tiempo transcurrido entre el momento en que se daña la base de datos y la copia de seguridad periódica de registros más reciente. Por lo tanto, recomendamos que realice copias de seguridad de registros con suficiente frecuencia para mantener el riesgo de pérdida de trabajo dentro de los límites establecidos por sus requisitos empresariales. Cuando se produce un error, puede intentar realizar una copia de seguridad del registro después del error (el registro del que aún no se ha realizado una copia de seguridad). Si la copia de seguridad del registro después del error se realiza sin problemas, puede evitar cualquier pérdida de trabajo restaurando la base de datos hasta el momento del error. Puede utilizar una serie de copias de seguridad de registros para poner al día una base de datos hasta cualquier momento que se encuentre en una de las copias de seguridad de registros. Para minimizar el riesgo, recomendamos programar copias de seguridad de registros rutinarias. Tenga en cuenta que para minimizar el tiempo de restauración, puede complementar cada copia de seguridad completa con una serie de copias de seguridad diferenciales de los mismos datos. La siguiente ilustración muestra una estrategia de copia de seguridad que complementa las copias de seguridad completas de la base de datos con copias de seguridad diferenciales, así como una serie de copias de seguridad de registros rutinarias. La presencia de copias de seguridad del registro de transacciones reduce el posible riesgo de pérdida de trabajo al momento después de la copia de seguridad de registros más reciente. Tras la primera copia de seguridad de la base de datos, se realiza una serie de tres copias de seguridad diferenciales. La tercera copia de seguridad diferencial tiene el tamaño suficiente como para que la próxima copia de seguridad sea una copia de seguridad de base de datos completa. Así se establece una nueva base diferencial.

- 41 -

En esta ilustración, antes de la primera copia de seguridad de la base de datos, existe un riesgo potencial de pérdida de trabajo en la base de datos (de la hora t0 a la hora t1). Por tanto, las copias de seguridad de registros rutinarias reducen el riesgo de pérdida de trabajo a la posibilidad de perder los cambios realizados después de la última copia de seguridad de registros (realizada a la hora t14 en esta ilustración). Si se produce un error, el administrador de la base de datos debe intentar realizar inmediatamente una copia de seguridad del registro activo (el final del registro). Si esta copia de seguridad de registros después del error se realiza correctamente, la base de datos se puede restaurar hasta el momento del error.

Copias de Seguridad del Registro de Transacciones En los modelos de recuperación completa y por medio de registros de operaciones masivas, es necesario realizar copias de seguridad periódicas de los registros de transacciones (copias de seguridad de registros) para recuperar datos. Gracias a las copias de seguridad de registros es posible recuperar la base de datos en el punto en que se haya producido el error o en un momento dado. Es aconsejable realizar copias de seguridad de registros suficientemente regulares para ajustarse a los requisitos de su empresa, específicamente a la tolerancia a la pérdida de trabajo que una unidad de registro dañada podría provocar. La frecuencia adecuada para realizar copias de seguridad de registros varía en función de la tolerancia al riesgo de pérdida de trabajo y, por otra parte, de la cantidad de copias de seguridad de registros que puede almacenar, administrar y, potencialmente, restaurar. Una copia de seguridad de registros cada 15 ó 30 minutos puede ser suficiente. Si su empresa necesita minimizar el riesgo de pérdida de trabajo, piense en la posibilidad de realizar copias de seguridad de registros más frecuentemente. Al realizar copias de seguridad de registros con más frecuencia tendrá la ventaja añadida de que la frecuencia del truncamiento del registro será mayor, por lo que los archivos o archivos de registro serán más pequeños. Antes de crear la primera copia de seguridad de registros, debe crear una copia de seguridad completa, como una copia de seguridad de la base de datos o la primera de un conjunto

- 42 -

completo de copias de seguridad de archivos. La restauración de una base de datos utilizando únicamente copias de seguridad de archivos puede llegar a ser un proceso complejo. Por lo tanto, es recomendable que comience con una copia de seguridad de la base de datos completa si es posible. Posteriormente, será necesario realizar copias de seguridad del registro de transacciones con regularidad. De esta forma, no sólo se minimiza el riesgo de pérdida de trabajo, sino que también se permite el truncamiento del registro de transacciones. Normalmente, el registro de transacciones se trunca tras cada copia de seguridad de registros convencional. La cadena de registros Una secuencia continua de copias de seguridad de registros se denomina cadena de registros. Una cadena de registros empieza con una copia de seguridad completa de la base de datos. Por lo general, una nueva cadena de registros sólo se inicia cuando se realiza una copia de seguridad de la base de datos por primera vez o después de cambiar del modelo de recuperación simple al modelo de recuperación completa o por medio de registros de operaciones masivas. Para restaurar una base de datos al momento del error, es preciso que la cadena de registros esté intacta. De esta forma, es necesario que una secuencia ininterrumpida de las copias de seguridad del registro de transacciones se extienda hasta el momento del error. El lugar en el que ésta secuencia de registros debe comenzar depende del tipo de copias de seguridad de datos que esté restaurando: de base de datos, parcial o de archivos. En las copias de seguridad de base de datos o parciales, la secuencia de copias de seguridad de registros debe extenderse desde el final de la copia de seguridad de base de datos o parcial. En un conjunto de copia de seguridad de archivos, la secuencia de copias de seguridad de registros debe comenzar desde el principio del conjunto completo de copias de seguridad de archivos. Si sólo utiliza copias de seguridad de archivos, es necesario realizar una copia de seguridad del registro desde el principio de la primera copia de seguridad de archivos completa. Es posible comenzar a realizar copias de seguridad de registros inmediatamente después de la primera copia de seguridad de archivos completa. Es recomendable comenzar en ese momento, dado que la primera copia de seguridad de registros puede tardar mucho tiempo. Mientras se realiza la copia de seguridad del registro, puede realizar copias de seguridad de otros archivos. Para restaurar la base de datos sólo con copias de seguridad de archivos, el conjunto de copias de seguridad completas de archivos debe ampliarse con una o más copias de seguridad de registros que cubran el intervalo entre la primera copia de seguridad de archivos y la última. Nota: Para identificar la copia de seguridad con la que comienza la cadena de registros en un conjunto de copias de seguridad, consulte la columna begins_log_chain de la tabla backupset o ejecute RESTORE HEADERONLY en el dispositivo de copia de seguridad para ver la columna BeginsLogChain en el conjunto de resultados. Administración de registros de transacciones y modelos de recuperación Las operaciones de copia de seguridad y restauración se producen en el contexto de un modelo de recuperación. Un modelo de recuperación es una propiedad de base de datos que

controla la forma en que se registran las transacciones, si el registro de transacciones requiere que se realice la copia de seguridad y si lo permite, y qué tipos de operaciones de restauración hay disponibles. Truncamiento del registro con el modelo de recuperación completa y por medio de registros de operaciones masivas

- 43 -

En el modelo de recuperación completa o en el modelo de recuperación por medio de registros de operaciones masivas, no se puede truncar la parte inactiva del registro hasta que se hayan capturado todas sus entradas de registro en una copia de seguridad de registros. Esto es necesario para mantener la cadena de registros, una serie de entradas de registro que tienen una secuencia continua de números de secuencia de registro (LSN). El registro se trunca

cuando se realiza la copia de seguridad del registro de transacciones, siempre que se cumplan las siguientes condiciones:

Se ha producido un punto de comprobación (Checkpoint) desde la última copia de seguridad del registro. Un punto de comprobación es esencial pero no suficiente para truncar el registro en el modelo de recuperación completa o el modelo de recuperación por medio de registros de operaciones masivas. Después de un punto de comprobación, el registro se mantiene intacto, al menos hasta la siguiente copia de seguridad del registro de transacciones.

Ningún otro factor impide el truncamiento del registro. Por lo general, si se hacen copias de seguridad con regularidad, el espacio de registro se libera con la misma frecuencia para su uso futuro. Sin embargo, otros factores, como una transacción de ejecución prolongada, pueden impedir temporalmente el truncamiento del registro.

La instrucción BACKUP LOG no especifica WITH NO_TRUNCATE, WITH NO_LOG o WITH COPY_ONLY.

Cómo funciona el truncamiento del registro El truncamiento no reduce el tamaño del archivo de registro físico. Reducir el tamaño físico de un archivo de registro requiere la reducción del archivo. El registro de transacciones es un archivo de registro circular. Cuando se crea la base de datos, el archivo de registro lógico empieza por el principio del archivo de registro físico. Las nuevas entradas del registro se agregan al final del registro lógico y se expanden hacia el final del archivo físico. El registro de transacciones de una base de datos está asignado a uno o varios archivos físicos. El Motor de base de datos de SQL Server segmenta cada archivo de registro físico internamente en una serie de archivos de registro virtuales. El truncamiento del registro libera el espacio en el registro lógico a base de eliminar archivos de registro virtuales inactivos desde el principio del registro lógico. Los archivos de registro virtuales son las unidades de espacio que se pueden reutilizar. Sólo se pueden truncar los archivos de registro que contienen únicamente entradas de registro inactivas. La parte activa del registro de transacciones, el registro activo, no puede truncarse ya que se necesita para recuperar la base de datos. El punto de comprobación más reciente define el registro activo. El registro se puede truncar hasta ese punto de comprobación. Cuando se lleva a cabo el punto de comprobación, la parte inactiva del registro de transacciones se marca como reutilizable. A partir de ese momento, se puede liberar la parte inactiva mediante el truncamiento del registro. El truncamiento libera los archivos de registro virtuales para su reutilización. Finalmente, cuando se escribe una nueva entrada en un registro virtual libre, ese archivo de registro virtual pasa de nuevo a estar activo. Una parte de la información registrada en un punto de comprobación es el número de secuencia de registro (LSN) de la primera entrada del registro que debe estar presente para una reversión correcta de toda la base de datos. Este LSN se denomina LSN de recuperación mínimo (MinLSN). El inicio de la parte activa del registro es el registro virtual que contiene el

MinLSN. Cuando se trunca un registro de transacciones, sólo se liberan para su reutilización las entradas del registro por delante de este archivo de registro virtual. En la siguiente ilustración se muestra un registro de transacciones antes y después del truncamiento. En la primera ilustración se muestra un registro de transacciones que no se ha truncado nunca. El registro lógico tiene actualmente cuatro archivos de registro virtuales en uso. El registro lógico empieza por delante del primer archivo de registro virtual y termina en el

- 44 -

registro virtual 4. La entrada MinLSN se encuentra en el registro virtual 3. Los registros virtuales 1 y 2 sólo contienen entradas de registro inactivas. Estas entradas pueden truncarse. El registro virtual 5 no se utiliza aún y no forma parte del registro lógico actual.

En la segunda ilustración se muestra el registro después del truncamiento. Se han liberado los registros virtuales 1 y 2 para su reutilización. El registro lógico empieza ahora en el inicio del registro virtual 3. El registro virtual 5 no se utiliza aún y no forma parte del registro lógico actual.

Cómo funcionan las copias de seguridad diferenciales Este tema es relevante para todos los tipos de base de datos. Una copia de seguridad diferencial se basa en la copia de seguridad completa más reciente existente. Esto se denomina base del diferencial. Una copia de seguridad diferencial incluye sólo los datos que han cambiado desde la última base diferencial. El tamaño de una copia de seguridad diferencial depende de la cantidad de datos que han cambiado desde la base. Como regla general, cuanto más antigua sea una base, más grande será una nueva copia de seguridad diferencial. Una copia de seguridad diferencial captura el estado de las extensiones modificadas en el momento en que se crea la copia de seguridad. Si crea una serie de copias de seguridad diferenciales, es probable que una extensión actualizada con frecuencia contenga datos diferentes en cada una de las copias diferenciales. A medida que se incrementa el tamaño de las copias de seguridad diferenciales, la restauración de una copia de seguridad diferencial puede incrementar sensiblemente el tiempo necesario para restaurar una base de datos. Por ello, recomendamos que realice una copia de seguridad completa a intervalos definidos para establecer una nueva base diferencial para los datos. Por ejemplo, cada semana podría realizar una copia de seguridad completa de toda la base de datos (es decir, una copia de seguridad completa de la base de datos) seguida de una serie de copias de seguridad diferenciales de la base de datos realizadas periódicamente durante la semana. En la siguiente ilustración se muestra cómo funciona una copia de seguridad diferencial. La ilustración muestra 24 extensiones de datos, 6 de las cuales han cambiado. La copia de seguridad diferencial sólo contiene estas 6 extensiones de datos. La operación de copia de seguridad diferencial se basa en una página de mapa de bits que contiene un bit por cada extensión. Por cada extensión actualizada desde que se creó la base, el bit se establece en 1 en el mapa de bits.

- 45 -

Nota: El mapa de bits de la copia de seguridad diferencial no se actualiza con las copias de seguridad de sólo copia. Por tanto, una copia de seguridad de sólo copia no puede servir de base diferencial o copia de seguridad diferencial. Una copia de seguridad de sólo copia no afecta a las copias de seguridad diferenciales subsiguientes. Una copia de seguridad diferencial que se realiza poco después de su base tiende a ser sustancialmente más pequeña que la base diferencial. Así, se gana espacio de copia de seguridad y tiempo. Sin embargo, a medida que la base de datos cambia, la diferencia entre la base de datos y una base diferencial concreta aumenta. Cuanto más tiempo pasa entre una copia de seguridad diferencial y su base, más probabilidades hay de que la copia de seguridad diferencial sea más grande. Esto significa que las copias de seguridad diferenciales pueden, a la larga, asemejarse en tamaño a la base diferencial. La copia de seguridad diferencial grande pierde las ventajas de una copia de seguridad más rápida y de menor tamaño. En el momento de la restauración, antes de restaurar una copia de seguridad diferencial, debe restaurar su base. A continuación, sólo necesita restaurar la copia diferencial más reciente para poner al día la base de datos hasta el momento en que se creó la copia de seguridad diferencial. Por lo general, restaurará la copia de seguridad completa más reciente seguida de la copia de seguridad diferencial más reciente que está basada en la copia de seguridad completa. Al crear y restaurar copias de seguridad diferenciales, SQL Server 2005 trata la base de datos como un conjunto de archivos. Esto afecta al contenido de las copias de seguridad diferenciales y al modo en que se utilizan en combinación con las copias de seguridad de bases de datos y de archivos. SQL Server Database Engine (Motor de base de datos de SQL Server) está diseñado para tratar los escenarios habituales fácilmente y sin ningún comportamiento inesperado. Copias de seguridad diferenciales de archivos Una copia de seguridad diferencial de archivos necesita una copia de seguridad completa de archivos como base. La copia de seguridad diferencial de archivos supone una forma rápida de crear copias de seguridad de archivos actuales y, además, ocupa poco espacio. En el modelo de recuperación simple, las copias de seguridad diferenciales de archivos se habilitan únicamente para los grupos de archivos de sólo lectura. En el modelo de recuperación completa, las copias de

- 46 -

seguridad diferenciales de archivos están permitidas en todos los grupos de archivos que tengan una base diferencial. Las copias de seguridad diferenciales de archivos pueden disminuir significativamente el tiempo de recuperación reduciendo la porción del registro de transacciones que debe restaurarse. Se recomienda utilizar las copias de seguridad diferenciales de archivos en las siguientes situaciones:

A algunos archivos se les hacen copias de seguridad con menor frecuencia que a otros.

Los archivos son grandes y los datos se actualizan con poca frecuencia, o bien se actualizan los mismos datos de forma repetida.

Importante: Evite el uso de copias de seguridad de bases de datos diferenciales y de archivos diferenciales en la misma base de datos. Copia de seguridad diferencial de grupos de archivos (filegroups) de sólo lectura en bases de datos de lectura y escritura Las copias de seguridad diferenciales de una base de datos de lectura y escritura funcionan correctamente aunque uno de los grupos de archivos fuera de sólo lectura cuando se creó la base diferencial. Como con cualquier copia de seguridad diferencial de una base de datos de lectura y escritura, el Motor de base de datos de SQL Server registra la base diferencial en el archivo principal. Nota: Para una base de datos de sólo lectura, el mapa de bits diferencial del archivo principal no se puede actualizar durante una copia de seguridad. Copia de seguridad de un grupo de archivos (filegroups) principalmente de sólo lectura En un grupo de archivos principalmente de sólo lectura, la mayor parte del tiempo el grupo de archivos es de sólo lectura pero, ocasionalmente, pasa a ser de lectura y escritura durante breves períodos de mantenimiento. Por ejemplo, un archivo de grupos que normalmente es de sólo lectura se puede establecer temporalmente como de lectura y escritura para permitir que los archivos se importen de forma masiva y, posteriormente, se restablece a sólo lectura. Una vez se hayan completado las actualizaciones, puede proteger los datos nuevos haciendo una copia de seguridad del grupo de archivos. La recomendación para esta copia de seguridad varía en función de cuánto ha cambiado el archivo:

Si el grupo de archivos ha cambiado significativamente y sigue siendo de lectura y escritura, realice una copia de seguridad completa de archivos. Dado que el grupo de archivos sigue siendo de lectura y escritura, la operación de copia de seguridad puede restablecer el mapa de bits diferencial para preparar una serie de copias de seguridad diferenciales nuevas. A continuación, cambie el grupo de archivos a sólo lectura nuevamente y cree inmediatamente una copia de seguridad diferencial de archivos para poder restaurar el grupo de archivos, que ahora es de sólo lectura.

Si el grupo de archivos no ha cambiado mucho desde la última copia de seguridad completa de archivos, asumiendo que existe una copia de seguridad completa de archivos como base diferencial, establezca el grupo de archivos como de sólo lectura de nuevo inmediatamente y, a continuación, cree una copia de seguridad diferencial de archivos.

Nota: La propiedad IsReadOnly se establece en un grupo de archivos, no en archivos individuales. Si un grupo de archivos es de sólo lectura (es decir, si la propiedad IsReadOnly es TRUE para el grupo de archivos), todos los archivos del grupo son de sólo lectura.

- 47 -

Copias de seguridad diferenciales parciales Las copias de seguridad diferenciales parciales se utilizan sólo con las copias de seguridad parciales. Una copia de seguridad diferencial parcial únicamente registra las extensiones de datos que han cambiado en grupos de archivos desde la copia de seguridad parcial anterior, que se conoce como la base para la diferencial. Si sólo han cambiado algunos de los datos capturados en la copia de seguridad parcial, la copia de seguridad diferencial parcial será menor que la base y más rápida de crear. En una base de datos grande, una copia de seguridad diferencial facilita la realización de copias de seguridad frecuentes de los datos, lo que disminuye el riesgo de pérdida de datos. Sin embargo, la restauración a partir de copias de seguridad diferenciales parciales implicará necesariamente más pasos y más tiempo que la restauración a partir de una copia de seguridad parcial. Además, el proceso de restauración es más complejo dado que intervienen dos archivos de copia de seguridad. Las copias de seguridad diferenciales parciales se utilizan con una base diferencial única. Crear una copia de seguridad diferencial de archivos La sintaxis de BACKUP necesaria para crear una copia de seguridad diferencial de archivos

es: BACKUP DATABASE database_name <file_or_filegroup> [ ,...n] TO <backup_device>

WITH DIFFERENTIAL También puede utilizar la herramienta SQL Server Management Studio

- 48 -

Consideraciones para el operador de las Copias de Seguridad El operador de las copias de seguridad deberá ser miembro de alguna de las funciones fijas de seguridad mencionadas a continuación:

sysadmin (función fija de servidor) db_owner (función fija de base de datos) db_backupoperator (función fija de base de datos)

- 49 -

3- Restauración de Bases de Datos de Usuario Descripción de cómo funcionan la restauración y la recuperación de copias de seguridad en SQL Server La restauración es el proceso de copiar datos desde una copia de seguridad y aplicar transacciones registradas a los datos para ponerlos al día hasta el punto de recuperación de destino. Una copia de seguridad de datos o diferencial contiene suficientes registros de transacciones para permitir poner al día las transacciones activas como parte de la restauración de cada copia de seguridad. Cada copia de seguridad contiene suficientes registros para revertir las transacciones no confirmadas y llevar la base de datos a un estado coherente con la transacción y utilizable. El proceso de poner al día las transacciones no confirmadas, si las hay, y poner la base de datos en conexión se conoce como recuperación. Conjunto de puestas al día El proceso de aplicar cambios registrados a los datos de una base de datos para poner los datos al día se conoce como poner al día. El conjunto de todos los datos restaurados se conoce como el conjunto de puestas al día. Un conjunto de puestas al día se define con la restauración de una o más copias de seguridad completas, como una copia de seguridad de base de datos o parcial, o un conjunto de copias de seguridad de archivos. Si una instrucción RESTORE especifica grupos de archivos, archivos o páginas, sólo se incluyen estos elementos

en el conjunto de puestas al día. De lo contrario, se incluirán en el conjunto de puestas al día todos los archivos de la copia de seguridad que se está restaurando. Si la copia de seguridad completa contiene entradas de registro, los datos restaurados se pondrán al día mediante este registro. Nota: Si especifica un grupo de archivos durante la restauración, ésta engloba todo el grupo de archivos tal como existe actualmente. Esto incluye los archivos agregados al grupo de archivos desde que se realizó la copia de seguridad. Para copias de seguridad diferenciales, si se agregaron archivos a la base de datos desde la base diferencial, la restauración de una copia de seguridad diferencial podría sobrescribir páginas del conjunto de puestas al día con datos de la copia de seguridad diferencial. La restauración de una copia de seguridad diferencial sólo actualiza una página si ésta está en el conjunto de puestas al día; la página se incluye en la copia de seguridad y la instrucción RESTORE muestra la página o su archivo o no muestra ningún archivo ni página.

Con los modelos de recuperación completa y de recuperación por medio de registros de operaciones masivas, se debe realizar una copia de seguridad independiente del registro. Después de restaurar copias de seguridad de datos y (opcionalmente) diferenciales, en general debería restaurar las copias de seguridad de registros subsiguientes para llevar la base de datos al punto de error. Restaurar una copia de seguridad de registros pone al día todas las páginas del conjunto de puestas al día. Secuencias de restauración Cada escenario de restauración se implementa mediante uno o varios pasos de restauración (operaciones), lo que se denomina secuencia de restauración. Cada operación corresponde a una instrucción RESTORE de Transact-SQL independiente. Una secuencia de restauración

mueve los datos afectados a través de una o varias fases de la restauración. Fases de la restauración Una restauración es un proceso de varias fases. Las fases posibles de una restauración incluyen las fases de copia de datos, rehacer (puesta al día) y deshacer (revertir):

- 50 -

La fase de copia de datos implica copiar todos los datos, el registro y las páginas de

índice desde el medio de copia de seguridad de una base de datos a los archivos de la base de datos.

La fase de rehacer aplica las transacciones registradas a los datos copiados desde la copia de seguridad para poner al día esos datos hasta el punto de recuperación. Normalmente, en este punto una base de datos tiene transacciones no confirmadas y se encuentra en un estado inutilizable. En ese caso, se requiere una fase de deshacer como parte de la recuperación de la base de datos.

La fase de deshacer, que es la primera parte de la recuperación, revierte cualquier transacción no confirmada y hace que la base de datos esté disponible para los usuarios. Después de la fase de reversión, no se pueden restaurar las copias de seguridad subsiguientes.

Fase de copia de datos La primera fase de todo proceso de restauración es la fase de copia de datos. La fase de copia de datos inicializa el contenido de la base de datos, los archivos o las páginas que se restauran. Esta fase se realiza mediante las operaciones de restaurar la base de datos, restaurar archivos y restaurar páginas utilizando copias de seguridad completas o diferenciales. La fase de copia de datos implica copiar datos de una o más copias de seguridad completas y, de forma opcional, copias de seguridad diferenciales y, a continuación, restablecer el contenido de la base de datos, los archivos o las páginas afectados en el momento en que fueron capturados por esas copias de seguridad. El archivo o la página más antiguo del conjunto de puestas al día determina el punto de inicio de la siguiente fase: rehacer (puesta al día). Fase de rehacer (puesta al día) Rehacer (o puesta al día) es el proceso de rehacer los cambios registrados hasta los datos del conjunto de puestas al día para avanzar los datos en el tiempo. Para llevar a cabo la puesta al día, el Motor de base de datos de SQL Server procesa las copias de seguridad de registros conforme se restauran, empezando por el registro contenido en las copias de seguridad completas. La restauración evita las puestas al día innecesarias. Generalmente, si los datos eran de sólo lectura cuando se realizó la copia de seguridad y han permanecido como de sólo lectura, la puesta al día es innecesaria y se omite. El objetivo de la puesta al día es devolver los datos a su estado original en el punto de recuperación. El punto de recuperación es el punto hasta el que el usuario especifica que

debe recuperarse el conjunto de datos. Con el modelo de recuperación completa, puede especificar el punto de recuperación como un momento determinado, una transacción marcada o un número de secuencia de registro. Con el modelo de recuperación por medio de registros de operaciones masivas, sólo puede realizar la restauración a un momento dado si no se ha realizado ninguna operación masiva desde la copia de seguridad de registros anterior. En la fase de rehacer, los datos siempre se ponen al día hasta un punto que es coherente para rehacer con el estado de la base de datos en el punto de recuperación. Todos los datos se han puesto al día hasta un punto en el que se puede realizar la operación de deshacer. El archivo principal define el estado de la base de datos, como se indica a continuación:

Si el archivo principal se está restaurando, el punto de recuperación determina el estado de toda la base de datos. Por ejemplo, si una base de datos se está recuperando a un momento dato justo antes de que la tabla se quitara accidentalmente, toda la base de datos debe restaurarse al mismo momento dado.

Si el archivo principal no se está restaurando, el estado de la base de datos es conocido y los datos restaurados se ponen al día hasta un punto de recuperación transaccionalmente coherente con la base de datos. SQL Server lo exige.

- 51 -

Sin embargo, la base de datos puede contener cambios realizados por transacciones que no están confirmadas en el punto de recuperación. Para la restauración con conexión, los datos se recuperan a un momento dado coherente con el estado actual de la parte conectada de la base de datos. Una copia de seguridad diferencial avanza hasta el punto en que se realizó la copia de seguridad diferencial. Las páginas del conjunto de puestas al día se sobrescriben con páginas más recientes de la copia de seguridad diferencial. Fase de deshacer (revertir) y recuperación Después de que la fase de rehacer haya puesto al día todas las transacciones del registro, una base de datos suele contener los cambios realizados por las transacciones no confirmadas en el punto de recuperación. Esto convierte los datos puestos al día en transaccionalmente incoherentes. El proceso de recuperación abre el registro de transacciones para identificar las transacciones no confirmadas. Las transacciones no confirmadas se deshacen mediante la reversión, a menos que mantengan bloqueos que eviten que otras transacciones vean datos transaccionalmente incoherentes. Este paso se denomina fase de deshacer (o revertir). Si los datos ya son transaccionalmente coherentes al inicio del proceso de recuperación, la fase de deshacer se omitirá. Después de que la base de datos sea transaccionalmente coherente, la recuperación conecta la base de datos. Nota: En términos generales, la recuperación es el conjunto de operaciones que hace que una base de datos sea coherente al inicio de esa base de datos. Si la base de datos se apagaba periódicamente, la recuperación omite las fases de rehacer y deshacer. Esto se conoce como recuperación de reinicio. Después de que se hayan restaurado una o más copias de seguridad, la recuperación suele incluir tanto la fase de rehacer y como la de deshacer. Cada copia de seguridad completa y diferencial contiene suficientes registros de transacciones para permitir que los datos de esa copia de seguridad se recuperen a un estado coherente consigo mismo. Nota: Durante una recuperación tras bloqueo o una conmutación por error de la creación de reflejo de la base de datos, SQL Server 2005 Enterprise Edition permite a los usuarios obtener acceso a la base de datos durante la fase de deshacer. Esto se conoce como recuperación rápida. La recuperación rápida es posible porque las transacciones que no estaban confirmadas cuando se produjo el error vuelven a adquirir los bloqueos que mantenían antes del error. Mientras estas transacciones se revierten, sus bloqueos las protegen de las interferencias de los usuarios. Opciones RECOVERY y NORECOVERY Una instrucción RESTORE específica termina después de la fase de rehacer o continúa con la fase de deshacer, según si la instrucción especificó WITH NORECOVERY, de la manera

siguiente: WITH RECOVERY: Recupera la base de datos e incluye las fases de rehacer y

deshacer; no se pueden restaurar otras copias de seguridad. Es el valor predeterminado. Si el conjunto de puestas al día no se ha puesto al día lo suficiente para ser coherente con la base de datos, la fase de deshacer no se podrá producir. El Motor de base de datos emitirá un error y la recuperación se detendrá. Si todo el conjunto de puestas al día es coherente con la base de datos, se realizará la recuperación y se podrá conectar la base de datos.

WITH NORECOVERY: Omite la fase de deshacer para preservar las transacciones no

confirmadas. Al omitir la fase de deshacer, se pueden restaurar otras copias de seguridad para poner al día la base de datos a un momento posterior. A veces,

- 52 -

RESTORE WITH NORECOVERY pone al día los datos hasta donde son coherentes

con la base de datos. En estos casos, el Motor de base de datos emite un mensaje informativo indicando que el conjunto de puestas al día se puede recuperar mediante la opción RECOVERY.

Restaurar una base de datos cuando SQL Server no está conectado Es posible restaurar y recuperar una base de datos mediante SQL Writer mientras SQL Server no está conectado si no hay ningún catálogo de texto. Si hay un catálogo de texto asociado a una base de datos, primero es necesario iniciar SQL Server o detener el servicio Motor de texto completo de Microsoft para SQL Server (MSFTESQL).

Al ejecutarse, SQL Server obliga a cerrar los archivos del catálogo de texto como preparación para la operación de restauración. Sin embargo, si SQL Server está sin conexión, es posible que MSFTESQL mantenga abiertos determinados archivos de texto. Así se evita que la aplicación de restauración los sobrescriba. Para obligar a esos archivos de texto a cerrarse, una aplicación puede apagar MSFTESQL. Para evitar tener que hacer esto, realice alguna de las siguientes acciones:

Inicie SQL Server Detenga MSFTESQL

Escenarios de restauración Un escenario de restauración en SQL Server es el proceso de restaurar datos de una o más copias de seguridad y, a continuación, recuperar la base de datos. Los escenarios de restauración compatibles dependen del modelo de recuperación de la base de datos y de la edición de SQL Server 2005. La siguiente tabla presenta los posibles escenarios de restauración compatibles para diferentes modelos de recuperación.

Escenario de restauración Modelo de recuperación simple

Modelos de recuperación completa o por medio de registros de operaciones masivas

Restauración completa de la base de datos

Es la estrategia de restauración básica. Una restauración de base de datos completa puede implicar simplemente la restauración y recuperación de una copia de seguridad completa de base de datos. Por otra parte, una restauración de base de datos completa puede consistir en restaurar una copia de seguridad completa de base de datos y, luego, restaurar y recuperar una copia de seguridad diferencial.

Es la estrategia de restauración básica. Una restauración completa de una base de datos supone restaurar una copia de seguridad completa de base de datos y, opcionalmente, una copia de seguridad diferencial (si existe), además de restaurar todas las copias de seguridad de registros posteriores (en orden secuencial). La restauración completa de base de datos finaliza al recuperar la última copia de seguridad de registros y restaurarla (RESTORE WITH RECOVERY).

Restauración de archivos*

Restauración de uno o más archivos de sólo lectura dañados, sin restaurar la base de datos completa. La restauración de archivos está disponible sólo si la base de datos tiene como mínimo un grupo de archivos de sólo lectura.

Restaura uno o más archivos, sin restaurar la base de datos completa. La restauración de archivos puede realizarse mientras la base de datos está desconectada o, en algunas versiones de SQL Server 2005, cuando está conectada. Durante la restauración de archivos, los grupos de archivos en los que se incluyen los archivos en cuestión permanecen siempre desconectados.

Restauración de páginas

No aplicable Restaura una o más páginas dañadas. La restauración de páginas puede realizarse mientras la base de datos está desconectada o,

- 53 -

en algunas versiones de SQL Server 2005, cuando está conectada. Durante la restauración de páginas, las páginas que se están restaurando permanecen siempre desconectadas.

Es preciso que haya disponible una cadena intacta de copias de seguridad de registros, hasta el archivo de registro actual, y deben aplicarse todas a fin de actualizar la página según el archivo de registro actual.

Restauración por etapas *

Restauración y recuperación de la base de datos por etapas a nivel de grupo de archivos, empezando por el grupo de archivos principal y todos los grupos de archivos secundarios de lectura y escritura.

Restauración y recuperación de la base de datos por etapas a nivel del grupo de archivos, empezando por el grupo de archivos principal.

* La restauración con conexión sólo se permite en SQL Server 2005 Enterprise Edition. Independientemente de la forma de restauración de datos, antes de que una base de datos se pueda recuperar, el Motor de base de datos de SQL Server garantiza la coherencia lógica de toda la base de datos. Por ejemplo, si restaura un archivo, no puede recuperarlo y conectarlo hasta que se haya puesto al día hasta un punto lo bastante avanzado de forma que sea coherente con la base de datos. Modelos de recuperación y operaciones de restauración admitidas Las operaciones de restauración disponibles para una base de datos dependen de su modelo de recuperación. En la tabla siguiente se resumen todos los modelos de recuperación y las diferentes situaciones de restauración en las que funcionarían.

Operación de restauración

Modelo de recuperación completa

Modelo de recuperación por medio de registros de operaciones masivas

Modelo de recuperación simple

Recuperación de datos

Recuperación completa (si el registro está disponible).

Existe el riesgo de perder algunos datos.

Se perderán los datos desde la última copia de seguridad completa o diferencial.

Restauración a un momento dado

Cualquier momento cubierto por las copias de seguridad de registros.

No está permitida si la copia de seguridad de registros contiene algún cambio registrado de forma masiva.

No compatible.

Restauración de archivos*

Totalmente compatible. A veces* Sólo está disponible para archivos secundarios de sólo lectura.

Restauración de páginas*

Totalmente compatible. A veces Ninguna.

Restauración por etapas (de grupos de archivos)*

Totalmente compatible. A veces Sólo está disponible para archivos secundarios de sólo lectura.

- 54 -

* Sólo disponible en SQL Server 2005 Enterprise Edition. Restaurar una copia de seguridad completa de la base de datos La sintaxis RESTORE básica para restaurar una copia de seguridad de la base de datos es:

RESTORE DATABASE nombre_basedatos FROM dispositivo [ WITH NORECOVERY ] Nota: Use WITH NORECOVERY si también desea restaurar una copia de seguridad diferencial de la base de datos. Restauración de base de datos completa (modelo de recuperación simple) El objetivo de una restauración completa de la base de datos es restaurar la base de datos completa. Durante el proceso de restauración, la base de datos completa se encuentra sin conexión. Antes de que ninguna parte de la base de datos tenga conexión, se recuperan todos los datos a un punto coherente en el que todas las partes de la base de datos se encuentran en el mismo momento y en el que no existe ninguna transacción sin confirmar. En el modelo de recuperación simple, no se puede restaurar la base de datos a un momento concreto de una copia de seguridad específica. Una restauración completa de base de datos con el modelo de recuperación simple implica una o dos instrucciones RESTORE, en función de si se debe restaurar o no una copia de seguridad

diferencial de la base de datos. Si sólo usa copias de seguridad completas de la base de datos, restaure sólo la copia de seguridad más reciente. Si también usa una copia de seguridad diferencial de la base de datos, restaure la copia de seguridad completa más reciente de la base de datos sin recuperar la base de datos y, a continuación, restaure la copia de seguridad diferencial más reciente de la base de datos y recupere la base de datos. Al restaurar completamente una base de datos, debe utilizar una única secuencia de restauración. En el siguiente ejemplo se muestran las opciones críticas de una secuencia de restauración en un escenario de restauración de base de datos completa. Una secuencia de restauración está formada por una o más operaciones de restauración que mueven los datos mediante una o varias fases de restauración. La sintaxis y los detalles no relevantes para este propósito se omiten. La base de datos se restaura a su estado de copia de seguridad completa de base de datos. Al recuperar una base de datos, se recomienda especificar explícitamente la opción RECOVERY

por motivos de claridad, aunque es la opción predeterminada. Ejemplo: En el siguiente ejemplo se muestra primero cómo usar la instrucción BACKUP para crear una copia de seguridad completa y diferencial de la base de datos AdventureWorks. A continuación, se restauran estas copias de seguridad una después de la otra. Nota: En el ejemplo se comienza con una instrucción ALTER DATABASE que establece el modelo de recuperación como SIMPLE. USE master; -- Establece el modelo Simple ALTER DATABASE AdventureWorks SET RECOVERY SIMPLE; GO -- Back up Completo de la base de datos AdventureWorks. BACKUP DATABASE AdventureWorks TO DISK = 'Z:\SQLServerBackups\AdventureWorks.bak'

- 55 -

WITH FORMAT; GO --Crea Backuo diferencial. BACKUP DATABASE AdventureWorks TO DISK = 'Z:\SQLServerBackups\AdventureWorks.bak' WITH DIFFERENTIAL; GO -- Restauración completa del backup completo. RESTORE DATABASE AdventureWorks FROM DISK = 'Z:\SQLServerBackups\AdventureWorks.bak' WITH FILE=1, NORECOVERY; -- Restauración diferencial. RESTORE DATABASE AdventureWorks FROM DISK = 'Z:\SQLServerBackups\AdventureWorks.bak' WITH FILE=2, RECOVERY; GO Restauración por etapas de la base de datos (modelo de recuperación completa) En una secuencia de restauración por etapas se restaura y recupera una base de datos en fases en el nivel del grupo de archivos, empezando con los grupos de archivos principales, los de lectura y escritura, y los secundarios. En este ejemplo, la base de datos adb se restaura en un nuevo equipo después de un desastre. La base de datos está utilizando el modelo de recuperación completa, por lo que, antes de iniciar la restauración, debe crearse una copia de seguridad de registros después del error de la base de datos. Antes del desastre, todos los grupos de archivos están conectados. El grupo de archivos B es de sólo lectura. Se deben restaurar todos los grupos de archivos secundarios, pero por orden de importancia: A (el de mayor importancia), C y, por último, B. En este ejemplo, hay cuatro copias de seguridad de registros, incluida la copia de seguridad de registros después del error. Antes de restaurar la base de datos, el administrador debe realizar una copia de seguridad de registros después del error. Dado que la base de datos está dañada, esta copia de seguridad debe crearse con la opción NO_TRUNCATE:

BACKUP LOG adb TO tailLogBackup WITH NORECOVERY, NO_TRUNCATE La copia de seguridad de registros después del error es la última copia de seguridad que se aplica en las secuencias de restauración siguientes.

a. Restauración parcial del grupo de archivos principal y secundario A: RESTORE DATABASE adb FILEGROUP='Primary' FROM backup1 WITH PARTIAL, NORECOVERY RESTORE DATABASE adb FILEGROUP='A' FROM backup2 WITH NORECOVERY RESTORE LOG adb FROM backup3 WITH NORECOVERY RESTORE LOG adb FROM backup4 WITH NORECOVERY RESTORE LOG adb FROM backup5 WITH NORECOVERY RESTORE LOG adb FROM tailLogBackup WITH RECOVERY

- 56 -

b. Restauración con conexión del grupo de archivos C. En este momento, el grupo de archivos principal y el secundario A están conectados. Todos los archivos de los grupos de archivos B y C están pendientes de recuperación y sin conexión. Los mensajes de la última instrucción RESTORE LOG del paso 1 indican que la reversión de las transacciones en las que interviene el grupo de archivos C se ha diferido porque este grupo de archivos no está disponible. Las operaciones periódicas pueden continuar, pero estas transacciones mantienen los bloqueos y no se truncará el registro hasta que se pueda completar la reversión. En la segunda secuencia de restauración, el administrador de la base de datos restaura el grupo de archivos C: RESTORE DATABASE adb FILEGROUP='C' FROM backup2a WITH NORECOVERY RESTORE LOG adb FROM backup3 WITH NORECOVERY RESTORE LOG adb FROM backup4 WITH NORECOVERY RESTORE LOG adb FROM backup5 WITH NORECOVERY RESTORE LOG adb FROM tailLogBackup WITH RECOVERY

En este momento, los grupos de archivos principal, A y C están conectados. Los archivos del grupo B permanecen pendientes de recuperación, con el grupo de archivos sin conexión. Las transacciones diferidas se han resuelto y se trunca el registro. c. Restauración con conexión del grupo de archivos B. En la tercera secuencia de restauración, el administrador de la base de datos restaura el grupo de archivos B. La copia de seguridad del grupo de archivos B se realizó después de cambiar el grupo a sólo lectura, por lo que no es necesario ponerlo al día durante la recuperación. RESTORE DATABASE adb FILEGROUP='B' FROM backup2b WITH RECOVERY Restauración por etapas para algunos grupos de archivos (modelo de recuperación simple) En una secuencia de restauración por etapas restaura y recupera una base de datos en fases en el nivel del grupo de archivos, empezando con los grupos de archivos principales y todos los secundarios de lectura y escritura. En este ejemplo, la base de datos adb se restaura en un nuevo equipo después de un desastre. La base de datos utiliza el modelo de recuperación simple. Antes del desastre, todos los grupos de archivos están conectados. Los grupos de archivos A y C son de lectura y escritura, y el grupo de archivos B es de sólo lectura. El grupo de archivos B pasó a ser de sólo lectura antes de la copia de seguridad parcial más reciente, que contiene el grupo de archivos principal y los grupos de archivos secundarios de lectura y escritura, A y C. Después de que el grupo de archivos B pasara a ser de sólo lectura, se realizó una copia de seguridad de archivos independiente del grupo de archivos B. a. Restauración parcial del grupo de archivos principal y los grupos de archivos A y C. RESTORE DATABASE adb FILEGROUP='A',FILEGROUP='C' FROM partial_backup WITH PARTIAL, RECOVERY; b. En este momento, los grupos de archivos principal, A y C están conectados. Todos los archivos del grupo de archivos B están pendientes de recuperación y el grupo de archivos está sin conexión.

- 57 -

RESTORE DATABASE adb FILEGROUP='B' FROM backup WITH RECOVERY; Todos los grupos de archivos están ahora conectados. Restauración por etapas para algunos grupos de archivos (modelo de recuperación completa) En una secuencia de restauración por etapas restaura y recupera una base de datos en fases en el nivel del grupo de archivos, empezando con los grupos de archivos principales y todos los secundarios de lectura y escritura. En este ejemplo, una base de datos llamada adb, que utiliza el modelo de recuperación completa, contiene tres grupos de archivos. El grupo de archivos A es de lectura y escritura, mientras que los grupos de archivos B y C son de sólo lectura. Inicialmente, los tres están conectados. Parece que el grupo de archivos principal y el B de la base de datos adb están dañados. El grupo de archivos principal es bastante más que pequeño y puede restaurarse con rapidez. El administrador de la base de datos decide restaurarlos utilizando una secuencia de restauración por etapas. En primer lugar se restauran el grupo de archivos principal y los registros de transacciones posteriores y luego se recupera la base de datos. Los grupos de archivos intactos A y C incluyen información fundamental. Por lo tanto, se recuperarán a continuación para conectarlos tan pronto como sea posible. Por último, se restaurará y recuperará el grupo de archivos secundario dañado, el B. a. Crea una copia de seguridad de registros después del error de la base de datos adb. Este paso es esencial para actualizar los grupos de archivos A y C intactos respecto al punto de recuperación de la base de datos. BACKUP LOG adb TO tailLogBackup WITH NORECOVERY b. Restauración parcial del grupo de archivos principal. RESTORE DATABASE adb FILEGROUP='Primary' FROM backup WITH PARTIAL, NORECOVERY RESTORE LOG adb FROM backup1 WITH NORECOVERY RESTORE LOG adb FROM backup2 WITH NORECOVERY RESTORE LOG adb FROM backup3 WITH NORECOVERY RESTORE LOG adb FROM tailLogBackup WITH RECOVERY En este momento, el grupo principal está conectado. La recuperación de los archivos de los grupos A, B y C está pendiente, por lo que estos grupos de archivo están desconectados. c. Restauración con conexión de los grupos de archivos A y C. Dado que estos datos no están dañados, no es preciso restaurar los grupos de archivos a partir de la copia de seguridad. Sin embargo, es necesario recuperarlos para volver a conectarlos. El administrador de la base de datos recupera A y C inmediatamente. RESTORE DATABASE adb FILEGROUP='A', FILEGROUP='C' WITH RECOVERY En este momento, los grupos de archivos principal, A y C están conectados. Los archivos del grupo B permanecen pendientes de recuperación, con el grupo de archivos sin conexión. d. Restauración con conexión del grupo de archivos B.

- 58 -

Los archivos del grupo de archivos B se restauran en cualquier momento a partir de este momento. Nota: La copia de seguridad del grupo de archivos B se realizó después de cambiar el grupo a sólo lectura, por lo que no es necesario poner al día los archivos. RESTORE DATABASE adb FILEGROUP='B' FROM backup WITH RECOVERY Ahora todos los grupos de archivos están conectados. Restauración con conexión de un archivo de sólo lectura (modelo de recuperación simple) El modelo de recuperación simple permite restaurar un archivo de sólo lectura con conexión si existe una copia de seguridad realizada después de que el archivo pasara a ser de sólo lectura por última vez. En este ejemplo, la base de datos adb contiene tres grupos de archivos. El grupo de archivos A es de lectura y escritura, mientras que los grupos de archivos B y C son de sólo lectura. Inicialmente, los tres están conectados. Se debe restaurar el archivo de sólo lectura b1 del grupo de archivos B. El administrador de la base de datos puede restaurarlo mediante una copia de seguridad realizada después de que el archivo pasara a ser de sólo lectura. Durante la restauración, el grupo de archivos B permanecerá sin conexión, pero el resto de la base de datos estará conectada. Para restaurar el archivo, el administrador de la base de datos utiliza la siguiente secuencia de restauración: RESTORE DATABASE adb FILE='b1' FROM filegroup_B_backup WITH RECOVERY Ahora el archivo está conectado. Aplicar copias de seguridad del registro de transacciones Este tema sólo es relevante para el modelo de recuperación completa o para el modelo de recuperación optimizado para cargas masivas de registros. En este tema se describe la aplicación de copias de seguridad del registro de transacciones como parte de la restauración de una base de datos de SQL Server. Para aplicar una copia de seguridad del registro de transacciones, deben cumplirse los requisitos siguientes:

Primero debe restaurarse la copia de seguridad diferencial de la base de datos o la copia de seguridad completa inmediatamente anterior de la base de datos.

Todos los registros de transacciones creados después de esa copia de seguridad completa o diferencial de la base de datos deben restaurarse en orden cronológico. Si se pierde o se daña una copia de seguridad del registro de transacciones en esta cadena de registros, sólo puede restaurar los registros de transacciones anteriores al registro de transacciones que falta.

Todavía no se ha recuperado la base de datos. No se puede recuperar la base de datos hasta que se haya aplicado el registro de transacciones final. Si recupera la base de datos después de restaurar una de las copias de seguridad intermedias del registro de transacciones, anterior al final de la cadena de registros, no podrá restaurar la base de datos más allá de ese punto sin reiniciar toda la secuencia de restauración, empezando por la copia de seguridad completa de la base de datos.

Registros de transacciones y recuperación

- 59 -

Cuando termina la operación de restauración y recupera la base de datos, la recuperación revierte todas las transacciones incompletas. Este paso se conoce como la fase de deshacer.

Revertir es necesario para restaurar la integridad de la base de datos. Después de la reversión, la base de datos pasa a estar en línea y no se pueden aplicar más copias de seguridad del registro de transacciones a la base de datos. Por ejemplo, una serie de copias de seguridad del registro de transacciones contiene una transacción de larga duración. El inicio de la transacción se registra en la primera copia de seguridad del registro de transacciones, pero el final de la transacción se registra en la segunda copia de seguridad. En la primera copia de seguridad del registro de transacciones no se registra ninguna operación de confirmación o reversión. Si se ejecuta una operación de recuperación cuando se aplica la primera copia de seguridad del registro de transacciones, la transacción de larga ejecución se trata como incompleta y se revierten las modificaciones de datos registradas en la primera copia de seguridad del registro de transacciones de la transacción. SQL Server no admite la aplicación de la segunda copia de seguridad del registro de transacciones a partir de este punto. Es aconsejable restaurar todas las copias de seguridad de registros mediante WITH NORECOVERY:

RESTORE LOG nombre_basedatos FROM <dispositivo> WITH NORECOVERY A continuación, después de restaurar la última copia de seguridad de registros, recupere la base de datos en una operación aparte: RESTORE DATABASE nombre_basedatos WITH RECOVERY Cómo restaurar a un momento dado (SQL Server Management Studio) Este tema sólo es relevante para las bases de datos que utilizan los modos de recuperación completa o por medio de registros de operaciones masivas.

Después de conectarse a la instancia adecuada del Motor de base de datos de SQL Server de Microsoft, en el Explorador de objetos, haga clic en el nombre del servidor para expandir el árbol.

Expanda Bases de datos. En función de la base de datos, seleccione una base de datos de usuario o expanda Bases de datos del sistema y, a continuación, seleccione

una base de datos del sistema. Haga clic con el botón secundario en la base de datos, seleccione Tareas y, a

continuación, haga clic en Restaurar. En función de si está restaurando copias de seguridad de datos o sólo registros de

transacciones (para una base de datos que ya esté en estado de restauración), haga clic en Base de datos o en Registro de transacciones.

En la página General, el nombre de la base de datos en restauración aparecerá en el cuadro de lista A una base de datos. Para crear una nueva base de datos, escriba su

nombre en el cuadro de lista. La ubicación de la opción A un momento dado depende de si está restaurando copias

de seguridad de datos o sólo copias de seguridad del registro de transacciones: o Restaurar base de datos: la opción A un momento dado en la sección Destino de

la restauración. o Restaurar registro de transacciones: la opción A un momento dado en la sección

Restaurar en. El momento dado predeterminado es Lo más reciente posible. Para seleccionar una

fecha y hora específicas, haga clic en el botón Examinar (...).

Haga clic en Fecha y hora específicas en el cuadro de diálogo Restauración a un momento dado.

- 60 -

Introduzca o seleccione una fecha en el cuadro de lista Fecha. Introduzca o seleccione una hora en el cuadro de lista Hora.

Para especificar el origen y la ubicación de los conjuntos de copias de seguridad que se deben restaurar, haga clic en una de las opciones siguientes: o Desde base de datos: Escriba un nombre de base de datos en el cuadro de lista. o Desde dispositivo: Haga clic en el botón de Examinar (...). En el cuadro de diálogo

Especificar copia de seguridad, seleccione uno de los tipos de dispositivo de la lista en el cuadro de lista Medio para copia de seguridad. Para seleccionar uno o varios dispositivos del cuadro de lista Ubicación de la copia de seguridad, haga clic en Agregar. Tras agregar los dispositivos que desee al cuadro de lista

Ubicación de la copia de seguridad, haga clic en Aceptar para volver a la página

General. Tras especificar un momento específico, sólo se seleccionan en la columna Restaurar

de la cuadrícula Seleccionar los conjuntos de copia de seguridad que se van a restaurar las copias de seguridad que deben restaurarse a ese momento. Estas copias de seguridad seleccionadas componen el plan de restauración recomendado para la restauración a un momento dado. Sólo deben utilizarse las copias de seguridad seleccionadas para la operación de restauración a un momento dado.

Para ver o seleccionar opciones avanzadas, haga clic en Opciones en el panel

Seleccionar una página. En el panel Opciones de restauración, puede seleccionar una de las opciones

siguientes si son apropiadas para su situación: o Sobrescribir la base de datos existente o Conservar la configuración de replicación o Preguntar antes de restaurar cada copia de seguridad o Restringir el acceso a la base de datos restaurada

Si lo desea, puede restaurar la base de datos a una nueva ubicación si especifica un nuevo destino de restauración para cada archivo de la cuadrícula Restaurar los archivos de base de datos como.

El panel Estado de recuperación determina el estado de la base de datos después de

la operación de restauración: o Dejar la base de datos lista para su uso revirtiendo las transacciones no

confirmadas. No pueden restaurarse registros de transacciones adicionales. (RESTORE WITH RECOVERY) . Predeterminado

o Dejar la base de datos no operativa y no revertir transacciones no confirmadas. Pueden restaurarse registros de transacciones adicionales. (RESTORE WITH NORECOVERY)

o Dejar la base de datos en modo de sólo lectura. Deshacer las transacciones sin confirmar, pero guardar las acciones de deshacer en un archivo en espera para que los efectos de recuperación puedan revertirse. (RESTORE WITH STANDBY)

- 61 -

Restauración online Sólo se admite la restauración con conexión en SQL Server 2005 Enterprise Edition. En esta versión, la restauración de un archivo, una página o por etapas es con conexión de manera predeterminada. La restauración de datos mientras la base de datos está conectada se denomina restauración con conexión. Se considera que una base de datos está conectada siempre que el grupo de archivos principal esté conectado, aunque alguno de los grupos de archivos secundarios esté sin conexión. En todos los modelos de recuperación se puede restaurar un archivo sin conexión mientras la base de datos está conectada. En el modelo de recuperación completa, también se pueden restaurar páginas mientras la base de datos está conectada. Durante una operación de restauración de archivos con conexión, los archivos que se estén restaurando y su grupo de archivos están sin conexión. Si algunos de dichos archivos está conectado cuando se inicia una restauración con conexión, la primera instrucción de la restauración desconecta el grupo de archivos al que pertenece el archivo. Por el contrario, durante una restauración con conexión de una página, sólo esa página está desconectada. El escenario de restauración con conexión implica los siguientes pasos básicos:

o Restaure los datos.

- 62 -

o Restaure el registro utilizando WITH RECOVERY para la última restauración del

registro. Así, se conectan los datos restaurados. A veces, una transacción sin confirmar no se puede revertir porque los datos necesarios para la operación de reversión están sin conexión durante el inicio. En ese caso, la transacción se difiere. Nota: Si la base de datos está usando en ese momento el modelo de recuperación por medio de registros de operaciones masivas, es recomendable cambiar al modelo de recuperación completa antes de iniciar la restauración con conexión. Importante: Si las copias de seguridad se realizaron con varios dispositivos conectados al servidor, será necesario que los mismos dispositivos estén disponibles durante una restauración con conexión. Copias de seguridad de registros para una restauración en línea En el caso de una restauración en línea, el punto de recuperación es el punto donde se dejaron sin conexión los datos que se van a restaurar o se convirtieron en datos de sólo lectura por última vez. Las copias de seguridad del registro de transacciones que llevan a este punto de recuperación y lo incluyen deben estar todas disponibles. Normalmente, es necesario hacer una copia de seguridad de registros después de ese punto para cubrir el punto de recuperación del archivo. La única excepción tiene lugar durante una restauración con conexión de datos de sólo lectura a partir de una copia de seguridad de datos que se realizó después de que los datos pasaran a ser de sólo lectura. En ese caso, no es necesario disponer de una copia de seguridad de registros. En general, puede realizar copias de seguridad del registro de transacciones mientras la base de datos esté en línea, incluso después de iniciar la secuencia de restauración. El momento oportuno para la realización de la última copia de seguridad de registros depende de las propiedades del archivo que se va a restaurar:

En el caso de un archivo con conexión de sólo lectura, puede realizar la última copia de seguridad de registros necesaria para la recuperación antes o durante la primera secuencia de restauración. Un grupo de archivos de sólo lectura no necesita copias de seguridad de registros si se realizó una copia de seguridad de datos o diferencial después de haber configurado el grupo de archivos como de sólo lectura.

La información anterior se puede aplicar también a todos los archivos sin conexión. Un caso especial es un archivo de lectura y escritura que estaba con conexión cuando

se emitió la primera instrucción de restauración y que, a continuación, dicha instrucción dejó sin conexión automáticamente. En este caso, debe realizar una copia de seguridad de registros durante la primera secuencia de restauración (secuencia de una o varias instrucciones RESTORE que restauran, ponen al día y recuperan los datos).

Por lo general, esta copia de seguridad de registros debe tener lugar después de que se hayan restaurado todas las copias de seguridad completas y antes de recuperar los datos. No obstante, si hay varias copias de seguridad de archivos para un grupo de archivos concreto, el punto mínimo de copia de seguridad de registros es después de que el grupo de archivos quede sin conexión. Esta copia de seguridad de registros posterior a la restauración de datos capta el punto en el que se dejó el archivo sin conexión y es necesaria porque el Motor de base de datos de SQL Server no puede utilizar un registro en línea para una restauración con conexión.

Desconectar una base de datos o un archivo Si no desea utilizar la restauración con conexión, puede desconectar la base de datos antes de iniciar la secuencia de restauración; para ello, puede usar uno de los métodos siguientes:

- 63 -

En todos los modelos de recuperación puede desconectar la base de datos utilizando la siguiente instrucción ALTER DATABASE:

ALTER DATABASE database_name SET OFFLINE

Si lo desea, en el modelo de recuperación completa, puede forzar que la restauración de un archivo o una página sea sin conexión; para ello, utilizando la siguiente instrucción BACKUP LOG la base de datos se pone en el estado de restauración:

BACKUP LOG database_name WITH NORECOVERY.

Siempre que la base de datos permanezca sin conexión, todas las restauraciones serán sin conexión.

- 64 -

Módulo 3

Manejo de Seguridad

- 65 -

1- Seguridad de Base Proteger SQL Server La protección de SQL Server implica:

Seguridad de la plataforma y de la red: La plataforma de SQL Server incluye el

hardware físico y los sistemas de redes que conectan los clientes con los servidores de base de datos, así como los archivos binarios que se utilizan para procesar solicitudes de base de datos.

Seguridad Física: Las recomendaciones de seguridad física limitan de forma estricta el acceso al servidor físico y a los componentes de hardware. Por ejemplo, use salas cerradas de acceso restringido para el hardware de servidor de base de datos y los dispositivos de red. Además, limite el acceso a los medios de copia de seguridad almacenándolos en una ubicación segura fuera de las instalaciones. La implementación de la seguridad de la red física comienza por mantener a los usuarios no autorizados fuera de la red.

Protocolos de Red y Extremos TDS Cuando el Motor de base de datos de SQL Server se comunica con una aplicación, asigna a la comunicación un formato denominado paquete de secuencia de datos tabular (TDS) de Microsoft. La capa del protocolo de interfaz de red de SQL Server (SNI), que reemplaza las

bibliotecas de red por SQL Server y Microsoft Data Access Components (MDAC), encapsula el paquete TDS dentro de un protocolo de comunicación estándar, como TCP/IP o canalizaciones con nombre (named pipes). La capa del protocolo SNI es común al Motor de base de datos y SQL Native Client. La capa del protocolo SNI no se configura directamente. En su lugar, el servidor y SQL Native Client se configuran para utilizar un protocolo de red. A continuación, el Motor de base de datos y SQL Native Client aplican automáticamente la configuración apropiada del protocolo. El servidor crea un objeto de SQL Server llamado extremo TDS para cada protocolo de red. En el servidor, SQL Server instala los extremos TDS durante la instalación de SQL Server. En el equipo cliente, SQL Native Client debe instalarse y configurarse para que utilice un protocolo de red habilitado en el servidor. Habilitar Protocolos de Servidor después de la Instalación Los protocolos de red subyacentes del sistema operativo (como TCP/IP) deberían estar

instalados en el cliente y el servidor. Normalmente, los protocolos de red se instalan durante la instalación de Microsoft Windows; no forman parte de la instalación de SQL Server. Si el protocolo de red necesario no está disponible ni configurado en el servidor, el Motor de base de datos no se iniciará. Si el protocolo de red necesario no está disponible ni configurado en el cliente, la biblioteca de red no funcionará. De aquí en adelante, "habilitar un protocolo" quiere decir habilitarlo para SQL Server, no para el sistema operativo. Los protocolos de red necesarios para comunicarse con SQL Server 2005 desde otro equipo a menudo no están habilitados para SQL Server durante la instalación. Por tanto, para conectarse desde un equipo cliente, es posible que tenga que habilitar los protocolos TCP/IP,

canalizaciones con nombre o VIA. El protocolo de memoria compartida se habilita de forma predeterminada en todas las instalaciones, pero sólo puede utilizarse para conectar con el Motor de base de datos desde una aplicación cliente en el mismo equipo. Para habilitar los protocolos de red, utilice la herramienta de Configuración de Superficie o el

Administrador de Configuración de SQL Server. Los protocolos también pueden habilitarse

durante la instalación utilizando opciones en el símbolo del sistema.

- 66 -

Una vez instaladas y configuradas las conexiones de red, SQL Server puede escuchar simultáneamente en cualquier combinación de protocolos de red del servidor. Definición de los Extremos TDS Un extremo TDS es el objeto de SQL Server que representa el punto de comunicación entre SQL Server y un cliente. SQL Server crea de forma automática un extremo para cada uno de los cuatro protocolos admitidos por SQL Server. De forma predeterminada, todos los usuarios tienen acceso a los protocolos cuando están habilitados. Si un protocolo de red no está habilitado, el extremo se mantiene, pero no puede utilizarse. Para la conexión de administrador dedicada (DAC), se creará un extremo adicional que sólo pueden utilizar los miembros de la función fija de servidor sysadmin.

SQL Server genera un nombre único para cada extremo TDS. La tabla siguiente muestra los extremos que se crean automáticamente.

Finalidad Nombre del extremo

Memoria compartida TSQL LocalMachine

Canalizaciones con nombre TSQL Named Pipes

TCP/IP TSQL Default TCP

VIA TSQL Default VIA

DAC Dedicated Admin Connection

HTTP HyperText Transport Protocol

Para los protocolos de canalizaciones con nombre y memoria compartida, sólo puede existir un extremo por instancia. Para estos tipos de protocolo, no existen extremos configurables. Para TCP/IP y VIA, existe un extremo predeterminado, pero se pueden crear extremos adicionales. Los extremos HTTP también son creados por el usuario y no aparecen en el Administrador de configuración de SQL Server, aunque aparecen en la herramienta Configuración de superficie. En los extremos del sistema, sólo se puede cambiar el propietario y el estado (mediante ALTER ENDPOINT). Los extremos predeterminados no pueden deshabilitarse, pero pueden

detenerse e iniciarse. Un extremo que se ha detenido sigue escuchando, pero rechaza y cierra las conexiones nuevas. De forma predeterminada, los clientes se configuran para probar todos los protocolos hasta que uno funcione. Si el protocolo TCP/IP está deshabilitado, los clientes continúan con el siguiente protocolo. Si TCP/IP está habilitado pero el extremo se ha detenido, no se rechazará el intento de conexión y el cliente no probará otros protocolos, pero no se podrá utilizar la conexión que se ha detenido. En este caso, debe conectarse explícitamente a un extremo activo. Los puertos TCP dinámicos normalmente se conectan al extremo TCP predeterminado. Restringir el Acceso a la Red Los usuarios y administradores deben ser autenticados por el sistema operativo Microsoft Windows para poder obtener acceso a los datos de Microsoft SQL Server 2005. El sistema operativo Windows permite a todos los usuarios autenticados obtener acceso a un servidor miembro desde la red. Sin embargo, de forma predeterminada, los miembros del grupo Everyone también tienen permiso para obtener acceso a los servidores miembro. El grupo

Everyone incluye los usuarios anónimos.

- 67 -

Para incrementar la seguridad del sistema operativo y de los datos, realice lo siguiente para restringir los derechos de acceso a la red de los usuarios anónimos:

Utilice la herramienta Directiva de seguridad local para quitar al grupo Everyone el

derecho de obtener acceso al equipo desde la red. Esta herramienta reside en el grupo Herramienta administrativas del equipo.

Deshabilite las sesiones nulas para evitar las sesiones anónimas o no autenticadas. A tal efecto, establezca la clave RestrictAnonymous en 1. Esta clave reside en el

Registro de Windows y se encuentra en HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA.

Seguridad del Sistema Operativo Los Service Packs y las actualizaciones del sistema operativo incluyen mejoras de seguridad importantes. Aplique todas las revisiones y actualizaciones al sistema operativo después de probarlas con las aplicaciones de base de datos. Los firewalls también proporcionan formas eficaces de implementar la seguridad.

Lógicamente, un firewall es un separador o limitador del tráfico de red, que puede configurarse para aplicar la directiva de seguridad de datos de su organización. El uso de un firewall aumenta la seguridad del sistema operativo ya que proporciona un punto de arranque en el que pueden centrarse las medidas de seguridad. La reducción de la superficie es una medida de seguridad que implica detener o deshabilitar componentes no utilizados. La reducción de la superficie ayuda a mejorar la seguridad al proporcionar menos accesos para ataques potenciales al sistema. La clave para limitar la superficie de SQL Server consiste en ejecutar los servicios requeridos con "privilegios mínimos" mediante la concesión de los derechos necesarios únicamente a los servicios y usuarios. Si el sistema SQL Server usa los Servicios de Internet Information Server (IIS), es necesario realizar pasos adicionales para proteger la superficie de la plataforma.

- 68 -

2- Introducción a la Seguridad de SQL Server Entidades de Seguridad y Seguridad de objetos de base de datos Las entidades de seguridad son los individuos, grupos y procesos que tienen acceso a SQL Server. Los asegurables son el servidor, la base de datos y los objetos incluidos en la base de

datos. Cada uno de estos elementos dispone de un conjunto de permisos que pueden configurarse para minimizar aún más la superficie de SQL Server. Entidades de Seguridad (Principals) Las entidades de seguridad son entidades que pueden solicitar recursos de SQL Server. Igual que otros componentes del modelo de autorización de SQL Server, las entidades de seguridad se pueden organizar en jerarquías. El ámbito de influencia de una entidad de seguridad depende del ámbito de su definición: Windows, servidor o base de datos; y de si la entidad de seguridad es indivisible o es una colección. Un Inicio de sesión de Windows es un ejemplo de entidad de seguridad indivisible y un Grupo de Windows es un ejemplo de una del tipo colección. Toda entidad de seguridad tiene un identificador de seguridad (SID). Entidades de seguridad a nivel de Windows:

Inicio de sesión del dominio de Windows Inicio de sesión local de Windows

Entidades de seguridad a nivel de SQL Server

Inicio de sesión de SQL Server

Entidades de seguridad a nivel de bases de datos Usuario de base de datos Función de base de datos Función de aplicación

Inicio de Sesión sa de SQL Server El inicio de sesión sa de SQL Server es una entidad de seguridad de nivel de servidor. Se crea de forma predeterminada cuando se instala una instancia. En Microsoft SQL Server 2005, la base de datos predeterminada de sa es master. Esto es un cambio de comportamiento con

respecto a versiones anteriores de Microsoft SQL Server. INFORMATION_SCHEMA y sys Todas las bases de datos incluyen dos entidades que aparecen como usuarios en vistas de catálogo: INFORMATION_SCHEMA y sys. SQL Server necesita estas dos entidades. No son

entidades de seguridad y no se pueden modificar ni quitar. Asegurables Los asegurables son los recursos cuyo acceso es regulado por el sistema de autorización del Motor de base de datos de SQL Server. Algunos asegurables pueden estar incluidos en otros, con lo que se crean jerarquías anidadas denominadas "ámbitos" que a su vez se pueden asegurar. Los ámbitos asegurables son servidor, base de datos y esquema.

Servidor: Incluye los asegurables siguientes:

Extremo Inicio de sesión

- 69 -

Base de datos

Base de Datos: Incluye los asegurables siguientes: Usuario Función Función de aplicación Ensamblado Tipo del mensaje Ruta Servicio Enlace de servicio remoto Catálogo de texto Certificado Clave asimétrica Clave simétrica Contrato Esquema

Esquema: Incluye los asegurables siguientes:

Tipo Colección de esquemas XML Objeto

Objetos Los elementos siguientes son miembros de la clase de objeto:

Agregado Restricción Función Procedimiento Cola Estadística Sinónimo Tabla Vista

Funciones (Roles) de Nivel de Servidor (Server Fixed Roles) Las funciones fijas de servidor abarcan todo el ámbito del servidor. Cada miembro de una función fija de servidor puede agregar otros inicios de sesión a esa misma función. Las funciones fijas de servidor se pueden asignar a los permisos más específicos que se incluyen en SQL Server 2005. La siguiente tabla describe la asignación de funciones fijas de servidor a permisos.

Función fija de servidor

Permiso en el servidor

bulkadmin Se le concede: ADMINISTER BULK OPERATIONS

dbcreator Se le concede: CREATE DATABASE

diskadmin Se le concede: ALTER RESOURCES

processadmin Se le concede: ALTER ANY CONNECTION, ALTER SERVER STATE

securityadmin Se le concede: ALTER ANY LOGIN

- 70 -

serveradmin Se le concede: ALTER ANY ENDPOINT, ALTER RESOURCES, ALTER SERVER STATE, ALTER SETTINGS, SHUTDOWN, VIEW SERVER STATE

setupadmin Se le concede: ALTER ANY LINKED SERVER

sysadmin Se le concede con la opción GRANT: CONTROL SERVER

La Función public Además de las funciones fijas de servidor mencionadas en la tabla anterior, cada instancia de SQL contiene una función fija de servidor especial denominada public de la cual todos los

inicios de sesión son miembros. A la función public se le concede el permiso VIEW ANY DATABASE.

Funciones (Roles) en el Nivel de Base de Datos Las funciones fijas de base de datos se definen en el nivel de base de datos y existen en cada una de ellas. Los miembros de las funciones de base de datos db_owner y db_securityadmin

pueden administrar a los miembros de una función fija de base de datos; sin embargo, sólo los miembros de una función de base de datos db_owner pueden agregar miembros a la función fija de base de datos db_owner.

Las funciones fijas de base de datos se pueden asignar a permisos más detallados que se incluyen en SQL Server 2005. La tabla siguiente describe la asignación de funciones fijas de base de datos a permisos.

Función fija de base de datos

Permiso en la base de datos Permiso en el

servidor

db_accessadmin Concedido: ALTER ANY USER, CREATE SCHEMA Concedido: VIEW ANY DATABASE

db_accessadmin Concedido con la opción GRANT: CONNECT

db_backupoperator Concedido: BACKUP DATABASE, BACKUP LOG, CHECKPOINT Concedido: VIEW ANY DATABASE

db_datareader Concedido: SELECT Concedido: VIEW ANY DATABASE

db_datawriter Concedido: DELETE, INSERT, UPDATE Concedido: VIEW ANY DATABASE

db_ddladmin Concedido: ALTER ANY ASSEMBLY, ALTER ANY ASYMMETRIC KEY, ALTER ANY CERTIFICATE, ALTER ANY CONTRACT, ALTER ANY DATABASE DDL TRIGGER, ALTER ANY DATABASE EVENT, NOTIFICATION, ALTER ANY DATASPACE, ALTER ANY FULLTEXT CATALOG, ALTER ANY MESSAGE TYPE, ALTER ANY REMOTE SERVICE BINDING, ALTER ANY ROUTE, ALTER ANY SCHEMA, ALTER ANY SERVICE, ALTER ANY SYMMETRIC KEY, CHECKPOINT, CREATE AGGREGATE, CREATE DEFAULT, CREATE FUNCTION, CREATE PROCEDURE, CREATE QUEUE, CREATE RULE, CREATE SYNONYM, CREATE TABLE, CREATE TYPE, CREATE VIEW, CREATE XML SCHEMA COLLECTION, REFERENCES

Concedido: VIEW ANY DATABASE

db_denydatareader Denegado: SELECT Concedido: VIEW ANY DATABASE

- 71 -

db_denydatawriter Denegado: DELETE, INSERT, UPDATE

db_owner Concedido con la opción GRANT: CONTROL Concedido: VIEW ANY DATABASE

db_securityadmin Concedido: ALTER ANY APPLICATION ROLE, ALTER ANY ROLE, CREATE SCHEMA, VIEW DEFINITION


dbm_monitor Concedido: VIEW el estado más reciente en el Monitor de creación de reflejo de la base de datos Nota: La función fija de base de datos dbm_monitor se crea en la base de datos msdb cuando se registra la primera base de datos en el Monitor de creación de reflejo de la base de datos. La nueva función dbm_monitor no tiene miembros hasta que un administrador del sistema asigne usuarios a la función.


Jerarquía de Permisos El Motor de base de datos de SQL Server 2005 administra un conjunto jerárquico de entidades que se pueden proteger mediante permisos. Estas entidades se conocen como asegurables.

Los asegurables más importantes son los servidores y las bases de datos, aunque se pueden establecer permisos discretos en niveles menores. SQL Server regula las acciones de las entidades de seguridad en los asegurables comprobando que se les han concedido los permisos adecuados. En la ilustración siguiente se muestran las relaciones entre las jerarquías de permisos del Motor de base de datos.

- 72 -

Trabajar con Permisos Los permisos se pueden manipular con las conocidas consultas GRANT, DENY y REVOKE de

Transact-SQL. La información sobre los permisos está visible en las vistas de catálogo sys.server_permisions y sys.database_permisions. También hay información sobre la

compatibilidad con permisos para consultas mediante el uso de las funciones integradas. Permisos a Nivel de Servidor Un servidor ocupa el nivel más alto en la jerarquía de permisos. En la siguiente tabla se muestran los permisos más específicos y limitados que pueden concederse en un servidor.

Permiso de servidor Implicado por el permiso de servidor

ADMINISTER BULK OPERATIONS CONTROL SERVER

ALTER ANY CONNECTION CONTROL SERVER

- 73 -

ALTER ANY CREDENTIAL CONTROL SERVER

ALTER ANY DATABASE CONTROL SERVER

ALTER ANY ENDPOINT CONTROL SERVER

ALTER ANY EVENT NOTIFICATION CONTROL SERVER

ALTER ANY LINKED SERVER CONTROL SERVER

ALTER ANY LOGIN CONTROL SERVER

ALTER RESOURCES CONTROL SERVER

ALTER SERVER STATE CONTROL SERVER

ALTER SETTINGS CONTROL SERVER

ALTER TRACE CONTROL SERVER

AUTHENTICATE SERVER CONTROL SERVER

CONNECT SQL CONTROL SERVER

CONTROL SERVER CONTROL SERVER

CREATE ANY DATABASE ALTER ANY DATABASE

CREATE DDL EVENT NOTIFICATION ALTER ANY EVENT NOTIFICATION

CREATE ENDPOINT ALTER ANY ENDPOINT

CREATE TRACE EVENT NOTIFICATION ALTER ANY EVENT NOTIFICATION

EXTERNAL ACCESS ASSEMBLY CONTROL SERVER

SHUTDOWN CONTROL SERVER

UNSAFE ASSEMBLY CONTROL SERVER

VIEW ANY DATABASE VIEW ANY DEFINITION

VIEW ANY DEFINITION CONTROL SERVER

VIEW SERVER STATE ALTER SERVER STATE

Conceder Permisos El que concede (o la entidad de seguridad especificada con la opción AS) debe tener el permiso con GRANT OPTION o un permiso superior que implique el permiso que se va a conceder. Los miembros de la función fija de servidor sysadmin pueden conceder cualquier

permiso. Ejemplos: a. Conceder un permiso a un inicio de sesión En el siguiente ejemplo se concede el permiso CONTROL SERVER al inicio de sesión Terry de SQL Server. USE master; GRANT CONTROL SERVER TO Terry; GO b. Conceder un permiso que dispone del permiso GRANT

- 74 -

En el siguiente ejemplo se concede ALTER ANY EVENT NOTIFICATION al inicio de sesión Janeth de SQL Server con el derecho a conceder este permiso a otro inicio de sesión. USE master; GRANT ALTER ANY EVENT NOTIFICATION TO Janeth WITH GRANT OPTION; GO Permisos a Nivel de Base de Datos Una base de datos es un elemento que puede protegerse, que contiene el servidor, que es su entidad primaria en la jerarquía de permisos. La mayoría de permisos limitados y específicos que se pueden conceder en una base de datos se muestran en la siguiente tabla, junto con permisos más generales que los incluyen por implicación.

Permiso de base de datos Implicado por el permiso de base de

datos Implicado por el permiso de

servidor

ALTER CONTROL ALTER ANY DATABASE

ALTER ANY APPLICATION ROLE ALTER CONTROL SERVER

ALTER ANY ASSEMBLY ALTER CONTROL SERVER

ALTER ANY ASYMMETRIC KEY ALTER CONTROL SERVER

ALTER ANY CERTIFICATE ALTER CONTROL SERVER

ALTER ANY CONTRACT ALTER CONTROL SERVER

ALTER ANY DATABASE DDL TRIGGER

ALTER CONTROL SERVER

ALTER ANY DATABASE EVENT NOTIFICATION

ALTER ALTER ANY EVENT NOTIFICATION

ALTER ANY DATASPACE ALTER CONTROL SERVER

ALTER ANY FULLTEXT CATALOG ALTER CONTROL SERVER

ALTER ANY MESSAGE TYPE ALTER CONTROL SERVER

ALTER ANY REMOTE SERVICE BINDING

ALTER CONTROL SERVER

ALTER ANY ROLE ALTER CONTROL SERVER

ALTER ANY ROUTE ALTER CONTROL SERVER

ALTER ANY SCHEMA ALTER CONTROL SERVER

ALTER ANY SERVICE ALTER CONTROL SERVER

ALTER ANY SYMMETRIC KEY ALTER CONTROL SERVER

ALTER ANY USER ALTER CONTROL SERVER

AUTHENTICATE CONTROL AUTHENTICATE SERVER

BACKUP DATABASE CONTROL CONTROL SERVER

BACKUP LOG CONTROL CONTROL SERVER

CHECKPOINT CONTROL CONTROL SERVER

CONNECT CONNECT REPLICATION CONTROL SERVER

CONNECT REPLICATION CONTROL CONTROL SERVER

- 75 -

CONTROL CONTROL CONTROL SERVER

CREATE AGGREGATE ALTER CONTROL SERVER

CREATE ASSEMBLY ALTER ANY ASSEMBLY CONTROL SERVER

CREATE ASYMMETRIC KEY ALTER ANY ASYMMETRIC KEY CONTROL SERVER

CREATE CERTIFICATE ALTER ANY CERTIFICATE CONTROL SERVER

CREATE CONTRACT ALTER ANY CONTRACT CONTROL SERVER

CREATE DATABASE CONTROL CREATE ANY DATABASE

CREATE DATABASE DDL EVENT NOTIFICATION

ALTER ANY DATABASE EVENT NOTIFICATION

CREATE DDL EVENT NOTIFICATION

CREATE DEFAULT ALTER CONTROL SERVER

CREATE FULLTEXT CATALOG ALTER ANY FULLTEXT CATALOG CONTROL SERVER

CREATE FUNCTION ALTER CONTROL SERVER

CREATE MESSAGE TYPE ALTER ANY MESSAGE TYPE CONTROL SERVER

CREATE PROCEDURE ALTER CONTROL SERVER

CREATE QUEUE ALTER CONTROL SERVER

CREATE REMOTE SERVICE BINDING ALTER ANY REMOTE SERVICE BINDING

CONTROL SERVER

CREATE ROLE ALTER ANY ROLE CONTROL SERVER

CREATE ROUTE ALTER ANY ROUTE CONTROL SERVER

CREATE RULE ALTER CONTROL SERVER

CREATE SCHEMA ALTER ANY SCHEMA CONTROL SERVER

CREATE SERVICE ALTER ANY SERVICE CONTROL SERVER

CREATE SYMMETRIC KEY ALTER ANY SYMMETRIC KEY CONTROL SERVER

CREATE SYNONYM ALTER CONTROL SERVER

CREATE TABLE ALTER CONTROL SERVER

CREATE TYPE ALTER CONTROL SERVER

CREATE VIEW ALTER CONTROL SERVER

CREATE XML SCHEMA COLLECTION ALTER CONTROL SERVER

DELETE CONTROL CONTROL SERVER

EXECUTE CONTROL CONTROL SERVER

INSERT CONTROL CONTROL SERVER

REFERENCES CONTROL CONTROL SERVER

SELECT CONTROL CONTROL SERVER

SHOWPLAN CONTROL ALTER TRACE

SUBSCRIBE QUERY NOTIFICATIONS CONTROL CONTROL SERVER

TAKE OWNERSHIP CONTROL CONTROL SERVER

- 76 -

UPDATE CONTROL CONTROL SERVER

VIEW DATABASE STATE CONTROL VIEW SERVER STATE

VIEW DEFINITION CONTROL VIEW ANY DEFINITION

Si utiliza la opción AS, se aplican los siguientes requisitos adicionales:

AS granting_principal Permiso adicional necesario

Usuario de la base de datos Permiso IMPERSONATE en el usuario debe pertenecer a la función fija de base de datos db_securityadmin , debe pertenecer a la función fija de base de datos db_owner debe pertenecer a la función fija de servidor sysadmin.

Usuario de la base de datos asignado a un inicio de sesión de Windows

Permiso IMPERSONATE en el usuario debe pertenecer a la función fija de base de datos db_securityadmin , debe pertenecer a la función fija de base de datos db_owner debe pertenecer a la función fija de servidor sysadmin.

Usuario de la base de datos asignado a un grupo de Windows

Debe pertenecer al grupo de Windows, debe pertenecer a la función fija de base de datos db_securityadmin , debe pertenecer a la función fija de base de datos db_owner debe pertenecer a la función fija de servidor sysadmin.

Usuario de la base de datos asignado a un certificado

Debe pertenecer a la función fija de base de datos db_securityadmin , debe pertenecer a la función fija de base de datos db_owner o debe pertenecer a la función fija de servidor sysadmin.

Usuario de la base de datos asignado a una clave asimétrica

Debe pertenecer a la función fija de base de datos db_securityadmin , debe pertenecer a la función fija de base de datos db_owner o debe pertenecer a la función fija de servidor sysadmin.

Usuario de la base de datos asignado a cualquier entidad de seguridad de servidor

Permiso IMPERSONATE en el usuario debe pertenecer a la función fija de base de datos db_securityadmin , debe pertenecer a la función fija de base de datos db_owner debe pertenecer a la función fija de servidor sysadmin.

Función de base de datos Permiso ALTER en la función, debe pertenecer a la función fija de base de datos db_securityadmin , debe pertenecer a la función fija de base de datos db_owner debe pertenecer a la función fija de servidor sysadmin.

Función de aplicación Permiso ALTER en la función, debe pertenecer a la función fija de base de datos db_securityadmin , debe pertenecer a la función fija de base de datos db_owner debe pertenecer a la función fija de servidor sysadmin.

Los propietarios de objetos pueden conceder permisos en los objetos que poseen. Las entidades de seguridad que tienen el permiso CONTROL en un elemento que puede protegerse pueden conceder permisos en ese elemento. Los receptores del permiso CONTROL SERVER, como los miembros de la función fija de servidor sysadmin, pueden conceder los permisos en cualquier elemento que puede

protegerse en el servidor. Ejemplos a. Conceder el permiso para crear tablas En el siguiente ejemplo se concede el permiso CREATE TABLE en la base de datos AdventureWorks para el usuario Melanie. USE AdventureWorks; GRANT CREATE TABLE TO Melanie; GO

- 77 -

b. Conceder el permiso SHOWPLAN para una función de aplicación En el siguiente ejemplo se concede el permiso SHOWPLAN en la base de datos AdventureWorks para la función de aplicación AuditMonitor. USE AdventureWorks; GRANT SHOWPLAN TO AuditMonitor; GO c. Conceder CREATE VIEW con GRANT OPTION En el siguiente ejemplo se concede el permiso CREATE VIEW en la base de datos AdventureWorks al usuario Carmine con el derecho para conceder CREATE VIEW a otras entidades de seguridad. USE AdventureWorks; GRANT CREATE VIEW TO Carmine WITH GRANT OPTION; GO Permisos a Nivel de Esquema Un esquema es un elemento que puede protegerse en el nivel de base de datos que contiene la base de datos que es su entidad primaria en la jerarquía de permisos. La mayoría de permisos limitados y específicos que se pueden conceder en un esquema se muestran a continuación, junto con permisos más generales que los incluyen por implicación.

Permiso del esquema Implicado por el permiso del esquema Implicado por el permiso de base de datos

CONTROL CONTROL CONTROL

TAKE OWNERSHIP CONTROL CONTROL

ALTER CONTROL ALTER ANY SCHEMA

EXECUTE CONTROL EXECUTE

INSERT CONTROL INSERT

DELETE CONTROL DELETE

UPDATE CONTROL UPDATE

SELECT CONTROL SELECT

REFERENCES CONTROL REFERENCES

VIEW DEFINITION CONTROL VIEW DEFINITION

Advertencia: Un usuario con permiso ALTER en un esquema puede utilizar encadenamiento de propiedad para tener acceso a asegurables de otros esquemas, incluidos los asegurables para los que se haya denegado explícitamente el acceso a ese usuario. Esto se debe a que el encadenamiento de propiedad omite las comprobaciones de permisos en los objetos a los que se hace referencia cuando pertenecen al servidor principal propietario de los objetos que hacen referencia a los mismos. Un usuario con permiso ALTER en un esquema puede crear procedimientos, sinónimos y vistas que son propiedad del propietario del esquema. Esos objetos tendrán acceso (mediante encadenamiento de propiedad) a información de otros esquemas que son propiedad del propietario del esquema. Si es posible, se debe evitar

- 78 -

conceder permiso ALTER en un esquema si el propietario de dicho esquema también es propietario de otros esquemas. Por ejemplo, este problema puede suceder en los siguientes escenarios. En ellos se supone que un usuario, denominado U1, tiene permiso ALTER en el esquema S1. Se deniega al usuario U1 acceso a un objeto tabla, denominado T1, en el esquema S2. Los esquemas S1 y S2 son propiedad del mismo propietario. El usuario U1 tiene permiso CREATE PROCEDURE en la base de datos y permiso EXECUTE en el esquema S1. Por tanto, el usuario U1 puede crear un procedimiento almacenado y después tener acceso al objeto T1 denegado en el procedimiento almacenado. El usuario U1 tiene permiso CREATE SYNONYM en la base de datos y permiso SELECT en el esquema S1. Por tanto, el usuario U1 puede crear un sinónimo en el esquema S1 para el objeto T1 denegado y después tener acceso a dicho objeto mediante el sinónimo. El usuario U1 tiene permiso CREATE VIEW en la base de datos y permiso SELECT en el esquema S1. Por tanto, el usuario U1 puede crear una vista en el esquema S1 para consultar datos del objeto T1 denegado y después tener acceso a dicho objeto mediante la vista. Los propietarios de objetos pueden conceder permisos en los objetos que poseen. Las entidades de seguridad con el permiso CONTROL en un elemento que puede protegerse pueden conceder permisos en ese elemento. Los receptores del permiso CONTROL SERVER, como los miembros de la función fija de servidor sysadmin, pueden conceder los permisos en cualquier elemento que puede

protegerse en el servidor. Los receptores del permiso CONTROL en una base de datos, como los miembros de la función fija de base de datos db_owner, pueden conceder los permisos en

cualquier elemento que puede protegerse en la base de datos. Los receptores del permiso CONTROL en un esquema pueden conceder los permisos en cualquier objeto del esquema. Ejemplos a. Conceder a un invitado permiso INSERT en el esquema HumanResources. GRANT INSERT ON SCHEMA :: HumanResources TO guest; b. Conceder al usuario de base de datos WilJo permiso SELECT en el esquema Person. GRANT SELECT ON SCHEMA :: Person TO WilJo WITH GRANT OPTION; Cifrado y Certificados El cifrado no resuelve los problemas de control de acceso. Sin embargo, mejora la seguridad debido a que limita la pérdida de datos, incluso en el caso poco probable de que se superen los controles de acceso. Por ejemplo, si el equipo host de base de datos no está configurado correctamente y un pirata informático obtiene datos confidenciales, como números de tarjetas de crédito, esa información robada resulta inservible si está cifrada. Jerarquía de Cifrado SQL Server 2005 cifra los datos con una infraestructura de cifrado jerárquico y administración de claves. Cada capa cifra la capa inferior utilizando una combinación de certificados, claves asimétricas y claves simétricas. El cifrado jerárquico está basado en una clave maestra de servicio (Service Master Key), ésta

clave es generada automáticamente cuando se instala SQL Server 2005. El motor de base de datos utiliza la clave maestra de servicio para cifrar los siguientes objetos:

Passwords de Servidores Vinculados (Linked Server Passwords)

Cadenas de Conexión (Connection Strings)

- 79 -

Credenciales de Cuentas (Account Credentials)

Todas las Claves maestras de la base de datos A la llave maestra de servicio se le debe sacar un backup y almacenarla en un sitio seguro y fuera de línea. Esto para poder administrar mas fácilmente ya sea hacer copias de seguridad o restaurar la clave maestra de servicio en caso de que sea necesario. Llave Maestra de Servicio (Service Master Key) Es una llave Triple DES en la raíz de SQL Server 2005 y es generada automáticamente la primera vez que es necesaria y está asegurada por la API de protección de datos de Windows (DPAPI). Llave Maestra de Base de Datos (Database Master Key) Es una llave simétrica Triple DES que puede utilizarse para proteger las llaves privadas de certificados y llaves asimétricas en una base de datos. Cuando se crea una llave Maestra de Base de Datos ésta es encriptada utilizando el algoritmo Triple DES y una contraseña provista por el usuario. SQL Server almacena una copia de la llave maestra de base de datos en la base de datos master y a su vez es cifrada con la llave maestra de servicio. Otra copia es almacenada en la base de datos cifrada con una contraseña. La siguiente ilustración muestra que cada capa de la jerarquía de cifrado cifra la capa que tiene debajo. La capa superior, la llave maestra de servicio, se cifra con la API de protección de datos (DPAPI) de Windows.

- 80 -

SQL Server 2005 le ofrece los mecanismos siguientes para el cifrado:

Certificados Claves asimétricas Claves simétricas

Certificados Un certificado de clave pública, normalmente denominado solo certificado, es una instrucción firmada digitalmente que enlaza el valor de una clave pública con la identidad de la persona, dispositivo o servicio que tiene la clave privada correspondiente. Las entidades emisoras de certificados (CA) son las encargadas de emitir y firmar los certificados. La entidad que recibe un certificado de una CA es el sujeto de ese certificado. Por lo general, los certificados contienen la siguiente información.

La clave pública del sujeto. La información que identifica al sujeto, como el nombre y la dirección de correo

electrónico. El periodo de validez. Es decir, el periodo de tiempo durante el que el certificado se

considera válido. Un certificado sólo es válido durante el periodo de tiempo que se especifica en el mismo; todos los certificados contienen una fecha Válido desde y otra Válido hasta.

Estas fechas establecen los límites del período de validez. Cuando el período de validez de un certificado ha transcurrido, es necesario que el sujeto del certificado caducado solicite uno nuevo. Información de identificador del emisor. La firma digital del emisor. Esta firma da fe de la validez de las obligaciones entre la

clave pública y la información de identificador del sujeto. (El proceso de firmar digitalmente la información conlleva a transformar la información, así como cierta información privada que conserva el remitente, en una etiqueta denominada firma.)

Una de las principales ventajas de los certificados es que liberan a los hosts de la necesidad de establecer contraseñas para sujetos individuales. En su lugar, el host simplemente establece la confianza en un emisor de certificados, que a continuación puede firmar un número ilimitado de certificados. Cuando un host, por ejemplo, un servidor Web seguro, designa a un emisor como entidad emisora raíz de confianza, el host implícitamente confía en las directivas que el emisor ha utilizado para establecer las obligaciones de los certificados que emite. En efecto, el host confía en que el emisor ha comprobado la identidad del sujeto del certificado. Un host designa a un emisor como entidad emisora raíz de confianza presentando el certificado autofirmado del emisor, que contiene la clave pública de éste, en el almacén de certificados de la entidad emisora de certificados raíz de confianza del equipo host. Las entidades emisoras de certificados intermedias o subordinadas sólo son de confianza si tienen una ruta válida de certificación procedente de una entidad emisora de certificados raíz. El emisor puede revocar un certificado antes de que caduque. La revocación cancela las obligaciones que una clave pública tiene con una identidad que se exprese en el certificado. Cada emisor mantiene una lista de revocación de certificados que los programas pueden utilizar cuando estén comprobando la validez de un certificado determinado. Dentro de las posibilidades de los certificados, se puede cargar desde un ensamblado o bien desde un archivo que contenga el certificado, como así también crear uno desde SQL 2005. Para la creación de estos certificados SQL dispones de la sentencia TSQL CREATE CERTIFICATE y su sintaxis es la siguiente:

- 81 -

CREATE CERTIFICATE certificate_name [ AUTHORIZATION user_name ] { FROM <existing_keys> | <generate_new_keys> } [ ACTIVE FOR BEGIN_DIALOG = { ON | OFF } ] <existing_keys> ::= ASSEMBLY assembly_name | { [ EXECUTABLE ] FILE = 'path_to_file' [ WITH PRIVATE KEY ( <private_key_options> ) ] } <generate_new_keys> ::= [ ENCRYPTION BY PASSWORD = 'password'] WITH SUBJECT = 'certificate_subject_name' [ , <date_options> [ ,...n ] ] <private_key_options> ::= FILE = 'path_to_private_key' [ , DECRYPTION BY PASSWORD = ‟password‟] [ , ENCRYPTION BY PASSWORD = ‟password‟] <date_options> ::= START_DATE = 'mm/dd/yyyy' | EXPIRY_DATE = 'mm/dd/yyyy' Ejemplo de creación de un Certificado con contraseña y fecha de expiración: USE AdventureWorks GO CREATE CERTIFICATE CERTIFICADO1 ENCRYPTION BY PASSWORD ='COMPLEJO' EXPIRY_DATE =''10/31/2009'', SUBJECT = „Adventure Works Customers' Ejemplo de importación de un certificado existente: USE AdventureWorks GO CREATE CERTIFICATE CERTIFICADO1 FROM FILE = 'c:\Cert\certificado.cer' GO Claves Asimétricas Una clave asimétrica se compone de una clave privada y su correspondiente clave pública. Cada clave puede descifrar los datos que cifra la otra. Una clave asimétrica se puede utilizar para cifrar una clave simétrica para almacenar en una base de datos. Las claves asimétricas son entidades que pueden protegerse a nivel de la base de datos. Por defecto, la clave privada es protegida por la Master Key; de no existir esta última, es necesario

una contraseña. La clave privada puede ser de 512, 1024 ó 2048 Bits. El cifrado y descifrado asimétricos consumen una cantidad grande de recursos pero proporcionan un nivel de seguridad superior al del cifrado simétrico.

- 82 -

Para crear claves asimétricas se utiliza CREATE ASYMMETRIC KEY. Ejemplo: USE AdventureWorks GO CREATE ASYMMETRIC KEY ClaveAsym WITH ALGORITHM = RSA_2048 ENCRYPTION BY PASSWORD ='$$PEPE$$' GO Claves Simétricas Una clave simétrica es una clave que se utiliza para el cifrado y el descifrado. El cifrado y el descifrado con una clave simétrica son más rápidos y adecuados para usarlos de forma rutinaria con datos confidenciales de una base de datos. Al crear una clave simétrica, ésta debe ser cifrada utilizando una de 4 opciones: certificado, contraseña, clave simétrica o clave asimétrica. Esta clave puede tener más de un cifrado de cada tipo. Si se utiliza contraseña (password) para cifrar la clave simétrica, entonces en lugar de utilizar la clave publica de la base de datos (Master Key) se debe utilizar el algoritmo Triple DES. Para

la creación de las claves simétricas se utiliza CREATE SIMMETRIC KEY. Ejemplo: USE AdventureWorks GO CREATE SYMMETRIC KEY SYM_KEY WITH ALGORITHM = TRIPLE_DES ENCRYPTION BY PASSWORD ='##JUAN##' Nota: Es muy importante realizar un backup de los certificados, como así también de las Master Key; para ello, SQL 2005 dispone de las sentencias BACKUP CERTIFICATE, BACKUP MASTER KEY.

- 83 -

3- Implementación de Seguridad en SQL Server 2005 Seleccionar un Modo de Autenticación Durante la instalación, debe seleccionar un modo de autenticación para el Motor de base de datos. Hay dos modos posibles

Modo de autenticación de Windows Modo mixto.

El modo de autenticación de Windows habilita la autenticación de Windows y deshabilita la autenticación de SQL Server. El modo mixto habilita tanto la autenticación de Windows como la de SQL Server. La autenticación de Windows está disponible siempre y no se puede deshabilitar.

Configurar el Modo de Autenticación

Si selecciona la autenticación de modo mixto durante la instalación, debe proporcionar una contraseña segura, y confirmarla después, para la cuenta de administrador del sistema de SQL Server integrada denominada sa. La cuenta sa se conecta con la autenticación de SQL Server.

- 84 -

Si selecciona la autenticación de Windows durante la instalación, el programa de instalación crea la cuenta sa para la autenticación de SQL Server pero se deshabilita. Si después cambia a la autenticación de modo mixto y desea utilizar la cuenta sa, debe habilitar la cuenta.

Cualquier cuenta de SQL Server o de Windows se puede configurar como del administrador del sistema. Dado que la cuenta sa es muy conocida y a menudo es el objetivo de usuarios

malintencionados, no la habilite a menos que la aplicación lo requiera. Nunca establezca una contraseña en blanco o con poca seguridad para la cuenta sa.

Conectar a través de la Autenticación de Windows

Cuando un usuario se conecta a través de una cuenta de usuario de Microsoft Windows, SQL Server valida el nombre de cuenta y la contraseña con el token de la entidad de seguridad de Windows del sistema operativo. Esto significa que Windows confirma la identidad del usuario. SQL Server no pide la contraseña y no realiza la validación de identidad. La autenticación de Windows es el modo de autenticación predeterminado y es mucho más seguro que la autenticación de SQL Server. La autenticación de Windows usa el protocolo de seguridad de Kerberos, proporciona la aplicación de directivas de contraseñas en cuanto a la validación de

la complejidad de las contraseñas seguras, ofrece compatibilidad para el bloqueo de cuentas y admite la expiración de las contraseñas. Una conexión realizada utilizando la autenticación de Windows se denomina a veces conexión de confianza, porque SQL Server confía en las credenciales proporcionadas por Windows. Conectar a través de la Autenticación de SQL Server

Al utilizar la autenticación de SQL Server, los inicios de sesión se crean en SQL Server, que no se basa en las cuentas de usuario de Windows. El nombre de usuario y la contraseña se crean utilizando SQL Server y se almacenan en SQL Server. Los usuarios que se conectan utilizando la autenticación de SQL Server deben proporcionar sus credenciales (inicio de sesión y contraseña) cada vez que se conectan. Al utilizar la autenticación de SQL Server, debe establecer contraseñas seguras para todas las cuentas de SQL Server. Hay tres directivas de contraseñas opcionales para los inicios de sesión de SQL Server.

El usuario debe cambiar la contraseña en el siguiente inicio de sesión Exige que el usuario cambie la contraseña la próxima vez que se conecte. SQL Server Management Studio proporciona la capacidad de cambiar la contraseña. Otros programadores de software deberían proporcionar esta característica si se utiliza esta opción.

Exigir expiración de contraseña. La directiva de vigencia máxima de la contraseña del equipo se exige para los inicios de sesión de SQL Server.

Exigir directivas de contraseñas. Las directivas de contraseñas de Windows del equipo se exigen para los inicios de sesión de SQL Server. Esto incluye la longitud y complejidad de las contraseñas. Esta funcionalidad depende de la API NetValidatePasswordPolicy, que sólo está disponible en Windows Server 2003 y versiones posteriores.

Para determinar las directivas de las contraseñas del equipo local

En el menú Inicio, haga clic en Ejecutar. En el cuadro de diálogo Ejecutar, escriba secpol.msc y, a continuación, haga clic en

Aceptar. En la aplicación Configuración de seguridad local, expanda Configuración de

seguridad, expanda Directivas de cuenta y, a continuación, haga clic en Directiva de contraseñas.

Las directivas de contraseñas se describen en el panel de resultados.

- 85 -

Ventajas de la Autenticación de SQL Server

Permite a SQL Server admitir las aplicaciones anteriores y las que proporcionan terceros y requieren la autenticación de SQL Server.

Permite que SQL Server admita entornos con sistemas operativos mixtos, en los que un dominio de Windows no autentica a todos los usuarios.

Permite a los usuarios conectarse desde dominios desconocidos o que no son de confianza. Por ejemplo, una aplicación en la que los clientes establecidos se conectan con los inicios de sesión de SQL Server asignados para recibir el estado de sus pedidos.

Permite que SQL Server admita aplicaciones basadas en WEB en las que los usuarios crean sus propias identidades.

Permite a los desarrolladores de software distribuir sus aplicaciones utilizando una jerarquía de permisos compleja basada en los inicios de sesión conocidos y preestablecidos de SQL Server.

Desventajas de la Autenticación de SQL Server

Si un usuario del dominio de Windows tiene un inicio de sesión y una contraseña para Windows, aún debe proporcionar otro inicio de sesión y contraseña (SQL Server) para conectarse. Hacer el seguimiento de varios nombres y contraseñas es difícil para muchos usuarios. Tener que proporcionar las credenciales de SQL Server cada vez que se conectan a la base de datos puede resultar molesto.

La autenticación de SQL Server no puede utilizar el protocolo de seguridad de Kerberos.

Windows proporciona directivas de contraseñas adicionales que no están disponibles para los inicios de sesión de SQL Server.

SQL Server 2005 puede ser configurado para utilizar unos de estos modos de autenticación: Cuándo utilizar el Modo de Autenticación de Windows Utilice este modo en entornos de red en los cuales los usuarios son autenticados a través de cuentas de usuario de Windows. Ventajas de la Autenticación Windows

Permite agregar grupos de usuarios a SQL Server agregando una única cuenta de usuario

Permite a los usuarios acceder rápidamente a SQL Server sin tener que recordar cuenta y contraseña.

Cuándo utilizar el Modo Mixto Utilice este modo cuando tenga que permitir conectarse a SQL Server a usuarios o aplicaciones que no tengan credenciales Windows. Directiva de Contraseñas Cuando SQL Server 2005 se ejecuta en Windows Server 2003 o versiones posteriores, puede utilizar mecanismos de directiva de contraseñas de Windows. SQL Server 2005 puede aplicar las mismas directivas de complejidad y caducidad que se usan en Windows Server 2003 a las contraseñas que se usan en SQL Server. Esta funcionalidad

- 86 -

depende de la API NetValidatePasswordPolicy, que sólo está disponible en Windows Server 2003 y versiones posteriores. Las directivas de complejidad de contraseñas están diseñadas para impedir ataques por fuerza bruta mediante el aumento del número de contraseñas posibles. Cuando se aplica la directiva de complejidad de contraseñas, se exige que las nuevas contraseñas cumplan las siguientes directrices:

La contraseña no debe contener parte o todo el nombre de la cuenta del usuario. Una parte de un nombre de cuenta se define como tres o más caracteres alfanuméricos consecutivos delimitados en ambos extremos por un espacio en blanco, como un espacio, tabulación, retorno, etc., o por alguno de los siguientes caracteres: coma (,), punto (.), guión (-), carácter de subrayado (_) o signo de número (#).

La contraseña debe tener una longitud de ocho caracteres como mínimo. La contraseña debe contener caracteres de tres de las siguientes categorías:

o Letras en mayúsculas del alfabeto Latín (de la “A” a la “Z”) o Letras en minúsculas del alfabeto Latín (de la "a" a la "z") o Dígitos en base 10 (del 0 al 9) o Caracteres que no sean alfanuméricos, como signo de exclamación (!), signo de

moneda ($), signo de número (#) o porcentaje (%). Las contraseñas pueden tener hasta 128 caracteres. Se recomienda utilizar contraseñas lo más largas y complejas posible. Las directivas de caducidad de contraseñas se utilizan para administrar la duración de una contraseña. Cuando SQL Server 2005 aplica la directiva de caducidad de contraseñas, se recuerda a los usuarios que cambien las contraseñas antiguas, y las cuentas con contraseñas que han caducado se deshabilitan. Aplicación de las Directivas de Contraseñas La aplicación de la directiva de contraseñas se puede configurar independientemente para cada inicio de sesión de SQL Server. Utilice ALTER LOGIN para configurar las opciones de la directiva de contraseñas de un inicio de sesión de SQL Server. Se aplican las siguientes reglas a la configuración de la aplicación de directivas de contraseñas:

Cuando el valor de CHECK_POLICY se cambia a ON, ocurre lo siguiente: o CHECK_EXPIRATION también se establece en ON, salvo que se haya establecido

de forma explícita en OFF. o El historial de contraseñas se inicializa con el valor hash de la contraseña actual.

Cuando el valor de CHECK_POLICY se cambia a OFF, ocurre lo siguiente: o CHECK_EXPIRATION también se establece en OFF. o Se borra el historial de contraseñas. o Se restablece el valor de lockout_time.

Algunas combinaciones de opciones de directiva no se admiten.

Si se especifica MUST_CHANGE, CHECK_EXPIRATION y CHECK_POLICY deben

establecerse en ON. De lo contrario, se producirá un error en la instrucción. Si CHECK_POLICY se establece en OFF, CHECK_EXPIRATION no puede

establecerse en ON. Se producirá un error en una instrucción ALTER LOGIN que combine estas dos opciones.

Importante: CHECK_EXPIRATION y CHECK_POLICY sólo se aplican en Windows Server 2003 y versiones posteriores.

- 87 -

Un problema conocido de Windows Server 2003 puede impedir que el recuento de contraseñas erróneas se restablezca una vez alcanzado LockoutThreshold. Esto puede provocar un

bloqueo inmediato en posteriores intentos de inicio de sesión erróneos. Puede restablecer el recuento de contraseñas erróneas de forma manual; para ello, tiene que establecer simplemente CHECK_POLICY = OFF, seguido de CHECK_POLICY = ON. Cuando se ejecuta SQL Server en Windows 2000, puede establecer CHECK_POLICY = ON

para evitar la creación de contraseñas que sean: Nulas o vacías Iguales al nombre del equipo o el inicio de sesión Una de las siguientes: "password", "admin", "administrator", "sa", "sysadmin"

Contraseñas Seguras Las contraseñas pueden constituir el vínculo más débil de una implementación de seguridad de servidor. Debe tener siempre mucho cuidado a la hora de elegir una contraseña. Una contraseña segura presenta las siguientes características:

Tiene una longitud de 8 caracteres como mínimo. Contiene una combinación de letras, números y símbolos. No es una palabra que pueda encontrarse en el diccionario. No es el nombre de un comando. No es el nombre de una persona. No es el nombre de un usuario. No es el nombre de un equipo. Se cambia con frecuencia. Presenta diferencias notables con respecto a contraseñas anteriores.

Las contraseñas de SQL Server pueden contener hasta 128 caracteres, entre los que se pueden incluir letras, símbolos y dígitos. Dado que los inicios de sesión, nombres de usuario, funciones y contraseñas se utilizan con frecuencia en instrucciones Transact-SQL, determinados símbolos deberán estar incluidos entre comillas dobles (") o corchetes ([ ]). Utilice estos delimitadores en las instrucciones Transact-SQL cuando el inicio de sesión, usuario, función o contraseña de SQL Server presente las siguientes características:

Contiene o comienza por un carácter de espacio. Comienza por el carácter $ o @.

Si se utiliza en una cadena de conexión OLE DB u ODBC, el inicio de sesión o la contraseña no deben contener ninguno de los siguientes caracteres: [] {}() , ; ? * ! @. Estos caracteres se utilizan para inicializar una conexión o para separar valores de conexión. Inicios de Sesión en SQL Server (login) Manejo de Inicios de Sesión La mayoría de usuarios de Windows necesitan un inicio de sesión de SQL Server para conectarse a SQL Server. A continuación se describen distintas opciones para crear un inicio de sesión en SQL Server: Para crear un inicio de sesión de SQL Server que use la autenticación de Windows (SQL Server Management Studio)

En SQL Server Management Studio, abra el Explorador de objetos y expanda la carpeta de la instancia de servidor en la que se creará el nuevo inicio de sesión.

Haga clic con el botón secundario en la carpeta Seguridad, seleccione Nuevo y, a continuación, Inicio de sesión.

- 88 -

En la página General, escriba el nombre de un usuario de Windows en el cuadro

Nombre de inicio de sesión. Seleccione Autenticación de Windows. Haga clic en Aceptar.

Para crear un inicio de sesión de SQL Server que use la autenticación de SQL Server (SQL Server Management Studio)

En SQL Server Management Studio, abra el Explorador de objetos y expanda la carpeta de la instancia de servidor en la que se creará el nuevo inicio de sesión.

Haga clic con el botón secundario en la carpeta Seguridad, seleccione Nuevo y, a continuación, Inicio de sesión.

En la página General, escriba un nombre para el nuevo inicio de sesión en el cuadro

Nombre de inicio de sesión. Seleccione Autenticación de SQL Server. La autenticación de Windows es la opción

más segura. Escriba una contraseña de inicio de sesión. Seleccione las opciones de la directiva de contraseñas que deben aplicarse al nuevo

inicio de sesión. En general, exigir la directiva de contraseñas es la opción más segura. Haga clic en Aceptar.

- 89 -

Para crear un inicio de sesión de SQL Server que use la autenticación de Windows con Transact-SQL

CREATE LOGIN <nombre de usuario Windows> FROM WINDOWS GO

Para crear un inicio de sesión de SQL Server que use la autenticación de SQL Server con Transact-SQL El ejemplo siguiente crea un inicio de sesión para un usuario determinado y asigna una contraseña. La opción MUST_CHANGE requiere que los usuarios cambien la contraseña la primera vez que se conectan al servidor. CREATE LOGIN <nombre login> WITH PASSWORD = '<password>' MUST_CHANGE; GO Ejemplos: a. Para crear un inicio de sesión asociado a una credencial CREATE LOGIN Mary WITH PASSWORD = '<password>', CREDENTIAL = <nombre_credenciall>; GO b. Para crear un inicio de sesión desde un certificado USE MASTER; CREATE CERTIFICATE <Nombre_certificado> WITH SUBJECT = '<nombre_login> CERTIFICATE IN master database', EXPIRY_DATE = '02/02/2009'; GO CREATE LOGIN < nombre_login > FROM CERTIFICATE < Nombre_certificado >; GO c. Para crear un inicio de sesión desde una cuenta de dominio de Windows CREATE LOGIN [Adventure-Works\Mary] FROM WINDOWS; GO Modificación de Inicios de Sesión Se pueden modificar inicios de sesión desde sus propiedades en el Explorador de Objetos de SQL Management Studio o bien utilizando ALTER LOGIN. Una utilización común de ALTER LOGIN es por ejemplo para desbloquear un inicio de sesión que fue bloqueado porque expiró su contraseña como se muestra a continuación: ALTER LOGIN Alice WITH PASSWORD = 'NewPa$$w0rd' UNLOCK Eliminación de Inicios de Sesión Se pueden eliminar un inicio de sesión con clic derecho sobre él en el Explorador de Objetos y luego elegir Delete, o bien utilizando DROP LOGIN, como se muestra en el siguiente ejemplo:

- 90 -

DROP LOGIN Alice Asignación de una cuenta de inicio de sesión a una función fija de servidor Usted puede utilizar las propiedades de inicio de sesión en el SQL Management Studio o bien el procedimiento almacenado de sistema sp_addsrvrolemember para agregar un inicio de sesión como miembro de una función fija de servidor. Solo los miembros de funciones fijas de servidor pueden ejecutar este procedimiento almacenado. Cuando usted agrega una cuenta de inicio de sesión a una función fija de servidor, la cuenta adquiere los permisos asociados a esa función. Al realizarlo tenga en cuenta lo siguiente:

Usted no puede agregar, modificar o eliminar las funciones fijas de servidor.

Cualquier miembro de una función fija de servidor puede agregar otra cuenta de inicio de sesión a esa función.

El procedimiento almacenado de sistema sp_addsrvrolemember no puede ser ejecutado dentro de una transacción definida por el usuario

Usted puede utilizar el procedimiento almacenado de sistema sp_dropsrvrolemember para eliminar un miembro de una función fija de servidor.

Usuarios de SQL Server Cómo crear un usuario de base de datos En este tema se explica cómo crear un usuario de base de datos asignado a un inicio de sesión de SQL Server. En este tema se asume que existe el correspondiente inicio de sesión de SQL Server. Para crear un usuario de base de datos mediante SQL Server Management Studio

En SQL Server Management Studio, abra el Explorador de objetos y expanda la carpeta Bases de datos.

Expanda la base de datos en la que se va a crear el usuario de la misma. Haga clic con el botón secundario en la carpeta Seguridad, seleccione Nuevo y, a

continuación, haga clic en Usuario. En la página General, escriba un nombre para el usuario en el cuadro Nombre de

usuario. En el cuadro Nombre de inicio de sesión, escriba el nombre de un inicio de sesión de

SQL Server para asignarlo al usuario de la base de datos. Haga clic en Aceptar.

- 91 -

Para crear un usuarios de bases de datos mediante Transact-SQL USE <nombre_base_datos> GO CREATE USER <nombre usuario> FOR LOGIN <nombre login>; GO Ejemplos: a. Crear un usuario de base de datos CREATE LOGIN John WITH PASSWORD = '340$Uuxwp7Mcxo7Khy'; USE AdventureWorks; CREATE USER John FOR LOGIN John b. Crear un usuario de base de datos con un esquema predeterminado CREATE LOGIN Mary WITH PASSWORD = '8fdKJl3$nlNv3049jsKK';

- 92 -

USE AdventureWorks; CREATE USER Mary FOR LOGIN Mary WITH DEFAULT_SCHEMA = Marketing; C. Crear un usuario de base de datos desde un certificado CREATE CERTIFICATE Produccion50 WITH SUBJECT = 'Carnation Production Facility Supervisors', EXPIRY_DATE = '11/11/2011'; GO CREATE USER Peter FOR CERTIFICATE Production50; Usuarios especiales de SQL Server

Cuenta de usuario dbo: dbo o propietario de base de datos, es una cuenta de usuario con permisos implícitos para realizar todas las actividades en la base de datos. Los miembros de la función fija del servidor sysadmin se asignan automáticamente a dbo. La cuenta de usuario dbo se confunde a menudo con la función fija de base de datos db_owner. El ámbito de db_owner es una base de datos y el ámbito de sysadmin es el servidor completo. La pertenencia a la función db_owner no proporciona privilegios de usuario dbo.

Cuenta de usuario guest: Después de que un usuario se haya autenticado y se le haya permitido iniciar sesión en una instancia de SQL Server, debe existir una cuenta de usuario independiente en cada base de datos a la que tenga acceso el usuario. Si se exige una cuenta de usuario en cada base de datos, se impide que los usuarios se conecten a una instancia de SQL Server y puedan tener acceso a todas las bases de datos de un servidor. La existencia de una cuenta de usuario guest en la base de datos evita este requisito, ya que permite que un inicio de sesión sin cuenta de usuario de base de datos tenga acceso a una base de datos. La cuenta guest es una cuenta integrada en todas las versiones de SQL Server. De forma predeterminada, está deshabilitada en las bases de datos nuevas. Si está habilitada, se puede deshabilitar mediante la revocación de su permiso CONNECT, que se lleva a cabo con la ejecución de la instrucción REVOKE CONNECT FROM GUEST de Transact-SQL.

Nota: Se debe evitar el uso de la cuenta guest, ya que todos los inicios de sesión que no dispongan de permisos de base de datos propios obtendrán los permisos de base de datos concedidos a esta cuenta. Si debe usar la cuenta guest, concédale los permisos mínimos. Delegación SQL Server y Windows pueden estar configurados para permitir que una instancia de SQL Server se conecte a otra instancia de SQL Server en el mismo contexto de un usuario autenticado por Windows. Esta técnica se denomina delegación. Por ejemplo, un procedimiento almacenado en una base de datos en el Servidor1 podría consultar una tabla en una base de datos en el Servidor2. Cuando se utiliza delegación, el procedimiento almacenado utiliza la identidad del usuario que lo llamó cuando requiera datos del Servidor2. Requerimientos para Delegación Para utilizar delegación, todos los servidores a los cuales usted está conectado deben ejecutar Windows 2000 o Windows Server 2003 con el soporte Kerberos habilitado, y usted debe utilizar Active Directory®.

- 93 -

Windows Server 2003 permite delegaciones más específicas que versiones anteriores de Windows. Windows Server 2003 permite establecer derechos de delegación a una combinación particular de servicios. Configurando Active Directory para Delegación Usted debe establecer las siguientes opciones de cuenta en Active Directory para que funcione la delegación:

La cuenta es sensible y no puede ser delegada (Account is sensitive and cannot be delegated.) Usted no debe elegir esta opción para un pedido de delegación de un usuario

La cuenta es confiable para delegación (Account is trusted for delegation.). Usted debe elegir esta opción para la cuenta de servicio de SQL Server

La computadora es confiable para delegación (Computer is trusted for delegation.) Usted debe elegir esta opción para la computadora donde se ejecuta SQL Server.

Configurando SQL Server para Delegación Para utilizar seguridad de delegación de cuenta, SQL Server debe tener un Nombre Principal de Servidor (Service Principal Name - SPN) asignado por el administrador de cuenta de dominio de Windows Server 2003 a la cuenta de servicio de SQL Server y estar utilizando TCP/IP. Si el servicio de SQL Server se está ejecutando bajo una cuenta de Sistema Local, automáticamente el servicio SQL Server registrará un SPN al iniciar el servicio y lo des-registrará al cerrar SQL Server. Credenciales Una credencial es un registro que contiene la información de autenticación (credenciales) necesaria para conectarse a un recurso situado fuera de SQL Server. Esta información la utiliza SQL Server internamente. La mayoría de las credenciales incluyen un nombre de usuario y una contraseña de Windows. La información almacenada en una credencial permite al usuario que se ha conectado a SQL Server mediante la autenticación de SQL Server obtener acceso a recursos situados fuera de la instancia del servidor. Cuando el recurso externo es Windows, el usuario se autentica como el usuario de Windows especificado en la credencial. Se puede asignar una única credencial a varios inicios de sesión de SQL Server. Sin embargo, un inicio de sesión de SQL Server sólo se puede asignar a una credencial. Las credenciales del sistema se crean de forma automática y se asocian a extremos específicos. Los nombres de las credenciales del sistema comienzan por dos signos de número (##). Usted puede crear una credencial desde SQL Management Studio o bien utilizando CREATE CREDENTIAL. CREATE CREDENTIAL nombre credencial WITH IDENTITY = 'nombre_identity' [ , SECRET = 'secreto' ] Argumentos:

Nombre credencial: especifica el nombre de la credencial a ser creada. No puede comenzar con el símbolo #.

Nombre_identity: Especifica el nombre de la cuenta que se utilizará para la conexión fuera del servidor.

secreto: Especifica una palabra secreta para la autenticación. Esta cláusula es opcional.

- 94 -

Módulo 4

Monitoreo de SQL Server

- 95 -

1- Monitorear la Actividad en Curso Determinar la actividad de los usuarios Se puede monitorear la actividad de cada usuario para identificar el tipo y la ubicación de las transacciones de bloqueo o el rendimiento lento de Microsoft SQL Server. La supervisión de la actividad de los usuarios ayuda a identificar tendencias como los tipos de transacciones ejecutadas por los usuarios, el número de consultas ineficaces y ad hoc, y los tipos de transacciones que requieren la mayor parte de los recursos. Para recopilar información estadística sobre los usuarios, utilice el Analizador de SQL Server o el Monitor de sistema. Utilice el Monitor de actividad de SQL Server Management Studio para la supervisión ad hoc de SQL Server, lo que permite determinar la actividad de los usuarios en el sistema. El Monitor de actividad (SQL Server Management Studio) Use el componente Monitor de actividad de Microsoft SQL Server Management Studio para obtener información sobre las conexiones de los usuarios al Motor de base de datos y los bloqueos que mantienen. El Monitor de actividad tiene tres páginas.

La página Información del proceso contiene información acerca de las conexiones. En la página Bloqueos por proceso se ordenan los bloqueos por conexión. En la página Bloqueos por objeto se ordenan los bloqueos por el nombre del objeto.

Haga clic en el botón Filtrar para aplicar un filtro con el fin de reducir la cantidad de información

mostrada. Utilice el Monitor de actividad al solucionar problemas de bloqueo y para terminar un proceso en interbloqueo (deadlock) o que no responde. Para ver el Monitor de actividad el usuario precisa el permiso VIEW SERVER STATE en SQL

Server 2005 y versiones posteriores del servidor SQL Server. Para ver el Monitor de actividad, el usuario necesita el permiso SELECT en las tablas sysprocesses y syslocks, en la base de datos maestra, en un servidor SQL Server 2000. El

permiso para ver estas tablas se concede de forma predeterminada a la función de base de datos Public. De forma predeterminada, los miembros de las funciones fijas de base de datos sysadmin y

processadmin tienen el permiso KILL; este permiso no se puede transferir.

Para abrir el Monitor de actividad en SQL Server Management Studio, conéctese al servidor mediante el Explorador de objetos, expanda Administración y, a continuación, haga doble clic en Monitor de actividad.

- 96 -

Monitor de actividad de trabajo El Monitor de actividad de trabajo permite ver la tabla sysjobactivity mediante SQL Server

Management Studio. Puede ver todos los trabajos del servidor, o bien puede definir filtros para limitar el número de trabajos mostrados. También puede ordenar la información sobre los trabajos haciendo clic en un encabezado de columna de la cuadrícula Actividad de Trabajo del Agente. Por ejemplo, al seleccionar el encabezado de columna Última ejecución, puede

ver los trabajos en el orden en que se ejecutaron por última vez. Al volver a hacer clic en el encabezado de columna, el orden de los trabajos cambia entre ascendente y descendente basándose en la fecha en que se ejecutaron por última vez. El Monitor de actividad de trabajo le permite realizar las siguientes tareas:

Iniciar y detener trabajos. Ver las propiedades del trabajo. Ver el historial de un determinado trabajo. Actualizar la información de la cuadrícula Actividad de trabajo del agente

manualmente o establecer un intervalo de actualización automático haciendo clic en Ver configuración de actualización.

- 97 -

Utilice el Monitor de actividad de trabajo cuando desee localizar los trabajos que están programados para su ejecución, el último resultado de los trabajos que se han ejecutado durante la sesión actual y localizar los trabajos que se están ejecutando actualmente o que están inactivos. Si el servicio del Agente SQL Server tiene un error inesperado, puede determinar los trabajos que se estaban ejecutando buscando en la sesión anterior del Monitor de Actividad de Trabajo. Para Ver la Actividad de Trabajo (SQL Server Management Studio) Cuando se inicia el servicio del Agente Microsoft SQL Server, se crea una nueva sesión y la tabla sysjobactivity de la base de datos msdb se llena con todos los trabajos definidos que

existen. En esta tabla se registra la actividad y el estado actuales de los trabajos. Puede utilizar el Monitor de Actividad de trabajo del Agente SQL Server para ver el estado actual de los trabajos. Si el servicio del Agente SQL Server finaliza inesperadamente, puede consultar la tabla sysjobactivity para ver qué trabajos se estaban ejecutando cuando finalizó el servicio.

Para ver la actividad de los trabajos

En el Explorador de objetos, conéctese a una instancia del Motor de base de datos

de SQL Server y expándala. Expanda Agente SQL Server.

Haga clic con el botón secundario en Monitor de Actividad de Trabajo y haga clic en

Ver actividad de trabajo. En el Monitor de actividad de trabajo, puede ver los detalles de cada trabajo definido

para este servidor. Haga clic con el botón secundario en un trabajo para iniciarlo, detenerlo, habilitarlo o

deshabilitarlo, actualizar el estado que se muestra en el Monitor de Actividad de Trabajo, eliminarlo o ver su historial o sus propiedades. Para iniciar, detener, habilitar o deshabilitar, o actualizar varios trabajos, seleccione varias filas y haga clic con el botón secundario en la selección.

Para actualizar el Monitor de actividad de trabajo, haga clic en Actualizar. Para ver menos filas, haga clic en Filtro y escriba los parámetros del filtro.

También puede ver la actividad de trabajo de la sesión actual mediante el procedimiento almacenado sp_help_jobactivity.

- 98 -

Sesiones del Agente SQL Server El Agente SQL Server crea una sesión cada vez que se inicia el servicio. Al crear una sesión, la tabla sysjobactivity de la base de datos msdb se rellena con todos los trabajos definidos

existentes. Esta tabla mantiene la última actividad para los trabajos cuando se reinicia el Agente SQL Server. Cada sesión registra la actividad de trabajo normal del Agente SQL Server desde el inicio del trabajo hasta que se termina. La información acerca de estas sesiones se almacena en la tabla syssessions de la base de datos msdb.

Funciones y Vistas de Administración Dinámica Las funciones y vistas de administración dinámica devuelven información sobre el estado del servidor que se puede utilizar para controlar el estado de una instancia del servidor, para diagnosticar problemas y para optimizar el rendimiento. Hay dos tipos de funciones y vistas de administración dinámica:

Funciones y vistas de administración dinámica con ámbito en el servidor. Se requiere el permiso VIEW SERVER STATE en el servidor.

Funciones y vistas de administración dinámica con ámbito en la base de datos. Se requiere el permiso VIEW DATABASE STATE en la base de datos.

Para ejecutar una consulta en una función o vista de administración dinámica, es necesario el permiso SELECT sobre el objeto y el permiso VIEW SERVER STATE o VIEW DATABASE STATE. Así podrá restringir de forma selectiva el acceso de un usuario o inicio de sesión a las

- 99 -

funciones y vistas de administración dinámica. Para ello, cree primero el usuario en la base de datos master y, a continuación, deniéguele el permiso SELECT sobre las funciones o vistas de

administración dinámica a las que no desea que tenga acceso. Después de esto, el usuario no podrá seleccionar ninguna de estas funciones o vistas de administración dinámica, sin tener en cuenta el contexto de la base de datos del usuario. Nota: Dado que el permiso DENY tiene prioridad, si un usuario tiene concedido el permiso VIEW SERVER STATE, pero tiene denegado el permiso VIEW DATABASE STATE, el usuario podrá ver la información en el servidor, pero no en la base de datos. Se muestran a continuación algunas de las vistas de administración dinámica más comunes:

Vista de Administración Dinámica

Descripción

sys.dm_db_partition_stats Devuelve información de página y recuento de filas de cada partición en la base de datos actual.

sys.dm_exec_sessions Devuelve una fila por cada sesión autenticada en SQL Server. sys.dm_exec_sessions es una vista de ámbito de servidor que muestra información acerca de todas las conexiones de usuario activas y las tareas internas.

sys.dm_io_pending_io_requests Devuelve una fila para cada petición de E/S pendiente de SQL Server.

sys.dm_os_memory_pools Devuelve una fila para cada almacén de objetos en la instancia de SQL Server.

sys.dm_os_threads Devuelve una lista de todos los subprocesos del sistema operativo SQL Server que se están ejecutando en el proceso de SQL Server.

sys.dm_broker_queue_monitors Devuelve una fila por cada monitor de cola en la instancia. Un monitor de cola administra la activación de una cola.

sys.dm_tran_locks Devuelve información acerca de los recursos del administrador de bloqueos activos actualmente.

Vistas de Catálogo (Transact-SQL) Las vistas de catálogo devuelven información utilizada por el Motor de base de datos de SQL Server 2005 de Microsoft. Se recomienda utilizar las vistas de catálogo porque son la interfaz más general para los metadatos del catálogo y proporcionan el método más eficaz para obtener, transformar y presentar formas personalizadas de esta información. Todos los metadatos del catálogo disponibles para el usuario se exponen mediante las vistas de catálogo. Las vistas de catálogo no contienen información sobre los datos de catálogo de réplica, copia de seguridad, plan de mantenimiento de bases de datos o Agente SQL Server. Algunas vistas de catálogo heredan filas de otras vistas de catálogo. Por ejemplo, la vista de catálogo sys.tables hereda de la vista de catálogo sys.objetcs. La vista de catálogo

sys.objects se denomina vista base y la vista sys.tables se denomina vista derivada. La vista de catálogo sys.tables devuelve las columnas específicas de tablas y todas las columnas que devuelve la vista de catálogo sys.objects. La vista de catálogo sys.objects devuelve filas de

objetos distintos de tablas, como procedimientos almacenados y vistas. Después de crear una tabla, sus metadatos se devuelven en ambas vistas. Si bien las dos vistas de catálogo devuelven diferentes niveles de información sobre la tabla, sólo existe una entrada en los metadatos para esta tabla con un nombre y un object_id. Esto se puede resumir de la manera

siguiente: La vista base contiene un subconjunto de columnas y un superconjunto de filas.

- 100 -

La vista derivada contiene un superconjunto de columnas y un subconjunto de filas. Consulta de una Vista de Administración Dinámica Todas las funciones y vistas de administración dinámica existen en el esquema sys y siguen la convención de nomenclatura siguiente: dm_*. Cuando utilice una función o vista de

administración dinámica, debe agregar un prefijo al nombre de la función o vista mediante el esquema sys.

Por ejemplo, para consultar la vista de administración dinámica dm_os_wait_stats, ejecute la

consulta siguiente: SELECT wait_type, wait_time_ms FROM sys.dm_os_wait_stats GO

- 101 -

2- Monitor de Sistemas (Windows) Utilice el Monitor de sistema para supervisar el uso de los recursos del sistema. Recopile y vea datos de rendimiento en tiempo real en forma de contadores para recursos de servidor, como el uso del procesador y la memoria, y para muchos recursos de Microsoft SQL Server, como los bloqueos y las transacciones. Para iniciar el Monitor de sistema en Windows en el menú Inicio, haga clic en Ejecutar, escriba

perfmon en el cuadro de texto y haga clic en Aceptar. O seleccione la opción Rendimiento de

las Herramientas Administrativas del Panel de Control.

Usar Objetos de SQL Server SQL Server incluye objetos y contadores que puede utilizar el Monitor de Sistema para

monitorear la actividad de los equipos en los que se ejecute una instancia de SQL Server. Un objeto es cualquier recurso de SQL Server como, por ejemplo, un bloqueo de SQL Server o un proceso de Windows XP. Cada objeto contiene uno o más contadores que determinan diversos aspectos de los objetos que se van a Monitorear. Por ejemplo, el objeto Bloqueos de SQL Server contiene los contadores Número de interbloqueos/seg. y Tiempos de espera de bloqueos/seg. Algunos objetos tienen varias instancias si existen varios recursos de un determinado tipo en el equipo. Por ejemplo, el tipo de objeto Procesador tendrá varias instancias si un sistema contiene varios procesadores. El tipo de objeto Bases de datos tiene una instancia para cada base de datos de SQL Server. Algunos tipos de objetos (por ejemplo, el objeto Administrador de memoria) tienen sólo una instancia. Si un tipo de objeto tiene varias instancias, puede

agregar contadores para realizar un seguimiento de las estadísticas relativas a cada instancia o, en muchos casos, de todas las instancias a la vez. Los contadores de la instancia predeterminada aparecen con el formato SQLServer:<object name>. Los contadores de las

- 102 -

instancias con nombre aparecen con el formato MSSQL$<instance name>:<counter name> o SQLAgent$<instance name>:<counter name>.

Al agregar o quitar contadores en el gráfico y guardar la configuración del gráfico, puede especificar los objetos y contadores de SQL Server que se supervisan al iniciar el Monitor de sistema. Puede configurar el Monitor de sistema para que muestre las estadísticas de cualquier contador de SQL Server. Además, puede establecer un valor de umbral para cualquier contador de SQL Server y generar posteriormente una alerta cuando un contador supere dicho umbral. Nota: Las estadísticas de SQL Server se muestran sólo si se instala una instancia de SQL Server. Si detiene y reinicia una instancia de SQL Server, se interrumpirá la presentación de estadísticas y, después, se reanudará automáticamente. Tenga en cuenta también que verá los contadores de SQL Server en el complemento del Monitor de sistema incluso si SQL Server no se está ejecutando. En una instancia agrupada, los contadores de rendimiento sólo funcionan en el nodo en el que se ejecuta SQL Server. En la siguiente tabla se describen los objetos de SQL Server.

Objeto de rendimiento Descripción

SQLServer:Métodos de acceso

Mide y realiza búsquedas mediante objetos de base de datos de SQL Server y su asignación (por ejemplo, el número de búsquedas de índices o de páginas asignadas a índices y datos).

SQLServer:Backup Device Proporciona información acerca de dispositivos de copia de seguridad utilizados para operaciones de copia de seguridad y restauración, como el rendimiento del dispositivo.

SQLServer:Buffer Manager Proporciona información acerca de los búferes de memoria que utiliza SQL Server, como la memoria disponible y la proporción de aciertos de caché del búfer.

SQLServer:Buffer Manager Proporciona información acerca de la frecuencia con que SQL Server solicita páginas libres y obtiene acceso a las mismas.

SQLServer:CLR Proporciona información acerca de CLR.

SQLServer:Cursor Manager by Type

Proporciona información acerca de los cursores.

SQLServer:Cursor Manager Total

Proporciona información acerca de los cursores.

SQLServer: Database Mirroring

Proporciona información acerca de la creación de reflejos de la base de datos.

SQLServer:Databases Proporciona información acerca de una base de datos de SQL Server, como la cantidad de espacio de registro disponible o el número de transacciones activas en la base de datos. Pueden existir múltiples instancias de este objeto.

SQLServer:Exec Statistics Proporciona información acerca de las estadísticas de ejecución.

SQLServer General Statistics

Proporciona información acerca de la actividad general de todo el servidor, como el número de usuarios conectados a una instancia de SQL Server.

SQLServer Latches Proporciona información acerca de los pestillos de los recursos internos, como las páginas de las bases de datos que utiliza SQL Server.

SQLServer:Locks Proporciona información acerca de las peticiones de bloqueo individuales que realiza SQL Server, como los tiempos de espera de bloqueos y los interbloqueos. Pueden existir múltiples instancias de este objeto.

- 103 -

SQLServer:Memory Manager

Proporciona información acerca de la utilización de memoria de SQL Server como, por ejemplo, el número total de estructuras de bloqueo asignadas actualmente.

SQLServer:Caché del plan Proporciona información acerca de la caché de SQL Server que se utiliza para almacenar objetos como procedimientos almacenados, desencadenadores y planes de consultas.

SQLServer:SQL Errors Proporciona información acerca de los errores de SQL Server.

SQLServer:Estadísticas de SQL

Proporciona información acerca de aspectos de consultas de Transact-SQL, como el número de lotes de instrucciones Transact-SQL que recibe SQL Server.

SQLServer Transactions Proporciona información acerca de las transacciones activas de SQL Server, como el número global de transacciones y el número de transacciones de instantáneas.

SQLServer:User Settable Realiza una supervisión personalizada. Cada contador puede ser un procedimiento almacenado personalizado o cualquier instrucción Transact-SQL que devuelva un valor para Monitorear.

SQLServer: Wait Statistics Proporciona información acerca de las esperas.

La posibilidad de utilizar los objetos de SQL Server depende de los permisos de Windows, salvo SQLAgent:Alertas. Los usuarios deben ser miembros de la función fija de servidor

sysadmin para poder utilizar SQLAgent:Alertas.

Consideraciones de Monitoreo de SQL Server Si está ejecutando el sistema operativo de servidor de Microsoft Windows, utilice la herramienta gráfica Monitor de Sistema para medir el rendimiento de SQL Server. Puede ver en los

objetos de SQL Server, los contadores de rendimiento y el comportamiento de otros objetos, como procesadores, memoria, caché, subprocesos y procesos. Cada uno de estos objetos tiene asociado un conjunto de contadores que miden el uso de los dispositivos, la longitud de las colas, las demoras y otros indicadores del rendimiento y la congestión interna. Al monitorear SQL Server y el sistema operativo Microsoft Windows para investigar problemas relacionados con el rendimiento, hay tres áreas principales en las que debe concentrarse inicialmente:

Actividad del disco Uso del procesador Uso de la memoria

Puede resultar útil monitorear el sistema operativo Windows y los contadores de SQL Server al mismo tiempo para determinar las posibles correlaciones entre el rendimiento de SQL Server y el de Windows. Por ejemplo, la supervisión simultánea de los contadores de E/S de disco de Windows y los contadores del Administrador de búfer de SQL Server puede mostrar el comportamiento del sistema en su totalidad. La supervisión de un equipo en el que se ejecuta el Monitor de sistema puede afectar un poco al rendimiento del equipo. Por tanto, registre los datos del Monitor de Sistema en otro disco o en otro equipo para reducir así el efecto en el equipo que está supervisando, o bien ejecute el Monitor de Sistema desde un equipo remoto. Supervise sólo los contadores en los que esté interesado. Si supervisa demasiados contadores, la sobrecarga de uso de los recursos se agrega al proceso de supervisión y afecta al rendimiento del equipo que se está supervisando. El Monitor de sistema permite obtener estadísticas sobre la actividad y el rendimiento actuales de SQL Server. Con el Monitor de sistema, puede:

Ver simultáneamente datos de cualquier número de equipos.

- 104 -

Ver y cambiar gráficos para reflejar la actividad actual y mostrar valores de contadores que se actualizan con la frecuencia definida por el usuario.

Exportar datos desde gráficos, registros, registros de alertas e informes a aplicaciones de hoja de cálculo o de base de datos para manipularlos e imprimirlos.

Agregar alertas del sistema que muestran un evento en el registro de alertas y que pueden notificarse mediante una alerta de red.

Ejecutar un programa predefinido la primera vez, o todas las veces, que el valor de un contador sea superior o inferior a un valor definido por el usuario.

Crear archivos de registro que contengan datos relativos a diversos objetos de equipos diferentes.

Anexar a un archivo secciones seleccionadas de otros archivos de registro existentes para crear un archivo de almacenamiento a largo plazo.

Ver informes de la actividad actual o crear informes a partir de archivos de registro existentes.

Guardar la configuración de gráficos, alertas, registros o informes individuales, o bien de toda el área de trabajo, para volverla a utilizar.

Monitorear la Actividad del Disco Microsoft SQL Server utiliza las llamadas de entrada y salida (E/S) del sistema operativo Microsoft Windows para realizar operaciones de lectura y escritura en el disco. SQL Server administra cuándo y cómo se realiza la E/S del disco, pero el sistema operativo Windows realiza las operaciones de E/S subyacentes. El subsistema de E/S incluye el bus del sistema, tarjetas controladoras de disco, discos, unidades de cinta, la unidad de CD-ROM y muchos otros dispositivos de E/S. La E/S del disco es una causa frecuente de los atascos en un sistema. La supervisión de la actividad del disco implica dos aspectos básicos:

Monitorear la E/S del disco y detectar la paginación excesiva Aislar la actividad del disco creada por SQL Server

Monitorear la E/S del Disco y Detectar la Paginación Excesiva Dos de los contadores que se pueden Monitorear para determinar la actividad del disco son:

DiscoFísico: % Tiempo de disco DiscoFísico: Long. media de la cola de disco

En el Monitor del sistema, el contador DiscoFísico: % Tiempo de disco supervisa el porcentaje de tiempo que el disco está ocupado con operaciones de lectura y escritura. Si el valor del contador DiscoFísico: % Tiempo de disco es alto (más del 90%), compruebe el contador DiscoFísico: Longitud actual de la cola de disco para ver el número de peticiones

del sistema que están en espera de acceso al disco. El número de peticiones de E/S en espera debe mantenerse en un máximo de 1.5 a 2 veces el número de ejes que componen el disco físico. La mayor parte de los discos tienen un eje, aunque los dispositivos de matriz redundante de discos independientes (RAID, Redundant Array of Independent Disks) suelen tener más. Un dispositivo RAID de hardware aparece como un disco físico en el Monitor del Sistema. Los dispositivos RAID creados mediante software aparecen como varias instancias en el Monitor del Sistema. Utilice los valores de los contadores Longitud actual de la cola de disco y % Tiempo de disco para detectar puntos de congestión en el subsistema de disco. Si los valores de los contadores Longitud actual de la cola de disco y % Tiempo de disco son altos, considere la

posibilidad de: Utilizar una unidad de disco más rápida.

- 105 -

Mover algunos archivos a otro disco o servidor. Agregar discos a una matriz RAID, si se está utilizando una.

Si utiliza un dispositivo RAID, el contador % Tiempo de disco puede indicar un valor superior al 100%. En tal caso, utilice el contador DiscoFísico: Long. media de la cola de disco para

determinar el promedio de peticiones del sistema que están en espera de acceso al disco. Las aplicaciones y sistemas enlazados a E/S pueden mantener el disco constantemente activo. Supervise el contador Memoria: Errores de página/s. para asegurarse de que la actividad del

disco no está causada por la paginación. En Windows, la paginación está causada por lo siguiente:

Procesos configurados para utilizar demasiada memoria Actividad del sistema de archivos

Si tiene más de una partición lógica en el mismo disco duro, utilice los contadores Disco lógico en lugar de los contadores Disco físico. Si observa los contadores de disco lógico, podrá determinar los archivos con un acceso frecuente. Una vez que haya encontrado los discos con mucha actividad de lectura y escritura, observe los contadores específicos de lectura y escritura para ver el tipo de actividad del disco que causa la carga en cada volumen lógico. Por ejemplo, Disco lógico: Bytes escritos en disco por segundo.

Aislar la Actividad del Disco creada por SQL Server Dos de los contadores que se pueden Monitorear para determinar el volumen de actividad de E/S que generan los componentes de SQL Server son los siguientes:

SQL Server:Buffer Manager:Lecturas de página/seg. SQL Server:Buffer Manager:Escrituras de página/seg.

En el Monitor del Sistema, estos contadores supervisan el volumen de actividad de E/S que generan los componentes de SQL Server examinando las áreas de rendimiento siguientes:

Escritura de páginas en disco Lectura de páginas del disco

Si los valores de estos contadores comienzan a acercarse al límite de capacidad del subsistema de E/S de hardware, intente reducirlos, ya sea optimizando la aplicación o la base de datos, para reducir las operaciones de E/S (como el alcance de los índices, mejores índices o la normalización), aumentando la capacidad de E/S del hardware o agregando memoria. Por ejemplo, puede utilizar el Asistente para la optimización de motor de base de datos para analizar cargas de trabajo habituales de SQL Server y crear recomendaciones para índices, vistas indexadas y particiones con el fin de mejorar el rendimiento del servidor. Monitorear el Uso de la CPU Supervise una instancia de Microsoft SQL Server periódicamente para determinar si los índices de uso de la CPU son normales. Un índice de uso de la CPU constantemente alto puede indicar la necesidad de actualizar la CPU o de agregar varios procesadores. Además, un uso alto de la CPU puede indicar que hay una aplicación mal optimizada o diseñada. La optimización de la aplicación puede reducir el uso de la CPU. El contador Procesador: % de tiempo de procesador en el Monitor de sistema es la forma

más eficaz de determinar el uso de la CPU. Este contador supervisa el tiempo que la CPU dedica a la ejecución de un subproceso que no está inactivo. Un estado continuado de entre el 80 y el 90 por ciento puede ser indicativo de que es necesario actualizar la CPU o bien agregar más procesadores. Para sistemas con múltiples procesadores, es necesario monitorear una instancia independiente de este contador para cada procesador. Este valor representa la suma

- 106 -

del tiempo de procesador en un procesador específico. Para determinar el promedio de todos los procesadores, utilice el contador Sistema: % Tiempo total de procesador.

Para monitorear el uso del procesador también puede utilizar los siguientes contadores:

Procesador: % Tiempo privilegiado: Porcentaje de tiempo de procesador dedicado

a la ejecución de comandos del núcleo de Microsoft Windows, como el procesamiento de solicitudes de E/S de SQL Server. Si este contador es constantemente alto cuando los contadores Disco físico son altos, considere la posibilidad de instalar un

subsistema de disco más rápido o eficaz. Procesador: % Tiempo de usuario: Porcentaje de tiempo que el procesador dedica a

la ejecución de procesos de usuario, como por ejemplo SQL Server. Sistema: Longitud de la cola del procesador: Número de subprocesos en espera del

tiempo del procesador. Se produce un punto de congestión en el procesador cuando los subprocesos de un proceso requieren más ciclos de procesador que los disponibles. Si bastantes procesos intentan utilizar el tiempo de procesador, puede que sea necesario instalar un procesador más rápido. Si dispone de una sistema con múltiples procesadores, puede agregar un procesador.

Nota: Los diversos controladores de disco emplean distintos intervalos de tiempo de proceso del núcleo. Los controladores eficaces utilizan menos tiempo privilegiado y dejan más tiempo de proceso disponible para aplicaciones del usuario, y aumentan así el rendimiento global. Cuando examine el uso de los procesadores, tenga en cuenta el tipo de trabajo que realiza la instancia de SQL Server. Si SQL Server realiza muchos cálculos, como consultas relativas a agregados o consultas enlazadas a memoria que no requieren E/S del disco, puede utilizarse el 100% del tiempo del procesador. Si esto afecta negativamente al rendimiento de otras aplicaciones, pruebe a variar la carga de trabajo. Por ejemplo, dedique el equipo a ejecutar la instancia de SQL Server. Los valores de uso en torno al 100%, que indican que se están procesando muchas peticiones de clientes, pueden mostrar que los procesos están en cola, en espera del tiempo del procesador y están causando un punto de congestión. Para solucionar este problema, agregue procesadores de mayor velocidad. Monitorear el Uso de la Memoria Monitoree una instancia de SQL Server periódicamente para confirmar que la utilización de la memoria se encuentra dentro de los intervalos normales. Para Monitorear las condiciones de memoria insuficiente, utilice los contadores de objetos siguientes:

Memoria: Bytes disponibles Memoria: Páginas/seg

El contador Bytes disponibles indica en bytes la memoria disponible actualmente para procesos. El contador Páginas/seg indica el número de páginas que se han recuperado del

disco debido a errores de página no recuperables o que se han escrito en disco para liberar espacio en el espacio de trabajo debido a errores de página. Un valor bajo en el contador Bytes disponibles puede indicar una escasez general de

memoria en el equipo o que un programa no está liberando memoria. Un valor alto en el contador Páginas/seg puede indicar una paginación excesiva. Supervise el contador Memoria: Errores de página/s. para asegurarse de que la actividad del disco no está causada por la

paginación. Una tasa baja de paginación (y por tanto, de errores de página) es normal, incluso si el equipo tiene mucha memoria disponible. El Administrador de memoria virtual (VMM) de Microsoft Windows sustrae páginas de SQL Server y otros procesos a medida que recorta los tamaños del espacio de trabajo para estos procesos, lo que suele provocar errores de página. Para

- 107 -

determinar si SQL Server u otro proceso, está causando una paginación excesiva, supervise el contador Proceso: Errores de página/s. de la instancia del proceso de SQL Server.

Aislar la Memoria que utiliza SQL Server De forma predeterminada, SQL Server cambia dinámicamente sus necesidades de memoria según los recursos del sistema disponibles. Si SQL Server necesita más memoria, consulta el sistema operativo para determinar si hay memoria física disponible y la utiliza. Si SQL Server no necesita la memoria que tiene asignada actualmente, la libera para el sistema operativo. Sin embargo, el uso dinámico de la memoria puede anularse mediante las opciones de configuración de servidor min server memory y max server memory

Para Monitorear la cantidad de memoria que utiliza SQL Server, examine los siguientes contadores de rendimiento:

Proceso: Espacio de trabajo SQL Server: Buffer Manager: Frecuencia de aciertos de caché del búfer SQL Server: Buffer Manager: Total de páginas SQL Server: Memory Manager: Memoria total del servidor (KB)

El contador Espacio de trabajo muestra la cantidad de memoria que utiliza un proceso. Si este

número es constantemente inferior a la cantidad de memoria establecida en las opciones del servidor min server memory y max server memory, SQL Server está configurado para utilizar más memoria de la que necesita. El contador Frecuencia de aciertos de caché del búfer es específico de la aplicación. Sin

embargo, es preferible un porcentaje del 90% o superior. Agregue más memoria hasta que el valor sea superior al 90%, lo que indica que se ha atendido más del 90% de todas las peticiones de información de la caché de datos. Si el valor del contador Memoria total del servidor (KB) es constantemente alto en

comparación con la cantidad de memoria física del equipo, puede que indique que se necesita más memoria.

- 108 -

3- Analizador de SQL Server (SQL Server Profiler) Introducción El Analizador de SQL Server de Microsoft es una interfaz gráfica de usuario de la Traza de SQL que se utiliza para supervisar una instancia del Motor de base de datos de SQL Server o de Analysis Services. Puede capturar y guardar datos acerca de cada evento en un archivo o en una tabla para analizarlos posteriormente. Por ejemplo, puede supervisar un entorno de producción para ver qué procedimientos almacenados afectan negativamente al rendimiento al ejecutarse demasiado lentamente. Para ejecutar Analizador de SQL Server, en el menú Inicio, elija Todos los programas,

Microsoft SQL Server 2005, Herramientas de rendimiento y, a continuación, haga clic en Analizador de SQL Server.

Terminología del Analizador de SQL Server Para utilizar el Analizador de SQL Server, debe comprender la terminología que describe cómo funciona la herramienta.

Evento: Un evento es una acción generada dentro de una instancia del Motor de base

de datos de SQL Server. Por ejemplo: o Conexiones, errores y desconexiones de inicio de sesión. o Instrucciones SELECT, INSERT, UPDATE y DELETE de Transact-SQL. o Estado de lotes de RPC (llamada a procedimiento remoto). o Inicio o finalización de procedimientos almacenados. o Inicio o finalización de instrucciones incluidas en procedimientos almacenados. o Inicio o finalización de lotes SQL. o Errores escritos en el registro de errores de SQL Server. o Bloqueos adquiridos o liberados en objetos de base de datos. o Cursores abiertos. o Comprobaciones de permisos de seguridad.

- 109 -

Todos los datos generados por un evento se muestran en la traza en una sola fila. Esta fila está intersectada por columnas de datos que describen el evento de forma detallada.

Clase de evento: Una clase de evento es un tipo de evento del cual se puede realizar un seguimiento. La clase de evento contiene todos los datos que puede comunicar un evento. Por ejemplo: o SQL:BatchCompleted o Audit Login o Audit Logout o Lock:Acquired o Lock:Released

Categoría de eventos: Una categoría de eventos define cómo se agrupan los eventos

en el Analizador de SQL Server. Por ejemplo, todas las clases de eventos de bloqueo se agrupan dentro de la categoría de eventos Bloqueos. Sin embargo, las categorías

de eventos sólo existen en el Analizador de SQL Server. Este término no refleja cómo se agrupan los eventos del motor.

Columna de datos: Una columna de datos es un atributo de una clase de evento

capturada en la traza. Como la clase de evento determina el tipo de datos que se pueden recopilar, no se aplicarán todas las columnas de datos a todas las clases de evento. Por ejemplo, en una traza que capture la clase de evento Lock:Acquired, la columna de datos BinaryData contiene el valor del Id. o la fila de la página bloqueada, pero la columna de datos Integer Data no contiene ningún valor porque no es aplicable

a la clase de evento que se captura. Plantilla: Una plantilla define la configuración predeterminada de una traza. En

concreto, incluye las clases de evento que desea supervisar con el Analizador de SQL Server. Por ejemplo, puede crear una plantilla que especifique los eventos, las columnas de datos y los filtros que desea utilizar. Las plantillas no se ejecutan, sino que se guardan como archivos con la extensión .tdf. Una vez guardada, una plantilla

controla los datos de la traza que se capturan cuando se inicia una traza basada en la plantilla en cuestión.

Traza: Una traza captura datos basándose en clases de evento, columnas de datos y

filtros seleccionados. Por ejemplo, puede crear una traza para supervisar errores de excepción. Para ello, seleccione la clase de evento Exception y las columnas de datos

Error, State y Severity. Deben recopilarse los datos de estas tres columnas para que

los resultados de la traza proporcionen datos con significado. Una vez hecho esto, puede ejecutar una traza configurada de esta forma y recopilar datos de cualquier evento Exception que se produzca en el servidor. Los datos de traza se pueden

guardar o utilizar inmediatamente para el análisis. Las trazas se pueden volver a reproducir posteriormente, aunque ciertos eventos, como los eventos Exception,

nunca se vuelven a reproducir. También puede guardar la traza como plantilla para crear trazas parecidas en el futuro. SQL Server ofrece dos formas de incluir en una traza una instancia de SQL Server: puede hacerlo con el Analizador de SQL Server o con procedimientos almacenados del sistema.

Filtro: Al crear una traza o una plantilla, puede definir criterios para filtrar los datos

recopilados por el evento. Para que las trazas no sean demasiado grandes, puede filtrarlas de forma que sólo se recopile un subconjunto de los datos del evento. Por ejemplo, puede limitar los nombres de usuario de Microsoft Windows de la traza a usuarios específicos, con lo que reducirá los datos de salida. Si no se establece un filtro, se devolverán todos los eventos de las clases de eventos seleccionadas en el resultado de la traza.

Usar el Analizador de SQL Server

- 110 -

El Analizador de SQL Server muestra el modo en que SQL Server resuelve las consultas internamente. Esto permite a los administradores ver exactamente las instrucciones Transact-SQL o las Expresiones multidimensionales que se envían al servidor y como el servidor tiene acceso a la base de datos o al cubo para devolver los conjuntos de resultados. Mediante el Analizador de SQL Server puede hacer lo siguiente:

Crear una traza que se base en una plantilla que se puede reutilizar. Observar el resultado de la traza a medida que se ejecuta la traza Almacenar el resultado de una traza en una tabla Iniciar, detener, pausar y modificar el resultado de la traza según sea necesario Reproducir el resultado de la traza

Utilice el Analizador de SQL Server para supervisar únicamente los eventos en los que está interesado. Si las trazas son demasiado grandes, puede filtrarlas a partir de la información que desea, de forma que sólo se recopile un subconjunto de los datos del evento. Si se supervisan demasiados eventos, aumentará la sobrecarga del servidor y el proceso de supervisión, y podría hacer que el archivo o la tabla de traza crezcan demasiado, especialmente cuando el proceso de supervisión se realiza durante un período prolongado de tiempo. Plantillas del Analizador de SQL Server Puede utilizar el Analizador de SQL Server para crear plantillas que definan las clases de evento y columnas de datos que desea incluir en las trazas. Después de definir y guardar la plantilla, ejecute una traza que registre los datos de cada clase de evento que ha seleccionado. Una sola plantilla puede utilizarse en varias trazas puesto que la plantilla no se ejecuta como tal. El Analizador de SQL Server incluye plantillas de traza predefinidas para que pueda configurar fácilmente las clases de evento que seguramente necesitará para trazas concretas. La plantilla Standard, por ejemplo, le ayuda a crear una traza genérica para registrar inicios y cierres de

sesión, lotes finalizados e información de conexión. Esta plantilla permite ejecutar trazas sin modificarlas o como punto de inicio para plantillas adicionales con configuraciones de evento distintas. Nota: Además de las trazas de las plantillas predefinidas, el Analizador de SQL Server también permite crearlas a partir de una plantilla en blanco que no contenga ninguna clase de evento de manera predeterminada. Puede resultar útil utilizar la plantilla de traza en blanco cuando una traza planeada no se parece a la configuración de ninguna de las plantillas predefinidas. El Analizador de SQL Server permite realizar un seguimiento de diversos tipos de servidor. Sin embargo, las clases de evento que pueden incluirse no son las mismas para cada tipo de servidor. Por lo tanto, el Analizador de SQL Server mantiene plantillas distintas para los diferentes tipos de servidor y pone a disposición del usuario la plantilla específica correspondiente al tipo de servidor seleccionado. Plantillas Predefinidas Además de la plantilla Standard (predeterminada), el Analizador de SQL Server incluye varias

plantillas predefinidas para supervisar determinados tipos de evento. En la siguiente tabla figura una lista de las plantillas predefinidas, su finalidad y las clases de eventos sobre las que capturan información.

Nombre de plantilla

Finalidad de la plantilla Clases de evento

SP_Counts Captura el comportamiento de la ejecución de procedimientos SP:Starting

- 111 -

almacenados a lo largo del tiempo.

Standard Punto de inicio genérico para crear una traza. Captura todos los procedimientos almacenados y lotes de Transact-SQL que se ejecutan. Utilice esta plantilla para supervisar la actividad general del servidor de base de datos.

Audit Login Audit Logout ExistingConnection RPC:Completed SQL:BatchCompleted SQL:BatchStarting

TSQL Captura todas las instrucciones Transact-SQL que los clientes envían a SQL Server y el momento en que se han emitido. Utilice esta plantilla para depurar las aplicaciones cliente.

Audit Login Audit Logout ExistingConnection RPC:Starting SQL:BatchStarting

TSQL_Duration Captura todas las instrucciones Transact-SQL que los clientes envían a SQL Server, el tiempo de ejecución (en milisegundos), y las agrupa por duración. Utilice esta plantilla para identificar consultas de ejecución lenta.

RPC:Completed SQL:BatchCompleted

TSQL_Grouped Captura todas las instrucciones Transact-SQL enviadas a SQL Server y el momento en que se han emitido. Agrupa la información por el usuario o cliente que ha enviado la instrucción. Utilice esta plantilla para investigar consultas de un cliente o usuario determinado.

Audit Login Audit Logout ExistingConnection RPC:Starting SQL:BatchStarting

TSQL_Replay Captura información detallada acerca de las instrucciones Transact-SQL necesaria para cuando se reproduzca la traza. Utilice esta plantilla para ejecutar optimizaciones iterativas tales como pruebas comparativas.

CursorClose CursorExecute CursorOpen CursorPrepare CursorUnprepare Audit Login Audit Logout Existing Connection RPC Output Parameter RPC:Completed RPC:Starting Exec Prepared SQL Prepare SQL SQL:BatchCompleted SQL:BatchStarting

TSQL_SPs Captura información detallada acerca de todos los procedimientos almacenados en ejecución. Utilice esta plantilla para analizar los pasos de componente de los procedimientos almacenados. Agregue el evento SP:Recompile si sospecha que se están volviendo a compilar los procedimientos.

Audit Login Audit Logout ExistingConnection RPC:Starting SP:Completed SP:Starting SP:StmtStarting SQL:BatchStarting

Tuning Captura información acerca de los procedimientos almacenados y la ejecución de lotes de Transact-SQL. Utilice esta plantilla para crear un archivo de salida de la traza que el Asistente para la optimización de motor de base de datos pueda utilizar como carga de trabajo para optimizar las bases de datos.

RPC:Completed SP:StmtCompleted SQL:BatchCompleted

Plantilla Predeterminada El Analizador de SQL Server designa de forma automática la plantilla Standard como plantilla

predeterminada para aplicar a cualquier traza nueva. No obstante, puede cambiar la plantilla predeterminada por cualquier otra predefinida o definida por el usuario. Para cambiar la plantilla predeterminada, active la casilla de verificación Usar como plantilla predeterminada para

- 112 -

tipo de servidor seleccionado cuando cree o edite una plantilla desde la pestaña General del cuadro de diálogo Propiedades de la plantilla de traza. Para obtener acceso al cuadro de diálogo Propiedades de la plantilla de traza, en el menú

Archivo del Analizador de SQL Server, seleccione Plantillas y haga clic en Nueva plantilla o Editar plantilla.

Guardar Trazas y Plantillas de Traza Es importante distinguir entre guardar archivos de traza y guardar plantillas de traza. Guardar un archivo de traza implica guardar los datos de eventos capturados en un lugar especificado. Guardar una plantilla de traza implica guardar la definición de la traza, como las columnas de datos, las clases de eventos o los filtros especificados. Guardar Trazas Guarde los datos de los eventos capturados en un archivo o una tabla de SQL Server cuando necesite analizar o reproducir los datos capturados más adelante. Utilice un archivo de traza para lo siguiente:

Utilice un archivo de traza o una tabla de traza para crear una carga de trabajo a fin de utilizarla como entrada para el Asistente, para la Optimización del Motor de Base de Datos.

Utilice un archivo de traza para capturar eventos y enviar el archivo de traza a un proveedor de asistencia técnica para su análisis.

Utilice las herramientas de procesamiento de consultas de SQL Server para tener acceso a los datos o verlos en el Analizador de SQL Server. Sólo pueden tener acceso directo a la tabla de traza los miembros de la función fija de servidor sysadmin o el

creador de la tabla. Nota: La captura de datos de traza en una tabla resulta una operación más lenta que la captura de datos de traza en un archivo. Una alternativa es capturar los datos de traza en un archivo, abrir el archivo de traza y, después, guardar la traza como una tabla de traza. Cuando utilice un archivo de traza, el Analizador de SQL Server guardará los datos de eventos capturados (no las definiciones de traza) en un archivo de traza (*.trc) del Analizador de SQL Server. La extensión se agrega automáticamente al final del archivo al guardarlo, independientemente de, si se ha especificado otra extensión. Por ejemplo, si especifica un archivo de traza llamado Traza.dat, el nombre del archivo creado será Traza.dat.trc.

Importar y Exportar Plantillas El Analizador de SQL Server permite importar y exportar plantillas de un servidor a otro. Al exportar una plantilla se mueve una copia de una plantilla existente al directorio especificado. Al importar una plantilla se realiza una copia de una plantilla especificada. Cuando éstas plantillas se ven en el Analizador de SQL Server, se pueden distinguir de las plantillas del sistema por el término "(usuario)" que sigue al nombre de la plantilla. Las plantillas del sistema

predefinidas no se pueden sobrescribir ni modificar directamente. Analizar el Rendimiento con Plantillas Si supervisa SQL Server con frecuencia, utilice plantillas para analizar el rendimiento. Las plantillas capturan los mismos datos de eventos cada vez y utilizan la misma definición de traza para supervisar los mismos eventos. No tendrá que definir las clases de eventos y las columnas de datos cada vez que cree una traza. Además, se puede proporcionar una plantilla a otro usuario para supervisar eventos específicos de SQL Server. Por ejemplo, un proveedor de asistencia técnica puede proporcionar una plantilla a un cliente. El cliente puede utilizar la

- 113 -

plantilla para capturar los datos de eventos necesarios, que posteriormente enviará al proveedor de asistencia técnica para que los analice.

- 114 -

4- Desencadenadores DLL (DLL Triggers) Definición Los desencadenadores DDL, al igual que los desencadenadores habituales, activan procedimientos almacenados como respuesta a un evento. Sin embargo, a diferencia de los desencadenadores DML, no se activan como respuesta a las instrucciones UPDATE, INSERT o DELETE de una tabla o vista. En cambio, sí se activan en respuesta a diversos eventos del lenguaje de definición de datos (DDL). Estos eventos corresponden principalmente a instrucciones Transact-SQL que comienzan por las palabras clave CREATE, ALTER y DROP. Determinados procedimientos almacenados del sistema que realizan operaciones de estilo DDL también pueden activar desencadenadores DDL. Los desencadenadores DDL pueden utilizarse para tareas administrativas como auditar y regular las operaciones de base de datos. Utilice los desencadenadores DDL cuando:

Desee evitar determinados cambios en el esquema de base de datos. Desee que ocurra algún evento en la base de datos como respuesta a un cambio

realizado en el esquema de base de datos. Desee registrar cambios o eventos del esquema de base de datos.

Los desencadenadores DDL sólo se activan cuando se ejecutan las instrucciones DDL que los desencadenan. Los desencadenadores DDL no se pueden utilizar como desencadenadores INSTEAD OF. En el siguiente ejemplo se muestra el uso de un desencadenador DDL para evitar que se modifique o quite una tabla de una base de datos: CREATE TRIGGER safety ON DATABASE FOR DROP_TABLE, ALTER_TABLE AS PRINT „Debe desactivar los desencadenadores “de seguridad” antes de modificar o eliminar bases de datos‟ ROLLBACK ; Los desencadenadores DDL pueden activarse en respuesta a un evento de Transact-SQL procesado en la base de datos actual o en el servidor actual. El ámbito del desencadenador depende del evento. Para ver un ejemplo de desencadenadores DDL que está disponible en la base de datos de ejemplo AdventureWorks , en el Explorador de objetos de SQL Server Management Studio, abra la carpeta Database Triggers, que se encuentra en la carpeta Programmability de la base de datos AdventureWorks. Haga clic con el botón secundario en ddlDatabaseTriggerLog y seleccione Incluir desencadenador de base de datos como. De forma predeterminada, el desencadenador DDL ddlDatabaseTriggerLog está deshabilitado.

Usar Eventos de DDL con Desencadenadores DDL En las siguientes tablas se enumeran los eventos de DDL que se pueden utilizar para activar un desencadenador DDL. Tenga en cuenta que cada evento corresponde a una instrucción Transact-SQL, cuya sintaxis se ha modificado a fin de que incluya caracteres de subrayado ('_') entre las palabras clave. Determinados procedimientos almacenados del sistema que realizan operaciones de estilo DDL también pueden activar desencadenadores DDL. Pruebe los desencadenadores DDL para

- 115 -

determinar su respuesta a los procedimientos almacenados del sistema que se ejecutan. Por ejemplo, la instrucción CREATE TYPE y el procedimiento almacenado sp_addtype activarán un desencadenador DDL creado en un evento CREATE_TYPE. Sin embargo, el procedimiento almacenado sp_rename no activa ningún desencadenador DDL. Para utilizar instrucciones de DDL en el ámbito de la base de datos :

CREATE_APPLICATION_ROLE (se aplica a la instrucción CREATE APPLICATION ROLE y sp_addapprole; si se crea un esquema, este evento desencadena también un evento CREATE_SCHEMA).

ALTER_APPLICATION_ROLE (se aplica a la instrucción ALTER APPLICATION ROLE y sp_approlepassword).

DROP_APPLICATION_ROLE (se aplica a la instrucción DROP APPLICATION ROLE y sp_dropapprole).

CREATE_ASSEMBLY ALTER_ASSEMBLY DROP_ASSEMBLY

ALTER_AUTHORIZATION_DATABASE (se aplica a la instrucción ALTER AUTHORIZATION cuando se especifica ON DATABASE, y sp_changedbowner).

CREATE_CERTIFICATE ALTER_CERTIFICATE DROP_CERTIFICATE

CREATE_CONTRACT DROP_CONTRACT

GRANT_DATABASE DENY_DATABASE REVOKE_DATABASE

CREATE_EVENT_NOTIFICATION DROP_EVENT_NOTIFICATION

CREATE_FUNCTION ALTER_FUNCTION DROP_FUNCTION

CREATE_INDEX ALTER_INDEX DROP_INDEX

CREATE_MESSAGE_TYPE ALTER_MESSAGE_TYPE DROP_MESSAGE_TYPE

CREATE_PARTITION_FUNCTION ALTER_PARTITION_FUNCTION DROP_PARTITION_FUNCTION

CREATE_PARTITION_SCHEME ALTER_PARTITION_SCHEME DROP_PARTITION_SCHEME

CREATE_PROCEDURE ALTER_PROCEDURE DROP_PROCEDURE

CREATE_QUEUE ALTER_QUEUE DROP_QUEUE

CREATE_REMOTE_SERVICE_BINDING

ALTER_REMOTE_SERVICE_BINDING DROP_REMOTE_SERVICE_BINDING

CREATE_ROLE (se aplica a la instrucción CREATE ROLE, sp_addrole y sp_addgroup).

ALTER_ROLE DROP_ROLE (se aplica a la instrucción DROP ROLE, sp_droprole y sp_dropgroup).

CREATE_ROUTE ALTER_ROUTE DROP_ROUTE

CREATE_SCHEMA (se aplica a la instrucción CREATE SCHEMA, sp_addrole, sp_adduser, sp_addgroup y sp_grantdbaccess).

ALTER_SCHEMA (se aplica a la instrucción ALTER SCHEMA y sp_changeobjectowner).

DROP_SCHEMA

CREATE_SERVICE ALTER_SERVICE DROP_SERVICE

CREATE_STATISTICS DROP_STATISTICS UPDATE_STATISTICS

CREATE_SYNONYM DROP_SYNONYM

CREATE_TABLE ALTER_TABLE DROP_TABLE

- 116 -

CREATE_TRIGGER ALTER_TRIGGER DROP_TRIGGER

CREATE_TYPE (se aplica a la instrucción CREATE TYPE y sp_addtype).

DROP_TYPE (se aplica a la instrucción DROP TYPE y sp_droptype).

CREATE_USER (se aplica a la instrucción CREATE USER, sp_adduser y sp_grantdbaccess).

ALTER_USER DROP_USER (se aplica a la instrucción DROP USER, sp_dropuser y sp_revokedbaccess).

CREATE_VIEW ALTER_VIEW DROP_VIEW

CREATE_XML_SCHEMA_COLLECTION

ALTER_XML_SCHEMA_COLLECTION DROP_XML_SCHEMA_COLLECTION

Utilizar instrucciones de DDL en el ámbito del servidor

ALTER_AUTHORIZATION_SERVER

CREATE_DATABASE ALTER_DATABASE DROP_DATABASE

CREATE_ENDPOINT ALTER_ENDPOINT DROP_ENDPOINT

CREATE_LOGIN (se aplica a la instrucción CREATE LOGIN, sp_addlogin, sp_grantlogin, xp_grantlogin y sp_denylogin cuando se utiliza en un inicio de sesión inexistente que debe crearse de forma implícita).

ALTER_LOGIN (se aplica a la instrucción ALTER LOGIN, sp_defaultdb, sp_defaultlanguage, sp_password y sp_change_users_login cuando se especifica Auto_Fix).

DROP_LOGIN (se aplica a la instrucción DROP LOGIN, sp_droplogin, sp_revokelogin y xp_revokelogin).

GRANT_SERVER DENY_SERVER REVOKE_SERVER

Usar la Función EVENTDATA La información acerca de un evento que activa un desencadenador DDL se captura mediante la función EVENTDATA. Esta función devuelve un valor xml. El esquema XML incluye

información acerca de lo siguiente: La hora del evento. El Id. de proceso del sistema (SPID) de la conexión en la cual se ha ejecutado el

desencadenador. El tipo de evento que ha activado el desencadenador.

En función del tipo de evento, el esquema incluirá información adicional, como la base de datos en la que se ha producido el evento, el objeto en el que se ha producido el evento y la instrucción Transact-SQL del evento. Por ejemplo, el siguiente desencadenador DDL se crea en la base de datos de ejemplo AdventureWorks : CREATE TRIGGER safety ON DATABASE FOR CREATE_TABLE AS PRINT ' Temas de CREATE TABLE' SELECT EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvar char(max)')

- 117 -

RAISERROR ('No pueden crearse nuevas tablas en esta base de datos', 16, 1) ROLLBACK; Se ejecutará la siguiente instrucción CREATE TABLE: CREATE TABLE NewTable (Column1 int); La instrucción EVENTDATA() del desencadenador DDL captura el texto de la instrucción CREATE TABLE que no se admite. Esto se realiza utilizando una instrucción XQuery en los datos xml generados por EVENTDATA y recuperando el elemento <CommandText>.

Advertencia: EVENTDATA captura los datos de los eventos CREATE_SCHEMA, así como el <schema_element> de la definición CREATE SCHEMA correspondiente, si existe. Además, EVENTDATA reconoce la definición <schema_element> como un evento aparte. Por lo tanto, un desencadenador DDL creado en un evento CREATE_SCHEMA y en un evento representado por el <schema_element> de la definición CREATE SCHEMA, puede devolver los mismos datos de evento dos veces, por ejemplo, datos TSQLCommand. Por ejemplo, considere un desencadenador DDL creado en los eventos CREATE_SCHEMA y CREATE_TABLE, y que se ejecute el siguiente lote: CREATE SCHEMA s CREATE TABLE t1 (col1 int) Si la aplicación recupera los datos TSQLCommand del evento CREATE_TABLE, tenga en cuenta que estos datos pueden aparecer dos veces: una vez cuando se produce el evento CREATE_SCHEMA y otra cuando se produce el evento CREATE_TABLE. Evite crear desencadenadores DDL en los eventos CREATE_SCHEMA y en los textos <schema_element> de cualquier definición CREATE SCHEMA correspondiente, o cree la lógica en su aplicación para que el mismo evento no se procese dos veces. Ejemplo: Puede utilizar la función EVENTDATA para crear un registro de eventos. En el siguiente ejemplo, una tabla se crea para almacenar la información del evento. A continuación, se crea un desencadenador DDL en la base de datos actual que llena la tabla con la siguiente información siempre que tiene lugar un evento DDL en la base de datos:

La hora del evento (mediante la función GETDATE).

El usuario de la base de datos contra cuya sesión se ha producido el evento (mediante la función CURRENT_USER).

El tipo de evento. La instrucción Transact-SQL que contenía el evento.

Una vez más, los dos últimos elementos se capturan mediante XQuery con los datos xml generados por EVENTDATA.

USE AdventureWorks; GO CREATE TABLE ddl_log (PostTime datetime, DB_User nvarchar(100), Event nvarchar(100), TSQL nvarchar(2000)); GO CREATE TRIGGER log ON DATABASE FOR DDL_DATABASE_LEVEL_EVENTS AS

- 118 -

DECLARE @data XML SET @data = EVENTDATA() INSERT ddl_log (PostTime, DB_User, Event, TSQL) VALUES (GETDATE(), CONVERT(nvarchar(100), CURRENT_USER), @data.value('(/EVENT_INSTANCE/EventType)[1]', 'nvarchar(100)'), @data.value('(/EVENT_INSTANCE/TSQLCommand)[1]', 'nvarchar(2000)') ) ; GO -- Probar el desencadenador CREATE TABLE TestTable (a int) DROP TABLE TestTable ; GO SELECT * FROM ddl_log ; GO

- 119 -

5- Notificaciones de Eventos Introducción Las notificaciones de eventos envían información acerca de los eventos a un servicio Service Broker. Se pueden programar notificaciones de eventos para muchos de los eventos

capturados por Traza de SQL, pero dichas notificaciones pueden utilizarse para realizar una acción en una instancia de SQL Server 2005 como respuesta a eventos, en lugar de utilizarse para crear trazas. Como las notificaciones de eventos se ejecutan asincrónicamente, no consumen los recursos definidos por la transacción inmediata. Conceptos Básicos de las Notificaciones de Eventos Las notificaciones de eventos se ejecutan como respuesta a una variedad de instrucciones del lenguaje de definición de datos (DDL) Transact-SQL y eventos de Traza de SQL enviando información acerca de esos eventos a un servicio de Service Broker.

Las notificaciones de eventos se pueden usar para realizar lo siguiente: Registrar y revisar cambios o actividades que se producen en la base de datos. Realizar una acción en respuesta a un evento de una forma asincrónica en lugar de

sincrónica.

Las notificaciones de eventos pueden ofrecer una alternativa de programación a los desencadenadores DDL y a la Traza SQL. Las notificaciones de eventos se ejecutan asincrónicamente, fuera del alcance de una transacción. Por consiguiente, a diferencia de los desencadenadores DDL, las notificaciones de eventos se pueden usar dentro de una aplicación de bases de datos para responder a eventos sin utilizar los recursos definidos por la transacción inmediata. A diferencia de la Traza de SQL, las notificaciones de eventos se pueden utilizar para realizar una acción en una instancia de SQL Server como respuesta a un evento de Traza de SQL. Cuando se crea una notificación de eventos, se abren una o más conversaciones de Service Broker entre una instancia de SQL Server y el servicio de destino que se especifica.

Normalmente, las conversaciones permanecen abiertas mientras existe la notificación de eventos como objeto de la instancia de servidores. En algunos casos de error, las conversaciones se pueden cerrar antes de que se quite la notificación de eventos. Esas conversaciones nunca se comparten entre notificaciones de eventos. Cada notificación de eventos tiene sus propias conversaciones exclusivas. Al finalizar una conversación explícitamente se impide que el servicio de destino reciba más mensajes y la conversación no se vuelve a abrir la próxima vez que se activa la notificación de eventos. La información de eventos se proporciona a Service Broker como una variable de tipo xml que

proporciona información acerca de cuándo se produce un evento, el objeto de la base de datos afectado, la instrucción de lote Transact-SQL implicada y otra información. Los datos de eventos pueden ser utilizados por aplicaciones que se ejecutan junto con SQL Server para realizar un seguimiento del progreso y tomar decisiones. Por ejemplo, la siguiente notificación de eventos envía un aviso a un servicio determinado cada vez que se emite una instrucción ALTER TABLE en la base de datos de ejemplo AdventureWorks : USE AdventureWorks GO CREATE EVENT NOTIFICATION NotifyALTER_T1 ON DATABASE FOR ALTER_TABLE TO SERVICE '//Adventure-Works.com/ArchiveService' , '8140a771-3c4b-4479-8ac0-81008ab17984';

- 120 -

Descripción de Notificaciones de Eventos frente a Desencadenadores En la siguiente tabla, se comparan y se establecen diferencias entre los desencadenadores y las notificaciones de eventos.

DESENCADENADORES NOTIFICACIONES DE EVENTOS

Los desencadenadores DML responden a eventos DML (de lenguaje de manipulación de datos). Los desencadenadores DDL responden a eventos DDL (de lenguaje de definición de datos).

Las notificaciones de eventos responden a eventos DDL y a un subconjunto de eventos de traza de SQL.

Los desencadenadores pueden ejecutar un código administrado de Transact-SQL o de Common Language Runtime (CLR).

Las notificaciones de eventos no ejecutan códigos. En cambio, envían mensajes xml a un servicio de Service Broker.

Los desencadenadores se procesan de manera sincrónica, dentro del ámbito de las transacciones que los accionan.

Las notificaciones de eventos se pueden procesar de manera asincrónica y no se ejecutan en el ámbito de las transacciones que las accionan.

El consumidor de un desencadenador está estrechamente unido al evento que acciona el desencadenador.

El consumidor de una notificación de eventos está desvinculado del evento que acciona la notificación.

Los desencadenadores se deben procesar en el servidor local.

Las notificaciones de eventos se pueden procesar en un servidor remoto.

Los desencadenadores se pueden revertir. Las notificaciones de eventos no se pueden revertir.

Los nombres de los desencadenadores DML pertenecen al ámbito del esquema. Los nombres de los desencadenadores DLL pertenecen al ámbito de la base de datos o del servidor.

Los nombres de las notificaciones de eventos pertenecen al ámbito del servidor o de la base de datos. Las notificaciones de eventos de un evento QUEUE_ACTIVATION pertenecen al ámbito de una cola específica.

Los desencadenadores DML pertenecen al mismo propietario que el de las tablas a las que fueron aplicados.

El propietario de una notificación de eventos de una cola puede ser diferente del propietario del objeto al que fue aplicada.

Los desencadenadores admiten la cláusula EXECUTE AS.

Las notificaciones de eventos no admiten la cláusula EXECUTE AS.

La información del evento del desencadenador DDL se puede capturar con la función EVENTDATA, que devuelve un tipo de dato xml.

Las notificaciones de eventos envían información de evento xml a un servicio de Service Broker. La información utiliza el formato del mismo esquema que el de la función EVENTDATA.

Los metadatos acerca de los desencadenadores se encuentran en las vistas de catálogo sys.triggers y sys.server_triggers.

Los metadatos sobre las notificaciones de eventos se encuentran en las vistas de catálogo sys.event_notifications y sys.server_event_notifications.

Notificaciones de Eventos frente a Traza de SQL En la siguiente tabla se compara y contrasta el uso de notificaciones de eventos y de la Traza de SQL para supervisar eventos de servidor.

Traza de SQL Notificaciones de eventos

Traza SQL Trace no genera carga de rendimiento asociada con transacciones. El empaquetado de los datos es eficaz.

Existe una carga de rendimiento asociada con la creación de datos de eventos con formato XML y con el envío de notificaciones de eventos.

Traza SQL puede supervisar y realizar un seguimiento de cualquier clase de evento.

Los notificaciones de eventos pueden supervisar un subconjunto de clases de eventos de seguimiento y

- 121 -

también todos los eventos del lenguaje de definición de datos (DDL).

Puede personalizar qué columnas de datos se crean en un evento de seguimiento.

El esquema de datos de eventos con formato XML devuelto por las notificaciones de eventos es fijo.

Los eventos de traza generador por DDL siempre se genera, independientemente de si la instrucción DDL se revierte.

Las notificaciones de eventos no se activan si el evento de la instrucción DDL correspondiente se revierte.

La administración del flujo intermedio de los datos de eventos de traza implica llenar y administrar archivos de traza o tablas de traza.

La administración intermedia de los datos de notificación de eventos se consigue automáticamente mediante las colas de Service Broker.

Las trazas deben reiniciarse cada vez que se reinicia el servidor.

Después de registrarse, las notificaciones de eventos persisten en ciclos de servidor y participan en transacciones.

Tras reiniciarse, la activación de las trazas no se puede controlar. Las horas de detención y filtrado se pueden usar para especificar cuándo se inician. Se obtiene acceso a las trazas sondeando el archivo de trazas correspondiente.

Las notificaciones de eventos se pueden controlar utilizando la instrucción WAITFOR sobre la cola que recibe el mensaje generado por la notificación de eventos. Se puede obtener acceso a ellas sondeando la cola.

ALTER TRACE es el permiso mínimo necesario para crear una traza. También se requiere el permiso para crear un archivo de traza en el equipo correspondiente.

El permiso mínimo depende del tipo de notificación de eventos que se está creando. El permiso RECEIVE también es necesario en la cola correspondiente.

Las trazas se pueden recibir remotamente. Las notificaciones de eventos se pueden recibir remotamente.

Los eventos de traza se implementan utilizando procedimientos almacenados del sistema.

Las notificaciones de eventos se implementan utilizando una combinación de Motor de base de datos de SQL Server y Service Broker, y de instrucciones Transact-SQL.

Se puede obtener acceso a los datos de eventos de traza mediante programación consultando la tabla de traza correspondiente, analizando el archivo de traza o utilizando la clase TraceReader de los objetos de administración de SQL Server (SMO).

Se obtiene acceso a los datos de eventos mediante programación emitiendo XQuery sobre los datos de eventos con formato XML, o utilizando las clases SMO Event.

Ejemplos: a. Crear una notificación de eventos en el ámbito de un servidor En el ejemplo siguiente se crean los objetos necesarios para configurar un servicio de destino utilizando Service Broker. El servicio de destino hace referencia al contrato y tipo de mensaje

del servicio de inicio específicamente para notificaciones de eventos. Después, se crea una notificación de eventos en el servicio de destino que envía una notificación cada vez que tiene lugar un evento de traza Object_Created en la instancia de SQL Server. --Crea una cola para recibir mensajes. CREATE QUEUE NotifyQueue ; GO --Crea un servicio sobre la cola que referencia la notificación del evento CREATE SERVICE NotifyService ON QUEUE NotifyQueue ([http://schemas.microsoft.com/SQL/Notifications/PostEventNotification]); GO

- 122 -

--Crea la ruta en el servicio para definir la dirección a donde el Service Broker va a -- enviar el mensaje para el servicio CREATE ROUTE NotifyRoute WITH SERVICE_NAME = 'NotifyService', ADDRESS = 'LOCAL'; GO -- Crea la notificación del evento CREATE EVENT NOTIFICATION log_ddl1 ON SERVER FOR Object_Created TO SERVICE 'NotifyService', '8140a771-3c4b-4479-8ac0-81008ab17984' ; b. Crear una notificación de eventos en el ámbito de una base de datos El ejemplo siguiente crea una notificación de eventos en el mismo servicio de destino que en el ejemplo anterior. La notificación de eventos se activa después de un evento ALTER_TABLE en la base de datos de ejemplo AdventureWorks. CREATE EVENT NOTIFICATION Notify_ALTER_T1 ON DATABASE FOR ALTER_TABLE TO SERVICE 'NotifyService', '8140a771-3c4b-4479-8ac0-81008ab17984'; c. Obtener información sobre una notificación de eventos en el ámbito de un servidor El ejemplo siguiente realiza una consulta en la vista de catálogo sys.server_event_notifications respecto de metadatos sobre la notificación de eventos

log_ddl1 creada en el ámbito de un servidor. SELECT * FROM sys.server_event_notifications WHERE name = 'log_ddl1' d. Obtener información sobre una notificación de eventos en el ámbito de una base de datos El ejemplo siguiente realiza una consulta en la vista de catálogo sys.event_notifications

respecto de metadatos sobre la notificación de eventos Notify_ALTER_T1 creada en el ámbito de una base de datos. SELECT * FROM sys.event_notifications WHERE name = 'Notify_ALTER_T1'

- 123 -

Módulo 5

Automatizando Tareas Administrativas

- 124 -

1- Automatizar las tareas administrativas (Agente SQL Server) Microsoft SQL Server le permite automatizar las tareas administrativas. Para automatizar la administración, se definen las tareas administrativas previsibles y, después, se especifican las condiciones en las que se produce cada tarea. El uso de la administración automatizada para controlar las tareas y eventos habituales le permite disponer de tiempo para realizar otras funciones administrativas. Herramientas para Automatizar la Administración SQL Server incluye las siguientes herramientas para ayudarle a automatizar la administración:

SQL Server Management Studio: Puede utilizar SQL Server Management Studio para

automatizar la administración mediante la creación de trabajos, alertas, operadores y servidores proxy en el nodo Agente SQL Server del Explorador de objetos.

Asistente para planes de mantenimiento: El Asistente para planes de mantenimiento

es una utilidad que puede ayudarle a crear trabajos, alertas y operadores para automatizar una instancia de SQL Server. Le ayuda a configurar las tareas de mantenimiento principales para asegurarse de que la base de datos funciona bien, se realiza una copia de seguridad regular de la misma y no tiene incoherencias. El Asistente para planes de mantenimiento crea uno o varios trabajos del Agente SQL Server que realizan estas tareas en servidores locales o en servidores de destino en un entorno multiservidor. La ejecución puede tener lugar a intervalos programados o a petición.

Planes de Mantenimiento Para crear o administrar planes de mantenimiento, debe ser miembro de la función fija de servidor sysadmin. Tenga en cuenta que el Explorador de objetos sólo muestra planes de

mantenimiento si el usuario es miembro de dicha función fija. Si desea crear o administrar planes de mantenimiento en un entorno de varios servidores, necesitará una configuración adicional. Los planes de mantenimiento se pueden crear para realizar las tareas siguientes:

Reorganizar los datos de las páginas de datos y de índices mediante una nueva generación de los índices con un nuevo factor de relleno. Al volver a crear índices con un nuevo factor de relleno se asegura que las páginas de la base de datos contienen una cantidad de datos y espacio libre distribuidos por igual. También permite un crecimiento más rápido en el futuro.

Comprimir archivos de datos mediante la eliminación de las páginas de base de datos que estén vacías.

Actualizar las estadísticas de los índices para asegurarse de que el optimizador de consultas dispone de información actualizada acerca de la distribución de los valores de los datos en las tablas. Esto permite al optimizador de consultas elegir el método más adecuado para obtener acceso a los datos, ya que dispone de más información acerca de los datos almacenados en la base de datos. Aunque SQL Server actualiza

- 125 -

periódicamente las estadísticas de los índices de forma automática, esta opción puede obligar a que se actualicen inmediatamente.

Realizar comprobaciones de coherencia interna de los datos y de las páginas de datos de la base de datos para asegurarse de que no se han dañado debido a un problema de software o del sistema.

Realizar copias de seguridad de la base de datos y de los archivos de registro de transacciones. Las copias de seguridad de la base de datos y del registro pueden mantenerse durante un período especificado. Esto le permite crear un historial de copias de seguridad para utilizarlo si tiene que restaurar la base de datos a una fecha anterior a la de la última copia de seguridad de la base de datos. También puede realizar copias de seguridad diferenciales.

Ejecutar trabajos del Agente SQL Server. Esta tarea se puede utilizar para crear trabajos que realicen una serie de acciones y, también, para crear los planes de mantenimiento para ejecutar los trabajos.

Los resultados generados por las tareas de mantenimiento pueden escribirse en forma de informe en un archivo de texto, o bien escribirse en las tablas del plan de mantenimiento, sysmaintplan_log y sysmaintplan_logdetail, en msdb. Para ver los resultados en el visor del archivo de registros, haga clic con el botón secundario en Planes de mantenimiento y, a continuación, haga clic en Ver historial.

- 126 -

Los planes de mantenimiento sólo se pueden ejecutar en bases de datos con un nivel de compatibilidad de 80 o superior. El Asistente para planes de mantenimiento no muestra las bases de datos cuyo nivel de compatibilidad esté establecido en 70 o inferior. Iniciar el Asistente para Planes de Mantenimiento (SQL Server Management Studio) Para iniciar el Asistente para planes de mantenimiento:

Expanda el servidor. Expanda la carpeta Administración. Haga clic con el botón secundario en Planes de mantenimiento y seleccione

Asistente para planes de mantenimiento. Esto inicia el asistente y podrá seguir los

pasos y crear un plan personalizado para cumplir sus requisitos de mantenimiento.

- 127 -

Editar y crear Planes de Mantenimiento Manualmente Usted puede editar un plan existente con la herramienta Diseñador de Plan de Mantenimiento disponible dentro de SQL Server Management Studio. Esta herramienta provee una interfaz gráfica permitiéndole reordenar tareas, agregar nuevas tareas y definir un flujo de trabajo, indicando cómo manejar el éxito o la falla de tareas. Agente SQL Server (SQL Server Agent) El Agente SQL Server es un servicio de Microsoft Windows que ejecuta tareas administrativas programadas, denominadas trabajos (Jobs). El Agente SQL Server utiliza SQL Server para

almacenar información de los trabajos. Los trabajos contienen uno o más pasos. Cada paso contiene su propia tarea; por ejemplo, realizar una copia de seguridad de una base de datos. El Agente SQL Server puede ejecutar un trabajo según una programación, como respuesta a un evento específico o a petición. Por ejemplo, si desea realizar una copia de seguridad de todos los servidores de la organización todos los días entre semana después del horario de trabajo, puede automatizar esta tarea. Programe la copia de seguridad para que se ejecute después de las 22:00 h de lunes a viernes; si la copia de seguridad encuentra un problema, el Agente SQL Server puede registrar el evento y notificárselo. Nota: De forma predeterminada, el servicio Agente SQL Server está deshabilitado al instalar SQL Server 2005, a menos que el usuario elija de forma explícita iniciarlo automáticamente. Para automatizar la administración, siga estos pasos:

Establezca las tareas administrativas o eventos del servidor que se realizan con regularidad y si estas tareas o eventos se pueden administrar mediante programación. Una tarea es una buena candidata a la automatización si consta de una secuencia de pasos predecible y se produce en un momento específico o en respuesta a un evento concreto.

- 128 -

Defina un conjunto de trabajos, programaciones, alertas y operadores usando SQL Server Management Studio, secuencias de comandos Transact-SQL u objetos de administración de SQL Server (SMO).

Ejecute los trabajos del Agente SQL Server que haya definido. Nota: Para la instancia predeterminada de SQL Server, el servicio SQL Server se denomina SQLSERVERAGENT. Para las instancias con nombre, el servicio Agente SQL Server se denomina SQLAgent$nombreDeInstancia. Si ejecuta varias instancias de SQL Server, utilice la administración multiservidor para automatizar las tareas comunes a todas las instancias. Componentes El Agente SQL Server utiliza los siguientes componentes para definir las tareas que se realizarán, cuándo se llevarán a cabo y como se informará de si se han realizado correctamente o no. El Agente SQL Server también proporciona seguridad para la administración automática.

Trabajos: Un trabajo es una serie especificada de acciones que realiza el Agente SQL

Server. Utilice los trabajos para definir tareas administrativas de manera que se ejecuten una o más veces, y se pueda supervisar si se realizan o no correctamente. Un trabajo se puede ejecutar en un servidor local o en varios servidores remotos. Existen varias maneras de ejecutar trabajos: o Conforme a una o más programaciones. o Como respuesta a una o varias alertas. o Ejecutando el procedimiento almacenado sp_start_job.

Cada acción de un trabajo es un paso de trabajo. Por ejemplo, un paso de trabajo

puede consistir en la ejecución de una instrucción Transact-SQL, la ejecución de un paquete SSIS o la emisión de un comando en un servidor de Analysis Services. Los pasos de trabajo se administran como parte de un trabajo. Cada paso se ejecuta en un contexto de seguridad específico. En el caso de los pasos de trabajo que utilizan Transact-SQL, use la instrucción EXECUTE AS para establecer el contexto de seguridad para éstos. Para los demás tipos de pasos de trabajo, utilice una cuenta de proxy para establecer el contexto de seguridad.

Programaciones: Una programación especifica cuándo se ejecuta un trabajo. Se

puede ejecutar más de un trabajo en la misma programación y se pueden aplicar más de una programación al mismo trabajo. Una programación puede definir las condiciones siguientes del momento en el que se ejecuta un trabajo: o Cuando se inicia el Agente SQL Server. o Cuando el uso de la CPU del equipo se encuentre en un nivel que se haya definido

como inactivo. o Una vez, a una hora y una fecha específicas. o Periódicamente.

Alertas : Una alerta es una respuesta automática a un evento específico. Por ejemplo, un evento puede ser el inicio de un trabajo o que los recursos del sistema alcancen un umbral específico. Debe definir las condiciones en las que se genera una alerta. Una alerta puede responder a una de las condiciones siguientes: o Eventos de SQL Server o Condiciones de rendimiento de SQL Server o Eventos de Instrumental de administración de Microsoft Windows (WMI) en el

equipo en el que se ejecuta el Agente SQL Server Una alerta puede realizar las acciones siguientes:

o Notificar a uno o varios operadores o Ejecutar un trabajo

- 129 -

Operadores: Los operadores definen información de contacto para las personas

responsables del mantenimiento de una o varias instancias de SQL Server. En algunas compañías, las responsabilidades de operador están asignadas a una sola persona. En compañías con varios servidores, muchas personas comparten las responsabilidades de operador. Un operador no contiene información de seguridad y no define una entidad de seguridad.

SQL Server puede notificar a los operadores de alertas mediante una o varias de las opciones siguientes:

Correo electrónico Localizador (por correo electrónico) NET SEND

Nota: Para enviar notificaciones mediante NET SEND, se debe iniciar el servicio Windows Messenger en el equipo en el que reside el Agente SQL Server. Para enviar a los operadores notificaciones por correo electrónico o localizador, deberá configurar el Agente SQL Server para utilizar Correo electrónico de base de datos o SQL Mail. Puede definir un operador como alias de un grupo de personas. De esta manera, todos los miembros de este alias pueden recibir notificaciones al mismo tiempo.

- 130 -

2- Configurar el Agente SQL Server Puede especificar algunas opciones de configuración para el Agente SQL Server durante la instalación de SQL Server. El conjunto completo de opciones de configuración del Agente SQL Server sólo está disponible en SQL Server Management Studio, SMO (objetos de administración de SQL Server) o los procedimientos almacenados del Agente SQL Server. Nota: Haga clic en el Agente SQL Server en el Explorador de objetos de SQL Server Management Studio para administrar trabajos, operadores, alertas y el servicio del Agente SQL Server. No obstante, el Explorador de objetos sólo muestra el nodo del Agente SQL Server si tiene permiso para utilizarlo. El Agente SQL Server almacena la mayor parte de la información de configuración en las tablas que residen en la base de datos msdb. El Agente SQL Server utiliza los objetos de

credenciales de SQL Server para almacenar la información de autenticación para los servidores proxy. Establecer los Permisos Necesarios Para realizar sus funciones, el Agente SQL Server debe configurarse de modo que utilice las credenciales de una cuenta que sea miembro de la función fija de servidor sysadmin en SQL

Server. La cuenta debe tener los siguientes permisos de Windows: Ajustar las cuotas de memoria de un proceso Actuar como parte del sistema operativo Omitir la comprobación transversal Iniciar sesión como proceso por lotes Iniciar sesión como servicio Reemplazar un símbolo de nivel de proceso

Para comprobar que todos estos permisos necesarios de Windows están establecidos

Haga clic en Inicio, Panel de control, Herramientas administrativas y Directiva de seguridad local.

Expanda la carpeta Directivas locales y, a continuación, haga clic en la carpeta

Asignación de derechos de usuario.

Repita los pasos siguientes para cada permiso: o Haga clic con el botón secundario en un permiso (como Iniciar sesión como

servicio) y, a continuación, haga clic en Propiedades. o En el cuadro de diálogo de propiedades (por ejemplo Propiedades de Iniciar

sesión como servicio), compruebe que se muestre la cuenta bajo la que se

ejecuta el Agente SQL Server. o Si no aparece, haga clic en Agregar usuario o grupo, escriba la cuenta bajo la

que se ejecuta el Agente SQL Server y, a continuación, haga clic en Aceptar.

Normalmente, la cuenta seleccionada para el Agente SQL Server es una cuenta de dominio creada para ese propósito cuyos permisos de acceso están muy controlados. No es necesario utilizar una cuenta de dominio, pero si utiliza una cuenta en el equipo local, el Agente SQL Server no tendrá permiso para obtener acceso a los recursos de otros equipos. Es muy habitual que SQL Server necesite permisos en otros equipos, por ejemplo, cuando crea una copia de seguridad de una base de datos y almacena el archivo en otro equipo.

- 131 -

Correo del Agente SQL Server El Agente SQL Server incluye la posibilidad de enviar correo electrónico. Puede configurar el correo del Agente SQL Server para enviar mensajes de correo electrónico a operadores predefinidos cuando:

Se desencadene una alerta. Las alertas se pueden configurar para enviar una notificación por correo electrónico acerca de eventos específicos que se produzcan. Por ejemplo, es posible configurar alertas para que avisen a un operador acerca de un determinado evento de la base de datos o una situación del sistema operativo que precise una acción inmediata.

Se lleve a cabo o no se complete una tarea programada, como una copia de seguridad de la base de datos o un evento de réplica. Por ejemplo, puede usar el correo del Agente SQL Server para notificar a los operadores si se produce un error durante el procesamiento a fin de mes.

Es posible enviar mensajes de correo electrónico a una lista de destinatarios para informarles del estado de los trabajos programados, lo que les permitiría emprender una acción. Por ejemplo, puede configurar el correo del Agente SQL Server para enviar mensajes de correo electrónico cuando termine de hacerse una copia de seguridad. De forma predeterminada, el correo del Agente SQL Server está desactivado. Para configurarlo, utilice el panel Sistema de alerta del cuadro de diálogo Propiedades de Agente SQL Server. Tenga en cuenta que el correo del Agente SQL Server sólo es necesario para la notificación de alertas y la notificación automática cuando se completa un trabajo. Cada paso de un trabajo puede enviar un mensaje de correo electrónico, independientemente de si el correo del Agente SQL Server está activado. Por ejemplo, un paso de trabajo de Transact-SQL puede usar el Correo electrónico de base de datos para enviar el resultado de una consulta a la lista de destinatarios.

- 132 -

El correo del Agente SQL Server permite usar dos sistemas de correo electrónico. Al configurar el correo del Agente SQL Server, elija el sistema de correo que se usará:

Si elige el Correo electrónico de base de datos, el Agente SQL Server utilizará el

Correo electrónico de base de datos para enviar el correo electrónico. Si elige SQL Mail, el Agente SQL Server utilizará la interfaz de MAPI extendida para

enviar el correo electrónico.

Nota: SQL Mail se quitará en una versión futura de SQL Server. Por tanto, evite usar esta característica en nuevos trabajos de desarrollos y tenga previsto modificar las aplicaciones que actualmente la utilizan. Para enviar correo electrónico desde Microsoft SQL Server 2005, use el Correo electrónico de base de datos. Después de cambiar el sistema de correo electrónico, debe reiniciar el servicio del Agente SQL Server para que el cambio entre en vigor. Correo Electrónico de Base de Datos con el Agente SQL Server El Agente SQL Server puede utilizar Correo electrónico de base de datos para enviar mensajes de correo electrónico. Para habilitar y configurar cuentas y perfiles del Correo electrónico de base de datos, utilice el Asistente para configuración del Correo electrónico de base de datos. Si desea utilizar Correo electrónico de base de datos para enviar mensajes de correo electrónico desde el correo del Agente SQL Server, debe:

Habilitar Correo electrónico de base de datos. Crear una cuenta de Correo electrónico de base de datos para la cuenta de servicio del

Agente SQL Server que desea usar. Crear un perfil del Correo electrónico de base de datos para uso de la cuenta de

servicio del Agente SQL Server y agregar el usuario a la función DatabaseMailUserRole de la base de datos msdb.

Establecer el perfil como perfil predeterminado de la base de datos msdb.

Elegir Correo electrónico de base de datos como sistema de correo para el Agente SQL Server.

Reiniciar el Agente SQL Server. El Agente SQL Server captura la información del perfil especificado. Esto permite al Agente SQL Server enviar correo electrónico en los casos en los que la instancia de SQL Server no está disponible. Si la instancia de SQL Server no está disponible, el Agente SQL Server inicia el programa externo de Correo electrónico de base de datos directamente para notificar al operador de conmutación por error que la instancia no está disponible. El Agente SQL Server captura la información del perfil, por lo que el Agente SQL Server no utiliza inmediatamente la nueva información cuando cambia el perfil. Después de cambiar el sistema de correo electrónico, debe reiniciar el servicio del Agente SQL Server para que el cambio surta efecto. Algunas características de este tipo de correo son:

No se requiere Microsoft Outlook ni MAPI (Interfaz de programación de aplicaciones

de mensajería) extendida. El Correo electrónico de base de datos utiliza el protocolo estándar SMTP (Protocolo simple de transferencia de correo) para enviar correo

electrónico. Puede utilizar el Correo electrónico de base de datos sin necesidad de instalar un cliente con MAPI extendida en el equipo en el que se ejecuta SQL Server.

Aislamiento de procesos. Para minimizar el impacto en SQL Server, el componente

que entrega el correo electrónico se ejecuta fuera de SQL Server, en un proceso independiente. SQL Server continuará almacenando en cola los mensajes de correo electrónico incluso si el proceso externo se detiene o genera un error. Los mensajes en cola se enviarán cuando el proceso externo o el servidor SMTP se encuentren en línea.

- 133 -

Cuentas de conmutación por error. Los perfiles del Correo electrónico de base de

datos permiten especificar más de un servidor SMTP. Si un servidor SMTP no está disponible, se puede enviar el correo mediante otro.

Compatibilidad con clústeres. El Correo electrónico de base de datos es una aplicación para clústeres y es totalmente compatible con éstos.

Entrega en segundo plano. El Correo electrónico de base de datos permite realizar entregas en segundo plano o asincrónicas. Cuando se llama a sp_send_dbmail para

enviar un mensaje, el Correo electrónico de base de datos agrega una solicitud a una cola de Service Broker. El procedimiento almacenado se devuelve inmediatamente. El componente de correo electrónico externo recibe la solicitud y entrega el mensaje.

Varios perfiles. El Correo electrónico de base de datos permite crear varios perfiles en

una instancia de SQL Server. También se puede seleccionar el perfil del Correo electrónico de base de datos para enviar el mensaje.

Varias cuentas. Cada perfil puede incluir varias cuentas de conmutación por error. Se

pueden configurar varios perfiles con distintas cuentas para distribuir el correo electrónico entre varios servidores de correo.

Compatibilidad con 64 bits. El Correo electrónico de base de datos es totalmente

compatible con las versiones de 64 bits de SQL Server. Regulador del tamaño de los datos adjuntos. El Correo electrónico de base de datos

fuerza un límite configurable para el tamaño de los datos adjuntos. Puede cambiar este límite utilizando el procedimiento almacenado sysmail_configure_sp.

Extensiones de archivo prohibidas. El Correo electrónico de base de datos mantiene

una lista de extensiones de archivo prohibidas. Los usuarios no pueden adjuntar archivos con las extensiones de la lista.

Configuración integrada. El Correo electrónico de base de datos mantiene la información para las cuentas de correo electrónico del SQL Server Motor de base de datos de SQL Server. No es necesario administrar un perfil de correo en una aplicación cliente externa. El Asistente para configuración del Correo electrónico de base de datos proporciona una interfaz adecuada para configurar el Correo electrónico de base de datos. También se pueden crear y mantener configuraciones del Correo electrónico de base de datos mediante Transact-SQL.

Registro. El Correo electrónico de base de datos registra la actividad de correo

electrónico en SQL Server, en el registro de eventos de aplicación de Microsoft Windows y en la base de datos msdb.

Auditoría. El Correo electrónico de base de datos conserva copias de los mensajes y datos adjuntos enviados en la base de datos msdb. Puede auditar fácilmente la

utilización del Correo electrónico de base de datos y revisar los mensajes conservados. Compatibilidad con HTML. El Correo electrónico de base de datos permite enviar

mensajes de correo electrónico con el formato HTML. Nota: Para que el inicio se realice de manera satisfactoria, el Agente SQL Server debe poder

conectarse a SQL Server. Por tanto, el Agente SQL Server puede enviar notificaciones cuando no hay disponible una instancia de SQL Server en ejecución, pero no puede enviar notificaciones si no se inicia una instancia de SQL Server al iniciarse el equipo. Cómo usar SQL Mail SQL Mail utiliza componentes de cliente de MAPI extendida de una aplicación de correo electrónico externa (por ejemplo, Microsoft Outlook) para enviar y recibir correo electrónico.

Por lo tanto, para utilizar SQL Mail, debe instalar una aplicación de correo electrónico compatible con MAPI extendida en el equipo que ejecute SQL Server. SQL Server utiliza los componentes de MAPI extendida proporcionados por la aplicación de correo electrónico para comunicarse con el servidor de correo electrónico.

- 134 -

- 135 -

3- Trabajos y Operadores Trabajos Un trabajo es una serie específica de operaciones que el Agente SQL Server realiza secuencialmente. Un trabajo puede realizar una amplia variedad de actividades, incluidas secuencias de comandos Transact-SQL, aplicaciones de símbolo del sistema, secuencias de comandos de Microsoft ActiveX, paquetes de Integration Services, comandos y consultas de Analysis Services o tareas de réplica. Los trabajos pueden ejecutar tareas repetitivas o que se pueden programar, y pueden notificar automáticamente a los usuarios el estado del trabajo mediante alertas, lo cual simplifica en gran medida la administración de SQL Server. Para crear un trabajo, el usuario debe ser miembro de una de las funciones fijas de base de datos del Agente SQL Server o de la función fija de servidor sysadmin. Sólo pueden editar el trabajo el propietario de éste o los miembros de la función sysadmin.

Se puede escribir un trabajo para que se ejecute en la instancia local de SQL Server o en varias instancias de una empresa. Para ejecutar trabajos en varios servidores, debe configurar al menos un servidor principal, y uno o más servidores de destino. Organizar trabajos Las categorías de trabajo le ayudan a organizar los trabajos para poder filtrarlos y agruparlos fácilmente. Por ejemplo, puede organizar todos los trabajos de copia de seguridad de las bases de datos en la categoría Mantenimiento de bases de datos. También puede crear sus propias categorías. Las categorías multiservidor existen sólo en los servidores principales. Sólo hay una categoría de trabajo predeterminada disponible en un servidor principal: [Sin categoría (Multiservidor)]. Cuando se descarga un trabajo multiservidor, su categoría se cambia a Trabajos del servidor principal en el servidor de destino. Propiedad de trabajos Por razones de seguridad, sólo puede cambiar la definición del trabajo el propietario de éste o un miembro de la función sysadmin. Los miembros de la función sysadmin pueden asignar el

valor de propiedad de trabajo a otros usuarios, y pueden ejecutar cualquier trabajo, independientemente del propietario del trabajo. Crear un trabajo

En el Explorador de objetos, conéctese a una sesión del Motor de base de datos de

SQL Server y expándala. Expanda Agente SQL Server. Haga clic con el botón secundario en Trabajos y, a continuación, haga clic en Nuevo

trabajo. En la página General, en el cuadro Nombre, escriba un nombre para el trabajo. Desactive la casilla de verificación Habilitado si no desea que el trabajo se ejecute

inmediatamente después de su creación. Por ejemplo, deshabilite un trabajo si desea probarlo antes de programar su ejecución.

En el cuadro Descripción, escriba la descripción de la acción que realiza el trabajo. El

número máximo de caracteres es 512.

- 136 -

Para agregar pasos de trabajo, programas, alertas y notificaciones que puedan enviarse a los operadores, seleccione las diferentes solapas de esta opción. Crear pasos de trabajo Los pasos de trabajo son acciones que el trabajo realiza en una base de datos o en un servidor. Cada trabajo debe estar formado por un paso, como mínimo. Los pasos de trabajo pueden ser:

Programas ejecutables y comandos del sistema operativo. Instrucciones Transact-SQL, incluidos los procedimientos almacenados y los

procedimientos almacenados extendidos. Secuencias de comandos Microsoft ActiveX. Tareas de réplica. Tareas de Analysis Services. Paquetes de Integration Services.

Todos los pasos de trabajo se ejecutan en un contexto de seguridad determinado. Si en el paso de trabajo se especifica un proxy, se ejecuta en el contexto de seguridad de la credencial del

proxy. Si en el paso de trabajo no se especifica un proxy, se ejecuta en el contexto de la cuenta

- 137 -

de servicio del Agente SQL Server. Sólo los miembros de la función de servidor fija sysadmin

pueden crear trabajos en los que no se especifique un proxy de forma explícita. Puesto que los pasos de trabajo se ejecutan en el contexto de un usuario específico de Microsoft Windows, dicho usuario debe disponer de los permisos y la configuración necesarios para que se ejecute el paso de trabajo. Por ejemplo, si crea un trabajo que requiere una letra de unidad o una ruta de acceso UNC (Convención de nomenclatura universal), los pasos de trabajo se pueden ejecutar con la cuenta de usuario de Microsoft Windows durante la comprobación de las tareas. Sin embargo, el usuario de Windows para el paso de trabajo debe tener también los permisos y configuraciones de letra de unidad necesarios, o acceso a la unidad requerida. De lo contrario, se producirá un error en el paso de trabajo. Para evitar este problema, asegúrese de que el proxy para cada paso de trabajo dispone de los permisos necesarios para la tarea que realiza dicho paso. Registros de Pasos de Trabajo El Agente SQL Server puede escribir la salida de algunos pasos de trabajo en un archivo del sistema operativo o en la tabla sysjobstepslogs de la base de datos msdb. Los siguientes

tipos de pasos de trabajo pueden escribir la salida en los siguientes destinos: Programas ejecutables y comandos del sistema operativo. Instrucciones Transact-SQL. Tareas de Analysis Services.

Sólo los pasos de trabajo que ejecutan los usuarios que son miembros de la función de servidor fija sysadmin pueden escribir la salida en archivos del sistema operativo. Si los pasos

de trabajo son ejecutados por usuarios que son miembros de las funciones fijas de base de datos SQLAgentUserRole, SQLAgentReaderRole o SQLAgentOperatorRole de la base de datos msdb, la salida de dichos pasos sólo se puede escribir en la tabla sysjobstepslogs.

Los registros de pasos de trabajo se eliminan automáticamente al eliminar los trabajos o pasos de trabajo. Nota: El registro de pasos de trabajo de tareas de réplica y paquetes de Integration Services lo

controla el subsistema respectivo. No se puede utilizar el Agente SQL Server para configurar el registro de pasos de trabajo para estos tipos de pasos. Programas Ejecutables y Comandos del Sistema Operativo como Pasos de Trabajo Los programas ejecutables y comandos del sistema operativo se pueden utilizar como pasos de trabajo. Los archivos pueden tener las extensiones .bat, .cmd, .com o .exe.

Si utiliza un programa ejecutable o un comando del sistema operativo como paso de trabajo, debe especificar:

El código de salida del proceso que se devuelve si el comando se ha ejecutado correctamente.

El comando que se debe ejecutar. Para ejecutar un comando del sistema operativo, se trata simplemente del propio comando.

En un programa externo, es el nombre del programa y los argumentos para el programa, por ejemplo:

C:\Archivos de programa\Microsoft SQL Server\90\Tools\Binn\sqlcmd.exe -e -q "sp_who" Nota: Debe proporcionar la ruta de acceso completa del archivo ejecutable si éste no se

encuentra en un directorio especificado en la ruta de acceso del sistema o la ruta de acceso del usuario con el que se ejecuta el paso de trabajo.

- 138 -

Pasos de Trabajo Transact-SQL Al crear un paso de trabajo Transact-SQL, debe:

Identificar la base de datos en la que se ejecutará el trabajo. Escribir la instrucción Transact-SQL que se debe ejecutar. La instrucción puede llamar

a un procedimiento almacenado o un procedimiento almacenado extendido. Opcionalmente, puede abrir un archivo Transact-SQL existente que actúe como

comando para el paso de trabajo. Los pasos de trabajo Transact-SQL no utilizan cuentas de proxy del Agente SQL Server. En lugar de ello, el paso de trabajo se ejecuta como el propietario del paso de trabajo, o con la cuenta de servicio del Agente SQL Server si el propietario del paso de trabajo es miembro de la función de servidor fija sysadmin. Los miembros de la función fija de servidor sysadmin

también pueden especificar que los pasos de trabajo Transact-SQL se ejecuten en el contexto de otro usuario mediante el parámetro database_user_name del procedimiento almacenado

sp_add_jobstep.

Nota: Un único paso de trabajo Transact-SQL puede contener varios procesos por lotes. Los

pasos de trabajo Transact-SQL pueden contener comandos GO incrustados. Pasos de Trabajo de Secuencias de Comandos ActiveX Al crear un paso de trabajo de secuencias de comandos ActiveX, debe realizar las siguientes acciones:

Identificar el lenguaje de secuencias de comandos en el que se ha escrito el paso de trabajo

Escribir la secuencia de comandos ActiveX También puede abrir un archivo de secuencias de comandos ActiveX existente y utilizarlo como comando para el paso de trabajo. Opcionalmente, los comandos de las secuencias de comandos ActiveX se pueden compilar externamente (por ejemplo, mediante Microsoft Visual Basic) y, después, ejecutarse como programas ejecutables. Si el comando del paso de trabajo es una secuencia de comandos ActiveX, puede utilizar el objeto SQLActiveScriptHost para imprimir la salida en el registro de historial del paso de trabajo o para crear objetos COM. SQLActiveScriptHost es un objeto global que el sistema

host del Agente SQL Server introduce en el espacio de nombres de secuencias de comandos. El objeto tiene dos métodos (Print y CreateObject). Controlar varios Pasos del Trabajo Si el trabajo está formado por varios pasos, debe especificar el orden de ejecución de los pasos del trabajo. Esto se denomina control de flujo. En cualquier momento puede agregar nuevos pasos del trabajo y reorganizar el flujo de los pasos; los cambios se aplicarán la próxima vez que se ejecute el trabajo. Esta ilustración muestra el control de flujo de un trabajo de copia de seguridad de una base de datos.

- 139 -

El primer paso es Copia de seguridad de la base de datos. Si este paso genera un error, el Agente SQL Server informa del error al operador que se ha definido que reciba la notificación. Si el paso Copia de seguridad de la base de datos es correcto, el trabajo pasa al siguiente paso: "Normalizar" los datos del cliente. Si este paso genera un error, el Agente SQL Server avanza a Restaurar base de datos. Si "Normalizar" los datos del cliente es correcto, el trabajo avanza al siguiente paso: Actualizar estadísticas y, así sucesivamente, hasta que el paso final da como resultado un informe correcto o con errores. Se define una acción de control de flujo para la ejecución satisfactoria o con errores de cada paso del trabajo. Debe especificar una acción que se deberá realizar cuando un paso del trabajo se ejecute correctamente y la acción que se llevará a cabo cuando se ejecute con errores. También puede definir el número de reintentos y el intervalo entre ellos para los pasos del trabajo que no se han ejecutado correctamente. Los pasos del trabajo deben ser independientes. Es decir, un trabajo no puede pasar datos, valores booleanos o numéricos entre pasos del trabajo. Sin embargo, puede pasar valores de un paso del trabajo de Transact-SQL a otro si utiliza tablas permanentes o tablas temporales globales. También puede pasar valores de pasos del trabajo que ejecuten programas ejecutables de un paso del trabajo a otro mediante archivos. Por ejemplo, el programa ejecutado mediante un paso del trabajo escribe un archivo y el programa ejecutado por un paso del trabajo posterior lee el archivo. Programar la Ejecución de un Trabajo La programación de trabajos del Agente SQL Server consiste en definir las condiciones que provocan el inicio de la ejecución de los trabajos sin intervención del usuario. Puede programar que un trabajo se ejecute automáticamente creando una nueva programación para el trabajo, o adjuntando una programación existente al trabajo. Hay dos maneras de crear una programación:

Crear la programación mientras se está creando un trabajo. Crear la programación en el Explorador de objetos.

Una vez creada una programación, puede adjuntarla a varios trabajos, aun cuando la programación se haya creado para un trabajo concreto. También puede separar las programaciones de los trabajos.

- 140 -

Una programación puede basarse en tiempo o en un evento. Por ejemplo, puede programar un trabajo para que se ejecute en los momentos siguientes:

Cuando se inicia el Agente SQL Server. Cuando el uso de la CPU del equipo se encuentre en un nivel que se haya definido

como inactivo. Una vez, a una hora y una fecha específicas. Periódicamente.

Como alternativa a las programaciones de trabajo, también puede crear una alerta que responda a un evento ejecutando un trabajo.

Nota: Sólo se puede ejecutar una instancia del trabajo cada vez. Si intenta ejecutar un trabajo

manualmente mientras se está ejecutando en el momento programado, el Agente SQL Server rechazará la petición.

Para impedir que un trabajo programado se ejecute, debe realizar una de las siguientes acciones:

Deshabilitar la programación. Deshabilitar el trabajo. Separar la programación del trabajo. Detener el servicio del Agente SQL Server. Eliminar la programación.

Aunque no esté habilitada la programación, se puede ejecutar el trabajo en respuesta a una alerta o cuando un usuario lo ejecute manualmente. Si no está habilitada una programación de trabajo, no estará habilitada para ningún trabajo que la utilice. Las programaciones deshabilitadas se deben volver a habilitar de manera explícita. La modificación de una programación no la vuelve a habilitar automáticamente.

- 141 -

Operadores

El servicio Agente SQL Server admite la notificación de administradores a través de operadores. Los operadores son alias para personas o grupos que pueden recibir una notificación electrónica cuando los trabajos finalizan o se activa una alerta. Los atributos principales de un operador son:

Nombre del operador Información de contacto

Se recomienda definir operadores antes de definir alertas. Cada operador debe tener asignado un nombre. Los nombres de los operadores deben ser únicos en la instancia de SQL Server y no pueden tener más de 128 caracteres. Proporcionar Información de Contacto La información de contacto de un operador define cómo se va a notificar a dicho operador. Se puede notificar a los operadores mediante correo electrónico, localizador o el comando NET SEND:

Notificación mediante correo electrónico: La notificación por correo electrónico

envía un mensaje de correo electrónico al operador. Para la notificación por correo electrónico debe proporcionar una dirección de correo electrónico al operador.

Notificación mediante localizador: Este tipo de notificación se implementa mediante

el correo electrónico. Para la notificación por localizador debe proporcionar una

- 142 -

dirección de correo electrónico en la que el operador recibirá los mensajes del localizador. Para establecer la notificación mediante localizador, debe instalar en el servidor de correo un software que procese el correo entrante y lo convierta en mensajes de localizador. El software realizará diversas acciones, entre las que se incluyen: o Reenviar el correo a un servidor de correo remoto en el sitio del proveedor del

localizador. El proveedor del localizador debe ofrecer este servicio, aunque el software necesario generalmente está disponible como parte del sistema de correo local.

o Enrutar el correo electrónico mediante Internet a un servidor de correo electrónico en el sitio del proveedor del localizador. Es una variación del primer planteamiento.

o Procesar el mensaje de correo electrónico de entrada y llamar al número del localizador mediante un módem conectado.

Este software es propiedad de los proveedores de servicios de localización. El software funciona como un cliente de correo electrónico que procesa periódicamente su bandeja de entrada mediante la interpretación de toda o parte de la información de la dirección de correo electrónico como un número de localizador o mediante la correspondencia del nombre de correo electrónico con un número de localizador en una tabla de traducción.

Si todos los operadores comparten el mismo proveedor de localizador, puede utilizar SQL Server Management Studio para especificar el formato especial de correo electrónico necesario para el sistema de conversión del localizador a correo electrónico. El formato especial puede ser un prefijo o un sufijo y puede incluirse en las siguientes líneas del mensaje de correo electrónico: Asunto, Cc, Para. Nota: Si utiliza un sistema de localización alfanumérica de baja capacidad, puede

reducir el texto enviado si excluye el texto del error de la notificación del localizador. Un sistema de localización alfanumérica de baja capacidad es, por ejemplo, uno que esté limitado a 64 caracteres por página.

Notificación mediante NET SEND: Envía un mensaje al operador mediante el

comando NET SEND. Si utiliza este comando, especifique el destinatario (el equipo o el usuario) de un mensaje de red.

Nota: El comando net send utiliza Microsoft Windows Messenger. Para enviar alertas

correctamente, este servicio debe ejecutarse tanto en el equipo en el que SQL Server se está ejecutando como en el equipo que utiliza el operador. Requisitos para Notificar a un Operador

Debe configurar al menos uno de los elementos siguientes para poder notificar a un operador: Para enviar un mensaje de correo electrónico mediante la funcionalidad Correo

electrónico de base de datos, debe tener acceso a un servidor de correo electrónico que admita SMTP.

Para enviar un mensaje de correo electrónico mediante la funcionalidad SQL Mail (MAPI extendido), debe tener acceso a un servidor Microsoft Exchange e instalar el cliente Microsoft Outlook y Microsoft Exchange en el equipo en el que se ejecuta SQL Server.

Para notificar mediante un localizador, debe disponer de hardware o software de otros fabricantes para enviar mensajes de localizador a correo electrónico.

Para utilizar NET SEND, el operador debe haber iniciado sesión en el equipo especificado y el equipo especificado debe permitir la recepción de mensajes desde Windows Messenger.

Designar un Operador a Prueba de Errores

- 143 -

El operador a prueba de errores recibe la notificación de una alerta después de que no se haya recibido respuesta a ninguna de las notificaciones enviadas mediante localizador a los operadores designados. Por ejemplo, si ha definido tres operadores para las notificaciones mediante localizador y no se pueden enviar mensajes al localizador de ninguno de ellos, entonces se notificará al operador a prueba de errores. Se notifica al operador a prueba de errores cuando:

No se pueden enviar mensajes al localizador de ninguno de los operadores responsables de la alerta. Entre los motivos que impiden contactar con los operadores principales se incluyen el uso de direcciones de localizador incorrectas y los operadores fuera de servicio.

El Agente SQL Server no puede tener acceso a las tablas del sistema en la base de datos msdb. La tabla del sistema sysnotifications especifica las responsabilidades de

los operadores respecto a las alertas. El operador a prueba de errores es una característica de seguridad. Para eliminar el operador asignado al servicio a prueba de errores debe reasignar el servicio a otro operador o eliminar completamente la asignación a prueba de errores.

- 144 -

Supervisar la Actividad de Trabajo Para supervisar la actividad de los trabajos puede usar las siguientes herramientas

Sesiones del Agente SQL Server Monitor de Actividades de Trabajo

Sesiones del Agente SQL Server El Agente SQL Server crea una sesión cada vez que se inicia el servicio. Al crear una sesión, la tabla sysjobactivity de la base de datos msdb se rellena con todos los trabajos definidos existentes. Esta tabla mantiene la última actividad para los trabajos cuando se reinicia el Agente SQL Server. Cada sesión registra la actividad de trabajo normal del Agente SQL Server desde el inicio del trabajo hasta que termina. La información acerca de estas sesiones se almacena en la tabla syssessions de la base de datos msdb.

Monitor de Actividad de Trabajo

El Monitor de actividad de trabajo permite ver la tabla sysjobactivity mediante SQL Server

Management Studio. Puede ver todos los trabajos del servidor, o bien puede definir filtros para limitar el número de trabajos mostrados. También puede ordenar la información sobre los trabajos haciendo clic en un encabezado de columna de la cuadrícula Actividad de trabajo del agente. Por ejemplo, al seleccionar el encabezado de columna Última ejecución, puede ver los trabajos en el orden en que se ejecutaron por última vez. Al volver a hacer clic en el encabezado de columna, el orden de los trabajos cambia entre ascendente y descendente basándose en la fecha en que se ejecutaron por última vez. El Monitor de actividad de trabajo le permite realizar las siguientes tareas:

Iniciar y detener trabajos. Ver las propiedades del trabajo. Ver el historial de un determinado trabajo. Actualizar la información de la cuadrícula Actividad de trabajo del agente manualmente

o establecer un intervalo de actualización automático haciendo clic en Ver configuración de actualización.

Utilice el Monitor de actividad de trabajo cuando desee localizar los trabajos que están programados para su ejecución, el último resultado de los trabajos que se han ejecutado durante la sesión actual y localizar los trabajos que se están ejecutando actualmente o que están inactivos. Si el servicio del Agente SQL Server tiene un error inesperado, puede determinar los trabajos que se estaban ejecutando buscando en la sesión anterior del Monitor de actividad de trabajo. Para abrir el Monitor de actividad de trabajo, expanda Agente SQL Server en el Explorador de objetos de Management Studio, haga clic con el botón secundario en Monitor de actividad de trabajo y haga clic en Ver actividad de trabajo. También puede ver la actividad de trabajo de la sesión actual mediante el procedimiento almacenado sp_help_jobactivity.

- 145 -

- 146 -

4- Alertas Alertas Microsoft SQL Server genera eventos que se incluyen en el registro de aplicación de Microsoft Windows. El Agente SQL Server lee el registro de aplicación y compara los eventos con las alertas definidas. Cuando el Agente SQL Server encuentra una coincidencia, activa una alerta, que es una respuesta automatizada a un evento. Además de supervisar los eventos de SQL Server, el Agente SQL Server también puede supervisar las condiciones de rendimiento y los eventos de Instrumental de Administración de Windows (WMI).

Para definir una alerta, debe especificar:

El nombre de la alerta. El evento o condición de rendimiento que desencadena la alerta. La acción que el Agente SQL Server realiza como respuesta al evento o condición de

rendimiento. Cada alerta debe tener un nombre. Los nombres de las alertas deben ser exclusivos en la instancia de SQL Server y no pueden tener más de 128 caracteres. Eventos Una alerta responde a un tipo de evento específico. Las alertas responden a los siguientes tipos de evento:

Eventos de SQL Server Condiciones de rendimiento de SQL Server Eventos de WMI

El tipo de evento determina los parámetros que se utilizan para especificar el evento preciso. Puede especificar una alerta para que se produzca en respuesta a uno o más eventos. Utilice los siguientes parámetros para especificar los eventos que desencadenan una alerta:

Número de error: El Agente SQL Server activa una alerta cuando se produce un error

específico. Por ejemplo, puede especificar el número de error 2571 para responder a los intentos no autorizados de invocar comandos de consola de base de datos (DBCC).

Nivel de gravedad: El Agente SQL Server activa una alerta cuando se produce un error de la gravedad específica. Por ejemplo, puede especificar el nivel de gravedad 15 para responder a errores de sintaxis en instrucciones Transact-SQL.

Base de datos: El Agente SQL Server sólo activa una alerta cuando el evento tiene

lugar en una base de datos determinada. Esta opción se aplica además del número de error o el nivel de gravedad. Por ejemplo, si una instancia contiene una base de datos que se utiliza para la producción y una base de datos que se utiliza para la elaboración de informes, puede definir una alerta que responda a los errores de sintaxis sólo en la base de datos de producción.

Texto del evento: El Agente SQL Server activa una alerta cuando el evento

especificado contiene una cadena de texto determinada en el mensaje de evento. Por ejemplo, puede definir una alerta que responda a los mensajes que contienen el nombre de una tabla o restricción determinada.

- 147 -

Seleccionar una Condición de Rendimiento

Puede especificar una alerta para que se active en respuesta a una condición de rendimiento determinada. En este caso, debe especificar el contador de rendimiento que se supervisa, un umbral para la alerta y el comportamiento que el contador debe mostrar si la alerta tiene lugar. Para establecer una condición de rendimiento, debe definir los siguientes elementos en la página General del cuadro de diálogo Nueva alerta o Propiedades de alerta del Agente SQL

Server: Objeto: El objeto es el área de rendimiento que se supervisa. Contador: Un contador es un atributo del área que se supervisa. Instancia: La instancia de SQL Server define la instancia específica (si la hay) del

atributo que se va a supervisar. Alertar si el contador y Valor: El umbral de la alerta y el comportamiento que genera

la alerta. El umbral es un número. El comportamiento puede ser: está por debajo de, es igual a o está por encima de un número especificado en Valor. El Valor es un número que describe el contador de condición de rendimiento. Por ejemplo, para establecer una alerta que tendrá lugar para el objeto de rendimiento SQLServer:Locks cuando

pasen 30 minutos del Tiempo de espera de bloqueos, deberá elegir está por encima de y especificar 30 para el valor. En otro ejemplo, puede especificar que una alerta tenga lugar para el objeto de rendimiento SQLServer:Transactions cuando el espacio libre

- 148 -

en tempdb esté por debajo de 1000 KB. Para ello, escogerá el contador Espacio libre

en tempdb (KB), está por debajo de y un Valor de 1000. Nota: Se muestrean periódicamente los datos de rendimiento, lo que puede causar una

pequeña demora (unos segundos) entre el momento en que se alcanza el umbral y la activación de la alerta relativa al rendimiento. Seleccionar un Evento de WMI

Puede especificar que una alerta tenga lugar como respuesta a un determinado evento de WMI. Para seleccionar un evento de WMI, debe definir lo siguiente en la página General del cuadro de diálogo Nueva alerta o Propiedades de alerta del Agente SQL Server:

Espacio de nombres: El Agente SQL Server se registra como un cliente de WMI en el

espacio de nombres de WMI que se proporciona para consultar los eventos. Consulta: El Agente SQL Server utiliza la instrucción de Lenguaje de consulta de

Instrumental de administración de Windows (WQL) proporcionada para identificar el evento específico.

Alertar a Operadores Puede elegir a qué operadores notificará en respuesta a una alerta. Por ejemplo, puede asignar responsabilidades rotativas para notificar a los operadores mediante la programación de alertas. Por ejemplo, se notifica a A de las alertas que se producen los lunes, miércoles o viernes, y a B de las que se producen los martes, jueves y sábados. Si no se puede notificar a ninguno de los dos operadores, o si la alerta se produce en domingo, se notificará al operador a prueba de errores. Los operadores pueden recibir notificaciones mediante uno o varios de los siguientes métodos:

Notificación mediante correo electrónico Notificación mediante localizador Notificación mediante NET SEND

Para enviar correo electrónico, el Agente SQL Server puede usar el Correo electrónico de base de datos, que utiliza el Protocolo simple de transferencia de correo (SMTP), o bien SQL Mail, que utiliza MAPI extendida. Los requisitos de configuración varían en función del sistema utilizado para enviar correo electrónico. Si utiliza SQL Mail, el servicio del Agente SQL Server utiliza una sesión de correo exclusiva para las actividades del Agente SQL Server. Si también utiliza una sesión de SQL Mail para el servicio SQL Server, se recomienda que el Agente SQL Server y Microsoft SQL Server utilicen la misma cuenta de usuario de dominio de Microsoft Windows. Esto permite que ambas sesiones de correo utilicen el mismo perfil de correo. Si los servicios del Agente SQL Server y de SQL Server utilizan distintas cuentas de usuario de dominio, deberá configurar un perfil de correo para cada servicio Si utiliza el Correo electrónico de base de datos para enviar correo electrónico, deberá configurar el Agente SQL Server para utilizar un perfil específico del Correo electrónico de base de datos.

- 149 -

5- Manejo de Servidores Múltiples Administración multiservidor La administración multiservidor requiere que se configure un servidor principal y uno o más servidores de destino. Los trabajos que se van a procesar en todos los servidores de destino se definen primero en el servidor principal y luego se descargan en los servidores de destino. Para crear un entorno multiservidor, utilice el Asistente para servidor principal. El cifrado SSL (Capa de sockets seguros) y la validación de certificados completos se habilitan

para las conexiones entre los servidores principales y los servidores de destino de forma predeterminada. El asistente le guía por los siguientes pasos:

Comprobar la configuración de seguridad del servicio del Agente SQL Server y del servicio SQL Server en todos los servidores que van a ser servidores de destino.

Se recomienda ejecutar ambos servicios en cuentas de dominio de Microsoft Windows. Crear un operador de servidor principal (MSXOperator) en el servidor principal.

MSXOperator es el único operador que puede recibir notificaciones de trabajos

multiservidor. Iniciar el servicio del Agente SQL Server en el servidor principal. Dar de alta uno o más servidores como servidores de destino.

Si tiene un gran número de servidores de destino, evite definir el servidor principal en un servidor de producción. De lo contrario, el tráfico del servidor de destino puede ralentizar el rendimiento en el servidor de producción. Si también reenvía eventos a este servidor principal dedicado, puede centralizar la administración en un servidor. Nota: Para utilizar el procesamiento de trabajos multiservidor, la cuenta de servicio del Agente SQL Server debe ser miembro de la función TargetServersRole de la base de datos msdb del

servidor principal. El Asistente para servidor principal agrega automáticamente la cuenta de servicio a ésta función como parte del proceso de alta. Consideraciones para Entornos Multiservidor

Considere lo siguiente cuando cree un entorno multiservidor: Cada servidor de destino notifica únicamente a un servidor principal. Para dar de alta

un servidor de destino en otro servidor principal, primero debe darlo de baja en el servidor principal actual.

Si desea cambiar el nombre de un servidor de destino, debe darlo de baja antes de cambiar el nombre y volver a darlo de alta después del cambio.

Si desea anular una configuración multiservidor, debe dar de baja todos los servidores de destino del servidor principal.

Si desea distribuir planes de mantenimiento, necesitará una configuración adicional. Procesar Trabajos Multiservidor

Un trabajo multiservidor es un trabajo que ejecuta un servidor principal en uno o más servidores de destino. Cada servidor de destino sondea periódicamente al servidor principal, descarga una copia de cualquier nuevo trabajo asignado al servidor de destino y, a continuación, se desconecta. El servidor de destino ejecuta el trabajo de manera local y, a continuación, se vuelve a conectar al servidor principal para cargar el estado del resultado del trabajo una vez finalizado.

- 150 -

Nota: Si no es posible el acceso al servidor principal cuando el servidor de destino intenta

cargar el estado del trabajo, dicho estado de trabajo se coloca en la cola hasta que vuelva a ser posible el acceso al servidor principal.

- 151 -

6– Manejando la Seguridad del Agente SQL Server El Agente SQL Server permite al administrador de la base de datos ejecutar cada paso de trabajo en un contexto seguro que sólo tiene los permisos necesarios para realizar ese paso de trabajo, que está determinado por un servidor proxy del Agente SQL Server. Para establecer los permisos para un paso de trabajo concreto, cree un proxy que disponga de los permisos necesarios y, a continuación, asigne ese proxy al paso de trabajo. Se puede especificar un servidor proxy en más de un paso de trabajo. Para los pasos de trabajo que necesitan los mismos permisos se utiliza el mismo proxy. Conceder Acceso al Agente SQL Server

Para utilizar el Agente SQL Server, los usuarios deben ser miembros de una o más de las siguientes funciones fijas de base de datos:

SQLAgentUserRole SQLAgentReaderRole SQLAgentOperatorRole

Estas funciones se almacenan en la base de datos msdb. De manera predeterminada, ningún

usuario es miembro de estas funciones de base de datos. La pertenencia a estas funciones se debe conceder explícitamente. Los usuarios que sean miembros de la función fija de servidor sysadmin tienen acceso total al Agente SQL Server, y no necesitan ser miembros de estas funciones fijas de base de datos para utilizar el Agente SQL Server. Si un usuario no es miembro de una de estas funciones de base de datos ni de la función sysadmin, el nodo del

Agente SQL Server no estará disponible para ellos cuando se conecten con SQL Server mediante SQL Server Management Studio. Los miembros de estas funciones de base de datos pueden ver y ejecutar trabajos que les pertenecen, así como crear pasos de trabajos que se ejecuten como una cuenta de proxy existente. Funciones Fijas de Base de Datos del Agente SQL Server

SQL Server 2005 presenta las siguientes funciones fijas de base de datos de base de datos msdb, que proporcionan a los administradores un control más preciso a la hora de obtener acceso al Agente SQL Server. Las funciones enumeradas de menor a mayor privilegio de acceso son:

SQLAgentUserRole SQLAgentReaderRole SQLAgentOperatorRole

Cuando los usuarios que no son miembros de una de estas funciones se conectan con SQL Server en SQL Server Management Studio, el nodo del Agente SQL Server no está visible en el Explorador de objetos. Es preciso que los usuarios sean miembros de las funciones fijas de bases de datos o de la función de servidor fija sysadmin para poder utilizar el Agente SQL

Server. Permisos de las Funciones Fijas de Base de Datos del Agente SQL Server

Los permisos de las funciones de base de datos del Agente SQL Server son concéntricos: las funciones con más privilegios heredan los permisos de las funciones con menos privilegios en los objetos del Agente SQL Server (incluidos alertas, operadores, trabajos, programaciones y servidores proxy). Por ejemplo, si a los miembros de la función SQLAgentUserRole con menos privilegios se les ha concedido el acceso a?l proxy_A, los miembros de las funciones SQLAgentReaderRole y SQLAgentOperatorRole tendrán automáticamente acceso a este

- 152 -

proxy incluso si no se les ha concedido explícitamente el acceso al proxy_A. Esto puede tener implicaciones de seguridad, que se describen en las siguientes secciones sobre cada función. Permisos de SQLAgentUserRole Es la función con menos privilegios de todas las funciones fijas de base de datos del Agente SQL Server. Sólo dispone de permisos para operadores, trabajos locales y programaciones de trabajos. Los miembros de SQLAgentUserRole sólo tienen permisos en los trabajos locales y

en las programaciones de trabajos que les pertenecen. No pueden utilizar trabajos multiservidor (trabajos de servidor de destino y de servidor principal), ni pueden cambiar la propiedad de un trabajo para obtener acceso a trabajos que todavía no les pertenecen. Los miembros de SQLAgentUserRole pueden ver una lista de los servidores proxy disponibles

únicamente en el cuadro de diálogo Propiedades de paso de trabajo de SQL Server Management Studio. Para los miembros de SQLAgentUserRole sólo está visible el nodo

Trabajos del Explorador de objetos de SQL Server Management Studio. Nota de seguridad: Tenga en cuenta las implicaciones de seguridad antes de conceder

acceso al servidor proxy a los miembros de las funciones de base de datos del Agente SQL Server. Las funciones SQLAgentReaderRole y SQLAgentOperatorRole se convierten automáticamente en miembros de la función SQLAgentUserRole. Esto significa que los miembros de SQLAgentReaderRole y SQLAgentOperatorRole tienen acceso a todos los servidores proxy del Agente SQL Server cuyo acceso se ha concedido a SQLAgentUserRole

y, por tanto, pueden utilizar dichos servidores proxy. En la siguiente tabla encontrará un resumen de los permisos de SQLAgentUserRole para los

objetos del Agente SQL Server.

Acción Operadores Trabajos locales (sólo

trabajos que les pertenecen)

Programación de trabajos (sólo programaciones que les

pertenecen)

Servidores proxy

Crear, modificar o eliminar

No Sí 1 Sí No

Ver lista (enumerar)

Sí 2 Sí Sí Sí

3

Habilitar o deshabilitar

No Sí Sí No aplicable

Ver propiedades No Sí Sí No

Ejecutar, detener o iniciar

No aplicable

Sí No aplicable No aplicable

Ver historial de trabajos

No aplicable

Sí No aplicable No aplicable

Eliminar historial de trabajos

No aplicable

No 4 No aplicable No aplicable

Adjuntar o separar

No aplicable

No aplicable Sí No aplicable

- 153 -

Referencias de la tabla: 1 No se puede cambiar la propiedad de un trabajo. 2 Se puede obtener la lista de operadores disponibles para utilizar en sp_notify_operator y en el cuadro de diálogo Propiedades del trabajo de Management Studio. 3 Lista de los servidores proxy disponibles solamente en el cuadro de diálogo Propiedades de paso de trabajo de Management Studio. 4 Es necesario que a los miembros de SQLAgentUserRole se les haya concedido explícitamente el permiso EXECUTE en sp_purge_jobhistory para eliminar el historial de los trabajos que les pertenecen. No pueden eliminar el historial de ningún otro trabajo. Permisos de SQLAgentReaderRole La función SQLAgentReaderRole incluye todos los permisos de SQLAgentUserRole así

como permisos para ver la lista de trabajos multiservidor disponibles, sus propiedades y su historial. Los miembros de esta función también pueden ver la lista de trabajos y programaciones de trabajos disponibles y sus propiedades, y no sólo los trabajos y programaciones de trabajos que les pertenecen. Los miembros de SQLAgentReaderRole no

pueden cambiar la propiedad de un trabajo para obtener acceso a trabajos que no les pertenezcan ya. Para los miembros de SQLAgentReaderRole sólo está visible el nodo

Trabajos del Explorador de objetos de SQL Server Management Studio. Nota de seguridad: Tenga en cuenta las implicaciones de seguridad antes de conceder

acceso al servidor proxy a los miembros de las funciones de base de datos del Agente SQL Server. Los miembros de SQLAgentReaderRole se convierten automáticamente en miembros de la función SQLAgentUserRole. Esto significa que los miembros de SQLAgentReaderRole

tienen acceso a todos los servidores proxy del Agente SQL Server cuyo acceso se ha concedido a SQLAgentUserRole y, por tanto, pueden utilizar dichos servidores proxy. En la siguiente tabla encontrará un resumen de los permisos de SQLAgentReaderRole para

los objetos del Agente SQL Server.

Acción Operadores Trabajos locales Trabajos

multiservidor Programación de

trabajos Servidores

proxy

Crear, modificar o eliminar No

Sí 1 (sólo trabajos

que les pertenecen)

No Sí (sólo

programaciones que les pertenecen)

No


Sí 2 Sí Sí Sí Sí

3

Habilitar o deshabilitar No

Sí (sólo trabajos que les

pertenecen) No

Sí (sólo programaciones que les

pertenecen) No aplicable

Ver propiedades No Sí Sí Sí No

Modificar propiedades No


pertenecen) No

Sí (sólo programaciones que les

pertenecen) No

- 154 -


No aplicable


pertenecen) No No aplicable No aplicable


No aplicable

Sí Sí No aplicable No aplicable


No aplicable

No 4 No No aplicable No aplicable

Adjuntar o separar

No aplicable

No aplicable No aplicable Sí (sólo


No aplicable

Referencias de la tabla: 1 No se puede cambiar la propiedad de un trabajo.

2 Se puede obtener la lista de operadores disponibles para utilizar en sp_notify_operator y en

el cuadro de diálogo Propiedades del trabajo de Management Studio. 3 Lista de los servidores proxy disponibles solamente en el cuadro de diálogo Propiedades de

paso de trabajo de Management Studio. 4 Es necesario que a los miembros de SQLAgentReaderRole se les haya concedido

explícitamente el permiso EXECUTE en sp_purge_jobhistory para eliminar el historial de los

trabajos que les pertenecen. No pueden eliminar el historial de ningún otro trabajo. Permisos de SQLAgentOperatorRole Es la función con más privilegios de todas las funciones fijas de base de datos del Agente SQL

Server. Incluye todos los permisos de SQLAgentUserRole y SQLAgentReaderRole. Los

miembros de esta función también pueden ver las propiedades de operadores y servidores proxy, así como enumerar los servidores proxy y alertas disponibles en el servidor. Los miembros de SQLAgentOperatorRole tienen permisos adicionales en los trabajos locales

y en las programaciones. Pueden ejecutar, detener o iniciar todos los trabajos locales, y pueden eliminar el historial de trabajos de cualquier trabajo local del servidor. También pueden habilitar o deshabilitar todos los trabajos locales y programaciones del servidor. Para habilitar o deshabilitar trabajos locales o programaciones, los miembros de esta función deben utilizar los procedimientos almacenados sp_update_job y sp_update_schedule. Los miembros de SQLAgentOperatorRole únicamente pueden especificar los parámetros que especifican el nombre o el identificador del trabajo o la programación y el parámetro @enabled. Si

especifican cualquier otro parámetro, se producirá un error en la ejecución de estos procedimientos almacenados. Los miembros de SQLAgentOperatorRole no pueden cambiar

la propiedad de un trabajo para obtener acceso a trabajos que no les pertenezcan ya. Para los miembros de SQLAgentOperatorRole están visibles los nodos Trabajos, Alertas,

Operadores y Servidores proxy del Explorador de objetos de SQL Server Management Studio. El único nodo que no está visible para los miembros de esta función es el nodo Registros de errores. Nota de seguridad: Tenga en cuenta las implicaciones de seguridad antes de conceder acceso al servidor proxy a los miembros de las funciones de base de datos del Agente SQL Server. Los miembros de SQLAgentOperatorRole se convierten automáticamente en miembros de SQLAgentUserRole y SQLAgentReaderRole. Esto significa que los miembros de SQLAgentOperatorRole tienen acceso a todos los servidores proxy del Agente SQL Server cuyo acceso se ha concedido a SQLAgentUserRole o SQLAgentReaderRole y, por tanto, pueden utilizar dichos servidores proxy.

- 155 -

En la siguiente tabla encontrará un resumen de los permisos de SQLAgentOperatorRole para

los objetos del Agente SQL Server.

Acción Alertas Operadores Trabajos locales

Trabajos multiservidor

Programación de trabajos

Servidores proxy

Crear, modificar o eliminar

No No Sí

2 (sólo

trabajos que les pertenecen)

No Sí (sólo


No


Sí Sí 1 Sí Sí Sí Sí

Habilitar o deshabilitar

No No Sí 3 No Sí

4

No aplicable

Ver propiedades


Modificar propiedades No No


pertenecen) No

Sí (sólo programaciones

que les pertenecen) No


No aplicable

No aplicable

Sí No No aplicable No

aplicable


No aplicable

No aplicable

Sí Sí No aplicable No

aplicable


No aplicable

No aplicable

Sí No No aplicable No

aplicable

Adjuntar o separar

No aplicable

No aplicable

No aplicable No aplicable Sí (sólo


No aplicable

Referencias de la tabla: 1 Se puede obtener la lista de operadores disponibles para utilizar en sp_notify_operator y en

el cuadro de diálogo Propiedades del trabajo de Management Studio. 2 No se puede cambiar la propiedad de un trabajo.

3 Los miembros de SQLAgentOperatorRole pueden habilitar o deshabilitar trabajos locales

que no les pertenecen utilizando el procedimiento almacenado sp_update_job y especificando valores para los parámetros @enabled y @job_id (o @job_name). Si un miembro de ésta

función especifica cualquier otro parámetro para este procedimiento almacenado, la ejecución del procedimiento producirá un error. 4 Los miembros de SQLAgentOperatorRole pueden habilitar o deshabilitar programaciones

que no les pertenecen utilizando el procedimiento almacenado sp_update_schedule y especificando valores para los parámetros @enabled y @schedule_id (o @name). Si un

miembro de esta función especifica cualquier otro parámetro para este procedimiento almacenado, la ejecución del procedimiento producirá un error.

- 156 -

Asignar a los Usuarios varias Funciones

Los miembros de la función fija de seguridad sysadmin tienen acceso a toda la funcionalidad del Agente SQL Server. Si un usuario no es miembro de la función sysadmin, pero es miembro de más de una función fija de base de datos del Agente SQL Server, es importante recordar el modelo de permisos concéntricos de estas funciones. Debido a que las funciones con más privilegios siempre contienen todos los permisos de las funciones con menos privilegios, un usuario que sea miembro de más de una función automáticamente tendrá los permisos asociados con la función con más privilegios de la que sea miembro. Crear Cuentas de Proxy del Agente SQL Server

Un proxy del Agente SQL Server define el contexto de seguridad de un paso de trabajo.

Proporciona al Agente SQL Server acceso a las credenciales de seguridad de un usuario de Microsoft Windows. Cada proxy se puede asociar a uno o más subsistemas. Un paso de trabajo que utilice el proxy puede obtener acceso a los subsistemas especificados usando el contexto de seguridad del usuario de Windows. Antes de que el Agente SQL Server ejecute un paso de trabajo que utilice un proxy, suplanta las credenciales definidas en el proxy y, a continuación, ejecuta el paso de trabajo usando éste contexto de seguridad. Nota: Los pasos de trabajo que ejecutan Transact-SQL no utilizan cuentas de proxy del Agente

SQL Server. Los pasos de trabajo Transact-SQL se ejecutan en el contexto de seguridad del propietario del trabajo. Para establecer el contexto de seguridad de un paso de trabajo Transact-SQL, utilice el parámetro database_user_name en el procedimiento almacenado

sp_add_jobstep.

Las cuentas de proxy del Agente SQL Server utilizan credenciales para almacenar información acerca de las cuentas de usuario de Windows. El usuario especificado en las credenciales debe tener el permiso "Iniciar sesión como proceso por lotes" en el equipo en que se ejecuta SQL Server. El Agente SQL Server comprueba el acceso al subsistema de un proxy y da acceso al proxy cada vez que se ejecuta el paso de trabajo. Si el proxy ya no tiene acceso al subsistema, el paso de trabajo da error. De lo contrario, el Agente SQL Server suplanta al usuario especificado en el proxy y ejecuta el paso de trabajo. La creación de un proxy no cambia los permisos del usuario especificado en las credenciales del proxy. Por ejemplo, puede crear un proxy para un usuario que no tiene permisos para conectarse a una instancia de SQL Server. En este caso, los pasos de trabajo que usan el proxy no pueden conectarse a SQL Server. Un usuario debe tener acceso a un proxy para utilizarlo en un paso de trabajo. Se puede conceder acceso a tres tipos de principios de seguridad:

Inicios de sesión de SQL Server Funciones del servidor Funciones en la base de datos msdb

Si el inicio de sesión del usuario tiene acceso al proxy o si el usuario pertenece a una función con acceso al proxy, puede usarlo en un paso de trabajo. Nota: Los miembros de la función fija del servidor sysadmin tienen acceso a todas las cuentas

de proxy de la instancia.

- 157 -

Módulo 6

Implementando Replicación

- 158 -

1- Introducción a Réplica de SQL Server La réplica 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. La réplica permite distribuir datos entre diferentes ubicaciones y entre usuarios remotos o móviles mediante redes locales y de área extensa, conexiones de acceso telefónico, conexiones inalámbricas e Internet. Información General sobre los Tipos de Réplica Microsoft SQL Server 2005 proporciona los siguientes tipos de réplica para utilizar en las aplicaciones distribuidas:

Réplica transaccional (Transactinal replication).

Réplica de mezcla (Merge replication).

Réplica de instantáneas (Snapshot replication). El tipo de réplica que se elige para una aplicación depende de muchos factores, como el entorno físico de la réplica, el tipo y la cantidad de datos que se desean replicar y si los datos se actualizan en el suscriptor. El entorno físico incluye el número y la ubicación de los equipos que participan en la réplica, y si éstos equipos son clientes (estaciones de trabajo, equipos portátiles o dispositivos de mano) o servidores. Por lo general, cada tipo de réplica comienza con una sincronización inicial de los objetos publicados entre el publicador y los suscriptores. Esta sincronización inicial puede llevarse a cabo mediante la réplica con una instantánea, que es una copia de todos los objetos y datos especificados por una publicación. Una vez creada la instantánea, se envía a los suscriptores. Para algunas aplicaciones, la réplica de instantáneas es lo único que se necesita. Para otros tipos de aplicaciones, es importante que los cambios de datos posteriores fluyan al suscriptor de forma incremental a lo largo del tiempo. Algunas aplicaciones también requieren que los cambios vuelvan del suscriptor al publicador. La réplica transaccional y la réplica de mezcla proporcionan opciones para estos tipos de aplicaciones. En la réplica de instantáneas, no se realiza un seguimiento de los cambios de datos; cada vez que se aplica una instantánea, ésta sobrescribe completamente los datos existentes. La réplica transaccional realiza un seguimiento de los cambios a través del registro de transacciones de SQL Server y la réplica de mezcla realiza un seguimiento de los cambios a través de desencadenadores y tablas de metadatos. Réplica Transaccional Normalmente, la réplica transaccional se inicia con una instantánea de los datos y los objetos de la base de datos de publicaciones. En cuanto se obtiene la instantánea inicial, los posteriores cambios de datos y modificaciones del esquema realizados en el publicador habitualmente se entregan en el suscriptor cuando se producen (casi en tiempo real). Los cambios de datos se aplican al suscriptor en el mismo orden y dentro de los mismos límites de la transacción que cuando se produjeron en el publicador. Por tanto, en una publicación, se garantiza la coherencia transaccional.

- 159 -

La réplica transaccional se utiliza normalmente en entornos entre servidores y es la adecuada en los siguientes casos:

Se desea que se propaguen cambios incrementales a los suscriptores en el momento en que ocurren.

La aplicación requiere latencia baja entre el momento en que se realizan los cambios en el publicador y el momento en que los cambios llegan al suscriptor.

La aplicación requiere acceso a estados de datos intermedios. Por ejemplo, si una fila cambia cinco veces, la réplica transaccional permite a una aplicación responder a cada cambio (por ejemplo, activando un desencadenador), no simplemente al cambio de datos neto de la fila.

El publicador tiene un volumen elevado de actividad de inserción, actualización y eliminación.

El publicador o el suscriptor es una base de datos que no es de SQL Server, como Oracle.

De forma predeterminada, los suscriptores de publicaciones transaccionales deben tratarse como de sólo lectura, porque los cambios no se propagan del vuelta al publicador. No obstante, la réplica transaccional ofrece opciones que permiten actualizaciones en el suscriptor. Para obtener más información, vea Tipos de publicaciones para la réplica transaccional. Réplica de Mezcla La réplica de mezcla, como la réplica transaccional, normalmente se inicia con una instantánea de los objetos y datos de una base de datos de publicaciones. Los cambios de datos y las modificaciones de esquema posteriores que se lleven a cabo en el publicador y en los suscriptores se controlan mediante desencadenadores. El suscriptor se sincroniza con el publicador cuando están conectados a la red e intercambian todas las filas que han cambiado entre el publicador y el suscriptor desde la última vez que se produjo la sincronización. La réplica de mezcla se suele utilizar en entornos de servidor a cliente. La réplica de mezcla es adecuada en las siguientes situaciones:

Varios suscriptores actualizan los mismos datos en diferentes ocasiones y propagan los cambios al publicador y a otros suscriptores.

Los suscriptores necesitan recibir datos, realizar cambios sin conexión y sincronizar mas adelante los cambios con el publicador y otros suscriptores.

Cada suscriptor requiere una partición de datos diferente.

Se pueden producir conflictos y, cuando ocurren, debe poder detectarlos y resolverlos.

La aplicación requiere el cambio de datos neto en lugar de acceso a los estados intermedios de los datos. Por ejemplo, si una fila cambia cinco veces en el suscriptor antes de que éste se sincronice con el publicador, la fila cambiará sólo una vez en el publicador para reflejar el cambio de datos neto (es decir, el quinto valor).

La réplica de mezcla permite que diferentes sitios funcionen de forma autónoma y, después, mezclen las actualizaciones en un solo resultado uniforme. Puesto que las actualizaciones tienen lugar en más de un nodo, los mismos datos pueden haber sido actualizados por el publicador y por más de un suscriptor. Por tanto, se pueden producir conflictos cuando las actualizaciones se mezclan y la réplica de mezcla proporciona varias formas de controlar los conflictos. Réplica de Instantáneas La réplica de instantáneas distribuye los datos exactamente como aparecen en un momento específico en el tiempo y no supervisa las actualizaciones de los datos. Cuando se produce la sincronización, se genera la instantánea completa y se envía a los suscriptores.

- 160 -

Utilizar la réplica de instantáneas por sí sola es lo mas adecuado si se cumplen una o varias de las siguientes circunstancias:

Los datos cambian con poca frecuencia

Es aceptable disponer de copias de datos que están anticuadas con respecto al publicador durante un período de tiempo.

Se replican pequeñas cantidades de datos.

Se produce un gran número de cambios a lo largo de un corto período de tiempo. La réplica de instantáneas es lo más adecuado cuando los cambios en los datos son sustanciales pero poco frecuentes. Por ejemplo, si una organización de ventas mantiene una lista de precios de productos y todos los precios se actualizan al mismo tiempo una o dos veces al año, es recomendable replicar la instantánea completa de los datos una vez que han cambiado. Para determinados tipos de datos pueden ser adecuadas también instantáneas mas frecuentes. Por ejemplo, si una tabla relativamente pequeña se actualiza en el publicador durante el día pero es aceptable cierta latencia, los cambios se pueden entregar por la noche como una instantánea. La réplica de instantáneas tiene una carga continua mas reducida en el publicador que la réplica transaccional, ya que no se realiza ningún seguimiento de los cambios incrementales. No obstante, si el conjunto de datos que se está replicando es muy grande, será necesaria una cantidad importante de recursos para generar y aplicar la instantánea. Tenga en cuenta el tamaño del conjunto de datos entero y la frecuencia de los cambios en los datos al evaluar si utiliza o no la réplica de instantáneas. Información General del Modelo de Publicación de Réplica La réplica utiliza una metáfora del sector editorial para representar los componentes de una topología de réplica, que incluyen el publicador, el distribuidor, los suscriptores, las publicaciones, los artículos y las suscripciones. Resulta útil pensar en la réplica de Microsoft SQL Server como si fuera una revista:

El publicador (editor) de una revista produce una o más publicaciones.

Una publicación contiene artículos.

El publicador distribuye la revista directamente o a través de un distribuidor.

Los suscriptores reciben las publicaciones a las que se han suscrito. Aunque la metáfora de la revista es útil para comprender la réplica, es importante señalar que la réplica de SQL Server incluye funciones que no están representadas en esta metáfora, en particular, la posibilidad de que un suscriptor realice actualizaciones y de que un publicador envíe cambios incrementales a los artículos de una publicación. Una topología de réplica define la relación entre los servidores y las copias de los datos, y aclara la lógica que determina cómo fluyen los datos entre los servidores. Hay varios procesos de réplica (denominados agentes) que son responsables de copiar y mover los datos entre el publicador y los suscriptores. En la siguiente ilustración se muestra información general acerca de los componentes y procesos que participan en la réplica.

- 161 -

Publicador El publicador es una instancia de base de datos que permite que los datos estén disponibles para otras ubicaciones a través de la réplica. El publicador puede tener una o más publicaciones, cada una de las cuales representa un conjunto de objetos y datos relacionados lógicamente para replicar. Distribuidor El distribuidor es una instancia de base de datos que funciona como almacén para datos específicos de réplica asociados con uno o más publicadores. Cada publicador está asociado con una sola base de datos (conocida como la base de datos de distribución) en el distribuidor. La base de datos de distribución almacena los datos de estado de la réplica, metadatos acerca de la publicación y, en algunos casos, funciona como cola para los datos que se transfieren del publicador a los suscriptores. En muchos casos, una sola instancia de servidor de bases de datos funciona como publicador y como distribuidor. Esto se conoce como un distribuidor local. Cuando el publicador y el distribuidor se configuran en instancias distintas del servidor de bases de datos, el distribuidor se denomina un distribuidor remoto. Suscriptores Un suscriptor es una instancia de base de datos que recibe datos replicados. Un suscriptor puede recibir datos de varios publicadores y publicaciones. En función del tipo de réplica elegida, el suscriptor también puede devolver los datos modificados al publicador o volver a publicar los datos en otros suscriptores. Artículo Un artículo identifica un objeto de base de datos incluido en una publicación. Una publicación puede contener diferentes tipos de artículos, como tablas, vistas, procedimientos almacenados y otros objetos. Cuando las tablas se publican como artículos, se pueden usar filtros para restringir las columnas y filas de datos que se envían a los suscriptores. Publicación

- 162 -

Una publicación es un conjunto de uno o más artículos de una base de datos. La agrupación de varios artículos en una publicación permite especificar mas fácilmente un conjunto de objetos y datos de bases de datos relacionados lógicamente, que se replican como una unidad. Suscripción Una suscripción es una solicitud de una copia de una publicación que se entrega a un suscriptor. La suscripción define qué publicación se recibirá, dónde y cuándo. Hay dos tipos de suscripciones: de inserción y de extracción.

- 163 -

2- Implementar replicación Implementación El proceso de implementación de la réplica varía según el tipo de réplica y las opciones elegidas pero, en general, la réplica se compone de las fases siguientes:

Configurar la réplica y publicar datos

Crear e inicializar suscripciones

Sincronizar datos En este tema se proporciona información de cada fase, con vínculos a descripciones más detalladas. Además de conocer los pasos necesarios para configurar la réplica, es importante conocer las consideraciones de:

Implementación.

Seguridad.

Rendimiento.

Copia de seguridad y restauración. Configurar la Réplica y Publicar Datos La implementación de la réplica comienza cuando se configura el publicador y el distribuidor. El distribuidor desempeña una función principal en la réplica transaccional; en cambio, tiene un papel más limitado en la réplica de instantáneas y de mezcla, donde se utiliza sólo para tareas del historial del agente y supervisión e informes de errores. Normalmente, la réplica de mezcla y la réplica de instantáneas utilizan un distribuidor que se ejecuta en el mismo equipo que el publicador, mientras que la réplica transaccional puede utilizar un distribuidor remoto, especialmente si el publicador es un sistema OLTP de alto rendimiento. Después de configurar el publicador y el distribuidor, puede crear publicaciones basadas en los datos, subconjuntos de datos y objetos de base de datos. Cuando se crea una publicación, debe especificar:

Los datos y los objetos de base de datos que desea replicar.

Qué tipo y opciones de réplica utilizará, incluido el filtro.

Dónde se almacenarán los archivos de instantáneas y cuándo se producirá la sincronización inicial, independientemente de que entregue manualmente el conjunto de datos inicial.

Otras propiedades que se deben establecer para la publicación. Según el tipo de réplica y las opciones elegidas al configurar la publicación, el suscriptor puede modificar los datos después de haber entregado el conjunto de datos inicial y propagar los cambios al publicador, que puede a su vez propagar los cambios a otros suscriptores. Las siguientes opciones y tipos de réplica permiten a los suscriptores modificar los datos replicados y hacer que las modificaciones se propaguen de vuelta al publicador:

Réplica de mezcla.

Réplica transaccional con suscripciones actualizables.

Réplica transaccional de punto a punto.

Réplica transaccional bidireccional. Filtrar Datos Publicados Al filtrar artículos de tabla podrá crear particiones de los datos que se publicarán. Si filtra los datos publicados, podrá:

Minimizar la cantidad de datos que se envían a través de la red.

- 164 -

Reducir la cantidad de espacio de almacenamiento necesario en el suscriptor.

Personalizar las publicaciones y las aplicaciones en función de los requisitos de cada suscriptor.

Evitar o reducir los conflictos si los suscriptores actualizan datos, ya que pueden enviarse particiones de datos diferentes a varios suscriptores (dos suscriptores distintos no actualizarán los mismos valores de datos).

Evitar la transmisión de datos reservados. Se pueden utilizar filtros de fila y filtros de columna para restringir el acceso de un suscriptor a los datos. Para la réplica de mezcla, existen consideraciones de seguridad si utiliza un filtro con parámetros que incluya HOST_NAME().

La Réplica ofrece cuatro Tipos de Filtros:

Filtros de fila estáticos: que están disponibles con todos los tipos de réplica. Mediante los filtros de fila estáticos, puede especificar un subconjunto de filas para publicarlo. Todos los suscriptores de una publicación filtrada reciben el mismo subconjunto de filas para la tabla filtrada.

En la siguiente ilustración se muestra una tabla publicada que está filtrada para que solamente se incluyan las filas 2, 3 y 6 en la publicación.

Filtros de columna: que están disponibles con todos los tipos de réplica. Al utilizar los filtros de columna, puede seleccionar un subconjunto de columnas para publicarlo.

En la siguiente ilustración se muestra una publicación que filtra la columna C.

- 165 -

También puede utilizar conjuntamente el filtrado de filas y columnas, como se ilustra a continuación.

Filtros de fila con parámetros: que están disponibles solamente con la réplica de mezcla. Al utilizar los filtros de fila con parámetros, puede seleccionar un subconjunto de filas para publicarlo. A diferencia de los filtros estáticos que envían el mismo subconjunto de filas a cada suscriptor, los filtros de fila con parámetros utilizan un valor de datos suministrado por el suscriptor para enviar a los suscriptores diferentes subconjuntos de filas.

- 166 -

Filtros de combinación: que están disponibles solamente con la réplica de mezcla. Al utilizar los filtros de combinación, puede ampliar un filtro de fila de una tabla publicada a otra.

Procedimientos Almacenados de Réplica Los procedimientos almacenados del sistema de réplica se documentan y están disponibles como un método para realizar tareas únicas como la implementación de la réplica y el uso de archivos de proceso por lotes y secuencias de comandos. Si desea agregar un control de programación de la réplica para una aplicación o realizar tareas de réplica repetidas como la sincronización de suscripciones, se recomienda utilizar las interfaces de programación suministradas con los objetos de administración de réplica (RMO). Importante: Sólo se admiten los procedimientos almacenados de réplica documentados en los Libros en pantalla de SQL Server. Los procedimientos almacenados no documentados sólo se utilizan para los componentes de réplica internos y no se pueden utilizar para administrar la réplica. En la tabla siguiente se muestran los principales procedimientos almacenados de réplica:

Procedimiento almacenado Descripción

sp_replicationdboption Establece una opción de base de datos de réplica para la base de datos especificada. Este procedimiento almacenado se ejecuta en el publicador o el suscriptor de cualquier base de datos.

sp_addlogreader_agent Agrega un Agente de registro del LOG a una base de datos dada. Este procedimiento almacenado se ejecuta en el publicador de la base de datos de publicaciones.

sp_addqreader_agent Agrega un Agente de lectura de cola a un distribuidor específico. Este procedimiento almacenado se ejecuta en el distribuidor de la base de datos de distribución o en el publicador de la base de datos de publicaciones.

sp_addpublication Crea una publicación de instantáneas o transaccional. Este procedimiento almacenado se ejecuta en el publicador de la base de datos de publicaciones.

sp_addpublication_snapshot Crea el Agente de instantáneas en la publicación especificada. Este procedimiento almacenado se ejecuta en el publicador de la base de datos de publicaciones.

sp_grant_publication_access Agrega un inicio de sesión a la lista de acceso de la publicación. Este procedimiento almacenado se ejecuta en el publicador de la base de datos de publicaciones.

sp_addarticle Crea un artículo y lo agrega a una publicación. Este procedimiento almacenado se ejecuta en el publicador de la base de datos de publicaciones.

sp_articlefilter Filtra los datos que se publican en función de un artículo de tabla. Este procedimiento almacenado se ejecuta en el publicador de la base de datos de publicaciones.

sp_articleview Crea la vista que define el artículo publicado cuando una tabla se filtra horizontal o verticalmente. Esta vista se utiliza como el origen filtrado del esquema y los datos de las tablas de destino. Con este procedimiento almacenado sólo pueden modificarse artículos sin suscripciones. Este procedimiento almacenado se ejecuta en el publicador de la base de datos de publicaciones.

- 167 -

Crear e Inicializar Suscripciones Una suscripción es una petición de copia de datos y objetos de base de datos en una publicación. Una suscripción define qué publicación se recibirá, dónde y cuándo. Al planear suscripciones, tenga en cuenta dónde se realizará el proceso del agente. El tipo de suscripción que elige controla dónde se ejecuta el agente. Con una suscripción de inserción, el Agente de Mezcla o el Agente de Distribución se ejecutan en el distribuidor, mientras que en una suscripción de extracción los agentes se ejecutan en los suscriptores. Después de crear una suscripción, no se puede cambiar de un tipo a otro. Después de crear una publicación, puede crear suscripciones y configurar opciones adicionales. Tanto si utiliza la réplica de instantáneas, transaccional o de mezcla, la réplica crea de forma predeterminada una instantánea inicial del esquema y los datos de la publicación y, a continuación, la guarda en la ubicación de la carpeta de instantáneas que ha especificado. Después de crear la suscripción, la instantánea inicial se aplica en función de la programación indicada al crear la publicación. Puede pasar por alto uno o varios pasos de la instantánea si el suscriptor ya tiene un conjunto de datos inicial o si desea aplicarla manualmente.

Suscripción Características Se utiliza si

Suscripción de inserción

Con una suscripción de inserción, el publicador propaga los cambios al suscriptor sin que éste lo pida. Los cambios pueden insertarse en los suscriptores a petición, de manera continua o según una programación. De forma predeterminada, el Agente de distribución o el Agente de mezcla se ejecutan en el distribuidor.

Normalmente, los datos se

sincronizarán de forma continua o

con una frecuencia determinada.

Las publicaciones requieren que el

movimiento de datos sea casi en

tiempo real.

La sobrecarga del procesador en el

distribuidor no afecta al

rendimiento.

Se utiliza frecuentemente en la

réplica de instantáneas y

transaccional.

Suscripción de extracción

En una suscripción de extracción, el suscriptor solicita los cambios efectuados en el publicador. Las suscripciones de extracción permiten al usuario del suscriptor determinar cuándo se sincronizan los cambios en los datos. El Agente de distribución o el Agente de mezcla se ejecutan en el suscriptor.

Los datos se sincronizarán,

generalmente, a petición o en

función de una programación, en

lugar de hacerlo de forma

continuada.

La publicación dispone de un gran

número de suscriptores y/o la

ejecución de todos los agentes en

el distribuidor supone un uso

demasiado intensivo de recursos.

Los suscriptores son autónomos,

- 168 -

están desconectados o se

desplazan. Los suscriptores

determinan cuándo se conectarán y

sincronizarán los cambios.

Se utiliza frecuentemente en la

réplica de mezcla.

Suscriptores que no son de SQL Server Oracle e IBM DB2 pueden suscribirse a publicaciones de instantáneas y transaccionales con suscripciones de inserción. Crear Suscripciones Para crear una suscripción, proporcione la siguiente información:

El nombre de la publicación.

El nombre del suscriptor y la base de datos de suscripciones.

Si el Agente de distribución o el Agente de mezcla se ejecutan en el distribuidor o en el suscriptor.

Si el Agente de distribución o el Agente de mezcla se ejecutan de forma continua, programada o solamente a petición.

Si el Agente de instantáneas debe crear una instantánea inicial para la suscripción y si el Agente de distribución o el Agente de mezcla debe aplicar esa instantánea en el suscriptor.

Las cuentas con la que se ejecutará el Agente de distribución o el Agente de mezcla.

En la réplica de mezcla, el tipo de suscripción: servidor o cliente. Sincronizar Datos La sincronización es el proceso de propagación de los datos entre el publicador y los suscriptores después de haber aplicado el conjunto de datos inicial en el suscriptor. En la réplica de instantáneas, la sincronización significa volver a aplicar la instantánea en el suscriptor, de modo que los datos y esquemas de la base de datos de suscripciones sean coherentes con la base de datos de publicaciones. En la réplica transaccional, la sincronización de datos significa que las modificaciones de datos, como las inserciones, actualizaciones y eliminaciones, se distribuyen entre el publicador y los suscriptores (y desde los suscriptores de vuelta al publicador en caso de suscripciones de actualización). En la réplica de mezcla, la sincronización significa que las modificaciones de datos realizadas en varios sitios se mezclan, los conflictos se detectan y resuelven, y los datos finalmente adoptan los mismos valores en todos los sitios. Asistentes para Réplica La réplica proporciona asistentes para simplificar la implementación de la réplica. A través de la carpeta Réplica en SQL Server Management Studio puede tener acceso a los asistentes para réplica. Asistente para Nueva Publicación Use el Asistente para nueva publicación para especificar lo siguiente:

- 169 -

Que la instancia del publicador también actuará como el distribuidor (si va a utilizar un distribuidor remoto, éste ya debe estar configurado con el Asistente para configurar la distribución).

La ubicación predeterminada de los archivos de instantáneas.

La base de datos de publicaciones.

El tipo de publicación que se va a crear (de instantánea, transaccional, transaccional con suscripciones actualizables o de mezcla).

Los datos y los objetos de la base de datos (artículos) que se incluirán en la publicación.

Los filtros de fila estáticos y los filtros de columna para todos los tipos de publicaciones, y los filtros de fila con parámetros y los filtros de combinación para publicaciones de mezcla.

La programación del Agente de instantáneas.

Las cuentas con las que se ejecutarán los siguientes agentes: el Agente de instantáneas para todas las publicaciones, el Agente de registro del LOG para todas las publicaciones transaccionales, el Agente de lectura de cola para publicaciones transaccionales que permiten suscripciones de actualización.

Un nombre y una descripción para la publicación.

Para Crear Publicaciones y Definir Artículos

Conéctese al publicador en Microsoft SQL Server Management Studio y expanda el nodo de servidor.

Expanda la carpeta Réplica y, a continuación, haga clic con el botón secundario en la carpeta Publicaciones locales.

Haga clic en Nueva publicación.

Siga las indicaciones de las páginas del Asistente para la nueva publicación.

Especifique un distribuidor si la distribución no se ha configurado en el servidor. Si en la página Distribuidor especifica que el servidor del publicador actúe como su propio distribuidor (un distribuidor local) y el servidor no está configurado como tal, el Asistente para nueva publicación configurará el servidor. Especifique una carpeta de instantáneas predeterminada para el distribuidor en la página Carpeta de instantáneas. La carpeta de instantáneas es simplemente un directorio designado como recurso compartido; los agentes que leen y escriben en esta carpeta deben tener suficientes permisos de acceso a la misma. Si especifica que otro servidor actúe como distribuidor, deberá escribir una contraseña en la página Contraseña administrativa para las conexiones que se realicen desde el publicador al distribuidor. Esta contraseña debe coincidir con la contraseña que se especificó al habilitar el publicador en el distribuidor remoto.

Elija una base de datos de publicaciones.

Seleccione un tipo de publicación.

Especifique los datos y los objetos de base de datos que se van a publicar; de forma opcional, filtrar columnas de artículos de tablas y establecer las propiedades de los artículos.

De forma opcional, filtrar filas de artículos de tablas.

Establezca la programación del Agente de instantáneas.

Especifique las credenciales con las que los siguientes agentes de réplica se ejecutan y efectúan conexiones:

-Agente de instantáneas para todas las publicaciones. -Agente de registro del LOG para todas las publicaciones transaccionales.

-Agente de lectura de cola para publicaciones transaccionales que permiten suscripciones de actualización.

Especifique un nombre para la publicación.

- 170 -

En las siguientes imágenes se pueden observar algunas solapas del Asistente de Nuevas Publicaciones:

- 171 -

Asistente para Nuevas Suscripciones Use el Asistente para nuevas suscripciones para especificar lo siguiente:

- 172 -

La publicación a la que desea suscribirse.

Dónde deben ejecutarse el Agente de distribución o el Agente de mezcla.

Las cuentas con las que se ejecutarán y realizarán las conexiones el Agente de distribución o el Agente de mezcla.

Uno o varios suscriptores que van a recibir datos publicados y la base de datos de suscripciones que recibirá los datos publicados en cada suscriptor.

Si la suscripción debe inicializarse y, si es así, cuándo.

Las programaciones de los agentes para definir la frecuencia con la que se propagarán las actualizaciones al suscriptor.

Información adicional basada en los valores de publicación. En las siguientes imágenes se pueden observar algunas solapas del Asistente de Nuevas Suscripciones:

- 173 -

- 174 -

Asistente para Configurar la Distribución Use el Asistente para configurar la distribución para lo siguiente:

Configurar un distribuidor remoto.

- 175 -

Especificar la ubicación predeterminada de los archivos de instantáneas. Nota: También puede utilizar este asistente para configurar un distribuidor local, pero normalmente esto se realiza mediante el Asistente para nueva publicación la primera vez que se crea una publicación en un publicador.

Asistente para deshabilitar la publicación y distribución Use el Asistente para deshabilitar la publicación y distribución para deshabilitar la publicación y distribución en un servidor. Asistente de configuración de la topología punto a punto Use el Asistente de configuración de la topología punto a punto para crear una topología de réplica transaccional de punto a punto. Cree una publicación transaccional en el primer nodo en el Asistente para nueva publicación y, a continuación, utilice el Asistente de configuración de la topología punto a punto para crear publicaciones y suscripciones en otros nodos.

- 176 -

Asistente para la sincronización Web Use el Asistente para la sincronización Web para configurar un servidor con Microsoft Internet Information Services (IIS) para la sincronización Web, que permite sincronizar suscripciones a publicaciones de mezcla a través de una conexión de Internet o intranet.

- 177 -

3- Monitor de Réplica Supervisión de la Réplica con el Monitor de Réplica El Monitor de réplica de Microsoft SQL Server es una herramienta gráfica que le permite supervisar el estado general de una topología de réplica. El Monitor de réplica proporciona información detallada sobre el estado y rendimiento de las publicaciones y suscripciones, y le permite responder a preguntas comunes, tales como:

¿Es correcto el sistema de réplica?

¿Qué suscripciones son lentas?

¿Cuál es el retraso de la suscripción transaccional?

¿Cuánto tardará una transacción confirmada ahora en llegar al suscriptor en la réplica transaccional?

¿Por qué es lenta la suscripción de mezcla?

¿Por qué no se ejecuta un agente? Para supervisar la réplica, un usuario debe ser miembro de la función fija de servidor sysadmin en el distribuidor o miembro de la función fija de base de datos replmonitor en la base de datos de distribución. Un administrador del sistema puede agregar cualquier usuario a la función replmonitor que permite a un usuario ver la actividad de réplica en el Monitor de réplica; sin embargo, el usuario no puede administrar la réplica. La interfaz del Monitor de réplica El Monitor de réplica de Microsoft SQL Server presenta una vista centrada en el publicador de toda la actividad de réplica en un formato de dos paneles. Se agrega un publicador al monitor en el panel izquierdo y, en el panel derecho, el monitor muestra información sobre el publicador, sus publicaciones, las suscripciones a esas publicaciones y los diversos agentes de réplica. Además de presentar información de la topología de réplica, el Monitor de réplica permite realizar varias tareas, como iniciar y detener agentes y validar datos.

- 178 -

Ver información de toda la topología En el panel izquierdo del Monitor de réplica se muestran los grupos de publicadores, los publicadores y las publicaciones. El panel izquierdo ayuda a responder a las siguientes preguntas:

¿Es correcto el estado de mi sistema de réplica? El estado del sistema de réplica es relativamente correcto si no existen iconos de error en los nodos del panel izquierdo. Para obtener una vista más completa del estado del sistema, también debe comprobar la ficha Lista de supervisión de suscripciones, en la que se muestra información sobre las suscripciones que pueden requerir atención.

¿Por qué no funciona un agente? Un agente no funciona en un momento determinado porque no está programado para ejecutarse o porque se ha producido un error. Si se ha producido un error, se muestra un icono de error en los nodos correspondientes del panel izquierdo. Por ejemplo, si el Agente de instantáneas de una publicación se detiene debido a un error, se muestra un icono de error en el grupo de publicador, el publicador y los nodos de publicación. En la ficha Advertencias y agentes de la publicación se muestra información resumida del Agente de instantáneas; haga doble clic en el Agente de instantáneas de esta ficha para obtener información detallada del error.

Ver información y realizar tareas relacionadas con publicadores El Monitor de réplica muestra información sobre publicadores en tres fichas:

Ficha Publicaciones: Esta ficha proporciona información resumida de todas las publicaciones en un publicador.

Ficha Lista de Supervisión de Suscripciones: Esta ficha está diseñada para mostrar información sobre suscripciones de todas las publicaciones disponibles en el publicador

- 179 -

seleccionado. Puede filtrar la lista de suscripciones para ver errores, advertencias y las suscripciones que tienen un rendimiento bajo. Esta ficha permite también: tener acceso a las propiedades de la suscripción, tener acceso a información detallada sobre el agente o los agentes asociados con una suscripción, y reinicializar y validar suscripciones.

La ficha Lista de supervisión de suscripciones ayuda a responder a las siguientes preguntas:

o ¿Cuáles son las suscripciones lentas? Establezca opciones en esta ficha para que la cuadrícula muestre las suscripciones ordenadas por su rendimiento relativo.

o ¿Es correcto el estado de mi sistema de réplica? La cuadrícula de esta ficha muestra iconos de advertencia y error en las suscripciones que requieren su atención.

Esta ficha no se muestra en los distribuidores que ejecutan versiones anteriores a Microsoft SQL Server 2005.

Ficha Trabajos Comunes: En esta ficha se muestra información sobre los trabajos utilizados por todos los tipos de réplica. Esta ficha permite también: tener acceso a información detallada sobre los trabajos e iniciar y detener cada trabajo.

El Monitor de réplica también proporciona un menú contextual para el nodo de publicador. En el panel izquierdo, haga clic con el botón secundario en un publicador para:

Editar la configuración del Monitor de réplica para el publicador.

Quitar el publicador del Monitor de réplica.

Ver y editar perfiles de agente.

Conectarse o desconectarse del distribuidor que almacena información sobre el publicador.

El Monitor de réplica también proporciona un menú contextual para el nodo de publicaciones. En el panel izquierdo, haga clic con el botón secundario en una publicación para:

Reinicializar todas las suscripciones en una publicación.

Validar todas las suscripciones en una publicación.

Generar una instantánea para una publicación.

Ver y editar las propiedades de una publicación. Ver información y realizar tareas relacionadas con suscripciones El Monitor de réplica muestra información sobre suscripciones en varias fichas diferentes. Haga doble clic en una suscripción en el Monitor de Réplica para tener acceso a información en una ventana de detalles. Todas estas fichas son útiles para responder a la pregunta "¿Por qué no funciona un agente?". Los mensajes de error disponibles proporcionan información detallada sobre por qué no funciona un agente y un punto inicial para solucionar problemas con los agentes asociados con una suscripción.

Ficha Todas las suscripciones y ficha Lista de supervisión de suscripciones: Estas fichas se han descripto anteriormente en este tema.

Ficha Historial de Publicador a distribuidor (sólo réplica transaccional): En esta ficha se muestra información sobre el Agente de registro del LOG para una publicación (la ficha es idéntica a la ventana de detalles del Agente de registro del LOG).

Ficha Historial de Distribuidor a suscriptor (réplica de instantánea y réplica transaccional). En esta ficha se muestra información sobre el Agente de distribución para una suscripción.

Ficha Comandos sin distribuir (sólo réplica transaccional): En esta ficha se muestra información sobre el número de comandos de la base de datos de distribución que no

- 180 -

se han entregado al suscriptor seleccionado y el tiempo estimado para entregar esos comandos. La ficha ayuda a responder a la pregunta, "¿Qué retraso tiene mi suscripción?" Esta ficha no se muestra en los distribuidores que ejecutan versiones anteriores a SQL Server 2005.

Ficha Historial de sincronizaciones (sólo réplica de mezcla): En esta ficha se muestra información sobre el Agente de mezcla para una suscripción. Esta ficha ayuda a responder a la siguiente pregunta: ¿Por qué mi suscripción de mezcla es lenta?

En esta ficha se proporcionan estadísticas detalladas de cada artículo procesado durante la sincronización, incluido el tiempo invertido en cada fase del proceso (carga de cambios, descarga de cambios, etc.). Puede ayudar a identificar con precisión tablas específicas que provocan lentitud y el mejor lugar para solucionar problemas de rendimiento con suscripciones de mezcla.

Ver información y realizar tareas relacionadas con perfiles de agente El Monitor de réplica incluye varios cuadros de diálogo para administrar perfiles de agente. Los perfiles de agente son conjuntos de parámetros de un agente que determinan su comportamiento. Los cuadros de diálogo son:

Perfiles de agente: Este cuadro de diálogo permite: cambiar las propiedades de perfiles, crear y eliminar perfiles, especificar un perfil predeterminado y especificar que todos los agentes de un tipo específico (por ejemplo, los Agentes de instantáneas) deben utilizar un perfil determinado.

Propiedades de <nombreDePerfilDeAgente>: Este cuadro de diálogo permite ver y editar la configuración de parámetros de un perfil.

Nuevo perfil de agente: Este cuadro de diálogo permite crear un perfil nuevo y, opcionalmente, incluye los valores de un perfil existente.

Supervisar estado de la suscripción y la publicación en el Monitor de réplica En el Monitor de réplica de Microsoft SQL Server se muestra información del estado de las publicaciones y suscripciones: El estado de una publicación está determinado por el estado de prioridad más alto de sus suscripciones. Por ejemplo, si una suscripción a una publicación tiene un error y otra tiene un problema de rendimiento se muestra un estado de error para la publicación. El estado de una suscripción se determina por el estado de los agentes que dan servicio a la suscripción. En la réplica de mezcla, es el Agente de mezcla. En la réplica transaccional, es el Agente de registro del LOG o el Agente de distribución (se muestra el estado de prioridad mas alto; el estado también se puede determinar por el Agente de lectura de cola si se utilizan suscripciones de actualización en cola). En la réplica de instantáneas, es el Agente de instantáneas o el Agente de distribución (se muestra el estado de prioridad más alto). En las tablas de las siguientes secciones se enumeran los posibles valores de estado de publicaciones y suscripciones. Tres de los valores de estado sólo se muestran si se cumple o supera un umbral:

Suscripción caducada: Este valor de estado se aplica a todos los tipos de réplica.

Rendimiento crítico: Este valor de estado se aplica a la réplica transaccional y a la réplica de mezcla.

Mezcla de ejecución prolongada: Este valor de estado se aplica a la réplica de mezcla.

Además de los estados de suscripción y publicación, la réplica de mezcla proporciona estadísticas de artículos, que ofrecen información detallada sobre cuánto tiempo tarda en completarse la fase de mezcla, cuanto tiempo se invierte en procesar un artículo determinado, el tipo de conexión de conexión que utiliza un suscriptor y demás información importante. Las

- 181 -

estadísticas se muestran en la ventana del Agente de mezcla en el Monitor de réplica. La réplica de instantáneas y transaccional proporciona información detallada sobre el proceso del Agente de distribución. Supervisar agentes de réplica El Monitor de réplica de Microsoft SQL Server proporciona una vista sistémica de la actividad de réplica, aunque también facilita la búsqueda de información sobre un agente concreto. En la siguiente lista se incluye cada agente, las fichas del Monitor de réplica en las que se puede encontrar y un vínculo a un tema en el que se explica el modo de obtener acceso a las fichas: Los siguientes agentes están asociados con publicaciones en el Monitor de réplica:

Agente de instantáneas

Agente de registro del LOG

Agente de lectura de cola Obtenga acceso a la información y a las tareas asociadas con estos agentes a través de las siguientes fichas de la publicación: la ficha Advertencias y agentes (para los distribuidores que se ejecutan en Microsoft SQL Server 2005) o la ficha Agentes (para los distribuidores que se ejecuten en versiones anteriores de Microsoft SQL Server). Los siguientes agentes están asociados con suscripciones en el Monitor de réplica:

Agente de distribución

Agente de mezcla Obtenga acceso a la información y a las tareas asociadas con estos agentes a través de las siguientes fichas: la ficha Lista de supervisión de suscripciones (disponible para todos los publicadores) o la ficha Todas las suscripciones (disponible para todas las publicaciones). Para supervisar el Agente de instantáneas y el Agente de registro del LOG

Conéctese al publicador en Management Studio y, a continuación, expanda el nodo de servidor.

Expanda la carpeta Réplica y, a continuación, expanda la carpeta Publicaciones locales.

Haga clic con el botón secundario en una publicación y, a continuación, en Ver estado del Agente de registro del LOG o en Ver estado del Agente de instantáneas.

En el cuadro de diálogo Ver estado del Agente de registro del LOG o Ver estado del Agente de instantáneas: o Vea el estado del agente o Inicie o detenga el agente si fuese necesario. o Haga clic en Supervisar para iniciar el Monitor de Réplica.

Haga clic en Cerrar. Para supervisar el Agente de distribución y el Agente de mezcla (en el publicador)

Conéctese al publicador en Management Studio y, a continuación, expanda el nodo de servidor.

Expanda la carpeta Réplica y, a continuación, expanda la carpeta Publicaciones locales.

Expanda la publicación de la suscripción que desea supervisar.

Haga clic con el botón secundario en la suscripción y, a continuación, haga clic en Ver estado de sincronización.

En el cuadro de diálogo Ver estado de sincronización:

- 182 -

o Vea el estado del agente o Inicie o detenga el agente si fuese necesario. o Para las suscripciones de inserción, haga clic en Supervisar para iniciar el Monitor

de réplica. o Para las suscripciones de extracción, haga clic en Ver historial de trabajos para

iniciar el Visor del archivo de registros, que muestra información sobre el registro del agente.

Haga clic en Cerrar. Para supervisar el Agente de distribución y el Agente de mezcla (en el suscriptor)

Conéctese al suscriptor en Management Studio y expanda el nodo de servidor.

Expanda la carpeta Réplica y, a continuación, expanda la carpeta Suscripciones locales.

Haga clic con el botón secundario en la suscripción que desee supervisar y, a continuación, haga clic en Ver estado de sincronización.

En el cuadro de diálogo Ver estado de sincronización: o Vea el estado del agente o Inicie o detenga el agente si fuese necesario. o Haga clic en Ver historial de trabajos para iniciar el Visor del archivo de

registros, que muestra información sobre el registro del agente.

Haga clic en Cerrar.

- 183 -

4- Configurar Replicación en algunos Escenarios Comunes Replicar Datos en un Entorno de Servidor a Servidor Resulta útil dividir la réplica en dos categorías generales: replicar datos en un entorno de servidor a servidor y replicar datos entre un servidor y los clientes. Por lo general, los datos se replican entre servidores para proporcionar compatibilidad con las siguientes aplicaciones y requisitos:

Mejorar la escalabilidad y la disponibilidad: Mantener copias de los datos que se actualicen de forma continua permite escalar la actividad de lectura entre varios servidores. La redundancia que produce el mantener varias copias de los mismos datos es crucial durante el mantenimiento del sistema (ya sea planeado o no planeado).

Almacenamiento de datos e informes: Los servidores de almacenamiento de datos e informes utilizan con frecuencia datos de los servidores de procesamiento de transacciones en línea (OLTP). Utilice la réplica para mover datos entre los servidores OLTP y los sistemas de informes y ayuda para la toma de decisiones.

Integrar datos de varios sitios: Con frecuencia, los datos se transfieren desde las oficinas remotas y se consolidan en una oficina central. De la misma forma, es posible replicar los datos en las oficinas remotas.

Integrar datos heterogéneos: Algunas aplicaciones dependen de datos que se envían o se reciben de bases de datos distintas de SQL Server. Utilice la réplica para integrar datos de bases de datos que no sean de SQL Server.

Descargar procesos por lotes: Las operaciones por lotes consumen con frecuencia demasiados recursos para ejecutarse en un servidor OLTP. Utilice la réplica para descargar el procesamiento a un servidor de proceso por lotes dedicado.

Replicar Datos entre un Servidor y los Clientes Los datos normalmente se replican entre servidores y clientes para admitir las siguientes aplicaciones:

Intercambiar datos con usuarios móviles: Muchas aplicaciones requieren que los datos estén disponibles para usuarios remotos, como personal de ventas, repartidores, etc. Estas aplicaciones incluyen las de administración de relaciones con los clientes (CRM), automatización del personal de ventas (SFA) y automatización del personal de campo (FFA).

Aplicaciones de punto de venta (POS) para el consumidor: Las aplicaciones POS, como los terminales de caja de salida y los cajeros automáticos, requieren que los datos se repliquen desde sitios remotos a un sitio central.

Integrar datos de varios sitios: Las aplicaciones a menudo integran datos de varios sitios. Por ejemplo, una aplicación de apoyo a oficinas regionales puede requerir que los datos fluyan en una o en ambas direcciones entre las oficinas regionales y la oficina central.

Réplica Transaccional de Punto a Punto (Peer to Peer) La réplica transaccional de punto a punto está diseñada para aplicaciones que pueden leer o modificar los datos en cualquiera de las bases de datos que participan en la réplica. Por ejemplo, una aplicación para realizar compras por Internet es muy adecuada para la réplica de punto a punto: el rendimiento de la aplicación se puede mejorar distribuyendo entre varias bases de datos las consultas que leen los datos. Además, si alguno de los servidores que alojan las bases de datos no está disponible, se puede programar una aplicación para dirigir el tráfico a los otros servidores, que contienen copias idénticas de los datos. El rendimiento de

- 184 -

lectura mejora porque la actividad se puede repartir entre todos los nodos. El rendimiento acumulado de actualización, inserción y eliminación para la topología es similar al de un solo nodo, porque al final todos los cambios se propagan a todos los nodos. Todos los nodos de una topología de punto a punto son pares: cada nodo publica y suscribe al mismo esquema y los mismos datos. Los cambios (inserciones, actualizaciones y eliminaciones) pueden realizarse en todos los nodos. La réplica reconoce cuándo un cambio se ha aplicado a un nodo determinado, lo que evita cambios cíclicos en los nodos más de una vez. Nota: Las aplicaciones personalizadas que tienen acceso a los datos y los modifican deben asegurarse de que las inserciones, actualizaciones y eliminaciones tienen particiones, de forma que las modificaciones en una fila determinada con origen en un nodo se sincronicen con el resto de bases de datos de la topología antes de que la fila se modifique en otro nodo diferente. Si una aplicación ejecuta modificaciones simultáneas que producen conflictos en una fila determinada en varios nodos, utilice la réplica de mezcla que se adapta perfectamente para controlar conflictos. La réplica transaccional estándar supone suscriptores de sólo lectura y tiene una estructura jerárquica: normalmente un solo publicador publica datos para uno o varios suscriptores. La réplica transaccional estándar también admite una jerarquía de republicación: las actualizaciones se entregan desde un publicador a un conjunto de suscriptores de republicación, que a su vez entregan las actualizaciones a un conjunto final de suscriptores de nodo hoja. Las suscripciones de actualización ofrecen la posibilidad de que los suscriptores inserten cambios de nuevo en el publicador, pero la organización aún es jerárquica porque los cambios siguen la estructura jerárquica cuando se mueven entre los suscriptores y los publicadores. Al contrario que la réplica transaccional de sólo lectura y la réplica transaccional con suscripciones de actualización, las relaciones entre nodos en una topología de réplica de punto a punto son relaciones entre pares en vez de jerárquicas, donde cada nodo contiene un esquema y datos idénticos. Aunque las actualizaciones pueden realizarse donde participan varias bases de datos, es importante comprender que las topologías de punto a punto no necesitan ni permiten las opciones de publicación de actualización en cola o inmediata. Topologías de Punto a Punto En los siguientes escenarios se ilustran los usos típicos de la réplica de punto a punto. Topología en la que participan dos bases de datos:

- 185 -

En las ilustraciones anteriores se muestran dos bases de datos participantes, con tráfico de usuario dirigido a las bases de datos a través de un servidor de aplicaciones. Esta configuración se puede utilizar en varias aplicaciones, desde sitios Web hasta aplicaciones de grupos de trabajo, y proporciona las siguientes ventajas:

Rendimiento de lectura mejorado, porque las lecturas se reparten en dos servidores.

Alta disponibilidad si se requiere mantenimiento o en caso de error en un nodo. En ambas ilustraciones, la actividad de lectura tiene equilibrio de carga entre las bases de datos participantes, pero las actualizaciones se controlan de forma diferente:

A la izquierda, las actualizaciones se particionan entre los dos servidores; si la base de datos contiene un catálogo de productos, puede, por ejemplo, hacer que una aplicación personalizada dirija las actualizaciones al nodo "A" para los nombres de productos que empiecen con la letra A hasta la M y dirija las actualizaciones al nodo "B" para los nombres de productos que empiecen con la letra N hasta la Z. Más tarde, las actualizaciones se replican en el otro nodo.

A la derecha, todas las actualizaciones se dirigen al nodo "B". Desde ahí, las actualizaciones se replican en el nodo "A". Si "B" está desconectado (por ejemplo, por motivos de mantenimiento), el servidor de aplicaciones puede dirigir toda la actividad a "A". Cuando "B" vuelve a conectarse, las actualizaciones pueden pasar a él, y el servidor de aplicaciones puede mover todas las actualizaciones de vuelta al nodo "B" o seguir dirigiéndolas al nodo "A".

La réplica de punto a punto puede admitir este método, pero el ejemplo de actualización centralizada de la derecha también se utiliza frecuentemente con la réplica transaccional estándar.

Topología en la que participan tres o más bases de datos

- 186 -

En la ilustración anterior se muestran tres bases de datos participantes que proporcionan el sistema de una organización de soporte de software internacional, con oficinas en Los Ángeles, Londres y Taipei. Los ingenieros de soporte de cada oficina reciben llamadas de clientes e incluyen y actualizan la información de las llamadas de los clientes. Las zonas horarias de las tres oficinas tienen una diferencia de ocho horas, por lo que no se superponen en la jornada laboral: cuando la oficina de Taipei cierra, se abre la oficina de Londres. Si hay una llamada en curso cuando se cierra una oficina, la llamada se transfiere a un representante de la siguiente oficina abierta. Cada ubicación tiene una base de datos y un servidor de aplicaciones, que los ingenieros de soporte utilizan para incluir y actualizar la información de las llamadas de los clientes. La topología se particiona por tiempo, por lo que las actualizaciones sólo se producen en el nodo que está abierto; a continuación, las actualizaciones pasan al resto de bases de datos participantes. Esta topología proporciona las siguientes ventajas:

Independencia sin aislamiento: cada oficina puede insertar, actualizar o eliminar datos de forma independiente, pero también puede compartir los datos porque se replican en el resto de bases de datos participantes.

Alta disponibilidad en caso de error o para permitir el mantenimiento en cualquiera de las bases de datos participantes.

- 187 -

En la ilustración anterior se muestra la adición de un nodo a la topología de tres nodos. En este escenario se podría agregar un nodo:

Porque se abre otra oficina.

Para proporcionar alta disponibilidad al mantenimiento de soporte o aumentar la tolerancia a errores en caso de un error grave.

Observe que en las dos topologías de tres y cuatro nodos, todas las bases de datos publican y se suscriben en las otras bases de datos, lo que proporciona la máxima disponibilidad en caso de necesidades de mantenimiento o error en uno o varios nodos. Al agregar nodos, se deben equilibrar las necesidades de disponibilidad y escalabilidad respecto al rendimiento y la complejidad de implementación y administración.

Implementar la Réplica por Internet La réplica de datos por Internet permite a usuarios desconectados y remotos obtener acceso a los datos cuando los necesiten, por medio de una conexión a Internet. Puede llevar a cabo la réplica de datos por Internet mediante:

Una red virtual privada (VPN): La tecnología de Red privada virtual (VPN) permite a los usuarios que trabajan en su casa, oficinas subsidiarias, clientes remotos y otras empresas conectarse a una red corporativa por Internet, al tiempo que se mantiene una comunicación segura. Los usuarios pueden utilizar la Autenticación de Windows como si estuvieran en una red de área local (LAN). Todos los tipos de réplica de Microsoft SQL Server pueden replicar datos a través de una red privada virtual (VPN), pero se puede usar la sincronización Web si se está usando la réplica de mezcla, porque con la sincronización Web no es necesario usar una VPN.

Una VPN incluye el software cliente para que los equipos se conecten a través de Internet (o incluso en una Intranet, en casos especiales) al software de un equipo dedicado o servidor. Opcionalmente, se utiliza el cifrado en ambos extremos y métodos de autenticación de usuario. La conexión VPN a través de Internet funciona lógicamente como un vínculo de red de área extensa (WAN) entre los sitios. Una VPN conecta los componentes de una red por medio de otra red. Para la conexión, el usuario utiliza Internet u otra red pública mediante un protocolo como el Protocolo de túnel punto a punto (PPTP) de Microsoft o el Protocolo de túnel de capa 2. Este proceso garantiza la misma seguridad y características que anteriormente sólo estaban disponibles en una red privada. El protocolo PPTP está disponible con los sistemas operativos Microsoft Windows NT versión 4.0 y Microsoft Windows 2000 (y posteriores), y el protocolo L2TP, con Windows 2000 y posteriores.

- 188 -

El usuario no puede ver la infraestructura intermedia de enrutamiento de Internet y parece como si los datos se enviaran a través de un vínculo privado dedicado. Desde el punto de vista del usuario, una VPN es una conexión de punto a punto entre el equipo del usuario y un servidor corporativo. Después de configurar el cliente remoto para la conexión mediante VPN, y que el cliente disponga de acceso a Internet y se conecte a la LAN corporativa, podrá configurar la réplica como si el cliente remoto estuviera conectado directamente a la LAN. Por razones de seguridad, es posible disponer de recursos de red diferentes para los usuarios conectados a través de VPN y los conectados directamente a la LAN.

Sincronización Web de la réplica de mezcla: La sincronización Web para la réplica de mezcla permite replicar datos utilizando el protocolo HTTPS y es útil en los siguientes escenarios: o Sincronizar datos de usuarios móviles a través de Internet o Sincronizar datos entre bases de datos de Microsoft SQL Server a través de un

firewall corporativo Por ejemplo, un representante de ventas puede utilizar la sincronización Web durante sus viajes. El Agente de mezcla de cada equipo portátil tiene una dirección URL de Internet que apunta a los componentes de réplica instalados en un equipo en el que se ejecutan los Servicios de Microsoft Internet Information Server (IIS). Estos componentes sincronizan el suscriptor con el publicador. Ahora cada representante se puede conectar a través de cualquier conexión de Internet disponible sin utilizar una conexión remota de acceso telefónico y puede cargar y descargar los datos que desee. La conexión de Internet utiliza SSL (Capa de sockets seguros), por lo que no es necesaria una red privada virtual (VPN).

Todos los tipos de réplica de Microsoft SQL Server pueden replicar datos mediante una VPN, pero debe considerar la sincronización Web si utilizan la réplica de mezcla. Configurar la Sincronización Web Para utilizar la sincronización Web para la réplica, siga estos pasos:

Configure una publicación para que permita la sincronización Web. Si utiliza un publicador por primera vez, también debe configurar un distribuidor y un recurso compartido de instantáneas. El Agente de mezcla de cada suscriptor debe tener permisos de lectura en el recurso compartido de instantáneas.

Configure el equipo en el que se están ejecutando los Servicios de Microsoft Internet Information Server (IIS) para sincronizar suscripciones. Las versiones 5.0 y 6.0 de IIS son compatibles.

Para utilizar la sincronización Web, debe configurar IIS mediante los siguientes pasos: o Configure SSL (Capa de sockets seguros). SSL es necesario para establecer

comunicaciones entre IIS y todos los suscriptores. o Instale los componentes de conectividad de Microsoft SQL Server en el equipo en

el que se ejecuta IIS mediante el Asistente para la instalación de SQL Server. o Configure el equipo en el que se ejecuta IIS para la sincronización Web. Puede

configurar el equipo manualmente o usar el Asistente para configurar la sincronización Web. Se recomienda utilizar el asistente.

o Seleccione los permisos adecuados para la Escucha de réplica de SQL Server. o Ejecute la sincronización Web en modo de diagnóstico para probar la conexión con

el equipo en el que se ejecuta IIS y para asegurarse de que el certificado SSL está instalado correctamente.

Configure una o más suscripciones para utilizar la sincronización Web.

- 189 -

Módulo 7

Mantenimiento de Alta Disponibilidad

- 190 -

1- Introducción a Alta Disponibilidad Factores que afectan la Disponibilidad: La disponibilidad se ocupa de asegurar que las aplicaciones y servicios de una organización sigan funcionando ante una falla. Para implementar soluciones de alta disponibilidad usted debe analizar y comprender los diferentes tipos de fallas a los que está expuesto su sistema y planificar una estrategia de disponibilidad adecuada.

Fallas de Software: Una aplicación consistirá de muchos componentes de software, la mayoría de los cuales serán requeridos para el funcionamiento de la aplicación. Además de las aplicaciones de cliente y servidor, puede haber aplicaciones intermedias y de servidor Web. Los sistemas operativos en todos los nodos son cruciales para que una aplicación funcione debidamente, inclusive servicios y aplicaciones no relacionadas pueden causar fallas si utilizan demasiados recursos.

Fallas de Componentes de Hardware: Considere los efectos de la falla de cada componente de hardware en su sistema. Discos duros, procesadores, memoria y tarjetas de red pueden causar problemas particulares, pero otros componentes como ventiladores y fuentes de energía pueden ser igualmente esenciales para el correcto funcionamiento de su sistema.

Falla de Red: Una falla de red puede deberse a un cable defectuoso. Una red basada en TCP/IP utiliza Servidores Domain Naming System (DNS) y Dynamic Host Configuration Protocol (DHCP), así como routers y otros elementos. Todos ellos pueden fallar o tener problemas de configuración.

Falla de energía o desastre natural: Resulta relativamente sencillo proteger por períodos cortos contra estas fallas, pero hay eventos naturales que pueden afectar un sitio entero por largos períodos.

Configurar una Alta Disponibilidad Una solución de alta disponibilidad enmascara los efectos de un error de hardware o software y mantiene la disponibilidad de las aplicaciones a fin de minimizar el tiempo de inactividad que perciben los usuarios. SQL Server 2005 ofrece varias opciones para crear una alta disponibilidad para un servidor o una base de datos. Entre las opciones de alta disponibilidad figuran las siguientes:

Clúster de conmutación por error

Creación de reflejo de la base de datos

Trasvase de registros

Replicación Importante: Es fundamental disponer de una estrategia de copia de seguridad y restauración bien diseñada e implementada para utilizar una solución de alta disponibilidad. Cluster de conmutación por error Un cluster de conmutación proporciona alta disponibilidad a una instancia completa de SQL Server. Un cluster de conmutación por error es una combinación de uno o varios nodos, o servidores, con dos o más discos compartidos. Aplicaciones como SQL Server y Notification Services se instalan cada una en un grupo de clústeres de Servicios de Cluster Server de Microsoft (MSCS), conocido como grupo de recursos. En todo momento, cada grupo de recursos es propiedad de un único nodo del clúster. El servicio de aplicación tiene un nombre virtual que es independiente de los nombres del nodo y al que nos referimos como nombre de instancia de clúster de conmutación por error. Una aplicación puede conectarse con la

- 191 -

instancia de clúster de conmutación por error si hace referencia al nombre de la misma. La aplicación no necesita saber qué nodo aloja a la instancia de clúster de conmutación por error. Una instancia de clúster de conmutación por error de SQL Server aparece en la red como un equipo individual, pero ofrece funciones para la conmutación por error entre nodos si el nodo actual deja de estar disponible. Por ejemplo, durante un error de hardware no relacionado con el disco, un error del sistema operativo o una actualización planeada del mismo, puede configurar una instancia de SQL Server en un nodo de un clúster de conmutación por error para que conmute a cualquier otro nodo del grupo de discos. Un clúster de conmutación por error no implica protección ante errores de disco. Puede utilizar el clúster de conmutación por error para reducir el tiempo de inactividad del sistema y garantizar una mayor disponibilidad de la aplicación. El clúster de conmutación por error es compatible con SQL Server 2005 Enterprise Edition, Developer Edition y, con algunas restricciones, en la versión Standard Edition. Creación de reflejo de la base de datos La creación de reflejo de la base de datos es básicamente una solución de software para aumentar la disponibilidad de la base de datos mediante una conmutación por error casi inmediata. La creación de reflejo de la base de datos puede utilizarse para mantener una sola base de datos en estado de espera, o base de datos reflejada, para una base de datos de producción correspondiente a la que se conoce como base de datos principal. La base de datos reflejada se crea mediante la restauración (sin recuperación) de una copia de seguridad de la base de datos principal. Eso hace que los clientes no dispongan de acceso a la base de datos reflejada. Sin embargo, es posible utilizarla de forma indirecta para generar informes creando una instantánea de base de datos en la base de datos reflejada. La instantánea de la base de datos proporciona a los clientes acceso de sólo lectura a la información de la base de datos tal como existía al crearse la instantánea. Cada configuración de creación de reflejo de la base de datos incluye un servidor principal que contiene la base de datos principal y un servidor reflejado que contiene la base de datos reflejada. El servidor reflejado actualiza de forma constante la base de datos reflejada con relación a la base de datos principal. La creación de reflejo de la base de datos se ejecuta con una operación sincrónica en modo de alta seguridad o con una operación asincrónica en modo de alto rendimiento. En modo de alto rendimiento, las transacciones se confirman sin esperar a que el servidor reflejado escriba el registro en el disco, lo que maximiza el rendimiento. En modo de alta seguridad, una transacción confirmada se confirma en ambos asociados, pero a riesgo de aumentar la latencia de las transacciones. En la configuración más sencilla, la creación de reflejo de la base de datos sólo implica a los servidores principal y reflejado. En ésta configuración, si se pierde el servidor principal, el reflejado se puede utilizar como servidor en espera semiactiva, con posible pérdida de datos. El modo de alta seguridad admite una configuración alternativa: modo de alta seguridad con conmutación por error automática. Esta configuración implica a una tercera instancia de servidor, denominada testigo, que permite al servidor reflejado actuar como servidor en espera activa. La conmutación por error de la base de datos principal a la base de datos reflejada suele tardar unos segundos. La creación de reflejo de la base de datos es completamente compatible con SQL Server Standard Edition y Enterprise Edition, aunque los asociados de conmutación por error deben utilizar la misma edición. Las instancias de servidor que se ejecutan en SQL Server Workgroup Edition o Express Edition sólo son compatibles con la función de testigo. Trasvase de registros Al igual que la creación de reflejo de la base de datos, el trasvase de registros se aplica en la base de datos. El trasvase de registros puede utilizarse para mantener una o más bases de datos en espera semiactiva, denominadas bases de datos secundarias, para una base de

- 192 -

datos de producción correspondiente conocida como base de datos primaria. Cada una de las bases de datos secundarias se crea al restaurar una copia de seguridad (sin recuperación) de la base de datos primaria, o en espera. La restauración con base de datos en espera permite que la base de datos secundaria resultante se utilice para la generación limitada de informes. La configuración del trasvase de registros incluye un único servidor primario que contiene la base de datos primaria, uno o varios servidores secundarios, cada uno con una base de datos secundaria, y un servidor de supervisión. Cada servidor secundario actualiza su base de datos secundaria a intervalos regulares a partir de las copias de seguridad del registro de la base de datos primaria. El trasvase de registros implica un retraso modificable por el usuario entre el momento en que el servidor primario crea una copia de seguridad del registro de la base de datos primaria y el momento en que el servidor secundario restaura la copia de seguridad del registro. Antes de que se pueda producir una conmutación por error, debe actualizarse totalmente una base de datos secundaria al aplicar manualmente las copias de seguridad del registro no restauradas. El trasvase de registros ofrece la flexibilidad de admitir varias bases de datos en espera. Si necesita varias bases de datos en espera, utilice el trasvase de registros por sí solo o como complemento a la creación de reflejo de la base de datos. Al combinar estas soluciones, la base de datos primaria actual de la configuración de la creación de reflejo de la base de datos es también la base de datos primaria actual de la configuración del trasvase de registros. El trasvase de registros es compatible con SQL Server 2005 Enterprise Edition, Standard Edition y Workgroup Edition. Replicación La réplica utiliza un modelo de publicación y suscripción, lo que permite que un servidor primario, conocido como publicador, distribuya datos a uno o varios servidores secundarios o suscriptores. Gracias a la réplica se puede obtener una disponibilidad y escalabilidad en tiempo real entre tales servidores. Esta solución admite el filtrado para obtener un subconjunto de datos de los Suscriptores, así como las actualizaciones con particiones. Los suscriptores están conectados y disponibles para la generación de informes y otras funciones, sin recuperación de consultas. SQL Server ofrece tres tipos de réplica: réplica de instantáneas, réplica transaccional y réplica de mezcla. La réplica transaccional proporciona la latencia más baja y es la que más se suele utilizar por su alta disponibilidad. La réplica es compatible con todas las ediciones de SQL Server 2005. La publicación de réplicas no está disponible en SQL Server 2005 Express Edition ni en SQL Server Compact Edition. Seleccionar una Solución de Alta Disponibilidad En la siguiente lista figuran algunas consideraciones que deben tenerse en cuenta para elegir una solución de alta disponibilidad. El cluster de conmutación por error y la creación de reflejo de la base de datos ofrecen:

Detección y conmutación por error automáticas

Conmutación por error manual

Redireccionamiento de clientes transparente

El cluster de conmutación por error presenta las siguientes restricciones:

Funciona en el ámbito de la instancia de servidor

Exige hardware certificado

No permite la generación de informes en espera

Utiliza una sola copia de la base de datos

No protege frente a errores de disco

- 193 -

La creación de reflejo de la base de datos ofrece las siguientes ventajas:

Se aplica en la base de datos

Utiliza una sola copia duplicada de la base de datos. En caso de necesitarse más copias, puede utilizar la solución de trasvase de registros en la base de datos además de la creación de reflejo de la base de datos.

Utiliza servidores estándar

Proporciona una capacidad de generación de informes limitada en el servidor reflejado mediante instantáneas de base de datos

Cuando funciona de forma sincrónica, garantiza una pérdida de datos cero gracias a la confirmación retardada de la base de datos principal

La creación de reflejo de la base de datos supone un aumento considerable de la disponibilidad con relación al nivel que se conseguía anteriormente con SQL Server y constituye una alternativa fácil de administrar al clúster de conmutación por error. El trasvase de registros puede ser un complemento o una alternativa a la creación de reflejo de la base de datos. Aunque son similares conceptualmente, la creación de reflejo de la base de datos asincrónica y el trasvase de registros tienen diferencias importantes. El trasvase de registros ofrece las siguientes capacidades distintivas:

Admite varias bases de datos secundarias en varias instancias de servidor para una base de datos principal única.

Permite un retraso especificado por el usuario entre el momento en que el servidor primario realiza una copia de seguridad del registro de la base de datos primaria y el momento en que los servidores secundarios deben restaurar la copia de seguridad del registro. 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 el cambio accidental rápidamente, un retraso puede permitirle recuperar datos aún sin modificar de una base de datos secundaria antes de que el cambio se refleje en ella.

Si se compara con el tiempo más breve necesario para que el trasvase de registros refleje un cambio en una base de datos secundaria, la creación de reflejo de la base de datos asincrónica tiene la ventaja potencial de un tiempo menor entre el momento en que se realiza un cambio determinado en la base de datos primaria y el momento en que dicho cambio surte efecto en la base de datos reflejada. Una ventaja de la creación de reflejo de la base de datos respecto al trasvase de registros es que el modo de alta seguridad es una configuración "sin pérdida de datos" compatible como estrategia de conmutación por error simple. La replicación ofrece las siguientes ventajas:

Permite el filtrado en la base de datos para obtener un subconjunto de datos en las bases de datos secundarias, dado que funciona en el ámbito de la base de datos.

Permite más de una copia redundante de la base de datos.

Permite la disponibilidad y escalabilidad en tiempo real entre varias bases de datos, además de admitir las actualizaciones con particiones.

Asegura una disponibilidad completa de las bases de datos secundarias para las opciones de informes entre otras, sin recuperación de consultas.

- 194 -

2- Implementación de Server Clustering Que es un Cluster? Un clúster de conmutación proporciona alta disponibilidad a una instancia completa de SQL Server. Un clúster de conmutación por error es una combinación de uno o varios nodos, o servidores, con dos o más discos compartidos. Aplicaciones como SQL Server y Notification Services se instalan cada una en un grupo de clústeres de Servicios de Cluster Server de Microsoft (MSCS), conocido como grupo de recursos. En todo momento cada grupo de recursos es propiedad de un único nodo del clúster. El servicio de aplicación tiene un nombre virtual que es independiente de los nombres del nodo y al que nos referimos como nombre de instancia de clúster de conmutación por error. Una aplicación puede conectarse con la instancia de clúster de conmutación por error si hace referencia al nombre de la misma. La aplicación no necesita saber qué nodo aloja a la instancia de clúster de conmutación por error. Una instancia de clúster de conmutación por error de SQL Server aparece en la red como un equipo individual, pero ofrece funciones para la conmutación por error entre nodos, si el nodo actual deja de estar disponible. Por ejemplo, durante un error de hardware no relacionado con el disco, un error del sistema operativo o una actualización planeada del mismo, puede configurar una instancia de SQL Server en un nodo de un clúster de conmutación por error para que conmute a cualquier otro nodo del grupo de discos. Un clúster de conmutación por error no implica protección ante errores de disco. Puede utilizar el clúster de conmutación por error para reducir el tiempo de inactividad del sistema y garantizar una mayor disponibilidad de la aplicación. El clúster de conmutación por error es compatible con SQL Server 2005 Enterprise Edition, Developer Edition y, con algunas restricciones, en la versión Standard Edition.

Consideraciones antes de Instalar un Cluster de Conmutación por Error Antes de instalar un clúster de conmutación por error de SQL Server 2005, debe seleccionar el hardware y el sistema operativo en el que se ejecutará SQL Server 2005. También debe configurar el Servicio de Cluster Server de Microsoft (MSCS), así como revisar las consideraciones relativas a la red, la seguridad y el resto del software que se ejecutará en el clúster de conmutación por error.

- 195 -

Lista de comprobación previa a la instalación Antes de comenzar el proceso de instalación del clúster de conmutación por error, revise los siguientes elementos: Comprobar la Solución de Hardware

El sistema de hardware debe aparecer en la categoría de solución de clúster. La agrupación de componentes de clúster individuales no representa un sistema aprobado de clúster de conmutación por error. Sólo los sistemas adquiridos como solución de clúster y que se muestran en el grupo de clústeres están aprobados.

Es necesario comprobar especialmente la compatibilidad del hardware al implementar un clúster de servidor de conmutación por error en una red de área de almacenamiento (SAN). La solución de hardware completa debe encontrarse en la categoría Cluster/Multi-cluster Device (Dispositivo de clúster/varios clústeres) de Microsoft Windows Catalog (Catálogo de Microsoft Windows) y Windows Hardware Compatibility List (Lista de compatibilidad de hardware de Windows).

Si la solución de clúster incluye nodos de clúster geográficamente dispersos, deben comprobarse elementos adicionales como la latencia de red y la compatibilidad con discos compartidos. La solución completa debe figurar en la lista de compatibilidad de hardware de clústeres geográficos.

Las configuraciones de SAN también se admiten en Microsoft Windows 2000 Advanced Server y Datacenter Edition. El Catálogo de Windows y la lista de compatibilidad de hardware muestran el conjunto de dispositivos de almacenamiento habilitados para SAN que se admiten como unidades de almacenamiento de SAN con varios clústeres de MSCS adjuntos. Puede implementar un conjunto de clústeres y servidores de Windows en un tejido SAN y tener el soporte técnico de Microsoft. Puede hacerlo mediante la correspondencia de los dispositivos de esta lista con las configuraciones de clúster completas definidas en la categoría "clúster" del Catálogo de Microsoft Windows y la lista de compatibilidad de hardware de Windows.

Si implementa un clúster de conmutación por error de SQL Server 2005 en componentes de tecnología de interfaz para pequeños equipos de Internet (iSCSI), se recomienda hacerlo con precaución.

Considere la posibilidad de utilizar el uso compartido de recursos de disco de quórum. En un clúster de servidores, el disco de quórum contiene una copia maestra de la configuración del clúster de servidores. También como "desempate" si se produce un error en toda la comunicación de red entre los nodos del clúster. En función del tipo de clúster de servidores que se implemente, el disco de quórum puede ser o no un disco físico en la matriz de discos del clúster compartidos. Aunque es conveniente reservar un disco del clúster completo para su uso como disco de quórum, se puede permitir el acceso de los recursos distintos del recurso de quórum al disco de quórum. Sin embargo, al hacer que el recurso de quórum comparta el mismo disco con otros recursos, debe decidir entre dos alternativas no deseadas. Debe configurar el recurso para que un potencial error no afecte al grupo, o bien debe permitir que los errores de otros recursos afecten al grupo. En el primer caso, se pierde compatibilidad con la conmutación por error con el recurso; en el segundo, el recurso de quórum realiza la conmutación por error junto con el resto del grupo que contiene el recurso de quórum y el recurso con error. Como consecuencia, todo el clúster queda sin conexión durante el tiempo que el grupo tarde en realizar la conmutación por error.

Para instalar un clúster de conmutación por error de SQL Server 2005 cuando los archivos de instalación de origen y el clúster existen en diferentes dominios, copie los archivos de instalación en el nodo principal del clúster. A continuación, inicie la instalación del nodo principal.

- 196 -

Comprobar la Configuración del Sistema Operativo

Asegúrese de que el sistema operativo esté correctamente instalado y diseñado para admitir los clústeres de conmutación por error.

Habilite el Proveedor de servicios de cifrado de Windows (CSP) en Windows Server 2003. Si el servicio CSP se detiene o deshabilita en cualquier nodo del clúster, se produce un error en la instalación de SQL Server con un mensaje de error de requisito del logotipo de Windows.

Habilite el servicio Programador de tareas en todos los sistemas operativos para la instalación remota y de clúster. Si el Programador de tareas está deshabilitado, la instalación de SQL Server producirá el error 1058.

SQL Server 2005 admite puntos de montaje; las instalaciones en clúster de SQL Server están limitadas al número de letras de unidad disponibles. Si utiliza sólo una letra de unidad para el sistema operativo, se limita a un máximo de 25 instancias de SQL Server por cluster de conmutación por error.

Un volumen montado, o punto de montaje, le permite utilizar una sola letra de unidad para hacer referencia a muchos discos o volúmenes. Si tiene una letra de unidad D: para un disco o volumen normal, puede conectar o "montar" discos o volúmenes adicionales como directorios en la letra de unidad D: sin que dichos discos o volúmenes adicionales exijan letras de unidad propias.

Configurar el Servicio de Cluster Server de Microsoft

El Servicio de Cluster Server de Microsoft (MSCS) debe configurarse al menos en un nodo del clúster de servidores. MSCS sólo se admite si está instalado en una configuración de hardware cuya compatibilidad con el software MSCS haya sido comprobada. Además, debe ejecutar SQL Server 2005 Enterprise Edition o Standard Edition junto con MSCS. SQL Server 2005 Enterprise Edition admite clústeres de conmutación por error con un máximo de 8 nodos. SQL Server 2005 Standard Edition admite clústeres de conmutación por error con 2 nodos.

La DLL de recursos para el servicio SQL Server exporta dos funciones utilizadas por administrador de clústeres de MSC para comprobar disponibilidad del recurso SQL Server. Una comprobación simple, LooksAlive, consulta el estado del Administrador de control de servicios de Windows NT. Una comprobación más rigurosa, IsAlive, conecta a SQL Server como un sondeo del usuario para realizar una consulta simple. De forma predeterminada, LooksAlive se activa cada 5 segundos e IsAlive se activa cada 60 segundos. Los intervalos de sondeo de IsAlive y LooksAlive se pueden cambiar en el Administrador de clústeres de MSC en la ficha Avanzadas para el recurso SQL Server o utilizando el comando del símbolo del sistema cluster.exe.

MSCS debe poder comprobar que la instancia agrupada de conmutación por error está en ejecución mediante la comprobación IsAlive. Esto requiere conectar al servidor mediante una conexión de confianza. De forma predeterminada, la cuenta que ejecuta el servicio de clúster está configurada como administrador en todos los nodos del clúster y el grupo BUILTIN\Administradores tiene permiso para iniciar sesión en SQL Server. Esta configuración sólo cambia si se cambian los permisos en los nodos del clúster. Si quita la cuenta BUILTIN\Administradores, asegúrese de que la cuenta con la que se ejecutan los Servicios de Cluster Server puede iniciar una sesión en SQL Server para la comprobación de IsAlive. En caso contrario, se producirá un error en la comprobación de IsAlive. Como mínimo, la cuenta de los Servicios de Cluster Server (MSCS) debe tener privilegios public en SQL Server para poder ejecutar @@servername de modo regular.

- 197 -

Al instalar MSCS, es muy importante utilizar cuentas de servicio independientes para iniciar una sesión en MSCS y SQL Server. De lo contrario, la contraseña del servicio de clúster no se puede cambiar con el comando de clúster.

Cuando se utiliza MSCS, un nodo debe tener el control del bus SCSI compartido antes de conectar el otro nodo. Si no es así, la conmutación por error de aplicaciones puede entrar en un estado pendiente de conexión e impedir la conmutación por error al otro nodo o producir un error total. Si el sistema de clúster tiene un proceso de instalación propio, debe utilizarse.

Instalar el Coordinador de Transacciones Distribuidas de Microsoft Antes de instalar SQL Server 2005 en un clúster de conmutación por error, determine si debe crearse el recurso de clúster del Coordinador de Transacciones Distribuidas de Microsoft (MSDTC). Si sólo instala el Motor de base de datos, no será necesario el recurso de clúster de MSDTC. Si instala el Motor de base de datos y SSIS, Notification Services o componentes de la estación de trabajo, deberá instalar MSDTC. Este requisito se aplica a los sistemas operativos Windows 2000 y Windows Server 2003. Las herramientas administrativas Servicios de componentes, proxy de MSDTC y administrador de transacciones de MSDTC se instalan en cada nodo del clúster de servidores basados en Windows. El clúster utiliza los Servicios de Cluster Server de Microsoft (MSCS) como parte de la instalación del clúster de servidores basados en Windows. Tras instalar el sistema operativo y configurar el clúster, debe configurar MSDTC para que funcione en un clúster mediante el Administrador de clústeres. Si no logra crear el clúster de MSDTC, no se bloqueará el programa de instalación de SQL Server, pero la funcionalidad de la aplicación SQL Server puede verse afectada si MSDTC no se configura correctamente. Todos los procesos que se ejecuten en cualquier nodo del clúster pueden utilizar MSDTC. Estos procesos simplemente llaman al proxy de MSDTC y éste reenvía automáticamente las llamadas de MSDTC al administrador de transacciones de MSDTC, que controla todo el clúster. Si se produce un error en el nodo que ejecuta el administrador de transacciones de MSDTC, éste se reinicia automáticamente en otro nodo del clúster. El administrador de transacciones recién reiniciado lee el archivo de registro de MSDTC en el disco del clúster compartido para determinar el resultado de las transacciones pendientes y recién completadas. Los administradores de recursos se vuelven a conectar al administrador de transacciones y realizan la recuperación para determinar el resultado de las transacciones pendientes. Las aplicaciones se vuelven a conectar a MSDTC para poder iniciar las nuevas transacciones. Por ejemplo, suponga que el administrador de transacciones de MSDTC está activo en el sistema B. El programa de aplicación y el administrador de recursos del sistema A llaman al proxy de MSDTC. El proxy de MSDTC del sistema A reenvía todas las llamadas de MSDTC al administrador de transacciones de MSDTC del sistema B. Si se produce un error en el sistema B, el administrador de transacciones de MSDTC del sistema A tomará el control. Leerá todo el archivo de registro de MSDTC en el disco del clúster compartido, realizará la recuperación y, a continuación, actuará como administrador de transacciones de todo el clúster. Otras Consideraciones de Software

Asegúrese de que todos los nodos del cluster están configurados de forma idéntica, lo que incluye COM+, letras de unidad de disco y usuarios del grupo de administradores.

Compruebe que la interconexión del clúster (latido) está configurada correctamente.

Compruebe que ha borrado los registros del sistema en todos los nodos y ha consultado de nuevo los registros del sistema. Antes de continuar, asegúrese de que los registros no contienen mensajes de error.

- 198 -

Para instalaciones de SQL Server 2005 en configuraciones simultáneas con versiones anteriores de SQL Server, los servicios de SQL Server 2005 deben usar cuentas que sólo se encuentran en el grupo de dominio global. Además, las cuentas utilizadas por los servicios de SQL Server 2005 no deben aparecer en el grupo local de administradores. Si no se sigue ésta directriz, se producirán comportamientos inesperados con respecto a la seguridad.

Si instala SQL Server 2005 en un grupo de clúster de Windows 2000 con varias unidades de disco y decide colocar los datos en una de las unidades, el recurso de SQL Server se configura para que sólo dependa de dicha unidad. Para colocar datos o registros en recursos de disco adicionales, primero debe agregar una dependencia al recurso de SQL Server para el disco adicional.

Para utilizar el cifrado, instale el certificado del servidor con el nombre DNS completo del clúster MSCS en todos los nodos del clúster de conmutación por error de SQL Server. Por ejemplo, si tiene un clúster con dos nodos cuyos nombres son "Test1.DomainName.com" y "Test2.DomainName.com" y una instancia de clúster de conmutación por error de SQL Server denominada "Virtsql", debe obtener un certificado para "Virtsql.DomainName.com" e instalarlo en los nodos test1 y test2. A continuación, puede activar la casilla de verificación Forzar cifrado de protocolo en el Administrador de configuración de SQL Server para configurar el clúster de conmutación por error para el cifrado.

Importante: No active la casilla de verificación Forzar cifrado de protocolo hasta que haya instalado certificados en todos los nodos participantes de la instancia de clúster de conmutación por error.

Compruebe que no tiene instalado software antivirus en el clúster MSCS.

SQL Server 2005 no se admite en Terminal Server de Windows Server 2003.

Compruebe que el disco en el que se instalará SQL Server no está comprimido. Si intenta instalar SQL Server en una unidad comprimida, se producirá un error en la instalación de SQL Server.

Compruebe también que los nombres del grupo de clústeres existentes no contienen caracteres no compatibles. Cuando asigne nombre a un grupo de clústeres de la instalación de clúster de conmutación por error, no debe utilizar ninguno de los caracteres siguientes: o Operador menor que (<) o Operador mayor que (>) o Comillas dobles (") o Comillas simples (') o Símbolo de "y" comercial (&)

Consideraciones Relativas a la Red Antes de iniciar el programa de instalación de SQL Server, compruebe que ha desactivado NetBIOS para todas las tarjetas de red privada. El nombre de red y la dirección IP del servidor SQL Server no deben utilizarse para ningún otro fin, por ejemplo el uso compartido de archivos. Si desea crear un recurso compartido de archivos, utilice un nombre de red y una dirección IP diferentes y únicos para el recurso. Importante: Microsoft recomienda no utilizar recursos compartidos de archivos en unidades de datos, ya que pueden afectar al comportamiento y el rendimiento de SQL Server. Aunque SQL Server 2005 admite canalizaciones con nombre y Sockets TCP/IP sobre TCP/IP en un clúster, Microsoft recomienda utilizar Sockets TCP/IP en una configuración de clúster. Otras Consideraciones

- 199 -

Para crear un clúster de conmutación por error, debe ser un administrador local con permisos para iniciar una sesión como servicio y para actuar como parte del sistema operativo en todos los nodos de la instancia de clúster de conmutación por error.

Antes de instalar o actualizar un clúster de conmutación por error de SQL Server, deshabilite todas las aplicaciones y servicios que podrían utilizar componentes de SQL Server durante la instalación, pero mantenga los recursos de disco en línea.

Cree grupos de dominios para los servicios en clúster que se instalarán como parte de su clúster de conmutación por error de SQL Server 2005. El servicio SQL Server, el servicio del agente SQL Server, el servicio Analysis Services y el servicio Búsqueda de texto deben ejecutarse como cuentas de dominio que son miembros del grupo de dominios global o local. Si es necesario, pregunte al administrador del dominio los nombres de los grupos de dominio existentes, o bien pídale que cree los grupos de dominio para su clúster de conmutación por error.

Los clústeres de conmutación por error de SQL Server no se admiten en el caso en que los nodos del clúster son controladores de dominio.

Configure el Servicio de nombres de dominio (DNS) o el Servicio de nombres Internet de Windows (WINS). En el entorno donde se va a instalar el clúster de conmutación por error de SQL Server debe estar ejecutándose un servidor DNS o WINS. El programa de instalación de SQL Server requiere el registro DDNS (servicio de nombres de dominio dinámicos) de la referencia virtual de la interfaz IP de SQL Server. Si no se puede llevar a cabo el registro dinámico, se produce un error en el programa de instalación y ésta se revierte. Si no está disponible el registro dinámico, debe haber registrado previamente el servidor en DNS.

Revise el contenido de Consideraciones de seguridad para una instalación de SQL Server.

Revise el contenido de Comprobar los parámetros del Comprobador de configuración del sistema.

Compruebe si las herramientas, características y componentes de SQL Server que desea usar son compatibles con el clúster de conmutación por error.

Considere cómo supervisará y mantendrá el clúster de conmutación por error para lograr los objetivos de alta disponibilidad.

Para reducir el tiempo necesario para instalar un clúster de conmutación por error de SQL Server 2005, puede preinstalar Microsoft .NET Framework versión 2.0 en todos los nodos de clúster de conmutación por error antes de ejecutar el programa de instalación de SQL Server.

Instalar un Custer de Conmutación por Error Para instalar un clúster de conmutación por error de Microsoft SQL Server 2005, debe crear y configurar una instancia de clúster de conmutación por error mediante la ejecución del programa de instalación de SQL Server. Elementos de una instancia de clúster de conmutación por error

Una instancia de clúster de conmutación por error puede ejecutarse en uno o varios equipos que sean nodos participantes de un clúster de conmutación por error. Sólo el sistema operativo puede limitar el número de nodos participantes.

Una instancia de clúster de conmutación por error contiene:

Una combinación de uno o más discos en un grupo de clústeres de Servicios de Cluster Server de Microsoft (MSCS), conocido también como grupo de recursos. Cada grupo de recursos puede contener una instancia de SQL Server como máximo.

Un nombre de red para la instancia de clúster de conmutación por error.

Una o más direcciones IP asignadas a la instancia de clúster de conmutación por error.

- 200 -

Una instancia de SQL Server 2005 que incluya SQL Server, el Agente SQL Server y el servicio de búsqueda de texto (FTS).

Asignar nombre a una Instancia de Cluster de Conmutación por Error Una instancia de cluster de conmutación por error de SQL Server siempre aparece en la red como si se tratara de un solo equipo. Debe utilizar el nombre de la instancia de clúster de conmutación por error de SQL Server para conectarse al clúster de conmutación por error de SQL Server, no el nombre del equipo del nodo en el que se está ejecutando. De este modo se garantiza que siempre se pueda conectar a la instancia de clúster de conmutación por error mediante el mismo nombre, sea cual sea el nodo en el que se ejecute SQL Server. El nombre de la instancia de clúster de conmutación por error debe ser único en el dominio. SQL Server no escucha en la dirección IP de los servidores locales. En realidad, SQL Server sólo escucha en la dirección IP virtual creada durante la instalación de la instancia de clúster de conmutación por error de SQL Server. SQL Server depende de claves del Registro y nombres de servicio diferenciados dentro del clúster de conmutación por error para garantizar que SQL Server siga funcionando tras una conmutación por error. Por tanto, el nombre que proporcione a la instancia de SQL Server, incluida la instancia predeterminada, debe ser único en todos los nodos del clúster de conmutación por error. El uso de nombres de instancia únicos garantiza que las instancias de SQL Server configuradas para realizar la conmutación por error en un solo servidor tengan claves del Registro y nombres de servicio diferenciados. Tenga en cuenta que la limitación de discos detectada en versiones anteriores de SQL Server no afecta a SQL Server 2005. Gracias a la compatibilidad con las unidades montadas en SQL Server 2005, cada instancia de SQL Server sólo necesita un disco de clúster para los archivos de datos.

- 201 -

3- Implementando Reflejo de Base de Datos Generalidades de la Creación de Reflejo de la Base de Datos La creación de reflejo de la base de datos es una solución de software usada principalmente para aumentar la disponibilidad de una base de datos. La creación de reflejo se implementa en cada una de las bases de datos y sólo funciona con las que utilizan el modelo de recuperación completa. Los modelos de recuperación simple y por medio de registros de operaciones masivas no admiten la creación de reflejo de la base de datos. Por lo tanto, todas las operaciones masivas se registran siempre por completo. La creación de reflejo de una base de datos funciona con cualquier nivel de compatibilidad con bases de datos. Nota: No es posible reflejar las bases de datos master, msdb, tempdb o model. La creación de reflejo de la base de datos mantiene dos copias de una sola base de datos que debe residir en diferentes instancias del Motor de base de datos de SQL Server (instancias de servidor). Generalmente, estas instancias de servidor residen en equipos de diferentes ubicaciones. Una instancia de servidor da servicio a la base de datos para los clientes (el servidor principal), mientras la otra actúa como un servidor en espera semiactiva o activa (el servidor reflejado), en función de la configuración y el estado de la sesión de creación de reflejo. Cuando una sesión de creación de reflejo de la base de datos está sincronizada, la creación de reflejo de la base de datos proporciona un servidor en espera activa que admite la conmutación por error rápida sin que se produzca ninguna pérdida de datos derivada de las transacciones confirmadas. Cuando la sesión no está sincronizada, el servidor reflejado suele estar disponible como servidor en espera semiactiva (con posible pérdida de datos). Ventajas de la creación de reflejo de la base de datos La creación de reflejo de la base de datos es una estrategia sencilla que ofrece las siguientes ventajas:

Aumenta la protección de los datos.

La creación de reflejo de la base de datos proporciona una redundancia completa o casi completa de los datos, en función de si el modo de funcionamiento es el de alta seguridad o el de alto rendimiento.

Incrementa la disponibilidad de una base de datos.

Si se produce un desastre en el modo de alta seguridad con conmutación por error automática, la conmutación por error pone en conexión rápidamente la copia en espera de la base de datos, sin pérdida de datos. En los demás modos operativos, el administrador de bases de datos tiene la alternativa del servicio forzado (con una posible pérdida de datos) para la copia en espera de la base de datos.

Mejora la disponibilidad de la base de datos de producción durante las actualizaciones.

Para minimizar el tiempo de inactividad de una base de datos reflejada, puede actualizar secuencialmente las instancias de SQL Server que participan en una sesión de reflejo de la base de datos, incurriendo sólo en el tiempo de inactividad de una única conmutación por error. Este formulario de actualización se conoce como actualización sucesiva.

Funcionamiento de la creación de reflejo de la base de datos Los dos servidores, principal y reflejado, se comunican y colaboran como asociados en una sesión de creación de reflejo de la base de datos. Los dos asociados realizan funciones complementarias en la sesión: la función principal y la función de reflejo. En cada momento, un asociado realiza la función principal y el otro realiza la función de reflejo. Cada asociado se

- 202 -

describe como poseedor de su función actual. El asociado que posee la función principal se denomina servidor principal y su copia de la base de datos es la base de datos principal actual. El asociado que posee la función de reflejo se denomina servidor reflejado y su copia de la base de datos es la base de datos reflejada actual. Cuando se implementa la creación de reflejo de la base de datos en un entorno de producción, la base de datos principal es la base de datos de producción. La creación de reflejo de la base de datos implica rehacer cada operación de inserción, actualización y eliminación que ocurre desde la base de datos principal a la base de datos reflejada tan pronto como sea posible. Para rehacer estas operaciones se envía cada entrada del registro de transacciones activo al servidor reflejado que, en secuencia, aplica las entradas del registro a la base de datos reflejada lo más rápido posible. A diferencia de la réplica, que trabaja en el nivel lógico, la creación de reflejo de la base de datos trabaja en el registro físico. Modos de funcionamiento Una sesión de creación de reflejo de la base de datos se ejecuta en modo sincrónico o asincrónico. Con el funcionamiento asincrónico, las transacciones se confirman sin esperar a que el servidor reflejado escriba el registro en el disco, lo que maximiza el rendimiento. Con el funcionamiento sincrónico, una transacción confirmada se confirma en ambos asociados, pero a costa de aumentar la latencia de las transacciones. Existen dos modos de funcionamiento de la creación de reflejo:

Modo de Alta Seguridad: Admite el funcionamiento sincrónico. En el modo de alta seguridad, cuando se inicia una sesión, el servidor reflejado sincroniza la base de datos reflejada con la base de datos principal lo más rápido posible. Una vez sincronizadas las bases de datos, una transacción confirmada se confirma en ambos asociados, pero a costa de aumentar la latencia de las transacciones.

Modo de Alto Rendimiento: Se ejecuta de forma asincrónica. El servidor reflejado intenta hacer frente a las entradas de registro enviadas por el servidor principal. La base de datos reflejada podría ir un poco retrasada con respecto a la base de datos principal; sin embargo, el espacio entre las bases de datos suele ser pequeño. No obstante, la diferencia puede ser considerable si el servidor principal soporta una gran carga de trabajo o el sistema del servidor reflejado se encuentra sobrecargado.

En el modo de alto rendimiento, en cuanto el servidor principal envía una entrada de registro al servidor reflejado, el servidor principal envía una confirmación al cliente, sin esperar una confirmación del servidor reflejado. Esto significa que las transacciones se confirman sin esperar a que el servidor reflejado escriba el registro en el disco. Este funcionamiento asincrónico permite que el servidor principal se ejecute con la mínima latencia de transacciones, pero a riesgo de una pérdida potencial de datos. Todas las sesiones de creación de reflejo de la base de datos sólo admiten un servidor principal y un servidor reflejado. En la siguiente ilustración se muestra esta configuración.

- 203 -

El modo de alta seguridad con conmutación automática por error requiere una tercera instancia de servidor denominada testigo. A diferencia de los dos asociados, el testigo no sirve a la base de datos. El testigo admite la conmutación automática por error al comprobar que el servidor principal se encuentre activo y en funcionamiento. El servidor reflejado inicia la conmutación automática por error sólo si éste y el testigo permanecen mutuamente conectados después de haberse desconectado del servidor principal. En la siguiente ilustración se muestra una configuración que incluye un testigo.

Seguridad de las Transacciones y Modos de Funcionamiento Que el modo operativo sea asincrónico o sincrónico depende de la configuración de seguridad de las transacciones. Si utiliza exclusivamente SQL Server Management Studio para configurar la creación de reflejo de la base de datos, la configuración de seguridad de las transacciones se realiza automáticamente cuando selecciona el modo operativo. Si utiliza Transact-SQL para configurar la creación de reflejo de la base de datos, deberá comprender cómo establecer la seguridad de las transacciones. El control de la seguridad de

- 204 -

las transacciones está a cargo de la propiedad SAFETY de la instrucción ALTER DATABASE. En la base de datos que se va a reflejar, la opción SAFETY se establece en FULL o en OFF. Si la opción SAFETY se establece en FULL, la operación de creación de reflejo de la base de datos es sincrónica, tras la fase inicial de sincronización. Si un testigo se establece en el modo de alta seguridad, la sesión admite la conmutación automática por error. Si la opción SAFETY se establece en OFF, la operación de creación de reflejo de la base de datos es asincrónica. La sesión se ejecuta en modo de alto rendimiento y la opción WITNESS también debe establecerse en OFF. Extremo de Creación de Reflejo de Base de Datos La administración de conexiones en Microsoft SQL Server 2005 se basa en extremos. Un extremo es un objeto de SQL Server que permite a SQL Server comunicarse por la red. En la creación de un reflejo de una base de datos, una instancia de servidor requiere su propio extremo de creación de reflejo de la base de datos dedicado. Todas las conexiones de creación de reflejo en una instancia de servidor utilizan un único extremo de reflejo de la base de datos. Se trata de un extremo especial que se utiliza exclusivamente para recibir conexiones de creación de reflejo de la base de datos procedentes de otras instancias de servidor. Nota: Las conexiones de cliente al servidor principal no usan el extremo de creación de reflejo de la base de datos. Los extremos de creación de reflejo de la base de datos utilizan el Protocolo de control de transporte (TCP, Transmission Control Protocol) para enviar y recibir mensajes entre instancias de servidor en sesiones de creación de reflejo de la base de datos. Cada extremo de creación de reflejo de la base de datos se escucha en un número de puerto TCP diferente. El extremo de creación de reflejo de la base de datos de una instancia de servidor controla el puerto en el que dicha instancia escucha los mensajes de creación de reflejo de la base de datos de otras instancias de servidor. Cómo Crear un Extremo de Reflejo para la Autenticación de Windows Cada instancia de servidor de creación de reflejo de base de datos requiere un puerto de escucha único asignado al extremo de creación de reflejo de base de datos de la instancia. Una instancia de servidor sólo puede tener un extremo de creación de reflejo de base de datos, que tiene un puerto único. Un extremo de creación de reflejo de base de datos puede utilizar cualquier puerto disponible en el sistema local cuando se crea el extremo. Todas las sesiones de creación de reflejo de base de datos de una instancia de servidor escuchan en dicho puerto y todas las conexiones entrantes para la creación de reflejo de base de datos utilizan dicho puerto. Roles de servidor Los argumentos que aparecen a continuación son específicos de la opción DATABASE_MIRRORING. ROLE = { WITNESS | PARTNER | ALL } Especifica la función o funciones de creación de reflejo de la base de datos que admite el extremo. Argumentos:

WITNESS: Permite al extremo realizar la función de un testigo en el proceso de creación del reflejo.

- 205 -

Nota: Para SQL Server 2005 Express Edition, WITNESS es la única opción disponible.

PARTNER: Permite al extremo realizar la función de un asociado en el proceso de creación del reflejo.

ALL: Permite al extremo realizar la función de un testigo y un asociado en el proceso de creación del reflejo.

Para Crear un Extremo de Reflejo utilizando la Autenticación de Windows

Conecte con la instancia del servidor para la que desea crear un extremo de reflejo de la base de datos.

Determine si ya existe un extremo de reflejo de la base de datos utilizando la siguiente instrucción:

SELECT name, role_desc, state_desc FROM sys.database_mirroring_endpoints Importante: Si ya existe un extremo de reflejo para la instancia del servidor, utilice ese extremo para todas las otras sesiones que establezca en la instancia del servidor.

Para usar Transact-SQL para crear un extremo que se utilice con la autenticación de Windows, utilice la instrucción CREATE ENDPOINT. La instrucción toma la siguiente forma general:

CREATE ENDPOINT <Nombre_endpoint> STATE=STARTED AS TCP ( LISTENER_PORT = <Lista_Puertos_Escucha> ) FOR DATABASE_MIRRORING ( [ AUTHENTICATION = WINDOWS [ <Metodo_Autorización> ] ] [ [,] ENCRYPTION = REQUIRED [ ALGORITHM { <algoritmo> } ] ] [,] ROLE = <rol> ) Argumentos:

<Nombre_endpoint>: Es un nombre exclusivo para el extremo de reflejo de la base de datos de la instancia del servidor.

STARTED: Especifica que el extremo debe iniciarse y que debe empezar a escuchar las conexiones. Un extremo de reflejo de base de datos normalmente se crea en el estado STARTED. Opcionalmente, puede iniciar una sesión en el estado STOPPED (valor predeterminado) o DISABLED.

<Lista_Puertos_Escucha>: Es un número de puerto único en el que desea que el servidor escuche los mensajes de creación de reflejo de base de datos. Sólo se permite TCP; si se especifica cualquier otro protocolo se provoca un error. Un número de puerto sólo se puede usar una vez por sistema. Un extremo de creación de reflejo de base de datos puede utilizar cualquier puerto disponible en el sistema local cuando se crea el extremo. Para identificar los puertos que están usando los extremos TCP del sistema, utilice la siguiente instrucción Transact-SQL:

SELECT name, port FROM sys.tcp_endpoints Importante: Cada instancia del servidor requiere sólo un puerto de escucha único.

AUTHENTICATION: Para la autenticación de Windows es opcional, a menos que desee que el extremo utilice sólo NTLM o Kerberos para autenticar conexiones.

- 206 -

<Metodo_Autorización>: Especifica el método que se utiliza para autenticar conexiones como uno de los siguientes: NTLM, KERBEROS o NEGOTIATE. El valor predeterminado, NEGOTIATE, hace que el extremo utilice el protocolo de negociación de Windows para elegir NTLM o Kerberos. La negociación habilita conexiones con o sin autenticación, dependiendo del nivel de autenticación del extremo opuesto.

ENCRYPTION se establece en REQUIRED de forma predeterminada. Esto significa que todas las conexiones con este punto final deben usar cifrado. No obstante, puede deshabilitar el cifrado o hacer que sea opcional en un extremo. Las alternativas son las siguientes:

Valor Definición

DISABLED Especifica que los datos enviados en una conexión no están cifrados.

SUPPORTED Especifica que los datos están cifrados sólo si el extremo opuesto especifica SUPPORTED o REQUIRED.

REQUIRED Especifica que los datos enviados en una conexión deben estar cifrados.

<algoritmo>: Proporciona la opción de especificar estándares de cifrado para el extremo. El valor de <algoritmo> puede ser uno de los siguientes algoritmos o combinaciones de algoritmos: RC4, AES, AES RC4 o RC4 AES.

AES RC4 especifica que este extremo negociará el algoritmo de cifrado, dando preferencia al algoritmo AES. RC4 AES especifica que este extremo negociará el algoritmo de cifrado, dando preferencia al algoritmo RC4. Si ambos extremos especifican ambos algoritmos pero en órdenes diferentes, el extremo que acepta la conexión gana.

<rol>: Define la función o las funciones que el servidor puede llevar a cabo. Se tiene que especificar ROLE. Para permitir que una instancia de servidor sirva como una función para una sesión de reflejo de base de datos y una función diferente para otra sesión, especifique ROLE=ALL. Para hacer que la instancia de un servidor sólo sea un asociado o un testigo, especifique ROLE=PARTNER o ROLE=WITNESS, respectivamente.

Dirección de Red de Servidor La dirección de red de una instancia de servidor (su dirección de red de servidor) contiene el número de puerto de su extremo, así como el nombre de sistema y de dominio del equipo host. Dado que cada servidor cuenta con un extremo para la creación de reflejo distinto que utiliza un puerto exclusivo, el número de puerto identifica de forma exclusiva una instancia de servidor específica. Esto permite que varias instancias de servidor en un mismo servidor participen en la creación del reflejo de la base de datos (que sólo se suele realizar con fines de pruebas). En la siguiente ilustración se muestra cómo dos instancias de servidor en el mismo servidor se identifican de forma exclusiva. Las direcciones de red de las dos instancias de servidor contienen el mismo nombre de sistema, MYSYSTEM, y el mismo nombre de dominio, Adventure-Works.MyDomain.com. Para habilitar el sistema de forma que enrute conexiones a una instancia de servidor, una dirección de red de servidor incluye el número de puerto asociado al extremo para la creación de reflejo de una instancia de servidor en particular.

- 207 -

Sesiones de Creación de Reflejo de la Base de Datos La creación de reflejo de la base de datos se produce en el contexto de una sesión de creación de reflejo de la base de datos. Cuando la base de datos reflejada esté preparada y las instancias del servidor estén configuradas, el propietario de la base de datos podrá iniciar la creación de reflejo de la base de datos. En cuanto se inicia la creación de reflejo, cada asociado comienza a mantener información de estado en su base de datos sobre esa base de datos y sobre el otro asociado y el testigo, si existen. Esta información de estado permite que las instancias de servidor mantengan una relación conocida como sesión de creación de reflejo de la base de datos. Durante una sesión de creación de reflejo de una base de datos, las instancias de servidor se supervisan entre sí. La información de estado se mantiene hasta que el propietario de la base de datos detiene la sesión. Al inicio de una sesión de creación de reflejo de la base de datos, el servidor reflejado identifica el número de secuencia de registro (LSN) del último registro de transacciones aplicado en la base de datos reflejada y solicita al servidor principal el registro de transacciones de todas las transacciones posteriores, si las hay. En respuesta, el servidor principal envía al servidor reflejado las entradas del registro activo acumuladas desde el último registro restaurado en la base de datos reflejada o enviado al servidor reflejado. El registro sin enviar que se ha acumulado en el disco lógico de la base de datos principal se conoce como cola de envío. El servidor reflejado escribe inmediatamente el registro entrante en el disco, donde se mantiene hasta que se aplica a la base de datos reflejada. El registro que permanece en espera en el disco del reflejo se conoce como la cola rehecha. La parte del registro sin restaurar que espera

- 208 -

en la cola rehecha es un indicador del tiempo necesario para conmutar por error a la base de datos reflejada. El servidor principal continúa poniendo la base de datos principal a disposición de los clientes y de las conexiones de cliente. Tras el inicio de la creación de reflejo, cada vez que un cliente actualiza la base de datos principal, al escribir la transacción en el registro de la base de datos principal, el servidor principal también envía esa entrada del registro al servidor reflejado. Ahí, el servidor reflejado escribe inmediatamente la entrada del registro en el disco como la última entrada de la cola rehecha. En segundo plano, el servidor reflejado rehace el registro en la base de datos reflejada, entrada por entrada, empezando por la entrada del registro más antigua, tan pronto como sea posible. Al rehacer el registro, se aplican secuencialmente las entradas del registro en cola a la base de datos reflejada, comenzando por la entrada más antigua. Cada entrada del registro sólo se rehace una vez. A medida que el servidor reflejado rehace el registro, la base de datos reflejada se pone al día de forma continua. Si el servidor principal trunca o reduce el registro de la base de datos principal, el servidor reflejado también reduce el registro en el mismo punto de la secuencia. Generalmente, al rehacer el registro, la base de datos reflejada se pone inmediatamente al nivel de la base de datos principal. El modo operativo de la sesión determina si la base de datos reflejada alcanza totalmente el nivel de la base de datos principal. En el modo de alta seguridad sincrónico, el servidor principal espera para confirmar las transacciones nuevas hasta que se graban en el disco del registro del servidor reflejado. Cuando las entradas del registro acumuladas se han enviado al servidor reflejado, la base de datos reflejada se sincroniza con la principal. Durante una sesión, si el servidor principal no puede enviar todas las entradas del registro inmediatamente, las entradas del registro sin enviar se acumulan en la cola de envío. En el modo de alta seguridad sincrónico, después de la sincronización, las nuevas entradas del registro sin enviar se acumulan sólo cuando la creación del reflejo se pone en pausa o se suspende. Por el contrario, en el modo de alto rendimiento asincrónico, el registro sin enviar se acumula siempre que el servidor reflejado se retrasa durante la creación del reflejo, además de cuando el reflejo se pone en pausa o se suspende. La cantidad del registro sin enviar es un indicador de la posible pérdida de datos en el caso de que el servidor principal no funcione. Nota: Si se producen errores al rehacer, el servidor reflejado pausa la sesión poniendo la base de datos en el estado SUSPENDED. Para poder reanudar la sesión, el propietario de la base de datos debe resolver la causa del error. Sesiones Simultáneas Una determinada instancia de servidor puede participar en varias sesiones simultáneas de creación de reflejo de base de datos (una por cada base de datos reflejada) con la misma instancia o con instancias de servidor distintas. Con frecuencia, una instancia de servidor sirve exclusivamente como asociado o como testigo en todas las sesiones de creación de reflejo de la base de datos. Sin embargo, puesto que cada sesión depende de las demás, una instancia de servidor puede actuar como asociado en algunas sesiones y como testigo en otras. Por ejemplo, considere las siguientes cuatro sesiones entre tres instancias de servidor (SSInstance_1, SSInstance_2 y SSInstance_3). Cada estancia de servidor sirve como asociado en algunas sesiones y como testigo en otras:

Instancia de servidor

Sesión para la base de datos A

Sesión para la base de datos B

Sesión para la base de datos C

Sesión para la base de datos D

- 209 -

SSInstance_1 Testigo Asociado Asociado Asociado

SSInstance_2 Asociado Testigo Asociado Asociado

SSInstance_3 Asociado Asociado Testigo Testigo

En la siguiente ilustración se muestran dos instancias de servidor que participan como asociados en dos sesiones de creación de reflejo. Una sesión es para una base de datos llamada Db_1 y la otra sesión es para una base de datos llamada Db_2.

Cada una de las bases de datos es independiente de las demás. Por ejemplo, una instancia de servidor puede ser inicialmente el servidor reflejado de dos bases de datos. Si en una de esas bases de datos se produce una conmutación por error, la instancia de servidor se convierte en el servidor principal de la base de datos en la que se ha realizado la conmutación por error y, a la vez, sigue siendo el servidor reflejado de la otra base de datos. Requisitos Previos para una Sesión de Creación de Reflejo de la Base de Datos Para que pueda comenzar una sesión de creación de reflejo, el propietario de la base de datos o el administrador del sistema deben crear la base de datos reflejada, configurar los extremos e inicios de sesión, y en algunos casos, crear y configurar certificados. La creación de una base de datos reflejada requiere como mínimo que se realice una copia de seguridad completa de la base de datos principal y una siguiente copia de seguridad del registro, y que ambas se restauren en la instancia de servidor reflejado mediante WITH NORECOVERY. Además, antes de que pueda iniciar la creación de reflejo, si se realizan copias de seguridad del registro, adicionales posteriores a la copia de seguridad del registro requerida, también debe aplicar manualmente cada copia de seguridad del registro adicional (siempre usando WITH NORECOVERY). Tras aplicar la copia de seguridad del registro más reciente, puede iniciar la creación de reflejo.

- 210 -

Conmutación de Funciones durante una Sesión de Creación de Reflejo de la Base de Datos En el contexto de una sesión de creación de reflejo de la base de datos, las funciones principal y reflejo suelen ser intercambiables en un proceso conocido como conmutación de funciones. En la conmutación de funciones, el servidor reflejado actúa como el asociado de conmutación por error para el servidor principal al asumir la función principal, y al recuperar su copia de la base de datos y ponerla en conexión como la nueva base de datos principal. El servidor principal anterior, cuando esté disponible, asumirá la función reflejo y su base de datos se convertirá en la nueva base de datos reflejada. Potencialmente, las funciones pueden conmutarse como respuesta a varios errores o con fines administrativos. Hay tres tipos de conmutación de funciones: conmutación por error automática, conmutación por error manual y servicio forzado (con posible pérdida de datos). La compatibilidad con cada forma depende del modo operativo de la sesión. Conmutación por Error Manual El modo de alta seguridad admite la conmutación por error manual. Al sincronizar la base de datos, su propietario puede iniciar una conmutación por error manual. La conmutación por error manual se proporciona con fines administrativos. Para realizar manualmente una conmutación por error de la creación de reflejo de la base de datos (SQL Management Studio):

Conéctese a la instancia del servidor principal y, en el panel Explorador de objetos, haga clic en el nombre del servidor para expandir el árbol de servidores.

Expanda Bases de datos y seleccione la base de datos de la que se va a realizar la conmutación por error.

Haga clic con el botón secundario en la base de datos, seleccione Tareas y, a continuación, haga clic en Reflejado.

Se abre la página Creación de reflejo del cuadro de diálogo Propiedades de la base de datos.

Haga clic en Conmutación por error (Failover).

- 211 -

Para realizar una conmutación por error manual en una sesión de creación de reflejo de base de datos (Transac-SQL):

Conéctese al servidor principal.

Establezca el contexto de la base de datos en la base de datos master:

Emita la siguiente instrucción en el servidor principal: ALTER DATABASE nombre_basedatos SET PARTNER FAILOVER donde database_name es la base de datos reflejada. Esto inicia una transición inmediata del servidor reflejado hacia la función principal. En el principal antiguo, los clientes se desconectan de la base de datos y las transacciones en curso se revierten. Nota: Las transacciones que se han preparado mediante el Coordinador de Transacciones Distribuidas de Microsoft pero que aún no están confirmadas en el momento de la conmutación por error, se consideran anuladas tras la conmutación por error de la base de datos. Aparece un cuadro de confirmación. Si confirma que desea realizar una conmutación por error en la base de datos reflejada, la operación continúa y las funciones de servidor principal y

- 212 -

reflejado se intercambian. La base de datos reflejada se convierte en la base de datos principal, y la base de datos principal se convierte en la reflejada. Conmutación por Error Automática En presencia de un testigo, el modo de alta seguridad admite la conmutación por error automática. La conmutación por error automática sólo se produce con la pérdida del servidor principal cuando el testigo y el servidor reflejado siguen conectados entre sí y la base de datos ya está sincronizada. Forzar Servicio (con posible pérdida de datos) Se permite forzar el servicio en modo de alta seguridad si no hay ningún testigo definido y en modo de alto rendimiento. Al perderse el servidor principal, el propietario de la base de datos puede hacer que ésta esté disponible forzando el servicio en el servidor reflejado (con posible pérdida de datos). Para forzar el servicio en una sesión de creación de reflejo de la base de datos:

Conéctese al servidor reflejado.

Emita la instrucción siguiente: ALTER DATABASE <database_name> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS donde <database_name> es la base de datos reflejada. El servidor reflejado pasa inmediatamente al servidor principal y la creación del reflejo se suspende. En la siguiente tabla se resumen las formas de conmutación por error admitidas en cada uno de los modos operativos.

Alto

rendimiento Modo de alta seguridad sin

ningún testigo Modo de alta seguridad con

un testigo

Conmutación por error automática

No No Sí

Conmutación por error manual

No Sí Sí

Servicio forzado Sí Sí No

4- Trasvase de Registros (Log Shipping) Definición El trasvase de registros permite enviar automáticamente copias de seguridad del registro de transacciones desde una base de datos primaria de una instancia del servidor primario 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 copia de seguridad y restauración y, opcionalmente, se activan alertas si estas operaciones no se producen según lo programado.

- 213 -

Operaciones del 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 primario.

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 primario al servidor secundario. Si la base de datos primaria deja de estar disponible, cualquiera de las bases de datos secundarias se puede poner en conexión manualmente. Puede utilizar una base de datos secundaria para la generación de informes. Configurar el Trasvase de Registros El trasvase de registros puede configurarse utilizando SQL Server Management Studio o ejecutando manualmente una serie de procedimientos almacenados. Para la configuración del trasvase de registros es necesario realizar los siguientes pasos básicos:

Elegir el servidor primario, el servidor secundario y un servidor de supervisión opcional.

Crear un recurso compartido de archivos para las copias de seguridad del registro de transacciones, preferiblemente en un servidor tolerante a errores que no forme parte de la configuración del trasvase de registros. Para maximizar la disponibilidad del servidor primario, Microsoft recomienda ubicar el recurso compartido de copia de seguridad en un equipo host separado.

Elegir una programación de copia de seguridad para la base de datos primaria.

Crear una carpeta para cada servidor secundario en la que se copiarán los archivos de la copia de seguridad del registro de transacciones. Estas carpetas suelen residir en los servidores secundarios.

Configurar una o más bases de datos secundarias.

Opcionalmente, configurar un servidor de supervisión. Al configurar un servidor secundario para el trasvase de registros, puede elegir las siguientes opciones en el cuadro de diálogo Configuración de base de datos secundaria del trasvase de registros de Management Studio para configurar la base de datos secundaria:

Crear automáticamente una copia de seguridad en la base de datos primaria y restaurarla en el servidor secundario y, si es necesario, crear una base de datos secundaria.

Restaurar una copia de seguridad existente de la base de datos primaria en el servidor secundario y, si es necesario, crear la base de datos secundaria.

También puede inicializar la base de datos secundaria restaurando manualmente una copia de seguridad de la base de datos. Importante: La herramienta de trasvase de registros de Management Studio está diseñada sólo para hacer frente a casos simples de copia de seguridad y restauración. Para los casos más complejos, como las bases de datos con muchos archivos u opciones que no son las predeterminadas, debe realizar una copia de seguridad y restaurar toda la base de datos manualmente. Por lo general, utilice la copia de seguridad y restauración manuales para los casos que requieran un comando BACKUP o RESTORE complejo. Una vez que la base de

- 214 -

datos secundaria se ha restaurado, utilice la herramienta de trasvase de registros de Management Studio para finalizar la configuración del trasvase de registros. Cuando configure el servidor primario para el trasvase de registros, puede especificar la frecuencia con la que se crean las copias de seguridad del registro de transacciones en el servidor primario. Si el volumen de transacciones es alto, puede ser útil hacer una copia de seguridad frecuente del registro de transacciones para minimizar la pérdida potencial de datos. Cómo habilitar el trasvase de registros (SQL Server Management Studio):

Haga clic con el botón secundario en la base de datos que desea usar como base de datos primaria en la configuración del trasvase de registros y, a continuación, haga clic en Propiedades.

En Seleccionar una página, haga clic en Trasvase de registro de transacciones.

Active la casilla de verificación Habilitar ésta como base de datos primaria en una configuración de trasvase de registros.

En Copias de seguridad de registros de transacciones, haga clic en Configuración de copia de seguridad.

En el cuadro Ruta de red a esta carpeta de copia de seguridad, escriba la ruta de acceso de red al recurso compartido que creó para la carpeta de copias de seguridad de los registros de transacciones.

Si la carpeta de copias de seguridad se encuentra en el servidor primario, escriba la ruta de acceso local a la carpeta de copias de seguridad en el cuadro Si la carpeta de copia de seguridad está ubicada en el servidor primario, escriba una ruta local a la carpeta (si la carpeta de copias de seguridad no está situada en el servidor primario, puede dejar este cuadro vacío).

Importante: Si la cuenta de servicio de SQL Server en el servidor primario se ejecuta bajo una cuenta del sistema local, debe crear la carpeta de copias de seguridad en el servidor primario y especificar una ruta de acceso local a esa carpeta.

Configure los parámetros Eliminar archivos con más de y Mostrar una alerta si no se produce una copia de seguridad tras.

Tenga presente la programación de copia de seguridad que aparece en el cuadro Programación bajo Trabajo de copia de seguridad. Si desea personalizar la programación de su instalación, a continuación, haga clic en Programar y ajuste la programación del Agente SQL Server según sus necesidades.

Haga clic en Aceptar.

En Instancias de servidores secundarios y bases de datos, haga clic en Agregar.

Haga clic en Conectar y conéctese a la instancia de SQL Server que desea utilizar como servidor secundario.

En el cuadro Base de datos secundaria, elija una base de datos de la lista o escriba el nombre de la base de datos que desea crear.

En la ficha Inicializar base de datos secundaria, elija la opción que desea utilizar para inicializar la base de datos secundaria.

Nota: Si elige que Management Studio inicialice la base de datos secundaria desde la copia de seguridad de una base de datos, los archivos de datos creados en el servidor secundario tendrán los mismos nombres que los del servidor primario, y se creará una estructura de directorios idéntica, incluida la letra de la unidad.

En la ficha Copiar archivos, en el cuadro Carpeta de destino de los archivos copiados, escriba la ruta de acceso de la carpeta en la que deben copiarse las copias de seguridad de los registros de transacciones. Esta carpeta normalmente está situada en el servidor secundario.

Tenga presente la programación de copia que aparece en el cuadro Programación bajo Trabajo de copia. Si desea personalizar la programación de su instalación, haga clic en Programar y, a continuación, ajuste la programación del Agente SQL Server

- 215 -

según sus necesidades. Esta programación debe aproximarse a la programación de las copias de seguridad.

En la ficha Restaurar, en Estado de la base de datos al restaurar copias de seguridad, elija la opción Modo sin recuperación o Modo de espera.

Si elige la opción Modo de espera, seleccione si desea desconectar a los usuarios de la base de datos secundaria mientras se realiza la operación de restauración.

Si desea retrasar el proceso de restauración en el servidor secundario, elija un tiempo de retraso en Retrasar la restauración de las copias de seguridad al menos.

Elija un umbral de alerta en Mostrar una alerta si no se produce una restauración tras.

Tenga presente la programación de la restauración que aparece en el cuadro Programación bajo Trabajo de restauración. Si desea personalizar la programación de su instalación, haga clic en Programar y, a continuación, ajuste la programación del Agente SQL Server según sus necesidades. Esta programación debe aproximarse a la programación de las copias de seguridad.


En Instancia del servidor de supervisión, active la casilla de verificación Utilizar una instancia del servidor de supervisión y, a continuación, haga clic en Configuración.

Importante: Para supervisar esta configuración de trasvase de registros, debe agregar ahora el servidor de supervisión. Para agregar un servidor de supervisión más adelante, deberá quitar esta configuración de trasvase de registros y reemplazarla por una configuración nueva que incluya un servidor de supervisión.

Haga clic en Conectar y conéctese a la instancia de SQL Server que desea utilizar como servidor de supervisión.

En Supervisar conexiones, elija el método de conexión que utilizarán los trabajos de copia de seguridad, copia y restauración para conectarse al servidor de supervisión.

En Retención de historial, elija el período de tiempo que desea retener un registro del historial de trasvase de registros.


En el cuadro de diálogo Propiedades de la base de datos, haga clic en Aceptar para comenzar el proceso de configuración.

- 216 -

Cómo habilitar el trasvase de registros (Transact-SQL):

Inicialice la base de datos secundaria restaurando una copia de seguridad completa de la base de datos primaria en el servidor secundario.

En el servidor primario, ejecute sp_add_log_shipping_primary_database para agregar una base de datos primaria. El procedimiento almacenado devuelve el Id. de trabajo de la copia de seguridad y el Id. principal.

En el servidor primario, ejecute sp_add_jobschedule para agregar un esquema para el trabajo de copia de seguridad.

En el servidor de supervisión, ejecute sp_add_log_shipping_alert_job para agregar el trabajo de alerta.

En el servidor primario, habilite el trabajo de copia de seguridad.

En el servidor secundario, ejecute sp_add_log_shipping_secondary_primary proporcionando los detalles del servidor y la base de datos primarios. Este procedimiento almacenado devuelve el Id. secundario y los Id. de trabajo de copia y restauración.

En el servidor secundario, ejecute sp_add_jobschedule para establecer el esquema para los trabajos de copia y restauración.

En el servidor secundario, ejecute sp_add_log_shipping_secondary_database para agregar una base de datos secundaria.

- 217 -

En el servidor primario, ejecute sp_add_log_shipping_primary_secondary para agregar la información necesaria acerca de la nueva base de datos secundaria al servidor primario.

En el servidor secundario, habilite los trabajos de copia y restauración. Cambiar las funciones entre el servidor primario y secundario Después de haber realizado la conmutación por error al servidor secundario, puede configurar la base de datos secundaria para que actúe como base de datos primaria. De este modo, podrá intercambiar la base de datos primaria y la secundaria cuando sea necesario. La primera vez que desee conmutar por error a una base de datos secundaria para convertirla en su nueva base de datos primaria, debe realizar una serie de pasos. Una vez realizados, podrá intercambiar fácilmente las funciones entre la base de datos primaria y la base de datos secundaria. Realice manualmente la conmutación por error de la base de datos primaria a la secundaria. Asegúrese de realizar una copia de seguridad del registro de transacciones activo en su servidor primario mediante NORECOVERY. Deshabilite el trabajo de copia de seguridad de trasvase de registros en el servidor primario, así como los trabajos de copia y restauración en el servidor secundario original. En la base de datos secundaria (la que desea convertir en principal), configure el trasvase de registros mediante SQL Server Management Studio. Siga estos pasos:

Utilice el mismo recurso compartido para crear copias de seguridad que el utilizado para el servidor primario original.

Cuando agregue la base de datos secundaria, en el cuadro de diálogo Configuración de base de datos secundaria, escriba el nombre de la base de datos primaria original en el cuadro Base de datos secundaria.

En el cuadro de diálogo Configuración de base de datos secundaria, seleccione No, la base de datos secundaria está inicializada.

Una vez realizados los pasos anteriores para realizar el cambio inicial de funciones, ya puede cambiar las funciones entre la base de datos primaria y la secundaria. A tal efecto, siga los pasos descritos a continuación. Para realizar el cambio de una función, realice estos pasos generales:

Conecte la base de datos secundaria y realice una copia de seguridad del registro de transacciones en el servidor primario mediante NORECOVERY.

Deshabilite el trabajo de copia de seguridad de trasvase de registros en el servidor primario, así como los trabajos de copia y restauración en el servidor secundario original.

Habilite el trabajo de copia de seguridad de trasvase de registros en el servidor secundario (el nuevo servidor primario), así como los trabajos de copia y restauración en el servidor primario (el nuevo servidor secundario).

manual sqlserver2005 mantenimiento

Documents

configuracin de sql

copias de seguridad

servicios sql server

instancias de sql server

copia de seguridad diferencial

modelos de recuperacin

sql server management

recuperacin simple