Database Reference
In-Depth Information
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
td (35) received from node 8 (12/0.36.0)
future ftd (37) received from node 5 (12/0.36.0)
future ftd (37) received from node 8 (12/0.36.0)
future ftd (37) received from node 4 (12/0.36.0)
future ftd (37) received from node 3 (12/0.36.0)
future ftd (37) received from node 6 (12/0.36.0)
future ftd (37) received from node 2 (12/0.36.0)
ftd (37) received from node 7 (12/0.36.0)
all ftds received
* kjxftdn: break from kjxftdn, post lmon later
ftd (30) received from node 4 (12/0.30.0)
ftd (30) received from node 3 (12/0.30.0)
. . . . . . . . . . .
. . . . . . . . . . . . .
* kjxftdn: break from kjxftdn, post lmon later
2013-11-27 13:17:58.131929 :
* End DRM for pkey remastering request(s) (locally requested)
Global Cache Optimization
When a user queries data from the database, data is retrieved from the storage subsystem, loaded into the
buffer cache, and data is traversed until the final result set is extracted. The final data set is then sent to the user.
Subsequently, if another user executes the same query, data is read from the buffer cache and data result sets are
returned back to the user. Not always is the data readily available; in situations such as insufficient buffer space that
holds the data or when data is modified by another session, data in the buffer needs to be refreshed and reloaded.
In a RAC environment, when users execute queries from different instances, instead of the having to retrieve data
from the I/O subsystem every single time, data is transferred over the interconnect from one instance to another. This
provides considerable performance benefits. Once data is transferred to the requesting instance, the execution plan
will then traverse through these rows to extract the actual result set requested by the user.
In certain situations, for example, when the segment is large and would not fit into the buffer cache, causing the
optimizer to choose a full table scan, it becomes more efficient to flush all dirty buffers and read directly from disk
(serial direct read, same as direct read for PQ [parallel query]) or it is read-mostly.
There are several types of data access patterns that can be implemented in a RAC environment based on the
type of application and database. For example, (1) if the query is going against a small subset of data like in an OLTP
implementation, data is accessed locally from storage; (2) if the query was going against a larger set of data such as
in a data warehouse implementation, you may consider using the parallel execution and taking advantage of the
resources available across multiple instances; and (3) if the query performs analytical functions and or is a summary
table, you could consider using the result cache feature in Oracle Database 11g where the final results are stored in the
results cache, making it available for other users in the system. In Oracle Database 11g Release 2, each of these options
follow different methods by which data is retrieved; and in some cases, these methods have changed compared to the
previous releases of Oracle RDBMS.
Search WWH ::
Custom Search