miércoles, 8 de junio de 2011

Optimización de Performace en SQL Server

A continuación se detallan conceptos y pautas básicas a tener en cuenta para un confiable estrategia de optimizacion de rendimiento para DBMS SQL Server.

Existen tres conceptos esenciales.
1) Tareas: El proceso debe considerar trabajar sobre las siguientes areas:
a) Esquema de diseño.
b) Optimización del query.
c) Indexación.
d) Locking.
e) Server Tuning.
2) Importancia: Los niveles más bajos del modelo son muy impoortantes pues impactan en forma directa a la performance, pues no es lo mismo tratar de solucionar o mejorar rendimiento sobre algo no muy correctamante diseñado, es decir, si inviertes tiempo y recursos en el esquema de diseño, la base de datos será más fáciles de optimizar para los demás niveles.
3) Orden: Comienza desde el esquema de diseño y se mueve hacia el server tunning. Este es el orden en que los elementos de la base de datos son más fáciles de optimizar.
Esquema de Diseño
La primera y más importante tarea de performance es optimizar el esquema de diseño. Y optimizar el esquema - diseño de base de datos tiene un impacto directo sobre el resto de los niveles de optimización. En esta etapa engloba los conceptos típicos de normalización, desnormalizacion y generalización o método de análisis de relaciones, columnas y asociaciones entre ellas o mejor dicho relaciones padres e hijos en el esquema de base de datos.
Optimización de Query
El segundo paso en la optimización de la estrategia de performance es optimizar los queries. Esto involucra el rediseño de queries. Luego de que optimices el esquema de base de datos se debe revisar y rediseñar los queries.
Indexación
El paso siguiente es la optimización de índices. Porque ello es el puente entre tus queries y los datos. La existencia o ausencia de los indices pueden afectar la performance de la base de datos ya sea mejorando o empeorando la misma. Es por ello que hay que revisar los índices solo después de haber optimizado los queries y re evaluado tu esquema de base de datos.
Locking
La penúltima fase es la estrategia de optimización de locks. Esta fase impacta en la concurrencia de la base de datos, afectando la performance de la misma. Bien es sabido, que los locking en las bases de datos SQL Server, se recomienda que lo maneje el mismo dbms, salvo que tengan que realizar alguna tarea por ej. en batch y deban lockear alguna tabla para realizar alguna actualización masiva.

Server Tunning

Él ultima paso es la estrategia de optimización es tunear el server. Se puede tunear el server en diferentes aspectos: agregar memoria, mejorar el disco i/O, sumar procesador, etc. Dependiendo de donde tengamos el cuello de botella. Ojo, sumar mas hardware no asegura que el problema de performance desaparezca, sino que esta intimamente ligado a los aspectos tratados con anterioridad y lo que si puede pasar es que tarde un poco mas en alcanzar el pico, por ejemplo memoria, si no se revee bien los niveles anteriores.

miércoles, 23 de marzo de 2011

Oracle 10g - Suse Enterprise Error Consola: java.lang.Exception: Failed to get Number of users

Este error de la consola de Oracle 10gR2 con Suse Enterprise (confirmado versión 10) hace que durante la navegación por la consola vayan apareciendo errores en la parte superior con el mensaje:
java.lang.Exception: Failed to get Number of users

La solución pasa por realizar los siguientes pasos:
1) Parar la consola de Oracle:
>emctl stop dbconsole
2) Ir al directorio:
>cd $ORACLE_HOME/sysman/admin/scripts
3) Realizar backup del fichero osLoad.pl
4) Editar el fichero osLoad.pl y cambiar las siguientes lineas:
>>> my $loadavg = NIL;
<<< my $loadavg = "0.46, 0.66, 0.61";
>>>> my $nusers = NIL;
<<<< my $nusers = 1;
5) Grabar el fichero y arrancar la consola
>emctl start dbconsole

Ora10g: TNS-12518 Listener could not hand off client connection

Cuando se produce este error el listener de nuestra base de datos Oracle está rechazando conexiones y no nos podemos conectar de ninguna manera con la base de datos. Para ver que está pasando podemos consultar el log del listener en /opt/oracle/product/10.2/db_1/network/log/listener.log para ver que nos cuenta el sistema. En el caso que nos ocupa podemos encontrar una entrada como la siguiente:
"TNS-12518: TNS:listener could not hand off client connection"
En el caso que me he encontrado este error puede producirse porque el número de procesos actuales de la base de datos está muy cerca del límite establecido en la configuración (por defecto 150). Inmediatamente se puede solucionar reiniciando el listener pero es recomendable revisar el valor del parámetro processes para incrementarlo. El valor máximo que le asignemos a este parámetro es trivial pero si lo modificamos debemos recalcular el valor de transacctions y sessions para que tengan en cuenta las sessiones de sistema de esta manera:
processes=x
transacctions=x*1.1
sessions=(processes*1.1)+5
Si con esto vemos que no se soluciona o queremos investigar más podemos activar la traza del listener para saber más sobre lo que acontece...

El error ORA-30926 como resultado de una operación Merge

El error ORA-30926 suele producirse cuando se realizan operaciones Merge, y lo normal es que nos deje algo descolocados, ya que la descripción del mismo no da demasiada información sobre lo que está pasando:
ORA-30926: unable to get a stable set of rows in the source tables.
Normalmente este error se produce cuando en la operación Merge a una fila destino que hay que actualizar le corresponden más de una fila en la tabla origen. Como el motor no sabe qué registro escoger devuelve un error. Es un problema de duplicidad en la tabla origen.
Ejemplo:
  • Tenemos:
    TABLA_ORIGEN con los valores
    ID    Descripcion
    1     'El primer valor'
    1     'El valor con id duplicado'
    2     'Otro valor' Y TABLA_DESTINO con los valores
    ID   Descripcion
    1    'Valor a actualizar'
    2    'Este no dará problemas'
    3    'Este se queda igual'
     
  • Queremos hacer un merge utilizando la siguiente sentencia:
MERGE into TABLA_DESTINO dest
USING TABLA_ORIGEN ori
ON (dest.ID = ori.ID)
WHEN MATCHED THEN UPDATE SET a.Descripcion = b.Descripcion;
Con estos datos obtendríamos el siguiente error sobre TABLA_ORIGEN:
ORA-30926: no se ha podido obtener un juego de filas estable en las tablas de origen

  • Ante este error tenemos 3 opciones: 1-. Eliminar los registros duplicados de la tabla origen:
 DELETE FROM TABLA_ORIGEN WHERE id=1 AND Descripcion='El valor con id duplicado'
 
2-. Revisar las claves por las que hacemos la join en el merge:
Si utilizamos también el campo Descripcion en el enlace ya sólo habrá cero o un registro origen para cada destino:

MERGE into TABLA_DESTINO dest
USING TABLA_ORIGEN ori
ON (dest.ID = ori.ID AND
dest.Descripcion=ori.Descripcion)WHEN MATCHED THEN UPDATE SET a.Descripcion = b.Descripcion;
(En este ejemplo no tiene mucho sentido porque la tabla son sólo estos dos campos, y además la join no encontrará coincidencias)

3-. Utilizar en lugar del MERGE un UPDATE con JOIN y el HINT /*+BYPASS_UJVC */  para saltarnos la validación del motor, y cruzar los dedos:
UPDATE /*+ BYPASS_UJVC */
 ( SELECT ori.ID ori_ID,
                  ori.Descripcion ori_Descripcion,
                  dest.ID dest_ID,
                  dest.Descripcion dest_Descripcion
    FROM TABLA_ORIGEN ori, TABLA_DESTINO dest
    WHERE ori.ID = dest.ID)
SET dest_Descripcion = ori_Descripcion;

Obviamente las más recomendables son la primera o la segunda, según el caso.

Las suites de Business Intelligence de Oracle

Oracle, aparte de su famoso gestor de base de datos, dispone de un gran catálogo de productos de software, muchos desarrollados internamente y otros adquiridos mediante la compra de otras compañías. Dentro del entorno del Business Intelligence este hecho es aún más notable, ya que justamente varias de las últimas adquisiciones de Oracle han sido operaciones de compra de fabricantes de software de BI.
El resultado es que, aunque cada herramienta tiene unas características y un mercado más apropiado, existen muchos solapamientos, y cuesta un poco situarse a la hora de elegir qué software o conjunto de herramientas podríamos utilizar para nuestro proyecto de Business Intelligence.
Para acabar de complicarlo hay que pensar también en las condiciones del licenciamiento y que el software suele comercializarse en suites que agrupan diferentes herramientas bajo un criterio que puede favorecernos o no.
Un buen ejemplo del efecto que esta situación puede provocar es el post Confusión con Oracle Business Intelligence, de Business Intelligence fácil
Yo tampoco soy un experto en el software BI de Oracle, pero voy a hacer un resumen de lo que conozco y me parece importante tener en cuenta de las tres suites que comercializa Oracle para Business Intelligence.
Cabe decir que este no es el único software de BI de Oracle, y que después de la adquisición de Hyperroll aún se complicará más el panorama, pero creo que con esto analizaremos las soluciones más utilizadas.
Las suites siguen la nomenclatura de las diferentes ediciones de bases de datos que ya conocemos, por lo que ayuda mucho si ya estamos familiarizados con ella. Tenemos una BI Standard Edition 1 (BISE1), que es la más modesta y orientada a pymes. Después viene la BI Standard Edition (BISE), que en teoría correspondería a la versión intermedia. La versión más completa es la BI Enterprise Edition Plus (BIEE), orientada a la gran empresa.

Oracle Business Intelligence Standard Edition (BISE)

Comienzo con la Standard Edition porque se diferencia mucho de las otras dos. Esta suite es la que tiene más historia. Es la evolución de las clásicas herramientas de reporting de Oracle, con Discoverer a la cabeza. Es la que tiene el coste menor por usuario nominal, pero no incluye la base de datos. Utiliza IAS para proveer el acceso web a los informes y cuadros de mando.
Puede encajar en entornos en los que se trabaja casi exclusivamente con Oracle, y no se quiera hacer una inversión demasiado grande para el BI o el reporting. De todas maneras, aunque Discoverer ha mejorado bastante, y ahora hasta puede funcionar en modo OLAP, creo que sigue estando lejos del nivel de herramientas de BI como BI Answers o Hyperion, que Oracle ofrece en las otras suites, y que son fruto de sus adquisiciones. 
De hecho, aunque la suite se sigue comercializando, es bastante complicado encontrarla en la web de Oracle, no parece que la intención sea apostar por ella para el futuro. 
Estos son los productos que incorpora:

 

