Today database consolidation and resource saving get even more important.
Resource saving means license saving – and in the end you could save a lot of money!
A few years ago we observed, that it is a waste of resource and money to build a database for every single test and dev environment that we were using in our company.
I think the most of you agree with me, that 90% of the non-production databases were idle most of the time.
Until 12.1 and the introduction of Multitenant, the first and only option to consolidate was schema based consolidation. Because MT 12.1 was newly available, we compared our most important business cases against schema consolidation and MT 12.1.
After comparing all the requirements, we had to say, that with the exception of the Backup / Restore we wouldn’t have a big benefit from the MT consolidation.
So we did the schema based consolidation and it was a great success for Mobiliar:
- We saved more than 300 databases.
- We saved the licenses of 2 physical servers or 16 cores.
But the job of the DBA becomes more complex with schema based consolidation because the most of the Oracle features are built to work on database level:
- Flashback features can’t be used.
- Restore / recovery gets more complicated.
- RMAN duplicate can’t be used to refresh the dev environments.
- Interpretation of AWR reports for performance analysis are very difficult on schema based consolidated databases.
With the new Oracle Release 12.2, the Multitenant Option becomes even better. Now you have the possibility to work in most cases with a PDB like a non CDB database
- Flashback on PDB level is possible now.
- AWR Reports on PDB level are available.
- PDB Hot Cloning is working – which is of course the biggest change compared to 12.1.
So as part of the Multitenant reference program and member of the annually MT round table @OOW we had the possibility to test the new functions already in the beta release.
With 12.2 we can fulfill the business and operational requirements.
We will move away from schema consolidation to Multitenancy in 12.2!
What are the next steps?
Although we did schema based consolidation, we had a strict separation between different application schemas. In my opinion, that’s a must, because if you start to grant access and make connections over different application schemas, you probably get into big trouble if you try to migrate into pluggable databases.
Because all databases are already on 126.96.36.199, we have multiple possibilities
to migrate from schema or non CDB databases to pluggable databases.
- For full database conversion, the DBMS_PDB.DESCRIBE package can be used
- Datapump or subset cloning (188.8.131.52) can be used to migrate from schema to PDB
- Remote clone of a non CDB database to CDB and convert with
In my opinion, one big challenge with Multitenant is the capacity planning.
You have to analyze, which applications are perfect candidates to move into the same container.
In order to get this information, we can use the data from our homegrown Mobiliar Performance Warehouse. More information about that is available in this blog article:
So finally, in the near future I will start with the migration of the first databases and I will keep you up to date with our experiences that we make and the problems or even bugs that we will happen to encounter on the way.