Cache Guide

Oracle® TimesTen In-Memory
Database
Cache Guide
Release 22.1
F35392-06
February 2023
Oracle TimesTen In-Memory Database Cache Guide, Release 22.1
F35392-06
Copyright © 2012, 2023, Oracle and/or its affiliates.
This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse
engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is
prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.
If this is software, software documentation, data (as defined in the Federal Acquisition Regulation), or related
documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S.
Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software,
any programs embedded, installed, or activated on delivered hardware, and modifications of such programs)
and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end
users are "commercial computer software," "commercial computer software documentation," or "limited rights
data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental
regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation
of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated
software, any programs embedded, installed, or activated on delivered hardware, and modifications of such
programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and
limitations specified in the license contained in the applicable contract. The terms governing the U.S.
Government's use of Oracle cloud services are defined by the applicable contract for such services. No other
rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications.
It is not developed or intended for use in any inherently dangerous applications, including applications that
may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you
shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its
safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this
software or hardware in dangerous applications.
Oracle®, Java, and MySQL are registered trademarks of Oracle and/or its affiliates. Other names may be
trademarks of their respective owners.
Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc,
and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered
trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products,
and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly
disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise
set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be
responsible for any loss, costs, or damages incurred due to your access to or use of third-party content,
products, or services, except as set forth in an applicable agreement between you and Oracle.
Contents
What's New
New features in Release 22.1.1.1.0 xii
1 Cache Concepts
Overview of Cache Groups 1-1
Cache Instance 1-3
Cache Group Types 1-3
Transmitting Changes Between the TimesTen and Oracle Databases 1-5
Using Oracle GoldenGate as an Alternative Cache Refresh Mechanism 1-7
High Availability Caching Solution 1-8
2 Getting Started
Setting Up the Oracle Database and TimesTen Classic Systems 2-1
Set Up Users in the Oracle Database 2-2
Create a DSN for the TimesTen Database 2-3
Set the Net Service Name for the Oracle Database in the tnsnames.ora File 2-4
Create Users in the TimesTen Database 2-4
Set the Cache Administration User Name and Password in the TimesTen Database 2-6
Creating Cache Groups 2-6
Identify the Oracle Database Tables To Be Cached 2-7
Start the Cache Agent 2-9
Create the Cache Groups 2-9
Start the Replication Agent for the AWT Cache Group 2-11
Performing Operations on the Read-Only Cache Group 2-11
Manually Load the Cache Group 2-11
Update the Cached Oracle Database Table 2-12
Performing Operations on a Dynamically Updatable Cache Group 2-13
Dynamically Load the Cache Group 2-14
Update the TimesTen Cache Table 2-14
Cleaning Up the TimesTen Classic and Oracle Database Systems 2-16
Stop the Replication Agent 2-16
iii
Drop the Cache Groups 2-16
Stop the Cache Agent and Destroy the TimesTen Database 2-16
Drop the Oracle Database Users and Their Objects 2-17
3 Setting Up a Caching Infrastructure

Configuring the Oracle Database to Cache Data 3-1
Create the Oracle Database Users and Default Tablespace 3-1
Grant Privileges to the Oracle Cache Administration User 3-3
Create Oracle Database Objects Used to Manage Data Caching 3-4
The grantCacheAdminPrivileges.sql Script 3-4
The initCacheAdminSchema.sql Script 3-5
Configuring a TimesTen Database to Cache Oracle Database Data 3-6
Specify Database Connection Definition for Cache 3-7
Define a DSN for the TimesTen Classic Database 3-7
Define Database Definition and Connectable in TimesTen Scaleout 3-8
Set the Net Service Name for the Oracle Database in the tnsnames.ora File 3-8
Create the TimesTen Users 3-9
Grant Privileges to the TimesTen Users 3-10
Set the Cache Administration User Name and Password 3-11
Setting the Cache Administration User Name and Password in TimesTen Classic 3-11
Setting the Cache Administration User Name and Password in TimesTen Scaleout 3-12
Testing the Connectivity Between the TimesTen and Oracle Databases 3-12
Managing the Cache Agent 3-13
Starting the Cache Agent 3-13
Stopping the Cache Agent 3-13
Set a Cache Agent Start Policy in TimesTen Classic 3-14
4 Defining Cache Groups

Cache Groups and Cache Tables 4-1
Single-Table Cache Group 4-3
Multiple-Table Cache Group 4-4
Creating a Cache Group 4-7
Read-Only Cache Group 4-8
Restrictions With Read-Only Cache Groups 4-11
Asynchronous WriteThrough (AWT) Cache Group 4-12
Starting and Stopping the Replication Agent 4-14
Setting a Replication Agent Start Policy 4-15
Monitoring Propagation of Transactions to the Oracle Database 4-15
Disabling Propagation of Committed Changes 4-16
iv
Configuring Parallel Propagation to the Oracle Database 4-16
What an AWT Cache Group Does and Does Not Guarantee 4-16
Restrictions With AWT Cache Groups 4-17
Reporting Oracle Database Permanent Errors for AWT Cache Groups 4-18
Synchronous WriteThrough (SWT) Cache Group 4-20
Restrictions With SWT Cache Groups 4-22
Hybrid Cache Group 4-23
Creating a Hybrid Cache Group 4-24
Specifying the Dynamic Load for a Hybrid Cache Group 4-25
Automatic Passthrough for Hybrid Cache Groups 4-28
Restrictions for a Dynamic Hybrid Read-Only Cache Group 4-28
User Managed Cache Group 4-28
READONLY Cache Table Attribute 4-29
PROPAGATE Cache Table Attribute 4-30
Examples of User Managed Cache Groups 4-32
Using a WHERE Clause 4-36
Proper Placement of WHERE Clause in a CREATE CACHE GROUP Statement 4-37
Referencing Oracle Database PL/SQL Functions in a WHERE Clause 4-38
Specifying Automatic Refresh With the AUTOREFRESH Cache Group Attribute 4-39
Creating a Dynamic Cache Group With the DYNAMIC Keyword 4-39
Creating a Hash Index on the Primary Key Columns of the Cache Table 4-39
ON DELETE CASCADE Cache Table Attribute 4-40
Caching Oracle Database Synonyms 4-40
Caching Oracle Database LOB Data 4-41
Restrictions on Caching Oracle Database LOB Data 4-42
Implementing Aging in a Cache Group for TimesTen Classic 4-42
LRU Aging in TimesTen Classic 4-43
Time-Based Aging in TimesTen Classic 4-44
Manually Scheduling an Aging Process in TimesTen Classic 4-46
Configuring a Sliding Window in TimesTen Classic 4-46
Replicating Cache Tables in TimesTen Classic 4-47
Create and Configure the Active Database 4-48
Create and Configure the Standby Database 4-50
Create and Configure the Read-Only Subscriber Database 4-51
5 Methods for Transmitting Changes Between TimesTen and Oracle

Databases
Manually Loading and Refreshing a Cache Group 5-2
Loading and Refreshing a Cache Group Using a WITH ID Clause 5-3
Loading and Refreshing a Multiple-Table Cache Group 5-4
v
Improving the Performance of Loading or Refreshing a Large Number of Cache
Instances 5-4
Example of Manually Loading and Refreshing a Static Cache Group 5-5
Example of Manually Loading and Refreshing a Dynamic Cache Group 5-6
Flushing a User Managed Cache Group 5-8
Unloading a Cache Group 5-9
Automatically Refreshing a Cache Group 5-9
AUTOREFRESH Cache Group Attribute Overview 5-10
Autorefresh Mode Attribute Settings 5-10
Autorefresh Interval and State Settings 5-11
Restrictions for Autorefresh 5-12
Altering a Cache Group to Change the AUTOREFRESH Mode, Interval or State 5-13
Manually Creating Oracle Database Objects for Cache Groups With Autorefresh 5-14
Initiating an Immediate Autorefresh in TimesTen Classic 5-15
Disabling Full Autorefresh for Cache Groups 5-16
Loading and Refreshing a Static Cache Group With Autorefresh 5-17
Loading and Refreshing a Dynamic Cache Group With Autorefresh 5-18
Manually or Dynamically Loading Cache Groups 5-19
Dynamic Cache Groups 5-20
Enabling or Disabling Dynamic Load 5-22
Guidelines for Dynamic Load 5-22
Examples of Dynamic Load of a Single Cache Instance 5-24
Dynamically Loading Multiple Cache Instances 5-27
Dynamically Loading Multiple Cache Instances With Multiple Primary Keys 5-27
Dynamically Loading Multiple Cache Instances Without Multiple Primary Keys 5-28
Returning Errors for Dynamic Load 5-30
Determining the Number of Cache Instances Affected by an Operation 5-31
Setting a Passthrough Level 5-31
PassThrough=0 5-32
PassThrough=1 5-32
PassThrough=2 5-33
PassThrough=3 5-34
Considerations for Using Passthrough 5-35
Changing the Passthrough Level for a Connection or Transaction 5-36
Automatic Passthrough of Dynamic Load to the Oracle Database 5-36
6 Managing a Caching Environment

Checking the Status of Cache and Replication Agents 6-1
Checking the Status of the Cache Agents in TimesTen Scaleout 6-1
Checking the Status of the Cache and Replication Agents in TimesTen Classic 6-2
Cache Agent and Replication Connection Recovery 6-3
vi
Managing a Cache Environment With Oracle Database Objects 6-4
Monitoring Cache Groups 6-6
Using the ttIsql Utility cachegroups Command 6-7
Monitoring Autorefresh Operations on Cache Groups 6-8
Monitoring AWT Cache Groups 6-8
Configuring a Transaction Log File Threshold for AWT Cache Groups 6-8
Tracking DDL Statements Issued on Cached Oracle Database Tables 6-9
Dropping Oracle Database Objects Used by Cache Groups With Autorefresh 6-10
Impact on Cache Groups When Modifying the Oracle Database Schema 6-12
Impact of Failed Autorefresh Operations on TimesTen Databases 6-12
Managing the Cache Administration User's Tablespace 6-16
Defragmenting Change Log Tables in the Tablespace 6-16
Manually Defragmenting the Change Log Tables for Cache Groups With
Autorefresh 6-19
Receiving Notification on Tablespace Usage 6-19
Recovering From a Full Tablespace 6-20
Backing Up and Restoring a TimesTen Classic Database With Cache Groups 6-21
Backing Up and Restoring Using the ttBackup and ttRestore Utilities 6-21
Backing Up and Restoring TimesTen Classic Database With the ttMigrate Utility 6-23
Changing Cache User Names and Passwords 6-26
7 Cache Performance
Dynamic Load Performance 7-1
Managing a Cache Connection Pool to the Oracle Database for Dynamic Load
Requests 7-2
Enable the Cache Connection Pool 7-3
Size the Cache Connection Pool 7-5
Use the ChildServer Connection Attribute to Identify a Child Server Process 7-6
Dynamically Applying Cache Connection Pool Sizing Modifications 7-6
Example Demonstrating Management of the Cache Connection Pool 7-7
Limiting the Number of Connections to the Oracle Database 7-8
Restrictions for the Cache Connection Pool 7-9
Improving AWT Throughput 7-9
Improving AWT Throughput With Parallel Propagation to the Oracle Database 7-10
Table Constraint Restrictions When Using Parallel Propagation for AWT Cache
Groups 7-12
Manually Initiate Check for Missing Constraints for an AWT Cache Group 7-15
Configuring Batch Size for Parallel Propagation for AWT Cache Groups 7-16
Improving AWT Throughput With SQL Array Processing 7-17
Improving Performance for Autorefresh Operations 7-17
Minimizing Delay for Cached Data With Continuous Autorefresh 7-18
vii
Reducing Contention for Dynamic Read-Only Cache Groups With Incremental
Autorefresh 7-18
Requirements for Setting DynamicLoadReduceContention 7-19
Reducing Lock Contention for Read-Only Cache Groups With Autorefresh and
Dynamic Load 7-19
Options for Reducing Contention Between Autorefresh and Dynamic Load Operations 7-20
Improving Performance When Reclaiming Memory During Autorefresh Operations 7-21
Running Large Transactions With Incremental Autorefresh Read-Only Cache Groups 7-22
Using ttCacheAutorefreshXactLimit 7-23
Example of Potential Transactional Inconsistency 7-24
Retrieving Statistics to Evaluate Performance When a Transaction Limit is Set 7-28
Configuring a Select Limit for Incremental Autorefresh for Read-Only Cache Groups 7-28
How to Determine Which Intervals Have a Particular Select Limit 7-29
Retrieving Statistics to Evaluate Performance When Using a Select Limit 7-30
Retrieving Statistics on Autorefresh Transactions 7-30
Caching the Same Oracle Table on Two or More TimesTen Databases 7-31
8 Cleaning Up the Caching Environment

Stopping the Replication Agent 8-1
Dropping a Cache Group 8-1
Stopping the Cache Agent 8-2
Destroying the TimesTen Databases 8-3
Dropping Oracle Database Users and Objects 8-4
Scheduling a Shutdown of Active Standby Pair With AWT Cache Groups 8-4
9 Using Cache in an Oracle RAC Environment

How Cache Works in an Oracle RAC Environment 9-1
Restrictions on Using Cache in an Oracle RAC Environment 9-4
Setting Up Cache in an Oracle RAC Environment 9-4
10 Using Cache With Data Guard

Components of MAA for Cache 10-1
Cache in TimesTen Works With Asynchronous Active Data Guard 10-1
Configuring the Primary and Standby Oracle Databases 10-3
Configuring Oracle Database Services Through Role Based Services 10-3
Configuring Oracle Database Services Through System Triggers 10-4
Configuring the Active Standby Pair With Read-Only Cache Groups 10-7
Recovery After Failure When Using Asynchronous Active Data Guard 10-8
Failure of the Standby Oracle Database 10-8
viii
Failure of the Primary Oracle Database 10-9
Failure of the Primary Site 10-10
Cache in TimesTen Works With Synchronous Data Guard 10-12
Configuring the Oracle Databases for TimesTen and Synchronous Data Guard 10-12
Configuring the TimesTen Database to Work With Synchronous Data Guard 10-15
11 Using GoldenGate as an Alternative to Native Read-Only Cache Groups

TimesTen and GoldenGate Support for Cache Refresh 11-1
Considerations When Using GoldenGate as the Cache Refresh Mechanism 11-2
Configuring GoldenGate to Provide Cache Refresh Functionality for TimesTen 11-3
Choosing On-Box or Off-Box for Deployment of a GoldenGate Replicat Process 11-4
Direct Mode Connectivity 11-4
Client-Server Connectivity 11-5
Installing and Configuring TimesTen and the Target Database 11-5
Create TimesTen Database Users, Tables and Synonyms 11-6
Installing and Configuring a TimesTen Client Instance (for Off-Box Deployments Only) 11-7
Configure GoldenGate Data Apply 11-8
Perform an Initial Load 11-9
Start GoldenGate Continuous Real-Time Replication 11-10
Example of Caching Using GoldenGate 11-11
Prepare TimesTen Users and Target Tables 11-12
Prepare Oracle Database for GoldenGate Replication 11-13
Prepare the TimesTen Database for GoldenGate Replication 11-14
Perform the Initial Data Load 11-14
Start Real-Time Replication 11-15
Verify That Replication is Working 11-15
A Procedure and Privileges for Caching Oracle Database Data in

TimesTen
Quick Reference to Cache Oracle Database Data in TimesTen A-1
Required Privileges for Cache Operations A-3
B SQL*Plus Scripts for Cache

Installed SQL*Plus Scripts B-1
C Compatibility Between TimesTen and Oracle Databases

Summary of Compatibility Issues C-1
Transaction Semantics C-1
ix
API Compatibility C-2
JDBC API Compatibility C-2
java.sql.Connection C-2
java.sql.Statement C-3
java.sql.ResultSet C-3
java.sql.PreparedStatement C-3
java.sql.CallableStatement C-4
java.sql.ResultSetMetaData C-4
Stream Support C-4
ODBC API Compatibility C-5
SQL Compatibility C-5
Schema Objects C-6
Caching Oracle Database Partitioned Tables C-6
Non-Schema Objects C-7
Differences Between Oracle Database and TimesTen Tables C-7
Data Type Support C-7
SQL Operators C-8
SELECT Statements C-9
SQL Subqueries C-9
SQL Functions C-9
SQL Expressions C-11
INSERT/DELETE/UPDATE/MERGE Statements C-12
TimesTen-Only SQL and Built-In Procedures C-12
PL/SQL Constructs C-13
Mappings Between Oracle Database and TimesTen Data Types C-13
x
About This Content
This document covers TimesTen support for cache operations.
Audience
This guide is for anyone developing or supporting applications to cache data from an Oracle
database in a TimesTen database. Cache operations enable the caching of subsets of an
Oracle database into cache tables within a TimesTen database for improved response time in
the application tier. Cache tables can be read-only or updatable. Applications read and
update the cache tables using standard Structured Query Language (SQL) while data
synchronization between the TimesTen database and the Oracle database is performed
automatically.
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility
Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My
Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info
or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
Conventions
The following text conventions are used in this document.
Convention Meaning
boldface Boldface type indicates graphical user interface elements associated with an
action, or terms defined in text or the glossary.
italic Italic type indicates book titles, emphasis, or placeholder variables for which
you supply particular values.
monospace Monospace type indicates commands within a paragraph, URLs, code in
examples, text that appears on the screen, or text that you enter.
11
What's New
What's New
This section summarizes new features and functionality of TimesTen Release 22.1 that
are documented in this guide, providing links into the guide for more information.
New features in Release 22.1.1.1.0

• You can use cache operations in both TimesTen Classic and TimesTen Scaleout.
TimesTen Scaleout supports static read-only cache groups with incremental
autorefresh. See Using Cache Groups in TimesTen Scaleout.
• A hybrid cache group is a dynamic read-only cache group where the root table is
created in the TimesTen database and does not exist in the Oracle database. See
Hybrid Cache Group.
• You can set the TT_DynamicPassthrough optimizer hint to notify TimesTen Classic
to pass through qualified SELECT statements to the Oracle database. See
Automatic Passthrough of Dynamic Load to the Oracle Database.
• You can dynamically load multiple cache instances, see Dynamically Loading
Multiple Cache Instances.
• You may prefer to use Oracle GoldenGate to refresh data from the backend Oracle
database to a TimesTen cache instead of using the built-in native cache refresh
mechanism of TimesTen. See Using Oracle GoldenGate as an Alternative Cache
Refresh Mechanism.
• There are now two LRU aging policies for TimesTen Classic:
– LRU aging based on set thresholds for the amount of permanent memory in
use.
– LRU aging based on row thresholds for a specified root tables of your cache
groups.
See LRU Aging in TimesTen Classic.
• As a result of changes in the Oracle Database, the privileges required for cache
operations have been updated. See Required Privileges for Cache Operations.
• An additional table and trigger were added for cache operations. The
TT_version_CACHED_COLUMNS table stores list of columns that are cached. And
instead of a single trigger, there are now two triggers to handle different aspects of
autorefresh operations. See Managing a Cache Environment With Oracle
Database Objects.
xii
1
Cache Concepts
Use caching to improve the performance for your applications access to data. You can cache
Oracle Database data and reduce the workload on the Oracle database.
The TimesTen mechanism that enables read and write caching for Oracle database tables is
called a cache group. A cache group can represent one or more related tables on an Oracle
database. Each Oracle table is represented in the cache group with a cache table. You can
read from or write to the cache tables. TimesTen connects to the backend Oracle database to
load or update data as appropriate.
You can use cache in both TimesTen Classic and TimesTen Scaleout.
• TimesTen Classic supports all cache group types.
• TimesTen Scaleout supports static read-only cache groups.
See Cache Group Types.
This chapter includes the following topics:
• Overview of Cache Groups
• Cache Instance
• Cache Group Types
• Transmitting Changes Between the TimesTen and Oracle Databases
• Using Oracle GoldenGate as an Alternative Cache Refresh Mechanism
• High Availability Caching Solution
Overview of Cache Groups

Cache groups define the Oracle database data to be cached in a TimesTen database. A
cache group can be defined to cache all or part of a single Oracle database table, or a set of
related Oracle database tables.
Figure 1-1 shows the target_customers cache group that caches a subset of a single Oracle
Database table customer.
1-1
Chapter 1
Overview of Cache Groups
Figure 1-1 Single Table Cache Group
TimesTen
Cache group target_customers
customer
cust_num* region name ...
122 West Jim Johnston ...
663 MidWest Pat Reed ...
Oracle
database
customer
122 West Jim John ...
342 West Jane Stone ...
942 East Terry Boone ...
You can cache multiple Oracle database tables in the same cache group by defining a
root table and one or more child tables. A cache group can contain only one root table.
The root table does not reference any table with a foreign key constraint. In a cache
group with multiple tables, each child table must reference the root table or another
child table in the same cache group using a foreign key constraint. Although tables in a
multiple-table cache group must be related to each other in the TimesTen database
through foreign key constraints, the corresponding tables in the Oracle database do
not necessarily need to be explicitly related to each other. The tables on the Oracle
database can be related:
• Explicitly through a foreign key constraint.
• Implicitly related by the user application (those that update the Oracle database).
The user application could maintain a relationship between tables that is not
enforced by the Oracle database.
See Multiple-Table Cache Group.
While you may have multiple TimesTen databases that synchronize with the same
Oracle database, they each operate independently. Thus, any data cached in separate
TimesTen databases each synchronize with the Oracle database independently.
An Oracle database table cannot be cached in separate cache groups within the same
TimesTen database. However, the table can be cached in separate cache groups
within different TimesTen databases. If the table is cached in separate cache groups
1-2
Chapter 1
Cache Instance
and the same cache instance is changed simultaneously on multiple TimesTen databases,
there is no guarantee as to the order in which the changes are propagated to the cached
Oracle database table. The contents of such cache groups in different TimesTen databases
may not be consistent at a given point in time.
Cache Instance
Data is loaded from an Oracle database into a cache group within a TimesTen database in
units called cache instances.
A cache instance is defined as a single row in the cache group's root table together with the
set of related rows in the child tables.
Figure 1-2 shows three tables in the customer_orders cache group. The root table is
customer. orders and order_item are child tables. The cache instance identified by the row
with the value 122 in the cust_num primary key column of the customer table includes:
• The two rows with the value 122 in the cust_num column of the orders table (whose value
in the ord_num primary key column is 44325 or 65432), and
• The three rows with the value 44325 or 65432 in the ord_num column of the order_item
table
Figure 1-2 Multiple-Table Cache Group
TimesTen
Cache group customer_orders
customer (Root table)
cust_num region name address
122 West Jim Johnston 231 Main, Needles, CA 92363
342 West Jane Stone 43 Cope, Palo Alto, CA 94302
663 Midwest Mary J. Warren 673 State, Madison, WI 53787
orders Oracle
ord_num cust_num when_placed when_shipped database
44325 122 10/7/16 10/7/16
customer
65432 122 8/24/16 8/27/16
Child 76543 663 4/2/16 4/8/16
Tables Data for all customers
order_item orders
ord_num prod_num quantity

order_item
44325 SD07 1
44325 TR3A 5
65432 FT094 1
76543 SD07 2
Cache Group Types

There are several cache group types from which you can choose depending on the
application needs.
1-3
Chapter 1
Cache Group Types
The most commonly used types of cache groups are:

• Read-only cache group
A read-only cache group enforces a caching behavior in which committed changes
on cached tables in the Oracle database are automatically refreshed to the cache
tables in the TimesTen database. Using a read-only cache group is suitable for
reference data that is heavily accessed by applications.
TimesTen Classic supports all types of read-only cache groups. TimesTen
Scaleout only supports static read-only cache groups with incremental autorefresh.
See Read-Only Cache Group in this book and Using Cache Groups in TimesTen
Scaleout in the Oracle TimesTen In-Memory Database Scaleout User's Guide.
• Asynchronous WriteThrough (AWT) cache group
An AWT cache group enforces a caching behavior in which committed changes on
cache tables in the TimesTen database are automatically propagated to the
cached tables in the Oracle database in asynchronous fashion. Using an AWT
cache group is suitable for high speed data capture and online transaction
processing.
Only TimesTen Classic supports AWT cache groups.
See Asynchronous WriteThrough (AWT) Cache Group.
Other types of cache groups include:
• Synchronous writethrough (SWT) cache group
An SWT cache group enforces a caching behavior in which committed changes on
cache tables in the TimesTen database are automatically propagated to the
cached tables in the Oracle database in synchronous fashion.
Only TimesTen Classic supports SWT cache groups.
See Synchronous WriteThrough (SWT) Cache Group.
• User managed cache group
A user managed cache group defines customized caching behavior.
For example, you can define a cache group that does not use automatic refresh or
automatic propagation where committed changes on the cache tables are
manually propagated or flushed to the cached Oracle Database tables.
You can also define a cache group that uses both automatic propagation in
synchronous fashion on every table and automatic refresh.
Only TimesTen Classic supports user managed cache groups.
See User Managed Cache Group.
• Hybrid cache group
All other cache groups require multiple table cache groups to have strict parent-
child relationships for all tables on a TimesTen database as well as the Oracle
database. With hybrid cache groups, the cache tables on a Oracle database must
be related, but the root (parent) table must only exist on the TimesTen database.
That is, you can dynamically load from cache tables that do not have a root table
on the Oracle database. A hybrid cache group is a dynamic read-only cache group
where the root table is created in the TimesTen database and does not exist in the
Oracle database.
See Hybrid Cache Group.
1-4
Chapter 1
Transmitting Changes Between the TimesTen and Oracle Databases
Transmitting Changes Between the TimesTen and Oracle

Databases
Transmitting committed changes between the TimesTen cache tables and the cached Oracle
Database tables keeps these tables in the two databases synchronized.
You can transmit changes between TimesTen and Oracle databases manually or
automatically.
• Manually load cache groups: You can manually load cache instances that are not in the
TimesTen cache tables from the Oracle database tables using LOAD CACHE GROUP
statement. This statement only loads committed inserts on the cached Oracle database
tables into the TimesTen cache tables. New cache instances are loaded into the cache
tables, but cache instances that already exist in the cache tables are not updated or
deleted even if the corresponding rows in the cached Oracle database tables have been
updated or deleted. A load operation is primarily used to initially populate a cache group.
• Manually refresh cache groups: You can manually refresh cache instances into the
TimesTen cache tables from the Oracle database tables using the REFRESH CACHE GROUP
statement. This statement replaces cache instances in the TimesTen cache tables with
the most current data from the cached Oracle database tables including cache instances
that are already exist in the cache tables. A refresh operation is primarily used to update
the contents of a cache group with committed changes on the cached Oracle database
tables after the cache group has been initially populated.
• Manually propagate committed changes: Use a FLUSH CACHE GROUP statement to
manually propagate committed changes on the TimesTen cache tables to the cached
Oracle database tables.
• Dynamically load cache groups: A dynamic cache group is one that is created with the
DYNAMIC keyword. Data is dynamically loaded on demand into the TimesTen cache tables
from the cached Oracle database tables for dynamic cache groups when a qualifying
SELECT, INSERT, UPDATE, or DELETE statement is issued on one of the cache tables. A
cache instance is automatically loaded from the cached Oracle database tables when a
qualified statement does not find the data in the cache table, but the data exists in the
cached Oracle database table. Typically, data automatically ages out from dynamically
loaded cache tables when it is no longer being used. This action is similar to a LOAD
CACHE GROUP statement, but dynamically issued. Dynamic cache groups are only
supported in TimesTen Classic.
Note:
A static cache group is one that is created without the DYNAMIC keyword.
• Automatically refresh cache groups: Autorefresh operations automatically replace cache

instances in the TimesTen cache tables with the most current data from the cached
Oracle database tables including cache instances that already exist in the cache tables.
Autorefresh operations update the contents of a cache group with committed changes on
the cached Oracle database tables after the cache group has been initially populated.
This action is similar to a REFRESH CACHE GROUP statement, but automatically performed.
Cache instances are automatically refreshed when the cache group is created with the
AUTOREFRESH cache table attribute. The AUTOREFRESH cache group attribute can be used
1-5
Chapter 1
Transmitting Changes Between the TimesTen and Oracle Databases
in a read-only or a user managed cache group to automatically refresh committed

changes on cached Oracle Database tables into the TimesTen cache tables. The
AUTOREFRESH cache group attribute can be defined on static or dynamic cache
groups.
• Automatic propagation of changes to the Oracle database: When you specify the
PROPAGATE cache table attribute when creating AWT, SWT, or user managed cache
groups, then committed changes on cache tables in the TimesTen database are
automatically propagated to the cached Oracle Database tables. This action is
similar to a FLUSH CACHE GROUP statement, but automatically performed.
Load, refresh, dynamic load and autorefresh are operations that transmit committed
changes on cached tables in the Oracle database to the cache tables in the TimesTen
database. Load and refresh are manual operations; dynamic load and autorefresh are
automatic operations. Propagate and flush are operations that transmit committed
changes on cache tables in the TimesTen database to the cached tables in the Oracle
database. Flush is a manual operation and propagate is an automatic operation.
Figure 1-3 Transmitting Committed Changes Between the TimesTen and Oracle
Databases
TimesTen
database
cache group
Flush Load
Refresh
Propagate
Dynamic load
Autorefresh
Oracle
database
The DYNAMIC keyword designates whether the cache group is a static or dynamic
cache group:
• Static cache group: Defined when the DYNAMIC keyword is not supplied when
creating the cache group. In a static cache group, cache instances are loaded
manually into the TimesTen cache tables from an Oracle database. Within a static
cache group, data is initially loaded into the cache tables from the cached Oracle
database tables using a LOAD CACHE GROUP statement. After which, you can
1-6
Chapter 1
Using Oracle GoldenGate as an Alternative Cache Refresh Mechanism
refresh the data with a REFRESH CACHE GROUP statement or automatically refresh the data
if defined to use autorefresh. Once the cache tables are loaded, the user can run queries.
A static cache group is appropriate when the set of data to cache is static and can be
predetermined before applications begin performing operations on the cache tables. By
default, cache groups are static.
• Dynamic cache group: Defined when the cache group is created with the DYNAMIC
keyword. Within a dynamic cache group, data can be loaded into the cache group from
an Oracle database either dynamically on demand or manually with LOAD CACHE GROUP or
REFRESH CACHE GROUP statements. A manual refresh or an autorefresh operation on a
dynamic cache group can result in existing cache instances being updated or deleted, but
committed changes on Oracle database data that are not being cached do not result in
new cache instances being loaded into its cache tables. A dynamic cache group is
appropriate when the set of data you need to cache is small compared to the full size of
the data that exists in the tables in the Oracle database.
The data should be preloaded from the Oracle database before applications perform
operations on the cache tables.
Choose static or dynamic load when deciding how much data you want to cache. Ideally, a
manual load is faster. Use dynamic load to automate loading new data or to specify how
much data to load into memory.
Any cache group type (read-only, AWT, SWT, user managed) can be defined as a static
cache group. All cache group types except a user managed cache group that uses both the
AUTOREFRESH cache group attribute and the PROPAGATE cache table attribute can be defined as
a dynamic cache group.
See Methods for Transmitting Changes Between TimesTen and Oracle Databases.
See Asynchronous WriteThrough (AWT) Cache Group and Synchronous WriteThrough
(SWT) Cache Group.
Using Oracle GoldenGate as an Alternative Cache Refresh

Mechanism
You may prefer to use Oracle GoldenGate to refresh data from the backend Oracle database
to TimesTen instead of using the built-in native cache refresh mechanism of TimesTen.
You can use GoldenGate instead of the native cache refresh mechanism of TimesTen to
provide the equivalent of static read-only cache groups. All other types of cache functionality
must use the TimesTen native cache mechanism.
The following are the advantages when using GoldenGate as your cache refresh mechanism:
• GoldenGate provides a lighter weight change data capture pipeline on the Oracle
database, especially if you have multiple TimesTen databases caching data from the
same Oracle database.
• The triggers and tracking tables that are required by TimesTen for cache operations in an
Oracle Database are not required.
• You can cache data from multiple Oracle databases into a single TimesTen database.
• You can cache data from a backend database that is not an Oracle database if the
database supported by GoldenGate.
See Using GoldenGate as an Alternative to Native Read-Only Cache Groups.
1-7
Chapter 1
High Availability Caching Solution
High Availability Caching Solution

You can configure cache to achieve high availability of cache tables, and facilitate
failover and recovery while maintaining connectivity to the Oracle database.
A TimesTen database that is a participant in an active standby pair replication scheme
can provide high availability for cache tables in a read-only or an AWT cache group.
An active standby pair provides for fault tolerance of a TimesTen database. Oracle
Real Application Clusters (Oracle RAC) and Data Guard provides for high availability
of an Oracle database.
See Replicating Cache Tables in TimesTen Classic, Using Cache in an Oracle RAC
Environment, and Using Cache With Data Guard.
1-8
2
Getting Started
Getting Started provides a demonstration of how to create and use cache groups in TimesTen
Classic.
See Using Cache Groups in TimesTen Scaleout in the Oracle TimesTen In-Memory Database
Scaleout User's Guide for an illustration of the creation and use of static read-only cache
groups in TimesTen Scaleout.
This chapter demonstrates how to create a static read-only local cache group and a dynamic
updatable cache group in TimesTen Classic. In addition, this chapter describes how to
populate cache tables, and how to observe the transfer of updates between the cache tables
in the TimesTen database and the cached tables in the Oracle database.
• Setting Up the Oracle Database and TimesTen Classic Systems
• Creating Cache Groups
• Performing Operations on the Read-Only Cache Group
• Performing Operations on a Dynamically Updatable Cache Group
• Cleaning Up the TimesTen Classic and Oracle Database Systems
Setting Up the Oracle Database and TimesTen Classic Systems

Before you can create a cache group, you must first install TimesTen Classic and then
configure the Oracle Database and TimesTen Classic systems.
See Overview of the Installation Process in TimesTen Classic in the Oracle TimesTen In-
Memory Database Installation, Migration, and Upgrade Guide.
Note:
You must always install the TimesTen and Oracle databases on separate systems
to avoid negative performance results and resource contention between them for
memory, CPU time and disk I/O.
When using cache, TimesTen must know which Oracle database to connect to, which
credentials to use when connecting to the Oracle database and which users own the tables in
both TimesTen and Oracle databases.
1. Set Up Users in the Oracle Database.
2. Create a DSN for the TimesTen Database.
3. Set the Net Service Name for the Oracle Database in the tnsnames.ora File.
4. Create Users in the TimesTen Database.
5. Set the Cache Administration User Name and Password in the TimesTen Database.
2-1
Chapter 2
Set Up Users in the Oracle Database

Part of the setup for caching is to create a cache administration user and identify the
schema (and its owner) on the Oracle database.
• Create a cache administration user that creates and maintains Oracle Database
objects that store information used to manage the cache environment and enforce
predefined behaviors of particular cache group types.
• Identify one or more schemas and respective schema owners who own the Oracle
Database tables that you want to cache in a TimesTen database. If a schema does
not already exist, you can create it.
1. Use SQL*Plus on the Oracle Database system from an operating system shell or
command prompt, and connect to the Oracle database instance as the sys user.
2. Use SQL*Plus to create a default tablespace to be used for storing cache
metadata and management objects that should not be shared with other
applications. We strongly recommend that this tablespace be used solely by
TimesTen for cache management.
In the following example, the name of the default tablespace is cachetblsp:
SQL> CREATE TABLESPACE cachetblsp DATAFILE 'tt_cache.f' SIZE 5G

SEGMENT SPACE MANAGEMENT AUTO;
Tablespace created.
3. Use SQL*Plus to perform the following operations:

a. Create a cache administration user and specify the default tablespace that you
created for cache management objects.
b. Run the SQL*Plus script timesten_home/install/oraclescripts/
grantCacheAdminPrivileges.sql to grant the cache administration user the
minimum set of privileges required to perform cache group operations.
c. Pass the cache administration user name as the argument to the
grantCacheAdminPrivileges.sql script.
Note:
See the comments in the grantCacheAdminPrivileges.sql script for
the required privileges by the user who runs this script and the
privileges that this user grants to the cache administration user.
In the following example, the cache administration user name is cacheadmin:
SQL> CREATE USER cacheadmin IDENTIFIED BY orapwd

DEFAULT TABLESPACE cachetblsp QUOTA UNLIMITED ON cachetblsp;
SQL> @grantCacheAdminPrivileges "cacheadmin"
SQL> exit
2-2
Chapter 2
The privileges that the cache administration user requires depend on the types of
cache groups you create and the operations that you perform on the cache groups.
4. Grant additional privileges required for caching to the existing schema owner that owns
the tables you want to cache. In the following example, the schema owner is sales:
SQL> GRANT CREATE SESSION, CREATE TRIGGER, CREATE SEQUENCE, CREATE TYPE, CREATE
PROCEDURE, CREATE TABLE
TO sales;
See Create the Oracle Database Users and Default Tablespace for more information about
the schema owner and the cache administration user.
Create a DSN for the TimesTen Database

In the following data source name (DSN) examples, the net service name of the Oracle
database instance is oracledb and its database character set is AL32UTF8. The TimesTen
database character set must match the Oracle database character set. You can determine
the Oracle database character set by running the following query in SQL*Plus as any user:
SQL> SELECT value FROM nls_database_parameters WHERE parameter='NLS_CHARACTERSET';
On UNIX or Linux, in the .odbc.ini file that resides in your home directory or the
timesten_home/conf/sys.odbc.ini file, create a TimesTen DSN cache1 and set the
following connection attributes:
[cache1]
DataStore=/users/OracleCache/ttcache
PermSize=64
OracleNetServiceName=oracledb
DatabaseCharacterSet=AL32UTF8
On Windows, create a TimesTen user DSN or system DSN cache1 and set the following
connection attributes:
• Data Store Path + Name: c:\\temp\ttcache
• Permanent Data Size: 64
• Oracle Net Service Name: oracledb
• Database Character Set: AL32UTF8
Use the default settings for all the other connection attributes.
See Define a DSN for the TimesTen Classic Database for more information about defining a
DSN for a TimesTen database that caches data from an Oracle database.
See Managing TimesTen Databases in Oracle TimesTen In-Memory Database Operations
Guide for more information about TimesTen DSNs.
Note:
The term "data store" is used interchangeably with "TimesTen database".
2-3
Chapter 2
Set the Net Service Name for the Oracle Database in the
tnsnames.ora File
In order to connect to the Oracle database, its net service name needs to be added to
the tnsnames.ora file.
1. Set the TNS_ADMIN location for the cache agent with the ttInstanceModify -
tnsadmin option to set the path to the tnsnames.ora file. Specify the full path to
the directory where the file is located.
ttInstanceModify -tnsadmin /TimesTen/conf
2. For cache in TimesTen Classic, set the TNS_ADMIN environment variable to indicate
the full path to the directory where the tnsnames.ora file is located. Set this
variable in the user's profile script so that it persists.
export TNS_ADMIN=/TimesTen/tnsadmin
3. Restart the main daemon to capture this setting.

ttDaemonAdmin -stop
ttDaemonAdmin -start
Add the net service name for the Oracle Database to the tnsnames.ora file. The
following is an example of defining orcl in a tnsnames.ora file:
orcl =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = myhost)
(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = myhost.example.com)))
Create Users in the TimesTen Database

In addition to the Oracle database users, you must create two TimesTen users before
you can use cache.
2-4
Chapter 2
sales sales
owner of same name schema owner
cache tables of tables
cacheadmin cacheadmin
cache same name cache
administration administration
user user
TimesTen database Oracle database
• A TimesTen cache administration user performs cache group operations. The TimesTen
cache administration user must have the same name as the companion Oracle Database
cache administration user that can access the cached Oracle Database tables. The
password of the TimesTen cache administration user can be different than the password
of the companion Oracle Database cache administration user with the same name.
Typically, the companion Oracle Database user is the cache administration user. But it
can also be a schema owner or some other existing user. For ease of use, making the
cache administration user the companion Oracle Database user of the cache
administration user is preferable.
Note:
See Create the TimesTen Users for more details on the TimesTen cache
administration user and its companion Oracle Database cache administration
user.
• One or more cache table owner users that own the cache tables. You must create a user
that owns the TimesTen cache tables that has the same name as the schema owner that
owns Oracle Database tables to be cached in the TimesTen database. The password of a
cache table user can be different than the password of the Oracle Database schema
owner with the same name.
The names of all TimesTen cache tables have the same names of the corresponding
cached Oracle Database tables.
Use the ttIsql utility on the TimesTen system from an operating system shell or command
prompt as the instance administrator, and connect to the cache1 DSN to create the TimesTen
database that is to be used to cache data from an Oracle database:
% ttIsql cache1
Use ttIsql to create a cache administration user on TimesTen. Grant this user the minimum
set of privileges required to create cache groups and to perform operations on the cache
2-5
Chapter 2
Creating Cache Groups
groups. In the following example, the cache administration user name is cacheadmin,
which is the same name as the Oracle Database cache administration user that was
created earlier:
Command> CREATE USER cacheadmin IDENTIFIED BY ttpwd;
Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE TO cacheadmin;
Then, use ttIsql to create a cache table user. In the following example, the cache
table user name is sales, which is the same name as the schema owner that owns the
Oracle database tables that are to be cached.
Command> CREATE USER sales IDENTIFIED BY ttpwd;
Command> exit
The privileges that the cache administration user requires depend on the types of
cache groups you create and the operations that you perform on the cache groups.
See Create the TimesTen Users for more information about the cache administration
user and the cache table users.
See Authentication in TimesTen and Authorization in TimesTen in Oracle TimesTen In-
Memory Database Security Guide for more information about TimesTen users and
privileges.
Set the Cache Administration User Name and Password in the

TimesTen Database
Use the ttIsql utility to connect to the cache1 DSN as the cache administration user.
In the connection string, specify the TimesTen cache administration user name in the
UID connection attribute. Specify the TimesTen cache administration user's password
in the PWD connection attribute. Specify the password of the Oracle Database cache
administration user in the OraclePWD connection attribute within the connection string.
% ttIsql "DSN=cache1;UID=cacheadmin;PWD=ttpwd;OraclePWD=orapwd"
Use ttIsql to call the ttCacheUidPwdSet built-in procedure to set the Oracle
Database cache administration user name and password:
Command> call ttCacheUidPwdSet('cacheadmin','orapwd');
The Oracle Database cache administration user name and password need to be set
only once in a TimesTen database. See Set the Cache Administration User Name and
Password.

An example of a read-only cache group and an Asynchronous WriteThrough (AWT)
cache group.
This section creates a read-only cache group (as shown in Figure 2-1) and an
Asynchronous WriteThrough (AWT) cache group (as shown in Figure 2-2).
2-6
Chapter 2
Figure 2-1 Single-Table Read-Only Cache Group
TimesTen Oracle Database

Cache group Cache group
Cache Cache
group group
tables tables
Figure 2-2 Single-Table WriteThrough Cache Group
TimesTen Oracle Database

Cache group Cache group
Cache Cache
group group
tables tables
Complete the following tasks to create a read-only cache group and an AWT cache group:
1. Identify the Oracle Database Tables To Be Cached.
2. Start the Cache Agent.
3. Create the Cache Groups.
4. Start the Replication Agent for the AWT Cache Group.
Identify the Oracle Database Tables To Be Cached

After you identify one or more existing Oracle database schemas (and the respective schema
owners), then you can either cache from existing tables or create new tables to be cached.
You can also create new schemas, if necessary.
Use SQL*Plus and connect to the Oracle database as the schema owner:
% sqlplus sales/orapwd
Use SQL*Plus to create a table readtab as shown in Figure 2-3, and a table writetab as
shown in Figure 2-4:
SQL> CREATE TABLE readtab (keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR2(32));
SQL> CREATE TABLE writetab (pk NUMBER NOT NULL PRIMARY KEY, attr VARCHAR2(40));
2-7
Chapter 2
Figure 2-3 Creating an Oracle Database Table to Be Cached in a Read-Only

Cache Group
Application
...
CREATE TABLE readtab .....

INSERT INTO readtab VALUES (1, 'Hello')
INSERT INTO readtab VALUES (2, 'World')
Oracle
database
readtab
1 Hello
2 World
Figure 2-4 Creating an Oracle Database Table to Be Cached in an AWT Cache

Group
Application
...
CREATE TABLE writetab .....

INSERT INTO writetab VALUES (100, 'TimesTen')
INSERT INTO writetab VALUES (101, 'CACHE')
Oracle
database
writetab
100 Oracle
101 CACHE
2-8
Chapter 2
Then use SQL*Plus to insert some rows into the readtab and writetab tables, and commit
the changes:
SQL> INSERT INTO readtab VALUES (1, 'Hello');
SQL> INSERT INTO readtab VALUES (2, 'World');
SQL> INSERT INTO writetab VALUES (100, 'TimesTen');

SQL> INSERT INTO writetab VALUES (101, 'CACHE');
SQL> COMMIT;
Next use SQL*Plus to grant the SELECT privilege on the readtab table, and the SELECT,
INSERT, UPDATE and DELETE privileges on the writetab table to the cache administration user:
SQL> GRANT SELECT ON readtab TO cacheadmin;
SQL> GRANT SELECT ON writetab TO cacheadmin;

SQL> GRANT INSERT ON writetab TO cacheadmin;
SQL> GRANT UPDATE ON writetab TO cacheadmin;
SQL> GRANT DELETE ON writetab TO cacheadmin;
The SELECT privilege on the readtab table is required to create a read-only cache group that
caches this table and to perform autorefresh operations from the cached Oracle Database
table to the TimesTen cache table.
The SELECT privilege on the writetab table is required to create an AWT cache group that
caches this table. The INSERT, UPDATE, and DELETE privileges on the writetab table are
required to run write through operations from the TimesTen cache table to the cached Oracle
Database table.
See Grant Privileges to the Oracle Cache Administration User for more information about the
privileges required for the cache administration user to create and perform operations on a
read-only cache group and an AWT cache group.
Start the Cache Agent

As the cache administration user, use the ttIsql utility to call the ttCacheStart built-in
procedure to start the cache agent on the TimesTen database.
Command> call ttCacheStart;
See Managing the Cache Agent.
Create the Cache Groups

As the cache administration user, use the ttIsql utility to create a read-only cache group
readcache that caches the Oracle Database sales.readtab table and a dynamic AWT cache
group writecache that caches the Oracle Database sales.writetab table:
Command> CREATE READONLY CACHE GROUP readcache
AUTOREFRESH INTERVAL 5 SECONDS
FROM sales.readtab
(keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR2(32));
Command> CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP writecache

FROM sales.writetab
(pk NUMBER NOT NULL PRIMARY KEY, attr VARCHAR2(40));
2-9
Chapter 2
The cache groups readcache and writecache, and their respective cache tables
sales.readtab and sales.writetab, whose table owners and table names are
identical to the cached Oracle Database schema and tables, are created in the
TimesTen database. Figure 2-5 shows that the writecache cache group caches the
sales.writetab table.
Figure 2-5 Creating an Asynchronous WriteThrough Cache Group
Application
...
CREATE READONLY
CACHE GROUP writecache ...
TimesTen
Oracle
database
database
TimesTen cache
sales.writetab
100 Oracle writetab
101 CACHE
100 Oracle
101 CACHE
writecache
Use the ttIsql cachegroups command to view the definition of the readcache and
writecache cache groups:
Command> cachegroups;
Cache Group CACHEADMIN.READCACHE:
Cache Group Type: Read Only

Autorefresh: Yes
Autorefresh Mode: Incremental
Autorefresh State: Paused
Autorefresh Interval: 5 Seconds
Autorefresh Status: ok
Aging: No aging defined
Root Table: SALES.READTAB

Table Type: Read Only
Cache Group CACHEADMIN.WRITECACHE:
Cache Group Type: Asynchronous Writethrough (Dynamic)
2-10
Chapter 2
Performing Operations on the Read-Only Cache Group
Autorefresh: No
Aging: LRU on
Root Table: SALES.WRITETAB

Table Type: Propagate
2 cache groups found.
See Read-Only Cache Group for more information about read-only cache groups.
See Asynchronous WriteThrough (AWT) Cache Group for more information about AWT
cache groups.
See Creating a Dynamic Cache Group With the DYNAMIC Keyword for more information
about dynamic cache groups.
Start the Replication Agent for the AWT Cache Group

As the TimesTen cache adminstration user, use the ttIsql utility to call the ttRepStart built-in
procedure to start the replication agent on the TimesTen database.
Command> call ttRepStart;
The replication agent propagates committed changes on TimesTen cache tables in AWT
cache groups to the cached Oracle Database tables.
See Starting and Stopping the Replication Agent.

After you manually load the read-only cache group, you can show the TimesTen cache table
automatically refreshed with committed changes on the cached Oracle Database table.
Complete the following tasks to perform operations on the read-only cache group:
1. Manually Load the Cache Group.
2. Update the Cached Oracle Database Table.
Manually Load the Cache Group

As the TimesTen cache administration user, use the ttIsql utility to load the contents of the
Oracle database sales.readtab table into the TimesTen sales.readtab cache table in the
readcache cache group. Use parellelism when a large amount of data is to be loaded.
Command> LOAD CACHE GROUP readcache COMMIT EVERY 256 ROWS PARALLEL 3;
2 cache instances affected.
Command> exit
Figure 2-6 shows that the Oracle database data is loaded into the sales.readtab cache
table.
2-11
Chapter 2
Figure 2-6 Loading a Read-Only Cache Group
TimesTen Oracle
database database
TimesTen cache
sales.readtab
Load Cache Group
1 Hello readtab
2 World 1 Hello
2 World
readcache
Start the ttIsql utility and connect to the cache1 DSN as the instance administrator.
Use ttIsql to grant the SELECT privilege on the sales.readtab cache table to the
TimesTen cache administration user so that this user can issue a SELECT query on this
table.
% ttIsql cache1
Command> GRANT SELECT ON sales.readtab TO cacheadmin;
Command> exit
Start the ttIsql utility and connect to the cache1 DSN as the TimesTen cache
administration user, including the TimesTen cache administration user password and
the Oracle cache administration user password. Use ttIsql to query the contents of
sales.readtab cache table.
% ttIsql "DSN=cache1;UID=cacheadmin;PWD=timesten;OraclePWD=orapwd"
Command> SELECT * FROM sales.readtab;
< 1, Hello >
< 2, World >
2 rows found.
See Manually Loading and Refreshing a Cache Group.
Update the Cached Oracle Database Table

Use SQL*Plus as the Oracle database schema user to insert a new row, delete an
existing row, update an existing row in the Oracle database readtab table, and commit
the changes.
SQL> INSERT INTO readtab VALUES (3, 'Welcome');
SQL> DELETE FROM readtab WHERE keyval=2;
SQL> UPDATE readtab SET str='Hi' WHERE keyval=1;
SQL> COMMIT;
Since the read-only cache group was created specifying autorefresh with an interval of
5 seconds, the sales.readtab cache table in the readcache cache group is
automatically refreshed after 5 seconds with the committed changes on the cached
Oracle Database sales.readtab table as shown in Figure 2-7.
2-12
Chapter 2
Performing Operations on a Dynamically Updatable Cache Group
Figure 2-7 Automatically Refresh the Cache Table With Oracle Database Updates
Application
...
INSERT INTO readtab VALUES (3,'Welcome');

DELETE FROM readtab WHERE keyval=2;
UPDATE readtab SET str='Hi' WHERE keyval=1;
COMMIT;
TimesTen Oracle
database database
TimesTen cache
sales.readtab Automatic refresh

1 Hi readtab
readtab
3 Welcome 1 HiHi
33 Welcome
Welcome
readcache
As the TimesTen cache administration user, use the ttIsql utility to query the contents of the
sales.readtab cache table after the readcache cache group has been automatically
refreshed with the committed changes on the cached Oracle database table:
Command> SELECT * FROM sales.readtab;
< 1, Hi >
< 3, Welcome >
2 rows found.
Command> exit
See Automatically Refreshing a Cache Group.
Performing Operations on a Dynamically Updatable Cache

Group
After you dynamically load an AWT cache group, you can show that committed changes on
the TimesTen cache table are automatically propagated to the cached Oracle Database table.
Complete the following tasks to perform operations on the AWT cache group:
1. Dynamically Load the Cache Group.
2. Update the TimesTen Cache Table.
2-13
Chapter 2
Dynamically Load the Cache Group

Use the ttIsql utility to connect to the cache1 DSN as the instance administrator.
Grant the SELECT privilege on the sales.writetab cache table to the TimesTen cache
administration user so that this user can issue a dynamic load SELECT statement on
this table.
% ttIsql cache1
Command> GRANT SELECT ON sales.writetab TO cacheadmin;
Command> exit
administration user, including the cache administration user password and the
password of its companion Oracle cache administration user. Use ttIsql to load a
cache instance on demand from the Oracle Database sales.writetab table to the
TimesTen sales.writetab cache table in the writecache cache group.
Command> SELECT * FROM sales.writetab WHERE pk=100;
< 100, TimesTen >
1 row found.
Command> exit
In a dynamic cache group, a cache instance can be loaded into its cache tables on
demand with a dynamic load statement. A SELECT, UPDATE, DELETE or INSERT
statement issued on a TimesTen cache table that uniquely identifies a cache instance
results in the cache instance being automatically loaded from the cached Oracle
Database table if the data is not found in the cache table.
Data can also be explicitly loaded into the cache tables of a dynamic cache group
using a LOAD CACHE GROUP statement.
See Manually or Dynamically Loading Cache Groups.
Update the TimesTen Cache Table

You can update the cache tables in TimesTen after the appropriate privileges are
assigned.
Grant the INSERT, DELETE, and UPDATE privileges on the sales.writetab cache table to
the TimesTen cache administration user so that this user can perform updates on this
table.
% ttIsql cache1
Command> GRANT INSERT ON sales.writetab TO cacheadmin;
Command> GRANT DELETE ON sales.writetab TO cacheadmin;
Command> GRANT UPDATE ON sales.writetab TO cacheadmin;
Command> exit
Use the ttIsql utility to connect to the cache1 DSN as the cache administration user.
Insert a new row, delete an existing row, update an existing row in the sales.writetab
cache table, and commit the changes.
Command> INSERT INTO sales.writetab VALUES (102, 'Cache');
2-14
Chapter 2
Command> DELETE FROM sales.writetab WHERE pk=101;

Command> UPDATE sales.writetab SET attr='Oracle' WHERE pk=100;
Command> COMMIT;
Command> exit
The committed changes on the sales.writetab cache table in the writecache cache group
are automatically propagated to the Oracle Database sales.writetab table as shown in
Figure 2-8.
Figure 2-8 Automatically Propagate TimesTen Cache Table Updates to Oracle

Database
Application
...
INSERT INTO sales.writetab VALUES (102, 'Cache');

DELETE FROM sales.writetab WHERE pk=101;
UPDATE sales.writetab SET attr='Oracle' WHERE pk=100;
COMMIT;
TimesTen Oracle
database database
TimesTen cache
sales.writetab
Writethrough
(automatic propagate)
100
101
Oracle
CACHE
writetab
100 Oracle
101 CACHE
writecache
As the Oracle database schema user, use SQL*Plus to query the contents of the writetab
table:
SQL> SELECT * FROM writetab;
PK ATTR
---------- -------------------------------
100 Oracle
102 Cache
SQL> exit
2-15
Chapter 2
Cleaning Up the TimesTen Classic and Oracle Database Systems
Cleaning Up the TimesTen Classic and Oracle Database

Systems
Run the relevant tasks to restore the TimesTen Classic and Oracle Database systems
to their original state before creating cache groups.
1. Stop the Replication Agent.
2. Drop the Cache Groups.
3. Stop the Cache Agent and Destroy the TimesTen Database.
4. Drop the Oracle Database Users and Their Objects.
Stop the Replication Agent

As the TimesTen cache administration user, use the ttIsql utility to call the ttRepStop
built-in procedure to stop the replication agent on the TimesTen database.
Command> call ttRepStop;
Command> exit
Drop the Cache Groups

Grant the DROP ANY TABLE privilege to the TimesTen cache administration user so that
this user can drop the underlying cache tables when dropping the cache groups.
% ttIsql cache1
Command> GRANT DROP ANY TABLE TO cacheadmin;
Command> exit
administration user. Use ttIsql to drop the readcache read-only cache group and the
writecache AWT cache group.
Command> DROP CACHE GROUP readcache;
Command> DROP CACHE GROUP writecache;
The cache groups readcache and writecache, and their respective cache tables
sales.readtab and sales.writetab, are dropped from the TimesTen database.
See Dropping a Cache Group.
Stop the Cache Agent and Destroy the TimesTen Database

As the TimesTen cache administration user, use the ttIsql utility to call the
ttCacheStop built-in procedure to stop the cache agent on the TimesTen database.
Command> call ttCacheStop;
Command> exit
2-16
Chapter 2
Cleaning Up the TimesTen Classic and Oracle Database Systems

Then, use the ttDestroy utility to connect to the cache1 DSN and destroy the TimesTen
database:
% ttDestroy cache1
Drop the Oracle Database Users and Their Objects

Use SQL*Plus to connect to the Oracle database as the sys user. Use SQL*Plus to drop the
schema user sales and the Oracle cache administration user cacheadmin.
SQL> DROP USER sales CASCADE;
SQL> DROP USER cacheadmin CASCADE;
Specifying CASCADE in a DROP USER statement drops all objects such as tables and triggers
owned by the user before dropping the user itself.
Next, use SQL*Plus to drop the TT_CACHE_ADMIN_ROLE role:
SQL> DROP ROLE TT_CACHE_ADMIN_ROLE;
Then, use SQL*Plus to drop the default tablespace cachetblsp used by the cache
administration user including the contents of the tablespace and its data file:
SQL> DROP TABLESPACE cachetblsp INCLUDING CONTENTS AND DATAFILES;
SQL> exit
2-17
3
Setting Up a Caching Infrastructure
Before you can start caching Oracle database data in a TimesTen database, you must first
install TimesTen.
Follow the instructions provided in Overview of the Installation Process in TimesTen Classic
in the Oracle TimesTen In-Memory Database Installation, Migration, and Upgrade Guide.
After which, perform these tasks for setting up the TimesTen and Oracle database systems:
• Configuring the Oracle Database to Cache Data
• Configuring a TimesTen Database to Cache Oracle Database Data
• Testing the Connectivity Between the TimesTen and Oracle Databases
• Managing the Cache Agent
Configuring the Oracle Database to Cache Data

The following sections describe the tasks that must be performed on the Oracle database by
the sys user:
• Create the Oracle Database Users and Default Tablespace

• Grant Privileges to the Oracle Cache Administration User
• Create Oracle Database Objects Used to Manage Data Caching
Create the Oracle Database Users and Default Tablespace

Create a default tablespace to store meta information about cache operations. Create a
cache administration user that creates, owns, and maintains Oracle database objects that
store information used to manage the cache environment for a TimesTen database and
enforce predefined behaviors of particular cache group types.
Perform the following on the Oracle database:
Note:
You cannot use the Oracle Autonomous Database for transaction processing (ATP)
as a source for caching data in TimesTen. In addition, if you are using a multitenant
container database (CDB) or pluggable database (PDB), note the specific
instructions below on how to create the cache administration user and grant this
user privileges in a CDB or PDB.
1. Create a default tablespace that stores information about cache operations.

This tablespace is used for storing cache management objects that should not be shared
with other applications. While you may also store Oracle database tables that are cached
3-1
Chapter 3
in a TimesTen database, we strongly recommend that this tablespace be used

solely by the TimesTen database for cache management.
Note:
See Managing a Cache Environment With Oracle Database Objects for
a list of Oracle database tables used by the cache administration user.
In the following SQL*Plus example, the default tablespace is cachetblsp and

defines a 5 GB data file named tt_cache.f. Choose a size that is appropriate for
your particular needs. Provide the SEGMENT SPACE MANAGEMENT AUTO clause so
that the Oracle database automatically manages the free space of all segments in
the tablespace (useful for monitoring autorefresh).
Note:
The use of the sys@tnsservicename as sysdba user in this example is
applicable only for a test environment.
% cd timesten_home/install/oraclescripts
% sqlplus sys@tnsservicename as sysdba
Enter password: password
SQL> CREATE TABLESPACE cachetblsp DATAFILE 'tt_cache.f' SIZE 5G
SEGMENT SPACE MANAGEMENT AUTO;
Tablespace created.
2. Create a cache administration user that creates, owns, and maintains Oracle
database objects that store information used to manage the cache environment for
a TimesTen database and enforce predefined behaviors of particular cache group
types.
If you are using a multitenant container database (CDB) or pluggable database
(PDB), the cache administrator user can be one of the following:
• Local user: A local user is a database user that can operate only within a
single PDB. You must assign cache privileges only within the PDB in which
this user exists.
• Common user: A common user is a database user known in every container
and has the same identity in the CBD root and in every existing and future
PDB in the CDB. You must assign cache privileges within each PDB in the
CDB in which you want to use cache.
3-2
Chapter 3
Note:
Each TimesTen database can be managed by only a single cache
administration user on the Oracle database. However, a single cache
administration user can manage multiple TimesTen databases. You can specify
one or more cache administration users where each manages one or more
TimesTen databases.
See Caching the Same Oracle Table on Two or More TimesTen Databases.
Designate the tablespace as the default tablespace for the cache administration user.
This user creates tables in this tablespace that are used to store information about the
cache environment and its cache groups. Other Oracle Database objects (such change
log tables, replication metadata tables, and triggers) are used to enforce the predefined
behaviors of cache groups with autorefresh and AWT cache groups are created in the
same tablespace. To create and manage these objects, the cache administration user
must have a high level of privileges. A cache group with autorefresh refers to a read-only
cache group or a user managed cache group that uses the AUTOREFRESH MODE
INCREMENTAL cache group attribute.
See Managing a Cache Environment With Oracle Database Objects for a list of Oracle
Database tables and triggers owned by the cache administration user.
Note:
If you create multiple cache administration users, each may use the same or
different tablespace as their default tablespace.
As the sys user, use SQL*Plus to create the Oracle database cache administration user
cacheadmin. In the following example, the default tablespace for the cacheadmin user is
cachetblsp.
SQL> CREATE USER cacheadmin IDENTIFIED BY orapwd
DEFAULT TABLESPACE cachetblsp QUOTA UNLIMITED ON cachetblsp;
3. Identify one or more existing schemas (or create a new schema) with schema owners
that own Oracle database tables that are to be cached in a TimesTen database. The
tables to be cached may or may not already exist.
Grant the schema owner the minimum set of privileges required to create tables in the
Oracle database to be cached in a TimesTen database.
This example will cache tables owned by the sales schema owner. As the sys user, the
following SQL*Plus example grants the necessary privileges required to this user.
SQL> GRANT CREATE SESSION, CREATE TABLE, CREATE CLUSTER, CREATE INDEXTYPE, CREATE
OPERATOR
TO sales;
Grant Privileges to the Oracle Cache Administration User

The cache administration user must be granted a high level of privileges depending on the
cache group types created and the operations performed on these cache groups.
3-3
Chapter 3
You can run the SQL*Plus script timesten_home/install/oraclescripts/

grantCacheAdminPrivileges.sql as the sys user to grant the cache administration
user the minimum set of privileges required to perform cache operations.
If you are using a multitenant container database (CDB) or pluggable database (PDB),
run the SQL*Plus script timesten_home/install/oraclescripts/
grantCacheAdminPrivileges.sql to assign cache privileges as follows:
• If the cache administrator user is a local user: You must assign cache privileges
only within the PDB in which this user exists. This is the preferred method.
• If the cache administrator user is a common user: You must assign cache
privileges within each PDB in the CDB in which you want to use cache. Do not run
the SQL*Plus script to grant privileges to the common user in the CBD root.
See Create Oracle Database Objects Used to Manage Data Caching.
The entire list of privileges required for this user for each cache operation are listed in
Required Privileges for Cache Operations.
Create Oracle Database Objects Used to Manage Data Caching

You request TimesTen to create Oracle database objects owned by the cache
administration user, such as cache and replication metadata tables, change log tables,
and triggers when particular cache environment and cache group operations are
performed.
Some of these objects are used to enforce the predefined behaviors of cache groups
with autorefresh and AWT cache groups.
These Oracle database objects are automatically created if the cache administration
user has been granted the required privileges with one of the following SQL*Plus
scripts:
• The grantCacheAdminPrivileges.sql Script: Run this script to grant all required
privileges to the cache administration user that are required to create Oracle
database objects used to manage the caching of Oracle database data when
particular cache group operations are performed. The cache administration user
then automatically creates Oracle database objects used to manage caching
Oracle database data in a TimesTen database.
• The initCacheAdminSchema.sql Script: Run this script to grant all required
privileges except for the CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR,
CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, and EXECUTE ON
SYS.DBMS_LOB package privileges. For security reasons, you may not want to grant
these privileges. The cache administration user then automatically creates all
Oracle database objects used to manage caching Oracle database data in a
TimesTen database, except for cache groups that use autorefresh.
The grantCacheAdminPrivileges.sql Script

The grantCacheAdminPrivileges.sql script grants privileges to the cache
administration user that are required to automatically create Oracle Database objects
used to manage the caching of Oracle Database data when particular cache group
operations are performed.
3-4
Chapter 3
See Required Privileges for Cache Operations for a complete list of privileges that need to be
granted to the cache administration user in order to perform particular cache group and
cache table operations.
Run the timesten_home/install/oraclescripts/grantCacheAdminPrivileges.sql as the
sys user. The cache administration user name is passed as an argument to the
grantCacheAdminPrivileges.sql script.
Note:
Alternatively, you can create these objects as described in The
initCacheAdminSchema.sql Script before performing any cache group operations if,
for security purposes, you do not want to grant certain privileges to the cache
administration user required to automatically create objects necessary for managing
autorefresh.
In addition to the privileges granted to the cache administration user by running the
grantCacheAdminPrivileges.sql script, this user may also need to be granted privileges
such as SELECT or INSERT on the cached Oracle Database tables depending on the types of
cache groups you create, and the operations that you perform on the cache groups and their
cache tables.
As the sys user, use SQL*Plus to run the grantCacheAdminPrivileges.sql script to grant
privileges to the cache administration user. The cache administration user then automatically
creates Oracle Database objects used to manage caching Oracle Database data in a
TimesTen database.
The grantCacheAdminPrivileges.sql script requires the Oracle database cache
administration user name as input, which is cacheadmin in this example.
SQL> @grantCacheAdminPrivileges "cacheadmin"
SQL> exit
For example, with cache groups with autorefresh, the Oracle database objects used to
enforce the predefined behaviors of these cache group types are automatically created if the
objects do not already exist and one of the following occurs:
• The cache group is created with its autorefresh state set to PAUSED or ON.
• The cache group is created with its autorefresh state set to OFF and then altered to either
PAUSED or ON.
The initCacheAdminSchema.sql Script

The Oracle database cache administration user requires certain privileges to automatically
create the Oracle database objects.
The cache administration user requires privileges used to:
• Store information about TimesTen databases that are associated with a particular cache
environment.
• Enforce the predefined behaviors of cache groups with autorefresh. In this case, the
cache administration user requires certain privileges to automatically create these Oracle
database objects.
3-5
Chapter 3
Configuring a TimesTen Database to Cache Oracle Database Data
• Enforce the predefined behavior for AWT cache groups.

For security purposes, if you do not want to grant the CREATE CLUSTER, CREATE
INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE,
and EXECUTE ON SYS.DBMS_LOB package privileges to the cache administration user
required to automatically create the Oracle Database objects, you can use the
initCacheAdminSchema.sql script. See Required Privileges for Cache Operations for a
full list of privileges granted by this script.
To create the Oracle Database tables and triggers used to enforce the predefined
behaviors of particular cache group types, run the SQL*Plus script timesten_home/
install/oraclescripts/initCacheAdminSchema.sql as the sys user. These objects
must be created before you can create cache groups with autorefresh and AWT cache
groups. The initCacheAdminSchema.sql script requires the cache administration user
name as input.
In addition to the privileges granted to the cache administration user by running the
initCacheAdminSchema.sql script, you may need to grant the user privileges such as
SELECT or INSERT on the cached Oracle Database tables depending on the types of
cache groups you create and the operations that you perform on the cache groups and
their cache tables.
As the sys user, use SQL*Plus to run the initCacheAdminSchema.sql script to create
Oracle Database objects, which are used to manage caching data. These Oracle
Database objects enforce the predefined behaviors of a cache group with autorefresh
and AWT cache groups, and grant a limited set of privileges to the cache
administration user. In the following example, the Oracle database cache
administration user name is cacheadmin.
SQL> @initCacheAdminSchema "cacheadmin"
SQL> exit
Other Oracle database objects associated with Oracle database tables that are
cached in a cache group with autorefresh are needed to enforce the predefined
behaviors of these cache group types. See Manually Creating Oracle Database
Objects for Cache Groups With Autorefresh for details about how to create these
additional objects as part of the steps for creating a cache group with autorefresh.
To view a list of the Oracle database objects created and used by TimesTen to
manage the caching of Oracle database data, run the following query in SQL*Plus as
the sys user:
SQL> SELECT owner, object_name, object_type FROM all_objects WHERE object_name
2 LIKE 'TT\___%' ESCAPE '\';
The query returns a list of tables, indexes, and triggers owned by the cache
administration user.
Configuring a TimesTen Database to Cache Oracle

Database Data
Certain operations must be performed on the TimesTen database by the instance
administrator or the TimesTen cache administration user.
• Specify Database Connection Definition for Cache
3-6
Chapter 3
• Create the TimesTen Users

• Grant Privileges to the TimesTen Users
• Set the Cache Administration User Name and Password
Specify Database Connection Definition for Cache

You can modify certain cache-related connection attributes to define connection attributes.
• Define a DSN for the TimesTen Classic Database
• Define Database Definition and Connectable in TimesTen Scaleout
• Set the Net Service Name for the Oracle Database in the tnsnames.ora File
Define a DSN for the TimesTen Classic Database

A TimesTen database that caches data from an Oracle database can be referenced by either
a system DSN or a user DSN. When creating a DSN for a TimesTen database that caches
data from an Oracle database, pay special attention to the settings of the connection
attributes.
See Managing TimesTen Databases in Oracle TimesTen In-Memory Database Operations
Guide.
All of these connection attributes can be set in a direct DSN or a connection string, unless
otherwise stated.
• PermSize specifies the allocated size of the database's permanent region in MB. The
PermSize value must be smaller than the physical RAM on the machine. The PermSize
value could be from a few GB to several TB. Set this value to at least 32 MB.
• OracleNetServiceName must be set to the net service name of the Oracle database
instance.
For Microsoft Windows systems, the net service name of the Oracle database instance
must be specified in the Oracle Net Service Name field of the TimesTen Cache tab
within the TimesTen ODBC Setup dialog box.
• DatabaseCharacterSet must match the Oracle database character set.
You can determine the Oracle database character set by running the following query in
SQL*Plus as any user:
SQL> SELECT value FROM nls_database_parameters
WHERE parameter='NLS_CHARACTERSET';
• UID specifies the name of the TimesTen cache administration user. The UID connection
attribute can be specified in a direct DSN, a client DSN, or a connection string.
• PWD specifies the password of the TimesTen cache administration user specified in the
UID connection attribute. The PWD connection attribute can be specified in a direct DSN, a
client DSN, or a connection string.
• OraclePWD specifies the password of the companion Oracle Database cache
administration user that has the same name as the TimesTen cache administration user
specified in the UID connection attribute.
3-7
Chapter 3
Note:
See Create the TimesTen Users.
• PassThrough can be set to control whether statements are to be run in the

TimesTen database or passed through to be processed in the Oracle database.
See Setting a Passthrough Level.
• LockLevel must be set to its default of 0 (row-level locking) because cache does
not support database-level locking.
• ReplicationApplyOrdering and CacheAWTParallelism control parallel
propagation of changes to TimesTen cache tables in an AWT cache group to the
corresponding Oracle Database tables. See Improving AWT Throughput With
Parallel Propagation to the Oracle Database.
The following example defines the cache1 DSN for a TimesTen database that caches
data from an Oracle database:
[cache1]
DataStore=/users/OracleCache/ttcache
PermSize=64
OracleNetServiceName=orcl
DatabaseCharacterSet=WE8ISO8859P1
Define Database Definition and Connectable in TimesTen Scaleout

In TimesTen Scaleout, a database definition contains the description of a database. It
defines the database name, as well as the attributes of the database. A database
definition can be used to create a database.
Each database has one or more connectables associated with it. Connectables specify
how applications connect to the database. A connectable defines a name that
applications can use to connect to a database.
See Create a Database Definition for the TimesTen Database and Create a
Connectable for the TimesTen Database in the Oracle TimesTen In-Memory Database
Scaleout User's Guide for connection attributes that relate to cache.
Set the Net Service Name for the Oracle Database in the tnsnames.ora File
For cache in TimesTen Classic, set the TNS_ADMIN environment variable to indicate the
full path to the directory where the tnsnames.ora file is located. This is for access to
Oracle Database data.
1. Set the TNS_ADMIN location for the cache agent with the ttInstanceModify -
tnsadmin option to set the path to the tnsnames.ora file. Specify the full path to
the directory where the file is located.
2. For cache in TimesTen Classic, set the TNS_ADMIN environment variable to indicate
the full path to the directory where the tnsnames.ora file is located. Set this
variable in the user's profile script so that it will persist.
3-8
Chapter 3
ttDaemonAdmin -stop
Add the net service name for the Oracle database into the tnsnames.ora file. The following is
an example of defining orcl in a tnsnames.ora file:
orcl =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = myhost)
(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = myhost.example.com)))
For TimesTen Scaleout, use ttGridAdmin commands to import or export tnsnames.ora or

sqlnet.ora configuration for connecting to an Oracle database. See Add the Oracle
Database Net Service Name to the tnsnames.ora File in the Oracle TimesTen In-Memory
Database Scaleout User's Guide.
Create the TimesTen Users

First, you must create a user who performs cache group operations on the TimesTen
database. We refer to this user as the TimesTen database cache administration user.
The TimesTen database cache administration user must have the same name as a
companion Oracle Database cache administration user that can access the cached Oracle
Database tables. For example, the companion Oracle Database cache administration user
must have privileges to select from and update the cached Oracle Database tables. The
password of the TimesTen database cache administration user can be different than the
password of the companion Oracle Database cache administration user.
The companion Oracle Database user is normally the cache administration user. However, if
you are concerned with the high level of privileges assigned to the cache administration user,
then choose another Oracle Database user as the companion Oracle user.
Note:
You can create multiple cache administration users on a TimesTen database, such
as one for each TimesTen DBA. However, you can only define a single cache
administration user on the Oracle database for this particular TimesTen database.
(You can use the same Oracle database cache administration user for all TimesTen
databases that connect to the Oracle database or define a separate cache
administration user for each TimesTen database.) If you create multiple TimesTen
cache administration users, one or more of these users can use the same Oracle
database cache administration user.
The TimesTen database cache administration user creates the cache groups. It may perform
operations such as loading or refreshing a cache group although these operations can be
performed by any TimesTen user that has sufficient privileges. The TimesTen database cache
administration user can also monitor various aspects of the caching environment, such as
asynchronous operations that are performed on cache groups such as autorefresh.
Then, you must create a user with the same name as the Oracle Database schema owner
who owns Oracle Database tables to be cached in the TimesTen database. We refer to these
users as cache table users, because the TimesTen cache tables are to be owned by these
3-9
Chapter 3
users. Therefore, the owner and name of a TimesTen cache table is the same as the
schema owner and name of the corresponding cached Oracle Database table. The
password of a cache table user can be different than the password of the Oracle
Database schema owner with the same name.
Operations on a cache group or a cache table, such as loading a cache group or
updating a cache table, can be performed by any TimesTen user that has sufficient
privileges. In the examples throughout this guide, the TimesTen database cache
administration user performs these types of operations although these operations can
be performed by another user, such as a cache table user, that has the required
privileges. If these operations are to be performed by a TimesTen user other than the
cache administration user, the other user must have the same name as the companion
Oracle Database cache administration user that can select from and update the
cached Oracle Database tables. Connect to the TimesTen database specifying that
user's name in the UID connection attribute, and supply the corresponding TimesTen
and Oracle Database passwords in the PWD and OraclePWD connection attributes,
respectively, to perform operations on a cache group or cache table.
The following example creates the TimesTen users.
The following example uses the ttIsql utility to connect to the cache1 DSN as the
instance administrator.
• Creates the TimesTen database cache administration user cacheadmin whose
name (in this example) is the same as the Oracle database cache administration
user.
• Creates a cache table user sales whose name is the same as the Oracle
Database schema owner of the Oracle Database tables to be cached in the
TimesTen database.
% ttIsql cache1
Command> CREATE USER cacheadmin IDENTIFIED BY ttpwd;
Command> CREATE USER sales IDENTIFIED BY ttpwd;
Grant Privileges to the TimesTen Users

The privileges that the TimesTen users require depend on the types of cache groups
you create and the operations that you perform on the cache groups.
All of the privileges required for the TimesTen cache administration user for each
cache operation are listed in Required Privileges for Cache Operations.
You must grant required privileges to the cache administration user. This example
grants the cacheadmin cache administration user the following required privileges to
perform the noted operations:
• Set the cache administration user and password (CACHE_MANAGER).
• Start or stop the cache agent and replication agent processes on the TimesTen
database (CACHE_MANAGER).
• Set a cache agent start policy (CACHE_MANAGER).
• Set a replication agent start policy (ADMIN)
• Create cache groups to be owned by the cache administration user (CREATE [ANY]
CACHE GROUP, inherited by the CACHE_MANAGER privilege; CREATE [ANY] TABLE to
3-10
Chapter 3
create the underlying cache tables which are to be owned by the cache table user).
• Alter, load, refresh, flush, unload or drop a cache group requires the appropriate privilege:
– ALTER ANY CACHE GROUP
– LOAD {ANY CACHE GROUP | ON cache_group_name
– REFRESH {ANY CACHE GROUP | ON cache_group_name
– FLUSH {ANY CACHE GROUP | ON cache_group_name
– UNLOAD {ANY CACHE GROUP | ON cache_group_name
– DROP ANY CACHE GROUP and DROP ANY TABLE
• Required privileges for other cache operations, such as dynamic load, full autorefresh
and asynchronous writethrough, are listed in Required Privileges for Cache Operations.
As the instance administrator, use the ttIsql utility to grant the cacheadmin cache
administration user the required privileges:
Command> exit
Set the Cache Administration User Name and Password

You must set the Oracle database cache administration user name and password in the
TimesTen database before any cache group operation can be issued.
The cache agent connects to the Oracle database as this user to create and maintain Oracle
Database objects that store information used to enforce predefined behaviors of particular
cache group types. In addition, both the cache and replication agents connect to the Oracle
database with the credentials set to manage Oracle database operations.
The Oracle database cache administration user name and password need to be set only
once in each TimesTen database that caches Oracle Database data unless it needs to be
changed. For example, if you modify the password of the cache administration user, if the
TimesTen database is destroyed and re-created, or if the Oracle cache administration user
name is dropped and re-created in the Oracle database, the Oracle cache administration
user name and password must be set again.
The Oracle cache administration user name cannot be changed if there are cache groups in
the database. The cache groups must be dropped before you can drop and recreate the
cache administration user. See Changing Cache User Names and Passwords.
The following sections detail the different tools provided in TimesTen Classic and TimesTen
Scaleout:
• Setting the Cache Administration User Name and Password in TimesTen Classic
• Setting the Cache Administration User Name and Password in TimesTen Scaleout
Setting the Cache Administration User Name and Password in TimesTen Classic
In TimesTen Classic, you can programmatically set the Oracle cache administration user
name and password by calling the ttCacheUidPwdSet built-in procedure after connecting as
the Timesten cache administration user.
3-11
Chapter 3
Testing the Connectivity Between the TimesTen and Oracle Databases
It can also be set from a command line by running a ttAdmin -cacheUidPwdSet utility
command as a TimesTen external user with the CACHE_MANAGER privilege:
% ttAdmin -cacheUidPwdSet -cacheUid cacheadmin -cachePwd orapwd cache1
If you do not specify the -cachePwd option, the ttAdmin utility prompts for the cache
administration user's password.
See ttAdmin in Oracle TimesTen In-Memory Database Reference.
Note:
When you connect to the TimesTen database to work with AWT or read-only
cache groups, TimesTen Classic uses the credentials set with the
ttCacheUidPwdSet built-in procedure when connecting to the Oracle
database on behalf of these cache groups.
When you connect to the TimesTen database to work with SWT or user
managed cache groups or passthrough operations, TimesTen Classic
connects to the Oracle database using the current user's credentials as the
user name and the OraclePwd connection attribute as the Oracle password.
Thus, the correct user name and Oracle database password that should be
used for connecting to the Oracle database must be set correctly in the
connection string or with the connection attributes.
Setting the Cache Administration User Name and Password in TimesTen

Scaleout
In TimesTen Scaleout, use the ttGridAdmin dbCacheCredentialSet command to set
the Oracle cache administration user name and password.
% ttGridAdmin dbCacheCredentialSet database1
Provide Oracle user id: cacheadmin
Provide Oracle password: orapwd
See Set the Cache Administration User Name and Password in the TimesTen
Database in the Oracle TimesTen In-Memory Database Scaleout User's Guide.
Testing the Connectivity Between the TimesTen and Oracle

Databases
If connectivity has been successfully established, the query returns the version of the
Oracle database.
To test the connectivity between the TimesTen and Oracle databases, set the
passthrough level to 3 and run the following query, to be processed on the Oracle
database, as the TimesTen cache administration user:
Command> passthrough 3;
Command> SELECT * FROM V$VERSION;
3-12
Chapter 3
Managing the Cache Agent
If it does not, check the following for correctness:

• The Oracle net service name set in the OracleNetServiceName connection attribute and
the state of the Oracle database server
• The settings of the shared library search path environment variable such as
LD_LIBRARY_PATH or SHLIB_PATH
• The setting of the cache administration user name in the TimesTen database
You can retrieve the Oracle cache administration user name setting by calling the
ttCacheUidGet built-in procedure as the TimesTen cache administration user:
Command> call ttCacheUidGet;
In TimesTen Classic, the Oracle cache administration user name can also be returned from a
command line by running a ttAdmin -cacheUidGet utility command as a TimesTen external
user with the CACHE_MANAGER privilege:
% ttAdmin -cacheUidGet cache1

The cache agent process performs cache operations such as loading a cache group and
autorefresh, as well as manages Oracle Database objects used to enforce the predefined
behaviors of particular cache group types.
• Starting the Cache Agent
• Stopping the Cache Agent
• Set a Cache Agent Start Policy in TimesTen Classic
Starting the Cache Agent

You can manually start the cache agent.
Start the cache agent with the following:
• In TimesTen Scaleout, use the ttGridAdmin dbCacheStart command to start the cache
agent on all instances in the grid. See Start a Cache Agent for TimesTen Scaleout in the
Oracle TimesTen In-Memory Database Scaleout User's Guide.
• In TimesTen Classic, call the ttCacheStart built-in procedure as the TimesTen cache
administration user:
You can also start the cache agent from a command line by running a ttAdmin -
cacheStart utility command as a TimesTen external user with the CACHE_MANAGER
privilege:
% ttAdmin -cacheStart cache1
Stopping the Cache Agent

You can manually stop the cache agent.
Stop the cache agent by performing the following:
3-13
Chapter 3
• In TimesTen Scaleout, use ttGridAdmin dbCacheStop command to stop the cache

agent on all instances within the grid. See Stopping the Cache Agents for
TimesTen Scaleout in the Oracle TimesTen In-Memory Database Scaleout User's
Guide.
• In TimesTen Classic, call the ttCacheStop built-in procedure as the TimesTen
cache administration user:
You can also stop the cache agent from a command line by running a ttAdmin -
cacheStop utility command as a TimesTen external user with the CACHE_MANAGER
privilege:
% ttAdmin -cacheStop cache1
Do not stop the cache agent immediately after you have dropped or altered a
cache group with autorefresh. Instead, wait for at least two minutes to allow the
cache agent to clean up Oracle Database objects such as change log tables and
triggers that were created and used to manage the cache group.
The ttCacheStop built-in procedure has an optional parameter and the ttAdmin -
cacheStop utility command has an option -stopTimeout that specifies how long
the TimesTen main daemon process waits for the cache agent to stop. If the cache
agent does not stop within the specified timeout period, the TimesTen daemon
stops the cache agent. The default cache agent stop timeout is 100 seconds. A
value of 0 specifies to wait indefinitely.
Note:
The TimesTen X/Open XA and Java Transaction API (JTA) implementations
do not work with cache. The start of any XA or JTA transaction fails if the
cache agent is running.
Set a Cache Agent Start Policy in TimesTen Classic

A cache agent start policy determines how and when the cache agent process starts
on a TimesTen Classic database.
Note:
In TimesTen Scaleout, the grid manages the cache agent start policy.
The cache agent start policy can be set to:

• manual
• always
• norestart
The default start policy is manual, which means the cache agent must be started
manually by calling the ttCacheStart built-in procedure or running a ttAdmin -
3-14
Chapter 3
cacheStart utility command. To manually stop a running cache agent process, call the
ttCacheStop built-in procedure or run a ttAdmin -cacheStop utility command.
When the start policy is set to always, the cache agent starts automatically when the
TimesTen main daemon process starts. With the always start policy, the cache agent cannot
be stopped when the main daemon is running unless the start policy is first changed to either
manual or norestart. Then issue a manual stop by calling the ttCacheStop built-in procedure
or running a ttAdmin -cacheStop utility command.
With the manual and always start policies, the cache agent automatically restarts when the
database recovers after a failure such as a database invalidation.
Setting the cache agent start policy to norestart means the cache agent must be started
manually by calling the ttCacheStart built-in procedure or running a ttAdmin -cacheStart
utility command, and stopped manually by calling the ttCacheStop built-in procedure or
running a ttAdmin -cacheStop utility command.
With the norestart start policy, the cache agent does not automatically restart when the
database recovers after a failure such as a database invalidation. You must restart the cache
agent manually by calling the ttCacheStart built-in procedure or running a ttAdmin -
cacheStart utility command.
Note:
See ttAdmin, ttCachePolicySet, ttCacheStart and ttCacheStop in the Oracle
TimesTen In-Memory Database Reference.
You can set the cache agent start policy in TimesTen Classic by calling the
ttCachePolicySet built-in procedure as the TimesTen cache administration user:
Command> call ttCachePolicySet('always');
It can also be set from a command line by running a ttAdmin -cachePolicy utility command
as a TimesTen external user with the CACHE_MANAGER privilege:
% ttAdmin -cachePolicy norestart cache1
3-15
4
Defining Cache Groups
There are several different types of cache groups. There are reasons for when to use each
type of cache group for different purposes, performance and availability needs. In addition,
there are different features that you can add to provide certain functionality to a specific
cache group type.
• Cache Groups and Cache Tables
• Creating a Cache Group
• Read-Only Cache Group
• Asynchronous WriteThrough (AWT) Cache Group
• Synchronous WriteThrough (SWT) Cache Group
• Hybrid Cache Group
• User Managed Cache Group
• Using a WHERE Clause
• Specifying Automatic Refresh With the AUTOREFRESH Cache Group Attribute
• Creating a Dynamic Cache Group With the DYNAMIC Keyword
• Creating a Hash Index on the Primary Key Columns of the Cache Table
• ON DELETE CASCADE Cache Table Attribute
• Caching Oracle Database Synonyms
• Caching Oracle Database LOB Data
• Implementing Aging in a Cache Group for TimesTen Classic
• Replicating Cache Tables in TimesTen Classic
Cache Groups and Cache Tables

A cache group defines the Oracle Database data to cache in the TimesTen database. When
you create a cache group, cache tables are created in the TimesTen database that
correspond to the Oracle Database tables being cached.
A separate table definition must be specified in the cache group definition for each Oracle
Database table that is being cached. The owner, table name, and cached column names of a
TimesTen cache table must match the schema owner, table name, and column names of the
corresponding cached Oracle Database table. The cache table can contain all or a subset of
the columns and rows of the cached Oracle Database table. Each TimesTen cache table
must have a primary key.
An Oracle Database table cannot be cached in more than one cache group within the same
TimesTen database. However, the table can be cached in separate cache groups in different
TimesTen databases.
If a table is cached in separate AWT cache groups and the same cache instance is updated
simultaneously on multiple TimesTen databases, there is no guarantee as to the order in
4-1
Chapter 4
which the updates are propagated to the cached Oracle Database table. In this case,
the contents of the updated cache table may be inconsistent between the TimesTen
databases.
Before you define the cache group table, create the Oracle Database tables that are to
be cached. Each table should be either:
• An Oracle Database table with a primary key on non-nullable columns. The
TimesTen cache table primary key must be defined on the full Oracle Database
table primary key. For example, if the cached Oracle Database table has a
composite primary key on columns c1, c2 and c3, the TimesTen cache table must
also have a composite primary key on columns c1, c2 and c3.
The following example shows how to create a cache group from an Oracle
Database table with a composite primary key. The following job_history table
was created with a composite key on the Oracle database:
CREATE TABLE job_history
(employee_id NUMBER(6) NOT NULL,
start_date DATE NOT NULL,
end_date DATE NOT NULL,
job_id VARCHAR2(10) NOT NULL,
department_id NUMBER(4),
PRIMARY KEY(employee_id, start_date));
Table created.
Create the cache group on the TimesTen database with all columns of the
composite primary key:
CREATE WRITETHROUGH CACHE GROUP job_hist_cg
FROM sales.job_history
(employee_id NUMBER(6) NOT NULL,
start_date DATE NOT NULL,
end_date DATE NOT NULL,
job_id VARCHAR2(10) NOT NULL,
department_id NUMBER(4),
PRIMARY KEY(employee_id, start_date));
• An Oracle Database table with non-nullable columns upon which a unique index is
defined on one or more of the non-nullable columns in the table. The TimesTen
cache table primary key must be defined on all of the columns in the unique index.
For example, if the unique index for the Oracle Database table is made up of
multiple columns c1, c2, and c3, the TimesTen cache table must have a composite
primary key on columns c1, c2, and c3.
The following examples show how Oracle Database unique indexes were defined
on tables with non-nullable columns.
SQL> CREATE TABLE regions(
region_id NUMBER NOT NULL,
region_name VARCHAR2(25));
Table created.
SQL> CREATE UNIQUE INDEX region_idx
ON regions(region_id);
Index created.
SQL> CREATE TABLE products(

prod_id INT NOT NULL,
cust_id INT NOT NULL,
quantity_sold INT NOT NULL,
time_id DATE NOT NULL);
4-2
Chapter 4
Table created.
SQL> CREATE UNIQUE INDEX products_index ON products(prod_id, cust_id);
Index created.
Based on these Oracle Database tables and unique indexes, you can create cache
groups on a TimesTen database for these tables using the unique index columns as the
primary key definition as shown below:
Command> CREATE WRITETHROUGH CACHE GROUP region_cg
FROM sales.regions
(region_id NUMBER NOT NULL PRIMARY KEY,
region_name VARCHAR2(25));
Command> CREATE WRITETHROUGH CACHE GROUP products_cg

FROM sales.products
(prod_id INT NOT NULL, cust_id INT NOT NULL,
quantity_sold INT NOT NULL, time_id DATE NOT NULL,
PRIMARY KEY(prod_id, cust_id));
A TimesTen database can contain multiple cache groups. A cache group can contain one or
more cache tables.
Creating indexes on a cache table in TimesTen can help speed up particular queries issued
on the table in the same fashion as on a TimesTen regular table. You can create non-unique
indexes on a TimesTen cache table. Do not create unique indexes on a cache table that do
not match any unique index on the cached Oracle Database table. Otherwise, it can cause
unique constraint failures in the cache table that do not occur in the cached Oracle Database
table, and result in these tables in the two databases being no longer synchronized with each
other when autorefresh operations are performed.
Single-Table Cache Group

The simplest cache group is one that caches a single Oracle Database table. In a single-table
cache group, there is a root table but no child tables.
Figure 4-1 shows a single-table cache group target_customers that caches the customer
table.
4-3
Chapter 4
Figure 4-1 Cache Group With a Single Table
TimesTen
Cache group target_customers
customer
cust_num* region name ...
122 West Jim Johnston ...
Oracle
database
customer
122 West Jim John ...
342 West Jane Stone ...
942 East Terry Boone ...
Multiple-Table Cache Group

A multiple-table cache group is one that defines a root table and one or more child
tables.
A cache group can only contain one root table. The root table does not reference any
table with a foreign key constraint.
In a cache group with multiple tables on TimesTen, each child table must reference the
primary key or a unique index of the root table or of another child table in the cache
group using a foreign key constraint. Although tables in a multiple-table cache group in
the TimesTen database must be related to each other through foreign key constraints,
the corresponding tables in the Oracle database do not necessarily need to be
explicitly related to each other. The tables on the Oracle database can be related:
• Explicitly through a foreign key constraint.
• Implicitly related by the user application (those that update the Oracle database).
The user application could maintain a relationship between tables that is not
enforced by the Oracle database.
Figure 4-2 shows a multiple-table cache group customer_orders that caches the
customer, orders and order_item tables. Each parent table in the customer_orders
cache group has a primary key that is referenced by a child table through a foreign key
constraint. The customer table is the root table of the cache group because it does not
4-4
Chapter 4
reference any table in the cache group with a foreign key constraint. The primary key of the
root table is considered the primary key of the cache group. The orders table is a child table
of the customer root table. The order_item table is a child table of the orders child table.
Figure 4-2 Cache Group With Multiple Tables
TimesTen
customer (Root table)
cust_num region name address
orders Oracle
ord_num cust_num when_placed when_shipped database
44325 122 10/7/16 10/7/16
customer
65432 122 8/24/16 8/27/16
Child 76543 663 4/2/16 4/8/16
Tables Data for all customers
order_item orders

order_item
44325 SD07 1
44325 TR3A 5
65432 FT094 1
76543 SD07 2
The table hierarchy in a multiple-table cache group can designate child tables to be parents
of other child tables. A child table cannot reference more than one parent table. However, a
parent table can be referenced by more than one child table.
Figure 4-3 shows an improper cache table hierarchy. Neither the customer nor the product
table references a table in the cache group with a foreign key constraint. This results in the
cache group having two root tables which is invalid.
4-5
Chapter 4
Figure 4-3 Problem: Cache Group Contains Two Root Tables
TimesTen
customer (Root table) Cannot Define
cust_num region name address Two Root Tables
product
orders
prod_name name price ship_weight description
ord_num cust_num when_placed when_shipped
SD07 1” brad $4.50 2 lbs brad
44325 122 10/7/16 10/7/16
TR3A .3” washer $1.94 5.4 lbs washer
65432 122 8/24/16 8/27/16
FT094 .4” washer $2.76 7.5 lbs washer
76543 663 4/2/16 4/8/16
order_item inventory
ord_num prod_num quantity prod_num warehouse quantity
44325 SD07 1 SD07 NewYork 2000
44325 TR3A 5 TR3A London 10000
65432 FT094 1 FT094 London 30000
76543 SD07 2 FT133 London 5000
Oracle
database
inventory
customer
product
orders
order_item
To resolve this problem and cache all the tables, create a cache group which contains
the customer, orders, and order_item tables, and a second cache group which
contains the product and the inventory tables as shown in Figure 4-4.
4-6
Chapter 4
Creating a Cache Group
Figure 4-4 Solution: Create Two Cache Groups
TimesTen
Cache group customer_orders Cache group product_inventory
customer (Root table) product
cust_num region name address prod_name name price ship_weight description
122 West Jim Johnston 231 Main, Needles, CA 92363 SD07 1” brad $4.50 2 lbs brad
342 West Jane Stone 43 Cope, Palo Alto, CA 94302 TR3A .3” washer $1.94 5.4 lbs washer
663 Midwest Mary J. Warren 673 State, Madison, WI 53787 FT094 .4” washer $2.76 7.5 lbs washer
orders
inventory
ord_num cust_num when_placed when_shipped
prod_num warehouse quantity
44325 122 10/7/16 10/7/16
SD07 NewYork 2000
65432 122 8/24/16 8/27/16
TR3A London 10000
76543 663 4/2/16 4/8/16
FT094 London 30000
FT133 London 5000
order_item
44325 SD07 1
44325 TR3A 5
65432 FT094 1
76543 SD07 2
Oracle
database
inventory
customer
product
orders
order_item
Creating a Cache Group

You create cache groups by using a CREATE CACHE GROUP SQL statement or by using Oracle
SQL Developer, a graphical tool.
For more information about SQL Developer, see Oracle TimesTen In-Memory Database SQL
Developer Support User's Guide.
Cache groups must be created by and are owned by the TimesTen cache administration user.
You cannot cache Oracle Database data in a temporary database.
Cache groups are identified as either system managed or user managed. System managed
cache groups enforce specific behaviors, while the behavior of a user managed cache group
can be customized.
System managed cache groups include:
• Read-Only Cache Group: Committed updates on the cached Oracle Database tables are
automatically refreshed to the cache tables on TimesTen. The TimesTen cache tables
cannot be updated directly.
4-7
Chapter 4
Read-Only Cache Group
• Asynchronous WriteThrough (AWT) Cache Group: Committed updates on the

TimesTen cache tables are automatically and asynchronously propagated to the
• Synchronous WriteThrough (SWT) Cache Group: Committed updates on the
TimesTen cache tables are automatically and synchronously propagated to the
• Hybrid Cache Group: Dynamically load committed updates from cache tables that
do not have a root table on the Oracle database.
User Managed Cache Group: Customize caching behavior. If the system managed
cache groups do not satisfy your application's requirements, you can create a user-
managed cache group that defines customized caching behavior with cache table
attributes.
You can define how data is loaded:
• Static cache group: Cache instances are loaded manually into the TimesTen cache
tables.
• Dynamic cache group: Cache instances are loaded into the TimesTen cache
tables on demand from an Oracle database using a dynamic load operation or
manually using a load operation.
See Transmitting Changes Between the TimesTen and Oracle Databases.
The following topics also apply to creating a cache group:
• Creating a Dynamic Cache Group With the DYNAMIC Keyword that enables
dynamic load of new cache instances updated on cached Oracle database tables
into TimesTen cache groups.
• Automatically Refreshing a Cache Group: The AUTOREFRESH cache table attribute
specifies that committed changes on cached Oracle Database tables are
automatically refreshed to read-only TimesTen cache tables.
• Using a WHERE Clause: You can restrict the rows to cache in the TimesTen
database for particular cache group types.
• ON DELETE CASCADE Cache Table Attribute: Specifies that when rows
containing referenced key values are deleted from a parent table, rows in child
tables with dependent foreign keys are also deleted.
• Creating a Hash Index on the Primary Key Columns of the Cache Table: Specifies
that a hash index rather than a range index is created on the primary key columns
of the cache table.

A read-only cache group enforces a caching behavior where the TimesTen cache
tables cannot be updated directly, and committed changes on the cached Oracle
Database tables are automatically refreshed to the cache tables.
See Figure 4-5.
4-8
Chapter 4
Figure 4-5 Read-Only Cache Group
TimesTen
Application
database
TimesTen cache
Readonly
cache group
Passthrough SQL* Autorefresh

from Oracle
Oracle
database
* Depending on the PassThrough attribute setting
If the TimesTen database is unavailable for whatever reason, you can still update the Oracle
Database tables that are cached in a read-only cache group. When the TimesTen database
returns to operation, updates that were committed on the cached Oracle Database tables
while the TimesTen database was unavailable are automatically refreshed to the TimesTen
cache tables.
Both TimesTen Classic and TimesTen Scaleout support read-only cache groups. TimesTen
Classic supports all read-only cache groups. TimesTen Scaleout only supports static read-
only cache groups with incremental autorefresh. See Using Cache Groups in TimesTen
Scaleout in the Oracle TimesTen In-Memory Database Scaleout User's Guide.
Note:
When TimesTen manages operations for read only cache groups, it connects to the
Oracle database using the Oracle cache administration user name and password.
For more details, see Set the Cache Administration User Name and Password.
The following are example definitions of the Oracle Database tables that are to be cached in
read-only cache groups. The Oracle Database tables are owned by the schema user sales.
The sales user must be granted the CREATE SESSION, CREATE TRIGGER, CREATE SEQUENCE,
CREATE TYPE, CREATE PROCEDURE, and CREATE TABLE privileges before it can create tables.
4-9
Chapter 4
CREATE TABLE customer

(cust_num NUMBER(6) NOT NULL PRIMARY KEY,
region VARCHAR2(10),
name VARCHAR2(50),
address VARCHAR2(100));
CREATE TABLE orders

(ord_num NUMBER(10) NOT NULL PRIMARY KEY,
cust_num NUMBER(6) NOT NULL,
when_placed DATE NOT NULL,
when_shipped DATE NOT NULL);
The companion Oracle Database cache administration user must be granted the
SELECT privilege on the sales.customer and sales.orders tables in order for the
TimesTen cache administration user to create a read-only cache group that caches
these tables, and for autorefresh operations to occur from the cached Oracle
Database tables to the TimesTen cache tables.
Use the CREATE READONLY CACHE GROUP statement to create a read-only cache group.
The following statement creates a read-only cache group customer_orders that

caches the tables sales.customer (root table) and sales.orders (child table):
CREATE READONLY CACHE GROUP customer_orders
FROM sales.customer
(cust_num NUMBER(6) NOT NULL,
name VARCHAR2(50),
address VARCHAR2(100),
PRIMARY KEY(cust_num)),
sales.orders
(ord_num NUMBER(10) NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num),
FOREIGN KEY(cust_num) REFERENCES sales.customer(cust_num));
By default, all read-only cache groups are defined with incremental autorefresh
paused with the default interval value. Perform a LOAD CACHE GROUP statement for the
first load of the read-only cache group since the cache tables are empty. The
autorefresh state changes from PAUSED to ON after the LOAD CACHE GROUP statement
completes.
The cache tables in a read-only cache group cannot be updated directly. However, you
can set the passthrough level to 2 to allow committed update operations issued on a
TimesTen cache table to be passed through and processed on the cached Oracle
Database table, and then have the updates be automatically refreshed into the cache
table. See Setting a Passthrough Level.
The effects of a passed through statement on cache tables in a read-only cache group
do not occur in the transaction in which the update operation was issued. Instead, they
are seen after the passed through update operation has been committed on the Oracle
database and the next automatic refresh of the cache group has occurred. The
companion Oracle Database cache administration user must be granted the INSERT,
UPDATE and DELETE privileges on the Oracle Database tables that are cached in the
read-only cache group in order for the passed through update operations to be
processed on the cached Oracle Database tables.
4-10
Chapter 4
If you manually created the Oracle Database objects used to enforce the predefined
behaviors of a cache group with autorefresh as described in The initCacheAdminSchema.sql
Script, you need to set the autorefresh state to OFF when creating the cache group.
Then you need to run the ttIsql utility's cachesqlget command to generate a SQL*Plus
script used to create a log table and a trigger in the Oracle database for each Oracle
Database table that is cached in the read-only cache group. See Manually Creating Oracle
Database Objects for Cache Groups With Autorefresh for how to create these objects.
Restrictions With Read-Only Cache Groups

Certain restrictions apply to read-only cache groups.
The following restrictions apply when using a read-only cache group:
• The cache tables on TimesTen cannot be updated directly.
• Only the ON DELETE CASCADE and UNIQUE HASH ON cache table attributes can be used in
the cache table definitions.
See ON DELETE CASCADE Cache Table Attribute.
See Creating a Hash Index on the Primary Key Columns of the Cache Table.
• A FLUSH CACHE GROUP statement cannot be issued on the cache group.
See Flushing a User Managed Cache Group.
• A TRUNCATE TABLE statement issued on a cached Oracle Database table is not
automatically refreshed to the TimesTen cache table.
• A LOAD CACHE GROUP statement can only be issued on the cache group if the cache
tables are empty, unless the cache group is dynamic.
See Creating a Dynamic Cache Group With the DYNAMIC Keyword.
• The autorefresh state must be PAUSED before you can issue a LOAD CACHE GROUP
statement on the cache group, unless the cache group is dynamic, in which case the
autorefresh state must be PAUSED or ON. The LOAD CACHE GROUP statement cannot contain
a WHERE clause, unless the cache group is dynamic, in which case the WHERE clause must
be followed by a COMMIT EVERY n ROWS clause.
See Automatically Refreshing a Cache Group.
See Using a WHERE Clause.
• The autorefresh state must be PAUSED before you can issue a REFRESH CACHE GROUP
statement on the cache group. The REFRESH CACHE GROUP statement cannot contain a
WHERE clause.
• All tables and columns referenced in WHERE clauses when creating, loading or unloading
the cache group must be fully qualified. For example:
owner.table_name and owner.table_name.column_name
• Least recently used (LRU) aging cannot be specified on the cache group, unless the
cache group is dynamic where LRU aging is defined by default.
4-11
Chapter 4
Asynchronous WriteThrough (AWT) Cache Group
• Read-only cache groups cannot cache Oracle Database views or materialized

views.

An Asynchronous WriteThrough (AWT) cache group enforces a caching behavior
where committed changes on the TimesTen cache tables are automatically and
asynchronously propagated to the cached Oracle Database tables.
See Figure 4-6.
Only TimesTen Classic supports AWT cache groups.
Note:
You should avoid running DML statements on Oracle Database tables
cached in an AWT cache group. This can result in an error condition. See
Restrictions With AWT Cache Groups.
Figure 4-6 AWT Cache Group
TimesTen
Application database
TimesTen cache
AWT
cache group
Automatically
propagate Load upon
updates request
Oracle
database
Since an AWT cache group propagates data from the TimesTen database to the
Oracle database, any data modified by the user in the cached tables on the Oracle
database is not automatically uploaded from the Oracle database to the TimesTen
4-12
Chapter 4
database. In this case, you must explicitly unload and then reload the AWT cache groups on
TimesTen.
The transaction commit on the TimesTen database occurs asynchronously from the commit
on the Oracle database. This enables an application to continue issuing transactions on the
TimesTen database without waiting for the Oracle Database transaction to complete.
However, your application cannot ensure when the transactions are completed on the Oracle
database.
Processing of the UNLOAD CACHE GROUP statement for an AWT cache group waits until
updates on the rows have been propagated to the Oracle database.
You can update cache tables in an AWT cache group even if the Oracle database is
unavailable. When the Oracle database returns to operation, updates that were committed on
the cache tables while the Oracle database was unavailable are automatically propagated to
the cached Oracle Database tables.
Note:
When TimesTen manages operations for AWT cache groups, it connects to the
Oracle database using the Oracle cache administration user name and password
set with the ttCacheUidPwdSet built-in procedure. For more details on
ttCacheUidPwdSet, see Set the Cache Administration User Name and Password.
The following is an example of a definition of the Oracle Database table that is to be cached
in an AWT cache group. The Oracle Database table is owned by the schema user sales. The
sales user must be granted the CREATE SESSION, CREATE TRIGGER, CREATE SEQUENCE, CREATE
TYPE, CREATE PROCEDURE, and CREATE TABLE privileges before it can create tables.
name VARCHAR2(50),
The companion Oracle cache administration user must be granted the SELECT privilege on the
sales.customer table in order for the TimesTen cache administration user to create an AWT
cache group that caches this table. The Oracle cache administration user must be granted
the INSERT, UPDATE and DELETE Oracle Database privileges on the sales.customer table for
asynchronous writethrough operations to be applied to the Oracle Database.
Use the CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP statement to create an AWT
cache group.
The following statement creates an AWT cache group new_customers that caches the
sales.customer table:
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers
FROM sales.customer
name VARCHAR2(50),
PRIMARY KEY(cust_num));
4-13
Chapter 4
The following sections describe configuration, behavior, and management for AWT
cache groups:
• Starting and Stopping the Replication Agent
• Setting a Replication Agent Start Policy
• Monitoring Propagation of Transactions to the Oracle Database
• Disabling Propagation of Committed Changes
• Configuring Parallel Propagation to the Oracle Database
• What an AWT Cache Group Does and Does Not Guarantee
• Restrictions With AWT Cache Groups
• Reporting Oracle Database Permanent Errors for AWT Cache Groups
Starting and Stopping the Replication Agent

Performing asynchronous writethrough operations requires that the replication agent
be running on the TimesTen database that contains AWT cache groups.
Running a CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP statement creates a
replication scheme that enables committed changes on the TimesTen cache tables to
be asynchronously propagated to the cached Oracle Database tables.
After you have created AWT cache groups, start the replication agent on the TimesTen
database by calling the ttRepStart built-in procedure as the cache administration
user.
Command> call ttRepStart;
It can also be started from a command line by running a ttAdmin -repStart utility
command as a TimesTen external user with the CACHE_MANAGER privilege:
% ttAdmin -repStart cache1
The replication agent does not start unless there is at least one AWT cache group or
replication scheme in the TimesTen database.
If the replication agent is running, it must be stopped before you can issue another
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP statement or a DROP CACHE GROUP
statement on an AWT cache group.
You can stop the replication agent by calling the ttRepStop built-in procedure as the
cache administration user:
Command> call ttRepStop;
You can also stop the replication agent from a command line with the ttAdmin -
repStop utility command as a TimesTen external user with the CACHE_MANAGER
privilege:
% ttAdmin -repStop cache1
4-14
Chapter 4
Setting a Replication Agent Start Policy

Performing asynchronous writethrough operations requires that the replication agent be
running on the TimesTen database that contains AWT cache groups. You can set a
replication agent start policy to determine how and when the replication agent process starts
on a TimesTen database.
The default start policy is manual which means the replication agent must be started manually
by calling the ttRepStart built-in procedure or running a ttAdmin -repStart utility
command. To manually stop a running replication agent process, call the ttRepStop built-in
procedure or run a ttAdmin -repStop utility command.
The start policy can be set to always so that the replication agent starts automatically when
the TimesTen main daemon process starts. With the always start policy, the replication agent
cannot be stopped when the main daemon is running unless the start policy is changed to
either manual or norestart and then a manual stop is issued by calling the ttRepStop built-in
procedure or running a ttAdmin -repStop utility command.
With the manual and always start policies, the replication agent automatically restarts after a
failure such as a database invalidation.
The start policy can be set to norestart which means the replication agent must be started
manually by calling the ttRepStart built-in procedure or running a ttAdmin -repStart utility
command, and stopped manually by calling the ttRepStop built-in procedure or running a
ttAdmin -repStop utility command.
With the norestart start policy, the replication agent does not automatically restart after a
failure such as a database invalidation. You must restart the replication agent manually by
calling the ttRepStart built-in procedure or running a ttAdmin -repStart utility command.
Perform the following to set the replication agent start policy:

1. Before you set a replication agent start policy, grant the ADMIN privilege to the TimesTen
cache administration user as the instance administrator.
% ttIsql cache1
Command> GRANT ADMIN TO cacheadmin;
Command> exit
2. Set the replication agent start policy by calling the ttRepPolicySet built-in procedure as
the TimesTen cache administration user:
Command> call ttRepPolicySet('manual');
Command> exit
Alternately, set the replication agent start policy from a command line by running a
ttAdmin -repPolicy utility command as a TimesTen external user with the ADMIN
privilege:
% ttAdmin -repPolicy always cache1
Monitoring Propagation of Transactions to the Oracle Database

Since the AWT cache group uses the replication agent to asynchronously propagate
transactions to the Oracle database, these transactions remain in the transaction log buffer
4-15
Chapter 4
and transaction log files until the replication agent confirms they have been fully
processed by the Oracle database.
You can monitor the propagation for these transactions with the ttLogholds built-in
procedure.
When you call the ttLogHolds built-in procedure, the description field contains
_ORACLE to identify the transaction log hold for the AWT cache group propagation.
Command> call ttLogHolds();
< 0, 18958336, Checkpoint , cache1.ds0 >
< 0, 19048448, Checkpoint , cache1.ds1 >
< 0, 19050904, Replication , ADC6160529:_ORACLE >
3 rows found.
See the Show Replicated Log Records section in the Oracle TimesTen In-Memory
Database Replication Guide.
You can also improve performance by configuring parallel propagation to the Oracle
Database. See Improving AWT Throughput With Parallel Propagation to the Oracle
Database.
Disabling Propagation of Committed Changes

If there are updates from DML statements that you do not want propagated to the
Oracle database, then you can disable propagation of committed changes (as a result
of running DML statements) within the current transaction to the Oracle database by
setting the flag in the ttCachePropagateFlagSet built-in procedure to zero.
After the flag is set to zero, the effects of running any DML statements are never
propagated to the back-end Oracle database. Thus, these updates exist only on the
TimesTen database. You can then re-enable propagation by resetting the flag to one
with the ttCachePropagateFlagSet built-in procedure. After the flag is set back to one,
propagation of all committed changes to the Oracle database resumes. The
propagation flag automatically resets to one after the transaction is committed or rolled
back. See ttCachePropagateFlagSet in the Oracle TimesTen In-Memory Database
Reference.
Configuring Parallel Propagation to the Oracle Database

To improve throughput for an AWT cache group, you can configure multiple threads
that act in parallel to propagate and apply transactional changes to the Oracle
database.
Parallel propagation enforces transactional dependencies and applies changes in
AWT cache tables to Oracle Database tables in commit order. See Improving AWT
Throughput With Parallel Propagation to the Oracle Database.
What an AWT Cache Group Does and Does Not Guarantee

An AWT cache group comes with some guarantees.
An AWT cache group can guarantee that:
• No transactions are lost because of communication failures between the TimesTen
and Oracle databases.
4-16
Chapter 4
• If the replication agent is not running or loses its connection to the Oracle database,
automatic propagation of committed changes on the TimesTen cache tables to the
cached Oracle Database tables resumes after the agent restarts or reconnects to the
Oracle database.
• Transactions are committed in the Oracle database in the same order they were
committed in the TimesTen database.
An AWT cache group cannot guarantee that:
• All transactions committed successfully in the TimesTen database are successfully
propagated to and committed in the Oracle database. Execution errors on the Oracle
database cause the transaction in the Oracle database to be rolled back. For example,
an update on the Oracle database may fail because of a unique constraint violation.
Transactions that contain execution errors are not retried.
Execution errors are considered permanent errors and are reported to the
TimesTenDatabaseFileName.awterrs file that resides in the same directory as the
TimesTen database's checkpoint files. See Reporting Oracle Database Permanent Errors
for AWT Cache Groups.
• The absolute order of Oracle Database updates is preserved because TimesTen does not
resolve update conflicts. The following are some examples:
– In two separate TimesTen databases (DB1 and DB2), different AWT cache groups
cache the same Oracle Database table. An update is committed on the cache table in
DB1. An update is then committed on the cache table in DB2. The two cache tables
reside in different TimesTen databases and cache the same Oracle Database table.
Because the writethrough operations are asynchronous, the update from DB2 may get
propagated to the Oracle database before the update from DB1, resulting in the
update from DB1 overwriting the update from DB2.
– An update is committed on a cache table in an AWT cache group. The same update
is committed on the cached Oracle Database table using a passthrough operation.
The cache table update, which is automatically and asynchronously propagated to
the Oracle database, may overwrite the passed through update that was processed
directly on the cached Oracle Database table depending on when the propagated
update and the passed through update is processed on the Oracle database. For this
and other potential error conditions, TimesTen recommends that you do not run DML
statements directly against Oracle Database tables cached in an AWT cache group.
For more information, see Restrictions With AWT Cache Groups.
Restrictions With AWT Cache Groups

Certain restrictions apply when using an AWT cache group.
The following restrictions apply when using an AWT cache group:
• Only the ON DELETE CASCADE and UNIQUE HASH ON cache table attributes can be used in
the cache table definitions.
See ON DELETE CASCADE Cache Table Attribute.
See Creating a Hash Index on the Primary Key Columns of the Cache Table.
• The cache table definitions cannot contain a WHERE clause.
4-17
Chapter 4

• A TRUNCATE TABLE statement cannot be issued on the cache tables.
• AWT cache groups cannot cache Oracle Database views or materialized views.
• The replication agent must be stopped before creating or dropping an AWT cache
group.
• Committed changes on the TimesTen cache tables are not propagated to the
cached Oracle Database tables unless the replication agent is running.
• To create an AWT cache group, the length of the absolute path name of the
TimesTen database cannot exceed 248 characters.
• You should avoid running DML statements on Oracle Database tables cached in
an AWT cache group. This could result in an error condition. Any insert, update, or
delete operation on the cached Oracle Database table can negatively affect the
operations performed on TimesTen for the affected rows. TimesTen does not
detect or resolve update conflicts that occur on the Oracle database. Committed
changes made directly on a cached Oracle Database table may be overwritten by
a committed update made on the TimesTen cache table when the cache table
update is propagated to the Oracle database. In addition, deleting rows on the
cached Oracle Database table could cause an empty update if TimesTen tries to
update a row that no longer exists.
To ensure that not all data is restricted from DML statements on Oracle Database,
you can partition the data on Oracle Database to separate the data that is to be
included in the AWT cache group from the data to be excluded from the AWT
cache group.
• TimesTen performs deferred checking when determining whether a single SQL
statement causes a constraint violation with a unique index.
For example, suppose there is a unique index on a cached Oracle Database
table's NUMBER column, and a unique index on the same NUMBER column on the
TimesTen cache table. There are five rows in the cached Oracle Database table
and the same five rows in the cache table. The values in the NUMBER column range
from 1 to 5.
An UPDATE statement is issued on the cache table to increment the value in the
NUMBER column by 1 for all rows. The operation succeeds on the cache table but
fails when it is propagated to the cached Oracle Database table.
This occurs because TimesTen performs the unique index constraint check at the
end of the statement's processing after all the rows have been updated. The
Oracle database, however, performs the constraint check each time after a row
has been updated.
Therefore, when the row in the cache table with value 1 in the NUMBER column is
changed to 2 and the update is propagated to the Oracle database, it causes a
unique constraint violation with the row that has the value 2 in the NUMBER column
of the cached Oracle Database table.
Reporting Oracle Database Permanent Errors for AWT Cache Groups

If transactions are not successfully propagated to and committed in the Oracle
database, then the permanent errors cause the transaction in the Oracle database to
be rolled back.
4-18
Chapter 4
For example, an update on the Oracle database may fail because of a unique constraint
violation. Transactions that contain permanent errors are not retried.
Permanent errors are always reported to the TimesTenDatabaseFileName.awterrs text file
that resides in the same directory as the TimesTen database checkpoint files. See Oracle
Database Errors Reported by TimesTen for AWT in the Oracle TimesTen In-Memory
Database Monitoring and Troubleshooting Guide for information about the contents of this
file.
You can configure TimesTen to report these errors in both ASCII and XML formats with the
ttCacheConfig built-in procedure.
Note:
Do not pass in any values to the tblOwner and tblName parameters for
ttCacheConfig as they are not applicable to setting the format for the errors file.
• To configure TimesTen to report permanent errors to only the

TimesTenDatabaseFileName.awterrs text file, call the ttCacheConfig built-in procedure
with the ASCII parameter. This is the default.
Command> call ttCacheConfig('AwtErrorXmlOutput',,,'ASCII');
• To configure TimesTen to report permanent errors to both the

TimesTenDatabaseFileName.awterrs text file as well as to an XML file named
TimesTenDatabaseFileName.awterrs.xml, call the ttCacheConfig built-in procedure with
the XML parameter.
Command> call ttCacheConfig('AwtErrorXmlOutput',,,'XML');
Note:
Before calling ttCacheConfig to direct permanent errors to the XML file, you must
first stop the replication agent. Then, restart the replication agent after the built-in
procedure completes.
See ttCacheConfig in the Oracle TimesTen In-Memory Database Reference.
When you configure error reporting to be reported in XML format, the following two files are
generated when Oracle Database permanent errors occur:
• TimesTenDatabaseFileName.awterrs.xml contains the Oracle Database permanent error
messages in XML format.
• TimesTenDatabaseFileName.awterrs.dtd is the file that contains the XML Document
Type Definition (DTD), which is used when parsing the
TimesTenDatabaseFileName.awterrs.xml file.
The XML DTD, which is based on the XML 1.0 specification, is a set of markup
declarations that describes the elements and structure of a valid XML file containing a log
of errors. The XML file is encoded using UTF-8. The following are the elements for the
XML format.
4-19
Chapter 4
Synchronous WriteThrough (SWT) Cache Group
Note:
For more information on reading and understanding XML Document
Type Definitions, see http://www.w3.org/TR/REC-xml/.
<!ELEMENT ttawterrorreport (awterrentry*) >

<!ELEMENT awterrentry(header, (failedop)?, failedtxn) >
<!ELEMENT header (time, datastore, oracleid, transmittingagent, errorstr,
(ctn)?, (batchid)?, (depbatchid)?) >
<!ELEMENT failedop (sql) >
<!ELEMENT failedtxn ((sql)+) >
<!ELEMENT time (hour, min, sec, year, month, day) >
<!ELEMENT hour (#PCDATA) >
<!ELEMENT min (#PCDATA) >
<!ELEMENT sec (#PCDATA) >
<!ELEMENT year (#PCDATA) >
<!ELEMENT month (#PCDATA) >
<!ELEMENT day (#PCDATA) >
<!ELEMENT datastore (#PCDATA) >
<!ELEMENT oracleid (#PCDATA) >
<!ELEMENT transmittingagent (transmitingname, pid, threadid) >
<!ELEMENT pid (#PCDATA) >
<!ELEMENT threadid (#PCDATA) >
<!ELEMENT transmittingname (#PCDATA) >
<!ELEMENT errorstr (#PCDATA) >
<!ELEMENT ctn (timestamp, seqnum) >
<!ELEMENT timestamp(#PCDATA) >
<!ELEMENT seqnum(#PCDATA) >
<!ELEMENT batchid(#PCDATA) >
<!ELEMENT depbatchid(#PCDATA) >
<!ELEMENT sql(#PCDATA) >

A synchronous writethrough (SWT) cache group enforces a caching behavior where
committed changes on the TimesTen cache tables are automatically and
synchronously propagated to the cached Oracle Database tables.
See Figure 4-7.
Only TimesTen Classic supports SWT cache groups.
Note:
You should avoid running DML statements on Oracle Database tables
cached in an SWT cache group. This can result in an error condition. See
Restrictions With SWT Cache Groups.
4-20
Chapter 4
Figure 4-7 Synchronous WriteThrough Cache Group
TimesTen
Application
database
TimesTen cache
Synchronous
writethrough
cache group
Automatically
propagate Load upon
updates creation
Oracle
database
The transaction commit on the TimesTen database occurs synchronously with the commit on
the Oracle database. When an application commits a transaction in the TimesTen database,
the transaction is processed in the Oracle database before it is processed in TimesTen. The
application is blocked until the transaction has completed in both the Oracle and TimesTen
databases.
If the transaction fails to commit in the Oracle database, the application must roll back the
transaction in TimesTen. If the Oracle Database transaction commits successfully but the
TimesTen transaction fails to commit, the cache tables in the SWT cache group are no longer
synchronized with the cached Oracle Database tables.
Note:
The behavior and error conditions for how commit occurs on both the TimesTen and
Oracle databases when committing propagated updates is the same commit
process on a user managed cache group with the PROPAGATE cache attribute that is
described in PROPAGATE Cache Table Attribute.
To manually resynchronize the cache tables with the cached Oracle Database tables, call the
ttCachePropagateFlagSet built-in procedure to disable update propagation, and then reissue
the transaction in the TimesTen database after correcting the problem that caused the
transaction commit to fail in TimesTen. Then, call the ttCachePropagateFlagSet built-in
4-21
Chapter 4
procedure to re-enable update propagation. You can also resynchronize the cache
tables with the cached Oracle Database tables by reloading the accompanying cache
groups.
The following is an example definition of the Oracle Database table that is to be
cached in an example SWT cache group. The Oracle Database table is owned by the
schema user sales. The sales user must be granted the CREATE SESSION, CREATE
TRIGGER, CREATE SEQUENCE, CREATE TYPE, CREATE PROCEDURE, and CREATE TABLE
privileges before it can create tables.
CREATE TABLE product
(prod_num VARCHAR2(6) NOT NULL PRIMARY KEY,
name VARCHAR2(30),
price NUMBER(8,2),
ship_weight NUMBER(4,1));
The companion Oracle cache administration user must be granted the SELECT privilege
on the sales.product table in order for the TimesTen cache administration user to
create an SWT cache group that caches this table. The Oracle cache administration
user must also be granted the INSERT, UPDATE, and DELETE privileges on the
sales.product table for synchronous writethrough operations to occur from the
TimesTen cache table to the cached Oracle Database table.
Use the CREATE SYNCHRONOUS WRITETHROUGH CACHE GROUP statement to create an
SWT cache group.
The following statement creates a synchronous writethrough cache group
top_products that caches the sales.product table:
CREATE SYNCHRONOUS WRITETHROUGH CACHE GROUP top_products
FROM sales.product
(prod_num VARCHAR2(6) NOT NULL,
name VARCHAR2(30),
price NUMBER(8,2),
ship_weight NUMBER(4,1),
PRIMARY KEY(prod_num));
When TimesTen manages operations for SWT cache groups, it connects to the Oracle
database using the current user's credentials as the user name and the OraclePwd
connection attribute as the Oracle password. TimesTen does not connect to the Oracle
database with the Oracle cache administration user name and password set with the
ttCacheUidPwdSet built-in procedure when managing SWT cache group operations.
See Set the Cache Administration User Name and Password.
Restrictions With SWT Cache Groups

There are certain restrictions when using an SWT cache group.
The following restrictions apply when using an SWT cache group:
• Only the ON DELETE CASCADE and UNIQUE HASH ON cache table attributes can be
used in the cache table definitions.
See ON DELETE CASCADE Cache Table Attribute for more information about the
ON DELETE CASCADE cache table attribute.
See Creating a Hash Index on the Primary Key Columns of the Cache Table for
more information about the UNIQUE HASH ON cache table attribute.
4-22
Chapter 4
Hybrid Cache Group

See Flushing a User Managed Cache Group for more information about the FLUSH CACHE
GROUP statement
• The cache table definitions cannot contain a WHERE clause.
See Using a WHERE Clause for more information about WHERE clauses in cache group
definitions and operations.
• A TRUNCATE TABLE statement cannot be issued on the cache tables.
• SWT cache groups cannot cache Oracle Database views or materialized views.
• You should avoid running DML statements directly on Oracle Database tables cached in
an SWT cache group. This could result in an error condition. Any insert, update, or delete
operation on the cached Oracle Database table can negatively affect the operations
performed on TimesTen for the affected rows. TimesTen does not detect or resolve
update conflicts that occur on the Oracle database. Committed changes made directly on
a cached Oracle Database table may be overwritten by a committed update made on the
TimesTen cache table when the cache table update is propagated to the Oracle
database. In addition, deleting rows on the cached Oracle Database table could cause an
empty update if TimesTen tries to update a row that no longer exists.
To ensure that not all data is restricted from DML statements on Oracle Database, you
can partition the data on Oracle Database to separate the data that is to be included in
the SWT cache group from the data to be excluded from the SWT cache group.
Hybrid Cache Group

A hybrid cache group is a dynamic read-only cache group where the root table is created in
the TimesTen database and does not exist in the Oracle database.
A cache group is a set of tables related through foreign keys that cache data from tables in
an Oracle database. Each cache group includes one root table that does not reference any of
the other tables. Foreign keys on all other cache tables in the cache group reference exactly
one other table in the cache group. In other words, the foreign key relationships form a tree.
For multiple table cache groups, you determined the relationship between the tables by
defining which table is the root table, which tables are direct child tables of the root table, and
which tables are the child tables of other child tables. Historically, all tables within the cache
group exist in the Oracle database.
With a hybrid cache group, you can dynamically load from cache tables that do not have a
root table on the Oracle database. A hybrid cache group is a dynamic read-only cache group
where the root table is created in the TimesTen database and does not exist in the Oracle
database.
• TimesTen creates the root table on the TimesTen database from the definition of the
hybrid cache group. Note that you should not create this table on the Oracle database.
• The only columns allowed in the root table definition are the columns defining the primary
key.
• All other cache tables must exist in the Oracle database.
• The root table must be referenced by at least one child table through a foreign key
relationship.
The following sections describe how to use a hybrid cache group:
• Creating a Hybrid Cache Group
4-23
Chapter 4
Hybrid Cache Group
• Specifying the Dynamic Load for a Hybrid Cache Group

• Automatic Passthrough for Hybrid Cache Groups
• Restrictions for a Dynamic Hybrid Read-Only Cache Group
Creating a Hybrid Cache Group

You can use the CREATE DYNAMIC HYBRID READONLY CACHE GROUP statement to create
a dynamic hybrid read-only cache group where the root table exists only on TimesTen.
The following are the definitions of the tables that are to be cached in the
customer_orders dynamic hybrid read-only cache group.
1. The customer root table exists only on the TimesTen database and contains only a
primary key. You do not create the root table in the Oracle database as it is
created by TimesTen when you specify the root table in the CREATE DYNAMIC
HYBRID READONLY CACHE GROUP statement.
2. Customers can have more than one order and each order can go to a different
location. To track the order status for each customer location, the locations and
orders tables are created on the Oracle database and are children of the customer
table.
With the customer_id as part of the composite key for both the locations and
orders tables, you can print out the status of all orders for each customer location.
In addition, the invoices table (as a child of the orders table) can be queried to
determine if the order has been paid.
CREATE TABLE locations
(customer_id NUMBER(6),
location_id NUMBER(6),
name VARCHAR2(255) NOT NULL,
street CHAR(30) NOT NULL,
city CHAR(20) NOT NULL,
state CHAR(2) NOT NULL,
zipcode CHAR(10) NOT NULL,
PRIMARY KEY (customer_id, location_id));
CREATE TABLE orders

(order_id NUMBER,
customer_id NUMBER(6),
status NUMBER(2) NOT NULL,
PRIMARY KEY (order_id, location_id, customer_id));
CREATE TABLE invoices

(invoice_id NUMBER PRIMARY KEY,
order_id NUMBER,
total NUMBER,
paid NUMBER);
3. Use the CREATE DYNAMIC HYBRID READONLY CACHE GROUP statement to create the
customer root table on TimesTen and a dynamic hybrid read-only cache group
called customer_orders, which caches the Oracle database tables: locations,
orders, and invoices (child tables). Note that the locations and orders cache
tables reference the primary key of the customer root table that exists on the
TimesTen database.
4-24
Chapter 4
Hybrid Cache Group
Note:
See CREATE CACHE GROUP in the Oracle TimesTen In-Memory Database
SQL Reference.
CREATE DYNAMIC HYBRID READONLY CACHE GROUP customer_orders

FROM customer
(customer_id NUMBER(6) NOT NULL,
PRIMARY KEY(customer_id)),
locations
(customer_id NUMBER(6),
street CHAR(30) NOT NULL,
city CHAR(20) NOT NULL,
state CHAR(2) NOT NULL,
zipcode CHAR(10) NOT NULL,
PRIMARY KEY (customer_id, location_id),
FOREIGN KEY (customer_id) REFERENCES customer(customer_id)),
orders
(order_id NUMBER,
customer_id NUMBER(6),
status NUMBER(2) NOT NULL,
PRIMARY KEY (order_id, location_id, customer_id),
FOREIGN KEY (customer_id) REFERENCES customer(customer_id)),
invoices
(invoice_id NUMBER,
order_id NUMBER,
total NUMBER,
paid NUMBER,
PRIMARY KEY (invoice_id),
FOREIGN KEY (order_id) REFERENCES order(order_id));
Specifying the Dynamic Load for a Hybrid Cache Group

For hybrid cache groups, you can specify a derived table within the FROM clause of the SELECT
statement or include more than one table of the same hybrid cache group in the same query.
Dynamic load occurs after evaluating the rules specified in Guidelines for Dynamic Load.
Using a Derived Table

For hybrid cache groups, you can specify a derived table within the FROM clause of the SELECT
statement. If the query specifies multiple tables including the derived table, then the
materialized result of the derived table with the dynamic load condition is treated as a parent
table (but only if the derived table specifies a single first child table of the hybrid cache
group).
See DerivedTable in the Oracle TimesTen In-Memory Database SQL Reference.
4-25
Chapter 4
Hybrid Cache Group
Example 4-1 Using a Derived Table

The following query uses a derived table within the FROM clause of the SELECT
statement. The materialized result of the derived table is treated as the parent table
orders when determining if the query qualifies for a dynamic load. The following query
uses a derived table within the FROM clause of the SELECT statement. The materialized
result of the derived table is treated as the parent table orders when determining if the
query qualifies for a dynamic load.
SELECT * FROM
(SELECT customer_id FROM orders WHERE customer_id=? AND ROWNUM <= 5);
Including Multiple Tables

More than one table of the same hybrid cache group can be included in the same
query.
• One or more first level child tables of the same hybrid cache group can be
included in a query (including the option of a derived table that includes a first level
child table):
– Specifies the same foreign key as the other first child tables or derived table.
– Includes a join condition that equates its foreign key with the foreign key of
other first child tables or derived table.
• Any included grandchild table of the same hybrid cache group must:
– Include a foreign key join condition with either the derived table or a first level
child table of the same hybrid cache group.
– Not be included in an outer table join with its parent table.
The following examples demonstrate the conditions that do and do not trigger a
dynamic load for a hybrid cache group. All of these examples are based on the
customer_orders hybrid cache group example defined in Creating a Hybrid Cache
Group.
Example 4-2 Dynamic Load Condition Using Multiple First Level Child Tables
The following query triggers a dynamic load since two first level child tables (orders
and locations) specify the same dynamic load condition.
SELECT * FROM orders, locations
WHERE orders.customer_id=:id and locations.customer_id=:id;
And the following query triggers a dynamic load since the locations table equates its
foreign key with the orders table foreign key.
SELECT * FROM orders, locations
WHERE orders.customer_id=:id and locations.customer_id=:id;
Example 4-3 Dynamic Load Condition Using a First Level Child Table and a
Derived Table
The following query triggers a dynamic load since two first level child tables (orders
and locations) specify the same dynamic load condition. The locations table
equates its foreign key with the dynamically loaded foreign key from the orders table.
The derived table is temporarily named cust as that name is provided directly after the
derived table specification.
4-26
Chapter 4
Hybrid Cache Group
SELECT * FROM
(SELECT customer_id,order_id FROM orders
WHERE customer_id=:id and ROWNUM <= 5) cust, invoices, locations
WHERE
invoices.order_id = cust.order_id and locations.customer_id=cust.customer_id;
Example 4-4 Dynamic Load Condition Using a First Level Child Table and Grandchild
Table
The following query example triggers a dynamic load since the dynamic load condition is on a
derived table that includes the orders table (a first level child table of the customer_orders
hybrid cache group). It also includes the grandchild table invoices that is included in a
foreign key join condition with the derived table cust.
Temporarily, the derived table name is orders and is treated as a parent table.
SELECT * FROM
WHERE customer_id=? and ROWNUM <= 5) cust, invoices
WHERE invoices.order_id = cust.order_id;
Example 4-5 Dynamic Load Using Grandchild Table Joined With Derived Table
The following query triggers a dynamic load because the invoices table (as a grandchild
table) is joined with the derived table cust through a foreign key join:
SELECT * FROM
WHERE invoices.order_id = cust.order_id;
Example 4-6 No Dynamic Load Example With First Level Child Table
The following query does not trigger a dynamic load because the first level child locations
table specifies a different dynamic load condition than the derived table (cust) load condition:
SELECT * FROM
WHERE customer_id=:id and ROWNUM <= 5) cust, invoices, locations
WHERE invoices.order_id = cust.order_id and locations.customer_id=:id2;
Example 4-7 No Dynamic Load Example Using Grandchild Table

The following query does not trigger a dynamic load because the invoices grandchild table is
not joined through a foreign key join with its parent, the orders table.
SELECT * FROM
WHERE invoices.invoice_id=?;
Example 4-8 No Dynamic Load Second Example Using Grandchild Table

The following query does not trigger a dynamic load because the invoices grandchild table is
included in an outer table of a join with its parent, the orders table.
SELECT * FROM invoices LEFT JOIN
WHERE customer_id=? and ROWNUM <= 5) cust
ON invoices.order_id = cust.order_id;
4-27
Chapter 4
User Managed Cache Group
Automatic Passthrough for Hybrid Cache Groups

Set the TT_DynamicPassthrough optimizer hint to notify TimesTen to pass through
qualified SELECT statements to the Oracle database for cache groups created without a
WHERE clause.
For cache groups without a WHERE clause, you can set the TT_DynamicPassthrough(N)
optimizer hint that notifies TimesTen to pass through any SELECT statement to the
Oracle database if it results in a dynamic load of a cache instance with >= N number of
rows. See Automatic Passthrough of Dynamic Load to the Oracle Database.
Restrictions for a Dynamic Hybrid Read-Only Cache Group

Restrictions for using a dynamic hybrid read-only cache group.
The following are restrictions for a dynamic hybrid read-only cache group:
• You can execute a SELECT statement on the root table, as this may help in
diagnosing problems. However, a dynamic load is not triggered if you execute a
SELECT on the root table in TimesTen.
• Hybrid cache groups do not support manually loading the cache group with the
LOAD CACHE GROUP statement.
• LRU aging is on by default for dynamic cache groups, including hybrid cache
groups. Currently, time-based aging is not supported for hybrid cache groups.
• Currently, the WHERE clause is not supported in CREATE CACHE GROUP for hybrid
cache groups.
• Currently, the WITH ID clause is not supported in UNLOAD CACHE GROUP for hybrid
cache groups.

If the system managed cache groups (read-only, AWT, SWT) do not satisfy your
application's requirements, you can create a user managed cache group that defines
customized caching behavior.
Create a user managed cache group with customized caching behavior with one or
more of the following cache table attributes:
Only TimesTen Classic supports user-managed cache groups.
Note:
When TimesTen manages operations for user managed cache groups, it
connects to the Oracle database using the current user's credentials as the
user name and the OraclePwd connection attribute as the Oracle password.
TimesTen does not connect to the Oracle database with the cache
administration user name and password set with the ttCacheUidPwdSet built-
in procedure for user managed cache group operations. See Set the Cache
Administration User Name and Password.
4-28
Chapter 4
• You can specify the READONLY Cache Table Attribute on individual cache tables in a
user managed cache group to define read-only behavior where the data is refreshed on
TimesTen from the Oracle database at the table level.
• You can specify the PROPAGATE cache table attribute on individual cache tables in a user
managed cache group to define synchronous writethrough behavior at the table level.
The PROPAGATE Cache Table Attribute specifies that committed changes on the cache
table are automatically and synchronously propagated to the cached Oracle Database
table.
• You can define a user managed cache group to automatically refresh and propagate
committed changes between the Oracle and TimesTen databases by using the
AUTOREFRESH cache group attribute and the PROPAGATE cache table attribute. Using both
attributes enables bidirectional transmit, so that committed changes on the TimesTen
cache tables or the cached Oracle Database tables are propagated or refreshed to each
other.
See Automatically Refreshing a Cache Group for more information about defining an
autorefresh mode, interval, and state.
• You can use the LOAD CACHE GROUP, REFRESH CACHE GROUP, and FLUSH CACHE GROUP
statements to manually control the transmit of committed changes between the Oracle
and TimesTen databases.
See Manually Loading and Refreshing a Cache Group for more information about the
LOAD CACHE GROUP and REFRESH CACHE GROUP statements. See Flushing a User Managed
Cache Group for more information about the FLUSH CACHE GROUP statement.
• You can cache Oracle Database materialized views in a user managed cache group that
does not use either the PROPAGATE or AUTOREFRESH cache group attributes. The cache
group must be manually loaded and flushed. You cannot cache Oracle Database views.
The following sections provide more information about user managed cache groups:
• READONLY Cache Table Attribute
• PROPAGATE Cache Table Attribute
• Examples of User Managed Cache Groups
READONLY Cache Table Attribute

The READONLY cache table attribute can be specified only for cache tables in a user managed
cache group.
READONLY specifies that the cache table cannot be updated directly. By default, a cache table
in a user managed cache group is updatable.
Unlike a read-only cache group where all of its cache tables are read-only, in a user managed
cache group individual cache tables can be specified as read-only using the READONLY cache
table attribute.
The following restrictions apply when using the READONLY cache table attribute:
• If the cache group uses the AUTOREFRESH cache group attribute, the READONLY cache table
attribute must be specified on all or none of its cache tables.
See Automatically Refreshing a Cache Group for more information about using the
AUTOREFRESH cache group attribute.
4-29
Chapter 4
• You cannot use both the READONLY and PROPAGATE cache table attributes on the
same cache table.
See PROPAGATE Cache Table Attribute for more information about using the
PROPAGATE cache table attribute.
• A FLUSH CACHE GROUP statement cannot be issued on the cache group unless one
or more of its cache tables use neither the READONLY nor the PROPAGATE cache
table attribute.
See Flushing a User Managed Cache Group for more information about the FLUSH
CACHE GROUP statement.
• After the READONLY cache table attribute has been specified on a cache table, you
cannot change this attribute unless you drop the cache group and re-create it.
PROPAGATE Cache Table Attribute

The PROPAGATE cache table attribute can be specified only for cache tables in a user
managed cache group.
PROPAGATE specifies that committed changes on the TimesTen cache table as part of a
TimesTen transaction are automatically and synchronously propagated to the cached
Oracle Database table. If the PROPAGATE cache table attribute is not specified, then the
default setting for a cache table in a user managed cache group is the NOT PROPAGATE
cache table attribute (which does not propagate committed changes on the cache
table to the cached Oracle table).
All SQL statements run by an application on cached tables are applied to the cached
tables immediately. All of these operations are buffered until the transaction commits
or reaches a memory upper limit. At this time, all operations are propagated to the
tables in the Oracle database.
Note:
If the TimesTen database or its daemon fails unexpectedly, the results of the
transaction on either the TimesTen or Oracle databases are not guaranteed.
Since the operations in the transaction are applied to tables in both the TimesTen and
Oracle databases, the process for committing is as follows:
1. After the operations are propagated to the Oracle database, the commit is first
attempted in the Oracle database.
• If an error occurs when applying the operations on the tables in the Oracle
database, then all operations are rolled back on the tables on the Oracle
database. If the commit fails in the Oracle database, the commit is not
attempted in the TimesTen database and the application must roll back the
TimesTen transaction. If the user tries to run another statement, an error
displays informing them of the need for a roll back. As a result, the Oracle
database never misses updates committed in TimesTen.
2. If the commit succeeds in the Oracle database, the commit is attempted in the
TimesTen database.
4-30
Chapter 4
• If the transaction successfully commits on the Oracle database, the user's transaction
is committed on TimesTen (indicated by the commit log record in the transaction log)
and notifies the application. If the application ends abruptly before TimesTen informs
it of the success of the local commit, TimesTen is still able to finalize the transaction
commit on TimesTen based on what is saved in the transaction log.
• If the transaction successfully commits on the Oracle database and a failure occurs
before returning the status of the commit on TimesTen, then no record of the
successful commit is written into the transaction log and the transaction is rolled
back.
• If the commit fails in TimesTen, an error message is returned from TimesTen
indicating the cause of the failure. You then need to manually resynchronize the
cache tables with the Oracle Database tables.
Note:
See Synchronous WriteThrough (SWT) Cache Group for information on
how to re-synchronize the cache tables with the Oracle Database tables.
You can disable propagation of committed changes on the TimesTen cached tables to the
Oracle database with the ttCachePropagateFlagSet built-in procedure. This built-in
procedure can enable or disable automatic propagation so that committed changes on a
cache table on TimesTen for the current transaction are never propagated to the cached
Oracle Database table. You can then re-enable propagation for DML statements by resetting
the flag to one with the ttCachePropagateFlagSet built-in procedure. After the flag is set
back to one, propagation of committed changes to the Oracle database resumes. The
propagation flag automatically resets to one after the transaction is committed or rolled back.
See ttCachePropagateFlagSet in the Oracle TimesTen In-Memory Database Reference.
The following restrictions apply when using the PROPAGATE cache table attribute:
• If the cache group uses the AUTOREFRESH cache group attribute, the PROPAGATE cache
table attribute must be specified on all or none of its cache tables.
See Automatically Refreshing a Cache Group for more information about using the
AUTOREFRESH cache group attribute.
• If the cache group uses the AUTOREFRESH cache group attribute, the NOT PROPAGATE cache
table attribute cannot be explicitly specified on any of its cache tables.
• You cannot use both the PROPAGATE and READONLY cache table attributes on the same
cache table.
See READONLY Cache Table Attribute for more information about using the READONLY
cache table attribute.
• A FLUSH CACHE GROUP statement cannot be issued on the cache group unless one or
more of its cache tables use neither the PROPAGATE nor the READONLY cache table
attribute.
See Flushing a User Managed Cache Group for more information about the FLUSH CACHE
GROUP statement.
• After the PROPAGATE cache table attribute has been specified on a cache table, you
cannot change this attribute unless you drop the cache group and re-create it.
4-31
Chapter 4
• The PROPAGATE cache table attribute cannot be used when caching Oracle
Database materialized views.
• TimesTen does not perform a conflict check to prevent a propagate operation from
overwriting data that was updated directly on a cached Oracle Database table.
Therefore, updates should only be performed directly on the TimesTen cache
tables or the cached Oracle Database tables, but not both.
Examples of User Managed Cache Groups

Examples are provided for the definition of the Oracle Database tables that are to be
cached in the user managed cache groups.
The Oracle Database tables are owned by the schema user sales. The sales user
must be granted the CREATE SESSION, CREATE TRIGGER, CREATE SEQUENCE, CREATE
TYPE, CREATE PROCEDURE, and CREATE TABLE privileges before it can create tables.
CREATE TABLE active_customer
(custid NUMBER(6) NOT NULL PRIMARY KEY,
name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12),
region VARCHAR2(12) DEFAULT 'Unknown');
CREATE TABLE ordertab

(orderid NUMBER(10) NOT NULL PRIMARY KEY,
custid NUMBER(6) NOT NULL);
CREATE TABLE cust_interests

(custid NUMBER(6) NOT NULL,
interest VARCHAR2(10) NOT NULL,
PRIMARY KEY (custid, interest));
CREATE TABLE orderdetails

(orderid NUMBER(10) NOT NULL,
itemid NUMBER(8) NOT NULL,
quantity NUMBER(4) NOT NULL,
PRIMARY KEY (orderid, itemid));
Use the CREATE USERMANAGED CACHE GROUP statement to create a user managed
cache group.
The following statement creates a user managed cache group
update_anywhere_customers that caches the sales.active_customer table as shown
in Figure 4-8:
CREATE USERMANAGED CACHE GROUP update_anywhere_customers
AUTOREFRESH MODE INCREMENTAL INTERVAL 30 SECONDS
FROM sales.active_customer
name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12),
PRIMARY KEY(custid),
PROPAGATE);
4-32
Chapter 4
Figure 4-8 Single-Table User Managed Cache Group
TimesTen
User managed cache group update_anywhere_customers
active_customer
custid name address zip
Updates on TimesTen Updates on cached

cache tables are propagated Oracle table are autorefreshed
to Oracle to TimesTen cache group
Oracle
database
active_customer
In this example, all columns except region from the sales.active_customer table are
cached in TimesTen. Since this is defined with the PROPAGATE cache table attribute, updates
committed on the sales.active_customer cache table on TimesTen are transmitted to the
sales.active_customer cached Oracle Database table. Since the user managed cache table
is also defined with the AUTOREFRESH cache attribute, any committed changes on the
sales.active_customer Oracle Database table are transmitted to the
update_anywhere_customers cached table.
sales.active_customer table in order for the TimesTen cache administration user to create a
user managed cache group that caches this table, and for autorefresh operations to occur
from the cached Oracle Database table to the TimesTen cache table. The companion Oracle
cache administration user must also be granted the INSERT, UPDATE and DELETE privileges on
the sales.active_customer table for synchronous writethrough operations to occur from the
TimesTen cache table to the cached Oracle Database table.
In this example, the AUTOREFRESH cache group attribute specifies that committed changes on
the sales.active_customer cached Oracle Database table are automatically refreshed to the
TimesTen sales.active_customer cache table every 30 seconds.
If you manually created the Oracle Database objects used to enforce the predefined
behaviors of a user managed cache group that uses the AUTOREFRESH MODE INCREMENTAL
4-33
Chapter 4
cache group attribute as described in The initCacheAdminSchema.sql Script, you

need to set the autorefresh state to OFF when creating the cache group.
Then you need to run the ttIsql utility's cachesqlget command to generate a
SQL*Plus script used to create a log table and a trigger in the Oracle database for
each Oracle Database table that is cached in the user managed cache group.
See Manually Creating Oracle Database Objects for Cache Groups With Autorefresh.
The following statement creates a multiple-table user managed cache group
western_customers that caches the sales.active_customer, sales.ordertab,
sales.cust_interests, and sales.orderdetails tables as shown in Figure 4-9:
CREATE USERMANAGED CACHE GROUP western_customers
name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12),
PROPAGATE)
WHERE (sales.active_customer.region = 'West'),
sales.ordertab
custid NUMBER(6) NOT NULL,
PRIMARY KEY(orderid),
FOREIGN KEY(custid) REFERENCES sales.active_customer(custid),
PROPAGATE),
sales.cust_interests
interest VARCHAR2(10) NOT NULL,
PRIMARY KEY(custid, interest),
FOREIGN KEY(custid) REFERENCES sales.active_customer(custid),
READONLY),
sales.orderdetails
PRIMARY KEY(orderid, itemid),
FOREIGN KEY(orderid) REFERENCES sales.ordertab(orderid))
WHERE (sales.orderdetails.quantity >= 5);
4-34
Chapter 4
Figure 4-9 Multiple-Table User Managed Cache Group
TimesTen
User managed cache group western_customers
active_customer (Root table)
custid name address zip region
ordertab cust_interests
orderid custid custid interests
orderdetails
orderid itemid quantity
Oracle
database
active_customer
cust_interests
Data for all customers
ordertab
order_details
Only customers in the West region who ordered at least 5 of the same item are cached.
sales.active_customer, sales.ordertab, sales.cust_interests, and sales.orderdetails
tables in order for the TimesTen cache administration user to create a user managed cache
group that caches all of these tables. The companion Oracle cache administration user must
also be granted the INSERT, UPDATE and DELETE privileges on the sales.active_customer
and sales.ordertab tables for synchronous writethrough operations to occur from these
TimesTen cache tables to the cached Oracle Database tables.
Each cache table in the western_customers cache group contains a primary key. Each child
table references a parent table with a foreign key constraint. The sales.active_customer
root table and the sales.orderdetails child table each contain a WHERE clause to restrict the
rows to be cached. The sales.active_customer root table and the sales.ordertab child
table both use the PROPAGATE Cache Table Attribute so that committed changes on these
4-35
Chapter 4
Using a WHERE Clause
cache tables are automatically propagated to the cached Oracle Database tables. The
sales.cust_interests child table uses the READONLY Cache Table Attribute so that
it cannot be updated directly.

A cache table definition in a CREATE CACHE GROUP statement can contain a WHERE
clause to restrict the rows to cache in the TimesTen database for particular cache
group types.
You can also specify a WHERE clause in a LOAD CACHE GROUP, UNLOAD CACHE GROUP,
REFRESH CACHE GROUP or FLUSH CACHE GROUP statement for particular cache group
types. Some statements, such as LOAD CACHE GROUP and REFRESH CACHE GROUP, may
result in concatenated WHERE clauses in which the WHERE clause for the cache table
definition is evaluated before the WHERE clause in the LOAD CACHE GROUP or REFRESH
The following restrictions apply to WHERE clauses used in cache table definitions and
cache group operations:
• WHERE clauses can only be specified in the cache table definitions of a CREATE
CACHE GROUP statement for read-only and user managed cache groups.
• A WHERE clause can be specified in a LOAD CACHE GROUP statement except on a
static cache group with autorefresh.
See Manually Loading and Refreshing a Cache Group for more information about
the LOAD CACHE GROUP.
• A WHERE clause can be specified in a REFRESH CACHE GROUP statement except on a
cache group with autorefresh.
See Manually Loading and Refreshing a Cache Group for more information about
the REFRESH CACHE GROUP statement.
• A WHERE clause can be specified in a FLUSH CACHE GROUP statement on a user
managed cache group that allows committed changes on the TimesTen cache
tables to be flushed to the cached Oracle Database tables.
See Flushing a User Managed Cache Group for more information about the FLUSH
• WHERE clauses in a CREATE CACHE GROUP statement cannot contain a subquery.
Therefore, each WHERE clause cannot reference any table other than the one in its
cache table definition. However, a WHERE clause in a LOAD CACHE GROUP, UNLOAD
CACHE GROUP, REFRESH CACHE GROUP or FLUSH CACHE GROUP statement may contain
a subquery.
• A WHERE clause in a LOAD CACHE GROUP, REFRESH CACHE GROUP or FLUSH CACHE
GROUP statement can reference only the root table of the cache group, unless the
WHERE clause contains a subquery.
• WHERE clauses in the cache table definitions are only enforced when the cache
group is manually loaded or refreshed, or the cache tables are dynamically loaded.
If a cache table is updatable, you can insert or update a row such that the WHERE
clause in the cache table definition for that row is not satisfied.
4-36
Chapter 4
• All tables and columns referenced in WHERE clauses when creating, loading, refreshing,
unloading or flushing the cache group must be fully qualified. For example:
Proper Placement of WHERE Clause in a CREATE CACHE GROUP

Statement
In a multiple-table cache group, a WHERE clause in a particular table definition should not
reference any table in the cache group other than the table itself. For example, the following
CREATE CACHE GROUP statements are valid:
FROM sales.customer
name VARCHAR2(50),
PRIMARY KEY(cust_num))
WHERE (sales.customer.cust_num < 100),
sales.orders

FROM sales.customer
name VARCHAR2(50),
sales.orders
WHERE (sales.orders.cust_num < 100)
The following statement is not valid because the WHERE clause in the child table's definition
references its parent table:
FROM sales.customer
name VARCHAR2(50),
sales.orders
4-37
Chapter 4
FOREIGN KEY(cust_num) REFERENCES sales.customer(cust_num))
WHERE (sales.customer.cust_num < 100);
Similarly, the following statement is not valid because the WHERE clause in the parent
table's definition references its child table:
FROM sales.customer
name VARCHAR2(50),
WHERE (sales.orders.cust_num < 100),
sales.orders
Referencing Oracle Database PL/SQL Functions in a WHERE Clause

A user-defined PL/SQL function in the Oracle database can be invoked indirectly in a
WHERE clause within a CREATE CACHE GROUP, LOAD CACHE GROUP, or REFRESH CACHE
GROUP (for dynamic cache groups only) statement.
After creating the function, create a public synonym for the function. Then grant the
EXECUTE privilege on the function to PUBLIC.
For example, in the Oracle database:

CREATE OR REPLACE FUNCTION get_customer_name
(c_num sales.customer.cust_num%TYPE) RETURN VARCHAR2 IS
c_name sales.customer.name%TYPE;
BEGIN
SELECT name INTO c_name FROM sales.customer WHERE cust_num = c_num;
RETURN c_name;
END get_customer_name;
CREATE PUBLIC SYNONYM retname FOR get_customer_name;

GRANT EXECUTE ON get_customer_name TO PUBLIC;
Then in the TimesTen database, for example, you can create a cache group with a
WHERE clause that references the Oracle Database public synonym that was created for
the function:
CREATE READONLY CACHE GROUP top_customer
FROM sales.customer
name VARCHAR2(50),
WHERE name = retname(100);
For cache group types that allow a WHERE clause on a LOAD CACHE GROUP or REFRESH
CACHE GROUP statement, you can invoke the function indirectly by referencing the
4-38
Chapter 4
Specifying Automatic Refresh With the AUTOREFRESH Cache Group Attribute
public synonym that was created for the function. For example, you can use the following
LOAD CACHE GROUP statement to load the AWT cache group new_customers:
LOAD CACHE GROUP new_customers WHERE name = retname(101) COMMIT EVERY 0 ROWS;
Specifying Automatic Refresh With the AUTOREFRESH Cache

Group Attribute
The AUTOREFRESH cache group attribute can be specified when creating a read-only cache
group or a user managed cache group using a CREATE CACHE GROUP statement.
AUTOREFRESH specifies that committed changes on cached Oracle Database tables are
automatically refreshed to the cache tables on TimesTen. Autorefresh is defined by default on
read-only cache groups. See Automatically Refreshing a Cache Group.
Creating a Dynamic Cache Group With the DYNAMIC Keyword

You define whether your cache group is dynamically loaded during cache group definition
with the DYNAMIC keyword.
Note:
Only TimesTen Classic supports the DYNAMIC keyword in its cache groups.
See Dynamic Cache Groups.
Creating a Hash Index on the Primary Key Columns of the

Cache Table
The UNIQUE HASH ON cache table attribute can be specified for cache tables in any cache
group type.
UNIQUE HASH ON specifies that a hash index rather than a range index is created on the
primary key columns of the cache table. The columns specified in the hash index must be
identical to the columns in the primary key. The UNIQUE HASH ON cache table attribute is also
used to specify the size of the hash index.
The following example demonstrates how to use the UNIQUE HASH ON cache table attribute on
the cache table's definition.
FROM sales.customer
name VARCHAR2(50),
UNIQUE HASH ON (cust_num) PAGES = 100;
See CREATE CACHE GROUP in the Oracle TimesTen In-Memory Database SQL Reference.
4-39
Chapter 4
ON DELETE CASCADE Cache Table Attribute
ON DELETE CASCADE Cache Table Attribute

The ON DELETE CASCADE cache table attribute can be specified for cache tables in any
cache group type.
ON DELETE CASCADE specifies that when rows containing referenced key values are
deleted from a parent table, rows in child tables with dependent foreign keys are also
deleted.
The following example demonstrates how to use the ON DELETE CASCADE cache table
attribute on the child table's foreign key definition:
FROM sales.customer
name VARCHAR2(50),
sales.orders
FOREIGN KEY(cust_num) REFERENCES sales.customer(cust_num) ON DELETE CASCADE);
All paths from a parent table to a child table must be either "delete" paths or "do not
delete" paths. There cannot be some "delete" paths and some "do not delete" paths
from a parent table to a child table. Specify the ON DELETE CASCADE cache table
attribute for child tables on a "delete" path.
The following restrictions apply when using the ON DELETE CASCADE cache table
attribute:
• For AWT and SWT cache groups, and for TimesTen cache tables in user managed
cache groups that use the PROPAGATE cache table attribute, foreign keys in cache
tables that use the ON DELETE CASCADE cache table attribute must be a proper
subset of the foreign keys in the cached Oracle Database tables that use the ON
DELETE CASCADE attribute. ON DELETE CASCADE actions on the cached Oracle
Database tables are applied to the cache tables on TimesTen as individual
deletes. ON DELETE CASCADE actions on the cache tables are applied to the cached
Oracle Database tables as a cascaded operation.
• Matching of foreign keys between the cache tables on TimesTen and the cached
Oracle Database tables is enforced only when the cache group is being created. A
cascade delete operation may not work if the foreign keys on the cached Oracle
Database tables are altered after the cache group is created.
See CREATE CACHE GROUP in the Oracle TimesTen In-Memory Database SQL
Reference.
Caching Oracle Database Synonyms

You can cache a private synonym in an AWT, SWT or user managed cache group that
does not use the AUTOREFRESH cache group attribute.
4-40
Chapter 4
Caching Oracle Database LOB Data
The private synonym can reference a public or private synonym, but it must eventually
reference a table because it is the table that is actually being cached.
The table that is directly or indirectly referenced by the cached synonym can be owned by a
user other than the Oracle Database user with the same name as the owner of the cache
group that caches the synonym. The table must reside in the same Oracle database as the
synonym. The cached synonym itself must be owned by the Oracle Database user with the
same name as the owner of the cache group that caches the synonym.
Caching Oracle Database LOB Data

You can cache Oracle Database large object (LOB) data in cache groups in TimesTen.
TimesTen caches the data as follows:
• Oracle Database CLOB data is cached as TimesTen VARCHAR2 data.
• Oracle Database BLOB data is cached as TimesTen VARBINARY data.
• Oracle Database NCLOB data is cached as TimesTen NVARCHAR2 data.
The following example shows how to cache Oracle Database LOB data
1. Create a table in the Oracle database that has LOB fields.
CREATE TABLE t (
i INT NOT NULL PRIMARY KEY
, c CLOB
, b BLOB
, nc NCLOB);
2. Insert values into the Oracle Database table. The values are implicitly converted to
TimesTen VARCHAR2, VARBINARY, OR NVARCHAR2 data types.
INSERT INTO t VALUES (1
, RPAD('abcdefg8', 2048, 'abcdefg8')
, HEXTORAW(RPAD('123456789ABCDEF8', 4000, '123456789ABCDEF8'))
, RPAD('abcdefg8', 2048, 'abcdefg8')
);
1 row inserted.
3. Create a dynamic AWT cache group and start the replication agent.
CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP cg1
FROM t
(i INT NOT NULL PRIMARY KEY
, c VARCHAR2(4194303)
, b VARBINARY(4194303)
, nc NVARCHAR2(2097152));
CALL ttrepstart;
4. Load the data dynamically into the TimesTen cache group.

SELECT * FROM t WHERE i = 1;
I: 1
C: abcdefg8abcdefg8abcdefg8...
B: 123456789ABCDEF8123456789...
NC: abcdefg8abcdefg8abcdefg8...
1 row found.
4-41
Chapter 4
Implementing Aging in a Cache Group for TimesTen Classic
Restrictions on Caching Oracle Database LOB Data

There are restrictions when caching Oracle Database LOB data into TimesTen.
These restrictions apply to caching Oracle Database LOB data in TimesTen cache
groups:
• Column size is enforced when a cache group is created. VARBINARY, VARCHAR2 and
NVARCHAR2 data types have a size limit of 4 megabytes. Values that exceed the
user-defined column size are truncated at run time without notification.
• Empty values in fields with CLOB and BLOB data types are initialized but not
populated with data. Empty CLOB and BLOB fields are treated as follows:
– Empty LOB fields in the Oracle database are returned as NULL values.
– Empty VARCHAR2 and VARBINARY fields in TimesTen are propagated as NULL
values.
In addition, cache groups that are configured for autorefresh operations have these
restrictions on caching LOB data:
• When LOB data is updated in the Oracle database by OCI functions or the
DBMS_LOB PL/SQL package, the data is not automatically refreshed in the cache
group in TimesTen. This occurs because TimesTen caching operations depend on
Oracle Database triggers, and Oracle Database triggers are not processed when
these types of updates occur. TimesTen does not notify the user that updates have
occurred without being refreshed in TimesTen. When the LOB data is updated in
the Oracle database through a SQL statement, a trigger is fired and autorefresh
brings in the change.
• Autorefresh operations update a complete row in the cache. Thus, the cached
data may appear to be updated in TimesTen when no change has occurred in the
LOB data in the Oracle database.

You can define an aging policy for a cache group in TimesTen Classic that specifies
the aging type, the aging attributes, and the aging state. TimesTen Classic supports
two aging types, least recently used (LRU) aging and time-based aging.
LRU aging deletes the least recently used or referenced data based on a specified
database usage range. Time-based aging deletes data based on a specified data
lifetime and frequency of the aging process. You can use both LRU and time-based
aging in the same TimesTen database, but you can define only one aging policy for a
particular cache group.
An aging policy is specified in the cache table definition of the root table in a CREATE
CACHE GROUP statement and applies to all cache tables in the cache group because
aging is performed at the cache instance level. When rows are deleted from the cache
tables by aging out, the rows in the cached Oracle Database table are not deleted.
You can add an aging policy to a cache group by using an ALTER TABLE statement on
the root table. You can change the aging policy of a cache group by using ALTER
TABLE statements on the root table to drop the existing aging policy and then add a
new aging policy.
4-42
Chapter 4
This section describes cache group definitions that contain an aging policy.
• LRU Aging in TimesTen Classic
• Time-Based Aging in TimesTen Classic
• Manually Scheduling an Aging Process in TimesTen Classic
• Configuring a Sliding Window in TimesTen Classic
LRU Aging in TimesTen Classic

LRU aging enables you to maintain the amount of memory used in a TimesTen database
within a specified threshold by deleting the least recently used data. LRU aging can be
defined for all cache group types except static cache groups with autorefresh enabled. LRU
aging is defined by default on dynamic cache groups.
Define an LRU aging policy for a cache group by using the AGING LRU clause in the cache
table definition of the CREATE CACHE GROUP statement. Aging occurs automatically if the aging
state is set to its default of ON.
The following example defines an LRU aging policy on the AWT cache group new_customers:
FROM sales.customer
name VARCHAR2(50),
AGING LRU ON;
There are two LRU aging policies:

• LRU aging based on set thresholds for the amount of permanent memory in use. This is
the default. Once you create (or alter) a table to use LRU aging, the LRU aging policy
defaults to using the default thresholds for permanent memory in use. See Defining LRU
Aging Based on Thresholds for Permanent Memory in Use in the Oracle TimesTen In-
Memory Database Operations Guide.
• LRU aging based on row thresholds for a specified root tables of your cache groups. See
Defining LRU Aging Based on Row Thresholds for Tables in the Oracle TimesTen In-
Both types of LRU aging can co-exist. Row threshold based aging takes precedence over
permanent memory in use based aging.
If a row has been accessed or referenced since the last aging cycle, it is not eligible for LRU
aging in the current aging cycle. A row is considered to be accessed or referenced if at least
one of the following is true:
• The row is used to build the result set of a SELECT or an INSERT ... SELECT statement.
• The row has been marked to be updated or deleted in a pending transaction.
In a multiple-table cache group, if a row in a child table has been accessed or referenced
since the last aging cycle, then neither the related row in the parent table nor the row in the
child table is eligible for LRU aging in the current aging cycle.
The ALTER TABLE statement can be used to perform the following tasks associated with
changing or defining an LRU aging policy on a cache group:
4-43
Chapter 4
• Change the aging state of a cache group by specifying the root table and using the
SET AGING clause.
• Add an LRU aging policy to a cache group that has no aging policy defined by
specifying the root table and using the ADD AGING LRU clause.
• Drop the LRU aging policy on a cache group by specifying the root table and using
the DROP AGING clause.
To change the aging policy of a cache group from LRU to time-based, use an ALTER
TABLE statement on the root table with the DROP AGING clause to drop the LRU aging
policy. Then use an ALTER TABLE statement on the root table with the ADD AGING USE
clause to add a time-based aging policy.
You must stop the cache agent before you add, alter or drop an aging policy on a
Time-Based Aging in TimesTen Classic

Time-based aging deletes data from a cache group based on the aging policy's
specified data lifetime and frequency. Time-based aging can be defined for all cache
group types in TimesTen Classic.
Define a time-based aging policy for a cache group by using the AGING USE clause in
the cache table definition of the CREATE CACHE GROUP statement. Aging occurs
automatically if the aging state is set to its default of ON.
The following example are the definitions of the Oracle Database tables that are to be
cached in the AWT cache group. The Oracle Database tables are owned by the
schema user sales. The sales user must be granted the CREATE SESSION, CREATE
TRIGGER, CREATE SEQUENCE, CREATE TYPE, CREATE PROCEDURE, and CREATE TABLE
privileges before it can create tables.
CREATE TABLE orders
CREATE TABLE order_item

(orditem_id NUMBER(12) NOT NULL PRIMARY KEY,
ord_num NUMBER(10),
prod_num VARCHAR2(6),
quantity NUMBER(3));
The companion Oracle cache administration user must be granted the SELECT privilege
on the sales.orders and sales.order_item tables in order for the TimesTen cache
administration user to create an AWT cache group that caches these tables. The
Oracle cache administration user must be granted the INSERT, UPDATE and DELETE
Oracle Database privileges for the sales.orders and sales.order_item tables for
asynchronous writethrough operations to be applied on the Oracle Database.
The following example defines a time-based aging policy on the AWT cache group
ordered_items:
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP ordered_items
FROM sales.orders
4-44
Chapter 4

PRIMARY KEY(ord_num))
AGING USE when_placed LIFETIME 45 DAYS CYCLE 60 MINUTES ON,
sales.order_item
(orditem_id NUMBER(12) NOT NULL,
ord_num NUMBER(10),
prod_num VARCHAR2(6),
quantity NUMBER(3),
PRIMARY KEY(orditem_id),
FOREIGN KEY(ord_num) REFERENCES sales.orders(ord_num));
Cache instances that are greater than 45 days old based on the difference between the
current system timestamp and the timestamp in the when_placed column of the sales.orders
table are candidates for aging. The aging process checks every 60 minutes to see if there are
cache instances that can be automatically aged out or deleted from the cache tables.
The AGING USE clause requires the name of a non-nullable TIMESTAMP or DATE column used
for time-based aging. We refer to this column as the timestamp column.
For each row, the value in the timestamp column stores the date and time when the row was
most recently inserted or updated. The values in the timestamp column is maintained by your
application. If the value of this column is unknown for particular rows and you do not want
those rows to be aged out of the table, define the timestamp column with a large default
value.
You can create an index on the timestamp column to optimize performance of the aging
process.
You cannot add a column to an existing table and then use that column as the timestamp
column because added columns cannot be defined as non-nullable. You cannot drop the
timestamp column from a table that has a time-based aging policy defined.
Specify the lifetime in days, hours, minutes or seconds after the LIFETIME keyword in the
AGING USE clause.
The value in the timestamp column is subtracted from the current system timestamp. The
result is then truncated to the specified lifetime unit (day, hour, minute, second) and
compared with the specified lifetime value. If the result is greater than the lifetime value, the
row is a candidate for aging.
After the CYCLE keyword, specify the frequency in which aging occurs in days, hours, minutes
or seconds. The default aging cycle is 5 minutes. If you specify an aging cycle of 0, aging is
continuous.
The ALTER TABLE statement can be used to perform the following tasks associated with
changing or defining a time-based aging policy on a cache group:
• Change the aging state of a cache group by specifying the root table and using the SET
AGING clause.
• Change the lifetime by specifying the root table and using the SET AGING LIFETIME
clause.
• Change the aging cycle by specifying the root table and using the SET AGING CYCLE
clause.
• Add a time-based aging policy to a cache group that has no aging policy defined by
specifying the root table and using the ADD AGING USE clause.
4-45
Chapter 4
• Drop the time-based aging policy on a cache group by specifying the root table
and using the DROP AGING clause.
To change the aging policy of a cache group from time-based to LRU, use an ALTER
TABLE statement on the root table with the DROP AGING clause to drop the time-based
aging policy. Then use an ALTER TABLE statement on the root table with the ADD AGING
LRU clause to add an LRU aging policy.
You must stop the cache agent before you add, alter or drop an aging policy on a
Manually Scheduling an Aging Process in TimesTen Classic

Use the ttAgingScheduleNow built-in procedure to manually start a one-time aging
process on a specified table or on all tables that have an aging policy defined.
The aging process starts as soon as you call the built-in procedure unless there is
already an aging process in progress. Otherwise the manually started aging process
begins when the aging process that is in progress has completed. After the manually
started aging process has completed, the start of the table's next aging cycle is set to
the time when ttAgingScheduleNow was called if the table's aging state is ON.
The following example shows how the ttAgingScheduleNow built-in procedure starts a
one-time aging process on the sales.orders table based on the time
ttAgingScheduleNow is called:
Command> CALL ttAgingScheduleNow('sales.orders');
Rows in the sales.orders root table that are candidates for aging are deleted as well
as related rows in the sales.order_item child table.
When you call the ttAgingScheduleNow built-in procedure, the aging process starts
regardless of whether the table's aging state is ON or OFF. If you want to start an aging
process on a particular cache group, specify the name of the cache group's root table
when you call the built-in procedure. If the ttAgingScheduleNow built-in procedure is
called with no parameters, it starts an aging process and then resets the start of the
next aging cycle on all tables in the TimesTen database that have an aging policy
defined.
Calling the ttAgingScheduleNow built-in procedure does not change the aging state of
any table. If a table's aging state is OFF when you call the built-in procedure, the aging
process starts, but it is not scheduled to run again after the process has completed. To
continue aging a table whose aging state is OFF, you must call ttAgingScheduleNow
again or change the table's aging state to ON.
To manually control aging on a cache group, disable aging on the root table by using
an ALTER TABLE statement with the SET AGING OFF clause. Then call
ttAgingScheduleNow to start an aging process on the cache group.
Configuring a Sliding Window in TimesTen Classic

You can use time-based aging to implement a sliding window for a cache group.
In a sliding window configuration, new rows are inserted into and old rows are deleted
from the cache tables on a regular schedule so that the tables contain only the data
that satisfies a specific time interval.
4-46
Chapter 4
Replicating Cache Tables in TimesTen Classic
You can configure a sliding window for a cache group by using incremental autorefresh mode
and defining a time-based aging policy. The autorefresh operation checks the timestamp of
the rows in the cached Oracle Database tables to determine whether new data should be
refreshed into the TimesTen cache tables. The system time and the time zone must be
identical on the Oracle Database and TimesTen systems.
If the cache group does not use incremental autorefresh mode, you can configure a sliding
window by using a LOAD CACHE GROUP, REFRESH CACHE GROUP, or INSERT statement, or a
dynamic load operation to bring new data into the cache tables.
The following example configures a sliding window on the read-only cache group
recent_shipped_orders:
CREATE READONLY CACHE GROUP recent_shipped_orders
AUTOREFRESH MODE INCREMENTAL INTERVAL 1440 MINUTES STATE ON
FROM sales.orders
PRIMARY KEY(ord_num))
AGING USE when_shipped LIFETIME 30 DAYS CYCLE 24 HOURS ON;
New data in the sales.orders cached Oracle Database table are automatically refreshed into
the sales.orders TimesTen cache table every 1440 minutes. Cache instances that are
greater than 30 days old based on the difference between the current system timestamp and
the timestamp in the when_shipped column are candidates for aging. The aging process
checks every 24 hours to see if there are cache instances that can be aged out of the cache
tables. Therefore, this cache group stores orders that have been shipped within the last 30
days.
The autorefresh interval and the lifetime used for aging determine the duration that particular
rows remain in the cache tables. It is possible for data to be aged out of the cache tables
before it has been in the cache tables for its lifetime. For example, for a read-only cache
group if the autorefresh interval is 3 days and the lifetime is 30 days, data that is already 3
days old when it is refreshed into the cache tables is deleted after 27 days because aging is
based on the timestamp stored in the rows of the cached Oracle Database tables that gets
loaded into the TimesTen cache tables, not when the data is refreshed into the cache tables.

To achieve high availability in TimesTen Classic, configure an active standby pair replication
scheme for cache tables in a read-only cache group or an AWT cache group.
An active standby pair that replicates cache tables from one of these cache group types can
automatically change the role of a TimesTen Classic database as part of failover and
recovery with minimal chance of data loss. Cache groups themselves provide resilience from
Oracle database outages, further strengthening system availability. An active standby pair
replication scheme provides for high availability of a TimesTen Classic database.
4-47
Chapter 4
Note:
This section describes one scenario in including cache groups within an
active standby pair replication scheme. See Administering an Active Standby
Pair with Cache Groups in Oracle TimesTen In-Memory Database
Replication Guide for more scenarios for including AWT and read-only cache
groups in an active standby pair replication scheme.
Oracle Real Application Clusters (Oracle RAC) provides for high availability of an
Oracle database. See Using Cache in an Oracle RAC Environment.
Perform the following tasks to configure an active standby pair for TimesTen Classic
databases that cache Oracle Database tables:
• Create and Configure the Active Database
• Create and Configure the Standby Database
• Create and Configure the Read-Only Subscriber Database
Create and Configure the Active Database

This example shows how to create and configure the active database in an active
standby pair replication scheme.
The following is the definition of the cacheactive DSN for the active database of the
active standby pair:
[cacheactive]
DataStore=/users/OracleCache/cacheact
PermSize=64
Start the ttIsql utility and connect to the cacheactive DSN as the instance
administrator to create the database. Then create the TimesTen cache administration
user cacheadmin whose name is the same as a companion Oracle cache
Then, create a cache table user sales whose name is the same as the Oracle
Database schema user who owns the Oracle Database tables to be cached in the
TimesTen Classic database.
% ttIsql cacheactive
Command> CREATE USER cacheadmin IDENTIFIED BY timesten;
Command> CREATE USER sales IDENTIFIED BY timesten;
As the instance administrator, use the ttIsql utility to grant the TimesTen cache
administration user cacheadmin the privileges required as well as create an active
standby pair replication scheme which requires the ADMIN privilege:
Command> GRANT CREATE SESSION, CACHE_MANAGER,
CREATE ANY TABLE, ADMIN TO cacheadmin;
Command> exit
4-48
Chapter 4
Start the ttIsql utility and connect to the cacheactive DSN as the TimesTen cache
administration user. Set the Oracle cache administration user name and password by calling
the ttCacheUidPwdSet built-in procedure.
% ttIsql "DSN=cacheactive;UID=cacheadmin;PWD=timesten;OraclePWD=orapwd"
Command> CALL ttCacheUidPwdSet('cacheadmin','orapwd');
If desired, you can test the connectivity between the active database and the Oracle
database using the instructions stated in Testing the Connectivity Between the TimesTen and
Oracle Databases.
Start the cache agent on the active database by calling the ttCacheStart built-in procedure
as the TimesTen cache administration user:
Command> CALL ttCacheStart;
The following statement is the definition of the Oracle Database table that is to be cached in a
dynamic AWT cache group. The Oracle Database table is owned by the schema user sales.
The sales user must be granted the CREATE SESSION, CREATE TRIGGER, CREATE SEQUENCE,
CREATE TYPE, CREATE PROCEDURE, and CREATE TABLE privileges before it can create tables.
CREATE TABLE subscriber
(subscriberid NUMBER(10) NOT NULL PRIMARY KEY,
minutes_balance NUMBER(5) NOT NULL,
last_call_duration NUMBER(4) NOT NULL);
The Oracle cache administration user must be granted the SELECT privilege on the
sales.subscriber table so that the TimesTen cache administration user can create an AWT
cache group that caches this table. The Oracle cache administration user must be granted
the INSERT, UPDATE and DELETE Oracle Database privileges for the sales.subscriber table
for asynchronous writethrough operations to be applied to the Oracle Database.
Then, create cache groups in the TimesTen Classic database with the CREATE DYNAMIC
ASYNCHRONOUS WRITETHROUGH CACHE GROUP statement as the TimesTen cache administration
user. For example, the following statement creates a dynamic AWT cache group
subscriber_accounts that caches the sales.subscriber table:
CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP subscriber_accounts
FROM sales.subscriber
(subscriberid NUMBER(10) NOT NULL PRIMARY KEY,
minutes_balance NUMBER(5) NOT NULL,
last_call_duration NUMBER(4) NOT NULL);
As the TimesTen cache administration user, create an active standby pair replication scheme
in the active database using a CREATE ACTIVE STANDBY PAIR statement.
In the following example, cacheact, cachestand and subscr are the file name prefixes of the
checkpoint and transaction log files of the active database, standby database and read-only
subscriber database. sys3, sys4 and sys5 are the host names of the TimesTen systems
where the active database, standby database and read-only subscriber database reside,
respectively.
Command> CREATE ACTIVE STANDBY PAIR cacheact ON "sys3", cachestand ON "sys4"
SUBSCRIBER subscr ON "sys5";
4-49
Chapter 4
As the TimesTen cache administration user, start the replication agent on the active
database by calling the ttRepStart built-in procedure. Then declare the database as
the active by calling the ttRepStateSet built-in procedure.
Command> CALL ttRepStart;
Command> CALL ttRepStateSet('active');
Create and Configure the Standby Database

This example shows how to create and configure a standby database in an active
standby pair replication scheme.
The following is the definition of the cachestandby DSN for the standby database of
the active standby pair:
[cachestandby]
DataStore=/users/OracleCache/cachestand
PermSize=64
As the instance administrator, create the standby database as a duplicate of the active
database by running a ttRepAdmin -duplicate utility command from the standby
database system. The instance administrator user name of the active database's and
standby database's instances must be identical.
Use the -keepCG option so that cache tables in the active database are duplicated as
cache tables in the standby database, because the standby database is connected
with the Oracle database.
In the following example:
• The -from option specifies the file name prefix of the active database's checkpoint
and transaction log files.
• The -host option specifies the host name of the TimesTen system where the
active database resides.
• The -uid and -pwd options specify a user name and password of a TimesTen
internal user defined in the active database that has been granted the ADMIN
privilege.
• The -cacheuid and -cachepwd options specify the Oracle cache administration
user name and password.
• cachestandby is the DSN of the standby database.
• The -keepCG option specifies that the standby database keeps the cache groups
defined on the active database.
% ttRepAdmin -duplicate -from cacheact -host "sys3" -uid cacheadmin -pwd timesten
-cacheuid cacheadmin -cachepwd orapwd -keepCG cachestandby
Start the ttIsql utility and connect to the cachestandby DSN as the TimesTen cache
administration user. Set the Oracle cache administration user name and password by
calling the ttCacheUidPwdSet built-in procedure.
% ttIsql "DSN=cachestandby;UID=cacheadmin;PWD=timesten;OraclePWD=orapwd"
Command> CALL ttCacheUidPwdSet('cacheadmin','orapwd');
4-50
Chapter 4
If desired, you can test the connectivity between the standby database and the Oracle
database using the instructions stated in Testing the Connectivity Between the TimesTen and
Oracle Databases.
Start the cache agent on the standby database by calling the ttCacheStart built-in procedure
as the TimesTen cache administration user:
Command> CALL ttCacheStart;
As the TimesTen cache administration user, start the replication agent on the standby
database by calling the ttRepStart built-in procedure.
Create and Configure the Read-Only Subscriber Database

This example demonstrates how to create and configure a read-only subscriber within an
active standby pair replication scheme.
The following is the definition of the rosubscriber DSN for the read-only subscriber database
of the active standby pair:
[rosubscriber]
DataStore=/users/OracleCache/subscr
PermSize=64
As the instance administrator, create the read-only subscriber database as a duplicate of the
standby database by running a ttRepAdmin -duplicate utility command from the read-only
subscriber database system. The instance administrator user name of the standby database
and read-only subscriber database must be identical.
Use the -noKeepCG option so that cache tables in the standby database are duplicated as
regular tables in the read-only subscriber database because the read-only subscriber
database is not connected with the Oracle database.
In the following example:
• The -from option specifies the file name prefix of the standby database's checkpoint and
transaction log files.
• The -host option specifies the host name of the TimesTen system where the standby
database resides.
• The -uid and -pwd options specify a user name and password of a TimesTen internal
user defined in the standby database that has been granted the ADMIN privilege.
• rosubscriber is the DSN of the read-only subscriber database.
% ttRepAdmin -duplicate -from cachestand -host "sys4" -uid cacheadmin -pwd timesten
-noKeepCG rosubscriber
As the TimesTen cache administration user, start the replication agent on the read-only
subscriber database by calling the ttRepStart built-in procedure.
% ttIsql "DSN=rosubscriber;UID=cacheadmin;PWD=timesten"
Command> exit
4-51
5
Methods for Transmitting Changes Between
TimesTen and Oracle Databases
You can transmit changes between TimesTen and Oracle databases manually or
automatically.
• Manually load cache groups: You can manually load or refresh cache instances into the
TimesTen cache tables from the Oracle database tables using LOAD CACHE GROUP or
REFRESH CACHE GROUP statements.
• Manually propagate committed changes: Use a FLUSH CACHE GROUP statement to
propagate committed changes on the TimesTen cache tables to the cached Oracle
Database tables.
• Automatically refresh cache groups: You can cause the cache instances to be
automatically refreshed with the AUTOREFRESH cache table attribute. Automatic refresh can
be defined on cache groups that are either explicitly or dynamically loaded.
• Dynamically load data on demand: When you define a cache group with the DYNAMIC
keyword, then the data in a cache group is dynamically loaded on demand.
• Automatic propagation of changes to the Oracle database: When you configure the
PROPAGATE cache table attribute on the TimesTen cache tables, then committed changes
are automatically propagated to the cached Oracle Database tables.
See Transmitting Changes Between the TimesTen and Oracle Databases for an overview of
each of these methods.
Note:
You can use SQL statements or SQL Developer to perform most of the operations
in this chapter. For more information about SQL Developer, see Oracle TimesTen
In-Memory Database SQL Developer Support User's Guide.
The following sections describe these operations:

• Manually Loading and Refreshing a Cache Group
• Flushing a User Managed Cache Group
• Unloading a Cache Group
• Automatically Refreshing a Cache Group
• Manually or Dynamically Loading Cache Groups
• Dynamic Cache Groups
• Determining the Number of Cache Instances Affected by an Operation
• Setting a Passthrough Level
5-1
Chapter 5
Manually Loading and Refreshing a Cache Group

You can manually insert or update cache instances into the TimesTen cache tables
from the cached Oracle Database tables using either a LOAD CACHE GROUP or REFRESH
The differences between loading and refreshing a cache group are:

• The LOAD CACHE GROUP statement only loads committed inserts on the cached
Oracle Database tables into the TimesTen cache tables. New cache instances are
loaded into the cache tables, but cache instances that already exist in the cache
tables are not updated or deleted even if the corresponding rows in the cached
Oracle Database tables have been updated or deleted. A load operation is
primarily used to initially populate a cache group.
• The REFRESH CACHE GROUP statement replaces cache instances in the TimesTen
cache tables with the most current data from the cached Oracle Database tables
including cache instances that are already exist in the cache tables. A refresh
operation is primarily used to update the contents of a cache group with committed
changes on the cached Oracle Database tables after the cache group has been
initially populated.
For a static cache group, a refresh operation is equivalent to issuing an UNLOAD
CACHE GROUP statement followed by a LOAD CACHE GROUP statement on the cache
group. In effect, all committed inserts, updates and deletes on the cached Oracle
Database tables are refreshed into the cache tables. New cache instances may be
loaded into the cache tables. Cache instances that already exist in the cache
tables are updated or deleted if the corresponding rows in the cached Oracle
Database tables have been updated or deleted. See Unloading a Cache Group for
more information about the UNLOAD CACHE GROUP statement.
For a dynamic cache group, a refresh operation only refreshes committed updates
and deletes on the cached Oracle Database tables into the cache tables because
only existing cache instances in the cache tables are refreshed. New cache
instances are not loaded into the cache tables so after the refresh operation
completes, the cache tables contain either the same or fewer number of cache
instances. To load new cache instances into the cache tables of a dynamic cache
group, use a LOAD CACHE GROUP statement or perform a dynamic load operation.
See Dynamic Cache Groups for more information about a dynamic load operation.
For most cache group types, you can use a WHERE clause in a LOAD CACHE GROUP or
REFRESH CACHE GROUP statement to restrict the rows to be loaded or refreshed into the
cache tables.
If the cache table definitions use a WHERE clause, only rows that satisfy the WHERE
clause are loaded or refreshed into the cache tables even if the LOAD CACHE GROUP or
REFRESH CACHE GROUP statement does not use a WHERE clause.
If the cache group has a time-based aging policy defined, only cache instances where
the timestamp in the root table's row is within the aging policy's lifetime are loaded or
refreshed into the cache tables.
To prevent a load or refresh operation from processing a large number of cache
instances within a single transaction, which can greatly reduce concurrency and
throughput, use the COMMIT EVERY n ROWS clause to specify a commit frequency unless
5-2
Chapter 5
you are using the WITH ID clause. If you specify COMMIT EVERY 0 ROWS, the load or refresh
operation is processed in a single transaction.
In addition, if the load operation is for a large amount of data, use parallelism to increase
throughput by specifying the number of threads with the PARALLEL clause.
A LOAD CACHE GROUP or REFRESH CACHE GROUP statement that uses the COMMIT EVERY n ROWS
clause must be performed in its own transaction without any other operations within the same
transaction.
The following example loads new cache instances into the TimesTen cache tables in the
customer_orders cache group from the cached Oracle Database tables:
LOAD CACHE GROUP customer_orders COMMIT EVERY 256 ROWS PARALLEL 3;
The following example loads into the TimesTen cache tables using a WHERE clause in the
new_customers cache group from the cached Oracle Database tables. The WHERE clause
specifies new cache instances for customers whose customer number is greater than or
equal to 5000:
LOAD CACHE GROUP new_customers WHERE (sales.customer.cust_num >= 5000)
COMMIT EVERY 256 ROWS;
The following example refreshes cache instances in the TimesTen cache tables within the
top_products cache group from the cached Oracle Database tables:
REFRESH CACHE GROUP top_products COMMIT EVERY 256 ROWS;
The following example refreshes in the TimesTen cache tables within the
update_anywhere_customers cache group from the cached Oracle Database tables. The
WHERE clause specifies cache instances of customers located in zip code 60610:
REFRESH CACHE GROUP update_anywhere_customers
WHERE (sales.customer.zip = '60610') COMMIT EVERY 256 ROWS;
See LOAD CACHE GROUP and REFRESH CACHE GROUP in Oracle TimesTen In-Memory
Database SQL Reference.
The rest of this section includes these topics:
• Loading and Refreshing a Cache Group Using a WITH ID Clause
• Loading and Refreshing a Multiple-Table Cache Group
• Improving the Performance of Loading or Refreshing a Large Number of Cache
Instances
• Example of Manually Loading and Refreshing a Static Cache Group
• Example of Manually Loading and Refreshing a Dynamic Cache Group
Loading and Refreshing a Cache Group Using a WITH ID Clause

The WITH ID clause of the LOAD CACHE GROUP or REFRESH CACHE GROUP statement enables
you to load or refresh a cache group based on values of the primary key columns without
having to use a WHERE clause.
The WITH ID clause is more convenient than the equivalent WHERE clause if the primary key
contains more than one column. Using the WITH ID clause allows you to load one cache
instance at a time. It also enables you to roll back the transaction containing the load or
5-3
Chapter 5
refresh operation, if necessary, unlike the equivalent statement that uses a WHERE
clause because using a WHERE clause also requires specifying a COMMIT EVERY n ROWS
clause.
The following example loads a cache group using a WITH ID clause. A cache group
recent_orders contains a single cache table sales.orderdetails with a primary key
of (orderid, itemid). If a customer calls about an item within a particular order, the
information can be obtained by loading the cache instance for the specified order
number and item number.
Load the sales.orderdetails cache table in the recent_orders cache group with the
row whose value in the orderid column of the sales.orderdetails cached Oracle
Database table is 1756 and its value in the itemid column is 573:
LOAD CACHE GROUP recent_orders WITH ID (1756,573);
The following is an equivalent LOAD CACHE GROUP statement that uses a WHERE clause:
LOAD CACHE GROUP recent_orders WHERE orderid = 1756 and itemid = 573
COMMIT EVERY 256 ROWS;
A LOAD CACHE GROUP or REFRESH CACHE GROUP statement issued on a cache group with
autorefresh cannot contain a WITH ID clause unless the cache group is dynamic.
You cannot use the COMMIT EVERY n ROWS clause with the WITH ID clause.
Loading and Refreshing a Multiple-Table Cache Group

If you are loading or refreshing a multiple-table cache group while the cached Oracle
Database tables are concurrently being updated, set the isolation level in the
TimesTen database to serializable before issuing the LOAD CACHE GROUP or REFRESH
This causes TimesTen to query the cached Oracle Database tables in a serializable
fashion during the load or refresh operation so that the loaded or refreshed cache
instances in the cache tables are guaranteed to be transactionally consistent with the
corresponding rows in the cached Oracle Database tables. After you have loaded or
refreshed the cache group, set the isolation level back to read committed for better
concurrency when accessing elements in the TimesTen database.
Improving the Performance of Loading or Refreshing a Large Number

of Cache Instances
You can improve the performance of loading or refreshing a large number of cache
instances into a cache group by using the PARALLEL clause of the LOAD CACHE GROUP
or REFRESH CACHE GROUP statement.
Specify the number of threads to use when processing the load or refresh operation.
You can specify 1 to 10 threads. One thread fetches rows from the cached Oracle
Database tables, while the other threads insert the rows into the TimesTen cache
tables. Do not specify more threads than the number of CPUs available on your
system or you may encounter decreased performance than if you had not used the
PARALLEL clause.
5-4
Chapter 5
Note:
You cannot use the WITH ID clause with the PARALLEL clause. You can use the
COMMIT EVERY n ROWS clause with the PARALLEL clause as long as n is greater than
0. In addition, you cannot use the PARALLEL clause for read-only dynamic cache
groups or when database level locking is enabled. See REFRESH CACHE GROUP
in the Oracle TimesTen In-Memory Database SQL Reference.
The following example refreshes cache instances in the TimesTen cache tables using a
PARALLEL clause. This example refreshes the western_customers cache group from the
cached Oracle Database tables using one thread to fetch rows from the cached Oracle
Database tables and three threads to insert the rows into the cache tables:
REFRESH CACHE GROUP western_customers COMMIT EVERY 256 ROWS PARALLEL 4;
Example of Manually Loading and Refreshing a Static Cache Group

This example shows the definition of an Oracle Database table that is to be cached in a static
AWT cache group.
The Oracle Database table is owned by the schema user sales.
name VARCHAR2(50),
The following is the data in the sales.customer cached Oracle Database table.
CUST_NUM REGION NAME ADDRESS
-------- ------- --------------- ---------------------------
1 West Frank Edwards 100 Pine St. Portland OR
2 East Angela Wilkins 356 Olive St. Boston MA
3 Midwest Stephen Johnson 7638 Walker Dr. Chicago IL
The following statement creates a static AWT cache group new_customers that caches the
sales.customer table:
FROM sales.customer
name VARCHAR2(50),
The sales.customer TimesTen cache table is initially empty.

Command> SELECT * FROM sales.customer;
0 rows found.
The following LOAD CACHE GROUP statement loads the three cache instances from the cached
Oracle Database table into the TimesTen cache table:
5-5
Chapter 5
Command> LOAD CACHE GROUP new_customers COMMIT EVERY 256 ROWS;

< 1, West, Frank Edwards, 100 Pine St. Portland OR >
< 2, East, Angela Wilkins, 356 Olive St. Boston MA >
< 3, Midwest, Stephen Johnson, 7638 Walker Dr. Chicago IL >
Update the cached Oracle Database table by inserting a new row, updating an existing
row, and deleting an existing row:
SQL> INSERT INTO customer
2 VALUES (4, 'East', 'Roberta Simon', '3667 Park Ave. New York NY');
SQL> UPDATE customer SET name = 'Angela Peterson' WHERE cust_num = 2;
SQL> DELETE FROM customer WHERE cust_num = 3;
SQL> COMMIT;
SQL> SELECT * FROM customer;
-------- ------- --------------- ---------------------------
2 East Angela Peterson 356 Olive St. Boston MA
4 East Roberta Simon 3667 Park Ave. New York NY
A REFRESH CACHE GROUP statement issued on a static cache group is processed by

unloading and then reloading the cache group. As a result, the cache instances in the
cache table matches the rows in the cached Oracle Database table.
Command> REFRESH CACHE GROUP new_customers COMMIT EVERY 256 ROWS;
3 cache instance affected.
< 2, East, Angela Peterson, 356 Olive St. Boston MA >
< 4, East, Roberta Simon, 3667 Park Ave. New York NY >
Example of Manually Loading and Refreshing a Dynamic Cache

Group
This example shows the definition of an Oracle Database table that is to be cached in
a dynamic AWT cache group.
The Oracle Database table is owned by the schema user sales.
name VARCHAR2(50),
The following is the data in the sales.customer cached Oracle Database table.
-------- ------- --------------- ---------------------------
2 East Angela Wilkins 356 Olive St. Boston MA
3 Midwest Stephen Johnson 7638 Walker Dr. Chicago IL
The following statement creates a dynamic AWT cache group new_customers that
caches the sales.customer table:
5-6
Chapter 5
CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers

FROM sales.customer
name VARCHAR2(50),
The sales.customer TimesTen cache table is initially empty:

0 rows found.
The following LOAD CACHE GROUP statement loads the three cache instances from the cached
Oracle Database table into the TimesTen cache table:
< 2, East, Angela Wilkins, 356 Olive St. Boston MA >
< 3, Midwest, Stephen Johnson, 7638 Walker Dr. Chicago IL >
Update the cached Oracle Database table by inserting a new row, updating an existing row,
and deleting an existing row:
SQL> INSERT INTO customer
2 VALUES (4, 'East', 'Roberta Simon', '3667 Park Ave. New York NY');
SQL> UPDATE customer SET name = 'Angela Peterson' WHERE cust_num = 2;
SQL> DELETE FROM customer WHERE cust_num = 3;
SQL> COMMIT;
SQL> SELECT * FROM customer;
-------- ------- --------------- ---------------------------
2 East Angela Peterson 356 Olive St. Boston MA
4 East Roberta Simon 3667 Park Ave. New York NY
A REFRESH CACHE GROUP statement issued on a dynamic cache group only refreshes
committed updates and deletes on the cached Oracle Database tables into the cache tables.
New cache instances are not loaded into the cache tables. Therefore, only existing cache
instances are refreshed. As a result, the number of cache instances in the cache tables are
either fewer than or the same as the number of rows in the cached Oracle Database tables.
Command> REFRESH CACHE GROUP new_customers COMMIT EVERY 256 ROWS;
A subsequent LOAD CACHE GROUP statement loads one cache instance from the cached
Oracle Database table into the TimesTen cache table because only committed inserts are
loaded into the cache table. Therefore, only new cache instances are loaded. Cache
instances that already exist in the cache tables are not changed because of a LOAD CACHE
GROUP statement, even if the corresponding rows in the cached Oracle Database tables were
updated or deleted.
1 cache instance affected.
5-7
Chapter 5
Flushing a User Managed Cache Group

< 4, East, Roberta Simon, 3667 Park Ave. New York NY >
Flushing a User Managed Cache Group

The FLUSH CACHE GROUP statement manually propagates committed inserts and
updates on TimesTen cache tables in a user managed cache group to the cached
Oracle Database tables.
A flush operation can manually propagate multiple committed transactions on cache
tables to the cached Oracle Database tables. This statement is available only for user
managed cache groups. Delete operations are not flushed or manually propagated.
Automatic propagation is initiated when you use the PROPAGATE cache table attribute
when defining your cache group. TimesTen then automatically propagates committed
inserts, updates and deletes at commit time to the Oracle database in the order that
they are committed in TimesTen.
You cannot flush a user managed cache group with the FLUSH CACHE GROUP statement
that uses the AUTOREFRESH cache group attribute.
You can flush a user managed cache group with the FLUSH CACHE GROUP statement if
at least one of its cache tables uses neither the PROPAGATE nor the READONLY cache
table attribute.
You can use a WHERE clause or WITH ID clause in a FLUSH CACHE GROUP statement to
restrict the rows to be flushed to the cached Oracle Database tables.
The following example flushes a cache group with the FLUSH CACHE GROUP statement.
It manually propagates committed insert and update operations on the TimesTen
cache tables in the western_customers cache group to the cached Oracle Database
tables:
FLUSH CACHE GROUP western_customers;
See FLUSH CACHE GROUP in Oracle TimesTen In-Memory Database SQL

Reference.
The following example creates a user managed cache group with the PROPAGATE cache
table attribute:
CREATE USERMANAGED CACHE GROUP updateanywherecustomers
AUTOREFRESH
MODE INCREMENTAL
INTERVAL 30 SECONDS
STATE ON
FROM
customer (custid INT NOT NULL,
name CHAR(100) NOT NULL,
addr CHAR(100),
zip INT,
PROPAGATE);
See PROPAGATE Cache Table Attribute in this book and CREATE CACHE GROUP in
the Oracle TimesTen In-Memory Database SQL Reference.
5-8
Chapter 5
Unloading a Cache Group
Unloading a Cache Group

You can delete some or all cache instances from the cache tables in a cache group with the
UNLOAD CACHE GROUP statement.
Unlike the DROP CACHE GROUP statement, the cache tables themselves are not dropped when
a cache group is unloaded.
To prevent an unload operation from processing a large number of cache instances within a
single transaction, which could reduce concurrency and throughput, use the COMMIT EVERY n
ROWS clause to specify a commit frequency.
Use caution when using the UNLOAD CACHE GROUP statement with cache groups with
autorefresh. An unloaded row can reappear in the cache table as the result of an autorefresh
operation if the row, or its related parent or child rows, are updated in the cached Oracle
Database table.
Processing of the UNLOAD CACHE GROUP statement for an AWT cache group waits until
updates on the rows have been propagated to the Oracle database.
The following example unloads all cache instances from all cache tables in the
customer_orders cache group. A commit frequency is specified, so the operations is
performed over several transactions by committing every 256 rows:
UNLOAD CACHE GROUP customer_orders COMMIT EVERY 256 ROWS;
The following statement unloads all cache instances from all cache tables in the
customer_orders cache group in a single transaction. A single transaction should only be
used if the data within customer_orders is small:
UNLOAD CACHE GROUP customer_orders;
The following equivalent statements delete the cache instance for customer number 227 from
the cache tables in the new_customers cache group:
UNLOAD CACHE GROUP new_customers WITH ID (227);
UNLOAD CACHE GROUP new_customers WHERE (sales.customer.cust_num = 227);
See UNLOAD CACHE GROUP in the Oracle TimesTen In-Memory Database SQL
Reference.
Automatically Refreshing a Cache Group

You can configure automatic refresh with the AUTOREFRESH cache group attribute.
• AUTOREFRESH Cache Group Attribute Overview

• Altering a Cache Group to Change the AUTOREFRESH Mode, Interval or State
• Manually Creating Oracle Database Objects for Cache Groups With Autorefresh
• Initiating an Immediate Autorefresh in TimesTen Classic
• Disabling Full Autorefresh for Cache Groups
• Loading and Refreshing a Static Cache Group With Autorefresh
• Loading and Refreshing a Dynamic Cache Group With Autorefresh
5-9
Chapter 5
AUTOREFRESH Cache Group Attribute Overview

The AUTOREFRESH cache group attribute can be specified when creating a read-only
cache group or a user managed cache group using a CREATE CACHE GROUP statement.
AUTOREFRESH specifies that committed changes on cached Oracle Database tables are
automatically refreshed to the TimesTen cache tables. Autorefresh is defined by
default on read-only cache groups.
The following are the default settings of the autorefresh attributes:
• The autorefresh mode is incremental.
• The autorefresh interval is 5 minutes.
• The autorefresh state is PAUSED.
If you create a unique index on a cache group with the AUTOREFRESH cache group
attribute, the index is changed to a non-unique index to avoid a constraint violation. A
constraint violation could occur with a unique index because conflicting updates could
occur in the same statement processing on the Oracle Database table, while each row
update is processed separately in TimesTen. If the unique index exists on the Oracle
Database table that is being cached, then uniqueness is enforced on the Oracle
Database table and does not need to be verified again in TimesTen.
The following sections describe each of the autorefresh attributes:
• Autorefresh Mode Attribute Settings
• Autorefresh Interval and State Settings
• Restrictions for Autorefresh
Autorefresh Mode Attribute Settings

You can set the autorefresh mode to designate how the automatic refresh is to
perform.
TimesTen supports two autorefresh mode settings:
• FULL: All cache tables are automatically refreshed, based on the cache group's
autorefresh interval, by unloading all their rows and then reloading from the
There is no overhead when using full autorefresh mode, but there may be
performance implications.
• INCREMENTAL: Committed changes on cached Oracle Database tables are
automatically refreshed to the TimesTen cache tables based on the cache group's
autorefresh interval.
There is overhead when using incremental autorefresh mode, but the performance
is better than when using full autorefresh.
Some applications choose incremental autorefresh instead of full autorefresh mode for
performance reasons. A full autorefresh can affect performance because:
• More rows are refreshed with a full autorefresh.
• A full autorefresh runs within a single transaction with no parallelism.
5-10
Chapter 5
Even if you use incremental autorefresh on your cache group, the first load is a full refresh. In
addition, TimesTen may perform a full autorefresh for recovery for certain error scenarios.
Note:
You can disallow full autorefresh with the DisableFullAutorefresh cache
configuration parameter. See Disabling Full Autorefresh for Cache Groups.
When using incremental autorefresh mode, committed changes on cached Oracle Database
tables are tracked in change log tables in the Oracle database. Because incremental
autorefresh tracks committed changes on the Oracle database, incremental autorefresh
mode incurs some overhead to refresh the cache group for each committed update on the
cached Oracle Database tables. Under certain circumstances, it is possible for some change
log records to be deleted (truncated) from the change log table before they are automatically
refreshed to the TimesTen cache tables. If this occurs, TimesTen initiates a full automatic
refresh on the cache group.
See Managing the Cache Administration User's Tablespace for information on how to
configure an action to take when the tablespace that the change log tables reside in becomes
full.
See Managing a Cache Environment With Oracle Database Objects for information on the
change log tables in the Oracle Database.
The change log table on the Oracle database does not have column-level resolution because
of performance reasons. Thus, the autorefresh operation updates all of the columns in a row.
XLA reports that all of the columns in the row have changed even if the data did not actually
change in each column. See XLA and TimesTen Event Management in the Oracle TimesTen
In-Memory Database C Developer's Guide or Using JMS/XLA for Event Management in the
Oracle TimesTen In-Memory Database Java Developer's Guide.
If you have a dynamic read-only cache group with autorefresh, you can reduce contention
and improve performance. See Reducing Contention for Dynamic Read-Only Cache Groups
With Incremental Autorefresh and Reducing Lock Contention for Read-Only Cache Groups
With Autorefresh and Dynamic Load and Options for Reducing Contention Between
Autorefresh and Dynamic Load Operations.
Autorefresh Interval and State Settings

The autorefresh interval determines how often autorefresh operations occur in minutes,
seconds or milliseconds.
Cache groups with the same autorefresh interval are refreshed within the same transaction.
You can specify continuous autorefresh with an autorefresh interval of 0 milliseconds. With
continuous autorefresh, the next autorefresh cycle is scheduled as soon as possible after the
last autorefresh cycle has ended.
In TimesTen Classic, you can manually initiate an immediate autorefresh operation with the
ttCacheAutorefresh built-in procedure. See ttCacheAutorefresh in Oracle TimesTen In-
Memory Database Reference.
The autorefresh state can be set to ON, OFF, or PAUSED.
5-11
Chapter 5
• ON: Autorefresh operations are scheduled by TimesTen when the cache group's
autorefresh state is ON.
• OFF: When the cache group's autorefresh state is OFF, committed changes on the
cached Oracle Database tables are not tracked.
• PAUSED: When the cache group's autorefresh state is PAUSED, committed changes
on the cached Oracle Database tables are tracked in the Oracle database, but are
not automatically refreshed to the TimesTen cache tables until the state is changed
to ON.
By default, a cache group is created with autorefresh state set to PAUSED. This provides
you a choice of how and when the initial full load is performed. If the data in the Oracle
database is large, then an initial full load of the cache group can prove to be time
consuming. The recommended option is to run a manual load with parallelism with the
LOAD CACHE GROUP... PARALLEL statement. The autorefresh state automatically
changes to ON after the load completes.
If the data on the Oracle database is small, change the state to ON with an ALTER
CACHE GROUP so that the initial load is performed and autorefresh operations start.
If the data on the Oracle database is too large to perform an initial full load, you can
disable all full load operations. See Disabling Full Autorefresh for Cache Groups.
Restrictions for Autorefresh

There are restrictions when using the AUTOREFRESH cache group attribute.
• TimesTen Scaleout only supports static read-only cache groups with incremental
autorefresh. See Using Cache Groups in TimesTen Scaleout in the Oracle
TimesTen In-Memory Database Scaleout User's Guide.
• A TRUNCATE TABLE statement issued on a cached Oracle Database table is not
automatically refreshed to the TimesTen cache table. Before issuing a TRUNCATE
TABLE statement on a cached Oracle Database table, use an ALTER CACHE GROUP
statement to change the autorefresh state of the cache group that contains the
cache table to PAUSED.
See Altering a Cache Group to Change the AUTOREFRESH Mode, Interval or
State.
After issuing the TRUNCATE TABLE statement on the cached Oracle Database table,
use a REFRESH CACHE GROUP statement to manually refresh the cache group.
• A LOAD CACHE GROUP statement can only be issued if the cache tables are empty,
unless the cache group is dynamic.
See Manually Loading and Refreshing a Cache Group and Creating a Dynamic
Cache Group With the DYNAMIC Keyword.
statement on the cache group, unless the cache group is dynamic. If the cache
group is dynamic, the autorefresh state must be PAUSED or ON.
5-12
Chapter 5
• The LOAD CACHE GROUP statement cannot contain a WHERE clause, unless the cache group
is dynamic. If the cache group is dynamic, the WHERE clause must be followed by a COMMIT
EVERY n ROWS clause.
statement on the cache group. The REFRESH CACHE GROUP statement cannot contain a
WHERE clause.
• All tables and columns referenced in WHERE clauses when creating, loading or unloading
the cache group must be fully qualified. For example:
• To use the AUTOREFRESH cache group attribute in a user managed cache group, all of the
cache tables must be specified with the PROPAGATE cache table attribute or all of the
cache tables must be specified the READONLY cache table attribute.
• You cannot specify the AUTOREFRESH cache group attribute in a user managed cache
group that contains cache tables that explicitly use the NOT PROPAGATE cache table
attribute.
• The AUTOREFRESH cache table attribute cannot be used when caching Oracle Database
materialized views in a user managed cache group.
• LRU aging cannot be specified on the cache group, unless the cache group is dynamic
where LRU aging is defined by default.
• If you want to use replication with a static cache group with autorefresh on TimesTen
Classic, you can only use an active standby pair replication scheme. Any other type of
replication scheme is not allowed with a static cache group with autorefresh on TimesTen
Classic.
Altering a Cache Group to Change the AUTOREFRESH Mode, Interval or

State
After creating a cache group with autorefresh, you can use ALTER CACHE GROUP statement to
change autorefresh mode, interval or state.
• In TimesTen Classic, you can change the cache group's autorefresh mode, interval or
state.
• In TimesTen Scaleout, you can only change the cache group's autorefresh state.
You cannot use ALTER CACHE GROUP to instantiate automatic refresh for a cache group that
was originally created without autorefresh defined.
If you change a cache group's autorefresh state to OFF or drop a cache group that has an
autorefresh operation in progress:
• The autorefresh operation stops if the setting of the LockWait connection attribute is
greater than 0. The ALTER CACHE GROUP or DROP CACHE GROUP statement preempts the
autorefresh operation.
• The autorefresh operation continues if the LockWait connection attribute is set to 0. The
ALTER CACHE GROUP or DROP CACHE GROUP statement is blocked until the autorefresh
operation completes or the statement fails with a lock timeout error.
5-13
Chapter 5
The following example alters the autorefresh attributes of a cache group in TimesTen
Classic. These statements change the autorefresh mode, interval and state of the
customer_orders cache group:
ALTER CACHE GROUP customer_orders SET AUTOREFRESH MODE FULL;
ALTER CACHE GROUP customer_orders SET AUTOREFRESH INTERVAL 30 SECONDS;
ALTER CACHE GROUP customer_orders SET AUTOREFRESH STATE ON;
TimesTen returns asynchronously after executing the ALTER CACHE GROUP statement.
However, there may be a delay for the cache agent to implement the change for the
new state, mode or interval.
Manually Creating Oracle Database Objects for Cache Groups With

Autorefresh
There are certain procedures you need to do if you created the Oracle Database
objects used to enforce the predefined behaviors of a cache group with autorefresh
with the initCacheAdminSchema.sql script.
See The initCacheAdminSchema.sql Script.

1. Set the autorefresh state to OFF when creating the cache group.
2. Run the ttIsql utility's cachesqlget command with the
INCREMENTAL_AUTOREFRESH option and the INSTALL flag as the TimesTen cache
administration user. This command generates a SQL*Plus script used to create a
cache log table and a trigger in the Oracle database for each Oracle Database
table that is cached in the autorefresh cache group. These Oracle Database
objects track updates on the cached Oracle Database tables so that the updates
can be automatically refreshed to the cache tables.
Note:
The ttCacheSQLGet built-in procedure provides the same functionality as
the ttISql cachesqlget command.
3. Use SQL*Plus to run the script generated by the ttIsql utility's cachesqlget
command as the sys user.
4. Run an ALTER CACHE GROUP statement to change the autorefresh state of the
cache group to PAUSED.
The following examples shows how to create a read-only cache group when Oracle
Database objects are created with the initCacheAdminSchema.sql script.
The first statement creates a read-only cache group customer_orders with the
autorefresh state set to OFF. The SQL*Plus script generated by the ttIsql utility's
cachesqlget command is saved to the /tmp/obj.sql file. The last statement changes
the autorefresh state of the cache group to PAUSED.
AUTOREFRESH STATE OFF
FROM sales.customer
5-14
Chapter 5
name VARCHAR2(50),
sales.orders
Command> cachesqlget INCREMENTAL_AUTOREFRESH customer_orders INSTALL /tmp/obj.sql;
Command> exit
% sqlplus sys as sysdba

SQL> @/tmp/obj
SQL> exit
ALTER CACHE GROUP customer_orders SET AUTOREFRESH STATE PAUSED;
See ttISql and ttCacheSQLGet in Oracle TimesTen In-Memory Database Reference.
Initiating an Immediate Autorefresh in TimesTen Classic

In TimesTen Classic, if the Oracle Database tables have been updated with data that needs
to be applied to cache tables without waiting for the next autorefresh operation, you can call
the ttCacheAutorefresh built-in procedure.
The ttCacheAutorefresh built-in procedure initiates an immediate refresh operation and

resets the autorefresh cycle to start at the moment you invoke ttCacheAutorefresh.
The refresh operation is full or incremental depending on how the cache group is configured.
The autorefresh state must be ON when ttCacheAutorefresh is called.
The autorefresh operation typically refreshes all cache groups sharing the same refresh
interval in one transaction in order to preserve transactional consistency across these cache
groups. Therefore, although you specify a specific cache group when you call
ttCacheAutorefresh, the autorefresh operation occurs in one transaction for all cache
groups that share the autorefresh interval with the specified cache group. If there is an
existing transaction with table locks on objects that belong to the affected cache groups,
ttCacheAutofresh returns an error without taking any action.
You can choose to run ttCacheAutorefresh asynchronously (the default) or synchronously.

In synchronous mode, ttCacheAutorefresh returns an error if the refresh operation fails.
After calling ttCacheAutorefresh, you must commit or roll back the transaction before
subsequent work can be performed.
This example calls ttCacheAutorefresh for the ttuser.western_customers cache group,
using asynchronous mode.
Command> call ttCacheAutorefresh('ttuser', 'western_customers');
5-15
Chapter 5
Disabling Full Autorefresh for Cache Groups

If performance is a concern, you can set the DisableFullAutorefresh cache
configuration parameter to 1 to disallow full autorefresh requests for all cache groups
defined with incremental autorefresh.
If you do disallow full autorefresh, then the initial load for each cache group requires a
manual load since the initial load requires a full refresh.
You can disable full autorefresh using the DisableFullAutorefresh cache
configuration parameter in both TimesTen Classic and TimesTen Scaleout.
Note:
The default value is 0 for the DisableFullAutorefresh cache configuration
parameter, which specifies full autorefresh behavior. Full autorefresh is only
supported on TimesTen Classic.
call ttCacheConfig('DisableFullAutorefresh',,,'1');
You can query the current value of the DisableFullAutorefresh parameter.

call ttCacheConfig('DisableFullAutorefresh');
If a full autorefresh is triggered for a cache group, TimesTen changes the cache group
status to disabled. After which, all autorefresh operations cease on the cache group.
You are notified of this action with a message logged in both the daemon and user log
files. See Error, Warning, and Informational Messages in the Oracle TimesTen In-
The TimesTen database status is set to recovering when at least one of its cache
groups have an autorefresh status of disabled or recovering. You can check the
state of a database and cache group with the ttCacheDbCgStatus built-in procedure.
The following example shows that:
• Recovering: Some or all the cache groups with the AUTOREFRESH attribute in the
database are being resynchronized with the Oracle database server. The status of
at least one cache group is recovering.
• Disabled: The cg1 cache group is disabled.
Command> call ttCacheDbCgStatus('ttuser','cg1');
< recovering, disabled >
1 row found.
When you set the DisableFullAutorefresh cache configuration parameter to 1, then

the DeadDbRecovery cache configuration parameter automatically changes to Manual.
TimesTen restores the original setting for the DeadDbRecovery cache configuration
parameter if you change the DisableFullAutorefresh cache configuration parameter
to 0.
If the autorefresh status of a cache group is either disabled or dead, its cache tables
are no longer being automatically refreshed when updates are committed on the
5-16
Chapter 5
cached Oracle Database tables. The cache group must be recovered in order to
resynchronize the cache tables with the cached Oracle Database tables.
• For each cache group whose autorefresh status is disabled, a REFRESH CACHE GROUP
statement must be issued in order to resume autorefresh operations for these cache
groups.
• For each dynamic cache group whose autorefresh status is disabled, an UNLOAD CACHE
GROUP statement must be issued in order to resume autorefresh operations for these
cache groups.
• See Impact of Failed Autorefresh Operations on TimesTen Databases for details on how
to specify recovery when the autorefresh status of a cache group is dead.
The following example shows the steps to manually refresh a disabled cache group.
1. Pause autorefresh for the cache group and return the cache group status to OK with the
ALTER CACHE GROUP SET AUTOREFRESH STATE PAUSED statement.
2. Manually request a full refresh with the REFRESH CACHE GROUP statement (optionally, with
parallelism).
ALTER CACHE GROUP cg_static SET AUTOREFRESH STATE PAUSED;
REFRESH CACHE GROUP cg_static COMMIT EVERY 500 ROWS PARALLEL 3;
Perform the following to reload a dynamic cache group:

1. To return the cache group status to OK, pause autorefresh for the cache group with the
ALTER CACHE GROUP SET AUTOREFRESH STATE PAUSED statement.
2. Unload the disabled dynamic cache group with the UNLOAD CACHE GROUP statement.
3. Optionally, you can load the cache group with the LOAD CACHE GROUP statement
(optionally, with parallelism) or initiate a dynamic load. See Dynamic Cache Groups.
The following example reloads the cg dynamic cache group:
ALTER CACHE GROUP cg_dynamic SET AUTOREFRESH STATE PAUSED;
UNLOAD CACHE GROUP cg_dynamic COMMIT EVERY 500 ROWS;
LOAD CACHE GROUP cg_dynamic COMMIT EVERY 500 ROWS PARALLEL 3;
Loading and Refreshing a Static Cache Group With Autorefresh

If the autorefresh state of a static cache group is PAUSED, the autorefresh state is changed to
ON after a LOAD CACHE GROUP or REFRESH CACHE GROUP statement issued on the cache group
completes.
The following restrictions apply when manually loading or refreshing a static cache group with
autorefresh:
• A LOAD CACHE GROUP statement can only be issued if the cache tables are empty.
statement.
statement.
• A LOAD CACHE GROUP statement cannot contain a WHERE clause.
• A LOAD CACHE GROUP or REFRESH CACHE GROUP statement cannot contain a WITH ID
clause.
5-17
Chapter 5
• A REFRESH CACHE GROUP statement cannot contain a WHERE clause.

• All tables and columns referenced in a WHERE clause when loading the cache
group must be fully qualified. For example:
When an autorefresh operation occurs on a static cache group, all committed inserts,
updates and deletes on the cached Oracle Database tables since the last autorefresh
cycle are refreshed into the cache tables. New cache instances may be loaded into the
cache tables. Cache instances that already exist in the cache tables are updated or
deleted if the corresponding rows in the cached Oracle Database tables have been
updated or deleted.
Loading and Refreshing a Dynamic Cache Group With Autorefresh

If the autorefresh state of a dynamic cache group is PAUSED, the autorefresh state is
changed to ON automatically after specific events occur.
• Its cache tables are initially empty, and then a dynamic load, a LOAD CACHE GROUP
or an unconditional REFRESH CACHE GROUP statement issued on the cache group
completes.
• Its cache tables are not empty, and then an unconditional REFRESH CACHE GROUP
statement issued on the cache group completes.
If the autorefresh state of a dynamic cache group is PAUSED, the autorefresh state
remains at PAUSED after any of the following events occur:
• Its cache tables are initially empty, and then a REFRESH CACHE GROUP ... WITH ID
statement issued on the cache group completes.
• Its cache tables are not empty, and then a dynamic load, a REFRESH CACHE
GROUP ... WITH ID, or a LOAD CACHE GROUP statement issued on the cache group
completes.
For a dynamic cache group, an autorefresh operation is similar to a REFRESH CACHE
GROUP statement that only refreshes committed updates and deletes on the cached
Oracle Database tables since the last autorefresh cycle into the cache tables because
only existing cache instances in the cache tables are refreshed. New cache instances
are not loaded into the cache tables. To load new cache instances into the cache
tables of a dynamic cache group, use a LOAD CACHE GROUP statement or perform a
dynamic load operation. See Dynamic Cache Groups.
The following restrictions apply when manually loading or refreshing a dynamic cache
group with automatic refresh:
• The autorefresh state must be PAUSED or ON before you can issue a LOAD CACHE
GROUP statement.
• The autorefresh state must be PAUSED before you can issue a REFRESH CACHE
GROUP statement.
• A LOAD CACHE GROUP statement that contains a WHERE clause must include a
COMMIT EVERY n ROWS clause after the WHERE clause.
• A REFRESH CACHE GROUP statement cannot contain a WHERE clause.
• All tables and columns referenced in a WHERE clause when loading the cache
group must be fully qualified. For example:
5-18
Chapter 5
Manually or Dynamically Loading Cache Groups
Manually or Dynamically Loading Cache Groups

You define whether your cache group is manually or dynamically loaded during cache group
definition.
Note:
A static cache group is one that is created without the DYNAMIC keyword. Static
cache groups are supported in both TimesTen Classic and TimesTen Scaleout. See
Using Cache Groups in TimesTen Scaleout in the Oracle TimesTen In-Memory
A dynamic cache group is created with the DYNAMIC keyword. Dynamic cache
groups are only supported in TimesTen Classic.
• Manually loaded: You can manually load data into either a static cache group or a
dynamic cache group. You will always manually load data into a static cache group.
Perform the initial load of data into either static or dynamic cache groups from cached
Oracle Database tables using a LOAD CACHE GROUP statement.
• Dynamically loaded on demand: For dynamic cache groups only, TimesTen can
dynamically load data on demand. Data is automatically loaded into the TimesTen cache
tables from the cached Oracle Database tables when a qualifying SELECT, INSERT,
UPDATE, or DELETE statement is issued on one of the cache tables and the data does not
exist in the cache table but does exist in the cached Oracle Database table.
With both static and dynamic cache groups, a LOAD CACHE GROUP statement manually loads
into the designated cache tables qualified data that exists in the cached Oracle Database
tables but not in the cache tables in TimesTen. However, if a row exists in a cache table but a
newer version exists in the cached Oracle Database table, a LOAD CACHE GROUP statement
does not load that row into the cache table even if it satisfies the predicate of the statement.
By contrast, a REFRESH CACHE GROUP statement manually reloads qualifying rows that exists
in the cache tables, effectively refreshing the content of the cache. For a static cache group,
the rows that are refreshed are all the rows that satisfy the predicate of the REFRESH CACHE
GROUP statement. However, for a dynamic cache group, the rows that are refreshed are the
ones that satisfy the predicate and already exist in the cache tables. In other words, rows that
end up being refreshed are the ones that have been updated or deleted in the cached Oracle
Database table, but not the ones that have been inserted. Therefore, a refresh operation
processes only the rows that are already in the cache tables. No new rows are loaded into
the cache tables of a dynamic cache group as a result of a refresh.
The data in the cache instance of a dynamic read-only cache group is consistent with the
data in the corresponding rows of the Oracle Database tables. At any instant in time, the data
in a cache instance of a static cache group is consistent with the data in the corresponding
rows of the Oracle Database tables, taking into consideration the state and the interval
settings for autorefresh.
5-19
Chapter 5
Dynamic Cache Groups

You define whether your cache group is dynamically loaded by specifying the DYNAMIC
keyword during cache group definition.
When a qualifying SQL statement queries rows that do not exist in the TimesTen
database, then TimesTen automatically loads the relevant cache instances from the
Oracle database tables into dynamic cache groups. A dynamic load of a cache
instance is similar to a LOAD CACHE GROUP statement in that it retrieves and
automatically loads a qualified cache instance on demand from the Oracle database to
the TimesTen database. A cache instance consists of row from the root table of any
cache group (that is uniquely identified by either a primary key or a unique index on
the root table) and all related rows in the child tables associated by foreign key
relationships. Dynamic load operations do not update or delete cache instances that
already exist in the cache tables even if the corresponding rows in the cached Oracle
Database tables have been updated or deleted. Dynamic load operations are used to
dynamically provide data for the application. Often, dynamic load operations are
combined with aging, so that data can be aged out when not needed and dynamically
loaded when needed.
Note:
The REFRESH CACHE GROUP statement and autorefresh are used to update or
delete cache instances that already exist in the TimesTen database. You can
use autorefresh to automatically populate changes made to cache instances
in the Oracle Database.
For example, a call center application may not want to preload all of its customers'
information into TimesTen as it may be very large. Instead, you can define the cache
group with the DYNAMIC keyword. After which, the cache group can use dynamic load
on demand so that a specific customer's information is loaded only when needed such
as when the customer calls or logs onto the system.
This following example creates a dynamic read-only cache group online_customers
that caches the sales.customer table:
CREATE DYNAMIC READONLY CACHE GROUP online_customers
FROM sales.customer
name VARCHAR2(50),
Any system managed cache group type (read-only, AWT, SWT or hybrid) can be
defined with the DYNAMIC keyword. A user managed cache group can be defined with
the DYNAMIC keyword unless it uses both the AUTOREFRESH and the PROPAGATE cache
table attributes.
5-20
Chapter 5
Note:
If you have a dynamic read-only cache group with incremental autorefresh, you can
reduce contention and improve performance with either of the methods described in
Options for Reducing Contention Between Autorefresh and Dynamic Load
Operations.
When a cache group is enabled for dynamic load, a cache instance is uniquely identified
either by a primary key, a unique index on any table, or a foreign key of a child table. If a row
in the cached Oracle Database table satisfies the WHERE clause and the row is not in the
TimesTen database, then the entire associated cache instance is loaded in order to maintain
the defined relationships between primary keys and foreign keys of the parent and child
tables. When a cache group is enabled for dynamic load, the dynamic load operation typically
loads only one cache instance into the root table of any cache group, unless you specifically
request to load multiple cache instances (as described in Dynamically Loading Multiple
Cache Instances).
The WHERE clause must specify one of the following for a dynamic load to occur:
• An equality condition with constants and/or parameters on all columns of a primary key or
a foreign key of any table of the cache group. If more than one table of a cache group is
referenced, each must be connected by an equality condition on the primary or foreign
key relationship.
• A mixture of equality or IS NULL conditions on all columns of a unique index, provided
that you use at least one equality condition. That is, you can perform a dynamic load
where some columns of the unique index are NULL. The unique index must be created on
the root table of the cache group.
Note:
Dynamic loading based on a primary key search of the root table performs faster
than primary key searches on a child table or foreign key searches on a child table.
The dynamic load runs in a different transaction than the user transaction that triggers the
dynamic load. The dynamic load transaction is committed before the SQL statement that
triggers the dynamic load has finished processing. Thus, if the user transaction is rolled back,
the dynamically loaded data remains in the cache group.
Note:
If the Oracle database is down, the following error is returned:
5219: Temporary Oracle connection failure error in OCISessionBegin():
ORA-01034: ORACLE not available
The following sections describes dynamic load for cache groups:

• Enabling or Disabling Dynamic Load
5-21
Chapter 5
• Guidelines for Dynamic Load

• Examples of Dynamic Load of a Single Cache Instance
• Dynamically Loading Multiple Cache Instances
• Returning Errors for Dynamic Load
Enabling or Disabling Dynamic Load

You can enable or disable dynamic load with the DynamicLoadEnable connection
attribute.
• 0 - Disables dynamic load of Oracle Database data to a single dynamic cache
group for the current connection.
• 1 (default) - Enables dynamic load of Oracle Database data to a single dynamic
cache group per statement for the current connection.
You can set the DynamicLoadEnable optimizer hint to temporarily enable or disable
dynamic loading of a single cache instance for a particular transaction. You can set the
DynamicLoadEnable optimizer hint with one of the following methods:
• Use the ttIsql utility set dynamicloadenable command.

• Call the ttOptSetFlag built-in procedure with the DynamicLoadEnable flag set to
the desired value. The following example sets dynamic loading to 1.
call ttOptSetFlag('DynamicLoadEnable', 1)
Note:
See DynamicLoadEnable, ttIsql or ttOptSetFlag in the Oracle TimesTen In-
You can also set connection attributes with the SQLSetConnectOption ODBC
function (ODBC 2.5) or the SQLSetConnectAttr function (ODBC 3.5). See
the Option Support for ODBC 2.5 SQLSetConnectOption and
SQLGetConnectOption and Attribute Support for ODBC 3.5
SQLSetConnectAttr and SQLGetConnectAttr sections in the Oracle
TimesTen In-Memory Database C Developer's Guide.
Guidelines for Dynamic Load

This section details the guidelines for a dynamic load to occur of cache instances for
each cache group referenced in the main query.
Note:
Examples for these guidelines are provided in Examples of Dynamic Load of
a Single Cache Instance.
5-22
Chapter 5
Dynamic load of a cache instance is available only for the following types of statements
issued on a cache table in a dynamic cache group:
• When an INSERT statement inserts values into any of the child tables of a cache instance
that does not currently exist in the TimesTen tables, the cache instance to which the new
row belongs dynamically loads. The insert operation for the new child row is propagated
to the cached Oracle Database table.
• SELECT, UPDATE, or DELETE statements require that the WHERE clause have the conditions
as stated in Dynamic Cache Groups.
The SELECT, UPDATE, or DELETE statements for which dynamic load is available must satisfy
the following conditions:
• If the statement contains a subquery, only the cache group with tables referenced in the
main query are considered for a dynamic load.
• If the statement references multiple tables of the cache group, the statement must
include an equality join condition between the primary keys and foreign keys for all parent
and child relationships.
• The statement cannot contain the UNION, INTERSECT, or MINUS set operators.
• The statement can reference non-cache tables.
• The statement can reference cache tables from only one dynamic cache group.
Dynamic load of a cache instance occurs when you set DynamicLoadEnable=1 and the
request passes the following rules:
• Dynamic load of a cache instance does not occur for a cache group if any table of the
cache group is specified more than once in any FROM clause.
• Only the conditions specified in the query are considered for dynamic load, which
excludes any derived conditions.
• If any cache group is referenced only in a subquery, it is not considered for a dynamic
load.
• When using an active standby pair replication scheme, dynamic load cannot occur in any
subscriber.
The following considerations can affect dynamic load:
• If tables within multiple cache groups or non-cache group tables are specified in the main
query, the join order influences if the cache instance is loaded. If during the processing of
the query, a dynamic load is possible and necessary to produce the query results, the
dynamic load occurs. However, if no rows are returned, then some or all of the cache
instances are not dynamically loaded.
• If a statement specifies more than the dynamic load condition on tables of a cache group,
the cache instance may be dynamically loaded even though the additional conditions are
not qualified for the statement.
You can use aging with a dynamic cache group. TimesTen supports two aging types, least
recently used (LRU) aging and time-based aging. By default, the data in a dynamic cache
group is subject to LRU aging. Time-based aging on a dynamic cache group overrides LRU
aging. If the cache group has a time-based aging policy defined, the timestamp in the root
table's row must be within the aging policy's lifetime in order for the cache instance to be
loaded.
Rows in a dynamic AWT cache group must be propagated to the Oracle database before
they become candidates for aging.
5-23
Chapter 5
You can use the ttAgingLRUConfig built-in procedure to override the default or current
LRU aging attribute settings for the aging cycle and TimesTen database space usage
thresholds. See Implementing Aging in a Cache Group for TimesTen Classic.
Examples of Dynamic Load of a Single Cache Instance

Provides an example that defines Oracle database tables, which are then cached into
a dynamic AWT cache group.
The following is the definition of the Oracle Database tables that are to be cached in a
dynamic AWT cache group. The Oracle Database table is owned by the schema user
sales.
name VARCHAR2(50),
CREATE TABLE orders

CREATE TABLE orderdetails

PRIMARY KEY (orderid, itemid));
For example, the following data is in the sales.customer cached Oracle Database
table.
-------- ------- --------------- ---------------------------
1 West Frank Edwards 100 Pine St., Portland OR
2 East Angela Wilkins 356 Olive St., Boston MA
3 Midwest Stephen Johnson 7638 Walker Dr., Chicago IL
The following statement creates a dynamic AWT cache group new_customers that
caches the sales.customer, sales.orders, and sales.orderdetails tables:
CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers
FROM sales.customer
name VARCHAR2(50),
sales.orders
FOREIGN KEY(cust_num) REFERENCES sales.customer(cust_num)),
sales.orderdetails
5-24
Chapter 5

PRIMARY KEY(orderid, itemid),
FOREIGN KEY(orderid) REFERENCES sales.orders(order_num));
The following examples show the default behavior as DynamicLoadEnable defaults to 1:
The sales.customer TimesTen cache table is initially empty:

0 rows found.
The following SELECT statement with an equality condition on the primary key for the
sales.customer table results in a dynamic load of a single cache instance:
Command> SELECT * FROM sales.customer WHERE cust_num = 1;
< 1, West, Frank Edwards, 100 Pine St., Portland OR >
If you do not use an equality condition on the primary key and you do not configure for
dynamic load of multiple cache instances, then no dynamic load occurs for this example,
since it would result in multiple cache instances. See Dynamically Loading Multiple Cache
Instances for details on how to configure for this scenario.
Command> SELECT * FROM sales.customer WHERE cust_num IN (1,2);
The following example contains equality expressions on all of the primary key columns for a
primary key composite. The orderdetails table has a composite primary key of orderid and
itemid.
UPDATE sales.orderdetails SET quantity = 5 WHERE orderid=2280 AND itemid=663;
The following example shows an INSERT into the orders child table, which initiates a dynamic
load. However, if you tried to insert into the customer table, which is the parent, no dynamic
load occurs.
INSERT INTO orders VALUES(1,1, DATE '2012-01-25', DATE '2012-01-30');
The following UPDATE statement dynamically loads one cache instance from the cached
Oracle Database table into the TimesTen cache table, updates the instance in the cache
table, and then automatically propagates the update to the cached Oracle Database table:
Command> UPDATE sales.customer SET name = 'Angela Peterson' WHERE cust_num = 2;
< 2, East, Angela Peterson, 356 Olive St., Boston MA >
The following is the updated data in the sales.customer cached Oracle Database table:
-------- ------- --------------- ---------------------------
2 East Angela Peterson 356 Olive St., Boston MA
3 Midwest Stephen Johnson 7638 Walker Dr., Chicago IL
The following DELETE statement dynamically loads one cache instance from the cached
Oracle Database table into the TimesTen cache table, deletes the instance from the cache
table, and then automatically propagates the delete to the cached Oracle Database table:
Command> DELETE FROM sales.customer WHERE cust_num = 3;
5-25
Chapter 5

< 2, East, Angela Peterson, 356 Olive St., Boston MA >
The following is the updated data in the sales.customer cached Oracle Database
table.
-------- ------- --------------- ---------------------------
2 East Angela Peterson 356 Olive St., Boston MA
The following is an example of a dynamic load performed using all columns of a

unique index on the root table. The departments table is defined in a dynamic AWT
cache group. A unique index is created on this cache group consisting of the
manager_id and location_id.
The following creates the departments table on the Oracle database.

Command> CREATE TABLE departments(
department_id INT NOT NULL PRIMARY KEY,
department_name VARCHAR(10) NOT NULL,
technical_lead INT NOT NULL,
manager_id INT,
location_id INT NOT NULL);
The following creates the dynamic AWT cache group and a unique index on the
dept_cg root table:
Command> CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP dept_cg
FROM departments
(department_id INT NOT NULL PRIMARY KEY,
department_name VARCHAR(10) NOT NULL,
technical_lead INT NOT NULL,
manager_id INT, location_id INT NOT NULL);
Command> CREATE UNIQUE INDEX dept_idx

ON departments
(manager_id,
location_id);
The following inserts three records into the departments table on the Oracle database:
Command> INSERT INTO departments
VALUES (1, 'acct', 1, 1, 100);
1 row inserted.
VALUES (2, 'hr', 2, 2, 200);
1 row inserted.
VALUES (3, 'owner', 3, NULL, 300);
1 row inserted.
Command> commit;
On TimesTen, dynamically load a cache instance based on the unique index:

Command> SELECT * FROM departments;
0 rows found.
Command> SELECT * FROM departments
WHERE manager_id IS NULL AND location_id=300;
< 3, owner, 3, <NULL>, 300 >
1 row found.
5-26
Chapter 5

< 3, owner, 3, <NULL>, 300 >
1 row found.
Command> SELECT * FROM departments
WHERE manager_id=2 AND location_id=200;
< 2, legal, 2, 2, 200 >
1 row found.
< 2, legal, 2, 2, 200 >
< 3, owner, 3, <NULL>, 300 >
2 rows found.
Dynamically Loading Multiple Cache Instances

If configured, TimesTen can dynamically load multiple cache instances for dynamic cache
groups that contain only a single table.
TimesTen Classic dynamically loads cache instances associated with a primary key that do
not already exist in the cache group. Any cache instances associated with a primary key that
already exist in the cache group are not reloaded. As a result, your query may return partial
results. If a cache instance already exists on TimesTen, these cache instances can only be
updated with either an autorefresh operation or a REFRESH CACHE GROUP statement.
The following sections describe methods for dynamically loading multiple cache instances:
• Dynamically Loading Multiple Cache Instances With Multiple Primary Keys
• Dynamically Loading Multiple Cache Instances Without Multiple Primary Keys
Dynamically Loading Multiple Cache Instances With Multiple Primary Keys

TimesTen Classic can dynamically load multiple cache instances for a SELECT statement that
includes more than one primary key referenced in the WHERE clause on a single table cache
group.
You can dynamically load multiple cache instances by specifying multiple primary key values
in the WHERE clause.
• Only supported with SELECT statements.

• Only supported on a single table cache group.
• For a multiple column primary key, all columns of the primary key must be specified in the
WHERE clause.
• Each primary key in the WHERE clause must use conditions with either an IN operator
and/or a single value from an equality condition.
By default, the DynamicLoadMultiplePKs or TT_DynamicLoadMultiplePKs statement,
transaction or connection level hint is set to 1. This must be enabled for dynamic load for
multiple cache instances using more than one primary key.
• Statement level hint:
/*+TT_DynamicLoadMultiplePKs(1)*/
• Transaction level hint:

Call ttOptSetFlag(DynamicLoadMultiplePKs, 1)
• Connection level hint:
5-27
Chapter 5
OptimizerHint = TT_DynamicLoadMultiplePKs(1)
Note:
See Use Optimizer Hints to Modify the Execution Plan in the Oracle
TimesTen In-Memory Database Operations Guide, ttOptSetFlag in the
Oracle TimesTen In-Memory Database Reference and Optimizer Hints in the
Oracle TimesTen In-Memory Database SQL Reference.
The following examples use a cache group of products_cg that caches the Oracle
database products table.
CREATE DYNAMIC READONLY CACHE GROUP products_cg FROM
products(prod_type INT NOT NULL, prod_id BIGINT NOT NULL, prod_name
VARCHAR2(100),
prod_weight NUMBER, PRIMARY KEY(prod_type, prod_id));
The following examples demonstrate SELECT statements with a WHERE clause with
multiple primary keys that use conditions with either an IN operator and/or a single
value from an equality condition to return the name and weight of multiple products.
If the primary key of a root table is composed of two columns, x and y, the following
SELECT queries do result in a dynamic load:
• Both columns of the primary key use a condition with an IN operator.

(x,y) IN ((1,2),(3,4))
SELECT p.prod_name, p.prod_weight
FROM products p
WHERE (((prod_type, p.prod_id) IN ((1,2), (10,20) , (100, 200))));
• Both columns of the primary key use conditions with an IN operator.

(x IN (1,3)) AND (y IN (2,4))
FROM products p WHERE ((p.prod_type IN (1, 10, 100)) AND (p.prod_id IN (2,
20, 200)));
• Both columns of the primary key use conditions with an equality condition resulting
in a single value.
(x=1 OR x=3) AND (y=2 OR y=4)
FROM products p WHERE ((p.prod_type = 10 OR p.prod_type=100) AND
(p.prod_id = 20 OR p.prod_id = 200));
Dynamically Loading Multiple Cache Instances Without Multiple Primary Keys

TimesTen Classic can dynamically load multiple cache instances without using multiple
primary keys referenced in a WHERE clause on a single table cache group.
If the query tries to load cache instances that both exist and do not exist in the
database, then the entire dynamic load operation does not execute. The dynamic load
only executes if none of the cache instances requested already exist in the TimesTen
database.
5-28
Chapter 5
By default, TimesTen Classic does not dynamically load multiple cache instances for a single
table cache group when the SELECT statement has an arbitrary WHERE clause, unless you set
one of the following statement, transaction or connection level hints to 1.
• Statement level hint:
/*+TT_DynamicLoadRootTbl (1)*/
• Transaction level hint:

Call ttOptSetFlag(DynamicLoadRootTbl , 1)
• Connection level hint:

OptimizerHint = TT_DynamicLoadRootTbl (1)
Note:
See Use Optimizer Hints to Modify the Execution Plan in the Oracle TimesTen In-
Memory Database Operations Guide, ttOptSetFlag in the Oracle TimesTen In-
Memory Database Reference and Optimizer Hints in the Oracle TimesTen In-
Memory Database SQL Reference.
Restrictions for dynamic load of multiple cache instances with arbitrary WHERE clause
In order for a dynamic load of multiple cache instances for a single table cache group, the
SELECT statement query must comply with the following:
• The results of the WHERE clause do not include any cache instances that currently exist in
the TimesTen database.
• The WHERE clause must be supported by the Oracle Database SQL syntax.
• Does not qualify for any other dynamic load condition.
• Does not use aggregation.
• No other table is referenced within the query. That is, the SELECT statement does not
specify any JOIN clauses or any subqueries embedded within the WHERE clause.
• Does not use the SELECT...FOR UPDATE clause or the INSERT … FOR SELECT clause.
Examples
These examples use the following cache group definition on the TimesTen database:
CREATE DYNAMIC READONLY CACHE GROUP cust_orders FROM
customers(cust_id BIGINT NOT NULL PRIMARY KEY, cust_name VARCHAR2(100),
cust_street VARCHAR2(200), cust_state VARCHAR2(2), cust_zip VARCHAR2(10))
WHERE (customers.cust_state = 'CA');
Data is inserted into the Oracle database.

INSERT INTO customers(cust_id, cust_name, cust_street, cust_state, cust_zip)
VALUES (100, 'Tom Hanks', '100 Rodeo Dr', 'CA', '90210');
VALUES (200, 'Fred Rogers', '1 Make-Believe Ave', 'CA', '90210');
5-29
Chapter 5
None of the requested customers are in the cache group on the TimesTen database;
thus, all of the requested customers (and their orders) are dynamically loaded and
their names are returned by the query.
SELECT c.cust_name
FROM customers c
WHERE (c.cust_zip like '90210%');
<'Tom Hanks'>
<'Fred Rogers'>
Another customer and full data is inserted into the Oracle database:
VALUES (300, 'Matthew Rhys', '2 Moscow Cir', 'CA', '90210');
On the TimesTen database, the following query is executed. Since the cache group
already has at least 1 row that satisfies the query, the dynamic load is not triggered.
Thus, only data that currently exists in the cache group are returned for the query.
SELECT c.cust_name
FROM customers c
WHERE (c.cust_zip like '90210%');
<'Tom Hanks'>
<'Fred Rogers'>
Returning Errors for Dynamic Load

You can configure TimesTen to return an error if a SELECT, UPDATE or DELETE statement
does not meet the requirements.
See Guidelines for Dynamic Load for requirements of a dynamic load.
The DynamicLoadErrorMode connection attribute controls what happens when an
application runs a SQL operation against a dynamic cache group and the SQL
operation cannot use dynamic load in a particular connection.
• When DynamicLoadErrorMode is set to a value of 0, dynamic load happens to any
cache group referenced in the query that is qualified for dynamic load. Cache
groups that do not qualify are not dynamically loaded and no errors are returned.
When DynamicLoadEnable=1, no dynamic load occurs if the query references more
than one cache group.
• When DynamicLoadErrorMode is set to a value of 1, a query fails with an error if
any dynamic cache group referenced in the query is not qualified for dynamic load.
The error indicates the reason why the dynamic load cannot occur.
To set the connection attribute solely for a particular transaction, use one of the
following:
• Use the ttIsql utility set dynamicloaderrormode 1 command.
• Call the ttOptSetFlag built-in procedure with the DynamicLoadErrorMode flag and
the optimizer value set to 1.
call ttOptSetFlag('DynamicLoadErrorMode', 1)
Call the ttOptSetFlag built-in procedure with the DynamicLoadErrorMode flag and
the optimizer value set to 0 to suppress error reporting when a statement does not
comply with dynamic load requirements.
5-30
Chapter 5
Determining the Number of Cache Instances Affected by an Operation
Determining the Number of Cache Instances Affected by an

Operation
You can use mechanisms to determine how many cache instances were loaded by a LOAD
CACHE GROUP statement, refreshed by a REFRESH CACHE GROUP statement, flushed by a FLUSH
CACHE GROUP statement, or unloaded by an UNLOAD CACHE GROUP statement.
• Call the SQLRowCount() ODBC function.

• Invoke the Statement.getUpdateCount() JDBC method.
• Call the OCIAttrGet() OCI function with the OCI_ATTR_ROW_COUNT option.
Setting a Passthrough Level

When an application issues SQL statements on a TimesTen connection, the SQL statement
can be performed in the TimesTen database or passed through to the Oracle database to be
performed. Whether the SQL statement is performed in the TimesTen or Oracle database
depends on the composition of the statement and the setting of the PassThrough connection
attribute.
You can set the PassThrough connection attribute to define which statements are to be
performed locally in TimesTen and which are to be redirected to the Oracle database for
processing.
The passthrough level can be set at any time and takes effect immediately. The value can be
set to 0 through 3. When appropriate within passthrough levels 1 through 3, TimesTen
connects to the Oracle database using the current user's credentials as the user name and
the OraclePwd connection attribute as the Oracle password.
Passing through update operations to the Oracle database for processing is not
recommended when issued on cache tables in an AWT or SWT cache group. See
Considerations for Using Passthrough.
Note:
A transaction that contains operations that are replicated with RETURN TWOSAFE
cannot have a PassThrough setting greater than 0. If PassThrough is greater than 0,
an error is returned and the transaction must be rolled back.
When PassThrough is set to 0, 1, or 2, the following behavior occurs when a
dynamic load condition exists:
• A dynamic load can occur for a SELECT operation on cache tables in any
dynamic cache group type.
• A dynamic load for an INSERT, UPDATE, or DELETE operation can only occur on
cached tables with dynamic AWT or SWT cache groups.
The following sections describe the different passthrough options:
5-31
Chapter 5
• PassThrough=0
• PassThrough=1
• PassThrough=2
• PassThrough=3
• Considerations for Using Passthrough
• Changing the Passthrough Level for a Connection or Transaction
• Automatic Passthrough of Dynamic Load to the Oracle Database
PassThrough=0
PassThrough=0 is the default setting and specifies that all SQL statements are to be
performed in the TimesTen database.
Figure 5-1 shows that Table A is updated on the TimesTen database. Table F cannot
be updated because it does not exist in TimesTen.
Figure 5-1 PassThrough=0
Application
Update Table A
Update Table F
PassThrough = 0
Update Table A Update Table F

Fails because
table F does not
A exist in the
TimesTen
TimesTen database
database B C
D Updatable
cache group
Oracle
database
B
A
F
E G
PassThrough=1
PassThrough=1 specifies that all DDL are run on TimesTen and most SQL statements
are run on TimesTen unless the tables referenced only exist on the Oracle database or
the SQL statement can only be parsed or understood on the Oracle database.
5-32
Chapter 5
Set PassThrough=1 to specify that:
• DDL statements are always executed on TimesTen.

• INSERT, UPDATE and DELETE statements are run on TimesTen unless they reference one
or more tables that do not exist in TimesTen. If they reference one or more tables that do
not exist in TimesTen, then these statements are passed through to run on the Oracle
database.
• If SQL statements generate a syntax error in TimesTen, include keywords that do not
exist in TimesTen SQL, or if one or more tables referenced within the statement do not
exist in TimesTen, then these statements are passed through to run on the Oracle
database.
• If TimesTen cannot parse INSERT, UPDATE or DELETE statements, TimesTen returns an
error and the statement is not passed through to the Oracle database.
Figure 5-2 shows that Table A is updated in the TimesTen database, while Table G is updated
in the Oracle database because Table G does not exist in the TimesTen database.
Application
Update Table A
Update Table G
PassThrough = 1
Update Table A Update Table G
TimesTen
B C Statement passed
database through to Oracle
D for execution
Updatable because table G
cache group does not exist in
TimesTen database
Oracle
database
B
A
F
E G
PassThrough=2
PassThrough=2 specifies that INSERT, UPDATE and DELETE statements performed on tables in
read-only cache groups or user managed cache groups with the READONLY cache table
attribute are passed through to the Oracle database.
5-33
Chapter 5
Passthrough=1 behavior applies for all other operations and cache group types.
Note:
You are responsible in preventing conflicts that may occur if you update the
same row in a cache table in TimesTen as another user updates the cached
Oracle Database table concurrently.
Figure 5-3 shows that updates to Table A and Table G in a read-only cache group are
passed through to the Oracle database.
Application
Update Table A
Update Table G
PassThrough = 2
Update Table A Update Table G
TimesTen database
A
B C
INSERT, UPDATE and DELETE statements
D Read-only
are passed through to the Oracle
cache group database for read-only cache groups and
read-only cache tables. SELECT statements
are executed in TimesTen unless they
Oracle contain invalid TimesTen syntax or
reference tables that do not exist in TimesTen.
database
B
A
F
E G
PassThrough=3
PassThrough=3 specifies that all statements are passed through to the Oracle
database for processing.
Figure 5-4 shows that Table A is updated on the Oracle database for a read-only or
updatable cache group. A SELECT statement that references Table G is also passed
through to the Oracle database.
5-34
Chapter 5
Application
Update Table A
Select from Table G
PassThrough = 3
Update Table A Select from Table G
TimesTen database
A
B C Statements are passed

D through to the Oracle database
Updatable or Read-only
cache group for read-only and updatable cache
groups.
Oracle
database
B
A
F
E G
Considerations for Using Passthrough

Passing through update operations to the Oracle database for processing is not
recommended when issued on cache tables in an AWT or SWT cache group.
• Committed changes on cache tables in an AWT cache group are automatically
propagated to the cached Oracle Database tables in asynchronous fashion. However,
passing through an update operation to the Oracle database for processing within the
same transaction as the update on the cache table in the AWT cache group renders the
propagate of the cache table update synchronous, which may have undesired results.
• Committed changes on cache tables in an SWT cache group can result in self-deadlocks
if, within the same transaction, updates on the same tables are passed through to the
Oracle database for processing.
A PL/SQL block cannot be passed through to the Oracle database for processing. Also, you
cannot pass through to Oracle Database for processing a reference to a stored procedure or
function that is defined in the Oracle database but not in the TimesTen database.
For more information about how the PassThrough connection attribute setting determines
which statements are performed in the TimesTen database and which are passed through to
the Oracle database for processing and under what circumstances, see PassThrough in
Oracle TimesTen In-Memory Database Reference.
5-35
Chapter 5
Note:
The passthrough feature uses OCI to communicate with the Oracle
database. The OCI diagnostic framework installs signal handlers that may
impact signal handling that you use in your application. You can disable OCI
signal handling by setting DIAG_SIGHANDLER_ENABLED=FALSE in the
sqlnet.ora file. Refer to Fault Diagnosability in OCI in Oracle Call Interface
Programmer's Guide.
Changing the Passthrough Level for a Connection or Transaction

You can override the current passthrough level using the ttIsql utility's set
passthrough command which applies to the current transaction.
You can also override the setting for a specific transaction by calling the ttOptSetFlag
built-in procedure with the PassThrough flag. The following procedure call sets the
passthrough level to 3:
CALL ttOptSetFlag('PassThrough', 3);
The PassThrough flag setting takes effect when a statement is prepared and it is the
setting that is used when the statement is performed even if the setting has changed
from the time the statement was prepared to when the statement is performed. After
the transaction has been committed or rolled back, the original connection setting
takes effect for all subsequently prepared statements.
Automatic Passthrough of Dynamic Load to the Oracle Database

Set the TT_DynamicPassthrough optimizer hint to notify TimesTen Classic to pass
through qualified SELECT statements to the Oracle database for cache groups created
without a WHERE clause.
When an application issues statements on a TimesTen connection, the statement can

be executed in the TimesTen database or passed through to the Oracle database for
resolution. If passed through to the Oracle database, the results are returned but the
cache instance is not loaded. Whether the statement is executed on the TimesTen or
Oracle databases depends on the composition of the statement and the setting of the
PassThrough connection attribute.
In TimesTen Classic, for cache groups that are created without a WHERE clause, you
can limit the number of rows that are dynamically loaded from the Oracle database
into the cache instance. You can set the TT_DynamicPassthrough(N) optimizer hint,
where N is the limit to the number of rows allowed to load into the cache instance. If
any SELECT statement to the Oracle database would return a result with > N number of
rows, then the statement is passed through to the Oracle database and the results are
not loaded into the cache instance.
By default, the SELECT statement for a dynamic load of a cache group that qualifies for
dynamic load is executed on the TimesTen Classic database and all rows of the cache
instances are loaded. In addition, if you provide the optimizer hint and set N=0, then all
rows are loaded into the cache instance on the TimesTen Classic database.
This optimizer hint is supported as connection and statement level hints.
5-36
Chapter 5
Statement level hint:

/*+TT_DynamicPassThrough (1)*/
Connection level hint:

OptimizerHint = TT_DynamicPassThrough (1)
The following example is a statement level optimizer hint requesting a dynamic passthrough
of a SELECT statement to the Oracle database if a dynamic load returns 1000 rows or more for
the SELECT statement.
SELECT /*+ TT_DynamicPassThrough(1000)*/ ...
See Setting a Passthrough Level.

See Optimizer Hints in the Oracle TimesTen In-Memory Database SQL Reference and Use
Optimizer Hints to Modify the Execution Plan in the Oracle TimesTen In-Memory Database
Operations Guide.
5-37
6
Managing a Caching Environment
You can manage and monitor various aspects of a caching system such as cache groups and
the cache agent process.
• Checking the Status of Cache and Replication Agents
• Cache Agent and Replication Connection Recovery
• Managing a Cache Environment With Oracle Database Objects
• Monitoring Cache Groups
• Dropping Oracle Database Objects Used by Cache Groups With Autorefresh
• Impact on Cache Groups When Modifying the Oracle Database Schema
• Impact of Failed Autorefresh Operations on TimesTen Databases
• Managing the Cache Administration User's Tablespace
• Backing Up and Restoring a TimesTen Classic Database With Cache Groups
• Changing Cache User Names and Passwords
Checking the Status of Cache and Replication Agents

You can check the status of cache and replication agents.
• Checking the Status of the Cache Agents in TimesTen Scaleout
• Checking the Status of the Cache and Replication Agents in TimesTen Classic
Checking the Status of the Cache Agents in TimesTen Scaleout

In TimesTen Scaleout, you can use the ttGridAdmin dbStatus -all command to check
whether the TimesTen cache agent processes are running.
See Monitoring the Status of the Cache Agent Processes in the Oracle TimesTen In-Memory
The following example shows that the cache agent processes are stopped with the CA
Status column.
% ttGridAdmin dbStatus -all
Database database1 summary status as of Mon Dec 7 09:36:43 PST 2020
created,loaded-complete,open
Completely created elements: 6 (of 6)
Completely loaded elements: 6 (of 6)
Completely created replica sets: 3 (of 3)
Completely loaded replica sets: 3 (of 3)
Open elements: 6 (of 6)
Database database1 element level status as of Mon Dec 7 09:36:43 PST 2020
6-1
Chapter 6
Checking the Status of Cache and Replication Agents
Host Instance Elem Status CA Status Date/Time of Event Message

----- --------- ---- ------ --------- ------------------- -------
host3 instance1 1 opened stopped 2020-11-23 08:37:35
Database database1 Replica Set status as of Mon Dec 7 09:36:43 PST 2020
RS DS Elem Host Instance Status Date/Time of Event Message

-- -- ---- ----- --------- ------ ------------------- -------
1 1 1 host3 instance1 opened 2020-11-23 08:37:35
Database database1 Data Space Group status as of Mon Dec 7 09:36:43 PST 2020
DS RS Elem Host Instance Status Date/Time of Event Message

-- -- ---- ----- --------- ------ ------------------- -------
Checking the Status of the Cache and Replication Agents in TimesTen

Classic
In TimesTen Classic, you can use either the ttAdmin or ttStatus utility to check
whether the cache agent and replication agent processes are running as well as
determine each agent's start policy.
You can use a ttAdmin -query command to determine the status of the cache and
replication agents, as well as the cache and replication agent start policies for a
TimesTen database:
% ttAdmin -query cache1
RAM Residence Policy : inUse
Replication Agent Policy : manual
Replication Manually Started : True
Cache Agent Policy : always
Cache Agent Manually Started : True
See ttAdmin in Oracle TimesTen In-Memory Database Reference.

Using the ttStatus utility without any commands shows all status information for
cache and replication for all TimesTen instances:
% ttStatus
TimesTen status report as of Thu May 7 13:42:01 2009
Daemon pid 9818 port 4173 instance myinst
6-2
Chapter 6
Cache Agent and Replication Connection Recovery
TimesTen server pid 9826 started on port 4175

------------------------------------------------------------------------
Data store /users/OracleCache/ttcache
There are 38 connections to the data store
Shared Memory KEY 0x02011c82 ID 895844354
PL/SQL Memory KEY 0x03011c82 ID 895877123 Address 0x10000000
Type PID Context Connection Name ConnID
Cache Agent 1019 0x0828f840 Handler 2
Cache Agent 1019 0x083a3d40 Timer 3
Cache Agent 1019 0x0842d820 Aging 4
Cache Agent 1019 0x08664fd8 Garbage Collector(-1580741728) 5
Cache Agent 1019 0x084d6ef8 Marker(-1580213344) 6
Cache Agent 1019 0xa5bb8058 DeadDsMonitor(-1579684960) 7
Replication 18051 0x08c3d900 RECEIVER 8
Replication 18051 0x08b53298 REPHOLD 9
Replication 18051 0x08af8138 REPLISTENER 10
Replication 18051 0x08a82f20 LOGFORCE 11
Replication 18051 0x08bce660 TRANSMITTER 12
Subdaemon 9822 0x080a2180 Manager 2032
Subdaemon 9822 0x080ff260 Rollback 2033
Subdaemon 9822 0x08548c38 Flusher 2034
Subdaemon 9822 0x085e3b00 Monitor 2035
Subdaemon 9822 0x0828fc10 Deadlock Detector 2036
Subdaemon 9822 0x082ead70 Checkpoint 2037
Subdaemon 9822 0x08345ed0 Aging 2038
Subdaemon 9822 0x083a1030 Log Marker 2039
Subdaemon 9822 0x083fc190 AsyncMV 2040
Subdaemon 9822 0x084572f0 HistGC 2041
Replication policy : Manual
Replication agent is running.
Cache Agent policy : Always
TimesTen's Cache agent is running for this data store
PL/SQL enabled.
------------------------------------------------------------------------
The information displayed by the ttStatus utility include the following that pertains to
TimesTen for each TimesTen instance:
• The names of the cache agent process threads that are connected to the TimesTen
database
• The names of the replication agent process threads that are connected to the TimesTen
database
• Status on whether the cache agent is running
• Status on whether the replication agent is running
• The cache agent start policy
• The replication agent start policy
See ttStatus in Oracle TimesTen In-Memory Database Reference.
Cache Agent and Replication Connection Recovery

When a connection from the cache agent to the Oracle database fails, the cache agent
attempts to connect every 10 seconds. If the cache agent cannot connect to the Oracle
database, the cache agent restarts after 10 minutes. This behavior repeats forever.
6-3
Chapter 6
Managing a Cache Environment With Oracle Database Objects
When a connection from the replication agent to the Oracle database fails, the
replication agent attempts to reconnect to the Oracle database after 120 seconds. If it
cannot reconnect after 120 seconds, the replication agent stops and does not restart.
If Fast Application Notification (FAN) is enabled on the Oracle database, the cache
agent and the replication agent receive immediate notification of connection failures. If
FAN is not enabled, the agents may wait until a TCP timeout occurs before becoming
aware that the connection has failed.
If the Oracle Real Application Clusters (Oracle RAC) is enable on the Oracle
database, along with FAN and Transparent Application Failover (TAF), then TAF
manages the connection to a new Oracle Database instance. See Using Cache in an
Oracle RAC Environment.
Managing a Cache Environment With Oracle Database

Objects
For a cache group with autorefresh, TimesTen creates a change log table and two
triggers in the Oracle database for each cache table in the cache group. One trigger is
fired for each INSERT statement and another trigger is fired for each UPDATE or DELETE
statement on the cached Oracle Database table.
These triggers record the primary key of the changed rows in the change log table.
The cache agent periodically scans the change log table for modified keys and then
joins this table with the cached Oracle Database table to get a snapshot of the latest
changes.
Note:
If you cache the same Oracle database table in a cache group on two
different TimesTen databases, we recommend that you use the same cache
administration user name on both TimesTen databases as the owner of the
cache table on each TimesTen database. See Caching the Same Oracle
Table on Two or More TimesTen Databases.
For each cache administration user, TimesTen creates the following Oracle Database
tables, where version is an internal TimesTen version number and object-ID is the ID
of the cached Oracle Database table:
Table Name Description

TT_version_AGENT_STATUS Created when the first cache group is created.
Stores information about each Oracle
Database table cached in a cache group with
autorefresh.
TT_version_AR_PARAMS Created when the cache administration user
name and password is set. Stores the action to
take when the cache administration user's
tablespace is full.
6-4
Chapter 6
Managing a Cache Environment With Oracle Database Objects

TT_version_ARDL_CG_COUNTER Created when you execute either the
grantCacheAdminPrivileges.sql or the
initCacheAdminSchema.sql scripts or
when the cache administration user and
password are set. Contains information used
for reducing contention for dynamic read-only
cache groups with incremental autorefresh.
See Reducing Contention for Dynamic Read-
Only Cache Groups With Incremental
Autorefresh.
TT_version_CACHE_STATS Created when the cache administration user
name and password is set.
TT_version_CACHED_COLUMNS Stores list of columns that are cached.
Created when you run the
initCacheAdminSchema.sql script or when
you set the cache administration user and
password.
TT_version_DATABASES Created when the cache administration user
name and password is set. Stores the
autorefresh status for all TimesTen databases
that cache data from the Oracle database.
TT_version_DB_PARAMS Created when the cache administration user
name and password is set. Stores the cache
agent timeout, recovery method for dead
cache groups, and the cache administration
user's tablespace usage threshold.
TT_version_DBSPECIFIC_PARAMS Internal use.
TT_version_DDL_L Created when the cache administration user
name and password is set. Tracks DDL
statements issued on cached Oracle Database
tables.
TT_version_DDL_TRACKING Created when the cache administration user
name and password is set. Stores a flag
indicating whether tracking of DDL statements
on cached Oracle Database tables is enabled
or disabled.
TT_version_LOG_SPACE_STATS Created when the cache administration user
and password are set. Contains statistics used
to monitor the cache administration user table
space. See Managing the Cache
Administration User's Tablespace.
TT_version_REPACTIVESTANDBY Created when the first AWT cache group is
created. Tracks the state and roles of
TimesTen databases containing cache tables
in an AWT cache group that are replicated in
an active standby pair replication scheme.
TT_version_REPPEERS Created when the first AWT cache group is
created. Tracks the time and commit sequence
number of the last update on the cache tables
that was asynchronously propagated to the
TT_version_SYNC_OBJS Created when the first cache group is created.
6-5
Chapter 6
Monitoring Cache Groups

TT_version_USER_COUNT Created when the first cache group is created.
Stores information about each cached Oracle
Database table.
TT_version_object-ID_L One change log table is created per Oracle
autorefresh when the cache group is created.
Tracks updates on the cached Oracle
Database table.
For each cache administration user, TimesTen creates the following Oracle Database
triggers, where version is an internal TimesTen version number, object-ID is the ID of
the cached Oracle Database table, and schema-ID is the ID of user who owns the
cached Oracle Database table:
Trigger Name Description

TT_version_REPACTIVESTANDBY_T Created when the first AWT cache group is
created. When fired, inserts rows into the
TT_version_REPACTIVESTANDBY table.
TT_version_object-ID_T This trigger is created for each Oracle
autorefresh when the cache group is created.
Fires for each update or delete operation
issued on the cached Oracle Database table to
track operations in the TT_version_object-
ID_L change log table.
TT_version_object-ID_TI This trigger is created for all autorefreshed
cached tables, except for autorefreshed
cached tables that are exclusively cached as
root tables in dynamic read-only cache groups.
Fires for each insert operation issued on the
cached Oracle Database table to track
operations in the TT_version_object-ID_L
change log table.
TT_version_schema-ID_DDL_T One trigger for each user who owns cached
Oracle Database tables. Created when a
cache group is created after tracking of DDL
statements has been enabled. Fired for each
DDL statement issued on a cached Oracle
Database table to track operations in the
TT_version_DDL_L table.

You can obtain information on cache groups and monitor the status of cache group
operations.
• Using the ttIsql Utility cachegroups Command
• Monitoring Autorefresh Operations on Cache Groups
• Monitoring AWT Cache Groups
• Configuring a Transaction Log File Threshold for AWT Cache Groups
6-6
Chapter 6
• Tracking DDL Statements Issued on Cached Oracle Database Tables
Using the ttIsql Utility cachegroups Command

You can obtain information about cache groups in a TimesTen database using the ttIsql
utility cachegroups command.
Command> cachegroups;
Cache Group CACHEADMIN.RECENT_SHIPPED_ORDERS:
Cache Group Type: Read Only

Autorefresh: Yes
Autorefresh Mode: Incremental
Autorefresh State: On
Autorefresh Interval: 1440 Minutes
Autorefresh Status: ok
Aging: Timestamp based uses column WHEN_SHIPPED lifetime 30 days cycle 24 hours on
Root Table: SALES.ORDERS

Cache Group CACHEADMIN.SUBSCRIBER_ACCOUNTS:
Cache Group Type: Asynchronous Writethrough (Dynamic)

Autorefresh: No
Aging: LRU on
Root Table: SALES.SUBSCRIBER

Cache Group CACHEADMIN.WESTERN_CUSTOMERS:
Cache Group Type: User Managed

Autorefresh: No
Aging: No aging defined
Root Table: SALES.ACTIVE_CUSTOMER

Where Clause: (sales.active_customer.region = 'West')
Child Table: SALES.ORDERTAB

Child Table: SALES.ORDERDETAILS

Where Clause: (sales.orderdetails.quantity >= 5)
Table Type: Not Propagate
Child Table: SALES.CUST_INTERESTS

3 cache groups found.
The information displayed by the ttIsql utility's cachegroups command include:
• Cache group type, including whether the cache group is dynamic

• Autorefresh attributes (mode, state, interval) and status, if applicable
6-7
Chapter 6
• Aging policy, if applicable

• Name of root table and, if applicable, name of child tables
• Cache table WHERE clause, if applicable
• Cache table attributes (read-only, propagate, not propagate)
See ttIsql in Oracle TimesTen In-Memory Database Reference.
Monitoring Autorefresh Operations on Cache Groups

TimesTen offers several mechanisms to obtain information and statistics about
autorefresh operations on cache groups.
See Monitoring Autorefresh Cache Groups in Oracle TimesTen In-Memory Database
Monitoring and Troubleshooting Guide.
Monitoring AWT Cache Groups

TimesTen Classic offers several mechanisms to obtain information and statistics about
operations in AWT cache groups.
See AWT Performance Monitoring in Oracle TimesTen In-Memory Database
Monitoring and Troubleshooting Guide.
Configuring a Transaction Log File Threshold for AWT Cache Groups

In TimesTen Classic, the replication agent uses the transaction log to determine which
updates on cache tables in AWT cache groups have been propagated to the cached
Oracle Database tables and which updates have not. If updates are not being
automatically propagated to the Oracle database because of a failure, transaction log
files accumulate on the file system.
Examples of a failure that prevents propagation are that the replication agent is not
running or the Oracle database server is unavailable. See Monitoring Accumulation of
Transaction Log Files in Oracle TimesTen In-Memory Database Operations Guide.
You can call the ttCacheAWTThresholdSet built-in procedure as the TimesTen cache
administration user to set a threshold for the number of transaction log files that can
accumulate before TimesTen Classic stops tracking updates on cache tables in AWT
cache groups. The default threshold is 0. This built-in procedure can only be called if
the TimesTen database contains AWT cache groups.
After the threshold has been exceeded, you need to manually synchronize the cache
tables with the cached Oracle Database tables using an UNLOAD CACHE GROUP
statement followed by a LOAD CACHE GROUP statement. TimesTen may purge
transaction log files even if they contain updates that have not been propagated to the
The following example sets a transaction log file threshold for AWT cache groups. In
this example, if the number of transaction log files that contain updates on cache
tables in AWT cache groups exceeds 5, TimesTen stops tracking updates and can
then purge transaction log files that may contain unpropagated updates:
Command> CALL ttCacheAWTThresholdSet(5);
6-8
Chapter 6
You can call the ttCacheAWTThresholdGet built-in procedure to determine the current
transaction log file threshold setting:
Command> CALL ttCacheAWTThresholdGet;
< 5 >
Command> exit
Tracking DDL Statements Issued on Cached Oracle Database Tables

When a DDL statement is issued on a cached Oracle Database table, this statement can be
tracked in the Oracle Database TT_version_DDL_L table when the Oracle Database
TT_version_schema-ID_DDL_T trigger is fired to insert a row into the table. The version is an
internal TimesTen version number and schema-ID is the ID of user that owns the cached
Oracle Database table.
A trigger is created for each Oracle Database user that owns cached Oracle Database tables.
One DDL tracking table is created to store DDL statements issued on any cached Oracle
Database table. The Oracle cache administration user owns the TT_version_DDL_L table and
the TT_version_schema-ID_DDL_T trigger.
By default, DDL statements are not tracked. On TimesTen, you can enable tracking of DDL
statements issued on cached Oracle Database tables, call the ttCacheDDLTrackingConfig
built-in procedure as the TimesTen cache administration user. The following example enables
tracking of DDL statements issued on cached Oracle Database tables:
Command> CALL ttCacheDDLTrackingConfig('enable');
The TT_version_DDL_L table and TT_version_schema-ID_DDL_T trigger are automatically

created if the Oracle cache administration user has been granted the set of required
privileges including CREATE TRIGGER, CREATE SEQUENCE, CREATE TYPE, CREATE PROCEDURE,
CREATE TABLE and CREATE ANY TRIGGER. These Oracle Database objects are created when
you create a cache group after tracking of DDL statements has been enabled.
On TimesTen Classic, if you manually created the Oracle Database objects used to manage
the caching of Oracle Database data, you need to run the ttIsql utility cachesqlget
command with the ORACLE_DDL_TRACKING option and the INSTALL flag as the TimesTen cache
administration user. This command should be run for each Oracle Database user that owns
cached Oracle Database tables that you want to track DDL statements on. Running this
command generates a SQL*Plus script used to create the TT_version_DDL_L table and
TT_version_schema-ID_DDL_T trigger in the Oracle database.
After generating the script, use SQL*Plus to run the script as the sys user.
The following example creates DDL tracking table and trigger when Oracle Database objects
are manually created. In this example, the SQL*Plus script generated by the ttIsql utility
cachesqlget command is saved to the /tmp/trackddl.sql file. The owner of the cached
Oracle Database table sales is passed as an argument to the command.
Command> cachesqlget ORACLE_DDL_TRACKING sales INSTALL /tmp/trackddl.sql;
Command> exit

SQL> @/tmp/trackddl
SQL> exit
6-9
Chapter 6
Dropping Oracle Database Objects Used by Cache Groups With Autorefresh
You can run the timesten_home/install/oraclescripts/cacheInfo.sql SQL*Plus

script as the Oracle cache administration user to display information about the Oracle
Database objects used to track DDL statements issued on cached Oracle Database
tables:
% sqlplus cacheadmin/orapwd
SQL> @cacheInfo.sql
***************** Database Information *********************
Database name: DATABASE1
Unique database name: database1
Primary database name:
Database Role: PRIMARY
Database Open Mode: READ WRITE
Database Protection Mode: MAXIMUM PERFORMANCE
Database Protection Level: UNPROTECTED
Database Flashback On: NO
Database Current SCN: 21512609
*************************************************************
*************Autorefresh Objects Information ***************
Grid name: grid1 (7D03C680-BD93-4233-A4CF-B0EDB0064F3F)
Timesten database name: database1
Cache table name: SALES.READTAB
Change log table name: tt_07_96977_L
Number of rows in change log table: 4
Maximum logseq on the change log table: 1
Timesten has autorefreshed updates upto logseq: 1
Number of updates waiting to be autorefreshed: 0
Number of updates that has not been marked with a valid logseq: 0
*************DDL Tracking Object Information ***************
Common DDL Log Table Name: TT_07_DDL_L
DDL Trigger Name: TT_07_315_DDL_T
Schema for which DDL Trigger is tracking: SALES
Number of cache groups using the DDL Trigger: 10
****************************
PL/SQL procedure successfully completed.
The information returned for each Oracle Database user that owns cached Oracle
Database tables includes the name of the DDL tracking table, the name of its
corresponding DDL trigger, the name of the user that the DDL trigger is associated
with, and the number of cache groups that cache a table owned by the user
associated with the DDL trigger.
If a cache group contains more than one cache table, each cache table owned by the
user associated with the DDL trigger contributes to the cache group count.
See SQL*Plus Scripts for Cache in this book and ttCacheDDLTrackingConfig in Oracle
Dropping Oracle Database Objects Used by Cache Groups

With Autorefresh
A TimesTen database is unavailable, for example, when the TimesTen system is taken
offline or the database has been destroyed without dropping its cache groups with
autorefresh.
6-10
Chapter 6
Dropping Oracle Database Objects Used by Cache Groups With Autorefresh
Oracle database objects used to implement autorefresh operations also continue to exist in
the Oracle database when a TimesTen database is no longer being used but still contains
cache groups with autorefresh. Rows continue to accumulate in the change log tables. This
impacts autorefresh performance on other TimesTen databases. Therefore, it is desirable to
drop these Oracle database objects associated with the unavailable or abandoned TimesTen
database.
• When using TimesTen Classic, run the timesten_home/install/oraclescripts/
cacheCleanUp.sql SQL*Plus script as the Oracle cache administration user to drop the
Oracle database objects used to implement autorefresh operations. The host name of the
TimesTen Classic system and the TimesTen database (including its path) are passed as
arguments to the cacheCleanUp.sql script.
You can run the cacheInfo.sql script as the Oracle cache administration user to
determine the host and database names.
• In TimesTen Scaleout, run the timesten_home/install/oraclescripts/
scaleoutCacheCleanUp.sql SQL*Plus script as the Oracle cache administration user to
drop the Oracle Database objects used to implement autorefresh operations. The grid
name and the TimesTen database name are passed as arguments to the
scaleoutCacheCleanUp.sql script.
determine the grid and database names.
The cacheInfo.sql script can also be used to determine whether any objects used to
implement autorefresh operations exist in the Oracle database.
The following example demonstrates how to drop Oracle database objects for cache groups
with autorefresh. In this example, the TimesTen database contains one read-only cache
group customer_orders with cache tables sales.customer and sales.orders.
This example uses the cacheCleanUp.sql script for a TimesTen Classic system. It drops the
change log tables and triggers associated with the two cache tables. The
scaleoutCacheCleanup.sql script runs in the same manner for TimesTen Scaleout, except
that it requires the grid name and database name as input parameters.
SQL> @cacheCleanUp "sys1" "/users/OracleCache/ttcache"
*****************************OUTPUT**************************************
Performing cleanup for object_id: 69959 which belongs to table : CUSTOMER
Executing: delete from tt_07_agent_status where host = sys1 and datastore =
/users/OracleCache/ttcache and object_id = 69959
Executing: drop table tt_07_69959_L
Executing: drop trigger tt_07_69959_T
Executing: delete from tt_07_user_count where object_id = object_id1
Performing cleanup for object_id: 69966 which belongs to table : ORDERS
/users/OracleCache/ttcache and object_id = 69966
**************************************************************************
See SQL*Plus Scripts for Cache.
6-11
Chapter 6
Impact on Cache Groups When Modifying the Oracle Database Schema
Impact on Cache Groups When Modifying the Oracle

Database Schema
When you need to issue DDL statements such as CREATE, DROP or ALTER on cached
Oracle Database tables in order to make changes to the Oracle Database schema,
drop the affected cache groups before you modify the Oracle Database schema.
Otherwise operations such as autorefresh may fail.
You do not need to drop cache groups if you are altering the Oracle Database table to
add a column.
To issue other DDL statements for Oracle Database tables, first perform the following
tasks:
1. Use DROP CACHE GROUP statements to drop all cache groups that cache the
affected Oracle Database tables. If you are dropping an AWT cache group, use
the ttRepSubscriberWait built-in procedure to make sure that all committed
changes on the cache tables have been propagated to the cached Oracle
Database tables before the cache group is dropped.
Command> CALL
ttRepSubscriberWait('_AWTREPSCHEME','TTREP','_ORACLE','sys1',-1);
2. Stop the cache agent.

3. Make the desired changes to the Oracle Database schema.
4. Use CREATE CACHE GROUP statements to re-create the cache groups, if feasible.
If you want to truncate an Oracle Database table that is cached in a cache group with
autorefresh, perform the following tasks:
1. Use an ALTER CACHE GROUP statement to set the cache group's autorefresh state
to PAUSED.
2. Truncate the Oracle Database table.
3. Manually refresh the cache group using a REFRESH CACHE GROUP statement without
a WHERE or WITH ID clause.
Autorefresh operations resume after you refresh the cache group.
Impact of Failed Autorefresh Operations on TimesTen

Databases
TimesTen does not delete rows in the change log tables when the cache agent is not
running on a TimesTen database. In this case, you can set a cache agent timeout to
prevent rows from accumulating in the change log tables.
A change log table is created in the Oracle cache administration user's tablespace for
each Oracle Database table that is cached in a cache group with autorefresh. For
each update operation issued on these cached Oracle Database tables, a row is
inserted into their change log table to keep track of updates that need to be applied to
the TimesTen cache tables upon the next incremental autorefresh cycle. TimesTen
6-12
Chapter 6
Impact of Failed Autorefresh Operations on TimesTen Databases
periodically deletes rows in the change log tables that have been applied to the cache tables.
An Oracle Database table cannot be cached in more than one cache group within a
TimesTen database. However, an Oracle Database table can be cached in more than one
TimesTen database. This results in an Oracle Database table corresponding to multiple
TimesTen cache tables. If updates on cached Oracle Database tables are not being
automatically refreshed into all of their corresponding cache tables because the cache agent
is not running on one or more of the TimesTen databases that the Oracle Database tables are
cached in, rows in their change log tables are not deleted by default. The cache agent may
not be running on a particular TimesTen database because the agent was either stopped or
never started, the database was destroyed, or the TimesTen instance is down. As a result,
rows accumulate in the change log tables and degrade the performance of autorefresh
operations on cache tables in TimesTen databases where the cache agent is running. This
can also cause the Oracle cache administration user's tablespace to fill up.
For example, if a single Oracle Database table is cached by two or more TimesTen
databases where one of the TimesTen databases is unable to connect to the Oracle
database, then autorefresh for the disconnected TimesTen database is not performed.
Instead, the records in the change log table accumulate (so that the disconnected TimesTen
database can catch up once a connection to the Oracle database is established). If the
AgentTimeout parameter is set to 0 (the default), then all change log records are kept
indefinitely until they have been applied to all its cache tables. The change log records of the
other TimesTen databases are not purged even though the transaction logs are already
applied to the local TimesTen database. Alternatively, you can set the AgentTimeout
parameter to define a specific timeout to wait before purging the saved change log records
and stop the accumulation of these change log records.
The following criteria must be met in order for TimesTen to delete rows in the change log
tables when the cache agent is not running on a TimesTen database and a cache agent
timeout is set:
• Oracle Database tables are cached in cache groups with autorefresh enabled within
more than one TimesTen database.
• The cache agent is running on at least one of the TimesTen databases but is not running
on at least another database.
• Rows in the change log tables have been applied to the cache tables on all TimesTen
databases where the cache agent is running.
• For those databases where the cache agent is not running, the agent process has been
down for a period of time that exceeds the cache agent timeout.
To set the cache agent timeout and prevent rows from accumulating in the change log tables,
set the AgentTimeout parameter with the ttCacheConfig built-in procedure as the TimesTen
cache administration user from any of the TimesTen databases that cache data from the
Oracle database. Pass the AgentTimeout string to the Param parameter and the timeout
setting as a numeric string to the Value parameter. Do not pass in any values to the tblOwner
and tblName parameters as they are not applicable to setting a cache agent timeout.
In the following example, the cache agent timeout is set to 900 seconds (15 minutes):
Command> CALL ttCacheConfig('AgentTimeout',,,'900');
To determine the current cache agent timeout setting, call ttCacheConfig passing only the
AgentTimeout string to the Param parameter:
6-13
Chapter 6
Command> CALL ttCacheConfig('AgentTimeout');

< AgentTimeout, <NULL>, <NULL>, 900 >
The default cache agent timeout setting is 0, which means that all change log records
are kept indefinitely until they have been applied to all its cache tables. If you set the
cache agent timeout to a value between 1 and 600 seconds, the timeout is set to 600
seconds. The cache agent timeout applies to all TimesTen databases that cache data
from the same Oracle database and have the same Oracle cache administration user
name setting.
When determining a proper cache agent timeout setting, consider the time it takes to
load the TimesTen database into memory, the time to start the cache agent process,
potential duration of network outages, and anticipated duration of planned
maintenance activities.
Each TimesTen database, and all of its cache groups have an autorefresh status to
determine whether any deleted rows from the change log tables were not applied to
the cache tables in the cache groups. If rows were deleted from the change log tables
and not applied to some cache tables because the cache agent on the database was
down for a period of time that exceeded the cache agent timeout, those cache tables
are no longer synchronized with the cached Oracle Database tables. Subsequent
updates on the cached Oracle Database tables are not automatically refreshed into
the cache tables until the accompanying cache group is recovered.
The following are the possible statuses for a cache group with autorefresh:
• ok: All of the deleted rows from the change log tables were applied to its cache
tables. Incremental autorefresh operations continue to occur on the cache group.
• disabled or dead: Some of the deleted rows from the change log tables were not
applied to its cache tables so the cache tables are not synchronized with the
cached Oracle Database tables. Autorefresh operations have ceased on the cache
group and do not resume until the cache group has been recovered.
• recovering: The cache group is being recovered. Once recovery completes, the
cache tables are synchronized with the cached Oracle Database tables, the cache
group's autorefresh status is set to ok, and incremental autorefresh operations
resume on the cache group.
The following are the possible autorefresh statuses for a TimesTen database:
• alive: All of its cache groups with autorefresh have an autorefresh status of OK.
• dead: All of its cache groups with autorefresh have an autorefresh status of dead.
• recovering: At least one of its cache groups with autorefresh have an autorefresh
status of recovering.
If the cache agent on a TimesTen database is down for a period of time that exceeds
the cache agent timeout, the autorefresh status of the database is set to dead. Also,
the autorefresh status of all cache groups with autorefresh within that database are set
to dead.
Call the ttCacheDbCgStatus built-in procedure as the TimesTen cache administration

user to determine the autorefresh status of a cache group and its accompanying
TimesTen database. Pass the owner of the cache group to the cgOwner parameter and
the name of the cache group to the cgName parameter.
In the following example, the autorefresh status of the database is alive and the
autorefresh status of the cacheadmin.customer_orders read-only cache group is ok:
6-14
Chapter 6
Command> CALL ttCacheDbCgStatus('cacheadmin','customer_orders');
< alive, ok >
To view only the autorefresh status of the database and not of a particular cache group, call
ttCacheDbCgStatus without any parameters:
Command> CALL ttCacheDbCgStatus;
< dead, <NULL> >
If the autorefresh status of a cache group is ok, its cache tables are being automatically
refreshed based on its autorefresh interval. If the autorefresh status of a database is alive,
the autorefresh status of all its cache groups with autorefresh are ok.
If the autorefresh status of a cache group is disabled or dead, its cache tables are no longer
being automatically refreshed when updates are committed on the cached Oracle Database
tables. The cache group must be recovered in order to resynchronize the cache tables with
the cached Oracle Database tables. See Disabling Full Autorefresh for Cache Groups.
You can configure a recovery method for cache groups whose autorefresh status is dead.
Call the ttCacheConfig built-in procedure as the TimesTen cache administration user from
any of the TimesTen databases that cache data from the Oracle database. Pass the
DeadDbRecovery string to the Param parameter and the recovery method as a string to the
Value parameter. Do not pass in any values to the tblOwner and tblName parameters as they
are not applicable to setting a recovery method for dead cache groups.
The following are the valid recovery methods:
• Normal: When the cache agent starts, a full autorefresh operation is performed on cache
groups whose autorefresh status is dead in order to recover those cache groups. This is
the default recovery method. However, if you set the DisableFullAutorefresh cache
configuration parameter to 1, then the DeadDbRecovery cache configuration parameter
automatically changes to Manual.
• Manual: For each static cache group whose autorefresh status is dead, a REFRESH CACHE
GROUP statement must be issued in order to recover these cache groups after the cache
agent starts.
For each dynamic cache group whose autorefresh status is dead, a REFRESH CACHE
GROUP or UNLOAD CACHE GROUP statement must be issued in order to recover these cache
groups after the cache agent starts.
• None: Cache groups whose autorefresh status is dead must be dropped and then re-
created after the cache agent starts in order to recover them.
In the following example, the recovery method is set to Manual for cache groups whose
autorefresh status is dead:
Command> CALL ttCacheConfig('DeadDbRecovery',,,'Manual');
To determine the current recovery method for dead cache groups, call ttCacheConfig
passing only the DeadDbRecovery string to the Param parameter:
Command> CALL ttCacheConfig('DeadDbRecovery');
< DeadDbRecovery, <NULL>, <NULL>, manual >
6-15
Chapter 6
Managing the Cache Administration User's Tablespace
The recovery method applies to all cache groups with autorefresh in all TimesTen
databases that cache data from the same Oracle database and have the same Oracle
cache administration user name setting.
When a cache group begins the recovery process, its autorefresh status is changed
from dead to recovering, and the status of the accompanying TimesTen database is
changed to recovering, if it is currently dead.
After the cache group has been recovered, its autorefresh status is changed from
recovering to ok. Once all cache groups have been recovered and their autorefresh
statuses are ok, the status of the accompanying TimesTen database is changed from
recovering to alive.
A full autorefresh operation requires more system resources to process than an

incremental autorefresh operation when there is a small volume of updates to refresh
and a large number of rows in the cache tables. If you need to bring a TimesTen
database down for maintenance activities and the volume of updates anticipated
during the downtime on the Oracle Database tables that are cached in cache groups
with autorefresh is small, you can consider temporarily setting the cache agent timeout
to 0. When the database is brought back up and the cache agent restarted,
incremental autorefresh operations resumes on cache tables in cache groups with
autorefresh. Full autorefresh operations are avoided because the autorefresh status
on the accompanying cache groups were not changed from ok to dead so those cache
groups do not need to go through the recovery process. Make sure to set the cache
agent timeout back to its original value once the database is back up and the cache
agent has been started.

You can manage the cache administration user's tablespace.
• Defragmenting Change Log Tables in the Tablespace
• Receiving Notification on Tablespace Usage
• Recovering From a Full Tablespace
Defragmenting Change Log Tables in the Tablespace

Prolonged use or a heavy workload of the change log tables for cache groups with
autorefresh can result in fragmentation of the tablespace.
In order to prevent degradation of the tablespace from fragmentation of the change log
tables, TimesTen calculates the percentage of fragmentation for the change log tables
as a ratio of used space to the total size of the space. If this ratio falls below a defined
threshold, TimesTen alerts you of the necessity for defragmentation of the change log
tables by logging a message. By default, this threshold is set to 40%.
You can configure what the fragmentation threshold should be with the ttCacheConfig
built-in procedure.
6-16
Chapter 6
Note:
Messages are logged to the user and support error logs. For details, see Error,
Warning, and Informational Messages in the Oracle TimesTen In-Memory Database
Operations Guide.
To set the fragmentation threshold, call the ttCacheConfig built-in procedure as the
TimesTen cache administration user from any of the TimesTen databases that cache data
from the Oracle database. Pass the AutoRefreshLogFragmentationWarningPCT string to the
Param parameter and the threshold setting as a numeric string to the Value parameter.
To set the time interval for how often to calculate the fragmentation percentage, call the
ttCacheConfig built-in procedure as the TimesTen cache administration user from any of the
TimesTen databases that cache data from the Oracle database. Pass the
AutorefreshLogMonitorInterval string to the Param parameter and the time interval (in
seconds) as a numeric string to the Value parameter.
Note:
Do not pass in any values to the tblOwner and tblName parameters as they are not
applicable to setting the fragmentation threshold or the time interval for the
threshold calculation.
In the following example, the fragmentation threshold is set to 50% and the time interval for
calculating the fragmentation threshold is set to 3600 seconds:
Command> CALL ttCacheConfig('AutoRefreshLogFragmentationWarningPCT',,,'50');
< AutoRefreshLogFragmentationWarningPCT, <NULL>, <NULL>, 50 >
1 row found.
Command> CALL ttCacheConfig('AutorefreshLogMonitorInterval',,,'3600');
< AutorefreshLogMonitorInterval, <NULL>, <NULL>, 3600 >
1 row found.
To determine the current fragmentation threshold setting, call ttCacheConfig passing the
AutoRefreshLogFragmentationWarningPCT string to the Param parameter:
Command> CALL ttCacheConfig('AutoRefreshLogFragmentationWarningPCT');
< AutoRefreshLogFragmentationWarningPCT, <NULL>, <NULL>, 50 >
You can either manually initiate defragmentation or configure TimesTen to automatically

defragment. To configure what action is taken when the ratio falls below the fragmentation
threshold, call the ttCacheConfig built-in procedure with the
AutoRefreshLogDeFragmentAction string to the Param parameter and the desired action as
the Value parameter as follows:
6-17
Chapter 6
Note:
Do not pass in any values to the tblOwner and tblName parameters as they
are not applicable to setting the defragmentation action.
• Manual. This is the default. No action is taken to defragment the change log tables.
Any defragmentation must be performed manually by running the
ttCacheAutoRefreshLogDeFrag built-in procedure. See Manually Defragmenting
the Change Log Tables for Cache Groups With Autorefresh.
• Compact: TimesTen defragments the change log tables.
• CompactAndReclaim: TimesTen defragments the change log tables and reclaims
the space.
Note:
When reclaiming space, the change log table is briefly locked, which
temporarily suspends writing into the base table.
In the following example, the action is set to CompactAndReclaim so that when the
fragmentation ratio falls below the threshold, TimesTen defragments the change log
tables and reclaims the space:
Command> CALL
ttCacheConfig('AutoRefreshLogDeFragmentAction',,,'CompactAndReclaim');
< AutoRefreshLogDeFragmentAction, <NULL>, <NULL>, compactandreclaim >
1 row found.
To determine the current fragmentation threshold setting, call ttCacheConfig passing

the AutoRefreshLogDeFragmentAction string to the Param parameter:
Command> CALL ttCacheConfig('AutoRefreshLogDeFragmentAction');
< AutoRefreshLogDeFragmentAction , <NULL>, <NULL>, compactandreclaim >
You can discover the fragmentation percentage of the tablespace and when the last
defragmentation operation was performed with the following returned columns from
the ttCacheAutorefreshStatsGet built-in procedure:
• AutoRefreshLogFragmentationPCT: The current fragmentation percentage for the

tablespace.
• AutoRefreshLogFragmentationTS: The timestamp of when the last fragmentation
percentage was calculated.
• autorefLogDeFragCnt: The count for how many times the tables in this particular
cache group have been defragmented.
See ttCacheConfig and ttCacheAutorefreshStatsGet in the Oracle TimesTen In-
6-18
Chapter 6
Manually Defragmenting the Change Log Tables for Cache Groups With Autorefresh
To manually initiate a defragmentation of the change log tables, call the
ttCacheAutoRefreshLogDeFrag built-in procedure as the TimesTen cache administration user
from any of the TimesTen databases that cache data from the Oracle database.
Pass in one of the following strings as the parameter:
• Compact: Defragment the change log tables.
• CompactAndReclaim: Defragment the change log tables and reclaim the space.
Note:
When reclaiming space, the change log table is briefly locked, which
temporarily suspends writing into the base table.
The following example manually defragments the change log tables with the
ttCacheAutoRefreshLogDeFrag built-in procedure providing the CompactAndReclaim option:
Command> CALL ttCacheAutoRefreshLogDeFrag('CompactAndReclaim');
See ttCacheAutoRefreshLogDeFrag in the Oracle TimesTen In-Memory Database

Reference.
Receiving Notification on Tablespace Usage

In order to avoid the tablespace becoming full, you can configure TimesTen to return a
warning to the application when an update operation (such as an UPDATE, INSERT or DELETE
statement) is issued on cached Oracle Database tables and causes the usage of the Oracle
cache administration user's tablespace to exceed a specified threshold.
Call the ttCacheConfig built-in procedure as the TimesTen cache administration user from
any of the TimesTen databases that cache tables from the Oracle database. Pass the
AutoRefreshLogTblSpaceUsagePCT string to the Param parameter and the threshold as a
numeric string to the Value parameter. The threshold value represents the percentage of
space used in the Oracle cache administration user's tablespace upon which a warning is
returned to the application when an update operation is issued on a cached Oracle Database
table. Do not pass in any values to the tblOwner and tblName parameters as they are not
applicable to setting a warning threshold for the usage of the Oracle cache administration
user's tablespace.
The Oracle cache administration user must be granted the SELECT privilege on the Oracle
Database SYS.DBA_DATA_FILES table in order for the TimesTen cache administration user to
set a warning threshold on the Oracle cache administration user's tablespace usage, and for
the Oracle cache administration user to monitor its tablespace to determine if the configured
threshold has been exceeded.
The following example configures a warning to be returned to the application that issues an
update operation on a cached Oracle Database table if it results in the usage of the Oracle
cache administration user's tablespace to exceed 80 percent:
Command> CALL ttCacheConfig('AutoRefreshLogTblSpaceUsagePCT',,,'80');
6-19
Chapter 6
To determine the current Oracle cache administration user's tablespace usage warning
threshold, call ttCacheConfig passing only the AutoRefreshLogTblSpaceUsagePCT
string to the Param parameter:
Command> CALL ttCacheConfig('AutoRefreshLogTblSpaceUsagePCT');
< AutoRefreshLogTblSpaceUsagePCT, <NULL>, <NULL>, 80 >
The default Oracle cache administration user's tablespace usage warning threshold is
0 percent which means that no warning is returned to the application regardless of the
tablespace usage. The Oracle cache administration user's tablespace usage warning
threshold applies to all TimesTen databases that cache tables from the same Oracle
database and have the same Oracle cache administration user name setting.
Recovering From a Full Tablespace

By default, when the Oracle cache administration user's tablespace is full, an error is
returned to the application when it attempts a DML operation, such as an UPDATE,
INSERT or DELETE statement, on a particular cached Oracle Database table.
Rather than TimesTen returning an error to the Oracle Database application when the
Oracle cache administration user's tablespace is full, you can configure TimesTen to
delete existing rows from the change log tables to make space for new rows when an
update operation is issued on a particular cached Oracle Database table. If some of
the deleted change log table rows have not been applied to the cache tables, a full
autorefresh operation is performed on those cache tables in each TimesTen database
that contains the tables upon the next autorefresh cycle.
Call the ttCacheConfig built-in procedure as the TimesTen cache administration user
from any of the TimesTen databases that cache tables from the Oracle database. Pass
the TblSpaceFullRecovery string to the Param parameter, the owner and name of the
cached Oracle Database table to the tblOwner and tblName parameters, respectively,
on which you want to configure an action to take if the Oracle cache administration
user's tablespace becomes full, and the action itself as a string to the Value
parameter.
The following are the valid actions:
• None: Return an Oracle Database error to the application when an update
operation is issued on the cached Oracle Database table. This is the default
action.
• Reload: Delete rows from the change log table and perform a full autorefresh
operation on the cache table upon the next autorefresh cycle when an update
operation is issued on the cached Oracle Database table.
The following example configures an action when the Oracle cache administration
user's tablespace becomes full. In this example, rows are deleted from the change log
table and a full autorefresh operation is performed on the cache table upon the next
autorefresh cycle when an update operation is issued on the sales.customer cached
Oracle Database table while the Oracle cache administration user's tablespace is full:
Command> CALL ttCacheConfig('TblSpaceFullRecovery','sales','customer','Reload');
To determine the current action to take when an update operation is issued on a

particular cached Oracle Database table if the Oracle cache administration user's
6-20
Chapter 6
Backing Up and Restoring a TimesTen Classic Database With Cache Groups
tablespace is full, call ttCacheConfig passing only the TblSpaceFullRecovery string to the
Param parameter, and the owner and name of the cached Oracle Database table to the
tblOwner and tblName parameters, respectively:
Command> CALL ttCacheConfig('TblSpaceFullRecovery','sales','customer');
< TblSpaceFullRecovery, SALES, CUSTOMER, reload >
The action to take when update operations are issued on a cached Oracle Database table
while the Oracle cache administration user's tablespace is full applies to all TimesTen
databases that cache tables from the same Oracle database and have the same Oracle
cache administration user name setting.
Backing Up and Restoring a TimesTen Classic Database With

Cache Groups
TimesTen Classic databases containing cache groups can be backed up and restored with
either the ttBackup or ttMigrate utilities.
• If the restored database connects to the same backend Oracle database, then use the
ttBackup and ttRestore utilities, then drop and recreate all cache groups in the restored
TimesTen database. If they are static cache groups, you may be required to reload them.
For dynamic cache groups, the reload is optional as data is pulled in from the Oracle
database as it is referenced.
Note:
If another TimesTen database is used to connect to the original backend Oracle
database (and now no longer connects) and if all cache groups in the TimesTen
database were not cleanly dropped, then run the cacheCleanUp.sql SQL*Plus
script against the original Oracle database to remove all leftover objects.
Specify the host and path for the original TimesTen database.
See SQL*Plus Scripts for Cache.
• If the restored database connects to a different backend Oracle database than what it
had originally connected with, then perform one of the following:
– Backing Up and Restoring Using the ttBackup and ttRestore Utilities
– Backing Up and Restoring TimesTen Classic Database With the ttMigrate Utility
Backing Up and Restoring Using the ttBackup and ttRestore Utilities

When you use the ttBackup utility, it backs up the TimesTen database with all of its data at a
particular time.
Thus, if you want to use these cache groups again, restoring this backup requires additional
action as the restored data within the cache groups are out of date and out of sync with the
data in the backend Oracle database. See Backup, Restore, and Migrate Data in TimesTen
Classic in the Oracle TimesTen In-Memory Database Installation, Migration, and Upgrade
Guide.
6-21
Chapter 6
Note:
See ttBackup and ttRestore in the Oracle TimesTen In-Memory Database
Reference.
If the restored database connects to a different backend Oracle database than what it
had originally connected with and you want to use the ttBackup and ttRestore utilities
to backup and restore your database, then perform the following:
1. Run the ttBackup utility command to backup the database and its objects into a
binary file. For example, to backup the cache1 database using the /tmp/dump
directory for temporary storage:
% ttBackup -dir /tmp/dump -connstr "DSN=cache1"

% ttIsql -connstr "DSN=cache1;UID=cacheadmin;PWD=timesten;OraclePWD=orapwd"
3. (Optional) Drop all cache groups from the TimesTen database. Since the database
still exists with its cache groups, TimesTen recommends that you drop the cache
groups.
Command> exit;
Disconnecting...
Done.
4. Destroy the database before restoring in the same or another location.

% ttDestroy cache1
5. Clean up objects on the Oracle database. Run the timesten_home/install/

oraclescripts/cacheCleanUp.sql SQL*Plus script from the current database
install as the Oracle cache administration user to drop the Oracle Database
objects used to implement autorefresh operations. The host name of the TimesTen
Classic system and the TimesTen database (including its path) are passed as
arguments to the cacheCleanUp.sql script.
SQL> @cacheCleanUp "sys1" "/users/OracleCache/cache1"
*****************************OUTPUT**************************************
/users/OracleCache/cache1 and object_id = 69959
6-22
Chapter 6

**************************************************************************
6. Restore the database with the ttRestore utility and then delete the temporary directory.
% ttRestore -dir /tmp/dump -connstr "DSN=cache1"
Restore started ...
Restore complete
% rm -r /tmp/dump
7. In order to re-synchronize the data within the cache groups, you must drop and recreate
the cache groups:
a. Connect to the TimesTen database.
b. Drop the cache groups that were restored with the ttRestore utility. Because the
data is out of sync, you may see errors.
c. Specify the Oracle cache administration user name and password with the
ttCacheUidPwdSet built-in procedure.
d. Start the cache agent.
e. Recreate and, if required, reload the cache groups.

Command> CREATE READONLY CACHE GROUP readcache
AUTOREFRESH INTERVAL 5 SECONDS
FROM sales.readtab
(keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR2(32));
Command> LOAD CACHE GROUP readcache COMMIT EVERY 256 ROWS;
Note:
If the restored TimesTen database is not able to connect to any backend Oracle
database, then TimesTen cannot autorefresh the data for the read-only cache
groups.
Backing Up and Restoring TimesTen Classic Database With the ttMigrate

Utility
The ttMigrate utility saves tables and indexes from a TimesTen Classic database into a
binary file.
When a cache group is migrated and included in the binary file, it includes the cache group
definition and schema; however, the data of the cache group is not migrated.
6-23
Chapter 6
Note:
See Backup, Restore, and Migrate Data in TimesTen Classic in the Oracle
TimesTen In-Memory Database Installation, Migration, and Upgrade Guide
and ttMigrate in the Oracle TimesTen In-Memory Database Reference.
If the restored database connects to a different backend Oracle database than what it
had originally connected with and you want to use the ttMigrate utility for backing up
and restoring the database, then perform the following:
Command> exit
Disconnecting...
Done.
2. Run the ttMigrate -c utility command to save the database and its objects into a
binary file.
% ttMigrate -c "DSN=cache1" cache1.ttm
...
Saving user CACHEADMIN
User successfully saved.
Saving user sales

User successfully saved.
Saving table CACHEADMIN.READTAB

Saving rows...
2/2 rows saved.
Table successfully saved.
Saving cache group CACHEADMIN.READCACHE

Saving cached table SALES.READTAB
Cache group successfully saved.
3. (Optional) Drop all cache groups from the TimesTen database. Since the database
still exists with its cache groups, TimesTen recommends that you drop the cache
groups. When you drop all cache groups before destroying the TimesTen
database, all metadata on the Oracle Database for these cache groups is deleted.
However, if you use the cacheCleanup.sql script in a future step, this script
deletes the metadata on the Oracle Database.
You may see errors reported, which can be ignored.
Command> exit
Disconnecting...
Done.
4. Destroy the TimesTen database.

% ttDestroy cache1
5. Clean up objects on the Oracle database: If you did not drop that cache groups in
an earlier step, you can run the timesten_home/install/oraclescripts/
cacheCleanUp.sql SQL*Plus script as the Oracle cache administration user to
6-24
Chapter 6
drop the Oracle Database objects used to implement autorefresh operations. The host
name of the TimesTen Classic system and the TimesTen database (including its path) are
passed as arguments to the cacheCleanUp.sql script.
SQL> @cacheCleanUp "sys1" "/users/OracleCache/cache1"
*****************************OUTPUT**************************************
**************************************************************************
6. Create and restore the database:

a. Create the TimesTen database with a first connection request.
b. Create the cache table user and the TimesTen cache administration user. Grant
appropriate privileges to these users.
Note:
Depending on which TimesTen Classic release you are migrating from, the
users and privileges may or may not be migrated. See ttMigrate in the
c. Specify the Oracle cache administrator user name and password with the
ttCacheUidPwdSet built-in procedure.
% ttIsql cache1
Command> CREATE USER cacheadmin IDENTIFIED BY timesten;
User created.

Command> CREATE USER sales IDENTIFIED BY timesten;
User created.
Command> exit
Disconnecting...
Done.

Command> exit
Disconnecting...
Done.
6-25
Chapter 6
Changing Cache User Names and Passwords
7. Restore the database from the saved binary file with the ttMigrate -r utility
command.
% ttMigrate -r -relaxedUpgrade -cacheuid cacheadmin -cachepwd orapwd
-connstr "DSN=cache1;UID=cacheadmin;PWD=timesten;OraclePWD=orapwd"
cache1.ttm
...
Restoring table CACHEADMIN.READTAB
Restoring rows...
2/2 rows restored.
Table successfully restored.
Restoring cache group CACHEADMIN.READCACHE

Restoring cached table SALES.READTAB
1/1 cached table restored.
Cache group successfully restored.
8. Connect to the restored database and reset the cache autorefresh state:
a. Connect to the TimesTen database with ttIsql.
b. Start the cache agent.
c. Alter the cache groups to set autorefresh state to ON.
% ttIsql -connstr
"DSN=cache1;UID=cacheadmin;PWD=timesten;OraclePWD=orapwd"
Command> ALTER CACHE GROUP readcache SET AUTOREFRESH STATE ON;
Note:
If the restored TimesTen database is not able to connect to any backend
Oracle database, then TimesTen cannot autorefresh the data for the read-
only cache groups.

You can change any of the user names or passwords for the TimesTen cache
administration user or its companion Oracle cache administration user.
1. If you want to modify the TimesTen cache administration user or password,
perform the following:
Note:
Passwords for both the TimesTen cache administration user and its
companion Oracle cache administration user can be changed at any
time.
The name for the TimesTen cache administration user must be the same
as its companion Oracle cache administration user; however, the
passwords may be different. See Create the TimesTen Users.
6-26
Chapter 6
a. On the TimesTen database, if you want to modify the password of the TimesTen
cache administration user, then use the ALTER USER statement on the active master.
Command> ALTER USER cacheadmin IDENTIFIED BY newpwd;
b. On the back-end Oracle database, you can modify the companion Oracle cache
administration user password with the ALTER USER statement. If you are working on
TimesTen, you can use Passthrough 3 to run this directly on the Oracle database.
Note:
If you have modified the password for the companion Oracle cache
administration user, reconnect to the TimesTen database as the TimesTen
cache administration user providing passwords for the TimesTen cache
administration user and its companion Oracle cache administration user.
c. If you want to change the TimesTen cache administration user, you must first drop all
cache groups that the TimesTen cache administration user owns before dropping the
existing user and creating a new user. The Oracle cache administration user name
can only be changed when there are no cache groups on the TimesTen database.
Note:
Alternatively, if you want to use a different user as the TimesTen cache
administration user, ensure that it has the correct privileges and a
companion Oracle cache administration user with the correct privileges.
In addition, since the TimesTen cache administration user must have a companion
Oracle cache administration user with the same name, you must either:
• Drop all tables owned by the current companion Oracle cache administration
user, drop the user, and then re-create it with the same name as the new
TimesTen cache administration user.
• Choose another Oracle user that has the same name as the TimesTen cache
administration user and provides the same functionality.
d. On TimesTen Classic, if the TimesTen cache administration user name or password
are defined in the sys.odbc.ini (or odbc.ini) file, update the new TimesTen cache
administration user name or password in the sys.odbc.ini (or odbc.ini) file on both
the active and standby masters.
2. If you want to modify the Oracle cache administration user or its password, perform the
following:
a. On the back-end Oracle database, you can modify the Oracle cache administration
password with the ALTER USER statement. The password of the Oracle cache
administration user can be changed at any time.
6-27
Chapter 6
If you are working on TimesTen, you can use Passthrough 3 to run this
directly on the Oracle database.
b. If you want to change the Oracle cache administration user, you must first drop
all cache groups on the TimesTen database that the Oracle cache
administration user manages before you can drop the Oracle cache
administration user on the Oracle database and create a new user. Dropping
the cache groups on TimesTen removes all metadata associated with those
cache groups.
When you create a new Oracle cache administration user on the Oracle
database, you must follow the same instructions for creating a Oracle cache
administration user that are provided in the Create the Oracle Database Users
and Default Tablespace.
c. Set the new user name or password for the Oracle cache administration user.
• On TimesTen Classic, run the ttCacheUidPwdSet built-in procedure on the
active master database.
Note:
Command> call ttCacheUidPwdSet('cacheadmin','newpwd');
• On TimesTen Scaleout, run the ttGridAdmin dbCacheCredentialSet

command.
Note:
See Set the Cache Administration User Name and Password in
the TimesTen Database in the Oracle TimesTen In-Memory
Database Cache Guide.
% ttGridAdmin dbCacheCredentialSet database1

Provide Oracle user id: cacheadmin
Provide Oracle password: oracle
6-28
7
Cache Performance
The following sections contain information about cache performance.
Note:
See Monitoring Autorefresh Cache Groups and Poor Autorefresh Performance in

the Oracle TimesTen In-Memory Database Monitoring and Troubleshooting Guide
for extensive information about monitoring autorefresh operations and improving
autorefresh performance.
See AWT Performance Monitoring and Possible Causes of Poor AWT Performance
in the Oracle TimesTen In-Memory Database Monitoring and Troubleshooting
Guide.
• Dynamic Load Performance

• Improving AWT Throughput
• Improving Performance for Autorefresh Operations
• Retrieving Statistics on Autorefresh Transactions
• Caching the Same Oracle Table on Two or More TimesTen Databases
Dynamic Load Performance

Dynamic loading of a single cache instance based on a primary key search of the root table
has faster performance than primary key searches on a child table or foreign key searches on
a child table.
Dynamic loading of multiple cache instances may have faster performance than loading
single cache instances. See Dynamically Loading Multiple Cache Instances.
If you combine dynamic load operations with autorefresh operations, you may experience
some contention. See Improving Performance for Autorefresh Operations for details on how
to improve your performance in this situation.
There can be a performance cost when opening a new connection for a dynamic load
operation. You can reduce the cost of opening new connections by creating a cache
connection pool. You may want to use a cache connection pool if your application requires
frequent dynamic load operations that would create too many open connections to the Oracle
database. See Managing a Cache Connection Pool to the Oracle Database for Dynamic
Load Requests.
7-1
Chapter 7
Managing a Cache Connection Pool to the Oracle Database for

Dynamic Load Requests
When a qualifying SELECT statement is issued on any dynamic read-only cache table
and the data does not exist in the cache table (but does exist in the base Oracle
database table), this results in a cache miss. After which, Timesten performs a
dynamic load to retrieve the data from the Oracle database (either over an existing or
a new connection to the Oracle database) and inserts the rows into the cache group.
There can be a performance cost when opening a new connection for the dynamic
load. You can reduce the cost of opening new client connections by creating a cache
connection pool.
By default, a client connection to the Oracle database remains open until the
application's connection to TimesTen is closed. When the application initiates a
dynamic load, each client connection is associated with a connection to the Oracle
database (when using cache). If you use several client connections, TimesTen's
requests for new client connections to the Oracle database could exceed the
maximum number of client connections allowed to the Oracle database.
Applications can have multiple dynamic load requests spread across multiple client
connections to the Oracle database, which could result in too many open client
connections to the back-end Oracle database. Alternately, there could be applications
across multiple TimesTen databases performing dynamic loads against the same
Oracle database. For client/server applications with multiple client connections per
server, you can configure TimesTen to use the cache connection pool for all client
connections that are used for dynamic load operations from the Oracle database. The
cache connection pool can only be utilized by an application using a client connection
as the pooled connections are shared across all client connections.
Dynamic load requests will use an existing client connection to the Oracle database
from the cache connection pool (rather than creating a new one) to reduce the total
number of open client connections. Once the dynamic load request completes, the
connection is returned to the cache connection pool.
Using an existing connection from the cache connection pool optimizes your
application performance by:
• Reducing the cost of starting a dedicated Oracle server process (or thread) for
each newly requested connection.
• Reducing the total number of Oracle server processes (threads) by sharing them
amongst client connections rather than having each process (thread) dedicated to
a single connection. However, if there are no available client connections in the
cache connection pool, the dynamic load operation waits until a connection is
added to the pool.
• Enabling the sharing of session level server resources, such as memory, between
client connections.
Once the connection is returned to the cache connection pool, the application logically
sees the client connection as disconnected. Thus, if an application contains
passthrough statements (DDL or DML statements performed in the Oracle database),
any passthrough statement must be committed or rolled back before the dynamic load
is requested or an error is thrown. You can set autocommit to ON or run the commit or
rollback within the transaction before the dynamic load.
7-2
Chapter 7
Note:
If an application runs a higher than expected number of dynamic load requests and
performance is critical, then you might consider either:
• Removing or minimizing passthrough statements with DDL or DML statements
(which can slow down performance) from any application using the cache
connection pool.
• Maintaining a completely separate client connection directly to the Oracle
Database to run its SQL directly against the Oracle database, rather than using
passthrough statements to run SQL indirectly through TimesTen.
To decide whether to use the cache connection pool, evaluate if any applications request a
high number of dynamic load operations from the Oracle database (resulting in too many
open client connections to the Oracle database).
The following sections describe how to use the cache connection pool for your dynamic read-
only cache groups:
• Enable the Cache Connection Pool
• Size the Cache Connection Pool
• Use the ChildServer Connection Attribute to Identify a Child Server Process
• Dynamically Applying Cache Connection Pool Sizing Modifications
• Example Demonstrating Management of the Cache Connection Pool
• Limiting the Number of Connections to the Oracle Database
• Restrictions for the Cache Connection Pool
Enable the Cache Connection Pool

You can specify that TimesTen creates a cache connection pool on the TimesTen server
when it starts up.
If a cache connection pool is created, then a dynamic load request from a client/server
connection acquires a connection from the cache connection pool, performs the dynamic
load, and returns the connection to the cache connection pool after the dynamic load request
completes. The cache connection pool is destroyed when the TimesTen server shuts down.
Note:
The cache connection pool can only be initiated from client-server applications
(using multithreaded mode) and is used only for dynamic loads initiated for dynamic
read-only cache groups.
To enable client/server connection requests to use the cache connection pool, an application
must specify the following connection attributes when connecting.
• MaxConnsPerServer connection attribute: This connection attribute sets the maximum
number of client/server connections that can be created for each child server process.
7-3
Chapter 7
When the value is set to > 1, each TimesTen child server can handle multiple client
connections where each client/server connection is multithreaded. You can only
use the cache connection pool with a multithreaded client/server connection.
When MaxConnsPerServer connection attribute is set to 1, TimesTen creates one
single-threaded client/server connection for each child server process.
• ServersPerDSN connection attribute: Value designates the number of child server
processes to spawn for the TimesTen server. Default is 1.
Each new incoming connection spawns a new child server process up to the value
specified by the ServersPerDSN connection attribute. When the maximum number
of child server processes is reached, the existing child server processes handle
multiple connections (up to the number specified in MaxConnsPerServer) in a
round-robin method. That is, if you specify ServersPerDSN = 2 and
MaxConnsPerServer = 3, then the first two connections would spawn two child
server processes. The third through the sixth connections would be handled by
these child server processes, where each child server process would service
every other connection.
Once all of the child server processes have the maximum allowed number of
connections, the next incoming connection starts a new set of child server
processes.
The ServersPerDSN and MaxConnsPerServer connection attributes are used to
designate how to distribute connections across multiple child server processes.
• UseCacheConnPool connection attribute: Must be enabled (set to 2) to use the
cache connection pool. When the UseCacheConnPool connection attribute is
enabled, the cache connection pool is created and used for dynamic load
operations initiated by multithreaded client/server connections. If the
UseCacheConnPool connection attribute is disabled (set to 0), then the cache
connection pool is not created and the dynamic load operations perform using the
existing behavior. See UseCacheConnPool in the Oracle TimesTen In-Memory
Database Reference.
Note:
You may also want to limit the number of connections to the Oracle
database. See Limiting the Number of Connections to the Oracle Database.
The following example specifies connection attributes for the cache connection pool in
the DSN definition:
The cache1 DSN definition in the sys.odbc.ini file specifies UseCacheConnPool=2,
ServersPerDSN=2 and MaxConnsPerServer=3.
[cache1]
DataStore=/users/OracleCache/database1
PermSize=64
OracleNetServiceName=oracledb
UseCacheConnPool=2
ServersPerDSN=2
MaxConnsPerServer=3
7-4
Chapter 7
Alternatively, you can specify both of the connection attributes on the command line when
connecting from the application.
ttIsql "DSN=cache1; OracleNetServiceName=oracledb; UseCacheConnPool=2;
ServersPerDSN=2; MaxConnsPerServer=3"
Note:
See the MaxConnsPerServer, ServersPerDSN, and UseCacheConnPool sections
in the Oracle TimesTen In-Memory Database Reference.
Size the Cache Connection Pool

You can appropriately size the cache connection pool to avoid contention for connections with
the ttCacheConnPoolSet built-in procedure.
The ttCacheConnPoolSet built-in procedure saves the values of these parameters in the
Oracle database, which are then used as the default values when restarting the TimesTen
server. Once applied to each TimesTen server, the values specified are used for the cache
connection pool across all client/server applications for a TimesTen database.
If you want to modify these values after the TimesTen server starts, you can change the
cache connection pool sizing parameters on the Oracle database using the
ttCacheConnPoolSet built-in procedure. After which, you can re-initialize the TimesTen server
by either:
• Restarting the TimesTen server to re-initialize the server (and all child server processes)
with the new sizing parameters.
• Dynamically re-initializing each TimesTen server with the cache connection pool
parameters saved on the Oracle database with the ttCacheConnPoolApply built-in
procedure. See Dynamically Applying Cache Connection Pool Sizing Modifications.
You can run the ttCacheConnPoolSet built-in procedure from a direct connection, a single-
threaded client/server connection or a multithreaded client/server connection.
Note:
See the ttCacheConnPoolSet in the Oracle TimesTen In-Memory Database
Reference.
For example, the following initiates the minimum and maximum number of pooled
connections to be between 10 and 32 connections and the increment is 1. The maximum idle
time by the client is set to 10 seconds. And all dynamic load operations will wait for an
available connection from the cache connection pool.
Command> call ttCacheConnPoolSet(10, 32, 1, 10, 0);
Set the minimum and maximum size of the cache connection pool to levels where
connections are available when needed. If no connections are available in the pool, dynamic
load operations stall until a connection from the pool is available (unless you set
7-5
Chapter 7
ConnNoWait=1). If a connection to the Oracle database times out, you receive an error
denoting a loss of the connection, sometimes requiring a rollback on TimesTen.
You can query what the cache connection pool parameters are with the
ttCacheConnPoolGet built-in procedure.
See Example Demonstrating Management of the Cache Connection Pool.
Use the ChildServer Connection Attribute to Identify a Child Server Process

In a client/server environment, TimesTen can create multiple TimesTen child server
processes to handle incoming requests from clients. You can use the ChildServer
connection attribute to identify a specific child server process when performing certain
cache connection pool administrative functions, such as the
ttCacheConnPoolGet('current') or ttCacheConnPoolApply built-in procedures.
The target child server process is identified by a value specified using the
ChildServer=n connection attribute, where n is a number ranging from 1 to the
number of running child server processes. When you specify the ChildServer
connection attribute, then the client process connects using the identified child server
process. If the attribute is not specified, then the client process connects using a
randomly selected child server process.
See ttCacheConnPoolApply and ttCacheConnPoolGet in the Oracle TimesTen In-
Memory Database Reference. See Example Demonstrating Management of the
Cache Connection Pool.
Dynamically Applying Cache Connection Pool Sizing Modifications

The cache connection pool parameters are saved in the Oracle database, which are
used to initialize the cache connection pool for the TimesTen database every time that
the TimesTen server restarts. The sizing is set on the Oracle database with the
ttCacheConnPoolSet built-in procedure. This sizing applies to each TimesTen server
and child server processes when started.
However, you can dynamically resize the cache connection pool parameters for each
child server process (while the database is running) with the ttCacheConnPoolApply
built-in procedure.
• Execute the ttCacheConnPoolSet built-in procedure to set a new set of parameters
that are stored on the Oracle database.
• Connect to the child server process.
• Dynamically associate the new set of cache connection pool parameters for this
particular child server process with the ttCacheConnPoolApply built-in procedure.
For example, the following connects to the child server process identified as 1 and
applies the new cache connection pool configuration to this child server process. It
does the same process for child server process 2 (given that ServersPerDSN=2).
Command> connect "DSN=cache1;ChildServer=1;";
Command> call ttCacheConnPoolApply;
Command> disconnect;

7-6
Chapter 7
You can run the ttCacheConnPoolApply built-in procedure only from a multithreaded client/
server connection.
If the cache connection pool fails, you can recreate the pool by running the
ttCacheConnPoolApply built-in procedure from any child server process.
See Example Demonstrating Management of the Cache Connection Pool.
Example Demonstrating Management of the Cache Connection Pool

This example shows how to set new values for the cache connection pool and apply them to
two separate child server processes.
This example uses the cache1 DSN as shown in Enable the Cache Connection Pool that
enables the cache connection pool. It also assumes that you have set the cache
administrator and password as described in Set the Cache Administration User Name and
Password.
/* Since ServerPerDSN is set to two and MaxConnsPerServer is set to 3, the first
and second connections spawn off both child server processes. And then you can
create four more connections to reach the MaxConnsPerServer maximum, which are
routed by the TimesTen server to the appropriate child server process (using a
round robin method).*/
Command> connect "DSN=cache1;" as conn1;
Command> use conn1;
/* Query the values for the cache connection pool that are saved on the Oracle
database*/
Command> call ttCacheConnPoolGet('saved');
< 1, 10, 1, 10, 0, -1, -1, -1>
/* Change the configuration of the cache connection pool */

Command> call ttCacheConnPoolSet(1, 20, 1, 10, 0);
/* Query existing values for cache connection pool saved on the Oracle data base.
Since these are the saved values, this returns -1 for OpenCount, BusyCount
and LastOraErr. */
Command> call ttCacheConnPoolGet('saved');
< 1, 20, 1, 10, 0, -1, -1, -1 >
/* Query existing values for the current cache connection pool on this TimesTen
database */
Command> call ttCacheConnPoolGet('current');
< 1, 10, 1, 10, 0, 1, 0, 0 >
/* Connect to the child server process 1 using the ChildServer=1 connection

attribute. Apply the saved values as the current values to the cache connection
pool for child server process identified as ChildServer 1. */
/* Connect to the child server process 1 using the ChildServer=1 connection

attribute. Apply the saved values as the current values to the cache connection
7-7
Chapter 7
pool for child server process identified as ChildServer 2. */

/* Query values for the cache connection pool in ChildServer 1 */

Command> use conn1;
< 1, 20, 1, 10, 0, 1, 0, 0 >
/* Query values for the cache connection pool in ChildServer 2 */

Command> use conn2;
< 1, 20, 1, 10, 0, 1, 0, 0 >
Limiting the Number of Connections to the Oracle Database

You can optimize performance while ensuring a limit to the number of connections to
the Oracle database.
Tuning the total number of connections depends on the following:
Note:
These calculations assume that all connections to the Oracle database are
client/server connections using a multithreaded server. The connections
referred to in the rest of this section are only those used for dynamic load
operations. There can be other connections from TimesTen to the Oracle
database that are not accounted for in these calculations.
• N: The number of connections to the Oracle database.

• P: The limit on the number of connections for each cache connection pool, where
each TimesTen child server process has a cache connection pool. You can set this
with the MaxSize cache connection pool parameter using the ttCacheConnPoolSet
built-in procedure.
• S: The maximum number of child server processes that can be spawned for new
connections. Currently, there is no direct way to limit the number of child server
processes. Indirectly, you can influence the number of child server processes by
setting the MaxConnsPerServer and Connections connection attributes. You should
measure S on your system when your system is in a steady state that represents
the typical operating conditions.
• M: The maximum number of connections for each child server process, which you
can set with the MaxConnsPerServer connection attribute.
• D: The maximum number of connections to a DSN, which is set with the
Connections connection attribute.
The number of connections (N) to the Oracle database is equal to the maximum
number of TimesTen child server processes (S) times the maximum number of
connections for each cache connection pool (P).
N=S*P
7-8
Chapter 7
Improving AWT Throughput
The maximum number of connections (D) to the DSN is equal to the maximum number of
connections for each child server process (M) times the maximum number of TimesTen child
server processes (S).
D=M*S
With the above calculation, you can also state:

S=D/M
Since there is no hard limit that we can configure for the number of TimesTen child server
processes, we substitute for S to get the following equation:
N=(D*P)/M
Assuming that all connections to the Oracle database are client/server connections, then the
maximum number of connections to the Oracle database arising from cache connection pools
is equal to the maximum number of connections to the DSN (set by the Connections
connection attribute) times the number of connections for each cache connection pool (set by
the MaxSize cache connection pool parameter), which is then divided by the maximum
number of connections for each child server process (set by the MaxConnsPerServer
connection attribute).
Note:
For TimesTen Scaleout, you may also want to limit the connections to the Oracle
database through limiting the number of cache agents. See Limiting Cache Agent
Connections to the Oracle Database in the Oracle TimesTen In-Memory Database
Scaleout User's Guide.
Restrictions for the Cache Connection Pool

There are restrictions when using the cache connection pool.
• You cannot use the cache connection pool in conjunction with the Oracle Database
Resident Connection Pooling feature.
• The cache connection pool is only supported for multithreaded client/server connections,
where the MaxConnsPerServer connection attribute must be greater than 1.
• The cache connection pool is only used for dynamic load operations for dynamic read-
only cache groups.

There are best practice methods to improve throughput for AWT cache groups.
• Improving AWT Throughput With Parallel Propagation to the Oracle Database
• Improving AWT Throughput With SQL Array Processing
7-9
Chapter 7
Improving AWT Throughput With Parallel Propagation to the Oracle

Database
To improve throughput for an AWT cache group, you can configure multiple threads
that act in parallel to propagate and apply transactional changes to the Oracle
database. Parallel propagation enforces transactional dependencies and applies
changes in AWT cache tables to Oracle Database tables in commit order.
Parallel propagation is supported for AWT cache groups with the following
configurations:
• AWT cache groups involved in an active standby pair replication scheme
• AWT cache groups in a single TimesTen database (without a replication scheme
configuration)
• AWT cache groups configured with any aging policy
The following data store attributes enable parallel propagation and control the number
of threads that operate in parallel to propagate changes from AWT cache tables to the
corresponding Oracle Database tables:
• ReplicationApplyOrdering enables parallel propagation by default.
• ReplicationParallelism defines the number of transmitter threads on the source
database and the number of receiver threads on the target database for parallel
replication in a replication scheme. This value can be between 2 and 32 when
used solely for parallel replication. The default is 1. In addition, the value of
ReplicationParellelism cannot exceed half the value of LogBufParallelism.
• CacheAWTParallelism, when set, determines the number of threads used in
parallel propagation of changes from AWT cache tables to the Oracle Database
tables. Set this attribute to a number from 2 to 31. The default is 1.
Parallel propagation for an AWT cache group is configured with one of the following
scenarios:
• ReplicationApplyOrdering is set to 0 and ReplicationParallelism is greater
than 1.
If you do not set CacheAWTParallelism, the number of threads that apply changes
to Oracle Database is 2 times the setting for ReplicationParallelism. For
example, if ReplicationParallelism=3, the number of threads that apply changes
to Oracle Database tables is 6. In this case, ReplicationParallelism can only be
set from 2 to 16; otherwise, twice the value would exceed the maximum number of
31 threads for parallel propagation. If the value is set to 16, the maximum number
of threads defaults to 31.
• ReplicationApplyOrdering is set to 0, ReplicationParallelism is equal to or
greater than 1, and CacheAWTParallelism is greater than 1. The value for
CacheAWTParallelism must be greater than or equal to the value set for
ReplicationParallelism and less than or equal to 31.
If CacheAWTParallelism is not specified, then ReplicationParallelism is used to
determine the number of threads that are used for parallel propagation to Oracle
Database. However, since this value is doubled for parallel propagation threads,
you can only set ReplicationParallelism to a number from 2 to 16. If the value is
set to 16, the maximum number of threads defaults to 31.
7-10
Chapter 7
If both ReplicationParallelism and CacheAWTParallelism attributes are set, the value

set in CacheAWTParallelism configures the number of threads used for parallel
propagation. The setting for CacheAWTParallelism determines the number of apply
threads for parallel propagation and the setting for ReplicationParallelism determines
the number of threads for parallel replication. Thus, if ReplicationParallelism is set to 4
and CacheAWTParallelism is set to 6, then the number of threads that apply changes to
Oracle Database tables is 6. This enables the number of threads used to be different for
parallel replication and parallel propagation to Oracle Database tables.
Note:
See Configuring Parallel Replication in the Oracle TimesTen In-Memory Database
Replication Guide. See ReplicationApplyOrdering, ReplicationParallelism, and
CacheAWTParallelism in the Oracle TimesTen In-Memory Database Reference.
These data store attributes are interrelated. Table 7-1 shows the result with the combination
of the various possible attribute values.
Table 7-1 Results of Parallel Propagation Data Store Attribute Relationships
ReplicationApply ReplicationParallelism CacheAWTParallelism Number of Parallel Propagation

Ordering Threads
Set to 0, which Set to > 1 for multiple Not specified. Set to twice the value of
enables parallel tracks and <= 16. ReplicationParallelism.
propagation
Set to 0, which Set to > 16 and <= 32 Not specified. Error is thrown. If
enables parallel for multiple tracks. CacheAWTParallelism is not set,
propagation then 2 times the value set in
ReplicationParallelism
specifies the number of threads.
Thus, in this case,
ReplicationParallelism cannot
be greater than 16.
Set to 0, which Set to > 1 and <= 32 for Set to >= to Set to number specified by
enables parallel multiple tracks. ReplicationParallelism. CacheAWTParallelism.
propagation
Set to 0, which Set to > 1 and <= 32 for Set to < Error is thrown at database creation.
enables parallel multiple tracks. ReplicationParallelism. The CacheAWTParallelism must
propagation be set to a value greater than or
equal to
ReplicationParallelism.
Set to 0, which Set to 1 or not specified. Set to > 1 Set to number specified by
enables parallel Single track. CacheAWTParallelism.
propagation
Set to 1, which N/A Set to > 1 Error is thrown at database creation,
disables parallel since parallelism is turned off, but
propagation. CacheAWTParallelism is set to a
value, expecting parallel
propagation to be enabled.
7-11
Chapter 7
Foreign keys in Oracle Database tables that are to be cached must have indexes
created on the foreign keys. Consider these Oracle Database tables:
CREATE TABLE parent (c1 NUMBER PRIMARY KEY NOT NULL);
CREATE TABLE child (c1 NUMBER PRIMARY KEY NOT NULL,
c2 NUMBER REFERENCES parent(c1));
CREATE TABLE grchild (c1 NUMBER PRIMARY KEY NOT NULL,
c2 NUMBER REFERENCES parent(c1),
c3 NUMBER REFERENCES parent(c1));
These indexes must be created:

CREATE INDEX idx_1 ON child(c2);
CREATE INDEX idx_2 ON grchild(c2);
CREATE INDEX idx_3 ON grchild(c3);
The following sections describe restrictions, configuration and checks for parallel
propagation:
• Table Constraint Restrictions When Using Parallel Propagation for AWT Cache
Groups
• Manually Initiate Check for Missing Constraints for an AWT Cache Group
• Configuring Batch Size for Parallel Propagation for AWT Cache Groups
Table Constraint Restrictions When Using Parallel Propagation for AWT Cache
Groups
When you use parallel propagation for AWT cache groups, you must manually enforce
data consistency.
Any unique index, unique constraint, or foreign key constraint that exists on columns in
the Oracle Database tables that are to be cached should also be created on the AWT
cache tables within TimesTen. If you cannot create these constraints on the AWT
cache tables and you have configured for parallel propagation, then TimesTen
serializes any transactions with DML operations to any table with missing constraints.
For example, if a unique index created on a table in the Oracle database cannot be
created on the corresponding cached table in TimesTen, all transactions for this table
are serialized.
TimesTen automatically checks for missing constraints on the Oracle database that are
not cached on TimesTen when you issue any of the following SQL statements:
• When you create an AWT cache group with the CREATE ASYNCHRONOUS CACHE
GROUP statement
• When you create a unique index on an AWT cache table with the CREATE UNIQUE
INDEX statement
• When you drop a unique index on an AWT cache table with the DROP INDEX
statement
7-12
Chapter 7
Note:
You can manually initiate a check for missing constraints with the ttCacheCheck
built-in procedure. For example, TimesTen does not automatically check for missing
constraints after a schema change on cached Oracle Database tables. After any
schema change on the Oracle database, you should perform an manual check for
missing constraints by running ttCacheCheck on the TimesTen database.
See Manually Initiate Check for Missing Constraints for an AWT Cache Group for
other conditions where you should manually check for missing constraints.
If the check notes missing constraints on the cached tables, TimesTen issues warnings about
each missing constraint.
For the following scenarios, the cached table is marked so that transactions that include DML
operations are serialized when propagated to the Oracle database.
• Transactions that apply DML operations to AWT cache tables that are missing unique
indexes or unique constraints.
• Missing foreign key constraints for tables within a single AWT cache group.
– If both the referencing table and the referenced table for the foreign key relationship
are in the same AWT cache group and the foreign key relationship is not defined,
both tables are marked for transaction serialization.
– If the referencing table is in an AWT cache group and the referenced table is not in
an AWT cache group, the table inside the cache group is not marked for transaction
serialization. Only a warning is issued to notify the user of the missing constraint.
– If the referenced table is in an AWT cache group and the referencing table is not in
an AWT cache group, the table inside the cache group is not marked for transaction
serialization. Only a warning is issued to notify the user of the missing constraint.
• Missing foreign key constraints between cache groups. When you have tables defined in
separate AWT cache groups that are missing a foreign key constraint, both tables are
marked for serialized transactions.
• If a missing foreign key constraint causes a chain of foreign key constraints to be broken
between two AWT cache groups, transactions for all tables within both AWT cache
groups are serialized.
Note:
An Oracle Database trigger may introduce an operational dependency of which
TimesTen may not be aware. In this case, you should either disable parallel
propagation for the AWT cache group or do not cache the table in an AWT cache
group on which the trigger is created.
The following is an example of missing constraints when creating an AWT cache group. This
example creates two tables in the sales schema in the Oracle database. There is a foreign
key relationship between active_customer and the ordertab tables. Because the examples
use these tables for parallel propagation, an index is created on the foreign key in the
ordertab table.
7-13
Chapter 7
SQL> CREATE TABLE active_customer

name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12),
region VARCHAR2(12) DEFAULT 'Unknown');
Table created.
SQL> CREATE TABLE ordertab

Table created.
SQL> ALTER TABLE ordertab

ADD CONSTRAINT cust_fk
FOREIGN KEY (custid) REFERENCES active_customer(custid);
Table altered.
SQL> CREATE INDEX order_idx on ordertab (custid);
TimesTen automatically checks for missing constraints when each CREATE CACHE
GROUP is issued. In the following example, a single cache group is created that includes
the active_customer table. Only a warning is issued since the active_customer is the
referenced table and the referencing table, ordertab, is not in any AWT cache group.
The active_customer table is not marked for serialized transactions.
CREATE WRITETHROUGH CACHE GROUP update_cust
name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12));
Warning 5297: The following Oracle foreign key constraints on AWT cache table
SALES.ACTIVE_CUSTOMER contain cached columns that do not have corresponding
foreign key constraints on TimesTen: SALES.CUST_FK [Outside of CG].
The following example creates two AWT cache groups on TimesTen, one that includes
the active_customer table and the other includes the ordertab table. There is a
missing foreign key constraint between the cache groups. Thus, a warning is issued
for both tables, but only the ordertab table is marked for serial transactions since it is
the referencing table that should contain the foreign key.
CREATE WRITETHROUGH CACHE GROUP update_cust
name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12);
Warning 5297: The following Oracle foreign key constraints on AWT cache table
sales.update_customer contain cached columns that do not have corresponding
foreign key constraints on TimesTen: ordertab.cust_fk [Outside of CG].
CREATE WRITETHROUGH CACHE GROUP update_orders

FROM sales.ordertab
Warning 5295: Propagation will be serialized on AWT cache table
SALES.ORDERTAB because the following Oracle foreign key constraints on this
table contain cached columns that do not have corresponding foreign key
constraints on TimesTen: ORDERTAB.CUST_FK [Across AWT cache groups].
7-14
Chapter 7
Manually Initiate Check for Missing Constraints for an AWT Cache Group
The ttCacheCheck built-in procedure performs the same check for missing constraints for
cached tables on the Oracle database as performed automatically by TimesTen.
The ttCacheCheck provides appropriate messages about missing constraints and the tables
marked for serialized propagation. With the ttCacheCheck built-in procedure, you can check
for missing constraints for a given cache group or for all cache groups in TimesTen to ensure
that all cache groups are not missing constraints.
Note:
Since ttCacheCheck updates system tables to indicate if DML performed against a
table should or should not be serialized, you must commit or roll back after the
ttCacheCheck built-in completes.
See ttCacheCheck in the Oracle TimesTen In-Memory Database Reference.
You may need to manually call the ttCacheCheck built-in procedure to update the known
dependencies after any of the following scenarios:
• After dropping a series of AWT cache groups on TimesTen with the DROP CACHE GROUP
statement.
• After adding or dropping a unique index, unique constraint, or foreign key on an Oracle
Database table that is cached in an AWT cache group. If you do not call the
ttCacheCheck built-in procedure after adding a constraint, you may receive a run time
error on the AWT cache group. After dropping a constraint, TimesTen may serialize
transactions even if it is not necessary. Calling the ttCacheCheck built-in procedure
verifies whether serialization is necessary.
• You can use this built-in procedure to determine why some transactions are being
serialized.
Note:
The ttCacheCheck built-in procedure cannot be called while the replication agent is
running.
If a DDL statement is being performed on an AWT cache group when ttCacheCheck
is called, then ttCacheCheck waits for the statement to complete or until the timeout
period is reached.
If you have not defined the CacheAwtParallelism data store attribute to greater
than one or the specified cache group is not an AWT cache group, then the
ttCacheCheck built-in procedure returns an empty result set.
The following example shows the user manually running the ttCacheCheck built-in procedure
to determine if there are any missing constraints for an AWT cache group update_orders that
is owned by cacheadmin. A result set is returned that includes the error message. The
7-15
Chapter 7
ordertab table in the update_orders cache group is marked for serially propagated
transactions.
Command> call ttCacheCheck(NULL, 'cacheadmin', 'update_orders');
< CACHEADMIN, UPDATE_ORDERS, CACHEADMIN, ORDERTAB, Foreign Key, CACHEADMIN,

CUST_FK, 1, Transactions updating this table will be serialized to Oracle
because: The missing foreign key connects two AWT cache groups.,
table CACHEADMIN.ORDERTAB constraint CACHEADMIN.CUST_FK foreign key(CUSTID)
references CACHEADMIN.ACTIVE_CUSTOMER(CUSTID) >
1 row found.
Whenever the cache group schema changes in either the TimesTen or Oracle
databases, you can call ttCacheCheck against all AWT cache groups to verify all
constraints. The following example shows the user manually running the ttCacheCheck
built-in procedure to determine if there are any missing constraints for any AWT cache
group in the entire TimesTen database by providing a NULL value for all input
parameters. A result set is returned that includes any error messages.
Command> call ttCacheCheck(NULL, NULL, NULL);
< CACHEADMIN, UPDATE_ORDERS, CACHEADMIN, ORDERTAB, Foreign Key, CACHEADMIN,

CUST_FK, 1, Transactions updating this table will be serialized to Oracle
because: The missing foreign key connects two AWT cache groups.,
table CACHEADMIN.ORDERTAB constraint CACHEADMIN.CUST_FK foreign key(CUSTID)
references CACHEADMIN.ACTIVE_CUSTOMER(CUSTID) >
1 row found.
Configuring Batch Size for Parallel Propagation for AWT Cache Groups
When using AWT cache groups, TimesTen batches together one or more transactions
that are to be applied in parallel to the back-end Oracle database. The
CacheParAwtBatchSize parameter configures a threshold value for the number of rows
included in a single batch. Once the maximum number of rows is reached, TimesTen
includes the rest of the rows in the transaction (TimesTen does not break up any
transactions), but does not add any more transactions to the batch.
For example, a user sets the CacheParAwtBatchSize to 200. For the next AWT
propagation, there are three transactions, each with 120 rows, that need to be
propagated and applied to the Oracle database. TimesTen includes the first two
transactions in the first batch for a total of 240 rows. The third transaction is included in
a second batch.
The default value for the CacheParAwtBatchSize parameter is 125 rows. The minimum
value is 1. See ttDBConfig in the Oracle TimesTen In-Memory Database Reference.
You can retrieve the current value of CacheParAwtBatchSize as follows:
call ttDBConfig('CacheParAwtBatchSize');
< CACHEPARAWTBATCHSIZE, 125 >
1 row found.
You can set the CacheParAwtBatchSize parameter to 200 as follows:

call ttDBConfig('CacheParAwtBatchSize','200');
< CACHEPARAWTBATCHSIZE, 200 >
1 row found
Set the CacheParAwtBatchSize parameter only when advised by Oracle Support, who
analyzes the workload and any dependencies in the workload to determine if a
7-16
Chapter 7
Improving Performance for Autorefresh Operations
different value for CacheParAwtBatchSize could improve performance. Dependencies exist

when transactions concurrently change the same data. Oracle Support may advise you to
reduce this value if there are too many dependencies in the workload.
Improving AWT Throughput With SQL Array Processing

The CacheAWTMethod connection attribute setting determines whether to use the PL/SQL
processing method or SQL array processing method for asynchronous writethrough
propagation when applying changes to the Oracle database.
• PL/SQL processing method: AWT bundles all pending operations into a single PL/SQL
collection that is sent to the Oracle database server to be performed. This processing
method is appropriate when there are mixed transactions and network latency between
TimesTen and the Oracle database server. It is efficient for most use cases when the
workload consists of mixed INSERT, UPDATE, and DELETE statements to the same or
different tables. By default, TimesTen uses the PL/SQL processing method
(CacheAWTMethod=1).
• SQL array processing method: Consider changing CacheAWTMethod to 0 when the
changes consist of mostly repeated sequences of the same operation (INSERT, UPDATE, or
DELETE) against the same table. For example, SQL array processing is very efficient
when a user does an update that affects several rows of a table. Updates are grouped
together and sent to the Oracle database in a single batch.
The PL/SQL processing method transparently falls back to SQL array processing mode
temporarily when it encounters one of the following:
• A statement that is over 32761 bytes in length.
• A statement that references a column of type BINARY FLOAT, BINARY DOUBLE and
VARCHAR/VARBINARY of length greater than 4000 bytes.
Note:
You can also set this value with the ttDBConfig built-in procedure with the
CacheAwtMethod parameter. See ttDBConfig in the Oracle TimesTen In-Memory
Database Reference.
See CacheAWTMethod in Oracle TimesTen In-Memory Database Reference.

There are best practice recommendations to improve performance for autorefresh operations.
• Minimizing Delay for Cached Data With Continuous Autorefresh
• Reducing Contention for Dynamic Read-Only Cache Groups With Incremental
Autorefresh
• Reducing Lock Contention for Read-Only Cache Groups With Autorefresh and Dynamic
Load
• Options for Reducing Contention Between Autorefresh and Dynamic Load Operations
• Improving Performance When Reclaiming Memory During Autorefresh Operations
7-17
Chapter 7
• Running Large Transactions With Incremental Autorefresh Read-Only Cache

Groups
• Configuring a Select Limit for Incremental Autorefresh for Read-Only Cache
Groups
Minimizing Delay for Cached Data With Continuous Autorefresh

You can specify continuous autorefresh with an autorefresh interval of 0 milliseconds.
With continuous autorefresh, the next autorefresh cycle is scheduled as soon as
possible after the last autorefresh cycle has ended.
Continuous autorefresh could result in a higher resource usage when there is a low
workload rate on the Oracle database, since the cache agent could be performing
unnecessary round-trips to the Oracle database.
See CREATE CACHE GROUP and ALTER CACHE GROUP in the Oracle TimesTen
In-Memory Database SQL Reference.
Reducing Contention for Dynamic Read-Only Cache Groups With

Incremental Autorefresh
Most autorefresh and dynamic load operations coordinate their access to the Oracle
database for correctness. The default TimesTen coordination behavior could result in
contention between autorefresh and dynamic load operations (in extreme cases).
If you have dynamic read-only cache groups with incremental autorefresh, then:
• Multiple dynamic load operations could be blocked by autorefresh operations.
• Autorefresh operations are frequently delayed while waiting for dynamic load
operations to complete.
Enabling the DynamicLoadReduceContention database system parameter is useful for
dynamic cache groups by changing the way that autorefresh and dynamic load
operations coordinate, which results in reduced contention between autorefresh and
dynamic load operations.
• Dynamic load operations are never blocked by autorefresh operations (due to
additional synchronization).
• Autorefresh operations are not completely delayed by dynamic load operations.
Instead, autorefresh operations will wait a short while for concurrently executing
dynamic load operations to be notified that a new autorefresh operation is starting.
This enables dynamic load operations to synchronize in tandem with concurrently
executing autorefresh operations.
Note:
You cannot change the value of the DynamicLoadReduceContention
database system parameter if there are any dynamic read-only cache groups
or if the cache or replication agents are running. In order to change the value
of this parameter, you must unload and drop (and later recreate) any existing
dynamic read only cache groups, then stop the cache and replication agents.
7-18
Chapter 7
The following example sets DynamicLoadReduceContention=1:

call ttDbConfig('DynamicLoadReduceContention','1');
You can query the current value of the DynamicLoadReduceContention parameter.

call ttDbConfig('DynamicLoadReduceContention');
Note:
See ttDBConfig in the Oracle TimesTen In-Memory Database Reference.
Requirements for Setting DynamicLoadReduceContention

There are requirements when using the DynamicLoadReduceContention database system
parameter.
The DynamicLoadReduceContention database system parameter requires the following to be
enabled:
• Required Oracle Database privileges: You must grant two additional Oracle Database
privileges to the cache administration user:
– EXECUTE ON SYS.DBMS_FLASHBACK
– SELECT ANY TRANSACTION
These are granted to the cache administration user when you execute the
grantCacheAdminPrivileges.sql and initCacheAdminSchema.sql scripts.
• Support for Oracle Database: This feature requires the use of the Oracle Database
Flashback Transaction Queries.With Oracle Database 12.2.0.1 with Multitenant option,
Flashback Transaction Queries only supports Local Undo. You cannot use this feature
with Oracle Database 12.2.0.1 Multitenant option with Shared Undo.
• Required settings for active standby pair replication scheme:
– Both active and standby masters must be installed. If you are replicating between
active and standby masters where each is installed with different TimesTen versions,
then this parameter cannot be enabled if one of the TimesTen versions does not
support this feature.
– The DynamicLoadReduceContention database system parameter must be set to the
same value on both the active and standby masters.
Otherwise, an error is written to the daemon log. Replication will not progress until the
settings and TimesTen versions conform on both the active and standby masters.
Reducing Lock Contention for Read-Only Cache Groups With Autorefresh

and Dynamic Load
Your application can time out because of a lock contention between autorefresh and dynamic
load requests.
An autorefresh operation automatically loads committed changes on cached Oracle
Database tables into the cache tables in TimesTen. A dynamic load operation requests data
7-19
Chapter 7
from the Oracle database (originating from a SELECT statement) and inserts the rows
into the cache group. Both the autorefresh and dynamic load operations require
access to the cache metadata, which could cause a lock contention.
At the end of an autorefresh operation, TimesTen updates the metadata to track the
autorefresh progress. If you have requested guaranteed durability by setting the
DurableCommits connection attribute to 1, then the autorefresh updates to the
metadata are always durably committed. If you have requested delayed durability by
setting the DurableCommits connection attribute to 0 (the default), then TimesTen must
ensure that the autorefresh updates to the metadata are durably committed before the
garbage collector can clean up the autorefresh tracking tables stored in the Oracle
database.
When a durable commit is initiated for the metadata, any previous non-durable
committed transactions in the transaction log buffer that have not been flushed to the
file system are also a part of the durable commit. On hosts with busy or slow file
systems, the durable commit could be slow enough to lock out dynamic load requests
for an undesirable amount of time.
If you notice that your application is timing out because of a lock contention between
autorefresh and dynamic load requests, you can set the CacheCommitDurable cache
configuration parameter to 0 with the ttCacheConfig built-in procedure. This reduces
the occurrence of lock contention between autorefresh and dynamic load requests in
the same application by:
• Running a non-durable commit of the autorefresh changes made to the metadata.
• Using a separate thread in the cache agent to durably commit the autorefresh
changes before the garbage collector cleans up the autorefresh tracking tables
stored in the Oracle database. This results in a slight performance cost as garbage
collection is delayed until after the durable commit completes.
The lock is removed after the non-durable commit of the autorefresh changes to the
metadata. After which, there is no longer a lock held on the metadata and any dynamic
load requests for the recently refreshed tables can continue processing without
waiting. However, if there is an error and database recovery starts, autorefresh may
need to reapply any committed transactions that did not flush to disk before a failure.
The following example sets CacheCommitDurable=0:
call ttCacheConfig('CacheCommitDurable',,,'0');
You can query the current value of the CacheCommitDurable parameter.

call ttCacheConfig('CacheCommitDurable');
Options for Reducing Contention Between Autorefresh and Dynamic

Load Operations
There are two methods to reduce contention between autorefresh and dynamic load
operations.
You can enable each or both if:
• If you see error messages indicating lock contention between autorefresh and
dynamic load operations, then enable the DynamicLoadReduceContention
7-20
Chapter 7
database system parameter by setting the value to 1 with the ttDbConfig built-in
procedure. See Reducing Contention for Dynamic Read-Only Cache Groups With
Incremental Autorefresh.
• If you notice that commit operations for autorefresh are taking an unusually long time,
then look for a TT47087 informational message in the support log. Locate the
tt1stXactCommitTime and tt2ndXactCommitTime entries within this message. If the time
indicated for either of both of these entries unusually high or is a major portion of the time
indicated in the Duration entry, this may indicate that the durable commit of transaction
logs is slow. In this case, you have the option to set the CacheCommitDurable cache
configuration parameter to 0 with the ttCacheConfig built-in procedure. For more details
on the CacheCommitDurable cache configuration parameter, see Reducing Lock
Contention for Read-Only Cache Groups With Autorefresh and Dynamic Load.
Enable both options if there is a small autorefresh interval in conjunction with a high number
of dynamic load requests.
Improving Performance When Reclaiming Memory During Autorefresh

Operations
As described Transaction Reclaim Operations in the Oracle TimesTen In-Memory Database
Operations Guide, TimesTen resource cleanup occurs during the reclaim phase of a
transaction commit.
To improve performance, a number of transaction log records are cached in memory to
reduce the need to access the transaction log file in the commit buffer. However, TimesTen
must access the transaction log if the transaction is larger than the reclaim buffer.
When you are using autorefresh for your cache groups, the cache agent has its own reclaim
buffer to manage the transactions that are committed within autorefresh operations. If the
cache agent reclaim buffer is too small, the commit operations during autorefresh can take
longer than expected as it must access the transaction log file. To avoid any performance
issues, you can configure a larger reclaim buffer for the cache agent so that the cache agent
can handle larger transactions in memory at reclaim time.
When using an active standby pair replication scheme to replicate autorefresh operations, the
replication agent applies the same autorefresh operations as part of the replication. Thus, the
replication agents on both the active and standby nodes have their own reclaim buffers that
should be configured to be the same size or greater than the cache agent reclaim buffer.
The ttDbConfig built-in procedure provides the following parameters for setting the maximum
size for the reclaim buffers for both the cache agent and the replication agent. (The memory
for the reclaim buffers are allocated out of temporary memory.)
• CacheAgentCommitBufSize sets the maximum size for the reclaim buffer for the cache
agent.
• RepAgentCommitBufSize sets the maximum size for the reclaim buffer for the replication
agent. You should configure the maximum size for the reclaim buffer on both the active
and standby nodes. It is recommended that you set the size for the reclaim buffers to the
same value on both nodes, but not required.
7-21
Chapter 7
Note:
For more details, see ttDBConfig in the Oracle TimesTen In-Memory
Database Reference.
To determine if you should increment the size for the cache agent reclaim buffer,
evaluate the CommitBufMaxReached and CommitBufNumOverflows statistics provided by
the ttCacheAutorefIntervalStatsGet built-in procedure. See Retrieving Statistics on
Autorefresh Transactions.
Running Large Transactions With Incremental Autorefresh Read-Only

Cache Groups
At certain times, you may run large transactions, such as for the end of the month, the
end of a quarter, or the end of the year transactions. You may also have situations
where you modify or add a large amount of data in the Oracle database over a short
period of time.
For read-only cache groups with incremental autorefresh, TimesTen could run out of
permanent space when an autorefresh operation applies either of these cases.
Therefore, for these situations, you can configure an autorefresh transaction limit,
where the large amount of data is broken up, applied, and committed over several
smaller transactions.
Note:
The autorefresh transaction limit can only be set for static read-only cache
groups.
The ttCacheAutorefreshXactLimit built-in procedure enables you to direct

autorefresh to commit after running a specific number of operations. This option
applies to all incremental autorefresh read-only cache groups that are configured with
the same autorefresh interval.
Since the single transaction is broken up into several smaller transactions,
transactional consistency cannot be maintained while autorefresh is in progress. Once
the autorefresh cycle completes, the data is transactionally consistent. To protect
instance consistency, we recommend that you set the autorefresh transaction limit only
on cache groups with only a single table, since instance consistency between the
parent and child tables is not guaranteed. When the autorefresh transaction limit is
turned on, TimesTen does not enforce the foreign key relationship that protects
instance consistency. Once you turn off the autorefresh transaction limit for
incremental autorefresh read-only cache groups, both instance and transactional
consistency are maintained again.
7-22
Chapter 7
Note:
If you are using an active standby pair, you must call the
ttCacheAutorefreshXactLimit built-in procedure for the same values on both the
active and standby masters.
The following sections describe how to configure an autorefresh transaction limit.

• Using ttCacheAutorefreshXactLimit
• Example of Potential Transactional Inconsistency
• Retrieving Statistics to Evaluate Performance When a Transaction Limit is Set
Using ttCacheAutorefreshXactLimit
Note:
See ttCacheAutorefreshXactLimit in the Oracle TimesTen In-Memory Database
Reference.
For the month end processing, there can be a large number updates in a single transaction
for the Oracle tables that are cached in cache groups with autorefresh. In order to ensure that
the large transaction does not fill up permanent memory, you can enable autorefresh to
commit after every 256 (or any other user specified number) operations with the
ttCacheAutorefreshXactLimit built-in procedure.
Turn on an autorefresh transaction limit for incremental autorefresh read-only cache groups
before a large transaction with the ttCacheAutorefreshXactLimit built-in procedure where
the value is set to ON or to a specific number of operations. Then, when autorefresh finishes
updating the cached tables in TimesTen, turn off the autorefresh transaction limit for
incremental autorefresh read-only cache groups with the ttCacheAutorefreshXactLimit
built-in procedure.
The following example sets up the transaction limit to commit after every 256 operations for
all incremental autorefresh read-only cache groups that are defined with an interval value of
10 seconds.
call ttCacheAutorefreshXactLimit('10000', 'ON');
After the month end process has completed and the incremental autorefresh read-only cache
groups are refreshed, disable the transaction limit for incremental autorefresh read-only
cache groups that are defined with the interval value of 10 seconds.
call ttCacheAutorefreshXactLimit('10000', 'OFF');
To enable the transaction limit for incremental autorefresh read-only cache groups to commit
after every 1024 operations, provide 1024 as the value as follows:
call ttCacheAutorefreshXactLimit('10000', '1024');
7-23
Chapter 7
Example of Potential Transactional Inconsistency

This example shows how to create two incremental autorefresh read-only cache
groups.
The following example uses the employee and departments table, where the
department id of the department table is a foreign key that points to the department id
of the employee table.
The following example creates two incremental autorefresh read-only cache groups,
where each is in its own cache group. The autorefresh transaction limit is enabled with
ttCacheAutorefreshXactLimit before a large transaction and is disabled after it
completes.
1. Before you initiate the large transaction, invoke ttCacheAutorefreshXactLimit to
set the interval value and the number of operations after which to automatically
commit. The following sets the number of operations to three (which is intentionally
low to show a brief example) for all incremental autorefresh read-only cache
groups with a two second interval.
CALL ttCacheAutorefreshXactLimit('2000', '3');
< 2000, 3 >
1 row found.
2. Create the incremental autorefresh read-only cache groups with interval of two
seconds. This example creates two static (non-dynamic) read-only cache groups,
where each contains a single table.
CREATE READONLY CACHE GROUP cgDepts AUTOREFRESH MODE INCREMENTAL
INTERVAL 2 SECONDS
FROM departments
( department_id NUMBER(4) PRIMARY KEY
, department_name VARCHAR2(30) NOT NULL
, manager_id NUMBER(6)
, location_id NUMBER(4)
);
CREATE READONLY CACHE GROUP cgEmpls AUTOREFRESH MODE INCREMENTAL

INTERVAL 2 SECONDS
FROM employees
( employee_id NUMBER(6) PRIMARY KEY
, first_name VARCHAR2(20)
, last_name VARCHAR2(25) NOT NULL
, email VARCHAR2(25) NOT NULL UNIQUE
, phone_number VARCHAR2(20)
, hire_date DATE NOT NULL
, job_id VARCHAR2(10) NOT NULL
, salary NUMBER(8,2)
, commission_pct NUMBER(2,2)
, department_id NUMBER(4)
);
3. Run a LOAD CACHE GROUP statement for both cache groups with autorefresh.
LOAD CACHE GROUP cgDepts COMMIT EVERY 256 ROWS;
LOAD CACHE GROUP cgEmpls COMMIT EVERY 256 ROWS;

7-24
Chapter 7
You can have inconsistency within the table during an autorefresh as shown with the
employees table.
1. On TimesTen, select the minimum and maximum salary of all employees.
SELECT MIN(salary), MAX(salary) FROM employees;
< 2100, 24000 >
1 row found.
2. On the Oracle database, add 100,000 to everyone's salary.

UPDATE employees SET salary = salary + 100000;
107 rows updated.
3. On TimesTen, when you run the SELECT again (while the autorefresh transactions are
commmitted after every 3 records), it shows that while the maximum salary has updated,
the minimum salary is still the old value.
< 2100, 124000 >
1 row found.
4. However, once the autorefresh completes, transactional consistency is maintained. For

this example, once the autorefresh process completes, all salaries have increased by
100,000.
< 102100, 124000 >
1 row found.
5. The large transaction is complete, so disable the transaction limit for cache groups with a
2 second interval autorefresh.
You can have transactional inconsistency between cache groups if you run a SQL statement
while the autorefresh process is progressing. The following SELECT statement example runs
against the employees and department table in the cgDepts autorefresh cache group. With
this example, since the foreign key is not enforced on TimesTen and the autorefresh process
applies several transactions, the employee table updates may be inserted before the
department updates.
In addition, all of the updates for both tables in the cache group are not applied until the
autorefresh cycle has completed. In the following example, the SELECT statement is
performed before the autorefresh process is complete. Thus, the results do not show all of
the expected data, such as the department name and several employees (some of the
lawyers in the legal department 1000) are missing.
SELECT e.department_id, d.DEPARTMENT_NAME, e.FIRST_NAME, e.LAST_NAME
FROM employees e, departments d
WHERE e.DEPARTMENT_ID = d.DEPARTMENT_ID (+)
AND e.department_id >= 1000 ORDER BY 1,2,3,4;
< 1000, Legal, Alec, Dunkle >
< 1000, Legal, Barry, Strong >
< 1000, Legal, Leigh, Harrison >
3 rows found.
However, after the autorefresh process completes, transactional consistency is maintained.

The following shows the same SELECT statement performed after the autorefresh is complete.
All expected data, the department information and all of the new lawyers, are updated.
SELECT e.department_id, d.DEPARTMENT_NAME, e.FIRST_NAME, e.LAST_NAME
7-25
Chapter 7
WHERE e.DEPARTMENT_ID = d.DEPARTMENT_ID (+)

AND e.department_id >= 1000 ORDER BY 1,2,3,4;
< 1000, Legal, Alec, Dunkle >
< 1000, Legal, Barry, Strong >
< 1000, Legal, Leigh, Harrison >
< 1000, Legal, John, Crust >
< 1000, Legal, Robert, Wright >
< 1000, Legal, Robert, Smith >
6 rows found.
For cache groups with autorefresh that have more than one table, you can also
experience transactional inconsistency if you run SQL statements while the
autorefresh process is in progress.
1. Initiate the transaction limit for incremental cache groups with autorefresh of 2
seconds with the ttCacheAutorefreshXactLimit built-in procedure and create a
single autorefresh cache group with two tables: the employees and departments
tables.
CALL ttCacheAutorefreshXactLimit('2000', '3');
< 2000, 3 >
1 row found.
CREATE READONLY CACHE GROUP cgDeptEmpls AUTOREFRESH MODE INCREMENTAL

INTERVAL 2 SECONDS
FROM departments
( department_id NUMBER(4) PRIMARY KEY
, department_name VARCHAR2(30) NOT NULL
, location_id NUMBER(4)
)
, employees
( employee_id NUMBER(6) PRIMARY KEY
, first_name VARCHAR2(20)
, last_name VARCHAR2(25) NOT NULL
, email VARCHAR2(25) NOT NULL UNIQUE
, phone_number VARCHAR2(20)
, hire_date DATE NOT NULL
, job_id VARCHAR2(10) NOT NULL
, salary NUMBER(8,2)
, commission_pct NUMBER(2,2)
, department_id NUMBER(4)
, foreign key(department_id) references departments(department_id)
);
2. Manually load the cache group.

LOAD CACHE GROUP cgDeptEmpls COMMIT EVERY 256 ROWS;
3. Run a SELECT statement on TimesTen that uploads all of the legal department
data.
SELECT e.department_id, d.department_name, count(*)
WHERE e.department_id = d.department_id (+)
GROUP BY e.department_id, d.department_name
ORDER BY 1 desc;
< 110, Accounting, 2 >
< 100, Finance, 6 >
< 90, Executive, 3 >
7-26
Chapter 7
< 80, Sales, 34 >

< 70, Public Relations, 1 >
< 60, IT, 5 >
< 50, Shipping, 45 >
< 40, Human Resources, 1 >
< 30, Purchasing, 6 >
< 20, Marketing, 2 >
< 10, Administration, 1 >
11 rows found.
4. On Oracle, insert a new legal department, numbered 1000, with 6 new lawyers in both
the employee and department tables.
5. When performing a SELECT statement on TimesTen during the autorefresh process, only
data on two of the lawyers in department 1000 have been uploaded into TimesTen.
SELECT e.department_id, d.department_name, count(*)
ORDER BY 1 desc;
< 1000, Legal, 2 >
< 100, Finance, 6 >
< 80, Sales, 34 >
< 60, IT, 5 >
12 rows found.
6. However, after the autorefresh process completes, all 6 employees (lawyers) in the legal
department have been uploaded to TimesTen. Now, it is transactionally consistent.
SELECT e.department_id, d.department_name, COUNT(*)
ORDER BY 1 desc;
< 1000, Legal, 6 >
< 100, Finance, 6 >
< 80, Sales, 34 >
< 60, IT, 5 >
12 rows found.
7. The large transaction is complete, so disable the transaction limit for cache groups with a
2 second autorefresh interval.
7-27
Chapter 7
Retrieving Statistics to Evaluate Performance When a Transaction Limit is Set

To see how a autorefresh transaction limit for a particular autorefresh interval is
performing, you can retrieve statistics for the last 10 incremental autorefresh
transactions for this autorefresh interval with the ttCacheAutorefIntervalStatsGet
built-in procedure.
See Retrieving Statistics on Autorefresh Transactions.
Configuring a Select Limit for Incremental Autorefresh for Read-Only

Cache Groups
To facilitate incremental autorefresh for read-only cache groups, TimesTen runs a table
join query on both the Oracle database base table and its corresponding change log
table to retrieve the incremental changes. However, if both tables are very large, the
join query can be slow. In addition, if the Oracle database base table is continuously
updated while the join-query is processing, you may receive the ORA-01555 “Snapshot
too old" error from a long-running autorefresh query.
To avoid this situation, you can configure incremental autorefresh with a select limit for
static read-only cache groups, which joins the Oracle database base table with a
limited number of rows from the autorefresh change log table. You can configure a
select limit with the ttCacheAutorefreshSelectLimit built-in procedure.
Note:
The select limit can only be set for static read-only cache groups. To protect
instance consistency, we recommend that you set the select limit only on
cache groups with only a single table.
Autorefresh continues to apply changes to the cached table incrementally until all the
rows in the autorefresh change log table have been applied. When there are no rows
left to apply, the autorefresh thread sleeps for the rest of the interval period.
Note:
See ttCacheAutorefreshSelectLimit in the Oracle TimesTen In-Memory
Database Reference.
For example, before a large transaction, you can call the

ttCacheAutorefreshSelectLimit built-in procedure to set a select limit to 1000 rows
for cache groups with incremental autorefresh where the interval value is 10 seconds.
The following example sets the value to ON.
Command> call ttCacheAutorefreshSelectLimit('10000', 'ON');
< 10000, ON >
1 row found.
7-28
Chapter 7
The following example set a select limit to 2000 rows for cache groups with incremental
autorefresh where the interval value is 7 seconds.
Command> call ttCacheAutorefreshSelectLimit('7000', '2000');
< 7000, 2000 >
1 row found.
You can disable any select limit for cache groups with incremental autorefresh where the
interval value is 10 seconds by setting the value to OFF.
Command> call ttCacheAutorefreshSelectLimit('10000', 'OFF');
< 10000, OFF >
1 row found.
The following sections describe details when configuring a select limit for static read-only
cache groups with incremental autorefresh.
• See How to Determine Which Intervals Have a Particular Select Limit to determine which
intervals have a select limit.
• See Retrieving Statistics on Autorefresh Transactions to retrieve statistics for incremental
autorefresh transactions for this autorefresh interval. This determines how a select limit
for a particular autorefresh interval is performing.
How to Determine Which Intervals Have a Particular Select Limit

To determine the interval for a cache group, use ttIsql and run the cachegroups command.
> cachegroups cgowner.cgname;
This returns all attributes for the cgowner.cgname cache group including the interval.
To determine which intervals have a select limit, you can run the following query on the
Oracle database where <cacheAdminUser> is the cache administrator, <hostName> is the host
name of the machine where the TimesTen database is located, <databaseFileName> is the
database path taken from the DataStore attribute, and substitute the version number (such
as 07) for the xx.
SELECT * FROM <cacheAdminUser>.tt_xx_arinterval_params
WHERE param='AutorefreshSelectEveryN'
AND host='<hostName>'
AND database like '%<databaseFileName>%'
ORDER BY arinterval;
For example, if the cache administrator user name is pat, the host name is myhost, the
database file name is myTtDb, and 07 is substituted for xx that is the TimesTen minor release
number then:
SELECT * FROM pat.tt_07_arinterval_params
WHERE param='AutorefreshSelectEveryN'
AND host='myhost'
AND database like '%myTtDb%'
ORDER BY arinterval;
The interval is stored in milliseconds.
7-29
Chapter 7
Retrieving Statistics on Autorefresh Transactions
Retrieving Statistics to Evaluate Performance When Using a Select Limit

To see how a select limit for a particular autorefresh interval is performing, you can
retrieve statistics for incremental autorefresh transactions for this autorefresh interval
with the ttCacheAutorefIntervalStatsGet built-in procedure.
See Retrieving Statistics on Autorefresh Transactions.
Retrieving Statistics on Autorefresh Transactions

Call the ttCacheAutorefIntervalStatsGet built-in procedure for statistical information
about the last 10 autorefresh cycles for a particular autorefresh interval defined for an
incremental autorefresh read-only cache group.
Note:
See ttCacheAutorefIntervalStatsGet in the Oracle TimesTen In-Memory
Database Reference.
This built-in procedure is useful if you have set an transaction limit or a select
limit for incremental, autorefresh read-only cache groups. See Running
Large Transactions With Incremental Autorefresh Read-Only Cache Groups
and Configuring a Select Limit for Incremental Autorefresh for Read-Only
Cache Groups.
The following example shows how to call the ttCacheAutorefIntervalStatsGet built-

in procedure to retrieve statistics for incremental autorefresh read-only cache groups
that have been defined as static and have the interval of 2 seconds:
Command> call ttCacheAutorefIntervalStatsGet(2000, 1);
< 2000, 1, 21, 2013-04-30 06:05:38.000000, 100, 3761, 3761, 822, 1048576,
1280, 0, 58825, 63825, 13590, 0, 0, 0, 0, 0 >
< 2000, 1, 20, 2013-04-30 06:05:37.000000, 100, 85, 85, 18, 1048576, 1280,
0, 55064, 60064, 12768, 0, 0, 0, 0, 0 >
< 2000, 1, 19, 2013-04-30 06:05:32.000000, 100, 3043, 3043, 666, 1048576,
1280, 0, 54979, 59979, 12750, 0, 0, 0, 0, 0 >
< 2000, 1, 18, 2013-04-30 06:05:30.000000, 100, 344, 344, 74, 1048576,
1280, 0, 51936, 56936, 12084, 0, 0, 0, 0, 0 >
< 2000, 1, 17, 2013-04-30 06:05:28.000000, 100, 1826, 1826, 382, 1048576,
1280, 0, 51592, 56592, 12010, 0, 0, 0, 0, 0 >
< 2000, 1, 16, 2013-04-30 06:05:26.000000, 100, 55, 55, 12, 1048576,
1280, 0, 49766, 54766, 11628, 0, 0, 0, 0, 0 >
< 2000, 1, 15, 2013-04-30 06:05:22.000000, 100, 2901, 2901, 634, 1048576,
1280, 0, 49711, 54711, 11616, 0, 0, 0, 0, 0 >
< 2000, 1, 14, 2013-04-30 06:05:21.000000, 100, 55, 55, 12, 1048576,
1280, 0, 46810, 51810, 10982, 0, 0, 0, 0, 0 >
< 2000, 1, 13, 2013-04-30 06:05:10.000000, 100, 5844, 5844, 1263, 1048576,
1280, 0, 46755, 51755, 10970, 0, 0, 0, 0, 0 >
< 2000, 1, 12, 2013-04-30 06:05:08.000000, 100, 607, 607, 132, 1048576,
1280, 0, 40911, 45911, 9707, 0, 0, 0, 0, 0 >
10 rows found.
7-30
Chapter 7
Caching the Same Oracle Table on Two or More TimesTen Databases
Caching the Same Oracle Table on Two or More TimesTen

Databases
For each cache administration user, TimesTen creates a change log table and trigger (as part
of what is created to manage caching) in the Oracle database for each cache table in the
cache group. A trigger is fired for each committed insert, update, or delete operation on the
cached Oracle Database table; the action is logged in the change log table.
If you cache the same Oracle database table in a cache group on two different TimesTen
databases, we recommend that you use the same cache administration user name on both
TimesTen databases as the owner of the cache table on each TimesTen database.
When you use the same cache administration user, only one trigger and change log table are
created to manage the changes to the base table. Thus, it is efficient and does not slow down
the application.
If you create separate cache administration users on each TimesTen database to own the
cache group that caches the same Oracle table, then separate triggers and change log tables
exist on the Oracle database for the same table: one for each cache administration user. For
example, if you have two separate TimesTen databases, each with their own cache
administration user, two triggers fire for each DML operation on the base table, each of which
are stored in a separate change log table. Firing two triggers and managing the separate
change log tables can slow down the application.
The only reason to create separate cache administration users is if one of the TimesTen
databases that caches the same table has a slow autorefresh rate or a slow connection to the
Oracle database. In this case, having a single cache administration user on both TimesTen
databases slows down the application on the faster connection, as it waits for the updates to
be propagated to the slower database.
7-31
8
Cleaning Up the Caching Environment
There are specific tasks that need to be performed in the TimesTen and Oracle databases to
drop cache groups. You should shut down all components when using AWT cache groups.
• Stopping the Replication Agent
• Dropping a Cache Group
• Stopping the Cache Agent
• Destroying the TimesTen Databases
• Dropping Oracle Database Users and Objects
• Scheduling a Shutdown of Active Standby Pair With AWT Cache Groups
Stopping the Replication Agent

If you are using AWT cache groups that use an active standby pair replication scheme, call
the ttRepStop built-in procedure to stop the replication agent.
This must be done on each TimesTen database of the active standby pair including any read-
only subscriber databases, and any standalone TimesTen databases that contain AWT cache
groups.
From the cache1, cache2, cacheactive, cachestandby and rosubscriber databases, call the
ttRepStop built-in procedure as the TimesTen cache administration user to stop the
replication agent on the database:
Command> CALL ttRepStop;
Dropping a Cache Group

Use the DROP CACHE GROUP statement to drop a cache group and its cache tables.
Oracle Database objects used to manage the caching of Oracle Database data are
automatically dropped when you use the DROP CACHE GROUP statement to drop a cache group,
or an ALTER CACHE GROUP statement to set the autorefresh state to OFF for cache groups with
autorefresh.
If you issue a DROP CACHE GROUP statement on a cache group that has an autorefresh
operation in progress:
• The autorefresh operation stops if the LockWait connection attribute setting is greater
than 0. The DROP CACHE GROUP statement preempts the autorefresh operation.
• The autorefresh operation continues if the LockWait connection attribute setting is 0. The
DROP CACHE GROUP statement is blocked until the autorefresh operation completes or the
statement fails with a lock timeout error.
If you have created an AWT cache group, a replication scheme is created to enable
committed changes on its cache tables to be asynchronously propagated to the cached
8-1
Chapter 8
Oracle tables. This replication scheme is automatically dropped when you drop the
AWT cache group. Thus, perform the following before dropping an AWT cache group:
1. Use the ttRepSubscriberWait built-in procedure to make sure that all committed
changes on its cache tables have been propagated to the cached Oracle
Database tables before dropping the AWT cache group.
Command> CALL
ttRepSubscriberWait('_AWTREPSCHEME','TTREP','_ORACLE','sys1',-1);
2. The cache tables in an AWT cache group are replicated in an active standby pair.
If the cache tables are the only tables that are being replicated, drop the active
standby pair using a DROP ACTIVE STANDBY PAIR statement before dropping the
AWT cache groups.
Run the following statement as the TimesTen cache administration user on the
cacheactive, cachestandby and rosubscriber databases to drop the active
standby pair replication scheme:
Command> DROP ACTIVE STANDBY PAIR;
Command> exit
Perform the following when dropping a cache group:

1. Before you can drop a cache group, you must grant the DROP ANY TABLE privilege
to the TimesTen cache administration user. Run the following statement as the
instance administrator on the cache1, cache2, cacheactive and cachestandby
databases to grant the DROP ANY TABLE privilege to the TimesTen cache
administration user. The following example shows the SQL statement issued from
the cache1 database:
% ttIsql cache1
Command> GRANT DROP ANY TABLE TO cacheadmin;
Command> exit
2. Use a DROP CACHE GROUP statement to drop the cache groups from the standalone
TimesTen databases and, if using an AWT cache group, the active and standby
databases.
Run the following statement as the TimesTen cache administration user on the
cache1, cache2, cacheactive and cachestandby databases to drop the
subscriber_accounts cache group. The following example shows the SQL
statement issued from the cache1 database:
Command> DROP CACHE GROUP subscriber_accounts;
The DROP CACHE GROUP statement updates the metadata on the Oracle database.
The objects are dropped if no other TimseTen databases are caching the same
tables.

TimesTen provides commands to stop a cache agent.
• In TimesTen Scaleout, use ttGridAdmin dbCacheStop command to stop the cache
agent on all instances within the grid. See Stopping the Cache Agents for
TimesTen Scaleout in the Oracle TimesTen In-Memory Database Scaleout User's
Guide.
8-2
Chapter 8
Destroying the TimesTen Databases
• In TimesTen Classic, call the ttCacheStop built-in procedure to stop the cache agent.
This must be done on all standalone TimesTen databases and, if used, the active and
standby databases of the active standby pair.
From the cache1, cache2, cacheactive and cachestandby databases, issue the following
built-in procedure call to stop the cache agent on the database:
Command> CALL ttCacheStop;
Command> exit
Destroying the TimesTen Databases

TimesTen provides commands to destroy a TimesTen database.
1. Ensure you backup all your data, since it will be discarded in the destruction process.
2. Make sure that you drop all cache groups before you attempt to destroy a database. If
you cannot drop the cache groups, then use the -force option on the destroy operation
in the next step. See Dropping a Cache Group.
3. Perform the destroy operation:
• In TimesTen Scaleout, if the TimesTen database is no longer needed, you can use
the ttGridAdmin dbDestroy command to destroy the databases. See Destroying a
Database in the Oracle TimesTen In-Memory Database Scaleout User's Guide.
• In TimesTen Classic, if the TimesTen databases are no longer needed, you can use
the ttDestroy utility to destroy the databases.
Note:
In TimesTen Classic, if the RAM policy designates that the database stays
in memory, then this may prevent you from destroying the database. For
example, if the RAM policy is set to always, then you must change the RAM
policy to manual and run the ttAdmin -ramunload command to unload the
database before destroying the database. See Specifying a RAM Policy
section in the Oracle TimesTen In-Memory Database Operations Guide.
The following example shows the ttDestroy utility connecting to and then destroying
the cache1 database:
% ttDestroy cache1
4. If you used the -force option on the destroy operation, run the following script to cleanup
the metadata and Oracle database objects.
• For TimesTen Scaleout, run the scaleoutCacheCleanup.sql script.
• For TimesTen Classic, run the cacheCleanup.sql script.
See Installed SQL*Plus Scripts.
8-3
Chapter 8
Dropping Oracle Database Users and Objects
Dropping Oracle Database Users and Objects

Use SQL*Plus as the sys user to drop the schema user sales, the Oracle cache
administration user cacheadmin, and all objects such as tables and triggers owned by
these users.
Then drop the TT_CACHE_ADMIN_ROLE role, and the default tablespace cachetblsp
used by the Oracle cache administration user including the contents of the tablespace
and its data file.
SQL> DROP USER timesten CASCADE;
SQL> DROP USER sales CASCADE;
SQL> DROP USER cacheadmin CASCADE;
SQL> DROP ROLE TT_CACHE_ADMIN_ROLE;
SQL> DROP TABLESPACE cachetblsp INCLUDING CONTENTS AND DATAFILES;
SQL> exit
Also, you can run TimesTen SQL*Plus scripts to drop the Oracle Database objects
used to implement autorefresh operations. See Managing a Cache Environment With
Oracle Database Objects.
Scheduling a Shutdown of Active Standby Pair With AWT

Cache Groups
When you are using active standby pairs with AWT cache groups, the environment
includes both an active and a standby master, potentially one or more subscribers, and
at least one Oracle Database.
The following is the recommended method when you initiate a scheduled shutdown of
outstanding transactions in this environment. This order of events provides the time
needed to finish applying outstanding transactions before shut down and minimizes
the time needed to restart all components.
1. Shut down all applications.
2. Ensure that all transactions have propagated to the Oracle database.
3. Shut down TimesTen.
4. Shut down the Oracle Database.
Then, when you are ready to restart all components:
1. Restart the Oracle Database.
2. Restart TimesTen.
3. Restart any applications.
You can shut down all of these products in any order without error. The order matters
only to maximize performance and reduce the need for preserving unapplied
transactions. For example, when you are using AWT cache groups within the active
standby pair and if you shut down the Oracle database before TimesTen, then all
unapplied transactions accumulate in the TimesTen transaction logs. Thus, when you
restart TimesTen and Oracle, you could potentially have a lower throughput while
8-4
Chapter 8
Scheduling a Shutdown of Active Standby Pair With AWT Cache Groups
pending transactions are applied to the Oracle database. Thus, shutting down TimesTen
before the Oracle database provides the most efficient method for your scheduled shutdown
and startup. In addition, shutting down the applications before TimesTen stops any additional
requests from being sent to an unavailable TimesTen database.
8-5
9
Using Cache in an Oracle RAC Environment
The following sections describe how to use cache in an Oracle Real Application Clusters
(Oracle RAC) environment:
• How Cache Works in an Oracle RAC Environment
• Restrictions on Using Cache in an Oracle RAC Environment
• Setting Up Cache in an Oracle RAC Environment
How Cache Works in an Oracle RAC Environment

Oracle RAC enables multiple Oracle Database instances to access one Oracle database with
shared resources, including all data files, control files, PFILEs and redo log files that reside
on cluster-aware shared file systems. Oracle RAC handles read/write consistency and load
balancing while providing high availability.
Fast Application Notification (FAN) is an Oracle RAC feature that is integrated with Oracle
Call Interface (OCI) in Oracle Database. FAN publishes information about changes in the
cluster to applications that subscribe to FAN events. FAN prevents unnecessary operations
such as the following:
• Attempts to connect when services are down
• Attempts to finish processing a transaction when the server is down
• Waiting for TCP/IP timeouts
See Oracle Real Application Clusters Administration and Deployment Guide for more
information about Oracle RAC and FAN.
To facilitate cache operations, TimesTen uses OCI integrated with FAN to receive notification
of Oracle Database events. With FAN, TimesTen detects connection failures within a minute.
Without FAN, it can take several minutes for TimesTen to receive notification of an Oracle
Database failure. Without FAN, TimesTen detects a connection failure the next time the
connection is used or when a TCP/IP timeout occurs. TimesTen can recover quickly from
Oracle Database failures without user intervention.
TimesTen also uses Transparent Application Failover (TAF), which is a feature of Oracle Net
Services that enables you to specify how you want applications to reconnect after a failure.
See Oracle Database Net Services Administrator's Guide for more information about TAF.
TAF attempts to reconnect to the Oracle database for four minutes. If this is not successful,
the cache agent restarts and attempts to reconnect with the Oracle database every minute.
Note:
You can configure how long TAF retries when establishing a connection with the
AgentFailoverTimeout parameter. For details, see Setting Up Cache in an Oracle
RAC Environment.
9-1
Chapter 9
OCI applications can use one of the following types of Oracle Net failover functionality:
• None: No failover functionality is used. This can also be specified to prevent
failover from happening. This is the default failover functionality.
• Session: If an application's connection is lost, a new connection is automatically
created for the application. This type of failover does not attempt to recover
selects.
• Select: This type of failover enables applications that began fetching rows from a
cursor before failover to continue fetching rows after failover.
The behavior of cache operations depend on the actions of TAF and how TAF is
configured. By default, TAF and FAN callbacks are installed if you are using cache in
an Oracle RAC environment. If you do not want TAF and FAN capabilities, set the
RACCallback connection attribute to 0.
Table 9-1 shows the behaviors of cache operations in an Oracle RAC environment
with different TAF failover types.
Table 9-1 Behavior of Cache Operations in an Oracle RAC Environment
Operation TAF Failover Type Behavior After a Failed Connection on the

Oracle Database
Autorefresh None The cache agent automatically stops, restarts
and waits until a connection can be established
on the Oracle database. This behavior is the
same as in a non-Oracle RAC environment.
No user intervention is needed.
Autorefresh Session One of the following occurs:
• All failed connections are recovered.
Autorefresh operations that were in
progress are rolled back and retried.
• If TAF times out or cannot recover the
connection, the cache agent automatically
stops, restarts and waits until a connection
can be established on the Oracle database.
• In all cases, no user intervention is needed.
Autorefresh Select One of the following occurs:
• Autorefresh operations resume from the
point of connection failure.
• Autorefresh operations that were in
progress are rolled back and retried.
connection, the cache agent automatically
stops, restarts and waits until a connection
can be established on the Oracle database.
• In all cases, no user intervention is needed.
AWT None The receiver thread of the replication agent for
the AWT cache group exits. A new thread is
spawned and tries to connect to the Oracle
database.
9-2
Chapter 9
Table 9-1 (Cont.) Behavior of Cache Operations in an Oracle RAC Environment

Oracle Database
AWT Session, Select One of the following occurs:
• If the connection is recovered and there are
uncommitted DML operations in the
transaction, the transaction is rolled back
and then reissued.
• If the connection is recovered and there are
no uncommitted DML operations, new
operations can be issued without rolling
back.
In all cases, no user intervention is needed.
SWT, propagate, None The application is notified of the connection loss.
flush, and The cache agent disconnects from the Oracle
passthrough database and the current transaction is rolled
back. All modified session attributes are lost.
During the next passthrough operation, the
cache agent tries to reconnect to the Oracle
database. This behavior is the same as in a non-
Oracle RAC environment.
SWT, propagate, Session One of the following occurs:
flush and • The connection to the Oracle database is
passthrough Select
recovered. If there were open cursors, DML
SWT, propagate and or lock operations on the lost connection, an
flush error is returned and the user must roll back
the transaction before continuing.
Otherwise, the user can continue without
rolling back.
connection, the application is notified of the
connection loss. The cache agent
disconnects from the Oracle database and
the current transaction is rolled back. All
modified session attributes are lost.
During the next passthrough operation, the
cache agent tries to reconnect to the Oracle
database.
In this case, no user intervention is needed.
Passthrough Select The connection to the Oracle database is
recovered. If there were DML or lock operations
on the lost connection, an error is returned and
the user must roll back the transaction before
continuing. Otherwise, the user can continue
without rolling back.
Load and refresh None The application receives a loss of connection

error.
9-3
Chapter 9
Restrictions on Using Cache in an Oracle RAC Environment
Table 9-1 (Cont.) Behavior of Cache Operations in an Oracle RAC Environment

Oracle Database
Load and refresh Session One of the following occurs:
• The load or refresh operation succeeds.
• An error is returned stating that a fetch
operation on Oracle Database cannot be
processed.
Load and refresh Select One of the following occurs:
• If the Oracle Database cursor is open and
the cursor is recovered, or if the Oracle
Database cursor is not open, then the load
or refresh operation succeeds.
• An error is returned if TAF was unable to
recover either the session or open Oracle
Database cursors.
Note: An error is less likely to be returned than if
the TAF failover type is Session.
Restrictions on Using Cache in an Oracle RAC Environment

There are some restrictions for cache support of Oracle RAC.
The restrictions for cache support of Oracle RAC are:
• Cache operations are limited to Oracle RAC, FAN and TAF capabilities. For
example, if all nodes for a service fail, the service is not restarted. TimesTen waits
for the user to restart the service.
• TAF does not recover ALTER SESSION operations. The user is responsible for
restoring changed session attributes after a failover.
• For cache operations, TimesTen uses OCI integrated with FAN. This interface
automatically spawns a thread to wait for an Oracle Database event. This is the
only TimesTen feature that spawns a thread in a TimesTen application with the
direct driver. Adapt your application to account for this thread creation. If you do
not want the extra thread, set the RACCallback connection attribute to 0 so that
TAF and FAN are not used.
Setting Up Cache in an Oracle RAC Environment

You can set up a cache in a TimesTen database to cache data within an Oracle RAC
environment.
After you install Oracle RAC and cache, perform the following to set up a cache for an
Oracle RAC environment:
1. On TimesTen, set the TAF timeout, in minutes, with the ttCacheConfig
AgentFailoverTimeout parameter. The AgentFailoverTimeout parameter
configures how long TAF retries when establishing a connection. TAF attempts to
reconnect to the Oracle database for the duration of this timeout. The default is
four minutes. If this is not successful, the cache agent restarts and attempts to
9-4
Chapter 9
Setting Up Cache in an Oracle RAC Environment
reconnect with the Oracle database every minute; the replication agent restarts any
threads that cannot connect to the Oracle database.
If you are using TimesTen Scaleout, you must run the ttCacheConfig built-in procedure
on every data instance in the database. See ttCacheConfig in the Oracle TimesTen In-
2. Make sure that the TimesTen daemon, the cache agent, and the following Oracle
Database components are started:
• Oracle Database instances
• Oracle Database listeners
• Oracle Database service that is used for cache operations
3. Verify that the TimesTen RACCallback connection attribute is set to 1 (default). See
RACCallback in the Oracle TimesTen In-Memory Database Reference.
4. Use the DBMS_SERVICE.MODIFY_SERVICE function or Oracle Enterprise Manager to enable
publishing of FAN events. This changes the value in the AQ_HA_NOTIFICATIONS column of
the Oracle Database ALL_SERVICES view to YES.
See Oracle Database PL/SQL Packages and Types Reference for more information
about the DBMS_SERVICE Oracle Database PL/SQL package.
5. Enable TAF on the Oracle Database service used for cache operations on TimesTen with
one of the following methods:
• Create a service for TimesTen in the Oracle Database tnsnames.ora file with the
following settings:
– LOAD_BALANCE=ON (optional)
– FAILOVER_MODE=(TYPE=SELECT) or FAILOVER_MODE=(TYPE=SESSION)
• Use the DBMS_SERVICE.MODIFY_SERVICE function to set the TAF failover type.
See Oracle Database Net Services Administrator's Guide for more information about
enabling TAF.
6. If you have a TimesTen application that uses the direct driver, link it with a thread library
so that it receives FAN notifications. FAN spawns a thread to monitor for failures.
9-5
10
Using Cache With Data Guard
You need to configure cache when you want cache to work with either synchronous or
asynchronous Data Guard. Data Guard support is only included within TimesTen Classic.
• Components of MAA for Cache
• Cache in TimesTen Works With Asynchronous Active Data Guard
• Cache in TimesTen Works With Synchronous Data Guard
Components of MAA for Cache

Oracle Maximum Availability Architecture (MAA) is Oracle Database's best practices blueprint
based on proven Oracle Database high availability (HA) technologies and recommendations.
The goal of MAA is to achieve the optimal high availability architecture at the lowest cost and
complexity.
To be compliant with MAA, cache must support Oracle Real Application Clusters (Oracle
RAC) and Oracle Data Guard, as well as have its own HA capability.
Cache provides its own HA capability through active standby pair replication of cache tables
in read-only and AWT cache groups. See Using Cache in an Oracle RAC Environment.
Oracle Data Guard provides the management, monitoring, and automation software
infrastructure to create and maintain one or more synchronized standby Oracle databases to
protect data from failures, disasters, errors, and corruptions. If the primary Oracle database
becomes unavailable because of a planned or an unplanned outage, Data Guard can switch
any standby Oracle database to the primary role, thus minimizing downtime and preventing
any data loss. See Oracle Data Guard Concepts and Administration.
The MAA framework supports cache tables in static read-only and AWT cache groups. For
cache tables in dynamic cache groups of any cache group type, SWT cache groups, and
user managed cache groups that use the AUTOREFRESH cache group attribute, TimesTen
cannot access the Oracle database during a failover and switchover because cache
applications wait until the failover and switchover completes.
In general, however, all cache groups types are supported with synchronous Data Guard or
Data Guard during planned maintenance.
Cache in TimesTen Works With Asynchronous Active Data

Guard
You can cache tables from an Oracle Active Data Guard with the asynchronous redo
transport mode into read-only cache groups.
When using cache with Active Data Guard, you can only use read-only cache groups that are
replicated within an active standby pair replication scheme.
10-1
Chapter 10
Cache in TimesTen Works With Asynchronous Active Data Guard
The Active Data Guard configuration includes a primary Oracle database that
communicates over an asynchronous transport to a single physical standby Oracle
database. As shown in Figure 10-1, the primary Oracle database is located on the
primary site, while the standby Oracle database is located on a disaster recovery site.
Figure 10-1 Recommended Configuration for Asynchronous Active Data Guard
ADG enabled
Active Standby read-only
master replicated master replicated subscriber
updates updates
cache tables cache tables cache tables
autorefresh
updates primary standby
Oracle Active Data Guard Oracle
Database Database
Primary Site application Disaster Recovery Site

updates
On TimesTen, the read-only cache groups on the primary site are autorefreshed from
the primary Oracle database; however, the only transactions that are autorefreshed
are those whose changes have been successfully replicated to the standby Oracle
database. Once refreshed to the active master, all changes are then propagated to the
TimesTen standby master and a read-only subscriber using standard TimesTen
replication processes.
For the best failover and recovery action, you should locate the read-only subscriber
on the same disaster recovery site as the standby Oracle database. Create this read-
only subscriber with the ttRepAdmin -duplicate -activeDataGuard utility option,
which replicates the read-only cache groups directly to the subscriber as it would to a
standby master database. That is, instead of the cache groups being converted to
tables when replicated to a subscriber, the cache groups themselves are replicated to
the read-only subscriber. This is to provide a recovery and failover option if the primary
site fails. See Recovery After Failure When Using Asynchronous Active Data Guard.
The following sections provide more details on the environment for asynchronous
Active Data Guard when using replicated read-only cache groups:
• Configuring the Primary and Standby Oracle Databases
• Configuring the Active Standby Pair With Read-Only Cache Groups
• Recovery After Failure When Using Asynchronous Active Data Guard
10-2
Chapter 10
Configuring the Primary and Standby Oracle Databases

When you create and configure Active Data Guard with primary and standby Oracle
databases, ensure that the configuration includes specific configuration that supports the
TimesTen cache environment.
1. Configure both the primary and standby Oracle databases to use Flashback queries. See
Configuring Recovery Settings in the Oracle Database 2 Day DBA guide.
2. The Data Guard configuration must be managed by the Data Guard Broker so that the
TimesTen daemon processes and application clients respond faster to failover and
switchover events. See the Data Guard Broker guide.
3. Create two supporting database services on both the primary and standby Oracle
databases in the Oracle Cluster. One database service points to the primary Oracle
Database and the other points to the physical standby Oracle Database. You can create
these either through role based services or through system triggers.
See the following sections for details.
• Configuring Oracle Database Services Through Role Based Services
• Configuring Oracle Database Services Through System Triggers
Configuring Oracle Database Services Through Role Based Services

You can automatically control the startup of Oracle database services on both the primary
and standby Oracle databases by assigning a database role to each service.
An Oracle database service automatically starts when the Oracle database starts if the
Oracle database policy is set to AUTOMATIC and if the service role matches the current role of
the database. In this case, the role for the Oracle database is either in the primary or standby
role as part of the Active Data Guard configuration.
Configure services with the srvctl utility identically on all Oracle databases in the Data
Guard configuration. The following example shows two services created identically on both
the primary and the standby Oracle databases. See srvctl add service in the Oracle Database
Administrator's Guide.
The following steps add the primaryrole and standbyrole database services to both the
primary and standby Oracle databases when the primary Oracle database is located in Austin
and the standby Oracle database is located in Houston.
1. On the primary Oracle database, add the primaryrole database service. While this
Oracle database acts as the primary, this service is started.
srvctl add service -d Austin -s primaryrole -r ssa1,ssa2,ssa3,
ssa4 -l PRIMARY -q TRUE -e SESSION -m BASIC -w 10 -z 150
2. On the primary Oracle database, add the standbyrole database service. This service
starts only if this Oracle database switches to the standby role and then provides real-
time reporting on the standby Oracle database.
srvctl add service -d Austin -s standbyrole -r ssa1,ssa2,ssa3,
ssa4 -l PHYSICAL_STANDBY -q TRUE -e SESSION -m BASIC -w 10 -z 150
3. On the standby Oracle database, add the primaryrole database service. This service
starts only if this Oracle database switches to the primary role.
10-3
Chapter 10
srvctl add service -d Houston -s primaryrole -r ssb1,ssb2,ssb3,

ssb4 -l PRIMARY -q TRUE -e SESSION -m BASIC -w 10 -z 150
4. On the standby Oracle database, add the standbyrole database service. While
this Oracle database acts as the standby, this service is started and then provides
real-time reporting on the standby Oracle database.
srvctl add service -d Houston -s standbyrole -r ssb1,ssb2,ssb3,
ssb4 -l PHYSICAL_STANDBY -q TRUE -e SESSION -m BASIC -w 10 -z 150
5. Run the following SQL statement on the primary Oracle database so that the
service definitions are transmitted and applied to the physical standby Oracle
database.
EXECUTE DBMS_SERVICE.CREATE_SERVICE('standbyrole', 'standbyrole', NULL,
NULL, TRUE, 'BASIC', 'SESSION', 150, 10, NULL);
6. Add connection aliases in the appropriate tnsnames.ora files to identify the

primary and standby Oracle databases and specify the database service names
for each.
primaryinstance=
(DESCRIPTION_LIST=
(LOAD_BALANCE=off)
(FAILOVER=on)
(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=myhost1)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=primaryrole)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=primaryrole))))
standbyinstance=
(DESCRIPTION_LIST=
(LOAD_BALANCE=off)
(FAILOVER=on)
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=standbyrole)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=standbyrole))))
7. On the primary Oracle database, start the primaryrole database service.

srvctl start service -d Austin -s primaryrole
8. On the standby Oracle database, start the standbyrole database service.

srvctl start service -d Houston -s standbyrole
Configuring Oracle Database Services Through System Triggers

You can perform certain steps to create the primaryrole and standbyrole database
services on the primary Oracle database using triggers. After creation, these are
replicated to the standby Oracle database.
1. Create the primaryrole and standbyrole database services in the primary Oracle
database.
10-4
Chapter 10
exec DBMS_SERVICE.CREATE_SERVICE(
service_name => 'primaryrole',
network_name => 'primaryrole',
aq_ha_notifications => true, failover_method => 'BASIC',
failover_type => 'SELECT', failover_retries => 180, failover_delay => 1 );
exec DBMS_SERVICE.CREATE_SERVICE(
service_name => 'standbyrole',
network_name => 'standbyrole',
aq_ha_notifications => true, failover_method => 'BASIC',
failover_type => 'SELECT', failover_retries => 180, failover_delay => 1 );
2. Create the primaryrole and standbyrole triggers in the primary Oracle database for
when the database starts.
CREATE OR REPLACE TRIGGER manage_OCIService
after startup on database
DECLARE
role VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE INTO role FROM V$DATABASE;
IF role = 'PRIMARY' THEN
BEGIN
DBMS_SERVICE.START_SERVICE('primaryrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
BEGIN
DBMS_SERVICE.STOP_SERVICE('standbyrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
ELSE
BEGIN
DBMS_SERVICE.STOP_SERVICE('primaryrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
BEGIN
DBMS_SERVICE.START_SERVICE('standbyrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
END IF;
END;
3. Create the following trigger on the primary Oracle database to run when the database
changes roles:
CREATE OR REPLACE TRIGGER manage_OCIService2
AFTER DB_ROLE_CHANGE ON DATABASE
DECLARE
role VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE INTO role FROM V$DATABASE;
BEGIN
DBMS_SERVICE.START_SERVICE('primaryrole');
10-5
Chapter 10
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
BEGIN
DBMS_SERVICE.STOP_SERVICE('standbyrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
ELSE
BEGIN
DBMS_SERVICE.STOP_SERVICE('primaryrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
BEGIN
DBMS_SERVICE.START_SERVICE('standbyrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
END IF;
END;
4. Add connection aliases in the appropriate tnsnames.ora files to identify the

primary and standby Oracle databases and specify the database service names
for each.
primaryinstance=
(DESCRIPTION_LIST=
(LOAD_BALANCE=off)
(FAILOVER=on)
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=primaryrole)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=primaryrole))))
standbyinstance=
(DESCRIPTION_LIST=
(LOAD_BALANCE=off)
(FAILOVER=on)
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=standbyrole)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=standbyrole))))
5. Restart both of the Oracle databases to enable the trigger to start and stop the
correct database services. Alternatively, if you do not want to restart both Oracle
databases, you can start and stop the appropriate database services on each
Oracle database as follows:
On the primary Oracle database:
10-6
Chapter 10
exec DBMS_SERVICE.START_SERVICE('primaryrole');
exec DBMS_SERVICE.STOP_SERVICE('standbyrole');
On the standby Oracle database:

exec DBMS_SERVICE.STOP_SERVICE('primaryrole');
exec DBMS_SERVICE.START_SERVICE('standbyrole');
Configuring the Active Standby Pair With Read-Only Cache Groups

The Active Data Guard with asynchronous redo transport mode supports an active standby
pair replication scheme that only contains replicated read-only cache groups.
All replicated read-only cache groups must be created before you create the active standby
pair. You cannot exclude a replicated read-only cache group when you are creating the active
standby pair and you cannot add another replicated read-only cache group to the active
standby pair after creation.
When you create and configure an active standby pair to support replicated read-only cache
groups, perform the following to support asynchronous Active Data Guard:
1. When you create the active standby pair, we recommend that you keep both the active
and standby masters within the same physical site. They can be on different hosts within
the same site.
2. If you want a read-only subscriber for disaster recovery, you can add a read-only
subscriber on the same disaster recovery site as the standby Oracle database and
enable the subscriber for cache groups. The subscriber that you should create when
using Active Data Guard is created with a duplicate operation with the ttRepAdmin -
duplicate -activeDataGuard options.
The -activeDataGuard option, which is solely for the Active Data Guard environment,
enables the subscriber to keep replicated read-only cache groups intact as it would for a
standby master. Since the subscriber retains these cache groups, you must provide the
Oracle cache administration user name and password on the ttRepAdmin utility
command line.
Note:
Alternatively, you can use the ttRepDuplicateEx C function setting the
TT_REPDUP_ADG flag in ttRepDuplicateExArg.flags.
The following example creates a read-only subscriber on the disaster recovery site
duplicating from the standby master providing the -activeDataGuard option, the cache
administration user name and passwords.
ttRepAdmin -duplicate -from master2 -host node1
-uid cacheadmin -pwd timesten -cacheuid cacheadmin -cachepwd orapwd
-activeDataGuard adgsubscriber
3. Create the cache environment on the primary Oracle database. You do not need to
perform any of these steps on the standby Oracle database.
4. On the primary Oracle database, grant the Oracle cache administration user the EXECUTE
privilege for the SYS.DBMS_FLASHBACK package. This privilege is granted as part of the
initCacheAdminSchema.sql and grantCacheAdminPrivileges.sql scripts.
10-7
Chapter 10
5. Configure the same connection attributes that you would for a TimesTen database
that caches data from an Oracle database. In addition, since we are also
monitoring transactions from the standby Oracle database, configure the
StandbyNetServiceName connection attribute with the net service name of the
standby Oracle database instance.
On Microsoft Windows systems, the net service name of the Oracle database
instance is specified in the Oracle Net Service Name field of the TimesTen Cache
tab within the TimesTen ODBC Setup dialog box. The standby Oracle database
instance is specified in the Standby Oracle Net Service Name field on the same
page.
Configure the StandbyNetServiceName ODBC.INI attribute on the active master to
configure the net service name of the physical standby Oracle database:
[cachedb]
DataStore=/myDb/cachedb
PermSize=256
TempSize=256
DatabaseCharacterSet=WE8DEC
OracleNetServiceName=primaryinstance
StandbyNetServiceName=standbyinstance
Recovery After Failure When Using Asynchronous Active Data Guard

There are recommended recovery procedures if the primary Oracle database fails, the
standby Oracle database fails, or the entire primary site fails taking down the primary
Oracle database as well as the active and standby masters.
• Failure of the Standby Oracle Database
• Failure of the Primary Oracle Database
• Failure of the Primary Site
Failure of the Standby Oracle Database

When the standby Oracle database in an Active Data Guard configuration fails, the
cache agent retries the connection to the standby Oracle database.
Note:
You can notify the cache agent of whether the standby Oracle database is
active or has failed by calling the ttCacheADGStandbyStateSet built-in
procedure with either the ON or the FAILED arguments.
• If a timeout is set, then the cache agent waits for the amount of time specified with
the ttCacheADGStandbyTimeoutSet built-in procedure. If the standby Oracle
database has not recovered after this period, then the cache agent sets the state
of the standby Oracle database by calling the ttCacheADGStandbyStateSet built-in
procedure with the FAILED argument and then facilitates autorefresh using only the
primary Oracle database.
• If no timeout has been set with the ttCacheADGStandbyTimeoutSet built-in
procedure (default value is 0), then the cache agent continues to wait on the
10-8
Chapter 10
standby Oracle database, unless you inform the cache agent that the standby Oracle
database is not recovering by calling the ttCacheADGStandbyStateSet built-in procedure
with the FAILED argument.
Once the state of the standby Oracle database is set to FAILED, the cache agent resumes
autorefresh with only the primary Oracle database until you reset the state of the standby
Oracle database by calling the ttCacheADGStandbyStateSet built-in procedure with the ON
argument. Even if the standby Oracle database eventually does recover, the cache agent
does not recognize that the standby Oracle database is active until you reset its state to ON.
Once the state of the standby Oracle database is set to ON, the cache agent pauses to wait
for the standby Oracle database to catch up to the primary Oracle database. After which, the
cache agent resumes autorefresh from the primary Oracle database for those transactions
that have successfully replicated to the standby Oracle database.
You can restore the original Active Data Guard configuration by dropping the active standby
pair and then loading the cache groups.
See ttCacheADGStandbyTimeoutSet and ttCacheADGStandbyStateSet in the Oracle
Failure of the Primary Oracle Database

If the primary Oracle database fails, then Data Guard switches over to the standby Oracle
database and the TimesTen cache agent switches autorefresh over to the new primary
Oracle database.
Figure 10-2 Failure of the Primary Oracle Database
ADG enabled
Active Standby read-only
master replicated master replicated subscriber
updates updates
cache tables cache tables cache tables
autorefresh
primary Oracle updates standby Oracle
database database
Disaster
Primary Site Recovery
Site application
updates
10-9
Chapter 10
Failure of the Primary Site

If the entire site where the primary Oracle database as well as the active and standby
master databases are located fails, then the standby Oracle database becomes the
primary Oracle database.
After which, you may want the disaster recovery site to become the primary TimesTen
database. Thus, on the disaster recovery site, the standby Oracle database is now a
sole Oracle database and the read-only subscriber becomes a single TimesTen
database that caches data in the Oracle database.
Transform the subscriber into a single TimesTen database with cached tables by:
1. Drop the active standby pair on the TimesTen database on the disaster recovery
site.
2. Alter the existing read-only cache groups on the disaster recovery site to set the
autorefresh state to on.
After which, the cache tables on the TimesTen database in the disaster recovery site
receive updates from the new primary Oracle database.
Figure 10-3 Recovery After Failure of Primary Site
Active Standby TimesTen

master master database
cached read-only tables
cache tables cache tables
Disaster replicated
Primary Site Recovery updates
Fails! Site
FAILED
primary primary
Oracle Oracle
Database Database
application
updates
The following is the process to recover a failed primary site and rebuild your
environment to the original state:
1. Create a new active standby pair on the disaster recovery site.
10-10
Chapter 10
2. Alter the existing read-only cache groups on the disaster recovery site to set the
autorefresh state to off to stop any future updates from the primary Oracle database.
3. Create the ADG enabled read-only subscriber on the recovered primary site.
4. Drop the active standby pair on the ADG enabled read-only subscriber on the primary
site, if it still exists after recovering the primary site.
5. Switch over the Oracle databases in the Active Data Guard. Currently, the applications
are updating the primary Oracle database on the disaster recovery site. However, once
you recover the Oracle database on the primary site, we want it to take over again as the
primary and to make the Oracle database on the disaster recovery site as the secondary.
The TimesTen database starts to receive updates from the Oracle database on the
primary site.
ADG enabled
read-only Active
Standby
subscriber
master master
cache tables cache tables cache table
3. Create a new ADG enabled 1. Create a new active standby

read-only subscriber on the primary site. pair in the disaster recovery site.
4. Drop the active 2. Set autorefresh to oﬀ for the

standby pair on the existing subscriber.
standby Oracle primary Oracle
primary site.
database Active Data Guard database
5. Swap the primary
and standby Oracle
databases so that
the updates come
from the disaster
recovery site to the
Disaster
primary site. Primary Site application
Recovery Site
updates
6. Create a new active standby pair on the primary site.

7. Create a new ADG enabled read-only subscriber on the disaster recovery site.
10-11
Chapter 10
Cache in TimesTen Works With Synchronous Data Guard
ADG enabled
Active Standby Read-only
master master subscriber
cache tables cache tables

cache tables
7. Create a new
ADG enabled read-only
subscriber on the
disaster recovery site.
6. Create a new active
standby pair on the primary Oracle standby Oracle
primary site. database Active Data Guard database
application Primary Site Disaster Recovery Site

updates

Cache in TimesTen works with synchronous physical standby failover and switchover
and logical standby switchover as long as the object IDs for cached Oracle Database
tables remain the same on the primary and standby Oracle databases.
Object IDs can change if the table is dropped and re-created, altered, or a truncated
flashback operation or online segment shrink is performed.
During a transient upgrade, a physical standby Oracle database is transformed into a
logical standby Oracle database. For the time that the standby Oracle database is
logical, the user must ensure that the object IDs of the cached Oracle Database tables
do not change. Specifically, tables that are cached should not be dropped and re-
created, truncated, altered, flashed back or have an online segment shrunk.
The following sections describe how to configure the Oracle and TimesTen databases.
• Configuring the Oracle Databases for TimesTen and Synchronous Data Guard
• Configuring the TimesTen Database to Work With Synchronous Data Guard
Configuring the Oracle Databases for TimesTen and Synchronous

Data Guard
You can configure TimesTen to fail over and switch over when using synchronous Data
Guard.
In order for TimesTen to fail over and switch over properly, configure the primary and
standby Oracle databases using the following steps:
10-12
Chapter 10
1. The Data Guard configuration must be managed by the Data Guard Broker so that the
TimesTen daemon processes and application clients respond faster to failover and
switchover events.
2. If you are configuring an Oracle RAC database, use the Oracle Enterprise Manager
Cluster Managed Database Services Page to create Oracle database services that
TimesTen and its client applications use to connect to the Oracle primary database. See
Workload Management With Dynamic Database Services in Oracle Real Application
Clusters Administration and Deployment Guide.
3. If you created the Oracle database service in step 2, use the MODIFY_SERVICE function of
the DBMS_SERVICE PL/SQL package to modify the service to enable high availability
notification to be sent through Advanced Queuing (AQ) by setting the
aq_ha_notifications attribute to TRUE. To configure server side TAF settings, set the
failover attributes, as shown in the following example:
BEGIN
DBMS_SERVICE.MODIFY_SERVICE
(service_name => 'DBSERV',
goal => DBMS_SERVICE.GOAL_NONE,
dtp => false,
aq_ha_notifications => true,
failover_method => 'BASIC',
failover_type => 'SELECT',
failover_retries => 180,
failover_delay => 1);
END;
4. If you did not create the database service in step 2, use the CREATE_SERVICE function of
the DBMS_SERVICE PL/SQL package to create the database service, enable high
availability notification, and configure server side TAF settings:
BEGIN
DBMS_SERVICE.CREATE_SERVICE
(service_name => 'DBSERV',
network_name => 'DBSERV',
goal => DBMS_SERVICE.GOAL_NONE,
dtp => false,
aq_ha_notifications => true,
failover_method => 'BASIC',
failover_type => 'SELECT',
failover_retries => 180,
failover_delay => 1);
END;
5. Create two triggers to relocate the database service to a Data Guard standby database
(Oracle RAC or non-Oracle RAC) after it has switched to the primary role. The first trigger
fires on the system start event and starts up the DBSERV service:
CREATE OR REPLACE TRIGGER manage_service
AFTER STARTUP ON DATABASE
DECLARE
role VARCHAR(30);
BEGIN
SELECT database_role INTO role FROM v$database;
dbms_service.start_service('DBSERV');
END IF;
END;
10-13
Chapter 10
The second trigger fires when the standby database remains open during a
failover and switchover upon a database role change. It relocates the DBSERV
service from the old primary to the new primary database and disconnects any
connections to that service on the old primary database so that TimesTen and its
client applications can reconnect to the new primary database:
CREATE OR REPLACE TRIGGER relocate_service
AFTER DB_ROLE_CHANGE ON DATABASE
DECLARE
role VARCHAR(30);
BEGIN
ELSE
dbms_service.stop_service('DBSERV');
dbms_lock.sleep(2);
FOR x IN (SELECT s.sid, s.serial#
FROM v$session s, v$process p
WHERE s.service_name='DBSERV' AND s.paddr=p.addr)
LOOP
BEGIN
EXECUTE IMMEDIATE
'ALTER SYSTEM DISCONNECT SESSION
''' || x.sid || ','|| x.serial# || ''' IMMEDIATE';
EXCEPTION WHEN OTHERS THEN
BEGIN
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_STACK);
END;
END;
END LOOP;
END IF;
END;
6. As an option, to reduce the performance impact to TimesTen applications and

minimize the downtime during a physical or logical standby database switchover,
run the following procedure right before initiating the Data Guard switchover to a
physical or logical standby database:
DECLARE
role varchar(30);
BEGIN
dbms_service.stop_service('DBSERV');
dbms_lock.sleep(2);
FOR x IN (SELECT s.sid, s.serial#
FROM v$session s, v$process p
WHERE s.service_name='DBSERV' AND s.paddr=p.addr)
LOOP
BEGIN
EXECUTE IMMEDIATE
'ALTER SYSTEM DISCONNECT SESSION
''' || x.sid || ',' || x.serial# || ''' IMMEDIATE';
EXCEPTION WHEN OTHERS THEN
BEGIN
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_STACK);
END;
END;
END LOOP;
ELSE
10-14
Chapter 10
END IF;
END;
This procedure should be performed first on the physical or logical standby database,
and then on the primary database, right before the switchover process. Before running
the procedure for a physical standby database switchover, Active Data Guard must be
enabled on the physical standby database.
Before performing a switchover to a logical standby database, stop the Oracle Database
service for TimesTen on the primary database and disconnect all sessions connected to that
service. Then start the service on the standby database.
At this point, cache applications try to reconnect to the standby database. If a switchover
occurs, there is no wait required to migrate the connections from the primary database to the
standby database. This eliminates the performance impact on TimesTen and its applications.
Configuring the TimesTen Database to Work With Synchronous Data

Guard
Configure TimesTen to receive notification of FAN HA events and to avoid reconnecting to a
failed Oracle Database instance. Use the Oracle client shipped with TimesTen.
1. Create an Oracle Net service name that includes all primary and standby hosts in
ADDRESS_LIST. For example:
DBSERV =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = PRIMARYDB)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = STANDBYDB)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA= (SERVICE_NAME=DBSERV))
)
2. In the client's sqlnet.ora file, set the SQLNET.OUTBOUND_CONNECT_TIMEOUT parameter to

enable clients to quickly traverse an address list in the event of a failure. For example, if a
client attempts to connect to a host that is unavailable, the connection attempt is bounded
to the time specified by the SQLNET.OUTBOUND_CONNECT_TIMEOUT parameter, after which
the client attempts to connect to the next host in the address list. Connection attempts
continue for each host in the address list until a connection is made.
Setting the SQLNET.OUTBOUND_CONNECT_TIMEOUT parameter to a value of 3 seconds
suffices in most environments. For example, add the following entry to the sqlnet.ora
file:
SQLNET.OUTBOUND_CONNECT_TIMEOUT=3
10-15
11
Using GoldenGate as an Alternative to Native
Read-Only Cache Groups
Oracle GoldenGate is Oracle's primary data replication and data exchange technology.
GoldenGate supports a multitude of databases as sources for data capture as well as targets
for data delivery.
TimesTen can be deployed in several ways, including as an in-memory cache for data that
resides in an Oracle database. TimesTen provides functionality to enable it to act as a cache
for Oracle database. This technology supports both read-only and read-write caching.
If your caching use case is to provide read-only caching, then (in some cases) you may
prefer to use GoldenGate to refresh data from the back-end database to the TimesTen cache,
instead of using the TimesTen native cache functionality.
Note:
While this chapter refers to using GoldenGate for cache refresh, the operation is
more accurately identified as unidirectional real-time replication. For the use case
described in this document, this distinction is mostly irrelevant.
Note:
The Oracle GoldenGate Documentation is the definitive source for information on
GoldenGate installation, configuration, and operation. See Using Oracle
GoldenGate With TimesTen in the Using Oracle GoldenGate for Heterogeneous
Databases guide for a description of features supported and guidelines for
preparing the system to support cache refresh using Oracle GoldenGate. This
chapter does not duplicate significant information from the GoldenGate
documentation, except where it is pertinent to do so.
The following sections describe when and how to use GoldenGate as the cache refresh
mechanism for TimesTen:
• TimesTen and GoldenGate Support for Cache Refresh
• Considerations When Using GoldenGate as the Cache Refresh Mechanism
• Configuring GoldenGate to Provide Cache Refresh Functionality for TimesTen
• Example of Caching Using GoldenGate
TimesTen and GoldenGate Support for Cache Refresh

GoldenGate delivery is supported with both TimesTen Classic and TimesTen Scaleout.
11-1
Chapter 11
Considerations When Using GoldenGate as the Cache Refresh Mechanism
The installed TimesTen version is 18.1.4.9.0 or higher and the installed GoldenGate
version is 19.1 or higher.
The GoldenGate parallel Replicat process, which can improve replication throughput in
some use cases, is supported with GoldenGate 21.3 and higher.
Use GoldenGate release 21.3 or later for the best experience.
Considerations When Using GoldenGate as the Cache

Refresh Mechanism
Instead of using the TimesTen provided cache refresh mechanism, there are a couple
of reasons when to use GoldenGate as the cache refresh mechanism for read-only
cache groups.
If you are planning to use GoldenGate as the cache refresh mechanism, consider that:
• GoldenGate cache refresh supports functionality similar to TimesTen static read-
only cache groups. All other types of cache groups (dynamic, Asynchronous
WriteThrough, Synchronous WriteThrough, User Managed, and so on) are not
currently supported to use GoldenGate as the cache refresh mechanism. These
types of cache groups must use the TimesTen native caching mechanisms.
• GoldenGate for Oracle TimesTen supports delivery of data to user tables, instead
of cache groups. Since GoldenGate uses regular tables instead of cache groups,
create your cache tables in TimesTen as regular tables (using the CREATE TABLE
statement) and not as cache groups (using the CREATE READONLY CACHE GROUP
statement).
• When using GoldenGate as the cache refresh mechanism, any read-only cached
tables in TimesTen are not truly read-only. Applications are not automatically
prevented from modifying data in the tables; however, any modifications can be
overwritten if GoldenGate refreshes newly modified data into the table from the
back-end database. You can mitigate this by having the tables owned by a
dedicated user separate from the application users and assigning database
privileges to ensure that application users only have read access to the cache
tables.
• A best practice is to use a dedicated TimesTen database user for the GoldenGate
apply process. Cached tables should be owned by this user and application users
should be granted only read (SELECT) privileges on the cached tables.
• Create private synonyms, owned by any application users, for the cached tables to
make the ownership transparent to application code and SQL statements.
• Golden Gate only refreshes cache tables in TimesTen with modified data. You
must perform an initial load of data from the source database into TimesTen. The
initial table data load is used to establish data synchronization when instantiating
GoldenGate replication.
• You must set the DatabaseCharacterSet TimesTen database parameter to the
same value as the Oracle Database database character set.
• All GoldenGate connections to the TimesTen database must use a connection that
explicitly sets ConnectionCharacterSet to the same value as
DatabaseCharacterSet.
11-2
Chapter 11
Configuring GoldenGate to Provide Cache Refresh Functionality for TimesTen
• GoldenGate is a separately licensed product, and you must have suitable licenses to
cover your usage. You must have license coverage for both GoldenGate capture for the
source database and GoldenGate apply for TimesTen.
Configuring GoldenGate to Provide Cache Refresh Functionality

for TimesTen
You can set up a caching environment between GoldenGate and TimesTen.
The high-level steps for setting up a GoldenGate caching environment with TimesTen are as
follows:
1. Install, configure and prepare the source database. In most scenarios, the source
database already exists and contains the tables that you desire to cache.
2. Install GoldenGate at the source database and prepare the source database for use with
GoldenGate.
3. Configure GoldenGate data capture for the source database tables that you wish to
cache in TimesTen.
4. Decide if you will run the GoldenGate apply processes on the same host as the target
TimesTen database (an on-box deployment) or on a different host to the target TimesTen
database (an off-box deployment). See Choosing On-Box or Off-Box for Deployment of a
GoldenGate Replicat Process.
5. Install, configure and prepare the TimesTen database that acts as a cache. In general,
deploy the cache on a different host from the source database, which is the host where
the application processes run. See Installing and Configuring TimesTen and the Target
Database.
6. Create the necessary database users in TimesTen. Create the TimesTen tables that
correspond to the tables that you wish to cache from the source database. Grant the
necessary privileges and create synonyms (if desired). See Create TimesTen Database
Users, Tables and Synonyms.
7. If you have chosen an off-box deployment, install a TimesTen client instance on the
GoldenGate apply host and configure it to connect to the TimesTen database. See
Installing and Configuring a TimesTen Client Instance (for Off-Box Deployments Only).
8. Configure the GoldenGate apply mechanism (Replicat process) for the TimesTen
database tables that correspond to the source database tables. See Configure
GoldenGate Data Apply.
9. Perform an initial data load to populate the TimesTen cache tables from the
corresponding source database tables. This process usually involves some GoldenGate
specific actions as well as the actual data loading. See Perform an Initial Load.
10. Activate GoldenGate continuous real-time replication to provide ongoing data change
synchronization from the source database to TimesTen. See Start GoldenGate
Continuous Real-Time Replication.
The remainder of this chapter assumes the following for simplicity:
• The source database is an Oracle database running a recent release (18c or later).
• The target database is TimesTen release 22.1.1.1.0 or later.
• The GoldenGate release is 21.3 or later.
11-3
Chapter 11
• The actions required for steps (1) through (3) above have been correctly carried
out. This chapter does not cover these steps since they are covered in detail in the
GoldenGate documentation and by many other online sources and articles.
• This chapter primarily focuses on steps (4) through (10).
Choosing On-Box or Off-Box for Deployment of a GoldenGate Replicat

Process
When you deploy GoldenGate for TimesTen, you ultimately instantiate a set of
processes that are responsible for receiving all replicated data from the GoldenGate
source, storing it in a (local) trail file, reading the replicated data from the trail file and
applying it to the target TimesTen database.
• If you deploy GoldenGate for TimesTen in the same host, VM, container, or pod as
the target TimesTen database, then you can use either direct mode or client-server
connectivity. This is known as an on-box deployment in GoldenGate terms.
Generally, direct mode connectivity is preferred and recommended for this
scenario.
• If you deploy GoldenGate for TimesTen in a different host, VM, container, or pod to
the target TimesTen database, then you have to use client-server connectivity. In
GoldenGate terms this is an off-box deployment.
The following sections describe the different connectivity options available to
application processes, including GoldenGate processes:
• Direct Mode Connectivity
• Client-Server Connectivity
Direct Mode Connectivity

TimesTen direct mode is a local only connectivity method that enables applications to
interact with a local (same host) TimesTen database.
Direct mode connections use a highly efficient mechanism that eliminates inter-
process communication, context switches and other overheads. Direct mode delivers
the lowest possible data access latency together with high throughput. Use of direct
mode is limited to application processes that are executing in one of the following
environments:
• In the same bare metal host as the TimesTen database.
• In the same virtual machine as the TimesTen database.
• In the same container as the TimesTen database or, for Kubernetes environments,
in a container in the same pod as the TimesTen database container.
Direct mode connections offer better performance with less overhead. Using direct
mode connections will significantly increase the complexity if you want high availability
when using a combination of TimesTen and Goldengate configurations. For example,
when you combine GoldenGate with either a TimesTen active-standby pair or
TimesTen Scaleout, automated failover and recovery for GoldenGate is significantly
more complex compared to an off-box configuration using client-server connections.
Host resources (CPU, memory, storage) must be sufficient to accommodate the
TimesTen database instance, the TimesTen database, all GoldenGate processes, all
associated processing plus any other local processing (such as applications).
11-4
Chapter 11
Client-Server Connectivity
TimesTen client-server mode provides regular client-server connectivity through TCP/IP
connections.
The applications can run anywhere that has suitable network connectivity to the host where
TimesTen is running. Client-server potentially offers more flexibility than direct mode, but this
flexibility comes at the cost of increased overhead and lower performance due to network
latency, additional processing, and so on.
Installing and Configuring TimesTen and the Target Database

You can install and configure TimesTen and the target database for both on-box and off-box
deployments.
Note:
If you already have a suitable TimesTen instance and database that is configured
for connectivity to the source Oracle database, then you can skip this step.
1. Prepare an Oracle Database Net Services tnsnames.ora file with a suitable TNS entry to
enable connectivity from the TimesTen host system to the source Oracle database. Save
this file in a suitable directory.
The following example creates a TNS entry called myoradb:
MYORADB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = oradb.example.net)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = myoradb)
)
)
2. Set the TNS_ADMIN location for the cache agent with the ttInstanceModify -tnsadmin
option to set the path to the tnsnames.ora file. Specify the full path to the directory where
the file is located.
3. For cache in TimesTen Classic, set the TNS_ADMIN environment variable to indicate the
full path to the directory where the tnsnames.ora file is located. Set this variable in the
user's profile script so that it persists.

ttDaemonAdmin -stop
5. Prepare the host where both TimesTen and the target database will reside. Install
TimesTen and create a TimesTen instance. When creating the instance, enable the
instance to use the TNS_ADMIN value that it can detect from the environment. See
11-5
Chapter 11
Installation of TimesTen Classic on Linux or UNIX in the Oracle TimesTen In-

Memory Database Installation, Migration, and Upgrade Guide.
6. Once you have a functional TimesTen instance, define a Data Source Name
(DSN) in the instance sys.odbc.ini file. The DSN defines all of the parameters for
the target database.
The following example shows a DSN, myappdb, for the TimesTen database. This
type of DSN is known as a Server DSN as it defines all of the attributes for the
database and defines an endpoint for direct mode connections. The value for the
OracleNetServiceName attribute should be the name of the TNS entry (myoradb in
this example) that was configured previously. The values specified for
DatabaseCharacterSet and ConnectionCharacterSet must match the source
Oracle Database character set.
[ODBC Data Sources]
myappdb=TimesTen 22.1 Driver
[myappdb]
DataStore=/disk1/db/ckpt/myappdb
LogDir=/disk2/db/log
PermSize=8192
TempSize=512
LogBufMB=1024
LogFileSize=1024
MemoryLock=4
ConnectionCharacterSet=AL32UTF8
OracleNetServiceName=myoradb
7. While logged in as the TimesTen instance administration user, set the environment
for the TimesTen instance. Connect to the DSN using the ttIsql utility, which
creates the target database.
Create TimesTen Database Users, Tables and Synonyms

Perform steps to create the TimesTen database users, tables and synonyms.
1. While connected to the TimesTen database as the TimesTen instance
administrator user, create a dedicated GoldenGate apply database user for the
GoldenGate apply processes. This user owns all of the cached tables in TimesTen.
Make sure that the dedicated GoldenGate apply database user has all necessary
privileges on the cached tables.
This example creates a dedicated GoldenGate apply database user called
ggapply.
CREATE USER ggapply IDENTIFIED BY "mypwd";
GRANT CREATE SESSION, CREATE TABLE to ggapply;
2. Applications should connect to the database as different users from the

GoldenGate apply database user. As always, application users should be granted
the minimum set of privileges consistent with the operations needed to perform.
This example creates two application users named appuser1 and appuser2:
CREATE USER appuser1 IDENTIFIED BY some_suitable_password;
GRANT CREATE SESSION to appuser1;
CREATE USER appuser2 IDENTIFIED BY some_suitable_password;
GRANT CREATE SESSION to appuser2;
11-6
Chapter 11
3. GoldenGate for Oracle TimesTen supports delivery of data to user tables, instead of
cache groups. Since GoldenGate uses regular tables instead of cache groups, create
your cache tables in TimesTen as regular tables (using the CREATE TABLE statement) and
not as cache groups (using the CREATE READONLY CACHE GROUP statement).
This step creates the required cache tables in TimesTen. Make sure that the table
definitions are compatible with the corresponding tables in the source database. You
should create the tables owned by the ggapply database user (you need to be connected
either as ggapply or as some other user with ADMIN privileges):
CREATE TABLE ggapply.cachetab1 ( … );
CREATE TABLE ggapply.cachetab2 ( … );
…
4. When using GoldenGate as the cache refresh mechanism, any read-only cached tables
in TimesTen are not truly read-only. Applications are not prevented from modifying data in
the tables (provided that they have suitable access privileges on the tables). However,
any such modifications can be overwritten if GoldenGate refreshes newly modified data
to the table from the back-end database. You can mitigate this by ensuring that
application users only have read access to the cache tables. These tables must be
owned by a user other than the application users, such as the dedicated GoldenGate
apply database user to ensure that the GoldenGate apply process to write to these same
tables.
Grant SELECT (read) privileges on the cache tables to the application users:
GRANT SELECT ON ggapply.cachetab1 TO appuser1, appuser2, …;
GRANT SELECT ON ggapply.cachetab2 TO appuser1, appuser2, …;
5. Generally, for convenience and transparency, each application user may want to have a
private synonym for the application tables that it needs to query to avoid having to always
qualify the table name with the name of the dedicated GoldenGate apply database user
ggapply user. For example:
CREATE SYNONYM appuser1.cachetab1 FOR ggapply.cachetab1;
Installing and Configuring a TimesTen Client Instance (for Off-Box

Deployments Only)
When using an off-box deployment, you need to prepare the host where GoldenGate for
TimesTen will be installed.
Create a TimesTen installation and from that a TimesTen client instance. Consult Installation
of TimesTen Classic on Linux or UNIX in the Oracle TimesTen In-Memory Database
Installation, Migration, and Upgrade Guide.
Add a suitable client DSN to the client instance sys.odbc.ini file to enable connections to
the target TimesTen database that was configured in the Installing and Configuring TimesTen
and the Target Database section.
In this example, the client DSN is named myappdbcs and the host name where the TimesTen
database is running is myttserver.example.com. The TimesTen server is listening on port
6625 (the default). This hostname must be resolvable on the client system through DNS
or /etc/hosts and regular TCP connectivity must be functional between the client and server
11-7
Chapter 11
systems. Port 6625 on the server must not be blocked by a firewall. Note the setting
for ConnectionCharacterSet.
[ODBC Data Sources]
myappdbcs=TimesTen 22.1 Client Driver
[myappdbcs]
TTC_SERVER=myttserver.example.com/6625
TTC_SERVER_DSN=myappdb
ConnectionCharacterSet=AL32UTF8
Configure GoldenGate Data Apply

Ensure that your environment is set for your local TimesTen instance (server or client)
and change your directory to the GoldenGate installation directory.
1. Start the GGSCI utility and use it to perform the following steps:
./ggsci
2. Start the manager process:

START MANAGER
3. Login to your TimesTen database using the DBLOGIN command. If you are using
off-box deployment, use the client DSN; otherwise, use the server DSN. The
following example uses the server DSN of myappdb.
DBLOGIN SOURCEDB myappdb, USERID ggapply, PASSWORD ggapply_users_password
4. Create the GoldenGate checkpoint table. This is required for using a GoldenGate
Replicat process with TimesTen. Choose a table name so that it does not conflict
with your application tables:
ADD CHECKPOINTTABLE ggapply.checkpoint_table_name
5. Create a parallel Replicat group, which maximizes throughput. In this example,

this group is called rep:
ADD REPLICAT rep, EXTTRAIL trail_name, PARALLEL, CHECKPOINTTABLE
ggapply.checkpoint_table_name
The trail_name is the name of the remote trail that you specified for either the
data pump or Extract process on the source server.
6. Create a parameter file for the Replicat group. In our example, this file should be
gg_home/dirprm/REP.prm:
REPLICAT rep
TARGETDB myappdb, USERID ggapply, PASSWORD ggapply_users_password
BATCHSQL
MAP oraowner.sourcetab1, TARGET ggapply.cachetab1;
MAP oraowner.sourcetab2, TARGET ggapply.cachetab2;
…
Here oraowner.sourcetab1 is the table owner and name on the source database,
and ggapply.cachetab1 is the table owner and name in the TimesTen database.
Usually the table name is the same in both the source and the target, but this is
not a requirement. You can specify multiple MAP directives or use wildcards for
multiple tables.
11-8
Chapter 11
For off-box deployment, use the client DSN instead of the server DSN. You can also use
a GoldenGate credential store and USERIDALIAS for password encryption. For more
information, see Using Oracle GoldenGate with Oracle Database.
If you are using a parallel Replicat process include the following line before the MAP
statements:
APPLY_PARALLELISM 4
You can experiment with the number of apply threads to see which value provides the
most optimal throughput in your environment.
Add any other parameters in this file that apply to your database environment.
Note:
When using TimesTen native caching, one option you have is to cache a subset of
a table (specific columns and/or rows). This is also possible with GoldenGate, but
these details are not covered in this document.
Perform an Initial Load

GoldenGate only refreshes cache tables in TimesTen with modified data. Thus, before
starting a GoldenGate Replicat process for continuous replication, you need to perform an
initial load of data to populate the cached tables in the TimesTen database with the rows from
the source database tables.
The initial table data load is used to establish data synchronization when instantiating
GoldenGate replication. In general, there may be a workload running against the source
database tables while you do this.
To perform the initial load (and the switch for continuous replication), perform the following:
1. Make sure that you have started the GoldenGate Extract process on the source Oracle
database. It is vital that GoldenGate has started change data capture and propagation on
the source database before proceeding to the next step.
2. On the source Oracle database, determine the current SCN value. For example, run the
following SQL query through SQL*Plus:
SELECT CURRENT_SCN FROM V$DATABASE;
In this example, the SCN value returned by this query is 12345678.

3. Connect to the TimesTen database as a suitable database user using the TimesTen ttIsql
utility. This user must meet the following criteria:
a. The user must exist in both the target TimesTen database and the source Oracle
database.
b. You must know the password for that user for both TimesTen and Oracle databases.
The passwords may differ on each of the databases.
c. In TimesTen, the user must have a minimum of the CREATE SESSION and INSERT
privileges on all tables to be loaded.
d. In the Oracle database, the user must have sufficient privileges to execute the load
query.
11-9
Chapter 11
The following example connects to the TimesTen database with the ggapply user
that was created earlier:
ttIsql -connStr "DSN=myappdb;UID=ggaply;PWD=tt_pwd;OraclePWD=ora_pwd"
4. The initial table data load is used to establish data synchronization when
instantiating GoldenGate replication. To achieve the best performance for the initial
table data load:
• Use the TimesTen ttLoadFromOracle built-in procedure for the initial table
data load if the backend database is an Oracle database. See
ttLoadFromOracle in the Oracle TimesTen In-Memory Database Reference.
• Use the TimesTen ttBulkCp utility for the initial table data load if the backend
database is a non-Oracle database. Export the table data in CSV format and
then load it into TimesTen using the ttBulkCP utility. See ttBulkCp in the
Load the data for each of the GoldenGate target tables using the TimesTen
ttLoadFromOracle built-in procedure, specifying a flashback query targeting the
SCN value determined in step (2) above. For example:
call ttLoadFromOracle('ggapply', 'cachetab1', 'SELECT * FROM
oraowner.sourcetab1 AS OF SCN 12345678');
call ttLoadFromOracle('ggapply', 'cachetab2', 'SELECT * FROM
oraowner.sourcetab2 AS OF SCN 12345678');
…
Note:
If there are no dependencies (such as foreign key constraints) between
tables, then you can load them in parallel using separate ttIsql sessions.
Provided that resources are not a constraint, this can reduce the time
required for the initial data load.
You have now populated the TimesTen cache tables with data from the source Oracle
database. For more information, see Loading Data From an Oracle Database Into a
TimesTen Table in the Oracle TimesTen In-Memory Database Operations Guide.
Start GoldenGate Continuous Real-Time Replication

Start the GoldenGate Replicat process rep using GGSCI, specifying the SCN value
from which to start.
START REPLICAT rep, AFTERCSN 12345678
Note:
GoldenGate refers to this value as a CSN (Commit Sequence Number)
rather than an SCN, hence the parameter name AFTERCSN.
You can see the changes are replicated from source database to TimesTen. You can
also check the status of a Replicat process using the following GGSCI command.
11-10
Chapter 11
Example of Caching Using GoldenGate
INFO REPLICAT rep
You now have a working setup that uses GoldenGate to replicate data changes from your
source Oracle database to your TimesTen cache database.

A complete end to end example is useful in demonstrating how to create a read-only cache
using GoldenGate.
In this example, the FQDN of the system hosting the TimesTen database is
tthost1.example.com.
The DSN for the TimesTen database is ecommerce.
The GoldenGate deployment mode for TimesTen is on-box using direct mode connectivity.
Prerequisites
• A functioning Oracle database is a recent version.
• A recent version of GoldenGate is installed on the Oracle database host.
• A functioning TimesTen instance is running at least TimesTen 22.1.1.1.0.
• GoldenGate 21.3 is installed on the TimesTen host.
• The TimesTen cache database has been configured and created.
• DatabaseCharacterSet and ConnectionCharacterSet correctly set in the TimesTen
database.
Oracle User and Source Tables

The Oracle application schema owner is appuser with password OR-AbCD123-zqpx.
There is also an Oracle user named ggapply with password OR-zXy087-TvrQ, which has
SELECT privileges on the tables that are to be cached.
The appuser user owns three tables that will be cached in TimesTen:
(
custid VARCHAR2(10) NOT NULL,
firstname VARCHAR2(20) NOT NULL,
lastname VARCHAR2(20) NOT NULL,
address VARCHAR2(128) NOT NULL,
phone VARCHAR2(16) NOT NULL,
PRIMARY KEY (custid)
);
CREATE TABLE order
(
orderid NUMBER(10,0) NOT NULL,
orderdate DATE NOT NULL,
priority CHAR(1),
amount NUMBER(12,2) NOT NULL,
PRIMARY KEY (orderid),
FOREIGN KEY (custid) REFERENCES customer(custid)
);
CREATE TABLE item
11-11
Chapter 11
(
itemno NUMBER(4,0) NOT NULL,
itemcode VARCHAR2(10) NOT NULL,
quantity NUMBER(4,0) NOT NULL,
price NUMBER(6,2) NOT NULL,
totalvalue NUMBER(10,2) NOT NULL,
PRIMARY KEY (orderid,itemno),
FOREIGN KEY (orderid) REFERENCES order(orderid)
);
INSERT INTO customer VALUES('C000000001', 'Fred', 'Bloggs', 'Nice Villas,
Pleasant Town', '+16072321234');
INSERT INTO order VALUES(123456, 'C000000001', '21/10/2021', 'N', 430.46);
INSERT INTO item VALUES(1, 123456, 'I000001725', 2, 15.25, 30.50);
INSERT INTO item VALUES(2, 123456, 'I000207351', 4, 99.99, 399.96);
COMMIT;
This example performs the following steps:

1. Prepare TimesTen Users and Target Tables
2. Prepare Oracle Database for GoldenGate Replication
3. Prepare the TimesTen Database for GoldenGate Replication
4. Perform the Initial Data Load
5. Start Real-Time Replication
6. Verify That Replication is Working
Prepare TimesTen Users and Target Tables

Perform procedures to create users and the target tables that support GoldenGate
replication.
The TimesTen application user is appuser with password TT-app123-XyZ.
The TimesTen GoldenGate apply user is ggapply with password GG-912-azq.
1. To create these users in your TimesTen database, connect, using the ttIsql utility,
to the TimesTen database as the instance administrator user and execute:
CREATE USER appuser IDENTIFIED BY TT-app123-XyZ;
GRANT CREATE SESSION, CREATE SYNONYM TO appuser;
CREATE USER ggapply IDENTIFIED BY GG-912-azq;
GRANT CREATE SESSION, CREATE TABLE TO ggapply;
2. Create the target tables in the TimesTen database. Make the tables owned by the
user ggapply, not the application user (appuser). Connect to the database, using
ttIsql, as the user ggapply:
ttIsql -connStr "DSN=ecommerce;UID=ggapply;PWD=GG-912-azq"
3. Execute the following SQL statements to create the tables and grant the
necessary permissions:
(
firstname VARCHAR2(20) NOT NULL,
lastname VARCHAR2(20) NOT NULL,
address VARCHAR2(128) NOT NULL,
11-12
Chapter 11
phone VARCHAR2(16) NOT NULL,

PRIMARY KEY (custid)
);
CREATE TABLE order
(
orderdate DATE NOT NULL,
priority CHAR(1),
amount NUMBER(12,2) NOT NULL,
PRIMARY KEY (orderid),
FOREIGN KEY (custid) REFERENCES customer(custid)
);
CREATE TABLE item
(
itemno NUMBER(4,0) NOT NULL,
itemcode VARCHAR2(10) NOT NULL,
quantity NUMBER(4,0) NOT NULL,
price NUMBER(6,2) NOT NULL,
totalvalue NUMBER(10,2) NOT NULL,
PRIMARY KEY (orderid,itemno),
FOREIGN KEY (orderid) REFERENCES order(orderid)
);
GRANT SELECT ON customer TO appuser;
GRANT SELECT ON order TO appuser;
GRANT SELECT ON item TO appuser;
quit;
4. Connect as the user appuser and create synonyms for the tables:
ttIsql -connStr "DSN=ecommerce;UID=appuser; TT-app123-XyZ "
CREATE SYNONYM customer FOR ggapply.customer;
CREATE SYNONYM order FOR ggapply.order;
CREATE SYNONYM item FOR ggapply.item;
Prepare Oracle Database for GoldenGate Replication

Perform a few procedures to prepare the Oracle database to use GoldenGate replication.
1. On the Oracle Database system, prepare the parameter file for the GoldenGate Extract
process. Using a text editor, create the file gg_home/dirprm/tt.prm with the following
contents:
EXTRACT tt
USERID appuser, PASSWORD OR-AbCD123-zqpx
RMTHOST tthost1.example.com, MGRPORT 7809
RMTTRAIL dirdat/tr
TABLE appuser.customer;
TABLE appuser.order;
TABLE appuser.item;
2. Start the GGSCI utility. Assuming that the GoldenGate home directory is in the $GG_HOME
directory:
cd $GG_HOME
./ggsci
From here on all commands use GGSCI.

3. Start the GoldenGate Manager:
11-13
Chapter 11
start manager
4. Configure Oracle for GoldenGate:

DBLOGIN USERID appuser, PASSWORD OR-AbCD123-zqpx
ADD SCHEMATRANDATA appuser
ADD EXTRACT tt, INTEGRATED TRANLOG, BEGIN NOW
REGISTER EXTRACT tt, DATABASE
ADD RMTTRAIL dirdat/tr, EXTRACT dirdat/tr
5. Start the GoldenGate Extract process using the file you configured above:
start tt
Prepare the TimesTen Database for GoldenGate Replication

There are a few procedures to perform when preparing the TimesTen database to
receive GoldenGate replication.
1. On the TimesTen host, use a text editor to create the Replicat parameter file
gg_home/dirprm/REP.prm with the following contents:
REPLICAT rep
TARGETDB ecommerce, USERID ggapply, PASSWORD GG-912-azq
BATCHSQL
APPLY_PARALLELISM 4
MAP appuser.*, TARGET ggapply.*;
2. Start the GGSCI utility. Assuming that the GoldenGate home directory is in
the $GG_HOME directory:
cd $GG_HOME
./ggsci
From here on all commands use GGSCI.

3. Start the GoldenGate Manager:
start manager
4. Login to the TimesTen database, create the GoldenGate checkpoint table and
configure a Replicat group:
DBLOGIN SOURCEDB ecommerce, USERID ggapply, PASSWORD GG-912-azq
ADD CHECKPOINTTABLE ggapply.gg_ckpt_table
ADD REPLICAT rep, EXTTRAIL dirdat/tr, PARALLEL, CHECKPOINTTABLE
ggapply.gg_ckpt_table
Perform the Initial Data Load

The first procedure to starting the cache operations is to perform an initial data load of
what is currently in the tables that are to be cached.
1. On the host with the Oracle database, determine the current SCN value (using
SQL*Plus):
SELECT CURRENT_SCN FROM V$DATABASE;
CURRENT_SCN
-----------
2791297
11-14
Chapter 11
2. On the host with the TimesTen database, connect to the TimesTen database as the
ggapply user specifying both the TimesTen and Oracle database passwords for this user:
ttIsql -connStr "DSN=ecommerce;UID=ggaply;PWD= GG-912-azq;
OraclePWD=OR-zXy087-TvrQ
3. Load the data for each of the tables based on the Oracle database SCN value
determined above:
call ttLoadFromOracle('ggapply', 'customer',
'SELECT * FROM appuser.customer AS OF scn 2791297');
call ttLoadFromOracle('ggapply', 'order', 'SELECT * FROM appuser.order
AS OF SCN 2791297');
call ttLoadFromOracle('ggapply', item, 'SELECT * FROM appuser.item
AS OF SCN 2791297');
4. Update the optimizer statistics for the tables that you just loaded to ensure optimal query
plans in TimesTen:
statsupdate customer;
statsupdate order;
statsupdate item;
quit;
Start Real-Time Replication

Using GGSCI, start a Replicat process beginning with the SCN value used for the data load.
Assuming that the GoldenGate home directory is in the $GG_HOME directory.
cd $GG_HOME
./ggsci
START REPLICAT rep, AFTERCSN 2791297
Verify That Replication is Working

Once you have replication set up, verify that replication is working.
On the Oracle database, insert, update, and/or delete rows to add new data into the
replicated tables.
On the TimesTen database, select from the replicated tables and verify that the changes are
being propagated from the Oracle database.
You can also check the status of a Replicat process using the GGSCI command:
INFO REPLICAT rep
11-15
A
Procedure and Privileges for Caching Oracle
Database Data in TimesTen
The following sections provide a quick reference on the steps for creating a cache
environment as well as the privileges required to do so:
• Quick Reference to Cache Oracle Database Data in TimesTen
• Required Privileges for Cache Operations
Quick Reference to Cache Oracle Database Data in TimesTen

This is a quick reference on the steps necessary when setting up an environment that caches
Oracle Database data into a TimesTen database.
For a detailed explanation and examples for each step, see Getting Started, Setting Up a
Caching Infrastructure, and Defining Cache Groups.
Perform the following on the Oracle database:
1. Create a default tablespace to be used for storing cache management objects.
2. As the sys user, create one or more schema users to own the cached Oracle Database
tables (may be existing users).
3. As the sys user, create the Oracle cache administration user that creates, owns, and
maintains Oracle Database objects that store information used to enforce predefined
behaviors of particular cache group types. In the CREATE USER statement for the Oracle
cache administration user, designate the default tablespace of the Oracle cache
See Create the Oracle Database Users and Default Tablespace for more information
about the Oracle Database users.
4. As the sys user, run the timesten_home/install/oraclescripts/
grantCacheAdminPrivileges.sql script to grant the Oracle cache administration user the
privileges required to create the desired types of cache groups and perform operations
on the cache groups. Alternatively, you can manually create each Oracle Database
object.
See Create Oracle Database Objects Used to Manage Data Caching or The
initCacheAdminSchema.sql Script to determine the appropriate script to run.
5. Some privileges cannot be granted until the cached Oracle Database tables have been
created. To grant these privileges, run GRANT statements as the sys user.
See Required Privileges for Cache Operations.
Perform the following on the TimesTen database:
1. Specify connection attributes used to connect to the TimesTen database that is to be
used to cache data from an Oracle database. In TimesTen Classic, these are specified
A-1
Appendix A
Quick Reference to Cache Oracle Database Data in TimesTen
within the DSN. In TimesTen Scaleout, these can be specified in either the
database definition or in a connectable.
a. Set the OracleNetServiceName connection attribute to the Oracle Net service
name that references the Oracle database instance.
b. Set the DatabaseCharacterSet connection attribute to the Oracle database
character set. The TimesTen database character set must match the Oracle
database character set.
See Specify Database Connection Definition for Cache.
2. Create the following users in the TimesTen database:
• TimesTen cache administration user
This user must have the same name as a companion Oracle cache
administration user that can access the cached Oracle Database tables. The
password of the TimesTen cache administration user and the companion
Oracle cache administration user can be different.
• One or more cache table users who own the TimesTen cache tables
These users must have the same name as the Oracle Database schema
users who own the cached Oracle Database tables. The password of a cache
table user and the Oracle Database user with the same name can be different.
Run CREATE USER statements as the instance administrator.
3. Grant the TimesTen cache administration user the privileges required to create the
desired types of cache groups and perform operations on the cache groups. Run
GRANT statements as the instance administrator.
See Required Privileges for Cache Operations.
4. Set the Oracle cache administration user name and password in the TimesTen
database.
5. Start the cache agent on the TimesTen database.
6. Design the schema for the cache groups by determining which Oracle Database
tables to cache and within those tables, which columns and rows to cache. For
multiple table cache groups, determine the relationship between the tables by
defining which table is the root table, which tables are direct child tables of the root
table, and which tables are the child tables of other child tables. For each cached
column, determine the TimesTen data type to which the Oracle Database data
type should be mapped.
See Mappings Between Oracle Database and TimesTen Data Types.
For each cache group, determine what type to create (read-only, SWT, AWT, or
user managed) based on the application requirements and objectives. Also,
determine whether each cache group is to be static or dynamic.
Then, create the cache groups. See Creating a Cache Group.
7. For TimesTen Classic, if this TimesTen database is intended to be an active
database of an active standby pair, create an active standby pair replication
A-2
Appendix A
Required Privileges for Cache Operations
scheme in the database. See Defining an Active Standby Pair Replication Scheme in the
Oracle TimesTen In-Memory Database Replication Guide.
8. For TimesTen Classic, if the TimesTen database contains an active standby pair
replication scheme or at least one AWT cache group, start the replication agent on the
database either by calling the ttRepStart built-in procedure as the TimesTen cache
administration user or running a ttAdmin -repStart utility command as a TimesTen
external user with the CACHE_MANAGER privilege.
9. Manually load the cache tables in static cache groups using LOAD CACHE GROUP
statements, and load the cache tables in dynamic cache groups using proper SELECT,
UPDATE or INSERT statements.
See Manually Loading and Refreshing a Cache Group and Dynamic Cache Groups.

The privileges that the Oracle Database users require depends on the types of cache groups
you create and the operations that you perform on the cache groups.
The privileges required for the Oracle cache administration user are listed in the first column
and the privileges required for the TimesTen cache administration user for each cache
operation are listed in the second column in Table A-1.
Table A-1 Oracle Database and TimesTen User Privileges Required for Cache Operations
Cache Operation Privileges Required for Oracle Privileges Required for

Database Cache Administration User1 TimesTen Cache
Administration User2
Minimum privileges required At minimum, the Oracle cache At minimum, the TimesTen cache
administration user must have the administration user must have
CREATE TYPE privilege the CREATE SESSION privilege.
A-3
Appendix A
Table A-1 (Cont.) Oracle Database and TimesTen User Privileges Required for Cache
Operations

Initialize the Oracle cache CREATE ANY TRIGGER3,4 None
administration user with the CREATE PROCEDURE4
grantCacheAdminPrivileges.sq
l script, which grants these CREATE SEQUENCE
privileges. CREATE SESSION
CREATE TABLE
CREATE TYPE
EXECUTE ON SYS.DBMS_DDL package
EXECUTE ON SYS.DBMS_FLASHBACK
package
EXECUTE ON SYS.DBMS_LOB package
EXECUTE ON SYS.DBMS_LOCK package
SELECT ANY TRANSACTION
SELECT ON SYS.ALL_OBJECTS
SELECT ON SYS.ALL_SYNONYMS
SELECT ON SYS.DBA_DATA_FILES
SELECT ON SYS.GV_$LOCK
SELECT ON SYS.GV_$SESSION
SELECT ON SYS.USER_FREE_SPACE
SELECT ON SYS.USER_SYS_PRIVS
SELECT ON SYS.USER_TS_QUOTAS
SELECT ON SYS.USER_USERS
SELECT ON SYS.V_$DATABASE
SELECT ON SYS.V_$PROCESS
SELECT ON SYS.V_$SESSION
TT_CACHE_ADMIN_ROLE
UNLIMITED TABLESPACE
A-4
Appendix A
Operations

Initialize the Oracle cache CREATE ANY TRIGGER None
administration user with the CREATE SESSION
initCacheAdminSchema.sql
script, which grants these privileges. CREATE TYPE
EXECUTE ON SYS.DBMS_DDL package
EXECUTE ON SYS.DBMS_FLASHBACK
package
EXECUTE ON SYS.DBMS_LOCK package
SELECT ANY TRANSACTION
SELECT ON SYS.ALL_OBJECTS
SELECT ON SYS.ALL_SYNONYMS
SELECT ON SYS.DBA_DATA_FILES
SELECT ON SYS.GV_$LOCK
SELECT ON SYS.GV_$SESSION
SELECT ON SYS.USER_FREE_SPACE
SELECT ON SYS.USER_SYS_PRIVS
SELECT ON SYS.USER_TS_QUOTAS
SELECT ON SYS.USER_USERS
SELECT ON SYS.V_$DATABASE
SELECT ON SYS.V_$PROCESS
SELECT ON SYS.V_$SESSION
TT_CACHE_ADMIN_ROLE
UNLIMITED TABLESPACE
Set the Oracle cache administration CREATE PROCEDURE4 CACHE_MANAGER
user or TimesTen cache CREATE SEQUENCE Requires access to the default
administration user name and tablespace on the Oracle
password: CREATE SESSION
database. See Create the Oracle
• In TimesTen Classic, you can CREATE TABLE Database Users and Default
call the ttCacheUidPwdSet CREATE TRIGGER Tablespace.
built-in procedure.
CREATE TYPE
• In TimesTen Classic, you can
run the ttAdmin - Requires access to the default
tablespace on the Oracle database. See
cacheUidPwdSet utility
Create the Oracle Database Users and
command.
Default Tablespace.
• In TimesTen Scaleout, run the
ttGridAdmin
dbCacheCredentialSet
command.
A-5
Appendix A
Operations

Get the Oracle cache administration None CACHE_MANAGER
user or TimesTen cache
administration user name with either:
• Call the ttCacheUidGet built-in
procedure.
run the ttAdmin -
cacheUidGet utility command.
Start the cache agent with either: CREATE SESSION CACHE_MANAGER
call the ttCacheStart built-in
procedure.
run the ttAdmin -cacheStart
utility command.
ttGridAdmin dbCacheStart
command.
Stop the cache agent None CACHE_MANAGER
call the ttCacheStop built-in
procedure
run the ttAdmin -cacheStop
utility command
ttGridAdmin dbCacheStop
command.
In TimesTen Classic, set a cache CREATE SESSION4 CACHE_MANAGER
agent start policy with either:
• Call the ttCachePolicySet
built-in procedure.
• Run the ttAdmin -
cachePolicy utility command.
In TimesTen Classic, return the CREATE SESSION None
cache agent start policy setting:
• Call the ttCachePolicyGet
built-in procedure.
In TimesTen Classic, start the None CACHE_MANAGER
replication agent with either:
• Call the ttRepStart built-in
procedure.
• Run the ttAdmin -repStart
utility command.
A-6
Appendix A
Operations

In TimesTen Classic, stop the None CACHE_MANAGER
replication agent with either:
• Call the ttRepStop built-in
procedure.
• Run the ttAdmin -repStop
utility command.
In TimesTen Classic, set a replication None ADMIN
agent start policy
• Call the ttRepPolicySet built-
in procedure
• Run the ttAdmin -repPolicy
utility command
In TimesTen Classic, CREATE CREATE TRIGGER Creating a cache group requires
ACTIVE STANDBY PAIR with Creating a cache group requires access access to the default tablespace
INCLUDE CACHE GROUP to the default tablespace on the Oracle on the Oracle database. See
database. See Create the Oracle Create the Oracle Database
when the cache group created is an
Users and Default Tablespace.
AWT cache group Database Users and Default Tablespace.
In TimesTen Classic, duplicate the CREATE TRIGGER None

database with ttRepAdmin -
duplicate when using an AWT
cache group within an active standby
pair replication scheme
CREATE [DYNAMIC] READONLY CREATE PROCEDURE4 CREATE [ANY] CACHE GROUP6
CACHE GROUP with AUTOREFRESH CREATE SEQUENCE CREATE [ANY] TABLE7
MODE INCREMENTAL
CREATE SESSION Creating a cache group requires
CREATE TABLE access to the default tablespace
on the Oracle database. See
CREATE TYPE Create the Oracle Database
SELECT ON table_name5 Users and Default Tablespace.
CREATE ANY TRIGGER4
Creating a cache group requires access
to the default tablespace on the Oracle
Database Users and Default Tablespace.
In TimesTen Classic, CREATE CREATE SESSION CREATE [ANY] CACHE GROUP6
[DYNAMIC] READONLY CACHE SELECT ON table_name5 CREATE [ANY] TABLE7
GROUP with AUTOREFRESH MODE
Creating a cache group requires access Creating a cache group requires
FULL
to the default tablespace on the Oracle access to the default tablespace
database. See Create the Oracle on the Oracle database. See
Database Users and Default Tablespace. Create the Oracle Database
A-7
Appendix A
Operations

In TimesTen Classic, CREATE CREATE PROCEDURE4 CREATE [ANY] CACHE GROUP6
[DYNAMIC] ASYNCHRONOUS CREATE SEQUENCE CREATE [ANY] TABLE7
WRITETHROUGH CACHE GROUP
CREATE TRIGGER Create the Oracle Database
CREATE TYPE Users and Default Tablespace.
SELECT ON table_name5
[DYNAMIC] SYNCHRONOUS SELECT ON table_name5 CREATE [ANY] TABLE7
WRITETHROUGH CACHE GROUP
[DYNAMIC] USERMANAGED CACHE SELECT ON table_name5 CREATE [ANY] TABLE7
GROUP
(see variants in following rows) to the default tablespace on the Oracle access to the default tablespace
In TimesTen Classic, CREATE CREATE PROCEDURE4 CREATE [ANY] CACHE GROUP6
[DYNAMIC] USERMANAGED CACHE CREATE SEQUENCE CREATE [ANY] TABLE7
INCREMENTAL
CREATE TYPE Create the Oracle Database
SELECT ON table_name5 Users and Default Tablespace.
CREATE ANY TRIGGER4
FULL
A-8
Appendix A
Operations

GROUP with READONLY
GROUP with PROPAGATE
ALTER CACHE GROUP SET CREATE PROCEDURE4 ALTER ANY CACHE GROUP9
AUTOREFRESH STATE PAUSED CREATE SEQUENCE
CREATE SESSION
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
SELECT ON table_name5,8
CREATE ANY TRIGGER4 ,8
ALTER CACHE GROUP SET CREATE PROCEDURE4 ALTER ANY CACHE GROUP9
AUTOREFRESH STATE ON CREATE SEQUENCE
CREATE SESSION
CREATE TABLE
CREATE TYPE
SELECT ON table_name5, 8
CREATE ANY TRIGGER4, 8
ALTER CACHE GROUP SET CREATE SESSION ALTER ANY CACHE GROUP9
AUTOREFRESH STATE OFF
In TimesTen Classic, ALTER CACHE CREATE SESSION ALTER ANY CACHE GROUP9
GROUP SET AUTOREFRESH MODE
FULL
A-9
Appendix A
Operations

In TimesTen Classic, ALTER CACHE CREATE PROCEDURE4 ALTER ANY CACHE GROUP9
GROUP SET AUTOREFRESH MODE CREATE SEQUENCE
INCREMENTAL
CREATE SESSION
CREATE TABLE
CREATE TYPE
CREATE ANY TRIGGER4
ALTER CACHE GROUP SET CREATE SESSION ALTER ANY CACHE GROUP9
AUTOREFRESH INTERVAL SELECT ON table_name5, 10
LOAD CACHE GROUP CREATE SESSION LOAD {ANY CACHE GROUP |
SELECT ON table_name5 ON cache_group_name}9
For TimesTen Scaleout:
INSERT ON table_name5
EXECUTE ON
SYS.DBMS_FLASHBACK package
on the Oracle Database
REFRESH CACHE GROUP CREATE SESSION REFRESH {ANY CACHE GROUP
SELECT ON table_name5 | ON cache_group_name}9
For TimesTen Scaleout:
EXECUTE ON
SYS.DBMS_FLASHBACK package
on the Oracle Database
FLUSH CACHE GROUP SELECT ON table_name5 SELECT ON table_name5
CREATE SESSION FLUSH {ANY CACHE GROUP |
UPDATE ON table_name5 ON cache_group_name}9
UNLOAD CACHE GROUP None UNLOAD {ANY CACHE GROUP |
ON cache_group_name}9
DROP CACHE GROUP CREATE SESSION DROP ANY CACHE GROUP9
DROP ANY TABLE11
In TimesTen Classic, synchronous CREATE SESSION INSERT ON table_name13
writethrough or propagate INSERT ON table_name5, 12 UPDATE ON table_name13
12
UPDATE ON table_name5, DELETE ON table_name13
12
DELETE ON table_name5,
A-10
Appendix A
Operations

In TimesTen Classic, asynchronous CREATE SESSION INSERT ON table_name13
writethrough INSERT ON table_name5 UPDATE ON table_name13
UPDATE ON table_name5 DELETE ON table_name13
DELETE ON table_name5
In TimesTen Classic, asynchronous CREATE PROCEDURE None
writethrough when the Note: This privilege is an addition to the
CacheAWTMethod connection privileges needed for any asynchronous
attribute is set to 1 writethrough cache group.
In TimesTen Classic, asynchronous EXECUTE privilege on the Oracle None
writethrough cache for Oracle Database DBMS_LOB PL/SQL package
Database CLOB, BLOB and NCLOB
Note: This privilege is an addition to the
fields when the CacheAWTMethod privileges needed for any asynchronous
connection attribute is set to 1 writethrough cache group.
Incremental autorefresh SELECT ON table_name5 None
Full autorefresh SELECT ON table_name5 None
In TimesTen Classic, dynamic load CREATE SESSION SELECT ON table_name13
SELECT ON table_name5 UPDATE ON table_name13
DELETE ON table_name13
In TimesTen Classic, aging None DELETE {ANY TABLE | ON
table_name}13
In TimesTen Classic, set the LRU None ADMIN
aging attributes
• Call the ttAgingLRUConfig
built-in procedure
• Call the
ttAgingTableLRUConfig built-
in procedure
Generate Oracle Database SQL CREATE SESSION CACHE_MANAGER
statements to manually install or
uninstall Oracle Database objects
• Run the ttIsql utility's
cachesqlget command
• Call the ttCacheSQLGet built-in
procedure
In TimesTen Classic, disable or None CACHE_MANAGER
enable propagation of committed
cache table updates to the Oracle
database
• Call the
ttCachePropagateFlagSet
built-in procedure
A-11
Appendix A
Operations

Configure cache agent timeout and CREATE SESSION CACHE_MANAGER
recovery method for cache groups
with autorefresh
• Call the ttCacheConfig built-in
procedure
In TimesTen Classic, set the AWT None CACHE_MANAGER
transaction log file threshold
• Call the
ttCacheAWTThresholdSet
built-in procedure
In TimesTen Classic, enable or None CACHE_MANAGER
disable monitoring of AWT cache
groups
• Call the
ttCacheAWTMonitorConfig
built-in procedure
Enable or disable tracking of DDL CREATE SESSION CACHE_MANAGER
statements issued on cached Oracle
Database tables
• Call the
ttCacheDDLTrackingConfig
built-in procedure
1 At minimum, the Oracle cache administration user must have the CREATE TYPE privilege.
2 At minimum, the TimesTen cache administration user must have the CREATE SESSION privilege.
3 If the Oracle cache administration user will not create cache groups with autorefresh, then you can grant the CREATE
TRIGGER privilege instead of the CREATE ANY TRIGGER privilege.
4 Required if the cache agent start policy is being set to always or norestart.
5 Required on all Oracle Database tables cached in the TimesTen cache group except for tables owned by the Oracle cache
6 The CACHE_MANAGER privilege includes the CREATE [ANY] CACHE GROUP privilege. ANY is required if the TimesTen
cache administration user creates cache groups owned by a user other than itself.
7 ANY is required if any of the cache tables are owned by a user other than the TimesTen cache administration user.
8 Required if the cache group's autorefresh mode is incremental and initial autorefresh state is OFF, and the Oracle Database
objects used to manage the caching of Oracle Database data are automatically created.
9 Required if the TimesTen user accessing the cache group does not own the cache group.
1 Required if the cache group's autorefresh mode is incremental.
0
1 Required if the TimesTen user accessing the cache group does not own all its cache tables.
1
1 The privilege must be granted to the Oracle Database user with the same name as the TimesTen cache administration user if
2 the Oracle Database user is not the Oracle cache administration user.
1 Required if the TimesTen user accessing the cache table does not own the table.
3
A-12
B
SQL*Plus Scripts for Cache
TimesTen is installed with SQL*Plus scripts that are used to perform various cache
configuration, administrative and monitoring tasks, and provide links to more information
including examples.
All scripts are installed in the timesten_home/install/oraclescripts directory.
Installed SQL*Plus Scripts

There are SQL*Plus scripts that are installed with TimesTen.
• cacheCleanUp.sql: This script drops Oracle Database objects such as change log tables
and triggers used to implement autorefresh operations for TimesTen Classic. This script
is used when a TimesTen Classic database containing cache groups with autorefresh is
unavailable because the TimesTen Classic system is offline, or the database was
destroyed without dropping its cache groups with autorefresh. Run this script as the
cache administration user. Provide the host name of the TimesTen Classic system and
the TimesTen database (including its path) as arguments. See Dropping Oracle Database
Objects Used by Cache Groups With Autorefresh.
• cacheInfo.sql: This script returns change log table information for all Oracle Database
tables cached in a cache group with autorefresh, and information about Oracle Database
objects used to track DDL statements issued on cached Oracle Database tables. This
script is used to monitor autorefresh operations on cache groups and DDL statements
issued on cached Oracle Database tables. Run this script as the cache administration
user. See Monitoring Autorefresh Operations on Cache Groups and Tracking DDL
Statements Issued on Cached Oracle Database Tables.
• grantCacheAdminPrivileges.sql: This script grants privileges to the cache
administration user that are required to automatically create Oracle Database objects
used to manage the caching of Oracle Database data when particular cache group
operations are performed. This includes the TT_CACHE_ADMIN_ROLE role that defines
privileges on Oracle Database tables. Run this script as the sys user. See Create Oracle
Database Objects Used to Manage Data Caching.
• initCacheAdminSchema.sql: This script grants a minimal set of privileges to the cache
administration user and manually creates Oracle Database objects used to manage the
caching of Oracle Database data. This includes the TT_CACHE_ADMIN_ROLE role that
defines privileges on Oracle Database tables. Run this script as the sys user. See The
initCacheAdminSchema.sql Script.
• scaleoutCacheCleanUp.sql: This script drops Oracle Database objects such as change
log tables and triggers used to implement autorefresh operations for TimesTen Scaleout.
This script is used when a TimesTen Scaleout database containing cache groups with
autorefresh is unavailable because the TimesTen Scaleout system is offline, or the
database was destroyed without dropping its cache groups with autorefresh. Run this
script as the cache administration user. Provide the grid name and the TimesTen
database name as arguments. See Dropping Oracle Database Objects Used by Cache
Groups With Autorefresh.
B-1
C
Compatibility Between TimesTen and Oracle
Databases
The following sections list compatibility issues between TimesTen and Oracle Databases. The
list is not complete, but it indicates areas that require special attention.
• Summary of Compatibility Issues
• Transaction Semantics
• API Compatibility
• SQL Compatibility
• Mappings Between Oracle Database and TimesTen Data Types
Summary of Compatibility Issues

There are a few compatibility issues between the TimesTen and Oracle databases.
Consider the following differences between TimesTen and Oracle databases:
• TimesTen and Oracle database metadata are stored differently. See API Compatibility.
• TimesTen and Oracle databases have different transaction isolation models. See
Transaction Semantics.
• TimesTen and Oracle databases have different connection and statement properties. For
example, TimesTen does not support catalog names, scrollable cursors or updateable
cursors.
• Sequences are not cached and synchronized between the TimesTen database and the
corresponding Oracle database. See SQL Expressions.
• Side effects of Oracle Database triggers and stored procedures are not reflected in the
TimesTen database until after an automatic or manual refresh operation.
Transaction Semantics
TimesTen and Oracle Database transaction semantics differ in a few ways.
• Oracle Database serializable transactions can fail at commit time because the transaction
cannot be serialized. TimesTen uses locking to enforce serializability.
• Oracle Database can provide both statement-level and transaction-level consistency by
using a multi-version consistency model. TimesTen does not provide statement-level
consistency. TimesTen provides transaction-level consistency by using serializable
isolation.
• Oracle Database users can lock tables manually through SQL. This locking feature is not
supported in TimesTen.
• Oracle Database supports savepoints while TimesTen does not.
C-1
Appendix C
API Compatibility
• In Oracle Database, a transaction can be set to be read-only or read/write. This is

not supported in TimesTen.
See Transaction Management in Oracle TimesTen In-Memory Database Operations
Guide.
API Compatibility
There are methods from the JDBC and ODBC APIs that have a compatibility issue
with cache.
The following sections list methods from the JDBC and ODBC APIs that have a
compatibility issue with cache.
• JDBC API Compatibility
• ODBC API Compatibility
JDBC API Compatibility

There are compatibility issues that apply to the JDBC API.
Compatibility issues that apply to JDBC include the following:
• JDBC database metadata functions return TimesTen metadata. If you want Oracle
metadata, connect to the Oracle Database directly.
• The set/get connection and statement attributes are performed on TimesTen.
• All Oracle java.sql.ResultSet metadata (length, type, label) is returned in
TimesTen data type lengths. The column labels that are returned are TimesTen
column labels.
• Oracle extensions (oracle.sql and oracle.jdbc packages) are not supported.
• Java stored procedures are not supported in TimesTen.
java.sql.Connection
The following Connection methods have no compatibility issues:
close()
commit()
createStatement()
prepareCall()
prepareStatement()
rollback()
setAutoCommit()
The following methods are run locally in TimesTen:

getCatalog()
getMetaData
get/setTransactionIsolation()
isReadOnly()
isClosed()
nativeSQL()
setCatalog()
setReadOnly()
C-2
Appendix C
API Compatibility
Note:
See Transaction Semantics for restrictions for the get/setTransactionIsolation()
methods.
The isClosed() method returns only the TimesTen connection status.
java.sql.Statement
The following Statement methods have no compatibility issues:
addBatch()
clearBatch()
close()
execute()
executeBatch()
executeQuery()
executeUpdate()
getResultSet()
getUpdateCount()
getWarnings()
The following methods run locally in TimesTen:

cancel()
get/setMaxFieldSize()
get/setMaxRows()
get/setQueryTimeout()
getMoreResults()
setEscapeProcessing()
setCursorName()
java.sql.ResultSet
The following ResultSet methods have no compatibility issues:
close()
findColumn(int) and findColumn(string)
getXXX(number) and getXXX(name)
getXXXStream(int) and getXXXStream(string)
getMetaData()
java.sql.PreparedStatement
The following PreparedStatement methods have no compatibility issues:
addBatch()
close()
execute()
executeUpdate()
executeQuery()
getResultSet()
getUpdateCount()
setXXX()
setXXXStream()
C-3
Appendix C
API Compatibility

cancel()
get/setMaxFieldSize()
get/setMaxRows()
get/setQueryTimeout()
getMoreResults()
setEscapeProccessing()
setCursorName()
java.sql.CallableStatement
The same restrictions as shown for the java.sql.Statement and
java.sql.PreparedStatement interfaces apply to CallableStatement.
• In a WRITETHROUGH cache group, if PassThrough=1, indirect DML operations that

are hidden in stored procedures or induced by triggers may be passed through
without being detected by Cache Connect to Oracle.
• Stored procedures that update, insert, or delete from READONLY cache group tables
will be autorefreshed within another transaction in an asynchronous fashion. Thus,
the changes do not appear within the same transaction that the stored procedure
was processed within and there may be some time lapse before the changes are
autorefreshed into the cache table.
java.sql.ResultSetMetaData
The following ResultSetMetaData methods have no compatibility issues:
getColumnCount()
getColumnType()
getColumnLabel()
getColumnName()
getTableName()
isNullable()

getSchemaName()
getCatalogName()
getColumnDisplaySize()
getColumnType()
getColumnTypeName()
getPrecision()
getScale()
isAutoIncrement()
isCaseSensitive()
isCurrency()
isDefinitelyWritable()
isReadOnly()
isSearchable()
isSigned()
isWritable()
Stream Support
There are compatibility issues related to streams.
The compatibility issues related to streams are:
C-4
Appendix C
SQL Compatibility
• The JDBC driver fully fetches the data into an in-memory buffer during a call to the
executeQuery() or next() methods. The getXXXStream() entry points return a stream
that reads data from this buffer.
• Oracle supports up to 2 GB of long or long raw data. When cached, TimesTen converts
LONG data into VARCHAR2 data. TimesTen converts LONG RAW data into VARBINARY data.
Both VARCHAR2 and VARBINARY data types can store up to a maximum 4,194,304 (222)
bytes).
• Oracle always streams LONG/LONG RAW data even if the application does not call
getXXXStream().
• TimesTen does not support the mark(), markSupported(), and reset() methods.
ODBC API Compatibility

Cache in TimesTen is compatible with a subset of ODBC functions.
Table C-1 describes the compatibility of ODBC functions.
Table C-1 ODBC Function Compatibility With Cache in TimesTen
Function Name Compatibility

SQLBindParameter Default TimesTen behavior matches Oracle Database behavior. See
Binding Parameters and Running Statements in Oracle TimesTen In-
Memory Database C Developer's Guide.
SQLBrowseConnect, Not supported.
SQLColumnPrivileges,
SQLExtendedFetch,
SQLMoreResults,
SQLSetPos,
SQLSetScrollOptions,
SQLTablePrivileges
SQLCancel There are some restrictions. In particular, SQLCancel cannot cancel
TimesTen administrative operations. See the SQLCancel entry in
ODBC 2.5 Function Support in the Oracle TimesTen In-Memory
Database C Developer's Guide.
SQLGetCursorName There are some restrictions. See the SQLGetCursorName entry in
ODBC 2.5 Function Support in the Oracle TimesTen In-Memory
Database C Developer's Guide.
SQL Compatibility
This section compares TimesTen's SQL implementation with Oracle Database SQL.
The purpose is to provide users with a list of Oracle Database SQL features not supported in
TimesTen or supported with different semantics.
• Schema Objects
• Non-Schema Objects
• Differences Between Oracle Database and TimesTen Tables
• Data Type Support
C-5
Appendix C
SQL Compatibility
• SQL Operators
• SELECT Statements
• SQL Subqueries
• SQL Functions
• SQL Expressions
• INSERT/DELETE/UPDATE/MERGE Statements
• TimesTen-Only SQL and Built-In Procedures
• PL/SQL Constructs
Schema Objects
TimesTen does not recognize some of the schema objects that are supported in
Oracle Database.
TimesTen returns a syntax error when a statement manipulates or uses these objects.
TimesTen passes the statement to Oracle Database. The unsupported objects are:
Clusters
Objects created by the CREATE DATABASE statement
Objects created by the CREATE JAVA statement
Database links
Database triggers
Dimensions
Extended features
External procedure libraries
Index-organized tables
Mining models
Partitions
Object tables, types and views
Operators
TimesTen supports views and materialized views, but it cannot cache an Oracle
Database view. TimesTen can cache an Oracle Database materialized view in a user-
managed cache group without the AUTOREFRESH cache group attribute and PROPAGATE
cache table attribute. The cache group must be manually loaded and flushed.
Caching Oracle Database Partitioned Tables

TimesTen can cache Oracle Database partitioned tables at the table level, but
individual partitions cannot be cached.
The following describes how operations on partitioned tables affect cache groups:
• DDL operations on a table that has partitions do not affect the cache group unless
there is data loss. For example, if a partition with data is truncated, an
AUTOREFRESH operation does not delete the data from the corresponding cached
table.
• WHERE clauses in any cache group operations cannot reference individual partitions
or sub-partitions. Any attempt to define a single partition of a table returns an error.
C-6
Appendix C
SQL Compatibility
Non-Schema Objects
TimesTen does not recognize some of the schema objects that are supported in Oracle
Database.
TimesTen returns a syntax error when a statement manipulates or uses these objects.
TimesTen passes the statement to Oracle Database. The unsupported objects are:
Contexts
Directories
Editions
Restore points
Roles
Rollback segments
Tablespaces
Differences Between Oracle Database and TimesTen Tables

TimesTen supports a subset of the Oracle Database features.
The Oracle Database table features that TimesTen does not support are:
• ON DELETE SET NULL
• Check constraints
• Foreign keys that reference the table on which they are defined
Data Type Support

Certain Oracle Database data types are not supported by TimesTen.
TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
UROWID
BFILE
Oracle Database-supplied types
User-defined types
The following TimesTen data types are not supported by Oracle Database:
TT_CHAR
TT_VARCHAR
TT_NCHAR
TT_NVARCHAR
TT_BINARY
TT_VARBINARY
TINYINT and TT_TINYINT
TT_SMALLINT
TT_INTEGER
TT_BIGINT
C-7
Appendix C
SQL Compatibility
TT_DECIMAL
TT_DATE
TIME and TT_TIME
TT_TIMESTAMP
Note:
TimesTen NCHAR and NVARCHAR2 data types are encoded as UTF-16. Oracle
Database NCHAR and NVARCHAR2 data types are encoded as either UTF-16 or
UTF-8.
To cache an Oracle Database NCHAR or NVARCHAR2 column, the Oracle
Database NLS_NCHAR_CHARACTERSET encoding must be AL16UTF16, not
AL32UTF8.
SQL Operators
TimesTen supports a subset of operators and predicates that are supported by the
Oracle Database:
unary -
+, -, *, /
=, <, >, <=, >=, <>, !=
||
IS NULL, IS NOT NULL
LIKE (Oracle Database LIKE operator ignores trailing spaces, but TimesTen does
not)
BETWEEN
IN
NOT IN (list)
AND
OR
+ (outer join)
ANY, SOME
ALL (list)
EXISTS
UNION
MINUS
INTERSECT
To run a bitwise AND operation of two bit vector expressions, TimesTen uses the
ampersand character (&) between the expressions while Oracle Database uses the
BITAND function with the expressions as arguments.
C-8
Appendix C
SQL Compatibility
SELECT Statements
TimesTen supports a subset of clauses of a SELECT statement that are supported by the
Oracle Database:
• FOR UPDATE
• ORDER BY, including NULLS FIRST and NULLS LAST
• GROUP BY, including ROLLUP, GROUPING_SETS and grouping expression lists
• Table alias
• Column alias
• Subquery factoring clause with constructor
Oracle Database supports flashback queries, which are queries against a database that is in
some previous state (for example, a query on a table as of yesterday). TimesTen does not
support flashback queries.
TimesTen does not support the CONNECT BY clause.
SQL Subqueries
TimesTen supports a subset of subqueries that are supported by the Oracle Database.
IN (subquery)
>,<,= ANY (subquery)
>,=,< SOME (subquery)
EXISTS (subquery)
>,=,< (scalar subquery)
Subqueries in WHERE clause of DELETE/UPDATE
Subqueries in FROM clause
Subquery factoring clause (WITH constructor)
Note:
A nonverifiable scalar subquery is a scalar subquery whose 'single-row-result-set'
property cannot be determined until runtime. TimesTen allows at most one
nonverifiable scalar subquery in the entire query and the subquery cannot be
specified in an OR expression.
SQL Functions
TimesTen supports a subset of functions that are supported by the Oracle Database.
ABS
ADD_MONTHS
ASCIISTR
AVG
CAST
C-9
Appendix C
SQL Compatibility
CEIL
COALESCE
CONCAT
COUNT
CHR
DECODE
DENSE_RANK
EMPTY_BLOB
EMPTY_CLOB
EXTRACT
FIRST_VALUE
FLOOR
GREATEST
GROUP_ID
GROUPING
GROUPING_ID
INSTR
LAST_VALUE
LEAST
LENGTH
LOWER
LPAD
LTRIM
MAX
MIN
MOD
MONTHS_BETWEEN
NCHR
NLS_CHARSET
NLS_CHARSET_NAME
NLSSORT
NULLIF
NUMTOYMINTERVAL
NUMTODSINTERVAL
NVL
POWER
RANK
REPLACE
ROUND
ROW_NUMBER
RPAD
RTRIM
SIGN
SQRT
SUBSTR
SUM
SYS_CONTEXT
SYSDATE
TO_BLOB
C-10
Appendix C
SQL Compatibility
TO_CLOB
TO_CHAR
TO_DATE
TO_LOB
TO_NCLOB
TO_NUMBER
TRIM
TRUNC
UID
UNISTR
UPPER
USER
These TimesTen functions are not supported by Oracle Database:

CURRENT_USER
GETDATE
ORA_SYSDATE
SESSION_USER
SYSTEM_USER
TIMESTAMPADD
TIMESTAMPDIFF
TT_HASH
TT_SYSDATE
TimesTen and the Oracle Database interpret the literal N'\UNNNN' differently. In TimesTen,
N'\unnnn' (where nnnn is a number) is interpreted as the national character set character
with the code nnnn. In the Oracle Database, N'\unnnn' is interpreted as 6 literal characters.
The \u is not treated as an escape. This difference causes unexpected behavior. For
example, loading a cache group with a WHERE clause that contains a literal can fail. This can
also affects dynamic loading. Applications should use the UNISTR SQL function instead of
literals.
SQL Expressions
TimesTen supports a subset of expressions that are supported by the Oracle Database.
Column Reference
Sequence
NULL
()
Binding parameters
CASE expression
ROWID pseudocolumn
ROWNUM pseudocolumn
TimesTen and Oracle Database treat literals differently. See the description of
HexadecimalLiteral in Constants in Oracle TimesTen In-Memory Database SQL Reference.
C-11
Appendix C
SQL Compatibility
INSERT/DELETE/UPDATE/MERGE Statements
TimesTen supports certain DML statements that are also supported by the Oracle
Database.
• INSERT INTO ... VALUES
• INSERT INTO ... SELECT
• UPDATE WHERE expression (expression may contain a subquery)
• DELETE WHERE expression (expression may contain a subquery)
TimesTen does not support updating of primary key values except when the new value
is the same as the old value.
TimesTen-Only SQL and Built-In Procedures

There are TimesTen SQL statements and functions and built-in procedures that are not
supported by the Oracle Database.
With PassThrough=3, these statements are passed to Oracle Database for processing
and an error is generated.
• All TimesTen cache group DDL and DML statements, including CREATE CACHE
GROUP, DROP CACHE GROUP, ALTER CACHE GROUP, LOAD CACHE GROUP, UNLOAD CACHE
GROUP, REFRESH CACHE GROUP and FLUSH CACHE GROUP.
• All TimesTen replication management DDL statements, including CREATE
REPLICATION, DROP REPLICATION, ALTER REPLICATION, CREATE ACTIVE STANDBY
PAIR, ALTER ACTIVE STANDBY PAIR and DROP ACTIVE STANDBY PAIR.
• FIRST n clause.
• ROWS m TO n clause.
• All TimesTen built-in procedures. See Built-In Procedures in Oracle TimesTen In-
• TimesTen specific syntax for character and unicode strings are not always
converted to the Oracle Database syntax when using PassThrough=3.
Note:
For more details on TimesTen support for unicode strings, see Character
and Unicode Strings in the Oracle TimesTen In-Memory Database
Reference.
– Supplying \046 converts to the & symbol on TimesTen, but is not converted to
this symbol when passed through to an Oracle database. The \xyz notation is
not supported by the Oracle database. To send a character through to an
Oracle database, pass it as an argument within the CHR() function with the
decimal value of the character.
C-12
Appendix C
Mappings Between Oracle Database and TimesTen Data Types
– TimesTen enables depicting a unicode value (a four-digit hexadecimal number) within

a character string with the \uxyzw syntax (for NCHAR and NVARCHAR2 only) where you
substitute the unicode value for xyzw, as in\ufe4a.
The \uxyzw notation is not supported by the Oracle database. Thus, any unicode
strings in NCHAR or NVARCHAR2 columns passed through to an Oracle database must
be passed as an argument within the UNISTR() function without the u character.
The following example inserts the unicode values '0063' and '0064', which are the a
and b characters respectively. Since we are using PassThrough=3, this statement is
performed on the Oracle database; thus, we do not provide the u character as we
would if this was performed on TimesTen.
Command> INSERT INTO my_tab VALUES (UNISTR(n'\0063\0064'));
1 row inserted.
PL/SQL Constructs
TimesTen supports a subset of stored procedure constructs, functions, data types, packages
and package bodies that are supported by Oracle Database.
See Overview of PL/SQL Features in the Oracle TimesTen In-Memory Database PL/SQL
Developer's Guide.

When you choose data types for columns in the TimesTen cache tables, consider the data
types of the columns in the Oracle Database tables and choose an equivalent or compatible
data type for the columns in the cache tables.
Note:
TimeTen cache, including passthrough, does not support the Oracle Database
ROWID data type. However, you can cast a ROWID data type to a CHAR(18) when
provided on the SELECT list in a SQL query.
The following example demonstrates the error that is returned when you do not cast
the ROWID data type. Then, the example shows the correct casting of a ROWID data
type to CHAR(18):
Command> SET PASSTHROUGH 3;
Passthrough command has set autocommit off.
Command> SELECT ROWID FROM dual;
5115: Unsupported type mapping for column ROWID
The command failed.
Command> SELECT CAST (ROWID AS CHAR(18)) FROM DUAL;
< AAAAB0AABAAAAEoAAA >
1 row found.
Primary and foreign key columns are distinguished from non-key columns. The data type
mappings allowed for key columns in a cache table are shown in Table C-2.
C-13
Appendix C
Table C-2 Data Type Mappings Allowed for Key Columns
Oracle Database Data Type TimesTen Data Type

NUMBER(p,s) NUMBER(p,s)
Note: DECIMAL(p,s) or NUMERIC(p,s) can also be used.
They are aliases for NUMBER(p,s).
NUMBER(p,0) TT_TINYINT
INTEGER TT_SMALLINT
TT_INTEGER
TT_BIGINT
NUMBER(p,0)
NUMBER TT_TINYINT
TT_SMALLINT
TT_INTEGER
TT_BIGINT
NUMBER
CHAR(n) CHAR(n)
VARCHAR2(n) VARCHAR2(n)
RAW(n) VARBINARY(n)
DATE DATE
TIMESTAMP(n) TIMESTAMP(n)
NCHAR(n) NCHAR(n)
NVARCHAR2(n) NVARCHAR2(n)
Table C-3 shows the data type mappings allowed for non-key columns in a cache
table.
Table C-3 Data Type Mappings Allowed for Non-Key Columns

NUMBER(p,s) NUMBER(p,s)
REAL
FLOAT
BINARY_FLOAT
DOUBLE
BINARY_DOUBLE
C-14
Appendix C
Table C-3 (Cont.) Data Type Mappings Allowed for Non-Key Columns

NUMBER(p,0) TT_TINYINT
INTEGER TT_SMALLINT
TT_INTEGER
TT_BIGINT
NUMBER(p,0)
FLOAT
BINARY_FLOAT
DOUBLE
BINARY_DOUBLE
NUMBER TT_TINYINT
TT_SMALLINT
TT_INTEGER
TT_BIGINT
NUMBER
REAL
FLOAT
BINARY_FLOAT
DOUBLE
BINARY_DOUBLE
CHAR(n) CHAR(n)
VARCHAR2(n) VARCHAR2(n)
RAW(n) VARBINARY(n)
LONG VARCHAR2(n)
Where n can be any valid value within the
range defined for the VARCHAR2 data type.
LONG RAW VARBINARY(n)
Where n can be any valid value within the
range defined for the VARBINARY data type.
DATE DATE
TIMESTAMP(0)
TIMESTAMP(n) TIMESTAMP(n)
FLOAT(n) FLOAT(n)
Note: Includes DOUBLE and FLOAT, which are BINARY_DOUBLE
equivalent to FLOAT(126). Also includes Note: FLOAT(126) can be declared as
REAL, which is equivalent to FLOAT(63). DOUBLE. FLOAT(63) can be declared as
REAL.
BINARY_FLOAT BINARY_FLOAT
BINARY_DOUBLE BINARY_DOUBLE
NCHAR(n) NCHAR(n)
C-15
Appendix C
Table C-3 (Cont.) Data Type Mappings Allowed for Non-Key Columns

NVARCHAR2(n) NVARCHAR2(n)
CLOB VARCHAR2(n)
Where 1 <= n <= 4 MB.
BLOB VARBINARY(n)
Where 1 <= n <= 4 MB.
NCLOB NVARCHAR2(n)
Where 1 <= n <= 2 MB.
C-16

Cache Guide

Uploaded by

Copyright:

Available Formats

Cache Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cache Guide

Uploaded by

Copyright:

Available Formats

Oracle® TimesTen In-Memory

Copyright © 2012, 2023, Oracle and/or its affiliates.

3 Setting Up a Caching Infrastructure

4 Defining Cache Groups

5 Methods for Transmitting Changes Between TimesTen and Oracle

6 Managing a Caching Environment

8 Cleaning Up the Caching Environment

9 Using Cache in an Oracle RAC Environment

10 Using Cache With Data Guard

11 Using GoldenGate as an Alternative to Native Read-Only Cache Groups

A Procedure and Privileges for Caching Oracle Database Data in

B SQL*Plus Scripts for Cache

C Compatibility Between TimesTen and Oracle Databases

Access to Oracle Support

New features in Release 22.1.1.1.0

Overview of Cache Groups

Figure 1-1 Single Table Cache Group

Figure 1-2 Multiple-Table Cache Group

122 West Jim Johnston 231 Main, Needles, CA 92363

342 West Jane Stone 43 Cope, Palo Alto, CA 94302

663 Midwest Mary J. Warren 673 State, Madison, WI 53787

ord_num prod_num quantity

Cache Group Types

The most commonly used types of cache groups are:

Transmitting Changes Between the TimesTen and Oracle

• Automatically refresh cache groups: Autorefresh operations automatically replace cache

in a read-only or a user managed cache group to automatically refresh committed

Using Oracle GoldenGate as an Alternative Cache Refresh

High Availability Caching Solution

Setting Up the Oracle Database and TimesTen Classic Systems

Set Up Users in the Oracle Database

SQL> CREATE TABLESPACE cachetblsp DATAFILE 'tt_cache.f' SIZE 5G

3. Use SQL*Plus to perform the following operations:

In the following example, the cache administration user name is cacheadmin:

SQL> CREATE USER cacheadmin IDENTIFIED BY orapwd

Create a DSN for the TimesTen Database

3. Restart the main daemon to capture this setting.

Create Users in the TimesTen Database

TimesTen database Oracle database

Set the Cache Administration User Name and Password in the

Creating Cache Groups

Figure 2-1 Single-Table Read-Only Cache Group

TimesTen Oracle Database

Figure 2-2 Single-Table WriteThrough Cache Group

TimesTen Oracle Database

Identify the Oracle Database Tables To Be Cached

Figure 2-3 Creating an Oracle Database Table to Be Cached in a Read-Only

CREATE TABLE readtab .....

Figure 2-4 Creating an Oracle Database Table to Be Cached in an AWT Cache

CREATE TABLE writetab .....

SQL> INSERT INTO writetab VALUES (100, 'TimesTen');

SQL> GRANT SELECT ON writetab TO cacheadmin;

Start the Cache Agent

See Managing the Cache Agent.

Create the Cache Groups

Command> CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP writecache

Figure 2-5 Creating an Asynchronous WriteThrough Cache Group

Cache Group CACHEADMIN.READCACHE:

Cache Group Type: Read Only