Ocultar código PL/SQL en Database con wrapper

En ocasiones nos encontramos con código PL/SQL almacenado en Base de Datos con información sensible que no queremos que nadie vea, nada más que nosotros. Oracle dispone de una utilidad (wrap.exe) la cuál puede servir para proteger la propiedad intelectual del código de los desarrolladores, ya que deja el código en un formato no legible.

Se puede invocar desde el S.O. o desde la propia Base de Datos (a partir de 10G). Vamos a ver las ambas opciones:

Imaginar que tenemos el siguiente código;

CREATE OR REPLACE procedure ADMIN.kill_session
( v_sid number, v_serial number )
as
v_varchar2 varchar2(100);
begin
execute immediate 'ALTER SYSTEM KILL SESSION '||''''|| v_sid || ',' || v_serial 
|| '''' || ' immediate;';
end;
/

Desde el S.O.:

Podemos ver el resultado de aplicar wrap.exe al procedimiento:

Ahora los subimos a Base de Datos y comprobamos que queda en un formato ilegible:

Uso del paquete DBMS_DDL para wrapping dinámico:

Este paquete contiene tres funciones sobrecargadas llamada WRAP. La más simple acepta parámetros de entrada del tipo VARCHAR2 conteniendo una sentencia PL/SQL CREATE OR REPLACE que retorna el PL/SQL ilegible. Veamos el siguiente ejemplo:

 

Esto funciona correctamente con código PL/SQL menor o igual a 32K, pero el parámetro de entrada VARCHAR2 no puede hacer frente a código más grande. Para solventar esto podremos utilizar las funciones sobrecargadas:

DBMS_DDL.WRAP(
   ddl      DBMS_SQL.VARCHAR2S,
   lb       PLS_INTEGER,
   ub       PLS_INTEGER)
  RETURN DBMS_SQL.VARCHAR2S;

DBMS_DDL.WRAP(
   ddl      DBMS_SQL.VARCHAR2A,
   lb       PLS_INTEGER,
   ub       PLS_INTEGER)
  RETURN DBMS_SQL.VARCHAR2A;

La diferencia entre ambas es el tipo DBMS_SQL.VARCHAR2S limitado a 256 bytes por línea, mientras que el tipo DBMS_SQL.VARCHAR2A mantiene un máximo de 32K por línea. Mostraré un ejemplo:

 

Comparte si te ha gustado ...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

FLASHBACK I: Introducción

Flashback es una nueva característica de Oracle Enterprise Edition 10G que puede ser usada para volver una Base de Datos atrás en un punto en el tiempo opuesto al tradicional point-in-time recovery.

Esta característica incluye Oracle Flashback Query, Oracle Flashback Version Query, Oracle Flashback Transaction Query, Oracle Flashback Transaction, Oracle Flashback Table, Oracle Flashback Drop, Oracle Flashback Database.

Podemos utilizar las funciones de Flashback para ver los estados pasados ​​de los datos y las partes o la totalidad de rebobinado su base de datos. En general, las características flashback son más eficientes y menos perjudiciales que la media recovery en la mayoría de las situaciones en las que se aplican.

Logical Flashback Features

La mayoría de las características de Oracle Flashback operan a nivel lógico, lo que le permite ver y manipular objetos de base de datos. Las características de flashback a nivel lógico de Oracle no dependen de RMAN y están disponibles sea o no RMAN parte de su estrategia de copia de seguridad. Con la excepción de Flashback Drop, las características de flashback a nivel lógico se basan en datos UNDO.

  • Oracle Flashback Query:
    Puedes especificar un target time y ejecutar queries sobre la Base de Datos,
    viendo los resultados que se deberían obtener sobre el target time.
  • Oracle Flashback Version Query:
    Puedes ver todas las versiones de todas las filas existentes en una o más
    tablas en un intervalo de tiempo especificado.
  • Oracle Flashback Transaction Query:
    Se pueden ver los cambios creados por una o todas las transacciones durante
    un periodo de tiempo.
  • Oracle Flashback Transaction:
    Se pueden invertir los efectos de una transacción. Oracle Database determina
    las dependencias entre transacciones y crea una transacción de compensación
    que se invierte los cambios no deseados.
  • Oracle Flashback Table:
    Se puede recuperar una tabla o conjunto de tablas a un punto específico de
    tiempo en el pasado sin poner parte de la Base de Datos offline. En muchos
    casos, Flashback Table elimina la necesidad de ejecutar la operación de
    point-in-time recovery que es más compleja.
  • Oracle Flashback Drop:
    Se pueden invertir los efectos de una sentencia DROP TABLE.

