Direct Path vs External Table Path

Direct Path y External Table Path son mecanismos que usan los trabajos Data Pump para cargar/descargar datos hasta/desde un archivo Pump (Pump File). En este artículo vamos a identificar sus diferencias y analizar su uso con el los datafiles y el Database Buffer Cache

Direct Path

Al utilizar Direct Path estamos evadiendo el Database Buffer Cache. Cuando se hace una exportación Data Pump lee los datafiles directamente desde disco, extrae el contenido y lo formatea y lo escribe como un archivo Dump (Dump File). En la importación en cambio, Data Pump lee el archivo Dump, usa su contenido para ensamblar los bloques de los datos de tabla y los escribe directamente en los datafiles.

Cuando se escribe la información en las tablas (Durante el proceso de importación), se la hace sobre el «High-water mark» de la tabla. El «High-water mark» es un marcador en la tabla sobre el cual ningún dato ha sido escrito nunca. Cuando la carga de los datos es finalizada, Data Pump eleva el «High-water mark» para incluir los nuevos bloques escritos y las nuevas filas insertadas en la tabla son visibles para los otros usuarios (Esto es equivalente a ejecutar un COMMIT)

Cabe recalcar que en este proceso no se generan Datos Undo y si se desa se puede desactivar la generación de Datos Redo

Al utilizar Data Pump se obtienen operaciones más rápidas a nivel de rendimiento; además no tiene un gran impacto sobre los usuarios finales ya que la interacción con el SGA es mínima.

External Table Path

Al utilizar External Table Path se utiliza el Database Buffer Cache. Aunque con este mecanismo Data Pump manipula archivos que son ajenos a la base de datos, se utiliza el Database Buffer Cache como si estuviera leyendo/escribiendo desde/hasta una tabla interna. Para una exportación, Data Pump lee los bloques desde los Datafiles y los carga en el Database Buffer cache (Similar a una operación normal de SELECT); desde ahí los formatea para ser cargados en el formato del archivo Dump (Dump File). Cuando se realiza una importación, Data Pump construye sentencias DML tipo INSERT desde el contenido del archivo Dump y las ejecuta leyendo los bloques desde los Datafiles y cargándolos en el Database Buffer Cache, donde las sentencias INSERT toman lugar (Como en un proceso INSERT normal)

En lo que concierne a la base de datos los trabajos Data Pump basados en External Table lucen como operaciones normales de Selección e Inserción (SECLECTs e INSERTs respectivamente); al ser así se generan datos Redo y Undo y Commits se realizan de forma normal (Tal como cualquier opeación DML)

Aspectos a tener en cuenta

Como DBA no tenemos opción de elejir si usamos External Table Path o Direct Path. Data Pump toma la decisión de acuerdo a la complejidad de los objetos.  Estructuras simples son ejecutadas via Direct Path. Estructuras más complejas (que incluyan triggers activos, tablas agrupadas – clustered – , o tablas particionadas) forzarán a Data Pump a usar External Table Path ya que necesitan interacción directa con el SGA para resolver la complejidad.  En cualquiera de los dos casos, el arhivo Pump generado es idéntico

REMOTE_LOGIN_PASSWORDFILE

El parámetro REMOTE_LOGIN_PASSWORDFILE controla si es posible conectarse a la instancia como un usuario con privilegios SYSDBA sobre una red.  Si este parámetro está en NONE (default), la única manera de tener conexión como SYSDB es iniciando una sesión en el sistema operativo de la máquina que trabaja como servidor de la base de datos, como un usuario miembro del grupo que es dueño del servidor Oracle (En el caso de Windows es ORA_DBA)

Si este parámetro es configurado en SHARED o EXCLUSIVE se da a los usuarios que si, aunque no estén «loggeados» en el sistema operativo del servidor como miembro del grupo que es dueño del servidor Oracle o si están connectados a través de una red, aún es posible conectarse como SYSDBA mediante el password adecuado. Existe un archivo en el directorio %ORACLE_HOME%\database que almacena estos passwords en forma encriptada.

Si el parámetro está configurado en SHARED quiere decir que todas las instancias que corren en el mismo ORACLE_HOME compartirán un mismo archivo de passwords (Password file); esto implica tener un solo password en el Password File para el usuario SYS que es común para todas las instancias. Si el parámetro está configurado en EXCLUSIVE, la instancia buscará por el Password File que tenga el nombre de la instancia (SID) en el nombre de archivo: PWD<SID>.ORA

Para añadir un usuario al Password File se le debe dar el permiso de SYSDBA o SYSOPER, mediante la sentencias :

