Hi, I am getting a strange behaviour when I try to restore a 800MB backup file using stsadm. Before that, just some introduction to my dev and production environment:My Dev environment has only 2 servers -1 of them is MOSS, and the other one is SQLMy Production environment has4 servers - 2 MOSS, and the other2 is SQL (cluster)And the production environment has a more powerful hardware spec.I am using the below stsadm command to restore the site:stsadm -o restore -filename C:\SiteBackup.bak -url http://sharepointIt will take ~15 minutes to complete the restore on the dev environment. However it took > 20 HOURS to for the restore to complete our the production server! Another weird thing is, I have created a console app to loop thru all sites in a site collection to update a setting in the document library. It will take 15 minutes to complete on dev, but 4 hours on production. However there is no major performance when I browse thru the site on production (the response time is heaps faster than the dev environment)Could anyone shed some light here?We actually ran into a big outage yesterday because we underestimate the time to restore a site on production. Thanks,WilsonWilson | SharePoint Egg's Blog

Hi Magnus,Thanks for your reply. I don't quite understand, could you please explain more about the name lookup issue. Is it the case that the wfe is taking a long time to resolve the location of the DB server? How do it identity this is the problem? Should i run SQL profiler (sorry, I am not a Infra guy and sql guy...)Thanks,WIlsonWilson | SharePoint Egg's Blog

Hi Wilson, Are there any other SQL instance running on that production? IF so, try to provide the sharepoint SQL instance with more priority.. Check for the performance of the server through the task manager... and see if there is anyreflection in % usage in CPU for any IO intensive sharepoint operation...I believe, Its the problem with the SQL installation on the server which may be the root cause..hope this helps...

Hi, Sorry haven't got time to get back on this thread. I was busy and forgot about this. I was able to resolve the problem. The cause of the problem was the MTU (Max Transfer Unit?) that was set on the hardware/network infrastructure (not 100% sure, as this was told by the server team, and I don't have any knowledge on hardware...). Once they increased the MTU, everything works perfectly! Hope this help. Wilson | SharePoint Egg's Blog