dbi services Blog
Welcome to the dbi services Blog! This blog focuses on IT infrastructure - featuring news, troubleshooting, and tips & tricks. It covers database, middleware, and OS technologies such as Oracle, Microsoft SQL Server, Documentum, MySQL, PostgreSQL, Sybase, Unix/Linux, etc. The dbi services blog represents the view of our consultants, not necessarily that of dbi services. Feel free to comment on the postings!
Oracle 12c Backup & Recovery: What's new?
After months of waiting, Oracle Database 12c is finally available. In this posting, I am going to provide a summary of the new features of Oracle 12c in terms Backup and Recovery.
Pluggable, what else?
For sure, the most remarkable change in this brand new version is the Pluggable Database or so called Multitenant Database concept, which is a huge change in the whole RDBMS architecture.
So what does it offers in terms of Backup and Recovery?
To answer this question, let's remember how we were able to perform application consolidation up to version 11g. Basically we had 2 choices:
- Merge multiple databases in a single server
- Merge multiple applications in a single database
Theoretically, the second options was the one providing the deepest consolidation possible. We simply integrated each applications on a dedicated schema and ran it…
In theory, this was a pretty nice solution, but it also came with multiple questions:
- Is my data properly segregated?
- Could an application be disturbing another one?
- Are there security issues between the applications?
...and the most tricky one:
- How can I restore one application without touching the others?
At this point, we looked up the RMAN documentation and started sweating when we saw that this RESTORE SCHEMA did not exist. Fortunately, looking a bit deeper we were able to find a "workaround" using Tablespace Point In Time Restore.
Tablespace Point In Time Restore - did you already try that?
Believe me, this is definitively not the most friendly operation to perform on a database, especially if you are using partitioning with one tablespace per partition.
Good news, the real solution now exists! Simply create Pluggable Databases!
We could have a container database (CDB) hosting multiple pluggable databases (PDBs) with each PDB dedicated to one application. Nice, isn't it? (For more details about PDBs have a look at Yann Neuhaus' blog post)
At that point, we now have to think about securing our new environment and being able to react in case of failures. Of course, Oracle 12c integrates several new Backup and Recovery features that allow this:
- Backup (full & incremental) a whole container including all PDBs
- Skip some PDBs during the container backup
- Backup (full & incremental) a single pluggable database
- Backup only specific tablespaces in some PDBs
- Skip some specific tablespaces for some PDBs
- Complete restore of a container or a single pluggable
- Point In Time Restore of a whole container
- Point In Time Restore of a single pluggable database!
Yes: With the PDBs, you are now able to restore an application (represented by a dedicated PDB) to a previous point in time without impacting the container or any other applications / pluggable database.
RMAN still growing up
Since Oracle 9i, RMAN is growing up and extending its capabilities version after version. This is also true for Oracle Database 12c.
Up to 11g, there were already multiple elements we could restore:
- Data Files
- Corrupted Blocks
With Oracle 12c, it is now possible to restore a single table, even to a previous point in time. If I am not a huge fan of Tablespace Point In Time Restore (it can still help in some cases), the capability of restoring a table is still looking pretty interesting.
I guess that some of you have already faced issues during application patching or maintenance, where you had to bring back a specific table. If no export is available it can easily become a tough challenge. Having the possibility to get it back from a backup can make life quite easier.
Of course the problems with constraints, sequences, or triggers must still be taken into consideration, but we will have time enough to discuss that in a dedicated post about Table Restore.
A nice feature that came with Oracle 11g was the ability to duplicate a database online without using any backup. However the question usually raised while preparing such a duplicate was the impact in terms of performance on the source database, which is often the productive one.
With Oracle 12c, the notion of push and pull methods has been clarified, allowing to better control where the load and processes will mainly run.
From now on, depending on the used method, the processing will either run on the target or the auxiliary database.
Doing backup of big tablespaces or simply tablespaces composed of 20-30 GB data files is not always that easy and that effective. With Oracle 12c, a new parameter has been introduced: SECTION_SIZE.
It allows splitting data files in several pieces and multiplexing their backup across multiple channels. SECTION_SIZE is available for backup sets as well as image copies and duplicates. In case of incremental backups, RMAN can use still use the Block Change Tracking (Fast Incremental Backup) feature.
The next point is the cross-platform data transport. With Oracle 12c, it is now much easier to move data, or even a whole database from one platform to another. The cross-platform transport can now be done using backup sets or image copies.
RMAN backup command supports the TO PLATFORM and FOR TRANSPORT conditions. These allow to generate a meta-data export using Data Pump, which will permit to restore a tablespace or a whole database on a different platform. Tablespaces can now be transported between any supported platform such as Linux, Windows, AIX, Solaris or HP-UX. In case of a complete database transport, the source and destination platforms must use the same ENDIAN format, which can be checked in the view V$TRANSPORTABLE_PLATFORM.
I hope this will help some of you. See you soon for more details on Oracle 12c features