DB Load fails with U00000002 EXISTS during upgrade
search cancel

DB Load fails with U00000002 EXISTS during upgrade

book

Article ID: 422611

calendar_today

Updated On:

Products

CA Automic Workload Automation - Automation Engine CA Automic One Automation

Issue/Introduction

During the upgrade of the initialdata, when running the db load (ucybdbld) utility, the load fails and throws an error:

U00000002 EXISTS

or

U00000002 VORHANDEN

Cause

This can happen during an upgrade when the db load of UC_UPD.TXT is attempting to load an object into client 0 that was already created, but has a different oh_idnr than it should.  For example, if a 21.0.0 system has UC_TRUSTEDCERTS created in client 0, an object that was not introduced until 21.0.7, but was created for some reason, it will be created something like oh_idnr 103180.  When the initialdata load for version 21.0.7 or higher is run, the load will:

Get the to the UC_TRUSTEDCERTS object which has a "reserved" oh_idnr of 50051
See if an object with oh_idnr 50051 already exists
Since it does not, it will attempt to insert an object called UC_TRUSTEDCERTS and oh_idnr 50051 into the system

Since an object called UC_TRUSTEDCERTS already exists, a database=4 trace on the load will show an error:

U00003592 UCUDB - Status: '' Native error: '1' Msg: 'ORA-00001: unique constraint (UK_OH_NAME) violated'

Resolution

The best way to resolve this issue is to restore the database to a working version/backup, log into client 0, and rename the object that shows up in the database=4 traces.  This can be found by:

  1. Set database=4 trace in the ucybdbld.ini file
  2. Run the db load, letting it error again
  3. Find the error:

    U00000002 EXISTS

  4. Look above that for the error about a unique constraint like:

    U00003592 UCUDB - Status: '' Native error: '1' Msg: 'ORA-00001: unique constraint (UK_OH_NAME) violated'
  5. Look above that error and find an insert statement.  Search above that for OH_NAME like and oh_idnr like:

    20251213/093013.896 - U00009909 TRACE: (BINDPAR:  OH_Name           )                                          0x7f0be4c7321f 000015
                                    00000000  55435F54 52555354 45444345 525453    >UC_TRUSTEDCERTS<
    ...
    20251213/093013.896 - U00009909 TRACE: (BINDPAR:  OH_Idnr           )                                          0x7f0be4c732e8 000004
    20251213/093013.896 -                                        >50051<

  6. Log into client 0 in the now-working system.  
  7. Rename the object shown in the OH_Name parameter above


  8. If you are unable to log into the system, open a case with Support and send the db load log and trace.  Also have your DBA run the following SQL statements against the Automic database and send the results:
    select oh_name, oh_idnr, oh_otype, oh_client from oh where oh_name like '%[OH_Name from trace]%';