What is the new view ad_objects and how is it different from dba_objects?

  • Developers often use the user_objects or all_objects data dictionary view to confirm that there are no unexpected invalid objects.
  • Due to a database limitation these dictionary views only return correct object status after running a full compilation procedure (utl_recomp.recomp_parallel or ad_zd.compile).
  • As a workaround, you can check object status using the ad_objects view included with online patching.

select * from ad_objects where status=’INVALID’;

If we compare the total number of objects in ad_objects to dba_objects, we find that ad_objects has one more object than dba_objects:

SQL> select count(*) from ad_objects

COUNT(*)
———-
394774

SQL>  select count(*) from dba_objects

COUNT(*)
———-
394773

So, what’s the difference between ad_objects and dba_objects?
SQL> select object_name, object_type, owner from ad_objects
2  minus
3  select object_name, object_type, owner from dba_objects;
OBJECT_NAME
——————————————————————————–
OBJECT_TYPE        OWNER
——————- ——————————
_default_auditing_options_
TABLE            SYS
How are the columns different between ad_objects  and dba_objects? Compare the following table structures below:

SQL> desc ad_objects
Name                       Null?    Type
—————————————– ——– —————————-
OWNER                            VARCHAR2(30)
OBJECT_NAME                   NOT NULL VARCHAR2(30)
OBJECT_TYPE                        VARCHAR2(18)
ACTUAL                         VARCHAR2(1)
STATUS                         VARCHAR2(7)
CTIME                            DATE
MTIME                            DATE
STIME                            DATE

SQL> desc dba_objects
Name                       Null?    Type
—————————————– ——– —————————-
OWNER                            VARCHAR2(30)
OBJECT_NAME                        VARCHAR2(128)
SUBOBJECT_NAME                     VARCHAR2(30)
OBJECT_ID                        NUMBER
DATA_OBJECT_ID                     NUMBER
OBJECT_TYPE                        VARCHAR2(19)
CREATED                        DATE
LAST_DDL_TIME                        DATE
TIMESTAMP                        VARCHAR2(19)
STATUS                         VARCHAR2(7)
TEMPORARY                        VARCHAR2(1)
GENERATED                        VARCHAR2(1)
SECONDARY                        VARCHAR2(1)
NAMESPACE                        NUMBER
EDITION_NAME                        VARCHAR2(30)

How to Determine that all Tables and Materialized Views have an Editioning View

After applying 13543062, we ran ADZDSHOWDDLS.sql to see if all tables and materialized views had editioning views. Below, an excerpt of ADZDSHOWDDLS.out shows the editioning results for tables and materialized views:

Phase                               Count Status

UPGRADE_TABLE          18355 S – Successfully Executed

UPGRADE_MVIEW              1 N – Not Executed                            1 R – Running                          113 S – Successfully Executed                           11 E – Error

Run the following SQL statement to check the count of editioning views versus the count of tables and materialized views:

select * from dba_objects where (object_type in (‘VIEW’) and object_name like ‘%#’)

union

select * from dba_objects where object_type in (‘MATERIALIZED VIEW’, ‘TABLE’);

Of course, we can do it an easier way and compare VIEW_NAME and TABLE_NAME in DBA_EDITIONING_VIEWS and do a “count” to see if the result agrees with the results from above.

describe dba_editioning_views

OWNER                 NOT NULL VARCHAR(128)

VIEW_NAME         NOT NULL VARCHAR(128)

TABLE_NAME       NOT NULL VARCHAR(128)

Or, select table_name where the view_name doesn’t exist.

Or, use the Section 20 SQL from ADZDDBCC.sql to find tables that don’t have an editioning view. In order to patch custom tables using online patching, custom tables require an editioning view and APPS synonym. The following SQL will find tables that may not have an editioning view.

**********************************************************************

SECTION-20  [full]

**********************************************************************

“Table must have an editioning view.”

– P2: These tables may not be patched using online patching.

– Fix:  Execute the table upgrade procedure.

SQL> exec ad_zd_table.upgrade(table_owner, new_table_name)

Note: Tables that are dynamically created by application runtime can be ignored.

Note: Tables that end with “_A” are typically audit tables by the Audit Trail feature, and can be ignored.

Note: This check is only active after Online Patching Enablement.

#

select tab.owner owner, tab.table_name table_name

from dba_tables tab

where tab.owner in

( select oracle_username from system.fnd_oracle_userid

where  read_only_flag in (‘A’, ‘B’, ‘E’) )

and tab.temporary = ‘N’

and tab.secondary = ‘N’

and tab.iot_type is null

and tab.tablespace_name not in (‘APPS_TS_NOLOGGING’, ‘APPS_TS_QUEUES’)

and tab.table_name not like ‘%$’

and not regexp_like(tab.table_name, ‘^AQ\$’, ‘c’)

and not regexp_like(tab.table_name, ‘^AW\$’, ‘c’)

and not regexp_like(tab.table_name, ‘^MLOG\$’, ‘c’)

and not regexp_like(tab.table_name, ‘^BSC_DI_[0-9_]+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^BSC_D_.+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^FA_ARCHIVE_ADJUSTMENT_.+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^FA_ARCHIVE_DETAIL_.+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^FA_ARCHIVE_SUMMARY_.+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^GL_DAILY_POST_INT_.+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^GL_INTERCO_BSV_INT_[0-9]+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^GL_MOVEMERGE_BAL_[0-9]+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^GL_MOVEMERGE_INTERIM_[0-9]+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^XLA_GLT_[0-9]+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^ICX_POR_C[0-9]+.*$’, ‘c’)

and not regexp_like(tab.table_name, ‘^ICX_POR_UPLOAD_[0-9]+.*$’, ‘c’)

and not regexp_like(tab.table_name, ‘^IGI_SLS_[0-9]+$’, ‘c’)

and not regexp_like(tab.table_name, ‘^JTF_TAE_[0-9]+.*$’, ‘c’)

and not regexp_like(tab.table_name, ‘^JTY_[0-9]+_.*$’, ‘c’)

and not regexp_like(tab.table_name, ‘^ZPBDATA[0-9]+_EXCPT_T$’, ‘c’)

and not regexp_like(tab.table_name, ‘^ZX_DATA_UPLOAD_.*$’, ‘c’)

/* Note: Exclusion list for AD varies by release */

and ( ( tab.table_name not in

(‘TXK_TCC_RESULTS’,

‘AD_DEFERRED_JOBS’,

‘AD_TABLE_INDEX_INFO’,

‘FND_INSTALL_PROCESSES’,

‘AD_UTIL_PARAMS’,

‘AD_PATCHED_TABLES’,

‘AD_ZD_DDL_HANDLER’,

‘AD_OBSOLETE_OBJECTS’,

‘FND_PRODUCT_INSTALLATIONS’)

and

( select codelevel from ad_trackable_entities

where upper(abbreviation)=’AD’ ) < ‘C.1’ )

or

( tab.table_name not in

(‘TXK_TCC_RESULTS’,

‘AD_DEFERRED_JOBS’,

‘AD_TABLE_INDEX_INFO’,

‘FND_INSTALL_PROCESSES’,

‘AD_UTIL_PARAMS’ )

and

( select codelevel from ad_trackable_entities

where upper(abbreviation)=’AD’ ) >= ‘C.1′ )

)

and (tab.owner, tab.table_name) not in

( select qt.owner, qt.queue_table

from   dba_queue_tables qt )

and (tab.owner, tab.table_name) not in

( select mv.owner, mv.container_name

from   dba_mviews mv )

and (tab.owner, tab.table_name) in

( select syn.table_owner, syn.table_name

from   dba_synonyms syn

where  syn.owner  in

( select oracle_username from system.fnd_oracle_userid

where  read_only_flag =’U’ ) )

and not exists

( select ev.owner, ev.view_name

from dba_editioning_views ev

where ev.owner      = tab.owner

and ev.table_name = tab.table_name

and ev.view_name  = substrb(tab.table_name, 1, 29)||’#’ )

and exists

( select null

from fnd_oracle_userid au, dba_users du

where au.oracle_username = du.username

and au.read_only_flag  = ‘U’

and du.editions_enabled = ‘Y’ )

and not exists

( select 1

from system.fnd_oracle_userid fou

, fnd_product_installations fpi

, ad_obsolete_objects aoo

where fpi.application_id = aoo.application_id

and fou.oracle_id = fpi.oracle_id

and fou.oracle_username = tab.owner

and aoo.object_name = tab.table_name

and aoo.object_type = ‘TABLE’ )

order by tab.owner, tab.table_name

/

 

Finding the Patches inside a Merged Patch

SELECT applied_patch_id, rapid_installed_flag, patch_name, patch_type, maint_pack_level
FROM   applsys.ad_applied_patches
order by 1 desc;
select * from ad_patch_drivers
where applied_patch_id = 102974;
Notice the ORIG_PATCH_NAME is a surrogate number instead of the old convention of “merged”.
PATCH_DRIVER_ID     APPLIED_PATCH_ID     ORIG_PATCH_NAME

                       99582                            102974                     2123079401

SELECT ab.bug_number, acp.patch_abstract
FROM  ad_comprising_patches acp, ad_bugs ab
WHERE acp.bug_id = ab.bug_id AND acp.patch_driver_id = 99582;

BUG_NUMBER    PATCH_ABSTRACT

 21830810            R12.TXK.C.DELTA.8
 23569114            INVALID APPS DATABASE USER CREDENTIALS – TXKGENADOPWRAPPER_PL – 12.2.4
23705992             TNSNAMES.ORA GENERATED WITH SCAN NAME INSTEAD OF SCAN IPS FOR CUSTOM RACE DB CLONE
18525466             REVERT CHANGES MADE TO VALIDATE MANAGED SERVER PORTS OF ALL NODES

Tips From Our Latest Release 12.2.6 First Pass Upgrades

We’ve just finished two successful Release 12.2.6 First Pass Upgrades in the last six weeks. We always encounter and resolve a few unique issues with each client. Here are two examples.

The first issue occurred while running Patch 10124646 (the 12.2.0 upgrade patch), and the second occurred after running that patch.

1. During the 10124646 patch (the upgrade to 12.2.0), with about 22000 jobs completed and about 10000 jobs remaining, we saw this error:

ATTENTION: All workers either have failed or are waiting:

FAILED: file CustMigrationTool.class on worker 1.
FAILED: file CustMigrationTool.class on worker 2.
FAILED: file CustMigrationTool.class on worker 3.
FAILED: file CustMigrationTool.class on worker 4.
FAILED: file EDRXDOMigration.class on worker 5.
FAILED: file CustMigrationTool.class on worker 6.
FAILED: file CustMigrationTool.class on worker 7.
FAILED: file CustMigrationTool.class on worker 8.
FAILED: file CustMigrationTool.class on worker 9.

According to the ad worker log: adworker001.log
Exception in thread “main” java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
ORA-04063: package body “APPS.FND_TRACE” has errors
ORA-06508: PL/SQL: could not find program unit being called: “APPS.FND_TRACE”
ORA-06512: at line 5

at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:462)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:397)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:389)
at oracle.jdbc.driver.T4C7Ocommoncall.processError(T4C7Ocommoncall.java:100)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:481)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:205)
at oracle.jdbc.driver.T4C7Ocommoncall.doOLOGOFF(T4C7Ocommoncall.java:64)
at oracle.jdbc.driver.T4CConnection.logoff(T4CConnection.java:583)
at oracle.jdbc.driver.PhysicalConnection.close(PhysicalConnection.java:5222)
at oracle.apps.edr.util.EDRXDOMigration.main(EDRXDOMigration.java:466)

