CA Service Management

  • 1.  Table load on sd 17.1

    Posted Jul 09, 2018 03:47 AM

    Hi Team

     

    iam extracting following 2 tables  from sdm 12.9 and load it to 17.1 sdm but i can see error.  As i have few different custom columns in it which does not match in both the tables.. And i need 2 months tickets to move on 17.1 sdm from 12.9....no need activity log or event log etc.... . How can i achieve this?

     

     

    1.Call_Req

    2.Change_Request



  • 2.  Re: Table load on sd 17.1

    Posted Jul 09, 2018 07:51 AM

    Hi Aarmir,

     

    It is not recommended to copy tickets from one SDM system to another this way. There is a possibility that there will be conflicts with ticket numbers and\or record IDs. There are a lot of other tables that are referenced by the tables you mentioned and you are likely to have orphaned records and render the MDB corrupted as a result of broken data integrity.

     

    What you are trying to do is not supported. If you needed all that data exactly as from one SDM server to another, you should have done a proper in-place migration.

     

    ===

    Kind Regards,

    Brian



  • 3.  Re: Table load on sd 17.1

    Posted Jul 09, 2018 08:04 AM

    Hi Brain

     

    I totally agree with you here. but the customer want atleast 2 months ticket not all.... as i already told them the consequences earlier while implementing new sdm 17 and they were agree but now they want tickets for 2 months.

     

    Is there still possibility of ticket conflict as we have no ticket already in new sdm??



  • 4.  Re: Table load on sd 17.1

    Posted Jul 09, 2018 08:15 AM

    Hi Aarmir,

     

    As mentioned in my last note, if you do an extract there are multiple tables like ca_contact, act_log, not_log, prob_cat, etc that are being referenced by the call_req and chg tables. What are you going to do and address that referential integrity issue as the records will be referencing records that don't exist? How will you do your reports?

     

    If all you want is some record of those tickets, then using pdm_extract of the table as it is, is definitely the wrong approach and recipe for disaster for the reasons already mentioned. Put frankly, the concept of garbage in, garbage out...

     

    ===

    Kind Regards,

    Brian



  • 5.  Re: Table load on sd 17.1

    Posted Jul 09, 2018 08:36 AM

    I agree Brian, as i created the same categories n same contacts in new sdm...just wanted to move some tickets withour act log or not log etc....anyways

     

    Many thanks for your advise



  • 6.  Re: Table load on sd 17.1

    Broadcom Employee
    Posted Jul 09, 2018 08:56 AM

    HI Aamir,

     

    With disclaimers sete by Brain007, You may want to try this but at your own risk of losing the data with the new system not taking into consideration of the already existing data.

     

    Run the Archive rule on the old system, capture the data into a text file. Copy the related text files to the new system and load the data using pdm_load command.

     

    You may also want to edit the sequence number format as per below document, which might be handy in your case.

     

    https://docops.ca.com/ca-service-management/14-1/en/administering/configure-ca-service-desk-manager/establishing-support-structure/setting-up-your-ca-sdm-system/edit-a-sequence-number-format

     

    regards ,

    Maheshwar Kusuma.



  • 7.  Re: Table load on sd 17.1
    Best Answer

    Posted Jul 09, 2018 10:22 PM

    I would have thought the cleanest way to do this would be to do a 'swing box' migration.  But after you migrate the MDB from the original system to your r12.9 replica on the swing box, do an SQL 'delete from call_req where open_date < your start date'.  Do the same for change records.  Clean up act_log and chgalg at the same time.  Then run the in-place upgrade to r17.1.  Then migrate the upgraded MDB to your new r17.1 production instance.  And there you should be, with your records from the last 2 months, and everything else properly linked.  Your ticket reference numbers will follow along as you create new tickets.  The new custom columns for the upgraded MDB can be added after the migration, and the old custom columns that you don't want any more can be dropped using the documented procedure.

     

    Regards,

    James



  • 8.  Re: Table load on sd 17.1

    Posted Jul 10, 2018 05:58 AM

    I would endorse James' idea,except instead of using direct SQL to get rid of the records not needed, I would use 'Archive & Purge' instead, just to keep things neat ;-)

     

    ===

    Kind Regards,

    Brian



  • 9.  Re: Table load on sd 17.1

    Broadcom Employee
    Posted Jul 13, 2018 02:14 PM

    La-Qa 

     

    Do you have any additional questions regarding this topic?

    If not, please mark one of the provided answers as Correct so that this thread can be closed.