You can think of this interaction on two levels. The first level involves the communications mechanisms used to interface your application with the database management system. The second level is after you are communicating with the database, how do you have to format your requests and in what format will the outputs be returned to your application?

Let me first address the communications mechanisms that Oracle supports. Basically, there are three ways to communicate with Oracle as shown in Figure 2.4:

•  The first mechanism relies on standard operating system interprocess communications mechanisms. These are the basis for all interaction between applications on the host computer system. This applies when the user application program is running on the same computer as the Oracle DBMS.

•  The second mechanism relies on Oracle’s communications utilities known as SQL*Net (pre-Oracle8 and still supported by Oracle8) or Net8. This software handles the details of interfacing to the appropriate communications protocols, transmitting the queries/transactions and then interfacing these transmissions to the database management system.

•  The final mechanism uses the standard protocols and tools that were originally developed for the World Wide Web (http and html). You have the option of installing a fully functional Web server with your Oracle8 system. This server is capable of receiving transmissions and sending responses to Web browsers connected to both intranets and the Internet. The communication between the Web server and the DBMS uses one of the above communications mechanisms (that is, SQL*Net or ODBC), but the client workstation is only responsible for using the standard Web protocols. This enables you to have a relatively “thin” client workstation with minimal memory, disk storage, and processing capabilities. It also saves a lot of client configuration work.

Figure 2.4.  Oracle communications mechanisms.

You can call methods within other programs (that is, the Oracle server) when Oracle implements its ORB. You will be able to access data via standard methods (think of them as selects and updates) provided as part of the CORBA standard. You can make these references either on the local computer or to a database on a remote computer. While you can do this with SQL*Net or Net8, the advantage of learning the CORBA APIs is that you can use these same techniques to access data and methods associated with a wide variety of applications. It will also provide a standard interface between Oracle products which should simplify the development team efforts when it comes to porting software.

Multiprocessor Configurations

The architecture shown in the previous section applies equally to both single and multiprocessor configurations. However, when you have multiple processors, you are probably not content to see your job running for a long time while a number of CPUs are idle. Oracle has realized that the way to support really large queries is to design their software to use as many CPUs as possible to perform a single operation. Some have even been heard to utter the slogan “parallel everything.” Anyway, for those operating systems that support multiple CPUs, Oracle has added a series of processes to take advantage of the additional CPUs:

•  Parallel query processes. These processes enable you to split the load for a given query between multiple processors. Depending on the query, Oracle may use one processor to scan the index while another retrieves information from the associated table. Oracle might choose to use separate processors to query different tables that are to be joined together. The key is that you have multiple CPUs and possibly multiple disk drives working at the same time on a single query.

•  Parallel load processes. This enables you to split up a bulk database load into multiple processes, similar to those used for parallel query.

•  Parallel DML statements. This enables you to do inserts, updates, and deletes on partitioned tables using multiple processors. You can also perform insert…select statements using multiple processors for nonpartitioned tables.

Fault Tolerance

Some systems are so critical to the operation of a company or organization that people are willing to spend extra money just to minimize any chance that the systems will be unavailable. As databases and their associated applications take over the processing functions of an organization and implement the basic business processes, up time becomes essential. Realizing this, Oracle has built into its architecture a couple of ways to increase the system’s tolerance to failures of CPUs, power supplies, memory, or disk drives.

The first option that came onto the market to increase fault tolerance actually had nothing to do with Oracle itself. Disk drive manufacturers developed technology to mirror disk drives (often referred to as RAID level 0). RAID 0 causes the operating system to make duplicate writes to two disk drives. If one disk drive fails, the operating system can still use the other drive for data storage and retrieval. There are both hardware-based and software-based disk mirroring solutions. One Oracle implementation of mirroring is the capability of mirroring the online redo log files. This provides both performance and security improvements.

The next fault tolerance feature that protects Oracle databases is the parallel server technology that Oracle has built as an optional product for the DBMS. This option applies to computer systems where multiple computers can access a common set of disk drives. The Oracle parallel server coordinates the activity and transactions across the multiple CPUs. It handles the locking that can occur between the CPUs. Finally, it provides a means for other processors to pick up tasks that were being accomplished by a CPU that fails.

A final fault tolerant feature that is new to Oracle8 is the table and index partitioning features. Here you are allowed to store different portions of a given data table (for example, all of the data from June on one disk and all of the data from July on another). The search algorithms have been implemented such that if a disk drive fails, you can still perform queries against the partitioned table as long as you do not need to access data from the failed partition. If the June disk drive fails, you can still run all of your July queries. This can be very useful when you have very large systems where a certain portion of the data is accessed often (and is therefore a candidate for disk mirroring) and the rest of the data is needed infrequently.