A successful CREATE DATABASE builds the new CDB's files, root, and seed. It does not install the dictionary views and standard packages. Those are still required before you can inspect and administer the database.
Oracle DBA Lesson 25B — Completing Manual CDB Setup
For a manually created Oracle 19c CDB, Oracle documents catcdb.sql as the CDB-specific post-creation workflow. This lesson covers dictionary installation and how to verify it. Creating an application PDB is a separate operation. Creating and configuring a CDB.
What the dictionary and packages provide
The data dictionary stores information about the database: object definitions, users, privileges, and storage. That is metadata, not application records such as customer orders. The core dictionary tables are created during database creation. They are not missing until catcdb.sql runs.
Dictionary views give SQL access to that information. A view can list the installed Oracle components. Standard PL/SQL packages supply built-in procedures for database tasks. PL/SQL is Oracle's procedural extension to SQL. A package groups related procedures, functions, and other definitions. You do not need to write a package to complete this step. Data dictionary. Creation scripts.
Run the CDB completion workflow
Continue the release-matched manual creation procedure for the new CDB. In SQL*Plus, connected to the root as SYSDBA:
SHOW CON_NAME
@?/rdbms/admin/catcdb.sqlSHOW CON_NAME confirms the current container. It should be CDB$ROOT. @ runs a SQL*Plus script. ? is the Oracle home, so the path is rdbms/admin/catcdb.sql in that home. Use the SQL*Plus executable and scripts from the Oracle home that belongs to this database. SQL*Plus. Administering a CDB with SQL*Plus.
The script asks for a log directory and a log filename, then for other setup values such as administrator passwords and the temporary tablespace name. Supply the values in the documented procedure for your installation. The script can take much longer than the video. Keep the complete logs.
Running catalog and package scripts only in the root leaves the seed unverified. That is not the complete CDB workflow. Manual CDB creation. Root and seed script execution.
Run these commands only on the new disposable database for this exercise, not on an existing application database. Use a release-matched VM snapshot and the course lab prerequisites. Enter credentials privately, and redact them from any shared evidence.
Check logs and component states
The installation logs show what the scripts did. Review them for unexpected SQL errors and compilation failures. A returned SQL prompt means the script stopped. It does not mean every component is installed. Investigate errors from the full log and the procedure for the installed release. Do not rerun scripts to get past an error you have not identified. Running Oracle-supplied scripts.
Root
After the script completes, inspect the component registry in the root:
ALTER SESSION SET CONTAINER=CDB$ROOT;
SHOW CON_NAME
SELECT comp_id, comp_name, status
FROM dba_registry
ORDER BY comp_id;DBA_REGISTRY records installed components. COMP_ID identifies a component, COMP_NAME is its name, and STATUS is its state. Every component required by the creation procedure must be present with the expected completed status. For the catalog and PL/SQL components in this lesson, that status is VALID. INVALID, or a component that never finished installing, needs investigation. A missing component has no row. Checking only that returned rows are VALID will miss it. DBA_REGISTRY.
CATALOG and CATPROC are two required components. They are not the full list. Do not use a fixed row count as the acceptance test. The full list depends on the installed features and the creation procedure. Component identifiers.
| Component ID | Meaning | Completed status |
|---|---|---|
CATALOG |
Oracle Database Catalog Views | VALID |
CATPROC |
Oracle Database Packages and Types | VALID |
Seed
A query in the root reports the root registry. Check the seed separately:
ALTER SESSION SET CONTAINER=PDB$SEED;
SHOW CON_NAME
SELECT comp_id, comp_name, status
FROM dba_registry
ORDER BY comp_id;
ALTER SESSION SET CONTAINER=CDB$ROOT;
SHOW CON_NAMEALTER SESSION SET CONTAINER changes this session's current container. It does not recreate the seed, and it does not change other sessions. The seed supplies the files used to create new PDBs, so its required components must be VALID too. A valid root is not evidence that the seed is complete. These queries only read the registry. Do not change the seed's open mode, and do not edit its dictionary to force a check to pass. Switching containers. Purpose of the seed.
Open modes
From the root:
SELECT name, open_mode
FROM v$pdbs
ORDER BY con_id;For the completed root-and-seed database in this lesson, PDB$SEED is READ ONLY. That is the seed's normal open mode. Open mode describes access. It does not say whether the components are valid. Read-only and VALID answer different questions. No user PDB has been created yet. V$PDBS. Seed open mode.
What remains outside dictionary setup
A complete dictionary is not a full readiness check. The creation procedure also covers any extra options you chose, SQL patches through Datapatch, and a database backup. Follow the instructions for the installed release and RU. Valid registry rows do not prove patch alignment, a tested backup, or application connectivity. Those are separate procedures. Creation steps 12–14.
Practice
On the new disposable CDB, or from a complete redacted execution record, note the script's log locations, any unexplained errors, the full root registry, the full seed registry, and the seed open mode. Compare the required components with the release-matched procedure. Leave anything unresolved marked unresolved. Keep the verified disposable database, or restore its VM snapshot, after you collect the evidence. Do not delete database files you have not identified.
No comments:
Post a Comment