M2 - Bases de dades / Continguts UF3: Emmagatzemament

De wikiserver
La revisió el 18:05, 4 feb 2018 per Rsort (Discussió | contribucions) (Concepto de Datafile (fichero de datos))
Dreceres ràpides: navegació, cerca

Tablespace

Una base de dades es divideix en unitats lògiques denominades TABLESPACES. Un tablespace no és un fitxer físic en el disc, simplement és el nom que té un conjunt de propietats d'emmagatzematge que s'apliquen als objectes (taules, seqüències%o2026) que es van a crear en la base de dades sota el tablespace indicat (taules, seqüències...).

Un objecte en base de dades ha d'estar emmagatzemat obligatòriament dins d'un tablespace.

Les propietats que s'associen a un tablespace són:

  • Localització dels fitxers de dades.
  • Especificació de màximes quotes de consum de disc.
  • Control de la disponibilitat de les dades (en línia o fora de línia).
  • Backup de dades.

Quan un objecte es crea dins d'un cert tablespace, aquest objecte adquireix totes les propietats abans descrites del tablespace utilitzat.

Tablespace

En aquest esquema podem veure que, per exemple, la taula ARTICULO s'emmagatzema dins del tablespace A, i que per tant tindrà totes les propietats del tablespace Al fet que poden ser::

  • Els seus fitxers de dades estan en $ORACLE_HOME/dades/dades_tablespace_A
  • Els objectes no poden ocupar més de 10Mb d'espai de base de dades.
  • A qualsevol moment es pot posar fora de línia tots els objecte d'un cert tablespace. -Es poden fer copiar de seguretat només de certs tablespaces.

Si ens fixem, es pot apreciar que és possible tenir una taula en un tablespace, i els índexs d'aquesta taula en un altre. Això és a causa que els índexs no són més que objectes independents dins de la base de dades, com el són les taules. I en ser objectes independents, poden anar en tablespaces independents. El tablespace SYSTEM és un dels quals es crear per defecte en totes les bases de dades Oracle. En ell s'emmagatzemen totes les dades de sistema, el catàleg i tot el codi font i compilat de procediments PL/SQL. També és possible utilitzar el mateix tablespace per guardar dades d'usuari. En l'esquema també veiem que hi ha un tablespace Temporal (en gris fosc). Est representa les propietats que tindran els objectes que la base de dades creu temporalment per als seus càlculs interns (normalment per a ordenacions i agrupacions). La seva creació difereix en una de les seves clàusules de creació. El tablespace RO (en grisa clar) difereix dels altres en què és de solament lectura (Read Only), i que per tant tots els objectes en ell continguts poden rebre ordres de consulta de dades, però no de modificació de dades. Aquests pot residir en suports de només lectura, com poden ser CDROMs, DVDs, etc. Quan es crea un tablespace, aquest es crea de lectura/escriptura. Després es pot modificar perquè sigui de solament lectura. Un tablespace pot estar en línia o fora d'ella (Online o Offline), això és que tots els objectes continguts en ell estan a la disposició dels usuaris o estan inhabilitats per restringir el seu ús. Qualsevol objecte emmagatzemat dins d'un tablespace no podrà ser accedit si aquest està fora de línia.

Datafile

Un datafile és la representació física d'un tablespace. Són els "fitxers de dades" on s'emmagatzema la informació físicament. Un datafile pot tenir qualsevol nom i extensió (sempre dins de les limitacions del sistema operatiu), i pot estar localitzat en qualsevol directori del disc dur, encara que la seva localització típica sol ser $ORACLE_HOME/Database. Un datafile té una grandària predefinida en la seva creació (per exemple 100Mb) i est pot ser alterat a qualsevol moment. Quan creiem un datafile, est ocuparà tant espai en disc com hàgim indicat en la seva creació, encara que internament estigui buit. Oracle fa això per reservar espai continu en disc i evitar així la fragmentació. Conforme es vagin creant objectes en aquest tablespace, s'anirà ocupant l'espai que va crear inicialment.

Un datafile està associat a un sol tablespace i, al seu torn, un tablespace està associat a un o diversos datafiles. És a dir, la relació lògica entre tablespaces i datafiles és d'1-N, mestre-detall.

Datafile

En l'esquema podem veure com el %o201CTablespace A%o201D està compost (físicament) per tres datafiles (DADES_1.ORA, DADES_2.ORA i DADES_3.ORA). Aquests tres datafiles són els fitxers físics que suporten els objectes continguts dins del tablespace A. Encara que sempre es diu que els objectes estan dins del tablespace, en realitat les taules estan dins del datafile, però tenen la propietats associades al tablespace.

Cadascun dels datafiles utilitzats està ocupant la seva grandària en disc (50 Mb els dos primers i 25 Mb l'últim) encara que en realitat només continguin dos objectes i aquests objectes no omplin l'espai que està assignat pels datafiles.

Els datafiles tenen una propietat anomenada AUTOEXTEND, que se si està activa, s'encarrega que el datafile creixi automàticament (segons una grandària indicada) cada vegada que es necessiti espai i no existeixi. Igual que els tablespaces, els datafiles també pot estar en línia o fora d'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).

Segment

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”.

Extent

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.

Datablock

(*) 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

Mida datablock

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.