curso de dba oracle

Upload: luchofigueroa

Post on 12-Jul-2015

1.567 views

Category:

Documents


4 download

DESCRIPTION

Curso rápido de administración de bases de datos

TRANSCRIPT

Curso

Dba para Desarrolladores

Impartido por: Luis Figueroa Santa Cruz de la Sierra, Bolivia Setiembre 1999

ndiceNDICE .............................................................................................................................................................. 2 ORACLE, ARQUITECTURA INTERNA Y EXTERNA ..............................................................................4 CONCEPTOS GENERALES .................................................................................................................................4 BASES DE DATOS .............................................................................................................................................5 TABLESPACES ..................................................................................................................................................6 ARCHIVOS O DATA FILES .................................................................................................................................6 INSTANCIAS ..................................................................................................................................................... 7 ESTRUCTURAS INTERNAS DE LA BASE DE DATOS ............................................................................................ 7 ORACLE, ARQUITECTURA INTERNA Y EXTERNA ............................................................................ 14 SECUENCIAS .................................................................................................................................................. 14 PROCEDIMIENTOS .......................................................................................................................................... 14 FUNCIONES .................................................................................................................................................... 14 PAQUETES ALMACENADOS ............................................................................................................................ 15 TRIGGERS ...................................................................................................................................................... 15 DATABASE LINKS ........................................................................................................................................... 16 SINNIMOS .................................................................................................................................................... 16 PRIVILEGIOS Y ROLES .................................................................................................................................... 17 SEGMENTS, EXTENTS Y BLOCKS ..................................................................................................................... 18 ROLLBACK SEGMENTS ................................................................................................................................... 19 ORACLE, ARQUITECTURA INTERNA Y EXTERNA ............................................................................ 20 ESTRUCTURAS INTERNAS DE MEMORIA ......................................................................................................... 20 ESTRUCTURAS EXTERNAS ............................................................................................................................. 26 CONSIDERACIONES DE HARDWARE Y CONFIGURACIN............................................................. 28 VISIN GENERAL DE LA ARQUITECTURA ....................................................................................................... 28 SERVIDORES INDEPENDIENTES (STAND-ALONE HOSTS) ................................................................................ 29 SERVIDORES INDPENDIENTES CON ARREGLOS DE DISCOS ............................................................................ 30 SERVIDOR INDEPENDIENTE CON ESPEJEO DE DISCOS VIA SISTEMA OPERATIVO .............................................. 32 SERVIDORES INDEPENDIENTES CON MLTIPLES BASES DE DATOS .................................................................. 32 SERVIDORES ENLAZADOS EN RED .................................................................................................................. 33 PLANEAMIENTO LGICO DE LA BASE DE DATOS ........................................................................... 36 OPTIMAL FLEXIBLE ARQUITECTURE (OFA) .................................................................................................. 36 PLANEAMIENTO FSICO DE LA BASE DE DATOS .............................................................................. 40 DISTRIBUCIN DE LOS ARCHIVOS DE LA BASE DE DATOS ............................................................................... 40 CONTENCIN DE I/O ENTRE LOS DATAFILES .................................................................................................. 40 CUELLOS DE BOTELLA DE I/O ENTRE TODOS LOS ARCHIVOS DE LA BASE DE DATOS....................................... 41 I/O CONCURRENTE ENTRE LOS PROCESOS DE BACKGROUND .......................................................................... 42 UTILIZACIN DEL ESPACIO DENTRO DE LA BASE DE DATOS............................................................................ 46 OPERACIONES RUTINARIAS DE MANEJO FSICO DE ARCHIVOS DE ORACLE ..................................................... 53 LABORATORIO, INSTANCIAS Y TABLESPACES................................................................................. 55 LABORATORIO, ERRORES, CAMBIAR TAMAO DE DATAFILES, MOVER DATAFILES, SCRIPT GENRICOS. .................................................................................................................................. 61 PROVOCAR UN ERROR IRRECUPERABLE.... ..................................................................................................... 61 MOVER DATAFILES, CAMBIO DE TAMAO Y AGREGAR DATAFILES................................................................. 61 VARIOS SCRIPTS ............................................................................................................................................. 62

AFINAMIENTO DEL SQL............................................................................................................................ 64 AFINANDO SINTAXIS ...................................................................................................................................... 65 EXPLAIN PLAN .......................................................................................................................................... 72 OPTIMIZADORES DE ORACLE ......................................................................................................................... 73 AFINAMIENTO DE LA UTILIZACIN DE MEMORIA......................................................................... 77 CMO DETERMINAR CUANDO RECONSTRUIR NDICES? ................................................................................. 82 UTILIZACIN DE UTLBSTAT Y UTLESTAT ............................................................................................... 83 SQL TRACE FACILITY .................................................................................................................................... 83 LABORATORIO, TUNING SQL .................................................................................................................. 87 LABORATORIO, TKPROF Y OTROS SCRIPTS...................................................................................... 90 SEGURIDAD Y AUDITORA ....................................................................................................................... 92 CAPACIDADES DE SEGURIDAD ....................................................................................................................... 92 IMPLEMENTANDO LA SEGURIDAD .................................................................................................................. 93 AUDITANDO ................................................................................................................................................. 100 RESPALDO Y RECUPERACIN .............................................................................................................. 102 RESPALDOS LGICOS ................................................................................................................................... 102 RESPALDOS FSICOS ..................................................................................................................................... 103 IMPLEMENTACIN........................................................................................................................................ 104 OFFLINE BACKUPS ....................................................................................................................................... 107 BLOQUEOS .................................................................................................................................................. 110 DEADLOCKS ................................................................................................................................................ 111 LABORATORIO, AUDITORIA, RESPALDO Y RECUPERACION ..................................................... 114 AUDITORA Y SEGURIDAD ............................................................................................................................ 114 RESPALDO Y RECUPERACIN ....................................................................................................................... 115 BIBLIOGRAFA ........................................................................................................................................... 116

Oracle, arquitectura interna y externaConceptos GeneralesOracle es una base de datos relacional, con una gran diversidad de herramientas para desarrollo de aplicaciones, administracin de la base de datos y herramientas de conectividad en redes (incluyendo el WEB). Una de las grandes confusiones que tiene cualquier persona que comienza a trabajar con Oracle es el confundir los diferentes productos que mercadea Oracle Corporation, mucha gente tiende a confundir o denominar Oracle a todos los productos y esto lleva a confusiones con los usuarios y entre las mismas personas de sistemas. Para aclarar este tema a continuacin detallo a continuacin algunos de los productos de Oracle y su clasificacin para que quede claro dnde se ubica exactamente el producto Oracle Database Server con respecto a toda la gama ofrecida por Oracle. Productos de Base de Datos Oracle Database Server Oracle Security Server Oracle Parallel Server ... Developer/2000 Designer/2000 Browser ... SQL*Net 2.3 Net8 Oracle Web Server

Productos de Desarrollo de Aplicaciones

Productos de Conectividad en Redes

El modelo relacional empleado por Oracle, est bastante probado y su definicin terica tiene ms de 20 aos de haber sido propuesta. Sin embargo no fue sino hasta bien entrados los aos 80 que fue posible dar soporte real a toda la teora relacional, gracias al abaratamiento de los discos duros y la memoria, ya que el modelo relacional requiere mayores cantidades de estos recursos que los modelos anteriores de bases de datos como el jerrquico y de redes.

Para aclarar trminos que emplearemos en el resto del curso veamos el siguiente esquema: Por ejemplo veamos una tabla tpica de departamentos en una empresa: Nombres de las columnas

Num_depto Filas 1 o Rows 2 de datos 3 4

Nombre Ventas Produccin Administracin Cmputo

Localizacin Santa Cruz Cochabamba La Paz Santa Cruz

Columnas de datos Para accesar a estos datos, se utiliza un lenguaje de consultas denominado SQL, el cual es un estndar utilizado por la mayora de manejadores de bases de datos a nivel mundial, sin embargo, Oracle a este SQL bsico le ha agregado una gran variedad de funcionalidad adicional lo cual lo hace el manejador de base de datos ms popular hoy da. El manejador de la base de datos utiliza estadsticas, ndices y ayudas provistas por el programador para extraer la informacin solicitada por un usuario, a este proceso se le denomina Optimizador y ser visto durante el transcurso del curso. Lo importante a tener en cuenta es que siempre que se hace una consulta hay un proceso intermedio que se encarga de determinar donde, cmo y qu datos traer de la base de datos.

Bases de DatosUna base de datos es un conjunto de datos. Oracle provee la habilidad de almacenar y accesar los datos de una manera consistente con el modelo relacional. Debido a que Oracle es referido como una base de datos relacional, cuando digamos base de datos nos referiremos no slo a los datos fsicos sino tambin a la combinacin de datos, memoria y procesos que explicaremos a continuacin. Los datos en una base de datos estn almacenados en tablas, las tablas relacionales estn definidas por sus columnas las cuales tienen un nombre. Los datos se almacenan en filas dentro de la tabla. Las tablas pueden relacionarse unas con otras y la base de datos puede ser usada para obligar a cumplir con estas relaciones. Internamente, Oracle almacena los datos en archivos, existen estructuras de la base de datos que proveen un mapeo lgico entre los datos y estos archivos, permitiendo que diferentes tipos de datos puedan ser almacenados en forma separada. Estas divisiones lgicas se llaman tablespaces.

TablespacesUn tablespace es una divisin lgica de la base de datos, cada base de datos tiene al menos un tablespace llamado SYSTEM, otros tablespaces pueden ser usados para agrupar usuarios o aplicaciones por facilidad de administracin asi como por beneficios de rendimiento que explicaremos luego. Un tablespace SOLO puede pertenecer a una base de datos.

Archivos o Data FilesCada tablespace est compuesto de uno o ms archivos llamados datafiles en disco. Un datafile slo puede pertenecer a un tablespace. Una vez que un datafile a sido agregado a un tablespace, no puede ser borrado del tablespace y no puede ser asociado con otro tablespace. Si se almacenan multiples objetos de base de datos en mltiples tablespaces, entonces se pueden separar fsicamente a nivel fsico colocando sus respectivos datafiles en discos separados. Esta separacin de datos es una herramienta importante de planeamiento y afinamiento de la forma en que la base de datos utiliza el I/O del servidor. Para ilustrar estas relaciones veamos el siguiente esquema: Base de Datos SYSTEM Tablespace Segundo Tablespace Tercer Tablespace

