![]() That meant that there was something wrong with the permissions, the problem was, what? So it wasn’t the backups or copy failing. My first idea was, “Well, there’s no files!” Easy! Problem solved! Or not…the files were in the folder, and the number was even correct. The new server wasn’t processing the policy correctly. There aren’t a lot of examples on the web, so I try to provide as many as I can. This isn’t exactly how we do it, but it gets my point across and it provides a good example of how a moderately complex policy works using ExecuteSQL. Each folder should have a backup file for each database, except for TempDB. The dumbed-down policy checks a backup server, which has a folder named for each SQL server, to see if it has the correct count of backups. INSERT _dirtree result for easy policy evaluation 1=Pass if( # files = # dbs ) Insert DirTree results into a table variable to return a numeric resultĭECLARE TABLE (SubDirectory VARCHAR(250), Depth BIT, BIT) SELECT = ''\\BACKUPSERVER\BACKUP\'' CONVERT(VARCHAR(100),SERVERPROPERTY(''MachineName'')) ![]() In case you would like to implement something like this on your system, the dumbed-down condition of the policy is below: Simple enough, but in the past, this policy has been prone to permissions errors. The policy verifies that every SQL server has a backup file stored on a remote directory. Today we had a policy failure on a newly built SQL server. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |