2.1.

2 Estructuras físicas de la base de datos

Estructura física de la base de datos Oracle:

La Arquitectura de Oracle tiene tres componentes básicos:

1. La Estructura de memoria
2. Los Procesos
3. Los Archivos.

1. ESTRUCTURA DE LA MEMORIA:

Es la estructura de memoria compartida que contienen datos e información de control para una
instancia de una base de datos, cada instancia tiene sus propias estructuras de memoria y se
localiza en la memoria virtual del computador. Las estructuras de memoria se denominan System
Global Area (SGA) la cual es un área compartida por todos los usuarios y se divide en tres partes:

1.1. Fondo común compartido (Shared pool): Se utiliza durante el procesamiento de comandos.
Tiene dos zonas:
– Library Cache: almacena información relacionada a la instrucción de SQL:
– – Data Dictionary Cache (Dictionary Cache o Row Cache): almacena la información de uso
más frecuente sobre el diccionario de datos. Esta información incluye definición de
columnas, usuarios, passwords y privilegios. Esta información es usada durante tiempo de
compilación.
1.2. Arear de Memoria rápida (Dtabase buffer cache): mantiene los bloques de datos leídos
directamente de los archivos de datos. Cuando se procesa una consulta, el servidor busca los
bloques de datos requeridos en esta estructura. Si no se encuentra, el proceso servidor lee el
bloque de la memoria secundaria y coloca una copia. Está organizada en dos listas:
– Lista de sucios: bloques que han sufrido modificaciones y no han sido escritos en disco.
– Lista de menos recientemente usados: mantiene los bloques libres, los bloques a los que se
está accediendo actualmente y los bloques sucios que aún no han sido remitidos a la lista
de sucios.

1.3. Área de registro de rehacer (Redo log buffer): es un buffer circular que mantiene todos los
cambios que han sido realizados sobre la base de datos por operaciones de insert, update,
delete, create, alter y drop. Las entradas de este buffer contienen toda la información
necesaria para reconstruir los cambios realizados a la base de datos por medio de cualquier
instrucción (el bloque que ha sido cambiado, la posición de cambio y el nuevo valor). El uso es
estrictamente secuencial.

2. ARCHIVOS:

Los archivos que maneja Oracle, se clasifican en cuatro grupos:

2.1 Los Archivos de Datos (Datafiles): sirve para el almacenamiento físico de las tablas, índices y
procedimientos, estos son los únicos que contienen los datos de los usuarios de la base de datos.

2.2 Archivos de Control (control files): tiene la descripción física y dirección de los archivos para el
arranque correcto de la base de datos

2.3 Archivos de Rehacer (redo log files): tienen los cambios que se han hecho a la base de datos
para recuperar fallas o para manejar transacciones. Debe esta conformado por dos grupos como
mínimo y cada grupo debe esta en discos separados. El principal propósito de estos archivos es de
servir de respaldo de los datos en la memoria RAM.

2.4 Archivos fuera de línea (archived files): archivos opcionales donde se pueda guardar
información vieja de los archivos de rehacer, convenientes para respaldos de base de datos

3. LOS PROCESOS:
Los procesos son programas que se ejecutan para permitior el acceso a los datos, se cargan en
memoria y son transportados para los usuarios. Se clasifican en tres grupos:

3.1. Procesos de Base o de Soporte: se encargan de traer datos desde y hacia la estructura de
memoria (SGA), cada uno tiene su propia área de memoria; los procesos de este tipo son los
siguientes:

- Database Writer (DBWR): se encarga de copiar los bloques desde el buffer cache hasta la
memoria secundaria.

- Log Writer (LGWR): escribe las entradas desde el Log Buffer a disco. La escritura de
bloques del Redo Log Buffer a disco ocurre secuencialmente y bajo las siguientes reglas:
– Cuando el Redo Log está lleno en un 33% o más.

– Cuando oucrre un time-out (cada tres segundos).

– Antes de que el DBWR escriba algún bloque modificado a disco.

– Cuando una transacción se compromete.

