We are currently on 12.2 and since a couple of months using multitenant, with more then 1 PDB in the CDB before we were using just 1 PDB.
From time to time the Test PDB’s need to be refreshed with production data.
Options to refresh PDB’s are limited in 12.2 (much better in 18c ) .
We Currently use this :
create pluggable database kabouter_plop from kuifje@PRODUCTION.ACME.COM
SERVICE_NAME_CONVERT = (
xxx,xxx
...
)
LOGGING
PARALLEL 8<
KEYSTORE IDENTIFIED BY ";
note the last line in this command is necessary if you have TDE enabled on your PDB
We have in production one CDB with two PDB’s:
PDB1 has TDE encrypted tablespaces and key set ( as outlined here )
PDB2 has no TDE encrypted tablespaces and no key set ( the alert.log is called Kuifje on production and kabouter_plop on testing )
We tried to “refresh” PDB2 We received following errors ( with or without specifying the KEYSTORE IDENTIFIED clause )
ORA-28374
ORA-283
and didn’t know why
here an excerpt of the alert.log
Endian type of dictionary set to little
2019-03-11 12:53:03.395000 +00:00
****************************************************************
Pluggable Database KABOUTER_PLOP with pdb id - 3 is created as UNUSABLE.
If any errors are encountered before the pdb is marked as NEW,
then the pdb must be dropped
local undo-1, localundoscn-0x00000000000000e0
****************************************************************
2019-03-11 12:53:15.973000 +00:00
Applying media recovery for pdb-4099 from SCN 91372363956 to SCN 91372887378
Remote log information: count-5
thr-2, seq-4950, logfile-+RECO4/L1/ARCHIVELOG/2019_03_11/thread_2_seq_4950.1360.1002631629, los-91372165870, nxs-91372721676
thr-1, seq-6955, logfile-+RECO4/L1/ARCHIVELOG/2019_03_11/thread_1_seq_6955.1359.1002631571, los-91372412147, nxs-91372715223
thr-1, seq-6954, logfile-+RECO4/L1/ARCHIVELOG/2019_03_11/thread_1_seq_6954.1358.1002630879, los-91372165747, nxs-91372412147
thr-2, seq-4951, logfile-+RECO4/L1/partial_archivelog/2019_03_11/thread_2_seq_4951.1361.1002631985, los-91372721676, nxs-18446744073709551615
thr-1, seq-6956, logfile-+RECO4/L1/partial_archivelog/2019_03_11/thread_1_seq_6956.1362.1002631993, los-91372715223, nxs-18446744073709551615
attach called for domid 3 (domuid: 0x8df2051, options: 0x0, pid: 78883)
queued attach broadcast request 0x82cec698
* allocate domain 3, valid ? 1
all enqueues go to domain 0
Media Recovery Start
Serial Media Recovery started
Media Recovery Log +RECO4/L1/ARCHIVELOG/2019_03_11/thread_2_seq_4950.1360.1002631629
2019-03-11 12:53:17.047000 +00:00
Media Recovery Log +RECO4/L1/ARCHIVELOG/2019_03_11/thread_1_seq_6954.1358.1002630879
2019-03-11 12:53:21.913000 +00:00
Errors with log +RECO4/L1/ARCHIVELOG/2019_03_11/thread_1_seq_6954.1358.1002630879
2019-03-11 12:54:43.280000 +00:00
Media Recovery failed with error 28374
detach called for domid 3 (domuid: 0x8df2051, options: 0x0, pid: 78883)
queued detach broadcast request 0x82cec640
freeing rdom 3
ORA-283 signalled during: create pluggable database kabouter_plop from kuifje@PRODUCTION.ACME.COM
SERVICE_NAME_CONVERT = (
xxxx
)
LOGGING
parallel 8
KEYSTORE IDENTIFIED BY *...
Note that this PDB has no encryption enabled.
We tried to reproduce this behaviour on another environment but didn’t succeed.
We tried again to refresh from production with alert log opened of both source and target and saw that at the time of the failure on there was quite some activity on the other PDB with encryption enabled and quiite some redo was generated.
Once we stopped the activity on the other live db we were able to create the pdb correctly.
As a next test will test if we see the same behaviour when the key is enabled in the non TDE enabled PDB. Will update article to keep you posted
Update : We now get some other weird error ORA-01144 : File size (31457280 blocks) exceeds maximum of 4194303 blocks it seems Bigfile Tablespaces are being ignored ? The version we are working on is 12.2.0.1.190115
