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

You can create a master server or target server from multiserver administration by right-clicking SQL Server Agent in the SQL Server Management Studio.. Exercise Using an SQL Server Agen

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

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

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

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

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

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

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

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

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

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