Module 7: Automating Administrative Tasks

Transcription

1 Module 7: Automating Administrative Tasks Table of Contents Module Overview 7-1 Lesson 1: Automating Administrative Tasks in SQL Server Lesson 2: Configuring SQL Server Agent 7-10 Lesson 3: Creating Jobs and Operators 7-17 Lesson 4: Creating Alerts 7-28 Lesson 5: Managing Multiple Servers 7-35 Lesson 6: Managing SQL Server Agent Security 7-42 Lab: Automating Administrative Tasks 7-50

2 Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e- mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. The names of manufacturers, products, or URLs are provided for informational purposes only and Microsoft makes no representations and warranties, either expressed, implied, or statutory, regarding these manufacturers or the use of the products with any Microsoft technologies. The inclusion of a manufacturer or product does not imply endorsement of Microsoft of the manufacturer or product. Links are provided to third party sites. Such sites are not under the control of Microsoft and Microsoft is not responsible for the contents of any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission received from any linked site. Microsoft is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement of Microsoft of the site or the products contained therein. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property Microsoft Corporation. All rights reserved. Microsoft, Active Directory, ActiveX, BizTalk, Excel, Internet Explorer, Jscript, Outlook, PowerPoint, SQL Server, Visual Basic, Visual Studio, Win32, Windows, Windows Mobile, Windows NT and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Version 1.1

3 Module 7: Automating Administrative Tasks 7-1 Module Overview There are many day-to-day administrative tasks that you must perform to manage a database. By automating these tasks, you can minimize the administrative workload associated with managing a database, and identify and resolve issues before they affect database availability. This module provides you with details about performing configuration and routine administrative tasks. It describes how to automate tasks by creating jobs, operators, and alerts. The module also discusses automating tasks in a multi-server environment. Objectives After completing this module, you will be able to: Define Microsoft SQL Server 2005 administrative tasks and schedule these tasks to run automatically. Configure SQL Server Agent to support automatic task scheduling. Script tasks by using SQL Server jobs, and define operators for managing these jobs. Define alerts to warn operators about events raised by SQL Server. Define and manage administrative tasks that span multiple servers. Configure SQL Server Agent security.

4 7-2 Module 7: Automating Administrative Tasks Lesson 1: Automating Administrative Tasks in SQL Server 2005 One of the primary functions of a database administrator is to maintain SQL Server and its databases. The job of an administrator often entails performing various administrative duties that do not change from day to day. You can automate these routine tasks and configure SQL Server to monitor for certain types of problems before they occur. Objectives After completing this lesson, you will be able to: List the benefits of automating common database administration tasks. Describe how to automate core SQL Server maintenance tasks by using the Maintenance Plan Wizard. Describe the purpose of SQL Server Agent for automating tasks.

5 Module 7: Automating Administrative Tasks 7-3 Benefits of Automation Automating management and monitoring tasks enables the database administrator to reduce the workload associated with performing repetitive tasks and monitoring SQL Server. By using jobs and alerts, you can configure SQL Server to respond to problems automatically, and even prevent some problems from occurring. Benefits of Automating Database Administration The benefits of automating database administration include: Reduced administrative workload, enabling database administrators to focus on other job functions, such as planning database changes or optimizing performance, instead of mundane maintenance tasks. Reduced risk of overlooking vital maintenance tasks. Reduced risk of human error when performing database maintenance tasks. Proactive database management through alerts indicating that action must be taken to prevent problems before they occur.

6 7-4 Module 7: Automating Administrative Tasks What Is the Maintenance Plan Wizard? You can use the Maintenance Plan Wizard to schedule core maintenance tasks to ensure that your database is regularly backed up, performs well, and is checked for inconsistencies. The Maintenance Plan Wizard creates one or more SQL Server Agent jobs that perform these maintenance tasks automatically at scheduled intervals. Using the Maintenance Plan Wizard to Automate Tasks You can schedule many maintenance tasks to run automatically, including: Backing up the database and transaction log files. Database and log backups can be retained for a specified period. Running SQL Server Agent jobs that perform a variety of actions. Compacting data files by removing empty database pages. Performing internal consistency checks of the data and data pages within the database to make sure that a system or software problem has not damaged data. Reorganizing the information on the data pages and index pages by rebuilding indexes. Updating index statistics to make sure the query optimizer has up-to-date information about the distribution of data values in the tables. The results generated by the maintenance tasks can be written as a report to a text file, or written to the maintenance plan tables sysmaintplan_log and sysmaintplan_log_detail in the msdb database. Launching the Maintenance Plan Wizard You can start the Maintenance Plan Wizard from SQL Server Management Studio. In Object Explorer, expand the server and the Management folder, right-click Maintenance

