Chapter 24. PL/SQL Architecture
In my experience, relatively few PL/SQL developers exhibit a burning curiosity about the underlying architecture of the PL/SQL language. As a community, we seem to mostly be content with learning the basic syntax of PL/SQL, writing our programs, and going home to spend quality time with family and friends. That’s a very healthy perspective!
I suggest, however, that all PL/SQL developers would benefit from a basic understanding of this architecture. Not only will you be able to write programs that utilize memory more efficiently, but you will be able to configure your programs and overall applications to behave in ways that you might have thought were impossible.
You will find in this chapter answers to the following questions…and many more:
How does the PL/SQL runtime engine use memory, and what can I do to manage how much memory is used?
Should I be running natively compiled code or stick with the default interpreted code? What does “native compilation” mean, anyway?
Why do my programs become INVALID and how can I recompile them back to health?
I have duplicated tables in 20 different schemas. Do I really have to maintain 20 copies of my code, in each of those schemas?
And…who or what is DIANA?