Export Datapump : No tan maravilloso pero.... comprime :)



Hace un tiempo hice un comentario, en parte infundado , en parte con fundamento sobre el export datapump.



Pueden revisar la nota acá

Era el problema de no poder contar con PIPE , tuberías o como le quieran llamar, al momento de exportar, lo que hacía que todos esos queridos códigos de export que comprimían on-line los respaldos, ya no funcionan con la versión Export Datapump.

Pues realizando un pequeño ejemplo, me encontre con la siguiente tabulación de ejemplos de export y export datapump, incluso con tuberías de por medio.
Comando % Compresion Tamaño MB
exp sin compress 0 574
exp con compress 0 574
exp sin compress y PIPE 87.5 77.5
expdp sin compress 11 512
expdp con compress 83.5 95

Los comandos

exp sin compress
exp system/oracle file=FULLDB11g full=y buffer=1000000

exp con compress
exp system/oracle file=FULLDB11g full=y buffer=1000000 compress=y

Nota : El COMPRESS del export , no está relacionado a la compresión de bloques Oracle, sino, más bien, a la cantidad de extensiones que conformarán un segmento :) , pero como sonaba a compresión lo añadí :P

exp sin compress y con PIPE
mknod pipes p
gzip < pipes> FULDB11gPipes.dmp.gz &
exp system/oracle file=pipes full=y buffer=1000000

expdp sin compress
expdp system/oracle DIRECTORY=data_pump_dir FULL=y DUMPFILE=FULLDB11gexpdp.dmp

expdp con compress
expdp system/oracle DIRECTORY=data_pump_dir FULL=y DUMPFILE=FULLDB11gexpdp.dmp COMPRESSION=ALL

Como pueden ver el ya famoso PIPE con export tiene un grado de compresión altísimo cercano al 87,5% , o sea , de cada 100MB de tamaño, deja un archivo en 12,5MB aproximadamente :)

Pero el Export Datapump , no es tan malo después de todo , pues logra un óptimo 83,5% de compresión , o sea, de cada 100MB de tamaño generaría un archivo de 16,5MB

Todo esto es en base a una base de datos de pruebas, todo varía de acuerdo a la porosidad de la base de datos (fragmentación)

Espero les sirva y claro.. me forme una mala impresión sobre el nuevo y populoso Export DataPump

PD : Gracias Luis Farías y Waldo Rojas ;)

PPD : La compresión está disponible desde 10g, pero para esta versión sólo es medatada, para la compresión total se debe usar Oracle 11g, gracias a mi amigo Juan Díaz (jada) por el comentario


by Ligarius
15.07.09. 19:30:39. 400 words, 26085 views. Categories: Base de datos, Oracle 11g, Oracle 10g, Tuning / Performance ,

Oracle Certified Expert : RAC 10g (1z0-048)



Bueno, después de un tropiezo en el examen 1z0-048 hoy por fin he obtenido mi certificación de Oracle RAC en 10g.



A esta certificación se le conoce como OCE : Oracle Certified Expert : RAC 10g

Más detalles aquí

De todas formas veo difícil alcanzar lo propuesto a principios de año con respecto a mis certificaciones, está última estuvo muy , muy difícil .

De hecho las preguntas eran del tipo elija 6 de las 8 opciones, o elija 5 de las 7, lo que obliga a analizarlas todas, no basta con encontrar al gran candidato.

Me queda por rendir
Oracle9i Forms Developer: New Features (1Z0-140)
Oracle Database: SQL Certified Expert (10g y 11g) (1Z0-047)
Oracle Database 10g: Managing Oracle on Linux Certified Expert (1Z0-046)
Oracle Database 11g: Performance Tuning (1Z0-054)

Pero es casi imposible :( , me conformo con dar 2 certificaciones más , lo cual es bastante... :)

Espero les sirva

by Ligarius
13.07.09. 13:10:00. 154 words, 4628 views. Categories: Base de datos, Certificaciones ,

¿¿Un nuevo número a nuestra versión de Oracle?? , claro , aplicando PSU (Patch Set Updates)



Acabo de leer una nota de un amigo peruano que escribe de Oracle, él es el Señor Enrique Orbegozo y me ha llamado tanto la atención lo que leí , que se los replico.



Oracle en su política de mejoras continuas acaba de crear un nuevo nivel de parches a los productos Oracle, este nivel de parches será conocido como Patches Set Updates (en adelante PSU), estos PSU serán liberados cada 3 meses a partir del 14 de Julio.

Sólo estarán disponibles PSU para las versiones (no windows) Oracle 10.2.0.4 y 10.2.0.5 y cada vez que se apliquen se generará una nueva versión de la base de datos , ¿cómo así? , pues se nombrará como 10.2.0.4.1 , vaya ... con lo complicado que es acordarse de todos los números y le agregan más.

