241 Chapter 19: Create and Modify Maintenance Plans Using the Designer It has been quite a long journey through the Designer to get to the point where we are ready to design, create, test, and schedule a full Maintenance Plan. In this chapter, we'll walk through the full process of creating from scratch, and deploying, a Maintenance Plan that could be used to perform the following essential database maintenance tasks: • back up database data and log files • run regular database integrity checks • perform index rebuilds • delete old data from the msdb database • remove old backup and report files that are no longer required to be stored on the local server • notify the designated operator should one of the tasks fail. While the example does perform many of the essential maintenance tasks, it's not intended as a "template" for how to create Maintenance Plans, nor does it cover all the necessary maintenance tasks. The exact nature of a Maintenance Plan will always depend on the exact nature of your business and administration needs. You must establish exactly what your Maintenance Plans need to achieve, and then implement them appropriately, using the available options that best meet your needs. Establishing Your Maintenance Goals Before you can create a Maintenance Plan for your SQL Server instances, you have to first establish what you want to accomplish. Based on established goals, the DBA must create Maintenance Plans that include the appropriate tasks, appropriately configured and scheduled, to meet these goals. Chapter 19: Create and Modify Maintenance Plans Using the Designer 242 To some extent, these goals will be established at an organizational level. For example, tolerance towards potential data loss should be established at a business level and on a system-by-system basis. This, in turn, will dictate the DBA's maintenance policy in regard to the nature and frequency of database backups in his or her Maintenance Plans. Elsewhere, the nature of the plans will be guided by the DBA's knowledge of a given system, of its databases, the data they contain, how that data is queried, how indexes are used, and so on. However, all plans must start somewhere and, if you don't have all the information available to make an informed decision, you'll need to create the plans using the data and knowledge you do have available, and then monitor them. As your knowledge of a system grows, so your plans can evolve and become more ecient. What's most crucial is that these essential maintenance tasks do get performed on a regular basis. Following is an example list of the objectives of a Maintenance Plan designed to maintain the AdventureWorks database on a SQL Server instance. • Once a day, use the Back Up Database task to perform a full backup on the AdventureWorks database. • Every hour, use the Back Up Database task to perform a transaction log backup on the AdventureWorks database. • Every Sunday, during a scheduled maintenance window, perform the following tasks: • Run the Check Database Integrity task • Run the Rebuild Index task • Run the History Cleanup task, deleting files older than 1 week • Run the Maintenance Cleanup task as follows: • Delete BAK files older than 2 days • Delete TRN files older than 2 days • Delete report text files older than one week. • If any of the previously listed tasks should fail, execute the Notify Operator task to immediately send an e-mail that tells the operator what task failed. • If any of the tasks fail, stop the execution of the Maintenance Plan so that any subsequent tasks aren't executed. This means that the operator has the opportunity to fix a problem before remaining tasks are executed. Having established the identity and nature of the database maintenance tasks that need to be carried out, we need to translate them into an actual Maintenance Plan. Chapter 19: Create and Modify Maintenance Plans Using the Designer 243 Creating Maintenance Plans: the Big Picture While there are many ways in which to translate database maintenance goals into an actual Maintenance Plan, I like to follow the ten steps below. 1. Create the new Maintenance Plan. 2. Create any necessary subplans. 3. Add the Maintenance Plan tasks to each subplan, as appropriate. 4. Configure each Maintenance Plan task. 5. Establish the necessary precedence links between tasks in a given subplan. 6. Define reporting and logging requirements. 7. Save the Maintenance Plan. 8. Test the Maintenance Plan. 9. Set the subplan schedules. 10. Run in production, and follow up. While you don't have to follow these steps in this exact order (the Maintenance Plan Designer is very flexible) I think you will find this particular order will help you manage the process most effectively, when you are first starting out using the tool. Create the New Maintenance Plan Before we can do anything, we must first create a new Maintenance Plan using the Maintenance Plan Designer. Right-click on Maintenance Plans, within the Management folder of SSMS Object Explorer, and select New Maintenance Plan. Enter a descriptive name in the New Maintenance Plan dialog box, and click OK. The new (empty) Maintenance Plan is created, as shown in Figure 19.1, and we are ready to begin. Chapter 19: Create and Modify Maintenance Plans Using the Designer 244 Figure 19.1: Once you have created the Maintenance Plan, you are now ready to build it. In this example, the new plan is called AdventureWorks Maintenance Plan. Optionally, we can add a description of this plan in the dialog box immediately below its name. Once this initial step is completed, we are ready to create any subplans appropriate to the goals of our Maintenance Plan. Chapter 19: Create and Modify Maintenance Plans Using the Designer 245 Create the Subplans As you may recall, the purpose of a subplan is to separate Maintenance Plan tasks into different schedules, as required. So, how many subplans do we need to meet our database maintenance goals? Did you guess right? We need three subplans, because our maintenance goals include three different scheduling requirements. • Once a day – for full database backups. • Once an hour – for transaction log backups. • Once a week – for all other database maintenance tasks. Since there is already one default subplan, we need to create two more, so add these to the Designer using the Add Subplan button in the menu bar. While your subplans will automatically be assigned non-descriptive names, it is always wise to make each plan as self-documenting as possible, as it will make it much easier for another DBA to review it and understand how it works. Having created the extra subplans, and given all three subplans descriptive names, the screen should look as shown in Figure 19.2. Figure 19.2: Three subplans have been created When you add subplans, they appear in the order that you create them, and you can't change that order. Fortunately, this is not a problem, because each of these subplans operates on a different schedule, so their order on the screen is irrelevant. The presence of those calendar buttons next to each subplan may tempt you into assigning the schedules now. However, resist the temptation. If you schedule the subplans, and then subsequently save the unfinished plan (in order to preserve your progress), the underlying SSIS packages and Agent jobs will be created, and SQL Server may attempt to start running the scheduled jobs! Never schedule the subplans until the plan is complete and tested, and . Picture While there are many ways in which to translate database maintenance goals into an actual Maintenance Plan, I like to follow the ten steps below. 1. Create the new Maintenance Plan. 2. Create any. are no longer required to be stored on the local server • notify the designated operator should one of the tasks fail. While the example does perform many of the essential maintenance tasks, it's. create a Maintenance Plan for your SQL Server instances, you have to first establish what you want to accomplish. Based on established goals, the DBA must create Maintenance Plans that include the