Curso de DBA Oracle

Curso
Dba para Desarrolladores
Impartido por: Luis Figueroa Santa Cruz de la Sierra, Bolivia Setiembre 1999
ndice
NDICE .............................................................................................................................................................. 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 externa

Conceptos Generales
Oracle 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 Datos
Una 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.
Tablespaces
Un 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 Files

Cada 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
Instancias
Para 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 Datos

Dado 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 datos

Las 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 Constraints
Una 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 Abstractos

A 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;
Particiones
A 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);
Usuarios
Una 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.
Esquemas
Un 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.
ndices
En 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: <1 1 1 1 1 0 0 0 0 0 > CA: <0 0 0 0 0 1 1 1 1 1> 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.
Vistas
Una 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.

Secuencias
Las 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;
Procedimientos
Un 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.
Funciones
Las 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 Almacenados
Los 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.
Triggers
Los 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 links
Las 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;
Sinnimos
Para 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 roles
Para 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 blocks

Los 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 segments
Para 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.

Estructuras Internas de Memoria
Existen 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 Cache

El 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 Cache
La 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 Buffer

Los 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 Pool

Almacena 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 Areas
Dentro 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 Area

Es 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.
SMON
Cuando 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.
PMON
El 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.
DBWR
El 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.
LGWR
El 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.
ARCH
El 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.
RECO
El 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.
SNPn
Las 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 Externas
Los 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 Logs
Oracle 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 Files
La 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 Log

Cada 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 Configuracin

Aunque 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 arquitectura

Una 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 Discos

Memoria 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 Files

El 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 File

La 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
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 datos

Se 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 red

Cuando 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 datos

El 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 Datos

Planear 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 SYSTEM

Es 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: INDEXES

Los 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: TOOLS

A 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: RBS

Los 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: TEMP

Los 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 tablespaces
Tambin 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 Datos

Nunca 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 datafiles
Cuando 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 Files

Como 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 Files
Con 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 Files

Cuando 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 Software
El 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 background

Cuando 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 Datos

Cuando 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/O

Ahora 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 datos

Cuando 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 storage

La 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 reglas generales para la aplicacin de la clusula? Realmente no existen reglas generales, sin embargo es importante el conocimiento de las caractersticas del objetos (finalidad, actualizacin, inclusin, borrados, etc) antes de su creacin en la base de datos. Debido a que algunas condiciones supuestas en la etapa de diseo pueden ser refutadas en el mbito prctico, es importante evaluar peridicamente el complimiento de las premisas que soportanron la especificacin de la directivas de la clusula para los objetos de actividad intensiva, una vez iniciada la puesta en produccin de los sistemas.
En general se debe asignar un espacio considerable en trminos de INITAL y MINEXTENS para aquellas tablas que tienen un crecimiento acelerado, considerando un periodo de 4 meses aproximadamente. Para las tablas estticas es til estimar su tamao aproximado y reservar desde el inicio exactamente todo el espacio requerido. Con la especificacin del PCTINCREASE es posible la gestin de grandes extents a futuro, sin embargo como ya se mencion esto disminuye la probabilidad de xito al encontrar extents suficientemente grandes. Cmo se puede saber el tamao del ltimo extent asignado a un objeto? Las vistas USER_TABLES, USER_SEGMENTS y USER_EXTENTS informan sobre los valores de la clusula vigente para el objeto, la cantidad de extents y el tamao de los extents asignados. Cmo se puede estimar el tamao de una tabla o ndice? La siguientes frmulas puede resultar til para una estimacin aproximada: Para una tabla: x rows * (5 bytes + y columns * (1 byte + z)) # de bloques = -------------------------------------------------------------------------(blocksize bytes - 90 bytes) * (1 - PCTFREE/100) Tamao = # de bloques * 4096 Para un ndice:
x rows * (11 bytes + y + z) # de bloques = ------------------------------------------------------------------------------(blocksize bytes - 90 bytes) * (0.75 - PCTFREE/200) Tamao = # de bloques * 4096 donde: x= Cantidad de filas en la tabla. y=Cantidad de columnas en la tabla o en el ndice. z=El largo promedio de todas las columnas de la tabla o ndice (en bytes). blocksize=tamao de los bloques de datos = 4096. PCTFREE = Valor definido para la tabla o ndice (Ver adelante en este texto). Para qu sirven las directivas PCTFREE y PCTUSED? La anterior temtica explica la forma en Oracle administra el crecimiento los objetos frente a la demanda de espacio libre dentro de un tablespace. Adems de ello Oracle incorpora algoritmos relacionados con el manejo del espacio libre en la extensin de los bloques dentro de cada extent. Dos parmetros de manejo de espacio, el PCTFREE y el PCTUSED, permiten al diseador controlar el uso de espacio disponible para inserciones y actualizaciones de filas en los bloques de datos. Ambos parmetros pueden ser especificados durante la ejecucin de instrucciones de creacin o alteracin de objetos. El
parmetro PCTFREE es usado para indicar el porcentaje de espacio libre, dentro de un bloque, que ser reservado para actualizaciones de las filas almacenadas en dicho bloque. El PCTUSED es el parmetro que define la forma de administrar el resto del espacio libre, indicando el porcentaje mnimo de espacio del bloque que se tender a mantener lleno siempre para cada bloque, visto de otra manera el PCTUSED indicar cuando un bloque es removido o incluido en la lista de bloques libres, estar en esta lista significa estar disponible para aceptar nuevas filas. Cmo son usados los parmetros PCTFREE y PCTUSED? Cuando el objeto es creado o modificado se definen estos parmetros, el PCTFREE es una cantidad de espacio reservado que define una frontera dentro del bloque, nuevas filas sern insertadas en el bloques hasta alcanzar esta frontera, momento en el cual el bloque se consider lleno. Este espacio reservado se usar solamente para actualizaciones de las filas que se encuentran almacenadas en el bloque. PCTFREE=20 por ejemplo, indicar que en cada bloque perteneciente al objeto se reservar un 20 % del espacio para futuras actualizaciones. Antes de que la frontera del PCTFREE sea alcanzada, el espacio libre disponible puede ser usado tanto por la inclusin de nuevas filas como por la actualizacin de las filas ya existentes. Luego de que un bloque llegue a estar lleno, segn lo indicado por el PCTFREE, el bloque no ser considerado (ser excluido de la free-list) para nuevas inserciones de filas hasta que el porcentaje de espacio usado llegue a reducirse hasta un valor menor que el PCTUSED. Cuando este valor sea alcanzado el bloque ser nuevamente considerado en el proceso de inclusin de filas, para ello el bloque se agregar a la free-list del objeto
Header Espacio libre Espacio usado
La filas son insertadas hasta un 80%, ya que indic un 20% pctfree.
El bloque se encuentra lleno, ya que alcanz al pctfree. Solo se soportan actualizaciones.
El bloque se considerar nuevamente para insercin de filas hasta que el porcentaje de uso sea menor que un 40%, vlor del pctused.
El ciclo de llenado y vaciado es repetido una y otra vez.
Qu sucede si el espacio para actualizaciones dentro de un bloque no es suficiente para acomodar la modificacin? El conocido y molesto efecto de encadenamiento es manifestado en esta situacin. Por ejemplo el encadenamiento entre bloques es comn cuando se manejan campos LONG. Si el largo de fila incluyendo la modificacin puede ser suficientemente pequeo como para guardarse en algn otro bloque, la fila es migrada en su totalidad al nuevo bloque,
sin embargo en el bloque anterior se mantendr un puntero a la nueva ubicacin. El encadenamiento y migracin de filas tiene un efecto negativo desde la perspectiva de I/O. Cmo se seleccionan los valores apropiados de PCTFREE y PCTUSED? El desempeo de algunas operaciones de base de datos puede verse mejorado mediante el uso adecuado de los parmetros en mencin. Es importante estar familiarizado con las aplicaciones, en particular es necesario saber cuales operaciones de base datos son realizadas con ms frecuencia en los objetos. Un bajo valor de PCTFREE puede mejorar el desempeo de full scans, ya que existir un promedio mayor de filas por bloque, y ser posible leer todas las filas leyendo menos bloques. Un valor bajo de PCTFREE debe ser usado en tablas query-por excelencia que carecen de la necesidad de actualizacin de sus filas. Un valor alto de PCTFREE disminuye la probabilidad de encadenamiento cuando la filas sean expandidas. Existe el riesgo de desperdicio de espacio libre. Recurdese que el PCTUSED sugiere la inclusin y eliminacin de los bloques en las listas de libres, as un valor bajo de PCTUSED har que los bloques sean retornados a las lista de libres con ms espacio disponible, ello disminuye tambin la probabilidad de encadenamiento. Un valor alto de PCTUSED reduce la cantidad de espacio libre para los bloques en la lista, ya que los bloques son retornados a la lista con poco espacio disponible. Un alto valor de PCTUSED almacena los datos de un modo ms eficiente desde la perspectiva de espacio, pero incrementa la probabilidad de encadenamiento (si no se usa un valor apropiado de PCTFREE) e incrementa el overhead de administracin de las listas de libres. Cuando un bloque es retornado a la lista de libres se ubicar al inicio de la lista, por ello un valor adecuado de PCTUSED permitir garantizar que el espacio liberado por DELETEs . Generalmente los ndices no son modificados por ello es recomandable el uso de un bajo PCTFREE.
Operaciones rutinarias de manejo fsico de archivos de Oracle Cmo cambiar el tamao de los datafiles
En Oracle 7.2 o superiores, los datafiles existentes pueden ser redimensionados, ya sea para hacerlos ms grandes o ms pequeos, si errneamente se asign demasiado espacio para un datafile. alter tablespace DATA datafile /f/oracle/data/data01.dbf resize 200M; Tambin tenemos a partir de esta versin opciones a la hora de crear un datafile para manejar un crecimiento dinmico: create tablespace DATA datafile /f/oracle/data/data01.dbf size 200M autoextend on next 10M maxsize 250M;
Cmo mover datafiles

Eventualmente necesitamos mover datafiles de un disco a otro por distintas razones, una puede ser que nos hayamos dado cuenta que la carga de I/O est desbalanceada o porque hemos agregado un disco nuevo al equipo, etc. 1. Ponemos el tablespace fuera de linea: alter tablespace DATA offline; 2. En el sistema operativo movemos el archivo de posicin: mv /f/oracle/data01.dbf /h/oracle/data 3. Alteramos el tablespace para que refleje el cambio: alter tablespace rename datafile /f/oracle/data01.dbf to /h/oracle/data01.dbf; 4. Ponemos el tablespace nuevamente en lnea: Alter tablespace DATA online;
Cmo mover Online Redo Log Files

A veces tambin se requiere mover los Online redo logs por las mismas razones de porqu debemos mover un datafile para esto debemos realizar los siguientes comandos: 1. Primero debemos bajar la base de datos: svrmgrl connect internal; shutdown exit; 2. Luego movemos el online redo log: mv /f/oracle/redo01.dbf /h/oracle/redo01.dbf 3. Luego montamos la base de datos (sin abrirla), suponiendo que la instancia se llama DEMO: svrmgrl connect internal; startup mount demo; alter database rename file /f/oracle/redo01.dbf to /h/oracle/redo01.dbf; 4. Luego abrimos (en la misma sesion del svrmgrl) la base de datos: alter database open;
Cmo mover Control Files

Mover un control file, no ser por cuestiones de I/O, podra ser por cuestiones de disco generalmente, para acerlo debemos realizar los siguientes pasos: 1. Primero debemos bajar la base de datos: svrmgrl connect internal; shutdown exit; 2. Luego movemos el control file: mv /f/oracle/ctrl01.ctl /h/oracle/ctrl01.ctl 3. Luego editamos el archivo config.ora: por ejemplo digamos que el config.ora tenia: control_files = (/f/oracle/ctr01.ctl, /f/ctrl02.ctl) entonces ahora quedara: control_files = (/h/oracle/ctr01.ctl, /f/ctrl02.ctl) 4. Luego subimos la base de datos nuevamente: svrmgrl connect internal; startup; exit;
Laboratorio, Instancias y Tablespaces

