La independencia me hará libre...



Siempre fue una aspiración que tuve desde hace años ... el poder crear una empresa y ser mi propio jefe, pero nunca se daba....y quedaba en eso, sólo un sueño.

Pues bien , se han dado varias cosas a mi favor y hace unos 4 meses vió la luz Ingeniería Ligarius Ltda, una empresa dedicada a realizar proyectos Oracle ...de cualquier tipo, este emprendimiento es mi sueño hecho realidad.







Y la verdad, nos ha ido muy bien...estoy asociado con mi partner Marcelo y hemos realizado varios trabajos con final exitoso..

- Upgrade de Discoverer, desde versión 9i a 11g
- Configuración de GG Java Adapter , para generar JMS y dejarlos en una cola IBM MQ :>>
- Tareas varias sobre base de datos

Y por supuesto proyectos que están por venir, incluído el hacer cursos de Oracle B)

Espero que esto crezca, pero en los primeros 2 años, será trabajar mucho y darnos a conocer... por lo mismo, mi tiempo se ha visto reducido a casi cero :|

De todas formas la sensación es maravillosa ;)

by Ligarius
09.01.14. 16:39:30. 183 words, 2100 views. Categories: Base de datos, Cosas varias, Instalación ,

Trabajando en : Bogota , Colombia



Tengo la suerte de ir a Colombia por trabajo, será la revisión de unos RACs en 11gr2 y 10gr2

Veremos problemas de desempeño y entregaremos las correspondientes soluciones.






Así que una semana estaré OFFLINE :)

Nos vemos a la vuelta...

by Ligarius
28.08.13. 18:14:15. 41 words, 10705 views. Categories: Cosas varias ,

Información importante en AWR : Operating System Statistics



Una parte importante para analizar en un reporte de AWR , es lo que corresponde a estadísticas de Sistema Operativo, aunque esto se puede sacar de múltiples formas, como por ejemplo el comando sar, prstat, top , etc,etc.

Pero como está disponible en Oracle a través de un reporte de AWR, sería necesario que supieramos al menos de que se trata, he acá un pequeño resumen de lo que significa ese bloque de datos.

Un ejemplo de estadísticas de sistema operativo



1.- AVG_BUSY_TIME = Es el cálculo de BUSY_TIME/NUM_CPUS
2.- AVG_IDLE_TIME = Es el cálculo de IDLE_TIME/NUM_CPUS
3.- AVG_IOWAIT_TIME = Es el cálculo de IOWAIT_TIME/NUM_CPUS
4.- AVG_SYS_TIME = Es el cálculo de SYS_TIME/NUM_CPUS
5.- AVG_USER_TIME = Es el cálculo de USER_TIME/NUM_CPUS

6.- BUSY_TIME = Es un tiempo equivalente a %usr + %sys en un comando sar , la diferencia está que el comando sar lo expresa en porcentajes y acá se expresa en unidades.
7.- IDLE_TIME = Es un tiempo equivalente a %idle en un comando sar, la diferencia está que el comando sar lo expresa en porcentajes y acá se expresa en unidades.
8.- IOWAIT_TIME = Es un tiempo equivalente a %wio en un comando sar, la diferencia está que el comando sar lo expresa en porcentajes y acá se expresa en unidades.
9.- SYS_TIME = Es un tiempo equivalente a %sys en un comando sar, la diferencia está que el comando sar lo expresa en porcentajes y acá se expresa en unidades.
10.- USER_TIME = Es un tiempo equivalente a %usr en un comando sar, la diferencia está que el comando sar lo expresa en porcentajes y acá se expresa en unidades.

%usr : Es el porcentaje de tiempo de la CPU que es gastada en procesos de usuarios, como aplicaciones , shell scripts o interactuando con el usuario
%idle : Es el porcentaje de tiempo de la CPU en que no hay ninguna actividad .
%wio : Es el porcentaje de tiempo de la CPU en que se está a la espera de una lectura o escritura de un bloque en sistema operativo, por ejemplo, tratando de leer un disco.
%sys : Este porcentaje de tiempo de uso de la CPU está relacionado a la ejecución de las tareas de Kernel (S.O.).


Esta información puede ser obtenida con el comando sar, ejemplo sar -u 1 10 , quiere decir que sacará estadísticas de sistema operativo cada 1 segundo , 100 repeticiones.

