Arquitectura de la base de datos: el motor de almacenamiento

Cathan Cook

Microsoft Consulting Services

Resumen: en este artículo se ofrece información detallada sobre el funcionamiento interno de la

arquitectura de SQL Server. Se especifican mejoras para el motor de la base de datos, ofreciendo

sugerencias de uso y punteros que permiten tener acceso a más información. Un conocimiento en

profundidad de los motores de SQL Server puede ayudar al administrador de la base de datos (ingeniero

del sistema de la base de datos) a sacar un mayor partido de SQL Server durante el diseño, creación o

mejora de los sistemas de bases de datos. Aunque este artículo está dirigido a los profesionales que

trabajan con bases de datos, el material puede resultar útil también desde un punto de vista educativo

o de mercadotecnia. (21 páginas impresas.)

Contenido

Introducción

Mejoras en el motor de almacenamiento

Interacción con los datos

Tablas e índices

Registro y recuperación

Mejoras administrativas

Componentes de almacenamiento de datos

Conclusión

Introducción

En este artículo se describen las nuevas características del motor de almacenamiento de Microsoft® SQL

Server™ 2000 y se ofrecen sugerencias para su uso, así como información detallada sobre cómo funciona

el motor de almacenamiento. Una comprensión básica del funcionamiento interno del motor permitirá

sacar el máximo partido de SQL Server.

En un mundo orientado a las aplicaciones de alta escalabilidad, las bases de datos se diseñan e

implementan actualmente siguiendo programaciones cortas y permanecen en un estado de constante

evolución a medida que cambian los requisitos de desarrollo y aumenta el uso de la producción. Los

requisitos de escalabilidad, disponibilidad y facilidad de uso exigen un motor de almacenamiento de datos

que sea flexible y receptivo.

Las distintas versiones de SQL Server 2000 admiten una amplia variedad de sistemas, con tamaños que

varían desde un diminuto sistema móvil para un Pocket PC hasta un sistema de soporte de decisiones o

procesamiento de transacciones de varios terabytes de alta disponibilidad que se ejecutan en servidores

Windows® 2000 Datacenter Server agrupados. Todos estos sistemas mantienen la flexibilidad, seguridad
y confiabilidad que exigen los sistemas empresariales de misiones importantes.

Se pueden distribuir aplicaciones de SQL Server 2000 para proyectos de distintas finalidades y tamaños,

como resultado de operaciones inteligentes y automáticas del motor de almacenamiento. Una

arquitectura con un alto grado de sofisticación mejora el rendimiento, la disponibilidad y la escalabilidad.

Disponibilidad

La confiabilidad y concurrencia se mejoran con nuevos algoritmos para la interacción física de archivos.

Estos algoritmos eliminan la necesidad de ejecutar comandos de consola de base de datos (DBCC) como

parte del mantenimiento habitual. No obstante, DBCC sigue estando disponible y los nuevos comandos

DBCC CHECK se pueden ejecutar sin impedir el procesamiento en línea.

Escalabilidad

El subsistema de almacenamiento, formado por archivos físicos de bases de datos y su diseño en disco,

admite la escala desde bases de datos muy pequeñas hasta bases de datos de gran tamaño. SQL Server

puede admitir ahora hasta 64 GB de memoria física (RAM) y hasta 32 procesadores.

Fácil utilización

Las capacidades de administración mejoradas ayudan al administrador de la base de datos (DBA) a

automatizar y centralizar la administración de servidores. De este modo, se consigue también un

mantenimiento sencillo de los servidores y las aplicaciones remotas sin necesidad de que el DBA tenga

que visitar cada uno de los sitios. La configuración del servidor, administrada por un sofisticado

algoritmo, responde de forma dinámica a los patrones de uso del servidor. De este modo, se libera al

DBA de centrarse en las tareas de administración y optimización de las bases de datos.

Mejoras en el motor de almacenamiento

El servidor de bases de datos relacionales de SQL Server 2000 está formado por dos partes principales:

el motor relacional y el motor de almacenamiento. Los dos motores funcionan de forma independiente,

interactuando entre sí a través de los componentes de acceso a datos nativos como OLE DB. El motor

relacional proporciona una interfaz en el motor de almacenamiento, formado por los servicios que

interactuarán con las características y los componentes del almacenamiento de la base de datos

subyacente.

Las principales responsabilidades del motor de almacenamiento incluyen:

 Ofrecer características que faciliten aún más el uso en la administración de los componentes de

almacenamiento

 Administrar los búferes de datos y todas las E/S en los archivos físicos

 Controlar la concurrencia, administración de transacciones, bloqueos y registro

 Administrar los archivos y las páginas físicas utilizadas para almacenar datos
  Recuperar desde errores graves del sistema

El motor de almacenamiento de SQL Server 2000 ofrece nuevas características que aportan simplicidad

conceptual y flexibilidad física, a la vez que reducen la necesidad de minuciosas planeaciones en relación

a la capacidad y ajustes del rendimiento. SQL Server 2000 reacciona en su propio entorno y se adapta

dinámicamente de forma rápida y precisa a los cambios en el uso de las bases de datos. Este avance en

la tecnología ha centrado la administración de la base de datos en la facilitación de datos como servicio.

Los administradores de bases de datos de SQL Server 2000 se pueden centrar en el diseño de un sistema

que responda al flujo y utilización de los datos en lugar de tener que dedicar tiempo a ajustar parámetros

individuales.

Las modificaciones realizadas en SQL Server 2000 se integran en las mejoras de la arquitectura

introducidas en SQL Server 7.0 para proporcionar una base para la mejora e innovación en curso. Uno de

los objetivos clave del equipo encargado del motor de almacenamiento era el de reducir la cantidad de

tiempo y esfuerzo empleados en los ajustes habituales del servidor. Debido a que la mayoría de los

valores de los parámetros de ajuste se pueden basar en el uso de las bases de datos, el motor se adapta

ahora dinámicamente a las situaciones del entorno de la base de datos de acuerdo a un algoritmo de

adaptación. Esta flexibilidad automática se ha implementado para los parámetros de ajuste que exigían

una experimentación y ajustes constantes en las versiones anteriores. Se pueden seguir ajustando las

características de forma manual, pero SQL Server 2000 libera al usuario en gran medida de esta labor.

Sólo un pequeño porcentaje de clientes de SQL Server puede necesitar un ajuste en los parámetros; este

tipo de ajuste sólo deberá realizarse con un meticuloso sistema de pruebas y bajo la supervisión de

administradores de bases de datos totalmente cualificados.

En la siguiente tabla se muestra un resumen de las mejoras esenciales realizadas en el

motor de almacenamiento de SQL Server 2000. Más adelante en este artículo se ofrece
una descripción más detallada.
Característica Descripción y ventajas
Administrador de bloqueos Si necesita controlar el acceso simultáneo a recursos definidos en
de aplicaciones aplicaciones, como los formularios, los nuevos procedimientos
almacenados permiten ahora bloquear estos recursos utilizando el
administrador de bloqueos de aplicaciones de SQL Server.
Comandos de la consola de Los comandos DBCC CHECK se pueden ejecutar ahora durante el
base de datos (DBCCs) procesamiento en línea, sin bloquear las actualizaciones. Las nuevas
mejoras permiten comprobar la coherencia de las páginas físicas para
detectar los errores inducidos por el hardware. En SQL Server 2000
Enterprise Edition, DBCC se ejecuta ahora en paralelo entre varios
procesadores.
Opciones de bases de datos Todas las opciones de las bases de datos se pueden modificar ahora
utilizando ALTER DATABASE. Esta capacidad simplifica la administración.
Copias de seguridad de Este tipo de copia de seguridad es más rápida en SQL Server 2000, debido
diferencias a una mejora que realiza un seguimiento de los cambios realizados en las
bases de datos en el nivel de extensión.
Ajuste dinámico Con los algoritmos de adaptación dinámicos, el servidor ajusta de forma
automática los valores de la configuración estática anterior. El control
administrativo sigue estando disponible para administrar los recursos de
todo el sistema, pero no será necesaria su utilización habitual. Los
parámetros establecidos manualmente se adaptan dinámicamente dentro
 de sus límites de restricción.
