Analysis on Parallel Processing Technology of Oracle Database

The parallel processing technology of Oracle Database is a c-core technology in the database. The parallel processing technology of Oracle database enables organizations to efficiently manage and access TB-level data. If efficient parallel processing technology is not available for Oracle databases, these large databases (usually used in data warehouses but are increasingly present in business systems) will not exist.

In short, parallel processing is to use multiple CPUs and I/O resources to perform a single database operation. Although every major database vendor claims to be able to provide parallel processing capabilities, the architecture provided by each vendor actually has a key difference.

This article discusses the architecture of Oracle 9i parallel processing and demonstrates its superiority over other architectures in practical applications. It should be noted that, the main advantage of the Oracle9i parallel processing architecture is that it fully utilizes the underlying hardware infrastructure-each processor unit, each memory byte, and all available I/O bandwidth under any circumstances. This White Paper also describes the seamless integration of the Oracle Parallel Processing component with other key business components (such as Oracle RealApplication Cluster.

Introduction to Parallel Processing Technology for Oracle databases

Current Databases, whether used in data warehouses, operational data storage (ODS), or OLTP systems, contain a wealth of information. However, because of the massive amount of data involved, it is a huge challenge to find and display information in a timely manner. Oracle Database Parallel Processing technology can solve this challenge. Using the Parallel Processing Technology of Oracle databases, You can process several terabytes of data in a few minutes (instead of hours or days.

Oracle Database Parallel Processing technology achieves this high performance by leveraging all available hardware resources: multiple CPUs, multiple I/O channels, multiple storage arrays, and disk drives, and a large amount of memory. The more efficient the database software can use all these resources, the more effective it is to process queries and other database operations.

In addition, the complexity of today's database applications is greatly increased, not only need to support a large number of concurrent users, but also need to manage different types of users. Therefore, a parallel query architecture should not only ensure that all resources on the underlying hardware platform are fully utilized, but also further allocate these resources to multiple concurrent requests as appropriate.

Obviously, the request to support the CEO's strategic decision is more important than the execution of the batch processing report. The parallel query architecture should be able to handle these business requirements: not only based on the request itself, in addition, dynamic allocation should be made based on the number of people sending requests and the number of currently available system resources.

The parallel processing architecture of Oracle9i can fully meet these requirements. The architecture of Oracle9i not only provides industry-leading high performance, but also is the only one that can be adaptive and dynamically adjusted.

Oracle9i's parallel processing architecture takes full advantage of each hardware investment-SMP, clustering, or MPP-to ensure optimal throughput and continuous, optimized system usage at any time.

The Oracle9i database balances all parallel operations based on available resources, request priorities, and actual system load control.

Parallel Design Strategy for Oracle Database Parallel Processing Technology-static and dynamic

The idea of parallel processing is to separate a single task into multiple smaller units. Instead of doing all the work through a process, you can run the tasks in parallel so that multiple processes can run on smaller units at the same time. This can greatly improve performance and optimize the use of the system. However, the most important part of parallel processing is how to make a correct decision to divide a single task into smaller units of work.

Typically, there are two methods for implementing parallel processing of database systems. The main difference is whether physical data layout is required, and static data partitions are used as the prerequisite for parallel processing.

Oracle Database Parallel Processing Technology-static parallelism through physical data partitions-not sharing

In a pure non-shared database architecture, database files must be partitioned on nodes of multiple computer systems for parallel processing. Each node has a data subset, and each node uses a single process or thread to perform all access to this data subset in an exclusive manner. Data access cannot be performed concurrently in a partition. (Sometimes, the term "virtual processor" is also used to replace nodes. "Virtual processor" is a mechanism for simulating non-shared nodes on SMP computers.

For simplicity, we will use "nodes" as the term when discussing a non-shared architecture ). In other words, a pure non-shared system uses a partition or restricted access method to divide the work among multiple processing nodes. Node ownership changes are rare-Database Reorganization, addition or deletion of nodes to adapt to changes in business needs are typical causes of ownership changes. This change in data ownership always means manual management for non-shared systems.

In terms of concept, we can think that a pure non-shared system is very similar to a distributed database. To perform the required read/write operations on a node, transactions on the node must send messages to other nodes with data to be accessed, and coordinate the work completed on other nodes.

Passing messages to other nodes requests for specific operations (functions) on their datasets is called function transfer. On the other hand, if you request simple data from a remote node, you must access the complete dataset and return it from the owning node to the requesting node (data transmission ).