CA Service Management

 View Only
  • 1.  Migration from SD r12.5 to r12.9

    Posted Jun 11, 2014 05:42 AM

    Hi All,

    We are facing lot of errors migrating Service Desk from r12.5 to r12.9. We have run successfully Query( SQLCheckr12UniqueIndexes) and removes all duplicates but still We are facing errors like some columns are already built in the MDB database and Migration console tries to create same column and index for the same. We also tried to drop each column one by one after looking into the logs of migration but still its giving errors of same type

    ( Update sql failed:ALTER TABLE ca_company ADD tenant binary(16)

    06-06,14:23:38 DEBUG - Column names in each table must be unique. Column name
    'tenant' in table 'ca_company' is specified more than once. )
    Do you have any idea how to remove these errors without dropping the columns which CA Service desk r12.9 DVD wants to create?
    Is there any patch for the same?
    Also are anyone facing same problem or running Migration DVD smoothly.


  • 2.  Re: Migration from SD r12.5 to r12.9

    Posted Jun 25, 2014 02:02 AM

    Hello Mayur.malhotra,

     

    Could you edit your original post and flag this to a particular Place/Category, and add some Tags?

    It will get more relevant views that way.

     

    Sorry for the delayed response - no SDM people were monitoring the general query space at the time.

     

    Thanks, Kyle_R.



  • 3.  Re: Migration from SD r12.5 to r12.9

    Broadcom Employee
    Posted Jul 01, 2014 09:32 AM

    Hi Mayur,

     

    Normally, duplicates are cleaned up by the SDM admin with the knowledge of table content (ie., what's the duplicate record, how many other related records might be using that etc)  in conjunction with the DBA's help.

     

    In this case, my guess is you have already have a column called Tenant in the ca_company table.  If you're not using tenancy, a quick solution could be to drop that column  and then re-run the mdb upgrade again. It'll add the column as part of the upgrade process.  A better option might be to raise a support ticket about the same so that one of the engineers can better understand the scenario and provide an appropriate resolution.


    Hope this helps

    _R



  • 4.  Re: Migration from SD r12.5 to r12.9

    Posted Jul 02, 2014 12:36 AM

    Hi Mayur,

     

    In addition to what Raghu had mentioned, you may take a backup and then drop the column. Similarly, if you see any errors with the indexes, take a backup of index query and then drop the indexes to rerun the migration. The file SQLCheckr12UniqueIndexes contains queries to identify duplicates for few important tables such as severity, impact etc. You may build similar queries on other tables to identify the duplicates. For example, to identify any duplicate userids in ca_contact table, run the following query against the mdb database:

     

    SELECT userid, COUNT(userid) AS NumOccurrences

    FROM ca_contact GROUP BY userid

    HAVING ( COUNT(userid) > 1 )

     

    Thanks,

    Naveen



  • 5.  Re: Migration from SD r12.5 to r12.9

    Broadcom Employee
    Posted Jul 02, 2014 01:40 AM

    Hi Mayur,

    You may check for the duplicate as per Naveen comment, and then run these below command to verify if the time stamp are same as  compared to upgraded box.

    select * from mdb_schema_information where FileName LIKE 'ca_comp%'

    select * from mdb_schema_information where FileName LIKE 'attmnt%'

     

    Reviewing the complete migration log will help to derive the cause of it.

     

    ~Vinod.



  • 6.  Re: Migration from SD r12.5 to r12.9
    Best Answer

    Posted Jul 03, 2014 02:42 AM

    Thanks Vinod, The issue has been resolved now as the issue was in the timestamp in MDB_SCHEMA_INFORMATION .

     

    Regards

    Mayur



  • 7.  Re: Migration from SD r12.5 to r12.9

    Posted Jul 10, 2014 12:22 AM

    Thanks for letting us know.

     

    As you've commented that this is resolved, I've marked this Discussion as having a "Correct Answer."

     

    Thanks, Kyle_R.