Texto de fila En las tablas que incluyen una columna pequeña de texto utilizada con
frecuencia, los valores de texto más pequeños se pueden almacenar en la
misma página que la fila de datos estándar en lugar de en una página de
valores de texto. En las tablas donde se tiene acceso frecuente a estos
datos de texto, esta característica puede eliminar una gran cantidad de
E/S del disco.
Generación de índices en En Enterprise Edition, la generación de índices utiliza de forma automática
paralelo todos los procesadores configurados para el procesamiento paralelo,
reduciendo el tiempo empleado en generar un índice con un factor de seis
en un servidor de ocho procesadores. La generación de índices también
utiliza los recursos disponibles en la memoria y en tempdb.
Lectura anticipada de índice Las lecturas de índices se han mejorado para aumentar el rendimiento en
las exploraciones de índices.
Reorganización de índices Las mejoras realizadas en DBCC SHOWCONTIG proporcionan más
información detallada con respecto a la fragmentación de índices. Un
nuevo comando DBCC, INDEXDEFRAG, reorganiza las páginas de índices
en línea sin necesidad de interrumpir el servicio de la base de datos ni
suponer ningún riesgo en la coherencia o recuperación de la base de
datos.
Columnas de clave en orden Las columnas de clave individuales de un índice se puede especificar en
descendente en los índices orden ascendente o descendente.
Comando KILL Este comando informa ahora del progreso en la ejecución. Si este comando
se encuentra a la espera en otro proceso, como la acción de deshacer,
podrá visualizar la cantidad de comando ejecutado. Este comando se ha
mejorado para permitir detener las transacciones del Coordinador de
transacciones distribuidas de Microsoft (MS DTC), que no se encuentran
asociadas a una sesión específica.
Soporte de memoria de gran La tecnología de Windows 2000 mejora el rendimiento de los sistemas de
tamaño Enterprise Edition que utilizan una gran cantidad de memoria. Con las
extensiones AWE de Windows 2000, SQL Server 2000 puede admitir hasta
64 GB de memoria física (RAM).
Bloqueo Se ha mejorado el administrador de bloqueos para que pueda detectar
interbloqueos en recursos adicionales como subprocesos y memoria. Las
mejoras en la concurrencia reducen los interbloqueos. De este modo,
mejora la escalabilidad de SQL Server 2000.
Marcas lógicas de registro Los comandos Transact-SQL pueden crear un marcador en el registro que
permita la restauración de la base de datos en un momento dado indicado
por el marcador. Esta característica también sincroniza la restauración de
varias bases de datos utilizadas para la misma aplicación.
Reorganización de índices en Las mejoras realizadas en DBCC SHOWCONTIG proporcionan más
línea información detallada con respecto a la fragmentación de índices. Un
nuevo comando DBCC, INDEXDEFRAG, reorganiza las páginas de índices
en línea sin necesidad de interrumpir el servicio de la base de datos ni
suponer ningún riesgo en la coherencia o recuperación de la base de
datos.
Lectura anticipada de E/S SQL Server 2000 emite varias lecturas anticipadas en serie al mismo
optimizada tiempo para cada archivo que toma parte en la exploración. El optimizador
de consultas utiliza la E/S de lectura anticipada en serie durante la
exploración de tablas e índices para obtener un mejor rendimiento.
Contraseñas en copias de Los soportes de copias de seguridad y las copias individuales se pueden
seguridad proteger con contraseña. De este modo, se evita que un usuario no
autorizado restaure una copia de seguridad y obtenga acceso a la base de
datos.
Modelos de recuperación Mediante los modelos de recuperación, se puede seleccionar el nivel de
registro en la base de datos. Esto permite una mayor flexibilidad en la
administración del registro de transacciones. El modelo de recuperación se
puede modificar en línea para complementar la utilización de una base de
datos variada durante el día.
Exploraciones de tablas En Enterprise Edition, varias exploraciones de una tabla pueden ahora
compartidas obtener ventajas de las demás exploraciones en curso de dicha tabla,
reduciendo la E/S física al disco.
Reducción del registro El comando que reduce el registro se ejecuta de forma inmediata en la
mayoría de los casos. Si el registro no se puede reducir inmediatamente,
SQL Server proporcionará información constructiva sobre lo que se debe
hacer antes de continuar o finalizar con la operación de reducción.
Copias de seguridad Mejora en la compatibilidad con las copias de seguridad instantáneas de
instantáneas otros fabricantes. Las copias de seguridad instantáneas aprovechan las
tecnologías de almacenamiento para realizar la copia de seguridad o
 restaurar toda una base de datos en segundos. Estas copias de seguridad
se pueden combinar ahora con un registro de transacciones tradicional y
copias de seguridad de diferencias con la finalidad de proporcionar una
protección total para las bases de datos OLTP. Esto resulta especialmente
beneficioso para moderar las bases de datos de gran tamaño en las que
resulta de vital importancia la disponibilidad.
Ahorro de espacio en índices No se asignan páginas de disco a tablas e índices vacíos en SQL Server
y tablas vacíos 2000. SQL Server 7.0 asignaba hasta tres páginas en tablas e índices
vacíos.
Clasificación de los n Esta nueva característica optimiza la recuperación de los principales n
registros principales valores (por ejemplo, SELECT TOP 5 * FROM tablename).
Xlock SQL Server 2000 proporciona esta nueva sugerencia de bloqueo Transact-
SQL. Se puede utilizar para llamar de forma explícita una página de nivel
de transacción exclusiva o bloqueo de página.

SQL Server 2000 se ha visto enriquecido con características que permiten una interacción de datos más

eficaz y una mayor flexibilidad administrativa. En las siguientes secciones se ofrece información más

detallada sobre estas mejoras así como algunas sugerencias sobre la forma de utilizarlas.

Interacción con los datos

En SQL Server 2000, el motor de almacenamiento se ha mejorado para proporcionar una mayor

escalabilidad y rendimiento a la hora de interactuar con los datos. Un conocimiento profundo de estas

mejoras puede ayudar a utilizar SQL Server de forma mucho más eficaz.

El intercambio de datos comienza con una consulta, originada desde una interfaz de usuario o una tarea

automática. La solicitud de datos pasa al motor relacional, que interactúa con el motor de

almacenamiento para obtener los datos y volver a pasarlos al usuario. Desde el punto de vista del

usuario, e incluso del administrador de la base de datos, no hay diferencia alguna en el funcionamiento

de los motores de almacenamiento y relacional.

Lectura más eficaz de los datos

Los datos se trasladan entre el servidor y el usuario a través de una serie de transacciones. La aplicación,

o el usuario, inicia el trabajo y la base de datos lo pasa al procesador de consultas para su realización y,

a continuación, devuelve los resultados finales. El procesador de consultas realiza la tarea de aceptar,

interpretar y ejecutar las instrucciones SQL.

Así, por ejemplo, cuando una sesión de usuario emite una instrucción SELECT, tienen lugar los siguientes

pasos:

1. El motor relacional compila y optimiza la instrucción en un plan de ejecución (que consiste en

una serie de pasos necesarios para la obtención de los datos). A continuación, el motor relacional
pone en práctica el plan de ejecución. Los pasos de ejecución incluyen el acceso a las tablas e
índices a través del motor de almacenamiento.

