Tuesday Sep 01, 2015

Upgrade downtime credited to APEX

What do you think when you see this post-upgrade result?

Oracle Database 12.1 Post-Upgrade Status Tool           08-07-2015 15:08:26

Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS

Oracle Server                          UPGRADED  00:19:26
JServer JAVA Virtual Machine              VALID  00:10:52
Oracle Workspace Manager                  VALID  00:01:52
OLAP Analytic Workspace                   VALID  00:00:34
OLAP Catalog                         OPTION OFF  00:00:00
Oracle OLAP API                           VALID  00:00:42
Oracle XDK                                VALID  00:01:07
Oracle Text                               VALID  00:01:36
Oracle XML Database                       VALID  00:03:55
Oracle Database Java Packages             VALID  00:00:22
Oracle Multimedia                         VALID  00:03:57
Spatial                                UPGRADED  00:08:56
Oracle Application Express                VALID  00:46:19
Final Actions                                                    00:03:48

Total Upgrade Time: 01:44:16

I've got a bit worried as the time to upgrade APEX took 44% of the complete database upgrade downtime. APEX (Oracle Application Express) is a fantastic piece of software which is still completely underrated - potentially because it is for free for everybody who has an Oracle Database license. And things not costing anything are just worth nothing, ey? 

Simply be aware when you have APEX in your databases installed - and especially if you ACTIVELY use APEX - it may be a very good idea to upgrade APEX upfront without causing downtime for your entire database.

See this blog post here about how to upgrade APEX upfront:



Monday Feb 23, 2015

Upgrade the Operating System in a RAC Environment

Last week at the upgrade workshop in Budapest a customer had a interesting and - I believe - not uncommon question.

How can I upgrade my Linux Operating System in my RAC environment without taking the entire cluster down?
In this specific case the customer wanted to upgrade from RHEL 5.10 to RHEL6 or RHEL7.

Let's assume it's the typical 2-node-RAC where one wants to upgrade in a rolling fashion. And the data is stored within ASM.

  1. Drain Node 1 (i.e. take the workload off) - this will be the node getting upgraded first
  2. Remove Node 1 from the  cluster (deleteNode procedure)
  3. Upgrade the OS (which is most likely a reimaging of the node). If the OS upgrade does not wipe out the entire server you can follow MOS Note:1559762.1 as it shows an OS upgrade from OL 6.2 to 6.4 which leave the Oracle installations intact) 
  4. Add Node 1 back to the cluster (addNode procedure)
  5. Extend the Database Home to Node 1 using either cloning or addNode
  6. Make the database available on the newly added Node 1 and drain Node 2
  7. Repeat steps 2-6 for Node 2 
  8. Ideally now you'll perform a rolling upgrade of Oracle GI to Oracle Database 12c. Please apply the most recent PSU as well.
  9. Furthermore you may now look into upgrading your databases to Oracle Database as well.
See the following documentation: 

Tuesday Mar 04, 2014

Upgrade to Grid Infrastructure - but OCR and VOTING on RAW?

Just received this question from a colleague these days:

"The current customer environment is on Linux with a 2 node RAC cluster having OCR and Voting Disks on RAW devices. Customer is concerned about the possibility of upgrading to 11gR2 Grid infrastructure first before they could upgrade to 12c Grid infrastructure."

Now the answer is written down in MOS Note 1572925.1:
How to Upgrade to 12c Grid Infrastructure if OCR or Voting File is on Raw/Block Devices

Basically the MOS Note says:
You will have to relocate your OCR/Voting to a supported device BEFORE you can upgrade to Oracle Grid Infrastructure 12c. No way out. A bit more clarification (thanks to Markus Michalewicz):

The assumption of the note (which you might want to state) is that the customer has pre-12c GI with OCR / Voting Disk on RAW.

In this case, Option A is always an option.

For Option B, however, you need to distinguish. So the note should say: 

  • Option B: Customer is on 11g Rel. 2 still using RAW Devices 
    • Then move the OCR and Voting Disks to ASM
  • Option C: Customer is on pre-11g Rel. 2 and does not want to introduce a CFS (bad idea anyways) or use NFS
    • Then upgrade to 11g Rel. 2 and move the Clusterware files into ASM as mentioned under Option B.

Unfortunately another example to add to my collection of "What happens if you stay too long on older releases?". In this case it simply increases complexity and drives costs as well. And please no complaints: Oracle Database 10.2 went out of PREMIER SUPPORT in July 2010 - 3.5 years ago!!!



Mike Dietrich - Oracle Mike Dietrich
Master Product Manager - Database Upgrade & Migrations - Oracle Corp

Based near Munich/Germany and spending plenty of time in airplanes to run either upgrade workshops or work onsite or remotely with reference customers. Acting as interlink between customers/partners and the Upgrade Development.

Follow me on TWITTER

Contact me via LinkedIn or XING


« September 2015
Oracle related Tech Blogs
Slides Download Center
Visitors since 17-OCT-2011
White Paper and Docs
Viewlets and Videos
Workshop Map
This week on my Rega & Pono
Upgrade Reference Papers