Hi Angthony,
Yes, have tried to rekey and also tried to explicitly direct the cloned PDB
to "use" the supposedly (partially?) imported key (when the key has been
imported prior to a clone attempt). e.g. administer key management use key
'Abcf34545....etc' identified by "password2" with backup;
Notably, a rekey or the 'use key' AKM commands will not work until I have
brought the cloned PDB out of restricted mode as I will receive the error
below...
ORA-28442: Rekey of the TDE Master encryption key is not permitted when the
database is in restricted mode...
Which means that I pretty much have to attempt an import of the key to
remove the pdb_plug_in_violation, and perform the upgrade steps, in order
to reach a position where I must close/open the PDB to finally get it out
of restricted mode *before* I attempt to either 'set' or 'use key'... and
by that stage, the PDB is not in a positive state with the usual TDE
specific errors and complaints completely littering the alert log.
There are about 33 slightly different methods now (in terms of either
sequencing or commands) which I have attempted to perform. All of which I
know do not work in my scenario. Just hoping someone may have crossed this
particular bridge before me and can suggest what just one working
sequence/path should look like, so I can focus on debugging that route...
Thanks,
Ruan
On Wed, Jan 1, 2020 at 4:45 PM anthony Sanchez <anthonycsanchez@xxxxxxxxx>
wrote:
Hi ruan,
Have you tried resetting the master key in your pdb after clone?
Connect to pdb
ADMINISTER KEY MANAGEMENT SET KEY FORCE KEYSTORE IDENTIFIED BY
keystorepassword with backup;
On Wed, Jan 1, 2020, 3:40 AM Ruan Linehan <ruandav@xxxxxxxxx> wrote:
Hi list,
I am very stuck and really beginning to tread water on an SR with the
below scenario. Would anyone have experience of a 12.1-12.2 Multitenant PDB
upgrade path via remote clone including TDE??
Source 12.1 Multitenant PDB on Exadata RAC with TDE.
Destination 12.2 Multitenant PDB on Exadata RAC (Separate CDB on
the same cluster with separate software wallet).
I am attempting to perform a 12.1 --> 12.2 individual PDB upgrade via
remote clone between CDB containers. I have verified the process as
successful when using a non-TDE [Tablespace] specific PDB. i.e. perform the
necessary preupgrade.jar steps in the 12.1 source side, clone the PDB over
a DB link into the 12.2 destination side and then proceed with the
catctl/catupgrd scripting to perform the upgrade. No issues and all works
fine... without TDE.
However, when TDE is in the mix on the source PDB, I cannot manage to
succeed in transitioning the TDE key properly from source side over into
the destination side (Either before, during or post the upgrade scripting).
Below is a summary of steps for context but the issues comes down to; how
do I get a TDE key imported successfully when cloning from a 12.1 CDB to a
12.2 CDB...
*High Level summary:*
1. Export the TDE key from the source 12.1 side (*From within the PDB
itself)...
- administer key management set keystore open identified by
"password1";
- administer key management export encryption keys with secret
"password1" to '/tmp/source_side.p12' identified by "password1";
* Note1* - I believe the export operation is 100% clean as the same
steps used for this export work seamlessly when performing clones of TDE
specific PDBs between *12.1* CDBs.
2. Put the source PDB in ReadOnly...
- alter pluggable database ORCL close immediate instances=all;
- alter pluggable database ORCL open read only instances=all;
3. Perform DB Link clone between containers (*From the CDB$ROOT of the
destination 12.2 CDB)
- create pluggable database ORCL122 from ORCL@CLONE_LINK standbys =
none;
* Note2* - The DB link is fine as the PDB creates in restricted mode. I
have also attempted incorporating the "keystore identified by" syntax as
part of the create statement.
i.e. create pluggable database ORCL122 from ORCL@CLONE_LINK keystore
identified by "password1" standbys = none;
4. Open the cloned pluggable...
- alter pluggable database ORCL122 open instances=all;
* Note3* - At this point, the absence of the TDE required key is evident
in the alert log messaging, "PDB needs to import keys from source". But
there is no PDB_PLUG_IN_VIOLATION entry present yet, for the TDE key. Only
an error as expected for the upgrade path, "PDB's version does not match
CDB's version", which is quite expected. The PDB exists in restricted mode,
ready for upgrade.
5. It's from this point that I run into difficulty. I can try to proceed
with the catupgrd script operations firstly. Once that completes (seemingly
cleanly), there is a PDB_PLUG_IN_VIOLATION entry for the TDE key
requirement. I can then try and import the TDE (*From within the 122 PDB
itself) key per:
- administer key management import encryption keys with secret
"password1" from '/tmp/source_side.p12' identified by "password1" with
backup;
Alternatively, I could try and perform the import 'ahead of time' at the
CDB$ROOT container, prior to the clone operation at all. This command
succeeds as I can see the additional entry populated into the
v$encryption_keys view and within the software wallet, detailing the source
of the key.
Alternatively, I can try and transition the key, from the CDB$ROOT
container levels between CDBs instead using the "WITH IDENTIFIER" clause
syntax as I note that certain operations are directed to be performed at
the root level from 12.2 forward, but the very same result occurs in the
end...
I can observe the messaging "Keys imported: PDB ORCL122 can now open in
normal mode" recorded in the alert log and the PDB_PLUG_IN_VIOLATION entry
disappears. Great!
However, no matter how I "get the Key in", post a close/open of the PDB
(To get it out of restricted mode) - I immediately start receiving errors
in the alert log around master key not found in current keystore and typed
master key not found in wallet. It seems no matter how I try to transition
the correct key INTO the 12.2 destination side, the AKM commands appear to
succeed but upon proper opening of the PDB, I am flooded with TDE errors in
the alert logs.
Mr. Pachot made it look frustratingly easy here - my experience differs
significantly, and not sure where I am going wrong:
https://blog.dbi-services.com/12cr2-upgrade-by-remote-clone-with-tde-in-dbaas/
So the TL;DR version of the above is simply...
a) Is this manner of migration path supported?
b) At what stage/point in the sequence should I look to perform the TDE
key IMPORT on the destination side when cloning between 12.1-12.2 CDBs for
an upgrade in this manner?
c) And should the tried and trusted 12.1 key import syntax work
effectively for importing the key on the 12.2 destination side or am
missing something?
"administer key management import encryption keys with secret
"password1" from '/tmp/source_side.p12' identified by "password1" with
backup;""
Regards,
Ruan
