SQL server maintenance when using active backup - arkitex

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]

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).

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.

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

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.

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 2005. 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
declare @OldestDate datetime
set @OldestDate = getdate() -120
exec sp_delete_backuphistory @OldestDate
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: http://weblogs.sqlteam.com/geoffh/archive/2008/01/21/MSDB-
Performance-Tuning.aspx

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 884666 5992
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 1561.63 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 884666 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 147444 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.