Apply PSU to Rac 12c on AIX7.1 (not pluggable database environment)

Recently I had opportunity to apply PSU to a rac environment in 12cR1 (not pluggable database architecture) on AIX7.1. The steps I followed are the next one:

1.- Make sure that I have the Opatch last version  (OPatch Version: 12.2.0.1.8) on all nodes (same version)

2.- Download PSU 24917825 for RAC Infra.

3.- Download PSU 24732082 for databases

4.- Take backup of ORACLE_HOME of Databases and Grid Infraestructure (also of your OraInventory) for all nodes (I suggest )

I have my install medios in the path: /u01/medios/ for my environments

(same Path on all nodes)

The PSU application on RAC nodes  can be performed  different ways. I choose this method and I will explain  you.

Apply PSU for Infraestructure GRID

The steps are the following (to do with grid user):

cd /u01/medios

unzip p24917825_121020_AIX64-5L.zip   

Note: For Opatch version 12.2.0.1.8 is not necessary to create response File with emocmrsp command.

This steps to do with root user but you will get error OPATCHAUTO-72046: Invalid wallet parameters (Doc ID 2150070.1). Here we will review patch conflicts:

export ORACLE_HOME=/u01/app/12.1.0/grid

/u01/app/12.1.0/grid/OPatch/opatchauto apply /u01/medios/24917825 –analyze

If there are not patch conflicts we can proceed to apply patch to Infra. I remember you that this patch is rolling installable. I take 30’ minutes to apply (with root user):

[nodo01]#> export ORACLE_HOME=/u01/app/12.1.0/grid

[nodo01]#>export export PATH=$PATH:$ORACLE_HOME/OPatch

[nodo01]#>/u01/app/12.1.0/grid/OPatch/opatchauto apply /u01/medios/24917825  -oh /u01/app/12.1.0/grid

OPatchauto session is initiated at Sat Feb  4 04:09:12 2017

System initialization log file is /u01/app/12.1.0/grid/cfgtoollogs/opatchautodb/systemconfig2017-02-04_03-09-19AM.log.

Session log file is /u01/app/12.1.0/grid/cfgtoollogs/opatchauto/opatchauto2017-02-04_03-09-52AM.log

The id for this session is DM67

Executing OPatch prereq operations to verify patch applicability on home /u01/app/12.1.0/grid

Patch applicablity verified successfully on home /u01/app/12.1.0/grid

Verifying patch inventory on home /u01/app/12.1.0/grid

Patch inventory verified successfully on home /u01/app/12.1.0/grid

Bringing down CRS service on home /u01/app/12.1.0/grid

Prepatch operation log file location: /u01/app/12.1.0/grid/cfgtoollogs/crsconfig/crspatch_cmh-racn1_2017-02-04_04-16-44AM.log

CRS service brought down successfully on home /u01/app/12.1.0/grid

Start applying binary patch on home /u01/app/12.1.0/grid

Successfully executed command: /usr/sbin/slibclean

Binary patch applied successfully on home /u01/app/12.1.0/grid

Starting CRS service on home /u01/app/12.1.0/grid

Postpatch operation log file location: /u01/app/12.1.0/grid/cfgtoollogs/crsconfig/crspatch_cmh-racn1_2017-02-04_04-34-16AM.log

CRS service started successfully on home /u01/app/12.1.0/grid

Verifying patches applied on home /u01/app/12.1.0/grid

Patch verification completed with warning on home /u01/app/12.1.0/grid

OPatchAuto successful.

--------------------------------Summary--------------------------------

Patching is completed successfully. Please find the summary as follows:

Host:cmh-racn1

CRS Home:/u01/app/12.1.0/grid

Summary:

==Following patches were SUCCESSFULLY applied:

Patch: /u01/medios/24917825/21436941

Log: /u01/app/12.1.0/grid/cfgtoollogs/opatchauto/core/opatch/opatch2017-02-04_03-18-06AM_1.log

Patch: /u01/medios/24917825/24732082

Log: /u01/app/12.1.0/grid/cfgtoollogs/opatchauto/core/opatch/opatch2017-02-04_03-18-06AM_1.log

