0

Oracle 行レベル セキュリティ (RLS) を使用して一部のレコードを非表示にすると、パフォーマンスへの影響はありますか? SQL クエリの速度が低下しますか? このための Oracle パッケージは、DBMS_RLS です。

いくつかのテーブルに IS_HISTORICAL=T/F を追加する予定です。次に、RLS を使用して、IS_HISTORICAL=T の値を持つレコードを非表示にします。

アプリケーションで使用する SQL クエリは非常に複雑で、内部/外部結合、サブクエリ、相関サブクエリなどがあります。

200 の奇数テーブルのうち、約 50 にこの RLS ポリシー (IS_HISTORICAL=T によってレコードを非表示にする) が適用されます。150 個のテーブルの残りは、これらの 50 個のテーブルの子テーブルであるため、RLS はそれらに暗黙的に適用されます。

ライセンスへの影響はありますか?

ありがとう。

4

1 に答える 1

2

「パフォーマンスへの影響はありますか？SQLクエリの速度が低下しますか？」

パフォーマンスに関連するすべての質問と同様に、答えは「状況によって異なります」です。RLSは、ポリシー関数をWHERE句として適用する外部クエリで制御されたクエリをラップすることによって機能します。

select /*+ rls query */ * from ( 
    select /*+ your query */ ... from t23 
    where whatever = 42 )
where rls_policy.function_t23 = 'true'

したがって、パフォーマンスへの影響は、関数の内容に完全に依存します。

これらを行う通常の方法は、コンテキスト名前空間を使用することです。これらは、SYS_CONTEXT（）関数を介してアクセスされるセッションメモリの事前定義された領域です。そのため、コンテキストから保存された値を取得するコストはごくわずかです。また、通常はセッションごとに1回名前空間にデータを入力するため（たとえば、ログオン後のトリガーまたは同様の接続フックによって）、クエリあたりの全体的なコストはわずかです。名前空間を更新するにはさまざまな方法があり、パフォーマンスに影響を与える可能性がありますが、これらは全体的なスキームでは簡単です（この他の回答を参照してください）。

したがって、パフォーマンスへの影響は、関数が実際に何をするかによって異なります。これにより、実際のポリシーを検討することができます。

「このRLSポリシー（IS_HISTORICAL = Tによってレコードを非表示にするため）」

幸いなことに、このような関数の実行自体にコストがかかる可能性はほとんどありません。悪いニュースは、パフォーマンスがまだTeh Suckである可能性があることです！とにかく、履歴レコードに対するライブレコードの比率が好ましくない場合。おそらく、すべてのレコードを取得してから、履歴レコードを除外することになります。オプティマイザーはRLS述語をメインクエリにプッシュする可能性がありますが、RLSの動作方法が原因で、そうなる可能性は低いと思います。ポリシーの基準を一般的な視線にさらすことを回避します（これにより、RLS操作のデバッグが実際のPITNになります）。

あなたのユーザーはあなたの貧弱な設計決定の代償を払うでしょう。古いレコードを保存し、実際のテーブルにライブデータのみを保持するために、ジャーナルテーブルまたは履歴テーブルを用意することをお勧めします。ライブレコードと一緒に履歴レコードを保持することは、拡張可能なソリューションになることはめったにありません。

「ライセンスへの影響はありますか？」

DBMS_RLSには、EnterpriseEditionライセンスが必要です。

于 2013-02-19T09:18:05.337 に答える