Category: Oracle 10g

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, 18660 views. Categories: Base de datos, Oracle 10g, 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, 7018 views. Categories: Oracle 11g, Oracle 10g, Tuning / Performance ,

Oracle 11g : SMCO Space Management Coordinator (Nuevo proceso background)



Oracle 11g : Space Management Coordinator

Este nuevo proceso background es el encargado de coordinar varias tareas asociadas al manejo del espacio en Oracle 11g



Por ejemplo , una de las tareas más efectivas en cuanto a la performance es evitar el crecimiento dinámico de los datafiles, eso que tanto daño hace a los tiempos de respuesta de las aplicaciones ¿Porqué?, sencillamente pues mientras un proceso que está ejecutando DML masivo hace que los datafiles lleguen al 100% de uso, habrá otro proceso que está asignando el espacio que necesitan esas DML, por ende ,habrán esperas a que los procesos internos de Oracle dispongan de espacio.

De hecho siempre nos dicen que debemos mantener nuestros tablespaces con un 10% o 15% de espacio libre (no sólo para ambientes transacionales ino que batch también), para evitar eso (el crecimiento dinámico) pues... desde ahora en adelante eso lo hará un proceso background llamado SPACE MANAGEMENT COORDINATOR (SMCO) , esta actividad la realiza mediante sus esclavos (parece cuento egipcio), y estos esclavos llamados Wnnn serán los que lleven a cabo la tarea indicada por el SMCO

En Oracle11g , este proceso background autoextiende los datafiles (de forma automática), para ello los datafiles deben estar con AUTOEXTEND en ON , el SMCO decide autoextender los datafiles, pero.. de acuerdo a su historial de crecimiento, cada vez que SMCO autoextiende los datafiles de un tablespace , lo hace siempre de forma pareja en todos los archivos del tablespace.

Este proceso background se gatilla cada una hora. De hecho se puede verificar que este presente , mediante un comando tail al archivo de alertas



O un comando ps -afe para analizarlo como Proceso Background



A parte de las tarea de asignar mas tamaño de forma dinámica a los tablespaces , este proceso background también efectúa las siguientes acciones :

- Administración de tamaño para los Securefile Log Segments
- Recuperación de tamaño de los tablespaces temporales (nueva característica de Oracle11g)

¿Con esto nos iremos despidiendo de los DBO?

Notas de redeferencia

Se actualizan los links (06 NOV 2015)
Note : 444149.1 : New Background Processes In 11g

Note : 743773.1 : Smco (Space Management Coordinator) And Autoextend On Datafiles

Espero sea de utilidad

by Ligarius
01.06.09. 17:11:49. 367 words, 6223 views. Categories: Base de datos, Oracle 11g, Oracle 10g, Tuning / Performance ,

<< 1 2 3 4