7 Module 7: Automating Administrative Tasks 7-5 Plans, and then click Maintenance Plan Wizard. You can then use the wizard to create a plan customized to meet your maintenance requirements. Editing and Creating Maintenance Plans Manually You can edit an existing maintenance plan by using the Maintenance Plan Designer, which is also available within SQL Server Management Studio. This tool provides a graphical interface, enabling you to reorder tasks, add new tasks, and define a simple workflow, indicating how to handle task success and failure.

8 7-6 Module 7: Automating Administrative Tasks What Is SQL Server Agent? SQL Server Agent is the component of SQL Server responsible for automating SQL Server administrative tasks. For SQL Server Agent to execute jobs and fire alerts, it must be running at all times and must have sufficient permissions. By using SQL Server Agent, the database administrator can schedule much more complex tasks with more flexibility than by using the Maintenance Plan Wizard alone. The SQL Server Agent Service On all Microsoft Windows Server 2003 and Microsoft Windows 2000 operating systems, SQL Server Agent runs as a Windows service. This service must be running to execute scheduled jobs and fire defined alerts. You should configure the SQL Server Agent service to start automatically whenever Windows Server 2003 or Windows 2000 starts. In addition, you can configure the SQL Server Agent service to restart automatically if it stops unexpectedly by using SQL Server Configuration Manager. To restart automatically, the SQL Server Agent service account must be a member of the Administrators local group.

9 Module 7: Automating Administrative Tasks 7-7 Practice: Using the Maintenance Plan Wizard The purpose of this practice is to enable you to automate administrative tasks by using the Maintenance Plan Wizard. Objectives In this practice, you will: Create a maintenance plan by using the Maintenance Plan Wizard. Verify that the maintenance plan executed successfully. Instructions Start the 2780B-MIA-SQL-07 virtual machine. Log on to the virtual machine with the user name Student and the password Pa$$w0rd. Create a maintenance plan by using the Maintenance Plan Wizard 1. Click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio. 2. In the Connect to Server dialog box, specify the values in the following table, and then click Connect. Property Server type Server name Authentication Value Database Engine MIAMI Windows Authentication 3. If Object Explorer is not visible, on the View menu, click Object Explorer.

10 7-8 Module 7: Automating Administrative Tasks 4. In Object Explorer, expand the MIAMI server, and then expand Management. 5. Right-click Maintenance Plans, and then click Maintenance Plan Wizard. 6. On the SQL Server Maintenance Plan Wizard page, click Next. 7. On the Select a Target Server page, in the Name box, type AdventureWorks daily backup, and then click Next. 8. On the Select Maintenance Tasks page, select the Back Up Database (Full) check box, and then click Next. 9. On the Select Maintenance Task Order page, click Next. 10. On the Define Back Up Database (Full) Task page, click the arrow next to Databases, click These databases, select the AdventureWorks check box, and then click OK. 11. Click Create a backup file for every database, and then select the Create a subdirectory for each database check box. 12. Accept the default file location and extension, and then click Next. 13. On the Select Plan Properties page, click Change. 14. In the New Job Schedule dialog box, in the Name box, type AdventureWorks Daily Backup. 15. In the Occurs list, click Daily. 16. In the Occurs once at box, specify a time of 2 minutes from the current time, and then click OK. 17. On the Select Plan Properties page, click Next. 18. On the Select Report Options page, ensure that Write a report to a text file is selected. 19. In the Folder location box, type D:\Practices and then click Next. 20. On the Complete the Wizard page, examine the summary, and then click Finish. 21. On the Maintenance Plan Wizard Progess page, verify that all five actions complete successfully, and then click Close. Verify that the maintenance plan executed successfully 1. Wait for 2 minutes to enable SQL Server Agent to perform the backup. 2. Click Start, and then click Windows Explorer. 3. In Windows Explorer, browse to the D:\Practices folder. 4. Double-click the AdventureWorks daily backup text file to open it in Notepad.

11 Module 7: Automating Administrative Tasks Examine the contents of the text file, verify that the backup was reported as completing successfully, and then close Notepad. 6. In Windows Explorer, browse to the C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\AdventureWorks folder, and then confirm that the AdventureWorks backup file has been created. 7. Close Windows Explorer. 8. Close SQL Server Management Studio. After you complete the practice, you must shut down the 2780B-MIA-SQL-07 virtual machine and discard any changes. Important: If the Close dialog box appears, ensure that Turn off and delete changes is selected, and then click OK.

12 7-10 Module 7: Automating Administrative Tasks Lesson 2: Configuring SQL Server Agent You must configure SQL Server Agent appropriately, to enable it to support automated database maintenance tasks. This lesson describes the configuration options for SQL Server Agent. Objectives After completing this lesson, you will be able to: Describe the options for running SQL Server Agent. Configure Database Mail to enable SQL Server Agent to send messages.

13 Module 7: Automating Administrative Tasks 7-11 Considerations for SQL Server Agent Configuration SQL Server Agent is implemented as a Windows service. Each instance of SQL Server has its own SQL Server Agent service, which is named SQLSERVERAGENT for default instances and SQLAgent$instancename for named instances. SQL Server Agent Service Startup Configuration Like any Windows service, the SQL Server Agent service can be configured to start manually or automatically, or it can be disabled. By default, the SQL Server Agent service is set to start manually when SQL Server 2005 is installed. Note: On the VPC image used by this course, SQL Server Agent for the default SQL Server instance is configured to start automatically. You can change the startup configuration of the SQL Server Agent service by using SQL Server Configuration Manager or the Services Windows administrative tool. If you plan to implement automated jobs and alerts, you should generally set the SQL Server Agent service to start automatically when Windows starts, unless there is a good reason to start the service manually. When it starts, the SQL Server Agent service connects to SQL Server and runs the xp_sqlagent_monitor extended stored procedure in the master database. This stored procedure monitors the status of the SQL Server Agent service, and restarts the service if it stops unexpectedly.

14 7-12 Module 7: Automating Administrative Tasks Specifying a SQL Server Agent Service Account You can configure the SQL Server Agent service to run as a built-in account or as a specific Windows user account. The following built-in accounts can be used for the SQL Server Agent service: Local System. The Local System account is a member of the local Administrators group. The option to use this account is provided for backward compatibility only, and you should not use this account for the SQL Server Agent service. Local Service. The Local Service account has similar permissions to a local user, and accesses network resources by using a null session with no credentials. The Local Service account is suitable for the SQL Server Agent service when all jobs and alerts can be implemented locally on the server. Network Service. The Network Service account has similar permissions to a local user, and accesses network resources by using the credentials of the computer account. Microsoft recommends that you do not use the Network Service account for the SQL Server Agent service. In most cases, you should specify a local user account or a domain user account for the SQL Server Agent service, and assign the minimal permissions and user rights that the service account requires. The SQL Server Agent service requires the log on as a service user right. In addition, the following user rights are required to support SQL Server Agent proxies: Act as part of the operating systemerror! Bookmark not defined. Bypass traverse checking Replace a process-level token Adjust memory quotas for a process Log on as a batch job If the user rights listed above are not granted, only members of the sysadmin fixed server role can create jobs. Additionally, if a domain user account is used, it should be a member of the Pre- Windows 2000 Compatible Access group on the domain controller to run jobs for users who are not members of the Administrators group. Finally, the SQL Server Agent service account uses Windows authentication to connect to SQL Server, and must be mapped to a login that is a member of the sysadmin fixed server role. If multi-server jobs will be created, the login should be mapped to a user that is a member of the TargetServersRole database role in the msdb database on the master server. For more information about configuring the SQL Server Agent service account, see Selecting an Account for SQL Server Agent Service in SQL Server Books Online.

15 Module 7: Automating Administrative Tasks 7-13 SQL Server Agent Service Dependencies The SQL Server Agent service depends on the SQL Server service for the instance to which it belongs. Additionally, some operations performed by SQL Server Agent might rely on other Windows services. For example, to send operator notifications by using the net send command, the Windows Messenger service must be running.

16 7-14 Module 7: Automating Administrative Tasks Options for SQL Server Agent Mail SQL Server 2005 includes two mechanisms for sending Database Mail and SQL Mail. You can configure SQL Server Agent to use either of these mechanisms when sending notifications. Using Database Mail with SQL Server Agent Database Mail is a feature of SQL Server 2005 that makes it possible for SQL Server to send through a Simple Mail Transport Protocol (SMTP) server. To use Database Mail with SQL Server Agent, you must perform the following configuration tasks: 1. Enable Database Mail. 2. Create a Database Mail profile that includes an account for SQL Server Agent to use. Make this the default profile for the user in the msdb database that is mapped to the login for the SQL Server Agent service account. 3. Add the user for the SQL Server Agent service account login to the Databas UserRole database role in the msdb database. 4. Configure the alert system properties of SQL Server Agent to use Database Mail, and specify the profile you created in the previous steps. 5. Restart the SQL Server Agent service. For more information about Database Mail, see Database Mail in SQL Server Books Online. When you have configured Database Mail, you can send an response as part of a SQL Server Agent job, and you can also send manually by using the sp_send_dbmail stored procedure.

17 Module 7: Automating Administrative Tasks 7-15 Using SQL Mail with SQL Server Agent SQL Mail is a Messaging Application Programming Interface (MAPI) based feature that you can use to configure SQL Server to send and receive by using Microsoft Exchange Server. To use SQL Mail, you must configure a MAPI profile on the SQL Server computer for the SQL Server Agent service account, which requires the installation of an client such as Microsoft Office Outlook. Caution: SQL Mail will be removed in a future version of Microsoft SQL Server. You should avoid using SQL Mail for the SQL Server Agent service.