SQL>  GRANT SYSDBA TO user_test IDENTIFIED BY user_test;
SQL>  GRANT SYSOPER TO user_test1 IDENTIFIED BY user_test1;

Y mediante la vista dinámica V$PWFILE_USERS se puede ver que usuarios tienen sus contraseñas en el Password File y si tienen o no los privilegios SYSDBA y SYSOPER

Identificar Segmentos de Undo Activos e Inactivos

Mediante dos simples sentencias SQL es posible identificar los Segmentos de Undo (Undo Segments)  online y offline:

Mediante la vista dinámica V$ROLLNAME es posible identificar los Segmentos Undo que están en estado Online:

SQL> select * from v$rollname;

       USN NAME
———- ——————————
         0 SYSTEM
         1 _SYSSMU1$
         2 _SYSSMU2$
         3 _SYSSMU3$
         4 _SYSSMU4$
         5 _SYSSMU5$
         6 _SYSSMU6$
         7 _SYSSMU7$
         8 _SYSSMU8$
         9 _SYSSMU9$
        10 _SYSSMU10$

11 filas seleccionadas.

Mediante la vista DBA_ROLLBACK_SEGS es posible listar los Segmentos Undo que están en estado Online y Offline, tanto en el UNDO TABLESPACE como en SYSTEM TABLESPACE. Esta vista además nos da un mayor nivel de detalle de los segmentos:

 SQL> SELECT SEGMENT_NAME, OWNER, STATUS FROM DBA_ROLLBACK_SEGS;

SEGMENT_NAME                   OWNER  STATUS
—————————— —— —————-
SYSTEM                            SYS          ONLINE
_SYSSMU1$                      PUBLIC    ONLINE
_SYSSMU2$                      PUBLIC    ONLINE
_SYSSMU3$                      PUBLIC    ONLINE
_SYSSMU4$                      PUBLIC    ONLINE
_SYSSMU5$                      PUBLIC    ONLINE
_SYSSMU6$                      PUBLIC    ONLINE
_SYSSMU7$                      PUBLIC    ONLINE
_SYSSMU8$                      PUBLIC    ONLINE
_SYSSMU9$                      PUBLIC    ONLINE
_SYSSMU10$                     PUBLIC    ONLINE

SEGMENT_NAME                   OWNER  STATUS
—————————— —— —————-
_SYSSMU11$                     PUBLIC    OFFLINE
_SYSSMU12$                     PUBLIC    OFFLINE
_SYSSMU13$                     PUBLIC    OFFLINE
_SYSSMU14$                     PUBLIC    OFFLINE
_SYSSMU15$                     PUBLIC    OFFLINE
_SYSSMU16$                     PUBLIC    OFFLINE
_SYSSMU17$                     PUBLIC    OFFLINE
_SYSSMU18$                     PUBLIC    OFFLINE
_SYSSMU19$                     PUBLIC    OFFLINE
_SYSSMU20$                     PUBLIC    OFFLINE
_SYSSMU21$                     PUBLIC    OFFLINE

22 filas seleccionadas.

Para ver el mayor nivel de detalle que da la vista DBA_ROLLBACK_SEGS se debe describir la vista y definir la columna deseada en la sentencia SELECT:

SQL> desc DBA_ROLLBACK_SEGS;
 Nombre                                    +Nulo?           Tipo
 —————————————– ——– —————————-
 SEGMENT_NAME                       NOT NULL      VARCHAR2(30)
 OWNER                                                           VARCHAR2(6)
 TABLESPACE_NAME                  NOT NULL      VARCHAR2(30)
 SEGMENT_ID                            NOT NULL      NUMBER
 FILE_ID                                    NOT NULL       NUMBER
 BLOCK_ID                                NOT NULL       NUMBER
 INITIAL_EXTENT                                             NUMBER
 NEXT_EXTENT                                                NUMBER
 MIN_EXTENTS                         NOT NULL       NUMBER
 MAX_EXTENTS                        NOT NULL       NUMBER
 PCT_INCREASE                                               NUMBER
 STATUS                                                          VARCHAR2(16)
 INSTANCE_NUM                                             VARCHAR2(40)
 RELATIVE_FNO                       NOT NULL        NUMBER

 

Server Parameter File SPFILE

El archivo SPFILE es el archivo de inicialización de parámetros de una instancia de Oracle. A diferencia del INIT<SID>.ora que es un archivo de texto plano, el SPFILE es un archivo binario. A continuación vamos a ver ciertas características de este archivo, su importancia en el funcionamiento de la instancia que se está ejecutando, entre otras cosas:

Características generales:

• Es un archivo binario, en lugar de un archivo de texto plano (archivo basado en texto)
• Está almacenado en el servidor, en lugar de estar en una máquina cliente
• Puede mantener los cambios a los valores del parámetro hacerlos perdurables sobre actividades de SHUTDOWN o STARTUP de la instancia

Cualquier cambio a los parámetros que se realice mediante la sentencia ALTER SYSTEM será almacenado como parte de la configuración permanente del archivo, por lo que si se cambian valores de parámetro por motivos de afinamiento, no se tiene que actualizar manualmente el archivo de parámetro (INIT.ora) para retener los nuevos valores. Automáticamente serán almacenados en el SPFILE

El SPFILE nos da la oportunidad de trabajar con cambios dinámicos a los parámetros, es decir, que los cambios que se apliquen a los parámetros no se harán parte del SPFILE. Esto se logra mediante la cláusula SCOPE:
ALTER SYSTEM SET parameter_name=parameter_value  SCOPE {MEMORY | SPFILE}

Si es que se está utilizando un SPFILE es posible cargar un archivo INIT.ORA, especificando su ubicación en la cláusula STARTUP:
STARTUP PFILE=/home/oracle/init<SID>.ora

Desde la versión 9i Oracle provee una forma simple de migrar los parámetros existentes en un archivo INIT.ORA a un archivo binario SPFILE. Para esto se usa el siguiente comando:
CREATE SPFILE FROM PFILE=’/home/oracle/init<SID>.ora’

Hay que tener en cuenta que para hacer este procedimiento es necesario copiar el archivo INIT.ORA en el servidor

Entendiendo Oracle Data Pump

En este artículo vamos a tratar sobre la arquitectura de Oracle Data Pump de la versión 10g, y como se genera un trabajo Data Pump:

Primero unas características generales:
Data Pump es una utilidad del lado de servidor. Aunque el proceso de usuario es el encargado de inicializar un trabajo de Data Pump, son los procesos de servidor los que se encargan de ejecutar el trabajo; de esta manera los procesos de servidor tienen acceso directo al SGA y a los Datafiles, sin necesidad de ir por medio de una sesión.

• Se puede especificar el número de hilos de una ejecución activa que se ejecuta en nombre de un trabajo Data Pump, permitiendo al DBA ajustar el consumo de recursos vs tiempo restante (Esto solo está disponible en Oracle 10g Enterprise Ed)
• Se puede inicializar un trabajo de Data Pump y desconectarse dejándolo que se ejecute. Se puede volver a conectar en cualquier momento para monitorear el progreso del trabajo, sin que el proceso de desconexión afecte el trabajo
• Operaciones de Exportación e Importación pueden ser ejecutadas en un ambiente de red. La fuente de cada operación funciona como una instancia remota
•  En un trabajo de importación se puede cambiar el nombre del Datafile fuente a un nombre diferente en todos los DDL generados que se mencione el dicho Datafile 
• Hay un soporte mejorado al mapear tablespaces en una operación de importación
• Se puede filtrar los metadatos que son exportados o importados según objeto o tipo de objeto
• Permite cuanto espacio físico será necesario para una actividad de exportación, sin necesidad de ejecutarla
• Permite especificar la versión de los objetos de la base de datos a ser movidos
• Las operaciones de exportación e importación son creadas en el servidor de la base de datos, no en el cliente

El trabajo Data Pump

Un trabajo de Data Pump involucra procesos, dos colas de trabajo, 3 tipos de archivos y las tablas.

• Procesos:
  Hay 2 procesos: expdp e impdp que son procesos de usuario para iniciar, controlar y monitorear los trabajos de Data Pump. Estos procesos establecen sesiòn contra la base de datos a través de procesos de servidor normales (los mismos utilizados para establecer sesiones de usuario). Esta es la sesión que controlará y monitorerá el trabajo Data Pump
  Cuando un trabajo Data Pump es lanzado, se inician los siguientes procesos: Data Pump Master Process (DMmn) y uno o más Worker Process (DWnm) que son controlados por el Master Process. Por cada trabajo Data Pump tendrá sus respectivos procesos Master y Workers
• Colas:
  Un trabajo Data Pump crea dos colas. Una de Control y una de Estatus: La cola de Control almacena las tareas individuales que tienen que hacer los procesos Worker. El master process divide un trabajo en tareas individuales que son ejecutadas por los procesos Worker; esta cola almacena las tareas en forma FIFO. Los procesos worker recojen de esta cola solo una tarea.  La cola de Estatus  se utiliza para monitorear: Almacena mensajes que describen el estado del trabajo. Estos mensajes son enviados por el Master Process. Cualquier sesión puede (Con sus privilegios asociados) puede consultar esta cola para monitorear el trabajo
