Solved: Re: ISE 2.2 --> 2.4 URT fails at "Clone database config"

alex.fritzsche · ‎04-10-2018

Hi,

we want to upgrade to 2.4 and wanted to test this on a non production ISE(unlicensed).

The URT fails at 75% of the "Clone config database" with "Failed (Import onto clones database failed)

Logs show ok here:

Job "CEPM"."SYS_EXPORT_SCHEMA_02" successfully completed at Tue Apr 10 14:41:44 2018 elapsed 0 00:02:09

but failed:

...

. . imported "CEPM"."UPSWORKFLOW_ROLES" 0 KB 0 rows

. . imported "CEPM"."WCS_SSO_TOKEN" 0 KB 0 rows

Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT

Processing object type SCHEMA_EXPORT/TABLE/COMMENT

Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX

Processing object type SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_INDEX/INDEX

Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT

ORA-31684: Object type CONSTRAINT:"CEPM"."SYS_C0015154" already exists

ORA-31684: Object type CONSTRAINT:"CEPM"."SYS_C0015147" already exists

Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT

Job "CEPM"."SYS_IMPORT_SCHEMA_01" completed with 2 error(s) at Tue Apr 10 14:43:50 2018 elapsed 0 00:01:56

same but other log:

Tue Apr 10 14:43:17 CEST 2018 : . . imported "CEPM"."UPSWORKFLOW_ROLES" 0 KB 0 rows

Tue Apr 10 14:43:17 CEST 2018 : . . imported "CEPM"."WCS_SSO_TOKEN" 0 KB 0 rows

Tue Apr 10 14:43:17 CEST 2018 : Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT

Tue Apr 10 14:43:17 CEST 2018 : Processing object type SCHEMA_EXPORT/TABLE/COMMENT

Tue Apr 10 14:43:17 CEST 2018 : Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX

Tue Apr 10 14:43:34 CEST 2018 : Processing object type SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_INDEX/INDEX

Tue Apr 10 14:43:35 CEST 2018 : Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT

Tue Apr 10 14:43:43 CEST 2018 : ORA-31684: Object type CONSTRAINT:"CEPM"."SYS_C0015154" already exists

Tue Apr 10 14:43:43 CEST 2018 : ORA-31684: Object type CONSTRAINT:"CEPM"."SYS_C0015147" already exists

Tue Apr 10 14:43:43 CEST 2018 : Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT

Tue Apr 10 14:43:53 CEST 2018 : Job "CEPM"."SYS_IMPORT_SCHEMA_01" completed with 2 error(s) at Tue Apr 10 14:43:50 2018 elapsed 0 00:01:56

and last:

===========================================================

Tue Apr 10 14:39:41 2018

