Pluggable Databases - Expert Consolidation in Oracle Database 12c - page 231

Implications for the Data Dictionary
The data dictionary as we know it needed tweaking, and can now take containers into account. This can be confusing
at times, especially when you are used to typing commands quickly and without looking. Before exploring the new
data dictionary further, let's step back a little bit and review how the dictionary was used before Pluggable Databases.
When you created a new database using dbca or the scripted method, you were presented with a pristine data
dictionary. Pristine in this context means that the only rows stored in the dictionary were Oracle's own metadata. This
situation is shown in Figure 7-4
Figure 7-4. Pristine data dictionary after database creation
But since the purpose of every database is to store user data, your dictionary (and the underlying tables in the
SYS schema) started to become intertwined with user metadata. This applied to data structures within the user
table spaces, as well as source code. There is nothing wrong with this by the way, it's the price you pay for using the
database! Consider Figure 7-5 , which shows the dictionary after it has been populated with user data, such as tables,
columns, indexes, and audit information.
Figure 7-5. User data and Oracle metadata are now intertwined
There is an implication to this method of storing metadata, as you will probably recall from your operational
experience. Your stored code for example could be invalidated by modifications to the data dictionary as part of
patching. It therefore was necessary to recompile dependent code in the database if an Oracle package has been
modified by a patch.