2. El motor relacional interpreta el plan de ejecución, realizando llamadas en el motor de

almacenamiento para reunir los datos necesarios.
3. El motor relacional combina todos los datos devueltos por el motor de almacenamiento en el
conjunto final de resultados y lo envía de vuelta al usuario.

Se han realizado algunas mejoras para aumentar el rendimiento de este proceso. En SQL Server 2000, el

motor relacional coloca de nuevo predicados de consulta necesarios en el motor de almacenamiento para
que se puedan aplicar con mayor antelación en el proceso, dando como resultado un intercambio más

eficaz entre el motor de almacenamiento y el relacional. De este modo se puede obtener un rendimiento

significativo en las consultas necesarias.

Mejora en los n registros principales

Otra mejora se encuentra en el modo en que el motor de almacenamiento controla la selección de los n

registros principales de un conjunto de resultados. En SQL Server 2000, un nuevo motor de los n

registros principales analiza la mejor ruta de operación para instrucciones como ésta:

SELECT top 5 * from orders order by date_ordered desc

En este ejemplo, si se debe buscar en toda la tabla, el motor analiza los datos y realiza únicamente un

seguimiento de los n valores principales en la memoria caché. Esto supone un aumento considerable en

el rendimiento para este tipo de instrucción SELECT, ya que sólo se ordenan los n valores principales en

lugar de toda la tabla.

Exploraciones compartidas

En SQL Server 2000 Enterprise Edition, dos o más consultas pueden compartir exploraciones de tablas en

curso, lo que permite mejorar el rendimiento en bases de datos de SQL Server 2000 de gran tamaño. Por

ejemplo, cuando la consulta realiza una búsqueda en una tabla de gran tamaño utilizando una

exploración no solicitada, las páginas se trasladan a través de la caché para dejar espacio para la entrada

de flujo de datos. Si se hubiese iniciado otra consulta, una segunda exploración de la misma tabla haría

que la E/S del disco volviese a recuperar dichas páginas. En un entorno en el que son frecuentes las

exploraciones de tablas, esto podría producir la hiperpaginación ("thrashing") del disco ya que ambas

consultas realizan la búsqueda de las mismas páginas de datos.

Figura 1. Eficacia de las exploraciones compartidas

Un proceso de optimización reduce la cantidad de E/S del disco producidas por este tipo de patrón de

acceso a datos. La primera exploración no solicitada de una tabla leerá los datos del disco; en lugar de

tener que volver a realizar la lectura del disco, las siguientes exploraciones no solicitadas de la misma

tabla se pueden generar sobre la información que se encuentra ya en memoria. Consulte la figura 1.

Durante varias exploraciones simultáneas de la misma tabla, este proceso de sincronización puede

mejorar el rendimiento hasta ocho veces más. Esta mejora se percibe aún más en las grandes consultas

de soporte de decisión, donde el tamaño total de la tabla es mucho mayor que el tamaño de la caché.

Las exploraciones compartidas constituyen una característica que llama el motor de almacenamiento

como servicio de ayuda con las consultas que no disponen de un plan mejor de ejecución. El objetivo de

esta característica es el de ayudar en las lecturas frecuentes de tablas de gran tamaño. Cuando el

procesador de consultas determina que el mejor plan de ejecución incluye una exploración de tabla, se

llama a esta característica. No obstante, aunque se puede utilizar el ajuste de índice o consulta para

forzar exploraciones compartidas, no se obtiene un mayor rendimiento forzando una exploración de tabla

cuando un índice bien mantenido realizaría igualmente bien esta labor, o incluso mejor.
Concurrencia

Para mantener la coherencia de transacciones mientras un gran número de usuarios están interactuando

con los datos, el motor de almacenamiento bloquea recursos para administrar las dependencias de filas,

páginas, claves, intervalos de clave, índices, tablas y bases de datos. Al bloquear los recursos mientras

se están modificando, el motor evita que más de un usuario modifique los mismos datos al mismo

tiempo. Los bloqueos de SQL Server se aplican dinámicamente en varios niveles de granularidad para

seleccionar el bloqueo menos restrictivo necesario para la transacción.

En SQL Server 2000, las mejoras en la concurrencia reducen aún más los interbloqueos y los bloqueos de

recursos evitables. Por ejemplo, el administrador de bloqueos se ha mejorado para que tenga en cuenta

otros recursos que se podrían utilizar, como subprocesos y memoria. Esta nueva capacidad puede ayudar

al administrador de la base de datos a identificar una variedad más amplia de limitaciones de diseño o

hardware.

Se ha introducido una nueva interfaz Transact-SQL en el administrador de bloqueos para que admita la

lógica de bloqueo personalizada dentro del código de programación. Los bloqueos necesarios para la

lógica empresarial se pueden iniciar mediante la llamada a sp_getapplock en el lote de Transact-SQL, lo

que permite especificar un recurso definido por la aplicación que se va a bloquear (por ejemplo, un

bloqueo en un recurso de aplicación como un formulario en lugar de un bloqueo en una fila de datos), el

modo de bloqueo que se utilizará, el valor del tiempo de espera y si el ámbito del bloqueo deberá ser la

transacción o la sesión. Una vez iniciados los bloqueos con el nuevo administrador de bloqueos de la

aplicación, éstos participan de la administración normal de bloqueos de SQL Server, como si el motor de

almacenamiento los hubiese iniciado, por lo que no es necesario preocuparse de que permanezca abierto

el bloqueo iniciado por la aplicación si se ha terminado la transacción de llamada.

El proceso a través del cual se obtienen los bloqueos en SQL Server 2000 tiene en cuenta si se confirman

o no todos los datos de la página. Por ejemplo, si se ejecuta una instrucción SELECT en una tabla cuyos

datos no se han modificado recientemente, como una tabla de bases de datos pubs, el proceso no

produce bloqueos, ya que ninguna transacción activa ha actualizado recientemente la tabla. El motor de

almacenamiento logra esto comparando el número de secuencia de registro de la página de datos con las

transacciones activas actuales. En las bases de datos donde la mayoría de los datos son más antiguos

que la transacción activa más antigua, esto puede reducir el bloqueo de forma significativa mejorando,

así, el rendimiento.

Mientras que los bloqueos protegen los datos durante las transacciones, otro proceso, el cierre con

pestillo, controla el acceso a las páginas físicas. Los pestillos son objetos de sincronización ligeros y a

corto plazo que protegen las acciones que no es necesario bloquear durante la vida de una transacción.

Cuando el motor explora una página, la cierra con pestillo, lee la fila, la devuelve al motor relacional y la

vuelve a dejar abierta para que otro proceso pueda tener acceso a los mismos datos. A través de un
proceso denominado cierre con pestillo selectivo ("lazy latching"), el motor de almacenamiento optimiza

el acceso a las páginas de datos abriendo los pestillos sólo cuando otro proceso en curso solicita también

la página. Si no hay ningún otro proceso en curso que solicite los mismos datos de la página, un único

cierre con pestillo permanece válido para toda la operación de dicha página.

Para mejorar la concurrencia del sistema, es necesario centrarse en el diseño del sistema de la base de

datos y los objetos de código que le afectan. SQL Server 2000 se ha diseñado para que admita varios

terabytes de datos y una escalabilidad lineal prácticamente ilimitada. El papel que debe cumplir el

administrador de la base de datos es la de administrar el ciclo vital de la base de datos, un ciclo de

diseño y optimización de todos los componentes de la base de datos desde el código hasta el

almacenamiento de datos en disco, para garantizar que el diseño continúa cumpliendo con el acuerdo a

nivel de servicios.

Tablas e índices

También se han realizado mejoras en las estructuras físicas de los datos para permitir una mayor