Patch: /u01/medios/24917825/24828633

Log: /u01/app/12.1.0/grid/cfgtoollogs/opatchauto/core/opatch/opatch2017-02-04_03-18-06AM_1.log

Patch: /u01/medios/24917825/24828643

Log: /u01/app/12.1.0/grid/cfgtoollogs/opatchauto/core/opatch/opatch2017-02-04_03-18-06AM_1.log

OPatchauto session completed at Sat Feb  4 04:42:40 2017

Time taken to complete the session 33 minutes, 30 seconds

Now is necessary to repeat same process  with all rest of nodes. When we have the Grid Infraestructure on all nodes with the same version, we can to apply the psu to database software.

Apply PSU to database software

Just like te previous situation, this part is rolling installation. We will start with the node one. First step is shutdown all db service in that node: (all following command with oracle user)

srvctl stop instance -d  database –I instance_name

Then we’ll check Patch conflict:

[nodo01]#>cd /u01/medios/24732082

[nodo01]#>opatch prereq CheckConflictAgainstOHWithDetail -ph ./

If all previous results fine, we’ll proceed with apply the database PSU:

[nodo01]#>cd  /u01/medios/24732082

[nodo01]#>opatch  apply

`

Oracle Interim Patch Installer version 12.2.0.1.8

Copyright (c) 2017, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/12.1.0/dbhome_1

Central Inventory : /u01/app/oraInventory

  from           : /u01/app/oracle/product/12.1.0/dbhome_1/oraInst.loc

OPatch version    : 12.2.0.1.8

OUI version       : 12.1.0.2.0

Log file location : /u01/app/oracle/product/12.1.0/dbhome_1/cfgtoollogs/opatch/opatch2017-02-04_04-01-02AM_1.log

Verifying environment and performing prerequisite checks...

OPatch continues with these patches:   23054246  24006101  24732082  

Do you want to proceed? [y|n]

y

User Responded with: Y

All checks passed.

This node is part of an Oracle Real Application Cluster.

Remote nodes: 'cmh-racn2' 'cmh-racn3' 'cmh-racn4'

Local node: 'cmh-racn1'

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.

(Oracle Home = '/u01/app/oracle/product/12.1.0/dbhome_1')

Is the local system ready for patching? [y|n]

y

User Responded with: Y

Backing up files...

Applying sub-patch '23054246' to OH '/u01/app/oracle/product/12.1.0/dbhome_1'

Patching component oracle.rdbms.dv, 12.1.0.2.0...

Patching component oracle.rdbms.rsf, 12.1.0.2.0...

Patching component oracle.rdbms.rman, 12.1.0.2.0...

Patching component oracle.rdbms, 12.1.0.2.0...

Patching component oracle.rdbms.dbscripts, 12.1.0.2.0...

Patching component oracle.ldap.rsf, 12.1.0.2.0...

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/lib/libzt12.a" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/lib/libzt12.a"

Patching component oracle.install.deinstalltool, 12.1.0.2.0...

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/lib/libldapjclnt12.so" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/lib/libldapjclnt12.so"

Patching component oracle.ldap.rsf.ic, 12.1.0.2.0...

Patching component oracle.oracore.rsf, 12.1.0.2.0...

Patching component oracle.ctx, 12.1.0.2.0...

Patching component oracle.xdk, 12.1.0.2.0...

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/bin/xmldiff" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/bin/xmldiff"

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/bin/xvm" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/bin/xvm"

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/bin/xmlpatch" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/bin/xmlpatch"

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/bin/xsl" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/bin/xsl"

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/bin/xmlcg" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/bin/xmlcg"

Patching component oracle.nlsrtl.rsf, 12.1.0.2.0...

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/bin/lxegen" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/bin/lxegen"

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/bin/lcsscan" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/bin/lcsscan"

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/bin/lxchknlb" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/bin/lxchknlb"

Patching component oracle.xdk.parser.java, 12.1.0.2.0...

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/bin/xml" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/bin/xml"

Patching component oracle.ctx.atg, 12.1.0.2.0...

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/lib/libanllexer12.so" because it is the same as

the file in incoming patch "/u01/medios/24732082/23054246/files/lib/libanllexer12.so"

Applying sub-patch '24006101' to OH '/u01/app/oracle/product/12.1.0/dbhome_1'

Patching component oracle.sqlplus, 12.1.0.2.0...

Patching component oracle.rdbms, 12.1.0.2.0...

Patching component oracle.network.listener, 12.1.0.2.0...

Patching component oracle.network.rsf, 12.1.0.2.0...

Patching component oracle.rdbms.dv, 12.1.0.2.0...

Patching component oracle.rdbms.rman, 12.1.0.2.0...

Patching component oracle.rdbms.dbscripts, 12.1.0.2.0...

Patching component oracle.sqlplus.ic, 12.1.0.2.0...

Patching component oracle.rdbms.rsf, 12.1.0.2.0...

Applying sub-patch '24732082' to OH '/u01/app/oracle/product/12.1.0/dbhome_1'

Patching component oracle.rdbms.install.plugins, 12.1.0.2.0...

Patching component oracle.rdbms.rsf, 12.1.0.2.0...

Skip copying to "/u01/app/oracle/product/12.1.0/dbhome_1/rdbms/mesg/oraus.msb" because it is the same as

the file in incoming patch "/u01/medios/24732082/24732082/files/rdbms/mesg/oraus.msb"

Patching component oracle.tfa, 12.1.0.2.0...

Patching component oracle.rdbms.rman, 12.1.0.2.0...

Patching component oracle.rdbms, 12.1.0.2.0...

Patching component oracle.rdbms.dbscripts, 12.1.0.2.0...

…………………..

…………………. (Here I cut this part becaouse es very very long ☹   )

………………….

Patching in rolling mode.

Remaining nodes to be patched:

'cmh-racn2' 'cmh-racn3' 'cmh-racn4'

What is the next node to be patched?

In that part the installation will ask us a question about which is the name of next hostname of Rac for the appy PSU. In this moment we will start again the database service only in this node (node 1), while we need shutdown the database service in the next one node (nodo2). When we have the instance up in the node 1 and down the service in the node , we can proceed with the installer.

When we have finished the installation on all nodes, we need to load the modified sql into the database.

Load modified sql into database (datapatch)

This is only necessary to apply once time, preferably node 1 with user oracle:

cd $ORACLE_HOME/OPatch

$ ./datapatch -verbose

SQL Patching tool version 12.1.0.2.0 Production on Wed Feb 22 05:35:11 2017

Copyright (c) 2012, 2016, Oracle.  All rights reserved.

Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_29229074_2017_02_22_05_35_11/sqlpatch_invocation.log

Connecting to database...OK

Bootstrapping registry and package to current versions...done

Determining current state...done

Current state of SQL patches:

Patch 22674709 (Database PSU 12.1.0.2.160419, Oracle JavaVM Component (Apr2016)):

 Installed in the binary registry only

Bundle series PSU:

 ID 170117 in the binary registry and ID 160419 in the SQL registry

Adding patches to installation queue and performing prereq checks...

Installation queue:

 Nothing to roll back

 The following patches will be applied:

   22674709 (Database PSU 12.1.0.2.160419, Oracle JavaVM Component (Apr2016))

   24732082 (DATABASE PATCH SET UPDATE 12.1.0.2.170117)

Installing patches...

Patch installation complete.  Total patches installed: 2

Validating logfiles...

Patch 22674709 apply: SUCCESS

 logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/22674709/20077876/22674709_apply_CMH_2017Feb22_05_36_19.log (no errors)

Patch 24732082 apply: SUCCESS

 logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/24732082/20919987/24732082_apply_CMH_2017Feb22_05_43_58.log (no errors)

SQL Patching tool complete on Wed Feb 22 05:44:33 2017

You have mail in /usr/spool/mail/oracle

And now when we execute query to catalog we can see that our database is update with the last PSU:

We can to do the same with de oraInventory  for the grid and database ORACLE_HOME:

Remains to explain what will happen with respect to OJVM upgrade. (I’ll have soon)

Bye : )

Upgrade de Oracle SAP 11g a 12c  + aplicación de SapBundlePatch

Si se va a realizar un upgrade a 12c se sugiere actualizar revisando la nota siguiente:

How to Upgrade to Oracle Database 12c Release1 (12.1.0) and Known Issues (Doc ID 2085705.1)

Se debe tener claro lo siguiente antes de hacer el upgrade. Mínimo la base de datos se debe encontrar dentro de las siguientes versiones:



Software requeridos para el upgrade

1.- El software de la base de datos: debe ser descargado del sitio de SAP. Los archivos finales que se descargan ( *.SAR) pueden ser descomprimidos usando la herramienta SAPCAR (más información en el link: (http://www.felipedonoso.cl/2016/04/sap-como-descomprimir-software-oracle.html) No se puede descargar el software directamente desde la página de oracle. Debe ser realizado directamente desde el sitio de soporte de SAP por lo cual se requiere tener acceso al soporte:

https://support.sap.com/swdc

2.- sapbundle patch : Se debe descargar el ultimo disponible en el sitio de SAP.

Como dato adicional será necesario instalar la última versión de OPATCH y MOPATCH sobre el nuevo software de base de datos 12c. En este sentido no hay problema y el OPATCH puede ser bajado directamente desde el sitio de Oracle. En este caso tengo descargada la última versión hasta la fecha (6880880_121010_AIX64-5L.zip) o en su defecto se puede ocupar opatch y mopatch que ofrece SAP el cual al igual que el software de BD puede ser descargado desde el sitio de soporte SAP.



Prerequisitos

1.- Se deben tener presente los objetos inválidos de la base de datos que aun esta en 11g. Puede que luego del upgrade de la BD varios objetos queden inválidos.

2.- Deben chequear que opciones adicionales pueden hacer falta instalar en la versión Enterprise enel wizard de 12c, revisando si la base de datos original tiene alguna opción adicional ocupada con la vista dba_feature_usage_statistics.

3.- Sugiero sacar un respaldo del inventario en mi caso de la carpeta /oracle/oraInventory/

Pueden ocupar la opción del comando cp –rp  para preservar los permisos originales en  el archivo de backup final.



Instalación de software de 12c de SAP

En este caso instalaremos el software de base de datos en un nuevo disco llamado: /oracle/PID/12102. Todo nuestro software de base de datos que usaremos para hacer todas las instalaciones se encuentran en el disco /oracle/PID/sapdata11/medios

orapid> cd /oracle/PID/sapdata11/medios/database

orapid> ls -lptr

total 96

-rw-r-----    1 orapid   dba             500 Feb 06 2013  welcome.html

-rw-r-----    1 orapid   dba           14047 Mar 10 2014  rootpre.sh

-rw-r-----    1 orapid   dba           16868 Nov 08 2014  runInstaller

drwxr-x---    2 orapid   dba             256 Feb 14 10:32 rpm/

drwxr-x---    2 orapid   dba             256 Feb 14 10:36 sshsetup/

drwxr-x---    3 orapid   dba             256 Feb 14 10:36 rootpre/

drwxr-x---    2 orapid   dba             256 Feb 14 10:36 SAP/

drwxr-x---    4 orapid   dba            4096 Feb 14 10:36 install/

drwxr-x---   14 orapid   dba            4096 Feb 14 2017  stage/

drwxr-x---    2 orapid   dba             256 Feb 14 2017  response/

orapid> ./runInstaller

Se siguen las instrucciones al igual que en un Oracle normal. Si aparecen errores de permisos de ejecución recordar dar privilegios de chmod +x ej:

Checking Temp space: must be greater than 190 MB.   Actual 3047 MB    Passed

Checking monitor: must be configured to display at least 256 colors.    Actual 16777216    Passed

Preparing to launch Oracle Universal Installer from /tmp/OraInstall2017-02-14_11-15-05AM. Please wait ...sh: /oracle/PID/sapdata11/medios/database/install/unzip: 0403-006 Execute permission denied.

Mi sugerencia es que den privilegios +x a toda la carpeta install del directorio del software base y su contenido. Recordar omitir el siguiente error (hay una nota de metalink que explica el porqué

Aparece esto)

Como pueden ver a continuación la instalación es tal cual un motor normal:

Si se aprecia el error: Cause - Failed to access the temporary location. Esto tiene varias soluciones pueden aplicar la siguiente:

Busquen la carpeta llamada CVU_* en el directorio /tmp y asignen sobre ella privilegios full: ejemplo;

root@DCPIDDEV:/tmp$ chmod -R 777 CVU_12.1.0.2.0_orapid/

root@DCPIDDEV:/tmp$

Luego continúen con la instalación de manera norma recordar que solo se instalará el software de base de datos. A continuación algunas evidencias:



Recordar chequear si en la base de datos se requiere alguna opción adicional (pueden chequear la vista: dba_feature_usage_statistics )

Como mencione la instalación es tal cual como en un Oracle normal.



Upgrade de base de datos a 12c

Luego que la instalación ha finalizado asegúrense de tener su archivo oratab en orden. Usaremos el método dbua para actualizar. Deberia lucir similar a este:

Posteriormente se deben copiar los archivos de parámetros spfile o pfile y los archivos de network/admin/* a la nueva ruta de 12c que acabamos de instalar. Ojo que a los archivos de parámetro spfile que usaran en el DBUA se le sugiere quitar los parámetros ocultos y los de EVENT solo mientras se haga el upgrade. Ojo NO CAMBIAR AUN EL PARAMETRO COMPATIBLE. Se sugiere eliminar el valor del parámetro REMOTE_OS_AUTHENT de manera temporal también pues el DBUA reclamará al respecto.

orapid> pwd              

/oracle/PID/112_64/dbs

orapid> cp * /oracle/PID/12102/dbs

orapid> cp /oracle/PID/122_64/network/admin/* /oracle/PID/12102/network/admin

cp: 0653-436  samples is a directory.

       Specify -r or -R to copy.

orapid> ls -lptr /oracle/PID/12102/network/admin

total 32

drwxr-xr-x    2 orapid   dba             256 Feb 14 11:42 samples/

-rwxr-x---    1 orapid   dba             796 Feb 14 12:06 listener.ora

-rw-r--r--    1 orapid   dba             187 Feb 14 12:06 shrept.lst

-rwxr-x---    1 orapid   dba             961 Feb 14 12:06 tnsnames.ora

-rwxr-x---    1 orapid   dba             501 Feb 14 12:06 sqlnet.ora

Usando aun el ORACLE_HOME de 11g se recomienda actualizar la estadisticas del diccionario de datos:

SQL> EXECUTE dbms_stats.gather_dictionary_stats;

(no deberia tomar para este caso más de 10 minutos)

Posteriormente en la misma base de datos se sugiere ejecutar el script para visualizar problemas pre-upgrade. El script se llama dbupgdiag.sql y lo pueden encontrar en la siguiente nota: Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql) (Doc ID 556610.1)

Otro paso necesario es ejecutar el siguiente script del nuevo HOME DE 12c (en la carpeta $ORACLE_HOME/rdbm/admin)

sqlplus "/as sysdba" @preupgrd.sql

Luego se deben seguir las instrucciones allí visualizadas para antes y después del upgrade. Esto todo con el fin de garantizar la operación del upgrade. Por ejemplo en los logs se visualizará que hay actualizar el TimeZone, etc.

Revisar el log y si es necesario ejecutar el script de de fix para antes del upgrade. Posteriormente a eso recargaremos las variables de ambiente apuntando todo al nuevo disco 12c, ejemplo:

export ORACLE_BASE=/oracle

export ORACLE_HOME=/oracle/PID/12102

export ORACLE_SID=PID

export ORASID=orapid

export LIBPATH=/usr/lib:/lib:/usr/sap/PID/SYS/exe/run:/usr/sap/PID/SYS/exe/uc/rs6000_64:$ORACLE_HOME/lib

export PATH=$ORACLE_HOME/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java5/jre/bin:/usr/java5/bin:/usr/sap/PID/SYS/exe/uc/rs6000_64:/usr/sap/PID/SYS/exe/run:/oracle/PID:.

La base de datos al momento de upgradear debe estar arriba con el software de 11g esto es porque el DBUA chequea los parámetros que actualmente están funcionando.  En ese mismo ORACLE_HOME de 11g los parámetros antes mencionados deben estar comentados (parámetros ocultos, events, fixcontrol, etc.)

Se sugiere realizar el upgrade usando estas opciones:



Cuando la actividad esté finalizada se visualizará algo parecido a esto:



Tareas Postupgrade a 12c

• Se deben revisar que no hayan objetos inválidos

• Crear el siguiente link simbólicos (son según la documentación de SAP):

ln -s /oracle/$ORACLE_SID/12102 /oracle/$ORACLE_SID/121_64

ln -s /oracle/PID/12102 /oracle/PID/121

• Revisar que el contenido del archivo /etc/oratab esté apuntando a la nueva base:

• Cambiar todas las variables de ambiente del usuario de SAP y de oracle que apuntan al antiguo ORACLE_HOME de 11g: (en la carpeta $HOME del usuario orapid)

/usr/bin/perl -p -i -e "s/11204/121_64/g" .*.sh

/usr/bin/perl -p -i -e "s/112_64/121_64/g" .*.sh

/usr/bin/perl -p -i -e "s/11204/121_64/g" .*.csh

/usr/bin/perl -p -i -e "s/112_64/121_64/g" .*.csh

Posteriormente se debe salir de la consola y volver a recargar las variables de ambiente.



Aplicación del sapbundle patch (Oracle® Database SAP® Bundle Patch 12.1.0.2.161018 - 201611V2)

Se debe actualizar el OPATCH y MOPATCH como se explica al principio del documento. Al interior del archivo zip del Sapbundle Patch se encuentra el archivo README.HTML el cual se debe leer y seguir el paso a paso. Pues lo que viene a continuación es lo que se pide ejecutar en dicho documento.

Tal cual como se menciona se debe también bajar el MOpatch y OPATCH desde el sitio de soporte de SAP y copiarlos a la ruta de ORACLE_HOME de 12c (allí descomprimirlos)

Nos debemos posicionarnos en la carpeta dónde tenemos todos los medios instalados y ejecutar los siguientes comandos como usuario oracle. Previamente se debe bajar la base de datos:

cd /oracle/PID/sapdata11/medios

export IHRDBMS=/oracle/PID/12102

export OHRDBMS=/oracle/PID/121

export SBPFUSER=/usr/sbin/fuser

$IHRDBMS/bin/unzip -qd $IHRDBMS/sapbundle SAP12102V2P_1611-20012297.ZIP 'SBP_12102161018_201611/OPatch/*'

mv $IHRDBMS/OPatch $IHRDBMS/OPatch-pre-SBP_12102161018_201611

mv $IHRDBMS/sapbundle/SBP_12102161018_201611/OPatch $IHRDBMS/OPatch

$IHRDBMS/bin/unzip -qd $IHRDBMS/sapbundle SAP12102V2P_1611-20012297.ZIP 'SBP_12102161018_201611/MOPatch/*'

test -d $IHRDBMS/MOPatch && mv $IHRDBMS/MOPatch $IHRDBMS/MOPatch-pre-SBP_12102161018_201611

mv $IHRDBMS/sapbundle/SBP_12102161018_201611/MOPatch $IHRDBMS/MOPatch

$SBPFUSER $IHRDBMS/bin/oracle

Como root es importante posteriormente  ejecutar el siguiente comando:

slibclean

Luego como orapid ejecutar lo que finalmente parchará nuestros binarios:

env ORACLE_HOME=$IHRDBMS $IHRDBMS/MOPatch/mopatch.sh -v -s SAP12102V2P_1611-20012297.ZIP

(Evidencia de ejecución:)

Luego Se levanta la base de datos de esta manera:

env ORACLE_HOME=$OHRDBMS sqlplus “/as sysdba”

SQL> startup

De lo contrario la aplicación de los archivos sql dará el siguiente error:

Connecting to database...

Connecting to database...failed.

Reason: ORA-01034: ORACLE not available

Prerequisite check failed:

Cause: The database instance has not been started or the Oracle

       environment variables have not been set correctly.

Action: Verify the Oracle environment variables and ensure that the

       database instance has been started.

catsbp completed with errors, post-installation of this SAP Bundle

Patch is INCOMPLETE.  Refer to the log file

 $ORACLE_BASE/cfgtoollogs/sqlpatch/SAP201611_APPLY_PID_2017_02_14-18-04-47.log

for more information.

Overall Status: INCOMPLETE

Una vez tengamos arriba la base procedemos a aplicar los archivos sql:

env ORACLE_HOME=$OHRDBMS $OHRDBMS/sapbundle/SBP_12102161018_201611/catsbp

Evidencia de la ejecución:

Actividades finales

• Cambiar en el archivo de parámetros al original que respaldamos al comienzo y cambiar el parámetro compatible al valor predeterminado:

SQL> alter system set compatible='12.1.0.2.0' scope=spfile ;

• Aplicar estos cambios que son parte de la nota de sapbundle patch:

ALTER SYSTEM SET "_FIX_CONTROL"=

'5099019:ON','5705630:ON','6055658:OFF','6120483:OFF','6399597:ON','6430500:ON',

'6440977:ON','6626018:ON','6972291:ON','7168184:OFF','7658097:ON','8937971:ON',

'9196440:ON','9495669:ON','13077335:ON','13627489:ON','14255600:ON','14595273:ON',

'18405517:2','20355502:8','14846352:OFF','22540411:ON','20107874:OFF','10038517:OFF'

COMMENT='SAP_12102161018_201611 RECOMMENDED SETTINGS'

SCOPE=SPFILE;

ALTER SYSTEM SET EVENT=

'10027',

'10028',

'10142',

'10183',

'10191',

'10995 level 2',

'38068 level 100',

'38085',

'38087',

'44951 level 1024'

COMMENT='SAP_121022_201503 RECOMMENDED SETTINGS'

SCOPE=SPFILE;

• Actualizar catalogo RMAN (upgrade necesario puesto que de no realizarse esto los respaldos no serán catalogados fallara):

• Relinkear librería de TSM en el nuevo ORACLE_HOME de 12c

ln -sf /usr/tivoli/tsm/client/oracle/bin64/libobk64.a $ORACLE_HOME/lib/libobk64.a

ln -sf /usr/tivoli/tsm/client/oracle/bin64/libobk64.a $ORACLE_HOME/lib/libobk.a

# Por si la ruta de instalación del TDP es distinta:

ln -sf /opt/tivoli/tsm/client/oracle/bin64/libobk.so $ORACLE_HOME/lib/libobk64.a

ln -sf /opt/tivoli/tsm/client/oracle/bin64/libobk.so $ORACLE_HOME/lib/libobk.a

• Subir el listener y modificar en el archivo listener.ora en la línea:

(ORACLE_HOME = /oracle/PID/112_64)

Que apunte al nuevo home que en este caso sería:

(ORACLE_HOME = /oracle/PID/12102)

• Entregar la clave del usuario SYSTEM a la gente de SAP o en su defecto cambiarla e informarselas. Las herramientas de BRTOOLS de sap utilizan este usuario

Consideraciones adicionales

El usuario orapid y pidadm deben ocupar el mismo ORACLE_HOME. Si uno de ellos ocupa la carpeta /oracle/PID/121_64 y el otro ocupa /oracle/PID/12102 como ORACLE_HOME (aunque la primera carpeta sea un link simbolico de la segunda). Uno de los dos usuarios no podrá conectarse al motor de base de datos por sqlplus. Atención con eso (uno de los usuarios verá esto aunque la instancia de BD siga arriba):

Ambos ORACLE_HOME de ambos usuarios deben apuntar directamente a la carpeta o al link simbolico. Es decir deben tener ambos usuarios deben tener en su profile el mismo valor y no distintos.

(Ver la siguiente nota al respecto: http://www.felipedonoso.cl/2017/02/ojo-con-los-link-simbolicos-en-los.html)

Eso es todo espero haya sido de ayuda ☺