Saturday, 24 April 2010

Check Backups on Multiple Servers

I've just finished the backup checking on my SQL Server Admin tool program so you can check the state of the server backups all from one screen as shown below.




I’ll explain what checks I do, when you click the “Check Backup Status” button it will go off and check the msdb tables for the most recent database backup for each table, it gets the time and size and location, the software will then attempt to go and find the backup file and check the size and date stamp against what is stored in the database as a kind of quick verify.

There’s also another button called “Verify Backup with SQL” what this will ask the SQL Server to runs a restore on the backup set with the VERIFYONLY flag set to make sure that the file is valid, all of this is done in a threaded environment so that there is no program hang and multiple servers can be checked at once.

Next task for the program is replication validation.

Tuesday, 20 April 2010

SQL Backup Logs

While working on the backup checking screen on my SQL Server admin app I had to come up with a few scripts to check on the state of the database backup list. After checking the systems tables I found that the database to use is MSDB which seems to hold information for backups, restore, broker, mail, Agent and maintenance plan metadata, it’s a good job to check out the tables and views in there for youself. After checking out the tables and figuring out the linking it appears that tables I need to concentrate on are backupset, backupmediafamily and backupfile and according to MSDN this is what they do.


dbo.backupset: provides information concerning the most-granular details of the backup process
dbo.backupmediafamily: provides metadata for the physical backup files as they relate to backup sets
dbo.backupfile: this system view provides the most-granular information for the physical backup files
OK So for a full list of database backups you can use this query


SELECT  
   CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server, 
   msdb.dbo.backupset.database_name,  
   msdb.dbo.backupset.backup_start_date,  
   msdb.dbo.backupset.backup_finish_date, 
   msdb.dbo.backupset.expiration_date, 
   CASE msdb..backupset.type  
       WHEN 'D' THEN 'Database'  
       WHEN 'L' THEN 'Log'  
   END AS backup_type,  
   msdb.dbo.backupset.backup_size,  
   msdb.dbo.backupmediafamily.logical_device_name,  
   msdb.dbo.backupmediafamily.physical_device_name,   
   msdb.dbo.backupset.name AS backupset_name, 
   msdb.dbo.backupset.description 
FROM   msdb.dbo.backupmediafamily  
   INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id  
ORDER BY  
   msdb.dbo.backupset.backup_finish_date,
   msdb.dbo.backupset.database_name

but this lists all the backups and I’m not really interested so the following SQL will give you the last backup for each database. As usual with these type of SQLs where you have to link on a subquery it’s pretty long.

SELECT  
   A.[Server],
   A.database_name,  
   A.last_db_backup_date,  
   B.backup_start_date,  
   B.expiration_date, 
   B.backup_size,  
   B.logical_device_name,  
   B.physical_device_name,   
   B.backupset_name, 
   B.description 
FROM 
   ( 
   SELECT   
       CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server, 
       msdb.dbo.backupset.database_name,  
       MAX(msdb.dbo.backupset.backup_finish_date) AS last_db_backup_date 
   FROM    msdb.dbo.backupmediafamily  
       INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id  
   WHERE   msdb..backupset.type = 'D' 
   GROUP BY 
       msdb.dbo.backupset.database_name  
   ) AS A 
    
   LEFT JOIN  

   ( 
   SELECT   
   CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server, 
   msdb.dbo.backupset.database_name,  
   msdb.dbo.backupset.backup_start_date,  
   msdb.dbo.backupset.backup_finish_date, 
   msdb.dbo.backupset.expiration_date, 
   msdb.dbo.backupset.backup_size,  
   msdb.dbo.backupmediafamily.logical_device_name,  
   msdb.dbo.backupmediafamily.physical_device_name,   
   msdb.dbo.backupset.name AS backupset_name, 
   msdb.dbo.backupset.description 
FROM   msdb.dbo.backupmediafamily  
   INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id  
WHERE  msdb..backupset.type = 'D' 
   ) AS B 
   ON A.[server] = B.[server] AND A.[database_name] = B.[database_name] AND A.[last_db_backup_date] = B.[backup_finish_date] 
ORDER BY  
   A.database_name

Of couse my app will be verifying the backups and the files produced so there’s more involved than the above but feel free to use it.

Friday, 16 April 2010

Executing SQLs across multiple servers

I've been working on a project to allow me to manage a few of my servers without having to pay each one attention in management studio. So this is a start, there's a lot more things I want to put in but for the moment it will allow you to execute SQLs across all your servers. Good for me since I have the same databases on loads of databases for the same application. I'll be posting a download link for it soon.




I also plan to implement some backup tracking / verifying, replication verification etc in later versions.

Thursday, 1 April 2010

SQL Server Failed Replication and odd behaviour

This is just really a note to the other DBAs out there since I spent half an hour on this issue only to find it was an illogical random problem, but if you can't be bothered reading my story the short hand version is If you are having issues with replication and getting errors concerning snapshot being out of date or not available before you try to go on the wild goose chase, try restarting the SQL Agent service first.

Anywho back to what happened, got a call from a client that the server had stopped replicating between London and Basra, so I got into the server and check the replication monitor, under the subscription it stated You must rerun snapshot because current snapshot files are obsolete. OK I thought and started the snapshot agent, off it went and came back a few seconds later stating A snapshot of 94 articles has been generated. Now this is a 27GB database so I know for a fact that it takes ages for the snapshot to come around, I messed around with folder permissions on the snapshot directory, all seemed fine, I delete the current snapshot and tried the agent again. A snapshot of 94 articles has been generated... LIES!

At this point I went into the Job Manager and ran the merge replication job to see what errors would come up in the history.. The Job failed. The owner of job() ..... does not have server access and that was what made me finally figure what it was. A while back I had the same issue after a power cut, for some reason if there is network failure the Agent has a heart attack and just stops working. Restarting the service fixes the problem.