En esta clase haremos un laborotorio donde aprenderemos bsicamente a crear una instancia y sus tablespaces. Nota: cambiar XXXX por lo que usted quiera. 1. 2. 3. 4. Entrar a Linux con el usuario oracle, sin password. Abra una sesin de terminal. cd $ORACLE_HOME/dbs cp initDEMO.ora initXXXX.ora
5. Ejecutar en Unix, vi createXXXX.sql, adecelo al nombre XXXX que usted haya elegido:
spool createdbTEST set echo on connect INTERNAL/manager startup nomount pfile=$ORACLE_HOME/dbs/initTEST.ora CREATE DATABASE TEST LOGFILE '$ORACLE_HOME/dbs/redoTEST01.log' SIZE 1024K, '$ORACLE_HOME/dbs/redoTEST02.log' SIZE 1024K MAXLOGFILES 32 MAXLOGMEMBERS 2 MAXLOGHISTORY 1 DATAFILE '$ORACLE_HOME/dbs/systemTEST01.dbf' SIZE 50M MAXDATAFILES 254 MAXINSTANCES 1 CHARACTER SET WE8ISO8859P1 NATIONAL CHARACTER SET WE8ISO8859P1; ALTER DATABASE DATAFILE '$ORACLE_HOME/dbs/systemTEST01.dbf' AUTOEXTEND ON; CREATE ROLLBACK SEGMENT SYSROL TABLESPACE "SYSTEM" STORAGE (INITIAL 100K NEXT 100K); ALTER ROLLBACK SEGMENT "SYSROL" ONLINE; CREATE TABLESPACE RBS DATAFILE '$ORACLE_HOME/dbs/rbsTEST01.dbf' SIZE 12M DEFAULT STORAGE ( INITIAL 1024K NEXT 1024K MINEXTENTS 2 MAXEXTENTS 121 PCTINCREASE 0); ALTER DATABASE DATAFILE '$ORACLE_HOME/dbs/rbsTEST01.dbf' AUTOEXTEND ON;
ALTER TABLESPACE SYSTEM DEFAULT STORAGE ( INITIAL 100K NEXT 100K MINEXTENTS 1 MAXEXTENTS 300 PCTINCREASE 1); CREATE TABLESPACE USERS DATAFILE '$ORACLE_HOME/dbs/usersTEST01.dbf' SIZE 3M DEFAULT STORAGE ( INITIAL 50K NEXT 50K MINEXTENTS PCTINCREASE 1);
MAXEXTENTS
121
ALTER DATABASE DATAFILE '$ORACLE_HOME/dbs/usersTEST01.dbf' AUTOEXTEND ON; CREATE TABLESPACE TEMP DATAFILE '$ORACLE_HOME/dbs/tempTEST01.dbf' SIZE 20M DEFAULT STORAGE ( INITIAL 100K NEXT 100K MINEXTENTS 1 MAXEXTENTS 121 PCTINCREASE 0) TEMPORARY; ALTER DATABASE DATAFILE '$ORACLE_HOME/dbs/tempTEST01.dbf' AUTOEXTEND ON; CREATE TABLESPACE INDX DATAFILE '$ORACLE_HOME/dbs/indxTEST01.dbf' SIZE 10M DEFAULT STORAGE ( INITIAL 50K NEXT 50K MINEXTENTS PCTINCREASE 1);
MAXEXTENTS
121
ALTER DATABASE DATAFILE '$ORACLE_HOME/dbs/indxTEST01.dbf' AUTOEXTEND ON; CREATE TABLESPACE OEM_REPOSITORY DATAFILE '$ORACLE_HOME/dbs/oemrepTEST01.dbf' SIZE 5M AUTOEXTEND ON NEXT 25M MAXSIZE 80M MINIMUM EXTENT 128K DEFAULT STORAGE ( INITIAL 128K NEXT 128K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0); CREATE PUBLIC ROLLBACK SEGMENT RB0 TABLESPACE RBS STORAGE (INITIAL 100K NEXT 250K); CREATE PUBLIC ROLLBACK SEGMENT RB1 TABLESPACE RBS STORAGE (INITIAL 100K NEXT 250K); ALTER ROLLBACK SEGMENT "RB0" ONLINE; ALTER ROLLBACK SEGMENT "RB1" ONLINE; alter user sys temporary tablespace TEMP; alter user system temporary tablespace TEMP; @$ORACLE_HOME/rdbms/admin/catalog.sql; @$ORACLE_HOME/rdbms/admin/catexp7.sql @$ORACLE_HOME/rdbms/admin/catproc.sql @$ORACLE_HOME/rdbms/admin/caths.sql connect system/manager @$ORACLE_HOME/sqlplus/admin/pupbld.sql
connect INTERNAL/manager alter rollback segment "SYSROL" offline; spool off
6. Ejecutar en Unix vi initXXXX.ora, cambiar lo que se muestra en negrita en el archivo initDEMO.ora:
# # $Header: init.ora 05-jun-97.14:56:46 hpiao Exp $ # # Copyright (c) 1991, 1997 by Oracle Corporation # NAME # init.ora # FUNCTION # NOTES # MODIFIED # hpiao 06/05/97 - fix for 803 # glavash 05/12/97 - add oracle_trace_enable comment # hpiao 04/22/97 - remove ifile=, events=, etc. # alingelb 09/19/94 - remove vms-specific stuff # dpawson 07/07/93 - add more comments regarded archive start # maporter 10/29/92 - Add vms_sga_use_gblpagfile=TRUE # jloaiza 03/07/92 - change ALPHA to BETA # danderso 02/26/92 - change db_block_cache_protect to _db_block_cache_p # ghallmar 02/03/92 - db_directory -> db_domain # maporter 01/12/92 - merge changes from branch 1.8.308.1 # maporter 12/21/91 - bug 76493: Add control_files parameter # wbridge 12/03/91 - use of %c in archive format is discouraged # ghallmar 12/02/91 - add global_names=true, db_directory=us.acme.com # thayes 11/27/91 - Change default for cache_clone # jloaiza 08/13/91 merge changes from branch 1.7.100.1 # jloaiza 07/31/91 add debug stuff # rlim 04/29/91 removal of char_is_varchar2 # Bridge 03/12/91 - log_allocation no longer exists # Wijaya 02/05/91 - remove obsolete parameters # ############################################################################## # Example INIT.ORA file # # This file is provided by Oracle Corporation to help you customize # your RDBMS installation for your site. Important system parameters # are discussed, and example settings given. # # Some parameter settings are generic to any size installation. # For parameters that require different values in different size # installations, three scenarios have been provided: SMALL, MEDIUM # and LARGE. Any parameter that needs to be tuned according to # installation size will have three settings, each one commented # according to installation size. # # Use the following table to approximate the SGA size needed for the # three scenarious provided in this file: #
# -------Installation/Database Size-----# SMALL MEDIUM LARGE # Block 2K 4500K 6800K 17000K # Size 4K 5500K 8800K 21000K # # To set up a database that multiple instances will be using, place # all instance-specific parameters in one file, and then have all # of these files point to a master file using the IFILE command. # This way, when you change a public # parameter, it will automatically change on all instances. This is # necessary, since all instances must run with the same value for many # parameters. For example, if you choose to use private rollback segments, # these must be specified in different files, but since all gc_* # parameters must be the same on all instances, they should be in one file. # # INSTRUCTIONS: Edit this file and the other INIT files it calls for # your site, either by using the values provided here or by providing # your own. Then place an IFILE= line into each instance-specific # INIT file that points at this file. ############################################################################### # replace DEFAULT with your database name db_name=XXXX db_files = 80 # db_files = 400 # db_files = 1000 db_file_multiblock_read_count = 8 # db_file_multiblock_read_count = 16 # db_file_multiblock_read_count = 32 db_block_buffers = 100 # db_block_buffers = 550 # db_block_buffers = 3200 shared_pool_size = 3500000 # shared_pool_size = 5000000 # shared_pool_size = 9000000 log_checkpoint_interval = 10000 processes = 50 # processes = 100 # processes = 200 parallel_max_servers = 5 # parallel_max_servers = 4 x (number of CPUs) # parallel_max_servers = 4 x (number of CPUs) log_buffer = 8192 # log_buffer = 32768 # log_buffer = 163840 sequence_cache_entries = 10 # sequence_cache_entries = 30 # sequence_cache_entries = 100 sequence_cache_hash_buckets = 10 # sequence_cache_hash_buckets = 23 # sequence_cache_hash_buckets = 89 # audit_trail = true # timed_statistics = true max_dump_file_size = 10240 # if you want auditing # if you want timed statistics # limit trace file size to 5 Meg each # SMALL # MEDIUM # LARGE # SMALL # MEDIUM # LARGE # SMALL # MEDIUM # LARGE # SMALL # MEDIUM # LARGE # SMALL # MEDIUM # LARGE # SMALL # MEDIUM # LARGE # SMALL # MEDIUM # LARGE # SMALL # MEDIUM # LARGE # SMALL # MEDIUM # LARGE
# Uncommenting the line below will cause automatic archiving if archiving has # been enabled using ALTER DATABASE ARCHIVELOG.
# log_archive_start = true # log_archive_dest = disk$rdbms:[oracle.archive] # log_archive_format = "T%TS%S.ARC" # If using private rollback segments, place lines of the following # form in each of your instance-specific init.ora files: # rollback_segments = (name1, name2) # # # # # # If using public rollback segments, define how many rollback segments each instance will pick up, using the formula # of rollback segments = transactions / transactions_per_rollback_segment In this example each instance will grab 40/10 = 4: transactions = 40 transactions_per_rollback_segment = 10
# Global Naming -- enforce that a dblink has same name as the db it connects to global_names = TRUE # # # # # Edit and uncomment the following line to provide the suffix that will be appended to the db_name parameter (separated with a dot) and stored as the global database name when a database is created. If your site uses Internet Domain names for e-mail, then the part of your e-mail address after the '@' is a good candidate for this parameter value. # global database name is db_name.db_domain
# db_domain = us.acme.com
# FOR DEVELOPMENT ONLY, DEFAULT TO SINGLE-PROCESS # single_process = TRUE # FOR DEVELOPMENT ONLY, ALWAYS TRY TO USE SYSTEM BACKING STORE # vms_sga_use_gblpagfil = TRUE # FOR BETA RELEASE ONLY. Enable debugging modes. Note that these can # adversely affect performance. On some non-VMS ports the db_block_cache_* # debugging modes have a severe effect on performance. #_db_block_cache_protect = #event = "10210 trace name #event = "10211 trace name #event = "10235 trace name #event = "10049 trace name true context context context context forever, forever, forever, forever, level level level level 2" 2" 1" 2" # memory protect buffers # data block checking # index block checking # memory heap checking # memory protect cursors
# define parallel server (multi-instance) parameters #ifile = ora_system:initps.ora # define two control files by default control_files = (control # # # # # #
XXXX1,
control
XXXX2)
Uncomment the following line if you wish to enable the Oracle Trace product to trace server activity. This enables scheduling of server collections from the Oracle Enterprise Manager Console. Also, if the oracle_trace_collection_name parameter is non-null, every session will write to the named collection, as well as enabling you to schedule future collections from the console.
# oracle_trace_enable = TRUE
7. En el prompt de Unix ejecutar: ORACLE_SID=XXXX
export ORACLE_SID 8. Ejecutar svrmgrl connect internal @createXXXX.sql 9. Si no hubo problemas, pruebe dentro del svrmgrl shutdown startup 10. Salga del svrmgrl, en Unix ejecute, ls -la *xxxx* , observe todos los distintos archivos que fueron creados, tales como datafiles, control files y redo logs. 11. En Unix ejecute, ps -ef | grep ora, observe los "background process" que estn corriendo.
Laboratorio, errores, cambiar datafiles, script genricos.

Provocar un error irrecuperable....
tamao
de
datafiles,
mover
1. Conectarse a Unix con el usuario Oracle y sin password. 2. Ejecutar: mv systemXXXX01.dbf XXXXsystem01.dbf 3. Ejecutar en el svrmgrl Connect internal Startup Ver los errores que aparecen...... Shutdown abort exit 4. Ejecutar: mv XXXXsystem01.dbf systemXXXX01.dbf
Mover datafiles, cambio de tamao y agregar datafiles

5. Ejecutar: mkdir new_disc Ponemos el tablespace fuera de linea: alter tablespace users offline; En el sistema operativo movemos el archivo de posicin: mv $ORACLE_HOME/dbs/usersXXXX01.dbf (en la misma linea->) $ORACLE_HOME/dbs/new_disc/usersXXXX01.dbf Alteramos el tablespace para que refleje el cambio: sqlplus system/odin o svrmgrl y connect internal alter tablespace USERS rename '$ORACLE_HOME/dbs/usersXXXX01.dbf ' '$ORACLE_HOME/dbs/new_disc/usersXXXX01.dbf'; Ponemos el tablespace nuevamente en lnea: alter tablespace USERS online; 6. En el laboratorio del dia de ayer creamos un tablespace USERS con un tamao de 3 megas, si desea verifquelo en Unix con el comando ls -la users* 7. Dentro del svrmgrl ejecute: alter tablespace USERS $ORACLE_HOME/dbs/new_disc/usersXXXX01.dbf resize con esto "estiramos" el datafile de 3M a 10M..... datafile 10M; datafile to
8. Ahora bien, si en el disco actual no hubiera ms espacio disponible, entonces tendramos que agregar un datafile ms a este tablespace: alter tablespace USERS add datafile '$ORACLE_HOME/dbs/new_disc/users02.dbf' size 1M;
Varios scripts
9. svrmgrl y connect internal show parameters observe la cantidad de parmetros posibles que maneja la base de datos, dele una mirada y trate de imaginarse para que sirve cada uno..... select tablespace_name, segment_name, status from dba_rollback_segs; select tablespace_name from dba_tablespaces; select tablespace_name, sum(bytes)/1024/1024 from dba_data_files group by tablespace_name; select tablespace_name, file_name, bytes/1024/1024 from dba_data_files; select username from dba_users; select username, default_tablespace, temporary_tablespace, profile from dba_users; select * from dba_profiles; de los anteriores scripts, observe cada resultado, piense en la utilidad que podran tener eventualmente..... 10. En Unix ejecute: sqlplus system/odin 11. Ahora cree los siguientes usuarios: Create user RH Identified by RH Default tablespace users Temporary tablespace temp Quota unlimited on users; Create user fernando Identified by fernando Default tablespace users Temporary tablespace temp Quota unlimited on users; Create user pedro Identified by pedro Default tablespace users Temporary tablespace temp Quota unlimited on users;
9. En unix ejecute: sqlplus prueba/prueba 10. Ahora creemos una tabla de ejemplo: Create table emp( Deptno number(5), Empno number(5), Name varchar2(30), Salary number(11,2), Mgr_no number(5), Birth_date date); Alter table emp Add constraint pk_emp Primary key(empno); Utilizando la sentencia insert de SQL, metale algunos datos de prueba a esta tabla. 11. Ahora conectese en sqlplus como system/odin: Create role gerente; Create role empleado; Grant gerente to fernando; Grant empleado to pedro; 12. Ahora conectese en sqlplus como usuario RH/RH: Grant select, insert, update, delete on emp to gerente; Grant select on emp to empleado; 13. Ahora conectese como fernando/fernando en sqlplus y trate de consultar, borrar o insertar datos nuevos en la tabla RH.emp 14. Luego conectese como pedro/pedro en sqlplus y trate de consultar, borrar o insertar datos en la tabla RH.emp
Afinamiento del SQLsad

