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?.

Modificar el editor por defecto de SQLplus en Unix

Vamos con una nota rápida y sencilla, pero bastante útil.

SQLPlus tiene por defecto el editor ed , sinceramente, el ed no es el editor mas usado del mundo, de hecho, no conozco a nadie que lo tenga como su primera opción, la pregunta ahora es, ¿Como hacemos para modificar este editor por defecto?

muy sencillo:


define_editor='vi'

Para no tener que estar añadiendo esta línea cada vez que entramos, podemos añadirla al fichero profile de sqlplus genérico que se encuentra en


$ORACLE_HOME/sqlplus/admin/glogin.sql

Problemas con los requerimientos del cliente 11gr2 en windows

Volvemos tras las vacaciones navideñas con una pequeña entrada de esas tremendamente simples, pero que pueden ser evitarnos una gran pérdida de tiempo.

Una de las cosas mas engorrosas de las instalaciones de Oracle es la instalación del cliente, en primer lugar, porque pocas veces nos especifican que es exactamente los componentes del cliente que necesitan, y en segundo lugar, por que, hasta estas últimas versiones la instalación ( especialmente la desinstalación) del cliente de windows era muy engorrosa.

Pues bien, el otro día en la instalación de un cliente 11gr2 en windows me encontré con un error nuevo:

error_instalacion_XP

Mi windows XP detectaba un error en los requerimientos de la instalacion del cliente (no instantclient), cuando, todos los requerimientos eran correctos.

La solución es tan sencilla como el habilitar el uso compartido de C$. Parece ser que el instalador utiliza «\\< servidor >\C$\temp» , con lo que si no está habilitado el recurso, la instalación falla.

La información completa del caso está (como siempre) en metalink, en la nota «Installation of 11gR2 on Windows Fails Checking Requirements [ID 1133495.1]»

Funcionamiento de las variables NLS

Hoy vamos a ver una de las cosas mas simples que hay en Oracle y de las que mas quebraderos de cabeza traen, la globalizacion.

Las variables que definen el idioma, numeros,fechas, ordenacion… de Oracle son las llamadas variables de globalización de Oracle o  mas comumente parámetros NLS.

Para evitar problemas con los acentos, eñes, puntos/comas,fechas…. deberias de tener claro cual es el NLS_LANG que tienes/quieres . Pero vamos a dejar este NLS_LANG para un poco mas adelante

Las principales variables para un entorno de oracle son:
•    NLS_LANGUAJE: Se usa para los mensajes (incluidos los de error)
•    NLS_DATE_LANGUAJE: Para los nombres de día y mes
•    NLS_SORT: (Binary) para la ordenación lingüística
Adicionalmente, tenemos una variable de entorno que nos define un amplio número de variables , este prámetro es NLS_TERRITORY , esta variable define las  siguientes subvariables
•    NLS_CURRENCY
•    NLS_DUAL_CURRENCY
•    NLS_ISO_CURRENCY
•    NLS_DATE_FORMAT
•    NLS_NUMERICA_CHARACTERS
•    NLS_TIMESTAMP_FORMAT
•    NLS_TIMESTAMP_TZ_FORMAT

Una vez visto esto, volvemos a NLS_LANG que se define como:
NLS_LANG=<language>_<territory>.<character set>  (por ejemplo export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 o en español  export NLS_LANG=SPANISH_SPAIN.WE8MSWIN1252 )
Así pues, si definimos correctamente nuestra variable NLS_LANG tendremos practicamente todas las variables de entorno definidas y conseguiremos que nuestras consultas tengan los caracteres que queremos.

Las variables de globalización de una base de datos se pueden fijar a 5 niveles:

  • Database
  • Instancia
  • Cliente
  • Sesión
  • Sentencia

Cada nivel inferior anula a un superior, es decir, si yo fijo una variable de entorno en una sentencia esta variable prevalecerá sobre las variables de base de datos, instancia o sesion.

Llegados a este punto, sabemos que queremos, pero, no sabemos que tenemos. ¿Como podemos saber que parámetros NLS tenemos definidos en nuestro cliente/aplicacion?

La solucion es muy sencilla, solamente tenemos que conectarnos y preguntar.

Para ver todas las variables de nuestra conexion de cliente

SQL> set pagesize 200;
column parameter format a25;
column value format a40;
select * from v$nls_parameters;

PARAMETER                 VALUE
------------------------- ----------------------------------------
NLS_LANGUAGE              SPANISH
NLS_TERRITORY             SPAIN
NLS_CURRENCY              
NLS_ISO_CURRENCY          SPAIN
NLS_NUMERIC_CHARACTERS    ,.
NLS_CALENDAR              GREGORIAN
NLS_DATE_FORMAT           DD/MM/RR
NLS_DATE_LANGUAGE         SPANISH
NLS_CHARACTERSET          WE8MSWIN1252
NLS_SORT                  SPANISH
NLS_TIME_FORMAT           HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT      DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT        HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT   DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY         
NLS_NCHAR_CHARACTERSET    AL16UTF16
NLS_COMP                  BINARY
NLS_LENGTH_SEMANTICS      BYTE
NLS_NCHAR_CONV_EXCP       FALSE

19 rows selected.

o la variable languaje exportada del entorno

 SQL> SELECT USERENV ('language') FROM DUAL;

USERENV('LANGUAGE')
----------------------------------------------------
SPANISH_SPAIN.WE8MSWIN1252

Con esto seguramente encontremos la explicación de por que las fechas no nos salen como queremos, vemos caracteres extraños en las ñ o nos fallan las inseciones por culpa de los . y ,

Recuperar un spfile borrado

Hoy vamos a ver algo tan sencillo como el recuperar un fichero spfile.

El spfile es la «nueva» version del fichero de configuracion de parametros texto de toda la vida llamado pfile. La principal ventaja que obtenemos con tener un fichero de configuración binario sobre un fichero de texto es que la instancia puede ir actualizando los cambios de configuración que llevas a cabo en la base de datos sin necesidad de tener que actualizarlo manualmente. Hemos de tener en cuenta que, con los nuevos modos de gestión de memoria la configuracion del tamaño de los distintos pooles ya no es estático, con lo que es necesario tener un fichero de datos actualizable si quieres mantener esa informacion en el siguiente arranque.

El fichero spfile es necesario en el momento en el que arrancas la instancia, pero no lo es para el funcionamiento de la base de datos, si  borras este fichero cuando la base de datos esta en funcionamiento todo funcionará correctamente, solamente tendremos errores cuando intentemos modificar algo del spfile, y los errorres que tendremos serán errores de localizacionde fichero del sistema operativo

ORA-01565: error al identificar el archivo '/opt/oracle/product/11.2.0.3/dbhome_1/dbs/spfileorcl.ora'
ORA-27037: no se ha podido obtener el estado del archivo
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Pero la base de datos seguirá funcionando correctamente.

Para restaurar un spfile tenemos dos opciones:

1- Restauración desde RMAN

Rman hace una copia del controlfile y el spfile cada vez que llevas a cabo un backup del tablespace system.  Así pues, si hacemos backups full de nuestra base de datos, deberíamos de tener una copia del spfile en el backupset.

La recuperación del fichero es muy sencilla, simplemente hay que decirle que lo restaure del autobackup con el comando:

restore spfile from autobackup;

Si tenemos la base de datos en funcionamiento el comando fallará devolviendonos el error:

RMAN> restore spfile from autobackup;
Starting restore at 29/09/12
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=156 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 09/29/2012 21:58:30
RMAN-06564: must use the TO clause when the instance is started with SPFILE

la solución a este problema es muy sencilla,  vamos a engañar un poco a nuestra base de datos, vamos a recuperarlo a un lugar alternativo y luego lo moveremos con comandos del sistema operativo (o del asm).

RMAN> restore spfile to '?/dbs/spfile.backup' from autobackup;
Starting restore at 29/09/12
using channel ORA_DISK_1
recovery area destination: /opt/oracle/flash_recovery_area
database name (or database unique name) used for search: ORCL
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /opt/oracle/flash_recovery_area/ORCL/autobackup/2012_09_29/o1_mf_s_795264706_86ffo3j0_.bkp
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 29/09/12
RMAN> quit
$cd /opt/oracle/product/11.2.0.3/dbhome_1/dbs/
mv spfile.backup spfileorcl.ora

P.D en caso de que la instancia estuviese caída y no tuviesemos el spfile en el momento la base de datos deberá de estar en modo MOUNT

2-Creándolo a partir del alert.log

Cada vez que arrancamos y paramos la base de datos, toda la información del spfile es volcada en el fichero alert.log

Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
  processes                = 150
  memory_target            = 1536M
  control_files            = "/opt/oracle/oradata/orcl/control01.ctl"
  control_files            = "/opt/oracle/flash_recovery_area/orcl/control02.ctl"
  db_block_size            = 8192
  compatible               = "11.2.0.0.0"
  db_recovery_file_dest    = "/opt/oracle/flash_recovery_area"
  db_recovery_file_dest_size= 3882M
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
  local_listener           = "LISTENER_ORCL"
  audit_file_dest          = "/opt/oracle/admin/orcl/adump"
  audit_trail              = "DB"
  db_name                  = "orcl"
  open_cursors             = 300
  diagnostic_dest          = "/opt/oracle"
.
.
.

Asimismo, tambien deja reflejados los cambios que hacemos si ejecutamos

SQL> alter system set undo_retention=9000;

Y luego miramos el alert, vemos que

ALTER SYSTEM SET undo_retention=9001 SCOPE=BOTH;

Con lo que, podremos  regenerar nuestro spfile creando un fichero de texto con estos valores  (fichero parameter file de texto clásico) , y despues ejecutando el comando.

create spfile from pfile='/tmp/init_SID.ora'

P.D  si la isntancia está levantada, aqui tendremos el mismo problema que cuando intentamos recuperar de RMAn con autobackup, con lo que tendremos que aplicar la misma solución, engañar a oracle desde el sistema operativo

create spfile='?/dbs/spfile.backup' from pfile='/tmp/initSID.ora'
cd $ORACLE_PRODUCT/dbs
mv spfile.backup spfileorcl.ora