flexibilidad en el diseño y mantenimiento.

A medida que aumenta la tabla o índice, SQL Server asigna nuevas páginas de datos en conjuntos de

ocho, denominados extensiones. Una fila de datos no puede atravesar páginas, por lo que sólo puede

contener 8 KB de datos, si bien el texto asociado, ntext o las columnas de imágenes se pueden

almacenar en distintas páginas. Las tablas que disponen de índices agrupados se almacenan físicamente

en orden de clave en el disco. Los montones, o "heaps", son tablas que no tienen índices agrupados y no

se encuentran ordenadas. Los registros se almacenan en el orden en el que se insertaron.

SQL Server 2000 admite vistas indizadas, normalmente denominadas vistas materializadas en otros

productos de bases de datos. Cuando se crea un índice agrupado en una vista, ésta deja de ser un objeto

derivado para convertirse en un objeto base almacenado en la base de datos con la misma estructura

que una tabla con un índice agrupado. La vista indizada resulta útil para almacenar valores calculados

previamente o el resultado de una unión compleja, en los casos en el que el coste de mantenimiento no

sobrepasa la mejora obtenida en relación al rendimiento. En SQL Server 2000 Enterprise Edition, el

procesador de consultas utiliza automáticamente una vista indizada cuando ésta optimiza un plan de

consulta. Las vistas indizadas pueden mejorar la velocidad de consulta en datos que rara vez se

modifican, pero normalmente forman parte de una unión o consulta de cálculo compleja.

Texto de fila

El texto de fila permite almacenar datos pequeños de texto en la página principal. Por ejemplo, si se

dispone de una tabla que tiene una columna de texto, pero que los valores de texto son normalmente lo

suficientemente pequeños como para ajustarse a una página normal con el resto de la fila, se puede

definir un umbral en la columna de texto. Este umbral determina el tamaño por debajo del cual los datos

se almacenan en la página principal en lugar de en otra página de texto. Esto daría como resultado un
rendimiento más rápido si la mayoría de los datos se ajustaran a la página, y sólo un pequeño porcentaje

de los datos es, en realidad, lo suficientemente grande como para justificar la creación de una página de

texto.

Para determinar cuándo se debe utilizar esta nueva característica, es necesario equilibrar la densidad del

almacenamiento o cuántas filas se almacenan en cada página de datos frente a la mejora de E/S. Por

ejemplo, se dispone de una columna de texto para los comentarios. En la tabla, se observa que el 20%

de los valores de texto son grandes, pero que el restante 80% es menor de 100 bytes. Éste parece ser

un candidato lógico para una solución de texto de fila; sin embargo, sólo se debe utilizar este tipo de

texto si se tiene acceso frecuente a los datos de esa columna. Si los usuarios tienen acceso a esta tabla

con frecuencia, pero no miran la columna de comentarios a menos que estén realizando una

investigación especial, puede que el uso de texto de fila no sea la respuesta más acertada. La densidad

de almacenamiento se reduce debido a que se almacenan menos columnas por página y, además, puesto

que la tabla contiene más páginas, aumentará el tiempo de respuesta de exploración de la tabla. Por

tanto, el mejor caso para implementar el texto de fila se produce cuando se tiene un acceso frecuente a

la columna de texto que, además, dispone de multitud de valores menores que 8 K que podrían

almacenarse en la fila.

Nuevos tipos de datos

SQL Server 2000 introduce tres nuevos tipos de datos. bigint es un tipo de entero de 8 bytes. sql_variant

permite el almacenamiento de valores de datos de distintos tipos de datos. El tercer tipo, table, resulta

útil para la optimización del rendimiento. Las variables de tabla utilizan tempdb de forma más eficaz y

resultan más rápidas que las tablas temporales. Al igual que otras variables, se incluyen en el ámbito del

lote en el que se declararon. Con una funcionalidad prácticamente idéntica a las tablas temporales, las

variables de tabla se ejecutan de forma más rápida que las tablas temporales o los cursores y utilizan

mejor los recursos del servidor. Como regla general, es necesario tener siempre en cuenta la mejor

forma de utilizar los recursos disponibles en los servidores cuando se cree código para interactuar con

una base de datos.

Índices

El acceso a los datos se optimiza a través del uso de los índices. Debido a que los requisitos de indización

se basan en el uso, la indización incorrecta es una de las causas más frecuentes de ralentización de una

base de datos. El mantenimiento estándar de los índices debería incluir la comprobación periódica del

esquema de indización actual y el ajuste del mismo a la utilización actual del sistema mediante la

agregación o eliminación de índices según sea necesario.

Varias características nuevas de SQL Server 2000 facilitan y hacen más eficaz la administración en el

mantenimiento de los índices. Estas mejoras disminuyen la E/S de disco, aumentando así el rendimiento

de las exploraciones de índices. Esto resulta especialmente útil cuando se encuentra disponible un
segundo índice para una exploración de intervalos.

Generación de índices

Al generar un índice, el motor de almacenamiento realiza una prueba de las filas y

calcula la forma más eficaz de utilizar los recursos del servidor para la generación del
índice. Las opciones permiten controlar la forma en que se generan los índices, de modo
que se puede elegir controlar cómo se asignarán los recursos del sistema. Estas opciones
se pueden utilizar para equilibrar los recursos de un proceso que sea importante para el
rendimiento del sistema en general, de acuerdo con los conocimientos que se tengan de
un sistema de base de datos específico, de forma que la generación del índice tenga el
menor impacto posible en el procesamiento de la transacción.
Recurso Comando Opción Descripción
Memoria sp_configure index create Especifica la cantidad de memoria utilizada por
(advanced) memory cualquier generación de índice.
TempDB create index sort_in_tempdb Hace que el espacio en disco utilizado para la
ordenación durante la generación del índice se
asigne desde tempdb. Esto puede dar como
resultado un mayor ancho de banda de E/S si
tempdb se encuentra en discos distintos y
obtener un diseño de páginas de índice más
contiguo físicamente si la base de datos dispone
de poco espacio contiguo.
CPU sp_configure max degree of Limita el número de procesadores (CPU)
(advanced) parallelism utilizados en operaciones paralelas (en todo el
servidor).

Para obtener más información sobre estas opciones, consulte los libros en línea de SQL Server 2000 (en

inglés).

Otra característica de escalabilidad para sistemas de gran tamaño es la generación de índices paralelos,

disponible en SQL Server 2000 Enterprise Edition. Este proceso se invoca de forma automática cuando se

emite una única instrucción CREATE INDEX. El motor de almacenamiento calcula los requisitos de los

datos y, a continuación, crea subprocesos separados, cada uno de los cuales genera una sección del

índice.
Figura 2. Optimización de índice paralela

La generación de un índice puede utilizar también una exploración de tabla compartida, optimizando aún

más el proceso.

Defragmentación de índices

SQL Server 2000 admite la reorganización en línea de los índices, un increíble avance desde las últimas

versiones. La reorganización de índices en línea apenas tiene impacto en el rendimiento de la transacción

y se puede detener y reiniciar en cualquier momento sin pérdida de trabajo. La reorganización se realiza

en pequeños incrementos y es totalmente recuperable.

A medida que se inserta, elimina y actualiza información de una tabla, las páginas de índices agrupados y

no agrupados pueden finalmente fragmentarse y reducir así la eficacia de las consultas de intervalo de

los datos. Por tanto, puede resultar beneficioso la defragmentación de los índices de forma periódica. Se

puede utilizar DBCC SHOWCONTIG, mejorado en SQL Server 2000, para analizar e informar de la

fragmentación. Para obtener más información, consulte los libros en línea de SQL Server 2000 (en

inglés).