Una aplicacin que est muy bien diseada en su modelo de base de datos, que corra en una base de datos donde hayamos tomado todas las precauciones posibles, puede ser que tenga problemas de rendimiento a pesar de todo debido a que los programadores escribieron el SQL sin tomar en cuenta ciertas condiciones para un desempeo ptimo. En una base de datos relacional, la localizacin fsica de los datos no es tan importante como la localizacin lgica dentro del diseo de la aplicacin. Sin embargo la base de datos tiene que encontrar los datos para poder devolverlos a un usuario que est haciendo una consulta. La llave para afinar el SQL es minimizar la ruta de bsqueda que la base de datos utiliza para encontrar los datos. Para todas las tablas en Oracle, cada fila tiene un RowId asociado. El RowID contiene informacin acerca de la localizacin fsica de la fila (archivo, bloque y fila dentro del bloque). Cuando un query sin clasula where es ejecutado, la base de datos deber realizar un full scan table, leyendo cada uno de los bloques de la tabla. Para hacer esto la base de datos localiza el primer extent de la tabla y entonces lee secuencialmente a travs de todos los extents de dicha tabla. Para tablas grandes esto puede significar una gran cantidad de tiempo. Cuando se consultan filas especficas, la base de datos podra utilizar un ndice para ayudar a acelerar la bsqueda las filas deseadas. Un ndice mapea valores lgicos de una tabla en sus respectivos RowId's, los cuales a su vez mapean la ubicacin fsica. Los ndices pueden ser nicos o no nicos. Podemos crear un ndice con varias columnas. A este se le llama un ndice concatenado, y ser utilizado si al menos la primer columna indexada es mencionada en el where. Por ejemplo supongamos un ndice con tres columnas: create index city_st_zip_ndx on employee(city, state, zip) tablespace indexes; si hacemos un query como: select * from employee where state = 'NJ'; el ndice no ser utilizado, debido a que la primer columna(City) no es usada en la clasula where. Si los usuarios, frecuentemente utilizan bsquedas por state, entonces el ndice debera ser recreado poniendo la columna state de primero. Ahora bien, cmo saber la ruta de acceso que utilizar la base de datos para realizar una consulta? Para esto tenemos en SQL*Plus el seteo "set autotrace on", el cual nos
permite luego de ejecutar una consulta ver si se utiliza o no algn ndice y en que forma est siendo utilizado. Para poder utilizar esta facilidad debemos ejecutar primero un script que se llama UTLXPLAN.sql, el cual normalemente se encuentra en el directorio $ORACLE_HOME/rdbms/admin. Por ejemplo el query: Select * from employee Where city > 'Y%'; producira el siguiente resultado: ------------------------------SELECT STATEMENT TABLE ACCESS BY ROWID EMPLOYEE INDEX RANGE SCAN CITY_ST_ZIP_NDX Para leer el plan, lea el orden de las operaciones desde adentro hacia fuera de la jerarqua. En el caso de ejemplo nos dice que hace un "range scan" del ndice, lo cual una bqueda dentro de un rango de valores, lo cual es mejor que leer toda la tabla. Cuando se evalan los resultados del plan, deberamos asegurarnos que los ndices ms selectivos (o sea los ms cercanos a valores nicos) sean utilizados por el query. Si se utiliza un ndice no muy selectivo, estaramos forzando a la base de datos a realizar lecturas innecesarias para resolver la consulta. Si la aplicacin est orientada a trabajos en lotes (data-warehouse), debemos enfocarnos a mejorar el tiempo total para completar la transaccion. Mejorar el rendimiento total de una transaccin requiere realizar "full table scans" en vez de ndices. Dado que los full table scan pueden utilizar el Parallel Query Option, podramos involucrar mayores recursos computacionales en la ejecucin de la consulta, mejorando con esto el rendimiento.
Afinando sintaxis
SQL es un lenguaje declarativo, de modo que los queries pueden ser escritos de muchas maneras. Aunque se pueden obtener resultados idnticos a partir de un nmero variado de queries, el tiempo de ejecucin de cada uno puede variar dramticamente. Para ilustrar este concepto, digamos que tenemos una pequea tabla de empleados con slo 15 filas y un ndice por sexo y fecha de contratacin. Si ejecutamos el siguiente query: Select emp_name From emp Where Sex = 'F' and hiredate between sysdate -90 and sysdate; Debido a que la tabla tiene slo 15 filas, la ms eficiente manera de realizar esta consulta sera realizando un full-table scan. Sin embargo, Oracle lo realizara (talvez) recorriendo
los ndices, aunque hubiera sido ms rpido el full-table scan. Esto causa I/O adicional para leer el rbol del ndice y luego accesar las filas de la tabla. Aunque este ejemplo es muy simplista, sirve para ilustrar el concepto de que el tiempo de ejecucin del SQL es muy dependiente de la estructura del query y de los ndices.
Consideraciones de costo
El primer paso para afinar el Oracle SQL es comparar el costo relativo de cada acceso SQL. Costo 1 2 3 4 5 6 7 8 9 10 11 Tipo de Operacin Una fila por Row ID Una fila por join de cluster Una fila por hash cluster con llave primaria o ndice nico. Una fila por llave primaria o ndice nico Join de cluster Llave de hash cluster Llave de cluster indexada ndice de mltiples columnas ndice una sla columna Bsqueda con lmites en columnas indexadas Bsqueda sin lmites en columnas no indexadas
Como vemos la forma ms rapida de recuperar una fila es conociendo su RowID. Algunas aplicaciones han cado en el error de utilizar bsquedas internas utilizando el RowId, pero NO EXISTE NINGUNA garanta de que una fila est siempre en el mismo RowID, ya que como recordarn una fila puede ser migrada en cualquier momento por falta de espacio, con lo que el uso de RowID se inutiliza. Por otro lado el mayor costo es un full-table scan. Para tablas pequeas es lo ms deseable, pero puede causar verdaderos dolores de cabeza cuando un full-table scan se realiza sobre una tabla grande. Por lo tanto evitar los full-table scan es la primera consideracin a la hora de realizar afinamiento. Sin embargo, debe considerarse otra situacin, por ejemplo para un query muy complejo, un full-table scan podra ser lo ms eficiente, pero esto es hecho en contra de "otros" SQL en el sistema que puedan estar corriendo en ese momento; entonces debemos preguntarnos afinamos un query especfico? o afinamos toda la base de datos como un conjunto?. La respuesta a estas preguntas no es sencilla, debido a que cada sentencia SQL debe ser afinada individualmente, pero este afinamiento NO debe realizarse a expensas de otros queries en la base de datos.
Operadores Booleanos en SQL

Desde que empezamos a estudiar Informtica se nos ha enseado que entre ms compacto sea un programa, mejor ser su ejecucin. En SQL esto no siempre es lo mejor, vemos el siguiente caso: select student_name from student where (student_nbr = :host_student or :host_student is null) and (social_security_nbr = :host_social or :host_social is null);
Como pueden ver este query est formulado para que funcione si el usuario digita el student_nbr o el social_security_nbr o ambos. Esta es una manera muy til de escribir el SQL ya que la aplicacin utiliza el mismo cdigo. Desde el punto de vista de programacin es muy conciso y claro. Desafortunadamente no se ejecuta eficientemente. Por ejemplo este query deberia reformularse como: Select student_name From student Where student_nbr = :host_student And :host_student is not null And :host_social is null UNION Select student_name From student Where social_security_nbr = :host_social And :host_social is not null And :host_student is null UNION Select student_name From student Where student_nbr = :host_student And social_security_nbr = :host_social And :host_social is not null And :host_student is not null UNION Select student_name From student Where :host_social is null And :host_student is null ;
Como podemos ver, el query original ha sido particionado en queries separaos y concatenados con el operardor UNION de SQL. Slo el cuarto query, en caso de que ambos valores en la forma sean nulos provocar un full-scan table, los otros tres utilizarn los ndices por student_nbr o social_security_nbr. Aunque reescribir este query de esta manera parece un gran esfuerzo, SI este query es para una aplicacin en lnea que es ejecutada MILES de veces al dia, la ganancia en el rendimiento bien vale la pena. Como reglas comunes podemos mencionar las siguientes para que nuestras consultas sean lo ms eficientes posible: NUNCA haga un clculo sobre (ej. WHERE salario * 5 > :mi_variable) una columna indexada
SIEMPRE que sea posible utilize UNION en vez de condiciones OR. Evite el uso de NOT IN or HAVING en la clasula WHERE. En lugar utilize la clasula NOT EXISTS. Siempre especifique valores numricos en forma numrica y valores carcter en forma carcter, o sea NO MEZCLE tipos de datos. Evite especificar NULL en una columna indexada. Evite el LIKE si se puede utilizar el =. Si su base de datos utiliza el optimizador basado en reglas (rule-based) , la posicin de las tablas en el WHERE es utilizado para escoger la tabla que va a manejar el query. Siempre ponga la tabla que ms filas va a traer de primero. Evite utilizar sub-queries cuando se puede hacer lo mismo con un JOIN. Utilize la funcin decode para minimizar el nmero de veces que una tabla es seleccionada. Para "apagar" un ndice que no quiere utilizar, concatene un string nulo a la columna indexada (ej. name||'') o agregele un cero si la columna es numrica (ej. salario+0). Si su consuta retorna ms del 20% de las filas en la tabla, utilize un full-scan table en lugar de un index-scan. SIEMPRE utilize alias de las tablas cuando referencia las columnas (ej. student.name)
Afinando los ndices en SQL

Como regla genera, los ndices siempre mejorar el rendimiento de una consulta en la base de datos. En Oracle, los ndices se utilizan para acelerar las consultas y para pre-ordenar conjuntos pequeos de datos sin generar un sort interno cuando se utiliza el order by. Para que se utilize un ndice, el optimizador de SQL debe reconocer que una columna tiene valor vlido para buscar en el ndice. A esto se le conoce como predicados de bsqueda, por ejemplo: Predicados vlidos select * from emp where emp_no = 123; select * from emp where dept_no = 10; Predicados invlidos select * from emp where emp_no = "123"; select * from emp where salary * 2 < 5000; select * from emp where dept_no != 10; Siempre que ocurra una transformacin sobre un campo, Oracle no podr utilizar un ndice para esta columna. Hay ocasiones en que cuando programamos la aplicacin podemos presumir cuando vamos a necesitar leer muchos datos y cuando pocos. Por ejemplo si tenemos la misma tabla student con un campo que tiene dos valores posibles ('GRADUADOS', 'NOGRADUADOS'). Supongamos que en la base de datos tiene un 90 % de estudiantes sin graduar y un 10% de graduados, Oracle no conoce esta distribucin de antemano, asi que si existiera un ndice sobre este campo, y realizamos una consulta donde el where especifica si el estudiante est graduado, Oracle utilizar el ndice, lo cual est bien porque slo hay un 10% de estudiantes graduados; pero en otra consulta o reporte talvez queramos traer slo los estudiantes no graduados, en este caso Oracle igual utilizar el ndice, pero no ser eficiente pues recuperar el 90% de los estudiantes, en este caso debemos anular el ndice concatenando un valor null en el where: Select * from student where student_leve||'' = 'NOGRADUADO";
ndices concatenados
Un ndice concatenado se crea basado en mltiples columnas. Este tipo de ndice puede acelerar grandemente una consulta cuando todas las columnas especificadas en el where pertenecen a un ndice. Por ejemplo, veamos el siguiente ndice: Create idnex idx1 On student (student_level, major, laste_name) ascending;
Este ndice puede ser utilizado para acelar bsquedas que hagan referencia a ambos campos, student_level y major: Select student_level From student Where student_level = 'NOGRADUADO' And major = 'computer science'; Sin embargo, algunos queries que utilizan uno u otro campo, no sern capaces de utilizar este ndice concatenado; en el siguiente ejemplo, slo el campo major es referenciado en el query: Select * From student Where major = 'computer science'; En este ejemplo, aunque el major est en el ndice, est como segunda columna, por lo que Oracle concluir que el ndice no es utilizable. Veamos este otro ejemplo: Select last_name From student Where student_level = 'PLEBE' Order by last_name; En este caso, debido a que el campo student_level es el pimer campo del ndice, la primera parte del ndice puede se leda, y el optimizador de SQL invocar un index scan.
ndices Bitmap
A partir de Oracle 7.3, podemos crear ndices bitmap, los cuales son una muy buena opcin para columnas de datos con muy pocos valores nicos, como regla general menor a 20. El ndice bitmap consume hasta 80 veces menos espacio que un ndice b-tree y provee un mejor tiempo de respuesta.
El operador NOT
El operador NOT causa que la utilizacin de un ndice sea OBVIADA causando un fullscan table en el siguiente ejemplo: Select * from student Where student_level = 'NOGRADUADO' And major != 'computer science'; Aqu la condicin NOT produce un full-scan table no deseado. Como hemos visto, muchas veces podemos provocar full-scan tables sin darnos cuenta o imaginarnoslo siquiera remotamente, para esto Oracle provee una herramienta muy til que es el EXPLAIN PLAN, el cual veremos en detalle.
EXPLAIN PLAN
Como hemos mencionado en clases anteriores antes de poder utilizar el explain plan debemos crear bajo el usuario correspondiente la tabla plan_table, cuyo script de creacin est en $ORACLE_HOME/rdbms/admin y se llama utlxplan.sql. Veamos un ejemplo de cmo utilizar esta facilidad: explain plan set statement_id = 'TEST1' for select * from student where student_nbr = 10; Es importante notar que al ejecutar en sqlplus este comando, el query no se ejecuta slo se valida contra la base de datos y se determina el plan de ejecucin, el query como tal no es ejecutado. Esto es importante para afinar querys sin esperar los resultados. Luego de haber llenado la tabla siguiente: plan_table debemos ejecutar un query como el
Set pages 9999 Select lpad(' ', 2*(level-1)) || operation operation, Options, Object_name, Position From plan_table Start with id=0 And statement_id='TEST1' Connect by prior id = parent_id;
como resultado de este query podemos ver si la consulta utiliza o no indices y en que forma, en este caso en particular utiliza la llave primaria que ha por student_nbr. Aunque el plan_table es til para determinar la ruta de acceso a los datos, por si slo no cuenta toda la historia. La configuracin de los datos es tambin una consideracin. Mientras que el optimizador de SQL conoce el nmero de filas de cada tabla (la cardinalidad) y la presencia de ndices sobre los campos, el optimizador de SQL NO conoce ciertos factores como el nmero esperado de filas retornadas de cada consulta. Existe otra herramienta, el trace de SQL, que muestra en detalle todos los recursos utilizados o consumidos durante la ejecucin de una consulta, tales como el nmero de accesos de I/O requeridos para satisfacer la consulta, el tiempo de CPU utilizado, etc. Esta la veremos ms adelante. Los posibles mtodos de acceso que podramos ver en un explain plan seran: AND-EQUAL, indica que las tablas estn siendo "joineadas" y que Oracle ser capaz de utilizar los valors de los ndices para hacer join de las filas. CONCATENATION, indica una operacin UNION.
COUNTING, indica el uso de la funcin count de SQL. FILTER, indica que la clasula where est removiendo filas no deseadas del conjunto resultante. FIRST ROW, indica que se ha declarado un cursor para la consulta FOR UPDATE, indica que las filas retornadas sern bloqueadas. INDEX (UNIQUE), indica que se utiliza un valor especfico de llave. INDEX (RANGE SCAN), indica que se busca por rangos en un ndice, usualmente al utilizar BETWEEN, LESS THAN o GREATHER THAN. INTERSECTION, indica un conjunto solucion para dos tablas joineadas. MERGE JOIN, indica que se utilizaron dos conjuntos resultantes para resolver la consulta. NESTED LOOPS, indica que la ltima operacin se realizada n veces, una por cada operacin precedente. PROJECTION, indica que slo ciertas columnas de una fila seleccionada sern retornadas SORT, indica un ordenamiento, en memoria o en el tablespace TEMP. TABLE ACCESS (ROWID), indica que una fila es accesada por ROWID. TABLE ACCESS (FULL), este es un full-table scan y es el ms lento de todos a menos que la tabla sea muy pequea. UNION, indica que probablemente se utiliz la clasula DISTINCT de SQL. VIEW, indica que una vista de SQL est involucrada en la consulta.
Optimizadores de Oracle
Oracle ofrece dos mtodos para afinar SQL, si se est usando Oracle 7.2 o superior, podemos utilizar el optimizador basado en costos, mientras que para versiones anteriores lo aconsejable es utilizar el optimizador basado en reglas. Cuando se utiliza en optimizador basado en reglas, el indexado de las talbas y el ORDEN de las clasulas dentro de cada sentencia SQL controlan las rutas de acceso. El optimizador basado en costos automticamente determina la ruta de ejecucin ms eficiente y el programador puede pasar ciertos hints para altera la ruta de acceso ya que conoce de antemano los resultados. Por default Oracle se instala con el parmetro opimizer_mode=CHOOSE, esto le indica a Oracle favorecer el optimizador basado en costos siempre y cuando las tablas involucradas en la consulta tengan estadsticas. Las estadsticas son creadas con el comando ANALYZE TABLE. Esto tiene varios problemas potenciales como son: 1. Por ejemplo en una consulta con tres tablas, si una o ms tienen estadsitcas, Oracle utilizar el optimizador basado en costos y ejecutar un
analyze tabla para las otras tablas que no tienen estadsiticas en tiempo de ejecucin retardando enormente esa consulta en particular. 2. Si, el DBA no ejecuta regularmente el analyze table, las estadsitcas estarn desactualizadas y provocarn resultados aleatorios. En general el optimizador basado en costos es la mejor opcin pero las estadsticas deben actualizarse regularmente. Para hacer esto podramos ejecutar regularmente el siguiente script: Spool runstat.sql Select 'analyze table ' || owner || '.' || table_name || ' estimate statistics sample 20%;' from dba_tables where owner not in ('SYS','SYSTEM'); select 'analyze index '|| owner || '.' || index_name || ' compute statistics;' from dba_indexes where owner not in ('SYS','SYSTEM'); spool off @runstat
Hints
Hay ocasiones en que las que el optimizador de Oracle decida no es lo mejor. Para esto tenemos a disposicin una serie de hints, los cuales son mayormente tiles cuando tenemos alguna idea del comportamiento de la aplicacin y los datos. En forma genrica podriamos hacer que para una aplicacin o sesin en particular cambiemos la forma de trabajar del optimizador: Alter session set optimizer_goal = ALL_ROWS; o Alter session set optimizer_goal = FIRST ROWS; el primero le indica al optimizador que lo que queremos es que traiga TODO lo antes posible, en cambio el segundo le indica que traiga la primera fila lo antes posible. Normalmente el primero se utilizara para procesos en lotes (generalmente nocturnos) y la segunda para aplicaciones en lnea. Adems para una query en particular podemos indicarle al optimizador hints especficos utilizando el siguiente ejemplo: select /*+ ALL_ROWS /* customer_name from customer;
en vez de ALL_ROWS podemos utilizar: ALL_ROWS, provee el mejor rendimiento global y un consumo menor de recursos, para procesos en lotes. FIRST_ROWS, provee el mejor tiempo de respuesta en lnea. INDEX(table_name index_name), obliga al optimizador a utilizar un ndice en particular. Por ejemplo: select /*+ INDEX(PK_PR_CREDITOS PR_CREDITOS) */ monto_credito from pr_creditos; RULE, indica que se utilize el optimizador basado en reglas, recuerde que el where debe estar en orden con respecto a los ndices y la tabla ms pequea debe estar a la derecha del from. hay muchas opciones ms no utilizadas frecuentemente. Debido a que los hints son codificados en las consultas como comentarios, el SQL no le indicar un error si un hint est escrito incorrectamente. Cuando utilize ALTER SESSION SET OPTIMIZER_GOAL, es importante recordar que este no tendr efecto para SQL que ya est en el shared pool de SQL, si se desea se puede ejecutar el comando ALTER SYSTEM FLUSH SHARED POOL para que regenere los SQL en el shared pool.
Afinando Sub-queries
Siempre que sea posible, el uso de un sub-query debe ser evitado en Oracle. En la mayora de los casos, el subquery puede ser remplazado por un JOIN estndar. Sin embargo hay circunstancias en las que el uso de un sub-query es inevitable. Como sabemos, Oracle en un update o delete slo permite UNA tabla, como consecuencia, la nica manera de especificar valores de otra tabla es haciendo un subquery, por ejemplo: Update table1 Set attr = 'Y' Where key in (select key from table2); Hemos dicho antes que cada quien puede escribir un query como le parezca y tengamos 30 querys que hagan lo mismo escritos en forma diferente, para el ejemplo podramos tener cuatro combinaciones bsicas, usando IN y un subquery correlacionado, IN y un subquery no-relacionado, tambin podemos usar EXISTS y un subquery correlacionado o uno no-relacionado. En esencia, un subquery correlacionado referencia la tabla externa mientras que uno norelacionado no referencia la tabla externa. Un subquery correlacionado es evaluado una vez por fila procesada en el query padre, mientras que un subquery no-relacionado se ejecuta una sla vez y, el resultado es mantenido en memoria si es pequeo o en un segmento temporal, si el resultado es grande. Un query no-relacionado que retorna un solo valores llamada un subquery scalar. En este caso el optimizador sustituye el resultado como una constante y ejecuta el subquery UNA sola vez.
Veamos un ejemplo de un mismo subquery escrito correlacionado y no-relacionado: No-relacionado select count(*) from table1 where key in (select key from table2); Correlacionado Select Count(*) From Table1 Where Key in (select key from table2 where table1.key = table2.key); Cul de estos dos ser ms eficiente? Eso depende de la cantidad de filas retornadas por el query padre y por el subquery. Debemos balancear la sobrecarga asociada con cada tipo de subquery: Subquery correlacionado: es re-ejecutado una vez por cada fila retornada en el query externo. Por lo tanto debemos asegurar que el subquery use un ndice siempre que sea posible. Subquery no-relacionado: es ejecutado una vez, y el resultado es normalmente ordenado y mantenido en un segmento temporal. Si el resultado es muy grande tendremos problemas al ordenar y almacena el resultado en un segmento temporal. Como reglas generales podemos decir: Cuando se utiliza un subquery correlacionado, los resultados son identicos para la clasula IN y EXISTS. La clasula EXISTS no es apropiada para querys no-relacionados. Cuando un query padre retorna un nmero relativamente pequeo de filas, un subquery correlacionado se ejecuta ms rapido que un subquery norelacionado. Cuando un subquery retorna un nmero pequeo de filas, un subquery norelacionado ser ms rapido que uno correlacionado.
Afinamiento de la utilizacin de memoria

