Let's step through the operations shown in this figure.
1. Starting on the left side of Figure 20-1, the user composes the block one line at a time and then gives SQL*Plus the "go-ahead" command (a slash). As the figure shows, SQL*Plus sends the entire code block, exclusive of the slash, to the server. This transmission occurs over whatever connection the session has established (for example, Oracle Net or interprocess communication).
2. Next, the PL/SQL compiler attempts to compile this anonymous block, generating internal data structures such as DIANA to help it analyze the code and generate bytecode.[1] A first phase is to check the syntax to ensure that the program adheres to the grammar of the language. In this simple case, there are no identifiers to figure out, only language keywords. If compilation succeeds, Oracle puts the block's bytecode into a shared memory area; if it fails, the compiler will return error messages to the SQL*Plus session.
[1] Actually, if some session previously needed Oracle to compile the block, there is a good chance that the compile phase won't need to be repeated. This is because the server caches in memory and tries to share the output of relatively expensive operations like compilation.
3. Finally, the PL/SQL runtime engine interprets the bytecode and ultimately returns a success or failure code to the SQL*Plus session.
Let's add an embedded SQL query statement into the anonymous block and see how that changes the picture. Figure 20-2 introduces some of the SQL-related elements of the Oracle server.
