Here’s an example to create a user account for Charles:

/usr/sbin/groupadd -K GID_MIN=500 -K GID_MAX=10000 ckim
/usr/sbin/useradd -g ckim -K UID_MIN=500 -K UID_MAX=10000 -c "Charles Kim" -d /home/ckim -m -s /bin/bash ckim

Then here is another example of creating a user for David:

# set -o vi
# for i in dknight; do groupadd -K GID_MIN=500 -K GID_MAX=10000 $i; /usr/sbin/useradd -g $i -K UID_MIN=500 -K UID_MAX=10000 -d /home/$i -m -s /bin/bash $i ; chage -d0 $i;echo "newpassword" | passwd --stdin $i;done
Changing password for user dknight



Here’s some of my favorite Oracle Database 12.2 Multitenant new features that I can talk about at this time. Oracle Database 12c Release 2 is slated to go live sometime this year.

Pluggable databases

  • The number of PDB limits per CDB increases to 4096 rom the limit of 252 PDBs in 12.2. Even though we do not have customers who have over 252 PDBs or even venture in this high number of PDBs, Oracle raised this limit in 12.2.
  • Resource manager will have the capability to limit the memory and govern CPU and I/O.  For RAC (or RAC One Node) services associated to a PDB, oracle will not have interconnect overhead
  • In 12.2, we will no longer need to to put the PDB in read-only mode to perform hot clones.  
  • We can refresh PDBs online.  
  • We can relocate PDBs without any downtime.  We can move PDBs from one CDB to another.  Larry Ellison in OOW 2015 did a live demo and moved a PDB from on-premise to Oracle Public Cloud.  12.2 eliminates the need to put the PDB in read-only mode.
  • Proxy PDBs are introduced.  We can have a new kind of a PDB which points to a remote PDB.  The remote PDB is presented as a local PDB and in all practical purposes looks like a local PDB with all functionality is available to the Proxy PDB.
  • All new Application Containers are introduced. Oracle revolutionizes the concept of having a single master application definition for all the tenant containers. We can make changes to just location and changes will sync to all the tenant container.

Are you up on Oracle 12.1.0.2 new features? Are you considering pluggable databases? 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.