TABLE SYS.WRP$_REPORTS: ADDED INTERVAL PARTITION SYS_P1008 (3022) VALUES LESS THAN (TO_DATE(' 2018-04-11 01:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))

TABLE SYS.WRP$_REPORTS_DETAILS: ADDED INTERVAL PARTITION SYS_P1009 (3022) VALUES LESS THAN (TO_DATE(' 2018-04-11 01:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))

TABLE SYS.WRP$_REPORTS_TIME_BANDS: ADDED INTERVAL PARTITION SYS_P1012 (3021) VALUES LESS THAN (TO_DATE(' 2018-04-10 01:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))

Tue Apr 10 14:41:53 2018

DM00 started with pid=50, OS id=27934, job CEPM.SYS_IMPORT_SCHEMA_01

Tue Apr 10 14:41:56 2018

DW00 started with pid=51, OS id=27966, wid=1, job CEPM.SYS_IMPORT_SCHEMA_01

Tue Apr 10 14:42:18 2018

Thread 1 cannot allocate new log, sequence 2

Private strand flush not complete

Current log# 1 seq# 1 mem# 0: /opt/oracle/base/oradata/cpm11/redo01.log

Tue Apr 10 14:42:21 2018

Thread 1 advanced to log sequence 2 (LGWR switch)

Current log# 2 seq# 2 mem# 0: /opt/oracle/base/oradata/cpm11/redo02.log

Tue Apr 10 14:42:54 2018

Thread 1 advanced to log sequence 3 (LGWR switch)

Current log# 3 seq# 3 mem# 0: /opt/oracle/base/oradata/cpm11/redo03.log

Tue Apr 10 14:43:19 2018

The value (159) of MAXTRANS parameter ignored.

The value (167) of MAXTRANS parameter ignored.

Tue Apr 10 14:43:34 2018

The value (167) of MAXTRANS parameter ignored.

Tue Apr 10 14:43:42 2018

Thread 1 cannot allocate new log, sequence 4

Checkpoint not complete

Current log# 3 seq# 3 mem# 0: /opt/oracle/base/oradata/cpm11/redo03.log

Tue Apr 10 14:43:48 2018

Thread 1 advanced to log sequence 4 (LGWR switch)

Current log# 1 seq# 4 mem# 0: /opt/oracle/base/oradata/cpm11/redo01.log

Tue Apr 10 14:43:54 2018

Shutting down instance (immediate)

Stopping background process SMCO

Shutting down instance: further logons disabled

Stopping background process CJQ0

Stopping background process MMNL

Stopping background process MMON

License high water mark = 43

Tue Apr 10 14:43:57 2018

All dispatchers and shared servers shutdown

ALTER DATABASE CLOSE NORMAL

Tue Apr 10 14:43:58 2018

Stopping Emon pool

Tue Apr 10 14:43:58 2018

SMON: disabling tx recovery

Stopping Emon pool

Tue Apr 10 14:43:58 2018

SMON: disabling cache recovery

Shutting down archive processes

Archiving is disabled

Tue Apr 10 14:43:58 2018

Thread 1 closed at log sequence 4

Successful close of redo thread 1

Completed: ALTER DATABASE CLOSE NORMAL

ALTER DATABASE DISMOUNT

Shutting down archive processes

Archiving is disabled

Completed: ALTER DATABASE DISMOUNT

Tue Apr 10 14:43:59 2018

ARCH: Archival disabled due to shutdown: 1089

Shutting down archive processes

Archiving is disabled

ARCH: Archival disabled due to shutdown: 1089

Shutting down archive processes

Archiving is disabled

Tue Apr 10 14:44:01 2018

Stopping background process VKTM

Tue Apr 10 14:44:10 2018

Instance shutdown complete

hope someone can help troubleshooting.

BR!

Jason Kunst · ‎04-10-2018

You should be working through the TAC to help you troubleshoot and identify potential issues so proper defects can be logged if needed

View solution in original post

Jason Kunst · ‎04-10-2018

You should be working through the TAC to help you troubleshoot and identify potential issues so proper defects can be logged if needed

alex.fritzsche · ‎04-16-2018

As the ISE I took for testing the upgrade isn't productive, I upgraded it without the success of the URT.

The upgrade completed successfull without any issue and ISE 2.4 is great on the first glance.

eugeniodesideri · ‎01-07-2021

You will face the same problem if you upgrade from 2.1 to 2.4 and from 2.4 to 2.7 ,

is related to the hands-off on the ORACLE db under the hood.

It seems like some internal user ( or some listener ) still doing some sort of query.

The solution is to run an " application stop ise " followed by " application start ise"

this will unlock the database and let you continue with URT .

let me know if is work for you too.

I tried this trick with to 2 different deployment and other 2 upgrade process .

marce1000 · ‎01-07-2021

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvf83249/?referring_site=ss&dtid=osscdc000283

M.

-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

eugeniodesideri · ‎01-07-2021

unfortunatly the bug still present after patch 8 of ise 2.4 , and proceed with the upgrade (in my case) without stopping the ise application caused the db corruption ,and eventually led to an unstable state of the appliance .

But hey , maybe someone got more lucky than me , just sharing my experience.