この章の次の項は、データベースをレプリケートする時に発生する可能性があるいくつかの問題の解決方法について説明します。
この項では、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オペレーション・ガイド』のOracle TimesTen Data Managerデーモンの処理に関する説明を参照して、TimesTenデーモンを起動します。 |
データベースがレプリケーション・スキームに入っていない | レプリケーション・スキームに関連していないデータベースのレプリケーション・エージェントを起動しようとしても失敗します。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つしかない単純なレプリケーション・スキームの出力は、例5-1のようになります。
TimesTenデーモンが稼働していても、レプリケーション・エージェントが稼働していない場合、出力は例5-2に示すようになります。この場合、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のレプリケーション・エージェントの起動と停止に関する説明に従ってレプリケーション・エージェントを起動します。
TimesTenデーモンとレプリケーション・エージェントがどちらも稼働していない場合、出力は例5-3に示すようになります。この場合、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のTimesTenのインストールに関する説明に記載されたとおりに、TimesTen が正しくインストールされていて、データマネージャ・サービスが起動しているか確認します。
例5-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
例5-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
データベースにレプリケートされる場合、出力は次のようになります。
例5-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
にリセットします。
例5-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」の下に表示されている表の名前が正しいかどうか。正しくない場合は、レプリケーション・スキーム構成ファイルで表名を修正します。
例5-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
表で、レプリケーションによってレプリケーション・スキームがローカル・データベースに関連付けられていることを確認します。
例5-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レプリケーション・ガイド』のホストIPアドレスの構成に関する説明を参照してください。
レプリケーション・スキームのホスト名とローカル・マシンのホスト名が一致していることを確認するには、次のタスクを実行するようにアプリケーションを作成します。
『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の、レプリケーション・スキームの表要件および制限に関する説明およびレプリケーション・スキームおよびレプリケートされたオブジェクトの所有者に関する説明に記載されているように、レプリケーション・スキームおよびレプリケートされた表の所有者名は関連するすべてデータベース全体で一貫している必要があります。
レプリケーション・スキームに割り当てられている所有者名は、ttIsql
repschemes
コマンドをコールするか、TTREP.REPLICATIONS
表の内容をリストして確認します。
例5-8は、SYSTEM1
とSYSTEM2
の両方で、レプリケーション・スキーム名REPSCHEME
がデータベースに一貫した所有者名(REPL
)を持つことを示しています。例5-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 |
マスター・データベースとサブスクライバ・データベースの両方で、レプリケーション表は完全に同じである必要があります。
例5-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開発者および管理者ガイド』の戻りサービス・トランザクションの状態の確認に関する説明を参照してください。
この項では、レプリケーションのパフォーマンスに影響する可能性がある問題について説明します。ログ・バッファが小さすぎたり、ディスク上のトランザクション・ログ・ファイルから読み取ると、レプリケーションと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開発者および管理者ガイド』のデータ・ストア要素の送信永続性の設定に関する説明を参照してください。
また、レプリケーション・スキームで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
例5-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秒毎に表示されます。
例5-14の出力では、日付に続いて、サブスクライバやそのホストなどの名前が表示されます。次に、待機時間、レートの情報、およびこのサブスクライバに代わって保持されているトランザクション・ログの数が表示されます。各値の具体的な意味は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のttRepAdminを使用したサブスクライバ状態の表示に関する項に説明されています。ここで特に注目するのは、'Last Msg Sent'および'Logs'値です。Last Msg Sentの値は、最終メッセージがマスターによってサブスクライバに送信されてからの経過時間を示し、Logsの値は、ライターが使用する現在のログ挿入ポイント(Last written LSN)以降で、レプリケーション・ログ・リーダーより遅れているログ・ファイル数を示します。
例5-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との差異は、サブスクライバに送信されていないトランザクション・ログのレコード数を示します。これらの値の差異が一定間隔で増加する場合は、レプリケーションの待機時間が増え、ログ・ファイルの読取りが発生する可能性があることを示します。
例5-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アドレスが含まれている必要があります。
ttRepAdmin -duplicate
の使用時に起きる問題の原因として次の2つが考えられます。
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;
例5-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
句のタイムスタンプ列に正しい名前が指定され、それが指定した表にあることを確認します。
また、タイムスタンプ列が主キーまたは索引の一部でないことを確認します。
レプリケーションをCHECK CONFLICTS
に構成している場合、TimesTenはローカル・ホストにレポートを送信します。レポート・ファイルを構成することもできます。『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップを使用した診断に関する説明を参照してください。
短期間に多数の競合が発生すると、レポートの要件によってサブスクライバのパフォーマンスが低下する可能性があります。CREATE REPLICATION
文またはALTER REPLICATION
文にストア属性を使用して、競合の頻度が指定した値に達した場合に競合レポートを一時停止したり、再開することができます。
CONFLICT REPORTING SUSPEND AT
頻度
CONFLICT REPORTING RESUME AT
頻度
レポートの一時停止中に発生した競合についての情報は取得できません。
『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の競合のレポートに関する説明を参照してください。