Arquitectura Oracle

De wikijoan
La revisió el 09:38, 10 nov 2009 per Joan (discussió | contribucions) (→‎Estructures Externes)
(dif) ← Versió més antiga | Versió actual (dif) | Versió més nova → (dif)
Salta a la navegació Salta a la cerca

font: http://www.infor.uva.es/~jvegas/cursos/bd/orarq/orarq.html#3.3.2

Configuració post-instal.lació

El Servidor Oracle de l'institut és un Oracle Server 11gR1, sobre Ubuntu (i LINKAT), amb IP 192.168.0.10, i nom de la instància: BBDD

Aquestes dades són necessàries per configurar el fitxer TNSNAMES.oRA en un ordinador client que vulgui connectar-se al servidor.

Després de la instal.lació del servidor, per tal d'automatitzar el procés d'arrencada hem d'aconseguir que el sevidor s'inicïi en l'inici del sistema, configurar totes les variables d'entorn (script oraenv), i fer que aquestes variables d'entorn estiguin actives (fitxer .bashrc de l'usuari que fa login).

Així mateix, és important assegurar-se que la codificació dels caràcters (accents, caràcters especials), comportament de les dates i unitats siguin els correctes.

Tot això està explicat a Instal.lació_d'Oracle_11g_a_Ubuntu_Jaunty_(9.04)#Configuraci.C3.B3_oraenv

Connexió com a SYSDBA

http://www.infor.uva.es/~jvegas/cursos/bd/orarq/orarq.html

Tot i que aquest link és antic (val per a Oracle 7), per a nosaltres ens és útil i és una demostració que els anys han passat però que el nucli de l'arquitectura d'Oracle és la mateixa.

Quant s'instal.la el software Oracle en un sistema, ers creen directoris i fitxers que pengen tots ells del ORACLE_HOME. 

export ORACLE_SID=BBDD
export ORACLE_HOME=/u01/app/oracle/product/11.1.0/bbdd
export PATH="$PATH:/u01/app/oracle/product/11.1.0/bbdd/bin"
export ORACLE_BASE=/u01/app/oracle
export NLS_LANG=SPANISH_SPAIN.AL32UTF8
set NLS_LANG=SPANISH_SPAIN.UTF8

joan@ubuntu-bbdd:/u01/app/oracle/product/11.1.0/bbdd$ ls
apex         diagnostics       listener.log  ord           sqldeveloper
assistants   has               log           oui           sqlj
bin          hs                md            owb           sqlplus
ccr          install           mesg          owm           srvm
cdata        install.platform  mgw           perl          startup.log
cfgtoollogs  instantclient     network       plsql         sysman
clone        inventory         nls           precomp       uix
config       j2ee              oc4j          racg          ultrasearch
crs          javavm            odbc          rdbms         wwg
csmig        jdbc              olap          relnotes      xdk
css          jdk               OPatch        root.sh
ctx          jlib              opmn          scheduler
dbs          ldap              oracore       shutdown.log
demo         lib               oraInst.loc   slax

Tots aquests subdirectoris contenen fitxers executables i scripts que són crucials per al funcionament i l'administració del SGBD, i és el que es coneix com a codi Oracle.

Per realitzar tasques administratives ens hem de connectar a l'Oracle com a administradors de bases de dades. No n'hi ha prou amb connectar-se amb un usuari que tingui el rol de DBA. Hem d'especificar que anem a realitzar tasques administratives: SYSDBA 

$ sqlplus sys as SYSDBA

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

Hi ha 5 operacions a Oracle que requereixen que l'usuari tingui privilegis de SYSDBA:

  • startup a database,
  • shutdown a database,
  • backup a database,
  • recover a database and
  • create a database

la vista v$pwfile_users llista tots els usuaris que tenen privilegis de SYSDBA o SYSOPER. El privilegi de SYSDBA no es pot donar al rol PUBLIC 

select * from v$pwfile_users;

USERNAME   SYSDBA   SYSOPER SYSASM
---------- -------- ------- --------
SYS        TRUE     TRUE    FALSE

l'únic usuari que té permís és el sys. I és el que rol DBA no inclou els privilegis de sistema SYSDBA o SYSOPER. Aquests són privilegis administratius especials.

Bases de Dades i Instàncies

En termes senzills, una instància de BD és un conjunt de processos del servidor Oracle que tenen la seva pròpia àrea global de memòria i una base de dades associada a ells.

Bases de Dades

Una Base de Dades Oracle és un conjunt de dades ammagatzemades i accessibles segons el format de taules relacionals (taules que contenen camps, i la informació està en files; les taules poden estar relacionades).

Una Base de Dades Oracle està emmagatzemada físicament en fitxers, i la correspondència entres els fitxers i les taules és possible gràcies a les estructures internes de la BD, que permeten que diferents tipus de dades estiguin físicament separats. Aquesta divisió lògica es fa gràcies als espais de taula, tablespaces.

Els Espais de Taules, Tablespaces

Un espacio de tablas es una división lógica de la BD. Cada BD tiene al menos uno (SYSTEM). Un espacio de tablas puede pertenecer sólo a una BD. Los espacios de tablas se utilizan para mantener juntos los datos de usuarios o de aplicaciones para facilitar su mantenimiento o mejorar las prestaciones del sistema.

De esta manera, cuando se crea una tabla se debe indicar el espacio de tablas al que se destina. Por defecto se depositan en el espacio de tablas SYSTEM, que se crea por defecto. Este espacio de tablas es el que contiene el diccionario de datos, por lo que conviene reservarlo para el uso del servidor, y asignar las tablas de usuario a otro.

Lo razonable y aconsejable es que cada aplicación tenga su propio espacio de tablas.

Hay varias razones que justifican este modo de organización de las tablas en espacios de tablas:

  • Un espacio de tablas puede quedarse offline debido a un fallo de disco, permitiendo que el SGBD continúe funcionando con el resto.
  • Los espacios de tablas pueden estar montados sobre dispositivos ópticos si son de sólo lectura.
  • Permiten distribuir a nivel lógico/físico los distintos objetos de las aplicaciones.
  • Son una unidad lógica de almacenamiento, pueden usarse para aislar completamente los datos de diferentes aplicaciones.
  • Oracle permite realizar operaciones de backup/recovery a nivel de espacio de tabla mientras la BD sigue funcionando.

Cuando se crean se les asigna un espacio en disco que Oracle reserva inmediatamente, se utilice o no. Si este espación inicial se ha quedado pequeño Oracle puede gestionar el crecimiento dinámico de los ficheros sobre los que se asientan los espacios de tablas. Esto elimina la posibilidad de error en las aplicaciones por fallos de dimensionamiento inicial. Los parámetros de crecimiento del tamaño de los espacios de tablas se especifican en la creación de los mismos.

Se pueden ver los espacios de tablas definidos en nuestra BD con el comando SQL siguiente: 

SQL> select * from user_tablespaces;

