| Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド リリース11.2.1 B56056-01 |
|
 戻る |
 次へ |
この章では、データ・ストアをレプリケートする際に発生する可能性のあるいくつかの問題の解決方法について説明します。
内容は次のとおりです。
この項では、CREATE REPLICATIONでレプリケーション・スキームを作成できないときに確認する事項を説明します。
| 考えられる原因 | 対処 |
|---|---|
| ADMIN権限がない | CREATE REPLICATIONまたはDROP REPLICATION文を使用するには、ADMIN権限が必要です。 |
| データ・ストア名、ホスト名または要素名が間違っている |
|
| ローカル・ホストがレプリケーション・スキームに含まれていない | レプリケーション・スキームに含めるホスト上にレプリケーション・スキームを作成します。 |
| CREATE REPLICATION文で定義されているレプリケーション表が存在しない | レプリケーション・スキームに含まれる表の名前、所有者および列の定義は、マスター・データ・ストアとサブスクライバ・データ・ストアで同一である必要があります。 CREATE TABLEを使用してデータ・ストアに表を作成するか、ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx Cファンクションを使用してレプリケート対象のデータ・ストア全体を複製します。 |
| その他の問題 | 『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のレプリケーション・スキームの定義に関する説明に記述されている手順と要件を確認します。 |
この項では、ALTER REPLICATIONでレプリケーション・スキームを変更できないときに確認する事項を説明します。
| 考えられる原因 | 対処 |
|---|---|
| ADMIN権限がない | ALTER REPLICATION文を使用するには、ADMIN権限が必要です。 |
| レプリケーション・エージェントがStart状態である | ほとんどのALTER REPLICATION操作は、レプリケーション・エージェントが停止（ttAdmin -repStop）しているときにのみサポートされています。マスターとサブスクライバの両方のデータ・ストアでレプリケーション・エージェントを停止し、マスターとサブスクライバの両方のデータ・ストアでレプリケーション・スキームを変更した後、両方のレプリケーション・エージェントを再起動します。 |
| データ・ストア名、ホスト名または要素名が間違っている |
|
| ALTER REPLICATION文で定義されているレプリケーション表が存在しない | CREATE TABLEを使用して、データ・ストアに表を作成します。 |
| その他の問題 | 『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のレプリケーションの変更に関する説明に記述されている手順と要件を確認します。 |
この項では、レプリケーション・エージェントを起動または停止できないときに確認する事項を説明します。
| 考えられる原因 | 対処 |
|---|---|
| ADMIN権限がない | ttAdminユーティリティ、ttRepStartプロシージャまたはttRepStopプロシージャを使用してレプリケーション・エージェントを起動または停止するには、ADMIN権限が必要です。 |
| TimesTenデーモンが起動されていない | TimesTenデーモンの状態を確認します（「TimesTenユーザー・エラー・ログを確認する」を参照）。 必要に応じて、TimesTenデーモンを起動します（『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTen Data Managerデーモンでの処理に関する説明を参照）。 |
| データ・ストアがレプリケーション・スキームに入っていない | データ・ストアがレプリケーション・スキームに関連していないデータ・ストアのレプリケーション・エージェントを起動しようとしても失敗します。 CREATE REPLICATIONを使用して、データ・ストアのレプリケーション・スキームを作成します。 |
TimesTenでは、特定のレプリケーション・イベントに対してSNMPトラップを送信して、ネットワーク管理ソフトウェアでの迅速な対処を可能にします。TimesTenでは、レプリケーション・イベントに対して次のトラップを送信できます。
ttRepAgentExitingTrap
ttRepAgentDiedTrap
ttRepAgentStartingTrap
ttRepCatchupStartTrap
ttRepCatchupStopTrap
ttRepReturnTransitionTrap
ttRepSubscriberFailedTrap
ttRepUpdateFailedTrap
これらのトラップの詳細は、『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップによる診断に関する説明を参照してください。
マスター・データ・ストアとサブスクライバ・データ・ストアの間でレプリケーションを正しく機能させることができない場合、次のいずれかの問題が該当する可能性があります。
| 考えられる原因 | 参照先 |
|---|---|
| TimesTenデーモンまたはレプリケーション・エージェント（あるいはその両方）が稼働していない | 「TimesTenデーモンとレプリケーション・エージェントのステータスを確認する」 |
| マスターとサブスクライバのエージェントが通信していない | 「レプリケーション・エージェントが通信していることを確認する」 |
| レプリケーションがStart状態でない | 「レプリケーションの状態を確認する」 |
| レプリケーション・スキームにエラーがある | 「レプリケーション・スキームの構成を確認する」 |
| レプリケーション・スキームと表の所有者名が一致しない | 「所有者名を確認する」 |
| レプリケーション表に整合性がない | 「レプリケーション表間の整合性を確認する」 |
ttStatusユーティリティを使用して、メインTimesTenデーモンが稼働していること、およびすべてのマスターおよびサブスクライバのデータ・ストアについてレプリケーション・エージェントが起動していることを確認します。 マスターおよびサブスクライバのデータ・ストアが1つしかない単純なレプリケーション・スキームの出力は、例6-1のようになります。
TimesTenデーモンが稼働していても、レプリケーション・エージェントが稼働していない場合、出力は例6-2に示すようになります。 この場合は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のレプリケーション・エージェントの起動と停止に関する説明に従って、レプリケーション・エージェントを起動します。
TimesTenデーモンとレプリケーション・エージェントがどちらも稼働していない場合、出力は例6-3に示すようになります。 この場合は、TimesTenが正しくインストールされていること、およびData Managerサービスが起動されていることを確認します（『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のTimesTenのインストールに関する説明を参照）。
例6-1 1つのマスターおよび1つのサブスクライバに対するttStatus出力
C:\>ttStatus TimesTen status report as of Thu Jan 25 16:23:33 2007 Daemon pid 5088 port 17000 instance MYINSTANCE TimesTen server pid 4344 started on port 17002 TimesTen webserver pid 4216 started on port 17004 ------------------------------------------------------------------------ Data store c:\temp\subscriber1ds There are 12 connections to the data store Data store is in shared mode Shared Memory KEY Global\DBI45b9471c.2.SHM.2 HANDLE 0x280 Type PID Context Connection Name ConnID Process 1244 0x00d08fb0 subscriber1ds 1 Replication 4548 0x00aed2f8 LOGFORCE 4 Replication 4548 0x00b03470 TRANSMITTER 5 Replication 4548 0x00b725a8 RECEIVER 6 Replication 4548 0x00b82808 REPHOLD 2 Replication 4548 0x00b98980 REPLISTENER 3 Subdaemon 2752 0x00526768 Worker 2042 Subdaemon 2752 0x0072a758 Flusher 2043 Subdaemon 2752 0x007308c0 Checkpoint 2044 Subdaemon 2752 0x00736a28 HistGC 2046 Subdaemon 2752 0x067f02f8 Aging 2045 Subdaemon 2752 0x068364a0 Monitor 2047 Replication policy : Manual Replication agent is running. Cache agent policy : Manual ------------------------------------------------------------------------ Data store c:\temp\masterds There are 12 connections to the data store Data store is in shared mode Shared Memory KEY Global\DBI45b945d0.0.SHM.6 HANDLE 0x2bc Type PID Context Connection Name ConnID Process 5880 0x00d09008 masterds 1 Replication 3728 0x00aed570 LOGFORCE 4 Replication 3728 0x00b036e8 TRANSMITTER 5 Replication 3728 0x00b168b8 REPHOLD 3 Replication 3728 0x00b1ca20 REPLISTENER 2 Replication 3728 0x00b22b88 RECEIVER 6 Subdaemon 3220 0x00526768 Worker 2042 Subdaemon 3220 0x0072e768 Flusher 2043 Subdaemon 3220 0x007348d0 Checkpoint 2044 Subdaemon 3220 0x067b0068 Aging 2045 Subdaemon 3220 0x067c0040 Monitor 2047 Subdaemon 3220 0x068404c8 HistGC 2046 Replication policy : Manual Replication agent is running. Cache agent policy : Manual ------------------------------------------------------------------------ Data store c:\temp\demo There are no connections to the data store Replication policy : Manual Cache agent policy : Manual ------------------------------------------------------------------------ End of report
例6-2 レプリケーション・エージェントが稼働していない
> ttStatus TimesTen status report as of Tue Oct 28 10:31:30 2006 Daemon pid 3396 port 15000 instance MYINSTANCE TimesTen server pid 3436 started on port 15002 ----------------------------------------------------------------- Data store c:\temp\subscriberds There are no connections to the data store cache agent restart policy: manual ----------------------------------------------------------------- Data store c:\temp\masterds There are no connections to the data store cache agent restart policy: manual ----------------------------------------------------------------- End of report
ttRepAdmin -receiver -listを使用して、レプリケーション・エージェントが互いに通信していることを確認します。 masterdsデータ・ストアがsubscriberdsデータ・ストアにレプリケートされる場合、出力は次のようになります。
例6-4 レプリケーション・エージェントが通信していることを確認する
> ttRepAdmin -receiver -list masterDSN Peer name Host name Port State Proto ---------------- ------------------------ ------ ------- ----- SUBSCRIBERDS MYHOST Auto Start 10 Last Msg Sent Last Msg Recv Latency TPS RecordsPS Logs ------------- ------------- ------- ------- --------- ---- 0:01:12 - 19.41 5 52 2
ttReplicationStatusプロシージャを使用して、マスターに対するサブスクライバ・データ・ストアの状態を確認します。 サブスクライバの状態がStop、PauseまたはFailedの場合は、ttReplicationStatusプロシージャを使用して、サブスクライバの状態をStartにリセットできます（『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のサブスクライバのレプリケーションの状態の設定に関する説明を参照）。
例6-5 サブスクライバ・データ・ストアのステータスをマスター・データ・ストアから取得する
ttReplicationStatusを使用して、subscriberdsデータ・ストアのステータスをそのマスター・データ・ストアmasterDSNから取得します。次のように入力します。
> ttIsql masterDSN
Command> CALL ttReplicationStatus ('subscriberds');
< SUBSCRIBERDS, MYHOST, 0, pause, 1, 10, REPSCHEME, REPL >
1 row found.
状態をStartにリセットするには、次のようにttRepSubscriberStateSetプロシージャをコールします。
Command> CALL ttRepSubscriberStateSet('REPSCHEME', 'REPL', 'SUBSCRIBERDS', 'MYHOST', 0)
Command> CALL ttReplicationStatus ('subscriberds');
< SUBSCRIBERDS, MYHOST, 0, start, 1, 152959, REPSCHEME, REPL >
1 row found.
この項では、レプリケートされたシステムで様々なコンポーネントが正しく構成されていることを確認する手順について説明します。基本的な手順は次のようになります。
ttRepAdmin -showconfigを使用して、レプリケーション・スキームの構成を確認します。
次の項目を確認します。
サブスクライバのエージェントがすべて起動され、Start状態であることが報告されているかどうか。 起動されていない場合は、そのエージェントをStart状態にリセットします。 詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のサブスクライバのレプリケーション状態の設定に関する説明を参照してください。
返されたPeer nameが、レプリケートするデータ・ストアのDSN定義のデータ・ストア属性で指定された名前と一致しているかどうか。 データソース名属性に設定されている名前を指定した場合、レプリケーションは動作しません。
「List of subscribers」の下に何か表示されているかどうか。表示されていない場合は、DSN定義で指定したデータ・ストア名が、レプリケーション・スキーム構成ファイルで指定した名前と一致することを確認します。
Host nameが正しいかどうか。 不明確な場合は、「ホスト名の確認」を参照してください。
「Table details」の下に表示されている表の名前が正しいかどうか。正しくない場合は、レプリケーション・スキーム構成ファイルで表名を修正します。
例6-6 レプリケーション・スキームの構成を確認する
> ttRepAdmin -showconfig masterDSN Self host "MYHOST", port auto, name "MASTERDS", LSN 4/2970276, timeout 120, threshold 0 List of subscribers ----------------- Peer name Host name Port State Proto ---------------- ------------------------ ------ ------- ----- SUBSCRIBERDS MYHOST Auto Start 10 Last Msg Sent Last Msg Recv Latency TPS RecordsPS Logs ------------- ------------- ------- ------- --------- ---- 0:01:12 - 19.41 5 52 2 List of tables and subscriptions -------------------------------- Table details ------------- Table : REPL.TAB Master Name Subscriber Name ----------- ------------- MASTERDS SUBSCRIBERDS
TTREP.TTSTORES表で、レプリケーションによってレプリケーション・スキームがローカル・データ・ストアに関連付けられていることを確認します。
例6-7 レプリケーション・スキームがローカル・データ・ストアに関連付けられていることを確認する
データ・ストアに接続し、次のように入力します。
SELECT * FROM ttrep.ttstores WHERE is_local_store <> 0x0;
Command> select * from ttrep.ttstores where is_local_store <> 0x0; < -5193371075573733683, MYHOST, MASTERDS, 01, 0, 0, 4, 0 > 1 row found.
1行の結果が返されます。 2行以上返される場合は、テクニカル・サポートに連絡してください。1行も返されない場合は、次の文によって返されるホストは、TimesTenレプリケーションではローカル・システムとみなされません。
SELECT DISTINCT host_name FROM ttrep.ttstores;
また、レプリケーション・スキームで指定されたデータ・ストア名が、DSNの記述で指定されたデータ・ストア名と一致しない場合もあります。
レプリケーション・スキームで指定されたホストとIPアドレスがレプリケーション・エージェントで解決できない場合、次のような原因が考えられます。
レプリケーション・スキームに間違ったホスト名またはIPアドレスが指定されているか、あるいはそれらの綴りが間違っている。
ホスト名またはIPアドレスが解決できない、あるいはDNSまたは/etc/hostsファイルに見つからない。
/etc/hostsファイルのエントリの記述順序が正しくない。このエラーは、複数のNICを使用している場合によく発生します。 /etc/hostsファイルを変更するには、root権限が必要です。
ホスト・マシンをレプリケーションで使用できるようにDNSおよび/etc/hostsファイルを構成する方法の詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のホストIPアドレスの構成に関する説明を参照してください。
レプリケーション・スキームのホスト名とローカル・マシンのホスト名が一致していることを確認するには、次のタスクを実行するようにアプリケーションを作成します。
『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』の表の要件と制限に関する説明、およびレプリケーションのスキームと表の所有者に関する説明で示されているように、レプリケーション・スキームとレプリケーション表の所有者名は、関連するすべてのデータ・ストアで一致している必要があります。
レプリケーション・スキームに割り当てられている所有者名は、ttIsql repschemesコマンドをコールするか、TTREP.REPLICATIONS表の内容をリストして確認します。
例6-8は、SYSTEM1とSYSTEM2の両方で、レプリケーション・スキーム名REPSCHEMEがデータ・ストアに一貫した所有者名（REPL）を持つことを示しています。 例6-9は、所有者名が一貫していないスキーム名を示しています。これは、レプリケーション・スキームの定義で所有者名の指定を省略し、システムがそのレプリケーション・スキームの作成者のIDを採用した場合に発生することがあります。
ttIsql tablesコマンドを使用して、各データ・ストアの表に割り当てられている所有者名を確認します。
| SYSTEM1の出力 | SYSTEM2の出力 |
|---|---|
SYS.CACHE_GROUP |
SYS.CACHE_GROUP |
SYS.COLUMNS |
SYS.COLUMNS |
SYS.COL_STATS |
SYS.COL_STATS |
SYS.INDEXES |
SYS.INDEXES |
SYS.MONITOR |
SYS.MONITOR |
SYS.PLAN |
SYS.PLAN |
SYS.TABLES |
SYS.TABLES |
SYS.TBL_STATS |
SYS.TBL_STATS |
SYS.TRANSACTION_LOG_API |
SYS.TRANSACTION_LOG_API |
|
|
TTREP.REPELEMENTS |
TTREP.REPELEMENTS |
TTREP.REPLICATIONS |
TTREP.REPLICATIONS |
TTREP.REPPEERS |
TTREP.REPPEERS |
TTREP.REPSTORES |
TTREP.REPSTORES |
TTREP.REPSUBSCRIPTIONS |
TTREP.REPSUBSCRIPTIONS |
TTREP.REPTABLES |
TTREP.REPTABLES |
TTREP.TTSTORES |
TTREP.TTSTORES |
| SYSTEM1の出力 | SYSTEM2の出力 |
|---|---|
SYS.CACHE_GROUP |
SYS.CACHE_GROUP |
SYS.COLUMNS |
SYS.COLUMNS |
SYS.COL_STATS |
SYS.COL_STATS |
SYS.INDEXES |
SYS.INDEXES |
SYS.MONITOR |
SYS.MONITOR |
SYS.PLAN |
SYS.PLAN |
SYS.TABLES |
SYS.TABLES |
SYS.TBL_STATS |
SYS.TBL_STATS |
SYS.TRANSACTION_LOG_API |
SYS.TRANSACTION_LOG_API |
|
|
TTREP.REPELEMENTS |
TTREP.REPELEMENTS |
TTREP.REPLICATIONS |
TTREP.REPLICATIONS |
TTREP.REPPEERS |
TTREP.REPPEERS |
TTREP.REPSTORES |
TTREP.REPSTORES |
TTREP.REPSUBSCRIPTIONS |
TTREP.REPSUBSCRIPTIONS |
TTREP.REPTABLES |
TTREP.REPTABLES |
TTREP.TTSTORES |
TTREP.TTSTORES |
マスター・データ・ストアとサブスクライバ・データ・ストアの両方で、レプリケーション表は完全に同じである必要があります。
例6-12 レプリケーション表間の整合性を確認する
このユーザー・エラー・ログの出力は、サブスクライバ表TTUSER.MYDSNの列の数が一致していないことを示しています。
11:37:58.00 Info: REP: 9430: REP1:transmitter.c(4936): TT16136: Sending definition for table TTUSER.MYDSN (1 columns) 11:37:58.00 Info: REP: 9412: REP2:receiver.c(5928): TT16193: Adding definition for table: TTUSER.MYDSN 11:37:58.00 Info: REP: 9412: REP2:meta.c(5580):TTUSER.MYDSN ptn 0: srcoff 0, destoff 0, length 8 11:37:58.00 Info: REP: 9412: REP2:meta.c(5580):TTUSER.MYDSN ptn 1: srcoff 8, destoff 12, length 12 11:37:58.00 Err : REP: 9412: REP2:receiver.c(6203): TT16198: Table definition mismatch on number of columns for table TTUSER.MYDSN. Local definition: 2; transmitting peer: 1 11:37:58.00 Err : REP: 9412: REP2:receiver.c(6380): TT16204: Table TTUSER.MYDSN marked invalid. Will not apply transactions received for it until a valid definition is received 11:37:58.00 Err : REP: 9412: REP2:receiver.c(7200): TT16078: Table definition for ID 637068 is invalid (Original failure 11:37:58 REP2:receiver.c(6203): TT16198: Table definition mismatch on number of columns for table TTUSER.MYDSN. Local definition: 2; transmitting peer: 1) 11:37:58.00 Err : REP: 9412: REP2:receiver.c(5002): TT16187: Transaction 1173958671/2; Error: transient 0, permanent 1
最初のヘッダー・セルに表の概要が示されています。
| 考えられる原因 | 参照先 |
|---|---|
| サブスクライバの障害 | 「レプリケーションの状態を確認する」 |
| RETURN RECEIPTタイムアウト時間が長すぎる | 「RETURN RECEIPTタイムアウトの設定を確認する」 |
ttReplicationStatusプロシージャを使用して、マスターに対するサブスクライバ・データ・ストアの状態を確認します。 サブスクライバがFailed状態になっている場合、障害のあったデータ・ストアへの対処法について、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のデータ・ストアのフェイルオーバーとリカバリの管理に関する説明を参照してください。
ttRepSyncGetプロシージャを使用して、RETURN RECEIPTタイムアウトの設定を確認します。-1は、サブスクライバからの応答を受け取るまでアプリケーションが待機することを示します。サブスクライバの応答の受取りは、ネットワークの待機時間などの問題によって遅延する可能性があります。 これらの問題を解決するか、またはttRepSyncSetプロシージャを使用してRETURN RECEIPTタイムアウト時間を再設定します。
詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のRETURN RECEIPTサービス・トランザクションのステータスの確認に関する説明を参照してください。
この項では、レプリケーションのパフォーマンスに影響する可能性がある問題について説明します。 ログ・バッファが小さすぎたり、ディスク上のトランザクション・ログ・ファイルから読み取ると、レプリケーションとXLAアプリケーションの両方のパフォーマンスに影響する可能性があります。
| 考えられる原因 | 参照先 |
|---|---|
| ネットワークが遅い | 「ネットワーク帯域幅を確認する」 |
| RETURN RECEIPTを使用している | 「RETURN RECEIPTブロッキングの使用を確認する」 |
| レプリケーション・スキームの効率が悪い | 「レプリケーションの構成を確認する」 |
| ログ・バッファが小さすぎる | 「ログ・バッファのサイズを確認する」 |
| ディスクの書込み頻度が高いか、または効率が悪い | 「永続性の設定を確認する」 |
| ログ・バッファではなくディスク上のトランザクション・ログ・ファイルからの読取り | 「トランザクション・ログ・ファイルからの読取りの有無を確認する」 |
| 競合の頻度が高い | 「競合レポートのためにレプリケーションが遅くなる」 |
通常、レプリケーション・エージェントはネットワーク接続を介して通信を行います。 10MB/秒（たとえば、LANで一般的な100 Base-Tイーサネットなど）より遅いネットワークでレプリケートを実行する場合、トランザクションの負荷をネットワークの利用可能な帯域幅に合わせるように注意する必要があります。詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のネットワーク帯域幅の要件に関する説明を参照してください。
すべてのトランザクションについて受取りの確認を必要とする場合以外は、RETURN RECEIPTブロッキングを無効にしてください。 一部のトランザクションについて受取りの確認が必要な場合は、RETURN RECEIPT BY REQUESTを設定して、ttRepSyncSetプロシージャをコールし、特定のトランザクションに対するRETURN RECEIPTサービスを有効にします。 詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のRETURN RECEIPT BY REQUESTに関する説明を参照してください。
|
注意: 複数のアプリケーション（またはスレッド）でデータ・ストアを更新している場合、RETURN RECEIPTによるパフォーマンスの低下はそれほど問題ではなくなります。トランザクションでRETURN RECEIPTを使用する必要がある場合、複数のスレッドを使用してデータ・ストアを更新することで、アプリケーションのパフォーマンスを改善できます。 各スレッドは受取りの確認のためにブロックする必要はありますが、それ以外のスレッドは自由に更新できます。 |
前述のRETURN RECEIPTの設定に加えて、レプリケーション・スキームの構成に関するその他の要因が、レプリケーションのパフォーマンスに影響を与える可能性があります。 『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のパフォーマンスとリカバリのトレードオフに関する説明で記述されているように、データ・ストアのフェイルオーバーとリカバリを効率的に実行できることと、レプリケーションのパフォーマンスのどちらを優先するかの比較検討が必要になる場合もあります。
次の説明も参照してください。
『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』の効率性および経済性に関する説明
『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』の直接レプリケーションまたはプロパゲータに関する説明
ログ・バッファの設定値が小さすぎると、レプリケーションのパフォーマンスに影響する場合があります。 かわりに、LogBufMB DSN属性のサイズを大きく設定します。 このDSN属性の詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のロギングの属性の設定に関する説明を参照してください。
レプリケーションのELEMENTに対してTRANSMIT NONDURABLEを設定して、ログをディスクにフラッシュする操作をレプリケーション・サイクルから取り除くことで、レプリケーションのパフォーマンスを改善できます。 詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のデータ・ストアの要素での送信永続性の設定に関する説明を参照してください。
また、レプリケーション・スキームでDURABLE COMMITオプションを有効にしても、パフォーマンスに影響があります。 詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のDURABLE COMMITに関する説明を参照してください。
状況によっては、マスター・レプリケーション・エージェントのTRANSMITTERスレッドやXLAアプリケーションのttXlaNextUpdateコールなどのログ・リーダーが、アプリケーションによるデータ・ストアへの書込みの更新を処理しきれない場合があります。通常、レプリケーションおよびXLAリーダーは、メモリー内のログ・バッファから更新レコードを取得します。 リーダーがアプリケーションの更新を処理しきれない場合、バックログがクリアできるようになるまで、トランザクション・ログ・ファイルがディスクに蓄積されることがあります。 この場合、リーダーは、非常に遅いディスク上のトランザクション・ログ・ファイルからトランザクションを読む必要があります。 トランザクション・ログ・ファイルからの読取りを検出したら、ログ・リーダーが処理できる速度までアプリケーションの更新速度を下げてください。
アプリケーションでは、SYS.MONITOR表のエントリLOG_FS_READSを追跡することで、ログ・リーダーがメモリー内のログ・バッファではなく、ディスク上のトランザクション・ログ・ファイルから更新レコードを取得していることを監視できます。 たとえば、データ・ストアMASTERDSNのLOG_FS_READS値は、次のttIsqlコマンドで確認できます。
% ttIsql -v1 -e "select log_fs_reads from monitor; quit;" -connStr dsn=MASTERDSN
LOG_FS_READSカウンタが増加している場合、ログ・リーダーはトランザクション・ログ・ファイル内のバックログより遅れている、バックログをクリアしています。
より完全にレプリケーション・プロセスを監視するには、次のような簡単なシェル・スクリプトを作成します。
!/bin/sh trap exit 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 DSN=$1 while [ 1 ] ; do date ttRepAdmin -receiver -list -connStr dsn=$DSN echo -n "Log reads from disk: " ttIsql -v1 -e "select log_fs_reads from monitor; quit;" -connStr dsn=$DSN echo ttRepAdmin -bookmark -connStr dsn=$DSN sleep 15 done
例6-14 トランザクション・ログのステータスを確認する
たとえば、前述のスクリプトがmonitorLogという名前で、レプリケーション・スキームによって、MASTERDSNデータ・ストアからSUBSCRIBER1DSNデータ・ストアにレプリケートが行われるとします。この場合は、次のように入力して、トランザクションのステータスを確認できます。
$ monitorLog masterdsn
次のような出力が表示されます。
Mon Aug 2 10:44:40 2004 Peer name Host name Port State Proto ---------------- ------------------------ ------ ------- ----- SUBSCRIBER1DSN MYHOST Auto Start 12 Last Msg Sent Last Msg Recv Latency TPS RecordsPS Logs ------------- ------------- ------- ------- --------- ---- 00:00:05 - -1.00 -1 -1 1 Log reads from disk: < 0 > Replication hold LSN ...... 10/2656136 Last written LSN .......... 10/4015824 Last LSN forced to disk ... 10/3970152
[Ctrl]キーを押しながら[C]キーを押して終了するまで、スクリプトによって、更新されたステータスが15秒毎に表示されます。
例6-14の出力では、日付の後にサブスクライバ名、ホスト名などが表示されます。 その後には、待機時間、速度に関する情報、およびこのサブスクライバに代わって保持されているトランザクション・ログ・ファイルの数が表示されます。 各値の具体的な意味は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のコマンドラインからのttRepAdmin -receiver -listに関する説明を参照してください。 ここでは、Last Msg SentとLogsの値です。 Last Msg Sentの値は、最終メッセージがマスターによってサブスクライバに送信されてからの経過時間を示します。Logsの値は、ライターが使用する現在のログ挿入ポイント（Last written LSN）以降で、レプリケーション・ログ・リーダーより遅れているトランザクション・ログ・ファイル数を示します。
例6-14で示すように、通常、Logsの値は1です。 Logsの値が一定間隔で増えることは、待機時間が増え、ディスクからログが読み取れることを示します。
|
注意: LogBufMBがLogFileSizeよりも大きい場合、Logsの値が増加しても、ログ・リーダーがトランザクション・ログ・ファイルから読取りを行っているとはかぎりません。 これは、データをファイル・システムに書き込む前に、未処理のデータが1ログ・ファイル分を超えることをログ・マネージャが許可しないためです。ログ・マネージャがデータを書き込んだ後は、ログ・リーダーから直接読み取れるように、データはログ・バッファ内に残ります。 したがって、LogBufMBがLogFileSizeよりも大きい場合、Logsの値のみでは、ログ・リーダーがメモリーとディスクのどちらから読取りを行っているかを判断できない場合があります。 |
次のコマンドの出力について考えます。
ttRepAdmin -bookmark -connStr dsn=$DSN
『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のコマンドラインからのttRepAdmin -bookmarkの説明で記述されているとおり、トランザクション・ログ・ファイル数およびログ・マネージャによって設定されるブックマークの位置が表示されます。 Replication hold LSNとlast written LSNとの差異は、サブスクライバに送信されていないトランザクション・ログのレコード数を示します。これらの値の差異が一定間隔で増加する場合は、レプリケーションの待機時間が増え、ログ・ファイルの読取りが発生する可能性があることを示します。
例6-15 ログ・リーダーはトランザクション・ログ・ファイルから読み取る必要がある
この例では、LogBufMBは16MB、LogFileSizeは8MBと想定しています。 次の出力は、ログ・リーダーがログ・バッファの容量よりも約1.8MB遅れており、トランザクション・ログ・ファイル14および15からの読取りが必要なことを示しています。
Peer name Host name Port State Proto ---------------- ------------------------ ------ ------- ----- SUBSCRIBER1DSN MYHOST Auto Start 12 Last Msg Sent Last Msg Recv Latency TPS RecordsPS Logs ------------- ------------- ------- ------- --------- ---- 00:00:03 - -1.00 -1 -1 4 Log reads from disk: <20> Replication hold LSN ...... 14/7007464 Last written LSN .......... 17/465336 Last LSN forced to disk ... 17/456152
この項の内容は次のとおりです。
ttRepAdmin -duplicateを実行する前に新しいサブスクライバDSNに接続している場合、データ・ストアはすでに作成されています。このような状況では、-duplicateは次のメッセージを返します。
Error : Restore not done : The datastore already exists. Unable to restore datastore locally
ttStatusを実行し、返されたリストにデータ・ストアがあるかどうかを確認することによって、データ・ストアの有無を確認します。 新しいサブスクライバ・データ・ストアがある場合は、それを破棄し、ttRepAdmin -duplicateを再度実行します。
> ttDestroy /tmp/newstore > ttRepAdmin -dsn newstoreDSN -duplicate -name newstore -from masterds -host "server1"
レプリケーション・スキームにサブスクライバ・データ・ストア名やホスト名を間違って入力した場合、次のようなメッセージが表示されます。
Unable to swap datastore locally No receiver NEWSTORE on SERVER2 found to swap with
TTREP.REPLICATIONS表に複数のスキームが指定されている場合、一部のttRepAdminコマンドによって次のエラーが返されることがあります。
Must specify -scheme to identify which replication scheme to use
データ・ストアで使用するレプリケーション・スキームの名前を確認するには、ttIsqlユーティリティを使用して接続し、次のコマンドを入力します。
Command> SELECT * from TTREP.REPLICATIONS;
例6-16 データ・ストアに2つのレプリケーション・スキームが割り当てられている
この例は、2つのレプリケーション・スキームREPSCHEME1とREPSCHEME2が、subDSNに関連付けられたデータ・ストアに割り当てられていることを示しています。 この場合、ttRepAdmin -schemeオプションを使用する必要があります。
> ttIsql -connStr "dsn=subDSN" Command> SELECT * from TTREP.REPLICATIONS; < REPSCHEME1 , REPL , C, 0, 0, -1 > < REPSCHEME2 , REPL , C, 0, 0, -1 > 2 rows found. Command> exit > ttRepAdmin -dsn subDSN -receiver -list -scheme REPSCHEME1 Peer name Host name Port State Proto ---------------- ------------------------ ------ ------- ----- SUBSCRIBER1 MYHOST Auto Start 10 Last Msg Sent Last Msg Recv Latency TPS RecordsPS Logs ------------- ------------- ------- ------- --------- ---- 0:01:12 - 19.41 5 52 2
この項の内容は次のとおりです。
CREATE REPLICATION文の要素にCHECK CONFLICTSを設定しようとすると、次のようなエラーを受け取ることがあります。
8004: Column REPL.TABS.TS cannot be used for replication timestamp checking if in an index or added by ALTER TABLE; and must be binary(8) with NULL values allowed.
この場合、次の項目を確認します。
指定した表のタイムスタンプ列がタイプBINARY(8)のNULL値可能な列であること。 前述の例では、REPL.TAB表のTS列のデータ型がBINARY(8)である必要があります。
タイムスタンプ列は、ALTER TABLEを使用して後から追加するのではなく、元のCREATE TABLE文で定義されていること。
2208: Column TS does not exist in table.
この場合、CHECK CONFLICTS句のタイムスタンプ列に正しい名前が指定され、それが指定した表にあることを確認します。
また、タイムスタンプ列が主キーまたは索引の一部でないことを確認します。
競合をチェックするようにレプリケーションを構成している場合、TimesTenはローカル・ホストにレポートを送信します。レポート・ファイルを構成することもできます。 詳細は、『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップによる診断に関する説明を参照してください。
短期間に多数の競合が発生すると、レポートの要件によってサブスクライバのパフォーマンスが低下する可能性があります。 CREATE REPLICATION文またはALTER REPLICATION文にストア属性を使用して、競合の頻度が指定した値に達した場合に競合レポートを一時停止したり、再開することができます。
CONFLICT REPORTING SUSPEND AT rate
CONFLICT REPORTING RESUME AT rate
レポートの一時停止中に発生した競合についての情報は取得できません。
『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』の競合レポートに関する説明
