Acerca de admin

Tras más de 20 años trabajando con tecnologías Oracle, me decidí a recopilar en un Blog algunas de las cosillas útiles para el día a día.

Como limpiar datapump fallidos ORA-31633

Hoy vamos a ver como solucionar el problema de relanzar algunos datapumps fallidos cuando nos devuelven el error ORA-31633

Una de las principales diferencias entre el export tradicional y el nuevo expdp es que el expdp crea un job en la base de datos que es quien se encarga de la labor de sacar los datos.

Cuando detenemos esta exportación de manera no controlada, puede ser que la definición del trabajo creada por el export quede dentro de la base de datos, con lo que, al volver a lanzar el trabajo del export recibamos un error «ORA-31633: unable to create master table XXX»

ORA-31626: job does not exist
ORA-31633: unable to create master table "SYSTEM.EXPORT_DIAR"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPV$FT", line 863
ORA-01031: insufficient privileges

Para solucionar este problema, lo primero que tenemos que hacer es comprobar que trabajos no se encuentran en estado RUNNING


SET lines 200
SELECT owner_name, job_name, operation, job_mode,
state, attached_sessions
FROM dba_datapump_jobs
ORDER BY 1,2;

Esta consulta nos devuelve la informacion de los trabajos de datapump que hay en la base de datos, el resultado es una tabla del tipo

OWNER_NAME JOB_NAME            OPERATION JOB_MODE  STATE       ATTACHED
———- ——————- ——— ——— ———– ——–
SCOTT      EXPORT_TABLA_1 EXPORT    TABLE     NOT RUNNING        0
SYSTEM     EXPORT_DIARIA  EXPORT    FULL      NOT RUNNING        0

Aquí podemos ver como tenemos dos trabajos, uno del usuario SCOTT y otro de SYSTEM que están en estado NOT RUNNING, con lo que podemos eliminarlos.

Ahora buscaremos cual es la «master table» del job con la consulta

SELECT o.status, o.object_id, o.object_type,
       o.owner||’.'||object_name “OWNER.OBJECT”
  FROM dba_objects o, dba_datapump_jobs j
 WHERE o.owner=j.owner_name AND o.object_name=j.job_name
   AND j.job_name NOT LIKE ‘BIN$%’ ORDER BY 4,2;

STATUS   OBJECT_ID OBJECT_TYPE  OWNER.OBJECT
——- ———- ———— ————————-
VALID        15223 TABLE        SCOTT. EXPORT_TABLA_1
VALID        15293 TABLE        SYSTEM.EXPORT_DIARIA

Ahora podemos eliminar las tablas de los trabajos con la consulta.

SQL> DROP TABLE SCOTT. EXPORT_TABLA_1;
SQL> DROP TABLE SYSTEM.EXPORT_DIARIA;

Con esto habremos limpiado la tabla de los jobs del datapump, con lo que podremos volver a lanzar nuestro script sin problemas

Problemas con SYSAUX, ocupación de AWRs

Hoy vamos a lidiar con un problema muy común en las bases de datos de Oracle que es el tamaño del tablespace SYSAUX.
El tablespace SYSAUX es uno de los tablespaces especiales de la base de datos con el que no podemos jugar alegremente, la principal característica que tiene de cara a la administración de base de datos es que ,el espacio que le demos se ha perdido, es decir, no va ha haber forma de hacerlo mas pequeño (al menos en mi caso siempre ha habido un «pero» que lo imposibilita).

Como decía al principio es junto con el SYSTEM un tablespace muy especial, y los motivos de su tamaño pueden ser varios,hoy vamos a centrarnos en como vaciar un poco el tamaño debido el AWR.

Lo que, lo primero que tendremos que hacer es ver cual es el componente que esta llenándonos el tablespace.
Para ello tenemos la consulta

set linesize 100;
column OCCUPANT_NAME format a20;
column OCCUPANT_DESC format a60;
column Mb format 999.99
SELECT occupant_name,space_usage_kbytes/1024 Mb,occupant_desc
  FROM V$SYSAUX_OCCUPANTS
  order by space_usage_kbytes  desc;

