変更をデプロイするために単一のスクリプトが必要になることは珍しいことではありません。重要なのは、このようなスクリプトは、任意のレベルのシステム権限を持っている必要があるため、パワーユーザーが実行する必要があるということです。これは通常、DBAアカウント、できればアプリケーションアカウントを意味しますが、それ以外の場合はSYSTEMまたはSYSを意味します。
したがって、必要なスクリプトは次のようになります。
grant select on user_a.t23 to user_b
/
grant select on user_a.t42 to user_b
/
create view user_b.v_69 as
select t23.col1, t42.col2
from user_a.t42
join user_a.t23
on (t42.id = t23.id)
/
grant select on user_b.v_69 to user_c
/
一般的なシナリオは、さまざまなユーザーが実行するように作成された一連の個別のスクリプトがありますが、これらを1つの展開にまとめる必要がある場合です。元のスクリプトにはスキーマ名が含まれておらず、スクリプトにそれらをハードコーディングしたくない理由はたくさんあります。
そのマスタースクリプトを作成する1つの方法は、CHANGECURRENT_SCHEMA構文を使用することです。
alter session set current_schema=USER_A
/
@run_grants_to_userb.sql
alter session set current_schema=USER_B
/
@create_view69.sql
@run_grants_to_userc.sql
マスタースクリプトを実行するには、DBAユーザーが必要です。現在のスキーマを切り替える利点の1つは、データベースリンクなどのオブジェクトをデプロイできることです。このオブジェクトは、構文の癖によって、宣言にスキーマ名を含めることができません。 1つの落とし穴は、ユーザーが変更されないことです。そのため、USER疑似列を使用するスクリプトは、望ましくない結果を生成する可能性があります。