When you pick up most computer magazines, you'll find pages and pages of IS professionals that never seem satisfied with their current working environment. They always want something new in the tools, databases, operating systems, and hardware that they use. Maybe we've been conditioned by vendors in this respect with the "it'll be fixed in the next release" attitude many software houses have. However, many IS people who help drive their businesses to bigger and better things have legitimate needs that the current crop of products just do not support. The sophistication of online transaction processing (OLTP) and data warehousing applications at many corporations has quickly outstripped the abilities of the hardware and software they use, leaving many vendors scrambling to catch up. Is Oracle catching up with business or exceeding expectations with the release of Oracle8? The answer depends on whom you ask. One thing is for sure, however: Whenever a company of Oracle's stature releases a new version of its core product, nearly everyone in the industry pauses and takes notice.

A Better Mousetrap?

What is Oracle's strategy with Oracle8, and does the product satisfy existing needs that demanding businesses have? Some say we never learn anything from history. But Oracle had the advantage of seeing firsthand the experience of Informix when the Informix Universal Server was released late last year. During the initial offering of the Informix Universal Server, it seemed Informix was on top of the world. Informix (and even IBM, which was already shipping its DB2 Relational Extenders) had beaten Oracle to the punch with the release of an extendible RDBMS and was being touted as the only company with the ability to overtake Oracle in the database race. However, Informix turned in very disappointing quarter earnings in the months that followed the Universal Server release, low enough to amaze Wall Street analysts. What happened? Most analysts will tell you it didn't happen because Informix lacked a credible architecture, and it didn't happen because Oracle sales reps kept proclaiming that DataBlades could crash the Informix kernel. It happened because Informix's Universal Server didn't have a lot of buyers. DataBlades were (and still are) a very potent weapon for the RDBMS, but the demand for such an architecture in many businesses just wasn't yet there. Even the most sophisticated new mousetrap will only be bought by those people having a problem with mice.

The noise surrounding the release of Oracle8, by contrast, didn't really stress extendible datatypes, although it certainly was included with the presentations and press releases. Instead, the focus of Oracle's strategic release centered on Oracle8's power and flexibility. The people at Oracle stressed that the new offering had more power for OLTP applications in the form of increased performance and the ability to handle a greater amount of incoming user requests with more efficiency. The company also touted Oracle8's increased power for data warehousing systems by providing partitionable tables and indexes as well as support for much larger data volumes and object structures. Oracle8 also doesn't force users into a particular way of working. Do you want to use the object-oriented option of Oracle to construct object types and methods? You can do that. If you choose to continue working in the normal relational manner as supported by previous versions, however, you can do that also.

By emphasizing power and flexibility, Oracle's message went right to the heart of most IS managers and developers. Those that either create or oversee mission-critical databases may occasionally need sophisticated datatypes or special, exotic features to fulfill the needs of their business, but by and large what they want is increased performance, rock-solid stability, and a flexible, feature-rich environment in which to work. Is this what Oracle has delivered with the latest release of its flagship product? Let's take a quick tour through the product and see what stands out.

Objects

Not too long ago, there were rumblings from some respectable IS think tanks that predicted the death of the relational database as it currently existed. They felt that object databases would soon overtake the standard RDBMS architecture. Although some corporations are using pure object databases (including many scientific organizations), the mass departure from the relational model didn't happen. Oracle follows an object/relational model, an appropriate name when you begin to dig under the covers of the engine and find what object features the database supports.

