20.6.3 Combining Rights Models

What do you think would happen when a definer rights program calls an invoker rights program? Or vice versa? The rules are simple:

• If a definer rights program calls an invoker rights program, the rights of the calling program's owner apply while the called program executes.

• If an invoker rights program calls a definer rights program, the rights of the called program's owner apply while the called program executes. When control returns to the caller, invoker rights resume.

To help keep all this straight in your head, just remember that definer rights are "stronger" than (take precedence over) invoker rights.

Here are some files on the O'Reilly web site that you can use to explore the nuances of the invoker rights model in more detail:

invdefinv.sql and invdefinv.tst

Two scripts that demonstrate the impact of the precedence of definer rights over invoker rights.

invdef_overhead.tst

Examines the overhead of reliance on invoker rights (hint: runtime resolution is slower than compile-time resolution).

invrole.sql

Demonstrates how a change in roles can affect how object references are resolved at runtime.

irdynsql.sql

Explores some of the complexities involved in using invoker and definer rights with dynamic SQL.

20.7 Hardware for PL/SQL: Bigger = Better?

Let's close out this chapter with a few observations about server hardware and its effect on PL/SQL performance. Typically, database server hardware is one of the following:

• A single-processor computer

• A symmetric multiprocessor (SMP) computer

• A "clustered" computer

Oracle, like any software that runs on SMP or clustered machines, won't automatically benefit from extra processors. Only when the software is carefully crafted to delegate computing tasks to different CPUs will those extra processors pay off. The smart programmers at Oracle have done a lot of work to enable the server to exploit multiprocessing hardware.

Not all Oracle editions have this capability, though. To take advantage of SMP hardware, you must be using either the Enterprise edition or the Personal edition of Oracle. The one exception to this rule has to do with bulk data loads; all editions of Oracle are capable of parallelizing loads on SMP machines. To take advantage of clustered computers, you must not only be running Oracle's Enterprise edition, you must also license an extra option called Real Application Clusters (RAC) in Oracle9i, or Oracle Parallel Server (OPS) prior to that.

But will the extra expense translate into better PL/SQL performance? Let's look at the three major processor families.

20.7.1 The Single-Processor Variation

If you're a lone developer running Oracle on a desktop machine, you're probably running Oracle on a single-processor computer. In this configuration, most computing tasks—including the execution of PL/SQL programs—are threaded through a single CPU. Modern operating systems schedule the CPU to rapidly cycle among multiple tasks so that they appear to be running concurrently.

In a single-processor arrangement, you may well be "compute-bound"—that is, you have unused memory capacity and disk throughput, but not enough CPU speed. In this case, the upgrade path on a single-processor machine might be to get a faster processor. However, given a well-tuned application running with sufficient memory and disk I/O bandwidth, fast single-processor machines can still provide Oracle database service for hundreds of simultaneous users, at least for some applications.

If you do upgrade the processor speed or power in a single-CPU machine, your PL/SQL will almost certainly experience a performance upgrade. Processing power doesn't automatically improve disk I/O, but a lot of PL/SQL's runtime performance depends on the raw speed of the CPU.