- Checkpoint (CKPT): encargado de notificar al DBWR para que se escriban en los archivos
de datos todos los bloques contenidos en la lista de sucios. Este proceso es invocado en
intervalos de tiempo determinados. El CKPT es opcional, si no existe las funciones son
realizadas por el LGWR.

- System Monitor (SMON): Encargado de realizar un proceso de recuperación rápida cada

vez que una instancia es inicializada. Esta labor incluye limpieza de las estructuras de datos
de soporte a la ejecución de consultas y llevar a la base de datos a un estado estable
 previo a la ejecución de aquellas transacciones que no hayan culminado exitosamente.
También se encarga de desfragmentar el espacio físico de almacenamiento uniendo
bloques de datos libres en la memoria secundaria.

- Process Monitor (PMON): lleva la pista de los procesos de la base de datos y efectúa
labores de limpieza (liberar recursos y bloques ocupados en los cache’s) si alguno de ellos
termina prematuramente.

- Archiver (ARCH): copia las bitácoras activas cuando éstas se encuentran llenas. Este
proceso se encuentra activo sólo cuando el DBMS se encuentra operando en modo
ARCHIVELOG, el único modo que admite recuperación de los datos frente a fallas del
sistema.

- Recoverer (RECO): resuelve transacciones distribuidas que se encuentran pendientes

debido a la red o a fallas ocurridas en la base de datos distribuida.

- Dispatcher (Dnnn): se crea por cada sesión de trabajo activa; es responsable de enrutar
los requerimientos desde el proceso usuario, al cual se encuentra asociado, hacia los
procesos servidores y retornar la respuesta al proceso de usuario adecuado. Estos
procesos se crean solo cuando se ejecuta con la opción multithreading.

3.2. Procesos de Usuario: se encarga de ejecutar el código de aplicación del usuario y manejar el
perfil del usuario con sus variables de ambiente. Estos procesos no se pueden comunicar
directamente con la base de datos, por lo que la comunicación la establecen mediante
procesos de servidores.

3.3. Procesos de Servidores: estos procesos ejecutan las órdenes SQL de los usuarios y llevan los
datos del buffer caché para que los procesos de usuario puedan tener acceso a los datos.

Estructura lógica de la base de datos oracle:

Estructura física de la base de datos Oracle:

La Arquitectura de Oracle tiene tres componentes básicos:

4. La Estructura de memoria
5. Los Procesos
6. Los Archivos.
1. ESTRUCTURA DE LA MEMORIA:

Es la estructura de memoria compartida que contienen datos e información de control para una
instancia de una base de datos, cada instancia tiene sus propias estructuras de memoria y se
localiza en la memoria virtual del computador. Las estructuras de memoria se denominan System
Global Area (SGA) la cual es un área compartida por todos los usuarios y se divide en tres partes:

3.4. Fondo común compartido (Shared pool): Se utiliza durante el procesamiento de comandos.
Tiene dos zonas:
– Library Cache: almacena información relacionada a la instrucción de SQL:
– – Data Dictionary Cache (Dictionary Cache o Row Cache): almacena la información de uso
más frecuente sobre el diccionario de datos. Esta información incluye definición de
columnas, usuarios, passwords y privilegios. Esta información es usada durante tiempo de
compilación.

3.5. Arear de Memoria rápida (Dtabase buffer cache): mantiene los bloques de datos leídos
directamente de los archivos de datos. Cuando se procesa una consulta, el servidor busca los
bloques de datos requeridos en esta estructura. Si no se encuentra, el proceso servidor lee el
bloque de la memoria secundaria y coloca una copia. Está organizada en dos listas:
– Lista de sucios: bloques que han sufrido modificaciones y no han sido escritos en disco.
– Lista de menos recientemente usados: mantiene los bloques libres, los bloques a los que se
está accediendo actualmente y los bloques sucios que aún no han sido remitidos a la lista
de sucios.

3.6. Área de registro de rehacer (Redo log buffer): es un buffer circular que mantiene todos los
cambios que han sido realizados sobre la base de datos por operaciones de insert, update,
delete, create, alter y drop. Las entradas de este buffer contienen toda la información
necesaria para reconstruir los cambios realizados a la base de datos por medio de cualquier
instrucción (el bloque que ha sido cambiado, la posición de cambio y el nuevo valor). El uso es
estrictamente secuencial.
4. ARCHIVOS:

