I'm reading about Oracles PDB and CDB, and their test performances
They compare PDB with non-CDB's.
But I dont understand what a non-CDB is. Here is the definition from the document
"multiple stacked single-instance databases (non-CDBs) on the same operating system"
Is non-CDB one single Database process with several databases or
Is non-CDB several Database processes?
Best Answer
A non-CDB is anything that isn't a CDB; that is, any database before 12c, or a 12c database created without the enable pluggable database clause. If you create a non-CDB it isn't Multitentant and is a single-instance standalone like a pre-12c database.
Neither, it's a single instance (set of processes) with a single database.
The definition you quoted refers to an aspect of non-Mulitenant architecture:
So you have one or more Oracle homes (software installations), each with one or more independent databases running from that home. This was the only way to run multiple databases on the same server before 12c's container/pluggable model.
The problem with doing that is the database instances are completely independent and have no visibility of each other, so they are all competing for resources (CPU, memory, network) at operating system level, and you have to have enough resources for them all to be running at peak to avoid degraded performance, even if that is unlikely to happen often. Or don't have enough resources and one or more end up starved at some point. You don't want that happening in production, so it's generally considered a bad idea to do this in production environments.
This is also touched on in the 12c documentation:
12c's Multitenant model gives you a single container database that manages the resources at operating system level and shares them with the pluggable databases as needed, potentially significantly reducing the total resources the O/S server needs, and hiding/simplifying the management of the plugged-in dtabases.
It's somewhat analogous to running virtual machines on a physical server - the physical server needs fewer actual CPUs and less memory than are allocated in total to all the VMs, and the VM management layer controls the balancing and contention of the resources depending on the actual needs and loads of all the VMs. The VMs themselves aren't really aware of that happening, they just use what they need; similarly pluggable databases aren't really aware that the container is managing their resources rather than the operating system.