Si se determina que un índice está fragmentado, utilice DBCC INDEXDEFRAG para reorganizarlo.

Reordena las páginas en orden de clave lógico, compactando el espacio libre y desplazando las filas

dentro de las extensiones establecidas para ajustarse al valor del factor de relleno. De este modo, mejora

el rendimiento de la lectura al rellenar densamente las páginas para que se deban leer menos páginas

durante la exploración de los datos. La ejecución de DBCC INDEXDEFRAG tiene un impacto mucho menor

en el rendimiento en línea que la regeneración del índice, siempre que el índice se haya mantenido

regularmente y no se encuentre totalmente fragmentado.

DBCC INDEXDEFRAG es uno de los números de las operaciones administrativas en línea de larga

ejecución que utiliza pequeñas transacciones internamente. Estas pequeñas transacciones maximizan la

concurrencia dentro del servidor, permiten que la operación se detenga sin pérdida en el trabajo y están

totalmente registradas para evitar tener que rehacerlas en caso de error.

Registro y recuperación

El registro de transacciones es una secuencia de registros que guarda los cambios producidos en la base

de datos desde el punto en el que ésta se creó hasta el momento actual. Cada operación registrada crea

a su vez un registro de dicha operación. Estos registros generados por la transacción se graban en el

disco cuando ésta se confirma. Por el contrario, las páginas de datos modificadas por la transacción no se

graban inmediatamente en el disco, sino que se retienen en la caché del búfer de SQL Server y se

guardan posteriormente. Este retraso en la escritura de los datos en el disco permite maximizar la

eficacia de los accesos múltiples a las páginas de datos y evita las interrupciones en las exploraciones.

Forzar el registro en el disco garantiza que no se pierda ningún trabajo confirmado en caso de un error
grave en el servidor.

Con la recuperación se asegura que la base de datos es coherente desde el punto de vista transaccional

como paso previo a su presentación en línea. Se dice que una base de datos es coherente de forma

transaccional cuando presenta todo el trabajo confirmado y ha deshecho el no confirmado. El registro

siempre define la vista correcta de la base de datos. En resumen, la recuperación es el proceso de hacer

que los datos sean coherentes con el registro de las transacciones en un momento dado.

La recuperación se lleva a cabo de forma automática cuando se inicia SQL Server, cuando se tiene acceso

a una base de datos o como paso final en la restauración de una base de datos desde la copia de

seguridad. El primero de los casos, cuando la recuperación se realiza cuando se inicia SQL Server, se

denomina recuperación de reinicio ("restartstartup recovery"). La recuperación desde las copias de

seguridad se debe normalmente a un error del disco. Este tipo de recuperación se denomina recuperación

de medios ("media recovery").

La recuperación de reinicio es automática y siempre recupera al momento dado más reciente. En el caso

de la recuperación desde copias de seguridad, el administrador de la base de datos puede elegir la

recuperación a un momento anterior. Esto está sujeto a limitaciones. Para obtener más información,

consulte los libros en línea de SQL Server 2000 (en inglés).

La recuperación de reinicio tiene lugar de forma automática cada vez que se inicia una instancia de SQL

Server y consiste en deshacer cualquier transacción que haya quedado incompleta la última vez que se

cerró la instancia. En el caso de la recuperación desde copias de seguridad, el administrador de la base

de datos puede elegir la recuperación a un momento anterior. Esto está sujeto a limitaciones. Para

obtener más información, consulte los libros en línea de SQL Server 2000 (en inglés). En ambos casos, la

recuperación funciona basada en este momento dado de destino.

La recuperación consta de dos fases:

1. Se rehacen todos los cambios hasta que se encuentra el momento dado de destino en el registro
de transacciones.

2. Se deshace todo el trabajo realizado por las transacciones que estaban activas en el momento
en el que se detuvo la acción de rehacer.

SQL Server utiliza puntos de control para acelerar la recuperación de reinicio. El punto de control fuerza

todas las páginas de datos modificadas actualmente en el búfer a que se incluyan en la caché del disco.

De este modo, se crea un punto de inicio para la parte de rehacer de la recuperación. Debido a que los

puntos de control pueden resultar costosos económicamente, SQL Server administra automáticamente

los puntos de control para maximizar el rendimiento mientras minimiza el tiempo que se tarda en

reiniciar.

En SQL Server 2000, las escrituras que finalizan correctamente se deben almacenar de forma duradera
en el disco. Si se utiliza el almacenamiento en disco en la caché de escritura, se debe trabajar en

colaboración con su proveedor para garantizar que la caché es tolerante a errores. Esta tolerancia indica

que la caché es inmune a los errores energéticos o a las acciones del operador. Si su caché no es

tolerante a errores, se debe deshabilitar.

Marcas lógicas de registro

En SQL Server 7.0 era posible la recuperación en cualquier momento especificado. En el caso de un error

grave del hardware, el proceso de restauración resultaba bastante sencillo. Sin embargo, otra amenaza

para la base de datos es la posibilidad de que se puedan introducir datos no válidos o que la acción de un

usuario destruya datos válidos. En este caso, es necesario determinar cuándo comenzó la transacción

problemática. En SQL Server 7.0, la única forma de realizar esto consistía en restaurar los registros en

una copia de la base de datos hasta que el problema volviese a repetirse; después, se podría ejecutar su

restauración en la imagen de producción hasta el momento justamente anterior al que fue descubierto el

error.

En SQL Server 2000, se pueden marcar las transacciones en el registro. Posteriormente, si se necesita

realizar una restauración, se puede hacer referencia a la marca utilizada en el momento de la ejecución

en lugar de emplear la hora de un reloj de pared. Para ello, se debe utilizar una instrucción denominada

BEGIN TRANSACTION y la cláusula WITH MARK [descripción]. Las marcas se almacenan en msdb. La

recuperación se puede incluir o detener justo antes de una transacción que contiene la marca. Por

ejemplo, si se dispone de un proceso que se ejecuta por lote y se cambian varios registros, se puede

utilizar esta característica para garantizar que si el proceso se ejecuta en circunstancias erróneas, se

puedan deshacer los datos hasta el momento dado en el que se ejecutó el comando.

Los nombres de marcas no necesitan ser únicos. Para indicar la transacción necesaria, se debe especificar

un valor datetime. La sintaxis es:

RESTORE LOG WITH [ STOPBEFOREMARK|STOPAFTERMARK ] = @TaggedTransaction

AFTER @datetime

También se pueden utilizar marcas en una transacción distribuida, denominadas marcas distribuidas,

para admitir la recuperación de varias bases de datos relacionadas en un estado coherente desde el

punto de vista transaccional. Estas bases de datos relacionadas pueden situarse en las mismas o en

diferentes instancias de SQL Server. Se pueden establecer marcas distribuidas en un conjunto de bases

de datos de forma periódica (por ejemplo, una vez cada cinco minutos). Si el registro de transacciones de

una de las bases de datos resulta dañado, se debe recuperar el conjunto de las bases de datos en un

momento anterior. La marca distribuida proporciona este punto. El uso de las marcas distribuidas invalida

la preocupación de coordinar el momento preciso de las copias de seguridad para varias bases de datos

relacionadas. Para obtener más información, consulte "Recovering to a Named Transaction" en los libros

en línea de SQL Server 2000.

Reducción del registro de transacciones

Las operaciones de reducción del registro no se ejecutaban de forma inmediata en SQL Server 7.0.

Quedaban aplazadas hasta que se realizara la copia de seguridad del registro de transacciones o se

truncara. Esto dejó confundidos a muchos clientes de SQL Server 7.0. SQL Server 2000 reduce al

máximo el registro y, a continuación, indica si se puede reducir aún más después de la copia de