Tablespaces

Datafiles

InstanciasPara accesar los datos en la base de datos, Oracle utiliza un conjunto de procesos concurrentes que son compartidos por todos los usuarios. Adems existen estructuras de memoria que son utilizadas para almacenar los datos de las consultas ms recientes. Estas reas de memoria ayudan a mejorar el rendimiento de la base de datos decrementando la cantidad de I/O realizado contra los datafiles. Una instancia de base de datos es un conjunto de estructuras de memoria y procesos concurrentes que accesa un conjunto de archivos de base de datos. Los parmetros que determinana el tamao y composicin de una instancia son almacenados en un archivo llamado init.ora. Este archivo es ledo durante el arranque de la base de datos y puede ser modificado or el DBA. Cualquier modificacin hecha a este archivo hasta la prxima vez que se arranque la base de datos. El archivo init.ora normalmente se llama init+nombre de la instancia.ora, asi por ejemplo si la base de datos se llama DESA, entonces el archivo de configuracin se llamar initDESA.ora. Un segundo archivo de configuracion, config.ora, es usado para almacenar caracteristicas que NO cambian despues de creada la base de datos, tales como el tamao del bloque. Al igual que el init.ora, siguiendo el ejemplo el config.ora se llamar configDESA.ora. Para que la configuracion del config.ora sea utilizada, en el init.ora debe haber un parametro que se llama IFILE el cual debe tener el nombre y ruta del config.ora. En resumen de un mismo servidor podra haber ms de una instancia de Oracle, pero slo una copia del software de base de datos. Aunque lo ms comun es que haya una instancia por servidor y dependiendo del tamao de la empresa varios servidores cada uno con una instancia de Oracle, corriendo cada uno distintos conjuntos de datos, por ejemplo un servidor con el sistema de Recursos Humanos y otro con el sistema de Administracin Financiera.

