SQL Server Tacklebox- P10 docx

For the remainder of this chapter, I will focus on how to create and use the DBA Repository, how to load it with all of the previously-described database information, using SSIS, and fin

http://www.microsoft.com/downloads/details.aspx?FamilyID=eedd10d 6-75f7-4763-86de-d2347b8b5f89&displaylang=en

• PowerShell – while I am not necessarily a developer, I do aspire,

occasionally, to expand my knowledge base and find tools that will make

my life easier One of these tools is PowerShell, which has been incorporated into SQL Server 2008 and promoted extensively

by Microsoft While I have not used this tool to build DBA solutions, others have and it is worth reviewing some of their solutions One such solution, by Allen White, can be found at:

http://www.simple-talk.com/sql/database-administration/let-powershell-do-an-inventory-of-your-servers/

• SQL Server 2008 Data Collector – this is a new feature in

SQL Server 2008 that you may choose to use in your day-to-day DBA data gathering tasks Once such technique, performance data gathering, is described by Brad McGehee at:

http://www.simple-talk.com/sql/learn-sql-server/sql-server-2008-performance-data-collector/

In addition to free tools and technologies, you could certainly acquire a vendor application that will provide some form of out-of-the-box "DBA repository" There is no shame in that whatsoever Many DBAs think that the only way they will get the solution they really want is to build it themselves, often believing that they will save their company lots of money in the process While this attitude is admirable, it is often misguided For one, it is unlikely that you'll be able to create

a documenting solution that will match the capability of a vendor product, the most obvious reason being that you are one person and your time will be limited

If your time can be given full bore to such an endeavor, you will then have to weigh the man-hours it will take you to build, test, and deploy and maintain the solution

Even without huge time constraints, a vendor-supplied solution is likely to have features that a home-grown one will never have, plus updates are regularly dispersed and features continually added In general, my advice to DBAs is that it's certainly worth researching vendor tools: if you find one that works for you, then that's probably the best route to go down

However, despite the apparent advantages of going down the Microsoft or vendor tool route, that is not the way that I went and here is why: I reasoned that as a DBA I would need to use SSIS often, either because I would be directly responsible for data loading/ transfer tasks that needed SISS, or I would have to work with developers who used SSIS

In short, a considerable fringe benefit of building my own repository solution would be that it would require me to expand my knowledge of creating all kinds of

SSIS packages and use objects I would not normally use Also, I did not want to

be in a position where I did not know more than the developer That is just me

So, in fact, I set out on the project primarily to gain valuable experience in SSIS Fortunately for me, and many other DBAs with whom I have shared the solution,

it turned out to be quite useful For the remainder of this chapter, I will focus on how to create and use the DBA Repository, how to load it with all of the previously-described database information, using SSIS, and finally how to generate reports on the assembled data using SSRS

The DBA repository solution

The DBA Repository solution consists of three components:

• A SQL Server database call DBA_Rep

• An SSIS package that contains data flow tasks designed to query a list of SQL Servers and store the results in the DBA_Rep database

• A series of Reporting Services reports and queries that the DBA team can use to make important decisions about their SQL Server infrastructure

I will introduce each piece of the solution individually and then marry them together to show how a DBA can use this solution every day The code download file for the book (http://www.simple‐ talk.com/RedGateBooks/RodneyLandrum/SQL_Server_Tacklebox_Code.zip) includes all the components of this solution, so that you can deploy and extend as you see fit

The DBA_Rep database

If you are going to store all of this information centrally in SQL Server, you need a database When I designed the DBA_Rep database, I decided to link each category

of information, such as Server, Database Management, Security, and job information, using the SQL Server name as the key field

With hindsight, the database design could have been a bit more normalized, with key columns other than the server name, for example, but for the most part it has worked as I intended and performs well Many of the joining queries you will see, when reporting off the DBA_Rep database, use this SQL Server Name key field Figure 2.6 shows the tables in the DBA_Rep database, as well as the columns specific to the SQL_Servers table

As you can see, the DBA_Rep database is fairly straightforward in terms of the scope of information it stores There are tables for logins (SQL_Logins),

Databases, (Database_Info and Databases), SQL Agent job information (Jobs), server-specific data (SQL_Servers) and the server location (Server_Location)

In this case, location refers to the geographical location of the server, like Beijing

or Houston or even Pensacola (shameless hometown plug) This is the one piece

of information that will need to be manually identified for the DBA repository

Figure 2.6: DBA_Rep sample schema

On this note, it is a pity that Microsoft, at present, does not offer "Extended Server Properties", in the same way that they provide Extended Properties for the internal documentation of database objects For example, I can create a table in a database and add an extended property that explains the purpose of the table but I cannot do the same at the server level If there was an extended Server property that held the location of the server, and its primary function, I could automate the collection of this data and store it in the SQL_Servers table, which is designed to store the bevy of Server information that we have collected about our SQL servers, including version, edition, collation and so on

To demonstrate how the DBA repository works, I will walk through an example using the SQL_Servers table, and how it is populated using the SSIS package The other tables in the database, aside from Server_Location, are populated in the same way

The SSIS package to load the DBA_Rep database

When I embarked on this project, the only previous attempt to consolidate and document server information had taken the form of a fairly primitive DTS package The main problems with it were:

• The package had to be updated manually with each new server addition

• It became unwieldy when more than 10 servers existed because every server connection was manually created and maintained

With over 100 servers for which to gather information, it was clear that this DTS package was not up to the job

SQL Server Integration Services contains three objects that make the process of

gathering information from multiple servers clean and efficient: Variables, Foreach Loop Containers and Expressions These three objects provided the

basis for the entire DBA_Rep documentation solution

When I want to add or remove a server, all I need to do is add this server to,

or update a bit flag on, a driving table, called ServerList_SSIS (more on this shortly)

The SSIS package that populates the DBA_Rep database is called

Populate_DBA_Rep Figure 2.7 shows several of the tasks that comprise the SSIS package

Figure 2.7: Populate_DBA_Rep SSIS package

Over the following sections, I'll walk through every step that is required to retrieve Server information from your SQL Server instances, and store the data in the

SQL_Servers tables of DBA_Rep Once you've seen how this section of the package works, you'll understand how the others work too

The only information the package needs in order to do its work is the names of the SQL instances that we wish to document In a way, this is a manual discovery process If you were to shell out to a command prompt where you have SQL Server installed and execute "sqlcmd /Lc", you may see something similar to that shown in Figure 2.8

Figure 2.8: List of SQL Servers using SQLCMD