 |
| Imagen tomada de www.enter.co |
Intoducción
En entornos corporativos con
mainframes, comunes hace unos años, el establecimiento de un sistema de base de
datos era un acontecimiento en el que no se podía dejar nada a la
improvisación. La inversión corporativa en bases de datos, tanto a nivel de hardware,
software como de recursos de administrador de bases de datos requería que los
detalles de la aplicación se conociesen perfectamente de antemano.
En la actualidad, las
aplicaciones de bases de datos evolucionan rápidamente y las inercias se
reducen, con la rapidez en el desarrollo e implantación que eso conlleva. Por
ello, es necesario que el gestor de bases de datos se encargue cada vez más de tareas rutinarias, presentando
a los usuarios y al administrador una mayor simplicidad, al mismo tiempo que
les dota de los mecanismos para poder modificar y extender las características
de las aplicación de base de datos mientras ésta se halla en producción.
SQL Server es un potente
gestor de bases de bases de datos que cumple estos requisitos necesarios para
poder gestionar de forma sencilla bases de datos con grandes volúmenes de
información.
Las estructuras físicas de almacenamiento y el modelo de datos
Los atributos de cada una de
las entidades van a tener que plasmarse en tablas, y estas concretarse en
registros. Cada uno de los registros de una tabla está limitado en la práctica como
veremos, por el tamaño de la página.
Las estructuras de almacenamiento y la escalabilidad
Una importante funcionalidad
que resulta deseable es la manera en que almacenan las bases de datos permita
que la cantidad de información pueda crecer a medida que lo requieran las
necesidades de la empresa. Además, también es importante que puedan gestionarse con similar eficiencia volúmenes
de información heterogéneos, de manera que el gestor pueda ser adecuado para
bases de datos desde unos pocos Megabytes hasta los Terabytes y más allá. SQL
Server almacena las bases de datos directamente en ficheros del sistema de
archivos del sistema operativo del servidor. Esto permite una gran
escalabilidad, ya que basta con añadir nuevos ficheros a la base de datos para
hacerla crecer, aun cuando los dispositivos de almacenamiento se llenen,
simplemente ubicándolos en nuevos dispositivos.
Las estructuras de almacenamiento y la obtención de datos
El modelo relacional no
especifica en absoluto cómo deben almacenarse los datos, pero, el modo en el
que esto se lleve a cabo repercutirá en la dinámica de las operaciones que
sobre ellos se efectúen. De este modo, los datos en las tablas se organizan
apoyándose en la existencia de índices, tablas de punteros a localizadores de
páginas, que se almacenan en páginas de un tipo especial. La elección de una
cierta arquitectura de índices repercutirá en la velocidad de ejecución de las
consultas así como en la de inserción modificación o eliminación de registros.
Cómo se almacenan los datos
El almacenamiento físico de
los datos en SQL Server es absolutamente independiente del almacenamiento
lógico, por lo que siempre utilizaremos en nuestra operación con el gestor la
terminología de bases de datos y tablas
que tan común es en el modelo relacional. Sin embargo, no resulta del todo
posible, como administradores, obviar el conocimiento de las particularidades
de SQL Server en cuanto al almacenamiento físico de los datos. Algunos aspectos
de este almacenamiento físico pueden ser susceptibles de ser administrados,
para mejorar el rendimiento del servidor.
Estructuras de datos
SQL Server almacena los datos
utilizando básicamente dos estructuras: páginas (pages) y extensiones
(extents).
Páginas (pages)
Toda la información en SQL
Server se almacena en páginas. Los datos y los índices o la información del
catálogo, se almacenan en páginas de 8 KB, por lo que se dispone de 128
páginas por MB. El tamaño de la página es importante, pues ciertos aspectos se
ven afectados por este tamaño de página como, el tamaño máximo del registro. A
cada página se le asigna un identificador numérico único que permite
referenciarla. Cada página contiene una cabecera de 96 bytes que contiene
información crucial para la gestión de datos y a la que el servidor va a hacer
referencia constantemente. La cabecera contiene el tipo de página en cuestión,
además indica el espacio libre de almacenamiento disponible en esta, y también
contiene punteros a las páginas anterior y posterior en el almacenamiento, así
como la ubicación física de la página y el identificador del objeto al que
pertenece la página.
Extensiones (extents)
Las páginas contiguas se agrupan
de ocho en ocho en extensiones. La extensión es la unidad mínima de
almacenamiento en las bases de datos, por lo que es precisamente la que se
asocia a una tabla o índice. Existen dos tipos de extensiones: aquellos que se
asignan completamente a un objeto, es decir, en los que todas sus páginas
pertenecen al mismo objeto, y los que contienen páginas de más de un objeto.
Los primeros son denominados uniformes (uniform extents) y los segundos mixtos
(mixed extents). Una extensión contiene 8 páginas, es decir, 64 KBytes. Sólo
tablas o índices que excedan este tamaño tiene sentido que reciban extensiones uniformes.
Cuando se crea un nuevo objeto se le asigna espacio en una extensión mixta, hasta que tiene páginas de
datos, momento en el que se le comienza a tratar como un objeto al que se le
asignan extensiones uniformes. Este comportamiento se ilustra en la Figura 1.
 |