SQL> desc user_tablespaces;
 Nombre                                    ¿Nulo?  Tipo
 ----------------------------------------- -------- ----------------------------
 TABLESPACE_NAME                           NOT NULL VARCHAR2(30)
 BLOCK_SIZE                                NOT NULL NUMBER
 INITIAL_EXTENT                                     NUMBER
 NEXT_EXTENT                                        NUMBER
 MIN_EXTENTS                               NOT NULL NUMBER
 MAX_EXTENTS                                        NUMBER
 MAX_SIZE                                           NUMBER
 PCT_INCREASE                                       NUMBER
 MIN_EXTLEN                                         NUMBER
 STATUS                                             VARCHAR2(9)
 CONTENTS                                           VARCHAR2(9)
 LOGGING                                            VARCHAR2(9)
 FORCE_LOGGING                                      VARCHAR2(3)
 EXTENT_MANAGEMENT                                  VARCHAR2(10)
 ALLOCATION_TYPE                                    VARCHAR2(9)
 SEGMENT_SPACE_MANAGEMENT                           VARCHAR2(6)
 DEF_TAB_COMPRESSION                                VARCHAR2(8)
 RETENTION                                          VARCHAR2(11)
 BIGFILE                                            VARCHAR2(3)
 PREDICATE_EVALUATION                               VARCHAR2(7)
 ENCRYPTED                                          VARCHAR2(3)
 COMPRESS_FOR                                       VARCHAR2(18)

SQL> select tablespace_name from user_tablespaces;

TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
USERS

Dentro de cada espacio de tabla se pueden almacenar objetos de distinta naturaleza: tablas, índices, etc. Pero no se pueden mezclar sin más. Necesitamos una manera de separarlos, y eso son los segmentos.

Se pueden almacenar más de un segmento por espacio de tabla. Un segmento está contenido en su totalidad en un espacio de tabla. Un segmento está constituido por un conjunto de extensiones, que no son más que grupos de bloques de disco ORACLE contiguos. Cuando se borra un segmento, el espacio es devuelto al espacio de tabla.

Todos los datos de la BD están almacenados en segmentos. Y existen 5 tipos de segmentos:

  • de datos: almacenan las tablas.
  • de índices: permiten un acceso rápido a los datos dependiendo de la cantidad de los mismos (árboles B). Las consultas que sólo referencian a columnas indexadas se resuelven en el índice. Establecen un control de unicidad (los índices son automáticos cuando se definen claves primarias). Cada índice ocupa un segmento independiente del segmento de datos y deberían estar en un espacio de tablas distinto al de los datos, para mejorar el rendimiento.
  • de rollback: son objetos internos de la BD que permiten efectuar la restauración de las transacciones no validadas asegurando la consistencia en lectura. La estructura de los registros de rollback es :
    • Identificador de la transacción.
    • Dirección del bloque donde está la tabla.
    • Número de fila.
    • Número de columna.
    • Valor del dato antiguo (antes de ser modificado).

Son tan importantes que una BD no puede arrancar si no puede acceder al menos a un segmento de rollback. Si la BD tiene múltiples espacios de tablas, deben existir al menos dos segmentos de rollback y cada segmento de rollback debe tener al menos dos extensiones, reutilizables de manera cíclica. Esto segmentos son un objeto compartido de la BD, aunque se puede asinar un segmento de rollback particular a una transacción dada.

  • temporales: son creados por Oracle para un uso temporal cuando debe realizar una ordenación que no le cabe en memoria, y en las operaciones: create index, order by, group by, distinct, union, intersect, minus. Son eliminados cuando la sentencia finaliza.
  • de bootstrap: Se crea en SYSTEM y contiene definiciones del diccionario para sus tablas, que se cargan al abrir la BD. No requiere ninguna acción por parte del DBA. No cambia de tamaño.

La tabla que guarda la información de los segmentos de usuario es user_segments, y se puede visualizar la información sobre los segmentos con la sentencia SQL siguiente: 

SQL> select * from user_segments;

SQL> desc user_segments;
 Nombre                                    ¿Nulo?  Tipo
 ----------------------------------------- -------- ----------------------------
 SEGMENT_NAME                                       VARCHAR2(81)
 PARTITION_NAME                                     VARCHAR2(30)
 SEGMENT_TYPE                                       VARCHAR2(18)
 SEGMENT_SUBTYPE                                    VARCHAR2(10)
 TABLESPACE_NAME                                    VARCHAR2(30)
 BYTES                                              NUMBER
 BLOCKS                                             NUMBER
 EXTENTS                                            NUMBER
 INITIAL_EXTENT                                     NUMBER
 NEXT_EXTENT                                        NUMBER
 MIN_EXTENTS                                        NUMBER
 MAX_EXTENTS                                        NUMBER
 MAX_SIZE                                           NUMBER
 RETENTION                                          VARCHAR2(7)
 MINRETENTION                                       NUMBER
 PCT_INCREASE                                       NUMBER
 FREELISTS                                          NUMBER
 FREELIST_GROUPS                                    NUMBER
 BUFFER_POOL                                        VARCHAR2(7)

SQL> select segment_name from user_segments;
...
SEGMENT_NAME
--------------------------------------------------------------------------------
SYS_LOB0000000472C00008$$
WRI$_OPTSTAT_SYNOPSIS_HEAD$
I_WRI$_OPTSTAT_SYNOPPARTGRP
WRI$_OPTSTAT_SYNOPSIS_PARTGRP
I_WRI$_OPTSTAT_OPR_STIME
WRI$_OPTSTAT_OPR
I_WRI$_OPTSTAT_AUX_ST
WRI$_OPTSTAT_AUX_HISTORY
I_WRI$_OPTSTAT_H_ST
I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST
WRI$_OPTSTAT_HISTGRM_HISTORY
...
2092 files

Fitxers de dades, datafiles

Cada espacio de tablas se compone de uno o más ficheros en disco. Un fichero puede pertenecer sólo a un espacio de tablas. Los ficheros reciben un tamaño fijo en el momento de su creación, y cuando se necesita más espacio se deben añadir más ficheros a espacio de tablas.

Dividir los objetos de la BD entre múltiples espacios de tablas permiten que los objetos sean almacenados físicamente en discos separados, dependiendo de donde estén los ficheros sobre los que se asientan.

Instàncies

Para permitir el acceso a los datos, Oracle utiliza un conjunto de procesos que son compartidos por todos los usuarios. Además, existen estructuras de memoria que son utilizadas para almacenar los datos más recientemente solicitados a la BD.

Una instancia de BD es el conjunto de estructuras de memoria y de procesos que acceden a los ficheros de datos. 

SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
BBDD

SQL> select name from v$database;
NAME
---------
BBDD

Los parámetros que determinan el tamaño y composición de una instancia están almacenados en un fichero llamado init.ora. Este fichero es leido durante el arranque de la BD y puede ser modificado por el DBA. Cualquier modificación de este fichero no tiene efecto hasta la siguiente vez que se arranque la BD.

Las estructuras de la BD Oracle pueden ser divididas en tres clases:

  • aquellas que son internas a la BD,
  • aquellas que son internas a las áreas de memoria (incluidas la memoria compartida y procesos),
  • aquellas que son externas a la BD.

Estructures Internes

Tablas y Columnas

Los datos son almacenados en la BD utilizando tablas. Cada tabla está compuesta por un número determinado de columnas.

Las tablas propiedad del usuario SYS son llamadas tablas del diccionario de datos. Proveen el catálogo del sistema que permite que la BD se gestione a sí misma.

