Best Of
Re: Upgrade 12.2 db to 19.3 - preupgrade check
Tldr: Use the principal names from the following query in the delete_application_principal procedure:
SELECT name principal FROM xdb.app_users_and_roles WHERE name <> 'AUTHENTICATED' ORDER BY 1;
Having encountered the same situation while preparing to upgrade from 18c to 19c, and having found no help here or elsewhere as to how to hunt down user/role name(s) in need of the delete_application_principal treatment, I finally thought to look at the code Oracle uses to determine whether or not the identified manual fix-ups have been satisfied.
Looking through the generated preupgrade_fixups.sql led me to the dbms_preup package in the SYS schema, which thankfully wasn't wrapped, and in there I found the function appl_principal_check. In that function was some simple PL/SQL code to count the number of records in two XDB schema views, XDB.APP_USERS_AND_ROLES and XDB.APP_ROLE_MEMBERSHIP. Querying the first of those (and noting the comment "Ignore the AUTHENTICATED record inserted at table creation") gave me a single result (other than the ignored AUTHENTICATED result): 'AUTHORIZED'. After running delete_application_principal with 'AUTHORIZED' as the argument, preupgrade_fixups.sql reported that the app_principal preupgrade check had been remedied.
Note: My situation was that I had (as far as I know) no user-defined applications using XDB or any security defined using "application principals" in my database, so the AUTHORIZED role is possibly a system-generated default (and if so, I would think the pre-upgrade scripts could auto-fix in the case that it's all there is). If you have XDB usage / application principals with users placed in roles, etc., you might have records in XDB.APP_ROLE_MEMBERSHIP, which apparently contains GUIDs rather than names, so you'll possibly have to chase things down further if you do.
So the following code should remedy this in simple cases:
SET SERVEROUTPUT ON BEGIN FOR r IN (SELECT name principal FROM xdb.app_users_and_roles WHERE name <> 'AUTHENTICATED' ORDER BY 1) LOOP dbms_output.put_line(r.principal ||' ...'); IF xdb.dbms_xdbz.delete_application_principal(name => r.principal) THEN dbms_output.put_line('Succeeded.'); ELSE dbms_output.put_line('Failed.'); END IF; END LOOP; END; / So now there is a solution findable on the 'Net!
All the best with your upgrades, everyone!
Eldon
EldonR
Re: How to rename database on ODA
Hi Rémi,
I've restored databases with a rename many times using the method Krisz mentions. It work great. However, if your database is tde-enabled make sure you have a backup of the tde key external to your ODA (on NFSor Object Storage) and test the password on the keystore to make sure it is correct. If you don't know your tde key password there is no way to restore a database backup.
Louis
Re: EBS Fixed Assets Analyzer Feedback Thread Note: 2061234.1
Hi All,
Version 200.68 was just released with the following enhancement. You can download the latest version from EBS Fixed Assets Analyzer, Doc ID 2061234.1.
Minor enhancement made to 'Asset XLA Transactions Data Checks' section.
- Modified signature 'XLA AE Headers' fixed missing comma after column name (JE_CATEGORY_NAME).