18 7-16 Module 7: Automating Administrative Tasks Demonstration: Configuring Database Mail In this demonstration, you will see how to: Configure Database Mail. Configure SQL Server Agent to use Database Mail. Test SQL Server Agent functionality. Key Points The key points of this demonstration are: Run the Database Mail Configuration Wizard to enable Database Mail and configure an profile for SQL Server Agent to use. Add the SQL Server Agent account to the Databas UserRole in the msdb database, and configure SQL Server Agent to use the profile when sending e- mail. Test the Database Mail configuration by creating a SQL Server Agent job that sends an message, running the job, and verifying that the was sent.

19 Module 7: Automating Administrative Tasks 7-17 Lesson 3: Creating Jobs and Operators You can use SQL Server Agent jobs to automate routine administrative tasks and run them on a recurring basis, making administration more efficient. You can also specify operators that can be notified when jobs are completed. This lesson describes how to create jobs and operators. Objectives After completing this lesson, you will be able to: Create SQL Server Agent jobs. Create SQL Server Agent operators. Create job steps containing Transact-SQL code, operating system commands, or Microsoft ActiveX scripts. View, start, and stop jobs by using the Job Activity Monitor.

20 7-18 Module 7: Automating Administrative Tasks What Is a Job? A job is a specified series of operations performed sequentially by SQL Server Agent. A job can perform a wide range of activities, including running Transact-SQL scripts, command-line applications, ActiveX scripts, Integration Services packages, Analysis Services commands and queries, or replication tasks. Jobs can run repetitive tasks or tasks that can be scheduled, and they can automatically notify specified users (known as operators) of job status by generating alerts, thereby greatly simplifying SQL Server administration. You can run a job manually, or you can configure it to run according to a schedule or in response to alerts. Creating Jobs You can use SQL Server Management Studio or execute the sp_add_job system stored procedure to define a new job. The job definition is stored in the sysjobs system table in the msdb database. This table is maintained in cache to improve performance. When you define jobs, you should: Ensure that a job is enabled. Jobs are enabled by default. If a job is disabled, it cannot execute as scheduled. However, a user can still execute a disabled job manually by starting it in SQL Server Management Studio. Specify the owner who is responsible for performing the job. By default, the owner is the Windows or SQL Server user logon account creating the job. Define whether the job executes on a local server or on multiple remote servers. Create job categories to help you organize, filter, and manage many jobs. For example, you can create job categories that correspond to the departments in your organization.

21 Module 7: Automating Administrative Tasks 7-19 What Are Operators? Operators are aliases for people or groups that can receive electronic notifications when jobs have been completed. When a job completes, or if any of the job steps fail, you can notify an operator by pager, , or by using a net send command. Guidelines for Creating Operators You can use SQL Server Management Studio or execute the sp_add_operator system stored procedure to define a new operator. The operator definition is stored in the sysoperators system table in the msdb database. When you create operators, you should: Use a group alias to notify more than one individual to respond to potential problems. Test each notification method that is used to notify the operator to ensure that the operator is able to receive messages. Specify a work schedule for each operator to be notified by pager. If a job that is defined to notify an operator by pager conflicts with the operator s work schedule, the notification fails. Use a net send command to send messages to network operators and servers running Windows Server 2003, Windows 2000, or Windows NT. Note: The Messenger service is disabled by default on Windows XP and Windows Server This service must be started to use the net send command.

22 7-20 Module 7: Automating Administrative Tasks Defining a Fail-Safe Operator You can define a fail-safe operator to respond to an alert when pager notifications to defined operators fail. For example, if all operators are off duty when an alert is fired, the fail-safe operator will be contacted. A fail-safe operator is notified when all the following facts are true: The alert has pager notifications defined for the response. None of the operators to be paged is on duty. A fail-safe operator is defined. When you assign a fail-safe operator, consider the following facts: The fail-safe operator information is cached so it is not dependent upon the connection to the msdb database. You can have only one fail-safe operator. You cannot delete an operator that has been designated as the fail-safe operator. However, you can remove the fail-safe operator assignment and then delete the operator.

23 Module 7: Automating Administrative Tasks 7-21 How to Create Job Steps You can use SQL Server Management Studio or execute the sp_add_jobstep system stored procedure to define each job step. The job step definitions are stored in the sysjobsteps system table in the msdb database. You can define job steps to execute Transact-SQL statements, operating system commands, ActiveX scripts, or SQL Server replication tasks. However, you can only specify one execution type for each job step. Defining Transact-SQL Job Steps When you define job steps to execute Transact-SQL statements, stored procedures, or extended stored procedures, consider the following guidelines: You must identify the database to be used. You must include required variables and parameters in the job step. You can send the result set of a job step to an output file. Output files are often used in troubleshooting to capture any error messages that may have occurred while the statement was executing. You cannot use an output file from one job step as input into a succeeding step. Defining Operating System Command Job Steps When you define a job step to execute an application or operating system command (identified by.exe,.bat,.cmd, or.com file-name extensions), you should: Identify a process exit code to indicate that the command was successful. Include the full path to the executable application. The path is required to help SQL Server Agent find the application source.

