Solved

Cloning PDB from Single Instance to RAC results in many SYS invalid objects


Userlevel 4
Badge +8

After our recent cloning from a Single Instance (PDB)  to a RAC, we found almost 75 SYS DB objects being invalidated, which resulted in more invalid objects in the IFSAPP schema (175 in total).

Recompiling the invalids won’t work as well, and it will still remain invalidated after force validations too. The RAC cluster is installed within Oracle Linux 8.5 which is Oracle verified, and the Oracle version of the DB is 19c E.A. Release 19.0.0.0.0 - Production [Version 19.14.0.0.0]

Has this situation been seen by anyone, and which solutions \ suggestions do you have for us to solve it immediately?

 

Thank you in advance.

icon

Best answer by Manulak 9 September 2022, 09:24

View original

10 replies

Userlevel 5
Badge +12

Hi,

Can you post the list of invalid objects under SYS schema?

Userlevel 4
Badge +8

Hi,

Can you post the list of invalid objects under SYS schema?

Sure, Ruchira.

This is the list of invalid objects for the SYS schema.

Name Type
SYS.LOGMNR$ALWSUPLOG_TABF_PUBLIC FUNCTION
SYS.ALL_STREAMS_COLUMNS VIEW
SYS.ALL_STREAMS_UNSUPPORTED VIEW
SYS.CDB_CHECKED_ROLES VIEW
SYS.CDB_CHECKED_ROLES_PATH VIEW
SYS.CDB_INVALID_OBJECTS VIEW
SYS.CDB_PROFILES VIEW
SYS.CDB_UNUSED_GRANTS VIEW
SYS.CDB_UNUSED_OBJPRIVS VIEW
SYS.CDB_UNUSED_PRIVS VIEW
SYS.CDB_UNUSED_SYSPRIVS_PATH VIEW
SYS.CDB_UNUSED_USERPRIVS_PATH VIEW
SYS.CDB_USED_OBJPRIVS VIEW
SYS.CDB_USED_PUBPRIVS VIEW
SYS.CDB_USED_USERPRIVS VIEW
SYS.CDB_USED_USERPRIVS_PATH VIEW
SYS.CDB_XS_AUDIT_POLICY_OPTIONS VIEW
SYS.DBA_CHECKED_ROLES VIEW
SYS.DBA_CHECKED_ROLES_PATH VIEW
SYS.DBA_INVALID_OBJECTS VIEW
SYS.DBA_UNUSED_GRANTS VIEW
SYS.DBA_UNUSED_OBJPRIVS VIEW
SYS.DBA_USED_OBJPRIVS VIEW
SYS.DBA_USED_PUBPRIVS VIEW
SYS.DBA_USED_USERPRIVS VIEW
SYS.DBA_USED_USERPRIVS_PATH VIEW
SYS.DBA_XS_AUDIT_POLICY_OPTIONS VIEW
SYS.MDX_ODBO_CUBES VIEW
SYS.MDX_ODBO_DIMENSIONS VIEW
SYS.MDX_ODBO_HIERARCHIES VIEW
SYS.MDX_ODBO_LEVELS VIEW
SYS.MDX_ODBO_MEASURES VIEW
SYS.MDX_ODBO_PROPERTIES VIEW
SYS.SM_$VERSION VIEW
Userlevel 7
Badge +21

Hi @Manulak ,

What are the actual errors that are holding up the compilation of these errors? Can you look at a few an see whether you get more concrete errors? 

Cheers

Userlevel 5
Badge +12

Agreeing with Sajith (Hi Sada ;)) Similarly I don’t see these being invalid will have an impact of the objects in IFSAPP schema but SYS.CDB_INVALID_OBJECTS is bit of a concern

Do you have any errors in PDB_PLUG_IN_VIOLATIONS view?

Userlevel 4
Badge +8

Hello @Sajith D and @Ruchira 

Thanks for your responses.

I’m sorry - ignoring SYS invalids is never a healthy option (which is not recommended at all) which could lead to an unstable and unsecured db which has an open threat of having more and more invalids in future with cloning RAC. 

However, the question about PDB_PLUG_IN_VIOLATIONS is interesting.
Yes, there are two errors.

  1. There are common XDB schema types missing from ROOT. [Resolved]
  2. Database option RAC mismatch: PDB installed version NULL. CDB installed version 19.0.0.0.0.[Pending]

Probably your suggestion might puzzle out all the issues 😎 Let me check that from my side as well. But please share your suggestions aligned with the errors I’ve mentioned too.

Thanks a lot.

PS : Few more info : 4 IFSAPP objects and 3 IFSINFO objects are invalidated currently. Let’s ignore IFSINFO objects for the moment, but the errors on IFSAPP objects are clearly the invalidated referenced objects. 

The compilation errors are pretty straight forward too, i.e. the referenced objects cannot be found or not authorized. E.g. : The object IFSAPP.FND_OBJ_TRACKING_SYS has the error ORA-04023: Object SYS.MSG_PROP_T could not be validated or authorized, and so on.

Cascade compilation is recommended to be done via utlrp.sql which also hangs until it’s being killed by the hang manager. That’s why it’s suspected that this is clearly an Oracle bug which needs a standard patch, hence two SRs are being raised already.

Userlevel 4
Badge +8

Hello @Sajith D and @Ruchira again

About the warning in the view PDB_PLUG_IN_VIOLATIONS, our DB experts had this to say : 

Warnings in PDB_PLUG_IN_VIOLATIONS do not prevent you from actually opening the PDB in READ WRITE mode.  You can ignore WARNING messages (you cannot ignore ERROR messages).   It is okay for a PDB to have a subset (fewer) options installed than the CDB into which it is plugged.   (The reverse is NOT true, however -- the CDB must always have the same or more options as its PDBs).

Just FYI.

Your feedback is highly appreciated.

Thank you.

Userlevel 7
Badge +21

Hi @Manulak,

it’s interesting why you would have different features in your single instance CDB vs RAC CDB. Assuming that both were created using the IFS template, they should be the same. Was there a different route taken when the RAC DB was created?

Cheers 

Userlevel 4
Badge +8

Hello @Sajith D 

The installations were done as per IFS guidelines. What is the feature difference you’ve noticed? If you referred to the warning of the table “Mismatch in installed version”, can you please guide me where in IFS template that setting is mentioned \ pushed?

Thank you.

Userlevel 4
Badge +8

Hello again

We learnt that the issue has a correlation with the OS (ours is Oracle Linux Server 7.8) and the Oracle version (ours is 12.2.0.3 (19c)) when the SI is cloned into a RAC. 

We are now discussing about deferent approaches of cloning which might overcome \ bypass the issue. Therefore, as @Sajith D mentioned above, please let me know if there’s a standard template \ guide which illustrates how a db should be cloned, so that I can inform our db experts to follow it up.

Thank you..

/Manulak

 

Userlevel 4
Badge +8

This was lately found to be an issue with the Oracle version, and certain oracle updates solved the issue.

Reply