Las tablas se pueden relacionar entre ellas a través de las columnas que las componen. La BD se puede utilizar para asegurar el cumplimiento de esas relaciones a través de la integridad referencial, que se concreta en las restricciones de tablas.

Restricciones de Tablas

Una tabla puede tener asociadas restricciones que deben cumplir todas las filas. Entre las restricciones que se pueden fijar algunas reciben nombres especiales.: clave primaria, clave ajena.

La clave primaria de una tabla está compuesta por las columnas que hacen a cada fila de la tabla una fila distinta.

La clave ajena se utiliza para especificar las relaciones entre tablas. De modo que un conjunto de columnas declaradas como clave ajena de una tabla deben tener valores tomados de la clave primaria de otra tabla.

Usuarios

Una cuenta de usuario no es una estructura física de la BD, pero está relacionada con los objetos de la BD: los usuarios poseen los objetos de la BD. Existen dos usuarios especiales: SYS y SYSTEM. El usuarios SYS posee las tablas del diccionario de datos; que almacenan información sobre el resto de las estructuras de la BD. El usuario SYSTEM posee las vistas que permiten acceder a las tablas del diccionario, para el uso del resto de los usuarios de la BD.

Todo objeto creado en la BD se crea por un usuario, en un espacio de tablas y en un fichero de datos determinado. Toda cuenta de la BD puede estár unida a una cuenta del S.O., lo que permite a los usuarios acceder a la cuenta de la BD sin dar la clave de acceso.

Cada usuario puede acceder a los objetos que posea o a aquellos sobre los que tenga derecho de acceso.

Esquemas

El conjunto de objetos de un usuario es conocido como esquema.

Índices

Un índice es una estructura de la BD utilizada para agilizar el acceso a una fila de una tabla. Cada fila tiene un identificador de fila, ROWID, que determina el fichero, bloque y fila dentro del bloque donde está almacenada la fila.

Cada entrada del índice consite en un valor clave y una ROWID. Cada una de estas entradas se almacena en un árbol B+.

Los índices se crean automáticamente cuando se define una restricción UNIQUE o PRIMARY KEY.

Clusters

Las tablas que son accedidas juntas frecuentemente pueden ser almacenadas juntas. Para ello se crea un cluster. De este modo se minimiza el número de E/S.

Las columnas que relacionan las tablas de un cluster se llaman clave del cluster.

Vistas

Conceptualmente, una vista puede considerarse como una máscara que se extiende sobre una o más tablas, de modo que cada columna de la vista se corresponde con una o más columnas de las tablas subyacentes. Cuando se consulta una vista, esta traspasa la consulta a las tablas sobre las que se asienta. Las vistas no se pueden indexar.

Las vistas no generan almacenamiento de datos, y sus definiciones se almacenan en el diccionario de datos.

Secuencias

Las definiciones de secuencias se almacenan en el diccionario de datos. Son mecanismos para obtener listas de números secuenciales.

Procedimientos y Funciones

Un procedimiento es un bloque de código PL/SQL, que se almacena en el diccionario de datos y que es llamado por las aplicaciones. Se pueden utilizar para implementar seguridad, no dando acceso directamente a determinadas tablas sino es a través de procedimientos que acceden a esas tablas. Cuando se ejecuta un procedimiento se ejecuta con los privilegios del propietario del procedimiento. La diferencia entre un procedimiento y una función es que ésta última puede devolver valores.

Paquetes, Packages

Se utilizan para agrupar procedimientos y funciones. Los elementos dentro de los paquetes pueden ser públicos o privados. Los públicos pueden ser llamados por los usuarios, los privados están ocultos a los usuarios y son llamados por otros procedimientos.

Disparadores, Triggers

Son procedimientos que son ejecutados cuando se procude un determinado evento en la BD. Se pueden utilizar para mejorar y reforzar la integridad y la seguridad de la BD.

Sinónimos

Para identificar completamente un objeto dentro de una BD se necesita especificar el nombre de la máquina, el nombre del servidor, el nombre del propietario y el nombre del objeto. Para hacer transparente todo esto al usuario se pueden utilizar los sinónimos. Éstos apuntarán a los objetos y si el objeto cambia de lugar o propietario, sólo habrá que modificar el sinónimo. Existen sinónimos públicos y privados. Los públicos son conocidos por todos los usuarios de una BD. Los privados son locales a un usuario.

Privilegios y Roles

Para que un objeto pueda ser accedido por un usuario debe de tener otorgado ese privilegio. Ejemplos de privilegios son INSERT, SELECT, UPDATE, EXECUTE, etc.

Los roles son grupos de privilegios que pueden ser utilizados para facilitar la gestión de los privilegios. Los privilegios se pueden otorgar a un rol, y los roles pueden ser otorgados a múltiples usuarios.

Segmentos, Extensiones y Bloques

Los segmentos son los equivalentes físicos de los objetos que almacenan datos. El uso efectivo de los segmentos requiere que el DBA conozca los objetos que utiliza una aplicación, cómo los datos son introducidos en esos objetos y el modo en que serán recuperados.

Como los segmentos son entidades físicas, deben estar asignados a espacios de tablas en la BD y estarán localizados en uno de los ficheros de datos del espacio de tablas. Un segmento está constituido por secciones llamadas extensiones, que son conjuntos contiguos de bloques Oracle. Una vez que una extensión existente en un segmento no puede almacenar más datos, el segmento obtendrá del espacio de tabla otra extensión. Este proceso de extensión continuará hasta que no quede más espacio disponible en los ficheros del espacio de tablas, o hasta que se alcance un número máximo de extensiónes por segmento.

Segmento de Rollback

Para mantener la consistencia en lectura y permitir deshacer las transacciones, Oracle debe tener un mecanismo para reconstruir la imágen previa a una transacción incompleta. Oracle utiliza los segmentos de rollback para esto.

Los segmentos de rollback pueden crecer tanto como sea necesario para soportar las transacciones.

Estructures de Memòria Internes

Oracle mantiene dos estructuras principales de memoria: el Área Global de Programa, Program Global Area, PGA; y el Área Global del Sistema, System Global Area o también Shared Global Area, SGA.

El PGA es la zona de memoria de cada proceso Oracle. No está compartida y contiene datos e información de control de un único proceso.

El SGA es la zona de memoria en la que la BD Oracle guarda información sobre su estado. Esta estructura de memoria está disponible para todos los procesos, por eso se dice que está compartida.

Àrea Global del Sistema, SGA

Sirve para facilitar la transferencia de información entre usuarios y también almacena la información estructural de la BD más frecuentemente requerida. 

SQL> select * from v$sga;

NAME			  VALUE
-------------------- ----------
Fixed Size		1298836
Variable Size	      155192940
Database Buffers       33554432
Redo Buffers		6635520

La SGA se divide en varias partes:

Buffers de BD, Database Buffer Cache

Es el caché que almacena los bloques de datos leidos de los segmentos de datos de la BD, tales como tablas, índices y clusters. Los bloques modificados se llamas bloques sucios. El tamaño de buffer caché se fija por el parámetro DB_BLOCK_BUFFERS del fichero init.ora. Como el tamaño del buffer suele ser pequeño para almacenar todos los bloques de datos leidos, su gestión se hace mediante el algoritmo LRU.

