Search

OakieTags

Who's online

There are currently 0 users and 31 guests online.

Recent comments

linux

Runtime Load Balancing Advisory in RAC 12c

This is a follow-up on yesterday’s post about services in the new 12c database architecture. After having worked out everything I needed to know about TAF and RAC 12c in CDBs I wanted to check how FCF works with PDBs today. While investigating I found out that the Runtime Load Balancing Advisory does not seem to work as expected in some cases. But I’m getting ahead of myself. First of all, here is my test case:

  • Oracle Linux 6.4 x86-64
  • Grid Infrastructure 12.1.0.1.2, i.e. January 2014 PSU applied
  • RDBMS 12.1.0.1.2, likewise patched with the January PSU
  • A CDB with just 1 PDB for this purpose, named DEMOPDB
  • Service FCFSRV is used

Service setup

The service is specifically created to connect against the PDB:

Runtime Load Balancing Advisory in RAC 12c

This is a follow-up on yesterday’s post about services in the new 12c database architecture. After having worked out everything I needed to know about TAF and RAC 12c in CDBs I wanted to check how FCF works with PDBs today. While investigating I found out that the Runtime Load Balancing Advisory does not seem to work as expected in some cases. But I’m getting ahead of myself. First of all, here is my test case:

  • Oracle Linux 6.4 x86-64
  • Grid Infrastructure 12.1.0.1.2, i.e. January 2014 PSU applied
  • RDBMS 12.1.0.1.2, likewise patched with the January PSU
  • A CDB with just 1 PDB for this purpose, named DEMOPDB
  • Service FCFSRV is used

Service setup

The service is specifically created to connect against the PDB:

RAC and Pluggable Databases

In preparation of the OUGN Spring Seminar and to finally fulfill at least a part of my promise from July I was getting ready to research RAC, PDBs and services for my demos. It turned out to become a lot more interesting than I first assumed.

RAC and Multi-Tenancy

So the first attempt to really look at how this works has started with my 2 node cluster where I created a RAC database: RAC12C, administrator managed with instance RAC12C1 and RAC12C2. The database is registered in Clusterware. Clusterware and RDBMS are patched to the January PSU, i.e. 12.1.0.1.2.

Oracle Linux and MySQL

I’m in the process of taking on some of the MySQL databases in my company. The first ones are MySQL 4.1 running on Windows, so we are upgrading them to MySQL 5.6 on Oracle Linux. As with many of our systems, these will be running on VMware virtual machines.

Since the current installations are so old, we are planning on dumping out the data and creating fresh installations on the new systems. Based on the advice I got from Ronald Bradford and Sheeri Cabral, we are also taking this opportunity to switch to InnoDB and utf8, rather than MyISAM and latin1 that are currently used.

Oracle Linux UEK3, Huge Pages and VMware

For those of you using Oracle Linux with UEK3, here are a couple of important blog posts that may have passed you by.

Thanks guys!

Cheers

Tim…

Analyzing IO at the Cell level with cellcli… a new and improved script

Recently I had the pleasure of corresponding with Hans-Peter Sloot.  After looking at my simple tool in this post to gather cell IO data from cellcli, he took it a several steps further and created a nice python version that goes to the next level to pull IO statistics from the cells.

current_rw_rq.py

This script provides breaks down the IO by “Small” and “Large” as is commonly done by the Enterprise manager.  It also provides a summary by cell.  Here is a sample output from this script.

If you’re not using hugepages, you’re doing it wrong!

Well, there’s been a bit of a delay in with my planned testing of dbVisit Replicate and Oracle GoldenGate for zero-downtime upgrades. So, I’ll be (hopefully) getting back to that within a couple of weeks.

Meanwhile, I recently ran across a discussion on the Oracle OTN Community forums, asking about performance and hugepages configuration, here in the Oracle Database – General Questions Forum.

I think my answer bears repeating, so, here is a slightly modified version:

First, I’m going to take a strong position on hugepages. I’m going to go as far as to say, for any non-trivial SGA size, if you’re not using hugepages, you’re doing it wrong. There are three main points to consider.

Applying GI PSU 12.1.0.1.2 in the lab

In my previous posts about the first RAC Grid Infrastructure Patchset I document a few issues I encountered that were worth noting. But where things work as advertised I am more than happy to document it too. In a way, the January 2014 GI PSU works as you’d hope it would (at least in my lab for my 2 node cluster). Well-almost: if you have a non 12.1 database in your environment you might encounter this.

UPDATE: You might want review some additional information with regards to datapatch.

Admittedly it’s taken from an Oracle Restart (i.e. non cluster) environment but I can’t see this not happening in RAC:

Applying PSU 12.1.0.1.1 to Oracle Restart

I was actually hoping I had already written enough about applying the PSU for 12.1.0.1.0 but today I tried to apply the patch to my Oracle Restart home in my lab VM and guess what-it wasn’t as automatic as I thought.

I must have performed the classic copy & paste error and applied the patch to the GRID_HOME only. Please don’t do this! The README clearly states you can but if you do, you will run into this mess. At the time of writing there was no hit for the error on my favourite search engine, hence this post. If you see this on a real database and not on your personal lab VM you should of course consult support what to do. This is for educational purposes only, so to say.

Interesting post-install steps for Oct 2013 12.1.0.1.1 PSU

I have already written about RAC/Grid Infrastructure related patching of 12.1.0.1.0 to 12.1.0.1.1, aka the October 2013 PSU for the database.

This post is a follow-up for pure RDBMS-only installations. I initially thought it wasn’t worth blogging about it (and hence the lag between the posts) but I came across an interesting post-apply step that is required for the databases: datapatch.

This is a new tool to run post the Patch Set Update installation against the non-CDB.

UPDATE: Oracle discourages the application of the patch set for RAC/GI on Multi-Tenant.

Here is the reference output for a non-CDB: