Conceptos de Almacenamiento en Oracle
Concepto de Tablespace (espacio de tablas)
Una
base de datos se divide en unidades lógicas denominadas TABLESPACES. Un
tablespace no es un fichero 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 objeto en base de datos debe estar almacenado obligatoriamente dentro de un tablespace.
Las propiedades que se asocian a un tablespace son:
- Localización de los ficheros de datos.
- Especificación de máximas cuotas de consumo de disco.
- Control de la disponibilidad de los datos (en línea o fuera de línea).
- Backup de datos.
En
este esquema podemos ver que, por ejemplo, la tabla ARTICULO se
almacena dentro del tablespace A, y que por lo tanto tendrá todas las
propiedades del tablespace A que pueden ser:
- Sus ficheros de datos están en $ORACLE_HOME/datos/datos_tablespace_A
- Los objetos no pueden ocupar más de 10Mb de espacio de base de datos.
- En cualquier momento se puede poner fuera de línea todos los objeto de un cierto tablespace. -Se pueden hacer copiar de seguridad sólo de ciertos tablespaces.
Si
nos fijamos, se puede apreciar que es posible tener una tabla en un
tablespace, y los índices de esa tabla en otro. Esto es debido a que los
índices no son más que objetos independientes dentro de la base de
datos, como lo son las tablas. Y al ser objetos independientes, pueden
ir en tablespaces independientes. El tablespace SYSTEM es uno de los que
se crear por defecto en todas las bases de datos Oracle. En él se
almacenan todos los datos de sistema, el catálogo y todo el código
fuente y compilado de procedimientos PL/SQL. También es posible utilizar
el mismo tablespace para guardar datos de usuario. En el esquema
también vemos que hay un tablespace Temporal (en gris oscuro). Este
representa las propiedades que tendrán los objetos que la base de datos
cree temporalmente para sus cálculos internos (normalmente para
ordenaciones y agrupaciones). Su creación difiere en una de sus
cláusulas de creación. El tablespace RO (en gris claro) difiere de los
demás en que es de solo lectura (Read Only), y que por lo tanto todos
los objetos en él contenidos pueden recibir órdenes de consulta de
datos, pero no de modificación de datos. Estos puede residir en soportes
de sólo lectura, como pueden ser CDROMs, DVDs, etc. Cuando se crea un
tablespace, éste se crea de lectura/escritura. Después se puede
modificar para que sea de solo lectura. Un tablespace puede estar en
línea o fuera de ella (Online o OffLine), esto es que todos los objetos
contenidos en él están a disposición de los usuarios o están
inhabilitados para restringir su uso. Cualquier objeto almacenado dentro
de un tablespace no podrá ser accedido si este está fuera de línea.
Concepto de Datafile (fichero de datos)
Un datafile es
la representación física de un tablespace. Son los "ficheros de datos"
donde se almacena la información físicamente. Un datafile puede tener
cualquier nombre y extensión (siempre dentro de las limitaciones del
sistema operativo), y puede estar localizado en cualquier directorio del
disco duro, aunque su localización típica suele ser
$ORACLE_HOME/Database. Un datafile tiene un tamaño predefinido en
su creación (por ejemplo 100Mb) y este puede ser alterado en cualquier
momento. Cuando creemos un datafile, este ocupará tanto espacio
en disco como hayamos indicado en su creación, aunque internamente esté
vacío. Oracle hace esto para reservar espacio continuo en disco y evitar
así la fragmentación. Conforme se vayan creando objetos en ese
tablespace, se irá ocupando el espacio que creó inicialmente.
Un datafile está
asociado a un solo tablespace y, a su vez, un tablespace está asociado a
uno o varios datafiles. Es decir, la relación lógica entre tablespaces y
datafiles es de 1-N, maestro-detalle.
En
el esquema podemos ver como el “Tablespace A” está compuesto
(físicamente) por tres datafiles (DATOS_1.ORA, DATOS_2.ORA y
DATOS_3.ORA). Estos tres datafiles son los ficheros físicos que
soportan los objetos contenidos dentro del tablespace A. Aunque siempre
se dice que los objetos están dentro del tablespace, en realidad las
tablas están dentro del datafile, pero tienen la propiedades asociadas al tablespace.
Cada uno de los datafiles utilizados
está ocupando su tamaño en disco (50 Mb los dos primeros y 25 Mb el
último) aunque en realidad sólo contengan dos objetos y estos objetos no
llenen el espacio que está asignado para los datafiles.
Los datafiles tienen una propiedad llamada AUTOEXTEND, que se si está activa, se encarga de que el datafile crezca
automáticamente (según un tamaño indicado) cada vez que se necesite
espacio y no exista. Al igual que los tablespaces, los datafiles también
puede estar en línea o fuera de ella.
Concepto de Segment (segmento, trozo, sección)
Un segment es aquel espacio reservado por la base de datos, dentro de un 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 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).
Podemos ver cómo el espacio que realmente se ocupa dentro del datafile es el segment y que cada segmento pertenece a un objeto.
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.
Concepto de Extent (extensión)
Para
cualquier objeto de base de datos que tenga cierta ocupación en disco,
es decir, cualquier objeto que tenga un segment relacionado, existe el
concepto de extent. Extent es un espacio de disco que se reserva
de una sola vez, un segmento que se reserva en un momento determinado de
tiempo. El concepto de extent es un concepto físico, unos están
separados de otros dentro del disco. Ya dijimos que todo objeto tiene su
segmento asociado, pero lo que no dijimos es que este segmento, a su
vez, se compone de distintas extensiones. Un segmento, puede ser
reservado de una sola vez (10 Mb de golpe), o de varias veces (5 Mb hoy y
5 Mb mañana). Cada una de las veces que se reserva espacio se denomina
“extensión”.
En el
esquema vemos como el objeto (tabla) FACTURA tiene un segmento en el
datafile A-1, y este segmento está compuesto de 3 extensiones. Una de
estas extensiones tiene un color distinto. Esto es porque existen dos
tipos de extensiones:
- INITIAL (extensiones iniciales): estas son las extensiones que se reservan durante la creación del objeto. Una vez que un objeto está creado, no se puede modificar su extensión inicial.
- NEXT (siguientes o subsiguientes extensiones): toda extensión reservada después de la creación del objeto. Si el INITIAL EXTENT de una tabla está llena y se está intentando insertar más filas, se intentará crear un NEXT EXTENT (siempre y cuando el datafile tenga espacio libre y tengamos cuota de ocupación suficiente).
Sabiendo
que las extensiones se crean en momentos distintos de tiempo, es lógico
pensar que unas extensiones pueden estar fragmentadas de otras. Un
objeto de base de datos no reside todo junto dentro del bloque, sino que
residirá en tantos bloque como extensiones tenga. Por eso es crítico
definir un buen tamaño de extensión inicial, ya que, si es lo
suficientemente grande, el objeto nunca estará fragmentado.
Si
el objeto tiene muchas extensiones y éstas están muy separadas en
disco, las consultas pueden retardarse considerablemente, ya que las
cabezas lectoras tienes que dar saltos constantemente.
El
tamaño de las extensiones (tanto las INITIAL como las NEXT), se definen
durante la creación del objeto y no puede ser modificado después de la
creación. Oracle recomienda que el tamaño del INITIAL EXTENT sea igual
al tamaño del NEXT EXTENT.
La
mejor solución es calcular el tamaño que tendrá el objeto (tabla o
índice), multiplicando el tamaño de cada fila por una estimación del
número de filas. Cuando hemos hecho este cálculo, debemos utilizar este
tamaño como extensión INITIAL y NEXT, y tendremos prácticamente la
certeza de que no se va a producir fragmentación en ese objeto. En caso
de detectar más de 10 extensiones en un objeto (consultando el catálogo
de Oracle, como veremos), debemos recrear el objeto desde cero
(aplicando el cálculo anterior) e importar de nuevo los datos.
Ciertas
operaciones, necesitan de espacio en disco para poder realizarse. El
espacio reservado se denomina “segmentos temporales”. Se pueden crear
segmentos temporales cuando:
- Se crea un índice
- Se utiliza ORDER BY, DISTINTC o GROUP BY en un SELECT.
- Se utilizan los operadores UNION, INTERSECT o MINUS.
- Se utilizan joins entre tablas.
- Se utilizan subconsultas.
Concepto de Data block (bloque de datos)
Un data block es el último eslabón dentro de la cadena de almacenamiento. El concepto de Data block es
un concepto físico, ya que representa la mínima unidad de
almacenamiento que es capaz de manejar Oracle. Igual que la mínima
unidad de almacenamiento de un disco duro es la unidad de asignación, la
mínima unidad de almacenamiento de Oracle es el data block. En
un disco duro no es posible que un fichero pequeño ocupe menos de lo que
indique la unidad de asignación, así si la unidad de asignación es de 4
Kb, un fichero que ocupe 1 Kb, en realidad ocupa 4 Kb.
Siguiendo
con la cadena, cada segmento (o cada extensión) se almacena en uno o
varios bloques de datos, dependiendo del tamaño definido para el
extensión, y del tamaño definido para el data block.
(*)
Espacio ocupado en el data block por la primera NEXT EXTENSION. (#)
Espacio ocupado en unidades de asignación del sistema operativo por los data blocks anteriores.
El esquema muestra toda la cadena de almacenamiento de Oracle.
Desde el nivel más físico al más lógico:
- Unidades de asignación del sistema operativo (El más físico. No depende de Oracle)
- Data blocks de Oracle
- Extents
- Segments
- DataFiles
- Tablespaces (El más lógico)
El
tamaño de las unidades de asignación del sistema operativo se define
durante el particionado del disco duro (FDISK, FIPS…), y el espacio de
los data blocks de Oracle se define durante la instalación y no puede ser cambiado.
Como es lógico, el tamaño de un data block tiene que ser múltiplo del tamaño de una unidad de asignación, es decir, si cada unidad de asignación ocupa 4 K, los data blocks pueden ser de 4K, 8K, 12K… para que en el sistema operativo ocupen 1, 2, 3… unidades de asignación.
Esquema extraído del Oracle8 Concepts
Estructuras de memoria
Todas las estructura
que hemos visto se refieren a cómo se almacenan los datos en el disco.
Sin embargo, y como es lógico, Oracle también utiliza la memoria del
servidor para su funcionamiento. Oracle utiliza dos tipos de memoria
- Memoria local y privada para cada uno de los procesos: PGA (Process Global Area o Program Global Area).
- Memoria común y compartida por todos los procesos SGA (System Global Area o Shared Global Area).
Cada vez que se conecta un cliente al servidor, se ejecuta un subproceso que atenderá sus peticiones (a través del fork en
Unix o con CreateThread en el mundo Windows), y este subproceso creará
un nuevo bloque de memoria de tipo PGA. El tamaño de este bloque de
memoria dependerá del sistema operativo, y permanece invariable, aunque
se puede configurar cambiando el valor de la variable SORT_AREA_SIZE del
archivo de inicialización INIT.ORA.
Por cada instancia de
base de datos, tendremos una zona de memoria global, el SGA, donde se
almacenan aquellos datos y estructuras que deben se compartidos entre
distintos procesos de la base de datos, como los procesos propios de
Oracle y cada uno de los subprocesos que gestionan la conexión. El
tamaño del SGA es uno de los puntos más críticos a la hora de mejorar el
rendimiento de una base de datos, ya que, cuanto mayor memoria se
reserve (mientras no sea memoria virtual), más rápidas se realizarán
ciertas operaciones. Por ejemplo, las ordenaciones (una de las
operaciones que más rápido deben hacerse) se realizan en el SGA si hay
espacio suficiente. En caso contrario, se realizarán directamente en el
disco, utilizando segmentos temporales.
El SGA se divide en cuatro grandes zonas:
- Database buffer cache: almacena los bloques que se han leído de los datafiles. Cada vez que es necesario acceder a un bloque, se busca el bloque en esta zona, y en caso de no existir, se lee de nuevo del datafile correspondiente. Cuantos más bloques quepan en esta zona de memoria, mejor será el rendimiento.
- SQL Area: es la zona de memoria se almacenan compiladas las últimas sentencias SQL (y bloques PL/SQL) ejecutadas. Además se almacenan las variables acopladas (bind), el árbol de parsing, los buffer de ejecución y el plan de ejecución. Es importante que siempre que se utilice la misma sentencia, sea exactamente igual, para poder aprovechar sentencias previas almacenadas en el SQL Area. Es decir, las siguientes sentencias:
“SELECT * FROM TABLA”
“select * from tabla” “SELECT * FROM TABLA” “SELECT * FROM tabla”
Se consideran distintas
y no se aprovecha el SQL Area. Debe coincidir el texto exactamente,
considerando mayúsculas y minúsculas, espacios, retornos de carro,
nombre de parámetros, etc. Esto es debido a que se buscan dentro del SQL
Area utilizando un hash de la sentencia, y un simple espacio (o cambiar
una letra a mayúsculas) hace que el hash resultante sea distinto, por
lo que no encontrará la sentencia dentro del SQL Area. Cuanto mayor sea
el espacio del SQL Area, se realizarán menos compilaciones, planes de
ejecución y análisis léxicos, por lo que la ejecución de las consultas
será más rápida.
- Redo cache: almacena los registros de redo de las últimas operaciones realizadas. Estos registros se almacenan en los archivos de redo, que sirven para recomponer la base de datos en caso de error.
- Dictionary cache: almacena datos del diccionario de Oracle, para utilizarlos en los planes de ejecución, optimización de consultas, etc. Cuantos más datos quepan en esta zona, mayor probabilidad habrá de que el dato que necesitamos ya esté en memoria, y no sea necesario acceder a las tablas del diccionario para leerlo.
Archivos de inicialización
Además de estructuras
de disco y de memoria, un servidor Oracle necesita ciertos archivos para
poder ejecutarse. Estos archivos se establecen durante la creación de
la base de datos, y se consultarán cada vez que se arranque la base de
datos, por lo que deben estar disponibles. Básicamente podemos
diferencias los tipos de archivos:
- Control files: son archivos de control que se consultan cada vez que se arranca la base de datos. Indica datos como la localización de los datafiles, nombre de la base de datos.
- Init file: es el archivo que contiene los parámetro de inicio de la base de datos (tamaño del bloque, tamaño del SGA, etc.). Normalmente tiene el nombre INIT.ORA
- Redo logs: estos archivos contienen un historial de todas las instrucciones que han sido lanzadas a la base de datos, para poder recuperarla en caso de fallo. No se utilizan durante la inicialización, sino durante toda la ejecución de la base de datos.
Best language to learn.
ResponderEliminarEste comentario ha sido eliminado por el autor.
ResponderEliminargracias
ResponderEliminar