Go to main content
1/21
Contents
Title and Copyright Information
Preface
Audience
Related documents
Conventions
Documentation Accessibility
What's New
New features in Release 11.2.2.8.0
New features in Release 11.2.2.7.0
New features in Release 11.2.2.5.0
New features in Release 11.2.2.4.0
New features in Release 11.2.2.2.0
New features in Release 11.2.2.1.0
New features in Release 11.2.2.0.0
1
Overview of TimesTen Replication
What is replication?
Requirements for replication compatibility
Replication agents
Copying updates between databases
Default replication
Return receipt replication
Return twosafe replication
Types of replication schemes
Active standby pair with read-only subscribers
Classic replication
Full database replication or selective replication
Unidirectional or bidirectional replication
Direct replication or propagation
Cache groups and replication
Replicating an AWT cache group
Replicating an AWT cache group with a subscriber propagating to an Oracle database
Replicating a read-only cache group
Sequences and replication
Foreign keys and replication
Aging and replication
2
Getting Started
Configuring an active standby pair with one subscriber
Step 1: Create the DSNs for the master and the subscriber databases
Step 2: Create a table in one of the master databases
Step 3: Define the active standby pair
Step 4: Start the replication agent on a master database
Step 5: Set the state of a master database to 'ACTIVE'
Step 6. Create a user on the active database
Step 7: Duplicate the active database to the standby database
Step 8: Start the replication agent on the standby database
Step 9. Duplicate the standby database to the subscriber
Step 10: Start the replication agent on the subscriber
Step 11: Insert data into the table on the active database
Step 12: Drop the active standby pair and the table
Configuring a replication scheme with one master and one subscriber
Step 1: Create the DSNs for the master and the subscriber
Step 2: Create a table and replication scheme on the master database
Step 3: Create a table and replication scheme on the subscriber database
Step 4: Start the replication agent on each database
Step 5: Insert data into the table on the master database
Step 6: Drop the replication scheme and table
3
Defining an Active Standby Pair Replication Scheme
Overview of master database states
Duplicating a database
Restrictions on active standby pairs
Defining the DSNs for the databases
Table requirements for active standby pairs
Defining an active standby pair replication scheme
Identifying the databases in the active standby pair
Using a return service for an active standby pair
Setting STORE attributes for an active standby pair
Configuring network operations for an active standby pair
Using automatic client failover for an active standby pair
Including or excluding database objects from replication
Replicating tables with foreign key relationships in an active standby pair
Materialized views in an active standby pair
Replicating sequences in an active standby pair
4
Defining Attributes and Options for a Replication Scheme
Using a return service
Specifying a different return service for each subscriber in a classic replication scheme
RETURN RECEIPT
RETURN RECEIPT BY REQUEST
RETURN TWOSAFE
RETURN TWOSAFE BY REQUEST
NO RETURN
Setting STORE attributes
Setting the return service timeout period
Managing return service timeout errors and replication state changes
Column definition options for replicated tables
Examples for an active standby pair replicating tables with table definition checking set to relaxed
Examples for classic replication scheme with table definition checking set to relaxed
Compressing replicated traffic
Port assignments
Setting wait timeout for response from remote replication agents
Setting the transaction log failure threshold
Suspending or resuming classic replication in response to conflicts
Configuring the network
Network bandwidth requirements
Replication in a WAN environment
Configuring network interfaces with the ROUTE clause
Configuring network interfaces when not using the ROUTE clause
Identifying database hosts on UNIX without using the ROUTE clause
Host name resolution on Windows
User-specified addresses for TimesTen daemons and subdaemons
Identifying the local host of a replicated database
5
Administering an Active Standby Pair without Cache Groups
Setting up an active standby pair with no cache groups
Recovering from a failure of the active database
Recovering when the standby database is ready
When replication is return receipt or asynchronous
When replication is return twosafe
Failing back to the original nodes
Recovering from a failure of the standby database
Recovering after a dual failure of both active and standby databases
Recover the active database
Recover the standby database
Recovering from the failure of a subscriber database
Reversing the roles of the active and standby databases
Detection of dual active databases
6
Administering an Active Standby Pair with Cache Groups
Active standby pairs with cache groups
Setting up an active standby pair with a read-only cache group
Setting up an active standby pair with an AWT cache group
Changing user names or passwords used by replication
Recovering from a failure of the active database
Recovering when the standby database is ready
When replication is return receipt or asynchronous
When replication is return twosafe
When there is unsynchronized data in the cache groups
Failing back to the original nodes
Recovering from a failure of the standby database
Recovering after a dual failure of both active and standby databases
Recover the active database and duplicate a new standby database
Recover the standby database to be the new active master
Restore the active master from a backup
Recovering from the failure of a subscriber database
Reversing the roles of the active and standby databases
Detecting dual active databases
Using a disaster recovery subscriber in an active standby pair
Requirements for using a disaster recovery subscriber with an active standby pair
Rolling out a disaster recovery subscriber
Switching over to the disaster recovery site
Creating a new active standby pair after switching to the disaster recovery site
Switching over to a single database
Returning to the original configuration at the primary site
7
Altering an Active Standby Pair
Making DDL changes in an active standby pair
Controlling replication of objects to all databases in an active standby pair
DDL statements that can be automatically replicated
Creating a new PL/SQL object in an existing active standby pair
Restrictions on making DDL changes in an active standby pair
Examples: Making DDL changes in an active standby pair
Making other changes to an active standby pair
Examples: Altering an active standby pair
8
Using Oracle Clusterware to Manage Active Standby Pairs
Overview of how Oracle Clusterware can manage TimesTen
Required privileges
Hardware and software requirements
Restricted commands and SQL statements
Configuring Oracle Clusterware management with the cluster.oracle.ini file
Configuring basic availability
Configuring advanced availability
Including cache groups in the active standby pair
Including the active standby pair in a cache grid
Implementing application failover
Recovering from permanent failure of both master nodes
Using the RepDDL attribute
Creating and initializing a cluster
Install Oracle Clusterware
Install TimesTen on each host
Register the TimesTen cluster information
Start the TimesTen cluster agent
Create and populate a TimesTen database on one host
Create system DSN files on other hosts
Create a cluster.oracle.ini file
Create the Oracle Clusterware resources to manage virtual IP addresses
Create an active standby pair replication scheme
Start the active standby pair and the applications
Load cache groups
Include more than one active standby pair in a cluster
Configure an Oracle database as a disaster recovery subscriber
Configure a read-only subscriber that is not managed by Oracle Clusterware
Using Oracle Clusterware with a TimesTen cache grid
Creating and initializing a cluster of cache grid members
Failure and recovery for active standby pair grid members
Making schema changes to active standby pairs in a grid
Add a cache group
Drop a cache group
Change an existing cache group
Recovering from failures
How TimesTen performs recovery when Oracle Clusterware is configured
When an active database or its host fails
When a standby database or its host fails
When read-only subscribers or their hosts fail
When failures occur on both master nodes
Automatic recovery when not attached to a grid
Manual recovery of both nodes of an active standby pair grid member
Manual recovery for advanced availability
Manual recovery for basic availability
Manual recovery to the same master nodes when databases are corrupt
Manual recovery when RETURN TWOSAFE is configured
When more than two master hosts fail
Perform a forced switchover after failure of the active database or host
Clusterware management
Performing a rolling upgrade of Oracle Clusterware software
Upgrading TimesTen
Managing hosts in the cluster
Adding a host to the cluster
Removing a host from the cluster
Managing active standby pairs in a cluster
Adding an active standby pair to a cluster
Removing an active standby pair from a cluster
Managing read-only subscribers in the active standby pair
Adding a read-only subscriber managed by Oracle Clusterware
Removing a read-only subscriber managed by Oracle Clusterware
Adding or dropping a read-only subscriber not managed by Oracle Clusterware
Rebuilding a read-only subscriber not managed by Oracle Clusterware
Changing the schema
Facilitating schema change for Oracle Clusterware
Managing subscribers and database attributes
Reversing the roles of the master databases
Moving a database to a different host
Performing host or network maintenance
Performing maintenance on the entire cluster
Changing user names or passwords when using Oracle Clusterware
Managing the TimesTen database RAM policy
Monitoring cluster status
Obtaining cluster status
Message log files
9
Defining Classic Replication Schemes
Designing a highly available system
Considering failover and recovery scenarios
Making decisions about performance and recovery tradeoffs
Distributing workloads
Defining a classic replication scheme
Owner of the replication scheme and replicated objects
Database names
Table requirements and restrictions for classic replication schemes
Restrictions for classic replication schemes involving multiple masters
Defining replication elements
Defining the DATASTORE element
Defining table elements
Replicating tables with foreign key relationships in a classic replication scheme
Replicating sequences
Views and materialized views in a replicated database
Checking for replication conflicts on table elements
Setting transmit durability on DATASTORE element
Using a return service in a classic replication scheme
Setting STORE attributes in a classic replication scheme
Configuring network operations for a classic replication scheme
Classic replication scheme syntax examples
Single classic subscriber schemes
Multiple subscriber classic replication schemes with return services and a log failure threshold
Replicating tables to different subscribers
Propagation scheme
Bidirectional split workload schemes
Bidirectional distributed workload scheme
Applying a classic replication scheme to a database
Creating classic replication schemes with scripts
10
Altering a Classic Replication Scheme
Altering a classic replication scheme
Adding a table or sequence to an existing classic replication scheme
Adding a PL/SQL object to an existing classic replication scheme
Adding a DATASTORE element to an existing classic replication scheme
Including tables or sequences when you add a DATASTORE element
Excluding a table or sequence when you add a DATASTORE element
Dropping a table or sequence from a classic replication scheme
Dropping a table or sequence that is replicated as part of a DATASTORE element
Dropping a table or sequence that is replicated as a TABLE or SEQUENCE element
Creating and adding a subscriber database to a classic replication scheme
Dropping a subscriber database from a classic replication scheme
Changing a TABLE or SEQUENCE element name in a classic replication scheme
Replacing a master database in a classic replication scheme
Eliminating conflict detection in a classic replication scheme
Eliminating the return receipt service in a classic replication scheme
Changing the port number for a classic replication scheme
Changing the replication route
Changing the log failure threshold
Altering a replicated table in a classic replication scheme
Truncating a replicated table in a classic replication scheme
Dropping a classic replication scheme
11
Setting Up a Replicated System
Setting up the replication environment
Establishing the databases
Connection attributes for replicated databases
Configuring parallel replication
Configuring automatic parallel replication
Configuring automatic parallel replication with disabled commit dependencies
Configuring user-defined parallel replication for classic replication schemes
Managing the transaction log on a replicated database
About log buffer flushing
About transaction log growth on a master database
Setting connection attributes for logging
Duplicating a master database to a subscriber
Configuring a large number of subscribers
Replicating databases across releases
Starting and stopping the replication agents
Setting the replication state of subscribers
12
Monitoring Replication
Show state of replication agents
Using ttStatus to obtain replication agent status
Using ttAdmin -query to confirm policy settings
Using ttDataStoreStatus to obtain replication agent status
Show master database information
Using ttRepAdmin to display information about the master database
Querying replication tables to obtain information about a master database
Show subscriber database information
Display subscriber status with the ttRepAdmin utility
Display subscriber status with the ttReplicationStatus built-in procedure
Display information about subscribers through querying replication tables
Subscriber information
Show the configuration of replicated databases
Display configuration information with the ttIsql repschemes command
Display configuration information with the ttRepAdmin utility
Display configuration information through querying replication tables
Show replicated log records
Monitor replication with the TTREP.REPPEERS table
Monitor replication with the ttLogHolds built-in procedure
Monitor replication with the ttRepAdmin utility
Monitor replication with the ttBookMark built-in procedure
Use ttRepAdmin to show replication status
MAIN thread status fields
Replication peer status fields
TRANSMITTER thread status fields
RECEIVER thread status fields
Check the status of return service transactions
Determine if return service is disabled
Check last returned status for a return service
Analyze outstanding transactions in the replication log
13
Resolving Replication Conflicts
How replication conflicts occur
Update and insert conflicts
Delete/update conflicts
Using a timestamp to resolve conflicts
Timestamp comparisons for local updates
Configuring timestamp comparison
Including a timestamp column in replicated tables
Configuring the CHECK CONFLICTS clause
Enabling system timestamp column maintenance
Enabling user timestamp column maintenance
Reporting conflicts
Reporting conflicts to a text file
Reporting conflicts to an XML file
Reporting uniqueness conflicts
Reporting update conflicts
Reporting delete/update conflicts
Suspending and resuming the reporting of conflicts
The conflict report XML Document Type Definition
The main body of the document
The uniqueness conflict element
The update conflict element
The delete/update conflict element
14
Improving Replication Performance
Adjust transaction log buffer size and CPU
Performance considerations when altering tables that are replicated
Increase replication throughput for active standby pairs
Limit replication transmitters, receivers, and XLA readers
15
Managing Database Failover and Recovery
Overview of database failover and recovery
General failover and recovery procedures
Subscriber failures
Master failures
Automatic catch-up of a failed master database
When master catch-up is required for an active standby pair
Failures in bidirectional distributed workload schemes
Network failures
Failures involving sequences
Recovering a failed database
Recovering a failed database from the command line
Recovering a failed database from a C program
Recovering nondurable databases
Writing a failure recovery script
A
TimesTen Configuration Attributes for Oracle Clusterware
List of attributes
Required attributes
MasterHosts
Conditionally required attributes
AppCheckCmd
AppFailureInterval
AppName
AppRestartAttempts
AppStartCmd
AppStopCmd
AppType
AppUptimeThreshold
CacheConnect
GridPort
MasterVIP
RemoteSubscriberHosts
RepBackupDir
SubscriberHosts
SubscriberVIP
VIPInterface
VIPNetMask
Optional attributes
AppFailoverDelay
AppFailureThreshold
AppScriptTimeout
AutoRecover
DatabaseFailoverDelay
FailureThreshold
MasterStoreAttribute
RepBackupPeriod
RepDDL
RepFullBackupCycle
ReturnServiceAttribute
SubscriberStoreAttribute
TimesTenScriptTimeout
Index
Scripting on this page enhances content navigation, but does not change the content in any way.