1273-1276

Previous Table of Contents Next

Page 1273

CHAPTER 56

Parallel Processing

IN THIS CHAPTER

• Understanding the Requirements for Parallel Processing 1274
• Leveraging Parallel Processing Platforms 1276
• Comparing Parallel Processing to Mainframes 1279
• Oracle Server Scalable Parallel Architecture for Open Data Warehousing 1280
• Oracle Parallel Architecture: An Overview 1284
• The Oracle Advantage over Pure Shared-Nothing Systems 1291
• Parallel Processing Platform Hardware Configuration Requirements 1295
• Making the Right Choice 1301
• Routine Parallel Platform Server Maintenance 1307

Page 1274

In recent years , Multi-Processors (commonly referred to as MPs), Symmetrical Multi- Processors (SMPs), and Massively Parallel Processors (MPPs) have been sweeping the marketplace and gaining ground to offload vast amounts of data processing. This processing is
performed in "parallel" among the available Central Processing Units (CPUs). In this chapter, I discuss how to choose, leverage, optimize, and convert to an Oracle parallel processing platform.

Understanding the Requirements for Parallel Processing

The following configurations describe which features, functions, and benefits are available through parallel processing:

Symmetrical Multiple Processors are usually a 1- to 49-processor system configuration having limited scalability. This is due to greater I/O per CPU as additional processors are added.

In Parallel Processors, the database query is divided into logical components that can be run in parallel on MP servers. Oracle Parallel Query Option uses this feature.

Massively Parallel Processors involve eight or more processors, as in the nCUBE 2 and 3 models with 65,536 parallel processors available.

Tightly coupled servers is an MP server in which all CPUs address shared memory or distributed memory addressing other processors. Tightly coupled servers provide very scalable operation without increased CPU I/O overhead.

Loosely coupled servers are MP servers that contain all CPUs divided between multiple servers, such as a DEC VAX or ALPHA NT cluster.

If the system you develop performs as planned but is modified or used by more users than originally designed for, you can add an additional processor and RAM for about $5,000. This assumes, of course, that your file server selection has a multi-processor upgrade path .

MP file servers feature a preconfigured, fixed number of processors and cannot be expanded without an expense nearly equal to the original file server purchase price. The advantage of an MP system is that the fixed number of processors are optimized to run in parallel with minimal parallel processing CPU overhead.

Symmetrical Multi-Processors enable the file server to incorporate additional processors to be included as needed. Scalability does have its drawbacks. As more processors are added to the system, the law of diminishing returns applies. Each additional CPU will deliver less processing power available to the combined CPU parallel processing capability.

Massively Parallel Processors incorporate an initially expensive architecture that delivers cheaper overall performance. As more processors are added, performance increases without the loss of I/O associated with scalability in SMP systems.

Page 1275

Operating System Impact in Parallel Processing

Some operating systems are more scalable than others. As a system accumulates processors, additional tasks are required of the hardware, operating system, and Distributed Lock Manager (DLM) for that platform. The DLM facilitates processor availability for tasks to be scheduled between processors, on both local and remote clustered file server configurations.

The DEC Alpha 2100 is exemplary in demonstrating that a great file server is only as great as its chosen operating system.

A DEC Alpha 2100 file server model EV5/275 (MHz) running MS-NT will only achieve the best processing results with no more than three processors, and in fact will actually achieve slower overall results as additional processors are added!

A DEC Alpha file server model 2100 EV5/275 running at 275 MHz and running digital
64-bit UNIX will continue to achieve the best processing results, regardless of how many processors are added to the system. In fact, the first four processors each contribute well over 90 percent additional throughput in a UNIX configuration.

New World Processing

Parallel processing was previously performed only by mainframes, which currently cost an average of $6 to 28 million to operate for five years versus any faster 32-bit or 64-bit, 30GB RAID5 SMP file server. Today, turnkey conversions can be done by AIS for less than $500,000, including fault-tolerant hardware, database software, application software, and a legacy conversion of the older application onto the new client/server platform.

The hardware costs for MP are approximately 1/32 than that of the traditional mainframe hardware cost, while delivering very high numbers of transactions per second (TPS). Due to very high mainframe costs, price/performance ratios are not available, as illustrated by the lack of audited benchmarks from the mainframe arena.

Mainframe Benchmarks

The best public TPC benchmark of late is that of a $27,913,514.00, ES/9000 model 511 TPF mainframe running the TPF 3.1 database at 3,504.93 TPS/A v1.2. The test results report that this mainframe's total five-year system cost, including software, will equate to $7,964.00 per transaction (TPC/A).

This compares with MP industry price/performance trends of 147 to 713 TPC/A v1.2 for any similar UNIX platform. The best UNIX systems costs vary from $1,000.00 to $5,941.00 per TPC/A.

These tests, like all TPC benchmarks, also include a complete five-year system cost including maintenance and all software all totaling from between $20,000.00 to $4,239,200.00
complete.

Page 1276

Leveraging Parallel Processing Platforms

How does Oracle leverage these newer parallel processing platforms? The Oracle Enterprise Edition has some very "advanced" features. The major enhanced features lacking in the Oracle Workgroup Server that the Enterprise Edition leverages for parallel processing are the following options:

• Parallel Query Option
• Parallel Server Option
• Distributed Database Option
• Data Replication Option
• 64-bit Option

The Parallel Query Option distributes queries among the available processors to complete complex tasks much more quickly than a single CPU can process. Even a full table scan can be distributed among separate CPUs on the same file server with this feature. Oracle Parallel Query employs "Query Slaves" that actually provide the scheduling of these Parallel job streams. These Parallel features are developed by Oracle Corporation, in conjunction with the Parallel Platform designers from each of the hardware vendors , and they are transparent to the Oracle programmers and users! Oracle delivers the Parallel Query Option and leverages MP by providing sophisticated high-speed record latching. This distributes parts of queries among the available processors for significant throughput advantages. The Parallel Query option is also transparent to the DBA, as the Oracle software and host-operating system automatically distribute these transactions among any MP, SMP, PP, or MPP system.

The Parallel Server Option creates a real-time copy of the Oracle instance and database on one or more file servers, or nodes on a network. This serves a dual purpose, as it can be used to do both of the following:

1. Balance the user load proportionally between separate file servers on a network
2. Enable an on- or off-site hot standby, real-time updated copy of the Oracle RDBMS

Balancing of the client/server user load proportionally between parallel server file servers and the associated parallel instances on a network can be achieved in three ways.

In the first method, as a PC windows client requests a connection from the client to the server, SQL*Net 2.2 is invoked and calls the / windows /oracle.ini variable:

 LOCAL=TNS:your_connect_string or "alias" 

The search path next defaults to your user's ora_home/network/admin directory to locate the user's tnsnames.ora file in search of your_connect_string or "alias". If half of the users have been defaulted to host1 and the other users were defaulted to host2, a proportional balance is achieved.

Previous Table of Contents Next