OCCUPANT_NAME             MB OCCUPANT_DESC
-------------------- ------- ------------------------------------------------------------
SM/AWR                780.06 Server Manageability - Automatic Workload Repository
SM/OPTSTAT            333.00 Server Manageability - Optimizer Statistics History
LOGMNR                 91.63 LogMiner
XDB                    85.50 XDB
SM/ADVISOR             65.56 Server Manageability - Advisor Framework
WM                      6.38 Workspace Manager
SM/OTHER                6.25 Server Manageability - Other Components
SMON_SCN_TIME           5.31 Transaction Layer - SCN to TIME mapping
EXPRESSION_FILTER       3.88 Expression Filter System
JOB_SCHEDULER           2.81 Unified Job Scheduler
EM_MONITORING_USER      2.75 Enterprise Manager Monitoring User
SQL_MANAGEMENT_BASE     1.69 SQL Management Base Schema
PL/SCOPE                1.56 PL/SQL Identifier Collection
XSOQHIST                1.38 OLAP API History Tables
AO                      1.38 Analytical Workspace Object Table
LOGSTDBY                1.38 Logical Standby
STREAMS                 1.00 Oracle Streams
AUTO_TASK                .31 Automated Maintenance Tasks
ORDIM/ORDDATA            .00 Oracle Multimedia ORDDATA Components
ORDIM/ORDPLUGINS         .00 Oracle Multimedia ORDPLUGINS Components
ORDIM/SI_INFORMTN_SC     .00 Oracle Multimedia SI_INFORMTN_SCHEMA Components
HEMA
EM                       .00 Enterprise Manager Repository
TEXT                     .00 Oracle Text
ULTRASEARCH              .00 Oracle Ultra Search
ORDIM                    .00 Oracle Multimedia ORDSYS Components
SDO                      .00 Oracle Spatial
STATSPACK                .00 Statspack Repository
TSM                      .00 Oracle Transparent Session Migration User
XSAMD                    .00 OLAP Catalog
AUDIT_TABLES             .00 DB audit tables
ULTRASEARCH_DEMO_USE     .00 Oracle Ultra Search Demo User

Como podemos ver, son muchas las cosas que se guardan en SYSAUX, pero, en nuestro caso, está bastante claro que, la mayoría de la ocupación es debida a los AWR.

Nuestro siguientes pasos van a ser:

  • Determinar que es lo que nos ocupa el espacio
  • Mirar si la causa esta en la retención
  • Mirar si la causa está en los AWR guardados
  • Mirar si la causa está en las lineas «huerfanas» de las Active Session History

Nuestro objetivo va a ser liberar espacio dentro de SYSAUX , no disminuir el tamaño de este tablespace ya que, como decía al principio esto es prácticamente una misión imposible.

Determinar que es lo que ocupa espacio

El siguiente paso será el buscar la información del AWR, para ello el propio Oracle tiene una utilidad que podemos llamar desde sqlplus

 SQL> @$ORACLE_HOME/rdbms/admin/awrinfo.sql

Este sql nos genera un informe con unos apartados muy interesantes que nos servirán para encontrar de donde liberar espacio.

Mirar si la causa esta en la retención

************************************                                                                         
(2) Size estimates for AWR snapshots                                                                          
*************************************                                                                                                                                                                                    
| Estimates based on 60 mins snapshot INTERVAL:                                                               
|    AWR size/day                           31.0 MB (1,324 K/snap * 24 snaps/day)                             
|    AWR size/wk                           217.2 MB (size_per_day * 7) per instance                                                                                                                                     
| Estimates based on 24 snaps in past 24 hours:                                                               
|    AWR size/day                           31.0 MB (1,324 K/snap and 24 snaps in past 24 hours)              
|    AWR size/wk                           217.2 MB (size_per_day * 7) per instance                           
|

Aqui podemos ver el tamaño estimado que ocupa nuestra información de los AWR, en función del periodo de retencion que tengamos de los AWR tendremos la ocupación en la base de datos.
Cuando sabemos cuanto ocupa cada AWR y cuanto hacemos al día, tenemos que saber cuantos dias guardamos para ver si la ocupación es correcta, para ello haremos :

SQL> SELECT retention FROM dba_hist_wr_control;

RETENTION
---------------------------------------------------------------------------
+00007 00:00:00.0

