Nuevas funcionalidades por defecto de Opatch 12c

Posted on 17 febrero, 2017 por admin

Hoy vamos a ver una pequeña entrada sobre algo que me ha sorprendido.

Entre los cambios que han llevado a cabo en el parchado de la 12c además de tener el parchado en dos fases (Opatch + datapatch), me he encontrado con que, las ultimas versiones de Opatch llevan a cabo muchas mas comprobaciones en la fase de pre-requisitos.
Como curiosidad, alguna de ellas son:

CheckActiveFilesAndExecutables Comprueba si alguno de los componentes a parchar esta corriendo, esto incluye el listener.
CheckActiveServicesEspecifico de equipos windows, comprueba los servicios activos.
CheckSystemSpace Comprueba que haya bastante espacio para la aplicacion
CheckUserAdminPrivilege comprueba que no sea lanzado como root

Hay muchísimos mas , y puedes verlos con

opatch prereq -help

Pero, no deja de ser curioso la cantidad de comprobaciones que lleva a cabo en estos momentos el optach

Métodos de parcheados del RAC

Posted on 17 diciembre, 2015 por admin

Responder

Hoy vamos a ver unas nociones rápidas sobre el parchado en un RAC
Parchear el RAC es diferente al parcheado de un sibgle node, si Opatch detecta un cluster preguntará al OUI el nombre del nodo local y el listado de nodos.
Además de esto, antes de instalar un parche hay que parar todoas las aplicaciones que corren en ese directorio de software deben de pararse.

Exsisten 3 métodos de parcheado de un RAC

All Node Patching
Rolling Patching
Minimum Dowtime

Para llevar a cabo el parchado seguiremos los siguientes pasos:
1. Parar el grid y todo lo que dependa de el en el nodo ( incluido ASM de single instances)
2. Desbloquear el GRID_HOME, como root ejecutaremos
cd $GRID_HOME/crs/install perl rootcrs.pl -unlock -crshome /u01/app/11.2.0/grid
Al ejecutar el rootcrs.pl con el flag -unlock desbloqueamos el GRID_HOME con lo que ya puede modificarse
3.Con el usuario del grid p parcheamos con el método que elijamos ( ver 3 métodos)
4. Como root de nuevo,volvemos a bloquear los binarios del grid con
cd $GRID_HOME/crs/install perl rootcrs.pl -patch
Al ejecutar el rootcrs.pl con el flag -patch bloqueamos el GRID_HOME y se rearranca el Oracle Clusterware stack

Métodos de parcheado

Vamos a describir cada uno de los tres métodos de parchado y las diferencias entre ellos

All Node Patching

Este método consiste en parar todos los recursos de todos los nodos y se instalan a la vez. una vez están todos parcheados arrancamos de nuevo.
Esté método es el que se usa típicamente para los parches críticos y es el que tiene el máximum downtime.
Opatch usa este método cuando el parche no puede aplicarse en “ rolling fashion” y cuando no se especifica la opcion minimize_downtime
Los pasos serían:
$ CRS_home/crs/bin/crsctl stop cluster -all $ Grid_home/bin/crsctl status resource -t $ cd Oracle_home/OPatch/4519934/4519934 opatch apply # Grid_home/bin/crsctl start cluster -all (como root) $ Grid_home/bin/crsctl status resource -t
Tras esto ejecutamos los post-scripts que nos diga el readme.

Rolling Patching

El método de Rolling patching es el método mas eficiente para la aplicación de parches en un RAC o un GRID. En este método se para un grupo de nodos , se aplican los parches a ese grupo, se levanta.. se va haciendo así hasta que todos los nodos del cluster están parcheados.
De esta forma el downtime es cero ya que siempre dejas un nodo disponible de cada instancia.
No todos los parches pueden ser aplicados mediante este método. Si no puede aplicarse es cuando tendrás que aplicar el “minimun downtime” o “all node”
Los pasos son:
opatch query -is_rolling_patch $ Grid_home/crs/bin/crsctl stop cluster -n RAC1 (paramostodo) opatch apply [-local_node rac1] -remote_nodes rac2, rac3 Arrancamos los nodos que hemos parcheado Comprobamos el estado con crsctl stat res –t Repetimos lospasos 2-5 en los que quedan Ejecutamos los comandos post-pacth

