2.1.

2 Estructuras fsicas de la base de datos

Estructura fsica de la base de datos Oracle:

La Arquitectura de Oracle tiene tres componentes bsicos:
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 informacin 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 comn compartido (Shared pool): Se utiliza durante el procesamiento de comandos.
Tiene dos zonas:
Library Cache: almacena informacin relacionada a la instruccin de SQL:
Data Dictionary Cache (Dictionary Cache o Row Cache): almacena la informacin de uso
ms frecuente sobre el diccionario de datos. Esta informacin incluye definicin de
columnas, usuarios, passwords y privilegios. Esta informacin es usada durante tiempo de
compilacin.

1.2. Arear de Memoria rpida (Dtabase buffer cache): mantiene los bloques de datos ledos
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 an 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 informacin
necesaria para reconstruir los cambios realizados a la base de datos por medio de cualquier
instruccin (el bloque que ha sido cambiado, la posicin 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 fsico 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 descripcin fsica y direccin 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
mnimo y cada grupo debe esta en discos separados. El principal propsito de estos archivos es de
servir de respaldo de los datos en la memoria RAM.

2.4 Archivos fuera de lnea (archived files): archivos opcionales donde se pueda guardar
informacin 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 ms.
Cuando oucrre un time-out (cada tres segundos).
Antes de que el DBWR escriba algn bloque modificado a disco.
Cuando una transaccin 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 recuperacin rpida cada
vez que una instancia es inicializada. Esta labor incluye limpieza de las estructuras de datos
de soporte a la ejecucin de consultas y llevar a la base de datos a un estado estable
previo a la ejecucin de aquellas transacciones que no hayan culminado exitosamente.
Tambin se encarga de desfragmentar el espacio fsico 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 efecta
labores de limpieza (liberar recursos y bloques ocupados en los caches) si alguno de ellos
termina prematuramente.

- Archiver (ARCH): copia las bitcoras activas cuando stas se encuentran llenas. Este
proceso se encuentra activo slo cuando el DBMS se encuentra operando en modo
ARCHIVELOG, el nico modo que admite recuperacin 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 sesin 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 opcin multithreading.


3.2. Procesos de Usuario: se encarga de ejecutar el cdigo de aplicacin 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 comunicacin 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 lgica de la base de datos oracle:





Estructura fsica de la base de datos Oracle:

La Arquitectura de Oracle tiene tres componentes bsicos:
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 informacin 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 comn compartido (Shared pool): Se utiliza durante el procesamiento de comandos.
Tiene dos zonas:
Library Cache: almacena informacin relacionada a la instruccin de SQL:
Data Dictionary Cache (Dictionary Cache o Row Cache): almacena la informacin de uso
ms frecuente sobre el diccionario de datos. Esta informacin incluye definicin de
columnas, usuarios, passwords y privilegios. Esta informacin es usada durante tiempo de
compilacin.

3.5. Arear de Memoria rpida (Dtabase buffer cache): mantiene los bloques de datos ledos
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 an 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 informacin
necesaria para reconstruir los cambios realizados a la base de datos por medio de cualquier
instruccin (el bloque que ha sido cambiado, la posicin 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 fsico 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 descripcin fsica y direccin 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
mnimo y cada grupo debe esta en discos separados. El principal propsito de estos archivos es de
servir de respaldo de los datos en la memoria RAM.

2.4 Archivos fuera de lnea (archived files): archivos opcionales donde se pueda guardar
informacin 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 ms.
Cuando oucrre un time-out (cada tres segundos).
Antes de que el DBWR escriba algn bloque modificado a disco.
Cuando una transaccin 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 recuperacin rpida cada
vez que una instancia es inicializada. Esta labor incluye limpieza de las estructuras de datos
de soporte a la ejecucin de consultas y llevar a la base de datos a un estado estable
previo a la ejecucin de aquellas transacciones que no hayan culminado exitosamente.
Tambin se encarga de desfragmentar el espacio fsico 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 efecta
labores de limpieza (liberar recursos y bloques ocupados en los caches) si alguno de ellos
termina prematuramente.

- Archiver (ARCH): copia las bitcoras activas cuando stas se encuentran llenas. Este
proceso se encuentra activo slo cuando el DBMS se encuentra operando en modo
ARCHIVELOG, el nico modo que admite recuperacin 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 sesin 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 opcin multithreading.


5.2. Procesos de Usuario: se encarga de ejecutar el cdigo de aplicacin 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 comunicacin 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 informacin est
organizada en bases de datos, que estn compuestas por tablas, que
estn compuestas
por registros, que estn 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. Adems
de los datos que almacenamos, las tablas pueden contener ndices, y
algunas de sus
columnas tienen propiedades especiales como claves primarias y
claves forneas 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 aplicacin es la parte ms externa del sistema y es la
interfice a travs de la
que los usuarios se comunican con el sistema.
La funcionalidad central del sistema est en la capa lgica. 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 aplicacin es el procesamiento de las instrucciones SQL.
Despus hay dos
mdulos: el manejo de transacciones, y la recuperacin despus de
errores. Finalmente
est la parte que se encarga de traducir las instrucciones SQL en
acciones sobre el
almacenamiento de datos.
Finalmente, la capa fsica es donde estn almacenados los datos.



Esta arquitectura general sirve para MySQL, y en la Figura 5podemos
ver con ms
detalle los aspectos particulares del sistema.
En esta figura, los Connectorsrepresentan la API que MySQL expone
al usuario, por lo
que representara la parte ms cercana al sistema de la capa
aplicacin. MySQL dispone
de APIs para muchos lenguajes de programacin. En la parte ms
baja podemos ver los
elementos File systemy Files & Logsque representan la capa fsica.
Lo que queda entre medio es la capa lgica, donde reside la
funcionalidad del servidor. La
Figura 6muestra como es el flujo de ejecucin de una sentencia SQL
dentro del servidor.
Bsicamente, las consultas entran a travs de un protocolo
cliente/servidor provenientes



de las aplicaciones. Las consultas, pueden ser almacenas en una
cache para su posterior
reutilizacin. Despus, si la consulta que ha entrado no se encuentra
en la cache, se
procede a su anlisis sintctico, 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 ejecucin 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 ms 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 travs de
una interfcie genrica de acceso a los datos fsicos 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 fsica de una base de datos en SQL Server


La unidad fundamental del almacenamiento de datos en SQL Server es la pgina. El
espacio en disco asignado a un archivo de datos (.mdf o .ndf) de una base de datos se divide
lgicamente en pginas numeradas de forma contigua de 0 a n. Las operaciones de E/S de
disco se realizan en el nivel de pgina. Es decir, SQL Server lee o escribe pginas de datos
enteras.
Las extensiones son una coleccin de ocho pginas fsicamente contiguas; se utilizan para
administrar las pginas de forma eficaz. Todas las pginas se almacenen en extensiones.
Pginas

En SQL Server, el tamao de pgina es de 8 KB. Esto significa que las bases de datos de
SQL Server tienen 128 pginas por megabyte. Cada pgina empieza con un encabezado de
96 bytes, que se utiliza para almacenar la informacin del sistema acerca de la pgina. Esta
informacin incluye el nmero de pgina, el tipo de pgina, el espacio libre en la pgina y
el Id. de unidad de asignacin del objeto propietario de la pgina.
En la siguiente tabla se muestran los tipos de pgina utilizados en los archivos de datos de
una base de datos de SQL Server.
Tipo de pgina Contenido
Datos
Las filas de datos con todos los datos, excepto los datos text,
ntext, image, nvarchar(max), varchar(max),
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 asignacin global,
Mapa de asignacin global
compartido
Informacin acerca de si se han asignado las extensiones.
Espacio disponible en
pginas
Informacin acerca de la asignacin de pginas y el espacio
libre disponible en las pginas.
Mapa de asignacin de
ndices
Informacin acerca de las extensiones utilizadas por una tabla
o un ndice por unidad de asignacin.
Mapa cambiado
masivamente
Informacin acerca de las extensiones modificadas por
operaciones masivas desde la ltima instruccin BACKUP
LOG por unidad de asignacin.
Mapa cambiado diferencial
Informacin acerca de las extensiones que han cambiado desde
la ltima instruccin BACKUP DATABASE por unidad de
asignacin.
Nota:
Los archivos de registro no contienen pginas, contienen series de registros.
Las filas de datos se colocan en las pginas una a continuacin de otra, empezando
inmediatamente despus del encabezado. Al final de la pgina, comienza una tabla de
desplazamiento de fila y cada una de esas tablas contiene una entrada para cada fila de la
pgina. Cada entrada registra la distancia del primer byte de la fila desde el inicio de la
pgina. Las entradas de la tabla de desplazamiento de fila estn en orden inverso a la
secuencia de las filas de la pgina.


Compatibilidad con filas largas
Los filas no puede abarcar pginas en SQL Server 2005; no obstante, partes de la fila se
pueden apartar de la pgina de la fila para que la fila pueda ser muy grande. La cantidad
mxima de datos y de sobrecarga que est contenida en una nica fila de una pgina es de
8.060 bytes (8 KB). Sin embargo, esto no incluye los datos almacenados en el tipo de
pgina Texto o imagen. En SQL Server 2005, esta restriccin se suaviza para tablas que
contienen las columnas varchar, nvarchar, varbinary o sql_variant. Cuando el tamao
de fila total de todas las columnas variables y fijas de una tabla excede el lmite de 8.060
bytes, SQL Server mueve dinmicamente una o ms columnas de longitud variable a
pginas de la unidad de asignacin ROW_OVERFLOW_DATA, empezando por la
columna con el mayor ancho. Esto se realiza cuando una operacin de insercin o
actualizacin aumenta el tamao total de la fila ms all del lmite de 8060 bytes. Cuando
una columna se mueve a una pgina de la unidad de asignacin
ROW_OVERFLOW_DATA, se mantiene un puntero de 24 bytes de la pgina original de
la unidad de asignacin IN_ROW_DATA. Si una operacin posterior reduce el tamao de
la fila ,SQL Server vuelve a mover las columnas dinmicamente a la pgina de datos
original. Para obtener ms informacin, vea Datos de desbordamiento de fila superiores a 8
KB.
Extensiones

Las extensiones son la unidad bsica en la que se administra el espacio. Una extensin
consta de ocho pginas contiguas fsicamente, es decir 64 KB. Esto significa que las bases
de datos de SQL Server tienen 16 extensiones por megabyte.
Para hacer que la asignacin de espacio sea eficaz, SQL Server no asigna extensiones
completas a tablas con pequeas cantidades de datos. SQL Server tiene dos tipos de
extensiones:
Las extensiones uniformes son propiedad de un nico objeto; slo el objeto propietario
puede utilizar las ocho pginas de la extensin.
Las extensiones mixtas, que pueden estar compartidas por hasta ocho objetos. Cada una
de las 8 pginas de la extensin puede ser propiedad de un objeto diferente.
A las tablas o ndices nuevos se les suelen asignar pginas de extensiones mixtas. Cuando
la tabla o el ndice crecen hasta el punto de ocupar ocho pginas, 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 pginas en el ndice, todas las asignaciones
del ndice estn en extensiones uniformes.


SQL Server 2005 asigna una base de datos a un conjunto de archivos del sistema operativo.
Los datos y la informacin del registro nunca se mezclan en el mismo archivo, y cada
archivo slo 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 colocacin de
datos y administrativas, como las operaciones de copia de seguridad y restauracin.
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
extensin 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
extensin de nombre de archivo recomendada para los archivos de datos secundarios es
.ndf.
Archivos de registro
Los archivos de registro almacenan toda la informacin de registro que se utiliza para
recuperar la base de datos. Como mnimo, tiene que haber un archivo de registro por cada
base de datos, aunque puede haber varios. La extensin 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
informacin de ubicacin del archivo de la base de datos master. Sin embargo, Database
Engine (Motor de base de datos) utiliza la informacin de ubicacin del archivo principal
para inicializar las entradas de ubicacin de archivos de la base de datos master en las
siguientes situaciones:
Al adjuntar una base de datos mediante la instruccin CREATE DATABASE con la opcin
FOR ATTACH o la opcin FOR ATTACH_REBUILD_LOG.
Al actualizar de SQL Server versin 2000 o versin 7.0 a SQL Server 2005.
Al restaurar la base de datos master.
Nombres de archivo lgico y fsico
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 lgico tiene que cumplir las reglas de
los identificadores de SQL Server y tiene que ser nico entre los nombres de archivos
lgicos de la base de datos.
os_file_name
os_file_name es el nombre del archivo fsico que incluye la ruta de acceso al directorio.
Debe seguir las reglas para nombres de archivos del sistema operativo.
La siguiente ilustracin muestra ejemplos de los nombres de archivo lgico y fsico 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
caractersticas 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.
Slo las bases de datos de slo lectura y los grupos de archivos secundarios de slo lectura
se pueden colocar en un sistema de archivos NTFS comprimido. Para obtener ms
informacin, vea Grupos de archivos de slo lectura y compresin.
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 ms informacin, vea Ubicaciones de archivos
para instancias predeterminadas y con nombre de SQL Server 2005.
Pginas de archivo de datos
Las pginas de un archivo de SQL Server 2005 estn numeradas secuencialmente,
comenzando por 0 para la primera pgina del archivo. Cada archivo de una base de datos
tiene un nmero de identificador nico. Para identificar de forma nica una pgina de una
base de datos, se requiere el identificador del archivo y el nmero de la pgina. El siguiente
ejemplo muestra los nmeros de pgina 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 pgina de cada archivo es una pgina de encabezado de archivo que contiene
informacin acerca de los atributos del archivo. Algunas de las otras pginas del comienzo
del archivo tambin contienen informacin de sistema, como mapas de asignacin. Una de
las pginas de sistema almacenadas en el archivo de datos principal y en el archivo de
registro principal es una pgina de inicio de la base de datos que contiene informacin
acerca de los atributos de la base de datos. Para obtener ms informacin acerca de las
pginas y los tipos de pginas, vea Pginas y extensiones.
Tamao de archivo
Los archivos de SQL Server 2005 pueden crecer automticamente a partir del tamao
originalmente especificado. Cuando se define un archivo, se puede especificar un
incremento de crecimiento. Cada vez que se llena el archivo, el tamao aumenta en la
cantidad especificada. Si hay varios archivos en un grupo de archivos, no crecern
automticamente hasta que todos los archivos estn llenos. A continuacin, el crecimiento
tiene lugar por turnos.
Cada archivo tambin puede tener un tamao mximo especificado. Si no se especifica un
tamao mximo, el archivo puede crecer hasta utilizar todo el espacio disponible en el
disco. Esta caracterstica es especialmente til cuando SQL Server se utiliza como una base
de datos incrustada en una aplicacin para la que el usuario no dispone fcilmente de
acceso a un administrador del sistema. El usuario puede dejar que los archivos crezcan
automticamente cuando sea necesario y evitar as las tareas administrativas de supervisar
la cantidad de espacio libre en la base de datos y asignar ms espacio manualmente.
Archivos de instantneas de bases de datos

La forma de archivo que utiliza una instantnea de base de datos para almacenar sus datos
de copia por escritura depende de si la instantnea la ha creado un usuario o se utiliza
internamente:
Una instantnea de base de datos que crea un usuario almacena sus datos en uno o ms
archivos dispersos. La tecnologa de archivos dispersos es una caracterstica 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 informacin general sobre el uso de los archivos
dispersos en instantneas de bases de datos y el crecimiento de stas, vea
Funcionamiento de las instantneas de la base de datos y Descripcin del tamao de los
archivos dispersos en instantneas de bases de datos.
Las instantneas 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 instantnea 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 caracterstica
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 estadsticas de tamao 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 asignacin y administracin. Hay dos tipos de grupos de archivos:
Principal
El grupo de archivos principal contiene el archivo de datos principal y los dems archivos
asignados especficamente a otro grupo de archivos. Todas las pginas de las tablas del
sistema estn 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 instruccin 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.
Ningn archivo puede pertenecer a ms de un grupo de archivos. Las tablas, los ndices y
los datos de objetos grandes se pueden asociar a un grupo de archivos especfico. En este
caso, todas sus pginas se asignarn 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 ms informacin 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 pginas se asignarn a partir del grupo de archivos predeterminado.
Slo un grupo de archivos puede ser el predeterminado en un momento dado. Los
miembros de la funcin fija db_owner de la base de datos pueden cambiar el grupo de
archivos predeterminado de un grupo a otro. Si no se especifica ningn 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 contrasea 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 instruccin ALTER DATABASE hace que el grupo de archivos definido
por el usuario sea el grupo predeterminado. A continuacin, 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 ilustracin resume los resultados del ejemplo anterior.




2.1.3 Requerimientos para instalacin.
2.1.4 Instalacin del software de BD en modo transaccional
2.1.5 Variables de Ambiente y archivos importantes para instalacin.
2.1.6 Procedimiento general de instalacin
2.1.7 Procedimiento para configuracin de un DBMS
2.1.8 Comandos generales de alta y baja del DBMS