How to Rename a Pluggable Database (PDB) in Oracle Database 19c (Multitenant)

We needed to rename a pluggable database from EBSDB to EBSPDB as part of standardizing naming across environments. It looks like a two-command job at first glance, but the rename has a strict sequence — close, reopen restricted, switch container, rename, then close and reopen from the root — and skipping or reordering a step either fails outright or leaves the PDB in a state where the new name doesn’t fully take. Here is the exact sequence we used, what each command does, and what a rename does and doesn’t touch.

Environment Details

Database	Oracle Database 19c (Multitenant / CDB-PDB architecture)
CDB Name	CDB1
Old PDB Name	EBSDB
New PDB Name	EBSPDB
DB Server Node	mydb

Understanding the Concepts

CDB, PDB, and What “Name” Actually Means

In the multitenant architecture, a single Container Database (CDB) hosts one or more Pluggable Databases (PDBs). The CDB owns the instance, the SPFILE, the control file, and the background processes; each PDB is a self-contained set of tablespaces and a data dictionary that plugs into that instance. A PDB has its own name, but that name is metadata stored in the CDB’s dictionary (visible via v$pdbs, v$containers, and DBA_PDBS) — it is not baked into the PDB’s datafiles or its physical files in any way. That is precisely why a rename is safe and fast: you are updating a row of metadata in the root container, not touching a single byte of the PDB’s own data.

Why GLOBAL_NAME, Not Just “NAME”

Every PDB has two related but distinct identifiers: its container name (the CON_NAME shown by show pdbs, used for administrative commands like ALTER SESSION SET CONTAINER) and its global name, which is what ALTER PLUGGABLE DATABASE … RENAME GLOBAL_NAME actually changes. In practice, for a PDB that is not using a DB_DOMAIN suffix, the two end up being the same string — which is why the command reads as a full rename rather than a narrower operation. The command also drives the PDB’s default database service, which is derived from this same name and is what client connect strings actually resolve against at the listener.

Why the PDB Must Be Closed and Reopened Restricted

A rename changes an identity that is cached in multiple places — the shared pool, the listener’s service registration, and any session that has already resolved the old name. Oracle requires the PDB to be closed first so there is no live state referencing the old identity when the change is made. Reopening in RESTRICTED mode rather than fully open is a safety measure: it lets the DBA (a RESTRICTED SESSION-privileged connection) get in to perform the rename while ordinary application sessions are locked out, so nobody can establish a new connection against the soon-to-be-stale name mid-operation.

Why the Rename Command Must Run Inside the PDB

ALTER SESSION SET CONTAINER = <pdb> doesn’t just change a label in your prompt — it moves your session’s container context so that subsequent DDL is scoped to that PDB rather than to CDB$ROOT. RENAME GLOBAL_NAME is deliberately scoped this way (rather than being expressed as, say, ALTER PLUGGABLE DATABASE EBSDB RENAME TO EBSPDB from the root) because a global name change is conceptually an operation the PDB performs on itself, consistent with how DB_DOMAIN/global name renames have always worked for non-CDB databases with ALTER DATABASE RENAME GLOBAL_NAME — multitenant reuses the same underlying mechanism, just scoped to a container.

Why You Reference the PDB by Its New Name Immediately After

Once the rename commits, the old identifier is gone from the CDB’s dictionary — there’s no grace period or alias left behind. Any subsequent ALTER PLUGGABLE DATABASE, connect string, or lsnrctl service check has to use the new name, because the old one no longer maps to anything in the control file or the dictionary. This is also why the final CLOSE/OPEN pair in the sequence uses EBSPDB and not EBSDB: it isn’t a cosmetic choice, it’s the only name Oracle recognizes at that point.

Renaming the PDB

1 Check the Current DBA Status

SQL> show pdbs;

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         4 EBSDB                          READ WRITE NO

Note: Always confirm the PDB’s current open mode before touching it — a rename requires the PDB to be closed first.

2 Close the PDB Before Renaming

SQL> ALTER PLUGGABLE DATABASE EBSDB CLOSE IMMEDIATE;

Pluggable database altered.

Note: A PDB’s global name cannot be changed while it is open. CLOSE IMMEDIATE is the standard way to bring it down cleanly for maintenance.

3 Reopen Restricted and Switch Into the PDB

SQL> ALTER PLUGGABLE DATABASE EBSDB OPEN RESTRICTED;

Pluggable database altered.

SQL> ALTER SESSION SET CONTAINER = EBSDB;

Session altered.

Note: RESTRICTED mode keeps ordinary sessions out while the rename is in progress. The rename command itself must be issued from inside the PDB, not from CDB$ROOT.

4 Rename the Global Name

