November 7, 2008 at 8:27 am
Hello,
I'm having a LogShipping issue that have found no explanation so far!
I Have a SQL Server 2005 with a 2,5 TB database configured for logshipping.
Firstly the logship job was configured to leave the secondary database in StandBy mode after apply the logs, this config was working fine but now it's very very slow. Each log (300 MB AVG) has taking 1 or 2 hours to apply.
The logs has already copied to the secondary server storage (4G Fiber 15K) disk.
Looking at SQL server I saw that my restore SPID is SUPENDED and the SPID has an IO_COMPLETION wait type.
My suspect was that the storage is bad configured, but I Checked and its ok and it's performance also is fine.
After I searched troubles in the storage I started to investigate the perfmon and there are almost no Disk activity.
After all I did a Test restoring the logs manually using the option 'NORECOVERY' instead standby and for my surprise each log took 1 or 2 minutes to be recovered.
In conclusion, I was wondering to know why the STANDBY option takes too long to restore? May be because the .TUF File?
Has anybody seem something like that?
Best regards
Eduardo
November 7, 2008 at 9:05 am
It sounds like it just flaked out. AFAIK, the restore with standby should not take much longer than a restore with norecovery.
Perhaps you have transactions open in the secondary database that are blocking the restore from going?
November 7, 2008 at 10:45 am
Perhaps you have transactions open in the secondary database that are blocking the restore from going?
Make sense, but no body can connect to this database, and this occur when the restore already started. Also the .tuf file is very small.
There are big transactions in my primary database(SAP) and this is a VLDB (2,5 TB), may be this the reason, but why this occur only with the "STANDBY" option?
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply