Let’s take a look at the new features that Oracle introduced in 12.1.0.2. Even though this is not a major release of Oracle, it is still packed with new features, especially in the world on multi-tenancy. The enhancements made to pluggable databases are really attractive. Here’s a brief overview of the new features in pluggable databases:

  • FDA Support for CDBs
  • PDB CONTAINERS Clause
  • PDB File Placement in OMF
  • PDB Logging Clause
  • PDB Metadata Clone
  • PDB Remote Clone
  • PDB Snapshot Cloning Additional Platform Support
  • PDB STANDBYS Clause
  • PDB State Management Across CDB Restart
  • PDB Subset Cloning

Every DBA should know how to leverage these commands. DBAs need to add this list of commands in their arsenal.

NewImage

Additional commands for your toolkit:
free –g (Memory free in Gigabytes)
free –g –s 1 (Display free in Gigabytes, update every second)

sar -u 2 10 (Report CPU utilization for each 2 seconds. 10 lines are displayed.)


Oracle Storage Cloud Service is an Infrastructure as a Service (IaaS) offering, which provides an enterprise scale object storage solution for all size files and unstructured data. You can leverage Oracle Storage Cloud Service to backup content and even Oracle Database(s) to an offsite location. We can programmatically store and retrieve content, and share content with others.

Oracle Storage Cloud Service stores data as objects within a flat hierarchy of containers. An object is most commonly created by uploading a file. It can also be created from ephemeral unstructured data. Objects are created within a container. A single object can hold up to 5 GB of data, but multiple objects can be linked together to hold more than 5 GB of contiguous data.

A container is a user-created resource, which can hold an unlimited number of objects, unless you specify a quota for the container. At a super high-level, you can think of containers like a directory in a file system except it cannot be nested.

Object storage provides an optimal blend of performance, scalability, and manageability when storing large amounts of unstructured data. Multiple storage nodes form a single, shared, horizontally scalable pool in which data is stored as objects (blobs of data) in a flat hierarchy of containers. Each object stores data, the associated metadata, and a unique ID. You can assign custom metadata to containers and objects, making it easier to find, analyze, and manage data. Applications use the unique object IDs to access data directly via REST API calls. Object storage is simple to use, performs well, and scales to a virtually unlimited capacity.

Oracle Storage Cloud Service provides a low cost, reliable, secure, and scalable object-storage solution for storing unstructured data and accessing it anytime from anywhere. It is ideal for data backup, archival, file sharing, and for storing large amounts of unstructured data like logs, sensor-generated data, and VM images.

In this post, I am providing a comprehensive shell script called curl.ksh script that can be used with Oracle Storage Cloud Service to early upload, download, maintain and query the contents of the storage cloud service.

In a nutshell, the korn shell script accepts for the first argument the command to:
1. ls (to list out the directory)
2. get (to download a file)
3. mkdir (to create a container directory)
4. put (to upload a file with the curl command)
5. jput (to upload a file with the java uploadcli Jar file)
6. pjput (to upload a file in parallel and in segments for large files over 5GB leveraging the java uploadcli Jar file)
7. del ( to delete a file )