24 7-22 Module 7: Automating Administrative Tasks Defining ActiveX Script Job Steps You can write job steps based on ActiveX scripts by using languages, such as Microsoft Visual Basic Scripting Edition (VBScript) or Microsoft JScript. You can also use other languages if the language library for the scripting language is installed. When you create an ActiveX script job step, you must: Identify the scripting language in which the job step is written. Write or open the active script. You can use the SQLActiveScriptHost object to print output to the job step history or create objects. Flow Logic of Job Steps When creating jobs, you should specify the action that SQL Server should take upon the success or failure of each job step. By default, SQL Server advances to the next job step upon success and stops upon failure of a job step. However, job steps can go to any step defined in the job upon success or failure. You can specify the number of times that SQL Server should attempt to retry execution of a job step if the step fails. You also can specify the retry intervals (in minutes). For example, if the job step requires a connection to a remote server, you could define several retry attempts in case the connection fails. Additionally, if you define a job to run only once, you can specify that the job be deleted when it completes.

25 Module 7: Automating Administrative Tasks 7-23 What Is the Job Activity Monitor? Job Activity Monitor is a tool in SQL Server Management Studio that enables you to view the information in the sysjobactivity table in a graphical manner. You can view all jobs on the server, or you can define filters to limit the number of jobs displayed. You can also sort the job information by clicking a column heading in the Agent Job Activity grid. For example, when you select the Last Run column heading, you can view the jobs in the order that they were last run. Clicking the column heading again toggles the order of the jobs in ascending and descending order based on their last run date. When to Use the Job Activity Monitor Use the Job Activity Monitor when you want to determine which jobs are scheduled to run, the last outcome of jobs that have run during the current session, and which jobs are running or idle. If the SQL Server Agent service fails unexpectedly, you can determine which jobs were being executed by looking at the previous session in the Job Activity Monitor. You can perform the following tasks by using the Job Activity Monitor: Start and stop jobs. View job properties. View the history for a specific job. Refresh the information in the Agent Job Activity grid manually or set an automatic refresh interval by clicking View refresh settings. To open the Job Activity Monitor, in SQL Server Management Studio, open Object Explorer, expand SQL Server Agent, right-click Jobs, and click View Job Activity.

26 7-24 Module 7: Automating Administrative Tasks You can also view job activity for the current session by executing the sp_help_jobactivity stored procedure in the msdb database.

27 Module 7: Automating Administrative Tasks 7-25 Practice: Implementing Operators and Jobs The purpose of this practice is to enable you to implement a job that sends a notification to an operator. Objectives In this practice, you will: Create an operator based on the Student user. Create a job to backup the master database. Test the job and verify that the operator is notified. Instructions Start the 2780B-MIA-SQL-07 virtual machine. Log on to the virtual machine with the user name Student and the password Pa$$w0rd. Create an operator based on the Student user 1. Click Start, point to Administrative Tools, and then click Services. 2. In the Services console, scroll down to the Messenger service, right-click Messenger, and then click Properties. 3. In the Messenger Properties (Local Computer) dialog box, on the General tab, in the Startup type list, click Automatic, and then click Apply. 4. Click Start to start the service, and then click OK. 5. Close the Services console.

28 7-26 Module 7: Automating Administrative Tasks 6. Click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio. 7. In the Connect to Server dialog box, specify the values in the following table, and then click Connect. Property Server type Server name Authentication Value Database Engine MIAMI Windows Authentication 8. If Object Explorer is not visible, on the View menu, click Object Explorer. 9. In Object Explorer, expand SQL Server Agent, right-click Operators, and then click New Operator. 10. In the New Operator dialog box: a. In the Name box, type Student. b. In the Net send address box, type Student, and then click OK. Create a job to backup the master database 1. In Object Explorer, in SQL Server Agent, right-click Jobs, and then click New Job. 2. In the New Job dialog box: a. In the Name box, type Backup Master. b. In the Description box, type Back up the master database and notify Student on completion. c. In the Select a page pane, click the Steps page, and then click New. 3. In the New Job Step dialog box: a. In the Step name box, type Backup Master. b. In the Command box, type the following Transact-SQL statement (the file path should be on a single line), and then click OK. BACKUP DATABASE [master] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\master_backup.bak' GO 4. In the New Job dialog box, in the Select a page pane, click the Notifications page. 5. On the Notifications page: a. Select the Net send check box. b. In the first drop-down list, click Student. c. In the second drop-down list, click When the job completes, and then click OK.

