Email retrieval extermely slow from vault

[Vlad2010]

I experienced quite issues with same client during server move to new harware.

Yesterday I moved SQL databases to new SQL server. What i did is backup Db and restore on new server. On new server created same name databases abd restore it using overwrite option.Fingerprint Db gave me an error b/c of ndf files, but I just restore it providing new name. No issues with that, but after SQL move mail retrieval extremely slow. Client uses Vault cache as well. No any error on Ev server.

Can you please point me what can wrong and if this can be because SQl move which I personally do not believe.

Thank you

[JesusWept3 · Accepted solution]

DTrace storageonlineopns and do some retrievals and see if you can spot any long running tasks, there is a line in there saying "elapsed time" which will give the amount of time in ms it took to complete the operations Also make sure that your SQL server is not being pegged either on CPU or caused by big disk queue lengths as well Also check things like firewall, antivirus, network connectivity and provider order and also do some more basic checks like how quick are the retrievals from different machines and using search.asp etc

[Vlad2010]

Thank you for info!

Ran dtrace and found elapsed time MAX value is 0.3 sec. SQL server looks good. CPU 2% and disk queue also good. No firewall, antivirus and networks seems good.

Just slow retrieval. No error in event log and client trace.

[Rob_Wilcox1]

So you mentioned that Vault Cache is involved? Retrievals of items for those people should be fast, right? The item they are retrieving should be in their vault cache. ... or are you using an online Outlook profile to test, without Vault Cache? Here is my suggestion... Online Outlook profile - and make sure that there is no vault cache involved. Enable maximum client logging Start Outlook Wait 5 minutes. Retrieve an item. Time it Wait 2 minutes. Retrieve the same item. Time it Close Outlook Post the client log. This will show whether there is a delay on the same item. If the second retrieval is very fast... then I would look at IIS timeouts on the EV server web site, and application pools. If the second retrieval is actually slow, then, lets look at the client log for the download request being sent, and the item being returned. We then may need to do the same tests again, but this time with DTRACE on the server side.

[Vlad2010]

Thank you all for help!

Issue solved. Data Domain was used and no DNS entry for new server created.