Archivo
Tareas programadas en entornos Oracle
En varias ocasiones he encontrado clientes con dudas sobre cómo se ejecutan las tareas programadas en sus sistemas Oracle (BBDD y servidores). No tienen claro quién es el responsable de su programación y ejecución, y esto puede ser un problema en caso de tener que modificarlas o desactivarlas.
A grandes trazos, podemos ejecutar tareas de 4 formas:
- Sistema operativo
- Tareas de la consola de administración
- Jobs de BBDD
- Scheduler de BBDD
Sistema operativo
Podemos programar tareas desde sistema operativo mediante el “crontab” en entornos Unix/Linux o el “Programador de tareas” en Windows.
Es bueno saber que en el caso concreto de los entornos Linux las tareas programadas en el crontab se almacenan de manera particular para cada usuario (cada uno puede tener las suyas) y, además, existen unos directorios de cron “horario”, “diario” y “mensual” en los que si dejamos algún script se ejecutará en esos intervalos de tiempo.
Tareas de la consola de administración
Podemos programar tareas desde la DBConsole o el Enterprise Manager/Grid Control, almacenándose en la BBDD de repositorio de estos productos. Pueden realizar tareas de todo tipo, sobre diferentes objetivos locales y remotos, hosts, BBDD, Servidores de Aplicaciones… (en el caso de objetivos remotos mediante agentes y solo en el caso del EM/GC).
Es bueno saber que estas tareas pueden generar confusión en el caso de la DBConsole, ya que en muchos casos se confunden con tareas de BBDD. Si por ejemplo programamos una “Tarea de Backup de BBDD” desde la DBConsole, se programará como una tarea de consola y solo podremos controlar su ejecución y logs desde la misma, además no se ejecutará si la consola está parada. En la siguiente imagen podemos ver el link de las tareas programadas en la DBConsole:
Jobs de BBDD
Estas eran las tareas típicas de BBDD hasta la versión 9.2. Consisten en un programador “simple” que permite ejecutar código PL/SQL o SQL de manera repetitiva a ciertos intervalos. Podemos programar estas tareas mediante el paquete de PL/SQL DBMS_JOB y controlar las tareas que tenemos programadas en la tabla DBA_JOBS (las que están en marcha en DBA_JOBS_RUNNING).
Es bueno saber que si el código programado no finaliza correctamente la tarea se intentará repetir a intervalos de tiempo que se irán doblando en cada iteración (en 1 minuto, en 2 minutos, en 4 minutos… hasta llegar al tiempo programado de la próxima ejecución “normal” prevista), al llegar a los 16 intentos la tarea se marcará como “broken” y no se repetirá. Esto es importante si tenemos una tarea que realiza ciertas modificaciones parciales antes de fallar, ya que estas modificaciones parciales se podrían repetir múltiples veces.
Otro detalle interesante es que podemos decidir cuántas tareas se pueden ejecutar simultáneamente (o parar completamente la ejecución de tareas) mediante el parámetro de inicialización “JOB_QUEUE_PROCESSES”, este parámetro es dinámico (lo podemos cambiar sobre la marcha sin parar el gestor). Por ejemplo si lo definimos a cero dejan de ejecutarse tareas mediante el sistema de JOBS.
Scheduler de BBDD
Finalmente tenemos el “SCHEDULER”, un sistema avanzado de programación de tareas aparecido en la versión 10g de la BBDD y que se ha ampliado y mejorado en versiones posteriores. Podemos crear una biblioteca de tareas, lanzar scripts de sistema operativo, crear cadenas de trabajos, ejecuciones condicionadas a eventos, ventanas de ejecución, vincular tareas al gestor de recursos, etc. En resumen, mucho más potente que el anterior sistema de jobs.
Se pueden programar las tareas mediante el paquete DBMS_SCHEDULER o desde el apartado de tareas de la BBDD en la DBConsole o en el EM/GC. Este es el sistema recomendado para programar tareas en las BBDD 10g y superiores.
En la siguiente imagen tenéis el resumen de componentes que forman el scheduler y sus relaciones:
Es bueno saber que si nos interesa arrancar la BBDD sin que se ejecute ningún job del scheduler, y estamos en versión 11.2, podemos definir a cero el parámetro job_queue_processes ya que en esta versión no solo desactiva los DMB_JOBS sino también los trabajos del scheduler. Para otras versiones tendremos que arrancar la BBDD en modo MIGRATE o UPGRADE y ejecutar el siguiente código:
exec dbms_scheduler.set_scheduler_attribute(‘SCHEDULER_DISABLED’,'TRUE’);
En la siguiente imagen tenéis la entrada de la DBConsole correspondiente a la programación de tareas en el Scheduler:
Volver a sincronizar esquemas o tablas en Oracle GoldenGate
En ocasiones en nuestras instalaciones de GoldenGate nos podemos encontrar con esquemas o tablas que quedan fuera de sincronía con el resto. Esto puede ser a causa de problemas que nos obligan a “saltar” ciertas transacciones o incluso a eliminar esquemas de la configuración de réplica para que ésta pueda continuar.
En esta entrada explicaremos como recuperar estos usuarios o tablas que han dejado de estar sincronizados sin tener que cargar nuevamente todos los esquemas o tablas de la réplica.
Usaremos dos sistemas, el primero disponible en todas las versiones de GoldenGate y tipos de BBDD y el segundo específico para GoldenGate 11.1.1 o superior y BBDD Oracle.
En ambos casos partiremos de un proceso EXTRACT que captura los datos en una BBDD origen y otro proceso REPLICAT que los entrega en una BBDD Destino.
Integración de EXADATA en Cloud Control 12c
En esta entrada del blog intentaré describir las opciones que tenemos para configurar la monitorización de una Database Machine (o como la llamaremos en adelante “Exadata”) mediante la última versión de la consola de administración de Oracle, el Cloud Control 12c.
Instalacion del Cloud Control 12c
En primer lugar es necesario disponer del Cloud Control 12c operativo para poder integrar en él al Exadata; para ello podemos usar un Cloud Control 12c del que ya dispongamos o proceder a instalar uno nuevo.
Podemos usar una versión “paquetizada” del Cloud Control 12c, especial para Exadata y que permite instalar todos sus componentes con un solo comando.
Parche 13546881
O instalar normalmente el Cloud Control 12c, obteniendo la versión genérica de éste.
La primera opción es interesante por su simplicidad, pero nos encontraremos con un Cloud Control 12c pensado sólo para Exadata. Mediante la segunda, si bien requiere más pasos de instalación (tampoco muchos más, no creáis) tendremos un Cloud Control 12c completo en el que podremos administrar y monitorizar todos los productos Oracle y no Oracle de nuestra empresa.
En caso de querer disponer el Cloud Control 12c completo, podemos encontrar las instrucciones y el software necesario en la siguiente dirección:
http://www.oracle.com/technetwork/oem/grid-control/downloads/index.html
Despliegue del agente de Cloud Control 12c
Bien, supongamos que ya tenemos el Cloud Control 12c; el primer paso para integrar un servidor (o servidores) Exadata es instalar los agentes.
La instalación se realiza desde uno de los nodos de BBDD y a partir de ese nodo se distribuirá de manera automática al resto de nodos (tanto de BBDD como de almacenamiento). Esto es especialmente importante en el caso de los servidores de almacenamiento, en los que no podemos instalar ningún tipo de software por nuestra cuenta.
En primer lugar nos bajamos el paquete de despliegue de agentes:
“Oracle Enterprise Manager Cloud Control 12c Setup Automation kit for Exadata” correspondiente al patch 12960596
Lo copiamos a uno de los nodos de BBDD a la carpeta /tmp/emkit y descomprimimos
Del export/import a Oracle Data Pump
Desde la versión 10gR1 de Oracle Database disponemos de una nueva herramienta para la carga/descarga de datos en formato nativo Oracle: Oracle Data Pump.
Es importante entender cómo funciona Oracle Data Pump, ya que ha sufrido grandes cambios si lo comparamos con el export/import tradicional, en concreto, ha pasado de ser una herramienta cliente a ser un trabajo en el servidor.
En esta entrada de blog intentaré aclarar en especial este punto, que creo, es el más difícil de entender al enfrentarse por primera vez a esta herramienta.
Al hablar de Data Pump en ningún caso digo “nueva herramienta”, ya que hace ocho años que la tenemos disponible (como ya he dicho desde la versión de BBDD 10gR1 en el 2003), pero para mi sorpresa mucha gente la sigue usando como si del export/import se tratara (cuando no usan directamente el export/import).
Otro punto a tener en cuenta es que el export/import está ya fuera de soporte. Esto implica que no deberíamos usar el export/import en nuestras BBDD 10g/11g, entre otras cosas porque no soportan (ni soportarán) los nuevos formatos de datos que han aparecido en estas versiones del gestor, y que tampoco podremos abrir casos de soporte para ellos en 10g/11g.
De todos modos, los binarios del export/import siguen estando presentes en las BBDD 10g y 11g para permitirnos migrar datos desde BBDD de versiones inferiores (por ejemplo de una 9i a una 11g). Esto es así porque los ficheros generados por el export/import no son validos para Oracle Data Pump y los de Data Pump tampoco lo son para export/import.
Operaciones de “FLASHBACK” en Oracle Database
Desde la versión 9i del gestor se han introducido funcionalidades en la BBDD, que para muchos de sus usuarios no dejan de ser sorprendentes. Una de ellas es la “Flashback Query” que nos permite realizar “selects” que muestren los valores que existían en la BBDD en un momento anterior en el tiempo. En este post os explicaré esta funcionalidad juntamente con algunas relacionadas y trucos interesantes asociados a ella.
Además intentaré contestar a las preguntas más frecuentes que me hacen los clientes a los que muestro alguna de estas funcionalidades por primera vez…
Empecemos, primero os describo un poco las diferentes opciones de “Flasback” de que disponemos en una BBDD 11gR2 (en versiones anteriores es posible que sólo se disponga de un subconjunto de éstas):
Flashback Query
Nos permite ver los datos de la tabla en un momento del pasado. Con esta técnica podremos acceder a datos borrados o modificados por error.
Se basa en los datos de UNDO y por tanto lo tenemos activo “por defecto” en cualquier BBDD de cualquier versión (XE, Standard Edition o Enterprise Edition).
Flashback Version Query
Nos permite ver el histórico de cambios en una tabla, que modificaciones se han ido realizando en los datos durante un periodo de tiempo de manera ordenada para poder “deshacer” sólo algunos de ellos.
Se basa en los datos de UNDO y lo podremos usar en cualquier BBDD Oracle Enterprise Edition.
Traspaso inicial de datos con Oracle GoldenGate
Oracle GoldenGate es una herramienta de replicación de datos entre entornos heterogéneos. Permite configurar soluciones de alta disponibilidad, de integración de datos o de réplica en tiempo real.
Para los que desconozcáis este producto, os recomiendo visitar esta entrada del blog y, en especial, ver la presentación que lo acompaña.
En la entrada de hoy comentaré una parte de la configuración de GoldenGate que no aparece en la mayoría de ejemplos existentes en la Web: el traspaso inicial de datos.
Al configurar una réplica con GoldenGate lo más común es que en el entorno de destino no dispongamos de datos, por lo que como paso previo a la réplica deberemos traspasar los datos para posteriormente poder empezar a traspasar únicamente los cambios. A este proceso lo llamamos la “carga inicial”.
Las cargas iniciales normalmente tienen como hándicap que el origen de datos se mantiene activo, esto es, se siguen generando cambios durante el proceso de carga inicial de datos.
Tenemos varias opciones para realizar esta tarea:
- Carga de datos en formato nativos con utilidades de la BBDD
En este caso replicaríamos la BBDD mediante las herramientas nativas de las que se disponga. En caso de Oracle podría ser desde una recuperación mediante RMAN (completa o Tablespace Point In Time Recovery) o mediante expdp/impdp.
Deberemos tener arrancado un proceso de EXTRACT/REPLICAT que controlará los cambios realizados durante el tiempo que dure la carga inicial y que posteriormente los aplicará en destino.
¿Tengo que instalar los “Oracle Critical Patch Update” en mis entornos?
Periódicamente (en la actualidad cada tres meses) Oracle envía a sus clientes notificaciones de la salida de los “Critical Patch Updates“:
La mayoría de clientes se preguntan si deben instalar estos parches en sus entornos y qué ventajas/inconvenientes tendrían en caso de hacerlo.
Cluster Activo/Pasivo cruzado de BBDD y Weblogic con Oracle Clusterware
Hoy os hablaré de la configuración de entornos Activo/Pasivo “cruzados” de Weblogic y BBDD. Esta configuración usa el software de cluster Oracle Cluster Ready Services 11gR1 para mantener los servicios de WebLogic (sean aplicaciones Java o Forms/Reports) activos en un nodo y la BBDD en el otro. En caso de caída de uno de los nodos los servicios que se ejecutaban en éste pasan a ejecutarse en el nodo superviviente, todo de manera automática.
Un ejemplo lo tenemos en la siguiente imagen. Existen dos servidores conectados a una cabina de discos, en el primero se ejecuta “por defecto” Weblogic y tiene asignado un disco, en el segundo se ejecuta “por defecto” la BBDD y tiene dos discos asignados. Existen también IP’s virtuales que están asignadas a Weblogic y a la BBDD respectivamente. Los servicios pueden moverse automáticamente de un servidor a otro en caso de problemas en uno de ellos, o manualmente (para realizar tareas de mantenimiento en uno de los servidores por ejemplo).
Los recursos de IP virtual son usados para que los clientes no deban preocuparse de en qué nodo está el producto, siempre pueden acceder a él por la misma IP/nombre.
Leer más…
Oracle y VMware: ¿amigos o enemigos?
En esta entrada de blog intentaré aclarar el estado en que se encuentra la combinación de Oracle y VMware a fecha de hoy y describir lo que personalmente creo será el futuro de esta combinación de tecnologías.
En el primer punto, que dividiré en “estado de soporte” de la combinación y “requerimientos de licenciado”, intentaré ser lo más simple y neutral posible, basándome únicamente en lo que ambas empresas (Oracle y VMware) han publicado al respecto.
El segundo punto será justo lo contrario, fruto de opiniones tanto personales como recogidas por la red… por lo que será totalmente discutible.
Nota: Téngase en cuenta que toda la información aquí presentada ha sido recopilada con fecha 22-11-2010, y que en el momento de la lectura de este post se podrían haber producido cambios de política o estrategia por parte de Oracle.
Evitar errores de “tabla mutante” en Oracle Database
Hace poco me preguntaron en un cliente cómo podían evitar la aparición del error:
ORA-04091: table xxx.yyyy is mutating, trigger/function might not see it
Primero os comento un poco qué es una “tabla mutante“. Se considera “mutante” una tabla que está siendo modificada, por ejemplo la tabla sobre la que el propio trigger se ha disparado por causa de un update/insert/delete.
O lo que es lo mismo, dentro de un trigger no podemos hacer referencia a la misma tabla que lo ha disparado, ya que, al estar siendo modificada, Oracle no puede asegurar una visión “consistente” de sus datos. En caso de hacerlo aparece este error.
Correcto, ¿y qué podemos hacer? Pues hay varias soluciones:
Hasta la versión 10gR2 podíamos:
Cambiar el código y no usar triggers: Podría ser que se pudiese solucionar modificando el diseño del modelo de datos o reprogramando una parte del codigo.
Usar un trigger “AFTER”: En “AFTER” los cambios en la tabla ya estan “consumados” y podemos acceder a una visión “consistente” de ésta.
Usar “PRAGMA AUTONOMOUS_TRANSACTION”: Nuestro trigger se ejecuta en una transacción diferente, y por tanto vemos la tabla en modo “consistente”. No es muy recomendable usar este sistema, ya que por ejemplo:
- Si queremos realizar varios cambios seguidos dentro de la misma transacción no tendremos acceso a ellos (es una transacción diferente cada vez)
- O si el trigger falla y se hace rollback tampoco nos enteraremos (no deshará la transacción en que se ha disparado el trigger)
A partir de la versión 11gR1, a las anteriores opciones podemos añadir:
Usar “COMPOUND TRIGGERS”: En la versión 11gR1 ha aparecido un nuevo tipo de trigger llamado “Compound Triggers“. En estos triggers podemos realizar cálculos previos para definir un “estado” que después es accesible durante la ejecución del trigger.
En resumen, que los cálculos que queramos hacer sobre la tabla afectada por el trigger los haremos previamente, guardando los valores necesarios en variables a las que accederemos posteriormente (evitando el acceso directo a la tabla y por tanto el problema). No nos soluciona todos los casos de tablas mutantes pero sí una parte importante de ellos.
El ejemplo que viene en la documentación es bastante bueno, por lo que os lo referencio directamente: Example 9-4 Compound Trigger that Avoids Mutating-Table Error
PD: No dejéis de estudiar qué otras ventajas ofrecen los “compound triggers”, pues la solución a las tablas mutantes sólo es una consecuencia de sus funcionalidades 
Nuestra red social |
|
|
