6

Oracle のデータベース変更通知機能は、行の挿入、更新、および削除時に行 ID (物理行アドレス) を送信します。オラクルのドキュメントに示されているように、アプリケーションはこの機能を使用して中間層キャッシュを構築できます。しかし、行 ID がどのように機能するかを詳しく見てみると、これは矛盾しているように見えます。

ROWID (物理行アドレス) は、この stackoverflow スレッドで示されているように、さまざまなデータベース操作が実行されると変更される可能性があります。これに加えて、このスレッドでトムが言及しているように、クラスター化されたテーブルは同じ行 ID を持つことができます。

上記の調査に基づいて、データベース変更通知中に送信されたROWIDをアプリケーションキャッシュのキーとして使用するのは安全ではないようですよね? これは、アプリケーション サーバー キャッシュを構築するためにデータベース変更通知機能を使用する必要があるかどうかについても疑問を投げかけます。または、キャッシュされたオブジェクトのテーブルで行 ID が変更される操作が行われたときに、すべてのアプリケーション サーバー クラスタを再起動する (キャッシュをリロード/リフレッシュする) ように推奨されていますか? それは本番環境で行うのに適した仮定でしょうか?

4

1 に答える 1

5

ROWID を変更する可能性のある操作はどれも、アプリケーションの実行中に実稼働環境で実行される操作ではないように思えます。さらに、トランザクション全体で ROWID を使用する多くの生産的なソフトウェアを見てきました (通常は数秒または数分)。ROWID が変更された場合、そのソフトウェアはキャッシュの前に失敗する可能性があります。したがって、変更通知に基づいてデータベース キャッシュを作成することは、私には理にかなっているように思えます。ROWID に関する小さな免責事項を提供するだけです。

唯一のやや問題のある操作は、別のパーティションへの移動を引き起こす更新です。しかし、少なくとも定期的に発生した場合は、パーティショニングの目的が無効になるため、これはめったに発生しません。特定のデータベース スキーマの設計者は、そのような操作が発生する可能性があり、キャッシュに関連するかどうかを判断できます。どのテーブルもENABLE ROW MOVEMENT設定されていない場合は、デザイナーに尋ねる必要さえありません。

ROWID の重複について: ROWID はグローバルに一意ではなく、テーブル内で一意です。また、変更通知で ROWID とテーブル名の両方が提供されます。したがって、ROWID とテーブル名のタプルは、信頼できるキャッシュを構築するための完全な一意のキーです。

于 2011-09-18T13:39:10.457 に答える