Contents

Title and Copyright Information

Preface

• Audience
• Related documents
• Conventions
• Documentation Accessibility
• Technical support

What's New

• New features in Release 11.2.1.4.0
• New features in Release 11.2.1.1.0

1 Overview of TimesTen Replication

• What is replication?
• Requirements for replication compatibility
• Replication agents
• Copying updates between data stores
  • Default replication
  • Return receipt replication
  • Return twosafe replication
• Types of replication schemes
  • Active standby pair with read-only subscribers
  • Full data store replication or selective replication
  • Unidirectional or bidirectional replication
    • Split workload configuration
    • Distributed workload
  • Direct replication or propagation
• Cache groups and replication
  • Replicating an AWT cache group
  • Replicating an AWT cache group with a read-only 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 data stores
  • Step 2: Create a table in one of the master data stores
  • Step 3: Define the active standby pair
  • Step 4: Start the replication agent on a master data store
  • Step 5: Set the state of a master data store to 'ACTIVE'
  • Step 6. Create a user on the active data store
  • Step 7: Duplicate the active data store to the standby data store
  • Step 8: Start the replication agent on the standby data store
  • Step 9. Duplicate the standby data store to the subscriber
  • Step 10: Start the replication agent on the subscriber
  • Step 11: Insert data into the table on the active data store
  • 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 data store
  • Step 3: Create a table and replication scheme on the subscriber data store
  • Step 4: Start the replication agent on each data store
  • Step 4: Insert data into the table on the master data store
  • Step 5: Drop the replication scheme and table

3 Defining an Active Standby Pair Replication Scheme

• Restrictions on active standby pairs
• Defining the DSNs for the data stores
• Defining an active standby pair replication scheme
• Identifying the data stores in the active standby pair
• Using a return service
  • 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
    • Disabling return service blocking manually
    • Establishing return service failure/recovery policies
  • Compressing replicated traffic
  • Port assignments
  • Setting the log failure threshold
• Configuring network operations
• Including or excluding data store objects from replication

4 Administering an Active Standby Pair Without Cache Groups

• Overview of master data store states
• Duplicating a data store
• Setting up an active standby pair with no cache groups
• Recovering from a failure of the active data store
  • Recovering when the standby data store is ready
    • When replication is return receipt or asynchronous
    • When replication is return twosafe
  • Recovering when the standby data store is not ready
    • Recover the active data store
    • Recover the standby data store
  • Failing back to the original nodes
• Recovering from a failure of the standby data store
• Recovering from the failure of a subscriber data store
• Reversing the roles of the active and standby data stores
• Detection of dual active data stores
• Changing the configuration of an active standby pair

5 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
• Recovering from a failure of the active data store
  • Recovering when the standby data store is ready
    • When replication is return receipt or asynchronous
    • When replication is return twosafe
  • Recovering when the standby data store is not ready
    • Recover the active data store
    • Recover the standby data store
  • Failing back to the original nodes
• Recovering from a failure of the standby data store
• Recovering from the failure of a subscriber data store
• Reversing the roles of the active and standby data stores
• Detection of dual active data stores
• Changing the configuration of an active standby pair with cache groups
• 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 data store
  • Returning to the original configuration at the primary site

6 Using Oracle Clusterware to Manage Active Standby Pairs

• Overview
  • Active standby configurations
  • Required privileges
  • Hardware and software requirements
  • Restricted commands and SQL statements
• The cluster.oracle.ini file
  • Configuring basic availability
  • Configuring advanced availability
  • Including cache groups in the active standby pair
  • Implementing application failover
  • Recovering from failure of both master nodes
  • Using the RepDDL attribute
• Creating and initializing a cluster
  • Install Oracle Clusterware
  • Install TimesTen on each host
  • Start the TimesTen cluster agent
  • Create and populate a TimesTen data store on one host
  • Create a cluster.oracle.ini file
  • Create the virtual IP addresses (optional)
  • Create an active standby pair replication scheme
  • Start the active standby pair
  • Including more than one active standby pair in a cluster
• Recovering from failures
  • When an active data store or its host fails
  • When a standby data store or its host fails
  • When read-only subscribers or their hosts fail
  • When failures occur on both master nodes
    • Automatic recovery
    • Manual recovery for advanced availability
    • Manual recovery for basic availability
  • When more than two master hosts fail
• Planned maintenance
  • Changing the schema
  • Performing a rolling upgrade of Oracle Clusterware software
  • Upgrading TimesTen
  • Adding a read-only subscriber to an active standby pair
  • Removing a read-only subscriber from an active standby pair
  • Adding an active standby pair to a cluster
  • Removing an active standby pair from a cluster
  • Adding a host to the cluster
  • Removing a host from the cluster
  • Reversing the roles of the master data stores
  • Moving a data store to a different host
  • Performing host or network maintenance
  • Performing maintenance on the entire cluster
  • Changing user names or passwords

7 TimesTen Attributes for Oracle Clusterware

• List of attributes
• Required attributes
  • MasterHosts
  • ScriptInstallDir
• Conditionally required attributes
  • AppCheckCmd
  • AppName
  • AppStartCmd
  • AppStopCmd
  • AppType
  • CacheConnect
  • MasterVIP
  • RemoteSubscriberHosts
  • RepBackupDir
  • SubscriberHosts
  • SubscriberVIP
  • VIPInterface
  • VIPNetMask
• Optional attributes
  • AppFailoverDelay
  • AppFailureThreshold
  • AppScriptTimeout
  • AutoRecover
  • ClusterType
  • DatabaseFailoverDelay
  • FailureThreshold
  • MasterStoreAttribute
  • MonInterval
  • RepBackupPeriod
  • RepDDL
  • RepfullbackupCycle
  • ReturnServiceAttribute
  • SubscriberStoreAttribute
  • TimesTenScriptTimeout

8 Defining Replication Schemes

• Designing a highly available system
  • Considering failover and recovery scenarios
  • Making decisions about performance and recovery tradeoffs
  • Distributing workloads
• Defining a replication scheme
  • Owner of the replication scheme and tables
  • Data store names
• Defining replication elements
  • Defining data store elements
  • Defining table elements
  • Replicating tables with foreign key relationships
  • Replicating materialized views
  • Replicating sequences
• Checking for replication conflicts on table elements
• Setting transmit durability on data store elements
• Using a return service
  • RETURN RECEIPT
  • RETURN RECEIPT BY REQUEST
  • RETURN TWOSAFE BY REQUEST
  • RETURN TWOSAFE
  • NO RETURN
• Setting STORE attributes
  • Setting the return service timeout period
  • Managing return service timeout errors and replication state changes
    • When to manually disable return service blocking
    • Establishing return service failure/recovery policies
  • Compressing replicated traffic
  • Port assignments
  • Setting the log failure threshold
  • Replicating tables with different definitions
• Configuring network operations
• Replication scheme syntax examples
  • Single subscriber schemes
  • Multiple subscriber schemes with return services and a failure threshold
  • Replicating tables to different subscribers
  • Propagation scheme
  • Bidirectional split workload schemes
  • Bidirectional distributed workload scheme
• Creating replication schemes with scripts

9 Setting Up a Replicated System

• Configuring the network
  • Network bandwidth requirements
  • Replication in a WAN environment
  • Configuring host IP addresses
    • Identifying data store hosts and network interfaces using the ROUTE clause
    • Identifying data store 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 data store
• Setting up the replication environment
  • Establishing the data stores
    • Data store attributes
    • Table requirements and restrictions
    • Copying a master data store to a subscriber
  • Managing the transaction log on a replicated data store
    • About log buffer size and persistence
    • About transaction log growth on a master data store
    • Setting attributes for logging
  • Configuring a large number of subscribers
  • Increasing replication throughput for active standby pairs
• Replicating data stores across releases
• Applying a replication scheme to a data store
• Starting and stopping the replication agents
  • Controlling replication agents from the command line
  • Controlling replication agents from a program
• Setting the replication state of subscribers

10 Managing Data Store Failover and Recovery

• Overview of data store failover and recovery
• General failover and recovery procedures
  • Subscriber failures
  • Master failures
  • Automatic catch-up of a failed master data store
  • Failures in bidirectional distributed workload schemes
  • Network failures
  • Failures involving sequences
• Recovering a failed data store
  • Recovering a failed data store from the command line
  • Recovering a failed data store from a C program
• Recovering nondurable data stores
• Writing a failure recovery script

11 Monitoring Replication

• Show state of replication agents
  • From the command line: ttStatus
  • From the command line: ttAdmin -query
  • From a program: ttDataStoreStatus
• Show master data store information
  • From the command line: ttRepAdmin -self -list
  • From a program: SQL SELECT statement
• Show subscriber data store information
  • Using ttRepAdmin to display subscriber status
  • Using ttReplicationStatus to display subscriber status
  • Using SQL to display information about subscribers
  • Verifying that a subscriber has received and applied all updates
• Show the configuration of replicated data stores
  • From ttIsql: repschemes command
  • From the command line: ttRepAdmin -showconfig
  • From a program: SQL SELECT statements
• Show replicated log records
  • From the command line: ttRepAdmin -bookmark
  • From a program: ttBookMark procedure
• Show replication status
  • MAIN thread status fields
  • Replication peer status fields
  • TRANSMITTER thread status fields
  • RECEIVER thread status fields
• Checking the status of return service transactions

12 Altering Replication

• Altering a replication scheme
  • Adding a table or sequence to an existing replication scheme
  • Adding a DATASTORE element to an existing 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 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 data store
  • Dropping a subscriber data store
  • Changing a TABLE or SEQUENCE element name
  • Replacing a master data store
  • Eliminating conflict detection
  • Eliminating the return receipt service
  • Changing the port number
  • Changing the replication route
  • Changing the log failure threshold
• Altering a replicated table
• Truncating a replicated table
• Dropping a replication scheme

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

Index