| Oracle® TimesTen In-Memory Databaseトラブルシューティング・ガイド リリース18.1 E98632-04 |
|
 前 |
 次 |
この章の次の項は、データベースをレプリケートする時に発生する可能性がある問題の解決方法について説明します。
|
ノート: この章の例で示すとおり、レプリケーション・エージェント・デーモンからのエラー・ログは、REPでメッセージ内に指定されます。ttDaemonLogユーティリティのREPLICATIONコンポーネントを無効化しないかぎり、これらのメッセージは有効です。ttDaemonLogオプションの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDaemonLogに関する項を参照してください。 |
この項では、CREATE REPLICATIONでレプリケーション・スキームを作成できないときに確認する事項を説明します。
| 考えられる原因 | 対処 |
|---|---|
ユーザーが、ADMIN権限を持っていない。 |
CREATE REPLICATIONまたはDROP REPLICATION文を使用するには、ADMIN権限が必要です。 |
| データベース名、ホスト名または要素名が間違っている。 |
|
| ローカル・ホストがレプリケーション・スキームに含まれていない | レプリケーション・スキームに含めるホスト上にレプリケーション・スキームを作成します。 |
CREATE REPLICATION文で定義されているレプリケーション表が存在しない |
レプリケーション・スキームに含まれる表の名前、所有者および列の定義は、マスター・データベースとサブスクライバ・データベースで同一である必要があります。CREATE TABLEを使用してデータベースに表を作成するか、ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx Cファンクションを使用してレプリケート対象のデータベース全体を複製します。 |
| その他の問題がある。 | 『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のクラシック・レプリケーション・スキームの定義に関する項に記載されているプロシージャおよび要件を確認します。 |
この項では、ALTER REPLICATIONでレプリケーション・スキームを変更できないときに確認する事項を説明します。
| 考えられる原因 | 対処 |
|---|---|
ユーザーが、ADMIN権限を持っていない。 |
ALTER REPLICATION文を使用するには、ADMIN権限が必要です。 |
| レプリケーション・エージェントがStart状態である。 | ほとんどのALTER REPLICATION処理は、レプリケーション・エージェントが停止している場合(ttAdmin -repStop)にのみサポートされます。マスターとサブスクライバの両方のデータベースでレプリケーション・エージェントを停止し、マスターとサブスクライバの両方のデータベースでレプリケーション・スキームを変更した後、両方のレプリケーション・エージェントを再起動します。 |
| データベース名、ホスト名または要素名が一致しない。 |
|
ALTER REPLICATION文で定義されているレプリケーション表が存在しない。 |
CREATE TABLEを使用してデータベースに表を作成します。 |
| その他の問題がある。 | 『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のクラシック・レプリケーション・スキームの変更に関する項に記載されているプロシージャおよび要件を確認します。 |
この項では、レプリケーション・エージェントを起動または停止できないときに確認する事項を説明します。
| 考えられる原因 | 対処 |
|---|---|
ユーザーが、ADMIN権限を持っていない。 |
ttAdminユーティリティ、ttRepStartプロシージャまたはttRepStopプロシージャを使用してレプリケーション・エージェントを起動または停止するには、ADMIN権限が必要です。 |
| TimesTenデーモンが起動しない。 | TimesTenデーモンの状態を確認します(「TimesTenユーザー・エラー・ログを確認する」を参照)。必要に応じて、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデーモンの処理に関する項を参照して、TimesTenデーモンを起動します。 |
| データベースがレプリケーション・スキームに入っていない | レプリケーション・スキームに関連していないデータベースのレプリケーション・エージェントを起動しようとしても失敗します。CREATE REPLICATIONを使用して、データベースのレプリケーション・スキームを作成します。 |
マスター・データベースとサブスクライバ・データベースの間でレプリケーションを正しく機能させることができない場合、次のいずれかの問題が該当する可能性があります。
| 考えられる原因 | 参照先 |
|---|---|
| TimesTenデーモンまたはレプリケーション・エージェントが稼働していない。 | 後述の「TimesTenデーモンとレプリケーション・エージェントのステータスを確認する」 |
| マスターとサブスクライバのエージェントが通信していない。 | 「レプリケーション・エージェントが通信していることを確認する」 |
| レプリケーションがStart状態ではない。 | 「レプリケーションの状態を確認する」 |
| レプリケーション・スキームでエラーが発生した。 | 「レプリケーション・スキームの構成を確認する」 |
| レプリケーション・スキームと表の所有者名が一致しない。 | 「所有者名を確認する」 |
| レプリケーション表に整合性がない。 | 「レプリケーション表間の整合性を確認する」 |
ttStatusユーティリティを使用して、メインTimesTenデーモンが稼働していること、およびすべてのマスターおよびサブスクライバのデータベースについてレプリケーション・エージェントが起動していることを確認します。マスターおよびサブスクライバのデータベースが1つしかない単純なレプリケーション・スキームの出力は、例4-1のようになります。
TimesTenデーモンが稼働していても、レプリケーション・エージェントが稼働していない場合、出力は例4-2に示すようになります。この場合、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のレプリケーション・エージェントの起動と停止に関する説明に従ってレプリケーション・エージェントを起動します。
TimesTenデーモンとレプリケーション・エージェントがどちらも稼働していない場合、出力は例4-3に示すようになります。この場合、TimesTenが正しくインストールされていて、Data Managerサービスが起動していることを確認します。
例4-1 1つのマスターおよび1つのサブスクライバに対するttStatus出力
C:\>ttStatus TimesTen status report as of Mon Aug 6 22:07:53 2012 Daemon pid 5088 port 17000 instance MYINSTANCE TimesTen server pid 4344 started on port 17002 ------------------------------------------------------------------------ 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
例4-2 レプリケーション・エージェントが稼働していない
> ttStatus TimesTen status report as of Mon Aug 6 22:07:53 2012 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データベースにレプリケートされる場合、出力は次のようになります。
例4-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の場合、Oracle TimesTen In-Memory Databaseレプリケーション・ガイドのサブスクライバのレプリケーション状態の設定の説明に従い、ttReplicationStatusプロシージャを使用してサブスクライバの状態をStartにリセットします。
例4-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レプリケーション・ガイドのサブスクライバのレプリケーション状態の設定を参照してください。
返されたPeer nameが、レプリケートするデータベースのDSN定義のDataStore属性で指定された名前と一致しているかどうか。データソースName属性に設定されている名前を指定した場合、レプリケーションは動作しません。
「List of subscribers」の下に何か表示されているかどうか。表示されていない場合は、DSN定義で指定したデータベース名が、レプリケーション・スキーム構成ファイルで指定した名前と一致することを確認します。
Host nameが正しいかどうか。不明確な場合は、「ホスト名の確認」を参照してください。
「Table details」の下に表示されている表の名前が正しいかどうか。正しくない場合は、レプリケーション・スキーム構成ファイルで表名を修正します。
例4-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表で、レプリケーションによってレプリケーション・スキームがローカル・データベースに関連付けられていることを確認します。
例4-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行以上返される場合は、TimesTenカスタマ・サポートに連絡してください。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レプリケーション・ガイド』のネットワークの構成に関する項を参照してください。
レプリケーション・スキームのホスト名とローカル・システムのホスト名が一致していることを確認するには、次のタスクを実行するようにアプリケーションを作成します。
gethostname オペレーティング・システム・ファンクション・コールを使用して、実行中のホストのホスト名を確認します。
ステップ1の出力を使用して、gethostbynameをコールします。
レプリケーション・スキームで指定されているホスト名を使用して、gethostbynameをコールします。
ステップ2とステップ3の出力を比較します。一致している場合、実行中のホストはレプリケーションに含まれています。一致していない場合は、レプリケーションに含まれていません。
Oracle TimesTen In-Memory Databaseレプリケーション・ガイドのクラシック・レプリケーション・スキームの表要件および制限およびレプリケーション・スキームおよびレプリケートされたオブジェクトの所有者に記載されているように、レプリケーション・スキームおよびレプリケートされた表の所有者名は関連するすべてデータベース全体で一貫している必要があります。つまり、レプリケーション・スキーム所有者はすべてのデータベースで一致し、それぞれの表はデータベース内の同一のユーザーにより所有されている必要があります。
レプリケーション・スキームに割り当てられている所有者名は、ttIsql repschemesコマンドをコールするか、TTREP.REPLICATIONS表の内容をリストして確認します。
例4-8は、SYSTEM1とSYSTEM2の両方で、レプリケーション・スキーム名REPSCHEMEがデータベースに一貫した所有者名(REPL)を持つことを示しています。例4-9は、所有者名が一貫していないスキーム名を示しています。これは、レプリケーション・スキームの定義で所有者名の指定を省略し、システムがそのレプリケーション・スキームの作成者のIDを採用した場合に発生することがあります。
ttIsql tablesコマンドを使用して、各データベースの表に割り当てられている所有者名を確認します。
| SYSTEM1の出力 | SYSTEM2の出力 |
|---|---|
|
|
| SYSTEM1の出力 | SYSTEM2の出力 |
|---|---|
|
|
デフォルトでは、TimesTenのレプリケーション・スキームはTABLE DEFINITION CHECKING RELAXED属性を使用して作成されます。TABLE DEFINITION CHECKING RELAXED属性では、レプリケートされた表の列定義が同じである必要はありません。RELAXED属性には、レプリケートされた表に同じキー定義、列数、列名および列のデータ型のみが必要です。TABLE DEFINITION CHECKING EXACT句を使用してレプリケーション・スキームを定義する場合、レプリケーション・スキームに含まれるレプリケートされた表の列の定義はマスター・データベースとサブスクライバ・データベースで同一である必要があります。TimesTenでは、TABLE DEFINITION CHECKING RELAXEDを使用することをお薦めします。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のレプリケート表の列定義オプションに関する項を参照してください。
例4-12 レプリケーション表間の整合性を確認する
このユーザー・エラー・ログの出力は、サブスクライバ表TTUSER.MYDSNの列の数が一致していないことを示しています。
11:37:58.00 Info: REP: 9430: REP1:transmitter.c(4936): TT16136: Sending definition for table TTUSER.MYDSN (1 column) 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開発者および管理者ガイド』のデータベースのフェイルオーバーおよびリカバリの管理に関する説明を参照してください。
ttRepSyncGetプロシージャを使用して、RETURN RECEIPTタイムアウトの設定を確認します。-1は、サブスクライバからの応答を受け取るまでアプリケーションが待機することを示します。サブスクライバの応答の受取りは、ネットワークの待機時間などの問題によって遅延する可能性があります。問題を解決するか、またはttRepSyncGetプロシージャ を使用して、受領通知のタイムアウト時間をリセットします。
詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のRETURNサービス・トランザクション状態の確認に関する項を参照してください。
この項では、レプリケーションのパフォーマンスに影響する可能性がある問題について説明します。ログ・バッファが小さすぎたり、ファイル・システム上のトランザクション・ログ・ファイルから読み取ると、レプリケーションとXLAアプリケーションの両方のパフォーマンスに影響する可能性があります。
| 考えられる原因 | 参照先 |
|---|---|
| ネットワークが遅い。 | 後述の「ネットワーク帯域幅を確認する」 |
RETURN RECEIPTが使用されている。 |
後述の「RETURN RECEIPTブロッキングの使用を確認する」 |
| レプリケーション・スキームに整合性がない。 | 「レプリケーションの構成を確認する」 |
| ログ・バッファが小さすぎる。 | 「ログ・バッファのサイズを確認する」 |
| ファイル・システムの書込み頻度が高いか、または効率が悪い。 | 「永続性の設定を確認する」 |
| ログ・バッファではなくファイル・システム上のトランザクション・ログ・ファイルから読み取られる。 | 「トランザクション・ログ・ファイルからの読取りの有無を確認する」 |
| 競合の頻度が高い。 | 「競合レポートのためにレプリケーションが遅くなる」 |
通常、レプリケーション・エージェントはネットワーク接続を介して通信を行います。1秒あたり10MBより遅いネットワーク上でレプリケートする場合(LANの100 Base-Tイーサネットがその典型例)、トランザクション・ロードが、利用できるネットワーク・バンド幅に一致するよう注意する必要があります。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のネットワーク・バンド幅の要件に関する説明を参照してください。
すべてのトランザクションについて受取りの確認を必要とする場合以外は、RETURN RECEIPTブロッキングを無効にしてください。一部のトランザクションについて受取りの確認が必要な場合は、RETURN RECEIPT BY REQUESTを設定して、ttRepSyncSetプロシージャをコールし、特定のトランザクションに対するRETURN RECEIPTサービスを有効にします。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のリクエストによる受領通知に関する説明を参照してください。
|
ノート: 複数のアプリケーション(またはスレッド)でデータベースを更新している場合、RETURN RECEIPTによるパフォーマンスの低下はそれほど問題ではなくなります。トランザクションでRETURN RECEIPTを使用する必要がある場合、複数のスレッドを使用してデータベースを更新することで、アプリケーションのパフォーマンスを改善できます。各スレッドは受取りの確認のためにブロックする必要はありますが、それ以外のスレッドは自由に更新できます。 |
前述のRETURN RECEIPTの設定に加えて、レプリケーション・スキームの構成に関するその他の要因が、レプリケーションのパフォーマンスに影響を与える可能性があります。『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のパフォーマンスおよびリカバリ・トレードオフに関する決定の説明に記載されているとおり、レプリケーション・パフォーマンスに対してデータベースを効果的にフェイルオーバーしたりリカバリする機能を頻繁に重み付けする必要があります。
『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の直接的なレプリケーションまたは伝播に関する説明を参照してください。
ログ・バッファの設定値が小さすぎると、レプリケーションのパフォーマンスに影響する場合があります。かわりに、LogBufMB DSN属性のサイズを大きく設定します。DSN属性に関する詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のログの接続属性の設定に関する説明を参照してください。
レプリケーションのELEMENTに対してTRANSMIT NONDURABLEを設定して、ログをファイル・システムにフラッシュする操作をレプリケーション・サイクルから取り除くことで、レプリケーションのパフォーマンスを改善できます。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のDATASTORE要素に対する送信永続性の設定に関する項を参照してください。
また、レプリケーション・スキームでDURABLE COMMITオプションを有効にしても、パフォーマンスに影響があります。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のDURABLE COMMITに関する説明を参照してください。
状況によっては、マスター・レプリケーション・エージェントのTRANSMITTERスレッドやXLAアプリケーションのttXlaNextUpdateコールなどのログ・リーダーが、アプリケーションによるデータベースへの書込みの更新を処理しきれない場合があります。通常、レプリケーションおよびXLAリーダーは、メモリー内のログ・バッファから更新レコードを取得します。リーダーがアプリケーションの更新を処理しきれない場合、バックログがクリアできるようになるまで、トランザクション・ログ・ファイルがファイル・システムに蓄積されることがあります。この場合、リーダーは、非常に遅いファイル・システム上のトランザクション・ログ・ファイルからトランザクションを読む必要があります。トランザクション・ログ・ファイルからの読取りを検出したら、ログ・リーダーが処理できる速度までアプリケーションの更新速度を下げてください。
アプリケーションでは、SYS.MONITOR表のエントリLOG_FS_READSを追跡することで、ログ・リーダーがメモリー内のログ・バッファではなく、ファイル・システム上のトランザクション・ログ・ファイルから更新レコードを取得していることを監視できます。たとえば、次のttIsqlコマンドを使用すると、データベースMASTERDSNのLOG_FS_READSの値を確認することができます。
% 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
例4-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秒毎に表示されます。
例4-14の出力では、日付に続いて、サブスクライバやそのホストなどの名前が表示されます。次に、待機時間、レートの情報、およびこのサブスクライバに代わって保持されているトランザクション・ログの数が表示されます。各値の具体的な意味は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のttRepAdminによるサブスクライバ状態の表示に関する項に説明されています。ここで特に注目するのは、'Last Msg Sent'および'Logs'値です。Last Msg Sentの値は、最終メッセージがマスターによってサブスクライバに送信されてからの経過時間を示し、Logsの値は、ライターが使用する現在のログ挿入ポイント(Last written LSN)以降で、レプリケーション・ログ・リーダーより遅れているログ・ファイル数を示します。
例4-14で示すように、通常、Logsの値は1です。Logsの値が一定間隔で増えることは、待機時間が増え、ファイル・システムからログが読み取れることを示します。
|
ノート: LogBufMBがLogFileSizeよりも大きい場合、Logsの値が増加しても、ログ・リーダーがトランザクション・ログ・ファイルから読取りを行っているとはかぎりません。これは、データをファイル・システムに書き込む前に、未処理のデータが1ログ・ファイル分を超えることをログ・マネージャが許可しないためです。ログ・マネージャがデータを書き込んだ後は、ログ・リーダーから直接読み取れるように、データはログ・バッファ内に残ります。したがって、LogBufMBがLogFileSizeよりも大きい場合、'Logs'の値のみでは、ログ・リーダーがメモリーとファイル・システムのどちらから読取りを行っているかを判断できない場合があります。 |
次のコマンドの出力では、トランザクション・ログ・ファイルの数、およびログ・マネージャによって設定されるブックマークの場所を表示しています。
ttRepAdmin -bookmark -connStr dsn=$DSN
詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のttRepAdminユーティリティを使用したレプリケーションの監視に関する項を参照してください。Replication hold LSNとlast written LSNとの差異は、サブスクライバに送信されていないトランザクション・ログのレコード数を示します。これらの値の差異が一定間隔で増加する場合は、レプリケーションの待機時間が増え、ログ・ファイルの読取りが発生する可能性があることを示します。
例4-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
この項の内容は次のとおりです。
レプリケーションでセカンダリIPアドレスを使用するように構成されている場合に、レプリケーションの受信側の状態を変更しようとすると、/etc/hostsファイルの不適切な構成が原因で、ttRepAdminが次のエラーを出力します。
Alter replication with 'ALTER REPLICATION...port 0' failed: TT0907: Unique constraint (REPSTORESIX) violated.
このエラーはローカル・データベースを認識していないレプリケーションが原因で発生しますが、これは次の問合せを行うことで確認できます。
SELECT * FROM ttrep.ttstores WHERE is_local_store <> 0x0;
この問合せで、行が戻されないか、またはユーザーが指定したホストではなく、hostnameコマンドの結果に設定されているデータベースのメイン・ホスト名を含む行が戻される場合は、/etc/hostsファイルに構成の問題があります。
この問題を解決するには、使用している特別なホスト名が/etc/hostsファイルに定義されていて、特別なホスト名とhostnameコマンドの結果に共通のIPアドレスがあることを確認します。
たとえば、hostnameコマンドによってsoftswitchが戻され、使用しているシステムにはアドレスが10.10.15.136と192.168.15.136の2つのイーサネット・カードが搭載されているとした場合、softswitchに定義するIPアドレスには、両方のIPアドレスが含まれている必要があります。
TimesTenは、ソース・システムおよびターゲット・システムの両方に、同一のインスタンス管理者でインストールされていることを確認します。インストールされている場合、次のような他の原因が考えられます。
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
サブスクライバに間違ったホスト名を入力した場合は、次のエラーを受け取ります。
Problem: ttRepAdmin -duplicate command returns TimesTen error 12080: No subscriber found to swap with.
また、TimesTenが見つけようとしているサブスクライバに関する情報も受け取ります。一般的な原因の1つとして、間違ったホスト名の入力が挙げられますが、ホスト名は、CREATE ACTIVE STANDBY PAIR文の発行時に指定したホスト名と完全に一致している必要があります。たとえば、myhost.oracle.comというサブスクライバを作成して、ttRepAdmin -duplicateにmyhostとしか入力しなかった場合、サブスクライバは見つかりません。
|
ノート: myhostがローカル・ホストである場合は、-localhost引数を使用します。ローカルホスト名が、レプリケーション・スキームの作成時に指定したホスト名と完全に一致しない場合は、一般的に-localhost引数を使用する必要があります。 |
TTREP.REPLICATIONS表に複数のスキームが指定されている場合、一部のttRepAdminコマンドによって次のエラーが返されることがあります。
Must specify -scheme to identify which replication scheme to use
データベースで使用するレプリケーション・スキームの名前を確認するには、ttIsqlユーティリティを使用して接続し、次のコマンドを入力します。
Command> SELECT * from TTREP.REPLICATIONS;
例4-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句のタイムスタンプ列に正しい名前が指定され、それが指定した表にあることを確認します。
また、タイムスタンプ列が主キーまたは索引の一部でないことを確認します。
短期間に多くの競合が発生すると、レポートの要件によってサブスクライバのパフォーマンスが低下する可能性があります。CREATE REPLICATION文またはALTER REPLICATION文にストア属性を使用して、競合の頻度が指定した値に達した場合に競合レポートを一時停止したり、再開することができます。
CONFLICT REPORTING SUSPEND AT 頻度
CONFLICT REPORTING RESUME AT 頻度
レポートの一時停止中に発生した競合についての情報は取得できません。
『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の競合のレポートに関する説明を参照してください。
パラレル・レプリケーションを構成している場合、システムで実行中の別のTimesTenレプリケーション・スレッドが存在します。レプリケーション・スレッドの数が増加しても対応できる十分なCPUコアがあることを確認してください。
ユーザー定義トラックに基づくパラレル・レプリケーション(ReplicationApplyOrdering = 1 and ReplicationParallelism > = 2)を構成していて、制約違反または列検索障害などの永続エラーが受信側で表示される場合、考えられる原因を次に示します。
アプリケーション定義の依存性が正しくない
同一のキーまたは制約関係にある表のキーに対する捜査が、異なるトラックに書き込まれている。
一般接続属性ReplicationTrackの値を確認してください。接続で実行されるすべてのトランザクションは、ReplicationTrack属性設定で定義されるトラックに割り当てられます。トラックのワークロードが適切であることを確認してください。ALTER SESSION文を使用して、レプリケーション・トラックを変更します。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER SESSIONに関する項を参照してください。パラレル・レプリケーションの構成の詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のパラレル・レプリケーションの構成に関する項を参照してください。
