Rather than focussing more about the event, I will focus what was being the agenda or what what I learned from this event.
I must admit I am getting old because this cloud business is too hard to understand. You will agree with me if you see advertisements of cloud-ready, but are not able to understand anything beneath it. This event gave me the initial thoughts.
Before 12c, Oracle databases supported multi-tenancy through VPD or FGAC (whatever you prefer to call it). To use this feature, your tables needed to have extra columns to identify a tenant when he is logging in to the database. So with a single database, you could (a big COULD) support multiple clients. But it was used not for this purpose (maybe oracle knew this before). Application developers took this feature to implement user security instead. Within a client if there are multiple units of business, you could hide the irrelevant information from being shown.
 |
| New Multi tenant architecture |
 |
| What is shared, and what is not |
When you install a database normally, whatever binary and data dictionary comes with it is now called Container database. You as application developer is not supposed to touch it. This isolation of oracle structures from user structures gives 12c database the extra mileage to support multi-tenancy.
This magic is called Pluggable databases. As soon as you install a container database, a pluggable database is also installed by default. This is called a seed database from where you can create multiple copies (tenant specific). There are new features which allows creating a database from existing pluggable databases or completely new.
As an application developer/product company you could install your application in one pluggable database. We will call this BASELINE for clarity of discussion. Once this baseline is installed you can keep it as a read only one. Whenever you need a database for a client, you simply clone the baseline and your new database for client 1 is ready. All it takes is seconds/minutes depending your dbf files size.
If you have trouble in understanding the concept of Container and Pluggable databases, consider this example. Visualize container database as a PC. Pluggable databases are like users logging into the same system. They share a lot of common things like operating system binaries, programs installed etc. This is just and idea and not exactly the same, so bear with me for this terrible comparison.
Whenever you require upgradation/patch fix for oracle database, it is applied only in container database and automatically all pluggable databases are upgraded or patched. If some clients are adamant in not applying any patches, then move them to a different container database. (Yes this is possible !)
It is easier to clone and plug/unplug/drop pluggable databases, new commands have been introduced. The container database is only one copy of oracle binaries which need not be duplicated in a server intended to run multiple databases for separate clients. Only the client specific copy of application logic is to be duplicated and kept separate. Thus minimizing memory and space constraints.
One important thing to remember is that to connect to pluggable databases, service_name only can be used and not SID in tnsnames.ora [This is my initial impression, need to dig deeper to find the reason]
You can create a maximum of 252 pluggable databases in one container database.
Don't think DBAs are left with no job now. They can concentrate more on database performance instead of installing new databases for new clients. (This was a boring job anyways.)
Apart from this there are new features added for application developers. You can call PL/SQL code within WITH statement in SQL itself. You can even create functions/procedures within WITH clause and execute a SQL statement. The use of it will be when in an environment if you don't have access to create procedures you can execute such statements. Not sure when the real usability will come.
All other features (519 in total), I think are just minor ones. The VARCHAR2 support of 32767 in tables is a very minor one. It treats data as CLOB internally, but is intended to be used for migrations from other databases like SQL server/MySQL.
The INTERNAL key feature may be useful one, but only for new developments. After all who will change their code to incorporate new features like this.
One more feature is READACTION. This is developed by oracle similar to what FGAC is. FGAC works on row filtering, whereas readaction works on columns. For example if we want to mask some sensitive columns based on application logic redaction can come in handy. This is additional cost option over database, and can be installed even in Oracle 11g db.
Also the EM console is called Enterprise Manager Database Express, which helps in real time monitoring of databases.
I will share more information as and when I could write something. Till the time, happy exploring.