Flashback Database

A nivel físico, Oracle Flashback Database ofrece una protección de datos más eficiente, alternativa a  database point-in-time recovery (DBPITR).

Flashback Database utiliza flashback Logs para acceder a versiones anteriores de bloques de datos y alguna información de archive redo logs. Flashback Database requiere la configuración de Flashback Recovery Area ya que los flashback logs serán almacenados en este área.

Oracle Database también soporta puntos de restauración (alias que corresponde a un SCN)  junto con Flashback Database y backup/recovery.

Comparte si te ha gustado ...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Clustering Factor

Oracle toma las I/O por bloques. Por lo tanto la decisión del optimizador de realizar TABLE FULL SCAN  está influenciado por la cantidad de bloques accedidos, no de filas. Esto es conocido como index cluatering factor. Si los bloques contienen una fila, entonces, las filas y bloques accedidos son los mismos.

Por todo esto, el clustering factor es una característica muy importante para la toma de decisiones del CBO, mas concretamente, a la hora de elegir el coste asociado a una operación mediante un INDEX RANGE SCAN o un TABLE FULL SCAN.

Con esta característica podemos observar la ordenación del índice con los datos en la tabla. Una tabla con los datos mal ordenados tendrá un clustering factor alto o cercano al número de registros, lo cual llevará a que el CBO acceda a los datos mediante FULL TABLE SCAN. Por el contrario si los datos están bien ordenados en la tabla , tendremos un clustering factor bajo o cercano al numero de bloques de datos, y el CBO llevara a cabo un INDEX RANGE SCAN.

Cuando un índice puede ser usado, Oracle revisa la información del Clustering Factor del índice, el cuál le dice a Oracle el número de bloques que deben ser leídos para conseguir los datos necesarios por la condición de la query.

Evidentemente podemos ver que con un clustering factor bueno, reducimos el número de I/O lógicas requeridas.

Algo importante a tener en cuenta es que no vamos a reducir el clustering factor llevando a cabo un rebuild del índice, ya que el clustereing factor está asociado con la ordenación de los datos dentro de la tabla y no del índice. La única forma de cambiar esto es cambiar el índice o el orden de la tabla.

La siguiente query es un ejemplo de como podemos obtener el clustering factor, entre otros valores, del índice dado:

SELECT a.index_name, b.num_rows, b.blocks, a.clustering_factor
FROM dba_indexes a, dba_tables b
WHERE a.index_name = ‘nombre_indice’
AND a.table_name = b.table_name ;

Comparte si te ha gustado ...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Oracle Database 11g: Diagnostics

Dentro del top de las nuevas características de Oracle 11g no puede faltar uno de los mayores cambios en cuanto a estructura de ficheros de diagnostico (alertas, errores, …) y forma de administrarlos. A continuación presentaré la nueva estructura.

Cambios en los archivos de log;

  • Automatic Diagnostic Repository
  • $ORACLE_BASE/diag
  • alert.log
    • xml format
    • $ORACLE_BASE/diag/rdbms/orcl/orcl/alert/log.xml
    • adrci> show alert -tail
    AUTOMATIC DIAGNOSTIC REPOSITORY

    Continue Reading

    Comparte si te ha gustado ...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

    Ciclo de vida de un Cursor

    Es importante entender el funcionamiento de un cursor para poder optimizar aplicaciones que ejecuten sentencias SQL. A continuación mostraré una gráfica con los distintos pasos que se llevan a cabo en el proceso de un cursor:

    Continue Reading

    Comparte si te ha gustado ...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

    Suspender, reanudar o matar un proceso Datapump

    Datapump es una versión mejorada de las utilidades export e import, que Oracle ha introducido en su versión 10g. Pero no voy a utilizar este post para explicar qué es o cómo usar Datapump, sino para cuando nos encontramos en la situación de haber lanzado un proceso de export o import con datapump y necesitamos suspenderlo o matarlo.

    Una característica de Datapump es que podemos tener mucho más control del proceso de export/import,  por ejemplo.

    Imaginemos que lanzamos el siguiente trabajo de exportación:

    expdp system@db full=Y dumpfile=dump:expDB.dmp logfile=dump:expDB.LOG job_name=jobdb

    Puede darse el caso que queramos suspender el proceso porque necesitamos ejecutar otra operación urgentemente y no queremos que ningún proceso auxiliar nos pueda afectar en el rendimiento. O simplemente queremos suspender el proceso desde la máquina en la que nos encontramos y continuarlo desde nuestra casa, por ejemplo.

    Si pulsamos ctrl+c desde la línea de comandos, entraremos en el modo interactivo de datapump “EXPORT>” y a partir de este momento podremos interactuar con algún job de Datapump. Esto es así dado que cuando un export o import datapump es lanzado, automáticamente se crea un JOB. Continue Reading

    Comparte si te ha gustado ...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

    Cómo particionar una tabla existente usando DBMS_Redefinition

    Presentaré un ejemplo de cómo particionar una tabla ya existente usando el paquete dbms_redefinition. Dicho paquete nos permite realizar una reorganización de tablas online.

    Existen ciertas restricciones por las cuales las tablas de la siguientes características no podrán ser redefinidas online (metalink ID 149564.1):

    • [9.0.1]Tables with no primary keys
    • Tables that have materialized view logs defined on them
    • [9i] Tables that are materialized view container tables and AQ tables
    • [10g] Tables that are replicated in an n-way master configuration can be redefined, but horizontal subsetting (subset of rows in the table), vertical subsetting (subset of columns in the table), and column transformations are not allowed
    • Tables with fine-grained access control (row-level security)
    • Tables with BFILE columns
    • Tables with LONG columns can be redefined online, but those columns must be converted to CLOBS. Also, LONG RAW columns must be converted to BLOBS. Tables with LOB columns are acceptable.
    • Tables in the SYS and SYSTEM schema
    • Temporary tables
    Los pasos para particionar una tabla ya existente son los siguientes:
    Comparte si te ha gustado ...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

    Slow Performance y Foreign Keys

    Cuando una tabla tiene una foreign key sin índice y se produce un DELETE o UPDATE en la tabla padre, un “shared lock” es requerido en la tabla hija. Aunque este bloqueo es liberado inmediatamente después de obtenerse, podemos apreciar una degradación de rendimiento del sistema en DML concurrentes en tablas padre e hija.

    Si la foreign key es indexada no se producirán bloqueos de tabla de ningún tipo en la tabla hija como resultado del INSERT, UPDATE o DELETE.

    Por esta razón es importante a la hora de crear una foreign key, ver que uso se le va a dar y si es necesario indexarla para evitar problemas de rendimiento en la aplicación.

    Este problema me lo he encontrado en algunas aplicaciones, cuando intentaban realizar un DELETE de una fila, el sistema era más lento de lo habitual. Lo mismo ocurría al intentar realizar un import de la misma tabla.

    Después de comprobar que el plan de ejecución del DELETE era correcto, activé la traza para la sesión en concreto que estaba realizando la operación y me di cuenta que estaba realizando un FULL TABLE SCAN de la tabla hija, la cual tenía la foreign key sin indexar.

    Tan pronto como desactivé la foreign key o creé un índice para dicha foreign key todo empezó a ir mucho más rápido.

    Comparte si te ha gustado ...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

    Instalación y Desinstalación Oracle Text 10g

    Oracle Text está disponible sin licencias adicionales para las cuatro ediciones de base de datos: Oracle Database Standard Edition One, Oracle Database Standard Edition (SE), Oracle Database Enterprise Edition (EE) y Oracle Database Personal Edition.

    Instalación manual de of Text 10gR1 (10.1.0.x)

    1. Nombre de schema CTXSYS, creado a través de la llamada al siguiente script desde SQL*Plus conectado as SYSDBA:

    SQL> connect SYS/password@tns_ as SYSDBA
    SQL> spool text_install.txt
    SQL> @?/ctx/admin/catctx.sql CTXSYS SYSAUX TEMP NOLOCK Continue Reading

    Comparte si te ha gustado ...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn