1. レプリケーション・ガイド
  2. レプリケーション競合の解消
  3. 競合のレポート

競合のレポート

TimesTenの競合検出では、判読可能なプレーン・テキスト・ファイル、またはユーザー・アプリケーションで使用されるXMLファイルに競合がレポートされるように構成できます。

この項の内容は次のとおりです。

テキスト・ファイルへの競合のレポート

判読可能なテキスト・ファイルに競合がレポートされるようにレプリケーションを構成できます(これがデフォルト)。

CHECK CONFLICTS BY ROW TIMESTAMP
  COLUMN ColumnName
  ...
  REPORT TO 'FileName' FORMAT STANDARD

各競合について記述するレポート・ファイルFileNameにエントリが追加されます。標準のレポート形式がデフォルトのため、FORMAT STANDARDという語はオプション(省略可能)です。

障害が発生した各処理は、ヘッダーで始まるエントリの後に、競合している処理に固有の情報が続く構成でレポートにロギングされています。レポート内の各エントリは、多数の空白行で区切られています。

ヘッダーには次の情報が含まれています:

  • 競合が検出された時間。

  • 競合する更新を送受信したデータベース。

  • 競合が発生した表。

ヘッダーの書式は次のとおりです。

Conflict detected at time on date
Datastore : subscriber_database
Transmitting name : master_database
Table : username.tablename

たとえば:

Conflict detected at 20:08:37 on 05-17-2004
Datastore : /tmp/subscriberds
Transmitting name : MASTERDS
Table : USER1.T1

ヘッダーの後には、競合に固有の情報が続きます。データ値はASCII形式で表示されます。バイナリ・データは表示前に16進形式に変換され、浮動小数点値が適切な精度およびスケールで表示されます。

競合レポート・ファイルの詳細は、「一意競合のレポート」、「更新競合のレポート」および「削除/更新競合のレポート」を参照してください。

XMLファイルへの競合のレポート

XMLファイルに競合がレポートされるようにレプリケーションを構成できます。

CHECK CONFLICTS BY ROW TIMESTAMP
  COLUMN ColumnName
  ...
  REPORT TO 'FileName' FORMAT XML

レプリケーションでは、基本ファイル名FileNameを使用して2つのファイルが作成されます。FileName.xmlはヘッダー・ファイルで、競合レポート構造のXML Document Type Definitionおよび<ttrepconflictreport>として定義されたルート要素を含んでいます。ルート要素の内部には、ファイルFileName.includeをインクルードするためのXMLディレクティブが存在し、すべての競合がこのファイルに書き込まれます。各競合は、<conflict>タイプの一要素として書き込まれます。

競合レポート・ファイルのXML要素の詳細は、「競合レポートのXML Document Type Definition」を参照してください。

ノート:

XML競合レポート・ファイルでログ・メンテナンスを実行する場合は、ファイルFileName.includeのみを切り捨てるか、または移動する必要があります。競合レポートを継続して正常に機能させるには、ファイルFileName.xmlは変更せずにそのままの状態にしておく必要があります。

一意競合のレポート

競合が原因でレプリケート対象の挿入が失敗した場合、一意競合レコードが発行されます。

レポート・ファイルの一意競合レコードには、次の情報が含まれます。

  • 既存のタプル(競合しているタプルの競合相手)のタイムスタンプおよび値。

  • 競合している挿入タプル(失敗した挿入のタプル)のタイムスタンプおよび値。

  • レコードの識別に使用されたキー列値。

  • 競合の検出時に行った処理(単一行挿入またはトランザクション全体の破棄)。

    ノート:

    トランザクションが破棄された場合は、トランザクション全体の内容がレポート・ファイルに記録されます。

一意競合レコードの書式は、次のとおりです。

Conflicting insert tuple timestamp : <timestamp in binary format>
Existing tuple timestamp : <timestamp in binary format>
The existing tuple :
<<column value> [,<column value>. ..]>
The conflicting tuple :
<<column value> [,<column value> ...]>
The key columns for the tuple:
<<key column name> : <key column value>>
Transaction containing this insert skipped
Failed transaction:
Insert into table <user>.<table> <<columnvalue> [,<columnvalue>...]>
End of failed transaction

この例に、主キー値2で識別される行に対する一意競合の出力を示します。subscriberdsからレプリケートされた古い挿入がmasterds内の新しい挿入と競合しているため、レプリケート対象の挿入は破棄されます。 