Los CPU (Critical Patch Updates) seguirán en las mismas fechas y estos no cambian la versión de la base de datos.

Toda la información que se encuentre en el CPU de ese trimnestre estarán contenidos en el PSU que a esa fecha se liberen.

Otra desgracias adicional es que lo que vaya en el PSU solamente serán fix encontrados en los clientes Oracle a lo largo del mundo , o sea, solamente fix ya probados, no en etapa de estudio ni nada de eso.

Los sistemas operativos donde será posible obtener estos PSU :
* HP-UX PA-RISC
* HP-UX Itanium
* IBM AIX 5L Based Systems (64-Bit)
* Linux x86 (32-bit), and Linux x86-64
* Solaris Operating System (SPARC 64-Bit)

Una cosa que cabe mencionar, es que el quinto nivel de parchado no está homologado para las distintas plataformas de la base de datos :( , por ende un 10.2.0.4.1 en Linux no correspondería a un 10.2.0.4.1 en Solaris, eso si que es una pena :'(

Como resumen, si quieres aplicar los CPU no hay cambio de versión , si quieres aplicar los PSU si hay cambio de versión , pero te aseguras que los fix conocidos sean arreglados (fixes graves, no cualquiera)

Los links necesarios
Oracle Announces First Patch Set Update For Oracle Database Release 10.2
Oracle Recommended Patches -- Oracle Database


Nota de Enrique Orbegozo

Espero les sirva.

by Ligarius
08.07.09. 13:32:24. 359 words, 6781 views. Categories: Parchado Oracle ,

VARIOS : Buena matriz de las funciones en Oracle 11gr1

Leyendo por aquí por acá , encontre esta estupenda matriz de las funciones en Oracle, con ejemplos, sintáxis y agrupaciones.

Realmente muy buena, para Oracle11gr1

Matriz de funciones en PSOUG

by Ligarius
26.06.09. 18:17:44. 31 words, 4466 views. Categories: Base de datos, SQL / Programación ,

BBDD : Como tracear una sesión que se conecta/procesa/desconecta en 2 segundos



0.-Situación
La situación es que hay una sesión que está hecha en un programa (C) , este programa hace una conexión a la base de datos y ejecuta ciertas rutinas en Pro*C , y se desconecta, el inconveniente es que se demora entre que se conecta, procesa y desconecta , entre 3 a 5 segundos.
Por ende hacerle un trace es bastante complicado, ya que no se alcanza a conocer el SID ,SPID o #SERIAL para incluirlo en el package
DBMS_SYSTEM.SET_SQL_TRACE_IN_SESION(SID,#SERIAL,TRUE)

Tampoco podríamos utilizar el package DBMS_SUPPORT.START_TRACE_IN_SESSION() ya que también debiesemos conocer el SID y #SERIAL

Por ende se debe desarrollar algo alternativo para poder rescatar el proceso de esa sesión



1.-Solución
Crear un trigger on-logon para detectar cuando hace la conexión ese usuario a través de ese programa (Pro*C)

2.-Código
CREATE OR REPLACE TRIGGER
tracea_audit_trigger
AFTER LOGON ON DATABASE
DECLARE
var_session VARCHAR2(100);
var_module VARCHAR2(100);
BEGIN
SELECT sys_context('USERENV','SESSIONID')
INTO var_session
FROM dual
;


BEGIN
SELECT module
INTO var_module
FROM v$session
WHERE audsid = var_session;
EXCEPTION
WHEN OTHERS THEN
var_module := 'NO';
END;


IF UPPER(var_module) LIKE '%PROGRAMA%' THEN
EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE=TRUE';
END IF;
END;
/


Hay que tener cuidado de dar los privilegios de select sobre la vista v$session, ya que un usuario que no posea los permisos de lectura no podrá realizar la conexión, por eso se recomienda que este código sea probado en ambientes de test, previo paso a producción

3.-Permisos necesarios

Grant select on v_$session to public;

¿Porque un privilegio a Public? Pues desde el momento en que se cree el trigger cualquier usuario que se conecte a la base de datos pasara por el trigger on-logon y si no tiene acceso a la vista v$session pues simplemente no se conectará y saldrá un error de privilegios.

Grant alter system to nombre_usuario;
Grant alter session to nombre_usuario;


Los permisos para alterar la sesión y el system debiesen ser revocados una vez finalizado el proceso de captura de estadísticas

Revoke alter system from ;
Revoke alter session from ;


4.-Si no esta activada la recolección de estadísticas
Si el parámetro TIMED_STATISTICS en la base de datos posee el valor FALSE, la traza no contendrá datos relevantes por ejemplo CPU, disk , etc.

Para ello se puede alterar el trigger y modificarlo de la siguiente forma

Código anterior
IF UPPER(var_module) LIKE '%PROGRAMA%' THEN
EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE=TRUE';
END IF;


Código nuevo
IF UPPER(var_module) LIKE '%PROGRAMA%' THEN
EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE=TRUE';
EXECUTE IMMEDIATE 'ALTER SYSTEM SET TIMED_STATISTICS=TRUE';
END IF;


5.-Si el archivo de trace generado es demasiado grande
Si el archivo de trace generado es demasiado grande, se puede disminuir su tamaño modificando el trigger

Código anterior
IF UPPER(var_module) LIKE '%PROGRAMA%' THEN
EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE=TRUE';
END IF;


Código nuevo
IF UPPER(var_module) LIKE '%PROGRAMA%' THEN
EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE=TRUE';
EXECUTE IMMEDIATE 'ALTER SYSTEM SET max_dump_file_size=5120';
END IF;


El tamaño asignado al parámetro max_dump_file_size está dado por Kb y el valor por defecto es UNLIMITED


6.- ¿Qué pasa si hay muchos usuarios, en la misma máquina, ejecutando el mismo Pro*C?
Pues una solución es realizar una copia de programa , por ejemplo si el programa se llama EjecutaProc, llamarlo de una forma que sea identificable , ejemplo , prueba_ejecucion y otorgar los permisos necesario para su ejecución

Con lo anterior , este programa va a ser inequivocamente ubicado en la vista v$session , bajo el campo module, y solamente a esta sesión le realizaremos un traceo

7.- Archivo de resultados
El archivo de resultados debe estar ubicado en la ruta que está predefinida en el parámetro de inicialización user_dump_dest

select value from v$parameter where name like 'user_dump_dest' , por defecto tiene el valor $ORACLE_HOME/rdbms/trace

El archivo de resultados del traceo , no es algo que sirva mucho a primera vista, a no ser que tengamos una memoria y ojos extraordinarios para hacer un formateo visual

Ejemplo del archivo :
PARSING IN CURSOR #6 len=67 dep=1 uid=0 oct=3 lid=0 tim=19191305310633 hv=2889900621 ad='f6f19668'
select pos#,intcol#,col#,spare1,bo#,spare2 from icol$ where obj#=:1
END OF STMT
PARSE #6:c=10000,e=9470,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=19191305310617
EXEC #6:c=0,e=918,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=19191305311971
FETCH #6:c=0,e=408,p=1,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=19191305312494
FETCH #6:c=0,e=24,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=19191305312632
FETCH #5:c=0,e=94,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=19191305312816
EXEC #6:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=19191305313060
FETCH #6:c=0,e=42,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=19191305313186
FETCH #6:c=0,e=16,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=19191305313283
FETCH #5:c=0,e=43,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=19191305313402
EXEC #6:c=0,e=37,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=19191305313660
FETCH #6:c=0,e=46,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=19191305313788
FETCH #6:c=0,e=16,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=19191305313888
FETCH #5:c=0,e=40,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=19191305314015
EXEC #6:c=0,e=36,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=19191305314229
FETCH #6:c=0,e=39,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=19191305314347
FETCH #6:c=0,e=16,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=19191305314452


8.- Formateo de archivo, salida de trace
Como es algo complicado el análisis del archivo anterior, existe un utilitario llamado tkprof que realiza el formateo de este archivo, para utilizarlo se debe ejecutar lo siguiente

tkprof [explain=usuario/password] [sys=no] [insert=archivo]

Con el parámetro "explain=usuario/password" indicamos que nos muestre el plan de ejecución de todas las instrucciones, conectándose para ello al usuario/password indicados.

Con el parámetro "sys=no" indicamos que no nos muestre las instrucciones realizadas por el usuario SYS.

Con el parámetro "insert=archivo" , dejamos toda la información mostrada por tkprof en el archivo de salida,como sentencias insert en una tabla llamada tkprof_table, con lo cual podemos realizar consultas de forma más óptima

Después de haber formateado nuestro archivo en user_dump_dest , se visualizaría de la siguiente forma

select USER into :b0
from
DUAL


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 3 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.00 0.00 0 3 0 1


Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30

Rows Row Source Operation
------- ---------------------------------------------------
1 TABLE ACCESS FULL DUAL


by Ligarius
26.06.09. 18:15:21. 1151 words, 6887 views. Categories: Base de datos, Oracle 11g, Oracle 10g, Tuning / Performance ,

<< 1 ... 34 35 36 37 38 39 40 41 42 43 44 >>