Los archivos que maneja Oracle, se clasifican en cuatro grupos:

2.1 Los Archivos de Datos (Datafiles): sirve para el almacenamiento físico de las tablas, índices y
procedimientos, estos son los únicos que contienen los datos de los usuarios de la base de datos.

2.2 Archivos de Control (control files): tiene la descripción física y dirección de los archivos para el
arranque correcto de la base de datos

2.3 Archivos de Rehacer (redo log files): tienen los cambios que se han hecho a la base de datos
para recuperar fallas o para manejar transacciones. Debe esta conformado por dos grupos como
mínimo y cada grupo debe esta en discos separados. El principal propósito de estos archivos es de
servir de respaldo de los datos en la memoria RAM.

2.4 Archivos fuera de línea (archived files): archivos opcionales donde se pueda guardar
información vieja de los archivos de rehacer, convenientes para respaldos de base de datos
5. LOS PROCESOS:

Los procesos son programas que se ejecutan para permitior el acceso a los datos, se cargan en
memoria y son transportados para los usuarios. Se clasifican en tres grupos:

5.1. Procesos de Base o de Soporte: se encargan de traer datos desde y hacia la estructura de
memoria (SGA), cada uno tiene su propia área de memoria; los procesos de este tipo son los
siguientes:

- Database Writer (DBWR): se encarga de copiar los bloques desde el buffer cache hasta la
memoria secundaria.

- Log Writer (LGWR): escribe las entradas desde el Log Buffer a disco. La escritura de
bloques del Redo Log Buffer a disco ocurre secuencialmente y bajo las siguientes reglas:
– Cuando el Redo Log está lleno en un 33% o más.

– Cuando oucrre un time-out (cada tres segundos).

 – Antes de que el DBWR escriba algún bloque modificado a disco.

– Cuando una transacción se compromete.

- Checkpoint (CKPT): encargado de notificar al DBWR para que se escriban en los archivos
de datos todos los bloques contenidos en la lista de sucios. Este proceso es invocado en
intervalos de tiempo determinados. El CKPT es opcional, si no existe las funciones son
realizadas por el LGWR.

- System Monitor (SMON): Encargado de realizar un proceso de recuperación rápida cada

vez que una instancia es inicializada. Esta labor incluye limpieza de las estructuras de datos
de soporte a la ejecución de consultas y llevar a la base de datos a un estado estable
previo a la ejecución de aquellas transacciones que no hayan culminado exitosamente.
También se encarga de desfragmentar el espacio físico de almacenamiento uniendo
bloques de datos libres en la memoria secundaria.

- Process Monitor (PMON): lleva la pista de los procesos de la base de datos y efectúa
labores de limpieza (liberar recursos y bloques ocupados en los cache’s) si alguno de ellos
termina prematuramente.

- Archiver (ARCH): copia las bitácoras activas cuando éstas se encuentran llenas. Este
proceso se encuentra activo sólo cuando el DBMS se encuentra operando en modo
ARCHIVELOG, el único modo que admite recuperación de los datos frente a fallas del
sistema.

- Recoverer (RECO): resuelve transacciones distribuidas que se encuentran pendientes

debido a la red o a fallas ocurridas en la base de datos distribuida.

- Dispatcher (Dnnn): se crea por cada sesión de trabajo activa; es responsable de enrutar
los requerimientos desde el proceso usuario, al cual se encuentra asociado, hacia los
procesos servidores y retornar la respuesta al proceso de usuario adecuado. Estos
procesos se crean solo cuando se ejecuta con la opción multithreading.

5.2. Procesos de Usuario: se encarga de ejecutar el código de aplicación del usuario y manejar el
perfil del usuario con sus variables de ambiente. Estos procesos no se pueden comunicar
 directamente con la base de datos, por lo que la comunicación la establecen mediante
procesos de servidores.

5.3. Procesos de Servidores: estos procesos ejecutan las órdenes SQL de los usuarios y llevan los
datos del buffer caché para que los procesos de usuario puedan tener acceso a los datos.
Arquitectura MySQL

MySQL es un sistema de bases de datos relacional. Eso significa que

la información está
organizada en bases de datos, que están compuestas por tablas, que
están compuestas
por registros, que están compuestos por columnas. En la Figura
2podemos ver dicha
estructura.
Cada base de datos está compuesta por tablas. Las tablas a su vez se
definen con
columnas, cada una de un tipo de datos diferente, que conforman los
registros. Además
de los datos que almacenamos, las tablas pueden contener índices, y
algunas de sus
columnas tienen propiedades especiales como claves primarias y
claves foráneas que
permiten establecer relaciones entre las tablas.
Los sistemas que manejan estas estructuras se pueden describir en
capas. En general,
un sistema de bases de datos relacional tienen tres capas:
La capa de aplicación es la parte más externa del sistema y es la
interfice a través de la
que los usuarios se comunican con el sistema.
La funcionalidad central del sistema está en la capa lógica. Es donde
se realizan todas las
operaciones del sistema. Esta capa se puede refinar de la siguiente
manera:
En esta capa se realizan varias operaciones. La primera y que sirve de
interficie con la
capa de aplicación es el procesamiento de las instrucciones SQL.
Después hay dos
módulos: el manejo de transacciones, y la recuperación después de
errores. Finalmente
está la parte que se encarga de traducir las instrucciones SQL en
acciones sobre el
almacenamiento de datos.
Finalmente, la capa física es donde están almacenados los datos.
Esta arquitectura general sirve para MySQL, y en la Figura 5podemos
ver con más
detalle los aspectos particulares del sistema.
En esta figura, los Connectorsrepresentan la API que MySQL expone
al usuario, por lo
que representaría la parte más cercana al sistema de la capa
aplicación. MySQL dispone
de APIs para muchos lenguajes de programación. En la parte más
baja podemos ver los
elementos File systemy Files & Logsque representan la capa física.
Lo que queda entre medio es la capa lógica, donde reside la
funcionalidad del servidor. La
Figura 6muestra como es el flujo de ejecución de una sentencia SQL
dentro del servidor.
Básicamente, las consultas entran a través de un protocolo
cliente/servidor provenientes
de las aplicaciones. Las consultas, pueden ser almacenas en una
cache para su posterior
reutilización. Después, si la consulta que ha entrado no se encuentra
en la cache, se
procede a su análisis sintáctico, que produce una serie de estructuras
de datos que se
almacenan en memoria. En esta fase, puede hacerse uso de las
sentencias preparadas
(Prepared statements) que sirven para aumentar la eficiencia de
determinadas consultas.
Una vez la consulta está preparada, su ejecución puede ser directa
(no es un SELECT) o
bien pasar por el optimizador si es de tipo SELECT. Esto es así ya que
las instrucciones
SELECT suelen ser las potencialmente más costosas ya que pueden
necesitar acceder a
tablas enteras o grandes porciones de la base de datos.
Una vez la sentencia está lista para ejecutarse, el acceso a los datos
se hace a través de
una interfície genérica de acceso a los datos físicos que es
independiente del tipo de tabla
que usemos. Y por último, la consulta se ejecuta en el subsistema
correspondiente al tipo
de tabla que estamos accediendo.

Arquitectura física de una base de datos en SQL Server

La unidad fundamental del almacenamiento de datos en SQL Server es la página. El

espacio en disco asignado a un archivo de datos (.mdf o .ndf) de una base de datos se divide
lógicamente en páginas numeradas de forma contigua de 0 a n. Las operaciones de E/S de
disco se realizan en el nivel de página. Es decir, SQL Server lee o escribe páginas de datos
enteras.

Las extensiones son una colección de ocho páginas físicamente contiguas; se utilizan para
administrar las páginas de forma eficaz. Todas las páginas se almacenen en extensiones.

Páginas

