Introduction x Chapter 7 Surely, like me, you are afraid of break-ins. I would not like to come home and find my things strewn about, wondering what all was taken. If you work for a large company that is regulated by one or more government mandates, like HIPAA or SOX (Sarbanes-Oxley) you cannot afford to be without a security monitoring solution. Here, I will introduce a set of scripts to show how to analyze login accounts, the first barrier between the outside world and your data. I will also give pointers to other solutions that will help you track down potential breaches in your outer wall defenses. Chapter 8 In this chapter I will unveil the monster. It is the Data Corruption beast. Despite advances in hardware, the number one cause of corruption, it does still exist. You will need to first hunt out corruption before you can slay it. And you need to find it early in its lair so as to not spread the corruption to backup files. Here, I will intentionally, though begrudgingly, corrupt a database and show some of the ways to discover and fix it, emphasizing the need for a solid backup strategy. Code Download All of the scripts provided in this 'tacklebox', as well as the full DBA Repository solution, presented in Chapter 2, are available to download from: http://www.simple‐talk.com/RedGateBooks/ RodneyLandrum/SQL_Server_Tacklebox_Code.zip . 11 CHAPTER 1: EATING SQL SERVER INSTALLATIONS FOR BREAKFAST For many DBAs, choosing an appropriate SQL Server installation is a lot like ordering breakfast at a diner: there is something to suit all appetites, tastes and budgets, and the range of choices can often be mind-boggling. A sample SQL Server breakfast menu might look something like this: The Express Breakfast (For the cost-conscious) • 1 SQL Server Express on top of a Windows XP Professional • 1 large hard drive • 2 Gig of RAM The Continental (Enough to hold you over for a while) • 1 SQL Server Standard Edition 32 bit on Windows Server 2003 Standard • 1 instance of Reporting Server • 1 instance of Analysis Server • 250 Gig RAID 5 Disk Subsystem • 4 Gigs of RAM The Deluxe (When cost is no barrier to hunger) • 1 SQL Server Enterprise Edition 64 bit Clustered • 2 Windows Server 2003 Enterprise Edition servers • 1 RAID 10 1TB Data Partition • 1 RAID 10 200G Log Partition • 1 RAID 0 100G TempDB Partition • 64 G of RAM It is the DBA's task to choose the SQL Server configuration that most accurately reflects the specific needs of a given project, whether it is for cost-conscious deployments, high availability, data analysis or high-performing online transactions for a critical business application. In this chapter, I will investigate the myriad available installation options and propose a custom post-installation script with which to automate the most common configurations. 1 – Eating SQL Server installations for breakfast 12 Specification, installation, configuration Once the project has been decided, there are many ensuing steps to climb to get from concept to full deployment. Installing SQL Server on the chosen platform is, in reality, only a small part of the overall pre-production setup process. Pre- installation, you have the planning stage, where you need to define the capacity, memory and CPU requirements, and required disk subsystems for your physical server(s). Post-installation, the true work begins, when it is time for configuration. Fortunately, both of the rote tasks of installation and configuration can be automated, to some degree. Specifying the physical server Generally, the size of a given project, in terms of the number of expected users, amount of data to be stored, and so on, will dictate the capacity of the physical server, or servers, that comprise the SQL Server installation. The sort of breakfast that lands on your plate is likely to differ wildly, depending on whether you work for the ubiquitous "mom and pop" shop, or a large enterprise. In the former case, you may well find yourself ordering the parts for the servers yourself, and putting them all together, before moving on to the SQL Server installation. If you are a DBA at the Fortune 100 end of the scale, you may never even get to see your servers, let alone build them! You will just be informed, by way of an e-mail from the server administration team, that your server is powered up, with the base OS installed, and ready to endure your SQL witch-trickery. In my career, I have sampled both the self-service buffet and the gourmet tasting menu. While I consider it a luxury to no longer have to have to build my own servers, I would not trade that experience. I am often asked how important it is for a DBA to have a technical understanding of networking, storage or even Windows Server systems. In my opinion, it is critical. I could go as far as to say that every DBA should spend two years working in technical support, troubleshooting problems and building systems from the ground up. But that is topic for a different book. Suffice to say here that, regardless of whether you are building your own server or having it delivered on a silver platter, it's vital that a DBA understands a few important components of that physical server, and the factors that affect how you choose these components. 1 – Eating SQL Server installations for breakfast 13 RAM SQL Server, like any other application, is going to use memory. RAM, like CPU and disk arrays, comes at a cost and how much RAM you are going to need depends on several factors. If you know that you will have 250 users connected simultaneously to a 200 Gigabyte database, then 4G of RAM on SQL Standard 32-bit and Windows 2003 is not going to be enough. Without wishing to be overly formulaic, I will say that connections come at a RAM cost. More connections equals more RAM. SQL Server will run comfortably in 1G of memory, but you would not want to roll out a production server on that amount. Ironically, one of the most important factors to consider is one that a DBA has very little control over: what application is going to access your beloved database objects? Is it "homegrown" or "third-party"? This is an important question because, if you do not "own" the database schemas, you could find yourself unable to employ basic performance tuning techniques, like adding indexes. In these situations, you are at the mercy of the vendor, whose recommendation is often to "add more RAM," even when all that is required is to add an overlooked index. At this planning stage, it is always safer to overestimate the need for memory. Get as much as you "think" you will need, and more if performance outweighs cost, which it should. Note though, that buying the additional physical RAM is not the only cost and is seldom the cure. You will also have to purchase software that can support the additional RAM and this might mean, for example, buying Windows Server Enterprise instead of Standard Edition. CPU Specifying processor requirements for a SQL Server is a slightly more complex task than specifying RAM. For one thing, software such as SQL Server can be licensed per processor. This can be quite expensive. As a DBA, you must understand the difference between the different processor types. For example, is the processor 32- or 64-bit architecture? Is it single-core or multi-core, meaning you can gain additional virtual processors with one physical processor? If it is multi-core, is it dual-core or quad-core, or octa-core? I'm not even sure if that last one exists yet, but it probably will soon. Why is it important to know the answer to all these questions? Well, you do not want to be the DBA who relays to your boss that your new 2-proc, quad-core SQL Server is going to require 8 "per proc" licenses when, in fact, it will only require 1 license per "physical" processor, even if SQL Server will use all 8 cores. 1 – Eating SQL Server installations for breakfast 14 The speed of the processor is important as well; what Gigabytes is to RAM, Gigahertz is to processors in determining how your new server is going to perform. Take a little time up front to investigate the server specifications, especially if someone else was responsible for ordering it. It will save you 3 months of pain later on, when the server is ill-performing. Disk subsystem The choice of disk subsystem is the most difficult pre-installation hardware decision that the DBA has to make. There are just so many options. Fortunately, you have put together the documentation for your SQL Server infrastructure that will help you narrow down the choices, right? You know, for example, that your performance requirements dictate that you are going to need RAID 1-0 data and log partitions, with a separate volume allocated for TempDB split across as many spindles as possible. OK, so you don't have that document; not a big deal. If you are able to at least have a RAID 5 configuration then you are off to a good start. It is also worth noting that if you are installing SQL Server in a clustered environment, you will need to have a shared disk array, typically implemented via a Storage Area Network (SAN) back end. Free tools are available for you to stress test the disk subsystem of the SQL Server installation, prior to moving it to production. One such tool is SQLIO, provided by Microsoft: http://www.microsoft.com/downloads/details.aspx?familyid=9 a8b005b-84e4- 4f24-8d65-cb53442d9e19&displaylang=en Ready to install – almost So, you have your server built and are ready to install SQL Server. Let's say that you have chosen to install a 32-bit version of SQL Server 2008 Standard, on Windows 2003 Enterprise, with 16 Gigabytes of RAM. You have been given a 350 Gigabyte data partition, and a 200 Gigabyte partition for the logs and TempDB. One thing you can take comfort in is that this will be your server, at least for the next several hours. If you're lucky, and the project is not as urgent, you may even have a day or two. For this short, precious time, you have total control of this server and can do with it whatever you will. Of course, you want to get the installation right and this is where having an established, standard set of installation procedures is priceless. . http://www.simple‐talk.com/RedGateBooks/ RodneyLandrum /SQL_ Server_ Tacklebox_Code.zip . 11 CHAPTER 1: EATING SQL SERVER INSTALLATIONS FOR BREAKFAST For many DBAs, choosing an appropriate SQL Server installation is a. hold you over for a while) • 1 SQL Server Standard Edition 32 bit on Windows Server 2003 Standard • 1 instance of Reporting Server • 1 instance of Analysis Server • 250 Gig RAID 5 Disk Subsystem. install – almost So, you have your server built and are ready to install SQL Server. Let's say that you have chosen to install a 32-bit version of SQL Server 2008 Standard, on Windows 2003