1277-1280
Page 1277
A second method of parallel load balancing is more difficult to accomplish. This balance is achieved at the TCP/IP or other protocol level by programming an automated switch sequence, triggered by a predetermined user limit.
When this high-water user connection mark is reached, users are shuttled to the next host specified in the program. If the primary host is unavailable, the secondary host is the recipient of all users requesting connections.
This fault-tolerant, fail-over mechanism can also be achieved by another method, enabling fault tolerance in an on- or off-site hot standby. This is accomplished through the parallel server's real-time updated copy of the Oracle RDBMS and is achieved through the tnsnames.ora file as well.
In the address list section of the tnsnames.ora file shown following, a second address entry specifies a redundant host name or Internet Protocol address (IP).
If the primary host database instance and SQL*Net listener are unavailable, then the second address connection is made to that second host's database listener, database, and associated database instance.
The Oracle "SID" or instance is the portion of the database cached in real memory, for that host database file server.
################ # Filename......: tnsnames.ora # Name..........: LOCAL_REGION # Date..........: 23-SEP-97 22:22:39 ################ your_connect_string_is_this= (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = VENUS) /*(The above host is the Primary host,*/ /*and is only used if the primary SID is available)*/ (Port = 1521) ) (ADDRESS = <(These four lines are (PROTOCOL = TCP) < the secondary host (Host = URANUS) < description and are only used (Port = 1521) < if the primary SID is unavailable) ) ) (CONNECT_DATA = (SID =ORAC) /*(This should be a single instance name or "SID",*/ /*shared by all Parallel Server instances)*/ ) )
Page 1278
In the preceding scenario, all of the fault tolerance is transparent to the user. The user was never required to enter a connect string or to change a connect string.
If a tool requests that an Oracle connect string be entered by the user, the user can simply press Enter on the keyboard to substitute the connect string or alias from the manually set
LOCAL=TNS:your_connect_string or "alias" line in the /windows/oracle.ini file.
This will then facilitate the user's connection to the first available Oracle database through that database's already running listener process.
The Oracle parallel server option always synchronizes transactions between the instances in memory and the database or databases. This assures transaction integrity in that all inserts , updates, and deletes committed on one parallel instance are immediately available to all users of any other parallel instance. These transactions can be applied to any parallel server instance on any other cluster or network node.
Parallel Server should not be confused with Parallel Processing, in that it can be used with the following:
- Single or multiple processor configurations
- Single file server configurations
- Clusters of one or more file servers
Such a file server configuration should have at least 16MB of RAM for each Oracle instance, simultaneously required to be resident in memory.
The Distributed Database Option joins two or more remote databases as one database. The remote database location and/or server name are transparent to the users.
The Data Replication Option is useful when isolated information, from a laptop or local regional office, is to be duplicated and updated separately from the master database.
The Oracle 64-bit Option allows for many unlimited and amazing Parallel Processing capabilities, including actual performance increases of up to 107 times faster than 32-bit systems, as well as the ability to leverage the following:
- Tens of gigabytes of RAM for any Oracle instance
- Tens of gigabytes of RAM for any Oracle data files that can be cached in memory
- 32-kilobyte Oracle data blocks for faster parallel reads and writes
- 64-bit executable code for Oracle
- 64-bit executable code for both Oracle Pro*C and Pro*COBOL
Page 1279
Comparing Parallel Processing to Mainframes
The following test results provided by the Oracle Corporation illustrate how these newer parallel processing platforms are faster, cheaper, and as fault-tolerant as any very expensive mainframe with terabytes of data.
Test Results
The tests shown in Table 56.1 were performed using maintenance releases 7.1, 7.2, and 7.3 of the Oracle server as a demonstration of the performance and scalability improvements engineered into these releases. Due to time constraints, not all of the tests could be run on releases 7.1 and 7.2. Some estimations and extrapolations based on available data were used to fill out the performance matrix.
Displaying time in minutes, the test results illustrate dramatic performance gains for all the major operations involved ”summary creation, index builds, and complex queries. Release 7.2 provides a ten-fold improvement in summary creation performance over release 7.1. Index builds and complex query execution are about twice as fast. These performance gains are further extended with release 7.3: summary creation exhibits an amazing twenty-fold improvement over release 7.1. Complex query execution is five times faster and index creation delivers over a three-fold improvement. Oracle8 is now 10 times faster than Oracle7.3!
Table 56.1. Performance comparison between releases 7.1, 7.2, and 7.3.
| Operation | Release 7.1 | Release 7.2 Results | Improvement over 7.1 | Release 7.3 Results | Improvement over 7.1 |
| Summary creation (6-D cube) | 13,400.0** | 1320.8 | 1015% | 647.4 | 2070% |
| Single key index creation | 967.7 | 398.6 | 243% | 304.3 | 318% |
| Concatenated key index creation | 1719.6 | 620.0 | 277% | 389.9 | 441% |
| Complex query | 149.1 | 75.4% | 198% | 29.9 | 498% |
**This number is an estimate. The operation was not run to completion.
Page 1280
Oracle Server Scalable Parallel Architecture for Open Data Warehousing
Oracle's scalable parallel database architecture combines the best elements of traditional shared-nothing and shared-disk approaches to provide highly scalable database system performance for open data warehousing on all parallel hardware systems ”from tightly coupled Symmetric Multi-Processor systems (SMP) to loosely coupled systems such as clusters and Massively Parallel systems (MPP). This chapter provides an outline of Oracle's parallel database architecture and illustrates the superiority of Oracle's "best-of-both- worlds " architecture over pure shared-nothing database systems in terms of performance, scalability, resource utilization, manageability, availability, and consistency with emerging trends in technology.
The increasing use of information as a key strategic weapon in business decision-making has led to an explosive growth in complex, data- intensive decision support applications in recent years . This growth has been further accelerated by the availability of cost-effective parallel processing systems from open system vendors . This section discusses the common architectural approaches that underlie parallel hardware and database systems.
Parallel Hardware Systems
Parallel hardware systems utilizing inexpensive commodity components have the potential to provide excellent price/performance advantages over traditional mainframe systems in data-intensive decision support applications. Tightly coupled Symmetric Multi-Processor (SMP) systems have been the most widely used parallel hardware systems. These systems utilize multiple processors that share common memory and disk resources and hence are also known as shared-everything systems. Primary advantages of SMP systems include simplicity of application development and ease of administration. These systems, however, do not provide any inherent fault-tolerance: the failure of a single critical component such as a CPU could bring the entire system down. Further, they are currently somewhat limited in terms of scalability and growth due to limitations in available system bus bandwidth and operating system software scalability.
Loosely coupled systems such as clusters and Massively Parallel Processing (MPP) systems eliminate some of the drawbacks of SMP systems, providing improved fault tolerance and easy incremental system growth. These systems are made up of multiple nodes, with each node consisting of a single processing unit ”a single CPU or an SMP unit, with its own dedicated system memory. In terms of disk sharing, these systems come in a variety of flavors. At one extreme are "shared-nothing" systems where each set of disk devices has physical connectivity only to a single node; at the other end are "shared-disk" cluster systems with each node having direct physical access to all of the disks. There are also hybrid systems where each node has direct physical access to a subset of devices but has logical access, enabled through an operating system abstraction layer, to all disk devices. The level of physical connectivity determines the potential for fault tolerance available
EAN: 2147483647
Pages: 391