The second argument will be the container name (or name of the directory. The last argument is the name of the file that we are uploading, downloading, listing or deleting.

The script executed without any arguments will display the authentication token to be used.

$ ./curl.ksh
*   Trying 129.152.172.1...
* Connected to viscosityxxxx.storage.oraclecloud.com (129.152.172.1) port 443 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_AES_128_CBC_SHA
* Server certificate: *.storage.oraclecloud.com
* Server certificate: VeriSign Class 3 Secure Server CA - G3
* Server certificate: VeriSign Class 3 Public Primary Certification Authority - G5
> GET /auth/v1.0 HTTP/1.1
> Host: viscosityxxxx.storage.oraclecloud.com
> User-Agent: curl/7.43.0
> Accept: */*
> X-Storage-User: Storage-viscosityxx:charles.kim@v.com
> X-Storage-Pass: xxxxxyyxxzzzz
> 
< HTTP/1.1 200 OK
< date: 1461554947509
< X-Auth-Token: AUTH_tk41223c8f481b0e5e42c47f1617560f54
< X-Storage-Token: AUTH_tk41223c8f481b0e5e42c47f1617560f54
< X-Storage-Url: https://storage.us2.oraclecloud.com/v1/Storage-viscosityxxxx
< Content-Length: 0
< Server: Oracle-Storage-Cloud-Service
< 
* Connection #0 to host viscosityxx.storage.oraclecloud.com left intact

Behind the scene, curl is logging in with the userid and password that is stored in the curl.conf configuration file. Because we provided the userid and password, Oracle Storage Cloud Service provides a temporary authentication token. Future request to the service must be leveraged through the supplied authentication token. The line that has the key words "X-Auth-Token" and "X-Storage-Token" has the authentication token that we need. This authentication token expires after 30 minutes.

curl.conf configuration file has three parameters:

DOMAIN=viscosityxxxx
USER=charles.kim@v.com
PW=xxxxxyyxxzzzz

The DOMAIN parameter is the identity domain. Account creation results in creation of an identity domain (IDM slice) for that customer that is leveraged across all Oracle Public Cloud Services (and across all data centers). During the Oracle Public Cloud Services account setup process, the customer needs to create an account and specify an account name. Using the specified account name, that the identity domain will be implicitly created.

There is one manual step that is required. The parameter named AUTH must be manually specified from the OS. Consideration was made to place the AUTH parameter in the curl.conf configuration file but because the authentication token expires in 30 minutes, I made the choice to make it a manaul process to manually set the AUTH parameter from the OS. Earlier I mentioned that by executing ./curl.ksh without any arguments will display the "X-Auth-Token" and "X-Storage-Token" value. We need to manually export the AUTH parameter to the authentication token as shown below:

export AUTH=AUTH_tk41223c8f481b0e5e42c47f1617560f54

The curl.ksh script leverages the AUTH environment variable for all curl invocation. For calls that are made with java, the userid and password will be required. You will be prompted for the password to your account when invoking the java to load files with the uploadcli.jar. Here's what the curl.ksh script looks like:

 cat curl.ksh
export INMETHOD=$1
export NEWCONTAINER=$2
export FILE=$3

. curl.conf

export METHOD=$(echo $INMETHOD |tr '[a-z]' '[A-Z]')

if [ "$METHOD" = "" ]; then
  echo "Executing: curl -v -s -X GET -H "X-Storage-User: Storage-${DOMAIN}:$USER" -H "X-Storage-Pass: $PW" https://${DOMAIN}.storage.oraclecloud.com/auth/v1.0 "
  curl -v -s -X GET -H "X-Storage-User: Storage-${DOMAIN}:$USER" -H "X-Storage-Pass: $PW" https://${DOMAIN}.storage.oraclecloud.com/auth/v1.0 
elif [ "$METHOD" = "LS" ]; then
  echo "Executing:  curl -s -X GET -H "X-Auth-Token: $AUTH" https://storage.us2.oraclecloud.com/v1/Storage-${DOMAIN}/$NEWCONTAINER?limit64"
  curl -s -X GET -H "X-Auth-Token: $AUTH" https://storage.us2.oraclecloud.com/v1/Storage-${DOMAIN}/$NEWCONTAINER?limit64
elif [ "$METHOD" = "GET" ]; then
  echo "curl -v -s -X GET -H "X-Auth-Token: $AUTH" -o $FILE https://storage.us2.oraclecloud.com/v1/Storage-${DOMAIN}/$NEWCONTAINER/$FILE"
  curl -v -s -X GET -H "X-Auth-Token: $AUTH" -o $FILE https://storage.us2.oraclecloud.com/v1/Storage-${DOMAIN}/$NEWCONTAINER/$FILE
elif [ "$METHOD" = "MKDIR" ]; then
  [ "$NEWCONTAINER" = "" ] && ( echo "Directory Name must be provided:  $NEWCONTAINER"; exit; )
  curl -v -s -X PUT -H "X-Auth-Token: $AUTH" https://storage.us2.oraclecloud.com/v1/Storage-$DOMAIN/$NEWCONTAINER
elif [ "$METHOD" = "DEL" ]; then
  [ "$NEWCONTAINER" = "" ] && ( echo "Directory Name must be provided:  $NEWCONTAINER"; exit; )
  echo "curl -v -s -X DELETE -H "X-Auth-Token: $AUTH" https://storage.us2.oraclecloud.com/v1/Storage-$DOMAIN/$NEWCONTAINER/$FILE"
  curl -v -s -X DELETE -H "X-Auth-Token: $AUTH" https://storage.us2.oraclecloud.com/v1/Storage-$DOMAIN/$NEWCONTAINER/$FILE
elif [ "$METHOD" = "PUT" ]; then
  [ "$NEWCONTAINER" = "" ] && ( echo "Directory Name must be provided:  $NEWCONTAINER"; exit; )
  [ "$FILE" = "" ] && ( echo "File Name must be provided:  $FILE"; exit; )
  curl -v -X DELETE -H "X-Auth-Token: $AUTH"  https://storage.us2.oraclecloud.com/v1/Storage-$DOMAIN/$NEWCONTAINER/$FILE
elif [ "$METHOD" = "JAVAPUT" -o "$METHOD" = "JPUT" ]; then
  [ "$NEWCONTAINER" = "" ] && ( echo "Directory Name must be provided:  $NEWCONTAINER"; exit; )
  [ "$FILE" = "" ] && ( echo "File Name must be provided:  $FILE"; exit; )
  java -jar uploadcli.jar -url https://storage.us2.oraclecloud.com/v1/Storage-${DOMAIN} -user $USER -container $NEWCONTAINER $FILE
elif [ "$METHOD" = "PJAVAPUT" -o "$METHOD" = "PJPUT" ]; then
  [ "$NEWCONTAINER" = "" ] && ( echo "Directory Name must be provided:  $NEWCONTAINER"; exit; )
  [ "$FILE" = "" ] && ( echo "File Name must be provided:  $FILE"; exit; )
  java -jar uploadcli.jar -url https://storage.us2.oraclecloud.com/v1/Storage-${DOMAIN} -user $USER -container $NEWCONTAINER -segment-size 1000 -max-threads 16 $FILE
fi


The Upload CLI is a Java-based CLI tool that simplifies uploading to Oracle Storage Cloud Service. To download the java uploadcli.jar file, visit the http://www.oracle.com/technetwork/topics/cloud/downloads/index.html page. Look for the Oracle Storage Cloud Service Upload CLI section, and download the tool. Here's some of the key features provided by the uploadcli.jar file:

  • Optimized uploads through segmentation and parallelization to maximize network efficiency and reduce overall upload time
  • Support for both object storage and archive storage
  • Automatic checksum verification on upload
  • Upload individual files, groups of files, and entire directories
  • Automatic retry on failures
  • Resume interrupted uploads of large files

To leverage the uploadcli.jar file, the minimum requirements are that you must be at JRE 7 or later.

Please note that this script is evolving and will be updated periodically. The main idea of this script was to make the userid, password, domain, container, and file input to be parameterized leveraging a configuration file and parameters so that we can make the process relatively painless.

In Part 2 of this series, we will go through each of the examples to upload files, delete files, and download files from Oracle Storage Cloud Service. We will fully exploit the curl.ksh shell script and provide screen shot example output of each of the scenarios.

In Part 3 of this series, we will go through step-by-step process of downloading, installing and configuring the OPC Install Jar File. We will configure RMAN for backups to Oracle Public Cloud (OPC) and run through each of the scenarios for backup to OPC and restore/recovery from OPC.



In this post, I will walk through the steps to apply the January 2016 PSU to the latest release of Oracle (12.1.0.2). In this post, we will apply Patch 22191349 – Oracle Grid Infrastructure Patch Set Update 12.1.0.2.160119 (Jan2016) to both the Grid Infrastructure and Oracle Database Home.

Notes:
1. From CPUJan2016 onwards, the 5th digit of the version number will be changed to reflect the release date in the format YYMMDD. See My Oracle Support Document 2061926.1 for more information.
2. The GI System patch includes updates for both the Clusterware home and Database home that can be applied in a rolling fashion.

This patch is Data Guard Standby First Installable – See Section 2.5, “Installing Database PSU in Standby-First Mode” for more information.

In our example, we did not create any databases prior to applying the PSU. This will a typical installation method for Viscosity consultants where we will create a custom database leveraging dbca.

In general, when we invoke opatchauto, opatch will patch both the GI stack and the database software stack. Since we do not have a database running, patch will skip the database software stack and only apply the PSU to the GI Home. Before we invoke the opatchauto command, let’s create the ocm.rsp response file by executing the OCM Installation Response Generator (emocmrsp).

[root@vnarac01 ~]# . oraenv
ORACLE_SID = [root] ? +ASM1
The Oracle base has been set to /u01/app/oracle
[root@vnarac01 ~]# 
[root@vnarac01 ~]# 
[root@vnarac01 ~]# export PATH=$PATH:/u01/app/12.1.0/grid/OPatch
[root@vnarac01 ~]# opatchauto apply /u01/app/oracle/soft/22191349 -ocmrf /tmp/ocm.rsp
OPatch Automation Tool
Copyright (c)2014, Oracle Corporation. All rights reserved.

OPatchauto Version : 12.1.0.1.10
OUI Version        : 12.1.0.2.0
Running from       : /u01/app/12.1.0/grid

opatchauto log file: /u01/app/12.1.0/grid/cfgtoollogs/opatchauto/22191349/opatch_gi_2016-03-25_15-13-49_deploy.log

Parameter Validation: Successful

Configuration Validation: Successful

Patch Location: /u01/app/oracle/soft/22191349
Grid Infrastructure Patch(es): 21436941 21948341 21948344 21948354 
DB Patch(es): 21948344 21948354 

Patch Validation: Successful
Grid Infrastructure home:
/u01/app/12.1.0/grid


Performing prepatch operations on CRS Home... Successful

Applying patch(es) to "/u01/app/12.1.0/grid" ...
Patch "/u01/app/oracle/soft/22191349/21436941" successfully applied to "/u01/app/12.1.0/grid".
Patch "/u01/app/oracle/soft/22191349/21948341" successfully applied to "/u01/app/12.1.0/grid".
Patch "/u01/app/oracle/soft/22191349/21948344" successfully applied to "/u01/app/12.1.0/grid".
Patch "/u01/app/oracle/soft/22191349/21948354" successfully applied to "/u01/app/12.1.0/grid".

Performing postpatch operations on CRS Home...  Successful

Apply Summary:
Following patch(es) are successfully installed:
GI Home: /u01/app/12.1.0/grid: 21436941,21948341,21948344,21948354

opatchauto succeeded.

Now we are going to attempt to apply the PSU to the database software home. You will encounter an error message indicating that the opatch that you are invoking must be from the same $ORACLE_HOME as the target HOME that is being patched.

[root@vnarac01 ~]# opatchauto apply /u01/app/oracle/soft/22191349 -oh /u01/app/oracle/product/12.1.0/dbhome_1 -ocmrf /tmp/ocm.rsp 
opatchauto must run from one of the homes specified
opatchauto returns with error code 2
[root@vnarac01 ~]# exit
logout

Next we will apply the PSU to the database home. Again as root, first set the PATH to include the OPatch directory to the $ORACLE_HOME/OPatch directory. This time when we invoke the opatchauto command, we will pass another parameter -oh to specifically patch the database Oracle Home.

vnarac01:/u01/app/oracle/soft
+ASM1 > su - root
Password: 
[root@vnarac01 ~]# cd /u01/app/oracle/product/12.1.0/dbhome_1/OPatch
[root@vnarac01 OPatch]# export PATH=$PATH:/u01/app/oracle/product/12.1.0/dbhome_1/OPatch
[root@vnarac01 OPatch]# opatchauto apply /u01/app/oracle/soft/22191349 -oh /u01/app/oracle/product/12.1.0/dbhome_1 -ocmrf /tmp/ocm.rsp 
OPatch Automation Tool
Copyright (c)2014, Oracle Corporation. All rights reserved.

OPatchauto Version : 12.1.0.1.10
OUI Version        : 12.1.0.2.0
Running from       : /u01/app/oracle/product/12.1.0/dbhome_1

opatchauto log file: /u01/app/12.1.0/grid/cfgtoollogs/opatchauto/22191349/opatch_gi_2016-03-25_15-32-22_deploy.log

Parameter Validation: Successful

Configuration Validation: Successful

Patch Location: /u01/app/oracle/soft/22191349
Grid Infrastructure Patch(es): 21436941 21948341 21948344 21948354 
DB Patch(es): 21948344 21948354 

Patch Validation: Successful
User specified the following DB home(s) for this session:
/u01/app/oracle/product/12.1.0/dbhome_1


Performing prepatch operations on RAC Home (/u01/app/oracle/product/12.1.0/dbhome_1) ... Successful

Applying patch(es) to "/u01/app/oracle/product/12.1.0/dbhome_1" ...
Patch "/u01/app/oracle/soft/22191349/21948344" successfully applied to "/u01/app/oracle/product/12.1.0/dbhome_1".
Patch "/u01/app/oracle/soft/22191349/21948354" successfully applied to "/u01/app/oracle/product/12.1.0/dbhome_1".

Performing postpatch operations on RAC Home (/u01/app/oracle/product/12.1.0/dbhome_1) ... Successful

[WARNING] The local database(s) on "/u01/app/oracle/product/12.1.0/dbhome_1" is not running. SQL changes, if any, cannot be applied.

Apply Summary:
Following patch(es) are successfully installed:
DB Home: /u01/app/oracle/product/12.1.0/dbhome_1: 21948344,21948354


opatchauto succeeded.


Session Title: Data Guard Attack!!
Session Number: 1580
Speakers: Charles Kim, Oracle ACE Director and Nitin Vengurlekar, Oracle ACE Director
Track: Database
Session Type: Hands-on Lab
Sub-Categorization: High Availability & Data Protection

Abstract
There is no reason why Data Guard setup, configuration, maintenance and monitoring cannot be setup As A Service. Automation is the crux of any rapid deployment and cloud models. Setting up Data Guard should be a service catalog for any DBaaS deployment.

You will also learn the new Data Guard features available in Oracle Database 12.2

Download the latest and greatest Data Guard automation toolkit from http://dbaexpert.com/dg/ prior to attending this session. We have incorporated industry best practices to the DG Toolkit. This session will disseminate fundamental Data Guard best practices and demonstrate how DBAs can automate setup, configuration, and monitoring of Data Guard environments with assistance from the Date Guard Toolkit (DG Toolkit).

In this hand-on deep dive session, we will go through step by step details of setting up Data Guard with the automation toolkit:
o Building the Physical Standby
o Monitoring and Maintaining the Physical Standby
o Configuring Data Guard Broker
o Performing Backup and Recovery with RMAN
o Setting Archive Retention
o Performing Switchovers and Failovers

Learning Objectives:

1. Most importantly, learn how to build the physical standby with ease and automation using the DG Toolkit
2. Learn how to monitor the physical standby database with DG Toolkit
3. Learn how to monitor the physical standby database with DG Toolkit

Outline / Content Structure:
Perform preliminary check prior to starting the Data Guard Build
1. Perform assessments on the source database
2. Perform assessments on the physical standby

Perform detailed steps to build the physical standby database
1. Look at building the physical standby with easy menu steps
2. Look at duplicating the physical standby database

Configure the Data Guard Broker

Perform monitoring of the Data Guard Environment
1. Monitor the physical standby for performance
2. See how far behind we are

Perform RMAN to disk configuration options


Oracle Database Backup Service is a secure, scalable, on-demand storage solution for backing up your Oracle databases to Oracle’s Cloud. In a nutshell, Oracle databases are backed up to Oracle Cloud using the Oracle Database Cloud Backup Module. The Oracle Database Cloud Backup Module Can be downloaded from Oracle Technology Network (OTN) and is tightly integrated with Recovery Manager (RMAN). Because of the tight integration with RMAN, DBAs and architects can continue to use their familiar RMAN commands for backup and restore operations. DBAs can specify retention policies, perform cross-check operations, and even delete backups using their familiar RMAN commands.

To leverage Oracle Database Backup Service, you must be running at at least Oracle Database 10g Release 2 (10.2) to leverage Oracle Database Backup Service. You must first download the Oracle Database Cloud Backup Module from OTN and install it on the local target server:
http://www.oracle.com/technetwork/database/availability/oracle-cloud-backup-2162729.html

Oracle Database Cloud Backup Module is supported only for 64-bit architectures and for the following Linux, Solaris, SPARC, HP-UX, AIX, zLinux, and Windows operating systems.

Oracle ensures that data stored in Oracle Database Backup Service Cloud is redundant. Within Oracle Database Backup Service Cloud, data is automatically replicated to three separate physical machines. Oracle leverages this triple mirroring technique to prevent data loss in the event of hardware catastrophe.

All backups made to Oracle Cloud must be encrypted. You can leverage RMAN to encrypt your backup before it’s sent over the internet to Oracle Cloud. Oracle will only accept secure backups and reject a RMAN backup if it not secured.

Oracle Wallet Keys are stored locally on-premise at your data center. One thing to note is that keys are not in the cloud.


Here’s a simple script to look at the v$recovery_process view:


The following dg_check_lag.ksh script can be leveraged to monitor a Data Guard environment and to send alerts if the apply lag or transport lag exceeds a specified threshold in the dg_check_lag.conf file. In our example, the dg_check_lag.conf file specifies a threshold of three hours. If we encounter a lag in redo transport or apply lag that exceeds 3 hours, we send an alert to our DG DBAs.

Contents of the dg_check_lag.ksh script:

 

Contents of dg_check_lag.conf:
HR_THRESHOLD=03

Contents of .ORACLE_BASE

This file must exist in the $HOME directory for Oracle. We source the .ORACLE_BASE file because some companies have crazy standards to where they place ORACLE_BASE and where they place all their shell scripts. We keep it simple by leveraging our own configuration file which points to where ORACLE_BASE is located and where all the shell scripts reside in.


First, download and apply the patch patch: 6880880 from support.oracle.com or from https://updates.oracle.com/download/6880880.html

Download the latest PSU from Doc ID 756671.1. Unzip the PSU, cd to the directory, and check for one-off patch conflict detection and resolution.

[oracle@dal66a 20299023]$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./
Oracle Interim Patch Installer version 12.1.0.1.7
Copyright (c) 2015, Oracle Corporation.  All rights reserved.

PREREQ session

Oracle Home       : /u01/app/oracle/product/12.1.0/dbhome_2
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0/dbhome_2/oraInst.loc
OPatch version    : 12.1.0.1.7
OUI version       : 12.1.0.2.0
Log file location : /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/opatch/opatch2015-05-16_17-46-46PM_1.log

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.
[oracle@dal66a 20299023]$ opatch lsinv
Oracle Interim Patch Installer version 12.1.0.1.7
Copyright (c) 2015, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/12.1.0/dbhome_2
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0/dbhome_2/oraInst.loc
OPatch version    : 12.1.0.1.7
OUI version       : 12.1.0.2.0
Log file location : /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/opatch/opatch2015-05-16_17-46-58PM_1.log

Lsinventory Output file location : /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/opatch/lsinv/lsinventory2015-05-16_17-46-58PM.txt

--------------------------------------------------------------------------------
Local Machine Information::
Hostname: dal66a
ARU platform id: 226
ARU platform description:: Linux x86-64

Installed Top-level Products (1): 

Oracle Database 12c                                                  12.1.0.2.0
There are 1 products installed in this Oracle Home.


There are no Interim patches installed in this Oracle Home.


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

OPatch succeeded.

Make sure that all databases are down from the Oracle Home that you are patching. Also, ensure that the database listeners are down from the same Oracle Home; otherwise, you will encounter the following error from opatch as you attempt to apply the PSU:

Prerequisite check "CheckActiveFilesAndExecutables" failed.
The details are:


Following executables are active :
/u01/app/oracle/product/12.1.0/dbhome_2/bin/oracle
/u01/app/oracle/product/12.1.0/dbhome_2/lib/libclntsh.so.12.1
UtilSession failed: Prerequisite check "CheckActiveFilesAndExecutables" failed.
Log file location: /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/opatch/opatch2015-05-16_17-47-06PM_1.log

OPatch failed with error code 73

Shutdown all databases and listeners that you are applying the patch for

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
[oracle@dal66a 20299023]$ ps -ef |grep -i tns
root        15     2  0 14:31 ?        00:00:00 [netns]
oracle    4067     1  0 16:45 ?        00:00:00 /u01/app/oracle/product/12.1.0/dbhome_2/bin/tnslsnr LISTENER -inherit
oracle    4074     1  0 16:45 ?        00:00:00 /u01/app/oracle/product/12.1.0/dbhome_2/bin/tnslsnr DBATOOLS -inherit
oracle    6046  3362  0 17:48 pts/0    00:00:00 grep -i tns
[oracle@dal66a 20299023]$ lsnrctl stop dbatools

LSNRCTL for Linux: Version 12.1.0.2.0 - Production on 16-MAY-2015 17:48:12

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

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dal66a)(PORT=1522)))
The command completed successfully


[oracle@dal66a 20299023]$ lsnrctl stop listener

LSNRCTL for Linux: Version 12.1.0.2.0 - Production on 16-MAY-2015 17:48:22

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

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dal66a)(PORT=1521)))
The command completed successfully

Now we can apply the latest PSU

[oracle@dal66a 20299023]$ opatch apply
Oracle Interim Patch Installer version 12.1.0.1.7
Copyright (c) 2015, Oracle Corporation.  All rights reserved.


Oracle Home       : /u01/app/oracle/product/12.1.0/dbhome_2
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/12.1.0/dbhome_2/oraInst.loc
OPatch version    : 12.1.0.1.7
OUI version       : 12.1.0.2.0
Log file location : /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/opatch/opatch2015-05-16_17-48-29PM_1.log

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   19769480  20299023  

Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
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



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


Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying sub-patch '19769480' to OH '/u01/app/oracle/product/12.1.0/dbhome_2'

Patching component oracle.rdbms.deconfig, 12.1.0.2.0...

Patching component oracle.xdk, 12.1.0.2.0...

Patching component oracle.tfa, 12.1.0.2.0...

Patching component oracle.rdbms.util, 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.xdk.parser.java, 12.1.0.2.0...

Patching component oracle.oraolap, 12.1.0.2.0...

Patching component oracle.xdk.rsf, 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.ldap.rsf, 12.1.0.2.0...

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

Verifying the update...
Applying sub-patch '20299023' to OH '/u01/app/oracle/product/12.1.0/dbhome_2'
ApplySession: Optional component(s) [ oracle.has.crs, 12.1.0.2.0 ]  not present in the Oracle Home or a higher version is found.

Patching component oracle.tfa, 12.1.0.2.0...

Patching component oracle.rdbms.deconfig, 12.1.0.2.0...

Patching component oracle.rdbms.rsf, 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.rdbms.rsf.ic, 12.1.0.2.0...

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

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

Verifying the update...
Composite patch 20299023 successfully applied.
Log file location: /u01/app/oracle/product/12.1.0/dbhome_2/cfgtoollogs/opatch/opatch2015-05-16_17-48-29PM_1.log

OPatch succeeded.

Let’s confirm that the PSU was successfully applied

[oracle@dal66a 20299023]$ opatch lsinventory |grep ^Patch
Patch  20299023     : applied on Sat May 16 17:49:12 CDT 2015
Patch description:  "Database Patch Set Update : 12.1.0.2.3 (20299023)"

Now let’s load the modified SQL files into the database. We need to execute Datapatch to complete the post-install SQL deployment portion of the PSU

[oracle@dal66a OPatch]$ ./datapatch -verbose
SQL Patching tool version 12.1.0.2.0 on Sat May 16 17:56:55 2015
Copyright (c) 2015, Oracle.  All rights reserved.

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

Connecting to database...OK
Bootstrapping registry and package to current versions...done
Determining current state...done

Current state of SQL patches:
Bundle series PSU:
  ID 3 in the binary registry and not installed 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:
    20299023 (Database Patch Set Update : 12.1.0.2.3 (20299023))

Installing patches...
Patch installation complete.  Total patches installed: 1

Validating logfiles...
Patch 20299023 apply: SUCCESS
  logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/20299023/18703022/20299023_apply_TOOLSDEV_2015May16_17_57_25.log (no errors)
SQL Patching tool complete on Sat May 16 17:57:31 2015

Look for future blog post on applying the same patch against the Oracle Grid Home. This is where the fun really begins as we will be leveraging opatchauto instead of opatch.