El tamao de memoria utilizado por Oracle es comunmente llamada la regin Oracle. La manera en que es manejada puede tener un gran impacto en el rendimiento y cada SGA debe ser afinada de acuerdo a los requerimientos de la aplicacin. Sin embargo debemos recordar que la SGA recibe fuerzas dinmicas y una sola transaccin puede ocasionar problemas para otras. Cientos de transacciones pueden ser servidas concurrentemente, cada una solicitando datos distintos. Afinar la memoria para cada actividad en un punto en el tiempo puede no ser lo mejor en otro punto diferente. Debido a la naturaleza dinmica de las bases de datos Oracle, slo es posible una afinamiento general. Afinar la memoria utilizada por Oracle involucra un gran nmero de parametros y carctersticas: Determinar el tamao de la SGA Afinar la PGA Afinar el ordenamiento Afinar el data buffer Afinar el shared pool Afinar el memory cache Otros
Determinar el tamao de la SGA

El archivo init.ora no slo determina el tamao global de la SGA sino tambin cuales estructuras tendr un tamao especfico de memoria. Oracle8 contiene 184 parametros de inicializacin. Para ver el tamao de la SGA, usted puede ejecutar el comando show SGA en el svrmgrl: SVRMGRL>show sga Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers 8252756 bytes 48260 bytes 6533328 bytes 1638400 bytes 32768 bytes
Afortunadamente, solo cinco parmetros son de importancia para el rendimiento global de Oracle, aunque hay otros que tambin influyen: db_block_buffers, este parmetro determina el nmero de database block buffers que habr en la SGA y representa el parmetro ms importante para la memoria de Oracle db_block_size, el tamao de los bloques de base de datos pueden provocar un gran mejoramiento en el rendimiento. Mientras el valo por defecto es de 2048 bytes, las bases de datos con tablas enormes y full-scan tables vern un gran mejoramiento incrementando el db_block_size.
log_buffer, este parmetro determina la cantidad de memoria reservada para los buffers de redo log. Si hay una gran actividad de actualizacin, al log_buffer debera reservarsele ms espacio. shared_pool_size, este parmetro define el rea que es compartida por todos los usuarios en el sistema, incluye reas para SQL y cach del diccionario de datos. large_pool_size, este parmetro define un rea de memoria es utilizado exclusivamente para ordenar. Slo es valido cuando se usa el multithreaded server, pero tiene un gran impacto en el rea de memoria compartida, ya que segrega la memoria utilizada para ordenamiento del resto de reas.
Afinando la PGA
Como se ha mencionado anteriormente, la SAGA no es la nica memoria disponible para los programas. La PGA es un rea privada de memoria reservada para tareas externas. Es utilizada para mantener informacin especfica de la aplicacin, tales como valores de los cursores, reservar memoria para ordenamientos internos. Los siguientes dos parmetros influencian el tamao de la PGA: open_links, define el mximo numeo de sesiones remotas concurrentes que un proceso puede inciar. El valor por defecto es de cuatro, lo que significa que una sentencia SQL puede referenciar hasta un mximo de cuatro bases de datos dentro de un query. sort_area_size, define la mxima cantidad de memoria PGA que puede ser usada para ordenamientos en disco. Para sorts muy largos, Oracle ordenar los datos en el tablespace temporal y el area definida en el sort_area_sizee ser utilizada para manejar este proceso. Cuando se utiliza el multithreaded server, el area de sort es tomada de otra area definida por el large_pool_size.
Afinando el Ordenamiento
A menudo olvidado a la hora de afinar, el ordenamiento en Oracle se realiza implcitamente cuando ejecutamos un CREATE INDEX, ORDER BY o GROUP BY. En el momento de que una sesion empieza, se reserva una pequea ra en memoria para ser utilizada en caso de ocurrir un ordenamiento. Desafortunadamente, la cantidad de memoria debe ser la misma para todas las sesiones, no es posible agregar areas adicionales para tareas que hagan mucho sort. No obstante, el DBA debe buscar un balance que permita reservar suficiente rea de sort para evitar ordenamientos en disco para las tareas que lo requieran, aunque para la mayora de los procesos talvez no se utilize. El tamao del rea privada es determinada por el parmetro sort_area_size. El tamao de cada sort individual es especificado por el sort_area_retainde_size. Siempre que un sort no puede ser completado dentro del espacio asignado, se invocar un sort en disco, el cual utiliza el tablespace temporal. Como regla general, slo la creacin de un ndice o el ORDER BY deberan hacer sort en disco.
Los ordenamientos en disco son costos por varias razones. Primero, consumen recursos en el tablespace temporal. Oracle debe reservar bloques en el buffer para retener los bloques en el tablespace temporal. Los sorts en memoria son siempre preferibles que los sorts en disco ya que seguro retardarn esa tarea en particular e impactarn en algn grado las otras tareas concurrentes en la instancia. Tambin un excesivo ordenamiento en disco, causar un alto valor de esperas por buffers libres, paginando los bloques de otras tareas fuera del buffer. Podemos ver la cantidad de sorts en memoria y en disco ejecutando el siguiente query: Column value format 999,999,999 Select name, value from v$sysstat Where name like 'sort%'; por ejemplo: NAME --------sorts(memory) sorts(disk) sorts(rows) VALUE ---------7,019 49 3,288,608
Podemos ver que slo 49 de 7068 sorts fueron realizados en disco, lo cual es cerca de un 1%, lo cual es probablemente aceptable para un sistema en particular.
Afinando el buffer de datos

Cuando se hace una peticin de datos, Oracle primero busca en las estructuras internas de memoria para ver si los datos ya estn en el buffer. De esta manera Oracle evita hacer I/O innecesario. Obviamente si el costo de la memoria fuera an ms econmico, podras tener una base de datos con todos los datos cargados en memoria, pero esto no es realizable en la vida real. A lo mejor, podemos reservar una parte de memoria real para los buffers y Oracle se encargar de administralos. Oracle utiliza el algoritmo LRU para determinar cuales pginas de memoria deben ser liberadas. En la mayora de los sistemas UNIX los bloques de base de datos estn definidos de 2K. Recordemos que el I/O es el mayor retardo que existe un sistema cliente/servidor, y entre ms informacin relevante puede ser traida en cada I/O, mejor ser el rendimiento. El costo de leer un bloque de 8K no es significativamente mayor que leer 2K. Sin embargo, la lectura de un bloque de 8K, no ser de beneficio si slo se necesita una pequea fila, ahora bien si las tablas son ledas en forma completamente a menudo, entonces podemos tener enormes beneficios cambiandonos a bloques ms grandes. Para sistemas orientados a reportes, siempre es recomendable los bloques grandes. Sin embargo, la mayora de las bases de datos utilizadas para procesamiento en lnea en la noche realizan procesos tipo batch, por lo que casi siempre un tamao de bloque de 8K ser de gran beneficio casi siempre.
Para determinar como se est comportando actualmente la base de datos podemos correr el siguiente script, cuyo resultado DEBE ser siempre mayor a 70, sino se debe incrementar el parmetro db_block_buffers. Select trunc((1-(sum(decode(name, 'physical reads', value, 0))/ (sum(decode(name, 'db block gets', value,0))+ (sum(decode(name,'consistent gets', value,0))))) ) * 100) "Buffer Hit Ratio" from V$SYSSTAT; Esta estadstica es recolectada desde el momento que arranca la base de datos, asi que es posible que vare de un da a otro dependiendo de la carga, siempre debe tratarse de ejecutar en dias normales, no en cierres. Una cosa que podemos hacer y que puede mejorar el rendimiento ostentiblemente es parametrizar el __small_table_threshold, el cual define el tamao de las tablas o ndices que puede ser localizadas en el espacio del buffer cache, normalmente no ms del 10% de la SGA. Hoy da la mayora de las bases de datos residen en un solo servidor. En este caso podemos predicir cuanta memoria estar libre despues de calcular el consumo del Kernel de UNIX (50MB) y de la PGA, la cual podemos calcular como el tamao del sort_area_size por la cantidad de usuarios en lnea; por ejemplo si tenemos un equipo con 10 usuarios y 20MB de sort_area_size, entonces la PGA medir 200MB.
Afinando el Shared Pool Size

