Databases Reference
In-Depth Information
Business intelligence data warehousing systems and OLTP systems could access much
of the same data, but these types of systems also typically have different requirements
in terms of CPU, memory, and data layout, which makes supporting a mixed workload
less than optimal for both types of processing. Real Application Clusters, with dynamic
service provisioning since Oracle Database 10
g
, makes it possible to allocate individual
nodes for individual workloads. It also makes it more feasible to deploy these mixed
workloads to a single database (albeit with multiple database instances).
Transactions and High Availability
As discussed in the previous chapter, the foundation of the transaction is the commit.
Once a transaction is committed, it is a part of the core data store—if the transaction is
not committed, its data is not visible to other users. Logically, this description is com‐
pletely accurate. In operational terms, there is an additional step that is part of this
process. Because commit operations are requested by a client application, the commit
first takes place in the database and is then acknowledged to the requesting client. A
failure could occur between the database commit operation and the reception of the
acknowledgment. When this occurs, the transaction is in a grey area, with a crucial
implication. If, when the system recovers, a transaction was committed on the database,
it should not be redone; if the transaction did not complete, it should be redone. All the
client knows is that the acknowledgment was not received. In a high-volume, mission-
critical system, many crucial transactions may be in this state, even due to very tempo‐
rary problems like network outages.
Oracle Database 12
c
introduces a new concept that addresses this specific problem,
called
Transaction Guard
. Transaction Guard tracks the state of transactions in the
database and provides an API that allows developers to query this state. With this ad‐
vance, an application can find out the true state of a transaction that did not complete
and take appropriate actions.
Another feature, Application Continuity, is also part of Oracle Database 12
c
. Application
Continuity allows developers to create
Database Requests
that can use the information
provided by Transaction Guard to determine the state of a failed transaction and auto‐
matically take action to either redo the transaction or ignore the failure. This capability
provides a higher level of consistency in the Oracle Database without forcing developers
to create entire subsystems to track and correct incomplete transactions on their own.
Oracle's OLTP Heritage
Oracle has enjoyed tremendous growth as the database of choice for OLTP in the mid
range computing environment. Oracle6 introduced nonescalating row-level locking
and read consistency (two of the most important of Oracle's core OLTP features), but
Oracle7 was really the enabler for Oracle's growth in OLTP. Oracle7 introduced many
key features, including the following:
