Tag: backup

Oracle Database 12c : Some Backup and Recovery Stuff

In a previous post, I had already listed an article on backup and recovery when using the Oracle 12c multitentant option.

In that article I made reference to a restriction when using flashback database against a CDB with a PDB that has had a point in time recovery. I finally got my head round this and posted a note about it here.

As well as this stuff, I’ve also had a play around with table recovery. It’s pretty cool! In previous versions you had to do a manual point in time clone to recover a table in this way. In Oracle 12c it still does this, but it has wrapped it up and hidden it behind a nice RMAN command, making it feel a lot simpler. Definitely a neat feature when you need to recover old versions data that pre-date the level of undo available.

I word of advice before you launch into playing with any of this. TAKE A SNAPSHOT OF YOUR VM!

I’ve been playing about with this stuff using Oracle 12c on Oracle Linux, running on an Oracle VirtualBox VM. You would not believe the number of times I’ve totally screwed up my databases while figuring this stuff out. I’ve recreated PDBs and CDBs a number of times. I’ve had to recover databases that I broke by accident. I’ve even had to restore a previous snapshot of the VM a couple of times to get myself back to a stable state. All this messing about is great for getting to grips with the tech, but it can be frustrating if you are only trying to investigate one specific feature. For this reason, I would say avoid trying to learn this stuff on a physical machine. Especially when learning backup and recovery, it can be a time consuming pain in the ass when you screw things up.You want to be able to get back to the start and try again as quickly as possible. This is where VM snapshots rule! Of course, if you’ve got the time to spare, you can come across some interesting things when you accidentally break things and try to fix them! 🙂

One of things I’ve noticed specifically about RMAN and PDBs is the error handling of some commands is not what it could be. Sometimes you perform a relative simple RMAN command while the PDB is closed and it gives you a “sky is falling in” type message, including the odd ORA-00600, which leads you to believe things are really screwed. You notice the PDB is closed, so you open it and hey presto, the RMAN command works just fine. Now admittedly, I was attempting to do something stupid, but a “You can’t do that when the PDB is closed dumb-ass!” message would have been a lot less scary than an ORA-00600. 🙂 I’m going to try and recreate the specific scenarios and log them on MOS so future versions can handle people doing stupid stuff a bit better. 🙂

Cheers

Tim…

Cloud Control 12c Database Backup Jobs (Continued)

I’ve been rather critical of the way Cloud Control handles database backup jobs, as can be seen in these two previous posts.

Yesterday I found out I schedule database backups in Cloud Control the “wrong way”…

So typically, when I am sorting out a new database, I do something like this:

  • If the host doesn’t already have an agent, push one out the to server.
  • Discover the targets. For existing hosts, this may just be discovering a new database.
  • Tell Cloud Control to used the RMAN catalog for backups. (Oracle Database > Availability > Backup & Recovery > Recovery Catalog Settings)
  • Set the default location for the backups and any other stuff. (Oracle Database > Availability > Backup & Recovery > Backups Settings)
  • Finally schedule the backup. (Oracle Database > Availability > Backup & Recovery > Schedule Backups…)

Notice how all the backup-related things come from the same location (Oracle Database > Availability > Backup & Recovery). Obvious right? Wrong!

So it turns out, if you schedule the backup using the (Oracle Database > Availability > Backup & Recovery > Schedule Backups…) screen, you do schedule a backup job, it works and it is visible in the (Enterprise > Job > Activity) screen, but it is not a “real” Cloud Control job. It is actually created using the job type of “Backup”, which is not a supported job type, rather than the job type “RMANScript”.

If you schedule a backup in this way, you can’t:

  • use the job library.
  • do a create-like of an existing job.
  • edit most of the details about the job after it’s created, including the RMAN script.
  • describe the job using EMCLI.

So what is the solution? Well, you do all the prep in the same way, but you don’t actually schedule the job using the (Oracle Database > Availability > Backup & Recovery > Schedule Backups…) screen. You do it directly from the (Enterprise > Job > Activity) screen. If you do it from here, then you get to pick the “RMANScript” job type and suddenly everything works much better and things seem a lot more consistent. Basically, you’ve created a “real” Cloud Control job.

So in my latest round of [enchancement requests | bug reports] I got the answer back from development that I was doing it wrong, which is good to know, and they want to close the SR. My response to that was, why do you let me do it the “wrong way”? Why does the (Oracle Database > Availability > Backup & Recovery > Schedule Backups…) screen not schedule a “real” Cloud Control job? It seems odd to me that you build a product that lets you do things inconsistently. It’s probably a throw back to the old DBConsole stuff, but that doesn’t make it any less annoying.

I’m going to recreate all my backup jobs to make them use the “RMANScript” job type, which will solve my EMCLI issues, but I really think this mess should get cleaned up. I wonder how many other people out there are not creating “real” Cloud Control jobs for their database backups?

I’m going add this blog post to my SR and see what the response is…

Cheers

Tim…