Estructuras internas de la Base de DatosDado lo que hemos visto hasta ahora, las estructuras de la base de datos Oracle pueden dividirse en tres categoras: Aquellas que son internas a la base de datos (como las tablas) Aquellas que son internas a las reas de memoria (como areas compartidas de memoria y los procesos. Aquellas externas a la base de datos (como los datafiles) A continuacin detallaremos el primer conjunto de estructuras, las internas.

Tablas, columnas y tipos de datosLas tablas son el mecanismo para almacenar datos dentro de una base de datos Oracle. Poseen un nmero fijo de columnas, las columnas de una tabla describen los atributos de una entidad que est siendo mapeada a una tabla. Cada columna tiene un nombre y caractersticas especficas. Las caractersticas de una columna se componen de dos partes: el tipo de datos y la longitu. Para columnas de tipo NUMBER, se puede especificar adems la precisin y la escala. La precisin determina el numero de dgitos significativos y la escala determina la posicin del punto decimal. Una especificacin de NUMBER(8,2) para una columna indica un total de ocho digitos, dos de los cuales estn a la derecha del punto decimal. La precisin por defecto es de 38 dgitos, la cul tambin es la mxima precisin. A continuacin detallaremos los tipos de datos vlidos en ORACLE (8.0.5): Tipo de Datos CHAR VARCHAR Descripcin Un campo de longitud FIJA de hasta 2000 caracteres. Actualmente es un sinnimo de varchar2, pero su funcionalidad puede cambiar en futuras versiones de Oracle. No obstante se recomienda utilizar varchar2 para literales de longitud variable. Un campo de longitud variable de hasta 4000 caracteres Es un campo fijo de 7 bytes usado para almacenar fechas. El tiempo tambin es almacenado como parte de la fecha. Una columna numrica de longitud variable. Los valores permitidos son: cero y valores positivos y negativos de 1.0E-130 hasta 9.99E125 Es un campo de longitud variable de hasta 2GB. Un campo de longitud variable utilizado para datos binarios de hasta 4000 caracteres. Es un campo de longitud variable para datos binarios de hasta 2GB. Se utiliza en una version especial de Oracle llamada Trusted Oracle Objetos binarios grandes de hasta 4GB de longitud. Objetos carcter grandes de hasta 4GB de longitud. CLOB para conjuntos multicaracteres (japons, chino, etc) de hasta 4GB. Archivos binarios externos, su tamao est limitado por el sistema operativo donde corre Oracle.

VARCHAR2 DATE NUMBER

LONG RAW LONG RAW MLSLABEL BLOB CLOB NCLOB BFILE

Ademas de estos tipos de datos, en Oracle8 se pueden definir tipos de datos creados por el usuario segn se requiera, aunque siempre basados en los explicados anteriormente que son los bsicos.

Restricciones o ConstraintsUna tabla puede tener constraints sobre ella, cuando un constraint es aplicado a una tabla, cada fila de la tabla debe satisfacer las condiciones especificadas en la definicin del constraint. En el siguiente create table, se crea una tabla empleados con varios constraints: Create table employee (empno number(10) primary key, name varchar2(40) not null, deptno number(2) default 10, salary number(7,2) check salary < 1000000, birth_date date, soc_sec_num char(9) unique foreign key(deptno) references dept.deptno) tablespace users; Primero, notemas que a la tabla se le da el nombre de EMPLOYEE, cada columna tiene un nombre (empno, name, etc), cada columna tiene un tipo de datos y una longitud. La llave primaria de la tabla es un constraint que se utiliza para identificar en forma nica cada fila, en el ejemplo definimos el empno como su llave primaria. Por otro lado vemos el constraint NOT NULL aplicado al nombre, esto significa que la base de datos validar que no sea posible meter un empleado con nombre nulo. Otro constraint interesante es el unique, el cual hace que el campo soc_sec_num sea unico dentro de la tabla, esto lo implemente la base de datos creando un ndice nico. Por ltimo tenemos el constraint foreign key, este se utiliza para que la base de datos valide la integridad referencial automticamente, esto es que el usuario no pueda crear un empleado en un departamento inexistente!. En la vida real muchas veces se requiere por ejemplo conocer todos los empleados de un departamento, es por esto que casi siempre que un campo se utiliza para hacer referencia tambin se crea un ndice por este campo para mejorar el rendimiento de consultas tpicas; en el caso de nuestro ejemplo deberamos crear un indice por deptno en la tabla EMPLOYEE.

Tipos de Datos AbstractosA partir de Oracle8, se pueden definir tipos de datos propios. Por ejemplo se puede crear un tipo de datos que contenga mltiples partes del nombre de una persona como un solo tipo de datos: Create type name_ty as object (name varchar2(25), primer_apellido varchar2(30), segundo_apellido varchar2(30));

Se puede utilizar los tipos de datos definidos por el usuario para estandarizar el uso de datos dentro de nuestras aplicaciones. Por ejemplo se puede utilizar el tyipo name_ty en lugar de otros tipos de datos: Create table employee (empno number(10) primary key name name_ty, deptno number(2) default 10, salary number(7,2) check salary < 1000000, birth_date date, soc_sec_num char(9) unique foreign key(deptno) references dept.deptno) tablespace users;

ParticionesA partir de Oracle8 se pueden especificar rangos que la base de datos utiliza para partir una tabla muy grande en tablas ms pequeas. Estas tablas ms pequeas, llamadas particiones, son ms fciles de manejar que tablas muy grandes. Por ejemplo, podemos utilizar el truncate sobre una particion sin truncar los datos de otras particiones. Las particiones tambien mejoran el rendimiento de una aplicacin. Debido a que el optimizador conoce los rangos de valores usados para crear la particin, es capaz de dirijir las consultas para utilizar slo ciertas particiones durante el acceso a las tablas. Como se leen menos datos durante el procesamiento de la consulta, el rendimiento de la consulta mejora. Tambin se pueden particionar ndices igual que las tablas. Si los rangos de valores de las particiones del indice son los mismos de la tabla particionada se llama un local index; si las particiones del ndice son diferentes a las de la tabla se llama un global index.

Un ejemplo de tabla particionada sera: create table employee( empno number(10) primary key, name varchar2(40), deptno number(2), salary number(7,2), birth_date date, soc_sec_num varchar2(9), constraint fk_deptno foreign key(deptno) references dept(deptno)) partition by range(deptno) ( partition part1 values less than (11), tablespace part1_ts, partition part2 values less than (21), tablespace part2_ts, partition part3 values less than (31), tablespace part3_ts, partition part4 values less than (MAXVALUE), tablespace part4_ts);

UsuariosUna cuenta de usuario no es una estructura fsica en la base de datos, pero tiene una gran importancia en sus relaciones con los objetos en la base de datos, los dueos de los objetos son usuarios. Asi por ejemplo el usuario SYS posee el diccionario de datos, donde se almacena informacin sobre el resto de estructuras de la base de datos. Cuando se crean los objetos de una aplicacin, se crean bajo una cuenta de usuario, adems a cada cuenta de usuario se le puede especificar el tablespace por defecto que debe utilizar.

EsquemasUn conjunto de objetos propiedad de una cuenta de usuario se llama esquema. Se pueden crear cuentas de usuarios que no tengan la capacidad de conectarse a la base de datos. Tales cuentas de usuario proveen un esquema para contener un conjunto de objetos separado de los esquemas de usuarios. Por ejemplo si tenemos un Sistema de Inventarios y creamos un usuario INV para almacenar sus objetos, INV sera un esquema, el cual no debe ser accesado directamente por INV excepto en la creacin; en produccin slo debe ser accesado por usuarios con permisos para hacerlo.

ndicesEn una base de datos relacional, la localizacin fsica de una fila es IRRELEVANTE, a menos por supuesto que la base de datos necesite encontrarla. Para que sea posible encontrar los datos, cada fila en la tabla tiene un pseudocolumna llamada RowID. Este RowID le indica a la base de datos exactamente donde se encuentra la fila (por archivo, bloque dentro del archivo y fila dentro del bloque). Un ndice es una estructura utilizada por el servidor para encontrar una fila rpidamente dentro de una tabla. Existen tres tipos de ndices: ndices de cluster, ndices de tablas y ndices bitmap. Un ndice contiene una lista de entradas, cada entrada consiste de un valor llave y un RowId. El valor llave es el valor de una columna en una fila o la combinacin de varias. Las entradas en los ndices de cluster y tablas son almacenados utilizando estructuras B*tree garantizando una ruta de acceso corta al valor llave. El I/O requerido para encontrar una llave es mnimo y una vez encontrado el RowID es utilizado para accesar directamente la fila. Los ndices se utilizan para mejorar el rendimiento y para asegurar la unicidad de una columna. Oracle automticamente crea un ndice cuando se especifican las clasulas UNIQUE o PRIMARY KEY en un create table. Adems se pueden crear ndices adicionales utilizando el comando create index. A partir de la versin 7.3 de Oracle se pueden crear ndices bitmap, los cuales son muy tiles cuando los datos en alguna columna no son muy selectivos, o sea que la columna tiene pocos valores distintos. Los ndices bitmap incrementan la velocidad de bsqueda cuando se requiere buscar datos por esas columnas. Los ndices bitmap son ms efectivos cuando los datos almacenados en estas columnas son bastante estticos, por ejemplo el tipo de sexo. Un ejemplo de cmo crear un ndice bitmap sera: create bitmap index IND_BITMAP_STAT_COD_EMPLOYEE on EMPLOYEE(state_code); Grficamente un ndice bitmap se puede expresar como: FL: CA: cada nmero representa una fila en la tabla EMPLOYEE. Debido a que hay 10 filas consideradas hay 10 valores bitmap mostrados. El optimizador de Oracle puede dinmicamente convertir las entradas de un ndice bitmap a valores de RowID durante el procesamiento de la consulta, esta capacidad de conversin le permite al optimizador utilizar indices normales en conjunto con los bitmap. Cuando se crean indices bitmap, Oracle comprime los bitmaps almacenados, como resultado el espacio requerido para un ndice de este tipo puede ser de slo 5 o 10% del espacio requerido por ndice normal.

VistasUna vista se parece a una tabla porque tiene columnas y es consultada de la misma forma que una tabla. Conceptualmente, una vista puede ser vista como una mscara que se sobrepone a una o ms tablas, tales que las columnas de la vista estn basadas en un o ms tablas subyacentes. La definicin de una vista (la cual incluye la consulta en la que est basada, el formato de las columnas y los privilegios respectivos) est almacenada en el diccionario de datos. Cuando una vista es consultada, se consultan las tablas en las que est basada y retorna los valores en el formato y orden especificados en la definicin de la vista. Debido a que no hay datos fsicos asociados con ellas, las vistas NO pueden ser indexadas. Las vistas son frecuentemente utilizadas para forzar la seguridad a nivel de filas sobre los datos, por ejemplo se puede crear una vista para que cada empleado SOLO pueda ver los datos de la tabla EMPLOYEE propios. Por ejemplo, supongamos la siguiente tabla USUARIOS_X_DEPTNO y la tabla EMPLOYEE: create table usuarios_x_deptno( empno number(10), username varchar2(10)); ahora podramos crear una vista V_EMPLOYEE: create or replace view v_employee as select * from employee e where empno in (select empno from usuarios_x_deptno where username = USER); Este esquema puede ser manipulado de acuerdo a las necesidas propias de cada institucin o empresa y aplicacin.

Oracle, arquitectura interna y externaSecuenciasLas secuencias son definiciones tambin almacenadas en el diccionario de datos. Las secuencias son utilizadas para simplificar la programacin proveyendo un lista secuencial de nmeros nicos. La primera vez que una secuencia es utilizada en una consulta, retorna un valor predeterminado; con cada subsecuente llamada es incrementada en un incremento especfico, normalmente 1. Las secuencias puede ser cclicas o pueden seguir incrementndose hasta que se alcanze un mximo especificado. Un ejemplo de secuencia podra ser: create sequence s_empleados Start with 1 increment by 1;

ProcedimientosUn procedimiento es un bloque PL/SQL que es almacenada en el diccionario de datos y es llamado por las aplicaciones segn se requiera. Los procedimientos permiten almacenar la lgica de las aplicaciones ms utilizada dentro de la base de datos. Cuando el procedimiento es ejecutado, sus sentencias son ejecutadas como una unidad. Los procedimientos no retornan un valor al programa que los llam. Los procedimientos almacenados pueden servir para reforzar la seguridad de los datos. Para lograr esto, no de grants directos de acceso a tablas a los usuarios dentro de una aplicacin. En lugar de esto, deles permiso de ejecutar procedimientos aque accesen las tablas. Cuando el procedimiento es ejecutado, se ejecuta con los privilegios del dueo del procedimiento. De esta manera los usuario sern incapaces de accesar las tablas excepto va el procedimiento.

FuncionesLas funciones as como los procedimientos son bloques de cdigo que es almacenado en la base de datos. Diferente a los procedimientos, las funciones retornan un valor al programa que las llama. Incluso pueden ser utilizadas dentro de sentencias SQL al igual que las funciones provistas por el SQL de Oracle. Por ejemplo, Oracle provee una funcin llamada substr que extrae hileras de otras hileras. Si creamos una funcion que se llama mi_substr que hace algo diferente, podramos utilizarla en un select de esta forma:

Select mi_substr(text) from dual; Slo se puede utilizar una funcin dentro una sentencia SQL si la funcin no modifica ninguna fila de la base de datos.

Paquetes AlmacenadosLos paquetes son utilizados para conjuntar procedimientos y funciones en grupos lgicos. Son muy tiles ya que facilitan la administracin al conjuntar gran cantidad de procedimientos y funciones. Tienen un efecto secundario que debemos considerar, el cual es que como son almacenados en el diccionario de datos, es probable que entre ms lgica pongamos en la Base de Datos, haya que agrandar el tablespace SYSTEM. Por otra parte, los paquetes tienen la ventaja de ser compilados, por lo que su ejecucin es mucho ms rpida, adems por estar en la base de datos permanecen en memoria mientras sta no sea utilizada para otros efectos, con lo que un segundo y posteriores usuarios que hagan uso de un paquete lograrn ejecuciones mucho ms rpidas.

TriggersLos triggers son procedimientos que son ejecutados cuando sucede un evento especificado contra una tabla de la base datos. Se pueden utilizar para aumentar la integridad referencial, reforzar la seguridad o mejorar las opciones de auditora. Existen dos tipos de triggers: Statement triggers: Row triggers Se disparan una vez por cada sentencia. Se disparan una vez por cada fila afectada en la sentencia.

Para cada uno de estos tipos se puede crear un trigger AFTER y uno BEFORE para cada evento disparador que son tres: INSERT, UPDATE y DELETE.

Database linksLas bases de datos Oracle tienen la capacidad de referenciar datos que se encuentran fuera de la base de datos local. Cuando se referencian tales datos, se debe calificar el objeto remoto en forma completa. Las ligas de base de datos pueden ser pblicas (disponibles para todas las cuentas de la base) o privadas (solo para el usuario que la cre). Cuando se crea una liga de base de datos se debe indicar el usuario y el password a la que se desea conectar as como el nombre del servicio (SQL*Net tnsnames.ora) asociado a la base de datos remota. Si no se indica el usuario y el password, Oracle intentar conectarse con el usuario y password locales, los cuales de no existir en la base de datos remota producir un error. Por ejemplo: Create public database link mi_liga Connect to HR identified by ab1yu Using DBONE;

SinnimosPara identificar completamente un objeto de base de datos en una base de datos distribuda, se debe especificar el servidor, la instancia, el dueo y el nombre del objeto. Dependiendo de la localizacin del objeto entre uno y cuatro de estos parametros son requeridos. Para aislar este proceso del usuario y proveer un acceso transparente al usuario sin importar dnde se encuentren los datos se utilizan los sinnimos. Existen sinonimos pblicos (vistos por todos los usuarios) y sinnimos privados (vistos slo por el dueo del sinnimo). Por ejemplo supongamos que la tabla EMPLOYEE est bajo el usuario HR, si no existieran los sinnimos un usuario cualquiera tendria que digitar: select * from HR.EMPLOYEE; En cambio si creamos un sinnimo como: create public synonym employee for hr.employee; el usuario no tendra que importarle quien sea el dueo del objeto y digitara: select * from EMPLOYEE; ahora bien, la utilidad de los sinnimos va ms all; cuando tenemos ambientes realmente grandes en el que tenemos varios servidores, utilizamos los sinnimos para aislar al usuario de esta complejidad utilizando sinnimos y ligas de base de datos: create public synonym EMPLOYEE for hr.employee@mi_liga;

Privilegios y rolesPara accesar los objetos posedos por otra cuenta de usuario, se debe haber dado previamente el privilegio de accesar ese objeto. Los permisos ms comunes son insert, update, delete los cuales se otorgan sobre tablas a un usuario o rol. Tambin existe el privilegio execute para paquetes, funciones y procedimientos almacenados. Para utilizar los ndices y triggers no se dan privilegios ya que son subyacentes a las tablas mismas. Ahora bien, en una empresa o institucin existe la rotacin de personal, algo inevitable tanto como la vida y la muerte, por lo tanto si construimos un esquema de privilegios slo sobre usuarios, cuando alguno de stos abandone la empresa o cambie de puesto, la seguridad tendr que recrearse o corremos el riesgo de dejar portillos abiertos al fraude. Por esta razn existen los roles (puestos) estos nos ayudan a agrupar y definir nuestra seguridad de acuerdo a un organigrama oficial de la empresa y luego asignamos o revocamos estos roles a los usuarios segn sea necesario. Ahora veamos un caso, de un departamento tpico de contabilidad: create role r_contador_general; create role r_auxiliar_contable; create role r_secretaria_conta; digamos que tenemos las tablas: cg_maestro_cuentas, cg_movimientos, cg_resumenes podemos definir el siguiente esquema de seguridad: grant select, insert, update, delete on cg_maestro_cuentas to r_contador_general; grant select, update on cg_maestro_cuentas to r_auxiliar_contable; grant select on cg_maestro_cuentas to r_secretaria_conta; ... ahora supongamos que existen los usuarios: juan, pedro, javier, jose y maria: grant r_contador_general to juan; grant r_auxiliar_contable to pedro, javier, jose; grant r_secretaria_conta to maria; supongamos que jose renuncia y contratan a carlos para sustituirlo, la actualizacin ser muy simple: revoke r_auxiliar_contable from jose; grant r_auxiliar_contable to carlos;

Segments, extents y blocksLos segmentos son la contraparte fsica de los objetos lgicos de la base de datos, los segmentos almacenan datos. Los segmentos de ndice, por ejemplo almacenan los datos asociados con los ndices. El manejo efectivo de los segmentos requiere que el DBA conozca los objetos que utiliza una aplicacin, cmo se ingresan los datos y las maneras en que son accesados. Debido a que un segmento es un entidad fsica, debe estar asignado a un tablespace en la base de datos. Un segmento se construye de secciones llamadas extents, que son un conjunto contiguo de bloques de Oracle. Cada vez que los extents de un segmento ya dan cabida a nuevos datos, el segmento obtiene un nuevo extent. Este proceso de extensin contina hasta que no haya ms espacio libre en el tablespace o hasta que un mximo nmero de extents para el objeto sea alcanzado. Si un segmento tiene mltiples extents, no hay garanta de que estos extents sean contiguos. Ahora bien, Oracle utiliza para grabar y leer una medida llamada block, esta se debe definir como mnimo igual al tamao del bloque utilizado por el Sistema Operativo, 4096 bytes en la mayora de equipos hoy da. Toda lectura o escritura se realiza en terminos de bloques, o sea que siempre se lee o escribe como mnimo un bloque. Es por esto que en bases de datos con mucha demanda de I/O se configura la base de datos con un tamao de bloque que sea mltiple del del sistema operativo por ejemplo 8K o 16K. Detalle de la relacin entre segmentos, extents y bloques.

Caractersitcas de un bloque de datos:

Rollback segmentsPara mantener la consistencia de lectura entre mltiples usuarios en la base de datos y para tener la capacidad de deshacer transacciones, Oracle debe tener un mecanismo para recontruir una imagen antes de de los datos que an no se han grabado. Oracle usa los rollback segments para cumplir con este propsito. Los segmentos de rollback crecern tanto como las transacciones que soportan. Una transaccin cualquiera en el sistema toma un segmento de rollback cuando empieza y ese ser el que utilize durante la vida de la transaccin. En un ambiente de produccin debe haber en promedio un segmento de rollback por cada cinco usuarios de modo que no haya mayores problemas con su manejo.

Oracle, arquitectura interna y externaEstructuras Internas de MemoriaExisten dos tipos de estructuras de memoria diferentes utilizadas por Oracle: reas globales y procesos concurrentes (background process). Empezaremos estudiando las estructuras de memoria globales utilizadas por todos los usuarios de la base de datos.

System Global Area (SGA)Facilita la transferencia de informacin entre los usuarios. Adems contiene la informacin consultada mas comunmente acerca de la estructura de la base de datos.

Data Block Buffers

Redo Log Buffers

Dictionary Cache

Shared SQL Pool

Data Block Buffer CacheEl data block buffer cache es un cache dentro del SGA usado para contener los bloques de datos que son ledos desde la base de datos, tales como tablas, ndices, y clusters. El tamao del data block buffer cache es determinado por el parmetro DB_BLOCK_BUFFERS (del init.ora), expresado en trminos de un nmero de bloques de base de datos. Manejar el tamao de este buffer es de gran importancia a la hora de optimizar el rendimiento de la Base de Datos.. Debido a que el buffer cache es de tamao fijo y ms pequeo que el tamao real utilizado por los datos, no puede retener en memoria todos los datos en un momento dado. Tpicamente, el buffer cache es de un 1% o 2% del tamao de la base de datos. Oracle maneja el espacio disponible utilizando el algoritmo LRU, least recently used o el menos utilizado recientemente. Cuando se necesita espacio libre en el cache, los bloques menos usados recientemente sern escritos a disco y los nuevos bloques son ledos a memoria. De esta memoria los datos ms frecuentemente utilizados son mantenidos en memoria. Sin embargo, en una base de datos con muchas aplicaciones, es posible que haya competencia entre ellas por el buffer cache, con lo cual puede suceder que bloques utilizados frecuentemente salgan del cache a causa de la competencia, esto conlleva a una baja frecuencia de xitos en el cache, incrementado el I/O y degradando el rendimiento de la Base de Datos.

Dictionary CacheLa informacin acerca de los objetos almacenados en la base de datos es almacenada en las tablas del diccionario de datos. Esta informacin incluye las cuentas de usuario, nombres de los datafiles, nombres de los segmentos, localizaciones de los extents, descripciones de las tablas y priviliegios de acceso. Cuando esta informacin es necesitada por la base de datos, por ejemplo para chequear los permisos de un usuario para accesar un tabla, las tablas del diccionario son ledas y los datos son almacenados en la SGA en el dictionary cache. Este cache tambin es manejado con el algoritmo LRU explicado anteriormente. El tamao de este cache es manejado internamente por la base de datos, es parte del shared SQL pool cuyo tamao se define con el parmetro SHARED_POOL_SIZE del archivo init.ora.

Redo Log BufferLos archivo redo log describen los cambios realizados en la base de datos. Los cambios son escritos en estos archivos de modo que puedan ser utilizados en operaciones de reconstruccin de la base de datos. Antes de ser escritos a los redo log files, las transacciones son escritas primero en la SGA en un rea llamada redo log buffer. La base de datos entonces peridicamente escribe en lotes los datos del buffer en los archivo redo log.

Shared SQL PoolAlmacena los datos del data dictionary cache y del library cache (informacin acerca de instrucciones ejecutadas contra la base de datos). Esto es, mientras el data block buffer y el dictionary cache, posibilitan el compartir informacin estructural y de informacin entre los usuarios de la base de datos, el library cache permite compartir las sentencias SQL ms utilizados frecuentemente. El shared SQL pool contiene el plan de ejecucin y el parse tree para cada sentencia SQL ejecutada contra la base de datos. La segunda vez que una sentencia SQL idntica sea ejecutada por cualquier usuario, es capaz de tomar ventaje de la informacin guardada en el shared SQL pool para aligerar su ejecucin.

Context AreasDentro del area compartida de SQL, existen reas pblicas y privadas. Cada sentencia SQL emitida por un usuario requiere un rea privada de SQL, la cual existe hasta que el cursor asociado sea cerrado.

Program Global AreaEs un rea en memoria utilizada por un proceso de usuario. Esta rea NO es compartida. Su funcin es almacenar los valores especficos de procesos de usuarios, datos e informacin de control de cada proceso.

Background Process

Las relaciones entre las estructuras fsicas y las estructuras de memoria es mantenida y reforzada por los procesos concurrentes o de background. Estos varan en nmero dependiendo de la configuracin de la base de datos. Estos procesos son manejados por la base de datos y requieren muy como trabajo administrativo. En la figura anterior se muestra una configuracin tpica de Oracle con sus procesos concurrentes y estructuras fsicas y de memoria.

SMONCuando la base de datos arranca, el SMON (system monitor) realica la recuperacin de la base de datos si es necesario (utilizando los redo log files). Tambin limpia la base de datos, eliminando objetos transacciones que no sean necesitados por el sistema. El SMON tiene un propsito adicional, conjuntar los extents libres que estn contiguos para crear extents ms grandes. La fragmentacin del espacio libre ser vista con ms profundidad ms adelante, auqne los DBA deben realizar manualmente esta compactacin del espacio libre para algunos tablespaces ya que el SMON solo compacta el espacio libre de los tablespaces que tengan un pctincrease distinto de cero.

PMONEl PMON limpia los procesos fallidos. Libera recursos que fueron utilizados por el usuario, es responsalbe de liberar los bloqueos y hacerlos disponibles para otros usuarios. As como el SMON, el PMON se levanta peridicamente para chequear si se le necesita.

DBWREl DBWR (database writer) es responsable de manejar el contenido del buffer de datos o data block buffer cache y el cach del diccionario. Lee los bloques de datos desde los datafiles y los almacena en la SGA. Tambin realiza escrituras en lotes de los bloques cambiados. Optimizar las actividades del DBWR (eficiencia de lectura desde los datafiles y eficiencia de lectura desde memria) constituye mucho de los efuerzos de optimizacin realizados por los DBA. Aunque existe slo un SMON y un PMON por cada instancia de base de datos, es posible tener mltiples procesos DBWR corriendo al mismo tiempo dependiendo de la plataforma y sistema operativo. Utilizar mltiples DBWR ayuda a minimizar la contencin dentro del DBWR durante consultas muy grandes que involucran varios datafiles. El nmero de DBWR es configurado con el parmetro DBWR_IO_SLAVES en el init.ora.

LGWREl LGWR (log writer) maneja la escritura del contenido del redo log buffer hacia los redo log files que estn en lnea. Las entradas de este buffer siempre contienen el estado ms actualizado de la base de datos, debido a que el DBWR puede esperar antes de escribir los bloques cambiados a los datafiles. Los online redo log files, son escritos en forma secuencial. Si los redo log files estn espejeados el LGWR escribe simultaneamente a todas las copias.

ARCHEl LGWR escribe a los redo log files en lnea en una manera cclica, despues de llenar el primer log file, empieza a escribir en el segundo hasta que se llene y entonces empieza a escribir en el tercero. Una vez que el litmo redo log file es llenado, el LGWR sobreescribe los contenidos del primer redo log file. Cuando Oracle se corre en el modo ARCHIVELOG, la base de datos realiza una copia de cada redo log file antes de sobrescribilo. Estos redo log files archivados se escriben casi siempre a disco aunque tambien pueden ser escritos a cinta. La funcin de archivo es realizada por el proceso ARCH. Las bases de datos podran encontrar problemas de contencin durante transacciones muy pesadas, debido a que el LGWR estar tratando de escribir a un redo log file mientras el ARCH est tratando de leer otro. Pueden suceder bloqueos de la base si el disco donde se estn archivando los redo log files se llena. En este punto el ARCH se congela, lo cual previene que el LGWR pueda escribir, lo cual impide cualquier otra transaccin hasta que se libere espacio.

RECOEl proceso RECO es usado para resolver fallos en bases de datos distribuidas. El RECO intenta accesar las bases de datos involucradas en transacciones que estn en duda y resuelve las transacciones. Este proceso es slo creado si la Opcin Distribuida es soportada en la plataforma y el parmetro DISTRIBUITED_TRANSACTIONS est configurado a un valor mayor a cero en el init.ora.

SNPnLas actualizaciones de snapshots y calendarizacion de la cola de trabajos interna confa en un proceso de background para su ejecucin. El nombre de este proceso empieza con las letras SNP y termina con un nmero o letra. El nmero de procesos SNP creados para una instancia es configurado con el parmetro JOB_QUEUE_PROCESS en el init.ora en Oracle 8 y en Oracle 7 con el parmetro SNAPSHOT_REFRESH_PROCESSES.

Estructuras ExternasLos datafiles descritos en las primeras lecciones, proveen el almacenamiento fsico para los datos de la base de datos. Aunque podemos decir que son internos y externo a la vez, internos poque estn relacionados directamente con la base de datos y externos porque son archivos fsicos.

Redo LogsOracle mantiene bitcoras de todas las transacciones realizadas contra la base de datos. Estas transacciones son grabadas en archivos llamados online redo log files. Estas bitcoras son usadas para recuperar las transacciones de la base de datos en el orden apropiado en el evento de una cada. Los redo log files, tambin le permite a Oracle optimizar la escritura a disco. Cuando ocurre una transaccin, es almacenada en el redo log buffer, mietrnas los bloques de datos afectados no son escritos inmediatamente a disco. Esto le permite a la base de datos realizar escrituras por lotes a los discos. Cada base de datos Oracle tiene dos o mas online redo log files. Oracle escribe a los online redo log files de manera cclica, despues de llenar el primer log file, empieza a escribir en el segundo hasta que se llene y entonces empieza a escribir en el tercero. Cuando todos estn llenos retorna al primer log file y empieza a sobreescribirlo. Si la base de datos est corriendo en modo ARCHIVELOG, entones la base de datos realiza copias de los online redo log files antes de sobreescribirlos. Estos log files archivados pueden ser utilizados luego para recuperar la base de datos. Los redo log files pueden ser espejeados parra una mayo seguridad en caso de falla mltiple de discos.

Control FilesLa arquitectura total de una base de datos es mantenida por sus control files, los cuales almacenan informacin acerca de todos los archivos dentro de una base de datos. Son utilizados paa mantener las estructuras internas consistentes y guiar las operaciones de recuperacin. Debido a que los control files son CRTICOS para la base de datos, se almacenan mtiples copias en lnea. Estos archivos son almacenados tpicamente en discos SEPARADOS para minimizar el pontencial dao debido a fallas en los discos. La base de datos creara y mantendr la cantidad de control files especificado al momento de la creacin de la base de datos.

Trace Files y Alert LogCada uno de los procesos de background que estn corriendo en una instancia tiene un archivo trace asociado con l. El trace file puede contener informacin acerca de eventos significativos encontrados por los procesos. Adems del trace file, Oracle mantiene un archivo llamado alert log, que guarda los comandos y resultados de los eventos ms importantes en la vida de una base de datos, como por ejemplo: creacin de tablespaces, cambios de redo log, operaciones de recuperacin y arranques o bajadas de la base de datos. El alert log es una fuente de informacin vital paa el manejo diario de la base de datos, los trace files se utilizan mayormente para descubrir la causa de una falla.

Consideraciones de Hardware y ConfiguracinAunque cada base de datos Oracle puede ser construda con las mismas piezas bsicas, las opciones disponibles en cada caso depende de la plataforma de hardware y del sistema operativo.

Visin General de la arquitecturaUna base de datos Oracle consiste de archivos fsicos, reas de memoria y procesos. La distribucin de estos componentes vara dependiendo de la arquitectura escojida. Los datos en la base de datos son almacenados en archivos fsicos en disco llamados datafiles. Cuando son usados se almacenan en memoria. Oracle utiliza las reas de memoria para mejorar el rendimiento y para compartir datos entre usuarios. La memoria principal en una base de datos es llamada System Global rea (SGA). Para leer y escribir entre la SGA y los datafiles, Oracle utiliza un conjunto de procesos de background que son compartidos por todos los usuarios. Un servidor de base de datos, o instancia, es un conjunto de estructuras de memoria y procesos de background que accesan un conjunto de datafiles, esta relacin se ilustra a continuacin:

System Global Area Server o Instancia Background Process

Database

Database Files

Las caractersitcas de la instancia, como el tamao de la SGA y el nmero de procesos de background, son especificados en el arranque a travs de los parmetros del archivo init.ora Este es ledo unicamente durante el arranque, cualquier cambio posterior tendr efecto hasta el siguiente arranque.

Servidores Independientes (Stand-Alone Hosts)Memoria System Global Area Server o Instancia Background Process

Unidad de Disco Database Database Files

La configuracin conceptual ms simple es un servidor que accesa una base de datos en un servidor con slo un disco. En esta configuracin, todos los archivos son almacenados en el nico disco que posee, y slo hay una SGA y un conjunto de procesos de background. Esta arquitectura representa la mnima configuracin, todas las dems configuraciones son modificaciones de estas estructuras bsicas. Los archivos almacenados en disco incluyen los datafiles y el archivo de configuracin init.ora. Existen dos puntos principales de interface en la base de datos: Entre los datafiles y los procesos de background. Entre los procesos de background y la SGA Los esfuerzos de optimizacin constituyen mayoritariamente en mejorar estos puntos de interface. Si el rea de memoria dedicada a la base de datos es lo suficientemente grande, entonces se realizarn menos lecturas repetitivas contra los datafiles. Debido a que estos archivos estn almacenados en un solo disco en esta configuracin, se debera tratar de minimizar la cantida de accesos a los datafiles.

Servidores Indpendientes con Arreglos de DiscosMemoria System Global Area Server o Instancia Background Process

Unidades de Disco Database Disco 1 Database Files Disco 2 Database Files Disco 3 Database Files

Si se dispone de mltiples discos, entonces los datafiles pueden ser separados en discos separados. Esto se hace para mejorar el rendimiento, reduciendo la cantidad de contencin de I/O entre los datafiles. Durante la operacin de la base de datos, es comn que se requiera informacin de varios archivos para satisfacer una consulta. Si los archivos no estn distribudos en varios discos, entonces el sistema necesitar leer mltiples archivos en el mismo disco concurrentemente.

Espejeo de los Control FilesEl archivo init.ora es almacenado en los directorios donde se haya instalado el software de Oracle, normalmente en un directorio como /orasw/app/oracle/admin/instance_name/pfile. El archivo init.ora no tiene los nombres de los datafiles o de los online redo log, estos estn almacenados dentro del diccionario de datos. Sin embargo, el init.ora tiene los nombres de los control files para la base de datos. En un servidor con mltiples discos, los control files debe almacenarse en discos separados. La base de datos los mantendr sincronizados. Almacenando los control files en discos separados reduce el riesgo de problemas causados por fallos de disco. Existe otro archivo de configuracin llamado config.ora el cual es llamado por el init.ora. El config.ora es usado para configurar los valores de aquellos parametros que NO cambian dentro de la base de datos, los nombres de los control files estn dentro de stos parmetros. Veamos un ejemplo del config.ora:

control_files

=(/db01/oracle/ORA1/ctrl1ora1.ctl, /db02/oracle/ORA1/ctrl2ora1.ctl, /db03/oracle/ORA1/ctrl3ora1.ctl)

Si se desea agregar otro control file para mayor seguridad siga el siguiente procedimiento: Baje la base de datos. Copie uno de los control files actuales a una nueva localizacion en disco. Edite el config.ora agregando el nuevo control file. Arranque de nuevo la base de datos.

Espejeo de los Redo Log FileLa base de datos puede automticamente espejear los online redo log files. Para hacer esto hay que utilizar los redo log groups. Cuando se utiliza esta funcionalidad, el proceso LGWR escribe simultaneamente a todos los miembros del online redo log group actual. O sean en vez de trabajar cclicamente a travs de los online redo log files, lo hace pero cclicamente a travez de los online redo groups. Los redo log groups pueden ser creados con el comando create database o alter database. Por ejemplo: alter database add logfile group 4 (/db01/oracle/CC1/log_1c.dbf, /db02/orace/CC1/log2c.dbf) size 5M; Para agregar un nuevo redo log file a un grupo existente: alter database add logfile member /db03/oracle/CC1/log_3c.dbf to group 4; Cuando se utiliza la opcion add logfile member, no se indica informacin de tamao, esto porque todos los miembros de un grupo deben tener el mismo tamao.

Servidor Independiente con espejeo de discos via sistema operativo

Arreglo de discos 1

Arreglo de discos 2

Disco 1 Database Files

Disco 1 Database Files

Disco 2 Database Files

Disco 2 Database Files

Disco 3 Database Files

Disco 3 Database Files

Muchos sistemas operativos posibilitan mantener copias duplicadas y sincronizadas de archivos a travs de lo que se llama disk shadowing conocido comunmente como mirroring. Existe dos beneficios al hacer este proceso. Primero, el conjunto adicional sirve como respaldo en caso de una falla de disco. En la mayora de los sistemas operativos, una falla de disco causa que los discos correspondientes del espejo tomen el lugar de los discos que han fallado. El segundo beneficio es la mejora en rendimiento, esto porque la mayora de los sistemas operativos que soportan esta arquitectura, pueden direccionar el I/O para usar indistintamente cualquier disco, incluso los del espejo. Esto reduce la carga por I/O en el conjunto de discos principal. El tipo de espejo mostrado en la ilustracion se conoce como RAID-1. Dependiendo del sistema operativo, existen otras opciones como RAID-3 o RAID-5.

Servidores independientes con mltiples bases de datosSe pueden crear mltiples bases de datos en un mismo servidor. Cada base de datos tendr un conjunto separado de achivos y sern accesados por una instancia diferente. Debido a que cada instancia requiere una SGA y procesos de background, el servidor debe ser capaz de soportar los requerimientos de memoria y procesos suficientes.

Servidores enlazados en redCuando los servidores que tienen bases de datos Oracle son conectados a travs de una red, estas bases de datos entonces pueden comunicarse entre ellas a travs de SQL*Net o Net8.

Oracle kernel o aplicacin

SQL*Net V2 / Net8

TNS

Driver especfico al protocolo

Software del Protocolo

Como se muestra en la figura, los drivers de Net8 confan en el protocolo de red local para lograr la conectividad entre dos servidores. Las opciones de configuracin en un ambiente en red son: Redes de bases de datos, utilizados para consultas remotas. Bases de datos distribuidas, utilizadas para transacciones remotas. Bases de datos paralelas, en la cual mltiples instancias accesan la misma base de datos. Bases de datos cliente/servidor.

Redes de bases de datosEl Net8 permite transferir datos entre bases de datos. En su ms simple configuracin, consiste de un proceso de servidor que espera conexiones via una ruta de conexin. Cuando una de estas conexiones es detectada, sigue las instrucciones pasadas a travs de la conexin y luego retorna los datos solicitados.

Para que Net8 puede recibir y procesa las comunicacioness, el servidor debe estar corriendo un proceso llamado el listener. El proceso listener debe estar corriendo en cda servidor involucrado en la comunicacin entre bases de datos. Por ejemplo con Net8 o SQL*Net podemos realizar consultas remotas utilizando database links, esta especifica el servidor, la base de datos y el usuario a utilizar en una consulta remota. Veamos como se crea una database link: create public database link MG_HR connect to HR identified by HR using MG; Ahora bien para realizar una consulta remota utilizando la liga de base de datos: select * from empleados@MG_HR where cod_depto = 10; El concepto anterior puede ser expandido utilizando el Advanced Replication Option de Oracle para realizar actualizaciones e inserciones en forma remota, haciendo uso como en el ejemplo anterior de ligas de bases de datos. En este caso, las transacciones distribuidas son controladas por Oracle a traves del TwoPhase Commit o commit en dos fases. Si existiera un error en la red o falla un servidor, puede suceder que los datos no estn sincronizados; para esto existe un proceso background que resuelve estos problemas tan pronto como los recursos estn nuevamente disponibles. El nmero mximo de transacciones distribuidas para una base de datos se configura con el parmetro DISTRIBUITED_TRANSACTIONES, si est en cero, no se permitirn transacciones distribuidas y el proceso de recuperacin en background no ser arrancado. Cuando se dispone de multiples procesadores Oracle nos da las opciones Parallel Query y Parallel Load, en la primera una consulta puede ser realizada por multiples procesadores coordinadamente, esto mejora el rendimiento y tiempo de respuesta de las transacciones. La arquitectura Parallel Query de Oracle le permite a la base de datos paralelizar operaciones. Las operaciones que pueden tomar ventaja de esta opcin son: create table as select, create index, recorridos completos de tablas, bsquedas en ndices, ordenamientos, inserciones, actualizaciones, borrados y la mayoria de las consultas. Para configurar un servidor paralelo se parametrizan los PARALLEL_MAX_SERVERS y PARALLEL_MN_SERVERS en el init.ora valores de

En el caso de que se desee utilizar la arquitectura cliente servidor, es necesario instalar el Net8 o SQL*Net en cada PC para que puedan comunicarse:

Sistema Operativo NIC Software de Comunicaciones SQL*Net o Net8 Programas de Aplicacin Ethernet

Sistema Operativo Software de Comunicaciones Oracle Software Oracle Database SQL*Net / Net8

En este caso la carga de CPU es distribuida entre el servidor y el cliente, aunque un inconveniente muy fuerte de esta arquitectura es la gran utilizacin de red que realiza transportando datos entre el sevidor y el cliente, problema que se agudiza an ms cuando tenemos enlaces remotos de muy poco ancho de banda.

Planeamiento Lgico de la Base de DatosPlanear adecuadamante el diseo de la base de datos es de vital importancia para la vida y rendimiento ptimo de cualquier base de datos Oracle. Para distribuir los objetos, se debe establecer un sistema de clasificacin. Los objetos lgicos dentro de la base de datos deben ser clasificados basndose en cmo son usados y en cmo sus estructuras fsicas impactan la base de datos. Esto incluye separar tablas de los ndicies y tablas de gran actividad de las que tienen poca actividad. Aunque el volumen de actividad contra objetos slo puede determinarse durante la fase de produccin, un conjunto inicial de tablas muy utilizadas puede separarse inicialmente.

Optimal Flexible Arquitecture (OFA) El tablespace SYSTEMEs posible aunque no recomendable almacenar todos los objetos de la base de datos en un solo tablespace, esto sera como guarda todos los archivos en el directorio raz de un disco. Este tablespace es donde se localizan las tablas del diccionario de datos y el rollback de SYSTEM. No hay razon para que haya algun otro objeto que no sea el diccionario o este segmento de rollback. Almacenar otros objetos en el tablespace SYSTEM incrementa la posibilidad de que haya problemas de espacio, lo cual requiere que el tablespace sea recreado. Como la nica posibilidad de reconstruir el tablespace SYSTEM es recrear la base de datos, cualquier cosa que pueda ser movida fuera de SYSTEM debe ser movida. Los segmentos del diccionario de datos almacenan toda la informacin acerca de los objetos en la bas de datos. Son almacenados en el tablespace SYSTEM y son generalmente estticos a menos que haya cambios estructurales muy grandes dentro de las aplicaciones. Lo que hace crecer el diccionario de datos en mayor medida son los triggers y procedimientos almacenados de PL/SQL. Para prevenir que los usuarios puedan crear objetos en el tablespace SYSTEM, podemos definir una cuota de cero para todos los usuarios que creeemos: alter user JDURAN quota 0 on SYSTEM; Por otra parte cuando creamos un usuario podemos indicarle un tablespace por defecto, tambien se puede hacer si ya existe: create user JDURAN identified by chepe default tablespace RH; o alter user JDURAN default tablespace RH;

Separar los segmentos de datos de aplicacin: DATA

Los segmentos de datos son las reas fsicas en las cuales los datos asociados con las tablas son almacenados. Estos segmentos tienden a ser accesados muy a menudo en un ambiente en produccin. Un tablespace DATA tpico contiene todas las tablas asociadas con una aplicacin. Los altos volmenes de trfico contra estas tablas la hacen un candidato ideal para ser aisladas en un tablespace propio. Si se separan las tablas de aplicacin en su propio tablespace, significa que puede ser separado fsicamente de otros datafiles en la base de datos. Esta separacin de datafiles a traves de las unidades de discos puede mejorar el rendimiento (a travs de una menor contencin de I/O) y un manejo ms sencillo de la base de datos. Los segmentos en un tablespace DATA, tienden a fragmentarse con el transcurso del tiempo, con lo que como veremos ms adelante, al estar separado, es mucho ms fcil su desfragmentacin futura.

Separar los segmentos de ndices de aplicacin: INDEXESLos ndicies asociados con tables estn sujetos al mismo I/O y fragmentacin que los datos. Los segmentos de ndice NO deben ser almacenados en el mismo tablespace que los datos asociados a ellos, debido a que tienen una gran cantidad de acceso concurrente durante la manipulacin y consulta de los datos. Los segmentos de ndice tambin estn sujetos a fragmentacin debido a una estimacin de tamao errnea o un crecimiento impredecible. Aislar los ndices de la aplicacin en un tablespace separado reduce grandemente los esfuerzos de administracin involucrados cuando se quiera desfragmentar ya sea el tablespace DATA o el INDEXES. Separar ndices existentes de sus respectivas tablas puede ser logrado mediante la opcin rebuild del comando alter index. Si un ndice ha sido creado en el mismo tablespace que su tabla, puede ser movido facilmente: alter index i_empl_depto rebuild tablespace INDEXES storage (initial 2M next 2M pctincrease 0);

Separar segmentos de Herramientas: TOOLSA pesar de lo que hemos visto de no almacenar segmentos de datos en el tablespace SYSTEM, muchas herramientas hacen precisamente eso. No lo hacen exactamente porque precisen que sus objetos estn en el tablespace SYSTEM, sino porque deben utilizar el usuario SYSTEM para hacer la instalacin y el usuario SYSTEM tiene el tablespace SYSTEM por defecto. Para evitar esto cambie el usuario SYSTEM para que su tablespace por defecto sea TOOLS y quitele las coutas a SYSTEM sobre el tablespace SYSTEM: alter user SYSTEM quota 0 on SYSTEM; alter user SYSTEM quota 50M on TOOLS;

Separar los segmentos de Rollback: RBSLos segmentos de rollback mantienen la consistencia de datos dentro de la base de datos. Debido a que incurren en mucho I/O lo aconsejable siempre es aislarlos en un tablespace dedicado a solo segmentos de rollback (RBS). Una vez que el tablespace RBS ha sido creado, es conveniente desactivar el segmento de rollback que existen en SYSTEM pero NO BORRARLO, ya que puede ser imprescindible en caso de un problema con el tablespace RBS. Los segmentos de rollback se expanden dinmicamente al tamao de la transaccin ms grande y se encojen hasta el tamao ptimo especificado. El I/O contra los segmentos de rollback es casi siempre concurrente con el I/O realizado contra DATA e INDEXES. Separarlos nos ayuda a reducir la contencin de I/O y facilita la administracin.

Separar los segmentos temporales: TEMPLos segmentos temporares son objetos creados dinmicamente dentro de la base de datos para almacenar durante largas operaciones de ordenamiento tales como: select distinct, union y create index. Debido a su naturaleza dinmica, los segmentos temporales no deben ser almacenados junto con ningn otro tipo de segmento. Tambin es importante considerar al crear o modificar un usuario, especificar el segmento para objetos temporales ya que por defecto el tablespace para objetos temporales es SYSTEM: create user JDURAN identified by chepe default tablespace RH temporary tablespace TEMP; o alter user JDURAN temporary tablespace TEMP;

Otros tablespacesTambin puede ser necesario crear otros tablespaces como USERS, para que los usuarios creen sus objetos, aunque esto no es muy comn. Adems puede ser recomendable crear un tablespace DATA_2 e INDEXES_2, para almacenar en estos datos e ndices de poca utilizacin o muy estticos como catlogos, etc., esto aumenta el rendimiento de las aplicaciones y facilita la administracin de la base de datos. A veces puede ser necesario tambien crear un tablespace de rollback, sobretodo cuando se est en procesos de migracin, durante los cuales se hacen importaciones masivas de datos, que pueden resultar en que los segmentos de rollback definidos no sean suficientes. Para esto podemos crear un tablespace RBS_2 y antes de empezar a hacer la carga de datos ejecutamos: set transaction use rollback segment segment_name; Pueden existir dependiendo de la empresa o institucin otros tablespaces que deben ser separados como para contener los snapshots, particiones (Oracle8) o algn tablespace temporal utilizado en cargas o migraciones. Podemos decir que la configuracin lgica de la base de datos es algo de sentido comn que podemos resumir como: Tipos de segmentos que son usados en una misma manera deben almacenarse juntos. El sistema debe disearse para un uso estandarizado. reas separadas deben existir por excepciones. La contencin entre tablespaces debe debe ser minimizado. El diccionario de datos debe ser aislado.

Planeamiento Fsico de la Base de DatosNunca dejes para maana lo que puedes hacer hoy. Muy a menudo, el planeamiento fsico de una base de datos Oracle, slo se toma en cuanto cuando los problemas ya han surgido a la superficie en un sistema en produccin, cuando el costo de afinamiento es muy alto y peligroso. Por otra parte nos enfrentamos a un problema de costo/beneficio, ya que siempre tendremos ms archivos de la base de datos que discos fsicos a utilizar, por lo cual debemos tomar varias decisiones en cuanto a como y cuales archivos distribuir en cada disco. En esta clase veremos varios aspectos fsicos a considerar ANTES de crear cualquier base de datos.

Distribucin de los archivos de la base de datos Contencin de I/O entre los datafilesCuando diseamos una base de datos tal y como vimos en la clase anterior, tendremos una coleccin de tablespaces, cada una de las cuales necesitar por lo menos un datafile, se puede monitorear el I/O entre datafiles despus de que la base de datos ha sido creada, pero a menos que tengamos a mano una base de datos con cargas o sistemas similares, el DBA deber estimar la carga de I/O para cada datafile. Empiece estiamando el I/O relatvio de los datafiles. Asigne al tablespace ms activo un peso de 100, luego estime el I/O de los dems datafiles de manera relativa a este tablespace. Asigne al tablespace SYSTEM un peso de 35 y a los tablespaces de ndices un tercio del peso del tablespace asociado. Por otro lado con respecto al tablespace TOOLS, en ambientes de produccin su utilizacin es muy bajo, por lo que su peso relativo debe ser menor a 5. El tablespace RBS depende del tipo de base de datos, si se realizan muchas transacciones puede llegar a pesar hasta 75, aunque en la mayora de los casos su peso va de 10 a 40. El TEMP, en un ambiente en produccin slo se utiliza en operaciones de sort grandes, por lo que su valor depende de cmo estn implementados nuestros sistemas y puede fluctuar entre 0 y 75. Veamos un ejemplo: Tablespace DATA RBS SYSTEM INDEXES TEMP DATA_2 INDEXES_2 TOOLS

Peso 100 40 35 33 5 4 2 1 220

% del Total 45 18 16 15 2 2 1 1

Notese que el 94% del I/O se concentra en los cuatro tablespaces iniciales, tericamente deberamos tener cinco discos para una ptima implementacin fsica de la base de datos, dejando cuatro discos slo para los primeros cuatro tablespaces, uno para cada uno. Ahora bien como veremos ms adelante y como sucede en la vida diaria, los recursos son escasos la mayora de las veces, por lo que este caso terico no es muy comn y al final terminaremos teniendo menos discos de los que tericamente quisiramos. Incluso, en teora podriamos desear tener una controladora de disco para cada disco, optimizando mucho ms el modelo y evitando algn cuello de botello en la tarjeta controladora.

Cuellos de botella de I/O entre todos los archivos de la base de datos(otros que no sean datafiles)

Online Redo Log FilesComo hemos visto los redo log files almacenan cada transaccin realizada en la base de datos, cada base de datos debe tener al menos dos online redo log files. Estos archivos son el taln de Aquiles de la base de datos. Como mantienen informacin acerca de las transacciones actuales, no pueden ser recuperados de un respaldo anterior. Es el nico archivo que no puede ser recuperado a travs de los utilitarios de respaldo. Por esta razn el DBA debe asegurarse de tener los online redo log files, espejeados de alguna manera. Dentro de Oracle, como vimos previamente los redo log groups nos permiten lograr este objetivo. En general, deberiamos tratar de tener los online redo log files aparte de los datafiles debido a problemas potenciales de rendimiento. Cualquier transaccin que no tengal el parmetro nologging es grabada en los redo log files. Estas son escritas por el LGWR, los datos en la transaccin son escritos a los tablespaces va DBWR. Esto significa que aunque el I/O puede ser distribuido adecuadamente, puede ocurrir contencin entre el DBWR y el LGWR si un datafile es almacenado en el mismo disco que un redo log file. Los redo log files son escritos SECUENCIALMENTE. Esto es si no hay actividad concurrente en el disco, entonces el hardware del disco estar posicionado correctamente para la siguiente escritura. En contraste, los datafiles son ledos y escritos en una forma ms o menos aleatoria. Debido a que los log files son escritos secuencialemente, sern procesados en forma ms rpida si no tienen que competir con otra actividad en el disco. Si tenemos que guardar un datafile junto con uno o ms redo log files, entonces no debe se ni SYSTEM, RBS, DATA o INDEX. Todos estos tendrn problemas direcots con los redo log files e incrementarn la posibilidad de que las escrituras de los log files sean afectadas por lecturas de la base de datos.

Control FilesCon respecto a estos diremos que el I/O relacionado con ellos es prcticamente nulo y de lo nico que tenemos que preocuparnos como explicamos en la clase anterior es de tener varias copias en distintos discos para prevenir su prdida en caso de fallo de discos.

Archived Redo Log FilesCuando Oracle se corren en modo ARCHIVELOG, la base de datos realiza una copia de cada online redo log file antes de sobrescribirlo. Estos redo log files archivados son normalmente escritos a un disco. Esta funcin de archivo es realizada por el proceso ARCH como se explic anteriormente. Las bases de datos que utilizan esta opcin podrn encontrar problemas de contencin en el disco donde se encuentren los online redo logs duarante transacciones que modifiquen datos en forma masiva, debido a que el LGWR estar tratando de escribir a un redo log mientras el ARCH est tratando de leer otro. La nica manera de evitar esta contencin es distribuir los online redo log files a travs de varios discos. Tambin se debe ser muy cuidadose en cuando al disco donde se grabarn los archived redo log files, ya que por su naturaleza demandan una cantidad de I/O similar a los online redo log. Por lo tanto siga las mismas reglas expresadas para estos.

Oracle SoftwareEl I/O contra el software de Oracle no queda registrada y por lo tanto no hay una manera directa de conocer el impacto del I/O respectivo. Lo ms aconsejable es instalar el software de Oracle en un disco donde no haya datafiles, aunque en caso de que sea necesario, debemos colocar en dicho disco los datafiles que sean accesados en menor grado.

I/O concurrente entre los procesos de backgroundCuando se evala la contencin entre varios procesos es importante identificar el tipo de I/O realizado y la oportunidad con que se realiza. Los archivos contienden entre si, si el I/O de un archivo interfiere con el I/O de un segundo archivo, de modo que dos archivos accesados en forma aleatoria que nunca son accesados al mismo tiempo pueden ser ubicados en el mismo disco. Basndonos en lo anterior, podemos definir dos tipos de contencin de I/O: concurrente e interferencia. La contencin de I/O concurrente ocurre cuando se realizan mltiples accesos contra el mismo disco al mismo momento. Esta es la clase de contencin que se elimina aslando las tablas de sus respectivos ndices. La contencin por interferencia ocurre cuando las escrituras secuenciales de un archivo son interrumpidas por lecturas o

escrituras de otros archivos en el mismo disco, an si estas ocurren en momentos distintos a las lecturas o escrituras secuenciales. Existen tres procesos background de la base de datos que accesan activamente los archivos en disco: el Database Writer (DBWR), el Log Writer (LGWR) y el Archiver (ARCH) si se utiliza la opcin ARCHIVELOG. El DBWR, escribe y lee los archivos en forma aleatoria, el LGWR escribe secuencialmente y el ARCH lee y escribe secuencialmente. Eliminando las posibilidades de contencin entre estos tres procesos efectivamente elimina la contencin a nivel de la base de datos. Notese que el LGWR y el ARCH, SIEMPRE escriben a un solo archivo a la vez, mientras que el DBWR, escribe a varios archivos a la vez por lo que puede causar contencin a si mismo!. Para evitar esto en algunas plataformas como UNIX, se pueden definir varios DBWR con el parmetro DBWR_IO_SLAVES, Oracle recomienda configurar este parmetro igual al nmero de disco o hasta un mximo de dos por disco. En todo caso, no importa que hagamos, la recuperabilidad de la base de datos siempre debe ser el primer objetivo en cuenta. Una vez que estemos seguros de que podemos recuperar bajo cualquier circunstancia la base de datos, debemos preocuparnos del rendimiento, o sea no sacrifiquemos seguridad por desempeo nunca.

Configuracin Fsica de la Base de DatosCuando nos sentemos a definir qu archivos irn en que discos tenemos muchas alternativas o pocas dependiendo como hemos dicho de los recursos, si tuvieramos recursos ilimitados y que podamos incluso subutilizar, entonces pongamos un disco para tablespace, uno para archived redo logs, otro para hacer exports, etc.; pero esto no es francamente muy econmico por lo que siempre deberemos tomar decisiones en base al peso relativo de cada archivo tomando como parmetro la tabla que construimos al principio. Veamos un caso hipottico de distribucin teniendo como lmite siete discos en un servidor: Disco 1 2 3 4 5 6 7 Peso 38 40 100 42 40+ 40+ Contenido Oracle Software SYSTEM, TOOLS, INDEXES_2 y Control File 1 RBS, RBS_2, Control File 2 DATA, Control File 3 INDEXES, TEMP, DATA_2 Online Redo Logs 1, 2 y 3, Export Software de aplicacin, archived redo logs

Verificacin de las estimacin de I/OAhora que hemos realizado esta configuracin, la cual fue elaborada con base a nuestra experiencia personal o de conocidos, el trabajo del DBA consiste en medir si en realidad su estimacin es cercana a la realidad, para esto usaremos el siguiente script: REM This script will only work in 7.2 and above. set pagesize 60 linesize 80 newpage 0 feedback off ttitle skip center "Database File IO Weights" skip center "ordered by Drive" skip 2 column Total_IO format 999999999 column Weight format 999.99 column file_name format A40 break on Drive skip 2 compute sum of Weight on Drive select substr(DF.Name, 1,5) Drive, DF.Name File_Name, FS.Phyblkrd+FS.Phyblkwrt Total_IO, 100*(FS.Phyblkrd+FS.Phyblkwrt)/MaxIO Weight from V$FILESTAT FS, V$DATAFILE DF, (select MAX(Phyblkrd+Phyblkwrt) MaxIO from V$FILESTAT) where DF.File# = FS.File# order by Weight desc spool io_weights / spool off Con los resultados que nos de este script podriamos valorar algn acomodo posterior a lo que hemos planeado previamente.

A continuacin listo un ejemplo de una corrida de este script en el servidor de produccin de la Mutual Guapay: Database File IO Weights ordered by Drive DRIVE FILE_NAME TOTAL_IO WEIGHT ----- ---------------------------------------- ---------- ------/i/b2 /i/b2000/dbs/data/ccd01.dbf 1647150 100.00 ***** ------sum 100.00 /d/b2 /d/b2000/dbs/instancia/temp/temp01.dbf ***** sum /g/b2 /g/b2000/dbs/data/bcgd01.dbf ***** sum /e/b2 /e/b2000/dbs/instancia/roll/roll01.dbf ***** sum /h/b2 /h/b2000/dbs/ind/bcgi01.dbf ***** sum /f/b2 /f/b2000/dbs/data/pad01.dbf /f/b2000/dbs/ind/cci01.dbf ***** sum etc... 190448 11.56 ------11.56 6.05 ------6.05 1.45 ------1.45 1.04 ------1.04 .90 .64 ------1.54

99726

23932

17127

14860 10558

Utilizacin del espacio dentro de la base de datosCuando un tablespace es creado, los datafiles son creados para contener sus datos, estos archivos resevan el espacio inmediatamente durante su creacin a nivel de sistema operativo. En resumen una base de datos puede tener muchos tablespaces y cada tablespace puede tener muchos datafiles. Una base de datos puede tener muchos usuarios llamados esquemas. Cada esquema es una coleccin de objetos lgicos de base de datos tales coo tablas e ndices. Estos objetos se refieren a estructuras de datos fsicas queson almacenadas en tablespaces. Los objetos de un un usuario son pueden estar almacenados en mltiples tablespaces, y un solo tablespace puede contener objetos de mltiples esquemas. Cuando se crea un objeto como tabla o ndice, es asignado a un tablespace en particular creando un segmento en este tablespace para contener los datos asociados a este objeto. El espacio reservado para este segmento NUNCA es liberado hasta que el segmento sea eliminado, reducido o truncado (drop, truncate). Un segment est construido de secciones llamadas extents, los cuales son bloques contiguos de bloques de Oracle. Una vez que los extents existentes no puedan contener nuevos datos, el segmento obtiene o solicita otro extent. Este proceso de extensin contina hasta que no haya ms espacio libre en el tablespace o se alcance un mximo interno por segmento (maxextents). Si un segmento tiene mltiples extents no hay NINGUNA garanta que que estos sean contiguos. Para aclarar estas relaciones entre distintos conceptos de la base de datos Oracle, veamos este esquema:

Databases

Tablespaces

Datafiles

Users

Esquemas

Segmentos

Extents

Implicaciones de la clasula storageLa cantidad de espacio utilizada por un segmento esta determinada por los parmetros de la clasula storage al momento de su creacin. Si no se utiliza esta clasula entonces el segmento, tomar por defecto el storage definido para el tablespace que lo contendr. Esta clasula puede especificarse en los siguientes comandos: Create table Create index Create cluster Create rollback segment Los parmetros del storage son: Initial, define el tamao en bytes del primer extent. Next, define el tamao de los extents subsiguientes. Pctincrease, es un factor porcentual, por el cual cada subsiguiente extent ir creciendo geomtricamente. Minextents, el nmero mnimo de extents a reservar para un objeto, por defecto es uno. Maxextents, el nmero mximo de extents que sern permitidos. En versiones anteriores a 7.2, el nmero mximo era 121, ahora se puede indicar la opcin maextents unlimited con lo cual el segmento no tendr limites de crecimiento, esto puede tiene su lado negativo, por cuanto como se dijo anteriormente, no hay garanta de que los extents adicionales estn contiguos lo cual puede provocar degradamiento del tiempo de respuesta. Los parmetros initial y minextents no pueden ser cambiados luego de la creacin. Cuando se crea un segmento, adquiere al menos un extent. Este extent ser utilizado para almacenar datos hasta que no haya espacio libre disponible, dentro de cada bloque tambin puede reservase espacio libre con la clasula pctfree, este espacio ser utilizado para actualizaciones de los datos almacenados dentro de cada bloque. El parmetro pctincrease est diseado para minimizar el nmero de extents en tablas en crecimiento. Un valor DISTINTO DE CERO, puede ser peligroso, ya que causa que cada extent sucesivo se incremente geomtricamente con base al factor especificado. Para qu sirven cada uno de las directivas componentes de la clusula? Cuando un objeto es creado debe incluir al menos un extent, la directiva INITIAL especifica la cantidad en bytes del primer extent que se desea reservar para el objeto, este espacio se encontrar vaco obviamente en el momento de la creacin. La cantidad en bytes debe ser un mltiplo del tamao de bloque (4096 bytes), de no ser as el valor ser redondeado al mltiplo ms cercano. El NEXT indica la cantidad de bytes (mltiplos del tamao de bloque) del siguiente extent que ser alojado cuando el objeto se expanda. PCTINCREASE permite hacer un incremento porcentual del NEXT de modo dinmico, de manera que si PCTINCREASE es

igual a cero los nuevos extents creados sern exactamente del tamao especificado en el NEXT, pero si el PCTINCREASE es de X porcentaje diferente de cero, cada nuevo extent tendr un tamao igual a la suma del tamao del extent anterior ms un incremento del porcentaje especificado, de este modo los nuevos extents sern ms grandes conforme la tabla sea ms grande. El valor MAXEXTENTS permite acotar la cantidad de extents que conformarn un segmento, esta directiva es muy prctia para poder controlor el sobre-crecimiento de los objetos antes de que lleguen al mximo permitido por la base de datos o para detectar crecimientos desproporcionados y no tomados en cuenta en la fase de diseo. MINEXTENTS se complementa con el INITIAL, especificando la cantidad de extents que sern alojados adems del INITIAL cuando el objeto sea creado, los nuevos extents sern creados respetando lo indicado en el NEXT y en el PCTINCREASE. De donde toma Oracle los extents libres para asignarlos a las nuevas tablas y a las tablas que estn creciendo? Cuando un tablespace es creado, el espacio no usado por las tablas se considera espacio libre y se administrar como un extent libre, enteramente disponible para la atencin de solicitudes de nuevo espacio. Adems cuando un usuario borra un segmento, Oracle desalojar los extents componentes del segmento y los declarar extents libres. Luego del borrado, Oracle no recombina extents contiguos an cuando pertenecieron a un mismo objeto y ahora se encuentren marcados como libres, Oracle los recombinar solo si su unin crea un extents suficientemente grande para suplir una solicitud de alojamiento y esa es la nica forma de lograr un extent del tamao deseado. Obsrvese que esta poltica de administracin de espacio induce a la existencia de fragmentacin de objetos y fragmentacin de espacio libre. En versiones recientes, si al storage del tablespace se le indica un pctincrease mayor a cero, Oracle se encarga de conjuntar los extents libres que estn contiguos. Tambin podemos utilizar el siguiente comando: alter tablespace DATA coalesce; De que manera utiliza el RDBMS las directivas de la clsula storage? Cuando el objeto es creado por el usuario, Oracle crea el segmento respectivo en el diccionario de datos. La indicacin de los valores en INITIAL y MINEXTENTS implicar una importante demanda de espacio fsico contiguo en los extents libres dentro del tablespace. En primera instancia el RDBMS buscar en el espacio libre (fragmentado o no fragmantado) un extent del tamao especificado en el INITIAL de NO hallarlo combinar los extents libres contiguos en procura de crear un solo extent del tamao solicitado, de no poder construir un extent como el deseado reportar un error de creacin del objeto. Si la accin es exitosa observar el valor del MINEXTENT y continuar buscando tanto extents libres del tamao calculado (por NEXT y PCTINCREASE) hasta que se logre suplir la cantidad de extents solicitada. Los extents creados por causa del INITAL y el MINEXTENT no tiene por que ser mutuamente contiguos. Cuando la situacin es que la tabla est creciendo, el RDBMS calcular el PCTINCREASE en base al ltimo extent creado para la tabla y lo adicionar al NEXT,

luego determinar la existencia de un extents suficientemente grande para alojar el espacio demandado. En todos los casos de bqueda y creacin de extents si no se encuentra un espacio libre del tamao apropiado se reportar un error de creacin del segmento. Qu implicaciones en el rendimiento tiene la clusula storage? Cuando el crecimiento de los segmentos es manejado de modo dinmico por el RDBMS existe un alto consumo de recursos de procesamiento e I/O, de hecho, la asignacin de nuevos extents es facilmente percibida como un pico de degradacin en los tiempos de respuesta para todos los usuarios en el momento de la ampliacin. Una reiterada sucesin de este evento mostrar un sistema degradado desde la perspectiva del usuario final. La clusula storage debe ser ideada de modo que se minimize la presencia de dicho evento. Adems, el ordenamiento de los registros dentro de bloques contiguos beneficiar el full scan en tablas y range index en ndices. Cul es el precio que se paga con el uso de la clusula storage? Evidentemente no es lgico asignar todo el espacio disponible en un tablespace para que sea usado por un solo segmento. Se debe pensar que si el espacio libre alojado por los extents de una tabla es muy grande, transcurrir mucho tiempo durante el cual dicho espacio libre ser inutilizado. Adems si los extents solicitados para asignar son muy grandes existe menos probabilidad de localizar grande extensiones de bloques contiguos libres. Si por otro lado los extents son muy pequeos, el procesamiento dinmico de solicitudes de extensines ser ms frecuente, y como ya se dijo antes, repercutir negativamente en el desempeo del sistema. Es posible modificar la clusula storage en un momento posterior a la creacin de la tabla? Si es posible, para ello se utiliza la sentencia ALTER TABLE. Los valores que no pueden ser modificados son, evidentemente, el INITIAL y el MINEXTENTS. La modificacin de estos valores se aplicar para las futuras extensiones, NO para los datos ya registrados en la tabla. Existen reg