Buffer Redo Log Los registros Redo describen los cámbios realizados en la BD y son escritos en los ficheros redo log para que puedan ser utilizados en las operaciones de recuperación hacia adelante, roll-forward, durante las recuperaciones de la BD. Pero antes de ser escritos en los ficheros redo log son escritos en un caché de la SGA llamado redo log buffer. El servidor escribe periódicamente los registros redo log en los ficheros redo log.

El tamaño del buffer redo log se fija por el parámetro LOG_BUFFER.

Área de SQL Compartido, Shared SQL Pool En esta zona se encuentran las sentencias SQL que han sido analizadas. El analisis sintáctico de las sentencias SQL lleva su tiempo y Oracle mantiene las estructuras asociadas a cada sentencia SQL analizada durante el tiempo que pueda para ver si puede reutilizarlas. Antes de analizar una sentencia SQL, Oracle mira a ver si encuentra otra sentencia exactamente igual en la zona de SQL compartido. Si es así, no la analiza y pasa directamente a ejecutar la que mantinene en memoria. De esta manera se premia la uniformidad en la programación de las aplicaciones. La igualdad se entiende que es lexicografica, espacios en blanco y variables incluidas. El contenido de la zona de SQL compartido es:

  • Plan de ejecución de la sentencia SQL.
  • Texto de la sentencia.
  • Lista de objetos referenciados.

Los pasos de procesamiento de cada petición de análisis de una sentencia SQL son:

  • Comprobar si la sentencia se encuentra en el área compartida.
  • Comprobar si los objetos referenciados son los mismos.
  • Comprobar si el usuario tiene acceso a los objetos referenciados.

Si no, la sentencia es nueva, se analiza y los datos de análisis se almacenan en la zona de SQL compartida.

También se almacena en la zona de SQL compartido el caché del diccionario. La información sobre los objetos de la BD se encuentra almacenada en las tablas del diccionario. Cuando esta información se necesita, se leen las tablas del diccionario y su información se guarda en el caché del diccionario de la SGA.

Este caché también se administra mediante el algoritmo LRU. El tamaño del caché está gestionado internamente por el servidor, pero es parte del shared pool, cuyo manaño viene determinado por el parámetro SHARED_POOL_SIZE.

Àrea Global de Programa, PGA

El Program Global Area es un área de memoria utilizada por un proceso Oracle. Esta zona de memoria no se puede compartir.

Estructures de Procés

Orarq.gif

El servidor se vale de una serie de procesos que son el enlace entre las estructuras físicas y de memoria. A continuación se describen cada proceso y el papel que juega en la gestión de laBD. Todo esto se puede ver en la siguiente figura.

System Monitor, SMON

El SMON es el supervisor del sistema y se encarga de todas las recuperaciones que sean necesarias durante el arranque. Esto puede ser necesario si la BD se paró inesperadamente por fallo físico, lógico u otras causas. Este proceso realiza la recuperación de la instancia de BD a partir de los ficheros redo log. Además límpia los segmentos temporales no utilizados y compacta los huecos libres contiguos en los ficheros de datos. Este proceso se despierta regularmente para comprobar si debe intervenir.

Process Monitor, PMON

Este proceso restaura las transacciones no validadas de los procesos de usuario que abortan, liberando los bloqueos y los recursos de la SGA. Asume la identidad del usuario que ha fallado, liberando todos los recursos de la BD que estuviera utilizando, y anula la transacción cancelada. Este proceso se despierta regularmente para comprobar si su intervención es necesaria.

Database Writer, DBWR

El proceso DBWR es el responsable de gestionar el contenido de los buffers de datos y del caché del diccionario. Él lee los bloques de los ficheros de datos y los almacena en la SGA. Luego escribe en los ficheros de datos los bloques cuyo contenido ha variado. La escritura de los bloques a disco es diferida buscando mejorar la eficiencia de la E/S.

Es el único proceso que puede escribir en la BD. Esto asegura la integridad. Se encarga de escribir los bloques de datos modificados por las transacciones, tomando la información del buffer de la BD cuando se valida una transacción. Cada validación no se lleva a la BD física de manera inmediata sino que los bloques de la BD modificados se vuelcan a los ficheros de datos periodicamente o cuando sucede algún checkpoint o punto de sincronizaión: grabación diferida:

Los bloques del buffer de la BD (bloques del segmento de rollback y bloques de datos) menos recientemente utilizados son volcados en el disco continuamente para dejar sitio a los nuevos bloques. El bloque del segmento de rollback se escribe SIEMPRE antes que el correspondiente bloque de datos. Múltiples transacciones pueden solapar los cambios en un sólo bloque antes de escribirlo en el disco. Mientras, para que se mantenga la integridad y coherencia de la BD, todas las operaciones se guardan en los ficheros de redo log. El proceso de escritura es asíncrono y puede realizar grabaciones multibloque para aumentar la velocidad.

Log Writer, LGWR

El proceso LGWR es el encargado de escribir los registros redo log en los ficheros redo log. Los registros redo log siempre contienen el estado más reciente de la BD, ya que puede que el DBWR deba esperar para escribir los bloques modificados desde el buffer de datos a los ficheros de datos.

Conviene tener en cuenta que el LGWR es el único proceso que escribe en los ficheros de redo log y el único que lee directamente los buffers de redo log durante el funcionamiento normal de la BD.

Coloca la información de los redo log buffers en los ficheros de redo log. Los redo log buffers almacenan una copia de las transacciones que se llevan a cabo en la BD. Esto se produce:

a cada validación de transacción, y antes de que se comunique al proceso que todo ha ido bien, cuando se llena el grupo de buffers de redo log cuando el DBWR escribe buffers de datos modificados en disco. Así, aunque los ficheros de DB no se actualicen en ese instante con los buffers de BD, la operación queda guardada y se puede reproducir. Oracle no tiene que consumir sus recursos escribiendo el resultado de las modificaciones de los datos en los archivos de datos de manera inmediata. Esto se hace porque los registros de redo log casi siempre tendrán un tamaño menor que los bloques afectados por las modificaciones de una transacción, y por lo tanto el tiempo que emplea en guardarlos es menor que el que emplearía en almacenar los bloques sucios resultado de una transacción; que ya serán trasladados a los ficheros por el DBWR. El LGWR es un proceso único, para asegurar la integridad. Es asíncrono. Además permite las grabaciones multibloque.

Checkpoint, CKPT

Este proceso escribe en los ficheros de control los checkpoints. Estos puntos de sincronización son referencias al estado coherente de todos los ficheros de la BD en un instante determinado, en un punto de sincronización. Esto significa que los bloques sucios de la BD se vuelcan a los ficheros de BD, asegurándose de que todos los bloques de datos modificados desde el último checkpoint se escriben realmente en los ficheros de datos y no sólo en los ficheros redo log; y que los ficheros de redo log también almacenan los registros de redo log hasta este instante. La secuencia de puntos de control se almacena en los ficheros de datos, redo log y control. Los checkpoints se produce cuando:

  • un espacio de tabla se pone inactivo, offline,
  • se llena el fichero de redo log activo,
  • se para la BD,
  • el número de bloques escritos en el redo log desde el último checkpoint alcanza el límite definido en el parámetro LOG_CHECKPOINT_INTERVAL,
  • cuando transcurra el número de segundos indicado por el parámetro LOG_CHECKPOINT_TIMEOUT desde el último checkpoint.

