Tag: pdb

PDB Logging Clause… Again…

About 14 months ago I spotted a problem with the PDB Logging Clause. I opened an SR and several months later I got a patch, which unfortunately didn’t fix the issue, just altered the symptom somewhat. I wrote about that patch here.

Yesterday I got a new patch, which actually does fix the problem, so now the PDB Logging Clause works as documented!

I’ve updated the PDB Logging Clause article to reflect the change.

I realise it’s a small issue, with an easy workaround, but 14 months seems a bit excessive. 🙂

Cheers

Tim…

Multitenant : PDB CONTAINERS Clause

I forgot to mention, I put another multitenant article live at the weekend.

I’m not sure I will ever use it, but it’s good to know it’s there.

I was originally working on an article on a completely different multitenant feature, but the examples I was using highlighted a bug, which kind-of scuppered that article. I’ve raised an SR and I’m waiting on the acknowledgement and possible fix. I’ll hold that article back until the fix is in place.

Cheers

Tim…

To PDB or not to PDB : The final decision

After yesterday’s to PDB or not to PDB post, I decided the answer was “to PDB”. Here’s what I did…

  • Installed the Oracle 12c (12.1.0.2) software. There is an installation article here, but all I had to do was a software-only installation because the OS already met all the prerequisites because of the existing 11.2.0.3 installation.
  • Upgrade the existing 11.2.0.3 instance. See here. I could have stopped at this point, but as I said I decided “to PDB”. 🙂
  • Created an empty CDB instance on the box using “dbca”.
  • Created a new PDB as a remote clone of the non-CDB instance, as described here.
  • Turned off the non-CDB instance.

Job done. So far it’s looking good. I’m going to do some messing about tomorrow to make sure it registers with Cloud Control properly and the backup schedule is sorted. Then I’ll give it to the folks to test their apps against.

Thoughts:

  • I flippin’ love the remote cloning of non-CDBs. I’ve played with it while writing the article about it, but seeing it happen on a real database was really exciting.
  • I think we all realise that this is version 1.1 of the multitenant architecture. The question is, is version 1.1 good enough at this point? The testing will determine that, not my excitement levels.
  • The testing will be based on our use of the DB. We are a small operation with quite simple needs. If we choose to go this route it will be because it is right for us. Depending on your usage, your experience may be different.
  • If things don’t work out with this POC, we will try with the non-CDB instance.

So it was kind-of exciting, fun and scary all rolled into one… 🙂

Cheers

Tim…

To PDB or not to PDB

I’m about to start a Proof of Concept (POC) for a 12c upgrade of one of our databases. The production database in question is running on Oracle Linux inside a VMware virtual machine, so the starting point I’ve been given for the POC is a clone of the whole VM…

Probably the biggest decision I’ve got to make is “to PDB or not to PDB” *. I mentioned it on Twitter earlier and got some conflicting opinions. I guess the pros and cons of the PDB approach go something like this in my head.

Pros:

  • The multitenant architecture is the future of Oracle. Depending on which rumours you believe, it’s possible that 12.2 will no longer allow the pre-12c style instances. Putting it off is delaying the inevitable.
  • As long as you only use a single PDB, there is no extra cost.
  • The multitenant architecture has some neat features related to cloning, especially remote clones. That potentially makes provisioning new environments pretty quick.
  • Even with a single PDB per CDB, there are potential advantages regarding patching and upgrades. Caveats apply as always.
  • I’m going to upgrade to a pre-12c style instance first anyway, so I will have a natural fallback position ready to go if I need it.
  • It would be good to invest the time up front to convert stuff now, rather than wait a few years to clean up the mess of CRON jobs and connections using SIDs, rather than services. This choice would force our hand.
  • If some of the technologies we are using are not going to “play well” with the multitenant architecture, I would rather know now than later.

Cons:

  • Using a PDB is definitely going to break a number of things for us, especially CRON jobs that run scripts using OS authentication. See here.
  • Once the decision has been made to “switch the multitenant architecture on”, it would be really easy for someone to create an extra PDB and incur additional licensing costs. As far as I’m aware, there is nothing to restrict the number of PDBs to 1, to prevent an uninitiated DBA from copying a script from the net and creating more. If someone knows an undocumented parameter for this I would be interested in knowing it. Note, “_max_pdbs” isn’t the answer here! 🙂
  • I’m going to upgrade to a pre-12c style instance first, so why add on the extra effort of cloning that to a PDB?
  • Why make life hard for yourself? You can use 12.1 as a half-way house and make the final step later.

I don’t think there is really a right or wrong answer in this debate. I could probably put forward a convincing argument in favour of either option. I’m leaning on the side of the “to PDB” choice. If this proves to be a no-go, then I’ll start a POC of a pre-12c style instance… 🙂

Despite my leaning for the PDB choice, I am interested to know what others think, especially those that have done something a bit more extensive than running this stuff on their laptop. 🙂

Cheers

Tim…

* I forgot to mention previously, we will almost definitely be going with a single PDB per CDB (the free option) initially. So this is not a “consolidate using multitenant” issue from the outset.

Oracle 12c Multitenant Option : CDBs and PDBs…

I started trying to play with the Oracle multitenant option (all that pluggable database stuff) a little while ago and gave up. It’s wasn’t that it was that difficult. More than anything my problem was I didn’t know what to focus on first. There is so much to it and it’s all interrelated, so you start to write about one small piece and before you know it your article has lost focus and is growing too big. As a result I decided to let it simmer in the background and start looking at some of the other smaller 12c new features first…

My next stumbling block was just about everything in 12c seems to relate back to pluggable databases in some way. So you either pretend it doesn’t exist and have gaping wholes in everything you write, or you have to bite the bullet and get to grips with pluggable databases. So back I came to pluggable databases…

Even with my new found commitment to getting to grips with it, I was still struggling to decide how to break this stuff up into manageable pieces so I could write concise articles and order my thoughts on this functionality. Writing is part of my learning process, so if I can’t see how to break down and structure the articles I’m a little lost. Then the recently released OCP syllabus came to the rescue. I always try to write revision notes for the OCP upgrade exam, so I decided the way they break it down will be my template. I’m probably going to write a separate article per bullet point, and try and keep them as directed as possible.

So the first couple of articles have gone live.

Now I’ve got a plan of attack I feel a lot happier.

As always, I will make multiple passes and keep adding things to articles as I encounter things of interest. It’s always a fine balance between being too brief on one hand or regurgitating the manual on the other. The important thing is the content constantly evolves.

The other thing to consider is the OCP syllabus is only a starting point. There is lots of cool stuff that is not on the OCP syllabus, so I’m not going to be a slave to it. As I’ve said before, the OCP syllabus is a nice framework to start you on your journey, but it is not the final goal, it’s just a stepping stone…

I’m not sure why I felt the need to write this little 12c mission statement. Probably to help me solidify in my head how I’m going to tackle the next 18 months while I’m getting to grips with this new version. So that’s the plan, until I come up with a better one… 🙂

Cheers

Tim…