削除ツームストーンの主キー更新の追跡

主キー(PK)の更新を完全にサポートするには、キーの変更前イメージで表される行とキーの変更後イメージで表される行の両方で競合を処理する必要があります。PK更新は自律型の削除および挿入のため、PK更新の競合は、キーの変更前イメージの競合とキー(および行)の変更後イメージの挿入の削除としてサポートされている必要があります。

キーの変更前イメージで表される行の削除としてPK更新をサポートすることは、削除ツームストン表に削除として挿入する必要があることを意味します。PKの更新時にツームストン表に挿入するために、更新内部トリガーが追加されます(実際には、行を識別するキーが追加されます。これは、存在する場合はPK、それ以外の場合はNULL値不可能の列が1つ以上ある指定のUKになります)。PKの更新によって2つの競合が発生する可能性があるため、行レベルで最大2つの解決が試行され、元のPKを持つ行が削除され、新しいPKを持つ行が挿入されます。

例: 最新のタイムスタンプの解決の使用

データベース1: tab1 key1 at ts1に対する更新

データベース2: tab1 key1 set key1 to key2 ts2に対する更新

データベース3: tab1 key2 ts3に対する更新

このシナリオでは、行レベルでkey1を含むtab1の行が削除され、データベース3の更新がtab1の行key2の最終変更になると考えられます。かわりに、データベース2がts3で、データベース3がts3の場合は、データベース2でのPK更新がtab1の行key2の最終変更になります。

ここで、データベース1がts3、データベース2がts2、データベース3がts1の場合について考えてみると、データベース1のtab1の行key1への更新は成功し、データベース2のtab1の行key2からのPK更新は成功します。この時点で、完全な解決策では、変更前イメージの削除と変更後イメージの挿入の両方を別々に解決する必要があると考えられます。これは、その両者が相互に依存することなく、一方の値の損失が両方の損失にならないことを意味します。