You may have heard that PL/SQL is an "interpreted" language, yet it's quite common for books like this one to refer to PL/SQL's "compiler." So is PL/SQL interpreted or compiled? It's not too far off to say that it is halfway between the two. You do send your source code through a compiler, and the compiler produces machine-dependent bytecode. At runtime, the PL/SQL virtual machine inside the Oracle server interprets the bytecode. And, just to make things even more interesting, you can also have Oracle9i translate your PL/SQL into C, compile it into a shared library using the compiler native to the machine, and load this compiled version dynamically at runtime.
20.1.1 PL/SQL Concepts
Let's begin our journey under the hood with some important terms and concepts relevant to the way that Oracle processes PL/SQL source code:
PL/SQL compiler
The Oracle component that parses your PL/SQL source code, checks the syntax, resolves names, checks semantics (for example, verifies that calls to other stored programs match its "signature"), and generates two binary forms of compiled code.
DIANA
An intermediate tree-structured form of PL/SQL and its dependencies that the compiler generates for syntax and semantic analyses. This is the first of the major outputs from the compiler. DIANA includes a representation of the call specification of your stored objectsthat is, data from the program header such as parameter names, sequence, position, and datatype. Even tables, views, and sequences can have DIANA. The literal expansion of this acronym is Distributed Intermediate Annotated Notation for Ada, although Oracle's form is a variant of Ada's.
Machine-dependent pseudocode (bytecode)
The executable form of compiled PL/SQL; the second major output generated by Oracle's PL/SQL compiler, known in some Oracle documentation by the term mcode and occasionally as P-code. This is the form required by the PL/SQL runtime engine. It may be helpful to know that bytecode is roughly equivalent to a.o object file.
You may encounter (in the database build script sql.bsq, for example) references to a third form of compiled PL/SQL known as portable pcode, but Oracle no longer produces this form. It turns out that the storage space for portable pcode does get used, thoughfor the symbolic information that the PL/SQL compiler generates when you compile a program with the DEBUG option.
As a bit of an aside, you probably know that you don't really run the PL/SQL compiler the way you would run a C or even a Java compiler. Instead, Oracle calls the compiler on your behalf whenever necessary. In fact, beginning PL/SQL programmers may not even realize the compiler exists! Any time you create a stored PL/SQL program using a CREATE PROCEDURE (or whatever) statement, Oracle runs the compiler on your behalf. Later we'll take a look at the way that Oracle automatically recompiles stored code after an object it depends upon changes.
|
|
|
Despite the way that Oracle shields you from the compiler, a good PL/SQL programmer will want to have a solid understanding of what goes on behind the scenes. In addition, the concept of executing PL/SQL once it's compiled introduces additional important elements:
PL/SQL runtime engine (PL/SQL virtual machine)
The Oracle component that executes a PL/SQL program's bytecode, making calls as necessary to the server's SQL engine and returning results to the calling environment. In client-side tools such as Oracle Forms, the runtime engine typically opens a session to a remote database, communicating with the SQL engine over a networking protocol.
(Oracle) session
For server-side PL/SQL, the process and memory space associated with an authenticated user through a network or interprocess connection. Each session has its own memory area where it can hold an executing program's data. While most people think of sessions as beginning with logon and ending with logoff, there are also recursive sessionswhich have no authenticationthat Oracle uses as a temporary means of changing a user's identity. For example, Oracle always executes program units running with definer rights in recursive sessions.
To put these ideas into context, let's take a look at several variations on running a trivial program from a very common front end, SQL*Plus. This is a good representative of a session-oriented tool that gives you direct access to the PL/SQL environment inside the Oracle database server. (We introduced SQL*Plus and showed how to use it with PL/SQL back in Chapter 2.) Of course, in your shop, you may also be calling the server from other tools such as Oracle's other client-side tools or even a procedural language such as Perl, C, or Java. But don't worry; processing on the server side is relatively independent of the client environment.
PL/SQL execution launched directly from SQL*Plus always involves a top-level anonymous block. While you may know that the SQL*Plus EXECUTE command converts the call into an anonymous block, did you know that SQL's CALL statement uses a (simplified) kind of anonymous block? Actually, until Oracle9i's direct invocation of PL/SQL from SQL, all PL/SQL invocations from SQL used anonymous blocks.
So let's begin with a look at the simplest possible anonymous block:
BEGIN NULL;END;... and find out just what happens when you send this block to the Oracle server (Figure 20-1).
