• AndrewSQLDBA (2/19/2010)


    Instead of using a Maintenance Task, why not simply create an SSIS package that performs the backup. It is very simple to write a package. I have never relied on the "Maintenance Task"

    Use a "Backup Database Task" from the Maintenance Plan Tasks" toolbox section. You can use a T-SQL Statement task to perform things like Transaction Log truncation. You can then shrink the log file. You can then use the Check Database Ingtegrity Task to check the database Integrity, and use the Maintenance Cleanup task to delete older backup files. Then use the Execute SQL Task to log the success or failure to a Database Maintenance database table. After that, you can use the send mail task to inform yourself that the backup was successful.

    Much easier than these Maintenance Tasks I think. This will give you more control over each step and allow you to manually fire off any step if needed.

    Please you can schedule this to fire off when needed.

    Did you happen to verify the job performed without error before you began? When was the last time this fired off successfully? Instead of adding to one, just create a new one.

    Are you placing the backup files on the same box? If so, why even bother, if that box dies, so do your backup files. Have SQL place the backups on another drive on another box.

    You really only need to make a backup of the master when a new user is added, or a user is modified. You need to backup the MSDB only if a schedule is modified, or a SSIS package is added or modified.

    Andrew SQLDBA

    Using SSIS is basically the same as using SSMS maintenance plans. SSMS maintenance plans are just a subset of SSIS that can be run in SSMS (which means you don't have to install integration services if you don't want to).

    Granted, there are other things you can add in with SSIS that are not available to SSMS maintenance plans but I have not found that to be much more useful. In fact, I don't like hiding maintenance plans inside SSIS where it is harder to find them and manage them.

    Either way - this statement is just wrong:

    You can use a T-SQL Statement task to perform things like Transaction Log truncation. You can then shrink the log file.

    You should not shrink the log file on a scheduled basis - unless you want to cause performance issues for your systems. You should not truncate the log file (ever) - unless you want to prevent the ability to restore your system to a point in time.

    Jeffrey Williams
    “We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”

    ― Charles R. Swindoll

    How to post questions to get better answers faster
    Managing Transaction Logs