| Oracle® In-Memory Database Cache Introduction 11g Release 2 (11.2.2) E21631-04 |
|
|
PDF · Mobi · ePub |
| Oracle® In-Memory Database Cache Introduction 11g Release 2 (11.2.2) E21631-04 |
|
|
PDF · Mobi · ePub |
This chapter includes the following topics:
This section describes the architecture of the Oracle In-Memory Database Cache. The architecture of the Oracle TimesTen In-Memory Database is the same as the architecture of the IMDB Cache except that the Oracle database and cache agent are not included. Figure 3-1 shows the architecture of the IMDB Cache.
Figure 3-1 Oracle In-Memory Database Cache architecture
The architectural components include shared libraries, memory-resident data structures, database processes, and administrative programs. Memory-resident data structures include tables, indexes, system tables, locks, cursors, compiled commands and temporary indexes. The application can connect to the IMDB Cache or TimesTen database by direct link and by client/server connections.
Replication agents receive information from master databases and send information to subscriber databases. The cache agent performs all asynchronous data transfers between cache groups in the IMDB Cache and the Oracle database.
These components are described in subsequent sections.
The routines that implement the TimesTen functionality are embodied in a set of shared libraries that developers link with their applications and execute as a part of the application's process. This shared library approach is in contrast to a more conventional RDBMS, which is implemented as a collection of daemon processes to which applications connect, typically over a client/server network. Applications can also use a client/server connection to access an IMDB Cache or TimesTen database, though in most cases the best performance can be realized with a directly linked application. See "TimesTen connection options".
The IMDB Cache or TimesTen database resides entirely in main memory at run time. It is maintained in shared memory segments provided by the operating system and contains all user data, indexes, system catalogs, log buffers, and temp space. Multiple applications can share one database, and a single application can access multiple databases on the same system.
TimesTen assigns a separate background process to each database to perform operations including the following tasks:
Loading the database into memory from a checkpoint file on disk
Recovering the database if it needs to be recovered after loading it into memory
Performing periodic checkpoints in the background against the active database
Detecting and handling deadlocks
Performing data aging
Writing log records to files
Utility programs are explicitly invoked by users, scripts, or applications to perform services such as interactive SQL, bulk copy, backup and restore, database migration and system monitoring.
Checkpoint files contain an image of the database in persistent storage on disk. TimesTen uses dual checkpoint files for additional safety, in case the system fails while a checkpoint operation is in progress. Changes to databases are captured in transaction logs that are periodically written to persistent storage on disk. If a database needs to be recovered, TimesTen merges the most recent database checkpoint file on disk with the completed transactions that are still in the transaction log files. Normal file systems are used for checkpoints and transaction log files.
See "Data Availability and Integrity" for more information.
When the IMDB Cache is used to cache portions of an Oracle database in a TimesTen in-memory database, a cache group is created to hold the cached data.
A cache group is a collection of one or more tables arranged in a logical hierarchy by using primary key and foreign key relationships. Each table in a cache group is related to an Oracle database table. A cache table can contain all rows and columns or a subset of the rows and columns in the related Oracle database table. You can create or modify cache groups by using SQL statements or by using Oracle SQL Developer. Cache groups support these features:
Applications can read from and write to cache groups.
Cache groups can be refreshed from the Oracle database automatically or manually.
Updates to cache groups can be propagated to the Oracle database tables automatically or manually.
Changes to either the Oracle database tables or the cache group can be tracked automatically.
When rows in a cache group are updated by applications, the corresponding rows in the Oracle database tables can be updated synchronously as part of the same transaction or asynchronously immediately afterward depending on the type of cache group. The asynchronous configuration produces significantly higher throughput and much faster application response times.
Changes that originate in the Oracle database tables are refreshed into the cache by the cache agent.
See "IMDB Cache" for more information.
TimesTen replication enables you to achieve near-continuous availability or workload distribution by sending updates between two or more hosts. A master host is configured to send updates and a subscriber host is configured to receive them. A host can be both a master and a subscriber in a bidirectional replication scheme. Time-based conflict detection and resolution are used to establish precedence in case the same data is updated in multiple locations at the same time.
TimesTen recommends the active standby pair configuration for highest availability. It is the only replication configuration that you can use for replicating IMDB Cache. An active standby pair includes an active database, a standby database, optional read-only subscriber databases, and the tables and cache groups that comprise the databases.
When replication is configured, a replication agent is started for each database, even if multiple databases exist on the same host. Each replication agent can send updates to one or more subscribers and to receive updates from one or more masters. Each of these connections is implemented as a separate thread of execution inside the replication agent process. Replication agents communicate through TCP/IP stream sockets.
For maximum performance, the replication agent detects updates to a database by monitoring the existing transaction log. It sends updates to the subscribers in batches, if possible. Only committed transactions are replicated. On the subscriber host, the replication agent updates the database through an efficient low-level interface, avoiding the overhead of the SQL layer.
See "Replication" for more information about replication configurations.
Applications can connect to a TimesTen database in one of the following ways:
In a traditional database system, TCP/IP or another IPC mechanism is used by client applications to communicate with a database server process. All exchanges between client and server are sent over a TCP/IP connection. This IPC overhead adds substantial cost to all SQL operations and can be avoided in TimesTen by connecting the application directly to the TimesTen ODBC direct driver.
The ODBC direct driver is a library of ODBC and TimesTen routines that implement the database engine used to manage the databases. Java applications access the ODBC direct driver through the JDBC library. OCI applications access the ODBC direct driver through the OCI library.
An application can create a direct driver connection when it runs on the same machine as the IMDB Cache or TimesTen database. In a direct driver connection, the ODBC driver directly loads the IMDB Cache or TimesTen database into a shared memory segment. The application then uses the direct driver to access the memory image of the database. Because no inter-process communication (IPC) of any kind is required, a direct-driver connection provides extremely fast performance and is the preferred way for applications to access the IMDB Cache or TimesTen database.
The TimesTen client driver and server daemon processes accommodate connections from remote client machines to databases across a network. The server daemon spawns a separate server child process for each client connection to the database.
Applications on a client machine issue ODBC, JDBC or OCI calls. These calls access a local ODBC client driver that communicates with a server child process on the TimesTen server machine. The server child process, in turn, issues native ODBC requests to the ODBC direct driver to access the IMDB Cache or TimesTen database.
If the client and server reside on separate hosts in a network, they communicate by using sockets and TCP/IP. If both the client and server reside on the same machine, they can communicate more efficiently by using a shared memory segment as IPC.
Traditional database systems are typically structured in this client/server model, even when the application and the database are on the same system. Client/server communication adds extra cost to all database operations.
Applications can connect to the IMDB Cache or TimesTen database through an ODBC driver manager, which is a database-independent interface that adds a layer of abstraction between the applications and the TimesTen database. In this way, the driver manager allows applications to be written to operate independently of the database and to use interfaces that are not directly supported by TimesTen. The use of a driver manager also enables a single process to have both direct and client connections to the database.
On Microsoft Windows systems, applications can connect to the MS ODBC driver manager to use an IMDB Cache or TimesTen database along with data sources from other vendors. Driver managers for UNIX systems are available as open-source software as well as from third-party vendors.
For more information about the TimesTen database, see "Working with TimesTen Databases in ODBC" in Oracle TimesTen In-Memory Database C Developer's Guide and "Working with Data in a TimesTen Database" in Oracle TimesTen In-Memory Database Operations Guide.
For more information about connecting to databases, see "Managing TimesTen Databases" and "Working with the TimesTen Client and Server" in Oracle TimesTen In-Memory Database Operations Guide.
|
 Copyright © 2012, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
