Oracle y yo

Para comenzar la charla , les pido disculpas por el tiempo alejado de las canchas, pero fue única y exclusivamente por la carga de trabajo que tenía en mi empresa, de hecho hoy en día me encuentro dictando dos cursos por día :

- Horario de tarde : WorkShop II Ed 3 de Oracle10g
- Horario de noche : Oracle Reports Builder 11g

Así que imagínense el tiempo que tengo, pero bueno... a lo que vinimos...



El evento de espera LOG FILE SYNC se da cuando una sesión de usuario ejecuta un final de transacción por ejemplo un COMMIT o un ROLLBACK , la información almacenada en el Log Buffer para esa transacción necesita ser envíada a disco , especificamente a los archivos de redolog, cuando está finaliza , la sesión recién comienza a generar otras actividades, en otras palabras, cuando se ejecuta un término de transacción la sesión entra en un evento de espera, que está relacionado al tiempo que demora el LGWR en escribir las entradas del log buffer (en realidad son vectores, pero es materia de otro Post) hacía los redologs, cuando eso finaliza .. la transacción se acepta como válida.


A veces , cuando la aplicación es muy transaccional , el LOG FILE SYNC , aparece como un Top 5 dentro del Statspack o dentro un AWR Rpt, cuando sucede eso, hay formas de mejorar esos tiempos de respuesta.



Observación : No se recomienda llevar a cabo estos cambios sin la visación de Oracle Support




Ejecución de commit asincrónico

Como ya vimos el proceso del commit y como se vaciaban los registros desde el Log Buffer , pasamos a señalar el como ejecutar el commit asincrónico para solucionar el evento de espera LOG FILE SYNC


El comando commit posee variaciones , las cuales se pueden apreciar en el siguiente detalle
WAIT : No se retorna el mensaje de commit exitoso hasta que las entradas del LogBuffer hayan sido escritas a los redo logs

NOWAIT : El commit puede retornar el control a la aplicación aunque aún la sentencia no este registrada a los archivos de redologs, lo cual puede resultar algo peligroso.

IMMEDIATE : El proceso LGWR escribe de forma inmediata la entrada de la transacción presente en los log buffer hacía los redo logs, en otras palabras , se fuerza un I/O

BATCH : Este modo le indica a Oracle que a pesar de haber finalizado la transacción con un commit, la bajada de los vectores desde el log buffer se produzca en el ciclo normal del log buffer , por ejemplo , cuando se llena a un tercio

Por defecto , cuando ustedes ejecutan el commit se ejecuta con WAIT IMMEDIATE , pero esto se puede modificar ejecutando la siguiente sentencia

COMMIT WRITE NOWAIT IMMEDIATE , o sea, no espera a que se escriba la información del log buffer a los redo logs, entrega el control a la aplicación y hace la bajada de la información del log buffer de forma inmediata a los redo logs

Es una opción que hay que manejar con cuidado , pues puede haber pérdida de datos , por ejemplo este comando

COMMIT WRITE NOWAIT BATCH , puede dejar mucha información en memoria , indicarles que se hizo el commit exitoso y ante una caída quedar con información inconsistente.

Todo lo anterior también se puede setear mediante el parámetro de incialización correspondiente

COMMIT_WRITE

Y analizando toda esta información , para solucionar en parte el evento de espera LOG FILE SYNC , se podría cambiar el modo del commit para los procesos batch de la siguiente forma

COMMIT WRITE NOWAIT BATCH

Espero que les haya servido

Documentación necesaria
Parámetro COMMIT_WRITE
Evento de espera LOG FILE SYNC

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

Me imagino que todos los que hemos programado en Reports Builder, conocemos lo complicado que es cuando nos encontramos con una serie de Frame de repetición, de no repetición , campos, imagenes, etc.

De hecho se podría decir que se ve así

Pues bien, existe una serie de modificaciones que se pueden realizar en Reports para que nunca más se visualice un reports de esa forma.

1.- Genero un reports por defecto , con el Wizard

2.- La salida del reporte se verá como sigue