29 Module 7: Automating Administrative Tasks 7-27 Test the job and verify that the operator is notified 1. In Object Explorer, expand Jobs, right-click Backup Master, and then click Start Job at Step. 2. Read the Messenger Service message to verify that the job completed successfully, and then click OK. 3. In the Start Jobs - MIAMI dialog box, verify that all actions completed successfully, and then click Close. 4. In Object Explorer, right-click Job Activity Monitor, and then click View Job Activity. 5. In the Job Activity Monitor - MIAMI dialog box, examine the row for the Backup Master job. 6. Right-click anywhere in the row for the Backup Master job, and then click View history. 7. In the Log File Viewer - MIAMI dialog box, examine the entries for the Backup Master job steps, and then click Close. 8. In the Job Activity Monitor - MIAMI window, click Close. 9. Close SQL Server Management Studio. After you complete the practice, leave the 2780B-MIA-SQL-07 virtual machine running, because you will use the Student operator in the next practice.

30 7-28 Module 7: Automating Administrative Tasks Lesson 4: Creating Alerts SQL Server enables you to create alerts to respond to SQL Server errors, user-defined errors, or performance conditions. You can also create a fail-safe operator in the event that a pager notification fails to contact an operator. This lesson describes configuration options for alerts in SQL Server. Objectives After completing this lesson, you will be able to: Describe the different types of alerts provided by SQL Server Agent. Explain how to create an alert that notifies an operator or that executes a SQL Server Agent job.

31 Module 7: Automating Administrative Tasks 7-29 What Is an Alert? Alerts are predefined responses to specific events that can occur in a SQL Server solution. You can define alerts to perform a job or to notify an operator when a particular event occurs or a performance threshold is exceeded. Events are generated by SQL Server and entered into the Windows application log. SQL Server Agent reads the application log and compares logged events to alerts that you have defined. When SQL Server Agent finds a match, it fires an alert, which is an automated response to an event. In addition to monitoring SQL Server events, SQL Server Agent can also monitor performance conditions and Windows Management Instrumentation (WMI) events. Defining Alerts on SQL Server Errors When you create an alert to fire a response when a SQL Server error occurs, you can specify a single error number, such as 9002, or all errors of a specific severity level, such as 17. You can define an alert on an error number or severity level for all databases, or for a specific database.

32 7-30 Module 7: Automating Administrative Tasks Note: One alert at most will fire for a given event. SQL Server Agent will fire the most specific alert that is defined. For example, if you have an alert defined on severity level 17 errors, and you also have an alert defined on error 9002 (which is also severity level 17), error 9002 will fire. Defining Alerts on Performance Conditions In addition to using alerts to respond to SQL Server errors, you can use them to respond to SQL Server performance conditions such as those that can be viewed in Windows System Monitor. When the condition value is exceeded, an alert is fired. For example, you can create a performance condition alert that fires when the transaction log in the AdventureWorks database has exceeded 75 percent capacity. The alert response could execute a job to back up the transaction log and notify the database administrator. Note: Windows System Monitor does not need to be running on the computer running SQL Server for you to use performance condition alerts. Performance data is sampled periodically (a few times each minute), which can cause a few seconds delay between the threshold being reached and the performance alert firing. Therefore, you may need to reduce the time delay between responses, or modify the threshold of your performance condition when the alert response is required to correct the condition quickly. Defining Alerts on WMI Events You can specify that an alert occur in response to a particular WMI event. When you define an alert on a WMI event, SQL Server Agent performs the following tasks: It registers as a WMI client to the WMI namespace that is provided to query for events. It executes the WMI Query Language (WQL) statement you have specified to identify the specific event.

33 Module 7: Automating Administrative Tasks 7-31 How to Create an Alert You create an alert by using SQL Server Management Studio or by using the sp_add_alert stored procedure. To create an alert, you specify: The name of the alert. The event or performance condition that triggers the alert. The action that SQL Server Agent takes in response to the event or performance condition. The type of event determines the parameters that you use to specify the precise event. Notifying an Operator The action that SQL Server Agent takes in response to the event or performance condition may include contacting an operator. To contact an operator, you must specify contact information for that operator, defining how the operator is notified. Operators can be notified by , pager, or through the net send command. Executing a Job The action that SQL Server Agent takes in response to the event or performance condition may include running a job. To have an alert start a job, you must specify the name of the job on the Response page of the alert. You can use an existing job or create a new job when defining the alert.

34 7-32 Module 7: Automating Administrative Tasks Practice: Implementing Alerts The purpose of this practice is to enable you create an alert that informs an operator when the transaction log for the AdventureWorks database fills beyond a critical level. Objectives In this practice, you will create an alert that informs an operator when a critical database event occurs. Instructions Start the 2780B-MIA-SQL-07 virtual machine. Log on to the virtual machine with the user name Student and the password Pa$$w0rd. Important: This demonstration requires you to have completed the preceding practice, "Implementing Operators and Jobs." Create an alert that informs an operator when a critical database event occurs 1. Click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio. 2. In the Connect to Server dialog box, specify the values in the following table, and then click Connect. Property Server type Server name Value Database Engine MIAMI