Oracle Business Intelligence Standard Edition 1 (BISE1)

Esta es la suite más modesta, muy asequible para pymes. Incluye todo lo necesario para tener funcionando en poco tiempo un sistema de Business Intelligence. Eso si, se ha de instalar todo en un servidor, y este ha de ser un Windows Server.
La licencia no permite utilizar más de dos CPU's del servidor y sólo permite utilizar otra fuente de datos directa aparte de la BD que incluye. El licenciamiento es obligatoriamente por usuario nominal, y se pueden licenciar entre 5 y 50 usuarios. La licencia es fácilmente transformable a una Enterprise, ya que esta última incluye el software de la Standard.
La instalación se realiza fácilmente, y en un sólo proceso instala en el servidor la base de datos, la herramienta de ETL Oracle Warehouse Builder (la versión básica), el servidor de BI y el resto de aplicaciones.
Este servidor de BI permite acceder por web a la herramienta de reporting analítico y de cuadros de mando, tanto para diseño como para explotación. Todo este entorno viene de la adquisición de Siebel que Oracle hizo ya hace algún tiempo, y su anterior denominación era Siebel Analytics.
Es un entorno de BI muy completo y fácil de utilizar, aunque no utiliza estructuras propias de OLAP, trabaja directamente sobre el modelo Relacional de la base de datos.
Las herramientas que incluye la suite son las siguientes:
  • Oracle BI Server: Acceso centralizado a los datos y motor de cálculo que se apoya en un modelo lógico de información empresarial común (nivel de abstracción de los metadatos)
  • Oracle BI Server Administrator: Creación de los metadatos y niveles de abstracción
  • Oracle BI Answers: Autoservicio ad-hoc que permite a los usuarios finales crear fácilmente diagramas, tablas dinámicas, informes y cuadros de mando, y navegar con capacidades de drill up/down.
  • Oracle BI Interactive Dashboards: Cuadros de mando interactivos para entornos de análisis.
  • Oracle BI Publisher (también conocido como XML Publisher): Reporting operacional empresarial y distribución de informes con gran nivel de detalle.
  • Oracle Database Standard Edition One: Base de datos
  • Oracle Warehouse Builder (core ETL): Diseño de base de datos y de extracción, transformación y carga (ETL) que ayuda a gestionar el ciclo de vida de los datos y metadatos.
El proceso básico para llegar a crear informes analíticos o dashboards con esta suite sería:
  1. Diseño de la ETL y creación de estructuras dimensionales en tablas con OWB
  2. Definición de metadatos y capas Física, de Negocio y de Presentación con Oracle BI Server Administrator
  3. Creación de informes analíticos y cuadros de mando con BI Answers e Interactive Dashboards
Para crear y distribuir informes operacionales se puede utilizar de manera autónoma BI Publisher.
Los informes se diseñan con Microsoft Word o Adobe Acrobat (instalando un add-in) y después también se pueden publicar y editar mediante servidor web WebDav.
Este software, aunque se integra con el portal de BI Dashboards es propio de Oracle, y es un poco más engorroso de utilizar. No se suele usar a menos que existan necesidades específicas que no se puedan solucionar con BI Answers. 
Se puede obtener más información sobre BISE1 en la sección del producto de la web de Oracle.
Para aprender en poco tiempo cómo empezar a trabajar con esta suite, con el apoyo de esquemas de ejemplo que se cargan al instalar el producto, recomiendo especialmente seguir el Tutorial de Oracle Business Intelligence Edition One

Oracle Business Intelligence Enterprise Edition Plus (BIEE)

Esta es la suite orientada a la gran empresa y a trabajar con múltiples orígenes de datos.
Está compuesta por todas las herramientas de Oracle BISE1 (exceptuando la base de datos) más algunas complementarias aplicables al mismo entorno, y que amplian la funcionalidad de la misma con utilidades de CPM, monitorización y alertas o para poder utilizar las funciones analíticas en modo desconectado.
Lo del Plus viene por el software de Hyperion, que se ha añadido para ampliar más aún la funcionalidad disponible, sobretodo en cuanto a utilidades de Reporting Financiero, una de sus mejores bazas. Este software funciona muy bien en modo OLAP, aunque para ello necesita apoyarse en un motor multidimensional, y Oracle BI Server no lo es, aunque con la versión empresarial sí que se pueda conectar a motores OLAP y otros tipos de orígenes de datos .
En todo caso, para sacar el máximo partido a las aplicaciones de Hyperion lo más indicado es disponer de o adquirir también una base de datos MOLAP como Essbase. También se pueden utilizar otros orígenes Multidimensionales como SAP BW, o Microsoft OLAP.

Si la suite se licencia por usuarios el mínimo es 50, y también se puede licenciar por procesador. No está limitada en cuanto a número de orígenes de datos, usuarios o CPU's más que por el presupuesto disponible.
Como contiene todas las aplicaciones de la versión BISE1, especialmente el servidor de BI, el paso de la versión más modesta a la Enterprise es inmediato, aunque si se quieren utilizar las aplicaciones de Hyperion la cosa se complica un poco más.
Este es el listado de aplicaciones que la componen: (marco en gris las que también forman parte de Oracle BISE1)

Limpieza de datos con Oracle Warehouse Builder

En el enlace Managing Data Quality se puede acceder a un artículo de Ron Hardman sobre cómo realizar procesos de limpieza de datos con Oracle Warehouse Builder.
El artículo comienza con una introducción a la calidad de los datos y maneras de gestionarla, siendo una de ellas la utilización de las opciones de limpieza de datos de Oracle Warehouse Builder.
Lo interesante es que se muestra cómo descargar un script con datos de prueba, y cómo configurar la herramienta para probar las utilidades de Profiling, definición de Reglas (Data Rules), y corrección o limpieza de los datos. De esta manera se puede ver y probar de manera sencilla cómo implementar un proceso básico de Data Cleansing con esta herramienta.
El artículo original está en inglés pero buscando en la web de Oracle he encontrado los 3 documentos que adjunto, traducidos al castellano, y relacionados con OWB y la limpieza de datos:
  • Informe Ejecutivo - Oracle Warehouse Builder 11g Versión 1 Información General
  • Oracle Warehouse Builder Data Quality Option
  • Oracle Warehouse Builder Enterprise ETL Option

Oracle Warehouse Builder 10g disponible sin cargo

Si trabajas con bases de datos Oracle y te estás planteando la posibilidad de utilizar una herramienta ETL (Extract, Transform & Load) para la alimentación de un Data warehouse, o simplemente para facilitar integraciones o migraciones de datos, te puede ir muy bien saber que Oracle permite la utilización de la versión básica de su herramienta de ETL Oracle Warehouse Builder 10g Release 2, sin coste adicional de licencias.
Eso sí, has de disponer de al menos una licencia de Oracle Database Standard Edition One, Oracle Database Standard Edition o Oracle Database Enterprise Edition.

Para más detalles, consultar el artículo de Oracle Press Oracle Anuncia la Disponibilidad General de Oracle Warehouse Builder 10g Release 2

Oracle10g: Poner la base de datos en modo archivelog y hacer backups con rman

El modo archivelog de una base de datos Oracle protege contra la pérdida de datos cuando se produce un fallo en el medio físico y es el primer paso para poder hacer copias de seguridad(en caliente!!) con rman. Para poner la base de datos en modo archivelog (sin usar la flash recovery area) debemos hacer básicamente dos cosas, añadir dos parámetros nuevos al fichero de configuración, reiniciar la base de datos y cambiar el modo trabajo a archivelog.
Como poner la base de datos Oracle 10g en modo archivelog
  1. Editamos el init.ora para añadir los siguientes parámetros
    *.log_archive_dest='/ejemplo/backup/'
    *.log_archive_format='SID_%r_%t_%s'
     
  2. Reiniciamos la base de datos para que coja los cambios y nos aseguramos.
    SQL> shutdown immediate
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL> startup mount pfile='/ejemplo/pfile/init.ora
    ORACLE instance started.

    Total System Global Area  272629760 bytes
    Fixed Size                   788472 bytes
    Variable Size             103806984 bytes
    Database Buffers          167772160 bytes
    Redo Buffers                 262144 bytes
    Database mounted.
    SQL> alter database archivelog;
    Database altered.
    SQL> alter database open;
    Database altered.
    SQL> create spfile;
    SQL> shutdown immediate;
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL> startup
Backups con RMAN

Una vez tenemos la base de datos funcionando en modo archivelog ya podemos plantearnos hacer los backups con rman. Para hacerlos basta con editar un script donde básicamnte hacemos la copia y mantenemos archives en base a cuantos copias queremos mantener y cada cuando ejecutaremos el script. Solo debemos tener cuidado y dimensionar correctamente el número de copias y archivelog que mantemos en base al espacio disponible en el disco. Para saber cuanto espacio necesitaremos podemos aplicar la siguiente formula, suponiendo que la copia sea diaria:
Espacio necesario = (num_backups_rman_mantenidos*tamanyo_backups_rman)+(media_num_redos_al_dia)*(dias_mantenidos).
 
Pasos para empezar a hacer backups:
  1. Editamos el script de sistema para el lanzamiento (/ejemplo/scripts/rman.sh) :
    #!/bin/bash
    export ORACLE_HOME=/opt/oracle/product/10.2/db_1/
    export ORACLE_SID=SID
    /opt/oracle/product/10.2/db_1/bin/rman @/ejemplo/scripts/rman.sql > /backup/scripts/rman.log
     
  2. Script sql que lanzaremos con el sh anterior (/ejemplo/scripts/rman.sql). No hace falta comentarlo porque es muy fácil leer lo que está haciendo en cada paso. Vereis también donde se indica la caducidad de los backups y los archives. connect target root/password@SID
    run {
    CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
    CONFIGURE CONTROLFILE AUTOBACKUP ON;
    CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/ejemplo/backup/%F';
    CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/ejemplo/backup/%d_%Y%M%D%U';
    CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;
    CONFIGURE MAXSETSIZE TO 8000M;
            backup database
            include current controlfile
            plus archivelog;
    CROSSCHECK BACKUP completed before 'sysdate - 4';     
    DELETE NOPROMPT OBSOLETE;                             
    DELETE NOPROMPT ARCHIVELOG UNTIL TIME "SYSDATE - 4";
    delete noprompt expired backup;
    delete noprompt expired archivelog all;
    report schema;
    }
    exit;
     
  3. Programamos la tarea (crontab?) y listo!!

