実行中のセッションのセッションパラメータ値のクエリ

これを行う方法はないと思いますが、実行中のセッションが現在COMMIT_WRITEセッションパラメータに対してどのような値を持っているかを照会できるようにしたいと思います。

私はv $パフォーマンスビューで何も見ていません...そのような値を取得できるSYS x $ビューを知っている人はいますか？

明確化-現在のセッションとは関係なく実行されている別のセッションのパラメーター設定をプルする必要があります。

oracle

この質問は1年以上前のものですが、私のように誰かがここでつまずく場合は、V $ SES_OPTIMIZER_ENVをクエリできます。

SYS> select name, value 
        from  V$SES_OPTIMIZER_ENV 
        where sid=54 
           and name='hash_area_size';

NAME                                     VALUE
—————————————- ————————-
hash_area_size                           100000

ソース：http : //oracleinaction.com/other-session-params/

— Rph
ソース

はい、これを確認する方法があります。

次のSQLでV $ PARAMETERをクエリできます。

SELECT name, value
  FROM v$parameter
 WHERE name like 'commit_write'
;

NAME                 VALUE
-------------------- --------------------
commit_write         (null)

その後、セッションごとにパラメーターを変更します。

ALTER SESSION SET commit_write = 'IMMEDIATE';

そして、v $ parameterをもう一度クエリします。

SELECT name, value
  FROM v$parameter
 WHERE name like 'commit_write'
;

NAME                 VALUE
-------------------- --------------------
commit_write         IMMEDIATE

— ora-600
ソース

元の質問に説明を追加する-課題は、このv $ parameter値が別のセッションで何であるかを見つけることです。

— KevinKirkpatrick

おそらく、oradebugコマンドを使用して、変更されたパラメータ値をダンプできます。別のセッションのオプティマイザに関連しないパラメータは、gv $またはx $からは見えないと思います。時々それらはセッションUGAに保存され、公開されません。好奇心が強い人は知りたいのですが、なぜこれが必要なのですか？

— Raj

ログオントリガーがそのセッションのcommit_writeパラメータを適切に設定していること（および、ALTER SYSTEMを変更してもcommit_writeパラメータがそのセッションで変更されないこと）の健全性を確認したいのですが、 "実行中のセッションのパラメーターを「ピーク」にする方法があります。重要ではありません-うまくいかない場合はすぐにわかります（うまくいくようです）が、直接確認する簡単な方法があるかどうかを確認したいと考えていました。

— KevinKirkpatrick

別のセッションの価値を得ることができるとは思いません。ただし、通常はその値を1日に2回変更しないので、他のセッションには構成済みのシステム値が必要です。値がセッションごとに変更されるかどうかを知りたい場合は、そのセッションをトレースする必要があります。ログオン直後は、セッションベースの値がシステム全体の値と同じであるため、ログオントリガーはあまり役に立ちません。

— ora-600

「ALTER SYSTEMを変更しても、commit_writeパラメータがそのセッションで変更されないことを確認してください）」。もちろん、変更したくないユーザーから「ALTER SESSION」または「ALTER SYSTEM」を取り消さない限り、これを強制することは不可能です。ALTER SYSTEMがDBA以外のユーザーに付与されていないことを願っています。ALTER SESSIONの取り消しはおそらく簡単です。システムレベルでcommit_writeを設定しますが、その場合はベンダーコードの要件を考慮する必要があります。また、ALTER SESSIONは、ALTER SYSTEMの後に行われた場合、ALTER SYSTEM設定をセッションレベルでオーバーライドします。したがって、その特権を安全なものにするために取り消します。

— Raj