35 Module 7: Automating Administrative Tasks 7-33 Property Authentication Value Windows Authentication 3. If Object Explorer is not visible, on the View menu, click Object Explorer. 4. In Object Explorer, expand SQL Server Agent, right-click Alerts, and then click New Alert. 5. In the New Alert dialog box, set the properties to the values in the following table. Property Name Enable Type Object Counter Instance Alert if counter Value 2 Value or action LogSize Selected SQL Server performance condition alert SQLServer:Databases Percent Log Used AdventureWorks rises above Note: This alert is raised when the transaction log for the AdventureWorks database becomes 2% full. This value has been selected for the purpose of this practice only, and is not a recommendation for an alert in a live environment. 6. In the Select a page pane, click the Response page. 7. On the Response page, select the Notify operators check box, and then select the Net Send check box for the Student operator. 8. In the Select a page pane, click the Options page. 9. On the Options page, select the Net send check box, in the Additional notification message to send box, type Warning: Log file is growing too large, and then click OK. 10. Wait for the alert to fire and examine the Messenger Service messages. 11. Click OK to close all message boxes. Note: The alert should fire almost immediately, and will keep firing periodically until you reduce the size of the transaction log or you disable the alert. 12. In Object Explorer, expand Alerts, right-click the LogSize alert, and then click Disable. 13. In the Disable Alerts - MIAMI dialog box, verify that the alert was successfully disabled, and then click Close. 14. Close SQL Server Management Studio.

36 7-34 Module 7: Automating Administrative Tasks After you complete the practice, leave the 2780B-MIA-SQL-07 virtual machine running, because you will require the Student operator in the next practice.

37 Module 7: Automating Administrative Tasks 7-35 Lesson 5: Managing Multiple Servers You can automate jobs across multiple servers in a network. Automating multi-server jobs consists of defining a master server and one or more target servers. A master server distributes jobs to and receives events from networked target servers. Having a multi-server administration configuration enables you to group multiple servers into logical functioning business units, and manage multiple servers from a single location. Objectives After completing this lesson, you will be able to: Describe how master servers and target servers work with each other. Explain how to create a master server, target servers, and implement multi-server jobs. Explain the advantages and disadvantages of using event forwarding.

38 7-36 Module 7: Automating Administrative Tasks What Are Master and Target Servers? To take advantage of multi-server administration, you must have at least one master server and at least one target server. Master Servers and Target servers A master server stores the central copy of job definitions for jobs that are run on target servers. A master server distributes jobs to and receives events from enlisted target servers. Target servers connect periodically to the master server to update their schedule of jobs. If a new job exists on the master server, the target server downloads the job. After the target server completes the job, it reconnects to the master server and reports the status of the job.

39 Module 7: Automating Administrative Tasks 7-37 Considerations for Multi-Server Jobs To automate jobs on multiple servers, you must first define a master server and one or more target servers. A master server defines, schedules, and manages the jobs on all target servers. Because of the higher connection load that a master server requires, a master server can be defined on a computer running Windows Server 2003 or Windows 2000 Server only. Defining a Master Server You can use the Master Server Wizard in SQL Server Management Studio or execute the sp_msx_enlist system stored procedure to define the master server. The wizard takes you through the following steps: Checking the security settings for the SQL Server Agent service and the SQL Server service on all servers intended to become target servers. Important: Both services must be running as Windows domain accounts. Creating a master server operator (MSXOperator) on the master server. MSXOperator is the only operator that can receive notifications for multiserver jobs. Starting the SQL Server Agent service on the master server. Enlisting one or more servers as target servers. Defining Target Servers You can use the Target Server Wizard in SQL Server Management Studio or execute the sp_msx_enlist system stored procedure to define any additional target servers. The target server definition is stored in the systargetservers system table in the msdb database.

40 7-38 Module 7: Automating Administrative Tasks Target servers: Are assigned to only one master server. Must reside in the same Windows domain as the master server or in a trusted Windows domain. Cannot be members of other master servers until they defect from their current master servers. Implementing Multi-Server Jobs After master and target servers have been defined, you can create jobs on the master server to execute on one or more target servers. You specify the target servers for the job by using the Targets page in the Job properties dialog box. This page is not shown until SQL Server has been defined as either a master or a target server in a multiserver environment. SQL Server goes through the following steps to process jobs in a multiserver environment: 1. The master server posts jobs for the target servers in a download list in the sysdownloadlist system table in the msdb database. 2. The target servers periodically connect to the master server to determine whether any new or updated jobs have been posted for download. 3. The target server uploads the job outcome status to the master server when the job completes. Caution: The paths and syntax in the job must be identical on all target servers, or the job will not work on all servers. Modifying Multi-Server Job Definitions The master server stores the master copy of job definitions and schedules. When you make any changes to jobs in a multiserver environment, consider the following facts: Job definitions cannot be modified on the target server; they must be modified on the master server. SQL Server Management Studio automatically posts the necessary instructions to the download list.

