ORACLE Master Gold 無料サンプル

マルチテナント環境では、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 なら PDB は通常どおり（RESTRICTED=NO）開き、ERROR なら開くものの RESTRICTED モードへ降格する。この対比がこの設問の論点である。

ERROR レベルの違反が残っている状態で OPEN すると、OPEN 自体は成功して Warning: PDB altered with errors. が表示され、PDB は RESTRICTED モード（RESTRICTED=YES）で開く。これは「管理者に未解決の問題があることを気付かせ、修正させる」ための安全装置である。 一般ユーザーは RESTRICTED SESSION 権限を持たない限り接続できない。 一方 WARNING レベルの違反はアラートログに記録されるだけで、PDB の OPEN は通常どおり成功し RESTRICTED=NO のままである。

管理者は 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 が犠牲になる」。

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 の肝。

ALTER SESSION SET CONTAINER = <pdb> は、いま張っている接続（セッション）を切らずに、カレントコンテナだけを対象 PDB へ切り替える文である。 新しい接続を張り直したり、再認証（パスワード再入力）したりする必要はない。接続プールが多数の PDB を効率よく捌くための中核機能である。

実行できるのは、対象コンテナへの SET CONTAINER システム権限を持つユーザー（典型的には共通ユーザー）である。 CDB$ROOT ⇄ 各 PDB のどちらの向きにも切り替えられ、ALTER SESSION SET CONTAINER = CDB$ROOT; でルートへ戻せる。

切り替え後は、その PDB がカレントとなり、以後の SQL はその PDB のスキーマ/オブジェクトを対象に解決される。物理接続は一つのまま維持される。

PDB ポイントインタイムリカバリ（PDB PITR）は、対象 PDB だけを過去の時点へ巻き戻す。CDB 全体を止める必要はなく、 他の PDB と CDB$ROOT はオンラインのまま影響を受けないのが最大の利点である。

手順は、対象 PDB をクローズ（MOUNTED 相当）にして RECOVER PLUGGABLE DATABASE ... UNTIL TIME/SCN で不完全リカバリし、 ALTER PLUGGABLE DATABASE ... OPEN RESETLOGS で開く。ローカル UNDOだと補助（auxiliary）インスタンスを別途用意せずに済み、PDB PITR がすっきり行える （共有 UNDO では補助インスタンスが必要になる）。ARCHIVELOG が前提。

巻き戻すのは対象 PDB のデータのみ。CDB 全体を UNTIL TIME で戻すわけではないので、他業務は継続できる。

保存方針（retention policy）は「どのバックアップを保持すべきか（＝保持しなくてよいか）」を定義する。方式は2つ。

• リカバリウィンドウ（RECOVERY WINDOW OF n DAYS）： 過去 n 日以内の任意時点へ復旧できるだけの一連のバックアップ＋アーカイブを保持する。
• 冗長性（REDUNDANCY n）： 各ファイルについて最新 n 世代のバックアップを保持する。

OBSOLETE（不要）とは、この保存方針を満たすうえでもう必要ないバックアップを指す。REPORT OBSOLETE はその一覧を表示するだけで、 DELETE OBSOLETE が実際に削除（＋カタログから登録解除）する。

重要：保存方針を満たしていても、RMAN が自動で勝手に消すわけではない（FRA の空き圧迫時に FRA 内ファイルが再利用対象になる挙動は別）。基本は DELETE OBSOLETE を明示実行して整理する。

CROSSCHECK は、RMAN リポジトリの登録内容と実際のメディア（ディスク/テープ）上のファイルの有無を突き合わせる。 リポジトリに載っているのに実体が見つからないバックアップは、状態が EXPIRED にマークされる（＝物理的に消えている）。

DELETE EXPIRED は、その EXPIRED とマークされたリポジトリの登録（メタデータ）だけを削除する。実体はすでに無いので、消すのはカタログ側の記録である。 これで「登録はあるが実体は無い」という食い違いが解消する。

対比：DELETE OBSOLETE は「保存方針上もう不要」なバックアップを実体ごと削除する。EXPIRED（実体が消えている）と OBSOLETE（保存方針上不要）は別軸である。

CONTROLFILE AUTOBACKUP ON にすると、RMAN はバックアップ実行後や、DB の物理構造変更後に、 制御ファイルと SPFILE を自動的にバックアップする。自動バックアップは既定のフォーマットで格納され、DBID から探し出せる。

これが効くのは、制御ファイルも SPFILE も失われ、リポジトリ情報が手元に無い最悪ケースである。 RESTORE SPFILE FROM AUTOBACKUP; / RESTORE CONTROLFILE FROM AUTOBACKUP; により、カタログ無しでも起点を復元でき、そこからデータベース全体のリストアに進める。

カタログ運用でも有用だが、カタログを使わない（制御ファイルのみ）運用では特に重要。制御ファイルが飛ぶとバックアップ情報ごと失うため、自動バックアップが復旧の生命線になる。

SELECT ... AS OF TIMESTAMP/SCN（Flashback Query）は、UNDO データを使って、指定した過去時点でコミット済みだった内容を読み取る参照専用の機能である。 表の現在のデータは一切変更しない。

前提・失敗ケース：

• 過去イメージの再構成に十分な UNDOが残っている必要がある。足りなければ ORA-01555（snapshot too old）になる。
• 参照しようとする時点以降に対象表の定義が変わった（ALTER TABLE 等の DDL）場合は、ORA-01466（データを読み取れません: 表定義が変更されました）になり得る。

結果を INSERT ... SELECT ... AS OF ... で救出したり、Flashback Version Query（VERSIONS BETWEEN）で変更履歴を追ったりと組み合わせられる。あくまで読み取りで、表を巻き戻すのは FLASHBACK TABLE（別機能）。

Flashback Data Archive（FDA / Flashback Time Travel）は、対象表の変更履歴を専用のフラッシュバックアーカイブへ長期間（年単位）自動保持する仕組みである。 UNDO の保持期間に縛られず、RETENTION で指定した期間だけ履歴を残せる。

有効化した表に対しては、SELECT ... AS OF TIMESTAMP/SCN や VERSIONS BETWEEN を使って、UNDO の限界をはるかに越えた過去時点の値・変更履歴を参照できる。 履歴の記録は透過的で、アプリ側の改修（履歴用トリガーや履歴表の自作）は不要である。

UNDO ベースの Flashback Query が「直近（UNDO 保持期間内）」しか遡れないのに対し、FDA は「監査・法令保持のような長期要件」に応える。両者は守備範囲が異なる。

リサイクルビンが有効なとき、通常の DROP TABLE（ケース1）は表を即時に物理削除せず、リサイクルビンへ移動（BIN$... にリネーム）する。 占有領域は保持されたままなので、FLASHBACK TABLE hr.emp TO BEFORE DROP; で元に戻せる。

一方 DROP TABLE ... PURGE（ケース2）はリサイクルビンを経由せず即座に完全削除する。リサイクルビンに入らないため、 TO BEFORE DROP では戻せない（この場合の復旧は、より重い時点指定リカバリ等に頼ることになる）。

補足：リサイクルビンはユーザー表領域のオブジェクトが対象で、SYSTEM 表領域のオブジェクトは対象外。領域が逼迫すると、リサイクルビン内のオブジェクトは古い順に自動的に追い出され得る（＝いつまでも戻せる保証はない）。

一時 UNDO（temporary undo）は、グローバル一時表（GTT）に対する DML の UNDOを、通常の UNDO 表領域ではなく一時表領域（TEMP）に格納する機能である （TEMP_UNDO_ENABLED=TRUE で有効化）。

効果：

• 通常 UNDO 表領域の消費が減り、その分に対応する REDO 生成も減る（一時 UNDO 自体はロギングされない）。
• 一時オブジェクトの UNDO が REDO を生まないため、Active Data Guard のリードオンリー・スタンバイ上でも GTT への DML が可能になる、といった利点にもつながる。

あくまで対象は一時オブジェクト（GTT 等）の UNDO であり、通常の永続表の UNDO や REDO を無くすものではない（永続表の変更は引き続き通常 UNDO＋REDO で保護される）。

impdp ... NETWORK_LINK=<dblink> は、ダンプファイルを介さず、ソース DB からデータベースリンク経由で直接データを引き込み、ターゲット DB に取り込む方式である。

利点・特徴：

• ダンプファイルが不要：expdp でファイルを作ってから転送・impdp、という二段階が要らない。中間ファイルの置き場（DIRECTORY）やディスクを気にせず済む。
• REMAP_SCHEMA 等の変換もそのまま使える（本問は HR → HR_TEST に付け替え）。
• 読み取りはリンク先（PROD）で行われ、書き込みはターゲット（TEST）。ネットワーク経由なので、巨大データや LOB が多いと帯域がボトルネックになり得る。

なお NETWORK_LINK インポートでは DUMPFILE は指定しない（ファイルを使わないため）。ファイル方式とネットワーク方式は排他的に選ぶ。

SQL Tuning Advisor（DBMS_SQLTUNE）は、単一の SQL 文を分析し、性能改善のための推奨を返す。返し得る推奨は複数種類ある。

• 統計の収集：欠落/失効した統計があれば、収集を推奨。
• SQL プロファイルの作成：オプティマイザに補助情報を与え、より良い計画を選ばせる（SQL 文自体は書き換えない）。ACCEPT_SQL_PROFILE で適用する。
• 索引の作成：新しい索引が有効なら提案（詳細な索引設計は SQL Access Advisor 領域）。
• SQL の書き換え（再構成）：より効率的な記述への変更を提案。

重要なのは、Advisor は推奨を出すだけで、DBA が採用（accept）して初めて適用される点（例：SQL プロファイルは ACCEPT_SQL_PROFILE）。自動で勝手に本番の計画を差し替えたりはしない。

19c の自動索引（Automatic Indexing）は、実ワークロードを分析して索引の候補を挙げ、 それらをまず不可視（invisible）索引として作成する。次に、その候補が実際に性能を改善するかを検証（対象 SQL の実行で比較）する。

• 候補が既存計画より性能を改善すると判定されれば、可視（visible）＝使用可能に昇格させる。
• 改善しない（または悪化する）候補は可視化せず、不可視のまま／使用不可（該当文には使わせない）にする。
• 一連の判断と結果はレポート（DBMS_AUTO_INDEX.REPORT_ACTIVITY 等）で確認できる。

ポイントは「いきなり全 SQL に効かせない」こと。まず不可視で作り、検証に合格したものだけ本採用する（＝退行を避けつつ自動化する）。

※Automatic Indexing を利用できるのは Enterprise Edition on Engineered Systems（Exadata。Oracle Database Appliance は対象外）と Oracle Exadata Database Service に限られ、Standard Edition 2 およびオンプレミスの Enterprise Edition では利用できない。