Reducción de Segmentos en Oracle 10g: Shrink Table

En Oracle 10g existe una nueva funcionalidad para a la recuperación del espacio ocupado por una tabla sin necesidad de recrearla: SHRINK TABLE
Es habitual en versiones anterior a la versión 10g el problema generado por el borrado de registros de una tabla y la generación de “huecos” a nivel de los bloques que componen esa tabla. A modo de ejemplo: es habitual la duda tras el borrado masivo de muchos registros de una tabla (o de todos) y la comprobación tras la eliminación de los registros de que la tabla ocupa exactamente lo mismo (misma HWM – High Water Mark).
Esta situación también se da en sistemas OLTP donde con el tiempo, y con las inserciones/borrados de registros en determinadas tablas, se van generando espacio no reutilizables por las nuevas inserciones por falta de espacio en los bloques incompletos, y a la larga caídas de rendimiento en los sistemas.
El método tradicional para recuperar este espacio consistía en realizar periódicamente export/import de la tabla en cuestión o recreación de la misma. Eso conllevaba una serie de problemas en la práctica como invalidación de índices, vistas, procedimientos…
En Oracle 10g surge la funcionalidad shrink table, que no sólo permite la recuperación de este espacio y recuperación del acceso óptimo a la misma, sino que permite realizarlo en 2 fases diferenciadas disminuyendo el tiempo de afectación a los usuarios.
Para llevar a cabo esta recuperación de espacio es necesario seguir los siguientes pasos:
1)Habilitación de movimientos de filas:
ALTER TABLE tabla ENABLE ROW MOVEMENT;
2)Movimiento de las filas:
ALTER TABLE tabla SHRINK SPACE COMPACT;
3)Reseteo HWM
ALTER TABLE tabla SHRINK SPACE;
Tan solo durante el último punto del procedimiento existe bloqueo de tabla, pero sin duda el punto 2 es el más costoso en tiempo y se puede hacer totalmente online.

Indices invisibles en Oracle 11g

A partir de la versión 11g Oracle permite la creación de índices llamados invisibles que permiten llevar realizar cosas realmente interesantes.

Esta invisibilidad se refiere a que el optimizador no tiene en cuenta la existencia de estos índices para la generación de los planes de ejecución.
Esto puede resultar muy interesante en bases de datos en Producción por ejemplo para:
  • En el caso de probar nuevos índices sin afectar a las sentencias SQL de las aplicaciones que atacan a la base de datos, puesto que se pueden activar/desactivar de manera muy rápida.
  • En el caso de querer probar ciertas sentencias SQL de aplicaciones sin índice sin tener que borrar el índice y perder tiempo recreándolo..
A partir de la versión 11g Oracle permite la creación de índices llamados invisibles que permiten llevar realizar cosas realmente interesantes.
Esta invisibilidad se refiere a que el optimizador no tiene en cuenta la existencia de estos índices para la generación de los planes de ejecución.
Esto puede resultar muy interesante en bases de datos en Producción por ejemplo para:
  • En el caso de probar nuevos índices sin afectar a las sentencias SQL de las aplicaciones que atacan a la base de datos, puesto que se pueden activar/desactivar de manera muy rápida.
  • En el caso de querer probar ciertas sentencias SQL de aplicaciones sin índice sin tener que borrar el índice y perder tiempo recreandolo.
Mientras un índice permanece invisible se va actualizando con las sentencias DDL (insert, update, ...), de manera que, los hace perfectos para este tipo de pruebas.
Un índice invisible se puede crear invisible o se puede alterar para que sea visible o invisible. Se puede consultar en que estado está un índice mediante la columna "visibility" de la vista DBA_INDEXES.
Un nuevo parámetro de inicialización controla la visibilidad o no de los índices invisibles "optimizer_use_invisible_indexes". Es decir, que aunque un índice sea invisible, si esta parámetro tiene el valor TRUE, el optimizador los ve y los puede usar sin problemas. Por lo que, recomiendo dejarlo siempre con el valor por defecto FALSE.

Ejemplo:
1) Verificamos el valor del parámetro que controla la visibilidad de los índices invisibles:
SQL> show parameter optimizer_use_invisible_indexes

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
optimizer_use_invisible_indexes boolean FALSE
2) Creamos una tabla de ejemplo con un indice visible:
SQL> create table prueba as select * from dba_tables;

SQL> create index i_prueba on prueba (table_name);
3) Consultamos su visibilidad
SQL> select index_name , visibility from dba_indexes where index_name = 'I_PRUEBA';

INDEX_NAME VISIBILITY
------------------------------ ------------------------------ ---------
I_PRUEBA VISIBLE
4) Consultamos su plan de ejecución forzando el uso del índice: Al ser visible el índice lo usará sin problemas.
SQL> explain plan
2> select /*+ index(prueba i_prueba) */ * from t where table_name

Explained.

SQL> select * from table(DBMS_XPLAN.DISPLAY);
Plan hash value: 2609566873

----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 18 | 1 (0)| 00:00:02 |
|* 1 | INDEX UNIQUE SCAN |I_PRUEBA | 1 | 18 | 1 (0)| 00:00:02 |
----------------------------------------------------------------------------------------
5) Hacemos invisible el índice
SQL> alter index I_PRUEBA invisible;
6) Consultamos su plan de ejecución forzando el uso del índice con un HINT: El optimizador no tiene en cuenta el índice invisible.
----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 93 | 1008 | 31 (0)| 00:00:20 |
|* 1 | TABLE ACCESS FULL | T | 93 | 1008 | 31 (0)| 00:00:20 |
----------------------------------------------------------------------------------------

Cómo crear un nuevo esquema en Oracle paso a paso

Vamos a ver en tres sencillos pasos cómo crear un nuevo esquema-usuario de Oracle. Para poder realizar estos pasos es necesario iniciar la sesión en la base de datos con un usuario con permisos de administración, lo más sencillo es utilizar directamente el usuario SYSTEM:
  • Creación de un tablespace para datos y otro para índices. Estos tablespaces son la ubicación donde se almacenarán los objetos del esquema que vamos a crear.
Tablespace para datos, con tamaño inicial de 1024 Mb, y auto extensible
CREATE TABLESPACE "APPDAT" LOGGING
DATAFILE '/export/home/oracle/oradata/datafiles/APPDAT.dbf' SIZE 1024M
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
Tablespace para índices, con tamaño inicial de 512 Mb, y auto extensible
CREATE TABLESPACE "APPIDX" LOGGING
DATAFILE '/export/home/oracle/oradata/datafiles/APPIDX.dbf' SIZE 512M
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
La creación de estos tablespaces no es obligatoria, pero sí recomendable, así cada usuario de la BD tendrá su propio espacio de datos.
  • Creación del usuario que va a trabajar sobre estos tablespaces, y que será el propietario de los objetos que se se creen en ellos
CREATE USER "APP" PROFILE "DEFAULT" IDENTIFIED BY "APPPWD"
DEFAULT TABLESPACE "APPDAT" TEMPORARY TABLESPACE "TEMP" ACCOUNT UNLOCK;
Si no se especifica un tablespace, la BD le asignará el tablespace USERS, que es el tablespace que se utiliza por defecto para los nuevos usuarios.
Se puede apreciar también que no hay ninguna referencia al tablespace de índices APPIDX que hemos creado. Si queremos mantener datos e índices separados habrá que acordarse de especificar este tablespace en las sentencias de creación de índices de este usuario, si no se hace éstos se crearán en APPDAT:
CREATE INDEX mi_indice ON mi_tabla(mi_campo)
TABLESPACE APPIDX;
  • Sólo falta asignarle los permisos necesarios para trabajar. Si se le asignan los roles 'Connect' y 'Resource' ya tiene los permisos mínimos, podrá conectarse y poder realizar las operaciones más habituales de consulta, modificación y creación de objetos en su propio esquema.
GRANT "CONNECT" TO "APP";
GRANT "RESOURCE" TO "APP";
Completamos la asignación de permisos con privilegios específicos sobre objetos para asegurarnos de que el usuario pueda realizar todas las operaciones que creamos necesarias
GRANT ALTER ANY INDEX TO "APP";
GRANT ALTER ANY SEQUENCE TO "APP";
GRANT ALTER ANY TABLE TO "APP";
GRANT ALTER ANY TRIGGER TO "APP";
GRANT CREATE ANY INDEX TO "APP";
GRANT CREATE ANY SEQUENCE TO "APP";
GRANT CREATE ANY SYNONYM TO "APP";
GRANT CREATE ANY TABLE TO "APP";
GRANT CREATE ANY TRIGGER TO "APP";
GRANT CREATE ANY VIEW TO "APP";
GRANT CREATE PROCEDURE TO "APP";
GRANT CREATE PUBLIC SYNONYM TO "APP";
GRANT CREATE TRIGGER TO "APP";
GRANT CREATE VIEW TO "APP";
GRANT DELETE ANY TABLE TO "APP";
GRANT DROP ANY INDEX TO "APP";
GRANT DROP ANY SEQUENCE TO "APP";
GRANT DROP ANY TABLE TO "APP";
GRANT DROP ANY TRIGGER TO "APP";
GRANT DROP ANY VIEW TO "APP";
GRANT INSERT ANY TABLE TO "APP";
GRANT QUERY REWRITE TO "APP";
GRANT SELECT ANY TABLE TO "APP";
GRANT UNLIMITED TABLESPACE TO "APP";
Ahora el usuario ya puede conectarse y comenzar a trabajar sobre su esquema

Como obtener la lista de tablas con más movimiento(insert,update) en Oracle

