locked
CRM 2011 to 2013 upgrade takes 4 days to complete RRS feed

  • Question

  • Hello, we are upgrading from 2011 to 2013 in the near future. So I created a test environment to do a test upgrade. However, the upgrade took 4 days. I repeated the test and found the same issue. It was stuck on "Remove sharing for workflowlog entity which was made a child entity" for a majority of the time.

    I have opened a case with Microsoft. Their response is "We've been seeing this among other systems but it is not an issue. It just takes time". Frankly I am absolutely stunned that they realize that there is an issue but will do nothing to fix it. 

    Are other people seeing this issue? We can't be down for 4 days to upgrade one damn system. How do we get the upgrade down to a few hours?


    Dan Chandler-Klein

    Thursday, June 12, 2014 9:33 PM

All replies

  • Hi Dan,

    Thank you for using Microsoft Forums and Communities. First of all I am sorry to hear about this issue and your current experience with MS Support in this regards. We have identified the Case number you have raised with us and we will internally review it to understand if we can further assist you.

    We will follow-up with you via the Support Request as soon as possible. Thank you for your patience and collaboration going forward.

    Nina Peneva

    Support Engineer

    Microsoft Dynamics CRM

    Follow EMEA CRM Support at https://twitter.com/MSDynCRMSupport


    Tuesday, June 17, 2014 2:12 PM
  • Hi Dan

    What is the size of your Database? When upgrading from CRM 4.0 to 2011 - clearing the Asyncoperationbase table can result in a significantly faster upgrade - The difference can be between hours and days - you should try it too:

    http://support.microsoft.com/kb/968520


    Please vote if you find my post helpful - Thanks

    Wednesday, June 18, 2014 6:29 AM
  • We have already ran that script to bring down that database. Our database is currently 63GB. Here is a snapshot of the largest tables in our database.


    Dan Chandler-Klein

    Thursday, June 19, 2014 2:19 PM
  • That's a lot of records in the PrincipalObjectAccess table. This table stores the information about record sharing, and the step that's taking the time in the upgrade also relates to sharing.

    It'd be intersting to know the breakdown by entity of the records in PrincipalObjectAccess - you could use the following query:

    select e.name, p.ct
    from 
    (select objecttypecode, count(*) as ct from PrincipalObjectAccess
    group by objecttypecode) p join EntityAsIfPublishedLogicalView e on p.objecttypecode = e.objecttypecode
    order by ct desc


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Thursday, June 19, 2014 2:55 PM
    Moderator
  • I am currently running the script located here: http://support.microsoft.com/kb/2664150/en-us against our test database and then will run an upgrade to see how long it takes.

    Here is the result of that command. It looks like a large portion of that is related to the workflow logs. FYI, when we ran the script located here http://support.microsoft.com/kb/968520 it reduced our database by 100GB. Not sure if that makes a different.



    Dan Chandler-Klein

    Thursday, June 19, 2014 3:22 PM
  • I agree that the size of some of your tables is a bit out of whack, but do you know if you are performing the table merge that happens as part of the 2013 upgrade? (Merging the entity table with it's 'Base' table). This requires significant space, I have heard that it could take up to twice the size, requiring that you have ~189 gig for your upgrade.

    I would clear out what you can, but this change might save you some time.

    Friday, June 20, 2014 8:11 PM
  • I'm sorry I'm not really following your question. When I did the upgrade, I just accepted the default settings. I didn't see any option about merging any tables. When we upgraded, I also didn't notice the database growing in size either. The log grew a bit, maybe a gigabyte at most.

    Dan Chandler-Klein

    Friday, June 20, 2014 8:14 PM
  • Hi Dan,

    You found the solution to make the process faster? Or, you had to be limited only to wait for the process to finish without matter how long this take?

    I'm having the same problem at the moment, we have a CRM 2011 Database from 700GB we are trying to upgrade to CRM 2013. In a first attempt the upgrade process is stalled for 3 days in "Verbose | Removing sharings for WorkflowLog Which entity was made to child entity ". We decided to stop the update, we think that maybe the database was corrupted. Now, we restart the process and we see that it has stalled  there in the same state and leads one day. This, obviously, we are doing in a test environment.

    If we can complete the upgrade to CRM 2013, we then should upgrade to 2015. our concern is that this taken a lot of days from CRM 2011 to CRM 2013 , and then occur the same updating from CRM 2013 to CRM 2015.

    I appreciate your response or assistance.

    Paul

    Friday, January 29, 2016 2:26 PM
  • Paul-

    I would highly suggest TZ00K1's suggestion above. Your wokflow logs and AsyncOperationBase tables are probably enormous. Can you post a report of your largest tables in the db?

    http://support.microsoft.com/kb/968520

    Friday, January 29, 2016 2:40 PM
  • Hi James,

    This are my tables on CRM 2011 Database:

    Tablas CRM


    Thanks a lot for your help,

    Paul


    Friday, January 29, 2016 8:32 PM
  • Paul-
    Some of those tables are HUGE. I would suggest some quick maintenance on them.

        • You have auditing enabled in CRM. You need to delete (through the ui) the old audit logs. It looks like you have 120 gig of audit logs. If you don't need auditing, I would turn it off or at least modify the number of entities and fields it is auditing.
        • Deleting old activities via the bulk delete will get rid of lots of the Activity pointer data, and the associated activity data.
        • Deleting any records will help to bring your PrincipalObjectAccess table in check.
        • You have 185 gig worth of old workflow and async job logs. Look over the info at http://support.microsoft.com/kb/968520 it will help.
  • I've never seen a CRM database at 700 gig. I would think with some good maintenance you should be able to drastically reduce the size. Do you really have 9 million opportunities and almost 4 million invoices?
  • I would suggest putting off your upgrade until you are able to get the size reduced significantly. The items above will help, but it looks like a data retention plan should be put in place as well.

Friday, January 29, 2016 8:47 PM
  • In addition to the suggestions to delete old data, you have some other worrying issues that might break the upgrade:

    • You have a different number of records in the Base and ExtensionBase tables for the Opportunity and Invoice entities. This should not happen if all data modification has been done in a supported way via CRM, and my suspicion is that there has been some direct SQL updates to cause this. The upgrade process combines the Base and ExtensionBase tables, and I wouldn't be surprised if it would throw errors with the current mismatch of records
    • You have some tables that are non-CRM tables. Almost certainly all tables beginning with a lowercase letter are non-CRM tables, and the upgrade may well fail because of these 

    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Saturday, January 30, 2016 7:01 PM
    Moderator