Saturday, November 14, 2015

Patchmgr to upgrade Exadata database Nodes.


Updating Database Nodes with patchmgr
--------------------------------------
*) Starting with Exadata release 12.1.2.2.0, Oracle Exadata database nodes (running
releases later than 11.2.2.4.2), Oracle Exadata Virtual Server nodes (dom0), and Oracle
Exadata Virtual Machines (domU) can be updated, rolled back, and backed up using
patchmgr. You can still run dbnodeupdate.sh in standalone mode, but performing the
updates by running patchmgr enables you to run a single command to update
multiple nodes at the same time; you do not need to run dbnodeupdate.sh separately
on each node. patchmgr can update the nodes in a rolling or non-rolling fashion.

For patchmgr to do this orchestration, you run it from a database node that will not be updated itself.

*) Getting and Installing dbserver.patch.zip

Starting with release 12.1.2.2.0 a new dbserver.patch.zip file will be available for
running dbnodeupdate from patchmgr. The zip file contains patchmgr and
dbnodeupdate.zip. Unzip the dbserver.patch.zip file and run patchmgr from there.
Do not unzip dbnodeupdate.zip. Always check My Oracle Support note 1553103.1 for
the latest release of dbserver.patch.zip.

or Download .

Patch 21634633: DBSERVER.PATCH.ZIP ORCHESTRATOR PLUS DBNU - ARU PLACEHOLDER

*) When using the ISO file for the update, it is recommended that you put the ISO file in the same directory
where you have dbnodeupdate.zip.

Behavior for Non-Rolling Upgrades
The behavior for non-rolling upgrades is as follows:
- If a node fails at the pre-check stage, the whole process fails.
- If a node fails at the patch stage or reboot stage, patchmgr skips further steps for
the node. The upgrade process continues for the other nodes.
- The pre-check, patch/reboot, and complete stages are done in parallel.

The notification alert sequence is:
1. Started (All nodes in parallel)
2. Patching (All nodes in parallel)
3. Reboot (All nodes in parallel)
4. Complete Step (Each node serially)
5. Succeeded (Each node serially)

Updating database nodes using patchmgr is optional. You can still run
dbnodeupdate.sh manually. If you get any blocking errors from patchmgr when
updating critical systems, it is recommended that you perform the update by running
dbnodeupdate.sh manually.

./patchmgr -dbnode dbnode_list -dbnode_precheck -dbnode_loc patch_file_name -dbnode_version version
./patchmgr -dbnode dbnode_list -dbnode_precheck -dbnode_loc http://yum-repo/yum/ol6/EXADATA/dbserver/12.1.2.2.0/base/x86_64/ -dbnode_version 12.1.2.2.0.date_stamp
./patchmgr -dbnode dbnode_list -dbnode_precheck -dbnode_loc ./repo.zip -dbnode_version 12.1.2.2.0.date_stamp

./patchmgr -dbnode dbnode_list -dbnode_backup

./patchmgr -dbnode dbnode_list -dbnode_upgrade -dbnode_loc patch_file_name -dbnode_version version
./patchmgr -dbnode dbnode_list -dbnode_upgrade -dbnode_loc http://yum-repo/yum/ol6/EXADATA/dbserver/12.1.2.1.0/base/x86_64/ -dbnode_version 12.1.2.2.0.date_stamp -rolling
./patchmgr -dbnode dbnode_list -dbnode_upgrade -dbnode_loc ./repo.zip -dbnode_version 12.1.2.2.0.date_stamp -smtp_from "
Example of a rolling update using yum http repository:
# ./patchmgr -dbnode dbnode_list -dbnode_upgrade -dbnode_loc http://yum-repo/yum/ol6/EXADATA/dbserver/12.1.2.1.0/base/x86_64/ -dbnode_version 12.1.2.2.0.date_stamp -rolling

Example of a non-rolling update using zipped yum ISO repository:
# ./patchmgr -dbnode dbnode_list -dbnode_upgrade -dbnode_loc ./repo.zip -dbnode_version 12.1.2.2.0.date_stamp

No comments:

Post a Comment