We found the partial solution in MOS Doc. ID: 1959572.1, CustMigrationTool.class Error Upgrading from EBS R12.1.3 to R12.2 as the Connection Is Not Being Made In the 60 Seconds Defined In sqlnet.ora, which says that the connection couldn’t be made in the 60 seconds timeout value defined in sqlnet.ora, so the value needs to be changed to 120 seconds. To resolve the issue:
1. Change sqlnet.ora, SQLNET.INBOUND_CONNECT_TIMEOUT=120
2. Restart the db server
3. Restart the patch

However, that was not the only solution that was required. It turns out that using Recommended Patch Collections (RPC) creates objects that have a higher version than objects delivered by the 12.2.0 upgrade. This means the 12.2.0 upgrade will not replace objects with a higher version number and the upgrade fails. We had to find the correct versions of the code that worked together and then drop a trigger in order to get the FND_TRACE package body and specification to compile. Very interesting.
_____________________________________________________________

2. When running the “Configure the Instance” step, we couldn’t run AutoConfig on the database tier. This step is from the “Finish the Upgrade” section of the 12.2 upgrade guide on page 3-8.

We found MOS Doc. ID: 2117174.1, 12.2 Adop Cleanup Fails with Error “ETCC not run in the Database Node” After Running ETCC on the Database Node.

This note suggests that either the /etc/host file is not correctly formatted, or the nodes don’t match in the TXK_TCC_RESULTS table or the FND_NODES table. While this note is not a direct “hit”, we did find the domain was appended to the node_name. We updated the node_name in the TXK_TCC_RESULTS table to fix the issue:

update APPLSYS.TXK_TCC_RESULTS set node_name=’data2′ where node_name =’data2.ca.local’;

Email sherri@trutek.com to discuss pricing or schedule a time to have us help you with a First Pass Upgrade. We have completed the First Pass Upgrade in as few as three weeks, but it can take longer if we experience new issues. Please see our webpage for more information about our First Pass Upgrades consulting engagement. We also provide training to the rest of your managers, DBAs and development staff to help them understand the best practices of Online Patching.