Salida de referencia :

$ sar -u 1 10

HP-UX Poseus B.11.31 U ia64 08/26/13

13:00:46 %usr %sys %wio %idle
13:00:47 89 6 5 0
13:00:48 81 4 15 0
13:00:49 78 13 9 0
13:00:50 78 21 1 0
13:00:51 76 22 2 0
13:00:52 85 13 2 0
13:00:53 88 7 5 0
13:00:54 75 11 13 1
13:00:55 61 8 29 2
13:00:56 57 4 35 4

Average 77 11 12 1


11.- LOAD = Significado no es claro, por ende se deja de lado en los análisis (incluso esto aparece en las notas oficiales de Oracle)

12.- OS_CPU_WAIT_TIME = El tiempo de espera en las colas de ejecución (dato no claro de acuerdo a las notas de Oracle)
13.- RSRC_MGR_CPU_WAIT_TIME = Tiempo de espera en los Resource Manager
14.- PHYSICAL_MEMORY_BYTES = Total de memoria usada
15.- NUM_CPUS = Número de CPUs reportadas por el Sistema Operativo

Casi todas las cantidades expresadas están en centésimas segundos...por ende si se requiere cambiar para llevar a porcentajes, se puede hacer de la siguiente forma.

ELAPSED TIME = SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME

O sea

ELAPSED TIME = 39948702 + 6304516 + 74707066 + 0
ELAPSED TIME = 120960284


El cálculo de "ELAPSED TIME" debe ser muy parecido a la cantidad de segundos que fueron contemplados dentro del informe de AWR, esto lo podemos ver al inicio del reporte

Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 41607 05-Aug-13 00:00:24 1913 3.0
End Snap: 41628 05-Aug-13 21:00:19 51 3.3
Elapsed: 1,259.91 (mins)
DB Time: 1,116.03 (mins)

"ELAPSED TIME" = (Cantidad de minutos desde el Snap inicial al final) * 60 seg. por minuto * Número de CPUs
"ELAPSED TIME" = 1259.91 * 60 * 16
"ELAPSED TIME" = 1209513.6


Como ya tenemos "ELAPSED TIME" derivado del cálculo de SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME , podemos realizar los cálculos del porcentaje...

ELAPSED TIME = 120960284


Ejemplo

%busy ={(BUSY_TIME / "ELAPSED TIME" )} * 100
%busy ={([USER_TIME + SYS_TIME] / "ELAPSED TIME" ) } * 100
%busy = {([6304516 + 39948702] / 120960284)} * 100
%busy = {46253218 / 120960284} * 100
%busy = 0.38 * 100
%busy = 38


En Oracle 12c , se agrega un nuevo bloque de datos en el AWR, la información que aquí aparece es similar a la salida del comando "sar -u" y muestra la carga que tuvo la base de datos
a nivel de CPU

Espero les sirva

by Ligarius
26.08.13. 16:00:12. 726 words, 6347 views. Categories: Tuning / Performance, Oracle 12c ,

Oracle 12c New Features : Ejecución de sentencias SQL a través de RMAN



Una nueva característica de RMAN es la posibilidad de ejecutar las sentencias SQL a través del mismo PROMPT de RMAN.


Simplemente una escena de culto :)

Antes de Oracle 12c , las sentencias SQL se tenían que ejecutar ocupando el string sql y no todas las sentencias podían ser ejecutadas , un ejemplo de ello.

sql 'alter system checkpoint';


Pues bien , desde ahora no es necesario ocupar el string sql , se puede colocar la sentencia directamente , algunos ejemplos de las sentencias que se pueden ejecutar .

Podemos realizar un Switch logfile

RMAN> alter system switch logfile;

Statement processed


Crear tablas

RMAN> create table b (campo1 number);

Statement processed


Insertarle valores o ejecutar cualquier DML

RMAN> insert into b values (1);

Statement processed


Terminar las transacciones

RMAN> commit;

Statement processed


Crear usuarios

RMAN> create user test identified by test;

Statement processed


Consultar el diccionario de datos

RMAN> select * from v$instance;


O simplemente bajar y subir nuestra base de datos (Esto depende de los privilegios que posea el usuario)

