Thursday Jul 30, 2015

SQL Monitoring - Limitation at 300 lines per statement

One of the best parts of my job at Oracle:
I still learn something new every day.

Yesterday I've learned from my colleague from Oracle Switzerland, Thomas Teske, that SQL Real Time Monitoring has an embedded default limitation on the number of lines in the statement. If the limit (default: 300 lines) is exceeded the statement won't be monitored. We both work with a leading Swiss company and we wanted to monitor a complex plan. 

Now you may think: Who the heck has statements longer than 300 lines?
Well ... sometimes that is beyond your influence as in this particular case this is of course done by the application.


SQL> alter system set "_sqlmon_max_planlines"=800 scope=both;

or set in your spfile:


This limitation is described in:

MOS Note:1613163.1
How to Monitor SQL Statements with Large Plans Using Real-Time SQL Monitoring?

If you'd like to read a bit more about SQL Real Time Monitoring please follow one of these links - and be aware that it's part of the Tuning Pack license and VERY helpful in many everyday situations. You'll have to have STATISTICS_LEVEL either TYPICAL (the default) or ALL and CONTROL_MANAGEMENT_PACK_ACCESS='DIAGNOSTIC+TUNING' (the default as well).



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


« August 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