A fin de obtener una lista aproximada de las tablas con más movimientos de la base de datos podemos consultar el contenido de la tabla dba_tables y cruzarlo con el estado actual de cada tabla en la bbdd. Esto puede tener sentido cuando queremos confeccionar una lista de tablas a las que se debe actualizar estadísticas periódicamente o queremos controlar la cantidad de información que genera alguna aplicación en concreto. Los datos que obtenemos por cada tabla son siempre respecto al último analisis de la misma.
La siguiente forma de hacerlo es un poco "rupestre" pero útil a la vez:
  1. Nos conectamos a la base de datos como system y ejecutamos la siguiente consulta que nos devolvera una lista de selects con todas las tablas de la base de datos (es mejor filtrar para no incluir las tablas de sistema o incluir solo las de un usuario en concreto). En el ejemplo obtendremos solo las de un usuario en concreto:


    select 'select ''' || table_name || ''' as TABLA, ''' || sysdate ||
    ''' as FECHA_ACTUAL, ''' || last_analyzed ||
    ''' as ULTIMO_ANALISIS, count(*) as RECUENTO,' || num_rows ||
    ' as RECUENTO_ANALISIS , to_date(''' || sysdate ||
    ''', ''DD/MM/YYYY'') - to_date(''' || last_analyzed ||
    ''',''DD/MM/YYYY'') as DIAS_DESDE_ANALISIS , count(*) - ' || num_rows ||
    ' as DIFERENCIA_RECUENTO, (count(*) - ' ||
    num_rows || ')/(to_date(''' || sysdate ||
    ''', ''DD/MM/YYYY'') - to_date(''' || last_analyzed ||
    ''',''DD/MM/YYYY'')) as INCREMENTO_DIARIO from ' || owner || '.' ||
    table_name || ' union '
    from dba_Tables
    where owner = 'USUARIO'


    Ejemplo del resultado con plsql:



   2. Copiamos toda la columna en el portapapeles y quitamos el último union. Obtendremos el siguiente resultado:



Podemos ver la tabla con los datos del último analisis de la tabla respecto a los actuales y la variación con su media diaria en número de registros (teniendo en cuenta que un insert(1row) + delete(1row) = 0movimientos )

Si a esto le sumamos otros datos como tamaños de fila, si la tabla tiene índices y lo que se nos ocurra podemos hacer otros "trabajos manuales" como acumular esos resultados en una tabla para ver que se cuece en nuestra base de datos.  Eso sí, cada uno puede adaptar esta técnica a su gusto para cubrir sus necesidades.

Acceso remoto mediante DBLINK de Oracle

Para acceder desde una base de datos Oracle a objetos de otra base de datos Oracle la manera más sencilla es utilizar un DBLINK (que sea la más sencilla no significa que siempre sea la más aconsejable, el abuso de los DBLINKS puede generar muchos problemas, tanto de rendimiento como de seguridad)
Para ello es necesario, con un usuario que posea el privilegio CREATE DATABASE LINK, crear el DBLINK en la base de datos origen (A) mediante una sencilla sentencia como la siguiente:

Create database link LNK_DE_A_a_B connect to USUARIO identified by CONTRASEÑA USING 'B';

 
'LNK_DE_A_a_B' es el nombre del link, 'USUARIO' y 'CONTRASEÑA' son los identificadores del usuario que utilizará el link para conectarse, los permisos del cual heredarán todos los accesos a través del link, y B es el nombre de la instancia de la base de datos.
A través del DBLINK se puede conectar con los objetos de la base de datos remota con los permisos que tenga el usuario que se ha proporcionado en la sentencia de creación.

Para referenciar un objeto de la base de datos remota se ha de indicar el nombre del objeto, concatenado con el carácter '@' y el nombre que se le ha dado al DBLINK.
Ejemplo:

select * from TABLA@LNK_DE_A_a_B

Documentar, Monitorear y Administrar en ORACLE

Aproveche las nuevas características de Oracle SQL Developer 1.5. Oracle SQL Developer 1.5 presenta una gran cantidad de nuevas funciones. Incluso características que pueden parecer insignificantes a primera vista, pueden ayudarlo con su trabajo diario considerablemente. Esta columna explora las características de Oracle SQL Developer 1.5 que ayudan a documentar y administrar sus objetos y esquemas de Oracle Database. Usted aprenderá a:
  • Compartir fácilmente los detalles de objetos con otros participantes de sus proyectos
  • Utilizar informes instantáneos para obtener detalles sobre las sesiones y espacios de tabla de su base de datos, terminar sesiones y cerrar la base de datos
  • Aprovechar los servicios copiar y exportar para facilitar el trabajo con múltiples esquemas

Comienzo
Los ejemplos de esta columna requieren Oracle SQL Developer 1.5.1. Si tiene instalada la versión de producción de Oracle SQL Developer 1.5, ábrala y utilice Help -> Check For Updates para realizar la actualización en Oracle SQL Developer 1.5.1. De lo contrario, descargue la instalación completa de Oracle SQL Developer 1.5.1 desde OTN y descomprímalo en una nueva carpeta vacía. (No lo descomprima en una carpeta existente de Oracle SQL Developer)
Puede migrar sus conexiones de base de datos y preferencias de Oracle SQL Developer 1.2.x ó 1.5 a Oracle SQL Developer 1.5.1 durante la instalación. Si no desea migrar las preferencias, todavía podrá importar las conexiones de base de datos de cualquier versión anterior después de la instalación. Para importar las conexiones:
  1. Inicie la versión anterior de Oracle SQL Developer
  2. Seleccione Connections en el Navegador de Conexiones
  3. Haga un click derecho y seleccione Export Connections
  4. Busque una ubicación adecuada, ingrese un nombre de archivo como connections.xml, y haga click en Guardar
  5. Cierre la versión anterior e inicie Oracle SQL Developer 1.5.1
  6. Seleccione Connections en el Navegador de Conexiones
  7. Haga un click derecho y seleccione Import Connections
  8. Busque el archivo que acaba de guardar, haga click en Open y en OK
Para esta columna, usted también necesita tener acceso a los esquemas de muestra HR y OE en una instancia Oracle Database.
Generar la Documentación de la Base de Datos
Usted puede generar documentación sobre su esquema en formato HTML para control propio o para compartir con otras personas. Siga estos pasos para generar y ver la documentación del esquema:
  1. Si usted todavía no tiene una conexión al esquema HR, genere uno y denomínelo HR_ORCL. (para obtener información detallada vea “Generar Conexiones de Base de Datos”, en la edición de mayo/junio de 2008 de Oracle Magazine).
  2. Haga un click derecho en la conexión HR_ORCL, y seleccione Generar DB Doc.
  3. Seleccione o genere una ubicación adecuada para los archivos creados, como \working. Si planea compartir los archivos creados con otras personas, utilice una ubicación compartida para servidores de archivos. (Usted también puede mover o copiar los archivos generados).
Un archivo index.html debería abrirse automáticamente en su browser por defecto. Si no es así, navegue en un browser hasta el archivo \working\index.html y ábralo.
Para ver los detalles para cualquier objeto de base de datos en la documentación HTML, seleccione el tipo de objeto en el panel del esquema en la parte superior izquierda. Una lista de todos los objetos de ese tipo aparece en un panel debajo del panel de esquema. Seleccione un objeto para desplegar los detalles en el panel central. Por ejemplo, para desplegar los detalles de la tabla EMPLOYEES, seleccione Tables del panel superior y EMPLOYEES del panel inferior (ver Figura 1).
Figura 1
Figura 1: Documentación generada para el esquema HR
Monitoreo y Administración con Informes
La función View -> Reports de Oracle SQL Developer permite seleccionar varios informes estándar del sistema para ver los detalles de su base de datos y esquemas. Asimismo, para un fácil acceso, hay dos informes disponibles desde el menú Tools y del Navegador de Conexiones, respectivamente. Ambos son adecuados para usuarios privilegiados como SYSTEM o SYS. (usted también puede ejecutarlos como usuario no privilegiado, como HR, con algunas limitaciones)
El informe de Sesiones muestra los detalles de las sesiones actuales activas e inactivas. Siga estos pasos para desplegar el informe de Sesiones:
  1. Genere una nueva conexión denominada SYSTEM_ORCL para el usuario SYSTEM.
  2. Seleccione Tools -> Monitor Sessions.
  3. Seleccione SYSTEM_ORCL en el cuadro de diálogo Select Connection y haga un click en OK para abrir el informe.
Los usuarios privilegiados pueden terminar una sesión desde el informe de Sesiones—por ejemplo, cuando la sesión de un usuario no ha cerrado adecuadamente. (el esquema HR por defecto no puede terminar las sesiones). Si la conexión HR todavía está activa del ejercicio anterior, por ejemplo, seleccione la sesión HR del informe de Sesiones que acaba de generar, presione el botón derecho del mouse y seleccione Kill Session, y haga un click en Apply.
El otro informe disponible en este nivel es el informe Manage Database. Presione el botón derecho del mouse sobre la conexión SYSTEM_ORCL del Navegador de Conexiones, y seleccione Manage Database. El informe muestra detalles de los espacios de tabla de su base de datos. Si usted ejecuta este informe desde una conexión SYS, puede cerrar y reiniciar la base de datos desde Oracle SQL Developer. (el botón de cierre no está disponible para usuarios no privilegiados)
Copiar Objetos a un Esquema Nuevo
Trabajar con múltiples esquemas a menudo implica copiar objetos y sus datos de un esquema a otro. Hay varias maneras de hacer esto en Oracle SQL Developer:
  • Copiar los objetos paso a paso, primero al crear y ejecutar el lenguaje de definición de datos (DDL) para crear la tabla y luego ejecutar una serie de sentencias insert para ingresar los nuevos datos.
  • Usar Table -> Copy para hacer una copia de una tabla con sus datos.
  • Usar Tools -> Database Copy para hacer una copia de una base de datos.
  • Usar el wizard de Exportación de Base de Datos para crear el DDL y las sentencias insert para múltiples tablas y otros objetos de base de datos.
En el siguiente ejercicio, utilizará cada uno de los cuatro métodos para comparar sus ventajas y limitaciones:
  1. Crear una nueva conexión de base de datos denominada OE_ORCL para el esquema OE.
  2. Seleccionar la conexión OE_ORCL y expandir el nodo Tablas.
  3. Hacer click derecho en la tabla CATEGORIES y seleccionar Export DDL -> Save to Worksheet (ver Figura 2).
Figura 2
Figura 2: Exportar DDL en la planilla SQL
El SQL que aparece en la planilla SQL incluye el nombre del esquema OE, de manera que no es adecuado para ejecutar un esquema nuevo. (La sintaxis para este SQL se construye utilizando el paquete DBMS_METADATA y está controlada por una serie de preferencias). Para regenerar el SQL sin el nombre de esquema OE, siga estos pasos:
  1. Seleccione Tools-> Preferences, expanda el nodo Database del árbol, y seleccione ObjectViewer Parameters.
  2. Desmarque las opciones Show Storage y Show Scheme, y marque Show Constraints as Alter.
  3. Haga click en OK.
  4. Limpie la Planilla SQL y repita los pasos anteriores: Presione el botón derecho del mouse sobre la tabla CATEGORIES y seleccione Export DDL -> Save to Worksheet. Tenga en cuenta que el código SQL de la planilla SQL ya no incluye el prefijo OE.
Ahora copie la tabla CATEGORIES y sus datos en el esquema HR_ORCL, siguiendo estos pasos:
  1. Seleccione la conexión HR_ORCL de la lista de Conexiones de la planilla SQL y haga click en Run Script (o presione F5) para ejecutar el DDL en el esquema HR.
  2. Expanda el nodo HR_ORCL y revise la nueva tabla CATEGORIES. Tenga en cuenta que no contiene datos.
  3. Haga un click derecho sobre la tabla CATEGORIES de la conexión OE_ORCL en el Navegador de Conexiones y seleccione Export Data -> Insert.
  4. En el cuadro de diálogo Export Data, envíe los resultados al portapapeles y haga un click en Apply.
  5. Abra una nueva planilla SQL para el usuario HR_ORCL y presione Ctrl-V para pegar los contenidos del portapapeles.
  6. Haga un click en Run Script (o presione F5) para ejecutar el SQL.
  7. Haga un click en el botón Commit (o presione F11) y vea los datos de la tabla CATEGORIES de la conexión HR_ORCL.
Los pasos anteriores solo copian una sola tabla y sus datos. Una alternativa más rápida para copiar un solo objeto y sus datos es el comando Copy del menú de contexto:
  1. Haga un click derecho en la tabla INVENTORIES de la conexión OE_ORCL y seleccione Table -> Copy.
  2. En el cuadro de diálogo Copy, seleccione HR como propietario de la nueva tabla, ingrese INVENTORIES como Nuevo Nombre de Tabla y marque Include Data.
  3. Haga un click en Apply.
  4. Actualice el nodo Tables de la conexión HR_ORCL para ver la nueva tabla INVENTORIES.
Para crear el código DDL para múltiples tablas y sus datos, utilice el wizard Database Export. Para copiar un grupo de tablas del esquema OE al esquema HR, siga estos pasos:
  1. Seleccione Tools -> Database Export. Busque una ubicación de archive adecuada, y acepte el nombre de archive por defecto, export.sql. (Puede establecer un una ruta por defecto para este archive al seleccionar Tools -> Preferences, seleccionar el nodo de base de datos del árbol, y configurar la ruta por defecto Select para almacenar la exportación en las preferencias).
    2. En el wizard Export, seleccione la conexión OE_ORCL y asegúrese de que las opciones Storage y Show Schema estén desmarcadas. Marque Include Drop Statement y Automatically Include Dependent Objects. Haga un click en Next.
    3. En la pantalla Types to Export, desmarque Toggle All y marque Tables y Data. Haga un click en Next.
    4. En la pantalla Specify Objects, debajo de la lista OE, haga un click en Go para completar la lista de tablas que se deben seleccionar. Traslade solo la tabla OE.ORDER_ITEMS al panel que se encuentra a la derecha. Haga un click en Next.
    5. En la pantalla Specify Data, haga un click en Go para completar la lista de tablas. Traslade solo la tabla OE.ORDER_ITEMS al panel que se encuentra a la derecha, y selecciónelo para resaltar la tabla. En el casillero vacío de abajo, ingrese order_id < 2355 y haga un click en Apply Filter (ver Figura 3). Haga click en Next y luego en Finish.
Figura 3
Figura 3: Exportación de la Base de Datos
Tenga en cuenta que el script export.sql que ahora aparece en la planilla SQL incluye tablas adicionales. Esto se debe a que las restricciones, que no están creadas aquí, dependen de estas tablas. También tenga en cuenta el grupo restringido de datos que se brindan.
Seleccione HR_ORCL de la lista de conexiones de la Planilla SQL y ejecute el script. Valide los cambios y luego actualice el nodo HR_ORCL para ver las tablas que el wizard Database Export ha copiado desde el esquema OE_ORCL.
Finalmente, el hecho de utilizar Database Copy en Oracle SQL Developer es una manera altamente eficiente de copiar los objetos a otro esquema. En lugar de producir un script de sentencias insert, Database Copy inserta los datos en las nuevas tablas en segundo plano. Database Copy también copia BLOBs y CLOBs en el nuevo esquema.
Para realizar este ejercicio comparativo, utilice Database Copy a fin de copiar un grupo de objetos en el esquema HR:
  1. Seleccione Tools -> Database Copy. Seleccione OE_ORCL para Source Connection y HR_ORCL para Destination Connection. Tenga en cuenta que las únicas opciones que tiene son crear un objeto nuevo, truncar los datos de objetos existentes (para reemplazarlos con nuevos datos), o eliminar (y reemplazar) los objetos.
  2. Seleccione Truncate Objects, y haga click en Next. Copy Summary indica que todas las tablas serán truncadas. Esto no es lo que desea hacer, entonces haga click en Back, seleccione Create Objects, y haga click en Next. Esto garantizará que los objetos existentes no se eliminen ni sean truncados.
  3. Haga click en Finish.
  4. Revise las tablas y los datos creados en la conexión HR_ORCL.
Database Export y Database Copy difieren de dos maneras significativas. Database Export le permite seleccionar los tipos de objeto a exportar y, dentro de cada categoría, restringir las instancias de objeto individual. Asimismo, con Database Export, usted puede elegir generar sentencias GRANT, incluir sentencias DROP, y crear sentencias INSERT, obteniendo así la capacidad para generar un script que puede volver a ejecutar a voluntad para esquemas nuevos o existentes.
Conclusión
Esta columna ha explorado una variedad de las características incluidas en Oracle SQL Developer 1.5. Usted puede mejorar su productividad con estas nuevas maneras de ver y compartir los detalles de base de datos, monitorear y administrar sesiones, y copiar los objetos de base de datos en todos los esquemas.

Sepa cómo administrar XML complejo con Oracle XML DB 11g, y cómo cambiar el esquema online

En los últimos años, XML ha resurgido como el nuevo estándar para la transmisión de datos, y su uso se ha vuelto más común a medida que las empresas adoptan soluciones basadas en XML. Debido a que las empresas comienzan a imponer sus estándares XML para la transmisión de todos los datos, cada vez aparecen formatos XML más complejos. Estos formatos complejos pueden incluir múltiples espacios de nombre, miles de elementos y definiciones recurrentes. A medida que los documentos XML producidos a partir de estos formatos crecen en tamaño y complejidad, administrar este contenido se vuelve una tarea cada vez más desafiante, con información limitada en cuanto a cómo abordar este desafío. En este informe usted aprenderá a utilizar la característica XML DB de Oracle Database 11g a fin de administrar el contenido XML complejo así como sus ventajas sobre los productos ETL comerciales. Usted verá un ejemplo de un esquema XML complejo que muestra lo siguiente:
  • Registro de un esquema XML complejo
  • Inserción de archivos XML en la base de datos
  • Recuperación de datos XML por medio de consultas relacionales
  • Evolución en el lugar para modificaciones de esquemas XML
Asimismo, usted tendrá una visión general de las estrategias para maximizar el desempeño y rendimiento de las soluciones Oracle XML DB y las aplicaciones prácticas de formatos XML complejos.
Contexto de Oracle XML DB
Oracle XML DB es una característica de Oracle Database que ofrece una poderosa herramienta para la administración de contenido XML, con inclusión del almacenamiento, la manipulación y recuperación. Ofrece distintas opciones de almacenamiento para cumplir con los requisitos exclusivos de distintos formatos XML. Estas opciones incluyen almacenamiento no estructurado, binario y estructurado:
  • No estructurado (grandes objetos de caracteres, o CLOB). Al tratar el documento como un gran objeto y almacenarlo en la base de datos, este método permite los mejores tiempos de inserción. No obstante, este método de almacenamiento también consume la mayor cantidad de espacio y tiene el peor desempeño para el acceso relacional a los datos. Esta es una solución poco práctica para administrar documentos XML grandes y complejos si se requiere el acceso relacional. El almacenamiento no estructurado puede ser una solución práctica si el espacio en disco no es un problema y el objetivo es archivar los documentos en su formato original.
  • Almacenamiento Binario. Esta opción, nueva en Oracle Database 11g, almacena datos en un formato postparse binario diseñado específicamente para datos XML. Esta opción tiene varias ventajas sobre el almacenamiento no estructurado, y al ser sensible al esquema XML, permite una mejor eficiencia del espacio de disco y un mejor desempeño de las consultas. A pesar de que esta opción ofrece un desempeño increíble comparado con el del almacenamiento no estructurado, ésta no tiene el mismo desempeño de consultas que el almacenamiento estructurado. El almacenamiento binario es una buena opción cuando su desempeño para acceso relacional es aceptable. Debido a que esta opción de almacenamiento es fácil de usar, vale la pena evaluarla antes de optar por el almacenamiento estructurado.
  • Almacenamiento No Estructurado. También conocido como almacenamiento basado en esquemas, esta opción utiliza un modelo de objeto relacional para almacenar documentos XML en la base de datos. Esta opción de almacenamiento es la más eficiente en términos de espacio de disco y acceso relacional. También presenta los niveles más elevados de gastos generales durante la inserción del archivo y requiere la preparación adicional para el registro del esquema. El almacenamiento estructurado es la mejor opción cuando el acceso relacional es un requisito. Para manejar archivos grandes y complejos con el fin de ofrecer acceso relacional eficiente, esta opción de almacenamiento generalmente es la mejor opción.
La percepción del tamaño y la complejidad de un documento XML pueden diferir enormemente, dependiendo de la empresa. Por un lado, para las bases de datos de procesamiento de transacciones online (OLTP) que utilizan XML para el intercambio electrónico de datos (EDI) u otro intercambio de datos transaccionales, un archivo con varias líneas podría considerarse un archivo muy extenso. Por otro lado, un depósito de datos de múltiples terabytes podría regularmente procesar documentos XML medidos en gigabytes y no considerar que un archivo sea extenso a menos que contenga millones de líneas. El mismo concepto se mantiene para la complejidad percibida de un documento XML.
A los fines de este informe, un documento se considera "complejo" si presenta las siguientes propiedades:
  • Tiene un origen único, con múltiples espacios de nombre.
  • Tiene definiciones XML flexibles, permitiendo grandes variaciones mientras se mantiene la validez.
  • Posee referencias circulares/clínicas recurrentes.
  • Posee esquemas XML no estáticos.
En este informe, los documentos XML son considerados “extensos” si poseen un solo origen y superan los 20MB. Estas propiedades incorporan ciertas consideraciones de administración y escalabilidad que deben tenerse en cuenta para obtener una solución empresarial sólida.
No hay reglas de oro para elegir la mejor opción de almacenamiento. Sobre la base de una estructura de archivos, objetivos de desempeño, recursos disponibles y el volumen de datos esperado, la mejor opción puede variar. Si usted no puede decidir cuál es la mejor opción de almacenamiento para su requerimiento particular, es conveniente probar otros formatos a fin de determinar lo que es óptimo para sus necesidades específicas.
Generalmente hablando, si usted está manejando grandes documentos y requiere acceso relacional, el almacenamiento no estructurado no es aceptable desde una perspectiva de recursos o desempeño. XML binario puede ser la solución óptima si el desempeño de consultas es aceptable para el uso comercial o si el negocio exige la aplicación de la opción con el menor tiempo de mantenimiento. No obstante, si el acceso relacional es el principal objetivo y los usuarios necesitan acceso rápido a la información contenida en un documento XML, posiblemente el almacenamiento estructurado sea la mejor opción.
Maximizar el Rendimiento con Almacenamiento Estructurado
A pesar de los gastos generales por incorporar archivos cuando se utiliza la opción de almacenamiento estructurado, usted puede reducir este costo fraccionando los grandes documentos en partes más pequeñas.
Por ejemplo, si hay un archivo XML de un solo origen de 700MB, es posible separarlo en 10 partes más pequeñas válidas con el esquema XML. Insertar 10 archivos diferentes de 70MB es mucho más rápido que insertar un solo archivo de 700MB, y el resultado es el mismo. El nivel de concurrencia debería estar determinado por la capacidad de procesamiento disponible de la base de datos. Esta estrategia aprovecha la concurrencia de la base de datos y maximiza el rendimiento.
Otra consideración para tener en cuenta cuando se utiliza Oracle XML DB es que el tiempo de inserción de un solo archivo XML generalmente está limitado por la velocidad de una única CPU. En otras palabras, tener múltiples procesadores no ayuda al rendimiento de un solo documento. Por ejemplo, considere una situación en la que se deba insertar un documento de 700MB complejo, de origen único, por medio del uso del almacenamiento basado en esquemas.
El tiempo total de inserción de este archivo podría ser de 10 minutos con un procesador 1.35GHz, ya sea que la base de datos tenga 12 ó 72 CPUs (suponiendo que al menos una CPU se encuentra disponible en cada escenario). Para aumentar el rendimiento de un solo documento XML, posiblemente necesite utilizar CPUs más rápidas. Insertar este mismo archivo cuando tiene un solo procesador de 3.4GHz podría tardar 4 minutos.
En cambio, cuando usted maneja muchos archivos XML, tener múltiples procesadores puede mejorar la concurrencia de las inserciones, lo cual mejorará el rendimiento a mayor escala. Por ejemplo, si el archivo de 700MB se divide en 10 documentos distintos de 70MB, el tiempo de inserción de cada documento de 70MB puede ser menor a un minuto si usted utiliza la base de datos con los procesadores 1.35GHz. Si la CPU está disponible, los 10 documentos pueden ser insertados simultáneamente en la base de datos. Esta estrategia da como resultado un tiempo de inserción total de alrededor de un minuto para insertar todo el documento de 700MB.
Desafortunadamente, calcular estas comparaciones no es ciencia exacta. Cada base de datos puede desempeñarse de manera diferente, dependiendo de varios factores, con inclusión del sistema operativo, la capacidad de procesamiento disponible, la memoria y la definición de esquemas. La mejor manera de optimizar el desempeño en su entorno es implementando estas estrategias y determinando los beneficios de cada una de ellas.
Productos ETL de Oracle XML DB vs. Listos para la Venta (COTS)
Varias herramientas comerciales de extracción, transformación y carga (ETL) están disponibles para cargar información de archivos en la base de datos. Estas herramientas generalmente presentan un solo front end con capacidad drag-and-drop y pueden ocultar la complejidad del verdadero proceso. Cuando usted crea un proceso de carga XML en una herramienta ETL comercial, es necesario definir los campos que deben extraerse. Si no especifica un determinado XPath, los datos no serán recopilados del documento.
En caso de documentos XMl complejos, la ventaja de Oracle XML DB es que obtiene una visión de los documentos centrada en la base de datos y analiza cada documento en un modelo de objeto relacional. Cuando el archivo se inserta exitosamente en la base de datos, se puede acceder a toda la información contenida dentro de ese archivo sin necesidad de ser nuevamente analizada.
Uno de los mejores beneficios de Oracle XML DB es que es una característica estándar de Oracle Database y no requiere licencia adicional. Pero si las tarifas de las licencias no fueran una preocupación para la empresa, ¿por qué usaría Oracle XML DB para su administración de contenido XML en lugar de la herramienta de una empresa que utilice ETL como función principal? Para comprender la respuesta, es necesario comprender cómo la tecnología de Oracle XML DB cumple con los requisitos exclusivos para la administración de XML complejo.
Los Desafíos del Contenido XML Complejo
Cuando el contenido XML es flexible, frecuentemente cambiante, recurrente y muy extenso, un desarrollador sin dudas encontrará ciertos desafíos que podrían no presentarse en los formatos más simples. Una de las posibilidades que podría presentarse con un documento XML complejo es que su esquema XML sea muy grande y permitir gran cantidad de flexibilidad mientras se mantiene válido. El uso de esquemas XML flexibles es una estrategia común para respaldar los estándares de todo el sector mientras se cumple con los requisitos específicos de la empresa.
Por ejemplo, se adopta un esquema XML como estándar para tres empresas. Además de los elementos estándar o compartidos, este esquema XML deberá incluir todas las definiciones específicas de la empresa para cada una de las empresas. Para respaldar este requerimiento, el esquema XML se diseña con gran flexibilidad para uso de elementos de contenido genérico que hagan referencia a todos los elementos específicos de la empresa posibles y que permitan que la mayoría de las referencias de elementos se produzcan 0 o más veces.
Como resultado, los documentos con elementos completamente diferentes son válidos con el mismo esquema XML. Desde una perspectiva de desarrollo, esta flexibilidad dificulta la escritura de análisis XML para extraer los datos necesarios, debido a que el surgimiento de elementos es difícil de predecir. Como las herramientas COTS ETL y los análisis personalizados requieren un XPath específico para la extracción de datos, cada XPath posible podría necesitar ser controlado para garantizar la captura de toda la información del documento.
Esta no es una solución práctica ya que existe una cantidad exponencial de posibles XPaths. Asimismo, si existen referencias recurrentes o cíclicas en el esquema, ellas son infinitas. Cuando se detectan datos que no han sido capturados, la única resolución es volver a analizar todo el archivo, una operación costosa que debería evitarse, de ser posible.
Tenga en cuenta el siguiente esquema XML (preste atención a las referencias cíclicas y a la flexibilidad del esquema que resulta de los elementos genéricos):
startData.xsd
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:bc="startData.xsd" xmlns:xn="standardData.xsd"
 xmlns:es="CompanySpecific.1.0.xsd"
                        


xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xdb="http://xmlns.oracle.com/xdb"
                        


  targetNamespace="startData.xsd"
                        


  elementFormDefault="qualified" 
  attributeFormDefault="unqualified">
<import namespace="standardData.xsd" schemaLocation="standardData.xsd"/>
<import namespace="CompanySpecific.1.0.xsd"
 schemaLocation="CompanySpecific.1.0.xsd"/>
<element name="rootElement" xdb:defaultTable="XML_DEFAULT">
<complexType>
<sequence>
        <element name="fileHeader">
                <complexType>
                        <attribute name="fileFormat" type="string"
                          use="required"/>          
                        <attribute name="companyName" type="string"
                          use="optional"/>
                </complexType>
        </element>
        <element name="fileData" maxOccurs="unbounded">
                <complexType>
                        <choice>
                                <element ref="xn:childContainer"
 maxOccurs="unbounded"/>
<element ref="xn:salesInformation"
 maxOccurs="unbounded"/>
                        </choice>
                </complexType>
        </element>
        <element name="fileFooter">
                <complexType>
                        <attribute name="timeStamp" type="string"
                          use="required"/>
                </complexType>
        </element>
</sequence>
</complexType>
</element>
</schema>
                      
standardData.xsd
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xn="standardData.xsd"
 targetNamespace="standardData.xsd" 
 elementFormDefault="qualified" 
 attributeFormDefault="unqualified" 
 xmlns:cs="CompanySpecific.1.0.xsd" >
<import namespace="CompanySpecific.1.0.xsd"
 schemaLocation="CompanySpecific.1.0.xsd"/>
<element name="childContainer">      
<complexType>
        <sequence>
                <element name="attributes" minOccurs="0">
                <complexType>
                <all>
                        <element name="childLabel" minOccurs="0"/>
                        <element name="childType" minOccurs="0"/>
                </all>
                </complexType>
                </element>
                <choice minOccurs="0" maxOccurs="unbounded">
                        <element ref="xn:childContainer"/>
                        <element ref="xn:CompanySpecificContainer"/>
                        <element ref="xn:salesInformation"/>
                </choice>
        </sequence>
</complexType>
</element>
<element name="salesInformation">    
<complexType>
        <sequence>
                <element name="storeNumber" type="string" minOccurs="0"/>
                <element name="orderNumber" type="string" minOccurs="0"/>
                <element name="salesDate" type="string" minOccurs="0"/>
<element name="product" type="string" minOccurs="0"/>
<element name="quantity" type="string" minOccurs="0"/>
<element name="price" type="string" minOccurs="0"/>
<choice minOccurs="0" maxOccurs="unbounded">
                        <element ref="xn:childContainer"/>
                </choice>
        </sequence>
</complexType>
</element>
<element name="CompanySpecificContainer">
<complexType>
        <sequence>
                <element name="attributes" minOccurs="0">
                <complexType>
                <all>
                        <element name="csDataType" minOccurs="0"/>
                        <element name="csDataFormat" minOccurs="0"/>
                        <element ref="cs:csStore" minOccurs="0"/>
<element ref="cs:csProduct" minOccurs="0"/>
                </all>
                </complexType>
                </element>
                <choice minOccurs="0" maxOccurs="unbounded">
                        <element ref="xn:CompanySpecificContainer"/>
                </choice>
        </sequence>
</complexType>
</element>
</schema>
CompanySpecific.1.0.xsd
<schema xmlns="http://www.w3.org/2001/XMLSchema"
 xmlns:cs="CompanySpecific.1.0.xsd"
                        


  targetNamespace="CompanySpecific.1.0.xsd"
                        


  elementFormDefault="qualified"
                        


  attributeFormDefault="unqualified">
<element name="csStore">
    <complexType>
      <sequence>
        <element name="label" type="string" minOccurs="0"/>
        <element name="name" type="string" minOccurs="0"/>
        <element name="value" type="string" minOccurs="0"/>
      </sequence>
    </complexType>
  </element>
<element name="csProduct">
    <complexType>
      <sequence>
        <element name="label" type="string" minOccurs="0"/>
        <element name="name" type="string" minOccurs="0"/>
        <element name="value" type="string" minOccurs="0"/>
      </sequence>
    </complexType>
  </element>
</schema>
                      
Este esquema XML podría utilizarse como estándar del sector para transmitir información de inventario y ventas. Tenga en cuenta que en el espacio de nombre standardData.xsd, tanto el elemento childContainer como el elemento companySpecificContainer actúan opcionalmente como autoreferencia. En esta definición particular, este diseño permite que cada empresa decida la granularidad de sus datos utilizando la relación principal/secundario. Este esquema también le da a cada empresa la opción de incluir datos de inventarios, datos de venta, o ambos. Además permite a cada empresa incluir o no incluir más locales, productos y ventas, sobre la base de sus necesidades individuales pero dentro del mismo formato flexible.
Por ejemplo, si una empresa hipotética ABC quiere incorporar datos de ventas e inventario de múltiples locales, podría usar una recopilación de los elementos CompanySpecificContainer para identificar cada local (principal) y una recopilación de elementos CompanySpecificContainer para identificar los productos (secundario) para cada local.
Un documento válido para ABC podría ser:
CompanyABC.xml
<?xml version="1.0"?>
<rootElement xmlns="startData.xsd" xmlns:xn="standardData.xsd"
 xmlns:cs="CompanySpecific.1.0.xsd" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<fileHeader fileFormat="v1.0" companyName="CompanyABC"/>
<fileData>
<xn:childContainer>
        <xn:attributes>
                <xn:childLabel>Store 0001 Inventory</xn:childLabel>
<xn:childType>Stock</xn:childType>
</xn:attributes>
        <xn:CompanySpecificContainer>
                <xn:attributes>
<xn:csDataType>csStore</xn:csDataType>                                    
<xn:csDataFormat>CompanySpecific.1.0</xn:csDataFormat>
<cs:csStore>
                        <cs:label>Store 0001</cs:label>
                        <cs:name>Product 1</cs:name>
                        <cs:value>In Stock</cs:value>
</cs:csStore>
</xn:attributes>
        <xn:CompanySpecificContainer>        
                        <xn:attributes>
<xn:csDataType>csProduct</xn:csDataType>                          
<xn:csDataFormat>CompanySpecific.1.0</xn:csDataFormat>
<cs:csProduct>
                                <cs:label>Product 1</cs:label>
                                <cs:name>Quantity</cs:name>
                                <cs:value>10</cs:value>
</cs:csProduct>
</xn:attributes>
                </xn:CompanySpecificContainer>
</xn:CompanySpecificContainer>
<xn:salesInformation>
        <xn:storeNumber>Store 0001</xn:storeNumber>
<xn:orderNumber>12345</xn:orderNumber>
        <xn:salesDate>20-SEP-2007</xn:salesDate>
<xn:product>Product 1</xn:product>
<xn:quantity>1</xn:quantity>
<xn:price>110.00</xn:price>
</xn:salesInformation>
</xn:childContainer>
</fileData>
<fileFooter timeStamp="20-SEP-2007"/>
</rootElement>

No obstante, si otra empresa, XYZ, tuviera un solo local y quisiera incorporar solo la información de ventas estándar de sus archivos, ésta omitiría el elemento childContainer e incluiría una recopilación de elementos salesInformation. Un documento válido de XYZ que describa solo la información de ventas estándar sería el siguiente:
CompanyXYZ.xml
<?xml version="1.0"?>
<rootElement xmlns="startData.xsd" xmlns:xn="standardData.xsd"
 xmlns:cs="CompanySpecific.1.0.xsd"
                        


  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<fileHeader fileFormat="v1.0" companyName="CompanyXYZ"/>
<fileData>
<xn:salesInformation>
        <xn:storeNumber>Store 0001</xn:storeNumber>
<xn:orderNumber>12345</xn:orderNumber>
        <xn:salesDate>20-SEP-2007</xn:salesDate>
<xn:product>Product 1</xn:product>
<xn:quantity>1</xn:quantity>
<xn:price>110.00</xn:price>
</xn:salesInformation>
</fileData>
<fileFooter timeStamp="20-SEP-2007"/>
</rootElement>
                      
Estos documentos son muy distintos, pero ambos son válidos en el esquema XML. Este diseño facilita el uso de estándares para todo el sector de diferentes empresas, con un formato único y flexible en el esquema XML. No obstante, el uso de referencias recurrentes para elementos de contenido genérico permite a cada empresa decidir la cantidad de detalles a incluir mientras se mantiene el cumplimiento con el esquema XML. Por ejemplo, un solo XPath para la extracción de datos CompanyABC.xml sería
'/rootElement/fileData/xn:childContainer/xn:CompanySpecificContainer/
  xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:value'

Sin embargo, si esta empresa desea incluir los datos almacenados con mayor granularidad, podría incluir otro elemento secundario para los sublocales, como por ejemplo:
'/rootElement/fileData/xn:childContainer/xn:CompanySpecificContainer/  
xn:CompanySpecificContainer/
  xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:value'

El diseño de este esquema XML permite enriquecer los archivos con el contenido determinado por cada empresa. Al utilizar las referencias opcionales y los elementos de contenido genérico, cada documento comienza a parecerse a una base de datos. Debido a la imprevisibilidad de cada archivo, administrar este XML con código personalizado o una herramienta COTS ETL implicaría un gran esfuerzo de desarrollo que requeriría el continuo mantenimiento y soporte. Si alguna de las empresas que utilizan este esquema XML incluyera un nuevo XPath, el código de extracción debería ser modificado para capturar estos datos. Todo archivo analizado sin los XPath actualizados debería ser reprocesado por completo. Este ejemplo muestra los desafíos sustanciales de los esquemas XML completos y las dificultades de los desarrolladores que administran dicho contenido.
La Solución Oracle XML DB
Este problema con el mapeo XPath, como se muestra en el ejemplo de arriba, no existe con Oracle XML DB, debido a que todo el archivo se almacena en la base de datos. Tan pronto como el documento es insertado, el contenido del documento queda inmediatamente a disposición para posibles consultas. Independientemente de la flexibilidad del esquema XML, se puede acceder a la información contenida en el documento con el XPath adecuado. Esto brinda una ventaja incomparable que maximiza la disponibilidad y minimiza el costo de mantenimiento.
Para implementar la solución XML DB, comience registrando el esquema XML (los documentos y archivos de definición se encuentran en un directorio denominado XML_TEST):
begin
DBMS_XMLSCHEMA.REGISTERSCHEMA(
        schemaurl => 'CompanySpecific.1.0.xsd',
        schemadoc => BFILENAME ('XML_TEST','CompanySpecific.1.0.xsd')
        );
DBMS_XMLSCHEMA.REGISTERSCHEMA(
        schemaurl => 'standardData.xsd',
        schemadoc => BFILENAME ('XML_TEST','standardData.xsd')
        );
DBMS_XMLSCHEMA.REGISTERSCHEMA(
        schemaurl => 'startData.xsd',
        schemadoc => BFILENAME ('XML_TEST','startData.xsd')
        );                              
end;    
/

Ahora que usted ha creado una estructura de objeto relacional para nuestro esquema XML, usted está listo para insertar archivos XML en la tabla por defecto (especificada en la anotación del elemento de origen).
insert into XML_DEFAULT values (XMLTYPE(BFILENAME
('XML_TEST','CompanyABC.xml'),nls_charset_id('AL32UTF8')));
/
                      
El archivo es exitosamente insertado en una fracción de segundos. Los datos están inmediatamente disponibles para el acceso relacional. Aquí hay un ejemplo de un acceso de consulta que describe el actual inventario:

SELECT extractValue(object_value,'/rootElement/fileFooter/@timeStamp')
  start_date, 
extractValue(object_value,'/rootElement/fileHeader/@companyName')
 companyName, 
extractValue(object_value,'/rootElement/fileHeader/@fileFormat')
 fileFormat,
extractValue(value(b),
   '/xn:childContainer/xn:attributes/xn:childLabel', 
   'xmlns:xn="standardData.xsd"') childLabel,
extractValue(value(b),
   '/xn:childContainer/xn:attributes/xn:childType', 
   'xmlns:xn="standardData.xsd"') childType,
extractValue(value(c),
   '/xn:CompanySpecificContainer/xn:attributes/xn:csDataType',         
   'xmlns:xn="standardData.xsd"') csDataType,
extractValue(value(c),
   '/xn:CompanySpecificContainer/xn:attributes/xn:csDataFormat', 
   'xmlns:xn="standardData.xsd"') csDataFormat,
extractValue(value(c),
   '/xn:CompanySpecificContainer/xn:attributes/cs:csStore/cs:label', 
   'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
 csStoreLabel,
extractValue(value(c),
   '/xn:CompanySpecificContainer/xn:attributes/cs:csStore/cs:name', 
   'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
 csStoreName,
extractValue(value(c),
   '/xn:CompanySpecificContainer/xn:attributes/cs:csStore/cs:value', 
   'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
 csStoreValue,
extractValue(value(c),
   '/xn:CompanySpecificContainer/xn:CompanySpecificContainer/xn:attributes/
xn:csDataType', 
   'xmlns:xn="standardData.xsd"') csDataTypeL2,
extractValue(value(d),
   '/xn:CompanySpecificContainer/xn:attributes/xn:csDataFormat', 
   'xmlns:xn="standardData.xsd"') csDataFormatL2,
extractValue(value(d),
   '/xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:label', 
   'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
 csProductLabel,
extractValue(value(d),
   '/xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:name', 
   'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
 csProductName,
extractValue(value(d),
   '/xn:CompanySpecificContainer/xn:attributes/cs:csProduct/cs:value', 
   'xmlns:xn="standardData.xsd" xmlns:cs="CompanySpecific.1.0.xsd"')
 csProductValue
from 
XML_DEFAULT a
,TABLE(XMLSequence(Extract(object_value,
 '/rootElement/fileData/xn:childContainer', 
   'xmlns:xn="standardData.xsd" xmlns="startData.xsd"'))) b
,TABLE(XMLSequence(Extract(value(b),
 '/xn:childContainer/xn:CompanySpecificContainer', 
   'xmlns:xn="standardData.xsd"'))) c
,TABLE(XMLSequence(Extract(value(c),
 '/xn:CompanySpecificContainer/xn:CompanySpecificContainer', 
   'xmlns:xn="standardData.xsd"'))) d
/

...
                        
snipped...
                      
Esta solución permite la administración de cualquier documento que concuerde con la definición de esquema XML. La visión de los documentos XML centrada en la base de datos de Oracle XML DB permite la utilización de documentos XML valiosos en contenido mientras se brinda un nivel de abstracción de las complejidades de desarrollo que sería inevitable con cualquier otra tecnología ETL.
Este ejemplo muestra las incomparables capacidades XML de almacenamiento y recuperación de Oracle XML DB. No obstante, el esquema XML completo también se caracteriza por tener cambios frecuentes en la definición del esquema XML. ¿Cómo Oracle XML DB facilita los cambios en el esquema XML?
Administración de Cambios en el Esquema XML
En el ejemplo anterior, la flexibilidad del esquema ha sido suministrada mediante el uso de elementos de contenedores genéricos y las referencias opcionales de todos los elementos específicos de la empresa. A pesar de que este diseño ofrece flexibilidad sustancial dentro del esquema XML, existe la posibilidad de realizar cambios en el espacio de nombre CompanySpecific.1.0.xsd si las empresas individuales eligen incluir datos adicionales en sus archivos.
Los cambios en las definiciones del esquema siempre han sido problemáticos para las soluciones basadas en XML. Generalmente es así porque se supone que un esquema XML debe ser utilizado para validar un documento XML. Si el documento contiene elementos no definidos en el esquema, el documento no es válido.
En el pasado, esto ha sido una debilidad de Oracle XML DB, ya que los cambios realizados en esquemas XML registrados requerían una operación costosa y compleja utilizando el procedimiento copyEvolve. Este procedimiento bloquea los recursos, crea tablas temporarias, traslada todos los datos desde la tabla XML de este esquema a las tablas temporarias, aplica cambios de esquemas, y luego devuelve los datos a la tabla XML. Cuantos más datos haya en la tabla XML, más larga y costosa será esta operación. Dependiendo del tamaño de la tabla, podría llevar horas completar una evolución del esquema para incorporar un solo elemento o atributo. Con respecto a XML complejo, este procedimiento no era una solución adecuada para administrar los cambios de esquema.
Para abordar esta limitación, Oracle ha introducido en Oracle XML DB 11g un nuevo procedimiento denominado inPlaceEvolve, el cual permite realizar las mismas modificaciones de esquema en una operación online que no requiera el movimiento de datos. En cambio, este procedimiento modifica los objetos de base de datos creados durante el registro de esquemas mientras los datos relacionados siguen disponibles. Esta mejora es fundamental para abordar los frecuentes cambios de definición comunes en esquemas XML complejos.
Al utilizar nuestro ejemplo anterior, considere una situación en la que se agrega un elemento adicional a la definición csProduct:
CompanySpecific.1.1.xsd
<schema xmlns="http://www.w3.org/2001/XMLSchema"
 xmlns:cs="CompanySpecific.1.0.xsd" 
 targetNamespace="CompanySpecific.1.0.xsd" elementFormDefault="qualified"
                        


 attributeFormDefault="unqualified">
<element name="csStore">
    <complexType>
      <sequence>
        <element name="label" type="string" minOccurs="0"/>
        <element name="name" type="string" minOccurs="0"/>
        <element name="value" type="string" minOccurs="0"/>
      </sequence>
    </complexType>
  </element>
<element name="csProduct">
    <complexType>
      <sequence>
        <element name="label" type="string" minOccurs="0"/>
        <element name="name" type="string" minOccurs="0"/>
        <element name="value" type="string" minOccurs="0"/>
        <element name="class" type="string" minOccurs="0"/>
      </sequence>
    </complexType>
  </element>
</schema>
                      
Con Oracle XML DB 11g, esta modificación es rápida y requiere recursos mínimos. Este nuevo procedimiento requiere que el esquema URL y un documento XMLType (XMLDiff) se ajusten al esquema xdiff XML. El documento XMLDiff es un documento especialmente formateado que refleja los cambios en el esquema XML. En lugar de tener que crear manualmente el documento XMLDiff, éste puede realizarse automáticamente con la función xmldiff en Oracle Database.
Primero, cree un nuevo archivo de esquema con la definición de esquema XML actualizada CompanySpecific.1.1.xsd. Luego utilice la función xmldiff de Oracle Database con el antiguo esquema como primer parámetro y el nuevo esquema como segundo parámetro:
var oldSchemaDoc clob;
var newSchemaDoc clob;
 begin
     :oldSchemaDoc := xmltype(bfilename('XML_TEST','CompanySpecific.1.0.xsd'),
                        


        nls_charset_id('AL32UTF8') ).getClobVal();
      :newSchemaDoc := xmltype(bfilename('XML_TEST','CompanySpecific.1.1.xsd'),
                        


        nls_charset_id('AL32UTF8') ).getClobVal();
    end;
/
                      
Usted puede ver el documento XMLDiff utilizando
select xmldiff(xmltype(:oldSchemaDoc),xmltype(:newSchemaDoc)).getClobVal()
 from dual;
/

Por razones de simplicidad, utilice una variable CLOB para almacenar el documento XMLDiff.
var diffXMLDoc clob;
begin
   select xmldiff(xmltype(:oldSchemaDoc),xmltype(:newSchemaDoc)).getClobVal()
   into :diffXMLDoc from dual;
end;
/ 

Ahora que el documento XMLDiff está disponible, el procedimiento inPlaceEvolve puede utilizarse para modificar el esquema XML online.
SQL>alter session set events='31150 trace name context forever, level 0x200000';

Session altered.

SQL> 
SQL> BEGIN 
 2 DBMS_XMLSCHEMA.inPlaceEvolve('CompanySpecific.1.0.xsd',xmltype(:diffXMLDoc));  
 3 END; 
 4 /

PL/SQL procedure successfully completed.

Un análisis del archivo de rastreo muestra que el tipo de base de datos que representa al elemento complejo modificado fue alterado para incluir al nuevo elemento:
change to ct  sqltype = csProduct1046_T
 ------------ QMTS Executing SQL ------------ 
ALTER TYPE "XMLTEST"."csProduct1046_T"
ADD ATTRIBUTE "class" VARCHAR2(4000 CHAR)
CASCADE NOT INCLUDING TABLE DATA
/
 --------------------------------------------
                      
La incorporación de esta nueva característica facilita la administración efectiva de los cambios en los esquemas XML, aún con una gran cantidad de volumen de documentos, sin requerir la aparición de una ventana de no disponibilidad durante la evolución del esquema. Esta es una importante mejora que optimiza la viabilidad de utilizar Oracle XML DB para las soluciones de grandes empresas.
Aplicaciones Prácticas
Oracle XML DB 11g ofrece una solución completa y eficiente para la administración de contenido que es mucho más útil y práctica que cualquier otra alternativa. Al tener una visión de cada documento centrada en la base de datos, Oracle XML DB ofrece un método innovador y avanzado para almacenar y recuperar el contenido XML. Las distintas opciones de almacenamiento brindan la capacidad de administrar eficazmente todos los documentos, independientemente del tamaño y la complejidad. La nueva característica para modificar eficazmente las definiciones del esquema XML hace que Oracle XML DB sea la solución ideal para el contenido frecuentemente cambiante. Estas características cumplen con los desafíos de administración de contenido XML complejo y brinda una solución que merece ser seriamente considerada por todas las empresas.
A pesar de que el uso de XML complejo descrito en este informe podría parecer bastante complicado, surge como el estándar de varias industrias. Por ejemplo, en el sector de telecomunicaciones, las empresas ya están utilizando esquemas XML similares a los demostrados en este informe para distribuir métricas de transmisión (vea 3GPP). Considerando el gran valor y la flexibilidad que XML complejo ofrece y las incomparables capacidades de Oracle XML DB para administrar eficazmente este contenido, es posible que el uso de XML se vuelva más frecuente a medida que más responsables de la toma de decisiones tomen conciencia del potencial de Oracle XML DB 11g.

Fuente: Web Oficial de Oracle