En mi caso por ejemplo, la retencion es de 7 días.

Mirar si la causa está en los AWR guardados

Otro de los problemas que podemos tener es que el número de AWR que mantenemos guardados por razones históricas en la instancia, en el informe que acabamos de obtener también aparece un apartado con las últimas 50 snapshots de la base de datos, el eliminar imágenes antiguas también nos ayudará a liberar espacio.

  • Mirar si la causa está en las lineas «huerfanas» de las Active Session History
  • Algunas veces el Active Session History (ASH) guarda filas que no pertenecen a ningún AWR,esto hace que el ASH ocupe gran parte del espacio dedicado al AWR, la forma de saber si esto nos está sucediendo es mirar nuestro informe en el apartado

    
    **********************************
    (3a) Space usage by AWR components (per database)
    **********************************
    
    COMPONENT        MB  % AWR  KB_PER_SNAP MB_PER_DAY MB_PER_WEEK TABLE% : INDEX%                                
    --------- --------- ------ ------------ ---------- ----------- ----------------                               
    FIXED         131.5   50.6          670       15.7       109.9    52% : 48%                                   
    EVENTS         37.9   14.6          193        4.5        31.7    43% : 57%                                   
    SQLPLAN        25.0    9.6          127        3.0        20.9    72% : 28%                                   
    ASH            18.3    7.0           93        2.2        15.3    89% : 11%                                   
    SQL            11.0    4.2           56        1.3         9.2    60% : 40%                                   
    SPACE          10.3    4.0           53        1.2         8.6    61% : 39%                                   
    SQLTEXT         5.2    2.0           26        0.6         4.3    96% : 4%                                    
    SQLBIND         0.8    0.3            4        0.1         0.6    50% : 50%                                   
    RAC             0.6    0.2            3        0.1         0.5    50% : 50%                                   
    

    Si la línea de ASH ocupa mas de un 1% probablemente sea la causa de nuestra ocupación.
    Mediante la siguiente consulta podemos saber si es nuestro caso.

    SELECT COUNT(*) huerfanas
    FROM wrh$_active_session_history a
    WHERE NOT EXISTS
      (SELECT *
      FROM wrm$_snapshot
      WHERE snap_id       = a.snap_id
      AND dbid            = a.dbid
      AND instance_number = a.instance_number
      );
    
    
     HUERFANAS
    ----------
           116
    
    

    Si aparece alguna línea podemos borrarlas con

    delete  
    FROM wrh$_active_session_history a
    WHERE NOT EXISTS
      (SELECT *
      FROM wrm$_snapshot
      WHERE snap_id       = a.snap_id
      AND dbid            = a.dbid
      AND instance_number = a.instance_number
      );
    

    Con estas tres acciones, si elproblema de laocupación del SYSAUX es debido a el AWR tendremos que haberpodido liberar el espacio suficiente para que la base de datos pueda seguir trabajando sin problemas de espacio.

    Aún así, el tema de la ocupación del SYSAUX es un tema bastante complejo, con lo que, como siempre, el mejor sitio para buscar soluciones es soporte de Oracle, aquí tenéis un pequeño listado de algunas de las notas que puede que os aplique y cuyo contenido tenéis en la página de soporte

    • AWR Data Uses Significant Space in the SYSAUX Tablespace [ID 287679.1]
    • Suggestions if your SYSAUX Tablespace grows rapidly or too large [Document 1292724.1]
    • General Guidelines for SYSAUX Space Issues [Document 552880.1]
    • SYSAUX Grows Because Optimizer Stats History is Not Purged [Document 1055547.1]
    • Space issue in Sysaux tablespace due to Unexpected AWR size [Document 1218413.1]
    • Space Management In Sysaux Tablespace with AWR in Use [Document 287679.1]
    • SYSAUX Tablespace Grows Heavily Due To AWR [Document 852028.1]

    O alguna entrada muy interesante en algunos blogs como es

    Why is my SYSAUX Tablespace so Big? Statistics_level=ALL

    Introduccion a los servicios de Oracle

    Uno de los elementos mas potentes que introdujo Oracle en la versión 10g fué el uso de servicios.
    Los servicios de Oracle no son otra cosa que una abstracción lógica de una instancia de base de datos. Aunque los servicios tienen mas sentido en entorno RAC, hoy vamos a ver como se configuran y para que pueden servir en un entorno de «single instance».

    Supongamos tenemos una base de datos produccion en la que tenemos consolidados 4 entornos distintos ( Webfotos,Cargas,Contabilidad y Desarrollo ) que acceden a nuestra instancia con el mismo esquema,y desde servidores de aplicaciones que comparten máquina entre ellos, en el momento en que la base de datos tiene problemas nos es muy difícil el saber quien es quien.
    Si pudiésemos discriminar las conexiones por una agrupación lógica, sería mas fácil el verlo, y , mas aún, si el EMC fuese capaz de separar las gráficas y estadísticas por esa agrupación.

    Pues esto es exactamente lo que nos proporcionan los servicios Oracle.
    En nuestro caso ficticio, vamos a crear los distintos servicios:

    • Webfotos
    • Cargas
    • Contabilidad
    • Desarrollo

    De esta forma, cada conexión de estos 4 entornos usara un service_name distinto en su TNS_NAMES de cliente, y , la base de datos podrá identificar ( y limitar) a cada uno de ellos de manera separada.

    Lo primero que tendremos que hacer es crear los servicios. Para esto tenemos dos maneras, o bien desde el srvctl ( en caso de RAC,Grid control u Oracle restart), o mediante el paquete DBMS_SERVICES , como nuestro caso es el de una «single instance», no nos va a quedar mas remedio que usar este paquete.
    Mediante la función CREATE_SERVICE crearemos los servicios de la manera:

    exec dbms_service.CREATE_SERVICE(SERVICE_NAME=>'webfotos', NETWORK_NAME=>'webfotos')
    exec dbms_service.CREATE_SERVICE(SERVICE_NAME=>'cargas', NETWORK_NAME=>'cargas')
    exec dbms_service.CREATE_SERVICE(SERVICE_NAME=>'contabilidad', NETWORK_NAME=>'contabilidad')
    exec dbms_service.CREATE_SERVICE(SERVICE_NAME=>'desarrollo', NETWORK_NAME=>'desarrollo')
    

    Una vez creados los servicios, los arrancaremos con la función

    exec dbms_service.START_SERVICE('webfotos')
    exec dbms_service.START_SERVICE('cargas')
    exec dbms_service.START_SERVICE('contabilidad')
    exec dbms_service.START_SERVICE('desarrollo')
    

    Para comprobar si la creación de nuestros servicios ha funcionado, podemos chequear el parámetro service_names

    SQL> select value from v$parameter where NAME='service_names';
    VALUE
    ---------------------------
    produccion,webfotos,cargas,contabilidad,desarrollo
    

    O bien el listener con lsnrctl services

    [oracle@blog] [$lsnrctl services
    
    LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 17-MAY-2013 13:31:06
    
    Copyright (c) 1991, 2011, Oracle.  All rights reserved.
    
    Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
    Services Summary...
    Service "PLSExtProc" has 1 instance(s).
      Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
        Handler(s):
          "DEDICATED" established:0 refused:0
             LOCAL SERVER
    Service "produccion" has 1 instance(s).
      Instance "XE", status READY, has 1 handler(s) for this service...
        Handler(s):
          "DEDICATED" established:34 refused:0 state:ready
             LOCAL SERVER
    Service "webfotos" has 1 instance(s).
      Instance "XE", status READY, has 1 handler(s) for this service...
        Handler(s):
          "DEDICATED" established:34 refused:0 state:ready
             LOCAL SERVER
    Service "contabilidad" has 1 instance(s).
      Instance "XE", status READY, has 1 handler(s) for this service...
        Handler(s):
          "DEDICATED" established:34 refused:0 state:ready
             LOCAL SERVER
    Service "desarrollo" has 1 instance(s).
      Instance "XE", status READY, has 1 handler(s) for this service...
        Handler(s):
          "DEDICATED" established:34 refused:0 state:ready
             LOCAL SERVER
    Service "cargas" has 1 instance(s).
      Instance "XE", status READY, has 1 handler(s) for this service...
        Handler(s):
          "DEDICATED" established:34 refused:0 state:ready
             LOCAL SERVER
    The command completed successfully
    

    Ahora, solamente tendremos que modificar los respectivos TNSNAMES de los distntos entornos para que se conecten mediante SERVICE_NAME y no mediante SID y tendremos identificados cada una de la sesiones de oracle con el servicio.

    ¿que beneficios nos aporta todo esto?

    • Trazabilidad: Nos va a ser sencillísimo encontrar quien es el que esta haciendo algo ya que en un primer vistazo encontraremos al culpable «logico» del problema, una vez tenemos el origen del problema es mas sencillo abordarlo.
    • Accounting: Vamos a poder ser capaces de ver los consumos de cada aplicacion/grupo lógico en la base de datos, lo que nos puede ser muy bueno a la hora de derivar costes o limitar recursos
    • control de accesos: Si en un momento específico queremos asegurarnos de que un elemento lógico no acceda a la aplicacion, podemos detener el servicio y el resto funcionaría correctamente.Esto puede ser muy útil por ejemplo, para evitar cargas en horario diurno, o para controlar los equipos de desarrollo

    Hasta ahora lo hemos visto todo muy fácil, pero .. ¿que ocurre cuando reinicias la base de datos?.
    Para que la instancia levante los servicios al arrancar deberán de estar en el init.ora con la sintaxsis:

    
    service_names='produccion','webfotos','cargas','desarrollo'
    

    Si no es así , cuando se levante nuestra base de datos no se levantan los servicios, y esto hace que no funcione nada de lo que apunta a ellos.
    La solución como os decía la principio es hacerlo desde el srvctl, pero …
    ¿como lo hacemos si no tenemos RAC,Grid u Oracle restart?
    La respuesta es brutalmente sencilla.

    [oracle@blog] [$sqlplus "/as sysdba"
    SQL*Plus: Release 11.2.0.2.0 Production on Vie May 17 13:09:11 2013
    Copyright (c) 1982, 2011, Oracle.  All rights reserved.
    
    Connected to:
    Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
    SQL> alter system set service_names='produccion,webfotos,cargas,contabilidad,desarrollo';
    System altered.
    

    Tan sencillo como acabáis de ver, simplemente hemos de conectarnos desde el sqlplus y hacer un ALTER SYSTEM para el parámetro service_names poniendo nuestros servicios separados por comas.

    Como siempre, para mas información, tenemos la documentación de Oracle del paqueteDBMS_SERVICES

    Problemas con glibc-devel instalando OEM 12c (crt1.o)

    Hoy vamos a ver la solución a un problema en la instalación de OEM 12c bajo Oracle linux 6.4

    Si miramos la documentación de la instalación en el apartado de paquetes tenemos que necesitamos los paquetes:

    • glibc-devel-2.5-49-i686 (This is a 32-bit package)
    • glibc-devel-2.5-49-x86_64 (This is a 64-bit package)

    Sin embargo, si miramos lo que tenemos en la distribución,

    [root@emc ~]# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n" | grep glibc-dev
    glibc-devel-2.12-1.107.el6(x86_64)
    

    Y a la hora de instalar otro glibc-devel nos dice que ya está instalado

    [root@emc ~]# yum install glibc-devel-2.12-1.80.el6
    Loaded plugins: security
    Setting up Install Process
    Package matching glibc-devel-2.12-1.80.el6.x86_64 already installed. Checking for update.
    Nothing to do
    

    Si intentamos instalar , llega aun punto en que nos da un error de linkado, y es que no encuentra la librería crt1.o

    
    INFO: Salida final del proceso iniciado.
    INFO: ----------------------------------
    INFO: Excepción devuelta de la acción: make
    Nombre de la Excepción: MakefileException
    Cadena de la Excepción: Error al llamar al destino 'install' del archivo make '/oem/oem12c/oms/sqlplus/lib/ins_sqlplus.mk'. 
    Consulte '/oraInventory/logs/installActions-XX.log' para obtener más información.
    Gravedad de la Excepción: 1
    INFO: POPUP WARNING:Error al llamar al destino 'install' del archivo make '/oem/oem12c/oms/sqlplus/lib/ins_sqlplus.mk'. Consulte '/oraInventory/logs/installActions-XX.log' para obtener más información.
    
    Haga clic en  "Reintentar" para volver a intentarlo.
    Haga clic en "Ignorar" para ignorar este error y continuar.
    Haga clic en "Cancelar" para parar esta instalación.
    

    Este error estaba en el proceso de linkado delsqlplus, con el error

    /usr/bin/ld: crt1.o: No suxh file or directory
    

    La solución es tremendamente sencilla, y pasa un poco por la comprension del Oracle Linux, y es que,debemos instalar una librería del formato i396 (i696 para Oracle Linux), el problema , es que, cuando ejecutamos el yum este no instala las librerias de i686 debido a que nuestro sistema es x64.

    Así pues, hay que forzarle a que instale el paquete de i386 (i686) con el comando

    
    yum install glibc-devel.i686
    

    Con este comando, tendremos los dos paquetes instalados

    [root@emc ~]# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n" 
     | grep glibc-dev
    
    glibc-devel-2.12-1.107.el6(x86_64)
    glibc-devel-2.12-1.107.el6(i686)
    
    

    Y la instalación continuará sin problemas

    Opatch, Parcheando la base de datos

    Vamos de vuelta con las entradas «for dummies». Hoy vamos a ver la heraamienta de parcheado de Oracle, Opatch

    Opatch es un binario que suele estar en el directorio $ORACLE_HOME/OPatch , este directorio no está en la ruta de los binarios, con lo que , probablemente si desde linea de comandos de oracle ejecutas «opatch» no encuentres nada.

    Otra de las características mas importantes del Opatch es que es bastante independiente, es decir, al ahora de un parcheado, puedes instalar la ultima versión del Opatch sin interferir con la base de datos, podréis encontrar mas información de esto en soporte con la nota «How To Download And Install The Latest OPatch Version [ID 274526.1]», pero básicamente os adelanto que los pasos son:

    • Descargar el .tgz del ultimo opatch
    • Renombrar el subdirectorio actual ( mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch-fecha )
    • Descomprimir el nuevo opatch ( cd $ORACLE_HOME ; unzup /mnt/downloas/opatch.tgz )

    Como decíamos al principio, Opatch es la herramienta que se utiliza para el parcheado de las bases de datos, su uso exacto está descrito en cada uno de los README.TXT del parche a aplicar, con lo que , SIEMPRE hay que seguir esos pasos, pero , en esta entrada vamos a ver la salida básica de algunos casos en los que se usa

    Supongamos queremos instalar el parche 8730312, para ello lo descargaremos, y lo descomprimiremos en /home/oracle/parches/

      Comprobacion de prerequisitos de un parche

    Lo primero que deberíamos de hacer es comprobar que no va ha haber ningún conflicto entre nuestro parche y la instalacion actual, para ello lanzaremos el Opatch con la opcion CheckConflictAgainstOHWithDetail

    [oracle@pruebas1.pamplona.name] [$   ./opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /home/oracle/parches/
    Invoking OPatch 11.1.0.6.6
    
    Oracle Interim Patch Installer version 11.1.0.6.6
    Copyright (c) 2009, Oracle Corporation.  All rights reserved.
    
    PREREQ session
    
    Oracle Home       : /opt/oracle/product/11.1/dbhome_1
    Central Inventory : /oracle/oraInventory
       from           : /etc/oraInst.loc
    OPatch version    : 11.1.0.6.6
    OUI version       : 11.2.0.1.0
    OUI location      : /opt/oracle/product/11.1/dbhome_1/oui
    Log file location : /opt/oracle/product/11.1/dbhome_1/cfgtoollogs/opatch/opatch2013-03-07_18-45-30PM.log
    Patch history file: /opt/oracle/product/11.1/dbhome_1/cfgtoollogs/opatch/opatch_history.txt
    Invoking prereq "checkconflictagainstohwithdetail"
    Prereq "checkConflictAgainstOHWithDetail" passed.
    OPatch succeeded.
    
      Instalación del parche

    Una vez tenemos claro que podemos aplicarlo, lo aplicamos siguiendo el README.txt del parche.
    La salida del comando de aplicación será algo similar a esto.

     ./opatch apply /home/oracle/parches/8730312/
    Invoking OPatch 11.1.0.6.6
    
    Oracle Interim Patch Installer version 11.1.0.6.6
    Copyright (c) 2009, Oracle Corporation.  All rights reserved.
    
    Oracle Home       : /opt/oracle/product/11.1/dbhome_1
    Central Inventory : /oracle/oraInventory
       from           : /etc/oraInst.loc
    OPatch version    : 11.1.0.6.6
    OUI version       : 11.2.0.1.0
    OUI location      : /opt/oracle/product/11.1/dbhome_1/oui
    Log file location : /opt/oracle/product/11.1/dbhome_1/cfgtoollogs/opatch/opatch2013-03-01_16-11-15PM.log
    Patch history file: /opt/oracle/product/11.1/dbhome_1/cfgtoollogs/opatch/opatch_history.txt
    ApplySession applying interim patch '8730312' to OH '/opt/oracle/product/11.1/dbhome_1'
    Running prerequisite checks...
    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 = '/opt/oracle/product/11.1/dbhome_1')
    
    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 '8730312' for restore. This might take a while...
    Backing up files affected by the patch '8730312' for rollback. This might take a while...
    
    Patching component oracle.rdbms, 11.2.0.1.0...
    Updating archive file "/opt/oracle/product/11.1/dbhome_1/lib/libserver11.a"  with "lib/libserver11.a/kewa.o"
    Updating archive file "/opt/oracle/product/11.1/dbhome_1/lib/libserver11.a"  with "lib/libserver11.a/kewast.o"
    Running make for target ioracle
    ApplySession adding interim patch '8730312' to inventory
    
    Verifying the update...
    Inventory check OK: Patch ID 8730312 is registered in Oracle Home inventory with proper meta-data.
    Files check OK: Files from Patch ID 8730312 are present in Oracle Home.
    
    The local system has been patched and can be restarted.
    OPatch succeeded.
    
      Ver los parches que tienes instalados

    Una de las funcionalidades es el ver que parches tienes instalados, para ello, solamente hay que ir al directorio donde está el Opatch y ejecutar el comando con el flag lsinventory

    [oracle@pruebas1.pamplona.name] [$ cd  $ORACLE_HOME/OPatch
    [oracle@pruebas1.pamplona.name] [$ ./opatch lsinventory
    Invoking OPatch 11.1.0.6.6
    Oracle Interim Patch Installer version 11.1.0.6.6
    Copyright (c) 2009, Oracle Corporation.  All rights reserved.
    Oracle Home       :/opt/oracle/product/11.1/dbhome_1
    Central Inventory : /oracle/oraInventory
       from           : /etc/oraInst.loc
    OPatch version    : 11.1.0.6.6
    OUI version       : 11.2.0.1.0
    OUI location      : /opt/oracle/product/11.1/dbhome_1
    Log file location : /opt/oracle/product/11.1/dbhome_1/cfgtoollogs/opatch/opatch2013-03-26_11-46-16AM.log
    
    Patch history file: /opt/oracle/product/11.1/dbhome_1/cfgtoollogs/opatch/opatch_history.txt
    
    Lsinventory Output file location : /opt/oracle/product/11.1/dbhome_1/cfgtoollogs/opatch/lsinv/lsinventory2013-03-26_11-46-16AM.txt
    
    --------------------------------------------------------------------------------
    Installed Top-level Products (1):
    
    Oracle Database 11g                                                  11.2.0.1.0
    There are 1 products installed in this Oracle Home.
    
    Interim patches (1) :
    
    Patch  8730312      : applied on Fri Mar 01 16:12:29 CET 2013
    Unique Patch ID:  12177426
       Created on 7 Feb 2010, 06:41:26 hrs PST8PDT
       Bugs fixed:
         8730312
    --------------------------------------------------------------------------------
    
    OPatch succeeded.
    

    Aquí podemos ver como tenemos aplicado el parche 8730312 , la fecha en la que se aplicó y el bug que soluciona.

    Como siempre, mas información en soporte en las notas

    • 274526.1 How To Download And Install The Latest OPatch Version
    • 458485.1 How to find whether the one-off Patches will conflict or not?
    • 551394.1 What Are The MANDATORY Information Required To File A Merge Patch Request?.