To start with, Oracle8 uses objects (or to put it more broadly, user-defined types) to extend the normal relational datatype offering, allowing DBAs and developers to define complex business objects that represent components in their data architecture. Using the new create type command in Oracle8, administrators can define a wide array of user-defined datatypes or "object types" that use standard Oracle datatypes or new object features such as VARRAYs (arrays of standard Oracle datatypes that can be used as table columns) or nested tables (tables that are contained or "nested" within normal Oracle table columns). In addition to creating these object types, a developer can define methods (primarily using Oracle's PL/SQL) that are associated with the new object types thereby encapsulating the two together. Furthermore, Oracle8 provides something no other popular relational database offers with respect to objects: REFs. REFs are pointers to other objects within the database that can replace the normal referential-integrity method of using foreign keys. REFs use the object identifier for an object instead of key data.

Another object-related technique Oracle8 provides are object views. Object views allow a DBA to construct virtual objects whose underlying foundation are relational structures, which allow normal RDBMS information to be mapped to an object-structured format. This form of object-oriented implementation in Oracle lets those developers new to object-oriented methodology test the waters with standard relational database tables before jumping in with both feet and begin building new object types alone. You can still access the underlying relational structures independently.

Even though the object/relational model Oracle8 offers looks interesting, the question must still be asked, "So what?" if Oracle is to avoid the type of fiasco that wrapped its arms around Informix. How is the object/relational model useful to system architects and developers charged with building mission-critical systems? First, although object-oriented database development hasn't been widely accepted, object-oriented programming and development have. Whether the work is done in a 3GL like C++ or a 4GL tool like PowerBuilder, developers are growing more accustomed to working within the object-oriented framework and have experienced firsthand the benefits of object reuse, inheritance, polymorphism, and encapsulation. Those who enjoy this method of work will find it more intuitive to work with Oracle8 objects than the standard relational format. For C programmers, access to nested tables and the like is available within the Oracle C libraries.

Some people also believe they can find other benefits to using object/relational technology in the ability to describe real-world business entities with objects instead of the typical entity-relationship diagram. Modeling a purchase order that contains order header information in an object format and then defining an attribute of that object (which is a nested table that contains each header's line details) makes more sense and seems more efficient to many systems designers than using the more common one-to-many relational setup.

There are also promised performance boosts when working with objects. Using REFs, for example, allows a much faster mechanism of data access and retrieval than the standard relational join. Object views supposedly also increase speed due to the fact that you can fetch relational data that logically belongs to an object in one network round trip.

Some people are skeptical about using Oracle's implementation of object orientation for real object-oriented work. They point out that the product doesn't support real inheritance, for example. For Oracle, however, the strategy to ease users into object-oriented concepts may not be a bad idea. Over time, if the demand is there, Oracle is likely to support more of the typical object-oriented features. There are restrictions on how you may use indexes with Oracle8 objects. For example, you can't index a VARRAY, but you can index individual columns of a nested table, and the optimizer will use them.

Cartridges for Extendible Datatypes

Although Oracle didn't make the main focus of its new server the extended datatype, Oracle8 does have the ability to manage the complex data that a number of companies struggle with. Using the concepts of "cartridges" that "plug" into the database kernel, the Oracle8 database engine can handle complex information that comes in the form of images, video, documents, spatial and time series data, messaging, and more.

Critics point out that Oracle8 still can't handle "any" type of data like the Informix Universal Server can, and for the most part, this criticism is accurate. But Oracle covers the datatypes most in demand, and with more cartridges being announced, Oracle8 is likely to have most of the bases covered in this area.

User Scalability

Gone are the days when office workers shared a single PC in a central location to access information from a database. Today, nearly all corporate personnel are empowered with PC desktops with built-in TCP/IP networking, which gives them access to the Internet and any database server, providing they have the security rights. Naturally, this setup can cause headaches for RDBMS vendors and DBAs as they continually fight to provide the necessary scalability to accommodate growing user requests. Just recently I had to troubleshoot a capacity problem on a database server and found the GUI front end had been designed to allow a single user to open 30 or more threads to a database. Imagine 100 to 200 concurrent users doing this!

How has Oracle provided help in this area? By introducing networking assistance in the form of connection pooling and multiplexing. These new abilities allow data architects to connect extra clients to a database server without the customary 1MB-memory price tag. Connection pooling lets DBAs configure their servers to limit the amount of time idle processes spend connected to an Oracle database. Administrators know all too well the users who come in at 7 a.m., connect to the database via some startup/boot up routine, and then sit idle until four in the afternoon. Connection pooling can be set up to automatically log off these lazy threads after a predetermined time-out value and then allow a different user to reuse the empty connection slot. Of course, the question then arises as to what happens when the user finally does submit work to the database? The last thing a DBA wants is to have his or her help desk flooded with angry calls from users wondering why their connections have been cut off. However, Oracle's SQL*Net will transparently reconnect the users back to the database and either immediately execute or queue their requests.

Oracle's multiplexing feature requires the use of a module called the Connection Manager (See Figure 1). DBAs can use this Oracle component to separate the database server from incoming network requests and instead route client traffic to a different server dedicated to handling Oracle's many network connections. This allows numerous inbound requests to be combined into one outgoing message to the database server. The end result is less network traffic to the server devoted to the Oracle database.

In addition to increased performance, Oracle has finally added more manageability to its SQL*Net networking software -- something administrators who have to perform the setup and configuration of Oracle servers have been demanding for some time. Users still remember the ease of use (albeit limiting) of SQL*Net version 1 and the headaches the move to SQL*Net version 2 caused with all the confusing configuration files that were introduced. Net8, Oracle's new SQL*Net, contains setup wizards and more intuitive GUI interfaces to carry out the configuration of Oracle clients and servers.

Big and Available

Even if a database can handle a large number of concurrent users, when talks about scalability, the conversation almost always turns to size instead of numbers of users. No one can completely define what a "large" database is anymore, what with many companies data warehouses and/or data marts in the terabyte range and others making tracks toward petabytes. Almost any DBA can tell horror stories of OLTP and OLAP applications that ran just fine until some magic size volume was reached within the database and now the same applications crawl along at a snail's pace. With nearly every corporation constructing data warehouses and/or data marts, the insatiable cry for "more" from the user community has caused administrators to get creative in building structures that hold the necessary bulk of data and deliver the performance necessary to make such repositories usable.

As if this weren't difficult enough, DBAs must deal with the availability issue as well. Once the exception, 24x7 systems are now the rule. This alone can cause many IS professionals stress when dealing with the subjects of backups, downtime, and high availability. (I used to work with one DBA who was under so much pressure with these types of systems he used to keep a full gallon-sized jug of Tums in his desk drawer!)

Recognizing these needs, Oracle8 is built to address both the size and availability issues today's businesses have to deal with. First, Oracle8 now boasts the capacity to support databases up to 512 petabytes (!) in size, with each table being able to hold up to 1,000 columns. This is a significant increase from the previous 255-column limit. Next, Oracle has introduced a strategy to address the size, performance, and availability issue all in one package -- partitioning.

Database designers have for a long time turned to manual horizontal and vertical partitioning to assist with the speed/size problem, but now Oracle has a more built-in method for providing help. Oracle8 supports range partitioning, a method of horizontal partitioning that allows the data architect to select a column or columns in which the data will be divided into physical separations within the database. For example, a data warehouse table that contains information about a busy hospital's admissions would likely contain a date/time column that indicated when a patient arrived. Using Oracle8, a DBA could carve out partitions for each month/year combination that existed in the table, thereby creating many subsets of data for the end users to work with. Indexes can be partitioned just like their associated tables (for each new table partition, Oracle automatically adds a corresponding index partition), or they can be created to span multiple partitions of a table if necessary.

How does partitioning help with the performance problems you usually experience with large tables? First, Oracle8 lets DBAs place partitions in different tablespaces, which in turn, can be placed on different hard disk drives on a server, minimizing I/O bottlenecks and contention. The biggest amount of performance boost, however, will no doubt come from Oracle8's abilities to work on single partitions of a table or index when requested. For example, if a historical sales table for a year contains 1.2 million rows, and the DBA partitions the table by month, table scans of a single partition would be able to operate on 100,000 rows instead of the normal 1.2 million resulting (hopefully) in decreased response time.

Query operations aren't the only SQL that will benefit from partitioning. Table partitions can be truncated, indexed, updated, and so on with Oracle's Data Manipulation Language (DML), whose operations, once again, should run much faster because the SQL will only be working with a subset of a table instead of the whole thing. Single partitions can also be loaded with Oracle's SQL*Loader data load utility, and export/import operations can also be set up to work with partitions.

In addition to increasing performance, partitioning also helps in the area of availability. Single partitions of a table can be backed up, loaded, and recovered by themselves thereby leaving other partitions accessible to user's requests. By their very nature, large tables and indexes can cause big headaches when something gets corrupted or needs repair, and being able to analyze how the recovery processes run against such large structures is a big plus. Modifications of partitions (adding new partitions or removing existing partitions) can also be done online so users who are working with other, unaffected partitions can continue uninterrupted.

Another improvement Oracle8 offers in the area of data warehousing is its better implementation of parallel processing. Parallel processing isn't new to the Oracle RDBMS -- it started around release 7.1. Oracle8, however, extends its capability to include query parallel processing in the areas of bitmap indexes, star queries and star joins, generic index scans, and parallelism within a single query. Parallelism also provides help when partitioned tables are used to allow parallel inserts, updates, and deletes. (This type of parallel support is currently missing on normal, nonpartitioned tables.)

The final item to note with respect to higher availability with Oracle8 is a new feature added to the parallel server option of Oracle. A lot of folks get confused by the parallel server option of Oracle, which is different from the parallel query option of the database. The parallel query option is what permits user requests to be split apart by the RDBMS and processed in parallel. In contrast, the parallel server option allows multiple Oracle instances (composed of the Oracle memory structures along with the background processes that read, write, and control database actions) usually located on separate machines to access a single Oracle database that normally resides on a set of shared DASD. Typically, businesses use parallel servers to offer higher availability to critical corporate systems that must stay up no matter what. Prior to Oracle8, however, if one node failed in a parallel server setup, either the application had to be smart enough to route to another node or clients would have to reconnect manually to a surviving instance of Oracle once they discovered the outage. With Oracle8, the parallel server option now includes the capability to switch automatically to a surviving system ID (SID) when a node goes down. A user's query severed because of an instance's failing will be automatically restarted on a new node at the point where it failed, and not back at the beginning -- a process that is bound to save time. Update activity will be rolled back as normal due to a node failure, however, the user will be notified of the problem and may then reissue the request, which will be processed on the node to which he or she is now connected.

This automatic failover feature is also useful for planned maintenance activities that are a must from time to time. New mechanisms exist within the server to move transactions transparently to other nodes for maintenance so the impact to the user community is near nil. This means higher availability for systems that can't afford to be down.

An NCA World?

When Larry Ellison of Oracle finished his Oracle8 presentation at Radio City Music Hall in New York City, many wondered if the show wasn't about the network computer instead of Oracle8. The network computing architecture (NCA) is the company's thin-client, network-distributed computing scheme that Oracle would like to see overtake today's Microsoft-based world. Naturally, every network computer would connect to a back-end server running Oracle8.

The NCA world is slated to be a major showplace for Oracle cartridges, many of which will also plug in to Oracle's Web Application Server. Using the Common Object Request Broker architecture (CORBA), Oracle sees the potential for applications to scale to whatever heights a business deems necessary. Whether this is possible remains to be seen.

Naturally, there are skeptics of Oracle's NCA framework who point out that it really doesn't offer the flexibility that the Oracle sales reps would have you believe. They cite the absence of Java support at the server level in the initial release of 8 as an example of how Oracle isn't ready yet for the type of computing that Oracle claims (Oracle sources say Java will be present in version 8.1, due sometime in 1998). On many levels, though, the NCA architecture makes sense in terms of cost, manageability, and usability. Like any other piece of software or operating system, it needs time to mature.

What's Missing?

Even though Oracle's latest release is incredibly robust in many respects, there are a few chinks in Oracle8's armor. As already noted, currently missing is the Java version of the database access language, JSQL. The number of data cartridges shipping is still small. And although Oracle8 makes a strong stab at object orientation, full inheritance support isn't really available except through a somewhat awkward use of object views.

I also wonder about the effect Oracle8 will have on other somewhat intangible areas such as product support, stability, and third-party vendor participation. Oracle has done a much better job of beefing up its support organization to handle its database's wild popularity, but is the company ready for the flood of calls that will come in relating to the RDBMS's new features? Product instability rears its ugly head whenever new bells and whistles are added to a product. I vividly remember crashing a system when I first tried to use the parallel scan feature of Oracle 7.2 on a table with over a million rows -- the instance just shut down completely. After fixes were applied, the problem vanished. As any Oracle veteran who's had to wade through the choppy sea of applying Oracle patches will tell you, the issue of patch and version/compatibility management can sometimes get to be a full-time job for large Oracle shops.

Then there's the issue of third-party support. How long will it take to get the industry's leading software development tools ready to build object/relational-based systems with Oracle8? Most, if not all, have declared plans to support the object-oriented features of the RDBMS, but getting concrete dates on when their tools will be up-to-snuff can be difficult. In addition to development tools, DBAs will need administration tools to manage and care for all the new features of the Oracle8 database engine. At press time, most of the big names in database systems administration aren't ready to ship tools that can handle Oracle's new offering. Even Oracle's own Enterprise Manager suite of tools isn't completely ready yet.

Time Will Tell

In addition to the features that I have already covered, there are other areas of Oracle8 that haven't been in the spotlight as much. The new release sports improvements in backup and recovery operations (including a new Recovery Manager facility to handle backup and recovery tasks, see Figure 2) that are more centrally managed and controlled from the server end. Benefits here include the fact that with a more automated and controlled approach to these critical operations, problems from human error should be decreased. Administrators should also see improvements in the migration path from version 7 to 8. I remember migrating from 6 to 7 and calling Oracle support about a question I had about the migration utility. They strenuously warned me not to use it and suggested that I instead use the typical export/import utilities to perform the migration. Such is not the case with the 8 migration utility, and most administrators report no problems with the upgrade path.

Has Oracle put something new on the table just to pacify all the IS crooners who loudly wail for something new, or has the company released a product that meets the long-standing needs of the IS community? Although only time will tell if the company has hit the mark with Oracle8, reports from beta testers and others using the initial release of the product have been very positive. Performance improvements using the new partitioning option have been widely reported. Before long, I'm sure we will see companies putting Oracle's new size limits to the test.

The question of whether many will flock to the object/relational method of building database objects remains to be answered -- again, only time will tell. The fundamental question is whether database designers can use the new object-oriented features to build reliable systems at a faster rate that will, in turn, make their companies more profitable. That's the real litmus test of any improvement made in a software product. And whether one agrees or disagrees with the object/relational approach of Oracle or the NCA framework, one thing that can't be argued with is that for those persons seeking more power and flexibility in their database engines, they won't be disappointed with Oracle8.

Oracle's multiplexing feature requires the use of a module called the Connection Manager. DBAs use this to separate the database server from incoming network requests and instead route client traffic to a different server dedicated to handling Oracle's many network connections.

Oracle's new Recovery Manager facility handles backup and recovery tasks.