- The Application name provided at step 3 of the deployment will be used for any object modification like object conversion or patch-set application. Suggested name – OBPM.

- The common user should have DBA role while application install or upgrade. It can be revoked once the application maintenance is completed.

• It is recommended to have a single application as the Common core units can be released as part of any product processor and if the object can be linked to only one application.
• Modification of the object belonging to one application cannot be modified in another application.

• Day zero set up has be done for each of the PDBs created under the approot. The record insertion will be based on the sharing type of the object.
• If the sharing is METADATA LINK, then the record for the table will be inserted into PDB schema and if the sharing is DATA LINK, record insertion happens in the approot schema for thattable.

• When synch with PDB fails, there is no definite solution available. Back up of the PDB can be taken before an upgrade and in case of synch failure; new PDB can be created and applied with the backup data.
• Generally, for multi-tenant the recommendation is that objects will be compiled in a normal schema to check the sanity and to make sure the Invalids are zero. Once that is successful, the compilation will be done in Multi-tenant database.

• Once the application upgrade is completed in approot, it can be synched up to the PDB. If the PDBs are not synched at the same time, there will be a mismatch between the front end and backend objects.
• In such case when a single PDB is parked for synching afterwards, a separate front URL with backup EAR has to be created to point to the PDB schema.

ORA-21700: object does not exist or is marked for delete

ORA-44201: cursor needs to be reparsed

• Root cause can be traced in DBA_APP_ERRORS / DBA_ERRORS oracle table.
• Execute below command in Approot and Pdb. Consolidate list and create a sql file.

  SELECT INVALIDOBJECT1
  FROM (SELECT 'alter ' || REFERENCED_TYPE || ' ' || REFERENCED_NAME || 
  ' compile;' INVALIDOBJECT1,
  1 INDX
  FROM USER_DEPENDENCIES 
  WHERE NAME IN
  (SELECT object_name FROM user_objects WHERE status = 'INVALID') 
  AND TYPE = 'PACKAGE'
  AND REFERENCED_TYPE IN ('PACKAGE', 'PACKAGE BODY') 
  AND REFERENCED_NAME NOT IN ('STANDARD')
  UNION
  SELECT 'alter ' || OBJECT_TYPE || ' ' || OBJECT_NAME || ' compile;' INVALIDOBJECT1, 
  2 INDX
  FROM USER_OBJECTS 
  WHERE OBJECT_NAME IN
  (SELECT object_name FROM user_objects WHERE status = 'INVALID') 
  AND OBJECT_TYPE IN ('PACKAGE')
  UNION
  SELECT 'alter package ' || OBJECT_NAME || ' compile body;' INVALIDOBJECT1, 
  3 INDX
  FROM USER_OBJECTS 
  WHERE status = 'INVALID'
  AND OBJECT_TYPE IN ('PACKAGE BODY')) 
  ORDER BY INDX;

• Start the upgrade in approot.
• Drop the root cause objects.
• Create the root cause objects.
• Execute the sql file placed in a path.
• End upgrade
• Sync to Entity pdb.
• Verify the result using DBA_APP_ERRORS/ DBA_ERRORS/USER_OBJECTS status = ‘INVALID’.