I recently put some more PL/SQL new features articles live.
I’ve also posted a top-level new features article.
This contains a number smaller features as well as links to other articles on the site that discuss some of the new features in greater depth.
I’ve got a couple of PL/SQL books I’ve got to read and review, but I’ve been holding back because I wanted to get my take on this subject written before I was influenced by others. I guess I don’t have that excuse any more.
Some more 12c articles have trickled out over the last few days.
I kind-of mentioned this next thing in a post a few weeks ago, but didn’t name names. While writing an article about the PDB logging clause in 126.96.36.199 I noticed it didn’t work. I raised an SR with Oracle Support and they confirmed it was a bug. I was not planning to release the article until the bug was patched, but it came up in conversation recently and I decided it was better to release the article with a big fat warning on the top saying it doesn’t work, just so others are not as confused by this as I was. I’m still not sure it is the right thing to do, but what the heck…
When the bug is patched, I will revise the article and probably promote it to the front page of the website as a “new article”. For now it is lurking in the depths of my website.
The 12c journey continues…
A few more 12c articles went live over the last few days…
The DMU and In-Database Archiving are from the OCP syllabus. The Invisible Columns stuff seemed like a natural thing to mention, when discussing the In-Database Archiving.
The 12c journey continues…
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.
I think I’ve lived through all the ages of Enterprise Manager. I used the Java console version back in the days when admitting you used it got you excommunicated from the church of DBA. I lived through the difficult birth of the web-based Grid Control. I’ve been there since the start of Cloud Control. I’ll no doubt be there when it is renamed to Big Data Cloud Pixie Dust Manager (As A Service).
I was walking from the pool to work this morning, checking my emails on my phone and it struck me (not for the first time) that I’m pretty much a 24 hour DBA these days. I’m not paid to be on call, I’m just a 9-5 guy, but all my Cloud Control notifications come through to my phone and tablet. I know when backups have completed (or failed). I know when a Tnsping takes too long. I know when we have storage issues. I know all this because Cloud Control tells me.
Now you might look on this as a bad thing, but being the control freak I am, I prefer to get a message on a Sunday telling me something is broken, hop on the computer and fix it there and then, rather than coming in on Monday to a complete sh*t-storm of users complaining. I’m not paid to do it, but that’s the way I roll.
While walking down memory lane I was thinking about all the scripting I used to do to check all this stuff. Endless amounts of shell scripts to check services and backups etc. I don’t do hardly any of that these days. Cloud Control handles all that.
We are a pretty small Oracle shop, but I think life would be a whole lot more difficult without Cloud Control. I’ve mentioned this a number of times, but it’s worth saying again… If you have more than a handful of Oracle databases, you really should be using Cloud Control these days. It’s as simple as that.
Just in case you are wondering, this is how our infrastructure looks this morning…
I wrote about the Code Based Access Control (CBAC) stuff in Oracle Database 12c a while back.
I’ve recently “completed the set” by looking at the INHERIT PRIVILEGES and BEQUEATH CURRENT_USER stuff for PL/SQL code and views respectively.
It’s pretty cool, but I’m not sure how much of it I will see in the wild as it will require developers to do a bit more thinking, rather than doing what they’ve always done…
There’s a neat little change to the Automatic Diagnostics Repository (ADR) in Oracle 12c. You can now track DDL operations and some of the messages that would have formerly gone to the alert log and trace files are now written to the debug log. This should thin out some of the crap from the alert log hopefully. Not surprisingly, ADRCI has had a minor tweak so you can report this stuff.
You can see what I wrote about it here:
Of course, the day-to-day usage remains the same, as discussed here:
I’ve been having a play with Oracle Linux 7 beta over the weekend. Not surprisingly my first thoughts were to install the Oracle database on it.
As expected, the installations were almost identical or Fedora 19.
I’ve put a warning on the front of the OL7 articles, but I’m sure it won’t stop some Muppets using it in production then trying to blame me.
I don’t know how long it will be until OL7 goes to production and I’m sure it will be a long time before anything is certified against it, but it’s always nice to see what’s coming… I’ll update the articles when anything significant happens…
I’ve recently put some new Oracle 12c articles on the website.
The privilege usage stuff is really cool. Normally, trying to figure out what you can remove from a user is always a complete pain in the ass. Some of the databases I’m currently working with have used GRANT like it’s going out of fashion. Trying to identify what is really necessary is a tough job. Features like this are going to be hard to wait for…