Hi all
We are planning to migrate to SQL our native database and are doing a few tests of performance, and are having a lot of problems. The biggest one we've seen is in restoring. When we try to restore a Company to an empty Navision SQL Database, it lasts for about 2 minutes. That's ok. But when there are already more companies, the time increases a lot. For example, when we restore the same company but with ten in the database, the restore time goes to 5 minutes, and when we have 50 companies, time goes to ours. As we have about 600 companies in our production database, this can be a great problem.
Anyone knows anything about obtaining a better performance, or what to do to obtain good results? Maybe we have something wrongly configured, but don't know what to look at, everything looks ok and the SQL Server works smoothly.
Thanks for your help.
0
Comments
May be you can try to divide it into seperate databases?
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
We will probably end up dividing the database, but even in that case the performance needs to be better.
Our SQL server has 4GB RAM, 4x 2GHZ processors and tons of disk space, so I don't think this can be the problem.
Are you using SQL backup or Navision backup?
May I ask why you have 600 companies?
Sorry for asking - I am just curiois about it
R.
But it's really driving me crazy!
(Careful, guessing follows...)
When the C/SIDE restore function restores a table in SQL, it first disables all indexes except the primary key, so that the table restore occurs at maximum speed. Then, when the table is restored, it re-enables the secondary keys, rebuilding them in the process. You can observe this behavior by following the progress dialogs during restore...
(Be even more careful... really wild guessing occurring now...)
It seems, however, that it is not just the indexes for the 'current' company that are being dropped/re-created. Instead, C/SIDE is doing the equivalent of a 'table re-design', which involves disabling and then re-enabling/rebuilding the alternate indexes for ALL companies... This explains (?) why restoring many companies one-at-a-time exhibits exponential runtime.
If this wild guess is correct, then there are two possible workarounds:
1) Don't restore one-at-a-time. It may be that restoring all companies at once will only do the alternate index rebuild once for all companies.
2) If you must restore one-at-a-time, then try the following:
We don´t plan to do the migration with one company at a time, the problem comes when the database is in production. Users usually backup companies, work with them locally, and then restore them in the server, thats why we need this to work ok.
If your guess is right I think we have a problem :?
I'll try something similar to your second workaround and see what I can do.
Thanks!
- You are using RAID 1 or 1+0 over many, smaller disks, right?
- You have configured your db space in multiple files, right?
- You are not relying on auto-grow, right?
[edit -- fixed busted links -- close-paren was incorrectly included in auto-link](see http://blogs.msdn.com/mat_stephen/archive/2005/02/02/365325.aspx)
(see http://blogs.msdn.com/Mat_Stephen/archive/2005/02/02/365370.aspx)
May you can think of dividing that one big database into seperate databases?
Companies that are not connecten to one way or another ... shouldn't be a problem ... .
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
We have only one datafile and we have auto-grow, so maybe this can be on of the problems. I'm going to do some more tests changing this.
Thanks again for your help!
Thanks to all for your help and advice anyway!
:-#
Standard Edition will use max. 2GB of RAM no matter how much you actually have installed. And there are other performance limits put on non-Enterprise Edition.
http://www.mibuso.com/forum/viewtopic.php?t=9228&highlight=
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n