Oracle has released its 12c database a few weeks ago. It comes with more than 500 new features, improvements and changes. You’ve read a lot about it on the web, blogs, magazines… One question still remains: Why move to Oracle Database 12c?
#1: « Because you’re looking forward to »
What will you do, in a few months, when you’ll figure out organizations will seek for people « Experienced with Oracle Database 12c »? You’d better have tried it first in your current position…
#2: « Because premier support ends on January 2015 »
You’ll start with a small development database, continue with internal-acceptance, user-acceptance and, eventually, make the move. How long would that take? A few months? A year? It will for sure depend on your applications, the number of changes involved or the new hardware infrastructure… Start now!
#3: « Because you’re busy »
You can’t deal with the growing database needs anymore: development teams want to duplicate environments to perform more tests. They want them rapidly and on-demand. Starting with DB12c they will be able to duplicate their « Pluggable » Database with a few SQL commands from SQL*Plus: they won’t even need to access the machine; they won’t either need to ask their DBA…
#4: « Because you need to match database resources with application needs »
If you have 5 to 20 databases per server, you might be using Resource Manager (DBRM) in every database but you can’t do much at the server level: instance caging or system-level technologies like cgroups, PRM, WLM don’t allow you to do a lot more than CPU resource partitioning between instances. Moreover, those technologies are difficult to set up correctly and won’t fit with your real application needs and changes.
Starting with DB12c you can use Resource Manager at the container database (CDB) and pluggable database (PDB) levels and control the following resources:
- Number of concurrent sessions
- CPU
- Ability to use Oracle parallel server processes
- File I/O (Exadata only)
You will be able to create global Resource Manager plans which fit with your application needs on predefined time basis.
#5: « Because you’re fully booked »
You are working on a new project which involves the setup of a new production database, the very same stuff than last week’s new production database. It’s going to take you a couple of hours/days to setup the database, plan and test backup jobs, configure monitoring, set up data guard, etc…
Starting with Oracle 12c, you can save most of that time using the Multitenant option: when adding a PDB, it will automatically benefit from backup procedures settled at CDB level. Moreover, when adding a PDB, it will be automatically replicated by Data Guard. In the same way, because you only patch the CDB, you will save time not patching every database individually…
Oracle says « Manage many as one »; I would add « and do the job only once ».