• Archivos:
  Los archivos generados por Data Pump vienen en tres formas: archivos SQL, archivos Dump y archivos de log. Los archivos SQL incluyen sentencias DDL que describen los objetos incluidos en el trabajo. Los archivos Dump contienen los datos exportados en formato XML. Para finalizar, los archivos de log incluyen un historial de todo el trabajo

Consideraciones para un DBA – Parte III

Continuando con nuestras consideraciones a tener en cuenta para administrar una base de datos, tenemos:

• Las entidades lógicas de almacenamiento son Base de Datos – Tablespace – Segments – Extents – Blocks
• Automatic Segment Space Management controla que los blocks sean reutilizados después de que filas hayan sido eliminadas; Manual Segment Space Management tiene que ser utilizada con los parámetros freelist, pctfree, pctused
• Un tablespace puede ser eliminado junto a su contenido y los datafiles dentro de él especificando INCLUDING CONTENTS AND DATAFILES en la sentencia DDL
• Una base de datos Oracle 10g consiste de Datafiles, Control Files, Redolog Files, SPFILE y a diferencia de versiones anteriores, de Temp Files
• No es recomendable el uso de índices Bitmap en tablas que sean actualizadas frecuentemente
• Los nombres para las columnas de una tabla deben empezar con una letra, y pueden contener números, letras y estos caracteres especiales _$#
• Cuando se define una Primary Key Constraint en una columna, tambièn implica que se define una NOT NULL Constraint y una UNIQUE Constraint adicionales
• Toda base de datos Oracle 10g tendrá un SYSAUX tablespace y se creará automáticamente con el comando CREATE DATABASE o al migrar a la versión 10g.
• Es altamente recomendable que toda base de datos 10g tenga un UNDO tablespace (este a diferencia del SYSAUX no se crea automáticamente)
• Un datafile no puede abarcar diferentes tipos de sistema de archivos (File system). Por el contrario, un tablespace si puede abarcar múltiples sistemas de archivos pero teniendo un datafile en cada uno
• Una vista no almacena datos independiente de la tabla base sobre la que se construyó. Simplemente es una tabla virtual que se basa en una consulta SQL

Consideraciones para un DBA – Parte II

Continuando con unas breves consideraciones para un DBA tenemos:

• Para poner a la base de datos en modo ARCHIVELOG es necesario tener el privilegio SYSDBA
• El asistente de creación de bases de datos DBCA automáticamente crea 3 copias multiplexadas del Control File
• Oracle recomienda tener al menos dos miembros por cada grupo de Redo Log Files
• Oracle 10g soporta hasta 5 niveles de backups incrementales
• Para saber si la base de datos está en modo ARCHIVELOG se usa la vista dinámica V$DATABASE
• El área donde se almacenan unificadamente todos los archivos relacionados con actividades de recuperación es el Flash Recovery Area
• La vista dinámica que contiene información sobre las cuotas, uso, estatus, y número de archivos en el Flash Recovery Area es V$RECOVERY_FILE_DEST
• 8. El tipo de dato DATE incluye dos partes: dia-mes-año y hora-minuto-segundo
• El nùmero máximo de datafiles que puede tener un tablespace tipo SMALLFILE es 1022
• Un tablespace tipo BIGFILE solo puede tener 1 solo datafile

Sesiones de Usuario con Oracle Shared Servers

Shared Server es un mecanismo que permite establecer sesiones de usuario contra el Servidor de una manera mucho más efectiva para el rendimiento de la base de datos. En este artículos vamos a ver como Oracle administra las sesiones de usuario con si tiene configurado Shared Server

Primero hay que definir los nuevos componentes que utiliza esta arquitectura: La instancia tiene dos nuevos procesos: Shared Servers y Dispatchers que son lanzados cuando se inicia la instancia. Además hay otras dos nuevas estructuras de memoria: Common Queue y Response Queue

• Los Shared Servers son procesos que reciben las sentencias SQL directamente desde el procesos de usuario (User Process). Compilan el código, ejecutan y generan un set de resultados para las sentencias SQL recibidas
• Los Dispatchers son procesos TCP que se ejecutan en un único puerto TCP. Se contanctan con el Listener y lo registran de tal manera que sirve como un medio para transmitir las peticiones de usuario al Common Queue
• El Common Queue es una estructura de memoria localizada en el SGA que almacena todas las peticiones de usuario que pasan por los dispatcher y que están a la espera de ser procesados por los Shared Servers
• El Response Queue es otra estructura de memoria localizada en el SGA que almacena el set de resultados procesado por los procesos Shared Servers y que esperan ser dirigidos al proceso de usuario que realizó la petición, mediante su Dispatcher

