 |
|
Oracle Times Ten data caching
Oracle Tips by Burleson Consulting |
Most Oracle professionals
recognize the huge benefits of RAM data caching, a techniques that can improve
data access speeds by up to 300x when compared to platter-based disk. RAM
can also support blistering table insert speeds of over a half million rows per
second.
The web site
www.statspackanalyzer.com is a
great way to see if your Oracle database is I/O-bound and you can simply paste-in
a STATSPACK or AWR report and see a detailed I/O analysis. Oracle's Time
Ten tool is the latest data caching approach in Oracle
There are several major
approaches to RAM data caching today:
Solid State Disk
data caching
RAM-SAN can hypercharge an
I/O-bound Oracle database overnight, speeding-up I/O operations. See the
book "Oracle Solid
State Disk Tuning: High Performance Oracle Tuning with RAM disk" for
benchmarks and tips on using SSD.
SSD is also very popular on
Oracle RAC databases, where the RAC architecture is ideal for RAM disks.
See the book "Oracle
RAC & Grid Tuning with Solid State Disk: Expert Secrets for High Performance
Clustered Grid Computing" for details on how to apply RAM disk to Oracle RAC
databases.
Large RAM Buffer Data
Caching
Many Oracle professionals
choose to use a very large db_cache_size, and most of the recent world-record
TPC benchmarks use Oracle data buffers in excess of 50 gigabytes, and one Oracle
benchmark that used over a terabyte of RAM. For details, see the book "Database
Benchmarking: Practical methods for Oracle":
Oracle Times Ten data caching
Oracle acquired the Times Ten
tool as a third alternative to data caching for high-speed data access.
Jonathan Gennick has a great article on the Oracle Times Ten tool for
caching large volumes of data.
When a data store is first opened, the entire contents
of the data store are read into memory from the checkpoint file. Subsequent
INSERT, DELETE, SELECT, UPDATE, and other database operations take place in
memory.
Data store changes from those operations are periodically and
asynchronously written to the on-disk checkpoint file. When the data store is
shut down, any remaining unwritten changes are written to the checkpoint file
before the data store is closed.
Time Ten Architecture (Source: Oracle Corporation)
Gennick also notes that The Times Ten RAM caching is not a Silver Bullet.
Because Oracle TimesTen derives its performance benefits from keeping an
entire data store in memory, why not simply run Oracle Database and
configure the buffer cache to be large enough to hold an entire database in
memory? Wouldn't Oracle Database then perform just as well as Oracle
TimesTen? This is a good and fair question, worthy of some attention.
Oracle TimesTen was designed from the ground up as an in-memory database.
There are no logical I/Os in the sense that there are in Oracle Database.
There are no database blocks. There is no buffer cache. Index entries,
rather than containing logical row IDs, point directly to the memory
locations where their target rows can be found. Going from an index entry to
a row in Oracle TimesTen requires the simple dereferencing of a pointer.
When using the TimesTen Data Manager 6.0 driver, your application has direct
access to the memory holding the data; no costly context switches are
needed.
Gennick concludes that TimesTen is great when response time is a primary
consideration:
Combined with sound database and application
design, the in-memory performance of Oracle TimesTen enables time- and
mission-critical database-backed applications. When minimizing microseconds
can save money or lives, Oracle TimesTen In-Memory Database can deliver.
For more details on Oracle Silver Bullets, see the book "Oracle
Silver Bullets", by Rampant TechPress.
