Separata uni sql2008 administracion

Facultad de Ingeniería Industrial y de Sistemas
SQL Administración danielramoscastaneda@hotmail.com Pág. 1
C
CA
AP
PI
IT
TU
UL
LO
O 1
1
 Instalación y configuración del SQL Server 2008
 Ediciones del SQL Server 2008
 Requerimientos de Hardware y Software

Universidad Nacional de Ingeniería
Pág. 2 danielramoscastaneda@hotmail.com SQL Administración
I N S T A L A C I O N Y C O N F I G U R A C I O N D E L
S Q L S E R V E R 2 0 0 8
Una de las primeras responsabilidades que asume un DBA (Data Base Administrador),
es la elección del software más adecuado a las necesidades que presente la empresa.
Es por esta razón que, Microsoft corp., pone a nuestra disposición, de diferentes
ediciones de su “Sistema Administrador de Base de Datos” SQL Server 2008.
¿QUÉ ES SQL SERVER 2008?
SQL Server 2008 es una plataforma global de base de datos que ofrece administración
de datos empresariales con herramientas integradas de inteligencia empresarial (BI). El
motor de la base de datos SQL Server 2008 ofrece almacenamiento más seguro y
confiable tanto para datos relacionales como estructurados, lo que le permite crear y
administrar aplicaciones de datos altamente disponibles y con mayor rendimiento para
utilizar en su negocio.
El motor de datos SQL Server 2008 constituye el núcleo de esta solución de
administración de datos empresariales. Asimismo, SQL Server 2008 combina lo mejor
en análisis, información, integración y notificación. Esto permite que su negocio cree y
despliegue soluciones de BI rentables que ayuden a su equipo a incorporar datos en cada
rincón del negocio a través de tableros de comando, escritorios digitales, servicios Web
y dispositivos móviles.
La integración directa con Microsoft Visual Studio, el Microsoft Office System y un
conjunto de nuevas herramientas de desarrollo, incluido el Business Intelligence
Development Studio, distingue al SQL Server 2008. Ya sea que usted se desempeñe
como encargado de desarrollo, administrador de base de datos, trabajador de la industria
de la información o dirija una empresa, SQL Server 2008 ofrece soluciones innovadoras
que le ayudan a obtener más valor de sus datos.
HERRAMIENTAS QUE INCLUYE EL SQL SERVER 2008
Base de datos relacional. Un motor de base de datos relacional más segura,
confiable, escalable y altamente disponible con mejor rendimiento y compatible para
datos estructurados y sin estructura (XML).
Servicios de réplica. Réplica de datos para aplicaciones de procesamiento de datos
distribuidos o móviles, alta disponibilidad de los sistemas, concurrencia escalable con
almacenes de datos secundarios para soluciones de información empresarial e
integración con sistemas heterogéneos, incluidas las bases de datos Oracle
existentes.
Notification Services. Capacidades avanzadas de notificación para el desarrollo y el
despliegue de aplicaciones escalables que pueden entregar actualizaciones de
información personalizadas y oportunas a una diversidad de dispositivos conectados y
móviles.
Integration Services. Capacidades de extracción, transformación y carga (ELT) de
datos para almacenamiento e integración de datos en toda la empresa.

Analysis Services. Capacidades de procesamiento analítico en línea (OLAP) para el
análisis rápido y sofisticado de conjuntos de datos grandes y complejos, utilizando
almacenamiento multidimensional.
Reporting Services. Una solución global para crear, administrar y proporcionar tanto
informes tradicionales orientados al papel como informes interactivos basados en la
Web.
Herramientas de administración. SQL Server incluye herramientas integradas de
administración para administración y optimización avanzadas de bases de datos, así
como también integración directa con herramientas tales como Microsoft Operations
Manager (MOM) y Microsoft Systems Management Server (SMS). Los protocolos de
acceso de datos estándar reducen drásticamente el tiempo que demanda integrar los
datos en SQL Server con los sistemas existentes. Asimismo, el soporte del servicio
Web nativo está incorporado en SQL Server para garantizar la interoperabilidad con
otras aplicaciones y plataformas.
Herramientas de desarrollo. SQL Server ofrece herramientas integradas de
desarrollo para el motor de base de datos, extracción, transformación y carga de
datos, minería de datos, OLAP e informes que están directamente integrados con
Microsoft Visual Studio para ofrecer capacidades de desarrollo de aplicación de
extremo a extremo. Cada subsistema principal en SQL Server se entrega con su
propio modelo de objeto y conjunto de interfaces del programa de aplicación (API)
para ampliar el sistema de datos en cualquier dirección que sea específica de su
negocio.
NOVEDADES EN SQL SERVER 2008
SQL Server permite ejecutar aplicaciones de misión crítica, reduciendo costos de
administración de infraestructura de datos y brindando introspectiva e información a
todos los usuarios.
 Confiable: Permite a las organizaciones ejecutar sus aplicaciones más críticas
con niveles de seguridad, confiabilidad y escalabilidad muy altos.
 Productivo: Permite reducir el tiempo y los costos requeridos para desarrollar y
administrar sus infraestructuras de datos.
 Inteligente: Ofrece una plataforma integral que brinda introspectiva e
información donde sus usuarios lo desean
Nuevas funcionalidades de SQL Server 2008:
Protección de la Información
 ¿Cómo podría saber si ha copiado la base de datos del servidor de producción
de un cliente y lo han instalado en otra base de datos o si están accediendo a
la información? Con SQL 2008, puede proteger la información con una clave de
protección (Encriptación).
 ¿Cómo podría saber que datos están siendo leídos y modificados, a qué hora y
por quien? SQL 2008 da la opción de Auditora de Datos.
Continuidad del Negocio
 Si sus clientes necesitan estar siempre en línea con sus sistemas sin caídas,
SQL 2008 ofrece mejoras en una técnica llamada “Mirroring”, el cual es una
copia o espejo de la base de datos.
 Si el disco se daña, donde reside los datos, SQL 2008 recupera la información
de una copia reciente de los datos dañados al otro equipo espejo de manera
transparente.

 Ahorro en espacio en disco, mediante la técnica de comprensión, ahorrando
costos en compra de discos si es que el volumen de la información de Base de
Datos empieza a crecer en forma rápida.
Datos Geoespaciales
 Poder manejar información geográfica, la que hoy en día es de alta importancia
en las organizaciones, con todo el tema de globalización
Acceder a la Información desde cualquier lugar en cualquier momento
 Con SQL 2008 podre crear rápidamente aplicaciones conectadas a la base de
datos con la funcionalidad de funcionar en forma desconectada y después
sincronizarlos con la base de datos central sin perder la línea de negocio y
manteniendo los datos validados
Reportes
 Poder acceder a reportes directamente desde Word, mejoras en los tipos de
gráficos en los reportes, haciéndolos más entendibles y poder editar los
reportes de Microsoft Office, sin saber donde fue diseñado el reporte.
LAS EDICIONES DEL SQL SERVER 2008
Cada una de las ediciones que se encuentran disponibles en el mercado, está dirigida
a un grupo, para responder adecuadamente a las necesidades y requisitos de estos.
EDICIONES DE SERVIDOR
Término Definición
Enterprise
(x86, x64 e
IA64)1
SQL Server Enterprise es una completa plataforma de datos que proporciona
escalabilidad empresarial, rendimiento, alta disponibilidad y capacidades avanzadas de
inteligencia empresarial para ejecutar aplicaciones seguras y esenciales para la
empresa. Para obtener más información, vea http://msdn.microsoft.com/es-
es/library/cc645993(v=SQL.100).aspx .
Standard
(x86 y x64)
SQL Server Standard es una completa plataforma de datos que proporciona facilidad
de uso y capacidad de administración. Esto incluye capacidades integradas de
inteligencia empresarial para ejecutar aplicaciones de departamentos. Para obtener
más información, vea http://msdn.microsoft.com/es-
es/library/cc645993(v=SQL.100).aspx .
SQL Server Standard for Small Business contiene todos los componentes técnicos y
capacidades técnicas de SQL Server Standard y su uso está autorizado en un entorno
de pequeña empresa con 75 equipos o menos.
EDICIONES ESPECIALIZADAS
SQL Server 2008
Developer (x86,
x64 e IA64)
SQL Server 2008 Developer permite a los desarrolladores crear cualquier tipo de
aplicación basada en SQL Server. Incluye toda la funcionalidad de SQL Server
2008 Enterprise, pero su uso está autorizado como sistema de desarrollo y
pruebas, no como servidor de producción. SQL Server 2008 Developer es una
opción ideal para las personas que crean y prueban aplicaciones. Puede
actualizar SQL Server 2008 Developer para utilizarlo en producción.
Workgroup (x86 y
x64)
SQL Server Workgroup es ideal para ejecutar bases de datos ubicadas en
sucursales y proporciona una administración de datos confiable y una

plataforma de informes que incluye capacidades de sincronización y de
administración seguras y remotas.
Web (x86, x64) SQL Server 2008 Web es una opción con un costo total de propiedad bajo para
los hosts de web y los sitios web que proporciona capacidades de administración
y escalabilidad para propiedades web, tanto de pequeña como de gran escala.
SQL Server Express
(x86 y x64)
SQL Server Express
with Tools (x86 y
x64)
SQL Server Express
con Advanced
Services (x86 y
x64)
La plataforma de bases de datos de SQL Server Express se basa en SQL Server
2008. Es también la sustitución de Microsoft Desktop Engine (MSDE). Gracias a
su integración con Visual Studio, SQL Server Express facilita el desarrollo de
aplicaciones controladas por datos que tienen una gran capacidad, ofrecen un
almacenamiento seguro y se implementan con rapidez.
SQL Server Express es gratuito y los ISV pueden redistribuirlo (según su
contrato). SQL Server Express es ideal para conocer y crear pequeñas
aplicaciones de servidor y de escritorio. Esta edición es la mejor opción para los
fabricantes de software independientes, los desarrolladores no profesionales y
los aficionados que crean 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.
Compact 3.5 SP1
(x86)
Compact 3.1 (x86)
SQL Server Compact 3.5 es una base de datos gratuita e incrustada, ideal para
crear aplicaciones independientes que se conectan ocasionalmente para
dispositivos móviles, escritorios y clientes web en todas las plataformas de
Windows.
COMPONENTES QUE VIENEN A ESCOGER EN EL SQL SERVER
Componentes de
servidor
Descripción
SQL Server Database
Engine (Motor de base de
datos de SQL Server)
SQL Server Database Engine (Motor de base de datos de SQL Server)
incluye Database Engine (Motor de base de datos), el servicio principal
para almacenar, procesar y proteger datos; también incluye replicación,
búsqueda de texto completo y herramientas para administrar datos XML
y relacionales.
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.
Integration Services Integration Services es un conjunto de herramientas gráficas y objetos
programables para mover, copiar y transformar datos.
Herramientas de
administración
Descripción
SQL Server Management
Studio
SQL Server Management Studio es un entorno integrado para tener
acceso, configurar, administrar y desarrollar componentes de SQL Server.

Herramientas de
administración
Descripción
Management Studio permite a los desarrolladores de software y
administradores con diferentes grados de experiencia usar SQL Server.
Para la instalación de Management Studio, se requiere Internet Explorer 6
Service Pack 1 o una versión posterior.
Administrador de
configuración de SQL
Server
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.
SQL Server Profiler SQL Server Profiler proporciona una interfaz gráfica de usuario para
supervisar una instancia del Database Engine (Motor de base de datos) o
de Analysis Services.
Asistente para la
optimización de Database
Engine (Motor de base de
datos)
El Asistente para la optimización de Database Engine (Motor de base de
datos) crea conjuntos óptimos de índices, vistas indizadas y particiones.
Business Intelligence
Development Studio
Business Intelligence Development Studio es un IDE para las soluciones
Analysis Services, Reporting Services y Integration Services. Para la
instalación de BI Development Studio, se requiere Internet Explorer 6
Service Pack 1 o una versión posterior.
Componentes de
conectividad
Instala componentes para la comunicación entre clientes y servidores, y
bibliotecas de red para DB-Library, ODBC y OLE DB.
NÚMERO MÁXIMO DE PROCESADORES COMPATIBLES CON LAS EDICIONES DE
SQL SERVER
SQL Server admite el número especificado de sockets de procesador multiplicado por
el número de CPU lógicas en cada socket. Por ejemplo, lo siguiente se considera un
solo procesador para los fines de esta tabla:
 Un procesador de un solo núcleo e hipersubprocesamiento con dos CPU
lógicas por socket.
 Un procesador de doble núcleo con dos CPU lógicas.
 Un procesador de núcleo cuádruple con cuatro CPU lógicas.
 SQL Server se utiliza bajo licencia para cada socket del procesador y no para
cada CPU lógica.
Edición de SQL Server 2008 Número de procesadores admitidos
Enterprise Sistema operativo máximo
Developer Sistema operativo máximo
Standard 4
Web 4
Workgroup 2

Edición de SQL Server 2008 Número de procesadores admitidos
Express 1
Express with Tools 1
Express con Advanced Services 1
REQUISITOS DEL SISTEMA SQL SERVER 2008
Componente Requisito
Marco de
trabajo2
El programa de instalación de SQL Server instala los siguientes componentes de
software requeridos por el producto:
.NET Framework 3.5 SP11
SQL Server Native Client
Archivos auxiliares para la instalación de SQL Server
Software2
El programa de instalación de SQL Server requiere Microsoft Windows Installer 4.5 o
una versión posterior
Una vez instalados los componentes requeridos, el programa de instalación de SQL
Server comprobará que el equipo en el que se ha instalado SQL Server 2008
también cumple los demás requisitos para su correcta instalación. Para obtener más
información, vea Comprobar los parámetros del Comprobador de configuración del
sistema.
Software de
red
Los requisitos de software de red para las versiones de 64 bits de SQL Server 2008
son los mismos que para las versiones de 32 bits.
Los sistemas operativos compatibles tienen el software de red integrado. Las
instancias predeterminadas y con nombre independientes admiten los siguientes
protocolos de red:
Memoria compartida
Canalizaciones con nombre
TCP/IP
VIA
Nota La memoria compartida y VIA no se admiten en clústeres de conmutación
por error.
Virtualización SQL Server 2008 es compatible con entornos de máquina virtual que se ejecutan en
la función Hyper-V de las ediciones Standard, Enterprise y Datacenter de Windows
Server 2008 R2 y Windows Server 2008. La máquina virtual debe ejecutarse en un
sistema operativo compatible con la edición de SQL Server 2008 concreta que se
cita más adelante en este tema.
Además de los recursos requeridos por la partición primaria, a cada máquina virtual
(partición secundaria) se debe proporcionar suficientes recursos de procesador,
memoria y recursos de disco para su instancia de SQL Server 2008. Los requisitos se
enumeran más adelante en este tema.3
Dentro de la función Hyper-V de Windows Server 2008, se puede asignar un
máximo de cuatro procesadores virtuales a máquinas virtuales que ejecuten las
ediciones de 32 o 64 bits de Windows Server 2008. Se pueden asignar como
máximo 2 procesadores virtuales a equipos virtuales que ejecuten ediciones de 32
bits de Windows Server 2003. Para equipos virtuales que alojan otros sistemas
operativos, se puede asignar como máximo un procesador virtual a equipos

virtuales.
Notas:
Se recomienda cerrar SQL Server 2008 antes de apagar la máquina virtual.
Para obtener más información sobre la función Hyper-V de Windows Server 2008,
vea el sitio web de Windows Server 2008.
La agrupación en clústeres de conmutación por error del invitado se admite en SQL
Server 2008. Para obtener más información sobre las versiones admitidas de SQL
Server y los sistemas operativos para la agrupación en clústeres de conmutación por
error del invitado, y la compatibilidad con la virtualización, vea el tema que trata
sobre la directiva de compatibilidad para los productos de Microsoft SQL Server que
se ejecutan en un entorno virtual de hardware.
Software de
Internet
Para todas las instalaciones de SQL Server 2008 se requiere Microsoft Internet
Explorer 6 SP 1 o una versión posterior. Se requiere Internet Explorer 6 Service Pack
1 o una versión posterior para Microsoft Management Console (MMC), SQL Server
Management Studio, Business Intelligence Development Studio, el componente
Diseñador de informes de Reporting Services y la Ayuda HTML.
Disco duro Las necesidades de espacio en disco variarán con los componentes de SQL Server
2008 que instale. Para obtener más información, vea Requisitos de espacio en disco
duro, más adelante en este tema.
Unidad Para la instalación desde disco se necesita una unidad de CD o DVD.
Pantalla Las herramientas gráficas de SQL Server 2008 requieren VGA o una resolución
mayor: resolución mínima de 1.024 x 768 píxeles.
Otros
dispositivos
Dispositivo señalador: se necesita un mouse Microsoft o dispositivo señalador
compatible.
Nota: Las versiones de 64 bits de SQL Server 2008 incluyen soporte para sistemas
extendidos, también conocidos como Windows on Windows (WOW64). WOW64 es una
característica de las ediciones de 64 bits de Microsoft Windows que permite que las
aplicaciones de 32 bits se ejecuten de forma nativa en modo de 32 bits. Las
aplicaciones funcionan en modo de 32 bits aunque el sistema operativo subyacente se
ejecute en la plataforma de 64 bits.
Procesador Tipo de procesador:
Mínimo: AMD Opteron, AMD Athlon 64, Intel Xeon compatible con Intel EM64T,
Intel Pentium IV compatible con EM64T
Velocidad de procesador:
Mínimo: 1,4 GHz
Recomendado: 2,0 GHz o más
Sistema
operativo
Windows Server 2003 SP2 de 64 bits x64 Standard1
Windows Server 2003 SP2 de 64 bits x64 Datacenter1
Windows Server 2003 SP2 de 64 bits x64 Enterprise1
Windows Server 2008 de 64 bits x64 Standard
Windows Server 2008 de 64 bits x64 Standard sin Hyper-V
Windows Server 2008 de 64 bits x64 Datacenter

Windows Server 2008 de 64 bits x64 Datacenter sin Hyper-V1
Windows Server 2008 de 64 bits x64 Enterprise
Windows Server 2008 de 64 bits x64 Enterprise sin Hyper-V1
Windows Server 2008 R2 de 64 bits x64 Web1,2
Windows Server 2008 R2 de 64 bits x64 Standard1,2
Windows Server 2008 R2 de 64 bits x64 Enterprise1,2
Windows Server 2008 R2 de 64 bits x64 Datacenter1,2
Memoria RAM:
Mínimo: 512 MB
Recomendado: 2,048 GB o más
Máximo: máximo del sistema operativo
CONSIDERACIONES SOBRE LA SEGURIDAD
Para iniciar Management Studio, elija Programas>Microsoft SQL Server 2008>SQL
Server Management Studio en el menú de Inicio de Windows. Management Studio se
instala durante la instalación de Sql Server 2008. Al abrirse, le pide que se conecte a
una instancia de SQL Server. En cuanto se conecte, la instancia de SQL Server
aparece en el Explorador de objetos.
Si fuera necesario, se podría dar a conocer características especiales sobre la
conexión, para ello, hay que hacer clic sobre el botón Options, luego, aparecerá la
siguiente pantalla.

En el combo de base de datos, se podrá seleccionar la Base de Datos con la cual
deseamos conectarnos, esto dependerá del servidor con el cual nos enlacemos.
En el área de detalles de la red, veremos el modo de conexión que tenemos con el
SQL Server, dicho sea de paso, no es necesario cambiar esta opción.
En conexiones, podemos especificar el tiempo de espera para la conexión, en tiempo
de ejecución, se determina el tiempo de espera para la ejecución de las sentencias en
T-SQL.
Una vez que hayamos dado a conocer, todas las características necesarias para la
conexión, haremos clic sobre el botón Connect. Seguidamente, veremos la pantalla
del Management Studio.

Instalando el SQL Server 2008
Una vez que hayan decidido la Edición a utilizar del SQL Server 2008, procederemos a
instalar el software.

Aquí dan a conocer todos los servicios que van a utilizar:

Si tuvieran que crear una nueva instancia, aquí deberán de dar el nombre de esta:

Tener en cuenta que la instalación se debe de hacer con el usuario que tenga
máximos privilegios, además de tener una contraseña.

C
CA
AP
PI
IT
TU
UL
LO
O 2
2
 Administración de la Base de Datos y Archivos
 Planificación de la BD.
 Creación de la BD.
 Administración de la BD.
 Uso de Schemas y FileGroups.

C R E A C I Ó N D E L A B D
Para crear la base de datos, podemos hacer uso del management Studio, o a través
de sentencias T-SQL, en ambos casos, tendremos los mismos resultados. El proceso
de definición de una base de datos crea también un registro de transacciones para esa
base de datos.
Utilizando el management Studio, el
procedimiento sería el siguiente, primero nos
ubicamos sobre el objeto Databases, luego clic
derecho.
Del menú contextual, seleccionar la
alternativa New Database, para que
se muestre la ventana de
propiedades de la nueva base de
datos.
Desde esta ventana, podremos darle
nombre a la nueva base de datos,
también se puede especificar el
propietario, así como los nombres físicos y lógicos de la base de datos.
Si fuera necesario agregar nuevos grupos de archivos, hacer clic sobre el botón Add,
luego aparecerá la siguiente pantalla.

Desde aquí podremos crear los nuevos grupos de archivo, con los cuales trabajará
nuestra base de datos.
Para crear la base de datos desde T-SQL, podemos escribir lo siguiente:
Creando la base de datos sin dar mayores especificaciones sobre los archivos a crear:
USE master;
GO
IF DB_ID (N'sistemasUNI') IS NOT NULL
DROP DATABASE miproyecto;
GO
CREATE DATABASE sistemasUNI;
GO – Verificando los archivos y tamaños de la BD
SELECT name, size, size*1.0/128 AS [Size in MBs]
FROM sys.master_files
WHERE name = N' sistemasUNI ';
GO
Creando una base de datos especificando los archivos de datos y de transacciones
USE master;
GO
IF DB_ID (N'Ventitas') IS NOT NULL
DROP DATABASE Sales;
GO – obteniendo la ruta del SQL Server
DECLARE @data_path nvarchar(256);
SET @data_path = ( SELECT SUBSTRING(physical_name, 1,
CHARINDEX(N'master.mdf', LOWER(physical_name)) - 1)
FROM master.sys.master_files
WHERE database_id = 1 AND file_id = 1);
-- ejecutando la sentencia CREATE DATABASE
EXECUTE ('CREATE DATABASE Ventitas
ON
( NAME = Ventitas _dat,
FILENAME = '''+ @data_path + ' Ventitasdat.mdf'',
SIZE = 10,
MAXSIZE = 50,
FILEGROWTH = 5 )
LOG ON
( NAME = Ventitas _log,
FILENAME = '''+ @data_path + ' Ventitaslog.ldf'',
SIZE = 5MB,
MAXSIZE = 25MB,

FILEGROWTH = 5MB )' );
GO
Creando una base de datos con múltiples archivos, los archivos con extensiones mdf
contienen los archivos primarios, los ndf contienen los archivos secundarios y los ldf
contienen las transacciones.
USE master;
GO
IF DB_ID (N'Archivo') IS NOT NULL
DROP DATABASE Archivo;
GO – obteniendo la ruta del SQL Server
DECLARE @data_path nvarchar(256);
SET @data_path =(SELECT SUBSTRING(physical_name, 1, CHARINDEX(N'master.mdf',
LOWER(physical_name)) - 1) FROM master.sys.master_files
WHERE database_id = 1 AND file_id = 1);
-- ejecutar la sentencia CREATE DATABASE
EXECUTE ('CREATE DATABASE Archivo
ON PRIMARY
( NAME = Arch1,
FILENAME = '''+ @data_path + 'archdat1.mdf'',
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 20),
( NAME = Arch2,
FILENAME = '''+ @data_path + 'archdat2.ndf'',
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 20),
( NAME = Arch3,
FILENAME = '''+ @data_path + 'archdat3.ndf'',
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 20)
LOG ON
( NAME = Archlog1,
FILENAME = '''+ @data_path + 'archlog1.ldf'',
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 20),
( NAME = Archlog2,
FILENAME = '''+ @data_path + 'archlog2.ldf'',
SIZE = 100MB,
MAXSIZE = 200,
FILEGROWTH = 20)' );
GO
La información acerca de las bases de datos de SQL Server está almacenada en la
tabla sysdatabases de la base de datos master. Por tanto, debe utilizar la base de
datos master para definir una base de datos cuando utilice instrucciones Transact-
SQL.
La definición de una base de datos consiste en especificar el nombre de la base de
datos, y diseñar el tamaño y la ubicación de los archivos de la base de datos. Cuando
se crea la nueva base de datos, ésta es un duplicado de la base de datos model. Las
opciones o configuraciones de la base de datos model se copian en la nueva base de
datos.
Importante, se recomienda hacer una copia de seguridad de la base de datos master
cada vez que cree, modifique o elimine una base de datos.
Al crear una base de datos se pueden establecer los siguientes parámetros:
PRIMARY

Este parámetro especifica los archivos del grupo de archivos principal. El grupo de
archivos principal contiene todas las tablas del sistema de la base de datos. También
contiene todos los objetos no asignados a grupos de archivos del usuario. Todas las
bases de datos tienen un archivo de datos principal. El archivo de datos principal es el
punto de inicio de la base de datos y señala a los demás archivos de la base de datos.
La extensión de nombre de archivo recomendada para los archivos de datos
principales es mdf. Si no se especifica la palabra clave PRIMARY, el primer archivo
enumerado en la instrucción es el archivo principal.
FILENAME
Este parámetro especifica el nombre del archivo del sistema operativo y la ruta de
acceso al archivo. La ruta acceso de archivo debe especificar una carpeta del servidor
en el que está instalado SQL Server.
SIZE
Este parámetro especifica el tamaño de los archivos de datos o de registro. Puede
especificar los tamaños en megabytes (MB), que es el valor predeterminado, o en
kilobytes (KB). El tamaño mínimo es de 512 KB, tanto para los archivos de datos como
para los archivos de registro. El tamaño especificado para el archivo de datos principal
debe ser, al menos, como el tamaño del archivo principal de la base de datos model.
Cuando se agrega un archivo de datos o un archivo de registro, el valor
predeterminado es 1 MB.
MAXSIZE
Este parámetro especifica el tamaño máximo hasta el que puede crecer el archivo.
Puede especificar el tamaño en megabytes (valor predeterminado) o en kilobytes. Si
no se especifica el tamaño, el archivo crece hasta que el disco esté lleno.
FILEGROWTH
Este parámetro especifica el incremento de crecimiento del archivo. El valor de
FILEGROWTH de un archivo no puede sobrepasar el valor de MAXSIZE. Un valor de
0 indica que no hay crecimiento. El valor se puede especificar en megabytes (el valor
predeterminado), en kilobytes o como porcentaje (%). Si no se especifica
FILEGROWTH, el valor predeterminado es el 10 por ciento y el valor mínimo es 64 KB
(una extensión). El tamaño especificado se redondea al múltiplo de 64 KB más
próximo.
COLLATION
Este parámetro especifica la intercalación predeterminada para la base de datos. La
intercalación incluye las reglas que gobiernan el uso de caracteres de un lenguaje o un
alfabeto.

Registro de Transacciones
SQL Server graba todas las transacciones en un registro de transacciones para
mantener la coherencia de la base de datos y facilitar la recuperación. El registro es un
área de almacenamiento que efectúa automáticamente el seguimiento de todos los
cambios en la base de datos. SQL Server graba las modificaciones al registro en disco
cuando se ejecutan, antes de que se escriban en la base de datos.
El proceso de registro es el siguiente:
La aplicación envía una modificación de datos.
Cuando la modificación se ejecuta, las páginas de datos afectadas se cargan en la
caché del búfer desde el disco si no están ya cargadas en la caché del búfer por una
consulta anterior.
Cada instrucción de modificación de datos se graba en el registro mientras se ejecuta.
El cambio siempre se graba en el registro y se escribe en disco antes de hacer la
modificación en la base de datos. Este tipo de registro se denomina registro de
preescritura.
De forma repetitiva, el proceso de punto de comprobación escribe en disco todas las
transacciones completadas en la base de datos.
Si se produce un error del sistema, el proceso automático de recuperación utiliza el
registro de transacciones para aplicar todas las transacciones confirmadas y deshacer
las transacciones incompletas.
Los marcadores de transacción del registro se utilizan durante la recuperación
automática para determinar los puntos de inicio y fin de cada transacción. Una
transacción se considera completa cuando el marcador BEGIN TRANSACTION tiene
Buffer Cache
Páginas de datos se encuentran
en, o se leen, en el buffer de
caché
y son modificados
2
La modificación se registra en
diario de las transacciones en
el disco
3
Checkpoint escribe
cometido de las
transacciones en la
base de datos
4
Modificaciones de datos es
enviada por la aplicación
1
Disk
Disk

un marcador COMMIT TRANSACTION asociado. Las páginas de datos se escriben en
disco cuando existe un punto de comprobación.
Administración de la BD.
Después de haber creado una base de datos, se puede definir opciones de base de
datos con el Management Studio del SQL Server o por medio de la instrucción ALTER
DATABASE.
Puede configurar varias opciones de base de datos, pero sólo se puede hacer en una
sola base de datos al mismo tiempo. Para que las opciones afecten a todas las bases
de datos nuevas, cambie la base de datos model.
La tabla siguiente enumera algunas de las opciones de uso más frecuente.
Propiedad Descripción Valor Retornado
Opciones
automáticas
AUTO_CREATE_STATISTICS Crea automáticamente las
estadísticas que faltan que son
necesarias para la optimización
de consultas. El valor
predeterminado es ON.
AUTO_UPDATE_STATISTICS Actualiza automáticamente las
estadísticas desfasadas
necesarias para la optimización
de consultas. El valor
predeterminado es ON.
Opciones de
cursor
CURSOR_CLOSE_ON_COMMIT Cierra automáticamente los
cursores abiertos cuando se
confirma una transacción. El valor
predeterminado es OFF y los
cursores permanecen abiertos.
CURSOR_DEFAULT LOCAL |
GLOBAL
CURSOR_DEFAULT_LOCAL
limita el ámbito del cursor. Es
local al lote, procedimiento
almacenado o desencadenador
en el que se creó el cursor.
CURSOR_DEFAULT_GLOBAL
es el valor predeterminado; el
ámbito del cursor es global
respecto a la conexión.
Opciones de
recuperación
RECOVERY FULL |
BULK_LOGGED | SIMPLE
FULL proporciona recuperabilidad
completa ante errores del medio;
es el valor predeterminado.
BULK_LOGGED utiliza menos
espacio de registro porque el
registro es mínimo, pero tiene un
riesgo mayor de exposición.
SIMPLE recupera la base de
datos sólo hasta la última copia
de seguridad completa de la base
de datos o hasta la última copia
de seguridad diferencial.
TORN_PAGE_DETECTION Permite a SQL Server detectar

Propiedad Descripción Valor Retornado
operaciones de E/S incompletas
causadas por cortes de energía u
otros apagones del sistema. El
valor predeterminado es ON.
Opciones de SQL ANSI_NULL_DEFAULT Permite al usuario controlar la
capacidad de asignación
predeterminada de valores NULL
de la base de datos.
ANSI_NULLS Si está activada, todas las
comparaciones con un valor nulo
se evalúan como NULL
(desconocido). Si está
desactivada, todas las
comparaciones de valores no
Unicode con un valor nulo se
evalúan como verdaderas (TRUE)
si ambos valores son NULL. De
manera predeterminada, la opción
de base de datos ANSI_NULLS
es OFF.
Opciones de
estado
READ_ONLY | READ_WRITE Define la base de datos como de
sólo lectura (se utiliza para
establecer la seguridad en las
bases de datos de ayuda a la
toma de decisiones) o devuelve la
base de datos a operaciones de
lectura y escritura.
SINGLE_USER |
RESTRICTED_USER |
MULTI_USER
SINGLE_USER permite que los
usuarios se conecten a la base de
datos de uno en uno. Todas las
demás conexiones se
interrumpen.
RESTRICTED_USER permite que
sólo los miembros de la función
fija de base de datos db_owner y
de las funciones fijas de servidor
dbcreator y sysadmin se conecten
a la base de datos. MULTI_USER
permite que todos los usuarios
con los permisos adecuados se
conecten a la base de datos.
MULTI_USER es la opción
predeterminada.
Recuperación de información de la base de datos
Puede determinar las propiedades de la base de datos con la siguiente función
DATABASEPROPERTYEX.
SELECT DATABASEPROPERTYEX (base de datos, propiedad)
Tener en cuenta que, esta función sólo devuelve el valor de una propiedad a la vez.

La siguiente tabla enumera algunas de las propiedades de la base de datos.
Propiedad Descripción Valor retornado
Collation nombre por defecto para
la base de datos.
Collation name
NULL = Database is not
started.
Base data type:
nvarchar(128)
ComparisonStyle The Windows comparison
style of the collation.
ComparisonStyle is a
bitmap that is calculated
by using the following
values.
Style Value
Ignore
case
1
Ignore
accent
2
Ignore
Kana
65536
Ignore
width
131072
For example, the default of
196609 is the result of
combining the Ignore
case, Ignore Kana, and
Ignore width options.
Returns the comparison
style.
Returns 0 for all binary
collations.
Base data type: int
IsAnsiNullDefault Base de datos sigue
normas ISO para permitir
valores nulos.
1 = TRUE
0 = FALSE
NULL = Input not valid
Base data type: int
IsAnsiNullsEnabled Todas las comparaciones
a nulo para evaluar
desconocidos.
1 = TRUE
0 = FALSE
Base data type: int
IsAnsiPaddingEnabled Cadenas son rellenadas
con la misma longitud
antes de comparación o
inserción.
1 = TRUE
0 = FALSE
Base data type: int
IsAnsiWarningsEnabled Mensajes de error o de
advertencia se emiten
cuando un error estándar
se produce.
1 = TRUE
0 = FALSE
Base data type: int
IsArithmeticAbortEnabled Las consultas se terminan
cuando un error por
desbordamiento o división
por cero se produce
durante la ejecución de las
consultas.
1 = TRUE
0 = FALSE
Base data type: int
IsAutoClose Base de Datos se cierra
limpiando y liberando
recursos a partir de la
1 = TRUE
0 = FALSE

última salida de usuario Base data type: int
IsAutoCreateStatistics Falta de estadísticas que
se requieren de una
consulta para la
optimización automática
se construyó durante la
consulta de optimización.
1 = TRUE
0 = FALSE
Base data type: int
IsAutoShrink Archivos de Base de datos
son candidatos para
periódos automáticos de
disminución.
1 = TRUE
0 = FALSE
Base data type: int
IsAutoUpdateStatistics Estadísticas existentes
son actualizadas
automáticamente, por las
estadísticas de fuera de
fecha, porque los datos en
las tablas han cambiado.
1 = TRUE
0 = FALSE
Base data type: int
IsCloseCursorsOnCommitEnabled Cursores que están
abiertas cuando una
transacción se ha
comprometido están
cerradas
1 = TRUE
0 = FALSE
Base data type: int
IsFulltextEnabled Base de Datos con full-
text permitido.
1 = TRUE
0 = FALSE
Base data type: int
IsInStandBy Base de Datos esta online
como read-only, con
restauración del log
permitido.
1 = TRUE
0 = FALSE
Base data type: int
IsLocalCursorsDefault Declaración del Cursor por
defecto como LOCAL
1 = TRUE
0 = FALSE
Base data type: int
IsMergePublished Las tablas de una Base de
Datos pueden ser
publicadas para una
replicación, si la
replicación está instalada.
1 = TRUE
0 = FALSE
Base data type: int
IsNullConcat Concatenación de
operaciones Null rinden
con NULL.
1 = TRUE
0 = FALSE
Base data type: int
IsNumericRoundAbortEnabled Los errores se generan
cuando la pérdida de
precisión se produce en
las expresiones
1 = TRUE
0 = FALSE
Base data type: int
IsParameterizationForced PARAMETERIZATION de
la base de datos con la
opción SET es FORCED.
1 = TRUE
0 = FALSE

IsQuotedIdentifiersEnabled Doble comillas se puede
utilizar en identificadores.
1 = TRUE
0 = FALSE
Base data type: int
IsPublished Las tablas de la base de
datos pueden ser
publicados por la
instantánea o la
replicación transaccional,
si se instala la replicación.
1 = TRUE
0 = FALSE
Base data type: int
IsRecursiveTriggersEnabled Recursivo disparo de
factores desencadenantes
está activado
1 = TRUE
0 = FALSE
Base data type: int
IsSubscribed Base de datos está
suscrito a una publicación
1 = TRUE
0 = FALSE
Base data type: int
IsSyncWithBackup La base de datos es una
base de datos de
publicación o una base de
datos de distribución, y
puede ser restaurada sin
interrumpir la replicación
transaccional.
1 = TRUE
0 = FALSE
Base data type: int
IsTornPageDetectionEnabled El SQL Server Database
Engine Engine detecta
operaciones incompletas
de E/S causados por fallos
de energía o cortes de
otro sistema.
1 = TRUE
0 = FALSE
Base data type: int
LCID El identificador de
Windows local (LCID) de
la colación.
LCID value (in decimal
format).
Base data type: int
For a list of LCID values
(in hexadecimal format),
see Collation Settings in
Setup.
Recovery Modelo de recuperación
para la base de datos
FULL = Full recovery
model
BULK_LOGGED = Bulk
logged model
SIMPLE = Simple
recovery model
Base data type:
nvarchar(128)
SQLSortOrder SQL Server sort order ID
supported in earlier
versions of SQL Server
SQL Server
ordenanimiento, apoya
ordenamiento por ID en
las versiones anteriores
de SQL Server
0 = Database is using
Windows collation
>0 = SQL Server sort
order ID
NULL = Input not valid or
database is not started
Base data type: tinyint
Status Estado de la Base de ONLINE = Database is

Datos. available for query.
OFFLINE = Database
was explicitly taken
offline.
RESTORING = Database
is being restored.
RECOVERING =
Database is recovering
and not yet ready for
queries.
SUSPECT = Database
did not recover.
EMERGENCY =
Database is in an
emergency, read-only
state. Access is restricted
to sysadmin members
Base data type:
nvarchar(128)
Updateability Indica si los datos pueden
ser modificados
READ_ONLY = Data can
be read but not modified.
READ_WRITE = Data
can be read and modified.
Base data type:
nvarchar(128)
UserAccess Indica que los usuarios
puedan acceder a la base
de datos.
SINGLE_USER = Only
one db_owner, dbcreator,
or sysadmin user at a
time
RESTRICTED_USER =
Only members of
db_owner, dbcreator, and
sysadmin roles
MULTI_USER = All users
Base data type:
nvarchar(128)
Version Número de versión interna
del código SQL Server
con el que la base de
datos se ha creado.
Identificado sólo con fines
informativos. No
soportado. La
compatibilidad en el futuro
no está garantizada.
Version number =
Database is open.
NULL = Database is not
started.
Base data type: int
La siguiente tabla enumera los procedimientos almacenados del sistema de uso
común que presentan información acerca de las bases de datos y sus parámetros.
Procedimiento almacenado de
sistema
Descripción
sp_helpdb Informa acerca de todas las bases de datos de
un servidor. Proporciona el nombre, tamaño,
propietario, Id., fecha de creación y opciones

Procedimiento almacenado de
sistema
Descripción
sp_helpdb baseDeDatos Informa sólo acerca de la base de datos
especificada. Proporciona el nombre, tamaño,
propietario, Id., fecha de creación y opciones
de la base de datos. También enumera los
archivos de datos y de registro.
sp_spaceused [nombreObjeto] Resume el espacio de almacenamiento que
utiliza una base de datos o un objeto de base
de datos.
Componentes físicos: archivos y grupos de archivos de bases de datos (FileGroup).
Un grupo de archivos es un conjunto lógico de archivos de datos que permite a los
administradores controlar todos los archivos del grupo como un único elemento.
La posibilidad de controlar la posición física de los objetos individuales de la base de
datos puede proporcionar diversas ventajas en cuanto a facilidad de administración y
rendimiento. Por ejemplo, puede utilizar varios grupos de archivos para controlar cómo
se almacenan físicamente los datos de una base de datos en dispositivos de
almacenamiento, y para separar los datos de lectura y escritura de los datos de sólo
lectura.
Tipos de grupos de archivos
SQL Server 2008 tiene un grupo de archivos principal y también puede tener grupos
de archivos definidos por el usuario.

El grupo de archivos principal contiene el archivo principal de datos con las tablas del
sistema. El archivo principal de datos utiliza normalmente la extensión .mdf.
Un grupo de archivos definido por el usuario consta de archivos de datos agrupados
con fines de asignación y administrativos. Estos otros archivos de datos se conocen
como archivos secundarios de datos y suelen utilizar la extensión .ndf.
SITUACIÓN DE EJEMPLO PARA VARIOS GRUPOS DE ARCHIVOS
La ilustración proporciona un ejemplo de cómo podría colocar los archivos de base de
datos en discos diferentes, como se describe en la lista siguiente:
Puede crear grupos de archivos definidos por el usuario para separar los archivos que
se consultan con mucha frecuencia de los que se modifican mucho. En la ilustración,
los archivos OrdHist1.ndf y OrdHist2.ndf se colocan en un disco distinto que las tablas
Product, Customer y SalesOrderHeader, ya que se consultan como ayuda para la
toma de decisiones en lugar de actualizarse con información de pedidos actual.
También podría colocar los archivos OrdHist1.ndf y OrdHist2.ndf en discos diferentes
si ambos se consultaran con mucha frecuencia.
No puede poner archivos de registro de transacciones en grupos de archivos. El
espacio del registro de transacciones se administra por separado del espacio de datos.
Los registros de transacciones suelen utilizar la extensión .ldf.
En el siguiente ejemplo de código Transact-SQL se utiliza la instrucción CREATE
DATABASE para implementar esta situación de ejemplo.
CREATE DATABASE [AdventureWorks] ON PRIMARY
( NAME = N'AdventureWorks_Data', FILENAME = N'C:AdventureWorks_Data.mdf' ),
FILEGROUP [OrderHistoryGroup]
( NAME = N'OrdHist1', FILENAME = N'D:OrdHist1.ndf' ),
( NAME = N'OrdHist2', FILENAME = N'D:OrdHist2.ndf' )
LOG ON
( NAME = N'AdventureWorks_log', FILENAME = N'E:AdventureWorks_log.ldf')
También puede utilizar la instrucción ALTER DATABASE para agregar o eliminar
archivos y grupos de archivos de bases de datos existentes.
CUÁNDO CREAR GRUPOS DE ARCHIVOS
Puede crear varios archivos de datos en discos diferentes y crear un grupo de archivos
definido por el usuario para contener los archivos. Las dos razones principales para
utilizar grupos de archivos son mejorar el rendimiento y controlar la colocación física
de datos.

Uso de varios archivos en un único grupo de archivos para mejorar el rendimiento
Si bien Matriz redundante de discos independientes (RAID) es la manera preferida de
mejorar el rendimiento de una base de datos, puede asignar varios archivos de discos
distintos a un único grupo de archivos para mejorar el rendimiento implementando una
forma de seccionamiento de datos dentro de SQL Server. Puesto que SQL Server
utiliza una estrategia de relleno proporcional al escribir datos en un grupo de archivos,
los datos se reparten entre los archivos y, por tanto, en las particiones físicas del
disco.
Este método permite tener un control más fino sobre el seccionamiento de datos del
que se puede lograr al crear un conjunto de volúmenes seccionados en el sistema
operativo Windows, o utilizando una controladora de matriz RAID.
Nota: En la mayoría de los casos, el uso de las funciones de seccionamiento de RAID
Proporciona la misma ganancia de rendimiento que podría lograr utilizando grupos
de archivos definidos por el usuario, sin la carga administrativa agregada que supone
definir y administrar los grupos de archivos.
USO DE VARIOS GRUPOS DE ARCHIVOS PARA CONTROLAR LA COLOCACIÓN
FÍSICA DE LOS DATOS
Para utilizar grupos de archivos con el fin de simplificar el mantenimiento o lograr
objetivos de diseño, puede:
Almacenar los datos de lectura y escritura separados de los datos de sólo lectura para
mantener separados los diferentes tipos de actividad de E/S de disco.
Almacenar los índices en discos diferentes que las tablas, lo que puede conducir a un
mayor rendimiento.
Hacer copia de seguridad o restaurar archivos individuales o grupos de archivos en
lugar de hacer copia de seguridad o restaurar una base de datos entera. Puede ser

necesario hacer copia de seguridad de archivos o de grupos de archivos para las
bases de datos grandes con el fin de tener una estrategia eficaz de copia de seguridad
y restauración.
Agrupar en los mismos grupos de archivos las tablas y los índices que tienen unos
requisitos de mantenimiento similares. Quizás desee realizar tareas de mantenimiento
en algunos objetos con más frecuencia que en otros. Por ejemplo, si crea dos grupos
de archivos y les asigna tablas, puede ejecutar las tareas diarias de mantenimiento en
las tablas de un grupo diario y las tareas de mantenimiento semanales en las tablas de
un grupo semanal. Esto limita la contención de disco entre los dos grupos de archivos.
Separar las tablas de usuario y otros objetos de base de datos de las tablas del
sistema en el grupo de archivos principal. También debe cambiar el grupo de archivos
predeterminado para evitar que el crecimiento inesperado de las tablas restrinja las
tablas del sistema del grupo de archivos principal.
Almacenar las particiones de una tabla con particiones en varios grupos de archivos.
Ésta es una buena forma de separar físicamente los datos que tienen necesidades de
acceso diferentes dentro de una única tabla, y también puede proporcionar ventajas de
facilidad de administración y rendimiento.
Creación de esquemas
Los desarrolladores que hayan trabajado con Microsoft .NET Framework o con XML
estarán familiarizados con el concepto de espacios de nombres. Un espacio de
nombres ayuda a agrupar los objetos relacionados, haciendo que las listas de objetos
complejas sean más fáciles de administrar. SQL Server 2008 utiliza esquemas para
implementar un concepto similar para los objetos de base de datos.
Los objetos de una base de datos (como tablas, vistas y procedimientos almacenados)
se crean dentro de un esquema. Es esencial comprender lo que es un esquema antes
de planear e implementar una base de datos de SQL Server 2008.

ESQUEMAS COMO ESPACIOS DE NOMBRES
Un esquema es un espacio de nombres para objetos de base de datos. Es decir, un
esquema define un límite dentro del cual todos los nombres son únicos. Puesto que
los nombres de esquema deben ser únicos dentro de la base de datos, cada objeto de
una base de datos tiene un nombre completo único con el formato servidor.base de
datos.esquema.objeto. Dentro de una base de datos, puede acortarlo a
esquema.objeto.
La ilustración anterior muestra tres esquemas de la base de datos AdventureWorks en
una instancia de SQL Server denominada Server1. Los esquemas se denominan
Person, Sales y dbo. Cada uno de estos esquemas contiene una tabla y el nombre
completo de la tabla incluye el nombre del servidor, la base de datos y el esquema.
Por ejemplo, el nombre completo de la tabla ErrorLog del esquema dbo es
Server1.AdventureWorks.dbo.ErrorLog.
En versiones anteriores de SQL Server, el espacio de nombres de un objeto estaba
determinado por el nombre de usuario de su propietario. En SQL Server 2008, los
esquemas están separados de la propiedad de los objetos, lo que proporciona las
ventajas siguientes:
Mayor flexibilidad a la hora de organizar los objetos de base de datos en espacios de
nombres, ya que la agrupación de objetos en esquemas no depende de la propiedad
de los objetos.
Administración de permisos más sencilla, ya que se puede otorgar permisos en el
ámbito del esquema y en los objetos individuales.
Facilidad de administración mejorada, porque al quitar a un usuario no es necesario
cambiar el nombre de todos los objetos que ese usuario posee.
ESQUEMAS DE EJEMPLO
La base de datos AdventureWorks utiliza los esquemas siguientes para organizar sus
objetos de base de datos en espacios de nombres:
HumanResources
Person
Production
Purchasing
Sales
Por ejemplo, para hacer referencia a la tabla Employee del esquema
HumanResources se utiliza HumanResources.Employee.
El esquema dbo
Todas las bases de datos contienen un esquema denominado dbo. dbo es el esquema
predeterminado para todos los usuarios que no tienen ningún otro esquema
predeterminado definido explícitamente.
Creación de un esquema
Para crear un esquema, utilice el Explorador de objetos de SQL Server Management
Studio o utilice la instrucción CREATE SCHEMA, como se muestra en el ejemplo
siguiente.
Use AdventureWorks

GO
CREATE SCHEMA Sales
GO
Cómo funciona la resolución de nombres de objetos
Cuando una base de datos contiene varios esquemas, la resolución de nombres de
objetos puede resultar confusa. Por ejemplo, una base de datos podría contener dos
tablas denominadas Order en dos esquemas diferentes, Sales y dbo. Los nombres
completos de los objetos dentro de la base de datos son inequívocos: Sales.Order y
dbo.Order, respectivamente. Sin embargo, el uso del nombre incompleto Order puede
producir resultados inesperados. Puede asignar a los usuarios un esquema
predeterminado para controlar cómo se resuelven los nombres de objetos incompletos.
CÓMO FUNCIONA LA RESOLUCIÓN DE NOMBRES
SQL Server 2008 utiliza el proceso siguiente para resolver un nombre de objeto
incompleto:
Si el usuario tiene un esquema predeterminado, SQL Server intenta encontrar el objeto
en ese esquema predeterminado.
Si el objeto no se encuentra en el esquema predeterminado del usuario, si el usuario
no tiene ningún esquema predeterminado, SQL Server intenta encontrar el objeto en el
esquema dbo.

Por ejemplo, un usuario que tiene el esquema predeterminado Person ejecuta la
siguiente instrucción Transact-SQL:
SELECT * FROM Contact
SQL Server 2008 intentará resolver primero el nombre de objeto como
Person.Contact. Si el esquema Person no contiene un objeto denominado Contact,
SQL Server intentará resolver el nombre de objeto como dbo.Contact.
Si un usuario que no tiene ningún esquema predeterminado definido ejecuta la misma
instrucción, SQL Server resolverá inmediatamente el nombre de objeto como
dbo.Contact.
Asignación de un esquema predeterminado
Puede asignar un esquema predeterminado a un usuario utilizando el cuadro de
diálogo Propiedades de Usuario de la base de datos o especificando el nombre del
esquema en la cláusula DEFAULT_SCHEMA de la instrucción CREATE USER o
ALTER USER. Por ejemplo, el siguiente código Transact-SQL asigna Sales como el
esquema predeterminado para el usuario Angello:
ALTER USER Angello WITH DEFAULT_SCHEMA = Sales

C
CA
AP
PI
IT
TU
UL
LO
O 3
3
 Planificación de una Estrategia de Backups
 Realizando el Backup de la BD
 Restaurando una BD
 Recuperación de datos desde Snapshots

P L A N I F I C A C I Ó N D E U N A E S T R A T E G I A D E
B A C K U P S
Con frecuencia, los datos en una base de datos confirman las operaciones de una
organización. Sin la base de datos, la organización no puede funcionar
adecuadamente. Es importante que cada misión crítica sistema de base de datos haya
sido adecuadamente definida en procedimientos de recuperación de desastres.
Las operaciones de Copia de seguridad y Restauración, son una parte vital de la
gestión de datos y son esenciales para la recuperación ante fallas y desastres. Por lo
tanto, una parte importante del papel de un administrador de bases de datos, es
garantizar que los datos sean respaldados y puedan ser restaurados rápidamente en
caso de un desastre.
Tipos de Backup Descripción
Full Todos los archivos de la Base de Datos, datos (MDF y NDF) y de
transacciones (LDF).
Transaction Log Cualquier cambio en la Base de Datos, es guardado en el archivo
de transacciones.
Tail-Log La porción activa del archivo de transacciones.
Differential Las partes de la Base de Datos que han cambiado desde el último
backup completo a la Base de Datos.
File / Filegroup Archivos específicos o grupos de archivos.
Partial El grupo de archivos primario, cada grupo de archivos de
lectura/escritura, y cualquier grupo de archivos especificado como
lectura/escritura.
Copy-only La Base de Datos o el archivo de Transacciones (sin afectar la
secuencia de backup).
Realizando el Backup de la BD
Uso de la Instrucción BACKUP DATABASE
Realiza una copia de seguridad completa de la base de datos o de uno o varios
archivos o grupos de archivos (BACKUP DATABASE). Además, con el modelo de
recuperación completa o el modelo de recuperación optimizado para cargas masivas
de registros, realiza la copia de seguridad del registro de transacciones (BACKUP
LOG).
Sintaxis
--creando un backup
BACKUP DATABASE { database_name | @database_name_var }
TO <backup_device> [ ,...n ]

[ <MIRROR TO clause> ] [ next-mirror-to ]
[ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]
--Backup para Files o Filegroups
<file_or_filegroup> [ ,...n ]
[;]
--Creando un Backup Parcial
READ_WRITE_FILEGROUPS [ , <read_only_filegroup> [ ,...n ] ]
[;]
Argumentos
DATABASE
Especifica una copia de seguridad completa de la base de datos. Si se especifica una
lista de archivos y grupos de archivos, sólo se realiza la copia de seguridad de esos
archivos o grupos de archivos. Durante una copia de seguridad completa o diferencial
de una base de datos, SQL Server realiza la copia de seguridad de una parte
suficiente del registro de transacciones para producir una base de datos coherente
cuando se restaure la base de datos.
LOG
Especifica que sólo se realizará la copia de seguridad del registro de transacciones.
Se realiza la copia de seguridad del registro desde la última copia de seguridad del
registro ejecutada correctamente hasta el final actual del registro. Antes de que pueda
crear la primera copia de seguridad del registro, debe crear una copia de seguridad
completa.
{ database_name | @database_name_var }
Es la base de datos para la que se realiza la copia de seguridad del registro de
transacciones, de una parte de la base de datos o de la base de datos completa. Si se
proporciona como una variable (@database_name_var), este nombre se puede
especificar como una constante de cadena (@database_name_var = database name)
o como una variable de un tipo de datos de cadena de caracteres, excepto los tipos de
datos ntext o text.
Se utiliza sólo con BACKUP DATABASE, especifica un grupo de archivos o un archivo
de copia de seguridad que se va a incluir en una copia de seguridad de archivos o
especifica un grupo de archivos o un archivo de sólo lectura que se va a incluir en una
copia de seguridad parcial.
FILE = { logical_file_name | @logical_file_name_var }
Es el nombre lógico de un archivo o una variable cuyo valor equivale al nombre lógico
de un archivo que se va a incluir en la copia de seguridad.
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

Es el nombre lógico de un grupo de archivos o una variable cuyo valor equivale al
nombre lógico de un grupo de archivos que se va a incluir en la copia de seguridad. En
el modelo de recuperación simple, se permite la copia de seguridad de un grupo de
archivos sólo si se trata de un grupo de archivos de sólo lectura.
n
Es un marcador de posición que indica que se pueden especificar varios archivos y
grupos de archivos en una lista separada por comas. El número es ilimitado.
READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name |
@logical_filegroup_name_var } [ ,...n ] ]
Especifica una copia de seguridad parcial. Una copia de seguridad parcial incluye
todos los archivos de lectura/escritura en una base de datos: el grupo de archivos
principal y los grupos de archivos secundarios de lectura/escritura, así como los
grupos de archivos o archivos de sólo lectura especificados.
READ_WRITE_FILEGROUPS
Especifica que en la copia de seguridad parcial se copiarán todos los grupos de
archivos de lectura/escritura. Si la base de datos es de sólo lectura,
READ_WRITE_FILEGROUPS incluye tan sólo el grupo de archivos principal.
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
Es el nombre lógico de un grupo de archivos de sólo lectura o una variable cuyo valor
equivale al nombre lógico de un grupo de archivos de sólo lectura que se va a incluir
en la copia de seguridad parcial. Para obtener más información, vea
"<file_or_filegroup>", anteriormente en este tema.
n
Es un marcador de posición que indica que se pueden especificar varios grupos de
archivos de sólo lectura en una lista separada por comas.
Indica que el conjunto de dispositivos de copia de seguridad correspondiente es un
conjunto de medios no reflejado o el primero de los reflejos de un conjunto de medios
reflejado (para los que se declaran una o más cláusulas MIRROR TO).
<backup_device>
Especifica el dispositivo de copia de seguridad físico o lógico que se va a utilizar para
la operación de copia de seguridad.
{ logical_device_name | @logical_device_name_var }
Es el nombre lógico del dispositivo de copia de seguridad en que se hace la copia de
seguridad de la base de datos. El nombre lógico debe seguir las reglas definidas para
los identificadores. Si se proporciona como una variable (@logical_device_name_var),
el nombre del dispositivo de copia de seguridad se puede especificar como una
constante de cadena (@logical_device_name_var = nombre del dispositivo de copia
de seguridad lógico) o como una variable de un tipo de datos de cadena de caracteres,
excepto los tipos de datos ntext o text.
{ DISK | TAPE } = { 'physical_device_name' | @physical_device_name_var }
Especifica un archivo de disco o un dispositivo de cinta.

No es necesario que exista un dispositivo de disco antes de que se especifique en una
instrucción BACKUP. Si el dispositivo físico existe y no se especifica la opción INIT en
la instrucción BACKUP, la copia de seguridad se anexa al dispositivo.
n
Es un marcador de posición que indica que se pueden especificar hasta 64
dispositivos de copia de seguridad en una lista separada por comas.
MIRROR TO <backup_device> [ ,...n ]
Especifica un conjunto de uno o varios dispositivos de copia de seguridad que
reflejarán los dispositivos de copia de seguridad especificados en la cláusula TO. La
cláusula MIRROR TO debe incluir el mismo número y tipo de dispositivos de copia de
seguridad que la cláusula TO. El número máximo de cláusulas MIRROR TO es tres.
Esta opción sólo está disponible en SQL Server 2008 Enterprise Edition y versiones
posteriores.
<backup_device>
Vea "<backup_device>", en un apartado anterior de esta sección.
n
Es un marcador de posición que indica que se pueden especificar hasta 64
dispositivos de copia de seguridad en una lista separada por comas. El número de
dispositivos de la cláusula MIRROR TO debe ser igual al número de dispositivos de la
cláusula TO.
[ next-mirror-to ]
Es un marcador de posición que indica que una sola instrucción BACKUP puede
contener hasta tres cláusulas MIRROR TO, además de una sola cláusula TO.
Opciones de WITH
Especifica las opciones que se van a utilizar con una operación de copia de seguridad.
DIFFERENTIAL
Se utiliza sólo con BACKUP DATABASE. Especifica que la copia de seguridad de la
base de datos o el archivo sólo debe estar compuesta por las partes de la base de
datos o el archivo que hayan cambiado desde la última copia de seguridad completa.
Una copia de seguridad diferencial suele ocupar menos espacio que una copia de
seguridad completa. Utilice esta opción para que no tenga que aplicar todas las copias
de seguridad de registros individuales efectuadas desde que se realizó la última copia
de seguridad completa.
DESCRIPTION = { 'text' | @text_variable }
Especifica el texto de forma libre que describe el conjunto de copia de seguridad. La
cadena puede tener un máximo de 255 caracteres.
NAME = { backup_set_name | @backup_set_var }
Especifica el nombre del conjunto de copia de seguridad. Los nombres pueden tener
un máximo de 128 caracteres. Si no se especifica NAME, está en blanco.
PASSWORD = { password | @password_variable }
Establece la contraseña del conjunto de copia de seguridad. PASSWORD es una
cadena de caracteres.

Si se define una contraseña para el conjunto de copia de seguridad, debe suministrarla
para realizar operaciones de restauración de SQL Server de ese conjunto de copia de
seguridad. No obstante, la contraseña del conjunto de copia de seguridad no impide
que se sobrescriba el archivo de copia de seguridad. Para evitar que se sobrescriba el
archivo de copia de seguridad, utilice una contraseña para el conjunto de medios (vea
la opción MEDIAPASSWORD más adelante en esta tabla). (Para obtener más
información sobre cómo utilizar las contraseñas, vea "Permisos", más adelante en este
tema.)
Utilizando el Management del SQL Server
Primero nos ubicamos en el explorador de objetos, y luego hacemos clic derecho
sobre la base de datos, seguidamente, haremos clic sobre la opción de propiedades
Luego, en la opción “Recovery Model”, seleccionaremos la alternativa “Full”, con la
cual, podremos realizar todos los tipos de Backup de nuestra Base de Datos.

Una vez cambiadas las propiedades de nuestra base de datos, haremos clic derecho
sobre la base de datos de la que queremos una copia de seguridad, en la opción
“Tasks”, seleccionamos “Back Up..” (ver figura).
Luego aparecerá la siguiente pantalla, en la cual seleccionaremos el tipo de Backup a
realizar.

Una vez que hayamos realizado las configuraciones del caso, procederemos a hacer
clic sobre el botón “OK”, luego de algunos instantes, aparecerá la siguiente pantalla.
Restaurando una BD
Para realizar la restauración de una Base de Datos, podemos hacer uso de la
instrucción RESTORE, o de los contrario, utilizar el management Sql Server.
RESTORE (Transact-SQL)
Restaura copias de seguridad realizadas con el comando BACKUP. Este comando le
permite realizar los siguientes escenarios de restauración:
 Restaurar una base de datos completa a partir de una copia de seguridad
completa de la base de datos (restauración completa).
 Restaurar parte de una base de datos (restauración parcial).
 Restaurar archivos o grupos de archivos en una base de datos (restauración de
archivos).
 Restaurar páginas específicas en una base de datos (restauración de páginas).
 Restaurar un registro de transacciones en una base de datos (restauración del
registro de transacciones).
 Revertir una base de datos al punto temporal capturado por una instantánea de
la base de datos.
--To Restore an Entire Database from a Full database backup (a Complete Restore):
RESTORE DATABASE { database_name | @database_name_var }
[ FROM <backup_device> [ ,...n ] ]
[ WITH
{
[ RECOVERY | NORECOVERY | STANDBY =
{standby_file_name | @standby_file_name_var }
]
| , <general_WITH_options> [ ,...n ]
| , <replication_WITH_option>
| , <change_data_capture_WITH_option>
| , <service_broker_WITH options>
| , <point_in_time_WITH_options—RESTORE_DATABASE>
} [ ,...n ]
]
[;]
--To perform the first step of the initial restore sequence
-- of a piecemeal restore:
<files_or_filegroups> [ ,...n ]
WITH

PARTIAL, NORECOVERY
[ , <general_WITH_options> [ ,...n ]
| , <point_in_time_WITH_options—RESTORE_DATABASE>
] [ ,...n ]
[;]
--To Restore Specific Files or Filegroups:
WITH
{
[ RECOVERY | NORECOVERY ]
[ , <general_WITH_options> [ ,...n ] ]
} [ ,...n ]
[;]
--To Restore Specific Pages:
PAGE = 'file:page [ ,...n ]'
[ , <file_or_filegroups> ] [ ,...n ]
WITH
NORECOVERY
[ , <general_WITH_options> [ ,...n ] ]
[;]
--To Restore a Transaction Log:
RESTORE LOG { database_name | @database_name_var }
[ <file_or_filegroup_or_pages> [ ,...n ] ]
[ WITH
{
[ RECOVERY | NORECOVERY | STANDBY =
{standby_file_name | @standby_file_name_var }
]
| , <general_WITH_options> [ ,...n ]
| , <replication_WITH_option>
| , <point_in_time_WITH_options—RESTORE_LOG>
} [ ,...n ]
]
[;]
FROM DATABASE_SNAPSHOT = database_snapshot_name
Permisos
Si la base de datos que se va a restaurar no existe, el usuario debe tener permisos
CREATE DATABASE para poder ejecutar RESTORE. Si la base de datos existe, los
permisos RESTORE corresponden de forma predeterminada a los miembros de las
funciones fijas de servidor sysadmin y dbcreator, y al propietario (dbo) de la base de
datos (para la opción FROM DATABASE_SNAPSHOT, la base de datos siempre
existe).
Los permisos RESTORE se conceden a funciones en las que la información acerca de
los miembros está siempre disponible para el servidor. Debido a que los miembros de
una función fija de base de datos sólo se pueden comprobar cuando la base de datos
es accesible y no está dañada, lo que no siempre ocurre cuando se ejecuta
RESTORE, los miembros de la función fija de base de datos db_owner no tienen
permisos RESTORE.

La operación de copia de seguridad puede especificar opcionalmente contraseñas de
un conjunto de medios, de un conjunto de copia de seguridad o de ambos. Si se ha
definido una contraseña en un conjunto de medios o un conjunto de copia de
seguridad, debe especificar la contraseña o contraseñas correctas en la instrucción
RESTORE. Estas contraseñas impiden operaciones de restauración y anexiones no
autorizadas de los conjuntos de copia de seguridad en medios que utilizan
herramientas de SQL Server. No obstante, los medios protegidos con contraseña se
pueden sobrescribir mediante la opción FORMAT de la instrucción BACKUP.
Ejemplos sobre el uso del RESTORE
A. Restaurar una base de datos completa
En el siguiente ejemplo se restaura una copia de seguridad completa de la base de
datos desde un dispositivo lógico de copia de seguridad de AdventureWorksBackups
RESTORE DATABASE AdventureWorks
FROM AdventureWorksBackups
B. Restaurar copias de seguridad de bases de datos completas y diferenciales
En el siguiente ejemplo se restaura una copia de seguridad completa después de una
copia de seguridad diferencial del dispositivo de copia de seguridad
Z:SQLServerBackupsAdventureWorks.bak, que contiene las dos copias de
seguridad. La copia de seguridad de bases de datos completa que se va a restaurar es
el sexto conjunto de copias de seguridad del dispositivo (FILE = 6), y la copia de
seguridad de base de datos diferencial es el noveno conjunto del dispositivo (FILE =
9). En cuanto se recupere la copia de seguridad diferencial, se recuperará la base de
datos.
FROM DISK = 'Z:SQLServerBackupsAdventureWorks.bak'
WITH FILE = 6
NORECOVERY;
FROM DISK = 'Z:SQLServerBackupsAdventureWorks.bak'
WITH FILE = 9
RECOVERY;
C. Restaurar una base de datos con la sintaxis de RESTART
En el ejemplo siguiente se usa la opción RESTART para reiniciar una operación
RESTORE interrumpida por un error de alimentación del servidor.
-- This database RESTORE halted prematurely due to power failure.
-- Here is the RESTORE RESTART operation.
FROM AdventureWorksBackups WITH RESTART
D. Restaurar una base de datos y mover archivos
En el ejemplo siguiente se restaura una base de datos completa y el registro de
transacciones, y se mueve la base de datos restaurada al directorio C:Program
FilesMicrosoft SQL ServerMSSQL10.MSSQLSERVERMSSQLData.
WITH NORECOVERY,
MOVE 'AdventureWorks_Data' TO

'C:Program FilesMicrosoft SQL ServerMSSQL10.MSSQLSERVERMSSQLDataNewAdvWorks.mdf',
MOVE 'AdventureWorks_Log'
TO 'C:Program FilesMicrosoft SQL ServerMSSQL10.MSSQLSERVERMSSQLDataNewAdvWorks.ldf'
RESTORE LOG AdventureWorks
WITH RECOVERY
E. Copiar una base de datos con BACKUP y RESTORE
En el ejemplo siguiente se usan las instrucciones BACKUP y RESTORE para realizar
una copia de la base de datos AdventureWorks. La instrucción MOVE hace que se
restauren los datos y el archivo de registro en las ubicaciones especificadas. La
instrucción RESTORE FILELISTONLY se usa para determinar el número y los
nombres de los archivos de la base de datos que se están restaurando. La nueva
copia de la base de datos se llama TestDB. Para obtener más información, vea
RESTORE FILELISTONLY (Transact-SQL).
BACKUP DATABASE AdventureWorks
TO AdventureWorksBackups ;
RESTORE FILELISTONLY
FROM AdventureWorksBackups ;
RESTORE DATABASE TestDB
WITH MOVE 'AdventureWorks_Data' TO 'C:MySQLServertestdb.mdf',
MOVE 'AdventureWorks_Log' TO 'C:MySQLServertestdb.ldf';
GO
F. Restaurar con la sintaxis de FILE y FILEGROUP
En el siguiente ejemplo se restaura una base de datos llamada MyDatabase que tiene
dos archivos, un grupo de archivos secundario y un registro de transacciones. La base
de datos usa el modelo de recuperación completa.
La copia de seguridad de la base de datos es el noveno conjunto de copia de
seguridad del conjunto de medios en un dispositivo lógico de copia de seguridad
llamado MyDatabaseBackups. A continuación se restauran mediante WITH
NORECOVERY tres copias de seguridad de registros que están en los tres conjuntos
de copia de seguridad siguientes (10, 11 y 12) en el dispositivo MyDatabaseBackups.
Tras restaurar la última copia de seguridad de registros se restaura la base de datos.
Tenga en cuenta que en RESTORE DATABASE hay dos tipos de opciones FILE. Las
opciones FILE que preceden al nombre del dispositivo de copia de seguridad
especifican los nombres de archivos lógicos de los archivos de base de datos que se
van a restaurar desde el conjunto de copia de seguridad; por ejemplo, FILE =
'MyDatabase_data_1'. Este conjunto de copia de seguridad no es la primera copia de
seguridad de la base de datos en el conjunto de medios; por ello, su posición en el
conjunto de medios se indica mediante la opción FILE de la cláusula WITH, FILE=9.
RESTORE DATABASE MyDatabase
FILE = 'MyDatabase_data_1',
FILE = 'MyDatabase_data_2',
FILEGROUP = 'new_customers'
FROM MyDatabaseBackups
WITH
FILE = 9,
NORECOVERY;
GO
-- Restore the log backups.
RESTORE LOG MyDatabase

WITH FILE = 10,
NORECOVERY;
GO
WITH FILE = 11,
NORECOVERY;
GO
WITH FILE = 12,
NORECOVERY;
GO
--Recover the database:
RESTORE DATABASE MyDatabase WITH RECOVERY;
GO
Recuperando la BD desde el management
Especificamos el origen del archivo de Backup, seleccionamos “From Device”

Hacemos clic sobre el botón “Add” para especificar la ubicación del archivo de Backup.
Seleccionamos el archivo.

Confirmamos la ubicación del archivo a recuperar.
Indicamos el nombre de la Base de Datos a recuperar.

Verificamos la ubicación de los archivos de mdf, ndf y ldf.
Una vez completado, aparecerá el siguiente mensaje.

C
CA
AP
PI
IT
TU
UL
LO
O 4
4
 Administración de la Seguridad
 Modos de autenticidad
 Creación de Usuarios
 Uso de Credenciales y Permisos

A D M I N I S T R A C I Ó N D E L A S E G U R I D A D
La seguridad es una consideración primordial cuando se diseña y administra un entorno de
base de datos, aquí, daremos a conocer los componentes fundamentales de seguridad de
SQL Server: entidades de seguridad, protegibles y el modo en que se aplican los permisos
dentro del modelo de seguridad de SQL Server.
¿Qué son las entidades de seguridad?
SQL Server 2008 emplea el término entidad de seguridad para referirse a las identidades
autenticadas en un sistema de SQL Server. La comprensión de las diferentes entidades de
seguridad que pueden existir en un sistema de SQL Server le ayudará a planear su modelo de
seguridad.
Una entidad de seguridad es cualquier identidad autenticada a la que se puede conceder
permiso para tener acceso a un objeto del sistema de base de datos. SQL Server distingue
entre entidades principales indivisibles, que son identidades únicas (como, por ejemplo, inicios
de sesión), y entidades de seguridad de colección, que son colecciones de identidades (tales
como funciones fijas de servidor).
Las entidades de seguridad existen en tres niveles: Microsoft Windows®, SQL Server y
base de datos. Los tipos de entidad de seguridad posibles en cada uno de estos niveles

se muestran en la tabla siguiente.
Nivel Entidades de seguridad
Windows Cuenta de usuario local de Windows
Cuenta de usuario de dominio de Windows
Grupo de Windows
SQL Server Inicio de sesión de SQL Server
Función de SQL Server
Base de datos Usuario de la base de datos
Función de la base de datos
Función de aplicación
Grupo de bases de datos (sólo para
compatibilidad con versiones anteriores)
Nota Los grupos de bases de datos se admiten principalmente por motivos de compatibilidad
con versiones anteriores. Debería usar las funciones de base de datos para crear entidades de
seguridad de colección en el nivel de base de datos.
¿Qué son los protegibles?
Los objetos cuyo acceso está regulado por el sistema de autorización de SQL Server 2008 se
denominan protegibles. Como ocurre con las entidades de seguridad, es necesario comprender
los diferentes ámbitos de los protegibles en SQL Server para planear su modelo de seguridad.
Los protegibles se organizan en jerarquías anidadas llamadas ámbitos, que también se pueden
proteger. Los tres ámbitos protegibles son servidor, base de datos y esquema. Los protegibles
en el nivel de Windows incluyen archivos y claves del Registro.
El ámbito de servidor Los protegibles que contiene el ámbito de servidor
incluyen:
■ Inicios de sesión
■ Extremos
■ Bases de datos

El ámbito de base de datos Los protegibles que contiene el ámbito de base de
datos incluyen:
■ Usuarios
■ Funciones
■ Funciones de aplicación
■ Certificados
■ Claves simétricas
■ Claves asimétricas
■ Ensamblados
■ Catálogos de texto completo
■ Eventos DDL
■ Esquemas
El ámbito de esquema Los protegibles que contiene el esquema incluyen:
■ Tablas
■ Vistas
■ Funciones
■ Procedimientos
■ Tipos
■ Sinónimos
■ Agregados
Nota Tenga en cuenta que una entidad de seguridad también puede ser un protegible. Por
ejemplo, un inicio de sesión es una entidad de seguridad, pero también se pueden otorgar
permisos en ese inicio de sesión a otros inicios de sesión, lo que lo convierte en un protegible.
Permisos de SQL Server 2008
SQL Server 2008 usa permisos para controlar el acceso a los protegibles por parte de
entidades de seguridad. Para planear su modelo de seguridad para la base de datos, es
importante entender cómo se implementan los permisos en los ámbitos de los protegibles.

Los permisos son las reglas que gobiernan el nivel de acceso de las entidades de seguridad a
los protegibles. Se pueden otorgar, revocar o denegar permisos en un sistema de SQL Server.
Todos los protegibles de SQL Server tienen permisos asociados que pueden otorgarse a cada
entidad de seguridad.
Ejemplo de permiso
La única manera de que una entidad de seguridad pueda tener acceso a un recurso en un
sistema de SQL Server es recibir permiso para ello, directa o indirectamente a través de la
suscripción de una entidad secundaria como una función o un grupo. Puede administrar los
permisos usando el Explorador de objetos en SQL Server Management Studio o mediante la
ejecución de instrucciones GRANT, REVOKE o DENY.
Los permisos concretos asociados a cada uno de los protegibles varían según los tipos de
acciones que son compatibles con un protegible.
Permisos heredados
Determinados permisos en SQL Server 2008 se pueden heredar a través de un permiso
concedido en un nivel más alto de la jerarquía de ámbito del protegible. Por ejemplo:
■ Una entidad de seguridad a la que se le ha concedido el permiso SELECT en un esquema
hereda automáticamente el permiso SELECT en todos los objetos del esquema.
■ Una entidad de seguridad a la que se la ha concedido el permiso CONTROL en un objeto de
base de datos hereda automáticamente el permiso CONTROL en todos los protegibles que
contiene esa base de datos y todos los protegibles que contienen los esquemas incluidos en
esa base de datos.
Permisos efectivos
Los permisos efectivos para una entidad de seguridad se evalúan de la misma manera que en
versiones anteriores de SQL Server. Una entidad de seguridad puede realizar una acción
determinada si:
■ El permiso se ha concedido explícitamente a la entidad de seguridad o a una colección de la
que es miembro la entidad de seguridad, y…
■ El permiso no se ha denegado explícitamente a la entidad de seguridad o a una colección de
la que es miembro la entidad de seguridad.
Nota Una instrucción DENY explícita siempre reemplaza a una instrucción GRANT. Por
ejemplo, si a un usuario se le ha concedido explícitamente el permiso SELECT en una tabla
determinada pero es miembro de una función a la que se le ha denegado explícitamente el
permiso SELECT en la tabla, el usuario no podrá ejecutar una instrucción SELECT en la tabla.
¿Qué son los modos de autenticación de SQL Server?
SQL Server 2008 puede configurarse para usar uno de los dos modos de autenticación
siguientes:

Modo de autenticación de Windows. Los usuarios se autentican con Windows y se les concede
el acceso a SQL Server mediante un inicio de sesión asignado a su cuenta de Windows (o a un
grupo de Windows del que son miembros). Cuando se realiza la solicitud de conexión inicial, el
símbolo de acceso del usuario, que se emitió cuando se inició sesión en Windows, se presenta
a SQL Server y, si se encuentra un inicio de sesión coincidente, se concede al usuario el
acceso a SQL Server.
Modo de autenticación de Windows y SQL Server. Los usuarios que se conectan a SQL Server
mediante una conexión de confianza (una conexión de red a través de la cual se puede pasar
el símbolo de acceso de Windows del usuario) tienen acceso a SQL Server mediante la
autenticación de Windows. Además, SQL Server mantiene inicios de sesión no asignados a
usuarios de Windows y los usuarios pueden conectarse a SQL Server tras indicar un nombre
de inicio de sesión válido y la contraseña que SQL Server valida de forma independiente a
Windows. El modo de autenticación de Windows y SQL
Server se conoce a veces como modo mixto.
Nota Los inicios de sesión en SQL Server asignados a los usuarios de Windows se
conocen como inicios de sesión de Windows. Los inicios de sesión autenticados en
SQL Server se conocen como inicios de sesión de SQL.
Las necesidades de seguridad de sus entornos de servidor y de red determinarán el modo de
autenticación que se usará para SQL Server. Puede usar SQL Server Management Studio para
establecer el modo de autenticación de su servidor.
CUANDO USAR EL MODO DE AUTENTICACIÓN WINDOWS
Use el modo de autenticación de Windows en entornos de red en los que todos los usuarios
estén autenticados mediante cuentas de usuario de Windows.
La autenticación de Windows proporciona varias ventajas sobre la autenticación de SQL
Server, como por ejemplo:
Le permite agregar grupos de usuarios a SQL Server mediante la agregación de una cuenta de
inicio de sesión única.
Permite a los usuarios un rápido acceso a SQL Server sin tener que recordar otra cuenta de
inicio de sesión y contraseña.

CUANDO USAR EL MODO DE AUTENTICACIÓN SQL
Use el modo de autenticación de Windows y SQL Server cuando deba permitir que se conecten
a SQL Server usuarios o aplicaciones que no tienen las credenciales de Windows. A menos
que necesite específicamente conexiones a SQL Server que no sean de Windows, no debería
habilitar el modo de autenticación de Windows y SQL Server por las razones siguientes:
La autenticación de Windows no exige que los nombres de usuario y las contraseñas pasen por
la red al conectarse a SQL Server. En su lugar, se usa el símbolo de acceso de usuario de
Windows, lo que hace más segura la autenticación de Windows.
La autenticación de Windows requiere menos sobrecarga administrativa, ya que el acceso a
SQL Server puede lograrse mediante un inicio de sesión que se asigna a un grupo de
Windows, y la administración de cada uno de los usuarios se confina al dominio de Windows.
El modo de autenticación de Windows y SQL Server aumenta la superficie del sistema de SQL
Server, lo que lo hace más vulnerable ante cualquier ataque.
Importante Independientemente del modo de seguridad empleado, asegúrese de que
la contraseña para el inicio de sesión del administrador del sistema (sa) no esté en
blanco.
Cómo funcionan las directivas de contraseñas
En Microsoft Windows Server™ 2003 y 2008, puede usar la Directiva de grupo para definir las
configuraciones de usuarios y equipos para grupos de usuarios y equipos. Puede usar la
Directiva de grupo para configurar muchas opciones, incluidas las directivas de cuentas. Las
directivas de contraseñas son útiles para garantizar que todas las contraseñas sean lo
suficientemente complejas y que se cambien periódicamente para maximizar la seguridad y
evitar el acceso no autorizado.
En SQL Server 2008, las directivas de cuentas locales o de dominio se pueden aplicar a inicios
de sesión de SQL, así como a los inicios de sesión de Windows, cuando SQL Server se instala
en equipos que usan Windows Server 2003 / 2008 o posterior.

Directivas de complejidad de contraseñas
Las directivas de complejidad de contraseñas están diseñadas para disuadir los ataques de
fuerza bruta por medio del aumento del número de contraseñas posibles. Cuando se aplica la
directiva de complejidad de contraseñas, las nuevas contraseñas deben cumplir los requisitos
de directiva establecidos por la directiva de contraseñas de Windows. Un ejemplo de este tipo
de directiva sería:
La contraseña no contiene todo o parte del nombre de 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 (espacio, tabulación, retorno, etc.) o
por cualquiera de los caracteres siguientes: , . - _ #
La contraseña debe tener una longitud de siete caracteres como mínimo.
La contraseña contiene caracteres de tres de las cuatro categorías siguientes:
Abecedario inglés en mayúsculas (de la A a la Z)
Abecedario inglés en minúsculas (de la a a la z)
Dígitos en base decimal (del 0 al 9)
Caracteres no alfanuméricos (por ejemplo: !, $, #, o %)
Directiva de caducidad de contraseña
Las directivas de caducidad de contraseñas se usan para administrar el tiempo de vida de una
contraseña. Cuando se usa una directiva de caducidad de contraseñas, se recuerda a los
usuarios que cambien las contraseñas anteriores y las cuentas con contraseñas caducadas se
deshabilitan.
Cómo administrar inicios de sesión de SQL Server
Puede administrar los inicios de sesión mediante el Explorador de objetos en SQL Server
Management Studio o por medio de la ejecución de las instrucciones Transact-SQL CREATE
LOGIN, ALTER LOGIN y DROP LOGIN.

Nota De manera predeterminada, SQL Server está configurado para usar el modo de
autenticación de Windows. Todavía puede crear inicios de sesión de SQL, pero no podrán
conectarse al servidor hasta que se cambie el modo de autenticación al modo de autenticación
de Windows y SQL Server.
CREANDO INICIOS DE SESIÓN
Puede usar la instrucción CREATE LOGIN para crear inicios de sesión de Windows o SQL
Server. Las opciones concretas que puede usar dentro de la instrucción CREATE LOGIN
dependen de si está creando un inicio de sesión de Windows o un inicio de sesión de SQL
Server.
El ejemplo siguiente muestra una instrucción CREATE LOGIN que crea un inicio de sesión de
Windows para un grupo de Windows local denominado SalesDBUsers:
CREATE LOGIN [SERVERXVendedor]
FROM WINDOWS
WITH DEFAULT_DATABASE = AdventureWorks
SQL:
CREATE LOGIN DRamos
WITH PASSWORD = 'Pa$$w0rd',
DEFAULT_DATABASE = AdventureWorks
Las cuentas de usuario de Windows están sujetas a directivas de contraseñas aplicadas por
Windows. SQL Server 2008 proporciona restricciones de directiva similares para inicios de
sesión de SQL cuando está instalado en Windows Server 2003/2008. Cuando una directiva de
contraseñas está habilitada para el servidor, SQL Server la habilita de forma predeterminada
para nuevos inicios de sesión de SQL; puede cambiar este comportamiento mediante las
opciones de la instrucción CREATE LOGIN mostradas
en la tabla siguiente.
Opción Descripción
HASHEDloca Especifica que la contraseña ya se ha comprobado
aleatoriamente. Si no está especificada, la cadena se
comprobará aleatoriamente antes del almacenamiento.
MUST_CHANGE Solicita a un inicio de sesión que cambie su contraseña la
primera vez que se conecta. Si se especifica esta opción,

CHECK_EXPIRATION y CHECK_POLICY deben
establecerse en ON.
CHECK_EXPIRATION Cuando se encuentra en ON (el valor predeterminado), esta
opción especifica que la directiva de caducidad de
contraseñas de Windows Server 2003/2008 debería
aplicarse al inicio de sesión de SQL Server. Si esta opción
se encuentra en ON, la opción CHECK_POLICY también
debe estar en ON o se producirá un error en la instrucción.
CHECK_POLICY Cuando se encuentra en ON (el valor predeterminado), esta
directiva especifica que la directiva de complejidad de
contraseñas de Windows Server 2003/2008 debería
aplicarse al inicio de sesión de SQL Server.
SQL que no está sujeto a la directiva de contraseñas definida para el servidor:
CREATE LOGIN LeoRamos
WITH PASSWORD = 'password',
DEFAULT_DATABASE = AdventureWorks,
CHECK_EXPIRATION = OFF,
CHECK_POLICY = OFF
Importante CHECK_EXPIRATION y CHECK_POLICY sólo se aplican en Windows Server
2003/2008 y posteriores. Además, un problema conocido en Windows Server 2003 podría
evitar que se restablezca el recuento de la contraseña incorrecta una vez se haya alcanzado el
umbral de bloqueo. Esto podría producir un bloqueo inmediato en los subsiguientes intentos
fallidos de inicio de sesión. Puede restablecer manualmente el recuento de la contraseña
incorrecta con solo establecer CHECK_POLICY = OFF, seguido por CHECK_POLICY = ON.
MODIFICANDO INICIOS DE SESIÓN
Puede modificar un inicio de sesión viendo sus propiedades en el Explorador de objetos o
mediante la ejecución de la instrucción ALTER LOGIN. Un uso común de la instrucción ALTER
LOGIN es desbloquear un inicio de sesión bloqueado por una contraseña caducada. El ejemplo
siguiente muestra cómo desbloquear una cuenta bloqueada:
ALTER LOGIN dRamos WITH PASSWORD = 'NewPa$$w0rd' UNLOCK
Eliminando inicios de sesión
Puede eliminar un inicio de sesión haciendo clic sobre él con el botón secundario en el
Explorador de objetos y haciendo clic a continuación en Eliminar, o ejecutando la instrucción
DROP LOGIN como se muestra en el ejemplo siguiente:
DROP LOGIN dRamos
¿Qué son las funciones fijas de servidor?
Las funciones proporcionan un medio de agrupar usuarios en una sola unidad a la que se
pueden aplicar permisos.

SQL Server proporciona funciones de servidor predefinidas para funciones administrativas
comunes, de manera que resulte sencillo otorgar una selección de permisos administrativos a
un usuario determinado. Las funciones fijas de servidor proporcionan agrupaciones de
privilegios administrativos en el nivel de servidor. Se administran de forma independiente a las
bases de datos de usuarios en el servidor.
Además de las funciones fijas de servidor mostradas en la tabla anterior, cada instancia de
SQL Server contiene una función fija de servidor especial denominada pública, de la que todos
los inicios de sesión son miembros. La función fija de servidor pública recibe el permiso VIEW
ANY DATABASE.
Asignar una cuenta de inicio de sesión a una función fija de servidor
Puede usar las Propiedades de inicio de sesión de SQL Server en SQL Server Management
Studio o el procedimiento almacenado del sistema sp_addsrvrolemember para agregar una
cuenta de inicio de sesión como un miembro de una función fija de servidor. Sólo los miembros
de funciones fijas de servidor pueden ejecutar el procedimiento almacenado del sistema
sp_addsrvrolemember.
Al agregar una cuenta de inicio de sesión a una función de servidor, la cuenta consigue los
permisos asociados a la función de servidor.
Para asignar cuentas de inicio de sesión a funciones fijas de servidor, tenga en cuenta los
puntos siguientes:
No puede agregar, modificar o eliminar funciones fijas de servidor.
Cualquier miembro de una función fija de servidor puede agregar otras cuentas de inicio de
sesión a esa función.
El procedimiento almacenado del sistema sp_addsrvrolemember no puede ejecutarse dentro
de una transacción definida por el usuario.
También puede usar el procedimiento almacenado del sistema sp_dropsrvrolemember para
eliminar un miembro de una función fija de servidor

Requisitos para la delegación
SQL Server y Windows se pueden configurar para permitir que una instancia de SQL Server se
conecte a otra instancia de SQL Server en el contexto de un usuario de Windows autenticado.
Esta técnica se conoce como delegación.
Por ejemplo, un procedimiento almacenado en una base de datos en Servidor1 podría
consultar una tabla en una base de datos en Servidor2. Cuando se usa la delegación, el
procedimiento almacenado usa la identidad de seguridad del usuario que lo llamó al solicitar los
datos desde Servidor2.
Requisitos para la delegación
Para usar la delegación, todos los servidores a los que está conectando deben tener instalado
Windows 2003 o Windows Server 2008 con el soporte técnico de Kerberos habilitado; además,
debe estar usando el servicio de directorios de Active Directory®.
Windows Server 2008 admite una delegación más concreta que las versiones anteriores de
Windows. Windows Server 2003 permite la concesión de derechos de delegación a
determinadas combinaciones de servicios. Se dice que estas combinaciones son de confianza
para la delegación restringida. Esta configuración es la configuración preferida y más segura en
dominios que tienen la funcionalidad completa de Windows Server 2003/2008.
Configurar Active Directory para la delegación
Debe establecer las opciones de cuenta siguientes en Active Directory para que la delegación
funcione:
La cuenta es confidencial y no se puede delegar. No debe seleccionar esta opción para el
usuario que solicita la delegación.
La cuenta es de confianza para la delegación. Debe seleccionar esta opción para la cuenta de
servicio de SQL Server.
El equipo es de confianza para la delegación. Debe seleccionar esta opción para el equipo que
ejecuta SQL Server.
Configurar SQL Server para la delegación
Para usar la delegación de la cuenta de seguridad, SQL Server debe tener un Nombre principal
de servicio (SPN) asignado por el administrador de dominio de cuenta de Windows Server
2003 a la cuenta de servicio de SQL Server y debe usar un Protocolo de control de
transmisión/Protocolo de Internet (TCP/IP). Si el servicio de SQL Server se está ejecutando en
la cuenta LocalSystem, el servicio SQL Server registra un SPN automáticamente al inicio del
servicio y anula el registro cuando se cierra SQL Server.

¿Qué son las credenciales?
Una credencial es una representación alternativa de un inicio de sesión que contiene la
información de autenticación necesaria para conectarse a un recurso fuera de SQL Server. La
mayoría de las credenciales están compuestas por un inicio de sesión y una contraseña de
Windows. Las credenciales permiten a los usuarios que se conectan a SQL Server mediante el
modo de autenticación de SQL Server conectarse a Windows (u otros recursos) fuera de SQL
Server. Por ejemplo, un usuario conectado a SQL Server con un inicio de sesión de SQL podría
ejecutar un procedimiento almacenado
que llama a un servicio web ASP.NET que está configurado para la autenticación de Windows.
El procedimiento almacenado pasaría al servicio web el nombre de cuenta y la contraseña de
Windows en la credencial asignada al inicio de sesión de SQL Server.
CREANDO CREDENCIALES
Puede crear una credencial mediante el uso de SQL Server Management Studio o de la
instrucción CREATE CREDENTIAL de Transact-SQL. La sintaxis de la instrucción CREATE
CREDENTIAL puede verse en la siguiente muestra de código.
CREATE CREDENTIAL credential_name WITH IDENTITY = 'identity_name'
[ , SECRET = 'secret' ]
Las cláusulas y parámetros de la instrucción CREATE CREDENTIAL son como se describen a
continuación:
credential_name. Especifica el nombre de la credencial que se está creando.
credential_name no puede comenzar con el signo almohadilla (#). Las credenciales del sistema
empiezan por ##.
identity_name. Especifica el nombre de la cuenta que se va a usar al conectarse fuera del
servidor.
secret. Especifica el secreto requerido para superar la autenticación. Esta cláusula es opcional.
El ejemplo siguiente crea la credencial llamada AlterEgo. La credencial contiene el usuario de
Windows Francesca y la contraseña Pa$$w0rd.
CREATE CREDENTIAL AlterEgo WITH IDENTITY = 'ADVENTURE-WORKSFrancesca',
SECRET = 'Pa$$w0rd'
GO

Permisos de ámbito de servidor
Los protegibles del ámbito de servidor incluyen objetos como el mismo servidor, los inicios de
sesión y las bases de datos.
La tabla siguiente muestra algunos permisos de ejemplo en el ámbito de servidor. Para obtener
una lista completa de los permisos, consulte “Permisos” en los Libros en pantalla de SQL
Server.
Protegible Permiso Descripción
Servidor CONNECT_SQL
CREATE LOGIN
ALTER ANY LOGIN
CONTROLSERVER
Conectarse al servidor.
Crear un inicio de sesión.
Modificar cualquier inicio de
sesión en el ámbito de servidor.
Control administrativo de todo el
sistema.
Login ALTER
IMPERSONATE
Modificar el inicio de sesión.
Suplantar el inicio de sesión.
Base de datos CREATE TABLE
ALTER ANY USER
CONTROL
Crear una tabla en la base de
datos.
Modificar cualquier usuario de la
base de datos.
Control completo de la base de
datos.
Conceder los permisos a protegibles de ámbito de servidor
Para conceder permisos a protegibles en el ámbito de servidor:
Use el Explorador de objetos en SQL Server Management Studio para ver las propiedades del
inicio de sesión al que desea conceder los permisos.
En la ficha Elementos que pueden protegerse, agregue los protegibles requeridos y
establezca los permisos necesarios.
También puede otorgar permisos del ámbito de servidor mediante el uso de la instrucción
GRANT de Transact-SQL con la sintaxis siguiente:
GRANT { securable_permission [ ,...n ] }
[ON securable_type :: securable_name]
TO login [ ,...n ]
[ WITH GRANT OPTION ]
[ AS { group | role } ]
Las cláusulas y parámetros de la instrucción GRANT para protegibles del ámbito de servidor se
describen en la tabla siguiente.
Cláusula/Parámetro Descripción
securable_permission El permiso específico que se concede al protegible.
securable_type El tipo de protegible del ámbito de servidor al que se
aplica el permiso. Esta cláusula se omite si el permiso
se aplica al propio servidor.
securable_name El nombre del protegible del ámbito de servidor.

Inicio de sesión Un inicio de sesión al cual se otorga el permiso.
WITH GRANT OPTION Una opción que permite que el cesionario conceda el
mismo permiso a otros.
AS group | role Una especificación de una entidad de seguridad con los
permisos necesarios para conceder este permiso del
ámbito de servidor. Se requiere en escenarios en los
que el otorgante no tiene todos los permisos necesarios
para conceder el permiso, pero es miembro de una
función o grupo que sí los tiene.
El ejemplo siguiente muestra cómo otorgar el permiso de servidor ALTER ANY DATABASE y el
permiso ALTER a un inicio de sesión denominado AWWebApp para un inicio de sesión
denominado ADVENTUREWORKSNaty:
USE master
GRANT ALTER ANY DATABASE
TO [ADVENTUREWORKSNaty]
GRANT ALTER
ON LOGIN :: AWWebApp
TO [ADVENTUREWORKSNaty]
Cómo administrar usuarios
Los inicios de sesión se usan para permitir el acceso al sistema SQL Server. Sin embargo, el
acceso a cada una de las bases de datos se logra creando usuarios en esas bases de datos.
Puede crear usuarios mediante el uso del Explorador de objetos en SQL Server Management
Studio o la ejecución de la instrucción CREATE USER en la base de datos adecuada.
Asignar usuarios a inicios de sesión
En la mayoría de los casos, los usuarios de la base de datos están asignados a inicios de
sesión. Por ejemplo, podría crear una usuaria llamada Eliana en la base de datos
AdventureWorks para hacer que esa base de datos sea accesible para un inicio de sesión
denominado ADVENTUREWORKS Eliana. De forma predeterminada, todos los inicios de
sesión suscritos a la función fija de servidor sysadmin están asignados al usuario dbo en
todas las bases de datos.
Cuando se ha creado un inicio de sesión para un grupo de Windows, puede crear un usuario
para que el inicio de sesión permita que todos los usuarios de Windows del grupo tengan
acceso a la base de datos. Además, puede crear un usuario para un miembro individual del
grupo Windows incluso si no existe ningún inicio de sesión individual para ese usuario. Por
ejemplo, si un grupo de Windows local denominado DBSERVER1SalesUsers contiene los
usuarios de dominio ADVENTUREWORKSNaty y ADVENTUREWORKSLeyla, puede crear
un inicio de sesión único para el grupo DBSERVER1SalesUsers para dar acceso a SQL
Server a ambos usuarios. Por ejemplo, podría crear un usuario denominado SalesUsers en la

base de datos AdventureWorks que se asigne al inicio de sesión denominado
DBSERVER1SalesUsers para permitir que ambos usuarios tengan acceso a la base de datos.
Sin embargo, si deseara conceder los permisos concretos a Naty y no a Leyla, puede crear un
usuario denominado Naty en la base de datos AdventureWorks para
ADVENTUREWORKSNaty, aunque no hay ningún inicio de sesión individual para
ADVENTUREWORKSNaty. Cuando Marta tiene acceso a la base de datos AdventureWorks,
lo hace usando la identidad SalesUsers, pero cuando Rosa tiene acceso a la base de datos, lo
hace con la identidad Naty.
Ejemplo de creación de un usuario
Puede crear un usuario en SQL Server Management Studio mediante el uso del Explorador de
objetos o la instrucción CREATE USER de Transact-SQL, como se muestra en los ejemplos
siguientes:
-- Crear un usuario para un inicio de sesión con el mismo nombre
CREATE USER Leonardo
-- Crear un usuario con un nombre diferente a partir del inicio de sesión asignado
CREATE USER Angello FOR LOGIN [ADVENTUREWORKSAngello]
-- Crear un usuario con un esquema predeterminado explícitamente definido CREATE
USER SalesUser FOR LOGIN [DBSERVER1SalesUsers]
WITH DEFAULT_SCHEMA = 'Sales'
Modificar un usuario
Puede modificar un usuario cambiando sus propiedades en el Explorador de objetos o
mediante la ejecución de la instrucción ALTER USER.
Quitar un usuario
Puede quitar un usuario eliminándolo en SQL Server Management Studio o ejecutando la
instrucción DROP USER. Debe transferir la propiedad de los objetos de un usuario antes de
anularlo.
Usuarios especiales
Los usuarios especiales de una base de datos son usuarios predefinidos que tienen funciones
especiales como la de permitir el acceso administrativo o de invitado.

dbo
El inicio de sesión sa y los miembros de la función sysadmin están asignados a una cuenta de
usuario especial, que se encuentra dentro de todas las bases de datos, denominada dbo.
Cualquier objeto creado por un administrador del sistema pertenece automáticamente a dbo. El
usuario dbo es una cuenta predeterminada y no puede eliminarse.
invitado
La cuenta de usuario guest (invitado) permite inicios de sesión sin cuentas de usuario para
tener acceso a una base de datos. Las cuentas de inicio de sesión asumen la identidad del
usuario guest cuando se cumplen las condiciones siguientes:
La cuenta de inicio de sesión tiene acceso a SQL Server pero no tiene acceso a la base de
datos a través de su propia cuenta de usuario.
Se ha habilitado la cuenta de invitado.
La cuenta de invitado puede habilitarse mediante la instrucción GRANT para conceder el
permiso CONNECT al usuario invitado. El código siguiente muestra cómo habilitar la cuenta
de invitado en la base de datos AdventureWorks:
USE AdventureWorks
GRANT CONNECT TO guest;
GO
Los permisos se pueden aplicar al usuario invitado como si el usuario invitado fuera cualquier
otra cuenta de usuario. Puede habilitar al usuario invitado en cualquier base de datos excepto
la master y las bases de datos tempdb.
¿Qué son las funciones de base de datos?
SQL Server proporciona dos tipos de funciones en el nivel de base de datos: funciones fijas de
base de datos y funciones de base de datos definidas por el usuario.
Las funciones fijas de base de datos proporcionan a las agrupaciones privilegios
administrativos en el nivel de base de datos a las que se han concedido permisos para las

tareas comunes de la base de datos. Las funciones fijas de base de datos de una base de
datos se describen en la tabla siguiente.
Función Descripción
db_accessadmin Agregar o quitar usuarios, grupos y funciones de la
base de datos.
db_backupoperator Realizar una copia de seguridad de la base de
datos.
db_datareader Leer datos de cualquier tabla.
db_datawriter Agregar, cambiar o eliminar datos de cualquier
tabla.
db_ddladmin Agregar, modificar o eliminar objetos de la base de
datos.
db_denydatareader No poder leer los datos de ninguna tabla.
db_denydatawriter No poder cambiar los datos de ninguna tabla.
db_owner Realizar cualquier actividad de función de base de
datos.
db_securityadmin Cambiar las funciones de la base de datos, cambiar
las funciones de aplicación, crear esquemas.
public Mantener los permisos predeterminados.
La función public es una función fija de base de datos especial a la que pertenece cada
usuario de la base de datos y no se puede eliminar. La función public:
Mantiene todos los permisos predeterminados para los usuarios de una base de datos.
No puede tener usuarios, grupos o funciones asignados porque los usuarios, grupos y
funciones ya le pertenecen de forma predeterminada.
Está definida en cada base de datos, incluidas las bases de datos master, msdb, tempdb,
model y todas las bases de datos de usuario.
No se puede eliminar.
Sin los permisos adecuados, un usuario puede tener acceso a una base de datos de SQL
Server pero sólo podrá realizar tareas limitadas. Sin permisos, un usuario posee todos los
permisos que se conceden a la función public y puede realizar las acciones siguientes:
Ejecutar las instrucciones que no requieren permisos, como la instrucción PRINT.
Ver información de la tabla del sistema y ejecutar ciertos procedimientos almacenados del
sistema para la base de datos master y las bases de datos de usuario a las que tenga acceso.
Obtener acceso a cualquier base de datos con una cuenta de invitado habilitada
Funciones de base de datos definidas por el usuario
Cuando ninguna de las funciones fijas de base de datos se adecúa a sus propósitos, puede
crear sus propias funciones de base de datos para agrupar a varios usuarios que requieran los
mismos permisos en una base de datos. La creación de una función de base de datos definida
por el usuario le permite crear un grupo de usuarios con un conjunto de permisos comunes.
Puede crear una función de base de datos definida por el usuario mediante el Explorador de
objetos en SQL Server Management Studio o por medio de la instrucción CREATE ROLE de
Transact-SQL, como se muestra en los ejemplos siguientes:
USE AdventureWorks
CREATE ROLE auditors
Puede modificar o eliminar una función de base de datos definida por el usuario en el
Explorador de objetos o mediante el uso de las instrucciones ALTER ROLE y DROP ROLE de
Transact-SQL.
Asignar una entidad de seguridad a una función de base de datos

Después de crear una función, use el Explorador de objetos en SQL Server Management
Studio o el procedimiento almacenado del sistema sp_addrolemember para agregar usuarios
o funciones como miembros de la función. Sólo los miembros de las funciones fijas de servidor
sysadmin, db_securityadmin y db_owner o el propietario de la función pueden ejecutar
sp_addrolemember para agregar un miembro a una función de base de datos definida por el
usuario.
Considere los datos siguientes cuando asigne cuentas de seguridad a una función de base de
datos definida por el usuario:
Cuando agrega una cuenta de seguridad a una función, cualquier permiso aplicado a la función
se aplicará al nuevo miembro.
Cuando agrega una función de base de datos como un miembro de otra función de base de
datos, no es posible crear funciones recursivas. Por consiguiente, SalesManager no podría
agregarse como miembro de SeniorEmployee si SeniorEmployee ya fuera miembro de
SalesManager.
Para quitar una entidad de seguridad de una función de base de datos, use el Explorador de
objetos o el procedimiento almacenado del sistema sp_droprolemember.
¿Qué son las funciones de aplicación?
Las funciones de aplicación permiten cumplir con la seguridad para una aplicación
determinada. Proporcionan un contexto de seguridad alternativo para que un usuario tenga
acceso a una base de datos. El usuario ejecuta una aplicación asociada a una función de
aplicación y el contexto de seguridad de la función de aplicación se usa en lugar del usuario
individual.
Funciones de aplicación frente a otras funciones de base de datos
Las funciones de aplicación difieren de otras funciones. A continuación se muestra una lista de
las diferencias fundamentales entre las funciones de aplicación y otras funciones:
Las funciones de aplicación no tienen miembros: se activan para los usuarios cuando los
usuarios ejecutan la aplicación.
Las funciones de aplicación permiten que los usuarios dispongan de permisos especiales
cuando usan la aplicación y evitan la necesidad de conceder permisos directamente a los
usuarios.
Las funciones de aplicación exigen activar una contraseña.

Al activar una función de aplicación, los usuarios:
Pierden todos los permisos existentes en la base de datos actual para sus cuentas de usuario y
cualquier función a la que pertenezcan, salvo los permisos que se aplican a la función public.
Heredan todos los permisos concedidos a la función de aplicación en la base de datos actual.
Crear una función de aplicación
Use SQL Server Management Studio o el comando CREATE APPLICATION ROLE (Transact-
SQL) para crear una nueva función de aplicación. Sólo los miembros de las funciones
db_owner, db_securityadmin y sysadmin pueden crear funciones de aplicación; la
instrucción requiere el permiso ALTER ANY APPLICATION ROLE en la base de datos.
Cuando se crea una función de aplicación, debe especificarse una contraseña. Esta contraseña
se usa a continuación para activar la función de aplicación.
El ejemplo siguiente muestra cómo crear una función de aplicación denominada
weekly_receipts con una contraseña compleja:
CREATE APPLICATION ROLE weekly_receipts
WITH PASSWORD = '987Gbv876sPYY5m23'
GO
Activar una función de aplicación
El procedimiento almacenado sp_setapprole se usa para activar una función de aplicación.
sp_setapprole puede ejecutarse sólo mediante instrucciones Transact-SQL y no puede
ejecutarse dentro de otro procedimiento almacenado o dentro de una transacción definida por
el usuario.
El ejemplo siguiente muestra el procedimiento sp_setapprole utilizado para activar la función
de aplicación weekly_receipts creada en el ejemplo anterior:
EXEC sp_setapprole 'weekly_receipts', '987Gbv876sPYY5m23'
GO
Permisos de ámbito de base de datos
Los permisos de base de datos son permisos para que una entidad de seguridad pueda
ejecutar ciertas tareas dentro de la base de datos. Por ejemplo, el permiso ALTER ANY USER
permite que una entidad de seguridad cree, modifique y quite usuarios de una base de datos.

Los permisos del ámbito de base de datos son permisos que pueden aplicarse a protegibles en
el ámbito de base de datos, como usuarios, esquemas, funciones, ensamblados y objetos de
service broker. La tabla siguiente muestra algunos de los permisos del ámbito de base de
datos.
Usuario ALTER Modificar el usuario especificado.
Esquema SELECT Seleccionar filas de cualquier objeto del
esquema.
ALTER Modificar cualquier objeto del esquema.
TAKE OWNERSHIP Hacerse con la propiedad del esquema.
Permisos de ámbito de esquema
Los protegibles del ámbito de esquema incluyen objetos como tablas, vistas, procedimientos
almacenados y tipos.

La tabla siguiente muestra algunos de los permisos aplicables en el ámbito de esquema.
Esquema SELECT Seleccionar filas de cualquier
objeto del esquema.
ALTER Modificar cualquier objeto del
esquema.
TAKE OWNERSHIP Hacerse con la propiedad del
esquema.
Tabla SELECT Seleccionar filas de la tabla.
ALTER Modificar la tabla.
CONTROL Control completo de la tabla.
Concesión de permisos de protegible del ámbito de esquema
Puede conceder permisos a algunos de los protegibles de la base de datos mediante el uso del
Explorador de objetos en SQL Server Management Studio o por medio de la instrucción
GRANT de Transact-SQL. La sintaxis de la instrucción GRANT es diferente para los tipos
definidos por el usuario que para otros protegibles del ámbito de esquema. La sintaxis usada
para conceder permisos en un tipo definido por el usuario se muestra en el ejemplo siguiente,
que muestra cómo conceder el permiso EXECUTE en un tipo llamado addressType:
USE AdventureWorks
GRANT EXECUTE
ON TYPE :: Person.addressType
TO SalesUser
Para otros protegibles de ámbito de esquema (como tablas, vistas y procedimientos
almacenados), use la sintaxis mostrada en el ejemplo siguiente, que muestra cómo conceder el
permiso SELECT en una tabla llamada orders en el esquema sales:
USE AdventureWorks
GRANT SELECT
ON sales.orders
TO SalesUser

¿Qué son las claves?
Una clave es un valor que se puede aplicar a una función criptográfica para cifrar o descifrar un
valor de datos seguro. El algoritmo criptográfico que se usa para crear la clave y la longitud de
la clave determinan su complejidad. Las claves son la base fundamental para toda la
criptografía y se pueden implementar en dos formas: simétrica y asimétrica.
Claves simétricas
Una clave simétrica es un valor que se usa tanto para cifrar como para descifrar datos. Cuando
se usa una clave simétrica, deben compartirla tanto la persona o sistema que cifra los datos
como la persona o sistema que los descifra. SQL Server admite claves simétricas para la
encriptación de datos.
Puede crear una clave simétrica en SQL Server mediante la ejecución de la instrucción
CREATE SYMMETRIC KEY, como se muestra en el ejemplo de código siguiente:
CREATE SYMMETRIC KEY SymKey
WITH ALGORITHM = AES_256
ENCRYPTION BY PASSWORD = 'j7%ga5c$b+£hdb05'
Tenga en cuenta que debe cifrar la propia clave simétrica para mantenerla en secreto. En el
ejemplo anterior, se usa una contraseña para cifrar la clave simétrica. Las opciones alternativas
para cifrar una clave simétrica son usar un certificado, una clave asimétrica u otra clave
simétrica.
Claves asimétricas
Las claves asimétricas están compuestas de un par de valores que pueden usarse en una
función aritmética unidireccional de manera que los datos puedan cifrarse con un valor y
descifrarse con el otro.
Los pares de claves asimétricas están compuestos de una clave pública, que puede
compartirse públicamente, y una privada, que el propietario de la clave debe mantener en
secreto. Los datos cifrados con la clave pública sólo pueden descifrarse con la clave privada.

Además, la clave pública puede usarse para comprobar que una parte de los datos ha sido
cifrada por la clave privada (aunque no puede usarse
para descifrar los datos). Este enfoque se usa para crear una firma digital que puede usarse
para autenticar el origen de los datos.
Puede crear claves asimétricas en SQL Server mediante la ejecución de la instrucción
CREATE ASYMMETRIC KEY, como se muestra en el ejemplo siguiente:
CREATE ASYMMETRIC KEY AsymKey
WITH ALGORITHM = RSA_2048
ENCRYPTION BY PASSWORD = 'bmsA$dk7i82bv55'
Tenga en cuenta que la clave privada de una clave asimétrica se cifra con una contraseña. Si
se omite la cláusula ENCRYPTION BY PASSWORD, SQL Server cifra la clave privada con la
clave de base de datos para la base de datos en la que se crea la clave. Las claves de base de
datos se analizan más adelante en este módulo.
¿Qué son los certificados?
Los certificados son instrucciones firmadas digitalmente que asocian una clave pública a la
identidad de la persona o sistema que posee la clave privada correspondiente. Una entidad
emisora de certificados de confianza puede emitir los certificados y usarlos para autenticar un
gran número de usuarios sin necesidad de mantener una contraseña para cada usuario.
Contenido de un certificado
Un certificado suele contener la siguiente información:
La clave pública del sujeto (la persona o sistema al que se emitió el certificado).
La información identificativa del sujeto, como el nombre y la dirección de correo electrónico.
El período de validez. Ésta es el tiempo durante el que el certificado se considera válido.
Información identificadora y firma digital del emisor.
Certificados en SQL Server
SQL Server 2008 admite certificados para la autenticación, autorización y criptografía; también
proporciona la funcionalidad para crear, exportar e importar certificados, como se muestra en el
ejemplo de código siguiente:

-- crear un nuevo certificado
CREATE CERTIFICATE AWCustRelationsCert
ENCRYPTION BY PASSWORD = 'pGFD4bb925DGvbd2439587y'
WITH SUBJECT = 'Adventure Works Customer Relations',
EXPIRY_DATE = '31/10/2009'
-- Exportar el certificado
BACKUP CERTIFICATE AWCustRelationsCert
TO FILE = 'c:certsAWCustRelationsCert.cer'
-- Importar un certificado
CREATE CERTIFICATE SupplierCert
FROM FILE = 'c:certsSupplierCert.cer'
Arquitectura de criptografía de SQL Server
SQL Server 2008 usa una jerarquía de claves y certificados para implementar la funcionalidad
criptográfica. Cada nivel de la jerarquía se usa para proteger los elementos del nivel
inmediatamente inferior.
Clave principal de servicio
La Clave principal de servicio es una clave Triple DES en la base de la jerarquía de cifrado de
SQL Server 2008. Esta clave se genera automáticamente cuando se necesita por primera vez,
y está protegida por la protección de datos de Windows API (DPAPI).
Clave principal de base de datos
Una clave principal de base de datos es una clave simétrica Triple DES que se puede usar
para proteger las claves privadas de certificados y claves asimétricas de una base de datos.
Cuando se crea una clave principal de base de datos, se cifra mediante el uso del algoritmo
Triple DES y una contraseña proporcionada por el usuario. Para habilitar el descifrado
automático de la clave principal, una copia de la clave se cifra mediante el uso de la Clave
principal de servicio tanto en la misma base de datos como en la base de datos master.
La muestra de código Transact-SQL siguiente muestra cómo crear una clave principal de base
de datos.
USE AdventureWorks
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '23987hxJ#KL95234nl0zBe'

Claves y certificados en una base de datos
Puede crear claves y certificados en una base de datos para cifrar los datos confidenciales o
implementar una autenticación y autorización basadas en certificados. Las claves privadas en
una base de datos se pueden proteger mediante la clave principal de base de datos o mediante
una contraseña.
Cuándo usar claves y certificados
Hay varias maneras de usar claves y certificados en una solución de base de datos de SQL
Server.
Cifrado de datos
Puede usar claves y certificados para cifrar datos para el almacenamiento seguro en la base de
datos. SQL Server incluye las funciones en la tabla siguiente para cifrar y descifrar datos.
Funciones Descripción
EncryptByKey y
DecryptByKey
Use estas funciones para cifrar y descifrar datos con
una clave simétrica. Estas funciones requieren un
GUID que identifique la clave asimétrica que debe
usarse, lo que puede obtenerse llamando a la función
KeyGUID.
EncryptByAsymKey y
DecryptByAsymKey
Use estas funciones para cifrar y descifrar datos con
una clave asimétrica. Estas funciones requieren un Id.
que identifique la clave asimétrica que debe usarse, lo
que puede obtenerse llamando a la función
AsymKey_ID.
EncryptByCert y
DecryptByCert
Use estas funciones para cifrar y descifrar datos con un
certificado. Estas funciones requieren un Id. Que
identifique la clave asimétrica que debe usarse, lo que
puede obtenerse llamando a la función Cert_ID
Los algoritmos de criptografía asimétrica, como los usados por claves y certificados
asimétricos, son intensivos para el procesador y pueden conducir a la sobrecarga de
rendimiento cuando se usan para cifrar grandes cantidades de datos. Por esta razón,
generalmente debería cifrar los datos con una clave simétrica, que a su vez se cifra con una
clave asimétrica o un certificado.
Firma de módulos de código
Puede usar una clave asimétrica o un certificado para firmar un módulo de código, como un
procedimiento, función o desencadenador almacenado. Cualquier modificación subsiguiente en
un módulo de código firmado invalidará la firma. La firma y contrafirma sólo pueden realizarla
las personas con acceso a la clave privada.
Además de comprobar que el módulo de código no ha sido forzado, una firma crea una
identidad secundaria para el módulo de código. Puede crear un usuario a partir del certificado
usado para firmar el módulo de código mediante la cláusula FOR CERTIFICATE de la
instrucción CREATE USER y conceder permisos al usuario basado en certificados en lugar de
a los usuarios que ejecutarán el módulo de código.
Para firmar un módulo de código, la clave privada debe estar presente y usar la instrucción
ADD SIGNATURE como se muestra en el ejemplo siguiente:
ADD SIGNATURE TO Sales.AddOrder BY CERTIFICATE SalesDevCert
Contexto de suplantación
SQL Server 2008 proporciona la cláusula EXECUTE AS para controlar el contexto de
seguridad para la ejecución del módulo de código. Si un módulo de código que cambia de
contexto de ejecución usando la cláusula EXECUTE AS obtiene acceso a los recursos de otra
base de datos, la base de datos de destino debe confiar en el autenticador usado para

establecer el contexto de la suplantación para extender el contexto de la suplantación de la
base de datos de origen.
Una manera de extender el contexto de la suplantación por varias bases de datos es firmar el
módulo de código que contiene la cláusula EXECUTE AS con un certificado. La firma realiza
dos funciones: actúa como autenticador para el contexto de la suplantación y proporciona una
identidad secundaria para el módulo de código.
En la base de datos de destino, debe crear un usuario que esté asignado al certificado y
conceder el permiso AUTHENTICATE (si el código requiere permisos del ámbito de base de
datos) o el permiso AUTHENTICATE SERVER (si el código requiere permisos del ámbito de
servidor). Esto permite que el certificado usado como autenticador en la base de datos de
origen compruebe la identidad del módulo de código en la base de datos de destino.
También deben concederse al usuario asignado al certificado los permisos necesarios para
tener acceso a los objetos de base de datos referenciados por el módulo de código. Esto
permite usar la identidad secundaria del módulo de código firmado para tener acceso a los
recursos necesarios.
Autenticación entre servidores
Puede usar certificados para implementar la autenticación por las instancias del servidor para
el reflejo del service broker y de la base de datos. Esto permite que las instancias del servidor
se autentiquen entre sí para comunicarse de forma segura.

C
CA
AP
PI
IT
TU
UL
LO
O 5
5
 Transferencia de Datos
 Modos de Transferencia de Datos
 Introducción al SQL Server Integration Services

¿ Q U É E S L A T R A N S F E R E N C I A D E D A T O S ?
La transferencia de datos es el movimiento de datos entre almacenes de datos. El proceso
puede ser desde muy simple hasta muy complejo. Prácticamente todas las soluciones de
bases de datos requieren algún tipo de transferencia de datos. Normalmente, el proceso de
transferir datos de un sistema a otro implica los pasos siguientes:
■ Extraer datos del origen de datos.
■ Transformar los datos (opcional).
■ Cargar los datos en el almacén de datos de destino.
Escenarios comunes
Los siguientes son escenarios comunes para la transferencia de datos:
 Trasladar los datos a sistemas de almacenamiento de datos.
 Consolidar datos en un lugar a partir de varios orígenes. Por ejemplo, una oficina
comercial central puede contar con una base de datos con datos consolidados de todos
sus sistemas de almacenamiento remotos.
 Mover datos de un sistema heredado a un sistema nuevo.
 Mover datos de un sistema no relacional, como el de Excel® de Microsoft Office, a un
sistema relacional, como SQL Server 2008.
¿Qué es la transformación de datos?
Cuando seleccione datos para importarlos a su sistema, los datos podrían no estar en el
formato necesario o no cumplir con sus reglas de validación. Con la transformación de los
datos se pueden eliminar incoherencias. La transformación de los datos puede significar un
simple cambio de los tipos de datos o una transformación compleja mediante código de
procedimiento.

Cambiar el formato de los datos
Si integra datos de diferentes orígenes, a sus formatos serán diferentes. El cambio del formato
de los datos podría implicar la simple modificación del tipo de datos char a varchar, pero
también puede conllevar una transformación más compleja, como el cambio de un campo de
fecha basado en cadenas a un tipo de datos datetime.
Agregar los datos
A menudo, necesitará copiar datos desde un sistema de Procesamiento de transacciones en
línea (OLTP) a un Sistema de ayuda a la toma de decisiones (DSS). Con frecuencia, el DSS no
requiere la granularidad fina de datos del sistema OLTP. Un DSS suele generar informes
agregados, y la transformación de los datos podría mejorar el rendimiento mediante la
agregación previa de estos datos y su almacenamiento en un formulario resumido.
Mantener la coherencia de los datos
Al tratar con datos de sistemas diferentes, existe con frecuencia más de una versión de los
mismos datos. Los nombres, direcciones y números de teléfono tienen, por lo general,
ortografías o estructuras diferentes y la transformación de los datos puede garantizar la
coherencia en el destino.
Validar los datos
Si tiene cualquier duda sobre la validez de los datos de origen, debería validarlos antes de
colocarlos en el sistema de destino. Puede resolver automáticamente algunos errores de
validación, pero puede que necesite hacerlo manualmente en el caso de que los errores sean
más complejos.
Escenarios comunes
A continuación se presentan algunos escenarios habituales en los que se puede usar la
transformación de los datos:
Almacenamiento de datos. Los almacenes de datos son colecciones de datos de varios
orígenes, que con frecuencia necesitan un esquema diferente al de estos sistemas
originales y podrían contener datos agregados. Un almacén de datos es una
herramienta clave para la toma de decisiones, por lo que resulta fundamental que los
datos sean coherentes, válidos, y que se almacenen en la estructura adecuada.

Integración de aplicación empresarial (EAI). La EAI es el uso compartido de todos los
datos disponibles dentro de una organización. Será más eficaz si los datos son
coherentes y válidos.
Integración negocio a negocio (B2B). Los sistemas B2B necesitan asignar estructuras
de datos de una organización a las de otra.
Integración con un sistema heredado. Muchas compañías confían en exceso en
sistemas heredados, que a menudo generan datos en un formato que no es el ideal
para el almacenamiento y el análisis en un sistema moderno. La transformación de los
datos modifica su estructura y formato antes de cargarlos en el nuevo sistema.
Herramientas para la transferencia de datos
SQL Server 2008 tiene varias herramientas para transferir datos. Cada una de ellas es
adecuada para escenarios concretos.
Programa de copia masiva
Un Programa de copia masiva (PCM) es un programa de línea de comandos para importar y
exportar los datos a archivos de texto. Es una herramienta útil cuando es necesario importar o
exportar datos desde la línea de comandos o un archivo de proceso por lotes; proporciona un
rendimiento rápido con una carga mínima para el sistema.
BULK INSERT
BULK INSERT es la versión de Transact-SQL del PCM y tiene muchos de los mismos
parámetros. Es útil cuando es necesario incluir la funcionalidad de importación de datos en su
lógica de Transact-SQL.
Componente de carga masiva XML
La Carga masiva XML es un Modelo de objetos componente (COM) independiente que le
permite cargar los datos del Lenguaje de marcado extensible (XML) en las tablas de SQL
Server. Debería usar el componente Carga masiva de XML cuando necesite importar una gran
cantidad de datos XML y distribuirlos en una o más tablas relacionales.
Réplica
La réplica es útil cuando dos o más sistemas tienen la misma estructura y no es necesario
transformar los datos. Los cambios en el sistema editor se replican en los suscriptores con una
frecuencia preconfigurada y algunas formas de réplica permitirán que los propios suscriptores

modifiquen los datos. La réplica no es adecuada si los datos deben transformarse o si
proceden de un sistema no relacional.
SQL Server Integration Services
Los SQL Server Integration Services son un sistema mucho más avanzado para la
transferencia y transformación de los datos. Proporciona una arquitectura flexible, rápida y
escalable que permite la integración de datos de forma eficaz en entornos empresariales
actuales. La transferencia y transformación de los datos puede ser muy sencilla mediante los
SSIS, pero también puede conllevar una compleja asignación y validación de datos.
Introducción a SQL Server Integration Services
SSIS es una aplicación compleja. SSIS tiene dos motores: un motor en tiempo de ejecución y
un motor de flujo de datos. El motor de flujo de datos controla las tareas de extracción,
transformación y carga; el motor en tiempo de ejecución controla todo lo demás, incluidas la
repetición y la comunicación con procesos externos.
¿QUÉ ES SSIS?
SQL Server 2008 Integration Services (SSIS) es una plataforma para generar soluciones de
integración de datos de alto rendimiento, incluidas la extracción, la transformación y la carga
(ETL) de paquetes para el almacenamiento de datos. SSIS se compone de un motor en tiempo
de ejecución orientado a operaciones y de un motor de flujo de datos escalable y rápido. El
flujo de datos existe en el contexto de un flujo de tareas global.
El motor en tiempo de ejecución es el que proporciona el recurso en tiempo de ejecución y el
soporte operativo para el motor de flujo de datos.
Herramientas y asistentes de SSIS
SSIS incluye las herramientas y asistentes siguientes, que pueden usarse para crear,
configurar, implementar y ejecutar paquetes SSIS:
Diseñadores. SSIS ofrece diseñadores integrados en SQL Server Business Intelligence
Development Studio. Juntos, proporcionan el principal entorno de desarrollo para crear
paquetes SSIS.
Herramientas administrativas. SSIS incluye varias herramientas administrativas que se pueden
usar solas, o bien, se puede obtener acceso a ellas desde SQL Server Management Studio.

Estas herramientas administrativas pueden usarse para configurar, implementar y ejecutar
paquetes SSIS.
Utilidades del símbolo de sistema. SSIS incluye utilidades del símbolo de sistema que pueden
usarse para ejecutar paquetes SSIS desde la línea de comandos o en un archivo de proceso
por lotes.
Asistentes. Los asistentes de SSIS proporcionan una sencilla interfaz de usuario que puede
usarse para llevar a cabo las tareas SSIS más habituales.
Terminología SSIS
Cuando se crea una solución SSIS, es importante entender la terminología siguiente:
Paquete. Un paquete es una colección organizada de conexiones, elementos de flujo de
control, elementos de flujo de datos, controladores de eventos, variables y configuraciones que
se ensamblan mediante las herramientas de diseño gráfico que proporciona SSIS o que se
generan mediante programación. A continuación, se debe guardar el paquete finalizado en
SQL Server 2008, el Almacén de paquetes SSIS o el sistema de archivos.
El paquete es la unidad de trabajo que se recupera, se ejecuta y se guarda.
Tarea. Las tareas realizan el trabajo en paquetes. SSIS incluye tareas para la realización de
diversas funciones.
Contenedor. Los contenedores son objetos que proporcionan la estructura a los paquetes.
Admiten los flujos de control repetidos en paquetes y agrupan tareas y otros contenedores en
unidades de trabajo significativas.
CÓMO PROCESA SSIS LAS TAREAS
Un paquete está compuesto por un flujo de control y, opcionalmente, por uno o más flujos de
datos.
Flujo de control
SSIS tiene tres tipos de componentes de flujo de control: contenedores, tareas y restricciones
de precedencia.

 Los contenedores agrupan las tareas en unidades significativas de trabajo y son
compatibles con la repetición a través del contenedor para cada miembro de una
colección o hasta que una expresión determinada se evalúa como FALSE.
 Las tareas realizan el trabajo en paquetes. Las tareas pueden:
o Extraer, transformar y cargar datos.
o Copiar datos.
o Comunicarse con otros procesos.
o Trabajar con objetos y datos de SQL Server.
o Trabajar con objetos de Analysis Services y procesarlos.
o Ejecutar trabajos administrativos como copias de seguridad.
 Las tareas también contienen secuencias de comandos para implementar
funcionalidades personalizadas.
 Las restricciones de precedencia crean una secuencia ordenada de ejecución para los
contenedores y las tareas.
Flujo de datos
El flujo de datos es un tipo especial de tarea dentro de un flujo de control. SSIS tiene tres tipos
de componentes de flujo de datos: orígenes, destinos y transformaciones.
■ Los orígenes extraen los datos de una amplia gama de almacenes de datos que incluyen
bases de datos relacionales, archivos de texto y hojas de cálculo.
■ Las transformaciones modifican los datos entre el origen y el destino, e incluyen la validación,
agregación y asignación de datos.
■ Los destinos cargan los datos en cualquiera de los almacenes de datos.
HERRAMIENTAS SSIS
SSIS cuenta con una amplia gama de asistentes y herramientas con las que es posible
desarrollar paquetes con rapidez.
Asistentes
SSIS incluye las herramientas y asistentes siguientes, que pueden usarse para crear y
administrar paquetes SSIS:
 El Asistente para importación y exportación es el método más simple de crear un
paquete. Puede importar y exportar de SQL Server, archivos de texto, Microsoft Office
Access, Excel, BD OLE y proveedores de Microsoft ADO.NET.
 El Asistente para la instalación de paquetes transfiere los paquetes al sistema de
archivos o a otra instancia de SQL Server 2008. Antes de ejecutar el Asistente para la
instalación de paquetes, debe construir una utilidad de implementación para el proyecto
que contiene los paquetes que desea implementar.
 El Asistente para la configuración de paquetes crea configuraciones para cambiar los
valores de las propiedades de objeto en tiempo de ejecución.
 El Asistente para la migración de paquetes convierte los paquetes de los Servicios de
transformación de datos (STD) de SQL Server 2000 en paquetes SSIS de SQL Server
2008.
Diseñador SSIS
El Diseñador SSIS es una herramienta gráfica para crear paquetes. Puede usarla para crear el
flujo de control o el flujo de datos, agregar controladores de eventos, ver el contenido del
paquete y ver el progreso de ejecución en tiempo de ejecución. El flujo de control, el flujo de
datos, los controladores de eventos y el Explorador de paquetes tienen una ficha cada uno en
el Diseñador SSIS y una ficha Progreso aparece cuando un paquete se está ejecutando. Hay
también un área de Administradores de conexión para agregar y configurar los administradores
de conexión que usa un paquete para conectarse a los datos.
Utilidades del símbolo de sistema
SSIS incluye las siguientes utilidades del símbolo del sistema:

■ La utilidad del símbolo del sistema dtexec ejecuta un paquete en el equipo local. Puede usar
la utilidad Paquete de ejecución (dtexecui.exe) para administrar dtexec a través de un cliente
gráfico.
■ La utilidad del símbolo del sistema dtutil copia, elimina, mueve, firma y comprueba paquetes
desde el símbolo del sistema.
Usar SQL Server Integration Services
Para crear paquetes SSIS es necesario entender cómo se crea cada objeto. A menudo los
paquetes se crean en sistemas de desarrollo y se implementan en entornos de producción.
¿QUÉ SON LOS ORÍGENES DE DATOS Y LAS VISTAS DE ORIGEN DE DATOS?
SSIS incluye dos objetos en tiempo de diseño que facilitan la implementación de las
conexiones en paquetes: orígenes de datos y vistas de origen de datos.
Los orígenes de datos y las vistas de origen de datos se crean en un proyecto. A continuación,
estarán disponibles para cada paquete de ese proyecto. Los orígenes de datos y las vistas de
origen de datos son objetos en tiempo de diseño que no se implementan. En su lugar, SSIS
usa las propiedades de los orígenes de datos y las vistas de origen de datos para crear
administradores de conexiones.
Orígenes de datos
Un origen de datos es una referencia en tiempo real a una conexión de almacén de datos. Los
orígenes de datos no son necesarios, pero pueden acelerar el desarrollo de un proyecto o de
un paquete, dado que muchos administradores de conexión pueden usar el mismo origen de
datos.
El uso de orígenes de datos en paquetes SSIS proporciona las ventajas siguientes:
 Los orígenes de datos están disponibles para un proyecto completo. Puede definir un
origen de datos una vez y, a continuación, hacer referencia a él en los administradores
de conexión de varios paquetes dentro del proyecto.
 Cuando se crea un administrador de conexión mediante un origen de datos, el
administrador de conexión copia la cadena de conexiones del origen de datos. El

administrador de conexión no exige que el origen de datos funcione y que continúe
funcionando si el origen de datos no está disponible.
 Si cambia las propiedades de un origen de datos, las cadenas de conexión de todos los
objetos basadas en el origen de datos cambiarán.
Vistas de origen de datos
Una vista de origen de datos proporciona un subconjunto de datos de un origen de datos.
Puede incluir una o más tablas o vistas del almacén de datos definidas en el origen de datos y
puede aplicar un filtro a una vista de origen de datos para quitar las filas no deseadas. Puede
agregar columnas calculadas y nuevas relaciones entre las tablas y reemplazar las tablas en el
origen de datos con consultas.
Cuando un componente usa una vista de origen de datos, almacena una instrucción Transact-
SQL. Por consiguiente, el objeto no se ve afectado incluso si la vista de origen de datos no está
disponible. Si la vista de origen de datos cambia las tablas a las que hace referencia, este
cambio no se reflejará en los objetos basados en ella. El uso de vistas de orígenes de datos en
paquetes SSIS proporciona las ventajas siguientes:
 Una vista de origen de datos sólo puede mostrar los objetos pertinentes. Un origen de
datos mostrará cada tabla en el almacén de datos subyacente.
 Las vistas de origen de datos están disponibles para un proyecto completo. Puede
definir una vista de origen de datos una vez y, a continuación, hacer referencia a ella
en los objetos de varios paquetes dentro del proyecto.
 Puede actualizar una vista de origen de datos para reflejar los cambios en sus orígenes
de datos subyacentes.
 Una vista de origen de datos almacena en memoria caché los metadatos de los
orígenes de datos subyacentes, lo que le permite desconectarse del almacén de datos
subyacente y seguir editando las propiedades de la vista de origen de datos.
¿Qué es un administrador de conexión?
Un administrador de conexión es una representación lógica de una conexión. Se crea un
administrador de conexión en tiempo de diseño para describir la conexión física que SSIS crea
cuando el paquete se ejecuta. SSIS crea la conexión física mediante la cadena de conexión y
otros atributos del administrador de conexión.
Un paquete puede tener varios administradores de conexión, y cada administrador de conexión
puede tener atributos diferentes. Por esta razón, podría crear varios administradores de
conexión para el mismo almacén de datos, cada uno con propiedades ligeramente diferentes.

Tipos de administradores de conexión
Como se describe en la tabla siguiente, SSIS proporciona distintos tipos de administradores de
conexión que permiten que los paquetes se conecten a diversos orígenes de datos y
servidores.
Tipo Descripción
ADO Se conecta a orígenes de datos de Objetos de datos de
ActiveX® (ADO)
ADO.NET Se conecta a un origen de datos mediante un
proveedor .NET
EXCEL Se conecta a un archivo de libro de Excel
FILE Se conecta a un archivo o a una carpeta
FLATFILE Se conecta a un origen de datos de archivo plano
FTP Se conecta a un servidor de Protocolo de transferencia de
archivos (FTP)
HTTP Se conecta a un servidor web
MSMQ Se conecta a una cola de mensajes
MSOLAP100 Se conecta a una instancia de SQL Server 2008 Analysis
Services (SSAS) o a un proyecto de Analysis Services
MULTIFILE Se conecta a varios archivos y carpetas
MULTIFLATFILE Se conecta a varios archivos de datos y carpetas
OLEDB Se conecta a un origen de datos mediante un proveedor OLE
DB
ODBC Se conecta a un origen de datos mediante la Conectividad
abierta de bases de datos (ODBC)
SMOServer Se conecta a un servidor de Objetos de administración SQL
(SMO)
SMTP Se conecta a un servidor de correo de Protocolo simple de
transferencia de correo
SQLMOBILE Se conecta a una base de datos SQL Server Mobile
WMI Se conecta a un servidor y especifica el ámbito del Instrumental
de administración de Microsoft Windows® (WMI) en el servidor
¿QUÉ ES EL FLUJO DE CONTROL DE PAQUETES?
El flujo de control de paquetes es el proceso de control de la ruta de ejecución de un paquete.
Puede implantar condiciones para controlar la secuencia de las tareas basándose en el éxito o
error de una tarea anterior o en los resultados de una expresión.
Puede agrupar tareas con propósitos organizativos o para proporcionar capacidades
transaccionales. También puede repetir grupos de tareas para ejecutar la tarea un cierto
número de veces o para cada miembro de una colección.

Tareas
Las tareas realizan el trabajo en paquetes. La más importante es la tarea de flujo de datos.
Puede haber varias tareas de flujo de datos dentro de un paquete, y cada una puede
representar varias operaciones de datos ETL. Otras tareas pueden realizar muchas
operaciones diferentes, desde enviar correos electrónicos hasta recibir datos de servicios web.
Restricciones de precedencia
Las restricciones de precedencia combinan tareas. En su forma más simple, las restricciones
de precedencia permiten un flujo estructurado de operación a través de un paquete. Sin
embargo, las restricciones de precedencia pueden ser condicionales y permitir que el proceso
se ramifique en base a ciertas condiciones.
Puede usar el éxito, error o finalización (éxito o error) de la tarea anterior para controlar la ruta
de ejecución. Las restricciones de precedencia también pueden comprobar si una expresión se
evalúa como Verdadera, y esta expresión se puede usar en lugar de, o además de, la
restricción de finalización.
Contenedores
Los contenedores permiten agrupar o repetir las tareas.
Los contenedores de secuencias pueden agrupar tareas para su organización. También puede
usarlos como ámbito para una variable, para mantener la privacidad de los valores frente a
otras operaciones y como base para transacciones. Puede establecer el soporte transaccional
y el nivel de aislamiento a nivel de contenedor de secuencias en lugar de tener que establecer
las propiedades de cada tarea individualmente.
El contenedor Foreach Loop repite las tareas para cada miembro de una colección. Por
ejemplo, podría repetir una importación para cada archivo de una carpeta, o una acción podría
realizarse en cada fila de una tabla.
Los contenedores For Loop repiten una colección de tareas una o dos veces según la
evaluación de una expresión. Antes de usar un contenedor For Loop, debe crear una variable.
A continuación, use el contenedor For Loop para establecer un valor inicial (InitExpression),
una iteración (AssignExpression) y una evaluación (EvalExpression) para esta variable. Por
ejemplo, si tuviera una variable llamada Contador, podría establecer un valor inicial de
@Contador=1, una iteración de
@Contador=@Contador+1, y una evaluación de @Contador<4. Esto repetiría el código
cuatro veces. La cuarta vez, el valor Contador se establecería en 4 y el bucle finalizaría.

¿Qué es una tarea de flujo de datos?
La tarea de flujo de datos es una tarea especial que abarca las operaciones de extracción,
transformación y carga de SSIS. Aparece en la página Flujo de control como una tarea normal,
pero tiene su propia ficha porque está compuesta por varios componentes.
El origen extrae datos de almacenes de datos relacionales y no relacionales, como bases de
datos de SQL Server, hojas de cálculo de Excel y bases de datos de Analysis Services.
La transformación transforma los datos mediante la asignación del origen al destino y la
limpieza, agregación y modificación de los datos y del esquema. El destino carga datos en
almacenes de datos o los almacena en conjuntos de datos en memoria.
Origen
El origen es la conexión al almacén de datos del que necesita extraer datos.
Normalmente genera un resultado compuesto por varias columnas. Muchos orígenes también
tienen una salida de error que tiene todas las columnas de la salida normal más dos columnas
adicionales para la información de errores. Aunque la mayoría de los orígenes sólo tienen una
salida normal, puede codificar y personalizar los orígenes para tener varias salidas normales y
varias salidas de error.
Transformación
Una transformación puede ser una simple columna que se asigna entre el origen y el destino,
pero también puede realizar complejas operaciones de modificación y limpieza en los datos.
Las transformaciones tienen una entrada y una salida normal, cada una de ellas compuesta de
una o más columnas. También pueden tener una salida de errores.
Las transformaciones son los componentes del flujo de datos de un paquete que agregan,
combinan, distribuyen y modifican los datos. También pueden realizar las operaciones de
búsqueda y generar conjuntos de datos de muestra.
Destinos
El destino es la conexión al almacén de datos en el que necesita cargar datos. Tiene por lo
menos una entrada, que tiene por lo menos una columna. Un destino puede dar salida a
información de errores así como recibir datos. Puede codificar y personalizar los destinos para
tener varias entradas y salidas de errores.

Cómo implementar paquetes
SSIS cuenta con herramientas y características para implementar paquetes de un sistema a
otro. El proceso de implementar paquetes consta de tres pasos:
1. Definir las configuraciones de paquetes.
2. Configurar la utilidad de implementación y generar el proyecto.
3. Copiar e implementar la generación.
Configuraciones de paquetes
Las configuraciones de paquetes permiten actualizar los valores de propiedades en tiempo de
ejecución. Esto es particularmente útil al trasladar un paquete de un sistema de desarrollo a un
sistema de producción. Los nombres de servidor y las cadenas de conexión probablemente
habrán cambiado y las configuraciones de paquetes pueden automatizar el proceso de
modificación de estos valores.
Los valores que desea aplicar se pueden almacenar en archivos XML, tablas SQL Server,
entradas del Registro o variables de entorno o de paquetes. Se puede agregar una referencia a
esta ubicación de almacenamiento agregando una nueva configuración desde el menú SSIS de
Business Intelligence Development Studio. El Asistente para la configuración de paquetes se
ejecuta automáticamente y le guiará a través del proceso de creación de una configuración de
paquetes.

C
CA
AP
PI
IT
TU
UL
LO
O 6
6
 Automatización de Tareas Administrativas
 Beneficios de la Automatización
 Uso del SQL Server Agent
 Creando Trabajos y Operadores
 Monitoreando los trabajos
 Creación de Alertas

M O N I T O R E A N D O A L S Q L S E R V E R 2 0 0 8
La supervisión es importante porque SQL Server proporciona un servicio en un entorno
dinámico. Los datos de la aplicación cambian, el tipo de acceso que los usuarios requieren
cambia y la manera en que los usuarios se conectan cambia. SQL Server administra
automáticamente recursos a nivel de sistema como la memoria y el espacio en disco, pero la
supervisión permite a los administradores identificar las tendencias de rendimiento para
determinar si es necesario efectuar cambios.
¿Qué es el Monitor de actividad?
El Monitor de actividad es una herramienta gráfica de SQL Server Management Studio que
muestra información sobre los procesos de usuario y bloqueos actuales. Puede usar el Monitor
de actividad para solucionar problemas de simultaneidad, como los retrasos excesivos en
consultas, mientras se liberan los bloqueos o los procesos paralizados que tienen lugar cuando
dos procesos esperan a que se liberen los bloqueos y ninguno de ellos puede continuar.
Páginas del Monitor de actividad
El Monitor de actividad muestra información sobre las conexiones abiertas y los bloqueos
actuales. Puede ver información en el Monitor de actividad en tres páginas:
Información del proceso, Bloqueos por proceso y Bloqueos por objeto.
Información del proceso. En la página <Información del proceso, el Monitor de actividad
muestra una lista de todos los procesos de conexión del sistema. Cada proceso está
identificado por un único Id. de proceso y el Monitor de actividad muestra información sobre
cada proceso, como el acceso a la base de datos, el nombre de la aplicación cliente y el inicio
de sesión usado por el proceso. Los administradores de la base de datos pueden usar esta
página para determinar qué procesos están activos actualmente y finalizar un proceso si es
necesario.
Bloqueos por proceso. En la página Bloqueos por proceso, el Monitor de actividad muestra
todos los bloqueos y las solicitudes de bloqueo mantenidas por el proceso seleccionado. Los
administradores de la base de datos pueden usar esta página para identificar procesos que
están bloqueándose entre sí debido a bloqueos excesivos e interbloqueos.

Bloqueos por objeto. En la página Bloqueos por objeto, el Monitor de actividad muestra todos
los bloqueos y las solicitudes de bloqueo mantenidas en el objeto de base de datos
seleccionado. Los administradores de la base de datos pueden usar esta página para
solucionar los problemas de bloqueos con una tabla determinada u otro objeto de base de
datos.
¿Qué son los objetos de administración dinámica?
Puede usar vistas de administración dinámica y funciones de administración dinámica para
consultar metadatos dinámicos en SQL Server 2008; proporcionan información sobre el estado
actual de SQL Server, como los bloqueos actuales de una base de datos.
Vistas de administración dinámica
Las vistas de administración dinámica se muestran con vistas de catálogo en la carpeta Vistas
del sistema en el Explorador de objetos de SQL Server Management Studio.
Mientras que las vistas de catálogo se pueden usar para ver la información de configuración
estática, las vistas de administración dinámica devuelven el estado actual de actividad
dinámica de SQL Server. Las vistas de administración dinámica, al igual que las vistas de
catálogo, se definen en el esquema sys, pero sus nombres generalmente contienen el prefijo
dm para distinguirlas de las vistas de catálogo.
La tabla siguiente muestra algunas de las vistas de administración dinámica que suelen usarse.
Vista de administración dinámica Descripción
sys.dm_db_partition_stats Devuelve información sobre recuentos de páginas
y filas para cada partición de la base de datos
sys.dm_exec_sessions Devuelve información sobre todas las sesiones
actuales conectadas al servidor
sys.dm_io_pending_io_requests Devuelve información sobre las solicitudes de
entrada/salida (E/S) pendientes
sys.dm_os_memory_pools Devuelve información sobre cada caché de
objetos simple del sistema
sys.dm_os_threads Devuelve información sobre las amenazas en el
sistema
sys.dm_broker_queue_monitors Devuelve información sobre cada monitor de cola
de Service Broker del sistema
sys.dm_tran_locks Devuelve información sobre cada bloqueo
concedido o solicitado actualmente en el sistema

Consultar vistas de administración dinámica
Puede consultar vistas de administración dinámica mediante una instrucción SELECT estándar.
Por ejemplo, el código siguiente devuelve detalles sobre el estado de bloqueo actual del
sistema:
SELECT * FROM sys.dm_tran_locks
Para observar las actividades, desplegar el administrador, y luego hacer doble clic
sobre el Monitor de Actividades.
Seguidamente, se mostrará la ventana con la información de los procesos.

Usando el Monitor del sistema
El Monitor de sistema es un complemento de Microsoft Management Console (MMC) que
puede usarse para ver medidas de rendimiento del sistema, como el uso del procesador y de la
memoria o las estadísticas de actividad de disco.
Objetos, instancias y contadores del Monitor de sistema
Puede ver el Monitor de sistema mediante el inicio de la aplicación Rendimiento en el grupo de
programas de Herramientas administrativas. El Monitor de sistema clasifica la información en
objetos, contadores e instancias. Entender cómo se relacionan entre sí los objetos, los
contadores y las instancias es fundamental para usar eficazmente el Monitor de sistema.
Objetos. En el Monitor de sistema, los objetos son componentes principales o subsistemas del
sistema del equipo. Los objetos pueden ser hardware (por ejemplo, un disco duro), software
(por ejemplo, un proceso) o aplicaciones (por ejemplo, una instancia de SQL Server). Hay un
número fijo de objetos en Microsoft Windows Server™ 2008 y, al instalar SQL Server, se
agregan más objetos específicos de SQL
Server.
Contadores. Los contadores recopilan datos sobre diferentes aspectos de los objetos. Por
ejemplo, para el objeto Proceso, los contadores recopilan los datos sobre el tiempo de
procesador y el tiempo de usuario. Los contadores se integran en el sistema operativo y leen
continuamente datos de rendimiento, tanto si están visibles en el Monitor de sistema como si
no. Si un tipo de objeto tiene varias instancias, los contadores recopilan estadísticas de cada
instancia o del total de todas las instancias.
Instancias. Las instancias son múltiplos del mismo tipo de objeto. Por ejemplo, si un sistema
tiene varios procesadores, el tipo de objeto Procesador tendrá varias instancias. Cuando se ve
información sobre rendimiento en el Monitor de sistema, puede decidir ver los valores para una
instancia individual de un objeto (por ejemplo, el uso de un único procesador) o los valores
combinados para todas las instancias de ese objeto (por ejemplo, el uso general de procesador
para todos los procesadores del sistema).
En el Monitor de sistema, puede especificar qué contadores se mostrarán. Puede mostrar los
valores de contador como un gráfico, un histograma (gráfico de barras) o un informe. Los
gráficos, histogramas e informes se pueden ver en un explorador e imprimirse cuando los datos
de rendimiento se guardan como archivo de Lenguaje de marcado de hipertexto (HTML). Los

informes se pueden exportar a una hoja de cálculo, como las de Microsoft Office Excel®, para
un análisis más extenso.
REGISTROS Y ALERTAS DE RENDIMIENTO
Además del complemento MMC Monitor de sistema, la herramienta Rendimiento incluye un
segundo complemento denominado Registros y alertas de rendimiento. Puede usar este
complemento para capturar información sobre el rendimiento en un archivo de registro para
poder verlo posteriormente en el Monitor de sistema. Los registros de contador registran datos
sobre los recursos de hardware y los servicios del sistema basados en el rendimiento a lo largo
del tiempo. Los registros de contador son
útiles para realizar un seguimiento de las tendencias. Los registros de traza recopilan las trazas
de eventos que miden las estadísticas de rendimiento asociadas a eventos como E/S de disco
y archivo.
Los archivos de registro proporcionan un caudal de información para la solución de problemas
o el planeamiento. Aunque los gráficos, alertas e informes sobre la actividad actual
proporcionan información instantánea, los archivos de registro le permiten realizar el
seguimiento de los contadores durante un largo período de tiempo. Así, puede examinar la
información de forma más exhaustiva y documentar el rendimiento del sistema.
Además, puede configurar alertas que se disparan cuando un contador alcanza un valor umbral
concreto. Las alertas son útiles si no está supervisando activamente un contador determinado
pero desea ser notificado cuando éste está por encima o por debajo de un valor especificado
para poder así investigar y determinar la causa del cambio. Por ejemplo, puede establecer una
alerta cuando el porcentaje de espacio en disco usado supere el 80% o cuando el número de
intentos de inicio de sesión fallidos exceda un número concreto.
OBJETOS DE RENDIMIENTO DE SQL SERVER
SQL Server proporciona objetos y contadores que el Monitor de sistema puede usar para
supervisar la actividad en equipos que ejecutan una instancia de SQL Server. Un objeto es
cualquier recurso de SQL Server, como el administrador de bloqueos de SQL Server. Cada
objeto contiene uno o más contadores que determinan varios aspectos de los objetos para
supervisar. Por ejemplo, el objeto Bloqueos de SQL Server contiene los contadores Número
de interbloqueos/seg. y Tiempos de espera de
bloqueos/seg.

Consideraciones para supervisar SQL Server
La supervisión de una instancia de SQL Server requiere el análisis de algunos aspectos clave
del sistema. Eliminar los cuellos de botella físicos puede afectar inmediatamente al rendimiento
e incluso localizar problemas de diseño en la base de datos, consultas Transact-SQL o
aplicaciones cliente.
Es importante supervisar el rendimiento de SQL Server para poder identificar cuellos de botella,
determinar su causa y eliminarlos. Los cuellos de botella pueden eliminarse ajustando bases de
datos de SQL Server, índices y consultas; actualizando el hardware; o distribuyendo la carga
del servidor entre otros servidores SQL.
Supervisar la actividad de disco
SQL Server usa las llamadas de entrada/salida (E/S) del sistema operativo Windows para
realizar operaciones de lectura y escritura en sus subsistemas de disco. SQL Server administra
cuándo y cómo se realizan las operaciones E/S de disco, pero el sistema operativo Windows
realiza las operaciones E/S subyacentes. El subsistema E/S incluye el bus del sistema, las
tarjetas controladoras de disco, los discos, las unidades de cinta, las unidades de CD-ROM y
muchos otros dispositivos de E/S. Las operaciones E/S de disco son con frecuencia la causa
de los cuellos de botella en un sistema.
Supervisar la actividad de disco requiere concentrarse en dos áreas:
Supervisar la E/S de disco y detectar la paginación excesiva.
Aislar la actividad de disco que crea SQL Server.
Puede supervisar los contadores siguientes en el objeto DiscoFísico para determinar la E/S de
disco y detectar la paginación excesiva.
Contador Descripción Directrices
% tiempo de disco Supervisa el porcentaje de
tiempo durante el cual el disco
está ocupado con la actividad
de lectura y escritura.
Si este contador es alto
(más del 90%), compruebe
el contador Longitud
actual
de la cola de disco.
Longitud media de la cola
de disco
Supervisa el número medio de
solicitudes de lectura y escritura
que se ponen en cola.
Este contador no debería
ser mayor que dos veces el
número de husos.
Longitud actual de la cola
de disco
Supervisa el número actual de
solicitudes de lectura y escritura
Este contador no debería
ser mayor que dos veces el

que se ponen en cola. número de husos.
Use los valores de los contadores Longitud actual de la cola de disco y % tiempo en disco
para detectar los cuellos de botella dentro del subsistema de disco. Si los valores de los
contadores Longitud actual de la cola de disco y % de tiempo en disco son altos de forma
consistente, considere la posibilidad de efectuar una de las acciones siguientes:
Usar una unidad de disco más rápida.
Mover algunos archivos a un disco o servidor adicional.
Agregar discos a un dispositivo de almacenamiento de matriz redundante de discos
independientes (RAID), si se usa alguno.
Supervise el contador Errores de página/s. en el objeto Memoria para asegurarse de que la
actividad de disco no está ocasionada por la paginación.
Supervisar el uso de memoria
Supervise periódicamente una instancia de SQL Server para confirmar que el uso de la
memoria se encuentra dentro de los valores normales. Debe asegurarse de que ningún
proceso, incluido SQL Server, usa demasiada memoria o está restringido por una memoria
insuficiente.
Para supervisar en busca de una condición de memoria baja, use los contadores de objeto
descritos en la tabla siguiente.
Objeto: contador Descripción Directrices
Memoria: Bytes
disponibles
Indica cuántos bytes de
memoria están disponibles
actualmente para su uso
Páginas/seg. por parte de
procesos.
Los valores bajos para el
contador Bytes disponibles
puede indicar una escasez
general de memoria en el
equipo o que una aplicación no
está liberando la memoria.
Memoria: Páginas/seg. Indica el número de páginas
que se recuperaron del disco
debido a los errores de
página en disco o que se
escribieron en el espacio
disponible del disco conjunto
de trabajo debido a los
errores de página.
Un alto número para el
contador Páginas/seg. podría
indicar una paginación
excesiva.
Supervise el contador
Memoria: Errores de
página/s. para asegurarse de
que la actividad del disco no
está ocasionada por la
paginación.
Proceso: Errores de
página/s
(instancia sqlservr)
Windows Virtual Memory
Manager toma las páginas
de SQL Server y otros
procesos cuando recorta
los tamaños del conjunto
de trabajo de esos procesos.
Un número alto para este
contador indica unas
paginaciones excesivas y
sacudidas en el disco. Use
este contador para comprobar
si SQL Server u algún otro
proceso está produciendo la
paginación excesiva.
Proceso: Conjunto de
trabajo (instancia
sqlservr)
Muestra la cantidad de
memoria usada por un
proceso.
Si este número se encuentra
de forma coherente por debajo
de la cantidad de memoria
establecida por las opciones
de servidor memoria mínima
del servidor y memoria
máxima del servidor, SQL
Server se configurará para
usar demasiada memoria.
SQL Server: Buffer
Manager:frecuencia de
Supervisa el porcentaje de
páginas necesarias
Agregue más memoria hasta
que el valor sea

aciertos de caché del búfer encontradas en la caché de
búfer, sin leer del disco duro.
No diferencia entre la
memoria física y la memoria
del archivo de paginación
usado para la caché de
búfer.
constantemente mayor que el
90%.
SQL Server: Buffer
Manager:total de
páginasSQL
Supervisa el número total de
páginas de la caché de
búfer, incluidas las páginas
de la base de datos, las
libres y las robadas de otros
procesos.
Un número bajo puede indicar
sacudidas frecuentes en el
disco E/S. Considere la
posibilidad de agregar más
memoria.
Servidor:Memory
Manager: Memoria total
del servidor (KB)
Supervisa la cantidad total
de memoria dinámica que
usa el servidor.
Si este contador es
consistentemente alto
comparado con la cantidad de
memoria física disponible,
puede que se necesite más
memoria.
Supervisar el uso de CPU
Supervise periódicamente una instancia de SQL Server para determinar si las tasas de uso de
CPU están dentro de los valores normales. Una tasa continuamente alta de uso de CPU puede
indicar la necesidad de actualizar la CPU o de agregar varios procesadores. Por otro lado, una
tasa alta de uso de CPU puede indicar la existencia de una aplicación mal ajustada o mal
diseñada. Optimizar la aplicación puede reducir el uso de CPU.
Use los contadores descritos en la tabla siguiente para supervisar el uso de CPU.
Objeto: contador Descripción Directrices
Procesador: % de tiempo
del procesador
Supervisa la cantidad de tiempo
que la CPU invierte en ejecutar
un subproceso que no se
encuentra inactivo.
Un estado coherente de
entre el 80% y el 90%
puede indicar la necesidad
de actualizar su CPU o de
agregar más procesadores.
En los sistemas
multiprocesador, supervise
una instancia independiente
de este contador para cada
procesador.
Proceso: % tiempo del
procesador (instancia
sqlservr)
Supervisa la cantidad de tiempo
que la CPU invierte en ejecutar
un subproceso en el proceso
SQL Server.
Use este contador para
evaluar la contribución de
SQL Server al uso total del
procesador.
¿Qué es el SQL Server Profiler?
El Analizador de Microsoft SQL Server es una herramienta de interfaz gráfica de usuario para
supervisar una instancia del Motor de base de datos de SQL Server o Análisis Services. Puede
capturar y guardar los datos sobre cada evento en un archivo o tabla para analizarlos
posteriormente. Por ejemplo, puede supervisar un entorno de producción para ver qué
procedimientos almacenados afectan al rendimiento debido a una ejecución demasiado lenta.

Funciones del SQL Server Profiler
El SQL Server Profiler muest ra cómo SQL Server resuelve las consultas internamente, lo que
permite a los administradores ver exactamente qué instrucciones Transact-SQL se envían al
servidor y cómo éste tiene acceso a la base de datos para devolver conjuntos de resultados.
Mediante el uso del SQL Server Profiler, podrá:
Crear una traza paso a paso basada en una plantilla reutilizable.
Consultar los resultados de traza mientras se ejecuta.
Almacenar los resultados de traza en una tabla o en un archivo para un análisis más detallado.
Iniciar, detener, poner en pausa y modificar los resultados de traza cuando sea necesario.
Reproducir los resultados de traza.
Use el SQL Server Profiler para supervisar sólo aquellos eventos que le interesen. Si hay
demasiada actividad para examinarla con facilidad, puede filtrar eventos basándose en la
información que desea, de modo que sólo se recopile un subconjunto de los datos de eventos.
Supervisar demasiados eventos puede sobrecargar al servidor y al proceso de supervisión, lo
que puede producir que el archivo o la tabla de traza se hagan muy grandes, sobre todo
cuando el proceso de supervisión tiene lugar durante un largo período de tiempo.
Obtener la traza de actividad de SQL Server mediante el SQL Server Profiler
Para usar el SQL Server Profiler, primero decida lo que desea seguir paso a paso y, a
continuación, elija los criterios. Las actividades que podría desear supervisar incluyen:
Consultas con un mal rendimiento.
Consultas que provocan recorridos de tabla.
Actividades de usuarios o aplicaciones individuales.
Rendimiento de la base de datos tempdb.
Problemas de interbloqueo.
Intentos de inicio de sesión, errores, conexiones y desconexiones.
Lecturas y escrituras del disco lógico.
Uso de CPU a nivel de instrucción.
Tiempo de espera para todos los eventos posteriores a la ejecución.
Puede establecer los procedimientos almacenados del sistema en el SQL Server Profiler para
seguir paso a paso un conjunto definido de eventos y filtrar el nivel de información recopilado
sobre esos eventos. Mediante el uso del procedimiento almacenado del sistema
sp_trace_create, puede hacer la traza de eventos especificados en su servidor. La opción
trace_produce_blackbox crea un registro rotativo de los últimos 5 megabytes (MB) de
eventos de servidor especificados.

Opciones de traza del SQL Server Profiler
Cuando usa el SQL Server Profiler para crear una traza, dispone de varias opciones para
definir la actividad que se registrará y dónde se almacenará la actividad de traza registrada.
Especificar una plantilla de traza
Los eventos incluidos en una traza están determinados por la especificación de las clases de
eventos que desea supervisar y los valores de datos individuales (columnas) que desea
registrar. Esto se lleva a cabo mediante la selección de la plantilla en la que desea basar su
traza y, a continuación, agregando o quitando clases o columnas de eventos individuales y
aplicando filtros para limitar los datos recopilados basándose en criterios concretos.
El SQL Server Profiler ofrece varias plantillas predefinidas que le permiten configurar con
facilidad los eventos que probablemente necesitará para tipos concretos de actividad. Por
ejemplo, la plantilla Estándar le ayuda a crear una traza genérica para registrar inicios y cierres
de sesión, lotes finalizados e información de conexión. Puede usar esta plantilla sin modificarla
para ejecutar trazas, o como punto de partida para
plantillas adicionales con configuraciones de eventos diferentes. También puede crear
sus propias plantillas o modificar las plantillas predefinidas.
Guardar datos de traza
Debería guardar los datos de eventos capturados en un archivo o una tabla de SQL Server
cuando necesite analizar o volver a consultar los datos capturados posteriormente.
Al guardar una traza, puede:
■ Usar un archivo o una tabla de traza para crear una carga de trabajo que se use como entrada
para Database Engine Tuning Advisor.
■ Usar un archivo de traza para capturar eventos y enviar el archivo de traza al proveedor de
soporte técnico para su análisis.
■ Usar las herramientas de procesamiento de consulta en SQL Server para tener acceso a los
datos o ver los datos en el SQL Server Profiler. Sólo los miembros de la función fija de servidor
sysadmin o el creador de la tabla pueden tener acceso a la tabla de traza directamente.
Las opciones disponibles al guardar una traza en una tabla son:
■ La ubicación y el nombre de la tabla.
■ El número máximo de filas que se almacenan en la tabla (opcional).
Las opciones disponibles al guardar una traza en un archivo son:
■ La ubicación y el nombre del archivo.
■ El tamaño máximo del archivo.
■ Siga el comportamiento cuando el archivo esté lleno (desplácese para iniciar al principio del
archivo otra vez o crear un nuevo archivo).
■ Siga el procesamiento por parte del servidor o del SQL Server Profiler. Configurar el servidor
para procesar la traza puede reducir el impacto de la traza en el rendimiento.
Especificar una hora de detención de traza
Puede decidir establecer una hora de detención de la traza, lo cual le permite iniciar una traza y
dejar que se ejecute hasta una fecha y hora concretas. La capacidad para especificar una
pausa es útil cuando desee registrar la actividad de SQL Server para un período
predeterminado.
COLUMNAS, EVENTOS Y CATEGORÍAS DE TRAZA
La información registrada en una traza se divide en categorías. Las categorías contienen
eventos, cada uno de los cuales tiene atributos definidos posteriormente por columnas.
Categorías de traza
En el SQL Server Profiler, una categoría es un grupo de clases de eventos relacionadas. Las
clases de eventos están compuestas por tipos de eventos que se pueden seguir paso a paso.
La clase de evento contiene todas las columnas de datos sobre las que un evento puede
realizar informes.

Las categorías mostradas de forma predeterminada son:
Security Audit. Incluye las clases de eventos que se usan para auditar la actividad del
servidor.
Sesiones. Incluyen clases de eventos generadas por clientes que se conectan y desconectan
de una instancia de SQL Server.
Procedimientos almacenados. Incluyen clases de eventos generadas por la ejecución de
procedimientos almacenados.
TSQL. Incluyen clases de eventos generadas por la ejecución de instrucciones Transact-SQL
pasadas a una instancia de SQL Server desde el cliente.
Eventos
Un evento se define como la aparición de una acción dentro de una instancia del Motor de base
de datos de SQL Server. Los eventos se definen además por sus atributos, que se muestran en
columnas de datos.
Los eventos predeterminados mostrados se describen en la tabla siguiente.
Categoría Evento Descripción
Security Audit Audit Login Indica que un usuario ha iniciado
sesión correctamente en SQL
Server.
Security Audit Audit Logout Indica que un usuario ha cerrado
la sesión de SQL Server.
Sesiones ExistingConnection Indica las propiedades de
conexiones de usuario
existentes cuando se inició la
traza. El servidor provoca un
evento ExistingConnection por
cada conexión de usuario
existente.
Procedimientos
almacenados
RPC: completed Indica que una llamada de
procedimiento remoto ha
finalizado.
TSQL SQL:BatchCompleted Indica que el lote de Transact-
SQL ha finalizado.
TSQL SQL:BatchStarting Indica que un lote de Transact-
SQL se está iniciando.
Columnas
Las columnas de datos contienen los atributos de los eventos. El SQL Server Profiler usa las
columnas de datos de la traza para describir eventos que se capturan cuando se ejecuta la
traza.
Puede administrar las columnas mediante filtros de columna para controlar qué datos se
recopilan. Por ejemplo, use el filtro Nombre de aplicación para excluir cualquier dato
generado por el propio SQL Server Profiler. También puede organizar columnas en grupos
relacionados usando la función Organizar columnas.
CREANDO UNA TRAZA CON EL SQL PROFILER
Haga clic en Inicio, seleccione Todos los programas, Microsoft SQL Server 2008 y
Herramientas de rendimiento y, a continuación, haga clic en SQL Server Profiler.
En el SQL Server Profiler, en el menú Archivo, haga clic en Nueva traza.
En el cuadro de diálogo Propiedades de traza, en el cuadro Nombre de traza, escriba Prueba
de esfuerzo.

En el cuadro de diálogo Tabla de destino, seleccione la base de datos AdventureWorks, el
propietario dbo, y la tabla Prueba de esfuerzo y, a continuación, haga clic en Aceptar.

En el cuadro de diálogo Propiedades de traza, active la casilla de verificación Habilitar hora
de detención de traza y, a continuación, especifique una hora 5 minutos después de la hora
actual.
Haga clic en Ejecutar/Run para iniciar la traza.
Usar los desencadenadores DDL
Los desencadenadores del Lenguaje de definición de datos (DDL) son una nueva característica
en SQL Server 2008. A diferencia de los desencadenadores estándar, que sólo pueden
responder a los cambios en los datos, los desencadenadores DDL se pueden usar para
responder a las acciones en objetos en una base de datos. Por ejemplo, un desencadenador
DDL puede usarse para auditar operaciones como la creación o supresión de tablas. Por

consiguiente, los desencadenadores de DDL son una herramienta muy útil para supervisar las
acciones que tienen lugar en una base de datos.
Es útil poder supervisar operaciones de definición de datos, como un usuario que crea o
suprime una tabla, al auditar y regular las acciones de base de datos. Los desencadenadores
DDL proporcionan una forma de capturar de forma transparente eventos de definición de datos,
para que un usuario que ejecute una instrucción de lenguaje de definición de datos no sea
consciente de que la tarea es observada.
Cuándo usar desencadenadores DDL
Un desencadenador DDL se inicia cuando un usuario ejecuta una instrucción de lenguaje de
definición de datos especificada, como CREATE TABLE, DROP TRIGGER o UPDATE
STATISTICS.
Los desencadenadores DDL pueden ser útiles para registrar acciones administrativas en el
sistema. Por ejemplo, podría crear un desencadenador en la instrucción CREATE VIEW para
registrar detalles sobre la vista que se creó, el usuario que la creó y la hora en que tuvo lugar la
acción.
Ámbito de desencadenador DDL
A diferencia de los desencadenadores corrientes que están asociados a tablas, un
desencadenador DDL se ejecuta cuando se ejecuta una instrucción determinada, sin tener en
cuenta el destino de esa instrucción. Por ejemplo, un desencadenador DLL DROP_TABLE se
iniciará cuando se anule una tabla.
Algunos desencadenadores DDL funcionan en el nivel de base de datos y sólo se inician
cuando el evento correspondiente tiene lugar en una base de datos concreta. Estos
desencadenadores tienen relación sobre todo con objetos de una sola base de datos, como
tablas, índices, usuarios, procedimientos, vistas, etc. Un ejemplo de un desencadenador DDL
que funciona en el ámbito de base de datos es CREATE_TABLE. Otros desencadenadores
DDL funcionan en el nivel de servidor y se inician sin tener en cuenta la base de datos que está
en uso. Estos desencadenadores están asociados a objetos en el nivel de servidor, como
inicios de sesión y certificados de seguridad. El desencadenador DLL CREATE_LOGIN es un
ejemplo que funciona en el ámbito de servidor.
Proceso desencadenador DDL
Los desencadenadores DDL se inician cuando finaliza la acción desencadenadora. Por
ejemplo, un desencadenador DROP_TABLE se inicia después de que la tabla de destino se

haya anulado correctamente. No hay ningún equivalente a los desencadenadores INSTEAD
OF para las operaciones DDL.
Puede usar la instrucción ROLLBACK TRANSACTION para anular la transacción actual y
deshacer cualquier trabajo que se haya realizado, incluida la operación DDL que hizo que el
desencadenador se iniciara.
Una sola operación DDL puede desencadenar varios desencadenadores DDL. El orden en el
que se inician los desencadenadores no se documenta. No debería confiar en que los
desencadenadores DDL se ejecuten siguiendo una secuencia determinada.
Cómo crear desencadenadores DDL
Puede crear desencadenadores DDL mediante la instrucción CREATE TRIGGER. Además,
puede usar algunas nuevas extensiones de sintaxis que se han agregado a SQL Server 2008.
La instrucción CREATE TRIGGER
Al crear un desencadenador DDL, debe especificar el ámbito y el tipo de operación DDL.
El ejemplo siguiente crea un desencadenador que se inicia en el momento en el que un usuario
ejecuta el comando UPDATE STATISTICS en la base de datos actual:
CREATE TRIGGER UpdStats
ON DATABASE
FOR UPDATE_STATISTICS
AS
...
Indique el ámbito de un desencadenador mediante la cláusula ON DATABASE o mediante la
cláusula ON ALL SERVER en la definición del desencadenador. El cuerpo de un
desencadenador DDL puede contener instrucciones Transact-SQL o puede hacer referencia a
un método en un ensamblado de Microsoft .NET.
La función eventdata
Los desencadenadores de Lenguaje de manipulación de datos estándar (DML) crean las tablas
insertadas y eliminadas, permitiendo que el desarrollador examine los datos que se están
cambiando y los nuevos valores que los modifican. Los desencadenadores DDL no crean estas
tablas. En su lugar, puede usar la función eventdata para obtener información sobre los
eventos que inician el desencadenador.

La función eventdata devuelve un documento XML EVENT_INSTANCE cuyo contenido varía
según el destino del desencadenador DDL. Todos los desencadenadores DDL devuelven un
documento que incluye los elementos siguientes:
<PostTime>. El momento en el que se inició el desencadenador.
<SPID>. El Id. del proceso de base de datos que activa el desencadenador.
<EventType>. El tipo de evento que activó el desencadenador, como CREATE_TABLE o
UPDATE_STATISTICS
El resto del documento XML contiene información que depende del comando que activa el
desencadenador. Por ejemplo, un desencadenador DDL devolvió el documento siguiente
mediante la activación del comando UPDATE STATISTICS:
<EVENT_INSTANCE>
<PostTime>2004-06-18T02:14:20.640</PostTime>
<SPID>58</SPID>
<EventType>UPDATE_STATISTICS</EventType>
<ServerName>SQL2008PC</ServerName>
<LoginName>SQL2008PCAdministrator</LoginName>
<UserName>SQL2008PCAdministrator</UserName>
<DatabaseName>AdventureWorks</DatabaseName>
<SchemaName>Production</SchemaName>
<ObjectType>STATISTICS</ObjectType>
<TargetObjectName>Product</TargetObjectName>
<TargetObjectType>TABLE</TargetObjectType>
<TSQLCommand>
<SetOptions ANSI_NULLS="ON" ANSI_NULL_DEFAULT="ON"
ANSI_PADDING="ON" QUOTED_IDENTIFIER="ON"
ENCRYPTED="FALSE"/>
<CommandText>
UPDATE STATISTICS Production.Product
</CommandText>
</TSQLCommand>
</EVENT_INSTANCE>
Extraer información de evento
Use la funcionalidad XQuery del tipo de datos xml para extraer la información de evento que
devolvió el documento con la función eventdata. Por ejemplo, la muestra de código siguiente
recupera los elementos PostTime, Database y TargetObject en un desencadenador DDL
UPDATE_STATISTICS y los muestra:
CREATE TRIGGER UpdStats
ON DATABASE
FOR UPDATE_STATISTICS
AS
DECLARE @data xml
DECLARE @posttime nvarchar(24)
DECLARE @database nvarchar(100)
DECLARE @targetobject nvarchar(100)
SET @data = eventdata()
SET @posttime = @data.value('(/EVENT_INSTANCE/PostTime)[1]',
'nvarchar(24)')
SET @database = @data.value('(/EVENT_INSTANCE/DatabaseName)[1]',
'nvarchar(100)')
SET @targetobject =
@data.value('(/EVENT_INSTANCE/TargetObjectName/text())[1]',
'nvarchar(100)')
PRINT @posttime
PRINT @database
PRINT @targetobject
Cómo administrar desencadenadores DDL
SQL Server 2008 ha ampliado la sintaxis de los comandos usados para administrar
desencadenadores con extensiones específicas para desencadenadores DDL.

Ver los desencadenadores
Puede obtener una lista de los desencadenadores disponibles de una base de datos, incluidos
los desencadenadores DDL, mediante la consulta de la vista de catálogo sys.triggers, como
se muestra en el ejemplo de código siguiente:
SELECT name
FROM sys.triggers
Puede recuperar la definición de un desencadenador mediante la consulta de la vista de
catálogo sys.sql_modules, como se muestra en el siguiente ejemplo de código:
SELECT definition
FROM sys.sql_modules
WHERE [object_id] =
(SELECT [object_id]
FROM sys.triggers
WHERE name='trigger_name')
Alternativamente, puede ver desencadenadores de base de datos mediante el Explorador de
objetos en SQL Server Management Studio.
Modificar un desencadenador
Use el comando ALTER TRIGGER para cambiar la definición de un desencadenador DDL. La
sintaxis para cambiar un desencadenador DDL es muy parecida a la corrección de un
desencadenador estándar. Puede:
Cambiar el evento desencadenador.
Cifrar el desencadenador.
Modificar las instrucciones Transact-SQL que constituyen el cuerpo del desencadenador.
Eliminar un desencadenador
Use el comando DROP TRIGGER para quitar un desencadenador. Por ejemplo:
DROP TRIGGER UpdStats
ON DATABASE

Usar las notificaciones de eventos
Las notificaciones de eventos son una nueva característica en SQL Server 2008 que
proporcionan un mecanismo muy escalable para supervisar la actividad de SQL Server.
Son una herramienta útil para registrar la actividad de la base de datos con un impacto mínimo
sobre el rendimiento de SQL Server.
¿QUÉ SON LAS NOTIFICACIONES DE EVENTOS?
Las notificaciones de eventos, como los desencadenadores, pueden responder a varios
eventos de la base de datos. A diferencia de los desencadenadores, que ejecutan el código en
el mismo motor de base de datos de SQL Server 2008 como el evento que activó el
desencadenador, las notificaciones de eventos se envían a un servicio mediante Service
Broker, lo que le permite enviar datos de eventos de varias bases de datos y servidores a un
servicio de control de eventos central.
Notificaciones de eventos
Una notificación de eventos reacciona ante uno o más eventos en la base de datos y envía un
mensaje a un servicio de Service Broker diseñado para controlar los eventos. Un evento de
base de datos puede ser una operación DDL en un objeto de base de datos o un evento de
traza parecido a aquéllos que se pueden capturar mediante el SQL Server Profiler.
Capturar eventos
Para capturar y procesar notificaciones de eventos, debe implementar un servicio de Service
Broker. Un servicio de Service Broker es un procedimiento almacenado o una aplicación
generada mediante el marco Service Broker que supervisa una cola para los mensajes
entrantes. Un servicio de Broker Service se puede escribir usando Transact-SQL o uno de los
lenguajes de Common Language Runtime (CLR). Service Broker envía mensajes al servicio, y
usa una cola para conservar la información de mensajes hasta que el servicio esté listo para
aceptarlos. El servicio también puede usar una cola para mantener solicitudes hasta que pueda
procesarlas.
Para simplificar el proceso de creación de notificaciones de eventos, SQL Server 2008 incluye
un tipo de mensaje predefinido y un contrato para las notificaciones de eventos. Los únicos
objetos de Service Broker que necesita crear son una cola, un servicio y una ruta.
CÓMO CREAR NOTIFICACIONES DE EVENTOS
Use la instrucción CREATE EVENT NOTIFICATION para crear un nuevo objeto de notificación
de eventos y enviar la información del evento a un servicio de procesamiento de eventos.

Usar la instrucción CREATE EVENT NOTIFICATION
Cuando use la instrucción CREATE EVENT NOTIFICATION, debe:
Definir la notificación de eventos con un nombre que sea único dentro de su ámbito.
Especificar el ámbito de la notificación de eventos. El ámbito puede ser SERVER, DATABASE
o QUEUE.
Especificar los eventos que desea capturar. Puede especificar un evento individual o un grupo
de eventos que contenga varios eventos relacionados.
Especifique el servicio de Service Broker al que se debería enviar la información del evento.
Debe especificar el nombre del servicio y la identificación de instancia de Service Broker
exclusiva que identifica la base de datos en la que se implementa el servicio. Para los servicios
de la base de datos local, puede usar la cadena literal 'current database'.
Ejemplos
El código de Transact-SQL siguiente muestra una instrucción CREATE EVENT NOTIFICATION
para una notificación de eventos denominada CreateLoginEvent.
La notificación de eventos tiene un ámbito de servidor y envía información al servicio
NotifyService en la base de datos actual cada vez que se ejecuta el comando CREATE
LOGIN:
CREATE EVENT NOTIFICATION CreateLoginEvent
ON SERVER
FOR CREATE_LOGIN
TO SERVICE 'NotifyService', 'current database'
El ejemplo siguiente muestra una instrucción CREATE EVENT NOTIFICATION para una
notificación de eventos denominada TableViewEvent con ámbito de base de datos que envía
información al servicio EvtService cuando se ejecuta cualquier operación DDL en una tabla,
vista, índice, o estadísticas:
CREATE EVENT NOTIFICATION TableViewEvent
ON DATABASE
FOR DDL_TABLE_VIEW_EVENTS
TO SERVICE 'EvtService', '8140a771-3c4b-4479-8ac0-81008ab17984'
También puede usar las notificaciones de eventos para capturar un evento de traza.
Por ejemplo, la notificación de eventos siguiente intercepta el evento SQL_BatchCompleted.
(Los eventos de traza sólo se pueden capturar en el nivel de servidor).
CREATE EVENT NOTIFICATION TraceSQLBatches
ON SERVER
FOR SQL_BatchCompleted
TO SERVICE 'NotifyService', 'current database'
CÓMO PROCESAR NOTIFICACIONES DE EVENTOS
La manera más simple de crear un servicio de Service Broker para controlar eventos de SQL
Server es usar un procedimiento almacenado que se active cuando aparezca un mensaje en
una cola, enviado por una notificación de eventos.

Puede especificar qué procedimiento almacenado se ejecutará cuando crea la cola. El código
siguiente muestra cómo especificar la ejecución de un procedimiento almacenado denominado
EventProc cuando se recibe un mensaje en la cola NotifyQueue:
CREATE QUEUE NotifyQueue
WITH ACTIVATION (
PROCEDURE_NAME = dbo.EventProc,
MAX_QUEUE_READERS = 5,
EXECUTE AS SELF)
GO
Recibir mensajes
El procedimiento almacenado de procesamiento de eventos debería recuperar primero el
mensaje de la cola mediante el comando RECEIVE y, a continuación, almacenar la información
en variables. El comando WAITFOR se usa para suspender el procesamiento hasta que se
reciba un mensaje o hasta que hayan pasado dos segundos.
Si no se recibe ningún mensaje, no es necesario efectuar más acciones. En el ejemplo
siguiente se muestra cómo recibir mensajes de una cola denominada NotifyQueue:
DECLARE @messageTypeName NVARCHAR(256),
@messageBody XML
;WAITFOR(
RECEIVE TOP(1)
@messageTypeName = message_type_name,
@messageBody = message_body
FROM dbo.NotifyQueue;
), TIMEOUT 2000 ;
IF @@ROWCOUNT = 0
RETURN
Procesar mensajes
A los mensajes de la cola se les asigna un message_type_name que describe el tipo de
mensaje. Puede usarlo para identificar si el mensaje es una notificación de eventos o un
mensaje de error de la notificación de eventos.
Los mensajes también contienen una columna message_body que contiene la información
real del evento. Esta columna contiene un documento EVENT_INSTANCE XML que incluye los
mismos elementos que el documento generado por el desencadenador DDL. Por ejemplo, una
notificación de eventos de tabla que activa un comando ALTER TABLE generó el documento
siguiente:
<EVENT_INSTANCE>

<SPID>58</SPID>
<EventType>ALTER_TABLE</EventType>
<ServerName>SQL2008PC</ServerName>
<LoginName>SQL2008PCAdministrator</LoginName>
<UserName>SQL2008PCAdministrator</UserName>
<DatabaseName>AdventureWorks</DatabaseName>
<SchemaName>dbo</SchemaName>
<ObjectName>T1</ObjectName>
<ObjectType>TABLE</ObjectType>
<TSQLCommand>
<SetOptions ANSI_NULLS="ON" ANSI_NULL_DEFAULT="ON"
ANSI_PADDING="ON" QUOTED_IDENTIFIER="ON"
ENCRYPTED="FALSE"/>
<CommandText>ALTER TABLE T1 ADD col13 int</CommandText>
</TSQLCommand>
</EVENT_INSTANCE>
Puede usar la funcionalidad XQuery del tipo de datos xml para recuperar la información del
evento como se muestra en el ejemplo siguiente:
DECLARE @cmd nvarchar(1000)
DECLARE @posttime nvarchar(24)
DECLARE @spid nvarchar(6)
DECLARE @loginname nvarchar(100)
DECLARE @hostname nvarchar(100)
SET @cmd = @messagebody.value
('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]'), 'nvarchar(1000)')
SET @posttime = @messagebody.value
('(/EVENT_INSTANCE/PostTime)[1]', 'nvarchar(24)')
SET @spid = @messagebody.value
('(/EVENT_INSTANCE/SPID)[1]', 'nvarchar(6)')
SET @loginname = @messagebody.value
('(/EVENT_INSTANCE/LoginName)[1]', 'nvarchar(100)')
SET @hostname = HOST_NAME()
INSERT INTO AuditLog(Command,PostTime,HostName,LoginName)
VALUES(@cmd, @posttime, @hostname, @loginname)
GO
CÓMO ADMINISTRAR NOTIFICACIONES DE EVENTOS
SQL Server 2008 proporciona nuevas instrucciones Transact-SQL para administrar
notificaciones de eventos. Estas instrucciones permiten ver, modificar y quitar notificaciones de
eventos.
Ver las notificaciones de eventos y colas
Puede obtener una lista de notificaciones de eventos mediante la consulta de la vista de
catálogo sys.event_notifications:
SELECT name
FROM sys.event_notifications

Puede ver una lista de colas, incluidas las usadas por las notificaciones de eventos, mediante
la consulta de la vista de catálogo sys.service_queues:
SELECT name
FROM sys.service_queues
Eliminar una notificación de eventos
Use el comando DROP EVENT NOTIFICATION para eliminar permanentemente una
notificación de eventos de la base de datos:
DROP EVENT NOTIFICATION UpdateStats
ON SERVER
Nota
Las notificaciones de eventos dependen de la funcionalidad Service Broker de SQL Server
2008. Para usar las notificaciones de eventos, debe habilitar Service Broker mediante la
habilitación de la configuración ENABLE_BROKER para la base de datos en la que se
encuentra su código de notificación de eventos.

C
CA
AP
PI
IT
TU
UL
LO
O 7
7
 Monitoreando al SQL Server 2008
 Uso del Monitor de Actividades
 Uso del Monitor del Sistema
 Uso del SQL Server Profiler
 Usando DDL Triggers
 Uso de Notificaciones

A U T O M A T I Z A C I Ó N D E T A R E A S
A D M I N I S T R A T I V A S
Una de las funciones principales de un administrador de bases de datos es el mantenimiento
de SQL Server y sus bases de datos. También se incluyen tareas que se deben realizar de
manera programada y tareas adicionales para anticiparse a los problemas antes de que se
produzcan.
El trabajo de un administrador conlleva deberes administrativos que no cambian de un día para
otro y que pueden llegar a ser aburridos. Puede automatizar estas tareas rutinarias y configurar
SQL Server para supervisar ciertos tipos de problemas antes de que aparezcan.
Ventajas de la automatización
La automatización de la administración y la supervisión de tareas permite al administrador de
bases de datos reducir la carga de trabajo asociada a realizar tareas repetitivas y a la
supervisión de SQL Server. Al usar trabajos y alertas, puede configurar SQL Server para
responder automáticamente a los problemas que surjan e incluso evitar que algunos de ellos
aparezcan.
Ventajas de la automatización de la administración de bases de datos
Las ventajas de la automatización de la administración de bases de datos incluyen:
Reducción de la carga de trabajo administrativa, con lo que se permite a los administradores de
bases de datos centrarse en otras funciones del trabajo, como planear cambios en la base de
datos u optimizar su rendimiento, en lugar de estar pendientes de tareas de mantenimiento
rutinarias.
Reducción del riesgo de que se pasen por alto tareas de mantenimiento fundamentales.
Reducción del riesgo de errores humanos al realizar tareas de mantenimiento de bases de
datos.
La administración proactiva de la base de datos a través de alertas indica la acción que debe
realizarse para impedir que se produzcan problemas antes de que ocurran.

¿Qué es el Asistente para planes de mantenimiento?
Puede usar el Asistente para planes de mantenimiento para programar las tareas de
mantenimiento principales a fin de garantizar la realización de copias de seguridad de la base
de datos con regularidad, que su rendimiento sea el adecuado y que se llevan a cabo
comprobaciones en busca de incoherencias. El Asistente para planes de mantenimiento crea
uno o varios trabajos del Agente SQL Server que realizan estas tareas de mantenimiento
automáticamente a intervalos programados.
Tareas que pueden automatizarse con el Asistente para planes de mantenimiento
Las tareas de mantenimiento que pueden programarse para que se ejecuten automáticamente
incluyen:
Realizar copias de seguridad de la base de datos y de archivos del registro de transacciones.
Las copias de seguridad de las bases de datos y del registro pueden conservarse durante un
período de tiempo específico.
Ejecutar trabajos del Agente SQL Server que permiten realizar una gran variedad de acciones.
Compactar los archivos de datos quitando las páginas de base de datos vacías.
Realizar comprobaciones de coherencia internas de los datos y páginas de datos dentro de la
base de datos para asegurarse de que un problema en el sistema o de software no haya
dañado los datos.
Reorganizar los datos en las páginas de datos y de índice volviendo a generar los índices.
Actualizar las estadísticas del índice para asegurarse de que el optimizador de consultas tiene
información actualizada sobre la distribución de valores de los datos en las tablas.
Los resultados generados por las tareas de mantenimiento se pueden escribir como un informe
en un archivo de texto o en las tablas del plan de mantenimiento (sysmaintplan_log y
sysmaintplan_log_detail) en la base de datos msdb.
Inicio del Asistente para planes de mantenimiento
El Asistente para planes de mantenimiento se inicia desde SQL Server Management Studio. En
el Explorador de objetos, expanda la carpeta del servidor y la carpeta Administración, haga clic
con el botón secundario en Planes de mantenimiento y, a continuación, haga clic en el
Asistente para planes de mantenimiento. Posteriormente, podrá usar el asistente para crear un
plan personalizado que se ajuste a sus requisitos de mantenimiento.
¿Qué es el Agente SQL Server?
El Agente SQL Server es el componente de SQL Server responsable de la automatización de
las tareas administrativas de SQL Server. Para que el Agente SQL Server ejecute trabajos y
active alertas, debe estar en funcionamiento siempre y debe contar con permisos suficientes. Al
usar el Agente SQL Server, el administrador de las bases de datos podrá programar tareas

mucho más complejas con más flexibilidad que usando exclusivamente el Asistente para
planes de mantenimiento.
Servicio Agente SQL Server
En todos los sistemas operativos Microsoft Windows Server™ 2003 y 2008, el Agente SQL
Server se ejecuta como servicio de Windows.
Deberá estar en funcionamiento para ejecutar trabajos programados y activar las alertas
definidas. Debería configurar el servicio Agente SQL Server para que se inicie
automáticamente cada vez que Windows Server 2003 o Windows 2008 se inician.
Además, puede configurar el servicio Agente SQL Server para que se reinicie automáticamente
si se detiene inesperadamente mediante el Administrador de configuración de SQL Server.
Para que se reinicie automáticamente, la cuenta de servicio Agente SQL Server debe ser un
miembro del grupo local Administradores.
Configurar el Agente SQL Server
El Agente SQL Server se implementa como un servicio de Windows. Cada instancia de SQL
Server tiene su propio servicio de Agente SQL Server, que se denomina SQLSERVERAGENT
para instancias predeterminadas, o bien SQLAgent$nombre_instancia para las instancias que
ya tengan un nombre.

Configuración de inicio del servicio Agente SQL Server
Como cualquier servicio de Windows, el servicio Agente SQL Server puede configurarse para
que se inicie manual o automáticamente o puede deshabilitarse. De forma predeterminada, el
servicio Agente SQL Server está definido para que se inicie manualmente cuando SQL Server
2008 está instalado.
Es posible cambiar la configuración de inicio del servicio Agente SQL Server usando el
Administrador de configuración de SQL Server o la herramienta administrativa de los servicios
de Windows. Si piensa implementar trabajos y alertas automatizados, por lo general debería
establecer que el servicio Agente SQL Server se iniciara automáticamente al arrancar
Windows, a menos que haya una buena razón para iniciar el servicio manualmente.
Cuando se inicia, el servicio Agente SQL Server se conecta a SQL Server y ejecuta el
procedimiento almacenado extendido xp_sqlagent_monitor en la base de datos master. Este
procedimiento almacenado supervisa el estado del servicio Agente SQL Server y lo reinicia si
se detiene inesperadamente.
ESPECIFICAR UNA CUENTA DE SERVICIO AGENTE SQL SERVER
Puede configurar el servicio Agente SQL Server para que se ejecute como una cuenta
integrada o como una cuenta de usuario de Windows concreta. Se pueden usar las siguientes
cuentas integradas para el servicio Agente SQL Server:
Sistema local. La cuenta de sistema local es miembro del grupo local Administradores. Sólo se
ofrece la posibilidad de usar esta cuenta para la compatibilidad con versiones anteriores y no
debería usarse para el servicio Agente SQL Server.
Servicio local. La cuenta de servicio local dispone de permisos similares a los de un usuario
local y tiene acceso a los recursos de red mediante una sesión nula sin credenciales. La cuenta
de servicio local es adecuada para el servicio Agente SQL Server cuando todos los trabajos y
alertas se pueden implementar de manera local en el servidor.
Servicio de red. La cuenta de servicio de red dispone de permisos similares a los de un usuario
local y tiene acceso a los recursos de red mediante las credenciales de la cuenta del equipo.
Microsoft recomienda que no se use la cuenta de servicio de red con el servicio Agente SQL
Server.

En la mayoría de los casos, debería especificar una cuenta de usuario local o de usuario de
dominio para el servicio Agente SQL Server y asignar los permisos y derechos de usuario
mínimos que la cuenta de servicio necesite. El servicio Agente SQL Server requiere el derecho
de usuario iniciar sesión como un servicio. Además, los siguientes derechos de usuario son
necesarios para que los servidores proxy del Agente SQL Server sean compatibles:
■ Actuar como parte del sistema operativo
■ Omitir comprobación de recorrido
■ Reemplazar un testigo de nivel de proceso
■ Ajustar las cuotas de memoria para un proceso
■ Iniciar sesión como trabajo por lotes
Si los derechos de usuario que se han descrito anteriormente no se conceden, sólo los
miembros de la función fija de servidor sysadmin pueden crear trabajos.
Finalmente, la cuenta de servicio Agente SQL Server usa la autenticación de Windows para
conectar con SQL Server y debe asignarse a un inicio de sesión que sea miembro de la función
fija de servidor sysadmin. Si se van a crear trabajos multiservidor, se debería asignar el inicio
de sesión a un usuario que sea miembro de la función de la base de datos TargetServersRole
en la base de datos msdb en el servidor principal.
Dependencias del servicio Agente SQL Server
El servicio Agente SQL Server depende del servicio de SQL Server para la instancia a la que
pertenece. Además, algunas operaciones realizadas por el Agente SQL Server podrían
basarse en otros servicios de Windows. Por ejemplo, para enviar las notificaciones del
operador usando el comando net send, debe iniciarse previamente el servicio Windows
Messenger.
Opciones de correo del Agente SQL Server
SQL Server 2008 incluye dos mecanismos para enviar correo electrónico: Correo electrónico
de base de datos y SQL Mail. Puede configurar el Agente SQL Server para que use cualquiera
de estos mecanismos al enviar las notificaciones por correo electrónico.
Usar Correo electrónico de base de datos con el Agente SQL Server
El Correo electrónico de base de datos es una función de SQL Server 2008 que permite a SQL
Server enviar correo electrónico a través de un servidor de Protocolo simple de transporte de
correo (SMTP, Simple Mail Transport Protocol). Para usar la función Correo electrónico de base
de datos con el Agente SQL Server, debe realizar las tareas de configuración siguientes:
Habilite el Correo electrónico de base de datos.
Cree un perfil de Correo electrónico de base de datos que incluya una cuenta de correo
electrónico que use el Agente SQL Server. Haga que éste sea el perfil predeterminado del
usuario en la base de datos msdb que se asigna al inicio de sesión de la cuenta de servicio
Agente SQL Server.
Agregue al usuario para el inicio de sesión de la cuenta de servicio Agente SQL Server a la
función de base de datos DatabaseMailUserRole en la base de datos msdb.
Configure las propiedades del sistema de alertas del Agente SQL Server para usar el Correo
electrónico de base de datos y especifique el perfil que haya creado en los pasos anteriores.

Reinicie el servicio Agente SQL Server.
Usar SQL Mail con el Agente SQL Server
SQL Mail es una función de correo electrónico basada en una Interfaz de programación de
aplicaciones de mensajería (MAPI, Messaging Application Programming Interface) que puede
usar para configurar SQL Server para enviar y recibir el correo electrónico a través de Microsoft
Exchange Server. Para usar SQL Mail, debe configurar un perfil de MAPI en el equipo de SQL
Server para la cuenta de servicio Agente SQL Server, que requiere la instalación de un cliente
de correo electrónico como Microsoft Office
Outlook®.
Crear trabajos y operadores
Un trabajo es una serie especificada de operaciones realizada secuencialmente por el Agente
SQL Server. Un trabajo puede realizar una amplia gama de actividades, incluso ejecutar
secuencias de comandos de Transact-SQL, aplicaciones de línea de comandos, secuencias de
comandos de 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. Además, pueden notificar automáticamente a los usuarios conocidos, como
operadores, acerca del estado del trabajo mediante la generación de alertas, con lo que se
simplifica en gran medida la administración de SQL Server.
Puede ejecutar manualmente un trabajo o puede configurarlo para que se ejecute según una
programación o como respuesta a alertas.

Crear trabajos
Puede usar SQL Server Management Studio o ejecutar el procedimiento almacenado del
sistema sp_add_job para definir un trabajo nuevo. La definición del trabajo se almacena en la
tabla del sistema sysjobs en la base de datos msdb. Esta tabla se mantiene en caché para
mejorar el rendimiento.
Al definir los trabajos, debe hacer lo siguiente:
Asegúrese de que el trabajo esté habilitado. Los trabajos se habilitan de manera
predeterminada. Si un trabajo se deshabilita, no podrá ejecutarse tal y como estaba
programado. Sin embargo, un usuario todavía puede ejecutar manualmente un trabajo
deshabilitado si lo inicia en el Administrador corporativo de SQL Server.
Especifique el propietario responsable de la realización del trabajo. De forma predeterminada,
el propietario es la cuenta de inicio de sesión del usuario de Windows o SQL Server que ha
creado el trabajo.
Defina si el trabajo se ejecuta en un servidor local o en varios servidores remotos.
Cree categorías de trabajo que le sirvan para organizar, filtrar y administrar muchos trabajos.
Por ejemplo, puede crear categorías de trabajo que se correspondan con los departamentos en
su organización.
¿Qué es un operador?
Los operadores son los alias para personas o grupos que pueden recibir notificación
electrónica cuando los trabajos hayan finalizado o se hayan emitido las alertas.
Los operadores deberían definirse antes que las alertas. Cuando un trabajo finaliza, o si
cualquiera de los pasos del trabajo falla, puede notificar a un operador mediante un localizador,
correo electrónico o un comando net send.

Directrices para la creación de operadores
sistema sp_add_operator para definir un nuevo operador. La definición del operador se
almacena en la tabla del sistema sysoperators en la base de datos msdb.
Al crear operadores, deberá hacer lo siguiente:
Use un alias de grupo de correos electrónicos para notificar a más de una persona para que
respondan a problemas potenciales.
Pruebe cada método de notificación que se use para notificar al operador a fin de garantizar
que el operador puede recibir los mensajes.
Especifique un programa de trabajo para cada operador al que se va a notificar mediante su
localizador. Si un trabajo que está definido para que se notifique a un operador mediante un
localizador está en conflicto con el programa de trabajo del operador, se producirá un error en
la notificación.
DEFINIR UN OPERADOR A PRUEBA DE ERRORES
Puede definir un operador a prueba de errores para que responda a una alerta cuando las
notificaciones mediante localizador enviadas a los operadores definidos fallen. Por ejemplo, si
todos los operadores no están disponibles cuando se activa una alerta, se pondrá en contacto
con el operador a prueba de errores.
Se notificará a un operador a prueba de errores cuando se cumplan las siguientes condiciones:
La alerta tiene definidas notificaciones del localizador para la respuesta.
Ninguno de los operadores a los que se va a avisar mediante un localizador está de servicio.
Se ha definido un operador a prueba de errores.
Al asignar un operador a prueba de errores, tenga en cuenta lo siguiente:
La información del operador a prueba de errores se almacena en la memoria caché de manera
que no dependa de la conexión con la base de datos msdb.
Sólo puede haber un operador a prueba de errores.
No puede eliminar un operador designado como operador a prueba de errores. Sin embargo,
puede quitar la asignación de operador a prueba de errores y, a continuación, eliminar al
operador.

Cómo crear pasos de trabajo
sistema sp_add_jobstep para definir cada paso del trabajo. Las definiciones de los pasos del
trabajo se almacenan en la tabla del sistema sysjobsteps en la base de datos msdb.
Puede definir pasos de trabajo para ejecutar instrucciones Transact-SQL, comandos del
sistema operativo, secuencias de comandos de ActiveX o tareas de réplica de SQL Server. Sin
embargo, sólo se puede especificar un tipo de ejecución para cada paso de trabajo.
Definir los pasos de trabajo de Transact-SQL
Al definir los pasos de trabajo para ejecutar instrucciones Transact-SQL, procedimientos
almacenados o procedimientos almacenados extendidos, tenga en cuenta las instrucciones
siguientes:
Debe identificar la base de datos que se va a usar.
Debe incluir variables necesarias y parámetros en el paso de trabajo.
Puede enviar el conjunto de resultados de un paso de trabajo a un archivo de salida.
Los archivos de salida se usan a menudo en la solución de problemas para capturar cualquier
mensaje de error que puede haber aparecido mientras la instrucción se estaba ejecutando. No
puede usar un archivo de salida de un paso de trabajo como entrada en un paso subsiguiente.
Definir los pasos de trabajo de comandos del sistema operativo
Al definir un paso de trabajo para ejecutar una aplicación o comando del sistema operativo
(identificado mediante las extensiones de nombre de archivo .exe, .bat, .cmd o .com), deberá
hacer lo siguiente:
Identificar un código de salida de proceso para indicar que el comando se ejecutó
correctamente.
Incluir la ruta de acceso completa a la aplicación ejecutable. La ruta de acceso es necesaria
para ayudar al Agente SQL Server a encontrar el origen de la aplicación.
Definir los pasos de trabajo de secuencias de comandos de ActiveX

Puede escribir los pasos de trabajo usando las secuencias de comandos de ActiveX con
lenguajes como Microsoft Visual Basic® Scripting Edition (VBScript) o Microsoft JScript®.
También puede usar otros lenguajes si se instala la biblioteca correspondiente al lenguaje de
secuencia de comandos.
Al crear un paso de trabajo de secuencias de comandos de ActiveX, deberá realizar lo
siguiente:
Identificar el lenguaje de secuencia de comandos con el que se escribe el paso de trabajo.
Escribir o abrir la secuencia de comandos activa. Puede usar el objeto SQLActiveScriptHost
para imprimir el resultado en el historial del paso de trabajo o para crear objetos.
Lógica de flujo de los pasos de trabajo
Al crear los trabajos, un administrador de bases de datos debería especificar las medidas que
SQL Server debería tomar si un paso de trabajo se realiza correctamente o si se produce un
error. De forma predeterminada, SQL Server avanza al paso de trabajo siguiente si se realiza
correctamente y se detiene si se produce un error.
Sin embargo, los pasos de trabajo pueden ir a cualquier paso definido en el trabajo tanto si es
correcto como si se produce un error.
Puede especificar el número de veces que SQL Server debería intentar la ejecución de un paso
de trabajo si se produce un error en él. También puede especificar el intervalo entre cada
reintento (en minutos).
Por ejemplo, si el paso de trabajo requiere una conexión a un servidor remoto, podría definir
varios intentos en caso de producirse un error en la conexión.
Además, si define un trabajo para que sólo se ejecute una vez, puede especificar que se
elimine el trabajo cuando finalice.
¿Qué es el Monitor de actividad de trabajo?
El Monitor de actividad de trabajo es una herramienta de SQL Server Management Studio que
le permite ver la tabla sysjobactivity. Puede ver todos los trabajos en el servidor o puede definir
los filtros para limitar el número de trabajos mostrados.
También puede ordenar la información del trabajo haciendo clic en un encabezado de columna
en la cuadrícula Actividad de trabajo del agente. Por ejemplo, al seleccionar el encabezado de
la columna Última ejecución, podrá ver los trabajos en el orden en que se ejecutaron en último
lugar. Al hacer clic de nuevo en el encabezado de columna, los trabajos se muestran en orden
ascendente y descendente según su última fecha de ejecución.
Cuándo usar el Monitor de actividad de trabajo

Use el Monitor de actividad de trabajo cuando desee determinar cuáles son los trabajos
programados para ejecutarse, el último resultado de los trabajos que se han ejecutado durante
la sesión actual y cuáles se están ejecutando o están inactivos. Si se produce un error
inesperado en el servicio Agente SQL Server, podrá determinar los trabajos que se estaban
ejecutando examinando la sesión anterior en el Monitor de actividad de trabajo.
Puede realizar las tareas siguientes con el Monitor de actividad de trabajo:
Iniciar y detener trabajos.
Ver las propiedades de los trabajos.
Ver el historial de un trabajo concreto.
Actualizar manualmente la información en la cuadrícula Actividad de trabajo del agente o
establecer un intervalo de actualización automática haciendo clic en Ver configuración de
actualización.
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 Trabajos y haga clic en
Ver actividad de trabajo.
También puede ver la actividad del trabajo para la sesión actual mediante el procedimiento
almacenado sp_help_jobactivity.
Crear alertas
Las alertas son respuestas predefinidas a eventos concretos que pueden producirse en una
solución SQL Server. Puede definir alertas para realizar un trabajo o notificar a un operador
cuando se produce un evento determinado o se excede un umbral de rendimiento.
SQL Server genera eventos y se anotan en el registro de aplicación de Windows. El Agente
SQL Server lee el registro de aplicación y compara los eventos anotados con las alertas que ha
definido. Cuando el Agente SQL Server encuentra una coincidencia, emite una alerta, es decir,
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 del
Instrumental de administración de Windows (WMI, Windows Management Instrumentation).
DEFINIR ALERTAS PARA ERRORES DE SQL SERVER

Al crear una alerta para que emita una respuesta cuando se produzca un error de SQL Server,
podrá especificar un número de error único (p. ej., el 9002) o todos los errores de un nivel de
gravedad concreto (p. ej., el 17). Puede definir una alerta en un número de error o nivel de
gravedad para todas las bases de datos o para una base de datos concreta.
Nota Para un evento determinado se emitirá a lo sumo una alerta. El Agente SQL Server
emitirá la alerta más específica que se haya definido. Por ejemplo, si tiene una alerta definida
con errores de un nivel de gravedad 17 y además tiene una alerta definida en el error 9002
(que también pertenece al nivel de gravedad 17), se emitirá el error 9002.
Definir alertas para condiciones de rendimiento
Además de usar alertas para responder a los errores de SQL Server, puede usarlas para
responder a condiciones de rendimiento de SQL Server como aquéllas que se pueden ver en el
Monitor de sistema de Windows. Cuando se excede el valor de la condición, se emite una
alerta.
Por ejemplo, puede crear una alerta de condición de rendimiento que se desencadene cuando
el registro de transacciones en la base de datos AdventureWorks haya excedido el 75 por
ciento de su capacidad. La respuesta de la alerta podría ejecutar un trabajo para realizar una
copia de seguridad del registro de transacciones y notificar al administrador de la base de
datos.
CÓMO SE CREA UNA ALERTA
Puede crear una alerta mediante SQL Server Management Studio o mediante el procedimiento
almacenado de Transact-SQL sp_add_alert.
Para crear una alerta, tiene que especificar lo siguiente:
El nombre de la alerta.
El evento o condición de rendimiento que desencadena la alerta.
Las medidas que el Agente SQL Server toma como respuesta al evento o condición de
rendimiento.
El tipo de evento determina los parámetros que usa para especificar el evento en concreto.
Especificar un operador
Las medidas que toma el Agente SQL Server como respuesta al evento o condición de
rendimiento pueden incluir ponerse en contacto con el operador. Para ello, debe especificar la
información de contacto de ese operador y definir cómo se le notificará. Se puede notificar al
operador por correo electrónico, localizador, o mediante el comando net send.
Ejecutar un trabajo
Las medidas que el Agente SQL Server toma como respuesta al evento o condición de
rendimiento pueden incluir la ejecución de un trabajo. Para que una alerta inicie un trabajo,
debe especificar el nombre del trabajo en la página de respuesta de la alerta. Puede usar un
trabajo existente o crear uno nuevo cuando defina la alerta.

C
CA
AP
PI
IT
TU
UL
LO
O 8
8
 Implementando un DataBase Mirroring
 Replicación de una BD.
 Examen Final.

I M P L E M E N T A R L A C R E A C I Ó N D E R E F L E J O
D E B A S E D E D A T O S
La creación de reflejo de la base de datos es una solución de alta disponibilidad alternativa al
clúster de conmutación por error en SQL Server 2008 Enterprise Edition. La creación de reflejo
de la base de datos admite la conmutación por error automática, pero no requiere un hardware
compatible con los clústeres. Por tanto, puede proporcionar una alternativa rentable al clúster
de conmutación por error.
Importante
Las directivas de soporte técnico de Microsoft no se aplican a la función de creación de
reflejo de la base de datos en SQL Server 2008. La creación de reflejo de la base de
datos está deshabilitada de forma predeterminada, pero puede habilitarse para
evaluarla únicamente mediante el uso de la marca de traza 1400 como parámetro de
inicio. Para obtener más información acerca de las marcas de traza, consulte “Marcas
de traza (Transact-SQL)” en los Libros en pantalla de SQL Server. La creación de
reflejo de la base de datos no se debería usar en entornos de producción. Los servicios
de soporte técnico de Microsoft no admiten bases de datos ni aplicaciones que usen la
creación de reflejo de la base de datos. La documentación sobre la creación de reflejo
de la base de datos se incluye en SQL Server 2008 sólo como evaluación. La directiva
de documentación para soporte técnico y actualización de SQL Server
¿Qué son los reflejos de base de datos?
La creación de reflejo de la base de datos ofrece una solución de alta disponibilidad alternativa
al clúster de conmutación por error. La creación de reflejo de la base de datos se puede
implementar con hardware estándar. Toda la administración tendrá lugar en su totalidad en
SQL Server.
En una solución de creación de reflejo de la base de datos, se almacena una base de datos en
un servidor y se copia en otro. De esta forma se proporciona una copia de reserva de la base
de datos que puede prestar servicio a los clientes en caso de un error de servidor.

Funciones de servidor en la creación de reflejo de la base de
datos
La creación de reflejo de la base de datos requiere varias instancias de SQL Server, que se
deberían instalar en equipos independientes para proporcionar protección frente a los errores
del servidor. Las funciones del servidor en una solución de creación de reflejo de la base de
datos son:
Servidor principal. El servidor principal aloja la copia activa de la base de datos (denominada
base de datos principal) y presta servicio a las solicitudes de los clientes. El servidor principal
reenvía todas las transacciones al servidor reflejado antes de aplicarlas en la base de datos
principal.
Servidor reflejado. El servidor reflejado aloja una copia de la base de datos principal
(denominada base de datos reflejada) y aplica las transacciones reenviadas por la base de
datos principal para mantener la base de datos reflejada sincronizada con la principal.
Servidor testigo. El servidor testigo es un componente opcional de una solución de creación de
reflejo de la base de datos. Cuando está presente, un servidor testigo supervisa los servidores
principales y reflejados para asegurar una conectividad continuada y la participación en la
sesión de reflejo (denominada quórum). Si uno de los servidores pierde el quórum, el servidor
testigo asigna la función de servidor principal, con lo que se produce la conmutación por error
automática del servidor principal al reflejado si fuera necesario. Los servidores testigo son
necesarios para la conmutación por error automática; sin embargo, un servidor testigo puede
admitir varias sesiones de reflejo porque no se trata de una tarea intensiva.
Redireccionamiento de clientes en una solución de creación de
reflejo de la base de datos
Cuando una sesión de creación de reflejo de la base de datos se conmuta por error, todas las
aplicaciones cliente deben conectarse al nuevo servidor principal (el servidor reflejado anterior).
Las aplicaciones cliente que usan SQL Native Client o el proveedor de datos Microsoft .NET
Framework 2.0 para Microsoft SQL Server admiten la redirección automática de clientes y
pueden controlar de forma transparente la conmutación por error al servidor reflejado. Las
aplicaciones cliente que usen otras tecnologías de acceso de datos deben adaptarse para
redirigir las solicitudes al servidor reflejado en el caso de conmutación por error.

CUÁNDO USAR LA CREACIÓN DE REFLEJO DE LA BASE DE DATOS
La creación de reflejo de la base de datos se usa en los siguientes casos:
Cuando necesita redundancia en el nivel de base de datos individual.
Cuando no desea invertir en hardware compatible con clústeres.
Cuando necesita una carga de trabajo administrativa inferior a la asociada con el clúster de
conmutación por error.
OPCIONES PARA LA CONFIGURACIÓN DE LA CREACIÓN DE REFLEJOS DE LA
BASE DE DATOS
Hay tres modos de creación de reflejo de la base de datos. El nivel de rendimiento y protección
difieren entre los modos, por lo que deberá tenerse cuidado a la hora de proporcionar la
solución adecuada para el sistema.
MODO DE ALTA DISPONIBILIDAD
En el modo de alta disponibilidad, se establece la seguridad de la transacción en COMPLETA,
lo que provoca que las transacciones se apliquen a las bases de datos principal y reflejada de
manera sincronizada. Cuando el servidor principal confirma una transacción, el servidor
reflejado también lo hace. El servidor principal sólo emite una confirmación una vez que el
servidor reflejado ha enviado la confirmación de que ha almacenado la transacción en el disco.
El modo de alta disponibilidad usa un servidor testigo. Debería colocarse en un tercer servidor
(no en el principal ni en el reflejado) para ofrecer redundancia. El modo de alta disponibilidad
permite la conmutación por error automática o manual del servidor principal en el reflejado.
Si se produce un error en el servidor principal en el modo de alta disponibilidad, el servidor
testigo inicia la conmutación por error automática en el reflejado. Si se produce un error en el
servidor reflejado, la base de datos sigue con conexión mientras se mantenga el quórum entre
los servidores principal y testigo.
MODO DE ALTA PROTECCIÓN
En el modo de alta protección, la seguridad de la transacción se establece en COMPLETA para
aplicar transacciones de manera sincronizada, tal y como ocurre en el modo de alta
disponibilidad. Sin embargo, el modo de alta protección no usa un servidor testigo.
Si se produce un error en el servidor principal en el modo de alta protección, habrá una copia
completa de los datos en el servidor reflejado, pero deberá realizar manualmente la
conmutación por error. Si se produce un error en el servidor reflejado, el principal se
desconecta por sí mismo para evitar el riesgo de pérdida de datos.

MODO DE ALTO RENDIMIENTO
En el modo de alto rendimiento, la seguridad de la transacción se desactiva y las transacciones
se aplican de forma asíncrona. De esta forma el servidor principal responde a los clientes sin
comprobar primero que las transacciones se hayan aplicado en el servidor reflejado. Aunque
así se obtiene mejor rendimiento, se sacrifica la alta disponibilidad.
Si se produce un error en el servidor principal en el modo de alto rendimiento, deberá conmutar
por error manualmente al servidor reflejado. Sin embargo, debido a que es posible que algunas
transacciones se completen en el servidor principal pero no en el reflejado, es posible que
pierda algunos datos. Si se produce un error en el servidor reflejado en el modo de alto
rendimiento, el servidor principal no se verá afectado.
¿Qué son los extremos en la creación de reflejos de base de
datos?
Un extremo es un objeto de SQL Server que permite la conectividad de red con el servidor.
Para la creación de reflejo de la base de datos, un extremo define el puerto TCP en el que una
instancia está a la escucha de mensajes de creación de reflejo. Cada instancia necesita un
extremo dedicado.
CREAR EXTREMOS DE REFLEJO
La instrucción CREATE ENDPOINT genera extremos para la creación de reflejo de la base de
datos.
Puede usar tanto la autenticación de Windows como la autenticación basada en certificados
como el modo de autenticación de los extremos. La sintaxis para crear los extremos se muestra
en la siguiente muestra de código de Transact-SQL:
CREATE ENDPOINT <endpointName>
STATE=STARTED
AS TCP ( LISTENER_PORT = <listenerPortList> )
FOR DATABASE_MIRRORING (
[ AUTHENTICATION = {
WINDOWS [ { NTLM | KERBEROS | NEGOTIATE } ]
| CERTIFICATE certificate_name
} ]

[ [ , ] ENCRYPTION = { DISABLED |SUPPORTED | REQUIRED }
[ ALGORITHM { RC4 | AES | AES RC4 | RC4 AES } ]
]
[,] ROLE = { WITNESS | PARTNER | ALL }
)
Parámetros
Los parámetros de la instrucción CREATE ENDPOINT para la creación de reflejo de la base de
datos se describen en la lista siguiente.
<endpointName>. Nombre único para el extremo de la creación de reflejo de la base de datos
de la instancia del servidor.
STARTED. Especifica que se va a iniciar el extremo y que va a empezar a escuchar las
conexiones. Normalmente se crea un extremo de creación de reflejo de la base de datos en el
estado STARTED. De manera alternativa, puede iniciar una sesión en el estado
predeterminado detenido (STOPPED) o en el deshabilitado (DISABLED).
<listenerPortList>. Lista de uno o varios números de puerto en los que desea que el servidor
realice escuchas de mensajes de creación de reflejo de la base de datos. Debe especificar
TCP, ya que si especifica cualquier otro protocolo se produce un error.
AUTHENTICATION. Especifica el modo de autenticación para el extremo. En el caso de la
autenticación de Windows, no es necesario especificar la opción de autenticación
(AUTHENTICATION) a menos que desee que el extremo use sólo NTLM o Kerberos para
autenticar las conexiones. <authorizationMethod> especifica el método usado para autenticar
las conexiones como una de las siguientes: NTLM, KERBEROS o NEGOTIATE. El método
predeterminado, NEGOTIATE, hace que el extremo use el protocolo de negociación de
Windows para elegir NTLM o Kerberos.
Para la autenticación basada en certificados, debe especificar un certificado existente.
ENCRYPTION. Especifica si se deberían cifrar las conexiones con el extremo, además del
algoritmo de cifrado que se va a usar. El ajuste de cifrado predeterminado es REQUIRED. Sin
embargo, puede deshabilitar el cifrado o hacerlo opcional en un extremo.
ROLE. Define la función o funciones que el servidor puede realizar. Es necesario especificar
ROLE. Para permitir a una instancia del servidor actuar como una función para una sesión de
creación de reflejo de la base de datos y una función diferente para otra sesión, especifique
ROLE=ALL. Para restringir una instancia de servidor para ser un socio o un testigo, especifique
ROLE=PARTNER o ROLE=WITNESS, respectivamente.
CÓMO PREPARAR LOS SERVIDORES PARA LA CREACIÓN DE REFLEJOS DE LA
BASE DE DATOS
Hay varios pasos que realizar antes de activar la creación de reflejo de la base de datos.
Tareas de preparación de creación de reflejo de la base de datos
Antes de poder establecer una sesión de creación de reflejo de la base de datos, debe realizar
las tareas de preparación descritas en la lista siguiente:
Crear extremos de reflejo e inicios de sesión. Debe crear extremos y un inicio de sesión en la
base de datos master para cualquier instancia del servidor que se ejecute como una cuenta de
usuario de dominio diferente del servidor principal.
Establecer el modelo de recuperación. Debe establecer el modelo de recuperación para la base
de datos que se va a reflejar en COMPLETO (full).
Realizar una copia de seguridad de la base de datos principal y restaurarla en el servidor
reflejado. Debe realizar una copia de seguridad completa de la base de datos principal y

restaurarla en la instancia reflejada mediante la especificación de NORECOVERY y el uso del
mismo nombre como la base de datos principal.
De manera alternativa, podría usar una copia de seguridad completa reciente. Si es el caso,
debería restaurar cualquier copia de seguridad del registro desde la copia de seguridad
completa y realizar una copia de seguridad y una restauración del registro de transacciones
para asegurarse de que los datos están al día.
Copiar recursos de nivel de servidor. Debería copiar manualmente cualquier recurso de nivel
de servidor, como inicios de sesión o trabajos del Agente SQL, que serían necesarios en el
caso de conmutación por error a la instancia reflejada.
CÓMO ESTABLECER UNA SESIÓN DE REFLEJO
Después de haber preparado los servidores, puede establecer una sesión de reflejo.
Necesita configurar los servidores reflejados y principales para hacer referencia los unos a los
otros con objeto de crear una sesión de reflejo en el modo de alta protección. Podrá cambiar a
continuación el modo de sesión de reflejo según sea necesario agregando un servidor testigo
para habilitar el modo de alta disponibilidad o deshabilitando la seguridad de la transacción
para activar el modo de alto rendimiento.
Establecer una sesión de reflejo
Es posible establecer una sesión de reflejo con el asistente en el cuadro de diálogo
Propiedades de la base de datos en el Explorador de objetos mediante la instrucción ALTER
DATABASE.
Use el proceso siguiente para establecer una sesión de reflejo:

1. Establezca el servidor principal a partir del servidor reflejado, tal y como se muestra en la
siguiente muestra de código:
ALTER DATABASE AdventureWorks SET PARTNER = 'TCP://
DBSERVER1.COMPANYINFO.MIEMPRESA.COM: 5022'
2. Establezca el servidor reflejado a partir del principal, tal y como se muestra en la siguiente
muestra de código:
ALTER DATABASE AdventureWorks
SET PARTNER = 'TCP://DBSERVER1.COMPANYINFO.MIEMPRESA.COM: 5023'
3. Si fuera necesario, cambie el modo de sesión de reflejo de protección alta.
Para definir el modo de alta disponibilidad, agregue un servidor testigo desde el servidor
principal o desde el reflejado, tal y como se muestra en la siguiente muestra de código:
ALTER DATABASE AdventureWorks SET WITNESS = 'TCP://
DBSERVER1.COMPANYINFO.MIEMPRESA.COM: 5024'
Para establecer el modo de alto rendimiento, desactive la seguridad de las transacciones en el
servidor principal, tal y como se muestra en la siguiente muestra de código:
ALTER DATABASE AdventureWorks SET PARTNER SAFETY OFF
Cómo tratar la conmutación por error
La conmutación por error puede ser automática o manual. Es posible usar la conmutación por
error manual aun cuando la conmutación por error automática está disponible si necesita dejar
sin conexión a un servidor para realizar tareas de mantenimiento.
El modo de alta disponibilidad puede usar la conmutación por error automática o manual. El
modo de alta protección puede usar la conmutación por error manual o el servicio forzado (con
posible pérdida de datos). El modo de alto rendimiento puede usar el servicio forzado (con
posible pérdida de datos).
Conmutación por error automática
Si se produce un error en el servidor principal en el modo de alta disponibilidad, la conmutación
por error será automática. Cuando el servidor principal está sin conexión, el reflejado y el

testigo formarán un quórum y harán que el reflejado sea ahora el principal. Si el servidor
principal original vuelve a conectarse, pasará a ser el reflejado.
Conmutación por error manual
Si se produce un error en el servidor principal en el modo de alta protección, debe iniciar la
conmutación por error manual realizando los pasos siguientes en el servidor principal:
Conecte con 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, a continuación, seleccione la base de datos para la que se va a
crear el reflejo.
Haga clic con el botón secundario en la base de datos y, a continuación, haga clic en
Propiedades; se abrirá el cuadro de diálogo Propiedades de la base de datos.
En el panel Seleccionar una página, haga clic en Creación de reflejo.
Haga clic en Conmutación por error.
De manera alternativa puede iniciar la conmutación por error manual usando Transact-SQL en
el servidor principal, tal y como se muestra en la siguiente muestra de código:
ALTER DATABASE AWData SET PARTNER FAILOVER
Servicio forzado (con posible pérdida de datos)
Si se produce un error en el servidor principal en el modo de alto rendimiento, puede forzar el
servicio en el servidor reflejado, con posible pérdida de datos, usando la instrucción ALTER
DATABASE con el parámetro FORCE_SERVICE_ALLOW_DATA_LOSS, tal y como se
muestra en la siguiente muestra de código:
ALTER DATABASE AWData SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
¿Qué es el trasvase de registros?
El trasvase de registros es una técnica de alta disponibilidad en la que el registro de
transacciones del servidor primario se restaura periódicamente en un servidor de reserva.
Puede programar las copias de seguridad del registro para que se produzcan con una
frecuencia que se adapte a los requisitos de disponibilidad y rendimiento.
Además de proporcionar redundancia, el servidor de reserva se puede usar para consultas de
sólo lectura y de esta forma aliviar parte de la carga del servidor primario.

En el caso de que se produzca un error en el servidor primario, la conmutación por error
automática no tendrá lugar. Debe promover manualmente el servidor de reserva y reconfigurar
todos los clientes para que se conecten a él. Si es necesaria una solución más automatizada,
debería considerar la creación de reflejo de la base de datos o el clúster de servidores.
De manera opcional, puede crear un servidor de supervisión. El servidor de supervisión registra
cualquier problema con el trasvase de registros además de enumerar las últimas operaciones
de copia de seguridad y restauración. Los servidores de supervisión deberían separarse de los
servidores primarios y de reserva en caso de error en los servidores.
CÓMO IMPLEMENTAR EL TRASVASE DE REGISTROS
Puede configurar el trasvase de registros mediante SQL Server Management Studio o usando
Transact-SQL.
Antes de configurar el trasvase de registros, sin embargo, deberá realizar las siguientes tareas:
Cree un recurso compartido de archivos para las copias de seguridad del registro de
transacciones, preferiblemente en un servidor tolerante a errores que no forma parte de la
configuración del trasvase de registros. Para maximizar la disponibilidad del servidor primario,
Microsoft recomienda que coloque el recurso compartido de copia de seguridad en un equipo
host independiente.
Cree una carpeta para cada servidor secundario en el que el trasvase de registros copiará los
archivos de copia de seguridad del registro de transacciones. Estas carpetas se colocan
normalmente en los servidores secundarios.
Transact-SQL
Use los siguientes procedimientos almacenados para configurar el trasvase de registros:
sp_add_log_shipping_primary_database
sp_add_jobschedule
sp_add_log_shipping_alert_job
sp_add_log_shipping_secondary_primary
sp_add_log_shipping_secondary_database
sp_add_log_shipping_primary_secondary
CÓMO CAMBIAR FUNCIONES DE SERVIDOR
El cambio de funciones convierte el servidor de reserva en servidor primario. Necesita realizar
un cambio de funciones si el servidor primario se queda inesperadamente sin conexión o si
necesita que el servidor primario esté sin conexión para realizar tareas de mantenimiento.

La primera vez que cambia las funciones, necesitará configurar el trasvase de registros en la
base de datos secundaria. Esto no es necesario para los cambios de funciones siguientes, por
lo que será más fácil cambiar y volver al estado previo.
Cambiar funciones
Realice los pasos siguientes para cambiar las funciones o para que el servidor de reserva pase
a ser el servidor primario:
1. Copie cualquier copia de seguridad del registro de transacciones del recurso compartido de
copia de seguridad en la carpeta de destino y restaure éstas y otras copias de seguridad de la
carpeta en el servidor de reserva.
2. Realice una copia de seguridad del registro con NORECOVERY si el servidor primario está
disponible, tal y como se muestra en el siguiente código de Transact-SQL:
BACKUP LOG AdventureWorks TO AWLogBackup
WITH NORECOVERY
3. Restaure la copia de seguridad del paso anterior en el servidor de reserva con la instrucción
RECOVERY, tal y como se muestra en el siguiente código de Transact-SQL:
RESTORE LOG AdventureWorks FROM AWLogBackup
WITH RECOVERY
De manera alternativa, si no hay disponible ninguna copia de seguridad, lleve a cabo una
restauración con RECOVERY sin especificar un archivo de copia de seguridad, tal y como se
muestra en el siguiente código de Transact-SQL:
RESTORE LOG AdventureWorks
WITH RECOVERY
4. Deshabilite los trabajos de trasvase de registros en el servidor primario original y deshabilite
la copia y restaure los trabajos en el servidor secundario original.
5. Si es la primera vez que se han cambiado las funciones del servidor, tendrá que configurar el
trasvase de registros en la base de datos secundaria. Debería tratarla ahora como una base de
datos primaria. Use el mismo recurso compartido para crear copias de seguridad que ya creó
para el servidor primario original. Al agregar 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 y, a continuación, seleccione No, la base de datos secundaria está
inicializada.
Introducción a la réplica
¿Qué es la réplica?
La réplica es el mecanismo para crear y mantener varias copias de los mismos datos. Los
datos se distribuyen de forma flexible, lo que da más autonomía a los sitios y garantiza que las
actualizaciones se replican en un período de tiempo aceptable. SQL Server 2008 tiene varios
métodos de réplica disponibles, lo que permite su uso en distintos escenarios.
Ventajas de la réplica
La réplica ofrece varias ventajas al sistema de base de datos:
■ Acerca los datos a usuarios alejados geográficamente.
■ Permite que los sitios autónomos no tengan que estar conectados continuamente.
■ Permite mantener copias independientes de los datos del Procesamiento de transacciones en
línea (OLTP) y del Sistema de ayuda a la toma de decisiones (DSS).
Por su naturaleza, OLTP y DSS generarán conflictos de bloqueo de archivos entre sí que
pueden resolverse mediante copias independientes, pero que se hayan replicado, de los datos.
Funciones de servidor en la réplica
En la réplica de SQL Server 2008, una instancia puede ser un publicador, distribuidor,
suscriptor o la combinación de los tres. La combinación y ubicación concretas de publicadores,
distribuidores y suscriptores se denomina “topología de réplica”.
Por ejemplo, puede haber un publicador usando un distribuidor independiente y replicando los
datos a dos suscriptores, tal y como se muestra en la ilustración.

Los publicadores crean y modifican los datos, los distribuidores almacenan datos concretos de
la réplica asociados con uno o varios publicadores y los suscriptores reciben los datos. Con la
réplica de mezcla, esta situación cambia ligeramente, ya que las modificaciones tienen lugar
tanto en el publicador como en los suscriptores.
Función del publicador
El publicador tiene la copia original de los datos y la pone a disposición de los suscriptores. Los
datos se envían al distribuidor, que los remite a continuación a los suscriptores.
Función del distribuidor
El distribuidor almacena información de estado de la réplica, metadatos de la publicación y, en
algunos casos, datos cuando viajan entre el publicador y los suscriptores. Un publicador
también puede actuar como un distribuidor (denominado distribuidor local), pero cuando se
replican muchos datos, se suele crear un distribuidor independiente (denominado distribuidor
remoto). Muchos publicadores pueden usar el mismo distribuidor, y cada uno de ellos cuenta
con una base de datos independiente en la instancia.
Función del suscriptor
Un suscriptor contiene una copia de la réplica de los datos. El suscriptor puede ser objeto de
las siguientes acciones:
■ Impedirle que realice modificaciones.
■ Permitirle realizar modificaciones en el publicador.
■ Permitirle realizar modificaciones locales que se mezclarán más tarde.
TIPOS DE RÉPLICA
Los distintos sistemas tendrán requisitos diferentes (y con frecuencia en conflicto los unos con
los otros) para la réplica. SQL Server proporciona tres métodos de réplica, aunque cada uno
proporciona un conjunto diferente de ventajas y tiene distintas configuraciones opcionales. Es
importante que considere los puntos mostrados en esta sección y elija el método adecuado
para su sistema.

Todos los métodos de réplica le permiten especificar la frecuencia de sincronización.
Réplica de instantáneas
La réplica de instantáneas envía todos los datos de una publicación cada vez que ésta se
sincroniza. De esta forma se elimina la necesidad de supervisar las modificaciones de datos,
aunque podría producir un aumento del volumen de datos que se están replicando.
Se replicarán todos los datos aun cuando no se haya modificado ninguno.
Normalmente, la réplica de instantáneas se usa en escenarios en los que una gran cantidad de
datos cambia entre cada sincronización. Con la réplica de instantáneas, los suscriptores
pueden actualizar los datos en el publicador. La actualización puede ocurrir inmediatamente o
ponerse en cola hasta que se produzca la siguiente sincronización.
Réplica transaccional
La réplica transaccional sólo envía modificaciones de los datos cuando tiene lugar la
sincronización. Esto puede reducir el volumen de los datos que se están replicando, sobre todo
si el número de modificaciones de datos es bajo o si la réplica es frecuente.
Debido a la disminución de volúmenes de datos, se puede usar la réplica transaccional cuando
sean necesarias actualizaciones frecuentes.
La réplica transaccional se inicia normalmente con una réplica de instantáneas de los objetos y
datos para proporcionar una línea de base. A continuación, se enviarán partes del registro de
transacciones a los suscriptores cuando se produzca la réplica.
Con la réplica transaccional estándar, los suscriptores pueden actualizar datos en el publicador.
La actualización puede ocurrir inmediatamente o ponerse en cola hasta que se produzca la
siguiente sincronización.
La réplica transaccional punto a punto también está disponible. En este método, cada nodo es
a la vez publicador y suscriptor de los mismos datos. No hay ninguna jerarquía de publicadores
y suscriptores. Utilice este método cuando cada punto trabaja con una parte concreta de los
datos. Si todos los puntos realizan cambios en los mismos datos y es posible que se produzcan
conflictos, se debería usar la réplica de mezcla.
Réplica de mezcla
La réplica de mezcla permite las modificaciones tanto en el publicador como en los
suscriptores. Cuando se produce la sincronización, se mezclarán las modificaciones en el
publicador y en el suscriptor.

En otras formas de réplica, todas las modificaciones aparecen en el publicador, con lo que se
evitan conflictos pero se reduce la autonomía. En la réplica de mezcla, pueden producirse
conflictos y será necesario resolverlos. La solución de conflictos puede ser controlada
automáticamente dando prioridad a los distintos suscriptores o usando una resolución basada
en Modelo de objetos componentes (COM). Puede escribir su propia resolución basada en
COM o usar una estándar incluida con SQL Server. Los conflictos también se pueden resolver
interactivamente durante la sincronización mediante el componente de resolución interactiva de
Microsoft. Este componente está disponible a través del Administrador de sincronización de
Microsoft Windows®.
La réplica de mezcla se inicia normalmente con una réplica de instantáneas de los objetos y
datos para proporcionar una línea de base. Las modificaciones subsiguientes se mezclan
cuando la réplica tiene lugar.
Réplica heterogénea
Puede replicar los datos de SQL Server en otros productos de bases de datos, como IBM DB2,
Oracle y Sybase. SQL Server también puede actuar como suscriptor de la versión 8 o posterior
de Oracle. Después podrá generar y mantener la suscripción con un conocimiento mínimo de
este programa. Se pueden usar réplicas de instantáneas y transaccionales si se suscribe a una
base de datos de Oracle.
¿Qué son artículos, publicaciones y suscripciones?
Los datos de réplica se organizan en artículos y publicaciones. Las publicaciones contienen
uno o varios artículos y son las unidades de suscripción y sincronización de los datos. Los
suscriptores pueden recibir suscripciones o suscribirse por sí mismos. Los agentes de réplica
administran todo el proceso de réplica, incluido el movimiento de los datos entre publicadores y
suscriptores.
Artículos
Un artículo puede ser toda una tabla u objeto de base de datos, o sólo una parte. Se puede
filtrar horizontalmente, restringiendo las filas que contiene, o verticalmente, restringiendo las
columnas que tiene.

Publicaciones
Una publicación puede contener uno o varios artículos. Sólo puede tener artículos de la misma
base de datos, aunque puede haber muchas publicaciones en una base de datos. Es tanto la
unidad de suscripción como la unidad de réplica.
Suscripciones
Una suscripción se crea en relación con una publicación; no se puede crear directamente en
relación con un artículo. Puede crear suscripciones de inserción o de extracción. Las
suscripciones de inserción
se crean en el publicador y se pueden crear al mismo tiempo que la publicación en muchos
suscriptores. Dado que las suscripciones se crean de manera centralizada, este método es
más seguro pero es necesario que los suscriptores se conecten cuando la réplica tiene lugar.
Las suscripciones de extracción se crean en el suscriptor. En primer lugar, el publicador debe
haber habilitado este tipo de suscripciones y haber registrado al suscriptor, o bien haber
permitido las suscripciones anónimas. Por lo general, este sistema es menos seguro, pero
permite al suscriptor controlar cuándo se reciben las actualizaciones, haciéndolo más
adecuado para aquellos sitios que se conectan con poca frecuencia. Puede tener una
suscripción de extracción en una publicación y una de inserción en otra.
Agentes de réplica
Los agentes de réplica controlan todo el proceso de réplica. Estos agentes se configuran
cuando se define la solución de réplica. Al implementar la réplica, debe especificar en qué
instancias de SQL Server se ejecutarán los agentes de réplica.
SQL Server 2008 proporciona los siguientes agentes de réplica:
 Agente SQL Server
 Agente de instantáneas
 Agente de registro del LOG
 Agente de lectura de cola
 Agente de distribución
 Agente de mezcla
Escenarios de réplica
Escenarios de réplica de servidor a servidor
Hay muchas situaciones en las que la réplica de servidor a servidor será beneficiosa para una
organización. En este tema se describen algunas de las más comunes.

Integrar datos de varios sitios
Con frecuencia, las oficinas regionales realizan modificaciones de datos que es necesario
replicar en la oficina central. Un ejemplo sería una empresa de venta al por menor donde las
tiendas puedan replicar los datos de ventas y enviarlos a un servidor de la oficina central. En
este escenario, es bastante probable que la oficina central también actúe como publicador ya
que enviará información sobre los productos a las tiendas.
Integrar datos heterogéneos
La mayoría de las organizaciones tienen distintos tipos de bases de datos. Podría necesitar
consolidar esos datos o replicar las modificaciones de un sistema en otro.
La réplica le permite integrar los datos heterogéneos de dos formas:
Mediante el uso de Oracle (versión 8 y posterior) como origen para los datos que pueden
replicarse a SQL Server.
Mediante el uso de SQL Server como origen para los datos que pueden replicarse a bases de
datos de IBM y Oracle. Incluso es posible que estos datos procedieran en un principio de
Oracle y se replicaran a SQL Server antes de pasar a IBM DB2.
Descargar el procesamiento por lotes
Si se programa con regularidad la actividad intensa del procesador en el servidor de
producción, es posible que las operaciones normales puedan verse afectadas de forma
negativa. Se puede usar la réplica para descargar este trabajo en un servidor independiente y,
si es necesario, replicar de nuevo en el servidor de producción después de que se haya
completado el procesamiento por lotes.
Almacenar datos e informes
Los almacenes de datos tendrán normalmente un esquema distinto al de las bases de datos
del procesamiento analítico en línea (OLAP), aunque los datos se consolidan a menudo en un
área de ensayo antes de transformarse y cargarse en el almacén de datos.
La réplica es un mecanismo ideal para este tipo de carga periódica.
Por lo general, los sistemas de informes tienen copias de sólo lectura de datos para
aplicaciones que usan muchos recursos de lectura. Si el sistema OLAP se usara para estos
informes, habría un conflicto entre las operaciones de lectura y escritura de OLAP y las
operaciones que sólo son de lectura aunque muy extendidas. Este conflicto puede resolverse
con la réplica de los datos en el sistema OLAP a una instancia de informes.
Mejorar la escalabilidad y disponibilidad
Si tiene una gran cantidad de actividades de lectura y datos relativamente estáticos, la réplica
puede usarse para mejorar la escalabilidad. Por ejemplo, un grupo de servidores web que

utilice el equilibrio de carga de red podría tener una instancia de SQL Server detrás de cada
servidor web individual. Los cambios en cualquier servidor de base de datos se replicarían en
los demás servidores.
Puede mejorar la disponibilidad con una réplica de una base de datos. Si se produce una
interrupción planeada o no en el servidor principal, se puede usar la réplica.
ESCENARIOS DE RÉPLICA DE SERVIDOR A CLIENTE
La réplica se realiza entre servidores y clientes además de entre servidores y otros servidores.
Muchas empresas confían en sus vendedores comerciales a la hora de realizar pedidos o tener
terminales de cajeros, ATM o equipos de las sucursales que no necesitan sistemas operativos
de servidor.
Intercambiar datos con usuarios móviles
Los usuarios móviles requieren a menudo copias de información de la empresa cuando
trabajan fuera de ella. Muchos de ellos incluso realizan pedidos o actualizan registros mientras
están fuera de la oficina. Los dispositivos que usan abarcan desde dispositivos de mano a
equipos portátiles de gran capacidad. Es posible realizar réplicas desde y hacia estos
dispositivos móviles de Windows y, en función del hardware, sincronizar de forma inalámbrica
con los usuarios móviles.
Aplicaciones de punto de venta (POS) del consumidor
Hay muchas aplicaciones que los consumidores usan directamente, como las ATM, o
indirectamente, como los terminales de cajeros. Todas estas aplicaciones necesitan datos de
un origen central y realizan actualizaciones que se vuelven a replicar en los servidores
centrales. Al usar la réplica, puede mejorar la autonomía y la escalabilidad.
Integrar datos de varios sitios
Muchas empresas tienen oficinas regionales que no necesitan que se estén ejecutando los
servidores, pero sí que necesitan los datos de la oficina central y realizar modificaciones que se
repliquen de nuevo posteriormente. SQL Server puede instalarse en Windows XP y la réplica
puede realizarse entre esas estaciones de trabajo y los servidores de la oficina central.

Separata uni sql2008 administracion

Más contenido relacionado

La actualidad más candente (19)

Destacado (18)

Similar a Separata uni sql2008 administracion (20)

Último (20)

Separata uni sql2008 administracion