El shared pool es utilizado primordialmente para almacenar cursores SQL compartidos, procedimientos almacenados, e informacin de sesin, y funcionar como un cach para para el diccionario y el library cache. Library Cache Las areas SQL compartidas y las res PL/SQL son llamadas el library cache, es cual es un subcomponente del shared pool. El promedio de fallos (cache miss ratio) le indica al DBA si debe o no agregar ms espacio al shared pool, en general si el cache miss ratio es mayor a 1, deberiamos considerar agregar espacio al shared_pool_size. El siguiente script nos indica el estado del library cache: COLUMN "LIBRARY CACHE MISS RATIO" FORMAT 99.9999 COLUM "executions" FORMAT 999,9999,999 COLUMN "Cache misses while executing" FORMAT 999,999,999 Select sum(pins) executions, sum(reloads) "Cache misses while executing", (((sum(reloads)/sum(pins)))) "LIBRARY CACHE MISS RATIO" from V$LIBRARYCACHE;
por ejemplo puede resultar: executions --------------251,272 Cache misses while executing ----------------------------------------2,409 LIBRARY CACHE MISS RATIO ------------------------------------------.0096
Cache del Diccionario El cache del diccionario es utilizado para almacenar filas de las tablas internas de Oracle, incluyendo el SQL de los paquetes. Un paquete la primera vez que se invoca va a provocar un fallo de cache, pero los otros usuarios se van a beneficiar porque lo encontrarn en memoria. El resultado del siguiente script debe ser mayor a 90, de lo contrario el remedio es incrementar el shared_pool_size: COLUMN "Data Dict. Gets" FORMAT 999,999,999 COLUMN "Data DICT. cache misses" FORMAT 999,999,999 Select Sum(gets) "Data Dict. Gets", Sum(getmisses) "Data Dict. cache misses", Trunc((1-sum(getmisses)/sum(gets)))*100) "DATA DICT RATIO" From V$ROWCACHE; por ejemplo: Data Dict. Gets --------------------409,288 Data Dict. cache misses --------------------------------11,639 DATA DICT CACHE HIT RATIO ------------------------------------------97
CACHE
HIT
Cmo determinar cuando reconstruir ndices?

Uno de los problemas con muchas bases de datos Orale es su gran tamao. Para algunas muy grandes, realizar una reorganizacin de la Base de Datos es imprctica por la cantidad de tiempo(das) que tomaria exportar los datos a cinta, borrar y recrear luego la base de datos. Por esta razn debemos tratar mantener la base bien afinada sin necesidad de una restructuracin total. En Oracle, bajo condiciones un ndice casi nunca requerira reconstruirse a menos que exista gran cantidad de actividad de modificacin y borrado contra las columnas indexadas. El INSERT no causa problemas a los ndices. Ahora bien, como determinar cuales ndices se beneficiaran de una reconstruccin?. Para hacer esto podemos ejecuta el siguiente comando: Analyze index index_name validate structure; el resultado sera mas o menos: SQL>select * from index_stats; HEIGTH BLOCKS NAME ..... DEL_LF_ROWS DEL_LF_ROWS_LEN DISTINCT_KEYS 3 5636 INDEX_NAME 41031 3956 7
Las siguientes son muy tiles para determinar si se debe reconstruir un ndice: Height, se refiere al mximo nmero de niveles encontrado dentro del ndice. Un ndice deberia tener 90% de los nodos en tres niveles, pero cuando hay mucha actualizacin y borrado pueden producirse ms niveles. Siempre que el valor de height sea mayor a 3, nos podramos beneficiar de una una reconstruccin del ndice. Del_lf_rows, se refiere al numero de hojas que han sido marcadas para ser borradas del ndice. Esto ocurre cuando existe alta activdad de update dentro del ndice e indica que el ndice debe ser reconstrudo. distinct_keys, indica el nmero de llaves distintas dentro de un ndice, a este se le llama la cardinalidad del ndice, y aquellos indices con valores menores a 20 son candidatos para ser recreados como indices bitmap. most_repeated_key, cuenta el valor que ms se repite dentro de un ndice no nico.
Utilizacin de UTLBSTAT y UTLESTAT

Como mencionamos anteriormente hay ciertas vistas que guardan estadsticas de la base de datos, las cuales empiezan cuando se levanta la base de datos y se pierden cuando se baja esta. Oracle provee dos scripts localizados en $ORACLE_HOME/rdbms/admin, llamados utlbstat.sql y utlestat.sql, los cuales nos permiten almacenar en tablas la informacin estadstica para su posterior revisin sin que se pierdan cuando se baja la base de datos. El script utlbstat, arranca crea algunas tablas para recolectar las estadsiticas. Es recomendable, modificar este script para que estas tablas sean creadas en un tablespace aparte o modificar el usuario system para que el default tablespace sea otro distinto a SYSTEM. El utlestat, colecta informacin de las vistas dinmicas mantenidas por Oracle y la guarda en tablas, adems genera un archivo .txt con la informacin ms importante.
SQL trace facility

Esta facilidad de Oracle nos permite determina punto por punto todos los recusos consumidos por una aplicacin en particular, sea una forma o un reporte. Para poder utilizar esta facilidad debemos chequear los siguientes parmetros de la base de datos: TIMED_STATISTICS, este parmetro habilita o deshabilita la recoleccin de estadsticas, tales como CPU y tiempos utilizados por la facilidad de SQL Trace as como la recoleccin de ciertas estadsticas en las tablas dinmicas de rendimiento. El valor por defecto es FALSE. Si deseamos utilizar el trace debe estar en TRUE. MAX_DUMP_FILE_SIZE, es el tamao del archivo en el sistema operativo definido para los archivos de trace, por defecto su tamao es de 500 bytes, lo cual es muy pequeo. USER_DUMP_DEST, especifica la ruta precisa donde se van a grabar los archivos de trace. Este valor tambien puede ser modificado con: ALTER SYSTEM SET USER_DUMP_DEST=newdir. Luego de lo anterior debemos asegurar alguna manera de distinguir los trace files, como puede haber muchos archivos, ser bien difcil reconocer cual pertenece a la aplicacin que estamos queriendo hacerle trace. Para hacer esto podramos poner en alguna parte de la aplicacin un select como: SELECT 'program name' from dual, de esta manera luego con un utilitario como el grep podramos buscar cual trace es el que nos interesa. Existe otra manera un poco ms primitiva que sera borrar antes de ejecutar nuestra aplicacin todos los traces existentes y luego ser facil encontrar el trace que nos interesa porque debera ser el primero o alguno de los primeros.
Para habilitar el SQL trace ejecutamos el siguiente comando: ALTER SESSION SET SQL_TRACE = TRUE; Y para desahabilitarlo: ALTER SESSION SET SQL_TRACE = FALSE;
TKPROF
El tkprof acepta como entrada un archivo de trace y produce un archivo de salida formateado, tambien puede ser utilizado para generar planes de ejecucin. Veamos un ejemplo del tkprof para el siguiente query:
SELECT * FROM emp, dept WHERE emp.deptno = dept.deptno; call count ---- ------Parse 1 Execute 1 Fetch 1 cpu ------0.16 0.00 0.03 elapsed disk query current --------- -------- -------- ------0.29 3 13 0 0.00 0 0 0 0.26 2 2 4 rows -----0 0 14
Misses in library cache during parse: 1 Parsing user id: (8) SCOTT Rows ------14 4 4 14 14 Execution Plan --------------------------------------------------MERGE JOIN SORT JOIN TABLE ACCESS (FULL) OF 'DEPT' SORT JOIN TABLE ACCESS (FULL) OF 'EMP'
La sintaxis del tkprof es: Tkprof archivo1 archivo2 explain=user/password sort=xxxx archivo1 es el archivo trace, archivo2 es el archivo de salida. xxxx es igual a uno de los siguientes: PRSCNT PRSCPU PRSELA PRSDSK PRSMIS number of times parsed CPU time spent parsing elapsed time spent parsing number of physical reads from disk during parse number of consistent mode block reads during parse
PRSCU PRSMIS EXECNT EXECPU EXEELA EXEDSK EXEQRY EXECU EXEROW EXEMIS FCHCNT FCHCPU FCHELA FCHDSK FCHQRY FCHCU FCHROW
number of current mode block reads during parse number of library cache misses during parse number of executes CPU time spent executing elapsed time spent executing number of physical reads from disk during execute number of consistent mode block reads during execute number of current mode block reads during execute number of rows processed during execute number of library cache misses during execute number of fetches CPU time spent fetching elapsed time spent fetching number of physical reads from disk during fetch number of consistent mode block reads during fetch number of current mode block reads during fetch number of rows fetched
Interpretando la salida del tkprof

El tkprof lista las estadsticas de una sentencia SQL en filas y columnas. corresponde a uno de tres pasos en el procesamiento de una sentencia SQL: Parse Cada fila
Este paso traduce la sentencia SQL en el plan de ejecucin. Este paso incluye chequeos de autorizacin de seguridad, existencia de tablas, columnas y otros objetos referenciados. Este paso es la ejecucin de la sentencia por Oracle. Para sentencias INSERT, Execute UPDATE, DELETE este paso realiza tambin la modificacin de los datos; para setencias SELECT este paso identifica las filas seleccionadas. Fetch Este paso recupera las filas retornadas por la consulta. Este paso es slo realizado por sentencias SELECT. Las otras columnas son estadsticas combinadas para todos los parses, todos los executes y todos los fetches en la sentencia. Estos valores son 0 si el parmetro TIMED_STATISTICS est en FALSE. count cpu Nmero de veces que la sentencia fue parsed, executed o fetched.
Tiempo total de CPU en segundos para todos las llamadas de parse, execute o fetch para la sentencia. elapsed Tiempo total transcurrido en segundos para todos las llamadas de parse, execute o fetch para la sentencia disk Nmero total de bloques de datos ledos fsicamente desde los datafiles en disco para todos las llamadas de parse, execute o fetch para la sentencia query Nmero total de buffers recuperados en modo consistente para todos las llamadas de parse, execute o fetch para la sentencia. current Nmero total de buffers recuperados en el modo actual. Los buffers son recuperados en el modo actual para sentencias INSERT, UPDATE o DELETE.
Existen opciones en el tkprof, para almacena estos valores para hacer comparaciones entre diversas corridas en el tiempo.
Laboratorio, Tuning SQL

1. Ejecutar los siguientes comandos en sqlplus con usuario system/manager : create tablespace prueba datafile '/home/oracle/prueba01.dbf' size 100M; create user prueba identified by prueba default tablespace prueba quota unlimited on prueba; grant dba to prueba; 2. En Unix ejecutar: Imp userid=prueba/prueba file=prueba.dmp touser=prueba fromuser=prueba 3. Ejecutar sqlplus con el usuario prueba. 4. Ejecutar el comando: set autotrace on 5. Ejecute los siguientes querys, para cada uno, observe el plan de ejecucin, es el ptimo?, podra mejorarse?, prueba otras alternativas....., incluso crear ndices adicionales....
select count(cod_persona) from personas; select /*+ index(personas pk_personas) */ count(cod_persona) from personas; select saldo from cuenta_efectivo where cod_empresa = 5; select saldo from cuenta_efectivo where num_cuenta = 10;
select saldo from cuenta_efectivo where num_cuenta=100 and cod_empresa = '1'; select saldo from cuenta_efectivo where num_cuenta=100 and cod_empresa=1; select cod_persona, nombre from personas fec_nacimiento = to_date('130999','DDMMYY'); select count(*) from cliente where estado = 'A'; where
select /*+ index(personas x) */ count(cod_persona) from personas; (observe que no da error a pesar que el indice x no existe) select * from cliente where (cod_cliente = 10 or 10=10) and (cod_oficial = 40000 or 40000=40000); (produce un full scan) select estado from cliente where (cod_cliente = '10' and 10 is not null); (es parte del query anterior pero reformulado para no usar or, y se puede completar con UNION) select count(*) from cliente where estado='A'; (note que utiliza indice para recuperar pocas filas) select count(*) from cliente where estado='V'; (note que utiliza el ndice a pesar de que recupera casi todos los datos) select count(*) from cliente where estado||'' = 'V'; (matamos el ndice para que haga un full scan. select count(*) (select cod_cliente relacionado) from personas where cod_persona from cuenta_efectivo); (query personas, cuenta_efectivo in no
select count(*) from cod_persona=cod_cliente; select count(*) from cod_persona=cod_cliente(+);
where
personas,
cuenta_efectivo
where
select sum(saldo) from cuenta_efectivo x where cod_cliente in (select y.cod_cliente from cliente y where y.cod_oficial='39999' and y.cod_cliente = x.cod_cliente); (subquery correlacionado) select sum(saldo) from cuenta_efectivo x, cliente y where x.cod_cliente=y.cod_cliente and y.cod_oficial='39999'; (con join)
Si desea conocer cunto tiempo en realidad tarda un realizando puede hacer un script como el siguiente, en ejecute vi tiempos.sql y digite:
set serveroutput on declare x date; y date; z number; begin x:=sysdate; select sum(saldo) into z from cuenta_efectivo; y:=sysdate; dbms_output.put_line(to_char(yx,'9.9999999999999999999999999999999')); end; /
query unix,
slvelo y en sqlplus ejecutelo asi: @tiempos.sql el script le mostrar la diferencia en fracciones de da de la duracin del query.
Debemos tomar en cuenta que cuando ejecutamos un query, los datos que este traiga, sern almacenados temporalmente en el buffer cache, por esta razn la segunda vez que ejecutamos un mismo query, el tiempo de ejecucin va a ser mucho menor, si deseamos repetirlo en las mismas condiciones deberiamos ejecutar lo siguiente bajo el usuario system: Alter system flush shared_pool;
Laboratorio, Tkprof y otros scripts

1. Entre al unix con el usuario Oracle. 2. Ejecute el svrmgrl, connectese con internal y levante la base de datos. 3. Ejecute el siguiente script para determinar la ruta donde quedan almacenados los archivos de trace: Select name, value From sys.v_$parameter Where name like '%user_dump_dest%'; 4. En unix vaya a ese directorio y borre los archivos *.trc que existan. 5. Conctese en sqlplus con el usuario prueba. 6. Ejecute en plus el siguiente comando Alter session set sql_trace = true; 7. Ejecute el siguiente script:
select cod_persona, nombre, sum(SAL_TOTAL_CTA) from personas p, cuenta_efectivo c where p.cod_persona = c.cod_cliente
group by cod_persona,nombre; 8. Ejecute luego el comando: Alter session set sql_trace = false; 9. En unix ejecute: Tkprof xxx.trc salida.txt explain=prueba/prueba sort=PRSCPU 10. Observe con detenimiento el archivo salida.txt. 11. Repita el proceso de nuevo, observe la diferencia en los resultados. qu sucedi? Explique la razn de esto.
12. Entre al svrmgrl y ejecute: SVRMGRL>show SGA Observe los valores mostrados y trate de determinar de donde se calculan estos valores, observando los parmetros que estn en el archivo iniXXXX.ora. Parmetros: shared_pool_size, db_block_buffers, log_buffer 13. Ejecute el siguiente script: Column value format 999,999,999 Select name, value from v$sysstat Where name like 'sort%'; 14. Ejecute este otro script y observe el resultado: Select trunc((1-(sum(decode(name, 'physical reads',value,0))/ (sum(decode(name,'db block gets',value,0))+ (sum(decode(name,'consistent gets',value,0))))) )*100) "Buffer Hit Ratio" from v$sysstat; 15. Ejecute este script: COLUMN "LIBRARY CACHE MISS RATIO" FORMAT 99.9999 COLUM "executions" FORMAT 999,9999,999 COLUMN "Cache misses while executing" FORMAT 999,999,999 Select sum(pins) executions, sum(reloads) "Cache misses while executing", (((sum(reloads)/sum(pins)))) "LIBRARY CACHE MISS RATIO" from V$LIBRARYCACHE; 16. Y, por ltimo este otro script: COLUMN "Data Dict. Gets" FORMAT 999,999,999 COLUMN "Data DICT. cache misses" FORMAT 999,999,999 Select Sum(gets) "Data Dict. Gets", Sum(getmisses) "Data Dict. cache misses", Trunc((1-sum(getmisses)/sum(gets)))*100) "DATA DICT RATIO" From V$ROWCACHE;
CACHE
HIT
Seguridad y auditora
La seguridad y los procedimientos establecidos nos ayudan a proteger el activo de mayor crecimiento en las empresas: los datos. Y mientras que almacenar datos en la base de datos y hacerlos disponibles para todos los usuarios, tambin nos conlleva a tener la susceptibilidad de accesos no autorizados. Estos accesos deben ser prevenidos y detectados. Oracle tiene varios niveles de seguridad, y la habilidad de auditar cada nivel.
Capacidades de seguridad Seguridad de cuenta

Para accesar los datos en cualquier base de datos Oracle, debemos tener acceso a una cuenta. Este acceso puede ser directo (a traves de conecciones a la base de datos) o indirecto. Las conexiones indirectas incluyen acceso a travs de las ligas de base de datos a bases localizadas remotamente. Adems una cuenta puede ser "amarrada" a una cuenta de usuario en el sistema operativo. Cuando se crea una cuenta se le asigna un password. Este puede ser modificado por el DBA o por el usuario. La base de datos almacena los passwords en forma encriptada en una tabla del diccionario. Si la cuenta est amarrada al sistema operativo, el chequeo de password no se realiza, esa funcin se le delega al sistema operativo. A partir de Oracle8, los password pueden expirar, y el DBA puede establecer las condiciones bajo las cuales un password en particular puede ser reutilizado. Adems, podemos usar profiles para reforzar estndares para los password (tales como longitud mnima) y automticamente podemos bloquear cuentas si ocurren multiples fallos para conectarse.
Privilegios de Objetos
El acceso a los objetos dentro de la base de datos es realizado va privilegios. Esto se realia via el comando grant. Por ejemplo si el usuario RH es dueo de la tabla emp y ejecuta el siguiente comando: grant select on emp to public; entonces todos los usuarios, tendrn la capacidad de seleccionar registros de la tabla emp de RH. Los roles (grupos de privilegios), pueden ser utilizados para simplificar la administracin de los privilegios. Para aplicaciones con gran cantidad de usuarios, los roles reducen grandemente el nmero de grants necesarios. Adems los roles puede ser protejidos via password y pueden ser habilitados o deshabilitados dinmicamente.
Roles y privilegios a nivel de Sistema

Podemos utilizar roles para administrar los comandos de sistema disponibles a los usuarios. Estos comandos incluyen por ejemplo el create table o create index. Las acciones contra cada tipo de objeto de la base de datos es autorizado a travs de privilegios separados. Por ejemplo, a un usuario se le puede dar el grant CREATE TABLE, pero no el CREATE TYPE. Podemos crear roles personalizados tan detallados como queramos y dandole a los usuarios slo lo que requieren.
Implementando la seguridad Seguridad del Sistema Operativo

No podemos accesar una base de datos a menos que primero podamos directa o indirectamente accesar el servirdor en que la base de datos est coriendo. El primer paso para asegurar la base de datos es asegurar la plataforma y la red en la cual reside la base de datos. Una vez que esto es realizado, podremos considerar la seguridad del sistema operativo. Oracle utiliza una serie de archivos a los cuales los usuarios NO requieren acceso directo. Por ejemplo los datafiles y los online redo log son escritos y ledos por los procesos background de Oracle. Por lo tanto, slo un DBA requiere acceso directo a estos archivos al nivel de sistema operativo. Los vaciados de export y otros archivos de respaldo tambin deben ser asegurados.
Creando usuarios
Cuando se crea un usuario, el objetivo es establecer una cuenta segura y til que tenga los privilegios adecuados y los seteos por defecto correctos. Cuando creamos un usuario no tiene an privilegios para conectarse, los cuales debemos otorga luego via grant. Los posible parmetros a tomar en consideracin a la hora de crear un usuario son: Parmetro Username Password Default tablespace Uso Nombre del esquema Password para lacuena, puede estar asociada a la cuenta del usuario en el sistema operativo El tablespace por defecto en el cual sern creados los objetos del usuario. Esta opcin NO le da privilegios para crear objetos, es slo un valor por defecto. El tablespace en el cual se utilizarn los segmentos temporales durante transacciones de sort. Le permite al usuario almacenar objetos en el tablespace especificado hasta un total mximo indicado por quota. Asigna un profile al usuario. Si no se asigna ninguno, se utilizar el profile estndar. Los profiles se utilizan para restringir recursos del sistema y para reforzar la administracin de las reglas aplicadas sobre los passwords.
Temporary tablespace Quota Profile
Borrando usuarios
Un usuario puede ser borrado completamente de la base de datos con el comando DROP USER. Este comando tiene el parmetro CASCADE, el cual a su vez borra todos los objetos del usuario antes de borrar el usuario. Por ejemplo: drop user RH cascade; Cualquier vista, sinnimo, procedimiento, funcin o paquete que referencien objetos pertenecientes a este usuario sern marcados como invlidos.
Privilegios a nivel de sistema

Podemos utilizar roles a nivel de sistema para habilitar comandos de sistema utilizados para administrar la base de datos. Se pueden utilizar varios roles pre-configurados o crear roles propios segn las necesidades. Cuando damos un role con grant, tenemos la opcin "with grant option", la cual significa que ese usuario puede a su vez otorgar ese rol a otros usuarios. Tambien algunos de los roles tiene la opcion ANY, la cual significa que ese role pude crear objetos en el esquema de otros usuarios. A continuacin veamos una tabla con algunos de los privilegios: Privilegio CREATE [ANY] INDEX CREATE [ANY] PROCEDURE CREATE [ANY] SEQUENCE CREATE [PUBLIC] SYNONYM CREATE [ANY] TABLE CREATE [ANY] TRIGGER CREATE [ANY] VIEW ALTER ANY INDEX ALTER ANY PROCEDURE ALTER ANY TABLE DROP ANY INDEX DROP ANY PROCEDURE DROP ANY SEQUENCE ALTER SESSION CREATE SESSION Capacidades otorgadas Crear ndices Crear procedimientos, funciones o paquetes Crear secuencias Crear sinonimos privados o pblicos Crear tablas, el usario debe tener una quota para el tablespace o haber recibido UNLIMITED TABLESPACE Crear Triggers Crear vistas Alterar cualquier ndice Alterar cualquier procedimiento, funcion o paquete Alterar cualquier table. Adems le da la capacidad de compilar vistas en cualquier esquema. Borrar cualquier ndice Borrar cualquier procedemiento, funcin o paquete Borrar cualquier secuencia Alterar parmetros de la sesin Conectarse a la base de datos
CREATE [PUBLIC] DATABASE LINK CREATE PROFILE CREATE ROLE CREATE TABLESPACE CREATE USER
Crear ligas a otras bases de a Crear profiles para los usuarios Crear roles Crear tablespaces Crear nuevos usuarios
Existen ocho roles a nivel de sistema que vienen configurados con la base de datos, estos son: CONNECT, RESOURCE, DBA, IMP_FULL_DATABASE, EXP_FULL_DATABASE, SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE y DELETE_CATALOG_ROLE. El role connect, es el que tpicamente se le otorga a los usuarios. Aunque este role tiene algunas capacidades limitadas de creacin de objetos, no le otorga ninguna quota al usuario, por lo tanto si no le damos una quota no podr crear objetos. En general es mejor otorgar a los usuarios normales slo el privilegio CREATE_SESSION. El role resource se le otorga a los desarrolladores, ste tiene la mayora de los permisos requeridos normalmente por un desarrollador. El role dba incluye TODOS los privilegios a nivel de sistema. En general no debera haber ms de un usuario con role dba por base de datos. Los roles IMP_FULL_DATABASE y EXP_FULL_DATABASE son utilizados durante operaciones de import y export. En un ambiente organizacinal muy grande podriamos delegar la funcin de crear usuarios fuera del DBA para facilidad de administracin, sin otorgar ms que lo necesario para realizar esta funcion. Por ejemplo: create role account_creator; grant create_session, create user, alter user to account_creator; luego este nuevo rol se lo damos por ejemplo a alguna persona del departamento de Recursos Humanos. Tambin por razones de seguridad, podramos asignarle los roles necesarios a un usuario pero luego ejecutar el siguiente comando: alter user RH default role NONE; y luego programticamente en las aplicaciones habilitamos o deshabilitamos los roles segn se necesiten: alter user RH default role account_creator;
de esta manera si el usuario se conecta a la base de datos con una herramienta distinta como SQL*Plus, ste no tendra ningn role habilitado al momento de conectarse y por lo tanto no podra hacer mayor cosa en la base de datos.
Profiles de Usuario
Podemos utilizar profiles para configurar lmites a la cantidad de recursos del sistema y de la base de datos disponibles para el usuario, si no se especifica ninguno, se utiliza el default que asigna recursos ilimitados para los usuarios. Veamos que valores podemos definir en un profile: Recurso SESSION_PER_USER CPU_PER_SESSION CONNECT_TIME IDLE_TIME LOGICAL_READS_PER_SESSION FAILED_LOGIN_ATTEMPTS Descripcin El nmero de sesiones concurrentes que un usuario puede tener en una instancia El tiempo de CPU, en centsimos de segundo que puede utilizar una sesin El nmero de minutos que una sesin puede estar conectada a la base de datos El nmero de minutos que una sesin puede estar conectada sin ser utilizada. Nmero de bloques de base de datos que pueden ser ledos en una sesin. El nmero de intentos consecutivos de fallos de conexin que causarn que se bloquee una cuenta. El nmero de das que puede ser utilizado un password El numero de dias que deben pasar antes de que pueda ser reutilizado un password El nmero de veces que debe ser cambiado el password antes de que pueda reutilizarse el mismo. El nmero de das que una cuenta ser bloqueada si el FAILED_LOGIN_ATTEMPTS es excedido. Nmero de das de gracia que transcurren luego de ser excedido el PASSWORD_LIFE_TIME El nombre de la fncion utilizada para evaluar la complejidad del password, Oracle provee una que podemos modificar.
PASSWORD_LIFE_TIME PASSWORD_REUSE_TIME PASSWORD_REUSE_MAX
PASSWORD_LOCK_TIME PASSWORD_GRACE_TIME PASSWORD_VERIFY_FUNCTION
Los profiles son creados con el comando "create profile" y modificados con el comando "alter profile".
Asociando las cuentas de base de datos a cuentas del Sistema Operativo

Para facilitar la administracin de usuarios, si tenemos un sistema operativo confiable (NO WINDOWS), podemos definir las cuentas de usuarios de modo que el password y la cuenta sean las mismas del sistema operativo. En la base de datos estas cuentas tendrn por defecto el prefijo "OPS$" mas el userid. Por ejemplo consideremos una cuenta de usuario llamado JDURAN. En la base de datos el usuario ser OPS$JDURAN, luego de que este usuario accese el sistema operativo, podr conectarse a Oracle sin poner ni usuario ni password: >sqlplus / para crear un usuario en estas condiciones debemos utilizar "identified externally" en el create user: create user OPS$JDURAN identified externally default tablespace USERS temporary tablespace TEMP; Cuando se utiliza la clasula "identified externally", esto fuerza a la base de datos a validar la cuenta contra el sistema operativo.
Privilegios a nivel de Objetos

Los privilegios a nivel de objetos le dan a los usuarios acceso a los datos de los cuales ellos no son dueos. Podemos utilizar roles para facilitar la administracin de privilegios. Los privilegios son otorgados con el comando grant y son almacenados en el diccionario de datos. A los usuarios les podemos dar permiso para accear tablas, vistas, secuencias ms la habilidad para ejecutar procedimientos, funciones y paquetes. Los posibles privilegios de objetos son: Privilegio SELECT INSERT UPDATE Capacidades otorgadas Poder consultar un objeto Poder insertar filas en un objeto. Poder actualizar filas de un objeto. Este priviliegio puede ser otorgado sobre columnas especficas Poder borrar filas de un objeto Poder alterar un objeto Poder crear ndices sobre una table Poder crear llaves forneas que referencien una tabla Poder ejecutar funciones, paquetes o funciones Poder accesar un directorio
DELETE ALTER INDEX REFERENCES EXECUTE READ
Debemos tomar en cuenta que tambin podemos revocar privilegios o roles de un usuario utilizando: revoke delete on emp from RH; adems si un usuario tiene el privilegio select sobre una tabla pero va rol y desea crear una vista que utiliza esta tabla, NO podr crear esa vista a menos que le demos un grant directo sobre la tabla a ese usuario. A menudo requerimos revisar que privilegios tiene otorgados un usuario o rol particular, para esto tenemos una serie de vistas: Vista del Diccionario DBA_ROLES DBA_ROLE_PRIVS DBA_SYS_PRIVS DBA_TAB_PRIVS DBA_COL_PRIVS Contenido Nombres de los roles Usuarios a los que les ha sido otorgado roles Usuarios a los que se les ha otorgado privilegios del sistema Usuarios a los cuales se les ha otorgado privilegios sobre tablas Usuarios a los cuales se les ha otorgado privilegios sobre columnas especficas de tablas Roles que han sido otorgados a otros roles Roles a los que se les ha otorgado privilegios del sistema Roles a los que se les ha otorgado privilegios sobre tablas
ROLE_ROLE_PRIVS ROLE_SYS_PRIVS ROLE_TAB_PRIVS
Por ejemplo para saber qu privilegios del sistema han sido otorgados a cules roles, podemos ejecutar el siguiente script: Select Role, Privilege, Admin_option From role_sys_privs; O para determinar qu grants se le ha otorgado a los usuarios sobre qu tablas: Select Grantee, Owner, Table_name, Grantor, Privilege, Grantable From dba_tab_privs;
Adicionalmente hay dos vistas, que listan los privilegios y roles habilitados actualmente para una sesin: SESSION_PRIVS, lista todos los privilegios del sistema disponibles para la sesin, ya sean grants directos o va rol. Lista todos los roles habiltados para la sesin.
Limitando los comandos disponibles, Product User Profiles