seguridad del registro. En este caso, se debe ejecutar el comando de reducción de nuevo tras la

finalización de la copia de seguridad del registro. Para obtener más información, consulte "Shrinking the

Transaction Log" en los libros en línea de SQL Server 2000 (en inglés).

El tamaño del registro se basará en su modelo de recuperación actual y el diseño de su aplicación. Si se

considera necesario reducir el registro periódicamente, deberá examinarse el síntoma de la causa. Es

necesario seguir investigando sobre cuál es la causa de que se rellene el registro en lugar de centrarse en

el mantenimiento constante con el comando de reducción.

Modelos de recuperación

Los modelos de recuperación se agregaron a SQL Server 2000 para facilitar la planeación de la protección

de datos. Clarifican el equilibrio entre el rendimiento, los requisitos de espacio del registro y la protección

ante un error de un medio (disco). Existen tres modelos de recuperación: simple, completa y de registro

masivo.

La elección del modelo de recuperación se basa en los requisitos de disponibilidad y uso de la base de

datos y ayuda a determinar los procedimientos adecuados de restauración y copia de seguridad. Los

modelos de recuperación sólo se aplican a la recuperación de medios, es decir, a la recuperación desde

las copias de seguridad. La recuperación de reinicio recupera todo el trabajo confirmado. Para obtener

más información, consulte "Selecting a Recovery Model" en los libros en línea de SQL Server 2000 (en

inglés).

Se puede cambiar fácilmente entre los modelos de recuperación. Por ejemplo, en una base de datos de

gran tamaño, se puede utilizar la recuperación completa, de registro masivo, o ambas. Se puede utilizar

la completa durante el día y la de registro masivo por la noche, durante un proceso de carga de datos

que consista en la inserción masiva y la regeneración de índices. También se puede cambiar al registro

masivo mientras se ejecuta una carga de datos y volver al modo completo, ejecutar una copia de

seguridad del registro de transacciones y ser capaz de restaurar al momento dado sin tener que ejecutar

una copia de seguridad completa de la base de datos. Esta característica permite realizar el

procesamiento masivo de forma más eficaz; lo único que hay que hacer es realizar luego una copia de

seguridad del registro de transacciones.

Para cambiar los modelos de recuperación, utilice la siguiente sintaxis:

ALTER DATABASE SET RECOVERY RecoveryModel

Para obtener más información, consulte "Switching Recovery Models" en los libros en línea de SQL Server

2000 (en inglés).

Modelo de recuperación simple

El modelo de recuperación simple normalmente requiere menos espacio en el registro, pero provoca la

mayor pérdida potencial de trabajo si se dañan los datos o los archivos del registro. Sólo se registran los

eventos necesarios para la recuperación básica. Mediante el modelo de recuperación simple, sólo se

encuentran disponibles las copias de seguridad completas o de las diferencias de las bases de datos. En

caso de un error grave, se debe volver a realizar todo el trabajo confirmado desde la última copia de

seguridad. Este modelo es el más sencillo de administrar, pero no se trata de una buena elección para

una aplicación fundamental donde no se puede tolerar la pérdida de trabajo confirmado.

Este modelo es similar a la opción truncar registro en punto de comprobación de SQL Server 7.0 y

de las versiones anteriores.

Modelo de recuperación completa

En el modelo de recuperación completa se registra todo. Este modelo proporciona una protección total

frente a la pérdida de trabajo desde un archivo de datos dañado. Si se daña el registro de transacciones,

se pierde el trabajo confirmado desde la última copia de seguridad del registro y se debe rehacer de

forma manual.

Aún cuando se utilice el modelo de recuperación completa, es importante utilizar los discos con tolerancia

a errores para el registro de transacciones y evitar la pérdida de datos. El modelo de recuperación

completa también permite la recuperación en cualquier momento dado.

Modelo de recuperación de registro masivo

El modelo de recuperación de registro masivo proporciona el rendimiento óptimo para las operaciones

masivas. Estas operaciones consumen menos espacio de registro que con el modelo de recuperación

completa. Así, por ejemplo, se registra la asignación de una nueva página, pero no los datos insertados

en la misma. En SQL Server 2000, las operaciones masivas están formadas por la carga masiva (BCP y

BULK INSERT, incluyendo cuando se ejecutan dentro del paquete DTS), SELECT INTO, CREATE INDEX,

WRITETEXT y UPDATETEXT.

Comparados con el modelo de recuperación completa, el modelo de recuperación de registro de forma

masiva minimiza el registro de las operaciones masivas. Tenga en cuenta que en el caso de que la

recuperación se convierta en necesaria, si se daña el registro o las operaciones masivas han tenido lugar

desde la copia de seguridad del registro más reciente, se pierden los cambios efectuados en la base de

datos desde la última copia de seguridad del registro.

Este modelo no admite la recuperación a un momento dado, pero permitirá la recuperación al final de

una copia de seguridad del registro de transacciones que contenga cambios masivos. Las copias de

seguridad del registro de transacciones realizadas mediante el modelo de recuperación de registro de

forma masiva contienen las extensiones modificadas por las operaciones masivas. Esta característica

mejora la compatibilidad para el envío de registros, debido a que ya no es necesario preocuparse de que

una operación masiva invalide las copias de seguridad. SQL Server mantiene un mapa de bits para

realizar el seguimiento de las extensiones de datos modificadas, lo que optimiza el proceso por el que

SQL Server identifica los cambios.

Funcionalidad de copia de seguridad mejorada

Además de la introducción de los modelos de recuperación para simplificar la protección de los datos en

general, SQL Server 2000 ha mejorado la capacidad de administración: la tecnología de instantáneas, las

copias de seguridad de las diferencias y la seguridad.

 La cadena del registro de transacciones nunca se rompe. En SQL Server 7.0, determinadas

operaciones, como la agregación de un archivo a la base de datos, rompe la cadena de registro y

requiere la subsiguiente copia de seguridad completa de la base de datos.

 Las operaciones de copia de seguridad no entran en conflicto con las aplicaciones u otras

acciones administrativas. Por ejemplo, las copias de seguridad se pueden producir de forma

simultánea con operaciones masivas como la creación de índice y la carga masiva.

 Las copias de seguridad del registro y de archivos se pueden realizar simultáneamente.

Las operaciones de copia de seguridad desatendidas, con independencia de la actividad del sistema,

también son totalmente compatibles en SQL Server 2000.

SQL Server admite tecnologías de copias de seguridad instantáneas y de restauración al igual que

proveedores independientes de hardware y software. Las copias de seguridad instantáneas minimizan o

eliminan el uso de los recursos del servidor para realizar la copia de seguridad. Esto resulta

especialmente beneficioso para moderar las bases de datos de gran tamaño en las que resulta de vital

importancia la disponibilidad. Las principales ventajas de esta tecnología son:

 Se puede realizar una copia de seguridad en un plazo muy breve de tiempo, generalmente

medido en segundos, con poco o ningún impacto en el servidor.

 Se puede utilizar una copia de seguridad en disco para restaurar una base de datos con la

misma rapidez.

 Otro host puede crear una copia de seguridad sin impacto alguno en el sistema de producción.

 Se puede crear de forma instantánea la copia de una base de datos de producción para la

creación de informes o pruebas.

Las copias de seguridad y restauraciones instantáneas se realizan junto con hardware o software de otros

proveedores que utilizan características de SQL Server 2000 diseñadas con este propósito. La tecnología

de copia de seguridad crea una copia instantánea de los datos que se desean guardar, generalmente

dividiendo un conjunto reflejado de discos. En el momento de la restauración, el original se convierte en

disponible de forma inmediata. Los discos subyacentes se sincronizan en el fondo, dando como resultado

restauraciones casi instantáneas.

Las copias de seguridad de diferencias se pueden completar en un tiempo que es proporcional a la

cantidad de datos cambiados desde la última copia de seguridad completa. Cuanto menos datos se hayan

cambiado, más rápida será la copia de seguridad. SQL Server 2000 utiliza un mapa de bits para realizar

el seguimiento de las extensiones de datos modificadas desde la última copia de seguridad de la base de

datos o de archivos para que se puedan localizar de forma eficaz. Además, SQL Server 2000 admite

copias de seguridad de diferencias para los archivos.

Las copias de seguridad siguen acumulando cambios realizados en la base de datos desde la última copia

de seguridad completa, funcionando del mismo modo en el caso de una recuperación. No obstante, son

considerablemente más rápidas ya que sólo registran la pequeña cantidad de información modificada,

especialmente en bases de datos de gran tamaño que contienen sólo una pequeña cantidad de datos

modificados.

Para una mayor seguridad, se puede aplicar la protección por contraseña para los medios y conjuntos de

copia de seguridad. De este modo, se evita que usuarios no autorizados se agreguen a las copias de

seguridad o restauren la base de datos.

Mejoras administrativas

Se han mejorado varias características administrativas del motor de almacenamiento en SQL Server

2000.

Comprobación de la base de datos

Los DBCCs proporcionan una variedad de capacidades administrativas, incluidos los comandos CHECK

para la comprobación de la coherencia de la base de datos.

La experiencia con SQL Server 7.0 y SQL Server 2000 ha demostrado que la incoherencia de las bases de

datos se produce por los problemas de hardware que pueden o no ser detectados por el motor de la base

de datos o las aplicaciones durante el funcionamiento normal de los mismos. Esto se aplica

especialmente a los datos a los que no se tiene un acceso frecuente. Como respuesta a esta necesidad,

SQL Server 2000 introduce un modo de comprobación, Physical_Only, diseñado para detectar la mayoría

de los problemas causados por el hardware. Es muy rápido, aproximadamente la velocidad de

exploración del disco, y no utiliza los recursos de forma intensiva.

Debido a las mejoras fundamentales de la arquitectura en el motor de almacenamiento de SQL Server,

que comenzaron con SQL Server 7.0, no es necesario ejecutar la comprobación de la base de datos como

parte del mantenimiento normal. No obstante, Microsoft continúa comprometido con las herramientas de

comprobación de bases de datos como parte importante en la administración de datos de vital

importancia. Microsoft recomienda:

 Ejecutar de vez en cuando la comprobación Physical_Only, según la confianza que merezca el

hardware subyacente, especialmente los subsistemas de disco.

 Ejecutar una comprobación completa de la base de datos en momentos importantes, como una

actualización de hardware o software, o bien, cuando se sospeche la aparición de un problema

cualquiera que sea la causa.

Microsoft no recomienda la ejecución de una comprobación completa como parte del mantenimiento

normal.

SQL Server 2000 también incluye mejoras importantes en la comprobación de la base de datos:

 De forma predeterminada, la comprobación se realiza totalmente en línea. La comprobación en

línea tiene poco impacto en la carga de trabajo de las transacciones. Este impacto variará según la

carga del sistema, la configuración de hardware y la velocidad de tempdb. Microsoft ha medido

este impacto de un 15 a un 20 por ciento con una carga de trabajo OLTP media (CPU al 50 por

ciento). La opción TABLOCK se proporciona para obligar a que la comprobación tome bloqueos de

tabla compartidos, lo que le permite una ejecución más rápida y evitará las actualizaciones.

 La comprobación se realiza en paralelo en equipos de multiproceso simétrico (SMP), limitados al

grado máximo de paralelismo que haya definido para la instancia de SQL Server.

Los comandos de comprobación de SQL Server 2000 continúan admitiendo la funcionalidad de reparación

introducida en SQL Server 7.0. La reparación fuera de línea puede proporcionar una alternativa a la

restauración desde copias de seguridad en determinadas situaciones.

Control del estado de la base de datos

SQL Server 2000 incluye mejoras en la instrucción ALTER DATABASE que permiten un mayor control de

los estados de las bases de datos a través de Transact-SQL. Todas las opciones de base de datos se

pueden modificar ahora ejerciendo un mayor control a través del comando ALTER DATABASE;

sp_dboption y databaseproperty() ya no se actualizarán en las versiones futuras. Los comandos

Transact-SQL sp_helpdb y DatabasePropertyEx() proporcionan información sobre el estado de la

base de datos.
En la siguiente tabla se enumeran las opciones de estado de la base de datos.
Tipo de opción Valores disponibles
Acceso de usuario SINGLE_USER
RESTRICTED_USER
MULTI_USER
Disponibilidad ONLINE
OFFLINE
Actualización READ_ONLY
READ_WRITE

SQL Server establece también los siguientes estados en reacción a las condiciones dentro de la base de

datos: restauración, recuperación y sospecha. Las opciones de la base de datos se pueden establecer

mediante el uso de la cláusula SET de la instrucción ALTER DATABASE, el procedimiento sp_dboption

almacenado en el sistema, o bien, en determinados casos, el Administrador corporativo de SQL Server.

Cuando se modifica el estado de una base de datos, la sesión que realiza los cambios en el estado

permanece conectada, mientras que las sesiones no coherentes con el nuevo estado pueden finalizar y

deshacer sus transacciones. Entre las opciones de finalización de sesión se incluyen las siguientes:

 Finalización inmediata

 Finalización después de un tiempo especificado

 Permiso para que los procesos en curso se completen normalmente

 Comprobación de la actividad sin tener en cuenta el cambio de estado si se encuentran sesiones

de usuario activas

A continuación, se muestran dos ejemplos de la sintaxis:

alter database accting set read_only with rollback immediate

alter database accting set single_user with rollback after 60 seconds

Para obtener más información, consulte "Setting Database Options" en los libros en línea de SQL Server

2000 (en inglés).

Identificadores de proceso de sistema y unidades de trabajo

Una mejora adicional administrativa que sirve de ayuda cuando se necesita detener un proceso es el

comando KILL. Este comando ha sido mejorado con la información del estado. Por tanto, si desea

conocer el estado de un comando KILL pendiente, ejecute lo siguiente:

KILL SPID WITH STATUSONLY

Si intenta detener un identificador de proceso del sistema (SPID) que otro comando KILL está

deteniendo, el sistema devuelve la misma información del estado.

En SQL Server 2000, las transacciones MS DTC pueden existir sin una conexión o SPID asociado. Por
tanto, se puede utilizar una conexión para otros procesos mientras se espera que se complete una

transacción o unidad de trabajo. Cuando el administrador de transacciones MS DTC envía un mensaje de

que se ha completado la tarea, puede ejecutar o deshacer la transacción. Esto se conoce como unidad de

trabajo (UOW), que es el identificador utilizado por MS DTC para la transacción. La unidad UOW no

dispone de SPID.

Para obtener más información, consulte los libros en línea de SQL Server 2000 (en inglés).

Ajuste dinámico

En SQL Server 2000, el ajuste de rendimiento basado en el uso se administra de forma dinámica, sin que

se necesiten ni se recomienden ajustes manuales. Los parámetros estáticos se han eliminado, pero se ha

retenido el control administrativo para determinados recursos (por ejemplo, el establecimiento de un

límite superior sobre la cantidad de memoria que puede utilizar SQL Server). Este método resulta mucho

más preciso y receptivo que el sistema calculado manualmente basado en promedios y cálculos

aproximados. De este modo, permite que se concentre en los aspectos del diseño de la administración de

la base de datos. Los sistemas tradicionales de las bases de datos exigen una gran cantidad de