En SQL Server, el tamaño de página es de 8 KB. Esto significa que las bases de datos de
SQL Server tienen 128 páginas por megabyte. Cada página empieza con un encabezado de
96 bytes, que se utiliza para almacenar la información del sistema acerca de la página. Esta
información incluye el número de página, el tipo de página, el espacio libre en la página y
el Id. de unidad de asignación del objeto propietario de la página.

En la siguiente tabla se muestran los tipos de página utilizados en los archivos de datos de
una base de datos de SQL Server.

Tipo de página Contenido

Las filas de datos con todos los datos, excepto los datos text,
ntext, image, nvarchar(max), varchar(max),
Datos
varbinary(max) y xml, cuando text in row está establecido en
ON.
Índice Entradas de índice.
Texto o imagen Tipos de datos de objetos grandes:

 Datos text, ntext, image, nvarchar(max),

varchar(max), varbinary(max) y xml.

Columnas de longitud variable cuando la fila de datos

 sobrepasa 8 KB:

 varchar, nvarchar, varbinary y sql_variant.

Mapa de asignación global,

Mapa de asignación global Información acerca de si se han asignado las extensiones.
compartido
Espacio disponible en Información acerca de la asignación de páginas y el espacio
páginas libre disponible en las páginas.
Mapa de asignación de Información acerca de las extensiones utilizadas por una tabla o
índices un índice por unidad de asignación.
Información acerca de las extensiones modificadas por
Mapa cambiado
operaciones masivas desde la última instrucción BACKUP
masivamente
LOG por unidad de asignación.
Información acerca de las extensiones que han cambiado desde
Mapa cambiado diferencial la última instrucción BACKUP DATABASE por unidad de
asignación.
Nota:
Los archivos de registro no contienen páginas, contienen series de registros.

Las filas de datos se colocan en las páginas una a continuación de otra, empezando
inmediatamente después del encabezado. Al final de la página, comienza una tabla de
desplazamiento de fila y cada una de esas tablas contiene una entrada para cada fila de la
página. Cada entrada registra la distancia del primer byte de la fila desde el inicio de la
página. Las entradas de la tabla de desplazamiento de fila están en orden inverso a la
secuencia de las filas de la página.

Compatibilidad con filas largas

Los filas no puede abarcar páginas en SQL Server 2005; no obstante, partes de la fila se
pueden apartar de la página de la fila para que la fila pueda ser muy grande. La cantidad
máxima de datos y de sobrecarga que está contenida en una única fila de una página es de
8.060 bytes (8 KB). Sin embargo, esto no incluye los datos almacenados en el tipo de
página Texto o imagen. En SQL Server 2005, esta restricción se suaviza para tablas que
contienen las columnas varchar, nvarchar, varbinary o sql_variant. Cuando el tamaño
de fila total de todas las columnas variables y fijas de una tabla excede el límite de 8.060
bytes, SQL Server mueve dinámicamente una o más columnas de longitud variable a
páginas de la unidad de asignación ROW_OVERFLOW_DATA, empezando por la
columna con el mayor ancho. Esto se realiza cuando una operación de inserción o
actualización aumenta el tamaño total de la fila más allá del límite de 8060 bytes. Cuando
una columna se mueve a una página de la unidad de asignación
ROW_OVERFLOW_DATA, se mantiene un puntero de 24 bytes de la página original de
la unidad de asignación IN_ROW_DATA. Si una operación posterior reduce el tamaño de
la fila ,SQL Server vuelve a mover las columnas dinámicamente a la página de datos
original. Para obtener más información, vea Datos de desbordamiento de fila superiores a 8
KB.
Extensiones

Las extensiones son la unidad básica en la que se administra el espacio. Una extensión
consta de ocho páginas contiguas físicamente, es decir 64 KB. Esto significa que las bases
de datos de SQL Server tienen 16 extensiones por megabyte.

Para hacer que la asignación de espacio sea eficaz, SQL Server no asigna extensiones
completas a tablas con pequeñas cantidades de datos. SQL Server tiene dos tipos de
extensiones:

 Las extensiones uniformes son propiedad de un único objeto; sólo el objeto propietario