Dentro de SQL*Plus, se ofrece un nivel adicional de seguridad, permitiendo habilitar o deshabilitar comandos especficos. De esta manera, los usuarios con el privilegio de UPDATE en una tabla pueden ser prevenidos de utilizar SQL*Plus para actualizar la tabla de manera NO controlada. Esta capacidad le permite a los DBA, evitar que los usuarios accesen el sistema operativo desde SQL*Plus va el comando "host". Tambin se puede deshabilitar el comando "connect", lo cual los obliga a permanecer slo en su cuenta propia. SQL>host invalid command: host SQL>connect system/manager invalid command: connect Para habilitar este nivel de seguridad, debemos crear las tablas del Product User Profile. El script para crearlas se encuentra en $ORACLE_HOME/sqlplus/admin y se llama pupbld.sql. Este script crea varias tablas y vistas y debe ser ejecutado dentro de la cuenta SYSTEM. En la siguiente tabla se muestran las columnas importantes para esta carcterstica: Nombre de la columna PRODUCT USERID Descripcin Poner "SQL*Plus", tal y como est escrito. El nombre del usuario en maysculas, o xxx% para varios usuarios o % para todos los usuarios El nombre en maysculas del comando a ser deshabilitado. Poner en "DISABLED" en maysculas.
ATTRIBUTE CHAR_VALUE
Auditando
La base de datos tiene la capacidad de auditar todas las acciones que ocurren dentro de ella. Estos registros son escritos a una tabla (SYS.AUD$) o al sistema operativo. La haiblidad de utilizar el sistema operativo depende de cul se utilize. Se pueden auditar tres distintos tipos de acciones: intentos de conexin, acceso a objetos y acciones de base de datos. Para habilitar la auditora, el archivo init.ora debe tener configurado el parmetro AUDIT_TRAIL con cualquiera de estos valores: NONE, auditora deshabilitada DB, habilita la auditora escribiendo a la tabla sys.aud$ OS, habilita la auditora utilizando la caracterstica de auditora que ofrezca el sistema operativo. Existen varias vistas para ver en forma legible los datos almacenados en sys.aud$, DBA_AUDIT_SESSION es una de ellas, por ejemplo para ver los intentos exitos o fallidos de conexin podemos ejecutar el siguiente comando: Select os_username, username, terminal, decode(returncode, '0','Connected', '1005', 'FailedNull', '1017', 'Failed', Returncode), to_char(timestamp, 'DD-MON-YY HH24:MI:SS'), to_char(Logoff_time, 'DD-MON-YY HH24:MI:SS') from dba_audit_session; Adems podemos auditar eventos u objetos especiales con el comando: audit xxxx; donde xxxx puede ser, DATABASE LINK, INDEX, PROFILE, ROLE, SESSION, TABLE, TRIGGER, TABLESPACE, etc... , o sea cada vez que se cree, borre o modifique alguno de estos, se dejar una huella en la auditora de la base de datos.
Para ver la auditora de estas acciones podemos ejecutar el siguiente script: Select Os_username, Username, Terminal, Owner, Obj_name, Action_name, Decode(returncode,'0','Success',returncode), To_char(timestamp,'DD-MON-YY HH24:MI:SS') From dba_audit_object; Tambien podemos auditar acciones especficas sobre un objeto u objetos: Audit insert on RH.emp; Audit all on RH.emp; Audit delete on RH.emp; los registros resultantes de este auditoraje quedan en la vista DBA_AUDIT_OBJECT, con esto podemos determinar con exactitud quin hizo qu cosas sobre qu tablas y en que momento especfico. Lo nico que debemos tener en cuenta es que estas tablas de auditora crecern mucho, provocando problemas en el tablespace SYSTEM, y debemos limpiar regularmente esta auditora para liberar espacio .
Respaldo y Recuperacin
Existen tres posibles mtodos para respaldar una base de datos Oracle: exports, offiline backups y online backups (ARCHIVELOG).
Respaldos Lgicos
Un respaldo lgico de la base de datos involucra leer un conjunto de registros y escribirlos a un archivo. Estos registros son ledos independientemente de su ubicacin fsica. En Oracle, el utilitario export es utilizado para realizar este tipo de respaldos.
Export
El utilitario export lee la base de datos, incluyendo el diccionario de datos, y escribe la salida a un archivo binario llamado archivo de vaciado de export. Podemos exportar TODA la base de datos (full), usuarios especficos o tablas especficas. Durante los exports, se puede escoger si queremos exportar informacin asociada a las tablas como grants, ndices y constraints. El archivo escrito por el export, contiene todos los comandos necesarios para completar la recreacin de todos los objetos escojidos. Un full export puede ser realizado para todas las tablas (llamado tambien export Completo), o slo para algunas tablas que hayan cambiado desde el ltimo export. Existen dos tipos diferentes de export incremental: Incremental y Acumulativo. El incremental exporta todas las tablas que han cambiado desde el ltimo export, mientras que el acumulativo exporta todas las tablas que han cambiado desde el ltimo full export.
Import
Una vez que los datos son exportados, puede ser importados utilizando el utilitario import. Este lee el archivo binario generado por el export y ejecuta los comandos que encuentre dentro de este. Por ejemplo estos comandos podran ser create table seguido de un insert para cargar los datos. Los datos que fueron exportados no tienen necesariamente que ser importados dentro de la misma base de datos o el mismo esquema donde se realiz el export. Podemos importar todo o parte de los datos. Si importamos un Full export en forma total, entonces todos los objetos de la base de datos, incluyendo tablespaces, datafiles y usuarios sern creados durante el import. Sin embargo, a menudo es til pre-crear los tablespaces y los usuarios de modo que podamos cambia la distibucin fsica de los objetos dentro de la base de datos.
Respaldos fsicos
Los respaldos fsicos involucran copiar los archivos que constituyen la base de datos sin importar su contenido lgico. Estos respaldos tambin se les conoce como respaldos a nivel de sistema de archivos porque conllevan utilizar utilitarios del sistema operativo para realizarlo.
Offline Backups
Los offline backups ocurren cuando la base de datos ha sido bajada normalmente (o sea, no por una falla de la instancia). Mientras la base de datos est "offline", se respaldan los siguientes tipos de archivos: Todos los datafiles Todos los control files Todos los online redo logs El archivo init.ora Es muy fcil respaldar estos achivos si utilizamos algn estndar en la estructura de directorios. Tener todos estos archivos respaldados mientras la base de datos est cerrada, nos provee una imagen COMPLETA de la base de datos tal y como exista en el momento de ser cerrada. Todos estos pueden ser restaurados posteriormene y la base de datos funcionar normalmente.
Online (ARCHIVELOG) backups

Podemos utilizar los online backups para cualquier base de datos que est corriendo en modo ARCHIVELOG. En este modo, los online redo logs son archivados, creando una bitcora completa de todas las transacciones dentro de la base de datos. Se puede realizar un respaldo a nivel de sistema de archivos mientras la base de datos est abierta si esta configurada con el ARCHIVELOG. Un respaldo en lnea involucra setear cada tablespace en un estado de respaldo, luego respaldar sus datafiles y, luego restaurar su estado a modo normal. La base de datos puede ser completamente recuperada va los archived redo logs. En un respaldo en lnea se respaldan estos archivos: Todos los datafiles Todos los redo logs archivados Un control file, via el comando alter database Los respaldos en lnea son muy poderosos. Primero, nos proveen una recuperacin completa a un punto en el tiempo y, segundo permiten que la base de datos permanezca abierta durante el respaldo. Sobre todo es importante en empresas donde las bases de datos no pueden ser bajadas porque se utilizan las 24 horas. Adems hay un beneficio adicional, al permanecer abierta, la SGA no se pierde, por lo tanto los caches permanecen intactos.
Implementacin Export
El utilitario export tiene tres niveles de funcionalidad: full, user, table. En el modo full, se exporta TODA la base de datos. Todo el diccionario de datos es ledo y se escriben los DDL necesarios para recrear completamente la base de datos. Este archivo incluye definiciones para todos los tablespaces, todos los usuarios, y todos los objetos, datos y privilegios. En el modo user, se exportan los objetos de un usuario junto con su definicin y datos. Todos los grants e ndices creados por el usuario sobre los objetos del usuario son exportados. Grants e ndices creados por otros usuarios NO son exportados en esta opcin. En el modo table, se exportan una o ms tablas especficas. La estructura de la tabla, los datos y los grants son exportados. Veamos los posibles parmetros del export y su funcionalidad: Parmetro USERID BUFFER FILE COMPRESS Descripcin Usuario y password que est ejecutando el export Tamao del buffer utilizado para recuperar las filas. Nombre del archivo que va a generar el export Es una bandera de valores Y o N que indica si el export comprime o no todos los extents de una tabla en un solo extent. Esto afecta la clasula storage de los objetos exportados. Es una bandara Y o N que indica si los grants sobre los objetos exportados tambin sern exportados. Una bandera Y o N que indica si se exportan las definiciones de los ndices. Una bandera Y o N que indica si se exportarn los datos, si se indica N, entonces slo se exportarn las definiciones DDL de las tablas. Una bandera Y o N que indica si los constraints sobre las tablas sern o no exportados. Si se pone Y, se realizar un full export. Es una lista de los usuarios a ser exportados. Lista de tablas a ser exportadas Longitud en bytes de los registros del archivo export, normalmente se deja el default a menos que requiramos pasar un export de un sistema operativo a otro distinto. Indica el tipo de export a ser realizado, los valores vlidos son : COMPLETE, CUMULATIVE, INCREMENTAL Es una bandera Y o N que indica si se realiza la opcin directa. Esta opcin se brinca el buffer cache durante el export, generando ganancias significativas de rendimiento durante el export El nombre de un archivo donde quedan todos los mensajes
GRANTS INDEXES ROWS
CONSTRAINTS FULL OWNER TABLES RECORDLENGTH
INCTYPE DIRECT
LOG
PARFILE
o errores dados por el export El nombre de un archivo de texto conteniendo todos estos parmetros
Opciones, Incremental vs Cumulative

Opcin COMPLETE CUMULATIVE Descripcin Es el valor por defecto. Todas las tablas especificadas sern exportadas. Si se indica FULL=Y, entonces puede utilizarse esta opcin. Slo aquellas tablas que contengan filaes que hayan cambiado desde el ltimo Full export de cualquier tipo sern exportadas Si se indica FULL=Y, entonces puede utilizarse esta opcin. Exporta todas las tablas cuyas filas hayan cambiado desde el ltimo export Cumulative o Complete.
INCREMENTAL
Import
El utilitario impor lee los datos del archivo generado por el export y ejecuta los comandos almacenados en l. Puede ser utilizado para restaurar selectivamente objetos o usuarios. A continuacin veamos los parmetros del import: Parmetro USERID BUFFER FILE SHOW IGNORE Descipcin Usuario y password de la cuenta que ejecuta el import. Tamao del buffer utilizado para leer datos. Nombre del archivo generado por el export Una bandera que muestra el contenido en vez de ejecutarlo Es una bandera que indica si el import debe ignorar los errorres provocados por el create cuando algn objeto ya exista. Es una bandera que indica si los grants sern importados o no. Una bandera que indica si se importarn o no los ndices. Es una bandera que indica si se importarn los datos. Si se especifica N, slo se ejecutarn los comandos DDL de creacin de los objetos. Si se especifica Y, se importar el archivo completo Una lista de usuarios cuyos objetos sern importados. (Cuando FULL=N) Lista de usuarios sobre los cuales sern restaurados los
GRANTS INDEXES ROWS
FULL FROMUSER TOUSER
TABLES RECORDLENGTH
INCTYPE COMMIT
PARFILE INDEXFILE
LOG ANALYZE
objetos Lista de tablas a ser restauradas Longitud en bytes de los registros del archivo export, normalmente se deja el default a menos que requiramos pasar un export de un sistema operativo a otro distinto. Indica el tipo de import a ser realizado, los valores vlidos son : COMPLETE, CUMULATIVE, INCREMENTAL Indica si el import debe hacer commit despues de cada arreglo (tamao del BUFFER), si se indice N, el import har commit despus de cada tabla. Normalmente use Y, para evitar problemas en los Rollback Segments durante el import. El nombre de un archivo de texto conteniendo todos estos parmetros Esta opcin escribe todos los comandos: create table, create cluster y create index a un archivo en luegar de ejecutar el import. Este archivo puede ser utilizado y es muy til para separar las tablas de los ndices. El nombre de un archivo donde quedan todos los mensajes o errores dados por el export Es una bandera que le indica al import si debe ejecutar los comandos analyze encontrados en el archivo export.
Una opcin muy utilizada es el Fromuser/Touser para mover datos entre usuarios, por ejemplo podramos ejecutar el siguiente comando: imp system/manager file=rh.dmp fromuser=rh touser=rh_new rows=y indexes=y;
Offline backups
En un respaldo en fro, se respaldan TODOS los archivos que constituyen la base de datos como hemos vistos previamente. Si nuestra base de datos est ubicada en un subdirectorio /discox/oracle/DEMO, donde discox puede ser disco1, disco2, etc.; en unix por ejemplo podramos ejecutar el siguiente comando para respaldar todos los archivos de la instanacia DEMO: Tar -cvf /dev/rmt/ohc /disco[1-9]/oracle/DEMO la opcin -cvf se utiliza para crear un archivo nuevo de tar. Para agregarle a este archivo el init.ora, que muy probablemente est en otra localizacin podemos ejecutar: tar -rvf /dev/rmt/ohc /orasw/app/oracle/DEMO/pfile/initDEMO.ora Estos dos comandos, ejecutados en conjunto, respaldarn todos los archivos de la base de dataos en un archivo en cinta. Antes de ejecutar los comandos anteriores debemos entrar al svrmgrl y hacer un shutdown de la base de datos.
Online backups (ARCHIVELOG)