Minimun Downtime

Este método es el casi igual que el de rolling patching, pero lo llevamos a cabo cuando losparches no sean “rolling patch”La diferencia principal es que los nodos que se van parando y arrancando son los que tienen un mismo servicio.Se pierde servicio enlos nodos parcheados, pero si hay mas de un servicio el resto sigue funcionando. Es una mezcla entre el mejor (rolling) y el peor(all nodes)
En este método se para un grupo de nodos , se aplican los parches a ese grupo, se levanta.. se va haciendo así hasta que todos los nodos del cluster están parcheados.
Los pasos son:
Elegimos un grupo de onodos aparchear. $ Grid_home/crs/bin/crsctl stop cluster -n RAC1 (paramos todo) opatch apply -minimize_downtime Arrancamos los nodos que hemos parcheado Comprobamos el estado con crsctl stat res –t Repetimos lospasos 2-5 en los que quedan Ejecutamos los comandos post-pacth

A groso modo esta es la diferencia entre los 3 métodos de parchado de un RAC, evidentemente, como siempre, conviene leerse el README tanto para ver las especificaciones del parche, como la vuelta atrás.
Antes de ejecutar los comandos que ponemos aquí, es siempre recomendable el hacer las propias comprobaciones previas con el Opatch tal y como indicábamos en la entrada para ver si la instalación cumple con los requisitos del parche.

Usuario administrador de Weblogic en OEM12C

Posted on 26 mayo, 2015 por admin

Vamos con una entrada rápida de esas que nos evitarán quebraderos de cabeza.

¿Sabemos cual es el usuario de administración de nuestro weblogic?

Cuando vamos a parchear nuestro Cloud control nos encontramos con lo siguiente

oracle@emc 18295180]$ opatchauto apply -analyze -property_file bundle.xml
OPatch Automation Tool  
 Copyright (c) 2013, Oracle Corporation.  All rights reserved.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          OPatchauto version : 11.1.0.10.0                                                                                                                                                                                                             OUI version        : 11.1.0.11.0                                                                                                                                                                                                             Running from       : /u01/app/oracle/middleware/oms
Log file location  : /u01/app/oracle/middleware/oms/cfgtoollogs/opatch/opatch2015-05-26_09-09-22AM_1.log
opatchauto log file: /u01/app/oracle/middleware/oms/cfgtoollogs/opatchauto/18295180/opatch_oms_2015-05-26_09-09-27AM_analyze.log
OPatch will do the following:
[Get weblogic Admin Server information]                        : Interview to get weblogic Admin Server of the GC Domain
[Generate configuration context of the GC Domain]              : Get the configuration context for the GC Domain
[Run patch(es) deployment prerequisite checks]                 : Check the status of admin server of the GC Domain
                                                               :  Check the status of OMS repository 
[Run patch(es) binary prerequisite checks]                     :Check if all the patches can be applied to or rolled back from their corresponding Oracle Home
[Generate execution steps to apply and deploy the patch(es)]   : Generate execution steps to modify bits and deploy artifacts of the patch

Please enter the WebLogic Admin Server URL for primary OMS(t3s://emc.pamplona.name :7103):>
Please enter the WebLogic Admin Server username for primary OMS:> 
Please enter the WebLogic Admin Server password for primary OMS:>

¿Cual es ese usuario que nos piden?
Si vamos a la URL que nos indica el fichero setupinfo.txt que nos dejó la instalacion en $ORACLE_HOME/install vemos que:

 Admin Server URL: https://emc.pamplona.name:7103/console

Y acediendo a esa URL nos encontramos con

Pero si revisamos los pasos de la instalacion del OEM12c veremos como en ninguna de las ventanas indicamos cual era el usuario de administrador del servidor de aplicaciones que va a correr el OEM12c. Solo indicamos el password.

La respuesta es sencilla :

usuario : weblogic
Contraseña: La de la instalación

Opatch, Parcheando la base de datos

Posted on 26 marzo, 2013 por admin

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

Dba stuff

Un cajon desastre para el día a día

Archivo de la etiqueta: opatch