I've been having an issue with a DB restore to a SQL2005SP2 VM
RESTORE DATABASE RiskShield
FROM DISK = N'\\NYRSQLV1\DBBackup\RISKSHIELD.BAK'
WITH MOVE 'RISKSHIELD' to 'E:\MSSQL\Data\RISKSHIELD.mdf',
MOVE 'RISKSHIELD_Log' to 'E:\MSSQL\DBLogs\RISKSHIELD_Log.ldf',
Msg 3203, Level 16, State 2, Server STG_NYRSQLV1, Line 1
Read on "\\NYRSQLV1\DBBackup\RISKSHIELD.BAK" failed: 1130(Not enough server storage is available to process this command.)
Msg 3013, Level 16, State 1, Server STG_NYRSQLV1, Line 1
RESTORE DATABASE is terminating abnormally.
Made change to registry as recommended, but no help. Server has plenty of DASD, 4 processors, 3.5 GB of RAM, a reboot seems to resolve, so it seems to be a memory leak of some sort.
Seems like it is something with Double-Take having the .BAK file open, this is becoming a major burden. The odd thing it gets, 10, 20, 30 percent complete, then wham, message appears, and gets further completed as more time goes by until if I wail long enough, it eventually restores, the only thing that would have the file open is Double-Take for DR replication. It's just odd that DT would interfere with the restore when it is already in progress, unless it has a certain part of the file in use and when SQL restore hits that block (which DT has in use), it reports the message.
is there anyway I can have SQL wait for the file to be released, instead of it getting 90% done (2+ hours), then bombing out, and having to restart from square 1 again.
Will the CONTINUE_AFTER_ERROR option help in this case, it would be easier for me to just tackle the issue once the DB is restored, I don't really care about all data being spot on since it's a sandbox server.