Conflict detected at 13:36:00 on 03-25-2002
Datastore : /tmp/masterds
Transmitting name : SUBSCRIBERDS
Table : TAB
Conflicting insert tuple timestamp : 3C9F983D00031128
Existing tuple timestamp : 3C9F983E000251C0
The existing tuple :
< 2, 2, 3C9F983E000251C0>
The conflicting tuple :
< 2, 100, 3C9F983D00031128>
The key columns for the tuple:
<COL1 : 2>
Transaction containing this insert skipped
Failed transaction:
Insert into table TAB < 2, 100, 3C9F983D00031128>
End of failed transaction

更新競合のレポート

競合が原因でレプリケート対象の更新が失敗した場合、更新競合レコードが発行されます。

このレコードでは、次の情報がレポートされます:

  • 既存のタプル(競合しているタプルの競合相手)のタイムスタンプおよび値。

  • 競合している更新タプル(失敗した更新のタプル)のタイムスタンプおよび値。

  • 古い値。この値は、競合しているタプルの元の値(更新に失敗する前の値)です。

  • レコードの識別に使用されたキー列値。

  • 競合の検出時に行った処理(単一行更新またはトランザクション全体の破棄)。

    ノート:

    トランザクションが破棄された場合は、トランザクション全体の内容がレポート・ファイルに記録されます。

更新競合レコードの書式は、次のとおりです。

Conflicting update tuple timestamp : <timestamp in binary format>
Existing tuple timestamp : <timestamp in binary format>
The existing tuple :
<<column value> [,<column value>. ..]>
The conflicting update tuple :
TSTAMP :<timestamp> :<<column value> [,<column value>. ..]>
The old values in the conflicting update:
TSTAMP :<timestamp> :<<column value> [,<column value>. ..]>
The key columns for the tuple:
<<key column name> : <key column value>>
Transaction containing this update skipped
Failed transaction:
Update table <user>.<table> with keys:
<<key column name> : <key column value>>
New tuple value:
<TSTAMP :<timestamp> :<<column value> [,<column value>. ..]>
End of failed transaction

次の例に、主キー値6で識別される行のcol2値に対する更新競合の出力を示します。masterdsデータベースからレプリケートされた古い更新がsubscriberds内の新しい更新と競合しているため、レプリケート対象の更新は破棄されます。 

Conflict detected at 15:03:18 on 03-25-2002
Datastore : /tmp/subscriberds
Transmitting name : MASTERDS
Table : TAB
Conflicting update tuple timestamp : 3C9FACB6000612B0
Existing tuple timestamp : 3C9FACB600085CA0
The existing tuple :
< 6, 99, 3C9FACB600085CA0>
The conflicting update tuple :
<TSTAMP :3C9FACB6000612B0, COL2 : 50>
The old values in the conflicting update:
<TSTAMP :3C9FAC85000E01F0, COL2 : 2>
The key columns for the tuple:
<COL1 : 6>
Transaction containing this update skipped
Failed transaction:
Update table TAB with keys:
<COL1 : 6>
New tuple value: <TSTAMP :3C9FACB6000612B0, COL2 : 50>
End of failed transaction

削除/更新競合のレポート

最近削除された行に対して更新を行おうとすると、削除/更新競合レコードが発行されます。

このレコードでは、次の情報がレポートされます:

  • 競合している更新タプルまたは競合している削除タプル(失敗した方のタプル)のタイムスタンプおよび値。

  • 削除タプルが失敗した場合、レポートには既存のタプル(削除タプルと競合していたが、その競合の影響を受けなかった更新タプル)のタイムスタンプおよび値も含まれます。

  • レコードの識別に使用されたキー列値。

  • 競合の検出時に行った処理(単一行更新またはトランザクション全体の破棄)。

    ノート:

    トランザクションが破棄された場合は、トランザクション全体の内容がレポート・ファイルに記録されます。TimesTenでは、削除/挿入競合は検出できません。

失敗した更新との削除競合を示すレコードの書式は、次のとおりです。

Conflicting update tuple timestamp : <timestamp in binary format>
The conflicting update tuple :
TSTAMP :<timestamp> :<<column value> [,<column value>. ..]>
This transaction skipped
The tuple does not exist
Transaction containing this update skipped
Update table <user>.<table> with keys:
<<key column name> : <key column value>>
New tuple value:
<TSTAMP :<timestamp> :<<column value> [,<column value>. ..]>
End of failed transaction

