Upgrading from 2.60F to 5.1

mromeromromero Member Posts: 20
edited 2008-09-24 in Navision Financials
Hello there,

I´m from Spain and I´m upgrading from 2.60 to 5.1 and I must to migrate previously to 4.0 SP3. The problem is that in the "Transfer Data" step in stage 1 the speed is too slow. It is spending DAYS to do the task.

Table 32 is huge, more than 5 millions of registers.

Please, could you tell me how can I reduce the time cost of this task?

I have read something about keys, state indicator and so on, but nothing seems to work. Therefore I can´t find a clear explanation about how must I do the changes.

I´m desperate and the time goes by......

Thans in advance.

Miguel

Comments

  • danlindstromdanlindstrom Member Posts: 130
    Have you checked the document w1w1upgr.pdf for Nav4sp3 page 57 and inserted keys for serialno and/or lotno?
    Have you changed the setting for 'DBMS Cache (KB)' in the client you are using for 'data transfer' upto your computers free memory and not exceeding 1GB
    Regards
    Dan Lindström
    NCSD Navision 2.00 since 1999 (Navision Certified Solution Developer)
    MBSP Developer for Microsoft Dynamics NAV 2009
  • krikikriki Member, Moderator Posts: 9,110
    [Topic moved from Navision DOS forum to Navision Financials forum]
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!


  • mromeromromero Member Posts: 20
    Have you checked the document w1w1upgr.pdf for Nav4sp3 page 57 and inserted keys for serialno and/or lotno?
    Have you changed the setting for 'DBMS Cache (KB)' in the client you are using for 'data transfer' upto your computers free memory and not exceeding 1GB

    Hello,

    Thanks a lot for your response.

    Yes, I have inserted the keys in table 32 but I haven´t changed DBMS Cache, I´ll try it and I´ll tell you the result.

    Miguel
  • mromeromromero Member Posts: 20
    Hello again,

    I´m sorry but it doesn´t seem to function. It´s very, very, very slow.

    ](*,)

    Regards.

    Miguel
  • mromeromromero Member Posts: 20
    Hello again,

    Finally nothing seems to work, it is spending an amazing amount if time to complete the "Transfer Data" task. :(

    I have done these changes, following the recomendations of users:

    1.- Add keys "Item No., Serial No." and "Item No., Lot No." in table 32.

    2.- Change "DBMS Cache" in "Tools -> Options" to value 500000

    3.- I have read codeunit 104045, that is containing in "Upgrade260400SP3.1.fob", but nothings seems to be wrong.

    4.- I have changed the refresh times in methods "Update" and "UpdateWindow" in table 104037 (State Indicator).

    Remember that I´m still in Stage 1, moving the data to temporary tables.


    Anybody can help me in other way? :cry:

    Thanks in advance.

    Miguel.
  • ara3nara3n Member Posts: 9,256
    I've mentioned it in the other website, that if you are not using bins, you can remove some of the code that deals with bins. This improves the performance a lot.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • mromeromromero Member Posts: 20
    ara3n wrote:
    I've mentioned it in the other website, that if you are not using bins, you can remove some of the code that deals with bins. This improves the performance a lot.

    Hello Rashed,

    Thanks again for your respose, but as I told in the other website, it uses bins, the field "Bin Code" is filled in all the entries and with different values.

    Regards.
  • ara3nara3n Member Posts: 9,256
    On what kind of hardware are you running this?

    I did an upgrade on regular hardware and it took several days.

    Ran it on server RAID one and it took around 6 hours.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • mromeromromero Member Posts: 20
    ara3n wrote:
    On what kind of hardware are you running this?

    I did an upgrade on regular hardware and it took several days.

    Ran it on server RAID one and it took around 6 hours.

    It´s a regular server, Xeon 2 Core with 2 Hard Disks. In C: is the SO and in D: is the fdb (50 G size). Sorry my inexperience but what is the difference between that configuration and if D: drive will be in RAID?

    Regards
  • ara3nara3n Member Posts: 9,256
    nav processes are very Hard disk intensive. Get a server that is RAID 10 or RAID 1.
    Get as many disks and spread the 50 gig accross the drives.

    I'm sure you are aware that you can have mulitple fdb for a nav database.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • mromeromromero Member Posts: 20
    No, sorry, it´s my first notice about it. Could you explain me how can I spread the DB or tell me where can I find a document that explain it?

    Many thanks.
  • ajhvdbajhvdb Member Posts: 672
    Please do a search on this forum. After 1 hour of (re)search you now all.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    mromero wrote:
    ara3n wrote:
    On what kind of hardware are you running this?

    I did an upgrade on regular hardware and it took several days.

    Ran it on server RAID one and it took around 6 hours.

    It´s a regular server, Xeon 2 Core with 2 Hard Disks. In C: is the SO and in D: is the fdb (50 G size). Sorry my inexperience but what is the difference between that configuration and if D: drive will be in RAID?

    Regards

    I would do the following:

    Get 10 drives and configure them as 5 x RAID0 arrays of 2 drives each. Split the database into 5 parts and spread it across each array (so you will have 10 spindles, but no redundancy). Do the upgrade. Then once the upgrade is done, backup the FDB files, and then reconfigure the RAID0 to 5 x RAID1 and put the fdb files back. (Now you will only have 5 spindles, but with redundancy)

    (Actually thats not true, what I would really do is upgrade to SQL, but I guess thats not an option here). :mrgreen:
    David Singleton
  • mromeromromero Member Posts: 20
    edited 2008-09-18

    I would do the following:

    Get 10 drives and configure them as 5 x RAID0 arrays of 2 drives each. Split the database into 5 parts and spread it across each array (so you will have 10 spindles, but no redundancy). Do the upgrade. Then once the upgrade is done, backup the FDB files, and then reconfigure the RAID0 to 5 x RAID1 and put the fdb files back. (Now you will only have 5 spindles, but with redundancy)

    (Actually thats not true, what I would really do is upgrade to SQL, but I guess thats not an option here). :mrgreen:

    Thank you David,

    The final target is upgrade to Nav 5.0 SP1 on SQL, but first I must to upgrade it from 2.60 native to 5.0 SP1 and then restore a fbk on SQL, isn´t it?

    Supposing that I can get 10 drives, how can I split the current fdb, is it possible or I must to create a new splitted fdb and then restore fbk on it?

    Regards.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    mromero wrote:

    (Actually thats not true, what I would really do is upgrade to SQL, but I guess thats not an option here). :mrgreen:

    Thank you David,

    The final target is upgrade to Nav 5.0 SP1 on SQL, but firts I must to upgrade it from 2.60 native to 5.0 SP1 and then restore a fbk on SQL, isn´t it?

    Suposing that I can get 10 drives, how can I split the current fdb, is it possible or I must to create a new splitted fdb and then restore fbk on it?

    Regards.

    Well if the plan is to move to SQL, then I would plan to move to SQL first. In that case use the 10 drives as one big RAID0 array (basically stripe the 10 drives) to do the conversion. Then when the conversion is done, move the MDF file and reconfigure the drives as a RAID 10 array (for the redundancy). Also you are going to need a big fast drive for the log file as well.
    David Singleton
  • mromeromromero Member Posts: 20
    Well if the plan is to move to SQL, then I would plan to move to SQL first. In that case use the 10 drives as one big RAID0 array (basically stripe the 10 drives) to do the conversion. Then when the conversion is done, move the MDF file and reconfigure the drives as a RAID 10 array (for the redundancy). Also you are going to need a big fast drive for the log file as well.

    Hello David,

    Thanks a lot for your suggestion, I´ll try it.

    Regards.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    Good luck.

    Keep in mind that no matter what you want to say about RAID arrays, RAID 0 is allways the fastest, but there is ZERO redundancy. So RAID 0 is only to do the conversion, NOT for live.
    David Singleton
  • mromeromromero Member Posts: 20
    Good luck.

    Keep in mind that no matter what you want to say about RAID arrays, RAID 0 is allways the fastest, but there is ZERO redundancy. So RAID 0 is only to do the conversion, NOT for live.

    Thanks a million, David. I´ll keep it in mind.

    =D>
Sign In or Register to comment.