SQL server maintenance when using active backup.

Transcription

1 SQL server maintenance when using active backup. SQL Server maintains a set of tables in the msdb database that stores details of all backups and restores that have been done over time. It generally remains small in size except when you are running :Arkitex Director in an active backup environment. In this case, the engine creates a backup of all of the Arkitex databases every x number of minutes (interval defined in system setup) and you can imagine that this creates a lot of entries in the msdb system database. The different tables that store these details are: Backupset Backupfile Backupfilegroup (SQL Server 2005 upwards) Backupmediaset Backupmediafamily Restorehistory Restorefile Restorefilegroup Logmarkhistory Suspect_pages (SQL Server 2005 upwards) Usefull SQL queries To get an idea about the kind of data saved by the SQL server: SELECT [backup_start_date],[backup_finish_date],[database_name],[server_name],[collation_name] FROM [msdb].[dbo].[backupset] ORDER BY [backup_start_date] Count the number of database backup or restores: SELECT FROM COUNT(*) AS Expr1 [msdb].[dbo].[backupset]

2 Setting up a new SQL server maintenance task SQL server 2005 Open the SQL server management studio and browse to Management\Maintenance Plan. Right click on Maintenance Plan and select to create a New Maintenance Plan. Fortunately, cleaning backup/restore history is already build-in into the SQL server. Select the task in the Toolbox at the left hand bottom corner and drag it onto the empty window at the right hand side. It might also be a good idea to shrink the database after it is cleaned. Drag a Shrink Database Task to the window on the right hand side. Connect both of the maintenance tasks: select the icon representing the history cleanup. You will now see a green arrow appearing. Select this green arrow and drag it onto the maintenance task that you want to de next (in this case the shrink database task).

3 Each of these tasks will have to be configured before it can be used (see the red icon inside the task). Right click on the History Cleanup Task and select Edit. In this example I decided to keep 2 weeks of backup/restore information in the msdb database.

4 Edit the Shrink database task. Here you can decide to shrink all of the databases or just a single one (msdb).

5 Setup the Job Schedule Properties. You should clean up this backup/restore history out of production hours! During this cleaning task, the sql server holds exclusive access to the msdb database and you might see sql errors in the Arkitex Client error list when the engine creates a new set of backupfiles. This error only indicates that SQL server was unable to add this new information inside the msdb database. There s no danger whatsoever that you are loosing data. The backup file set should normally be created without any problem. Right click on the tab and select to Save Selected Items in order to save this new scheduled maintenance task.

6 The new task will now show up in SQL Server Agent\Jobs. Needless to say that the SQL server agent service needs to be running when scheduling maintenance tasks. In SQL 2000 Note that the previous procedure is only valid when using SQL server It will not work on the old SQl server 2000 for the simple reason that there is no such thing as a history cleanup task. A possible solution would be to run the following SQL server commands. These commands will purge the history older then 120 days: use msdb go datetime = getdate() -120 exec Watch out!! I have tried this and during my tests I only purged out one (1) single day of backup/restore data and it took about 10 minutes!! Purging out months or years of backup/restore history would take an incredible amount of time (hours to days) and meanwhile it would block the usage of the msdb database. Best practice would first be to find out how long it takes to purge out a single day of backup/restore history. See the examples of SQl queries that I described earlier for finding out the oldest entry in the database. You can then use the following code for purging out a history older then a specific date. Purge history older then 20/8/2011 use msdb exec sp_delete_backuphistory '08/20/2011' The reason that is taking such a long time is that SQL 2000 is not having indexes on the tables in the msdb database. You could manually add indexes but I have never tried it. There s enough information on the internet that can give you some assistance in this matter. See also: Performance-Tuning.aspx

7 Initializing the Arkitex databases will NOT bring down the size of the msdb database. This msdb is a system database and not an Arkitex database. Initializing the Arkitex database is not going to wipe out the info out of the msdb database. Some facts before and after cleaning. Before cleaning After cleaning (kept 1 week) of history Number of lines in msdb Msdb properties (db size) 1561,63 Mb 1569,56 Mb Msdb properties (db size free 135,78 Mb 626,79 Mb space) Manually shrinked msdb after Mb 167,50 Mb running the maintenance task (db size) Disk Free space (windows) 27,3 Gb 26,3 Gb In my case I had a SQL server that made database backups (used a SQL query to find out). Arkitex creates 6 backup files each time (one for each of the Arkitex databases). This means that the engine created about sets of database backup files and this happened every 10 minutes. This learned me that in total, this server did production for about 1023 days. These numbers will give you a pretty good idea of the amount of data that is kept during 2 or 3 years of production (rule of thumb might be a 500 Mb per year). The automatic shrink didn t quite work out as I expected it to be. In fact, it didn t shrink the database at all. No idea yet what was going on but I then decided to do a manual shrink. This brought the size of the database down from 1561,63 Mb to 167,5 Mb.