次の例に、最近削除された行に対する更新で発生した削除/更新競合の出力を示します。更新する行がないため、SUBSCRIBERDSからの更新は破棄されます。 

Conflict detected at 15:27:05 on 03-25-2002
Datastore : /tmp/masterds
Transmitting name : SUBSCRIBERDS
Table : TAB
Conflicting update tuple timestamp : 3C9FB2460000AFC8
The conflicting update tuple :
<TSTAMP :3C9FB2460000AFC8, COL2 : 99>
The tuple does not exist
Transaction containing this update skipped
Failed transaction:
Update table TAB with keys:
<COL1 : 2>
New tuple value: <TSTAMP :3C9FB2460000AFC8,
COL2 : 99>
End of failed transaction

失敗した削除との更新競合を示すレコードの書式は、次のとおりです。

Conflicting binary delete tuple timestamp : <timestamp in binary format>
Existing binary tuple timestamp : <timestamp in binary format>
The existing tuple :
<<column value> [,<column value>. ..]>
The key columns for the tuple:
<<key column name> : <key column value>>
Transaction containing this delete skipped
Failed transaction:
Delete table <user>.<table> with keys:
<<key column name> : <key column value>>
End of failed transaction

次の例に、最近更新された行に対する削除で発生した削除/更新競合の出力を示します。削除より後に更新された行があるため、masterdsからの削除は破棄されます。 

Conflict detected at 15:27:20 on 03-25-2002
Datastore : /tmp/subscriberds
Transmitting name : MASTERDS
Table : TAB
Conflicting binary delete tuple timestamp : 3C9FB258000708C8
Existing binary tuple timestamp : 3C9FB25800086858
The existing tuple :
< 147, 99, 3C9FB25800086858>
The key columns for the tuple:
<COL1 : 147>
Transaction containing this delete skipped
Failed transaction:
Delete table TAB with keys:
<COL1 : 147>

競合のレポートの一時停止と再開

レプリケーションの競合がホストに悪影響を与えることを避けるために、1秒当たりの競合数がユーザーが指定するしきい値を超えたときに競合のレポートを一時停止するようにレプリケーションを構成できます。また、1秒当たりの競合数がユーザーが指定するしきい値を下回ったときに競合のレポートを再開するように構成することもできます。

アプリケーションが正しく動作している場合は、レプリケーションで競合が発生してレポートされることは通常ほとんどありません。ただし、負荷が高い場合に、短時間で競合が一時的に発生することがあり、特にアプリケーションの開発中は、そのようなエラーが発生する可能性があります。この場合、競合レポート・ファイルへの過度の書込み操作が原因で、ホストのパフォーマンスに悪影響を与える可能性があります。

競合レポートを1秒当たりの競合数に基づいて一時停止および再開するように構成するには、レプリケーション・スキームのSTORE句に対してCONFLICT REPORTING SUSPEND ATおよびCONFLICT REPORTING RESUME AT属性を使用します。

競合のレポートが一時停止しているときにレプリケーション・エージェントが停止した場合、そのレプリケーション・エージェントが再起動すると競合のレポートも有効になります。レプリケーション・エージェントがアクティブな状態でCONFLICT REPORTING RESUME ATを0に設定した場合、レプリケーション・エージェントが再起動されるまでレポートは再開されません。

次の例に、1秒当たりの競合数が20を超えたときに競合レポートを一時停止し、競合数が10未満に下がったときに再開するレプリケーション・スキームの構成を示します。

CREATE REPLICATION r1
ELEMENT elem_accounts_1 TABLE accounts
      CHECK CONFLICTS BY ROW TIMESTAMP
        COLUMN tstamp
        UPDATE BY SYSTEM
        ON EXCEPTION ROLLBACK WORK
        REPORT TO 'conflicts' FORMAT XML
  MASTER westds ON "westcoast"
  SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE accounts
      CHECK CONFLICTS BY ROW TIMESTAMP
        COLUMN tstamp
        UPDATE BY SYSTEM
        ON EXCEPTION ROLLBACK WORK
        REPORT TO 'conflicts' FORMAT XML
  MASTER eastds ON "eastcoast"
  SUBSCRIBER westds ON "westcoast"
STORE westds ON "westcoast"
  CONFLICT REPORTING SUSPEND AT 20
  CONFLICT REPORTING RESUME AT 10
STORE eastds ON "eastcoast"
  CONFLICT REPORTING SUSPEND AT 20
  CONFLICT REPORTING RESUME AT 10;