SQL> ALTER PLUGGABLE DATABASE EBSDB RENAME GLOBAL_NAME TO EBSPDB;

Pluggable database altered.

Note: This is the actual rename. Run while connected to the PDB itself, it updates the PDB’s name in the CDB dictionary — not just a DB_DOMAIN-style string — so v$pdbs.name and every future show pdbs report the new name.

5 Return to the Root Container and Reopen

SQL> ALTER SESSION SET CONTAINER = CDB$ROOT;

Session altered.

SQL> ALTER PLUGGABLE DATABASE EBSPDB CLOSE IMMEDIATE;

Pluggable database altered.

SQL> ALTER PLUGGABLE DATABASE EBSPDB OPEN;

Pluggable database altered.

Note: Reference the PDB by its NEW name once back at CDB$ROOT — EBSDB no longer resolves to anything. Opening normally (not RESTRICTED) at the end lets application sessions back in.

Why a Custom Service Doesn’t Follow the Rename

Oracle only auto-manages the PDB’s default service — the one it creates for you the moment the PDB is created, sharing the PDB’s name. Any service you created afterward with DBMS_SERVICE.CREATE_SERVICE is a separate object registered in the dictionary with its own name and its own PDB association by CON_ID, not by name-matching. A rename updates the PDB’s CON_ID’s associated name; it doesn’t walk the list of services and rename ones that happen to reference the old string. This is a common surprise for DBAs coming from single-instance (non-CDB) databases, where a global name rename and the database’s connect identity were effectively the same thing.

6 Verify the Rename and the Service Registration

SQL> show pdbs;

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         4 EBSPDB                         READ WRITE NO

$ lsnrctl status

Service "EBSPDB" has 1 instance(s).
  Instance "CDB1", status READY, has 1 handler(s) for this service...

Note: Dynamic registration usually picks up the renamed PDB’s default service with the listener within about a minute of the final OPEN. If you use a custom (non-default) service name, drop and recreate it explicitly with DBMS_SERVICE.CREATE_SERVICE / START_SERVICE — it won’t follow the rename on its own.

Test Connectivity Under the New Name

$ tnsping EBSPDB

$ sqlplus system/<pwd>@//oradb01t:1521/EBSPDB

SQL> select sys_context('userenv','con_name') from dual;

CON_NAME
-----------
EBSPDB

Note: EBSDB no longer resolves to anything at the listener or dictionary level — any client, tnsnames entry, script, or connect string still pointing at the old name will fail to connect from this point forward.

Rename Impact Summary

Component	Status	Detail
PDB Global Name	Renamed	EBSDB → EBSPDB via ALTER PLUGGABLE DATABASE
PDB Datafiles	Unchanged	Paths and filenames untouched by the rename
Default DB Service	Renamed	Follows the PDB name automatically
Custom (Non-Default) Services	Must Recreate	Not renamed automatically — recreate with DBMS_SERVICE
Listener Service Registration	Verify	Dynamic registration usually updates within ~60 seconds
tnsnames.ora / Client Connect Strings	Must Update	Still reference EBSDB until edited manually

Key Takeaways for Oracle DBAs

• ALTER PLUGGABLE DATABASE … RENAME GLOBAL_NAME must be run while connected inside the PDB (after ALTER SESSION SET CONTAINER), not from CDB$ROOT.
• The PDB must be closed, reopened RESTRICTED, renamed, then closed and reopened normally — and referenced by its new name immediately afterward.
• Only the PDB’s name and its default service change. Datafile paths, redo/archive destinations, and SPFILE settings are completely unaffected.
• Custom (non-default) services you created for the PDB do not follow the rename automatically — recreate them with DBMS_SERVICE against the new PDB name.
• Once the rename completes, the old name stops resolving immediately — test connectivity under the new name before considering the change finished.

Commands Quick Reference

Command	Purpose
show pdbs;	Check current PDB status
ALTER PLUGGABLE DATABASE <pdb> CLOSE IMMEDIATE;	Close the PDB before renaming
ALTER PLUGGABLE DATABASE <pdb> OPEN RESTRICTED;	Reopen in restricted mode
ALTER SESSION SET CONTAINER = <pdb>;	Switch the session into the PDB
ALTER PLUGGABLE DATABASE <pdb> RENAME GLOBAL_NAME TO <new>;	Perform the rename
ALTER SESSION SET CONTAINER = CDB$ROOT;	Return to the root container
ALTER PLUGGABLE DATABASE <new> CLOSE IMMEDIATE;	Close the PDB under its new name
ALTER PLUGGABLE DATABASE <new> OPEN;	Reopen normally under the new name
lsnrctl status	Confirm the renamed service registered
tnsping <service>	Validate the new service name resolves

FAQs