1Z0-060 · Question #116
You are about to plug a multi-terabyte non-CDB into an existing multitenant container database (CDB) as a pluggable database (PDB). The characteristics of the non-CDB are as follows…
The correct answer is B. Transportable tablespace. When plugging a non-CDB with character set WE8ISO8859P15 into a CDB with AL32UTF8, the character set mismatch disqualifies DBMS_PDB, making transportable tablespace with datafile conversion the correct approach to minimize downtime for a multi-terabyte database.
Question
You are about to plug a multi-terabyte non-CDB into an existing multitenant container database (CDB) as a pluggable database (PDB). The characteristics of the non-CDB are as follows:
- Version:Oracle Database 12c Releases 1 64-bit
- Character set: WE8ISO8859P15
- National character set: AL16UTF16
- O/S: Oracle Linux6 64-bit
The characteristics of the CDB are as follows:
- Version: Oracle Database 12c Release 1 64-bit
- Character set: AL32UTF8
- O/S:OracleLinux 6 64-bit
Which technique should you use to minimize down time while plugging this non-CDB into the CDB?
Options
- ATransportable database
- BTransportable tablespace
- CData Pump full export / import
- DThe DBMS_PDB package
- ERMAN
How the community answered
(64 responses)- A2% (1)
- B69% (44)
- C5% (3)
- D8% (5)
- E17% (11)
Why each option
When plugging a non-CDB with character set WE8ISO8859P15 into a CDB with AL32UTF8, the character set mismatch disqualifies DBMS_PDB, making transportable tablespace with datafile conversion the correct approach to minimize downtime for a multi-terabyte database.
Transportable database (full transportable export/import) requires character set compatibility between source and target; because WE8ISO8859P15 and AL32UTF8 are incompatible in the required direction, this technique cannot be used directly.
Transportable tablespace supports cross-character-set migration by using RMAN to convert datafiles during transport, avoiding a full logical export of terabytes of data. It minimizes downtime because datafiles are moved directly rather than being unloaded and reloaded row-by-row, while still handling the WE8ISO8859P15-to-AL32UTF8 character conversion.
Data Pump full export/import performs a logical row-by-row migration, which is prohibitively slow for a multi-terabyte database and results in far more downtime than a transportable approach.
The DBMS_PDB package requires that the non-CDB's character set be binary-compatible with or a strict subset of the CDB's character set; WE8ISO8859P15 does not satisfy this requirement relative to AL32UTF8, so the plug operation would fail.
RMAN alone cannot perform the logical character set data conversion required when migrating from WE8ISO8859P15 to AL32UTF8; RMAN handles physical datafile operations, not character encoding transformation of stored data.
Concept tested: Non-CDB to PDB migration with character set mismatch
Source: https://docs.oracle.com/database/121/ADMIN/transport.htm
Topics
Community Discussion
No community discussion yet for this question.