Está activo si el parámetro CHECKPOINT_PROCESS tiene un valor verdadero.

Archiver, ARCH

El proceso archivador tiene que ver con los ficheros redo log. Por defecto, estos ficheros se reutilizan de manera cíclica de modo que se van perdiendo los registros redo log que tienen una cierta antiguedad. Cuando la BD se ejecuta en modo ARCHIVELOG, antes de reutilizar un fichero redo log realiza una copia del mismo. De esta manera se mantiene una copia de todos los registros redo log por si fueran necesarios para una recuperación. Este es el trabajo del proceso archivador.

Recoverer, RECO

El proceso de recuperación está asociado al servidor distribuido. En un servidor distribuido los datos se encuentran repartidos en varias localizaciones físicas, y estas se han de mantener sincronizadas. Cuando una transacción distribuida se lleva a cabo puede que problemas en la red de comunicación haga que una de las localizaciones no aplique las modificaciones debidas. Esta transacción dudosa debe ser resuelta de algún modo, y esa es la tarea del proceso recuperador. Está activo si el parámetro DISTRIBUTED_TRANSACTIONS tiene un valor distinto de 0.

Lock, LCK

El proceso de bloqueo está asociado al servidor en paralelo.

Estructures Externes

Por estructuras externas se entienden los ficheros que utiliza el servidor de BD, de los cuales ya se han ido contanto algunos aspectos, y otros se han ido intuyendo. Estos ficheros guardan información tanto de los datos almacenados en la BD como la necesaria para gobernar la propia BD.

Ficheros de la BD

En estos ficheros reside la información de la BD. Solo son modificados por el DBWR. A ellos se vuelcan los bloques sucios de la SGA cuando se hace una validación o cuando sucede un checkpoint. Las validaciones de las transacciones no producen un volcado inmediato, sino lo que se conoce por un commit diferido. Toda actualización se guarda en los ficheros de redo log, y se lleva a la BD física cuando tenemos una buena cantidad de bloques que justifiquen una operación de E/S. Almacenan los segmentos (datos, índices, rollback) de la BD. Están divididos en bloques (Bloque Oracle = c * Bloque SO), cada uno de los cuales se corresponde con un buffer del buffer cache de la SGA. En el bloque de cabecera no se guardan datos de usuario, sino la marca de tiempo del último checkpoint realizado sobre el fichero. 

SQL> desc v$datafile
SQL> select status, substr(name,1,70) nombre from v$datafile

SYSTEM  /u01/app/oracle/oradata/BBDD/system01.dbf
ONLINE  /u01/app/oracle/oradata/BBDD/sysaux01.dbf
ONLINE  /u01/app/oracle/oradata/BBDD/undotbs01.dbf
ONLINE  /u01/app/oracle/oradata/BBDD/users01.dbf

Ficheros redo log

En ellos se graba toda operación que se efectue en la BD y sirven de salvaguarda de la misma. Tiene que haber por lo menos 2, uno de ellos debe estar activo, online, y se escribe en ellos de forma cíclica. Existe la posibilidad de almacenar los distintos ficheros de redo log en el tiempo mediante el modo ARCHIVER. Así, se puede guardar toda la evolución de la BD desde un punto dado del tiempo.

Una opción es la utilización de archivos redo log multiplexados:

  • Permite al LGWR escribir simultaneamente la misma información en múltiples archivos redo log.
  • Se utiliza para protegerse contra fallos en el disco.
  • Da una alta disponibilidad a los archivos redo log activos u online.

Esto se hace definiendo el número de grupos y de miembros de archivos redo log que van a funcionar en paralelo:

  • grupos: funcionan como ficheros redo log normales, uno de ellos está activo y el resto espera su turno. Su nombre lleva incorporado una numeración. Deben contener todos el mismo número de miembros.
  • miembros: cada escritura de un registro redo log se lleva a cabo en todos los miembros del grupo activo en ese momento. Los miembros deben tener el mismo tamaño y el mismo número de secuencia. Deben tener nombres similares y estar en diferentes discos para proteger contra fallos de una manera efectiva.

Cuando se produce algún fallo en los ficheros de redo log o en el proceso LGWR:

  • Si la escritura en un fichero redo log falla pero el LGWR puede escribir al menos en uno de los miembros del grupo, lo hace , ignorando el fichero inaccesible y registrando un fallo en un fichero de traza o alerta.
  • Si el siguiente grupo no ha sido archivado (modo ARCHIVELOG) antes del cambio de grupo que lo pone activo, ORACLE espera hasta que se produzca el archivado.
  • Si fallan todos los miembros de un grupo mientras el LGWR trata de escribir, la instancia se para y necesita recupeción al arrancar.

Redologfile.gif

Se pueden visualizar los nombres y estado de los ficheros de redo log: 

SQL> select group#, status, substr(member,1,60) from v$logfile;

    GROUP# STATUS   SUBSTR(MEMBER,1,60)
    ------------------------------------
         3  /u01/app/oracle/oradata/BBDD/redo03.log
         2  /u01/app/oracle/oradata/BBDD/redo02.log
         1  /u01/app/oracle/oradata/BBDD/redo01.log

Més útil és mirar sobre V$LOG, on podem veure quina és el fitxer de log actiu (CURRENT) i quina és al seqüència de logs que portem. Per provocar un canvi de fitxer de log de forma articial utilitzem la sentència ALTER SYSTEN SWITCH LOGFILE. 

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,BYTES,ARCHIVED,STATUS,FIRST_CHANGE#,FIRST_TIME FROM V$LOG;

    GROUP#    THREAD#  SEQUENCE#      BYTES ARCHIVED  STATUS	FIRST_CHANGE# FIRST_TIME
------------------------------------------------------------------------------------------------
	 1	    1	      31   52428800 NO        INACTIVE	1710165       09/11/09
	 2	    1	      32   52428800 NO        CURRENT   1745283       10/11/09
	 3	    1	      30   52428800 NO        INACTIVE  1674932       05/11/09

SQL> ALTER SYSTEM SWITCH LOGFILE;
Sistema modificado

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,BYTES,ARCHIVED,STATUS,FIRST_CHANGE#,FIRST_TIME FROM V$LOG;

    GROUP#    THREAD#  SEQUENCE#      BYTES ARCHIVED  STATUS	FIRST_CHANGE# FIRST_TIME
------------------------------------------------------------------------------------------------
	 1	    1	      31   52428800 NO        INACTIVE  1710165       09/11/09
	 2	    1	      32   52428800 NO        ACTIVE    1745283       10/11/09
         3	    1	      33   52428800 NO        CURRENT   1752047       10/11/09

Com veiem, hem canviat el fitxer de log que està treballant, ara és el GROUP#=3, que es correspon al redo03.log: 

SQL> SELECT substr(member,1,60) FITXER,V$LOG.STATUS FROM V$LOG, V$LOGFILE WHERE V$LOG.GROUP#=V$LOGFILE.GROUP# AND V$LOG.STATUS='CURRENT';

