Category: Tuning / Performance

Graficar en Excel información proveniente desde Statspack

El utilitario Statspack es bastante útil cuando queremos sacar datos de sucesos que han ocurrido en nuestra base de datos, de hecho nos proporcionan siempre un promedio de los datos en 2 puntos del tiempo, ¿pero que sucedería si necesitamos sacar un gráfico?, ¿cómo obtendríamos el comportamiento de nuestra base de datos por ejemplo en lo relacionado al database buffer cache?

O como podríamos saber el I/O que está presente en nuestro Storage en un período de tiempo

Suena bastante entretenido... de hecho se ve bonito , fijense..

Se imaginan crear esos gráficos con toda la información que nos presenta en Statspack

Aquí les explico paso a paso como generarlo

Aca un archivo Excel con datos de ejemplo

Espero les sirva

by Ligarius
08.06.09. 07:22:07. 128 words, 4850 views. Categories: Base de datos, Tuning / Performance, Eventos Oracle ,

Analizando la carga de trabajo mediante los Switch de Redologs

A veces sucede que nos dicen

" La base de datos está lenta " , y claro, al buscar y buscar, no encontramos el porque, hasta que alguien nos dice..

"Y justo se coloca lenta , cuando ejecutamos un proceso de carga masiva" |-|

Obviamente una de las cosas que siempre debemos fijarnos cuando el desempeño de nuestras bases de datos se ven afectadas , es inicialmente si hay algún proceso que genere alta transaccionalidad.

Esto se puede verificar por la cantidad de Switch de Redo log (información generada en los archivos de redolog)

¿Cómo saberlo? aunque sea una estimación...

Pues hay mucho scripts al respecto, y de hecho el script que les voy a enseñar, esta en miles de partes, pero la verdad es bastante útil

Este script tiene que ser ejecutado con la instancia arriba

Script SQL para calcular la cantidad de Switch de Redo Log
Para ejecutar este archivo :
sqlplus "/ as sysdba" @redo.txt

Como se visualiza la información

Este script puede que ser ejecutado con la instancia abajo :>>
Script en Perl para calcular la cantidad de Switch de Redo Log
Basado en los switch que aparecen en el archivo de alertas
Para ejecutar este archivo :
perl count_log_switches.txt

Dentro del archivo count_log_switches.txt existe una línea que se visualiza así

@check_files=("/u01/app/oracle/admin/$db_sid/bdump/alert_$db_sid.log");

En esa línea debemos colocar la real ruta de nuestro archivo de alertas ;)

Como se visualiza la salida del perl

Si analizan la información que saca estos scripts, no debiesen sobrepasar (según Oracle) los 3 switch por hora, como recomendación , les puedo decir que un switch cada 10 minutos no es para nada malo (se debe considerar el tamaño de los archivos de redolog)

Particularmente me gusta mas el de la consulta a la base de datos mediante SQL, ya que la mantención sobre el archivo de alertas muchas veces no nos deja mirar muchos días hacía atrás.

Referencias
Script: Perl sample script to parse the Alert Log for log switches Doc ID: 73475.1

Espero les sirva

by Ligarius
11.06.09. 18:13:17. 357 words, 8424 views. Categories: Base de datos, Oracle 10g, Tuning / Performance ,

Oracle10gr2 : Introducción a Transparent Data Encryption (TDE)

Una de las debilidades de muchas instituciones que cuidan sus datos de forma exagerada es que sólo los cuidan (encriptan) cuando los leen, en las interfaces de trabajo, pero nunca lo hacen de forma física, ¿cómo así?

Pues los datos físicamente pueden ser visualizados, por ejemplo , con el comando strings en los archivos de redologs, o con algún editor hexadecimal para los datafiles.

Es allí donde reside la importancia del Transparent Data Encryption (TDE), es una cualidad nacida en Oracle10gr2, que permite encriptar los datos de forma física mediante un Wallet (archivo creado en disco) y con esto sólo los datos en el archivo son codificados, pero no cuando se leen , de hecho es transparente para los usuarios.

Acá les presento un pequeño brief de lo que es Transparent Data Encryption , y claro, la forma en que se puede implementar para encriptar nuestros datos de forma física.

Explicación de Transparent Data Encryption

by Ligarius
23.05.09. 19:59:42. 163 words, 18579 views. Categories: Base de datos, Oracle 10g, Tuning / Performance ,

Tips de migración desde Oracle8i a Oracle10g : ¿Por qué no ordena? (Tips migrating Sort)

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 :yes: , 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

by Ligarius
19.05.09. 12:59:32. 514 words, 5849 views. Categories: Base de datos, SQL / Programación, Tuning / Performance ,

Oracle 10g u Oracle 11g : ¿Qué procesos se activan cuando creo y borro una tabla?

Muchas veces creemos que cuando creamos o borramos un objeto hay un par de procesos background asociados a estas tareas.

La verdad es que se mueve todo el aparataje de Oracle, para llevar a cabo actividades básicas de creación y eliminación, todo muy bien afinado con absolutamente todo al azar calculado.

Imaginense la siguiente situación :

Se muestran los procesos background que están ejecutándose en nuestra máquina

Se crea una tabla con poco menos de 5 millones de registros

Mientras esa creación esta en proceso, sucede lo siguiente en los procesos background

1)

25937 : Proceso que gatillo el proceso de creación de la tabla
11661 : Proceso LGWR (Proceso encargado de llevar hasta los archivos de redo, los vectores generados a partir de la PGA y esta a su vez, son llenados con la información del Log Buffer)

2)

25937 : Proceso que gatillo el proceso de creación de la tabla
11949 : Proceso ARC0 (Proceso encargado de generar una copia del archivo RedoLog recientemente llenado producto de transacciones efectuadas en la base de datos)
11661 : Proceso LGWR

3)

25937 : Proceso que gatillo el proceso de creación de la tabla
11661 : Proceso LGWR
11656 : Proceso DBW0 (Proceso encargado de bajar a disco aquellos bloques en estado Dirty, según una lista llamada Dirty Buffer List, ubicada en el Database Buffer Cache)
11951 : Proceso ARC1

4)

25937 : Proceso que gatillo el proceso de creación de la tabla
11661 : Proceso LGWR
11951 : Proceso ARC1
11635 : Procesp PSP0
11667 : Proceso CKPT

5)

11949 : Proceso ARC0
25937 : Proceso que gatillo el proceso de creación de la tabla
11661 : Proceso LGWR
11683 : Proceso MMON

6)

11951 : Proceso ARC1
25937 : Proceso que gatillo el proceso de creación de la tabla
11661 : Proceso LGWR
11667 : Proceso CKPT
25858 : Proceso padre de la sesión que gatillo el proceso
11681 : Proceso CJQ0

Todo lo anterior sucedio cuando se creo la tabla.

¿y qué sucedio cuando se borro?

Pues bien , los procesos background involucrados

7)

25937 : Proceso que gatillo el proceso de borrado de la tabla
11677 : Proceso SMON
11661 : Proceso LGWR

8)

11677 : Proceso SMON

Oracle es potente y por sobre todo dessincronizado :) , ¿cómo aprender más del ciclo natural de Oracle?, pues bien...

Lee los Concepts

Concepts Oracle8i
Concepts Oracle9i
Concepts Oracle10g
Concepts Oracle11g

by Ligarius
28.05.09. 12:51:51. 356 words, 7000 views. Categories: Oracle 11g, Oracle 10g, Tuning / Performance ,

<< 1 2 3 4 5 6 7 8 >>