3.- Y dentro del Paper Layout, saldrá así, todo junto, pegado , una línea sobrepuesta con otra y en este punto, maldecimos de porque llegamos a la informáatica, sobre todo, cuando se mueve una de esas rayitas

4.- Para evitar esas líneas pegadas, vamos al menú principal, y en Edit --> Preferences, veremos la siguiente pantalla

Y modificamos los campos "Horizontal Gap", "Vertical Gap" , "Horizontal Interfield" y "Vertical Interfield" , asignandole un valor, salvamos y cerramos

5.- Volvemos a ejecutar el reporte y se visualiza de la siguiente forma

O sea, igual que la vez anterior

6.- Pero la diferencia grandiosa y única, es que ahora aparece todo separado, que bien!!

Espero les sirva

Cuando se lleva adelante una migración de 9i a 10g, o de 8i a 10g, se tienen en consideración muchísimas cosas :
- Uso de manejo automático de memoria
- Manejo automático de la PGA
- Tablespaces en LMT con manejo automático de segmentos
- Etc,etc,etc

Pero hay un dato, bastante importante y para nada menor, que son las consultas cuando utilizamos por ejemplo, un Group By o un Distinct , en versiones anteriores a Oracle 10g, esto implicaba un ordenamiento, pero desde Oracle10g , esto ya no se produce, verdad!!! NO SE PRODUCE.

Veamos un ejemplo :

1)
Creamos en Oracle8i (8.1.7) una pequeña tabla de ejemplo, para realizar una carga de datos

2)
Le insertamos datos

3)
Cuando ejecutamos algún comando en el select que involucre ordenamiento, Oracle muestra los datos ordenados, por ejemplo , con un GROUP BY

4)
Ejecutamos un trace de la sentencia

Si nos damos cuenta , la operación para llevar a cabo el GROUP BY es una SORT GROUP BY

5)
Lo mismo sucede si llevamos a cabo una operación distinct , produce un ordenamiento implícito

6)
Al ver el plan de ejecución, para resolver la sentencia , utiliza la operación
SORT UNIQUE

¿Pero que sucede en Oracle10g?

7)Al crear la misma tabla, cargarla con los mismos datos y ejecutar las mismas sentencias, el resultado es diametralmente opuesto en cuanto a orden

8)
Si obtenemos un plan de ejecución de la sentencia, veremos que el algoritmo de ordenamiento a cambiado, ahora nos muestra un HASH GROUP BY , y los datos, ya no salen ordenados

9)
Incluso en la sentencia distinct, ya no provoca un ordenamiento

10)
Y si vemos su plan de ejecución, pues ahora nos enseña el algoritmo HASH UNIQUE para resolver el distinct

11)
El comportamiento en Oracle10g se puede modificar, no cambiando el modo del optimizador, ni su versión, se puede cambiar simplemente indicandole a Oracle que no utilice las funciones de HASH para ordenamiento

12)
Ejecutamos nuevamente la consulta yyyy , nos muestra nuevamente ordenada la consulta

Esto puede ser muy bueno, por el aspecto visual, pero puede ser muy malo a nivel de performance, ya que el no utilizar las funciones HASH para ordenamiento, puede redundar en problemas de Performance, o es arreglar todo el código, o quizás, sólo quizás, haya unos pequeños problemas de performance.

13)
Si vemos el nuevo plan de ejecución, estando en Oracle10g, nos muestra las funciones de ordenamiento antiguas

Resumen : No todo es tan bueno como parece y si los algoritmos de ordenamiento en Oracle10g son más rápidos, nada asegura que salgan en orden y eso , para los pobres programadores puede resultar desastroso , pero a la larga es lo mejor, no hay comparación entre Oracle8i y Oracle10g.

Aunque se puede llevar a cabo una modificación de parámetros ocultos, para que el comportamiento de los ordenamientos sea similar en Oracle10g a las versiones antiguas.

Referencias :Nota 345048.1 : 'Group By' Does Not Sort If You Don'T Use Order By In 10g