41 Module 7: Automating Administrative Tasks 7-39 What Is Event Forwarding? You can forward all event messages that meet or exceed a specific error severity level to an instance of SQL Server. This is called event forwarding. The forwarding server is a dedicated server that can also be a master server. You can use event forwarding to centralize alert management for a group of servers, thereby reducing the workload on heavily used servers. When one server receives events for a group of other servers, the server that receives events is called an alerts management server. The use of events forwarding is unrelated to master and target servers, but if you have a multi-server environment configured, you should generally designate the master server as the alerts management server. Advantages of Using an Alerts Management Server The advantages of setting up an alerts management server include: Centralization. Centralized control and a consolidated view of the events of several instances of SQL Server are possible from a single server. Scalability. Many physical servers can be administered as one logical server. You can add or remove servers to this physical server group as needed. Efficiency. Configuration time is reduced because you need to define alerts and operators only once. Disadvantages of Using an Alerts Management Server The disadvantages of setting up an alerts management server include: Increased traffic. Forwarding events to an alerts management server can increase network traffic. This increase can be moderated by restricting event forwarding to events that are above a designated severity level.

42 7-40 Module 7: Automating Administrative Tasks Single point of failure. If the alerts management server goes offline, no alerts are issued for any event on the managed group of servers. Server load. Handling alerts for the forwarded events causes an increased processing load on the alerts management server.

43 Module 7: Automating Administrative Tasks 7-41 Demonstration: Implementing Event Forwarding In this demonstration, you will see how to: Start a second instance of SQL Server to act as a master server. Configure the SQL Server instance as an events forwarding server. Key Points The key points of this demonstration are: Use SQL Server Configuration Manager to start a second instance of SQL Server and SQL Server Agent. Configure the properties of SQL Server Agent for the second instance to forward events to the default SQL Server instance.

44 7-42 Module 7: Automating Administrative Tasks Lesson 6: Managing SQL Server Agent Security You can define jobs that enable SQL Server Agent to perform highly privileged tasks in databases and on the server. You should restrict access to SQL Server Agent functionality to ensure that only authorized users can execute SQL Server Agent jobs, and that jobs that access system resources do so with the minimal level of privilege required. Objectives After completing this lesson, you will be able to: Describe the different SQL Server Agent roles and their privileges. Explain how to use SQL Server Agent proxies.

45 Module 7: Automating Administrative Tasks 7-43 What Are SQL Server Agent Roles? SQL Server 2005 includes the following fixed database roles in the msdb database to give administrators finer control over access to SQL Server Agent. The roles, listed from least to most privileged access, are: SQLAgentUserRole SQLAgentReaderRole SQLAgentOperatorRole When users who are not members of one of these roles are connected to SQL Server in SQL Server Management Studio, the SQL Server Agent node in Object Explorer is not visible. A user must be a member of one of these fixed database roles or a member of the sysadmin fixed server role to use SQL Server Agent. SQLAgentUserRole SQLAgentUserRole is the least privileged of the SQL Server Agent fixed database roles. Members of SQLAgentUserRole have permissions only on local jobs and job schedules that they own. They cannot run multi-server jobs (master and target server jobs), and they cannot change job ownership to gain access to jobs that they do not already own. SQLAgentUserRole members can view a list of available proxies in the Job Step Properties dialog box of SQL Server Management Studio. SQLAgentReaderRole SQLAgentReaderRole includes all the SQLAgentUserRole permissions as well as permissions to view the list of available multiserver jobs, their properties, and their history. Members of this role can also view the list of all available jobs and job schedules and their properties, not just the jobs and job schedules that they own.

46 7-44 Module 7: Automating Administrative Tasks SQLAgentReaderRole members cannot change job ownership to gain access to jobs that they do not already own. SQLAgentOperatorRole SQLAgentOperatorRole is the most privileged of the SQL Server Agent fixed database roles. It includes all the permissions of SQLAgentUserRole and SQLAgentReaderRole. Members of this role can also view properties for operators and proxies, and enumerate available proxies and alerts on the server. SQLAgentOperatorRole members have additional permissions on local jobs and schedules. They can execute, stop, or start all local jobs, and they can delete the job history for any local job on the server. They can also enable or disable all local jobs and schedules on the server. To enable or disable local jobs or schedules, members of this role must use the sp_update_job and sp_update_schedule stored procedures, specifying the job name or schedule identifier parameter and the enabled parameter. If any other parameters are specified, execution of these stored procedures fails. SQLAgentOperatorRole members cannot change job ownership to gain access to jobs that they do not already own.