Show Replicated Log Records
You can monitor replication through bookmarks and the log sequence numbers with certain tools.
In a replicated database, transactions remain in the transaction log buffer and transaction log files until the master replication agent confirms they have been fully processed by the subscriber. In an active standby pair replication scheme that contains subscribers, transactions remain in the transaction logs until the active master confirms that they are processed by both the standby master and any subscribers. Only then can the active master consider purging them from the log buffer and transaction log files. When the log space is exhausted, subsequent updates on the master database are aborted.
Note:
For more information about transaction log growth, see Monitoring Accumulation of Transaction Log Files in Oracle TimesTen In-Memory Database Operations Guide.
Transactions are stored in the log in the form of log records. You can use bookmarks to detect which log records have or have not been replicated by a master database. A bookmark consists of log sequence numbers (LSNs) that identify the location of particular records in the transaction log that you can use to gauge replication performance. The LSNs associated with a bookmark are: hold LSN, last written LSN, and last LSN forced to disk. The hold LSN describes the location of the lowest (or oldest) record held in the log for possible transmission to a subscriber. You can compare the hold LSN with the last written LSN to determine the amount of data in the transaction log that have not yet been transmitted to the subscribers. The last LSN forced to disk describes the last records saved in a transaction log file.
You can monitor replication through bookmarks and the log sequence numbers with the following tools:
Monitor Replication With the TTREP.REPPEERS Table
An accurate way to monitor replication to a particular subscriber is to look at the
send LSN for the subscriber, which consists of the SENDLSNHIGH and
SENDLSNLOW fields in the TTREP.REPPEERS table.
In contrast to the send LSN value, the hold LSN returned in a bookmark is computed every 10 seconds to describe the minimum send LSN for all the subscribers, so it provides a more general view of replication progress that does not account for the progress of replication to the individual subscribers. Because replication acknowledgements are asynchronous for better performance, the send LSN can also be some distance behind. Nonetheless, the send LSN for a subscriber is the most accurate value available and is always ahead of the hold LSN.
Monitor Replication From the Replication Log Holds
Select from the SYS.GV$LOG_HOLDS or SYS.V$LOG_HOLDS
system views or call the ttLogHolds built-in procedure to get information
about replication log holds.
The following example shows the output of ttLogHolds built-in procedure for an active standby pair replication scheme, where the active master is master1 and the standby master is master2, with a single subscriber, subscriber1. All transactions are replicated from the active master first to the standby master who then propagates the transactions to the subscriber. Thus, the subscriber's progress is slightly behind the standby master's progress.
The active master monitors the progress of both the standby master and the subscriber; therefore, if the standby master goes down for any reason, the active master can take over the replication to the subscriber. The active master receives acknowledgements when transactions are applied on the subscriber so the active master knows when it can release pertinent log records that might be needed if the standby master fails (upon which the active master switches to replicate directly to the subscribers). The transactions remain in the transaction logs until they are processed on both the standby master and the subscriber.
Command> call ttLogHolds; < 0, 3569664, Checkpoint , master1.ds0 > < 0, 15742976, Checkpoint , master1.ds1 > < 0, 16351496, Replication , ADC6160529:SUBSCRIBER1 > < 0, 16351640, Replication , ADC6160529:MASTER2 > 4 rows found.
If you are using an AWT cache group, it uses the replication agent to asynchronously propagate transactions to the Oracle database. 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 , cachealone1.ds0 > < 0, 19048448, Checkpoint , cachealone1.ds1 > < 0, 19050904, Replication , ADC6160529:_ORACLE > 3 rows found.
See SYS.GV$LOG_HOLDS or SYS.V$LOG_HOLDS in the Oracle TimesTen In-Memory Database System Tables and Views Reference or ttLogHolds in the Oracle TimesTen In-Memory Database Reference.
Monitor Replication With the ttRepAdmin Utility
Use the ttRepAdmin utility with the -bookmark
option to display the location of bookmarks.
> ttRepAdmin -dsn masterds -bookmark Replication hold LSN ...... 10/927692 Last written LSN .......... 10/928908 Last LSN forced to disk ... 10/280540 Each LSN is defined by two values: Log file number / Offset in log file
The LSNs output from ttRepAdmin -bookmark are:
| Line | Description |
|---|---|
|
|
The location of the lowest (or oldest) record held in the log for possible transmission to a subscriber. A value of -1/-1 indicates replication is in the If you are monitoring an active standby pair with one or more subscribers, then this value denotes the oldest record held for all nodes involved in the replication scheme. For example, in an active standby pair with subscribers, the oldest record could be held in the log for the standby master or any of the subscribers. |
|
|
The location of the most recently generated transaction log record for the database. |
|
|
The location of the most recent transaction log record written to the disk. |
Monitor Replication With the ttBookMark Built-In Procedure
Use the ttBookmark built-in procedure to display the location of
bookmarks.
> ttIsql masterds Command> call ttBookMark(); < 10, 928908, 10, 280540, 10, 927692 > 1 row found.
The first two columns in the returned row define the "Last written LSN," the next two columns define the "Last LSN forced to disk," and the last two columns define the "Replication hold LSN."
If you are monitoring an active standby pair with one or more subscribers, then the "Replication hold LSN" denotes the oldest record held for all nodes involved in the replication scheme. For example, in an active standby pair with subscribers, the oldest record could be held in the log for the standby master or any of the subscribers.