Time to show you what is the big advantage of multitenant. Then we have consolidated several datamarts into same tablespaces. I had to when we had some block corruption on the SAN (you know, because of issue 1 we did lot of online reorg of the filesystems, and SAN software had a bug) This is where I made my alternative to DBA_EXTENTS. Let me give you an example I create the same table in two schemas (DEMO1 and DEMO2) of same database.10 years ago I worked on a database that had 3000 schemas. You can think of them as specialized datamarts: same code, same data model, but different data, used by application services provided to different customers. When I think about it, the multitenant database we can have today (12c) would not have been an easy solution. I’m in multitenant here because of the second test I’ll do, but it’s the same pluggable database PDB1.I remember a telco billing software I’ve installed 15 years ago. It had nothing to do with the software name or the vendor name. Per application backend point-in-time recovery is prohibitively difficult I don’t see the point.Currently multitenant do not give us more options because pluggable database point in time recovery, nor flashback pluggable database, is currently possible in-place. You can already read about it at Of course, when using schema-based consolidation you should used different tablespaces and you have TSPITR.
Multitenant is just an easy way to force the application to use specific services. It’s still a good think when the system metadata is a lot smaller than the application metadata Cloning a single application backend is difficult Cloning a PDB is easy. Finally, multitenant is nice because of pluggable databases.
Patching the Oracle version for a single application backend is not possible Yes, plugging a PDB into a different version CDB can be faster for those applications that have lot of objects. Do you know that all occurrence of ‘multitenant’ in 12c code or documentation was ‘pluggable database’ one month before the release?
But wait a minute, I’m not talking about test environments here.
Name collision might prevent schema-based consolidation Yes some applications have a fixed schema name.
If your ERP must be installed in SYSERP schema, then you cannot install several ones in the same database. Schema-based consolidation brings weak security Same idea.