| Figura 1 |
Tipos de página y modos de almacenamiento
Páginas de datos (data pages)
En estas páginas es en las que
realmente se almacenan los registros de cada uno de los objetos de la base de
datos. El tamaño de fila está directamente limitado a esta cantidad, con la
salvedad, que comentaremos con más detalle más adelante, que los tipos de datos
text, ntext e image que no deben tenerse en cuenta al almacenarse en páginas
separadas. Una fila no puede almacenarse en más de una página, con lo que,
teniendo en cuenta que poseen una cabecera de 96 bytes y que la estructura de
la fila también consume un pequeño espacio que debe almacenarse, limita el tamaño de los registros en SQL Server a 8.060 bytes. Las páginas de datos se
vinculan unas con otras siguiendo un modelo de lista doblemente enlazada, de manera que cada una de las páginas
contiene en su cabecera punteros a la página que le sigue y a la que le precede
en la estructura de almacenamiento de un determinado objeto. Cada fila posee un
número que la identifica y la información de los datos que almacena. En la
parte final de la página se almacena un tabla de punteros, tal y como se
Ilustra en la Figura 2, que permite acceder a las filas de datos almacenadas en
el interior de la página. Esta tabla contiene la posición relativa, en bytes y
respecto al origen de la página del inicio de cada uno de los registros.
Páginas de texto e imagen (text, ntext e image pages)
Este tipo de objeto que
permite una gran cantidad de información almacenada se llama BLO ( Binary Large
Object) o BLOPS en plural.
Para poder almacenar este tipo
de objetos, SQL Server destina páginas separadas especiales que se encuentran
vinculadas a las páginas que contienen
las filas de la tabla.
El tipo de datos text es el que se utiliza para almacenar
cadenas de más de 8.000 caracteres. O si una fila debe almacenar varios campos
que en total ocupen más de 8.000 caracteres.
El tipo ntext es similar a este pero para caracteres Unicode cuando la cadena excede los 4.000 caracteres.
El tipo image se utiliza para almacenar imágenes, gráficos o bien cualquier
tipo de fichero que contenga información no textual como archivos ejecutables.
Cada dato que pertenezca a uno
de estos tipos de datos independiente de lo grande que sea, se almacena en una
fila ocupando 16 bits en realidad sólo se almacena el puntero que apunta a la
ubicación real de los datos que se
encuentran en las páginas anteriormente citadas.
Las páginas de este tipo de
datos pueden contener datos de más de una columna de la misma tabla pero no de
tablas distintas. Incluso es posible que una misma página mezcle información de
los tres tipos distintos text, ntext
e image siempre que pertenezcan a la
misma tabla.
Cómo se almacenan los datos en las páginas textuales
Cualquiera de los tres tipos
de datos contiene una información binaria que se dividirá en páginas de 8K que
se almacenan separadamente a las de datos de la misma Tabla.
Las páginas se estructuran de
manera análoga a como lo hace las
páginas del índice, en un árbol balanceado (b-tree). Esta estructura en árbol sobre
los fragmentos de la página facilita lecturas y búsquedas más eficientes.
Además objetos text pequeños comparten
páginas, con lo que se consigue un mejor aprovechamiento del espacio.
El puntero de 16 bytes que,
para cada dato text se almacena en la
fila de datos de la tabla, contiene un puntero a un bloque de 84 bytes que se constituye
en la raíz del árbol balanceado de las páginas textuales para ese dato. En función
del número de páginas necesarias para almacenar el dato, esto es, del tamaño
del mismo, se insertarán tantos niveles intermedios entre la raíz y las hojas
en el árbol balanceado como sea necesario.
Páginas de índice
En estas páginas se almacenan
las tablas de punteros que plasman la estructura de árbol balanceado de los
índices en SQL Server.
Páginas de log
El Iog es un conjunto de ficheros
lógicos que contiene filas de log en páginas especiales, que en la terminología
del gestor se llaman registros.
Al no construir el log con
páginas de datos convencionales, no compite con los datos por la ocupación de
la memoria caché, con la consiguiente mejora de rendimiento.
El log es divisible en varios
ficheros físicos, puede crecer automáticamente y permite su truncado más rápido
e independiente de los datos.
Páginas de asignación de extensiones (Extents)
Para conocer la distribución
de los datos en las extensiones disponibles, SQL Server utiliza unas páginas
especiales que se agrupan con el nombre de mapa global de asignación de extensiones
o Global Allocation Map. (GAM). Este
mapa contiene información acerca de las extensiones que están ocupadas o libres.
También recoge la distribución de los mixed y uniform extents, ambas
informaciones se encuentran separadas en dos mapas diferentes: El GAM que
almacena la información que ocupan las extensiones y un segundo mapa denominado Second
Global Allocation Map, SGAM, que contiene las extensiones mezcladas mixed extent a las que aún no se les ha asignado ningún objeto.
Las páginas GAM tienen una
estructura similar aun Bitmap en la que
cada bit está asociado a un estent gestionable. Cada página GAM puede administrar hasta 63,904 extensiones
o cerca de 4GB de datos. Estas páginas contienen 1 bit por cada extension que
administran. El bit toma valor 0 si la extensión a sido asignada y 1 si se
encuentra libre.
La estructura de las páginas
SGAM es prácticamente idéntica. También tienen un tamaño de 64K y estructura de
bitmap. En este caso el bit toma valor 1 si la extension asociada es de tipo mixed
extent y 0 en caso contrario aunque la extensión esté libre.
Páginas de asignación de páginas (Page Free space, PFS)
SQL incluye un último tipo de
páginas denominadas Page Free Space (PFS), que contiene información sobre de si
cada una de las páginas de datos ha sido asignada a un objeto o está libre. Es
decir, las páginas GAM y SGAM sólo proporcionan información sobre si una extensión
está libre o no, pero si su ocupación es parcial no indican que páginas están
libres ni cual es su grado de ocupación de las que contienen datos.
Las páginas PFS tienen una
estructura similar a las GAM, disponen de un array de 8.060 posiciones en que
cada elemento es un bitmap de 3 posiciones y su valor representa el grado de
ocupación de la página. Cada PFS controla 8.060 páginas de datos, es decir 64
Mb. La utilización combinada de
las páginas GAM y PFS permite a SQL Server decidir dónde ubicar cada nuevo
registro que deba añadirse a una tabla.
Páginas de ubicación de objetos (Index Allocatíon Map Pages IAM)
Todavía falta información para
poder gestionar el almacenamiento en una base de datos. Sabemos qué extensiones
están libres y ocupadas. Incluso conocemos el grado de ocupación de las páginas
individuales, pero nos falta saber a qué objeto está asociada cada página.
Para cada fichero de datos en
el que el objeto está ubicado, se dispone de una o varias de estas páginas, en
las que se almacenan las extensiones que dicho objeto tiene asignadas en ese
fichero. Se almacenarán tantas páginas IAM como sean necesarias para conocer las
asignaciones de extensión para todos los objetos.
Cómo
decide SQL Server dónde almacenar los datos
Cuando enviamos a SQL Server
una sentencia SQL, ya sea una sentencia de selección SELECT o una sentencia de
modificación de datos como UPDATE o INSERT, el gestor debe decidir dónde se hallan los datos que estamos reclamando, o
dónde ubicar los registros que deseamos insertar. Estas tareas necesitan leer o
modificar la información anotada en las páginas PFS, GAM e IAM anteriormente
descritas.Cómo se distribuyen las páginas de ubicación
Las páginas de ubicación se almacenan
en los ficheros asociados a las bases de datos. Estos ficheros contienen una
cabecera y un conjunto de bytes estructurados como una sucesión de páginas,
cada una de ellas con un identificador numérico único. La primera página de cada
fichero, identificada con el número 1 es una PFS, que contendrá el espacio libre
en las 8.060 páginas ordinarias de datos siguientes. El fichero contendrá tantos
grupos de 8.60 páginas precedidas por una PFS corno sea necesario. Tras la
primera PFS, y con identificador de página 2, aparece una página GAM, y después una
SGAM, con el número 3 que contiene la información de ocupación de las 64.000
primeras extensiones que pueda contener el
fichero. Esta estructura se repite por cada 64.000 extensiones que contenga el
fichero. Por el contrario la ubicación de
las páginas IAM no está fijada previamente. Se insertan aleatoriamente a lo
largo del fichero, en una lista
enlazada, y existirán tantas como sean necesarias para cada
Insercción de registros
Para insertar nuevos datos en
la base de datos SQL Server examinará las páginas IAM para determinar que
extensiones han sido asociadas al objeto en el que estamos insertando el registro. Por cada una de estos extensiones el gestor inspeccionará
las páginas PFS correspondientes para
determinar si existen páginas en él con suficiente espacio para añadir la nueva
fila.
Si se da el caso que ninguna
de las páginas ubicadas en las extensiones asociadas tenga espacio libre para
insertar la fila, se asigna una nueva
extensión al objeto. Para optimizar el almacenamiento, la extensión se escoge
de las que aun queden disponibles en los ficheros que más espacio vacío tengan en
el grupo de ficheros. En caso de que tengan que asociarse múltiples elementos, se hará de
manera proporcional al espacio vacío disponible en cada fichero.
Páginas incompletas
Existe la posibilidad de que se produzcan
escrituras incompletas de páginas de datos si por ejemplo se produce una caída
de corriente eléctrica, o en casos graves de avería que detengan el servidor
antes de que haya completado una
operación de entrada-salida.
Para proteger nuestra base de
datos de estos fallos, podemos activar la detección de páginas incompletas (torn
page detection), Si activamos esta opción, cada vez que se realiza una nueva
escritura de datos en la base de datos se escriben bits adicionales de
comprobación, de manera que el gestor pueda examinar el contenido de las
páginas para comprobar que no se ha producido una escritura incompleta de página.
Unidades de almacenamiento (allocaton units)
Las extensiones también se
agrupan, para formar allocation units, Cada allocation unit contiene 32
extensiones, es decir, 256 páginas con un espacio de almacenamiento de 512 KB. La primera de las 256 páginas es denominada allocation
page y contiene información que permite controlar la ubicación de cada una de las
páginas en la unidad de almacenamiento, así como los vínculos de cada extensión
con los objetos de la base de datos. Después de la cabecera se almacenan 32 estructuras de 16 bytes cada una, una
para cada extensión en la allocation unit.
Aquí la segunda parte de Arquitectura física de SQL Server
Aquí la segunda parte de Arquitectura física de SQL Server
Buena informacion crack me sirvio mucho
ResponderEliminar