{"id":3650,"date":"2020-11-22T18:27:22","date_gmt":"2020-11-22T18:27:22","guid":{"rendered":"https:\/\/nenadnoveljic.com\/blog\/?p=3650"},"modified":"2020-11-22T18:28:32","modified_gmt":"2020-11-22T18:28:32","slug":"duplicating-pluggable-databases-with-sysbackup","status":"publish","type":"post","link":"https:\/\/nenadnoveljic.com\/blog\/duplicating-pluggable-databases-with-sysbackup\/","title":{"rendered":"Duplicating Pluggable Databases with sysbackup"},"content":{"rendered":"

According to Backup and Recovery User’s Guide<\/a>, duplicating of a pluggable database in the existing CDB should work with both sysdba and sysbackup privileges:
\n“Connect AS TARGET to the root of the source CDB as a common user with the SYSDBA or SYSBACKUP privilege.
\nConnect AS AUXILIARY to the root of the destination CDB as a common user with the SYSDBA or SYSBACKUP privilege”.
\nsysbackup is more secure because of the principle of least privilege<\/a>.
\nBut duplicate fails with sysbackup, because of “insufficient privileges”:<\/p>\n

connect target 'sysbackup\/password@SRCCDB as sysbackup'\nconnect auxiliary 'sysbackup\/password@DESTCDB as sysbackup'\nduplicate pluggable database SRCPDB as DESTPDB to DESTCDB from active database;\n\n...\nStarting Duplicate PDB at 20-NOV-20\nusing target database control file instead of recovery catalog\nallocated channel: ORA_AUX_DISK_1\nchannel ORA_AUX_DISK_1: SID=226 device type=DISK\ncurrent log archived\nduplicating Online logs to Oracle Managed File (OMF) location\nduplicating Datafiles to Oracle Managed File (OMF) location\nRMAN-00571: ===========================================================\nRMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============\nRMAN-00571: ===========================================================\nRMAN-03002: failure of Duplicate PDB command at 11\/20\/2020 15:20:29\nRMAN-05501: aborting duplication of target database\nRMAN-06136: Oracle error from auxiliary database: ORA-17628: Oracle error 1031 returned by remote Oracle server\nORA-01031: insufficient privileges<\/code><\/pre>\n
It’s not clear what privilege is missing.<\/p>\n
RMAN debug trace gives more information:<\/p>\n
begin sys.dbms_backup_restore.describeRemotePdb( service     => :service_in, pdbname     => :pdbname_in, descxmlfile => :descxmlfile_in); end;\nDBGSQL:             sqlcode = 17628\nDBGSQL:              B :service_in = SRCCDB\nDBGSQL:              B :pdbname_in = SRCPDB\nDBGSQL:              B :descxmlfile_in = \/u00\/oracle\/orabase\/product\/19.8.0.0.200714_a\/dbs\/_rm_pdb_pitr_2_DESTCDB.xml\nDBGSQL:          error: ORA-17628: Oracle error 1031 returned by remote Oracle server (krmkosqlerr)\nDBGSQL:          ORA-06512: at \"SYS.DBMS_BACKUP_RESTORE\", line 10817 (krmkosqlerr)\nDBGSQL:          ORA-01031: insufficient privileges (krmkosqlerr)\nDBGSQL:          ORA-06512: at \"SYS.DBMS_BACKUP_RESTORE\", line 10811 (krmkosqlerr)\nDBGSQL:          ORA-06512: at line 1 (krmkosqlerr)<\/code><\/pre>\n
Still not sure what the problem is, but I’ve got the idea where to look. The error ORA-17628 came from the auxiliary database, because of the ORA-01031 on the remote database. “Remote database” is the target database from the auxiliary perspective. In other words, the problem is on the target.<\/p>\n
There weren’t any ORA-01031 recorded in the target’s audit trail (even with audit_sys_operations=TRUE). This usually indicates that the operation bypassed the shared pool, as many Oracle C functions running under sysdba do.<\/p>\n
The error was registered in the alert log, though, without any details.<\/p>\n
ORA-01031: insufficient privileges<\/code><\/pre>\n
I captured the call stack for getting the context:<\/p>\n
alter system set events '1031 trace name errorstack level 3';<\/code><\/pre>\n
kgeade()+392         call     dbkePostKGE_kgsf()   7F18758C19A0 7F1870ACFA38\n                                                   000000407 000000000 ?\n                                                   7FFF0BDC9228 ? 000000082 ?\nkgeselv()+89         call     kgeade()             7F18758C19A0 ? 7F18758C1BE8 ?\n                                                   7F1870ACFA38 ? 000000407 ?\n                                                   000000000 000000000\nksesecl0()+189       call     kgeselv()            7F18758C19A0 ? 7F1870ACFA38 ?\n                                                   000000407 ? 013666718\n                                                   013666728 F9FF4D0000000000\nkpdbcBeginClone()+5  call     ksesecl0()           7F18758C19A0 ? 7F1870ACFA38 ?\n17                                                 000000407 ? 0774C3388\n                                                   7F18759123C0 0C0040000\nkpdbksrpcswCbk()+28  call     kpdbcBeginClone()    7FFF0BDCBF62 7FFF00000009\n57                                                 7F1800000002 000000007\n                                                   000000000 000000000\nkpdbksrpcCbk()+204   call     kpdbksrpcswCbk()     7FFF0BDCBF50 7FFF00000009 ?\n                                                   7FFF0BDCBF60 7FFF0BDCD270\n                                                   000000000 ? 000000000 ?\nksrpc_sgfun()+3055   call     kpdbksrpcCbk()       000000014 7FFF0BDCD270\n                                                   7F1870C18660 7FFF0BDCD270 ?\n                                                   000000000 ? 000000000 ?\nksrpcsexec()+1315    call     ksrpc_sgfun()        000000014 7FFF0BDCFB40\n                                                   7F1870C18660 ? 7FFF0BDCD270 ?\n                                                   7F18758C1BE8 7FFF00000000\nopiodr()+1202        call     ksrpcsexec()         00000009E 000000004\n                                                   7FFF0BDCFB40 7FFF0BDCD270 ?\n                                                   7F18758C1BE8 7FFF0BDC0000\nttcpip()+1222        call     opiodr()             00000009E 000000004\n                                                   7FFF0BDCFB40 ? 000000000\n                                                   7F18758C1BE8 ? 7FFF0BDC0000 ?<\/code><\/pre>\n
The shared pool was bypassed. We know this, because there aren’t any parsing functions on the stack.<\/p>\n
ksesecl0() generated ORA-01031 due to a failed security check in kpdbcBeginClone(). I assume it’s hardcoded in kpdbcBeginClone() that it can’t be called in a sysbackup session.<\/p>\n
A little benefit of this analysis: we can deduce some unknown meanings in the Oracle C function naming convention:<\/p>\n