Migration large database 260 -> 4SP2

Comments

• Waldo Member Posts: 3,412

  2007-01-03

  Well, here are a few questions and tips:
  - If it is divided into companies, try to upgrade company per company.
  - I guess it's a Native server (no SQL Server?)? Well, you can put 50 CPU's and 32Gb RAM in the machine, it'll only use 1Gb and 1CPU. That's the main reason it's goes that slow. To start with, I would give the database server the full 1Gb RAM.
  - The database should be spread to seperate physical disks ... . In your case it's difficult to achieve, but consider this (or migrating to SQL Server). (http://www.mibuso.com/forum/viewtopic.php?t=2102&highlight=)
  - You can also start with a 'new implementation'. Then, you'll need to start with the open entries (instead of the history). If your customer still wants the history in the same database, then, you can also export it from the old db, and import it into journals and post. This is not really a "default" way to go... .
  
  I have a question: Which step(s) exactly take(s) so long?

  
  Eric Wauters
  MVP - Microsoft Dynamics NAV
  My blog
  

  0
• Iwan_Ubachs Member Posts: 19

  2007-01-03

  Thanks for your fast reply.
  
  The database is divided into companies, but the masterfile tables have the property data per company=No.
  
  The step which takes the longest time is the upgrade from the item ledger entries compressed by date.

  0
• Waldo Member Posts: 3,412

  2007-01-03

  Still, I would do it company by company... .
  
  For the rest, I don't know what you mean by "the upgrade from the item ledger entries compressed by date". What is it exactly that you do?

  
  Eric Wauters
  MVP - Microsoft Dynamics NAV
  My blog
  

  0
• Iwan_Ubachs Member Posts: 19

  2007-01-03

  There are 3 companies, one is very large and two other are much smaller. So, I think the benefit in this case is not that much.
  
  What I mean with "the upgrade from the item ledger entries compressed by date":
  
  The item ledger entries which are compressed by date.
  In particular these entries take a lot of time during the conversion.
  Why? We do not know....

  0
• Mbad Member Posts: 344

  2007-01-03

  Additional question. Does anyone know if the datecompressed posts are unpacked to create detailed posts?(here value entries). Im guessing no, but can someone confirm that?
  Anyways it will take a while regardless, to create the value entries.

  0
• cropredy Member Posts: 5

  2007-01-03

  Do you need all the Item Ledger entries ? Is it possible to compress the eldest one's by MONTH/YEAR.
  
  
  What's your item costing method, FIFO,average or standard ? Do you use automatic posting to G/L or Batch?

  0
• Iwan_Ubachs Member Posts: 19

  2007-01-03

  Do you need all the Item Ledger entries ? Is it possible to compress the eldest one's by MONTH/YEAR.

  
  There are already compressed by Year.
  

  What's your item costing method, FIFO,average or standard

  
  FIFO, posting in Batch.

  0
• kriki Member, Moderator Posts: 9,120

  2007-01-03

  You don't need all the indexes on the item ledger entry table and value entry table (doesn't exist in version 2.60). So delete (or disable) the ones you DON'T need for the upgrade (in both the 2.6 and 4.00 versions). Then when all is finished, you can import the the fobs WITH the indexes.
  
  This will be a lot faster. Because at a certain point Navision has to create the value entry records. If Navision has to maintain all indexes for each record it inserts, it takes a lot of time. It is a lot faster creating an index from scratch than maintaining an index.

  Regards,Alain Krikilion
  No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
  
  

  0
• DenSter Member Posts: 8,307

  2007-01-03

  Another suggestion:
  
  Have your solution center put all secondary keys of your biggest ledger tables into a keygroup. Before you run the upgrade process and/or the restore, go to database information and disable the keygroup. This should do what Alain is suggesting without having to do any object work, and should allow the processes to run much faster.
  
  Then after that is done, enable the keygroup, which should rebuild all keys. Do this after hours, because it'll probably run for quite a while.

  Daniel Rimmelzwaan
  RIS Plus, LLC

  0
• Captain_DX4 Member Posts: 230

  2007-01-03

  A huge warning for everyone suggesting to turn off keys:
  
  The company I was with ran a v2.60 native database sized at 100GB. Another developer decided to disable the keys, like is suggested here, to help a custom inventory revaluation process run more quickly. The company said the same as you that they could not withstand having the database offline for more than a weekend.
  
  The end result was the process ran very smoothly and quickly, to everyone's delight. But the developer hadn't tested the full process in testing, so by the end of running the live revaluation and we attempted to restore the keys, the reindexing of the keys took another 30 hours to process. The database was offline for all of Monday and some of Tuesday, and no contigency plan was in place for this oversight. This also caused much greater anxiety with the staff and management than if we had just left the keys active and told everyone that we would finish sometime Monday by lunchtime.
  
  Test the entire process from start to finish (including turning the indexes back on) before attempting this. You may end up taking longer when all is done.

  Kristopher Webb
  Microsoft Dynamics NAV Developer

  0
• Savatage Member Posts: 7,142

  2007-01-03

  I guess 1+ days is still better than your estimated 4+ days.
  Plus 33gb is less than 100gb
  and As Daniel said run if off hours rebuilding (or weekend is better).
  
  Gook Luck

  Harry Ruiz
  http://www.BiloBeauty.com
  http://www.autismspeaks.org

  0