Online transaction processing applications that modify disjoint sets of data are suitable for OPS. A good example of this type of application is a banking application in which each bank branch accesses its own accounts information and very rarely needs to access information from a different branch. In such a situation, each branch can access an OPS instance that is specific to that branch. Each instance then accesses its own set of data, for the branch that it supports. Since each instance is accessing data for a different bank branch, conflicts between the instances will be almost nonexistent.

Some OLTP applications access very large databases, but in a relatively random pattern. Income tax applications are a good example of this type, in which individual records accessed by one instance are highly unlikely to be accessed by another instance at the same time. These applications can exploit the benefits of Oracle Parallel Server without incurring the overhead costs of lock conversion and pinging that result when multiple instances contend for the same data.

In today’s globally competitive business environment, there is a growing need for high availability. Companies can’t afford extended downtime for databases supporting mission-critical applications. The cost of downtime in a stock brokerage application, for example, can be extremely high. Applications requiring high availability can benefit from the application failover capability built into Oracle Parallel Server. When a connection to the database through one instance fails, an application can reconnect to the database through another instance (as we described in Chapter 12).

Departmental applications sometimes are suitable for use against an OPS database. If you have multiple departmental applications each modifying a different set of tables, you can set up an OPS database with one instance for each application. Common reference data can be accessed (in read-only mode) by all the applications. For example, an organization can put its Sales application on one node, its Human Resource application on another, its Project Accounting application on a third, and so forth. All of these applications modify different sets of tables but occasionally access some common data (such as employee data, for example) in read-only mode. Because the applications do not modify the same data, conflicts between the OPS instances are minimized.

Collaborative applications involve messaging services, directory services, workflow, and document management services in which multiple-user groups work together to share, exchange, and manage information. These applications often are suitable for OPS. Each user group can connect to one instance, and the chance that the same information will be updated by multiple instances is very low. Multiple instances can conveniently share the common directory information and documents in read-only mode without causing any locking conflicts.

DSS applications, such as those accessing a data warehouse or a data mart, execute large, complex queries but comparatively few updates, inserts, and deletes. In most DSS applications, data is queried throughout the day, and any insert, update, and delete activities take place during off-peak hours. Because they are primarily read-only, DSS applications are well suited to OPS. Multiple OPS instances can simultaneously read the same data without causing contention between those instances. DSS applications can employ the processors on multiple nodes to improve the performance of large and complex queries.

Scalability is a very important requirement of DSS applications. With growth in the database size and increase in user population, you can conveniently add another node to the system and run an additional OPS instance to support that growth.

DSS applications involve large and complex queries against a very large database. The databases used by DSS applications require regular feeds from transactional systems, and these feeds can be quite large. Parallel execution features such as parallel query, parallel data loading, and parallel table and index creation can very effectively improve the performance of DSS applications.

Many organizations have large reporting requirements and use copies of transactional databases as reporting databases. Some companies may need to generate reports that run to hundreds of pages or that crunch gigabytes of data. Other organizations may need hundreds of reports generated on a regular basis. In either of these cases, you can use separate reporting databases to eliminate the reporting load from the transactional database. Reporting applications involve large queries with aggregate, summary, and sorting requirements. Oracle’s parallel execution features can help improve the performance for these types of queries.

Many OLTP applications require large batch jobs to be run at off-peak hours. Some of these batch jobs are used to upload and download data to and from other databases, maintain indexes, and purge old data. You can use parallel DML and parallel DDL very effectively to reduce the runtime of these batch jobs.

Many organizations use replicated databases for disaster recovery. Oracle’s advanced replication can help maintain multiple copies of database objects at multiple sites. The replicated database is a real-time copy of the operational database. In case of a hardware failure, database failure, or other disaster, the replicated database becomes the operational database. Maintaining a replicated database involves constantly updating the replicated database as changes are made to the operational database. Oracle’s parallel replication propagation can be used to improve replication performance.