Hay que entender que en este tipo de arquitectura el listener funciona diferente: Cuando llega una nueva petición de conexión, el listener no dispara un proceso de servidor dedicado (Server Dedicated Process) sino que, mediante un listado de todos los dispatchers disponibles para cada servicio junto al número de conexiones concurrentes para cada dispatcher, el listener enruta la petición de conexión al dispatcher con la menor carga. De esta manera el usuario se mantiene conectado al mismo dispatcher durante toda la sesión.

Ahora vamos a ver como es el proceso como tal:

1. El user process redirecciona la petición de conexión hacia su dispatcher
2. El dispatcher posiciona la petición en el Common Queue del SGA (Las peticiones son procesadas en base FIFO)
3. El próximo Shared Server disponible toma la petición del Common Queue y la procesa
4. Después de procesar, el Shared Server llama al Response Queue del Dispatcher con el que está conectado la sesión,  toma el set de resultados y lo envía al a dicho Response Queue
5. El Dispatcher toma el set de resultados desde su respectivo Response Queue
6. El Dispatcher envía el resultado al User Process

Hay que tener en cuenta ciertas consideraciones:

• El Common Queue es compartido por todos los Dispatchers
• Cada Dispatcher tiene su propio Response Queue
• Los Shared Process están monitoreando contínuamente el Common Queue en busca de nuevas peticiones
• Las estructuras de memoria almacenadas en el PGA en la arquitectura dedicada es ahora almacenada en el SGA

Consideraciones para un DBA – Parte I

A continuación voy a listar un top X (la verdad X porque no se cuantas saldrán en total) de las consideraciones y conceptos básicos que debe tener un DBA para gestionar su base de datos 10g. Muchas de esas son básicas pero hay que tener en cuenta que al administrar nuestra infraestructura podemos olvidar ciertos criterios:

• En Oracle 10g deben haber al menos 2 copias del control file, sin embargo Oracle recomienda 3 copias
• Los archived log files pueden ser escritos hasta en 10 locaciones, ya sean local o remotas
• El número de archivos en el Flash Recovery Area está disponible solo la vista dinámica de rendimiento V$RECOVERY_FILE_DEST
• Una instancia de Orale falla al iniciar si una copia multiplexada del Control File está perdida
• El uso de Redo Logs asegura que transacciones realizadas COMMIT no se pierdan
• Offline Backups son conocidos también como Backups «Consistentes»
• El problema más serio de relacioando con una falla de media (Media Failure) es la pérdida de un grupo entero de Redo Log Files
• DB_RECOVERY_FILE_DEST es el parámetro de inicialización que controla la ubicación por defecto de los archived log files

Paradigma Cliente/Servidor en Oracle

Para entender como implementar una infraestructura de red con un servidor Oracle es necesario entender como Oracle establece su paradigma Cliente/Servidor. Entender que procesos están involucrados durante el proceso y como interaccionan entre sí y con sus respectivos componentes. En este artículo vamos a detallar como Oracle trabaja con este paradigma.

Primero hay que entender que en el ambiente de Oracle existen algunas capas entre el usuario y la base de datos. El usuario no tiene acceso directo a la base de datos, ni el proceso que él está ejecutando.  El acceso a los datos es controlado por el servidor.

El usuario interactúa con su respectivo Proceso de Usuario que procesa las sentencias SQL que el usuario genera (mediante código directo, aplicación, ODBC driver, librerías OCI, etc). Por otro lado, el Proceso de Servidor está ejecutándose físicamente en la máquina que hace de servidor o host de la base de datos y es este proceso que ejecuta las sentencias SQL recibidas por el proceso de usuario mediante el ciclo parse/bind/execute/fetch.

• En la fase de parse el proceso de servidor analiza e interpreta la sentencia SQL. Trabaja directamente con el Shared Pool para convertir el código obtenido en algo que sea ejecutable
• En la fase de bind  todas las variables son asignadas a un valor literal
• En la fase de execute los datos en el Database Buffer Cache serán leídos y actualizados y los cambios escritos en el Redo Log Buffer. (Si los bloques necesarios no están en el Database Buffer Cache el Proceso de Servidor los leerá desde los Datafiles)
• En la fase de fetch  se envía el resultado de la sentencia SQL al Proceso de Usuario

Oracle Net provee un mecanismo para lanzar un proceso de servidor que responda a la ejecución de código solicitada por un proceso de usuario; esto es lo que define como una sesión.

Paradigma Cliente Servidor