Upgrading from 2.60F to 5.1

mromero

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

danlindstrom

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

kriki

[Topic moved from Navision DOS forum to Navision Financials forum]

mromero

danlindstrom wrote:

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

mromero

Hello again,

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

](*,)

Regards.

Miguel

mromero

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?

Thanks in advance.

Miguel.

ara3n

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.

mromero

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.

ara3n

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.

mromero

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 is the fdb (50 G size). Sorry my inexperience but what is the difference between that configuration and if drive will be in RAID?

Regards

ara3n

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.

mromero

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.

ajhvdb

Please do a search on this forum. After 1 hour of (re)search you now all.

David_Singleton

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 is the fdb (50 G size). Sorry my inexperience but what is the difference between that configuration and if 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).

mromero

David Singleton wrote:

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).

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_Singleton

mromero wrote:

David Singleton wrote:

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

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.

mromero

David Singleton wrote:

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_Singleton

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.

mromero

David Singleton wrote:

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>