Con este tipo de respaldos podemos realizar un respaldo de los archivos a nivel fsico sin tener que hacer shutdown de la base de datos. En primer lugar debemos asegurarnos que la base de datos est corriendo en ARCHIVELOG, para esto podemos ejecutar lo siguiente en el svrmgrl: svrmgrl SVRMGR>connect internal SVRMGR>startup mount DEMO; SVRMGR>alter database archivelog; SVRMGR>archive log start; SVRMGR>alter database open; Tambin podemos configurar este modo en el init.ora para que siempre la base de datos levante en el modo ARCHIVELOG, agregando estas dos lineas: log_archive_dest = /disco1/oracle/arch/DEMO/arch log_archive_start =TRUE en el diretorio definido quedarn los redo logs archivados con una numeracin consecutiva. Nunca borre alguno de estos, no hay forma de recuperar una base de datos si se pierde alguno.
En forma genrica podemos definir que para hacer un respaldo en caliente debemos: 1. Para cada tablespace que exista: Poner el tablespace en modo backup. Respaldar los datafiles del tablespace Restaurar el tablespace al modo normal. 2. Respaldar los archived redo logs: Temporalmente suspender el proceso de archive Determinar los archivos que existen en el directorio de archived redo logs. Restaurar el proceso de archivo. Respaldar los archived redo logs y luego borrarlos 3. Respaldar un control file utilizando el comando "alter database backup controlfile". Veamos un ejemplo reducido dentro del svrmgrl: alter tablespace SYSTEM begin backup; !tar -cvf /dev/rmt/ohc/ /db01/oracle/DEMO/system01.dbf alter tablespace SYSTEM end backup; alter tablespace RBS begin backup; !tar -rvf /dev/rmt/ohc/ /db01/oracle/DEMO/rbs01.dbf alter tablespace RBS end backup; archive log stop --Registrar cuales arch existen ... !FILES='ls /db01/oracle/arch/DEMO/arch*.dbf'; export FILES archive log start !tar -rvf /dev/rmt/0hc $FILES !rm -f $FILES alter database backup controlfile to '/db01/oracle/DEMO/DEMOcontrolfile.bck'; !tar -rvf /dev/rmt/0hc /db01/oracle/DEMO/DEMOcontrolfile.bck
Cual mtodo de respaldo utilizar?

Como siempre, no hay recetas mgicas, veamos una comparacin entre ellos: Mtodo Export Tipo Lgico Caractersticas de Recuperacin Puede recuperar cualquier objeto de la base de datos al momento en que fue exportado. Puede recuperar la base de datos a su estado al momento que fue bajada. Si la base de datos est corriendo en modo ARCHIVELOG, podr luego ser recuperado a cualquier punto en el tiempo. Puede recuperar la base de datos a cualquier punto en el tiempo.
Offline Backups
Fsico
Online Backups
Fsico
Recuperacin
Por ejemplo si se ha daado un datafile especfico: 1. Restaurar el archivo daado desde el respaldo de la noche anterior 2. Montar la base de datos Svrmgrl Connect internal Startup mount DEMO; 3. Dentro del svrmgrl, ejecutar Recover database esto nos preguntar por cada archived redo log, aunque existe una opcin AUTO para que la recuperacin sea mas rpida. 4. Por ltimo abrimos la base de datos: Alter database open; Tambien podemos recuperar una tabla que haya sido borrada accidentalmente importandola desde un import: Imp rh/rh tables=(emp) file=exp.dmp fromuser=rh touser=rh Existen muchas opciones adicionales de recuperacin que estn fuera del alcance de este libro pero que nos dan un nivel adicional de seguridad en caso de fallas.
Bloqueos
Oracle mantiene bloqueos a nivel de fila o tabla. Oracle nunca escalar un bloqueo hasta nivel de tabla, aunque detecte que una gran mayora de las filas en la tabla estn siendo bloqueadas. Consecuentemente, el programador debe decidir con anterioridad si bloque la tabla completa o permite que cada fila sea bloqueada individualmente. Existen dos parmetros en el init.ora que controlan el bloqueo: serializable=false y row_locking=always. Estos valores por defecto nunca deben ser cambiados excepto en casos raros. Los distintos bloqueos que utiliza Oracle pueden subdivirse en: Row Share Table Locks (RS), estos bloqueos son colocados cuando una transaccin SQL declara su intento de actualizar una tabla en modo row-share. Este tipo de bloqueo le permitir a otros queries actualizar filas en la tabla. Por ejemplo: lock table customer in row share mode; select customer_name from customer for update of customer; Row Exclusive Table Locks (RX), estos bloqueos se ejecutan automticamente contra una tabla cuando se utiliza el comando Update, Delete o Insert contra una tabla. Table Share Locks (S), este tipo de bloqueo es ejecutado cuando se utiliza el comando LOCK TABLE. Este indica que la transaccin pretende realizar actualizaciones contra algunas de las filas en la tabla y previene a otras aplicaciones ejecutarse. Share Row Exclusive Table Locks (SRX), estos bloqueos se ejecutan cuando utilizamos el comando LOCK TABLE xxxx IN SHARE ROW EXCLUSIVE MODE. Esto previene a cualquier otra tarea de colocar cualquier LOCK TABLE hasta que la tarea anterior sea completada, tambin previene cualquier intento de bloqueo a nivel de fila Exclusive Table Locks(X), este el bloqueo ms restrictivo. Este bloqueo previene todo excepto queries contra la tabla afectada. Los bloqueos exclusivos son utilizados cuando un programador desea tener control exclusivo sobre un conjunto de filas hasta que su operacin haya sido completada. lock table customer in row exclusive mode nowait;
Para entender mejor como interactan entre s los diferentes tipos de bloqueo, veamos la siguiente tabla, un valor NO, significa que no pueden existir al mismo momento. RS RS RX S SRX X YES YES YES YES NO RX YES YES NO NO NO S YES NO YES NO NO SRX YES NO NO NO NO X NO NO NO NO NO
Deadlocks
El escenario de bloqueos de Oracle asegura una integridad total de la base de datos y que actualizaciones no sobreescriban actualizaciones anterior. Sin embargo, pagamos una penalidad al utilizar bloqueos compartidos. En Oracle, cada bloqueo requiere 4 bytes de RAM, por ejemplo un select que recuper 1000 filas requerir 4000 bytes para manejo de bloqueos. Tambin se pueden producir, lo que traducido a espaol sera algo as como el abrazo mortal, deadlocks.
Tarea A
Tarea B
LOCK MANAGER
1. La tarea A, ejecuta select * from emp; (1000 shared locks) 2. La tarea B ejecuta update emp set salary = salary * 1.1; (espera que la tarea A libere sus shared locks) 3. La tarea A, ejecuta update emp set bonus_flag=1; (la tarea A ahora espera por los bloqueos exclusivos seteados por la tarea B, sin darse cuenta que la tarea A est esperando por sus bloqueos)
La mayora de los programadores no nos damos cuenta que muy comunmente los deadlocks ocurren dentro de un ndice. Es importante notar que un Select de una sla fila puede colocar ms de un bloqueo. La fila recibe un bloqueo, pero cada nodo del ndice que contiene el valor para esta fila tambien recibe un bloqueo. Cuando se ejecuta un Update o Delete tambin sucede lo mismo, se bloque la fila de datos, pero muy probablemente se localicen bloqueos en los ndices de esa tabla. Debido a que la mayora de las bases de datos comerciales slo realizan un bloqueo de una fila cuando necesitan bloquear una fila, podemos utilizar soluciones programticas para minimizar la cantidad de bloqueos utilizados durante tareas de gran actualizacin. Por ejemplo, en Oracle, un programador puede utilizar Select .... For Update, para bloquear explcitamente una fila o conjunto de filas antes de una operacin de update. Esto causar que la base de datos ejecute bloqueos exclusivos al momento de recuperar la informacin y mantendr este bloqueo hasta que la tarea sea grabada. Por ejemplo: Select * From emp Where emp_name = 'JDURAN' For update of salary; Para actualizacion muy largas, podemos bloquear una tabla completa durante la duracin de la operacin. Esto es til cuando todas las filas de la tabla van a ser actualizadas como en el siguiente ejemplo: Lock table emp in exclusive mode nowait; Update emp Set salary = salary * 1.1; Algunas veces una aplicacin necesita actualizar todas las filas en una tabla pero no es prctico bloquear toda la tabla. Una alternativa al update exclusivo, es utilizar la sentencia FETCH de Oracle para bloquear un pequeo segmento de una tabla, realizar una actualizacion, y luego liberarlas con un commit, o lo que es lo mismo hacer un cursor para traer por ejemplo todos los empleados, para cada uno hacer un update contra un cursor que haya sido hecho con la opcin "for update". Claro que este mtodo, nos provoca otros problemas, como qu pasa si detectamos un problema luego de haber procesado cierta cantidad?, ya habra muchas transacciones grabadas.
Para identificar bloqueos que estn evitando que otras tareas sean completadas podemos ejecutar el siguiente script: COLUMN username COLUMN lockwait COLUMN sql_text COLUMN object_owner COLUMN object Select b.username username, c.sid sid, c.owner object_owner, c.object object, b.lockwait, a.sql_text sql from v$sqltext a, v$session b, v$access c where a.address=b.sql_address and a.hash_value=b.sql_hash_value and b.sid=c.sid and c.owner != 'SYS'; Existen varias vistas que a veces no estn creadas, pero que su script se encuentra en $ORACLE_HOME/rdbms/admin y se llama catblock.sql, los nombres de estas vistas son: Dba_waiters Dba_blockers Dba_dml_locks Dba_ddl_locks Dba_locks format a10 format a10 format a80 format a14 format a15
Laboratorio, auditoria, respaldo y recuperacion

Auditora y seguridad
1. 2. 3. 4. 5. 6. Ejecutar svrmgrl en unix Connect internal Startup Exit Sqlplus system/manager Create profile prueba Limit sessions_per_user 2 Cpu_per_session 10 Idle_time 60 Failed_login_attempts 5 Password_reuse_time 60 Password_reuse_max unlimited; 7. Select * from session_roles; 8. Select * from session_privs; 9. Create role account_creator; 10. Grant create session with admin option, create user, alter user to account_creator; 11. Create user juan identified by juan; 12. Grant account_creator to juan; 13. Connect juan/juan 14. Create user carlos identified by carlos; 15. Grant create session to carlos; 16. Create user ops$oracle identified externally; 17. Grant create session to ops$oracle; 18. Exit 19. Sqlplus / 20. Exit 21. Sqlplus system/manager 22. Select role, privilege, admin_option from role_sys_privs; 23. Select grantee, owner, table_name, grantor, privilege, grantable from dba_tab_privs where grantee = 'SYSTEM'; 24. Edite con vi el archivo initXXXX.ora, quite el simbolo "#" de la linea que dice "audit_trail", luego salve el archivo. 25. Baje la base de datos y vuelvala a subir para que retome la nueva configuracin 26. Sqlplus system/manager 27. Set linesize 120 28. Select Substr(username, 1, 10) username, Substr(os_username,1, 10) os_username, Substr(owner, 1, 10) owner, Substr(obj_name, 1, 30) obj_name, Substr(action_name, 1, 30) action_name, Timestamp, From dba_audit_object Where username = 'SYSTEM';
Save audit 29. create table x (linea varchar2(100)); 30. audit all on x; 31. insert into x values 'askdlakdlads'; 32. commit; 33. @audit; 34. exit
Respaldo y recuperacin
35. exp userid=system/manager full=y file=curso.dmp 36. svrmgrl 37. connect internal 38. shutdown 39. exit 40. mkdir $ORACLE_HOME/respaldo 41. cd $ORACLE_HOME/dbs 42. tar -cvf $ORACLE_HOME/respaldo/copia.tar *.dbf 43. tar -rvf $ORACLE_HOME/respaldo/copia.tar init*.ora 44. tar -rvf $ORACLE_HOME/respaldo/copia.tar *control*
Bibliografa
Oracle 7 Server Concepts Manual, Oracle Corporation, 1997. Oracle 7 Server Tuning, Oracle Corporation, 1997. Oracle DBA Handbook, Kevin Loney, Osborne McGrawHill, 1998. High Performance, Oracle Tuning, Don Burleson, Coriolis Group Books, 1998

Curso de DBA Oracle

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Curso de DBA Oracle

Transféré par

Droits d'auteur :

Formats disponibles

Curso

Dba para Desarrolladores

Oracle, arquitectura interna y externa

Productos de Desarrollo de Aplicaciones

Productos de Conectividad en Redes

Num_depto Filas 1 o Rows 2 de datos 3 4

Nombre Ventas Produccin Administracin Cmputo

Localizacin Santa Cruz Cochabamba La Paz Santa Cruz

Archivos o Data Files

Estructuras internas de la Base de Datos

Tablas, columnas y tipos de datos

VARCHAR2 DATE NUMBER

LONG RAW LONG RAW MLSLABEL BLOB CLOB NCLOB BFILE

Tipos de Datos Abstractos

Oracle, arquitectura interna y externa

Segments, extents y blocks

Caractersitcas de un bloque de datos:

Oracle, arquitectura interna y externa

System Global Area (SGA)

Data Block Buffers

Redo Log Buffers

Shared SQL Pool

Data Block Buffer Cache

Redo Log Buffer

Shared SQL Pool

Program Global Area

Trace Files y Alert Log

Consideraciones de Hardware y Configuracin

Visin General de la arquitectura

System Global Area Server o Instancia Background Process

Servidores Independientes (Stand-Alone Hosts)

Unidad de Disco Database Database Files

Servidores Indpendientes con Arreglos de Discos

Espejeo de los Control Files

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

Espejeo de los Redo Log File

Servidor Independiente con espejeo de discos via sistema operativo

Disco 1 Database Files

Disco 1 Database Files

Disco 2 Database Files

Disco 2 Database Files

Disco 3 Database Files

Disco 3 Database Files

Servidores independientes con mltiples bases de datos

Servidores enlazados en red

Oracle kernel o aplicacin

Driver especfico al protocolo

Software del Protocolo

Redes de bases de datos

Planeamiento Lgico de la Base de Datos

Optimal Flexible Arquitecture (OFA) El tablespace SYSTEM

Separar los segmentos de datos de aplicacin: DATA

Separar los segmentos de ndices de aplicacin: INDEXES

Separar segmentos de Herramientas: TOOLS

Separar los segmentos de Rollback: RBS

Separar los segmentos temporales: TEMP

Planeamiento Fsico de la Base de Datos

Peso 100 40 35 33 5 4 2 1 220

Cuellos de botella de I/O entre todos los archivos de la base de datos

Online Redo Log Files

Archived Redo Log Files

I/O concurrente entre los procesos de background

Configuracin Fsica de la Base de Datos

Verificacin de las estimacin de I/O

select count() from cod_persona=cod_cliente; select count() from cod_persona=cod_cliente(+);