2 – The SQL Server landscape 45 http://www.microsoft.com/do wnloads/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-a n-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- perf ormance-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 2 – The SQL Server landscape 46 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), 2 – The SQL Server landscape 47 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. 2 – The SQL Server landscape 48 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. 2 – The SQL Server landscape 49 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. . ( SQL_ Logins), 2 – The SQL Server landscape 47 Databases, ( Database_Info and Databases), SQL Agent job information (Jobs), server- specific data ( SQL_ Servers) and the server location (Server_ Location) http://www.simple-talk.com /sql/ database-administration/let-powershell- do-a n-inventory-of-your-servers/ • SQL Server 2008 Data Collector – this is a new feature in SQL Server 2008 that you may. performance data gathering, is described by Brad McGehee at: http://www.simple-talk.com /sql/ learn -sql- server /sql- server- 2008- perf ormance-data-collector/. In addition to free tools and technologies,