The Oracle Database 12c Release 2 (12.2) learning process continues. I’m determined to get to the bottom of all this new multitenant stuff. 🙂
Here’s the latest batch of articles.
So the last one is actually for 12.1, but I hadn’t written about it already, so I added it.
I also updated this article to include the “CONTAINERS Hint” feature functionality.
There is a new feature listed in the docs as as “Support for PDBs with Different Character Sets, Time Zone File Versions, and Database Time Zones in a CDB”. I’ve already written about the PDB character set stuff and it is also listed separately as a new feature. The time zone stuff works in 12.1, so it doesn’t appear to be a 12.2 new feature. The different Time Zone File Versions functionality, as far as I can see, relates to OCI client connections to the server and was introduced in 11.2. With all that in mind, I’m really not sure what this listed new feature specifically relates to. If someone can clear that up for me I would be really grateful, as I’m wondering if I’ve just missed the point somewhere. 🙂
I’ve added these to the list of all my multitenant articles here.
I’ve continued playing with some of the new multitenant functionality in Oracle Database 12c Release 2 (12.2).
Here’s the latest batch of articles.
This article is not a multitenant article as such, but you can use the functionality in a PDB.
I’ve added these to the list of all my multitenant articles here.
Some things happened to me yesterday which I thought I would pass on, in case it helps others. This is not necessarily a criticism of the Multitenant architecture itself, but more about my
misuse of it. 🙂
I’ve complained numerous times about the inclusion of the shared APEX installation used with the Multitenant option. I’m sure it is great for some companies that provide APEX as a service, but it’s not the right option for me. I would typically recommend removing it before you create a PDB, as described here. So what did I do yesterday? I banged out a script as a variant of a non-CDB build and totally forgot about the shared installation. When everything was finished I patted myself on the back, then noticed my mistake. 🙁 I had to remove the PDBs from 3 instances, remove the shared APEX installations, the recreate the PDBs. Luckily it was early on in the process, so it wasn’t a great drama. It would have been significantly more annoying if I hadn’t noticed for a few days!
Next up I nearly cloned a PDB, which would have left me with 2 PDBs in the instance, and potentially a big bill for the Multitenant option. I was literally about to hit the return key when I realised what I was doing. 🙁 Needless to say I immediately added a trigger to all my instances to prevent any future stupidity on my part. You can see what I did here. As I say in the article, I’m not sure if there is some hidden long term tracking of the maximum number of PDBs in a CDB, but I’m a paranoid type… 🙂
As an aside, I also noticed that when I add a new PDB to a CDB it takes Cloud Control 13c a long time to notice the PDB is there. I did try to give it a nudge by doing the following, but it didn’t seem to notice.
- Highlight the CDB in the database target list.
- Click the “Configure” button.
- Scroll down and click the “Sync Pluggable Databases” button.
It didn’t recognise the change, even though it was clear in the V$PDBS and CDB_PDBS views. Not sure if this is normal or if I just got unlucky. Everything looks OK now… 🙂
It’s been over 2 years since 12c was released and there still seems to be a lot of confusion about the pluggable database stuff. I think most people know the top-level concept, there’s only so many times you can see the memory stick analogy before it gets burned on your skull, but that doesn’t do much to help with the reality of working with it day-to-day.
I’ve written a whole bunch of articles on pluggable databases (listed here), but even then I think there is quite a bit of text for what in many cases is a feature that consists of a single statement. 🙂
I’ve recently been pushing out some videos on this stuff and I’ve got some more already recorded for release while I’m at OOW. Of course, the articles allow you to copy/paste your way through an example, but I think the videos give a more accurate representation of just how simple some of this stuff is from a functional perspective. If you are interested, all the multitenant stuff will be added to this playlist as it is released.
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.
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 (188.8.131.52) 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 184.108.40.206 installation.
- Upgrade the existing 220.127.116.11 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.
- 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… 🙂
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.
- 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.
- 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. 🙂
* 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.
When I wrote about the remote cloning of PDBs, I said I would probably be changing some existing articles. Here’s a change I’ve done already.
There are also new articles.
I’m sure there will be some more little pieces coming out in the next few days…
As I mentioned before, the multitenant option is rounding out nicely in this release.
I mentioned in a previous post that I would be revisiting some of my existing multitenant articles to include some of the features introduced in the 18.104.22.168 patch. Here’s one of them.
Not only have Oracle fixed the bug in 22.214.171.124 that prevented the remote cloning, but they’ve also added the ability to clone directly from non-CDB style instances, giving you another option for migrating from non-CDBs to PDBs. Pretty darn cool if you ask me! 🙂
Some more stuff will be amended over the coming days. If the changes result in some major rewrites I’ll probably blog about them. If not, I’ll just slip them into the articles and make a reference to the fact the specific feature was introduced in 126.96.36.199…
From a technology perspective, the Multitenant option is really cool, but it can be rather difficult to get to grips with some aspects of it. Everything is so intertwined and every feature in 12c somehow links back to the Multitentant option. As I’ve been working my way through the features the same pattern keeps repeating.
- Write an article on a feature X.
- Put it live.
- Move on to looking at feature Y.
- Notice something about feature Y that affects the article I’ve written about feature X.
- Go back and revise the article on feature X.
- Rinse and repeat.
This pattern has made me rather reluctant to post anything on the blog about new articles, because although I don’t release articles until I think they are finished, all these Multitenant articles feel very much like a work-in-progress. I fully expect to step back and revise/rewrite all of them as I figure more out about this stuff.
The first link is not so much an article, more of a links page. I originally wanted to write about Multitenant as a single article. Looking back now that is quite laughable. Ten articles in and I’ve barely scratched the surface. As I keep adding more content, I’ll keep adding it to the overview article, so it remains the index page for the option.
I’ve said it before and I’ll say it again, it’s going to take a long time to get fully up to speed with this option, so you really need to start learning about it now!