Comments
Sort by recent activity
Hi Brian,
Thank you very much for your reply. The link provided has answered my questions.
Cheers
Rich / comments
Hi Brian,
Thank you very much for your reply. The link provided has answered my questions.
Cheers
Rich
Hi aaoudi,
I was forced to reboot the machine. I did this nearly 2 weeks ago. It seemes to have fixed the problem, however, it was about 2 weeks into the initial test before roll out to production that I started experiencing problems. It's getting close to the time lapse before this started happening so I'll post another to this thread to let you know how I get on.
Saying all this though, I did notice that the Server Agent Service was taking nearly all of the processor time prior to rebooting the machine. There were some replication jobs running, but nothing that you would expect to do this. Because the Server Agent service was busy this would then affect the SQL Backup app since I got an error suggesting that the Agent Service was not responding due to it not being started.
It's all still a mystery I'm afraid. I'm just hoping that the tests that I am running will not break again otherwise I'll have to consider not using RedGate backup s/w.
Rich / comments
Hi aaoudi,
I was forced to reboot the machine. I did this nearly 2 weeks ago. It seemes to have fixed the problem, however, it was about 2 weeks into the initial test before roll out to productio...
Thanks for the reply H. I'll do this.
Rich / comments
Thanks for the reply H. I'll do this.
Rich
Yes I have confirmed that Server Agent Serivce is running. The backups were happening fine for nearly 2 weeks without a problem. I then recieve the error message described in the previous posting.
As an aside, I also tried restoring a db to this sql server and it ran for about 24 hours before I cancelled it. I ran the script from QA and copied the script from the script tab in RedGate UI. However, when restoring the db to a different machine it worked fine. The sqb file is being restored over the network since all backups reside on a file server.
I have now replaced the redgate backup routines to the original sql server backup routines and these backups are working fine.
I have not yet restarted this sql server in question. I don't really want to have to restart this sql server every two weeks (if this is the solution) since this box does have a high availability within the organisation as well as being a pain in the neck.
Regards
Rich / comments
Yes I have confirmed that Server Agent Serivce is running. The backups were happening fine for nearly 2 weeks without a problem. I then recieve the error message described in the previous posting...
This response is to lionheart where you asked about detecting files of a certain age and deleting them. Very easy thing to do (see code below) - sorry about the format but you get the idea. Key is to use xp_getfiledetails Hope it helps Rich:
INSERT #tmpFileDetails
EXEC master..xp_getfiledetails @vchrBackupLocation
-- Determine whether the file is too old to retain
IF EXISTS
(
SELECT *
FROM #tmpFileDetails
WHERE
DATEDIFF(
day
,CASE WHEN LEN(LastWrittenTime) = 6 THEN
CONVERT(DATETIME,LastWrittenDate + ' '
+ LEFT(LastWrittenTime,2) + ':'
+ LEFT(RIGHT(LastWrittenTime,4),2) + ':'
+ RIGHT(LastWrittenTime,2))
ELSE -- Take into account when the time is not in the desired time formate from xp_getfiledetails function
CONVERT(DATETIME,LastWrittenDate + ' '
+ LEFT('000000',2) + ':'
+ LEFT(RIGHT('000000',4),2) + ':'
+ RIGHT('000000',2))
END
,GETDATE()
) >= @intRetainDays
)
BEGIN
SET @vchrCmdLine = 'del ' + QUOTENAME(@vchrBackupFolder + '\' + @vchrDatabaseName + '\' + @oFileName,'"')
EXEC @intErrorCode = master..xp_cmdshell @vchrCmdLine
END / comments
This response is to lionheart where you asked about detecting files of a certain age and deleting them. Very easy thing to do (see code below) - sorry about the format but you get the idea. Key i...