SELECT p.name AS [Name] ,
r.type_desc ,
r.is_disabled ,
r.create_date ,
r.modify_date ,
r.default_database_name
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON p.principal_id = m.member_principal_id
WHERE r.type = 'R'
AND r.name = N'sysadmin'
Which is a heck of a lot easier than faffing about clicking things...
Monday, 30 December 2013
Tuesday, 10 December 2013
Oh what a horrible error!
RAISERROR('Error performing SQLBackup backup.', 16, 1)SQL Backup v7.3.2.12 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ERRSQB: 5240 (SQB service did not acknowledge receipt of data. (WAIT_TIMEOUT)) ()
And the log backups completely and utterly failed. Trawling round the internet gave me one post in a Red Gate Forum, and that looked scary. Removing mutex objects? Restarting the server (not exactly an option)?
However, simply restarting SQL Backup itself solved the problem. As to why it happened? I'm not sure. The cluster hadn't failed over, or received any patches. It might be co-incidence that I'd just applied the licence key after having run out of evaluation period. It might not.
We now have log backups again. Phew.
And the log backups completely and utterly failed. Trawling round the internet gave me one post in a Red Gate Forum, and that looked scary. Removing mutex objects? Restarting the server (not exactly an option)?
However, simply restarting SQL Backup itself solved the problem. As to why it happened? I'm not sure. The cluster hadn't failed over, or received any patches. It might be co-incidence that I'd just applied the licence key after having run out of evaluation period. It might not.
We now have log backups again. Phew.
Subscribe to:
Posts (Atom)