FITXER                                    STATUS
----------------------------------------  ---------
/u01/app/oracle/oradata/BBDD/redo03.log   CURRENT

Nota: per formatar les columnes podem utilitzar l'expressió del SQL*Plus column: 

column FITXER format a50
column STATUS format a10
SELECT member FITXER,V$LOG.STATUS FROM V$LOG, V$LOGFILE WHERE V$LOG.GROUP#=V$LOGFILE.GROUP# AND V$LOG.STATUS='CURRENT';

Ficheros de control

Mantienen la información física de todos los ficheros que forman la BD, camino incluido; así como el estado actual de la BD. Son utilizados para mantener la consistencia interna y guiar las operaciones de recuperación. Son imprescindibles para que la BD se pueda arrancar.

Contienen:

  • Infomación de arranque y parada de la BD.
  • Nombres de los archivos de la BD y redo log.
  • Información sobre los checkpoints.
  • Fecha de creación y nombre de la BD.
  • Estado online y offline de los archivos.

Debe haber múltiples copias en distintos discos, mínimo dos, para progerlos de los fallos de disco. La lista de los ficheros de control se encuentra en el parámetro CONTROL_FILES, que debe modificarse con la BD parada. 

SQL> select * from v$controlfile;

STATUS         NAME                                      IS_RECOVERY_  BLOCK_SIZE FILE_SIZE_BLKS
------------  --------                                   ------------- ---------- --------------
              /u01/app/oracle/oradata/BBDD/control01.ctl NO             16384     594
              /u01/app/oracle/oradata/BBDD/control02.ctl NO             16384     594
              /u01/app/oracle/oradata/BBDD/control03.ctl NO             16384     594


Se puede componer una sentencia SQL que nos muestre todos los ficheros asociados a una BD. Esta es: 

SQL> select 'control' tipo, substr(name,1,70) nombre from v$controlfile
union all
select 'datos' tipo, substr(name,1,70) nombre from v$datafile
union all
select 'redo log' tipo, substr(member,1,70) nombre from v$logfile;

Hasta aquí los tipos de ficheros que se suelen considerar fundamentales en la arquitectura del SGBD Oracle. Pero existen otros ficheros, que aunque no forman parte de la arquitectura Oracle resultan importantes en el uso del SGBD.

El Fichero INIT.ORA

Como parte de la distribución software, Oracle provee de un fichero de parámetros de inicialización llamado init.ora. Este fichero contiene los parámetros del sistema Oracle y debe ser utilizado por el DBA para configurar el SGDB y adecuarlo a una determinada explotación. Oracle lee este fichero durante el proceso de arranque para determinar el tamaño de la SGA y encontrar los ficheros de control, entre otros menesteres.

Como el fichero init.ora es fundamental para el arranque de la BD, debería ser copiado frecuentemente para protegerlo de posibles prédidas. 

root@ubuntu-bbdd:/u01/app/oracle$
./admin/BBDD/scripts/init.ora -> aquest és el que val
./product/11.1.0/bbdd/srvm/admin/init.ora
./product/11.1.0/bbdd/dbs/init.ora

Ficheros de Traza (log)

Orace crea ficheros de texto llamados de traza para ayudar en la diagnosis de problemas y en el ajuste del SGBD. Cada proceso del servidor escribe en un fichero de traza asociado cuando es necesario. Los procesos de usuarios también pueden tener asociados ficheros de traza. La situación de estos ficheros de traza del sistema se especifica por el parámetro BACKGROUND_DUMP_DEST, y los de usuario por USER_DUMP_DEST. Oracle crea ficheros de traza automáticamente cuando ocurre algún error.

Un parámetro muy frecuentemente utilizado por los desarrolladores Oracle es el SQL_TRACE, que cuando está puesto a TRUE produce que toda sentencia SQL ejecutada genere información en los ficheros de traza. Este parámetro se puede variar con el siguiente comando: 

SQL> alter session set SQL_TRACE=TRUE;
Session Altered.

El directorio donde se depositan los ficheros de traza debe de examinarse con regularidad para controlar el tamaño de los fichero allí depositados.

Cicle d'Execució

Para ilustrar el funcionamiento del servidor Oracle vamos a ver el ciclo de ejecución de una sentencia de lectura y otra de actualización.

Cicle de Lectura

Las sentencias de lectura siguen el siguiente ciclo:

  1. El proceso cliente pasa la sentencia SQL (SELECT) al proceso servidor por medio de la SGA.
  2. Los procesos del servidor buscan en la zona de SQL compartido una versión ejecutable de la sentencia. Si la encuentran no tienen que procesarla.
  3. Se procesa la sentencia SQL y su versión ejecutable se coloca en la zona de SQL compartido.
  4. El proceso del servidor intenta leer los bloques de datos de la SGA. Si no están, se han de leer del fichero de datos. Si los bloques están en la SGA pero han sido modificados por otro usuario y esa modificación no ha sido validada aún, el proceso de servidor debe reconstruir la imagen de la fila a partir de los segmentos de rollback, para conseguir consistencia en lectura.
  5. El proceso servidor pasa los datos solicitados al proceso cliente.

Cicle de Actualització

Las sentencias de actualización siguen el siguiente ciclo:

  1. El proceso cliente pasa la sentencia SQL (UPDATE) al proceso servidor por medio de la SGA.
  2. Los procesos del servidor buscan en la zona de SQL compartido una versión ejecutable de la sentencia. Si la encuentran no tienen que procesarla.
  3. Se procesa la sentencia SQL y su versión ejecutable se coloca en la zona de SQL compartido.
  4. El proceso del servidor intenta leer los bloques de datos de la SGA. Si no están, se han de leer del fichero de datos.
  5. Se registra el valor antiguo de los datos en un segmento de rollback y se crea un registro redo log.
  6. Se crea una copia de la transacción en un registro redo log.
  7. Se ejecuta la sentencia SQL modificando los datos, y se crea un registro redo log que así lo refleja.
  8. El proceso usuario valida la transacción (COMMIT), registrandose en un registro redo log.
  9. El LGWR escribe los buffers del redo log en el disco.
  10. El servidor indica al cliente que la operación ha sido completada de manera satisfactoria.
  11. Se registra la terminación de la transacción en un registro redo log.
  12. Se libera la información del rollback, pues ya no va a necesitarse.

Si a partir del paso 6 el usuario cancela la transacción (ROLLBACK), se puede utilizar la información de rollback para restablecer el valor original.

Si sucede algo que impida que la transacción validada por el usuario pueda llevarse a cabo, se puede utilizar la información contenida en los registros redo log para rehacer la transacción (a partir del paso 6).

Como ocurre con todas las transacciones, en algún momento el DBWR escribe en el archivo de datos la copia de los bloques de datos modificados que se encuentran en el buffer cache.

Configuració

El Codi Oracle

Arrencada i aturada de la BD

arrencada i aturada d'una BD Oracle

Emmagatzematge de Dades

Los datos se almacenan en estacios de tablas, y un espacio de tabla es la entidad lógica que se corresponde con uno o más ficheros físicos. La principal razón de esta organización es el aumento de la flexibilidad a la hora de realizar operaciones con la BD. En esta sección vamos a dar un repaso a las tareas de administración relacionadas con los espacios de tablas y con los ficheros.

