無料サンプル問題

マルチテナント環境では、CDB$ROOT で CONTAINER=ALL（または root 接続時の既定）として作る 共通ユーザー（common user）の名前は、COMMON_USER_PREFIX で定義されたプレフィックスで始まらなければならない。 既定値は C## である。

文(1) の hr_admin は C## で始まらないため、共通ユーザーとして作成できず失敗する。 文(2) の c##ops は C##（大文字小文字は不問）で始まるため有効な共通ユーザー名として成功する。

なお、プレフィックス規則が課されるのは共通ユーザーのみ。特定の PDB に接続して CONTAINER=CURRENT で作るローカルユーザーには C## プレフィックスは不要（むしろ付けてはならない）。

PDB をプラグイン（またはクローン/作成）した後、Oracle は互換性チェックを行い、問題があれば PDB_PLUG_IN_VIOLATIONS ビューに記録する。 違反には ERROR（致命的）と WARNING（警告）がある。

WARNING レベルの違反が残っている状態で OPEN すると、PDB は開くものの RESTRICTED モード（RESTRICTED=YES）で開く。これは「管理者に未解決の問題があることを気付かせ、修正させる」ための安全装置である。 一般ユーザーは RESTRICTED SESSION 権限を持たない限り接続できない。

管理者は PDB_PLUG_IN_VIOLATIONS を確認して原因を解消し、いったん CLOSE → 再 OPEN すると、違反が消えていれば RESTRICTED=NO の通常モードで開けるようになる。

BACKUP INCREMENTAL LEVEL 1 は、CUMULATIVE を付けない場合差分（DIFFERENTIAL）が既定である。

• 差分（DIFFERENTIAL・既定）： 直近のレベル0 またはレベル1 のいずれか最も新しいバックアップ以降に変更されたブロックをバックアップする。本問では木曜のレベル1 以降の変更分。
• 累積（CUMULATIVE）： 直近のレベル0以降に変更されたブロックをバックアップする（途中のレベル1 は無視）。リストアは速いがバックアップは大きくなる。

つまり「差分はバックアップが小さくリストアが遅い／累積はバックアップが大きくリストアが速い」というトレードオフ。金曜の差分レベル1 は、最新のレベル1（木曜）以降の変更ブロックだけを取る。

データファイルのリカバリ手順は、それがクリティカル（critical）か否かで分かれる。

• クリティカルなファイル＝ SYSTEM 表領域、および現在アクティブな UNDO 表領域のデータファイル。これらはデータベースが OPEN のままではオフラインにできない。よってリカバリには SHUTDOWN → STARTUP MOUNT でいったん閉じ、MOUNT 状態でリストア＆リカバリし、その後 ALTER DATABASE OPEN する必要がある。
• 非クリティカル（通常のユーザー表領域）のデータファイルは、DB を OPEN のまま当該データファイルだけ OFFLINE にしてオンラインリカバリできる。

本問は SYSTEM 表領域＝クリティカルなので、MOUNT 状態でのリカバリが必要。ARCHIVELOG モードなのでアーカイブREDO を適用して障害直前まで完全リカバリできる。

FLASHBACK TABLE ... TO TIMESTAMP / TO SCN は、UNDO データを使って表の内容を過去の時点へ巻き戻す機能である。 この処理は内部的に行の rowid が変わり得る（行の再配置を伴う）ため、対象表で行移動（row movement）が有効になっている必要がある。

無効のまま実行すると ORA-08189（row movement is not enabled）になる。 したがって ALTER TABLE hr.emp ENABLE ROW MOVEMENT; を実行してから FLASHBACK TABLE ... TO TIMESTAMP を再実行すればよい。

RETENTION GUARANTEE は「失効していない（unexpired）UNDO を UNDO_RETENTION 期間が経過するまで絶対に上書きさせない」設定である。 これにより、長時間の問合せが必要とする読み取り一貫性用の UNDO が確実に保護され、ORA-01555（snapshot too old）を防げる。

そのトレードオフとして、UNDO 領域が逼迫し、かつ保護対象（未失効）の UNDO を上書きできないと、 新しい DML 側が UNDO 領域を確保できず失敗する。固定サイズで AUTOEXTEND OFF なので拡張もできず、 典型的には ORA-30036（UNDO 表領域内でセグメントを拡張できません）になる。 つまり「問合せの一貫性を守る代わりに、領域不足時は DML が犠牲になる」。

Data Pump Import の TABLE_EXISTS_ACTION は、取り込み先に同名の表が既にある場合の動作を制御する。取り得る値は SKIP / APPEND / TRUNCATE / REPLACE の4つ。

既定値は SKIP である（メタデータも含めて取り込む通常モードの場合）。 SKIP は「既存表には手を触れず、その表の取り込みを丸ごとスキップする」。よって既存の EMP はそのまま、ダンプの EMP は取り込まれない。

重要な例外：CONTENT=DATA_ONLY を指定した場合は、SKIP が使えないため既定が APPEND に変わる。 本問は CONTENT 未指定（＝ALL）なので既定は SKIP。

AWR の自動スナップショット採取は STATISTICS_LEVEL に依存する。値は3段階：

• BASIC： 自動統計収集機能の大半（AWR 自動スナップショット、ADDM、各種アドバイザ等）を無効化する。手動でスナップショットは取れても自動採取は止まる。
• TYPICAL（既定）： 一般的に必要な統計を収集。AWR は正常動作。通常はこれを使う。
• ALL： TYPICAL に加え OS 統計・実行計画の行ソース統計など追加情報も収集（オーバーヘッド増）。

したがって BASIC のままだと自動 AWR スナップショットが採取されない。TYPICAL（または ALL）へ戻せばよい。

ALTER TABLE ... SHRINK SPACE は、セグメント内の行を前方に詰め直して空きブロックを解放し、HWM を引き下げる操作である。 行を物理的に移動させる（rowid が変わる）ため、対象表で行移動（row movement）が有効であることが前提となる。 無効だと ORA-10636（ROW MOVEMENT is not enabled）になる。

よって ALTER TABLE hr.bigt ENABLE ROW MOVEMENT; を実行してから SHRINK SPACE を再実行すればよい。 なお SHRINK SPACE は ASSM の表領域でのみ使える（本問は ASSM で前提を満たす）。

システム権限とオブジェクト権限で、再付与した相手への取消の連鎖（cascade）挙動が異なる。

• システム権限（WITH ADMIN OPTION）： 付与者から取り消しても、その付与者が他者へ与えた権限は連鎖して取り消されない（NO CASCADE）。 よって取消(1) で user_a の CREATE TABLE は消えるが、user_b の CREATE TABLE は残る。
• オブジェクト権限（WITH GRANT OPTION）： 付与者から取り消すと、その付与者が GRANT OPTION を使って他者へ与えた権限も連鎖して取り消される（CASCADE）。 よって取消(2) で user_a の SELECT が消えると、user_b の SELECT も連鎖して消える。

この「システム権限は連鎖しない／オブジェクト権限は連鎖する」という非対称が本問の核心。

CREATE PLUGGABLE DATABASE ... FROM <pdb>@<link> RELOCATE は、 PDB を別の CDB へほぼ無停止で移設（relocate）するための構文である。リモートの「ホットクローン」基盤の上に成り立つ。

前提条件（これが満たされないと実行できない）：

• ローカル UNDO モード：ソース PDB がオープン（READ WRITE）のまま移設・クローンするには、CDB がローカル UNDO（local undo）である必要がある。共有 UNDO ではホット（オンライン）操作はできない。
• ソース CDB が ARCHIVELOG モード：オープン中の PDB を一貫した状態でコピーするためにアーカイブ REDO が要る。

挙動の流れ：

• ターゲット CDB2 で CREATE ... RELOCATE を実行すると、SALES は MOUNTED 状態で作成される（まだオープンしていない）。この間、ソース CDB1 側の SALES は READ WRITE のまま稼働を続け、ユーザーは更新できる。
• ターゲットで ALTER PLUGGABLE DATABASE sales OPEN; を実行すると、移設が確定（finalize）する。差分が同期され、ソース側 SALES はクローズされ、リスナーの接続転送によって既存接続が新しい場所へ引き継がれる（ダウンタイム最小）。

アプリケーションコンテナでは、アプリケーションルートでアプリケーションのインストール／アップグレード／パッチを行い（BEGIN INSTALL/UPGRADE/PATCH 〜 END ... で囲む）、 その変更は各アプリケーション PDB で明示的に「同期（SYNC）」して初めて適用される。

同期は各アプリケーション PDB に接続して ALTER PLUGGABLE DATABASE APPLICATION hr_app SYNC; を実行する。 これによりその PDB が、ルートに記録されたアプリケーションの最新バージョン（ここでは 2.0）まで共通オブジェクト定義・シードデータを取り込む。

言い換えると、ルートでの END UPGRADE は「ルート側の正本を更新した」だけであり、各 PDB は SYNC するまで旧バージョンのまま動き続ける（段階的ロールアウトが可能）。

ブロックメディアリカバリ（Block Media Recovery, BMR）は、メディア破損した個々のブロックだけを復旧する機能である （RECOVER ... BLOCK または、登録済み破損を一括処理する RECOVER CORRUPTION LIST）。

核心となる性質：

• 粒度がブロック単位：データファイル全体を復旧する必要がない。破損ブロック以外は触らない。
• オンラインのまま：対象データファイルも DB もオフラインにせず、復旧中も正常ブロックにはアクセスできる（可用性が高い）。
• ARCHIVELOG が前提：破損ブロックの過去イメージを古いバックアップから取り出し、アーカイブ REDO を適用して現在時点まで追いつかせる。よって NOARCHIVELOG では成立しない。
• 増分バックアップは使えない：BMR でブロックの基となるイメージに使えるのは全体/レベル0 バックアップ・イメージコピー・（あれば）フラッシュバックログ等であり、レベル1 増分バックアップは BMR には使用できない。

「増分更新イメージコピー」は、1本のイメージコピーを増分で“育てて”最新に保つ定番戦略である。2つのコマンドが対になっている。

• BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'inc_upd' DATABASE;
  … タグ inc_upd のイメージコピーを更新するためのレベル1 増分を取得する。
• RECOVER COPY OF DATABASE WITH TAG 'inc_upd';
  … 取得済みのレベル1 増分をイメージコピー（バックアップ側）に適用してロールフォワードし、コピーをより新しい時点へ進める。本番データベースは一切変更しない（適用先はあくまでバックアップのコピー）。

結果として、常に「ほぼ最新のフル相当イメージコピー」が手元にある状態を維持できる。障害時は そのイメージコピーへ SWITCH（コピーをそのまま現用ファイルにする）か、リストアして少量のアーカイブ REDO を適用するだけで済むため、リストア／リカバリが高速になる。毎日フルバックアップを取り直すコストも避けられる。

なお初回実行時は適用すべき増分もイメージコピーもまだ無いため、RECOVER COPY は実質何もせず、BACKUP INCREMENTAL LEVEL 1 ... はベースとなるレベル0 のイメージコピーを生成する（以後の実行で増分が積まれ、ロールフォワードが効き始める）。

保証付きリストアポイント（guaranteed restore point）は、その時点へ FLASHBACK DATABASE で戻せることを保証する仕組みである。 通常の Flashback Database（FLASHBACK ON による継続的なフラッシュバックログ収集）を有効にしていなくても、 保証付きリストアポイントを作ると、その時点へ戻すのに必要なフラッシュバックログが確実に保持される。

前提条件：

• DB が ARCHIVELOG モード。
• 高速リカバリ領域（FRA）が構成済み（フラッシュバックログの保存先）。

移行に失敗したら SHUTDOWN → STARTUP MOUNT → FLASHBACK DATABASE TO RESTORE POINT before_migration; → ALTER DATABASE OPEN RESETLOGS; で当該時点へ戻せる。 作業が成功して不要になったら DROP RESTORE POINT before_migration; で保証を解除すると、保持されていたフラッシュバックログが解放される （保持し続けると FRA を圧迫し得る点には注意）。

統合監査では、監査は2段構えになっている。

• ① ポリシーの定義： CREATE AUDIT POLICY <名> ACTIONS ...; で「何を監査するか」を定義する。これは定義しただけで、まだ監査は始まらない。
• ② ポリシーの有効化： AUDIT POLICY <名> [BY <user> | WHENEVER ...]; を実行して有効化して初めて、以後の該当操作が UNIFIED_AUDIT_TRAIL に記録される。

本問はポリシーを CREATE しただけで AUDIT POLICY emp_dml_pol; を実行していないため、UPDATE しても記録されない。 AUDIT POLICY emp_dml_pol; を実行すれば（以降の操作から）記録される。

補足：純粋統合監査（pure unified auditing）モードでは、旧来の AUDIT_TRAIL 初期化パラメータは無視される（監査の有効/出力先は統合監査の仕組みが制御）。

Resource Manager の CPU 配分（management）ディレクティブ MGMT_Pn は、CPU が飽和して取り合いになったときに、誰に何%ずつ配るかを決めるものである。 言い換えると競合時にだけ効く比率であり、CPU に余裕があるときは抑制しない。

したがって CPU に空きがある時間帯に REPORTS だけが走っているなら、競合が無いので 25% という比率は作用せず、必要なだけ CPU を使える（100% 近くまで）。

「空いていても絶対に 25%（あるいは指定%）を超えさせたくない」＝ハードキャップが欲しい場合は、配分ディレクティブではなく UTILIZATION_LIMIT（MAX_UTILIZATION_LIMIT）を設定する。これは CPU に空きがあっても絶対上限として頭を抑える。

この「配分（competition 時のみ） vs 絶対上限（常時キャップ）」の違いが本問の核心。

ヒープ表の移動には2つのモードがある。

• オフライン移動 ALTER TABLE ... MOVE（案1）： 移動中は表に排他ロックがかかり、DML がブロックされる。さらに移動で rowid が変わるため、移動後は表の索引が UNUSABLE になり、索引を再構築（ALTER INDEX ... REBUILD）するか UPDATE INDEXES 句を併用する必要がある。
• オンライン移動 ALTER TABLE ... MOVE ONLINE（案2）： 移動中もDML（INSERT/UPDATE/DELETE）を許可し、索引も自動的に保守される（移動後に UNUSABLE にならず、別途再構築は不要）。24時間稼働の無停止移動にはこちらが適する。

本問は「無停止で移したい」ので案2（MOVE ONLINE）が適切。

保留統計（pending statistics）は、収集した統計を即座に全体公開せず、“保留”として隔離しておき、検証してから公開する仕組みである。

• DBMS_STATS.SET_TABLE_PREFS(...,'PUBLISH','FALSE') を設定した表では、以後の GATHER_..._STATS の結果は公開されず保留になる（DBA_TAB_PENDING_STATS 等で確認可）。通常セッションは引き続き従来の公開済み統計を使うので、計画は変わらない。
• 保留統計を使って計画を確かめたいセッションだけ ALTER SESSION SET OPTIMIZER_USE_PENDING_STATISTICS = TRUE; を実行する。そのセッションに限りオプティマイザが保留統計を採用する。
• 検証して問題なければ EXEC DBMS_STATS.PUBLISH_PENDING_STATS('HR','ORDERS'); で公開（全体へ反映）。ダメなら DBMS_STATS.DELETE_PENDING_STATS で破棄。

これにより「新統計で計画が劣化しないか」を本番影響なしに先行検証できる。

SQL Plan Management（SPM）／SQL Plan Baseline の目的は実行計画の安定性である。 「コストが低いから」という理由だけで計画を勝手に乗り換えて性能が突然劣化する（plan regression）のを防ぐ。

ベースラインを持つ SQL の挙動（OPTIMIZER_USE_SQL_PLAN_BASELINES=TRUE）：

• オプティマイザはベースライン内の「承認済み（accepted）かつ有効・再現可能」な計画のうち最小コストのものを選んで使う。
• 今回見つかった新しい低コスト計画は、ベースラインに無い計画なのでそのまま採用されない。代わりに未承認（non-accepted）としてプラン履歴に記録される。
• その新計画を使えるようにするには、DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE（または自動 SPM 進化タスク）で「本当にベースラインより速いか」を検証し、合格すれば承認（accept）してベースラインに昇格させる。

つまり「低コスト＝即採用」ではなく、承認（accept）されて初めて使われるのが SPM の肝。