administración y ajuste manual. Así, por ejemplo, para ajustar el sistema según el uso, el administrador

de la base de datos necesitará controlar el sistema, grabando una enorme cantidad de estadísticas con el

tiempo, para seleccionar una configuración estática que parezca proporcionar la ventaja óptima del

sistema. A continuación el DBA deberá volver a evaluar el sistema para valorar el efecto que tiene la

nueva configuración y el proceso de ajuste volverá a comenzar de nuevo.

SQL Server 2000 introduce un algoritmo dinámico en el motor de almacenamiento que controla de forma

activa la utilización del servidor y ajusta la configuración internamente. La información y el análisis

dinámicos de SQL Server 2000 mantienen la configuración dentro del 10 por ciento del valor óptimo

absoluto (consulte la figura 3), dando como resultado un sistema muy adaptable y con un mejor ajuste.
Figura 3. Ajuste del algoritmo adaptable

Componentes de almacenamiento de datos

SQL Server 2000 proporciona un equilibrio en el procesamiento de todas las CPUs disponibles en

coordinación con el sistema operativo Windows 2000. Si se está ejecutando una instancia dedicada de

SQL Server, y no hay otras aplicaciones que produzcan una carga en los mismos recursos, no se debe

modificar la configuración predeterminada relacionada con el procesador para utilizar al máximo todos los

procesadores. SQL Server puede aprovechar las ventajas del procesamiento en paralelo en varios

procesadores para consultas, generación de índices, DBCCs y otras operaciones. Para obtener más

información sobre el paralelismo, consulte "Degree of Parallelism" en los libros en línea de SQL Server

2000 (en inglés).

SQL Server 2000 Standard Edition puede admitir hasta cuatro procesadores y 2 GB de memoria física

(RAM). Enterprise Edition puede escalar hacia arriba a nuevos niveles y admitir hasta 32 procesadores y

64 GB de memoria física (RAM).

La principal fuente de memoria para una instancia de SQL Server se denomina su bloque de memoria.

Prácticamente todas las estructuras de datos que utilizan memoria en una instancia de SQL Server se

asignan desde el bloque de memoria. Entre los ejemplos de objetos asignados desde el bloque de

memoria se incluyen la caché de búfer, donde se almacenan las últimas páginas de datos leídas, y la

caché de procedimiento, que retiene los últimos planes de ejecución.

Las asignaciones dentro del bloque de memoria son muy dinámicas. Para optimizar el rendimiento, SQL

Server ajusta de forma constante las cantidades de bloque de memoria asignadas a las distintas áreas.
Por ejemplo, cuando el número de planes de ejecución almacenados es más bajo, se ajusta el bloque

para utilizar de forma óptima los recursos haciendo disponible más memoria para la caché de datos.

SQL Server 2000 está diseñado para que la utilización de la memoria minimice al máximo la E/S de

disco. Para llevar a cabo esta tarea, SQL Server utiliza la caché de búfer para retener los últimos datos a

los que se ha hecho referencia, en la memoria física (RAM), donde pueden volver a utilizarse. Una posible

forma de reducir la E/S de disco y acelerar el sistema de la base de datos consistiría en agregarla a la

memoria física (RAM) disponible en SQL Server.

Normalmente, la configuración de la memoria no requiere ajuste alguno. No obstante, se puede controlar

en determinados casos. Por ejemplo, la memoria requiere una atención especial cuando se ejecutan

varias instancias de SQL Server en el mismo servidor, especialmente si se utiliza el clúster de

conmutación por error. Asimismo, es necesario controlar el uso de la memoria si se ejecutan

aplicaciones, además de SQL Server, en el mismo servidor.

Figura 4: Utilización de la memoria con más de 4 GB de RAM

SQL Server 2000 aprovecha las nuevas capacidades de Windows 2000 para incluir memoria física (RAM)

superior a 3 GB. Consulte la figura 4. SQL Server 2000 Enterprise Edition puede utilizar toda la memoria

que permita Windows 2000 Advanced Server o Windows 2000 Datacenter Server.

Para obtener más información sobre los soportes de memoria de gran tamaño en SQL Server 2000,

consulte "Managing AWE Memory" en los libros en línea de SQL Server 2000 (en inglés).

Archivos, grupos de archivos y discos

SQL Server almacena los datos y el registro en archivos de disco. En una instalación básica y

predeterminada, los datos y los archivos de registro se crean en la ubicación predeterminada especificada

en la configuración del servidor. Sin embargo, para maximizar el rendimiento y la capacidad de

administración, puede aplicar algunos principios básicos:

  Repartir los datos tantos discos, canales y controladores como sea posible.

En general, cuanto más discos (ejes) se tengan (a pesar del tamaño individual) y más rápido sea el
acceso a éstos (controladores y canales), más rápido podrá el motor de almacenamiento leer y escribir
datos. Cuanto mayor sea la utilización del sistema, más importante será separar los archivos de datos de
los archivos del registro mediante su almacenamiento en distintos grupos de unidades físicas. Además,
debido a que ha cambiado el uso de tempdb, deberá ahora almacenar tempdb en un grupo grande de
discos, por ejemplo, con los archivos de datos o en un conjunto de discos.

 Utilizar grupos de archivos para que la base de datos corporativa resulte más fácil de

administrar.

Cada base de datos comienza por un grupo de archivos predeterminado. Debido a que SQL Server 2000
puede trabajar de forma eficaz sin grupos de archivos adicionales, un gran número de sistemas no
necesitarán agregar grupos de archivos definidos por los usuarios. Sin embargo, a medida que aumenta
el sistema, el uso de grupos de archivos adicionales puede proporcionar una mayor capacidad de
administración cuando un administrador de base de datos cualificado la implemente y mantenga.
En SQL Server 2000, si define un grupo de archivos en particular dentro de una base de datos como de
sólo lectura, los datos de dicho grupo no podrán alterarse, aunque se puede seguir administrando la
información del catálogo como los permisos.
Nota   En SQL Server 2000, el número de E/S asincrónicas se administra ahora de forma dinámica
dentro del motor de la base de datos y no se ve influida por el número de archivos o grupos de archivos
utilizados, como era el caso en SQL Server 7.0.
Al implementar u optimizar un diseño de la base de datos, el administrador de la base de datos
(ingeniero de la base de datos) necesita tener en cuenta la configuración de los componentes de la base
de datos, especialmente el diseño de los discos lógicos y físicos y la organización de los archivos de las
bases de datos en los discos.

Conclusión

Para los administradores de bases de datos, una mayor flexibilidad y control sobre el rendimiento ofrece

libertad para centrar sus conocimientos y experiencia sobre tecnología de base de datos en la

administración de los componentes de código, diseño y almacenamiento de base de datos como un

enfoque unificado en la administración del sistema de base de datos. El motor de base de datos de SQL

Server 2000 proporciona una extensibilidad y flexibilidad para una gran variedad de implementaciones de

bases de datos.

Lectura recomendada

Para obtener información sobre el correcto funcionamiento de un sistema de base de datos con procesos

y profesionales, se recomienda que lea sobre el programa de Microsoft Certified Database Administrator

(en inglés) y Microsoft Operations Framework (en inglés).

Los libros en línea de SQL Server 2000 se incluyen con SQL Server 2000. También se encuentran

disponibles en http://www.microsoft.com/sql/productdoc/ (en inglés)

Para obtener más información sobre hardware y SQL Server, consulte SQL Server 2000 on Large Servers

en los libros en línea de SQL Server 2000 (en inglés).

Para obtener más información sobre la arquitectura de SQL Server y el motor de almacenamiento,

consulte los libros en línea de SQL Server 2000 (en inglés), así como Inside Microsoft SQL Server 2000

de Kalen Delaney (en inglés).