SQL Server Tacklebox- P11 pptx

All I need to do is place these server instance details into a table, called ServerList_SSIS, which can then be used to "seed" the Populate_DBA_Repository SSIS package.. This field is us

In this simple example, we have discovered one server, with two instances of SQL

Server, MW4HD1 and MW4HD1\SRVSAT The former is a version 10, or SQL

Server 2008, instance, and the latter a version 9, or SQL Server 2005, instance This is a simple scenario, but the principles would be exactly the same were the instances installed on two separate servers on the network, or if there were hundreds of instances distributed across 10, 50 or 200 servers on your network In short, this solution will work with any number of servers

All I need to do is place these server instance details into a table, called

ServerList_SSIS, which can then be used to "seed" the

Populate_DBA_Repository SSIS package The ServerList_SSIS table is shown in Figure 2.9

Figure 2.9: The Serverlist_SSIS table

As you can see, the Server column stores the instance names The other columns

in the table are as follows:

• Connect – a smallint data type If it has a value of "1" for the server, the

SSIS package will attempt to connect otherwise it will skip the server

• Version – version of the SQL Server instance, 8, 9 or 10 for SQL Server

2000, 2005 and 2008 respectively This field is used after the package execution to update the servers that are added to the SQL_Servers table that contains the information for each SQL Server from Listing 2.1 of this chapter

• DMZ – used for specific connection types where SQL Authentication

has to be employed

• LocationID – denotes the geographic location of the server A join to

the Server_Location table, on LocationID, will reveal the location details, such as a city name or region

We are now ready to walk through the steps that comprise the SSIS package The basic objective is to have the package load, and "spin" through, the list of SQL

Server instances in our Serverlist_SSIS table and, one by one, connect to the appropriate server, execute the queries, and then store the results in the DBA_Rep database

Truncate tables in DBA_REP

The top portion of the package, shown in Figure 2.7, simply truncates all of the tables so that you can subsequently insert fresh, clean data So, in this case, we will simply have a "Truncate SQL_Servers" control flow task that truncates the

SQL_Servers table While there is no archival process for the SQL_Servers table, there is simple archiving functionality for the Jobs query If you need to maintain archival information for your server information all that is required is that you add another data flow to append data to an archive table, prior to performing the truncate

Populate ADO variable with server names from Serverlist_SSIS

This task populates an ADO System Object variable, called SQL_RS, with the server instances names, which it retrieves from the ServerList_SSIS table The query that is used to populate the SQL_RS object variable is shown in Listing 2.7 SELECT LTRIM(RTRIM(Server)) AS servername

FROM ServerList_SSIS

WHERE (Connect = 1) AND (DMZ = 0)

ORDER BY LTRIM(RTRIM(Server))

Listing 2.7: Populating the SQL_RS variable

In SSIS you can use many types of variables, such as a String variable and a System Object variable In order to iterate through each server in the ServerLIst_SSIS

table, I had to use both The ForEachLoop container that iterates through the list

of server requires the ADO object source type of variable However, the Expressions that dynamically control the actual connection string of the target servers (explained shortly) require a string variable Figure 2.10 shows the

"Populate ADO Variable with Server Named from Serverlist_SSIS" task, as well as the list of variables that I use

Figure 2.10: Populating the ADO System Object Variable, SQL_RS

Figure 2.11: Using the SQL_RS ADO variable in the Foreach Loop container

Load server info

Once the SQL_RS Object variable is populated with a list of servers from the

ServerList_SSIS table, which in this case will be two instances, this ADO variable is fed into the next task, "Load Server Info" In this task, a Foreach Loop Container object enumerates through the list of servers in the SQL_RS variable, as shown in Figure 2.11

Notice that the SQL_RS variable is referenced now as User::SQL_RS If you click

to the "Variable Mappings" tab of the Foreach Loop editor, you will see that this object variable will be used to populate a string variable called SRV_Conn, as shown in Figure 2.12

Figure 2.12: Mapping the ADO Object variable to a string variable, SRV_Conn

This mapping of Object-to-String ultimately leads to the final dynamic association, and that is to the Connection Manager object

Connection manager

The Connection Manager object, called MultiServer, controls which servers to connect to in order to execute the underlying SQL code, in this case the script shown in Listing 2.1 In other words, the Multiserver Connection Manager object is used to connect to each listed SQL Server instance, for every Foreach Loop Container in the Populate_DBA_Rep package You can see other Connection Manager objects, as well as the MultiServer object, in Figure 2.13

Figure 2.13: Connection Manager objects in Populate_DBA_Rep SSIS package

All of the Multi_Server_XXX objects are used in the same way as Multiserver, but control connections to various locations and versions; Multi_Server_9, for example, is for connections to SQL Server 2005 instances, and

Multi_Server9_DMZ connects to SQL Server 2005 instances in the DMZ, and thus knows to use SQL authentication and not Windows authentication in cases where cross domain authentication may not exist for the account executing the package The Local.DBA_Rep object is the Connection Manager for the DBA_Rep

database, where the gathered server information will be stored

Figure 2.14 shows the Properties window for the MultiServer Connection Manager object