3.1 - Estructuras lógicas de almacenamiento.
3.1.1 - Definición de espacio de almacenamiento.
Para la gestión del almacenamiento de una base de datos existen 4 conceptos bien definidos que deben
ser conocidos para poder comprender la forma en la que se almacenan los datos. Estos conceptos son:
bloque de datos, extensiones, segmentos y espacios de tablas.
Bloque de datos (Data blocks).- Se trata de la unidad más pequeña de almacenamiento en una base de
datos. Generalmente debe ser múltiple del tamaño de bloque del sistema operativo, ya que es la unidad
mínima que va a pedir la BD al sistema operativo. Si no fuera múltiple del bloque del sistema se añadiría un
trabajo extra ya que el sistema debería obtener más datos de los estrictamente necesarios. Generalmente
se especifica mediante el parámetro DB_BLOCK_SIZE.
Extensiones (Extents).- Se forma con uno o más bloques. Cuando se aumenta tamaño de un objeto en la
base de datos, se usa una extensión para incrementar el espacio.
Segmentos (Segments).- Grupo de extensiones que forman un objeto de la base de datos, como por
ejemplo una tabla o un índice.
El segmento de datos es una colección de extensiones que mantiene todos los datos para una tabla
o cluster.
El segmento de índices mantiene todos los datos para un índice.
El segmento de rollback mantiene datos para rollback, consistencia de lecturas o recuperación.
El segmento temporal es una colección de extensiones que mantiene datos pertenecientes a
objetos temporales.
Espacio de tablas (Tablespaces).- Formado por uno o más archivos de datos (datafiles) del SO, donde
cada datafile solo puede pertenecer a un determinado tablespace y una base de datos. Representan un
nivel medio entre la BD y los datafiles.
El SGBD tiene estructuras lógicas y físicas que el administrador ha de gestionar. Las estructuras físicas son
aquellas se pueden ver en el sistema operativo como son los archivos; mientras que las estructuras lógicas
sólo se pueden ver desde el manejador de base de datos, como son por ejemplo los tablespaces.
Los usuarios más avanzados tendrán conocimiento de la estructura lógica de la base de datos, y es
responsabilidad del DBA gestionar la correspondencia entre las estructuras lógicas y físicas para tener un
rendimiento óptimo.
3.1.2 - Definición y creación del espacio asignado para cada base de datos.
Una base de datos se divide en unidades lógicas denominadas TABLESPACES. Un tablespace no es un
archivo físico en el disco, simplemente es el nombre que tiene un conjunto de propiedades de
almacenamiento que se aplican a los objetos (tablas, secuencias…) que se van a crear en la base de datos
bajo el tablespace indicado (tablas, secuencias…). Un espacio de tablas puede pertenecer sólo a una BD.
Un objeto en la base de datos debe estar almacenado obligatoriamente dentro de un tablespace.
Cuando se crea una tabla se debe indicar el espacio de tablas (Tablespace) al que se destina. Por defecto
se depositan en el espacio de tablas SYSTEM.
Cuando se crea un nuevo Tablespace, la capacidad total del tablespace coincidirá con la suma de los
tamaños de los archivos de datos (datafiles) asociados.
Por ejemplo:
create tablespace app_data
datafile ‘/u03/oradata/ userdata01. dbf ’ size 100m,
datafile ‘/u03/oradata/ userdata02. dbf ’ size 250m;
En este caso se crea un tablespace app_data asociado a dos archivos con una capacidad total de 350M.
Si se quiere incrementar el tamaño de la base, se puede hacer incrementando el tamaño de un archivo de
datos (data files) de un Tablespace en particular.
Por ejemplo:
alter database datafile ‘/u03/oradata/ userdata02. dbf’ resize 200m;
Si no se tiene espacio libre en la partición del disco, entonces se puede agregar otro archivo de datos (data
files) sobre otra partición de disco para un Tablespace en particular.
Por ejemplo:
alter tablespace app_data add datafile ‘/u01/oradata/ userdata03. dbf’ size 200m;
3.1.3 - Bitácoras
Las bitácoras, son las estructuras de datos más ampliamente usada para grabar las modificaciones de la
base de datos.
Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo siguiente:
1. Nombre de la transacción: Nombre o número de la transacción que realizó la operación de escritura.
2. Nombre del dato: El nombre único del dato escrito.
3. Valor antiguo: El valor del dato antes de la escritura.
4. Valor nuevo: El valor que tendrá el dato después de la escritura.
Existen otros registros de bitácora especiales para grabar sucesos importantes durante el proceso de
transacción tal como:
< T1, inicio >
< T1, x, v1, v2 >
< T1, commit >
Es fundamental que siempre se cree un registro en la bitácora cuando se realice una escritura antes de que
se modifique la base de datos, ya que esto nos da la posibilidad de deshacer una modificación que ya se
ha escrito en la base de datos, esto se realizará usando el campo del valor antiguo de los registros de la
bitácora.
Los registros de la bitácora deben residir en memoria estable y como resultado, el volumen de datos en la
bitácora puede ser exageradamente grande.
Bitácora (Redo log files) en Oracle
Los archivos de redo log son las bitácoras que registran los cambios a la base de datos como resultado de
transacciones o acciones internas del servidor Oracle.
Los archivos de redo log protegen la base de datos de la pérdida de integridad en casos de fallas causadas
por suministro eléctrico, errores en discos duros, y otras causas.
Es recomendable que los archivos de redo log sean multiplexados para asegurar que la información
almacenada en ellos no se pierda en caso de un fallo en disco.
Consiste en grupos de archivos de redo log y cada grupo está integrado por un archivo de redo log y sus
copias multiplexadas. Se dice que cada copia idéntica es miembro de un grupo, y cada grupo es
identificado por un número.
El proceso de escritura en logs (LGWR) escribe los registros de redo del buffer de redo log a todos los
miembros del grupo actual de redo logs, hasta que el archivo se llena o se solicita una operación de cambio
de archivo de log. Entonces, cambia el grupo activo y comienza a escribir en los archivos del siguiente
grupo.
Cuando Oracle se ejecuta en modo ARCHIVELOG el proceso en segundo plano llamado ARCH hace una
copia de cada archivo de redo log online una vez que el proceso LGWR termina de escribir en él, guarda
dicha copia en los archivos de reconstrucción fuera de línea (redo log offline) en disco
3.1.4 - Particiones
Una partición es una división de una base de datos lógica o sus elementos constituyentes en partes
independientes.
La creación de particiones en una base de datos mejora el rendimiento y simplifica el mantenimiento. Al
dividir una tabla grande en tablas individuales más pequeñas, las consultas que tengan acceso únicamente
a una parte de los datos pueden ejecutarse con mayor rapidez, ya que deben recorrer menos datos. Las
tareas de mantenimiento (por ejemplo, volver a generar los índices o hacer copias de seguridad de una
tabla), pueden ejecutarse con mayor rapidez.
Una aplicación popular y favorable es en un Sistema de Administración de Base de Datos Distribuida. Cada
partición puede ser extendida hasta múltiples nodos, y los usuarios en el nodo pueden hacer transacciones
locales en la partición. Esto aumenta el rendimiento en sitios que tienen transacciones regularmente
involucrando ciertas vistas de datos, y manteniendo la disponibilidad y la seguridad.
Esta partición puede hacerse creando bases de datos más pequeñas separadas (cada una con sus propias
tablas, índices, y registros de transacciones) o dividiendo elementos seleccionados, por ejemplo, solo una
tabla.
Particiones horizontales
La creación de particiones horizontales divide una tabla en varias tablas. Así, cada tabla contiene el mismo
número de columnas, pero menos filas. Por ejemplo, se podría crear una partición horizontal de una tabla
que contenga mil millones de filas en 12 tablas; cada una de las tablas más pequeñas representaría un
mes de datos de un año específico. Las consultas que requieran datos de un mes específico sólo hacen
referencia a la tabla apropiada.
La determinación del modo de crear particiones horizontales de las tablas depende de cómo se analicen los
datos. Debería crear particiones de tablas de forma que las consultas hagan referencia al menor número
posible de tablas. De lo contrario, un número excesivo de consultas UNION, utilizadas para mezclar las
tablas de forma lógica en el momento de la consulta, podría afectar al rendimiento.
Particiones verticales
La creación de particiones verticales divide una tabla en varias tablas que contienen menos columnas. Los
dos tipos de particiones verticales son la normalización y la división de filas:
La normalización es el proceso estándar de bases de datos que consiste en quitar columnas
redundantes de una tabla y colocarlas en tablas secundarias vinculadas a la tabla principal
mediante relaciones de clave principal y clave externa.
La división de filas divide verticalmente la tabla original en tablas con menos columnas. Cada fila
lógica de una tabla dividida coincide con la misma fila lógica en las demás tablas, según se
identifica en la columna UNIQUE KEY que es idéntica en todas las tablas con particiones. Por
ejemplo, al combinar la fila con el Id. 712 de cada tabla dividida se vuelve a crear la fila original.
Igual que las particiones horizontales, las particiones verticales permiten a las consultas recorrer menos
datos. De ese modo se aumenta el rendimiento de las consultas. Por ejemplo, una tabla que contenga siete
columnas de las cuales generalmente sólo se hace referencia a las cuatro primeras, puede beneficiarse de
la división de las tres últimas columnas en una tabla independiente.
La creación de particiones verticales se debe considerar detenidamente, ya que analizar datos de varias
particiones requiere consultas que combinen las tablas. La partición vertical también puede afectar al rendimiento si las particiones son muy grandes.
3.1.5 Espacios privados
PRIVATE_SGA – Define la cantidad de espacio privado que una sesión puede reservar en la zona de SQL
compartido de la SGA.
3.1.6 Espacios para objetos
3.2 - Segmentos
Un segmento (segment) es aquel espacio reservado por la base de datos, dentro de un archivo de datos
(datafile), para ser utilizado por un solo objeto. Así una tabla (o cualquier otro objeto) está dentro de su
segmento, y nunca podrá salir de él, ya que si la tabla crece, el segmento también crece con ella.
Físicamente, todo objeto en base de datos no es más que un segmento (segmento, trozo, sección) dentro
de un archivo de datos (datafile). Se puede decir que, un segmento es a un objeto de base de datos, lo que
un datafile a un tablespace: el segmento es la representación física del objeto en base de datos (el objeto
no es más que una definición lógica).
Existen cuatro tipos de segmentos (principalmente):
Segmentos de TABLE: aquellos que contienen tablas.
Segmentos de INDEX: aquellos que contienen índices.
Segmentos de ROLLBACK: aquellos se usan para almacenar información de la transacción activa.
Segmentos TEMPORALES: aquellos que se usan para realizar operaciones temporales que no
pueden realizarse en memoria, tales como ordenaciones o agrupaciones de conjuntos grandes de
datos.
Calcular el tamaño de un segmento en Oracle
select segment_name , sum(bytes)/(1024*1024) SegmentSize
from user_extents
where segment_'TABLE' and segment_name = 'MYTABLE'
TABLE = Tipo de segmento: "table," "index" o "cluster
MYTABLE = nombre de la tabla
3.3 - Memoria Compartida.
Cuando de habla de la estructura de memoria, se tienen dos tipos: Una de ellas es compartida por todos
los usuarios conectados y la otra es dedicada al trabajo de cada uno de ellos.
SGA (Area Global del Sistema):
Esta es la estructura de memoria que es compartida por todos los usuarios y se dividen en:
Shared pool (Fondo Común Compartido): almacena parte del diccionario de datos y las sentencias
SQL que han sido analizadas.
DataBase Buffer Cache (Área de memoria Rápida): almacena los bloques de datos leídos resultado
de las órdenes SQL ejecutadas por los usuarios conectados.
RedoLogs (Área de registro rehacer): se registran los cambios hechos a la base de datos.
PGA (Program global área):
Es un área de memoria utilizada por los procesos del DBMS. Esta zona de memoria no se puede compartir
y se divide en:
Procesos de usuarios.- Cuando un usuario se conecta a la base de datos se crea un proceso de
usuario, Los procesos de usuarios no interactúan directamente con la base de datos, lo hace a
través de los procesos del servidor.
Procesos del servidor.- Ejecutan las peticiones de los usuarios y devuelven los resultados. Un
proceso del servidor ejecuta las peticiones de un solo proceso de usuario.
Procesos de fondo (background).- Son creados por cada instancia de la BD y se encarga de las
entradas/ salidas del SGA, existen los procesos que son obligatorios, los cuales son:
o Obligatorios (DBWR, LGWR, SMON, PMON, CKPT)
o Opcionales (ARCH, LMON, LCKn, etc)
Para visualizar todos los procesos en segundo plano, puede consultarse la vista v$bgprocess
3.4 - Instancias múltiples
Cada servidor de bases de datos está compuesto por:
Una Base de Datos: donde se almacenan los datos físicos (archivos de datos y otros componentes).
Una instancia: constituye el mecanismo que permite su manipulación.
Una instancia de Base de datos es el conjunto formado por los procesos y las estructuras de memoria
que se encuentran en un servidor.
Puede haber múltiples instancias para una única base de datos o múltiples bases de datos en una misma
instancia.
Instancias en SQL Server
Una instancia de Motor de base de datos es una copia del ejecutable de sqlservr.exe que se ejecuta como
un servicio de sistema operativo. Cada instancia administra varias bases de datos del sistema y una o
varias bases de datos de usuario. Cada equipo puede ejecutar varias instancias de Motor de base de
datos. Las aplicaciones se conectan a la instancia para realizar el trabajo en una base de datos
administrada por la instancia.
Cada Base de Datos mantiene sus propios archivos de datos (dónde se almacenan las tablas, índices,
vistas, procedimientos almacenados, y resto de objetos de base de datos), archivos de LOG (dónde se
almacenan las transacciones de dicha base de datos), configuración (Modo de Recuperación o Modo de
Registro, intercalación, nivel de compatibilidad, etc.). Por el contrario, todas las bases de datos de una
instancia en particular, comparten la base de datos TEMPDB (dónde se almacenan los objetos temporales,
resultados intermedios de consultas, etc.) y otros recursos de la Instancia, como la memoria, la afinidad de
CPU, y la afinidad de entrada/salida (E/S).
Instancia de una Base de Datos en Oracle
Cada instancia Oracle está asociada a una base de datos. Cuando se inicia una base de datos en un
servidor, se le asigna un área de memoria (SGA) y lanza uno o más procesos. A la combinación del SGA y
de los procesos es lo que se llama instancia. La memoria y los procesos de una instancia gestionan las
datos de la base de datos asociada de forma eficiente y sirven a uno o varios usuarios.
3.1.1 - Definición de espacio de almacenamiento.
Para la gestión del almacenamiento de una base de datos existen 4 conceptos bien definidos que deben
ser conocidos para poder comprender la forma en la que se almacenan los datos. Estos conceptos son:
bloque de datos, extensiones, segmentos y espacios de tablas.
Bloque de datos (Data blocks).- Se trata de la unidad más pequeña de almacenamiento en una base de
datos. Generalmente debe ser múltiple del tamaño de bloque del sistema operativo, ya que es la unidad
mínima que va a pedir la BD al sistema operativo. Si no fuera múltiple del bloque del sistema se añadiría un
trabajo extra ya que el sistema debería obtener más datos de los estrictamente necesarios. Generalmente
se especifica mediante el parámetro DB_BLOCK_SIZE.
Extensiones (Extents).- Se forma con uno o más bloques. Cuando se aumenta tamaño de un objeto en la
base de datos, se usa una extensión para incrementar el espacio.
Segmentos (Segments).- Grupo de extensiones que forman un objeto de la base de datos, como por
ejemplo una tabla o un índice.
El segmento de datos es una colección de extensiones que mantiene todos los datos para una tabla
o cluster.
El segmento de índices mantiene todos los datos para un índice.
El segmento de rollback mantiene datos para rollback, consistencia de lecturas o recuperación.
El segmento temporal es una colección de extensiones que mantiene datos pertenecientes a
objetos temporales.
Espacio de tablas (Tablespaces).- Formado por uno o más archivos de datos (datafiles) del SO, donde
cada datafile solo puede pertenecer a un determinado tablespace y una base de datos. Representan un
nivel medio entre la BD y los datafiles.
El SGBD tiene estructuras lógicas y físicas que el administrador ha de gestionar. Las estructuras físicas son
aquellas se pueden ver en el sistema operativo como son los archivos; mientras que las estructuras lógicas
sólo se pueden ver desde el manejador de base de datos, como son por ejemplo los tablespaces.
Los usuarios más avanzados tendrán conocimiento de la estructura lógica de la base de datos, y es
responsabilidad del DBA gestionar la correspondencia entre las estructuras lógicas y físicas para tener un
rendimiento óptimo.
3.1.2 - Definición y creación del espacio asignado para cada base de datos.
Una base de datos se divide en unidades lógicas denominadas TABLESPACES. Un tablespace no es un
archivo físico en el disco, simplemente es el nombre que tiene un conjunto de propiedades de
almacenamiento que se aplican a los objetos (tablas, secuencias…) que se van a crear en la base de datos
bajo el tablespace indicado (tablas, secuencias…). Un espacio de tablas puede pertenecer sólo a una BD.
Un objeto en la base de datos debe estar almacenado obligatoriamente dentro de un tablespace.
Cuando se crea una tabla se debe indicar el espacio de tablas (Tablespace) al que se destina. Por defecto
se depositan en el espacio de tablas SYSTEM.
Cuando se crea un nuevo Tablespace, la capacidad total del tablespace coincidirá con la suma de los
tamaños de los archivos de datos (datafiles) asociados.
Por ejemplo:
create tablespace app_data
datafile ‘/u03/oradata/ userdata01. dbf ’ size 100m,
datafile ‘/u03/oradata/ userdata02. dbf ’ size 250m;
En este caso se crea un tablespace app_data asociado a dos archivos con una capacidad total de 350M.
Si se quiere incrementar el tamaño de la base, se puede hacer incrementando el tamaño de un archivo de
datos (data files) de un Tablespace en particular.
Por ejemplo:
alter database datafile ‘/u03/oradata/ userdata02. dbf’ resize 200m;
Si no se tiene espacio libre en la partición del disco, entonces se puede agregar otro archivo de datos (data
files) sobre otra partición de disco para un Tablespace en particular.
Por ejemplo:
alter tablespace app_data add datafile ‘/u01/oradata/ userdata03. dbf’ size 200m;
3.1.3 - Bitácoras
Las bitácoras, son las estructuras de datos más ampliamente usada para grabar las modificaciones de la
base de datos.
Cada registro de la bitácora escribe una única escritura de base de datos y tiene lo siguiente:
1. Nombre de la transacción: Nombre o número de la transacción que realizó la operación de escritura.
2. Nombre del dato: El nombre único del dato escrito.
3. Valor antiguo: El valor del dato antes de la escritura.
4. Valor nuevo: El valor que tendrá el dato después de la escritura.
Existen otros registros de bitácora especiales para grabar sucesos importantes durante el proceso de
transacción tal como:
< T1, inicio >
< T1, x, v1, v2 >
< T1, commit >
Es fundamental que siempre se cree un registro en la bitácora cuando se realice una escritura antes de que
se modifique la base de datos, ya que esto nos da la posibilidad de deshacer una modificación que ya se
ha escrito en la base de datos, esto se realizará usando el campo del valor antiguo de los registros de la
bitácora.
Los registros de la bitácora deben residir en memoria estable y como resultado, el volumen de datos en la
bitácora puede ser exageradamente grande.
Bitácora (Redo log files) en Oracle
Los archivos de redo log son las bitácoras que registran los cambios a la base de datos como resultado de
transacciones o acciones internas del servidor Oracle.
Los archivos de redo log protegen la base de datos de la pérdida de integridad en casos de fallas causadas
por suministro eléctrico, errores en discos duros, y otras causas.
Es recomendable que los archivos de redo log sean multiplexados para asegurar que la información
almacenada en ellos no se pierda en caso de un fallo en disco.
Consiste en grupos de archivos de redo log y cada grupo está integrado por un archivo de redo log y sus
copias multiplexadas. Se dice que cada copia idéntica es miembro de un grupo, y cada grupo es
identificado por un número.
El proceso de escritura en logs (LGWR) escribe los registros de redo del buffer de redo log a todos los
miembros del grupo actual de redo logs, hasta que el archivo se llena o se solicita una operación de cambio
de archivo de log. Entonces, cambia el grupo activo y comienza a escribir en los archivos del siguiente
grupo.
Cuando Oracle se ejecuta en modo ARCHIVELOG el proceso en segundo plano llamado ARCH hace una
copia de cada archivo de redo log online una vez que el proceso LGWR termina de escribir en él, guarda
dicha copia en los archivos de reconstrucción fuera de línea (redo log offline) en disco
3.1.4 - Particiones
Una partición es una división de una base de datos lógica o sus elementos constituyentes en partes
independientes.
La creación de particiones en una base de datos mejora el rendimiento y simplifica el mantenimiento. Al
dividir una tabla grande en tablas individuales más pequeñas, las consultas que tengan acceso únicamente
a una parte de los datos pueden ejecutarse con mayor rapidez, ya que deben recorrer menos datos. Las
tareas de mantenimiento (por ejemplo, volver a generar los índices o hacer copias de seguridad de una
tabla), pueden ejecutarse con mayor rapidez.
Una aplicación popular y favorable es en un Sistema de Administración de Base de Datos Distribuida. Cada
partición puede ser extendida hasta múltiples nodos, y los usuarios en el nodo pueden hacer transacciones
locales en la partición. Esto aumenta el rendimiento en sitios que tienen transacciones regularmente
involucrando ciertas vistas de datos, y manteniendo la disponibilidad y la seguridad.
Esta partición puede hacerse creando bases de datos más pequeñas separadas (cada una con sus propias
tablas, índices, y registros de transacciones) o dividiendo elementos seleccionados, por ejemplo, solo una
tabla.
Particiones horizontales
La creación de particiones horizontales divide una tabla en varias tablas. Así, cada tabla contiene el mismo
número de columnas, pero menos filas. Por ejemplo, se podría crear una partición horizontal de una tabla
que contenga mil millones de filas en 12 tablas; cada una de las tablas más pequeñas representaría un
mes de datos de un año específico. Las consultas que requieran datos de un mes específico sólo hacen
referencia a la tabla apropiada.
La determinación del modo de crear particiones horizontales de las tablas depende de cómo se analicen los
datos. Debería crear particiones de tablas de forma que las consultas hagan referencia al menor número
posible de tablas. De lo contrario, un número excesivo de consultas UNION, utilizadas para mezclar las
tablas de forma lógica en el momento de la consulta, podría afectar al rendimiento.
Particiones verticales
La creación de particiones verticales divide una tabla en varias tablas que contienen menos columnas. Los
dos tipos de particiones verticales son la normalización y la división de filas:
La normalización es el proceso estándar de bases de datos que consiste en quitar columnas
redundantes de una tabla y colocarlas en tablas secundarias vinculadas a la tabla principal
mediante relaciones de clave principal y clave externa.
La división de filas divide verticalmente la tabla original en tablas con menos columnas. Cada fila
lógica de una tabla dividida coincide con la misma fila lógica en las demás tablas, según se
identifica en la columna UNIQUE KEY que es idéntica en todas las tablas con particiones. Por
ejemplo, al combinar la fila con el Id. 712 de cada tabla dividida se vuelve a crear la fila original.
Igual que las particiones horizontales, las particiones verticales permiten a las consultas recorrer menos
datos. De ese modo se aumenta el rendimiento de las consultas. Por ejemplo, una tabla que contenga siete
columnas de las cuales generalmente sólo se hace referencia a las cuatro primeras, puede beneficiarse de
la división de las tres últimas columnas en una tabla independiente.
La creación de particiones verticales se debe considerar detenidamente, ya que analizar datos de varias
particiones requiere consultas que combinen las tablas. La partición vertical también puede afectar al rendimiento si las particiones son muy grandes.
3.1.5 Espacios privados
PRIVATE_SGA – Define la cantidad de espacio privado que una sesión puede reservar en la zona de SQL
compartido de la SGA.
3.1.6 Espacios para objetos
3.2 - Segmentos
Un segmento (segment) es aquel espacio reservado por la base de datos, dentro de un archivo de datos
(datafile), para ser utilizado por un solo objeto. Así una tabla (o cualquier otro objeto) está dentro de su
segmento, y nunca podrá salir de él, ya que si la tabla crece, el segmento también crece con ella.
Físicamente, todo objeto en base de datos no es más que un segmento (segmento, trozo, sección) dentro
de un archivo de datos (datafile). Se puede decir que, un segmento es a un objeto de base de datos, lo que
un datafile a un tablespace: el segmento es la representación física del objeto en base de datos (el objeto
no es más que una definición lógica).
Existen cuatro tipos de segmentos (principalmente):
Segmentos de TABLE: aquellos que contienen tablas.
Segmentos de INDEX: aquellos que contienen índices.
Segmentos de ROLLBACK: aquellos se usan para almacenar información de la transacción activa.
Segmentos TEMPORALES: aquellos que se usan para realizar operaciones temporales que no
pueden realizarse en memoria, tales como ordenaciones o agrupaciones de conjuntos grandes de
datos.
Calcular el tamaño de un segmento en Oracle
select segment_name , sum(bytes)/(1024*1024) SegmentSize
from user_extents
where segment_'TABLE' and segment_name = 'MYTABLE'
TABLE = Tipo de segmento: "table," "index" o "cluster
MYTABLE = nombre de la tabla
3.3 - Memoria Compartida.
Cuando de habla de la estructura de memoria, se tienen dos tipos: Una de ellas es compartida por todos
los usuarios conectados y la otra es dedicada al trabajo de cada uno de ellos.
SGA (Area Global del Sistema):
Esta es la estructura de memoria que es compartida por todos los usuarios y se dividen en:
Shared pool (Fondo Común Compartido): almacena parte del diccionario de datos y las sentencias
SQL que han sido analizadas.
DataBase Buffer Cache (Área de memoria Rápida): almacena los bloques de datos leídos resultado
de las órdenes SQL ejecutadas por los usuarios conectados.
RedoLogs (Área de registro rehacer): se registran los cambios hechos a la base de datos.
PGA (Program global área):
Es un área de memoria utilizada por los procesos del DBMS. Esta zona de memoria no se puede compartir
y se divide en:
Procesos de usuarios.- Cuando un usuario se conecta a la base de datos se crea un proceso de
usuario, Los procesos de usuarios no interactúan directamente con la base de datos, lo hace a
través de los procesos del servidor.
Procesos del servidor.- Ejecutan las peticiones de los usuarios y devuelven los resultados. Un
proceso del servidor ejecuta las peticiones de un solo proceso de usuario.
Procesos de fondo (background).- Son creados por cada instancia de la BD y se encarga de las
entradas/ salidas del SGA, existen los procesos que son obligatorios, los cuales son:
o Obligatorios (DBWR, LGWR, SMON, PMON, CKPT)
o Opcionales (ARCH, LMON, LCKn, etc)
Para visualizar todos los procesos en segundo plano, puede consultarse la vista v$bgprocess
3.4 - Instancias múltiples
Cada servidor de bases de datos está compuesto por:
Una Base de Datos: donde se almacenan los datos físicos (archivos de datos y otros componentes).
Una instancia: constituye el mecanismo que permite su manipulación.
Una instancia de Base de datos es el conjunto formado por los procesos y las estructuras de memoria
que se encuentran en un servidor.
Puede haber múltiples instancias para una única base de datos o múltiples bases de datos en una misma
instancia.
Instancias en SQL Server
Una instancia de Motor de base de datos es una copia del ejecutable de sqlservr.exe que se ejecuta como
un servicio de sistema operativo. Cada instancia administra varias bases de datos del sistema y una o
varias bases de datos de usuario. Cada equipo puede ejecutar varias instancias de Motor de base de
datos. Las aplicaciones se conectan a la instancia para realizar el trabajo en una base de datos
administrada por la instancia.
Cada Base de Datos mantiene sus propios archivos de datos (dónde se almacenan las tablas, índices,
vistas, procedimientos almacenados, y resto de objetos de base de datos), archivos de LOG (dónde se
almacenan las transacciones de dicha base de datos), configuración (Modo de Recuperación o Modo de
Registro, intercalación, nivel de compatibilidad, etc.). Por el contrario, todas las bases de datos de una
instancia en particular, comparten la base de datos TEMPDB (dónde se almacenan los objetos temporales,
resultados intermedios de consultas, etc.) y otros recursos de la Instancia, como la memoria, la afinidad de
CPU, y la afinidad de entrada/salida (E/S).
Instancia de una Base de Datos en Oracle
Cada instancia Oracle está asociada a una base de datos. Cuando se inicia una base de datos en un
servidor, se le asigna un área de memoria (SGA) y lanza uno o más procesos. A la combinación del SGA y
de los procesos es lo que se llama instancia. La memoria y los procesos de una instancia gestionan las
datos de la base de datos asociada de forma eficiente y sirven a uno o varios usuarios.