RMAN> startup force

Oracle instance started
database mounted
database opened

Total System Global Area 521936896 bytes

Fixed Size 2404552 bytes
Variable Size 415239992 bytes
Database Buffers 96468992 bytes
Redo Buffers 7823360 bytes


La ejecución de un script mediante rman se puede hacer de la siguiente forma :

rman target usuario/password@string_de_conexion @script_a_ejecutar


Donde script_a_ejecutar puede ser lo que ustedes quieran y el resultado de ese script, lo pueden ver realizando la siguiente consulta

select * from v$rman_output;


Espero les sirva...

by Ligarius
23.08.13. 06:43:18. 250 words, 3421 views. Categories: Oracle 12c, RMAN (Recovery Manager) ,

¿Qué es un CRASH RECOVERY o INSTANCE RECOVERY?



¿Qué es un Crash Recovery o un instance Recovery?



Este concepto no es más que la recuperación de una base de datos Oracle sin intervención alguna después de que ha sufrido alguna caída inesperada, este tipo de caidas pueden ser provocadas por un corte de electricidad, desmontaje de un disco donde reside el motor, una eliminación manual de algún proceso background necesario (smon,pmon), un shutdown abort, etc.

Cuando sucede lo anterior, al levantar la base de datos esta por sí sola comienza el proceso de recuperación o crash recovery, pues es el System monitor (SMON) que detecta que Oracle no se bajo de la mejor forma y que algunos datafiles quedaron desincronizados con respecto al último SCN que queda registrado en el controlfile.

Para realizar un Crash Recovery Oracle utiliza la información que se encuentra en los redologs (técnicamente llamados online redologs), para lo anterior Oracle realiza algunos dos pasos importantes :

1.- Rolling Forward : En este proceso en partícular, Oracle va a actualizar todos los datafiles con TODA la información que encuentre en el último redologs utilizado hasta el momento de la caída, cabe recordar que Oracle escribe primero en los redologs y una vez escrito allí comienza a trasladar la información a los datafiles, es por eso que ante una caída abrupta de la base, hay ciertos registros o transacciones que no han sido pasada a los datafiles y que aún se encuentran en los redologs.

2.- Rolling Back : Con el proceso de "Rolling Forward" se pasaron todos los cambios encontrados en el último redolog utilizado hacía los datafiles y por cada cambio se generó una entrada en el tablespace de UNDO, pues bien, NO TODAS las transacciones que se aplicaron en los datafiles fueron "Comiteadas" , o sea, existen algunas transacciones a las cuales se les aplico un Rollback, pero esto Oracle no tiene como saberlo dado que los archivos de redologs son secuenciales, el no sabe si por delante de una transacción cualquiera
viene un commit o un rollback , si se traspaso a los datafiles una transacción que posteriormente se le aplicó un rollback, pues Oracle saca la información anterior desde el tablespace de UNDO, el cual se fue llenando de información a partir del proceso de Rolling Forward.

Cuando el punto 2 finaliza, sólo información realmente comiteada queda en los datafiles y es allí donde la base de datos queda en estado OPEN.

En el punto 1 , Oracle va a aplicar todas las transacciones que se encuentran entre el último Checkpoint que se produjo en la base de datos (que se encuentra marcado dentro del archivo de redolog que estaba en estado CURRENT antes de la caída) y el final del mismo archivo de redolog, está cantidad de información es la que Oracle va a aplicar en los datafiles, esta cantidad de información puede ser controlada mediante un parámetro llamado FAST_START_MTTR_TARGET (la sigla MTTR viene de las palabras MEAN TIME TO RECOVER) , con este parámetro se le busca indicar a Oracle que cantidad de segundos el se debiese demorar en realizar un CRASH RECOVERY, Oracle es capaz mediante formulas internas de convertir esos segundos a cantidad de transacciones.

El máximo valor para el parámetro FAST_START_MTTR_TARGET es 3600 segundos , o sea, que Oracle en el peor de los casos se podría demorar hasta una hora en hacer un CRASH RECOVERY después de una caida abrupta

by Ligarius
20.08.13. 07:42:32. 593 words, 4751 views. Categories: Base de datos, Conceptual ,

<< 1 ... 2 3 4 5 6 7 8 9 10 11 12 ... 44 >>