puede utilizar las ocho páginas de la extensión.
 Las extensiones mixtas, que pueden estar compartidas por hasta ocho objetos. Cada una
de las 8 páginas de la extensión puede ser propiedad de un objeto diferente.

A las tablas o índices nuevos se les suelen asignar páginas de extensiones mixtas. Cuando
la tabla o el índice crecen hasta el punto de ocupar ocho páginas, se pasan a extensiones
uniformes para las posteriores asignaciones. Si crea un índice de una tabla existente que
dispone de filas suficientes para generar ocho páginas en el índice, todas las asignaciones
del índice están en extensiones uniformes.
SQL Server 2005 asigna una base de datos a un conjunto de archivos del sistema operativo.
Los datos y la información del registro nunca se mezclan en el mismo archivo, y cada
archivo sólo es utilizado por una base de datos. Los grupos de archivos se denominan
colecciones con nombre de archivos que se utilizan como ayuda en tareas de colocación de
datos y administrativas, como las operaciones de copia de seguridad y restauración.
Archivos de base de datos

Las bases de datos de SQL Server 2005 utilizan tres tipos de archivos:

 Archivos de datos principales

El archivo de datos principal es el punto de partida de la base de datos y apunta a los otros
archivos de la base de datos. Cada base de datos tiene un archivo de datos principal. La
extensión recomendada para los nombres de archivos de datos principales es .mdf.
 Archivos de datos secundarios
Los archivos de datos secundarios son todos los archivos de datos menos el archivo de
datos principal. Puede que algunas bases de datos no tengan archivos de datos
secundarios, mientras que otras pueden tener varios archivos de datos secundarios. La
extensión de nombre de archivo recomendada para los archivos de datos secundarios
es .ndf.
 Archivos de registro
Los archivos de registro almacenan toda la información de registro que se utiliza para
recuperar la base de datos. Como mínimo, tiene que haber un archivo de registro por cada
base de datos, aunque puede haber varios. La extensión de nombre de archivo
recomendada para los archivos de registro es .ldf.

SQL Server 2005 no exige las extensiones de nombre de archivo .mdf, .ndf y .ldf, pero
estas extensiones ayudan a identificar las distintas clases de archivos y su uso.

En SQL Server 2005, las ubicaciones de todos los archivos de una base de datos se graban
tanto en el archivo principal de la base de datos como en la base de datos master. SQL
Server Database Engine (Motor de base de datos de SQL Server) utiliza casi siempre la
información de ubicación del archivo de la base de datos master. Sin embargo, Database
Engine (Motor de base de datos) utiliza la información de ubicación del archivo principal
para inicializar las entradas de ubicación de archivos de la base de datos master en las
siguientes situaciones:

 Al adjuntar una base de datos mediante la instrucción CREATE DATABASE con la opción
FOR ATTACH o la opción FOR ATTACH_REBUILD_LOG.
 Al actualizar de SQL Server versión 2000 o versión 7.0 a SQL Server 2005.
 Al restaurar la base de datos master.

Nombres de archivo lógico y físico

Los archivos de SQL Server 2005 tienen dos nombres:

logical_file_name

logical_file_name es el nombre que se utiliza para hacer referencia al archivo en todas las
instrucciones Transact-SQL. El nombre de archivo lógico tiene que cumplir las reglas de
los identificadores de SQL Server y tiene que ser único entre los nombres de archivos
lógicos de la base de datos.

os_file_name

os_file_name es el nombre del archivo físico que incluye la ruta de acceso al directorio.
Debe seguir las reglas para nombres de archivos del sistema operativo.

La siguiente ilustración muestra ejemplos de los nombres de archivo lógico y físico de una
base de datos creada en una instancia predeterminada de SQL Server

Los archivos de datos y de registro de SQL Server se pueden colocar en sistemas de

archivos FAT o NTFS. Se recomienda utilizar el sistema de archivos NTFS por las
características de seguridad que ofrece. No se pueden colocar grupos de archivos de datos
de lectura y escritura, y archivos de registro, en un sistema de archivos NTFS comprimido.
Sólo las bases de datos de sólo lectura y los grupos de archivos secundarios de sólo lectura
se pueden colocar en un sistema de archivos NTFS comprimido. Para obtener más
información, vea Grupos de archivos de sólo lectura y compresión.

Cuando se ejecutan varias instancias de SQL Server en un único equipo, cada instancia
recibe un directorio predeterminado diferente para albergar los archivos de las bases de
datos creadas en la instancia. Para obtener más información, vea Ubicaciones de archivos
para instancias predeterminadas y con nombre de SQL Server 2005.

Páginas de archivo de datos

Las páginas de un archivo de SQL Server 2005 están numeradas secuencialmente,

comenzando por 0 para la primera página del archivo. Cada archivo de una base de datos
tiene un número de identificador único. Para identificar de forma única una página de una
base de datos, se requiere el identificador del archivo y el número de la página. El siguiente
ejemplo muestra los números de página de una base de datos que tiene un archivo de datos
principal de 4 MB y un archivo de datos secundario de 1 MB.

La primera página de cada archivo es una página de encabezado de archivo que contiene
información acerca de los atributos del archivo. Algunas de las otras páginas del comienzo
del archivo también contienen información de sistema, como mapas de asignación. Una de
las páginas de sistema almacenadas en el archivo de datos principal y en el archivo de
registro principal es una página de inicio de la base de datos que contiene información
acerca de los atributos de la base de datos. Para obtener más información acerca de las
páginas y los tipos de páginas, vea Páginas y extensiones.

Tamaño de archivo

Los archivos de SQL Server 2005 pueden crecer automáticamente a partir del tamaño
originalmente especificado. Cuando se define un archivo, se puede especificar un
incremento de crecimiento. Cada vez que se llena el archivo, el tamaño aumenta en la
cantidad especificada. Si hay varios archivos en un grupo de archivos, no crecerán
automáticamente hasta que todos los archivos estén llenos. A continuación, el crecimiento
tiene lugar por turnos.
Cada archivo también puede tener un tamaño máximo especificado. Si no se especifica un
tamaño máximo, el archivo puede crecer hasta utilizar todo el espacio disponible en el
disco. Esta característica es especialmente útil cuando SQL Server se utiliza como una base
de datos incrustada en una aplicación para la que el usuario no dispone fácilmente de
acceso a un administrador del sistema. El usuario puede dejar que los archivos crezcan
automáticamente cuando sea necesario y evitar así las tareas administrativas de supervisar
la cantidad de espacio libre en la base de datos y asignar más espacio manualmente.
Archivos de instantáneas de bases de datos

La forma de archivo que utiliza una instantánea de base de datos para almacenar sus datos
de copia por escritura depende de si la instantánea la ha creado un usuario o se utiliza
internamente:

 Una instantánea de base de datos que crea un usuario almacena sus datos en uno o más
archivos dispersos. La tecnología de archivos dispersos es una característica del sistema de
archivos NTFS. Al principio, un archivo disperso no incluye datos de usuario y no se le
asigna espacio en disco. Para obtener información general sobre el uso de los archivos
dispersos en instantáneas de bases de datos y el crecimiento de éstas, vea
Funcionamiento de las instantáneas de la base de datos y Descripción del tamaño de los
archivos dispersos en instantáneas de bases de datos.
 Las instantáneas de bases de datos las utilizan internamente algunos comandos DBCC.
Entre estos comandos se incluyen: DBCC CHECKDB, DBCC CHECKTABLE, DBCC
CHECKALLOC y DBCC CHECKFILEGROUP. Una instantánea de base de datos interna utiliza
secuencias de datos alternativos dispersos de los archivos de base de datos originales.
Como los archivos dispersos, las secuencias de datos alternativos son una característica
del sistema de archivos NTFS. El uso de las secuencias de datos alternativos dispersos
permite que varias asignaciones de datos se asocien a un único archivo o carpeta sin
afectar a las estadísticas de tamaño o volumen.

Grupos de archivos de una base de datos

Los objetos y archivos de una base de datos se pueden agrupar en grupos de archivos con
fines de asignación y administración. Hay dos tipos de grupos de archivos:

Principal

El grupo de archivos principal contiene el archivo de datos principal y los demás archivos
asignados específicamente a otro grupo de archivos. Todas las páginas de las tablas del
sistema están asignadas al grupo de archivos principal.

Definidos por el usuario

Los grupos de archivos definidos por el usuario son los grupos de archivos especificados
mediante la palabra clave FILEGROUP en la instrucción CREATE DATABASE o ALTER
DATABASE.

Los archivos de registro nunca forman parte de un grupo de archivos. El espacio del
registro se administra de forma independiente del espacio de datos.

Ningún archivo puede pertenecer a más de un grupo de archivos. Las tablas, los índices y
los datos de objetos grandes se pueden asociar a un grupo de archivos específico. En este
caso, todas sus páginas se asignarán a dicho grupo de archivos o se pueden crear particiones
en las tablas e índices. Los datos de las tablas e índices con particiones se dividen en
unidades y cada una de ellas se puede colocar en un grupo de archivos independiente de
una base de datos. Para obtener más información acerca de las tablas e índices con
particiones, vea Tablas e índices con particiones.

Un grupo de archivos de cada base de datos se designa como grupo de archivos

predeterminado. Cuando se crea una tabla o un índice sin especificar un grupo de archivos,
se supone que todas las páginas se asignarán a partir del grupo de archivos predeterminado.
Sólo un grupo de archivos puede ser el predeterminado en un momento dado. Los
miembros de la función fija db_owner de la base de datos pueden cambiar el grupo de
archivos predeterminado de un grupo a otro. Si no se especifica ningún grupo de archivos
predeterminado, se considera como tal al grupo de archivos principal.

Ejemplo de archivos y grupos de archivos

En el siguiente ejemplo se crea una base de datos con una contraseña de SQL Server. La
base de datos tiene un archivo de datos principal, un grupo de archivos definido por el
usuario y el archivo de registro. El archivo de datos principal está en el grupo de archivos
principal y el grupo de archivos definido por el usuario tiene dos archivos de datos
secundarios. Una instrucción ALTER DATABASE hace que el grupo de archivos definido
por el usuario sea el grupo predeterminado. A continuación, se crea una tabla que especifica
el grupo de archivos definido por el usuario.

USE master;
GO
-- Create the database with the default data
-- filegroup and a log file. Specify the
-- growth increment and the max size for the
-- primary data file.
CREATE DATABASE MyDB
ON PRIMARY
( NAME='MyDB_Primary',
FILENAME=
'c:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\data\MyDB_Prm.mdf',
SIZE=4MB,
MAXSIZE=10MB,
FILEGROWTH=1MB),
FILEGROUP MyDB_FG1
 ( NAME = 'MyDB_FG1_Dat1',
FILENAME =
'c:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\data\MyDB_FG1_1.ndf',
SIZE = 1MB,
MAXSIZE=10MB,
FILEGROWTH=1MB),
( NAME = 'MyDB_FG1_Dat2',
FILENAME =
'c:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\data\MyDB_FG1_2.ndf',
SIZE = 1MB,
MAXSIZE=10MB,
FILEGROWTH=1MB)
LOG ON
( NAME='MyDB_log',
FILENAME =
'c:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\data\MyDB.ldf',
SIZE=1MB,
MAXSIZE=10MB,
FILEGROWTH=1MB);
GO
ALTER DATABASE MyDB
MODIFY FILEGROUP MyDB_FG1 DEFAULT;
GO

-- Create a table in the user-defined filegroup.

USE MyDB;
CREATE TABLE MyTable
( cola int PRIMARY KEY,
colb char(8) )
ON MyDB_FG1;
GO
La siguiente ilustración resume los resultados del ejemplo anterior.

2.1.3 Requerimientos para instalación.

2.1.4 Instalación del software de BD en modo transaccional
2.1.5 Variables de Ambiente y archivos importantes para instalación.
2.1.6 Procedimiento general de instalación
2.1.7 Procedimiento para configuración de un DBMS
2.1.8 Comandos generales de alta y baja del DBMS