Microsoft SQL Server 2008 R2 Unleashed- P52 docx

ptg 454 Configuring Email Notification The SQL Server Agent can send email notifications; it can send email via SQL Mail or Database Mail. SQL Mail was retained for backward compatibility. It utilizes an Extended Messaging Application Programming Interface (Extended MAPI) interface to send email and requires that you install an email application (such as Outlook) that supports Extended MAPI communication on the computer that is running SQL Server. Database Mail, which is now the recommended mail solution for the SQL Server Agent, is the focus of this section. It was added in SQL Server 2005, and it utilizes Simple Mail Transfer Protocol (SMTP) instead of Extended MAPI to send mail. This simplifies email setup and has many benefits over SQL Mail, including the following: . There is no requirement that an email client be installed on the SQL Server machine. . Email is queued for later delivery if the mail server stops or fails. . Multiple SMTP servers can be specified so that mail continues to be delivered in the event that one of the SMTP servers stops. . Database Mail is cluster aware. Database Mail is disabled by default in SQL Server 2008 but can be enabled using the Database Mail Configuration Wizard. This wizard provides a comprehensive means for configuring Database Mail. The Database Mail Configuration Wizard is not launched from the SQL Server Agent node. Instead, you can launch it by expanding the Management node, right-clicking Database Mail, and selecting Configure Database Mail. This wizard guides you through the configuration of mail profiles, SMTP accounts, and other options relevant to Database Mail. The Configuration Wizard and many other details related to Database Mail are discussed in detail in Chapter 15, “Database Mail.” After you set up Database Mail and confirm that it is working properly, you can select it as your mail system for the SQL Server Agent to send mail. You do this by right-clicking the SQL Server Agent node in the Object Explorer and selecting Properties. Then you select the Alert System page in the SQL Server Agent Properties dialog, and the screen shown in Figure 16.3 appears. In this figure, Database Mail is selected as the mail system, along with a mail profile for Database Mail created with the Database Mail Configuration Wizard. The mail profile you select can have multiple SMTP accounts assigned to it. This allows for redundancy in the event that the mail cannot be sent to one of the SMTP accounts. To ensure proper functioning of the alert system, you should restart the SQL Server Agent service after the alert system has been configured. If you experience problems sending notifications via the SQL Server Agent, you should check the service account that SQL Server is running under. If the SQL Server Agent is running with the local system account, resources outside the SQL Server machine will be unavailable; this includes mail servers that are on other machines. You should change the service account for the SQL Server Agent to a domain account to resolve this issue. Chapter 15 provides more information on using Database Mail in SQL Server 2008. CHAPTER 16 SQL Server Scheduling and Notification Download from www.wowebook.com ptg 455 FIGURE 16.3 The Alert System page of the SQL Server Agent Properties dialog. Configuring the SQL Server Agent 16 SQL Server Agent Proxy Account Proxy accounts allow non–Transact-SQL (non–T-SQL) job steps to execute under a specific security context. By default, only users in the sysadmin role can execute these job steps. Non-sysadmin users can be assigned to a proxy account to allow them to run the special job steps. In SQL Server 2000, a single proxy account was provided for this function. With SQL Server 2008, multiple proxy accounts can be established, each of which can be assigned to a different SQL Server Agent subsystem. To establish a proxy account for the SQL Server Agent, you must first create a credential. A credential contains the authentication information necessary to connect to a resource outside SQL Server. The credential is typically linked to a Windows account that has the appropriate rights on the server. To create a credential, you open the Security node in the Object Explorer, right-click the Credentials node, and select New Credential. You give the credential a name, enter an identity value that corresponds to a valid Windows account, and provide a password for the account. After creating a credential, you can create a new proxy account and link it to the creden- tial. To create a new proxy account, you expand the SQL Server Agent node in the Object Explorer tree, right-click Proxies, and select New Proxy Account. Figure 16.4 shows an example of the New Proxy Account dialog. In this example, the proxy name and creden- tial name are the same, but they do not need to be. The only subsystem selected for the Download from www.wowebook.com ptg 456 CHAPTER 16 SQL Server Scheduling and Notification FIGURE 16.4 Creating a new proxy account. sample proxy account in Figure 16.4 is the operating system, but a proxy account can be linked to multiple subsystems. After a proxy account is created, a sysadmin can assign one or more SQL logins, msdb roles, or server roles to the proxy. You do this by using the Principals page of the New Proxy Account dialog. A proxy account can have zero or many principals assigned to it. Conversely, a principal can be assigned to many different proxies. Linking non-admin principals to the proxy allows the principal to create job steps for subsystems that have been assigned to the proxy. Proxy accounts are referenced within a SQL Server Agent job step. The General page of the Job Step Properties dialog contains a Run As drop-down that lists valid accounts or proxies that can be used to run the particular job step. After you add a proxy account, you see it in this drop-down list. Keep in mind that the account is not visible for a T-SQL job step that does not utilize a proxy account. Steps that utilize the T-SQL subsystem execute under the job owner’s context and they do not utilize a proxy account. Viewing the SQL Server Agent Error Log The SQL Server Agent maintains an error log that records information, warnings, and error messages concerning its operation. A node named Error Logs is located in the SQL Server Agent tree in the Object Explorer. The Error Logs node contains multiple versions of the Download from www.wowebook.com ptg 457 Viewing the SQL Server Agent Error Log 16 SQL Server Agent error log. By default, a maximum of 10 versions of the error log are displayed under the Error Logs node. The versions displayed include the current error log and the last 9 versions. Each time the SQL Server Agent is restarted, a new error log is generated, with a name that includes a time stamp. The first part of the current version’s name is Current. Names of older logs start with Archive #, followed by a number; the newer logs have lower numbers. The SQL Server error log works in much the same way as the SQL Server Agent’s error log. TIP You can cycle the e rr or log at any time without stopping and star ting the SQL Ser ver Agent. To do so, you right-click the Error Logs node in the Object Explorer and select Recycle; a new error log is then generated. You can also use the msdb.dbo.sp_cycle_agent_errorlog stored procedure to cycle the error log. You need to remember to also select the Refresh option to show the latest available error logs. To view the contents of any of the logs, you need to double-click the particular log. Double-clicking a particular log file launches the Log File Viewer. The Log File Viewer contains the SQL Server Agent error logs in addition to logs that are associated with other SQL Server components, including Database Mail, SQL Server, and Windows NT. Figure 16.5 shows a sample Log File Viewer screen with the current SQL Server Agent error log selected for display. The Log File Viewer provides filtering capabilities that allow you to focus on a particular type of error message, along with other viewing capabilities that are common to all the logs available for viewing. FIGURE 16.5 The SQL Server Agent error log. Download from www.wowebook.com ptg 458 CHAPTER 16 SQL Server Scheduling and Notification SQL Server Agent Security Many changes were made to the security model related to the SQL Server Agent in SQL Server 2005. In the past, everyone could view the SQL Server Agent. Starting in SQL Server 2005, logins must be a part of the sysadmin server role or assigned to one of three msdb database roles to be able to view and modify the SQL Server Agent. The SQL Server Agent node does not appear in the Object Explorer tree if the login does not have the appropri- ate permissions. Following are the msdb database roles and their basic permissions: . SQLAgentUserRole—Users with this permission can create and manage local jobs and job schedules that they own. They cannot create multiserver jobs or manage jobs that they do not own. . SQLAgentReaderRole—Users with this permission can view jobs that belong to other users in addition to all the permissions associated with SQLAgentUserRole. . SQLAgentOperatorRole—Users with this permission can view operators and alerts and control jobs owned by other users. The job control on jobs owned by other users is limited to stopping or starting and enabling or disabling those jobs. SQLAgentOperatorRole also has all the permissions available to SQLAgentUserRole and SQLAgentReaderRole. SQLAgentUserRole has the fewest privileges, and each subsequent role has increasing levels of security. In addition, each subsequent role inherits the permissions of the roles with fewer permissions. For example, SQLAgentReaderRole can do everything that SQLAgentUserRole can do and more. Refer to the topic “Implementing SQL Server Agent Security” in SQL Server Books Online for a detailed list of all the permissions related to the new database roles. Managing Operators Operators are accounts that can receive notification when an event occurs. These accounts are not linked directly to the user and login accounts that are defined on the server. They are basically aliases for people who need to receive notification based on job execution or alerts. Each operator can define one or more electronic means for notification, including email, pager, and the NET SEND command. To add a new operator, you expand the SQL Server Agent node in the Object Explorer and right-click the Operators node. Then you select New Operator from the right-click menu. Figure 16.6 shows the New Operator screen, with many of the fields populated for the creation of a new operator named LauraG. The General page of the New Operator screen allows you to enter the name of the opera- tor, the notification options, and the “on duty” scheduled for the operator. The operator name can be any name, but it must be unique within the SQL Server instance and must be no more than 128 characters. The operator name can be the same as another login or user on the server, but this is not required. Download from www.wowebook.com ptg 459 Managing Operators 16 FIGURE 16.6 Creating a new operator. The notifications options are the key to operators. You create operators so that you can then define notification options and have messages sent from SQL Server. If you use the email notification option, the email address you specify must be a valid address that can be reached via Database Mail or SQL Mail. One of the two mail options must be configured before the email functionality will work. If Database Mail is config- ured, the email is sent via an SMTP server. To send email with SQL Mail, SQL Server must be able to access a Microsoft Exchange server, and you must have the Extended MAPI client installed on the SQL Server machine. The NET SEND notification option causes a pop-up window to appear on the recipient’s computer; this window contains the notification text. In the Net Send Address text box, you specify the name of the computer or user that is visible on the network to the SQL Server machine. For NET SEND to work, the Messenger service on SQL Server must be started. This Messenger service must also be started on the machine that is receiving the NET SEND message. You can test the basic NET SEND capabilities by executing NET SEND at the command prompt. The basic syntax for NET SEND follows: NET SEND {name | * | /domain[:name] | /users} message The following example uses the NET SEND command to send the message “Test net send message” to the operator LauraG: NET SEND LauraG “Test net send message” Download from www.wowebook.com ptg 460 CHAPTER 16 SQL Server Scheduling and Notification The final notification option is through a pager email address. Pager email requires that third-party software be installed on the mail server to process inbound email and convert it to a pager message. The methods for implementing pager email and the available soft- ware are dependent on the pager provider. You should contact your pager vendor for implementation details. If you implement pager notification, you can also define the pager schedule for the opera- tor. The Pager on Duty Schedule section of the New Operator dialog allows you to define the days and times when the operator will be available to receive a page. The General page includes a check box for each day the operator can receive a page. It also includes the Workday Begin and Workday End settings, which you can use to define the valid time periods to receive a page. The other page available when defining a new operator is the Notifications page, which displays the alerts and jobs for which the operator will receive notifications. For a new operator, the Alert List or Job List is empty, as shown in Figure 16.7. You’ll have a better understanding of the usefulness of operators after you read the follow- ing discussions of jobs and alerts. Jobs and alerts can have operators linked to them for notification purposes. FIGURE 16.7 The Notifications page of the New Operator dialog. Download from www.wowebook.com ptg 461 Managing Jobs 16 Managing Jobs A job is a container for operations that can be executed by the SQL Server Agent. Jobs can be run once or scheduled to run on a regular basis. Jobs provide the basis for SQL Server automation and allow for the execution of many different types of operations, including T-SQL, SQL Server Integration Services (SSIS) packages, and operating system commands. Defining Job Properties The Jobs node is located under SQL Server Agent in the Object Explorer. You right-click the Jobs node and select New Job to create a new SQL Server Agent job. A New Job dialog like the one shown in Figure 16.8 appears. NOTE Only logins that are part of one of the msdb fixed database roles or are members of the sysadmin fixed server role are able to create or modify jobs. The General properties page shown in Figure 16.8 contains the basic information about the job, including the name and description. The owner of the job defaults to the login FIGURE 16.8 The New Job dialog. Download from www.wowebook.com ptg 462 CHAPTER 16 SQL Server Scheduling and Notification for the person creating the job; however, if the login of the person creating the job is part of the sysadmin fixed server role, the default can be changed. You use the Category selec- tion to group or organize jobs. There are several predefined categories for selection, includ- ing Database Maintenance and Log Shipping. The default category is set to [Uncategorized(local)]. Defining Job Steps After you add the general information for a new job, you are ready to add the job steps that actually perform the work. To do this, you select the Steps page on the left side of the New Job dialog, and the job steps for this job are listed. To create a new job step, you click the New button, and a New Job Step dialog like the one shown in Figure 16.9 appears. A step name is the first piece of information you need to provide for the job step. It can be up to 128 characters long and must be unique within the job. Then you need to select a job step type. The SQL Server Agent can run a variety of types of job steps, including the following: . ActiveX script (Visual Basic, Java, Perl script) . Operating System (CmdExec) . PowerShell FIGURE 16.9 The New Job Step dialog. Download from www.wowebook.com ptg 463 Managing Jobs 16 . Replication Distributor . Replication Merge . Replication Queue Reader . Replication Snapshot . Replication Transaction Log Reader . SQL Server Analysis Services Command . SQL Server Analysis Services Query . SQL Server Integration Services Package . Transact-SQL script (T-SQL) SQL Server Analysis Services Command, Server Analysis Services Query, and SQL Server Integration Services Package are types that were added in SQL Server 2005. They provide integration with SQL Server Analysis Services (SSAS) and SSIS. Chapters 45, “SQL Server and the .NET Framework,” and 46, “SQLCLR: Developing SQL Server Objects in .NET,” provide detailed discussions of these technologies. The PowerShell job type was added in SQL Server 2008; further information on PowerShell is provided in Chapter 17, “Administering SQL Server 2008 with PowerShell.” The Step properties page displays different information, depending on the type of step selected. When the Transact-SQL script (T-SQL) type is selected, you see a window similar to the one shown in Figure 16.9. If you choose the SQL Server Integration Services Package type, the Step properties page changes to allow you to enter all the rele- vant information needed to execute an SSIS package. In many cases (including T-SQL), a command window is available to input the step commands. With a T-SQL command, you can enter the same type of commands you would enter in a query window. You click the Parse button to validate the SQL and ensure proper syntax. The Operating system (CmdExec) type allows you to enter the same types of commands that you can enter in a command prompt window. Each step type has its own command syntax that you can test in the native environment to ensure proper operation. You can select the Advanced page to configure job flow information and other informa - tion related to the job step. On Success Action allows you to specify the action to perform when the current job step completes. Actions include the execution of the next job step (if one exists) and the ability to set job status based on the step completion. The same selec- tion options also exist for On Failure Action. The Retry options define the options that relate to retrying the job step in the event that the job step fails. Retry Attempts defines the number of times the job step will be re- executed if it fails. Retry Intervals (Minutes) defines the amount of time (in minutes) between retry attempts. Download from www.wowebook.com . Reader . SQL Server Analysis Services Command . SQL Server Analysis Services Query . SQL Server Integration Services Package . Transact -SQL script (T -SQL) SQL Server Analysis Services Command, Server. related to the SQL Server Agent in SQL Server 2005. In the past, everyone could view the SQL Server Agent. Starting in SQL Server 2005, logins must be a part of the sysadmin server role or. via an SMTP server. To send email with SQL Mail, SQL Server must be able to access a Microsoft Exchange server, and you must have the Extended MAPI client installed on the SQL Server machine. The