Hands-On Microsoft SQL Server 2008 Integration Services part 29 ppsx

258 Hands-On Microsoft SQL Server 2008 Integration Services 2. Expand the SQL Server Agent node in Object Explorer and right-click Jobs; then choose New Job from the context menu to open the New Job dialog box. 3. Type Running Mailing Opportunities in the Name field. Ensure that the Enabled check box is ticked before moving on to the Steps page. 4. Go to the Steps page and click New to create a new step for this job. In the Step Name field of the New Job Step window, type Executing Mailing Opportunities Step. 5. In the Type field, click the down arrow to display the list of job types and choose SQL Server Integration Services Package. As you choose this option, the window changes to include the options for running an Integration Services package. 6. In the Run As field, leave SQL Agent Service Account selected. 7. In the General tab, set the Package Source field to SSIS Package Store, type localhost in the Server field, and leave Use Windows Authentication selected in the Log On To The Server area. Click the ellipsis button next to the Package field to choose the Mailing Opportunities package under the MSDB storage folder. Click OK. Note the package path shown in Figure 6-6. 8. Click the Advanced page in the New Job Step window to see the available options. You can specify what should happen on the success or failure of a step. The default for success of a step is to go to the next step, and the default for the failure of a step is to quit the job and report failure. You can also specify the number of retry attempts and the time to wait between retries here, as well as record output in an output file or table. Click OK to close this dialog box. You should see the package listed in the Job Step List area. Notice the arrow buttons on the lower-left side of this page; you can use these to move your job steps up and down and hence change the order in which they are executed. Exercise (Create a Schedule to Execute the Package) In this section, you will be creating and adding a schedule to the job. 9. Move to the Schedules page. You can now create a new schedule for this job by clicking the New button or choose a schedule from the list of already defined schedules by clicking the Pick button. Once you create a schedule for a job, it is listed in the Available Schedules list, where you can pick a schedule for other jobs you define, saving you the time required to redefine similar schedules again. As you have not created any schedule until now, you will create a new schedule here. Click New to open a New Job Schedule window. In the Name field, type Schedule for Mailing Opportunities package. Leave the Recurring setting in the Schedule type field and leave the Enabled option checked. 10. In the Frequency area’s Occurs field, choose Daily and leave the Recurs Every field set to 1 day. Chapter 6: Administering Integration Services 259 11. In the Daily Frequency area, select a time equal to the time when you want to execute the package. For the sake of quick testing, set the time about 10 minutes from now. 12. In the Duration area, you can specify when to start and when to stop executing the scheduled packages. Leave default values selected. 13. A summary of the schedule is shown in the Description box in plain English for your review (see Figure 6-7). Click OK. 14. In the next two pages of Alerts and Notifications, you can create alerts, define responses to those alerts, and send the notifications via e-mail, page, or Net Send or write to a Windows Application event log. Refer to Microsoft SQL Server 2008 Books Online for more details on these topics. Figure 6-6 Configuring a step for an SQL Server Agent job 260 Hands-On Microsoft SQL Server 2008 Integration Services 15. The Targets page lets you define which server to target with this job. SQL Server 2008 includes a feature called multiserver administration to manage multiple servers by designating them a master server and target servers. The master server distributes jobs to the target servers and receives events from them to keep the status information. Target servers periodically connect to master servers to get the new schedules for the jobs allocated, download new jobs, or update the master server with the latest status about the jobs being run. You can create a master server or target server from multiserver administration by right-clicking SQL Server Agent in the SQL Server Management Studio. If no target servers are listed, the only option is to run the job from the local server. For more details on multiserver administration and how to make a master server or a target server, refer to Microsoft SQL Server 2008 Books Online. Figure 6-7 Creating a schedule for a job Chapter 6: Administering Integration Services 261 16. Click OK to create the job. You will see this job listed in the Jobs node under SQL Server Agent. Have a cup of coffee, and by the time you return to your computer, you will see the test mails in your inbox. Exercise (Using an SQL Server Agent Proxy Account to Run the Job) In the previous part of the exercise, you’ve added the job step using an SQL Server Agent Service Account. In real life not many DBAs would like to run the jobs under such a privileged account. SQL Server 2008 does provide an alternate way to run the jobs under a less privileged account. To understand how the SQL Server Agent lets you do this, you should know a couple of things. Firstly, note that several security enhancements have been made in SQL Server 2005 onward that affect the way jobs run in the SQL Server Agent. In the versions before SQL Server 2005, the SQL Server Agent service account had to be a member of the local Administrators group when executing the xp_cmdshell extended stored procedure, ActiveX scripting, or CmdExec jobs owned by users who were not members of the SysAdmin fixed server roles. This is not required in SQL Server 2005 and above, as it has a hierarchy of fixed database roles (in the MSDB database) to control access to the SQL Server Agent. A user must be a member of any of the three fixed database roles in order to use the SQL Server Agent. These roles, SQLAgentUserRole, SQLAgentReaderRole, and SQLAgentOperatorRole, are stored in the MSDB database. Second, when you define a job step for an SQL Server Agent job, you choose a Type for the job as you did in Step 5. This job step is actually called an SQL Server Agent subsystem and is a security object that represents a set of functionality available to special accounts called the SQL Server Agent Proxy. The Sysadmin fixed server role can create multiple proxy accounts and assign each account to a separate step of an SQL Server Agent job. This means that you can create security contexts using SQL Server Agent proxy accounts limited to their own subsystems and hence to a job step only. You can have a proxy for multiple subsystems to keep things simple, but if you have a requirement to secure each and every job step, you can do so. Ideally, you will not run the SQL Server Agent service under a Microsoft Windows account that has administrative privileges but will create dedicated proxy accounts with necessary permissions required to run the job steps for the required subsystems and will use these proxy accounts to configure the job steps. Enough theory, it’s time to do the hands dirty. 17. Create two windows accounts as follows that we will use in Chapter 7 as well. Choose Start, right-click Computer, and choose Manage from the context menu. In the Server Manager window, expand Configuration and then the Local Users and Groups folder, right-click the Users folder, and choose New User from the 262 Hands-On Microsoft SQL Server 2008 Integration Services context menu. This will open a New User window where you can create a user. Fill in the following details to create a user account: User name ISUser01 Password ISUp@ss01 Clear the User Must Change Password At Next Logon option check box before clicking the Create button. Create another user with the following details: User name ISUser02 Password ISUp@ss02 Close the New User and Server Manager windows. 18. Next create logins for both users in SQL Server Management Studio. Assign db_datareader role to ISUser01on the Campaign database. To do this, go to User Mapping page, select the Campaign database in the Users Mapped To This Login section, and select db_datareader in the Database Role Membership section. Click OK to create this login. Assign SQLAgentOperatorRole to ISUser02on the MSDB database. To do this, go to User Mapping page, select msdb as the database in the Users Mapped To This Login section, and select SQLAgentOperatorRole in the Database Role Membership section as shown in Figure 6-8. Click OK to create this login. 19. In this step we will create an SQL Server Agent proxy account and will link this account to ISUser01. To link these accounts, we will need to use a credential. So, let’s first create a credential for ISUser01. In Management Studio, expand the Security node, right-click on the Credentials node and select New Credential from the context menu. Type ISUser01 in the Credential Name field. Select the Windows user account ISUser01 in the Identity field by clicking the ellipsis button. Finally fill in the password fields for the ISUser01 account and click OK. Now expand SQL Server Agent and right-click the Proxies node. Select New Proxy from the context menu. Type ISUser01 in the Proxy Name field and select ISUser01 in the Credential Name field by clicking the ellipsis button. Now select SQL Server Integration Services Package in the Active To The Following Subsystems section (Figure 6-9). Click OK to create the proxy account. 20. Until now you’ve created accounts—ISUser01 with sufficient permissions to execute the package and ISUser02 with rights to start the job. Let’s now modify the job to use the proxy created earlier. Open the Running Mailing Opportunities Job properties from the Jobs node. Go to the Steps page and click Edit to edit the step. In the Run As field, select ISUser01 proxy from the drop-down list. Click OK twice to close the Job Properties window. Chapter 6: Administering Integration Services 263 21. Now, Logon with ISUser02 account. Open SQL Server Management Studio and expand the Jobs node under SQL Server Agent. Right-click the Running Mailing Opportunities job and choose Start Job At Step from the context menu. You will see the job executed successfully. So, in the preceding step you’ve run a job using an account ISUser02 that had no permissions on Campaign database and with the proxy account ISUser01 that had just sufficient permissions to execute the job successfully. Figure 6-8 Assigning an SQL Server Agent operator role 264 Hands-On Microsoft SQL Server 2008 Integration Services Exercise (View the Job History) Let’s now study how you can obtain the status of a job: You can configure a notification to be sent to you via e-mail while configuring the c job in the Notifications tab. You can choose to write to the Windows Application event log in the c Notifications tab while configuring the job. You can select to see the Job History from the Report drop-down list box in the c Summary sheet of Jobs in SQL Server Management Studio. Figure 6-9 Creating a Proxy for SQL Server Integration Services Package subsystem Chapter 6: Administering Integration Services 265 To see the detailed job history, you can right-click the job and choose View c History. When you choose the View History option, you will see the history as shown in the Log File Viewer window (see Figure 6-10). Review In this exercise, you learned how to automate execution of an SSIS package using the SQL Server Agent. You learned how to create a new job, add steps to the job, specify a schedule for the job, and view job history. You have also seen some of the key features that make creation of jobs in the SQL Server Agent much safer and easier to run, such as: Figure 6-10 Job History in Log File Viewer window 266 Hands-On Microsoft SQL Server 2008 Integration Services e user account under which the job executes doesn’t need to be sysadmin c anymore; you can use a proxy account to run the packages. e steps of a job have a type that is, the agent subsystem—SQL Server c Integration Services Package—which allows you to configure all the options required to run a SSIS package in this category. Executing SSIS Packages Programmatically SSIS packages can also be run programmatically using the SSIS Object Model. You can build a custom application such as a Windows Forms application, an ASP.NET Web form, or a Web service that allows users to run SSIS packages on local or remote servers. SSIS exposes a rich object model that allows you to not only manage and run SSIS packages but to build custom objects and packages to extend SSIS functionality. More details on programming facilities in SSIS are covered in Chapter 11. Taking you through the custom application development for this exercise is out of scope of this book; however, the steps that you will take while building a custom application to run SSIS packages are listed here. 1. First of all, you will add a reference to the Microsoft.SqlServer.ManagedDTS assembly in your project, as it provides access to the managed run-time engine. 2. Import the Microsoft.SqlServer.Dts.Runtime namespace in your application, as it will allow you to use classes and interfaces to load and run packages. The Microsoft.SqlServer.Dts.Runtime namespace is commonly used in custom applications, as it contains the classes and interfaces to create packages, custom tasks, and other package control flow elements. 3. The Application class provides a mechanism to discover and access package objects. You will use the Application class to discover and instantiate the package object. 4. If you want to run the package on a local server, you will load the package first before executing it. You can load a package using different methods based on the storage type. LoadPackage c Loads a package stored in the file system LoadFromSqlServer c Loads a package stored in the SQL Server LoadFromDtsServer c Loads a package stored in the SSIS Package Store Chapter 6: Administering Integration Services 267 For running a package on a remote server, you can use the LaunchPackage web service method that loads the package using one of these methods based on the source or storage type. You can also choose to run a package on the remote server using the sp_start_job system stored procedure inside your application, in which case, you don’t have to follow any of the preceding steps, but simply add a reference to the System.Data assembly and build your application as you would to execute a stored procedure on a remote server. 5. Irrespective of the fact that you can build an application to run SSIS packages locally or on a remote server, SSIS packages execute on the server where the SSIS service is installed. So, if you are executing packages locally, the SSIS service has to be installed on the local server and if you are executing packages on the remote server, the SSIS service has to be installed on the remote server. 6. Finally, you use the Execute() method to execute the package. Summary SQL Server 2008 comes with several tools that enable you to manage Integration Services and Integration Services packages effectively and easily. You started this chapter learning to manage storage locations for storing Integration Services packages. You’ve used SQL Server Management Studio and dtutil to manage Integration Services packages and storage areas. You also learned how to import and export an Integration Services package from one storage location to the other. In the process, you created a new storage location on the file system for these packages. Last, but most important, you learned about various tools to run an Integration Services package that include the use of the Execute Package Utility and the DTExec command-line utility. In the end you automated running of a package by creating a job and its schedule using the SQL Server Agent. In the next chapter we will discuss securing Integration Services packages and use of fixed database-level roles to control access to SSIS packages. . to Microsoft SQL Server 2008 Books Online for more details on these topics. Figure 6-6 Configuring a step for an SQL Server Agent job 260 Hands-On Microsoft SQL Server 2008 Integration Services 15 258 Hands-On Microsoft SQL Server 2008 Integration Services 2. Expand the SQL Server Agent node in Object Explorer and right-click Jobs;. execute the job successfully. Figure 6-8 Assigning an SQL Server Agent operator role 264 Hands-On Microsoft SQL Server 2008 Integration Services Exercise (View the Job History) Let’s now study