Espais de Taules, Tablespaces

Los espacios de tablas se utilizan para realizar tareas de gestión de espacio, controlar la disponibilidad de los datos y ejecutar copias de seguridad y recuperaciones parciales.

Gestión de Espacio

El primer espai de taules és el SYSTEM. Aquest espai de taules ha d'estar disponible sempre durante el funcionament normal de la BD perque conté el diccionari de dades. Després de la creació de la BD, es recomana la creació d'altres espais de taules per tal que les dades dels usuaris estiguin separades del diccionari de dades. Fins i tot, si varies apliacions s'executen sobre la mateixa BD és recomanable que les seves dades estiguin separades. Per crear un espai de taules s'utilitza la comanda create tablespace: 

SQL> CREATE TABLESPACE "PROVA_TS" DATAFILE 'prova_ts.dbf' size 50M ONLINE;
Tablespace creado

En l'exemple anterior s'ha creat un espai de taules de 50 Mb. de tamany. Cada espai de taula té un conjunt de paràmetres que controla el seu creixement:

  • initial: tamaño de la extensión inicial (10k).
  • next: tamaño de la siguiente extensión a asignar (10k).
  • minextents: número de extensiones asignadas en el momento de la creación del espacio de tablas (1).
  • maxextents: número máximo de extensiones.
  • pctincrease: Porcentaje en el que crecerá la siguiente extensión antes de que se asigne, en relación con la última extensión utilizada.
  • optimal: Tamaño óptimo declarado para este espacio de tablas.
  • pctused: porcentaje de utilización del bloque por debajo del cual Oracle considera que un bloque puede ser utilizado para insertar filas nuevas en él.

Si l'espai de taules necessita més espai després de la seva creació es pot alterar per afegir un o més fitxers. Per fer-ho s'utilitza la comanda alter tablespace: 

SQL> ALTER TABLESPACE "PROVA_TS" ADD DATAFILE 'prova_ts2.dbf' size 30M;
Tablespace modificado.

SQL> select tablespace_name,status from user_tablespaces;
SQL> SELECT NAME FROM v$datafile;

Els datafiles els trobaré a la carpeta ./oracle/product/11.1.0/bbdd/dbs/ (compte perquè no estan dins de oradata, que és on esperava trobar-los). 

root@ubuntu-bbdd:/u01/app# find -name prova_ts.dbf
./oracle/product/11.1.0/bbdd/dbs/prova_ts.dbf

Si es necessita variar la localització dels fitxers associats a un espai de taules es pot fer amb les comandes alter tablespace (l'espai de taules ha d'estar offline) o alter database (la BD ha d'estar muntada però no oberta). Abans d'executar les anteriors comandes els fitxers assoicats a l'espai de taules hs'han d'haver mogut a la nova localització.

crear un usuari associat al nou espai de taules Creem un usuari associat a aquest nou espai de taules. Crearem una taula per a aquest usuari, i hi ficarem dades. L'objectiu és verue com aquestes dades es guardaran físicament en els datafiles assoicats a l'espai de taules. 

SQL> create user "PROVA" identified by "prova" default   tablespace "PROVA_TS";
SQL> grant connect,resource to prova;
SQL> create table prova (id number(1), nom varchar2(10));
SQL> insert into prova values(1,'aaa');
SQL> insert into prova values(1,'bbb');

$ cd ./oracle/product/11.1.0/bbdd/dbs/
$ joe prova_ts.dbf

cerquem dins del datafile la cadena 'aaa' o 'bbb' i no les trobem. L'explicació és que les operacions es mantenen i s'aguanten a la SGA (RAM), el procés DBWR encara no ha grabat aquesta informació als datafiles. Per obligar a executar el procés DBWR aturem la base de dades: 

SQL> shutdown immediate

$ joe prova_ts.dbf
...
@BB@B@@AC>@@@AC>@@,ABBACCbbb,ABBABCaaaAFV'F"@@P@@AR'Z@@@ADFN
...

i ara sí que veiem que s'han grabat les dades de l'usuari al datafile.

Poniendo los tablespaces offline

Llevar a un espacio de tablas al estado offline significa que se impide el acceso a los datos que almacena. El espacio de tablas SYSTEM nunca puede estar offline. Las razones para poner un espacio de tablas offline pueden ser varias: un error de escritura en los ficheros que lo soportan, el mover los ficheros de sitio, etc. Depués de realizar estas operaciones hay que poner otra vez disponible el espacio de tablas, esto es on line

Los espacios de tablas se pueden poner offline de tres modos: normal, temporary e immediate. Si no existe ningún error lo recomendable es poner el espacio de tablas offline usando el modo normal. Así, se colocará un checkpoint en el espacio de tablas antes de ponerlo offline. 

SQL> alter tablespace "PROVA_TS" offline normal;
Tablespace modificado.
SQL> select tablespace_name, status from user_tablespaces
TABLESPACE_NAME            STATUS
------------------------------ ------------------------------------
SYSTEM                   ONLINE
SYSAUX                   ONLINE
UNDOTBS1               ONLINE
TEMP                   ONLINE
USERS                   ONLINE
PROVA_TS               OFFLINE

Si alguno de los ficheros está corrupto, la opción normal fallará y se necesitará el modo temporary. La opción immediate se utilizará sólo cuando la BD está en modo ARCHIVELOG, ya que no se produce checkpoint alguno.

Poniendo los ficheros offline

No es normal poner los ficheros offline/online. Si un determinado fichero de datos se corrompe, se tendrá que pone offline, repararlo y ponerlo online de nuevo. Esta operación puede suponer sustituirlo por su copia de seguridad, lo que implicará ejecutar el comando recover datafile antes de poner el fichero online.

Esborrar un espai de taules 

SQL> DROP tablespace "PROVA_TS";
no deixa eliminar el tablespace perque hi ha objectes dins l'espai de taules.

DROP tablespace "PROVA_TS" INCLUDING CONTENTS;
Tablespace eliminado

Quan eliminem l'espai de taules, no s'esborren els datafiles associats (els hem d'esborrar amb les comandes del SO)

Només ens falta esborrar l'usuari de prova que hem creat: 

SQL> SELECT username FROM dba_users order by username;
SQL> DROP USER PROVA;

Segments, Extensions i Blocs

Los datos en la BD son almacenados físicamente en bloques Oracle: la mínima unidad de espacio físico, y es un múltiplo del bloque del SO (2 Kb usualmente). El tamaño del bloque Oracle se fija por el parámetro DB_BLOCK_SIZE del fichero init.ora. Un tamaño grande de bloque mejora la eficiencia del cache de E/S, pero el tamaño de la SGA aumentará para contener los mismos DB_BLOCK_BUFFERS, lo que significa un problema de memoria.

Una serie de bloques contiguos es una extensión, que es una unidad lógica de almacenamiento. Una serie de extensiones es un segmento. Cuando un objeto es creado, se reserva una extensión en su segmento. Cuando el objeto crezca, necesitará más espacio y se reservarán más extensiones.

Cada segmento tiene un conjunto de parámetros de almacenamiento que controla su crecimiento:

  • initial: tamaño de la extensión inicial (10k).
  • next: tamaño de la siguiente extensión a asignar (10k).
  • minextents: número de extensiones asignadas en el momento de la creación del segmento (1).
  • maxextents: número máximo de extensiones (99).
  • pctincrease: Porcentaje en el que crecerá la siguiente extensión antes de que se asigne, en relación con la última extensión utilizada (50).
  • pctfree: porcentaje de espacio libre para actualizaciones de filas que se reserva dentro de cada bloque asignado al segmento (10).
  • pctused: porcentaje de utilización del bloque por debajo del cual Oracle considera que un bloque puede ser utilizado para insertar filas nuevas en él.
  • tablespace: nombre del espacio de tablas donde se creará el segmento.

Cuando se diseña una BD se ha de tener mucho cuidado a la hora de dimensionar la BD y prever el crecimiento de las tablas. A continuación se hacen algunas consideraciones sobre la gestión del espacio para los diferentes segmentos.

Segmentos de Datos

El espacio del diccionario de datos se suele mantener más o menos constante, aunque es crítico que tenga suficiente espacio para crecer en el espacio de tablas SYSTEM. Así, hay que tener cuidado de colocar las tablas de usuario, los índices, segmentos temporales y los segmentos de rollback en otros espacios de tablas. Además, es recomendable que el espacio de tablas SYSTEM esté al 50% o 75% de su espacio disponible. Finalmente, asegurarse que los usuarios no tienen privilegios de escritura en el espacio de tablas SYSTEM.

Las tablas crecen proporcionalmente con el número de filas, ya que se puede suponer que la longitud de las filas es constante.

Segmentos de Índice

Los índices crecen en tamaño en mayor proporción que las tablas asociadas si los datos en la tabla son modificados frecuentemente. La gestión del espacio es mejor si se mantienen los índices de tablas grandes en espacios de tablas separados.

Segmentos de Rollback

Los segmentos de rollback almacenan la imagen anterior a una modificación de un bloque. La información en el segmento de rollback se utiliza para asegurar la consistencia en lectura, el rollback (el valor en el segmento de rollback se copia en el bloque de datos) y la recuperación.

Es importante comprender cual es el contenido de un segmento de rollback. No almacenan el bloque de datos modificado entero, sólo la imagen previa de la fila o filas modificadas. La información del segmento de rollback consiste en varias entradas llamadas undo. Por ejemplo, si se inserta una fila en una tabla, el undo necesitará sólo el rowid de la fila insertada, ya que para volver atrás la insercion sólo hay que realizar un delete. En las operación de actualización, se almacenará el valor antiguo de las columnas modificadas. El segmento de rollback asegura que la información undo se guardan durante la vida de la transacción.

Un segmento de rollback como cualquier otro segmento consiste en una serie de extensiones. Sin embargo, la mayor diferencia entre un segmento de datos y otro rollback es que en este último las extensiones se utilizan de manera circular. Así, habrá que tener cuidado a la hora de fijar el tamaño del segmento de rollback para que la cabeza no pille a la cola.

Segmentos Temporales

Los segmentos temporales se crean cuando se efectuan las siguientes operaciones:

  • Create Index
  • Select con distinct, order by, union, intersect y minus.
  • uniones no indexadas.
  • Ciertas subconsultas correlacionadas.

Si las tablas a ordenar son pequeñas la ordenación se realiza en memoria principal, pero si la tabla es grande se realiza en disco. El parámetro SORT_AREA_SIZE determina el lugar donde se hace la ordenación. Incrementándole se reduce la creación de segmentos temporales.

Configuració de la BD

Mientras se diseña la BD hay que considerar la posible recuperación de una caida, y las prestaciones de la BD, relacionando todo esto con las necesidades de la implantación y los medios disponibles. La configuración de la BD está relacionada con los ficheros de control, los ficheros redo log activos y los archivados.

Gestionant els Fitxers de Control

Los ficheros de control contienen el esquema de la BD. Es uno de los más importantes ficheros e imprescindible para el uso normal de la BD. Así que daremos alguna pista para su gestión.

El parámetro CONTROL_FILES del fichero init.ora contiene la lista de todos los ficheros de control. Cuando se arranca la BD, Oracle lee el fichero init.ora para determinar cuántos ficheros de control se usan en la BD y dónde están. Durante la fase de montaje, se abren los ficheros de control para leer el esquema de la BD. Aunque Oracle escribe en todos los ficheros de control, sólo lee el primero listado en el parámetro CONTROL_FILES.

Para protegerlos contra fallos de almacenamiento, se sugiere que al menos existan dos ficheros de control, cada uno en un disco diferente, aunque es buena idea mantener más copias en diferentes discos. Esto es una política de espejado que protege frente a fallos en disco. Si un disco falla y se pierden todos los ficheros en él, se puede seguir utilizando los ficheros de control de otros discos. Esto supone una pequeña sobrecarga al sistema, ya que cada vez que se porduce un checkpoint o cambia el esquema de la BD, todos los ficheros de control son actualizados.

Cuando se produce un fallo en algún disco y algún fichero de control se pierde hay que parar la BD con la opción abort, copiar el fichero de control que queda en otro disco, editar el fichero init.ora para reflejar este cambio, y volver a levantar la BD.

Si un fallo ha producido la pérdida de todas las copias de los ficheros de control habrá que recrearlos con el comando create controlfile. Si algunos de los parámetros MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHISTORY, MAXDATAFILES y MAXINSTANCES varía habrá que utilizar también el comando CREATE CONTROLFILE.

Gestionant els Fitxers Redo Log Actius

Oracle proporciona la posibilidad de espejar los ficheros redo log activos. Mecanismo conocido como ficheros redo log multiplexados. Oracle necesita al menos dos grupos de fricheros redo log, cada uno con un miembro como mínimo. Oracle efectua escrituras en paralelo a cada miembro, pero si están en el mismo disco, realmente la escritura se serializa.

Otro aspecto a tener en cuenta es el tamaño de los ficheros redo log. Si son muy pequeños, el LGWR deberá cambiar de ficheros demasiado frecuentemente, lo que reduce su rendimiento. Por otro lado, si los ficheros redo log son demasiado grandes, se necesitará mucho tiempo en las recuperaciones, ya que se tendrán que recuperar muchas transacciones.

Otro aspecto muy importante es la elección del número correcto de grupos, ya que disponer de demasiados pocos grupos puede acarrear problemas cuando estámos en modos ARCHIVELOG y tenemos una tasa de transacciones muy alta. Esto puede suponer que un grupo que todavía está archivando por el proceso ARCH se convierta en el grupo en el que el LGWR necesite escribir, lo que produciría que la BD se parara, ya que el LGWR tienen que esperar a que el grupo esté disponible, una vez que su contenido ha sido archivado. Para la mayoría de las implantaciones, tener entre 2 y 10 grupos puede ser suficiente. El número de grupos no puede exceder de MAXLOGFILES, ni el número de miembros puede ser mayor que MAXLOGMEMBERS.


creat per Joan Quintana Compte, novembre 2009

Obtingut de «http://wiki.joanillo.org/index.php?title=Arquitectura_Oracle&oldid=3929»