The Clustered Variation
Clustering is a way to join multiple computers, each with its own CPU and memory, so that they can divide and conquer large jobs. Prior to Oracle9i, the optional feature for this was named Oracle Parallel Server (OPS). As of Oracle9i, the new and improved technology is known as Real Application Clusters (RAC). With both technologies, Oracle runs separate instances on each machine in the cluster, and these instances communicate among themselves to respond to application requests while sharing a common database on disk.
One of Oracle's advertised improvements of RAC over OPS is the ease with which applications can take advantage of the extra hardware. Oracle marketing literature asserts that you can "scale up your applications without changing a line of code." However, the fine print says that you may first need to do two things:
· Design the database to take advantage of RAC
· Partition the application to distribute the workload
Then, as the database grows in size, you should be able to scale by adding another node to the cluster. If the number of users grows, though, you may need to repartition the application. To tell you the truth, I have not had a chance to test any of Oracle's claims in this area.
Another advertised benefit of running Oracle on clustered computers is increased availability—the database will keep running even if one of the computers in the cluster goes belly-up. With OPS or RAC, some of these benefits are available automatically, while deeper support (such as transparently preserving a user's session and even preserving incomplete transactions) requires configuring additional database features. Through Oracle8i, the relevant feature was called Oracle Parallel Fail Safe, but in Oracle9i it was replaced by Real Application Clusters Guard. These topics, while extremely important to some sites, are outside the scope of this book, so check Oracle's documentation for more information.
20.8 What You Need to Know
Do you really need to remember everything in this chapter? I certainly hope not, though your database administrator probably does. In addition to satisfying healthy curiosity, my goal in presenting this material was to help allay any misgivings programmers might have about what happens under the hood. Whether or not you've ever had such concerns, there are a number of important points to remember about PL/SQL's runtime architecture.
· To avoid compilation overhead, programs you plan to use more than a few times should be put in stored programs rather than stored in files as anonymous blocks.
· In addition to their unique ability to preserve state throughout a session, PL/SQL packages offer performance benefits. You should put most of your extensive application logic into package bodies.
· If you don't want to bother learning how to query Oracle's data dictionary, you should probably be using a front-end developer's tool of some kind.
· While Oracle's automatic dependency management approach relieves a huge burden on developers, upgrading applications on a live production database should be undertaken with great care.
· Oracle's sophisticated approaches aimed at minimizing the machine resources needed to run PL/SQL occasionally need a little help from developers and DBAs—for example, by explicitly freeing unused user memory or pinning objects in memory.
· When you OPEN an explicit cursor in a PL/SQL program, be sure to CLOSE it as soon as you are through fetching.
· Native compilation of PL/SQL may not offer any performance advantages for SQL-intensive applications, but it can significantly improve the performance of compute-intensive programs.
· Calling remote packages entails some special programming considerations if you want to take advantage of anything in the package other than procedures, functions, types, and subtypes.
· If you are using Oracle's client-side tools, putting reusable client-side code into PL/SQL libraries generally makes sense.
· Use definer rights to maximize performance and to help simplify the management and control of privileges on database tables. Use invoker rights to address particular problems (for example, programs that use dynamic SQL and that create or destroy database objects).
· Faster CPUs, more memory, and better disk I/O will improve PL/SQL performance, but taking advantage of parallel computing still requires conscious design effort.
Chapter 21. Object-Oriented Aspects of PL/SQL
PL/SQL has always been a language that supports traditional procedural programming styles such as structured design and functional decomposition. Using PL/SQL packages, it is also possible to take an object-based approach, applying principles such as abstraction and encapsulation to the business of manipulating relational tables. Later version of Oracle have introduced direct support for object-oriented programming (OOP), providing a rich and complex type system, complete with support for type hierarchies and "substitutability."
In the interest of summarizing this book-sized topic into a modest number of pages, this chapter presents a few choice code samples to demonstrate the most significant aspects of object programming with PL/SQL. These cover the following areas:
· Creating and using object types
· Inheritance and substitutability
· Type evolution
· Pointer (REF)-based retrieval
· Object views
Among the things you won't find in this chapter are:
· Comprehensive syntax diagrams for SQL statements dealing with object types
· Database administration topics such as importing and exporting object data
· Low-level considerations such as physical data storage on disk
I'd like to introduce the topic with a brief history.
21.1 Introduction to Oracle's Object Features
First released in 1997 as an add-on to Oracle8 (the so-called "object-relational database"), the "objects option" allowed developers to extend Oracle's built-in datatypes to include abstract datatypes. Oracle8's introduction of programmer-defined collections (described in Chapter 11) also proved useful, not only because application developers had been looking for ways to store and retrieve arrays in the database, but also because PL/SQL provided a new way of querying collections as if they were tables. While there were other interesting aspects of the Oracle8 object model such as pointer-based navigation, there was no notion of inheritance or dynamic polymorphism, making the object-relational features of Oracle8 an option that drew few converts from (or into) the camp of true OOP believers. The complexity of the object features, plus a perceived performance hit, also limited uptake in the relational camp.
Oracle8i introduced support for Java Stored Procedures, which not only provided the ability to program the server using a less proprietary language than PL/SQL, but also made it easier for the OOP community to consider using stored procedures. Oracle provided a way to translate object type definitions from the server into Java classes, making it possible to share objects across the Java/database boundary. Oracle released 8i during a peak of market interest in Java, so hardly anyone really noticed that Oracle's core object features were not much enhanced—except that Oracle quietly began bundling the object features with the core database server, meaning that using the features required no additional license fees. Around this time, I asked an Oracle representative about the future of object programming in PL/SQL, and the response was, "If you want real object-oriented programming in the database, use Java."
With Oracle9i, though, Oracle has significantly extended the depth of its native object support, becoming a more serious consideration for OO purists. Inheritance and polymorphism have become available in the database, and PL/SQL has gained new object features. Does it finally make sense to extend the object model of our system into the structure of the database itself? Should we repartition existing middleware or client applications to take advantage of "free stuff" in the database server? As Table 21-1 shows, Oracle has made great strides, and the move may be tempting. The table also shows that a few desirable features still aren't available.[1]
[1] Perhaps I should say arguably desirable features. The missing features are unlikely to be showstoppers.
| Table 21-1. Significant object programming features in the Oracle database | ||||
| Feature | Oracle8 | Oracle8i | Oracle9i Release 1 | Oracle9i Release 2 |
| Abstract datatypes as first-class database entity | 
|
|
|
|
| Abstract datatypes as PL/SQL parameter |
|
|
|
|
| Collection-typed attributes |
|
|
|
|
| REF-typed attributes for intra-database object navigation |
|
|
|
|
| Implementing method logic in PL/SQL or C |
|
|
|
|
| Programmer-defined object comparison semantics |
|
|
|
|
| Views of relational data as object-typed data |
|
|
|
|
| Compile-time or static polymorphism (method overloading) |
|
|
|
|
| Ability to "evolve" type by modifying existing method logic (but not signature), or by adding methods |
|
|
|
|
| Implementing method logic in Java |
|
|
| |
| "Static" methods (executes without having object instance) |
|
|
| |
| Relational primary key can serve as persistent object identifier, allowing declarative integrity of REFs |
|
|
| |
| Inheritance of attributes and methods from a user-defined type |
|
| ||
| Dynamic method dispatch |
|
| ||
| Non-instantiable supertypes, similar to Java-style "abstract classes" |
|
| ||
| Ability to evolve type by removing methods (and adding to change signature) |
|
| ||
| Ability to evolve type by adding and removing attributes, automatically propagating changes to associated physical database structures |
|
| ||
| "Anonymous" types: ANYTYPE, ANYDATA, ANYDATASET |
|
| ||
| Downcast operator (TREAT) and type detection operator (IS OF) available in SQL |
|
| ||
| TREAT and IS OF available in PL/SQL |
| |||
| User-defined constructor functions |
| |||
| "Private" attributes, variables, constants, or methods | ||||
| Inheritance from multiple supertypes | ||||
| Sharing of object types or instances across distributed databases without resorting to object views |
Unless you're already a practicing object-oriented programmer, many of the terms in Table 21-1 probably don't mean much to you. However, the remainder of this chapter should shed some light on these terms and give some clues about the larger architectural decisions you may need to make.
21.2 An Extended Example
I'd like to point out that this example—indeed, most of this chapter—relies heavily on features introduced in Oracle9i. In a number of areas, this section focuses on features available only in Oracle9i Release 2. If you really want server-side object orientation, you probably won't want to use any version earlier than Oracle9i anyway, and you'll probably agree that ignoring the OO-challenged earlier versions is no great sacrifice.