TechTarget Windows Media SearchWinIT.com SearchExchange.com SearchSQLServer.com SearchEnterpriseDesktop.com SearchWindowsServer.com SearchDomino.com LabMice.net E-Guide Mid-Market Guide to Architecting SQL Server for High Performance and 100% Uptime on a budget It was only a short time ago when organizations with fully dedicated SQL Server DBAs, redundant hardware, and reams of expertise were able to configure SQL Server for mission critical, highly available situations. Times change. With the advent of virtualization, new features in SQL Server 2008 and a little background knowledge, any organization is able to have highly available, fault tolerant SQL Server installations. OK, 100% uptime might be a little optimistic, but 99.99% is within your reach. Read this expert E-Guide from Dell to learn key concepts that will help you architect your next SQL Server installation. Sponsored By:
Table of Contents E-Guide Mid-Market Guide to Architecting SQL Server for High Performance and 100% Uptime on a budget Table of Contents: Creating fault-tolerant SQL Server installations The short course on how SQL Server really works Maintaining high availability of SQL Server virtual machines Resources from Dell, Inc. Sponsored by: Page 2 of 11
Creating fault-tolerant SQL Server installations Creating fault-tolerant SQL Server installations By Danielle Ruest and Nelson Ruest, Contributors Organizations banking on SQL Server to protect and manage their internal data are in for a treat when they upgrade to SQL Server 2008. That's because the latest version of SQL Server provides a host of new features geared toward data protection and database fault tolerance, with both traditional and new or updated fault tolerance configurations now available. Traditional fault tolerance configurations for SQL Server rely on the Windows Server Failover Clustering service. Windows Server supports two types of failover clusters: single-site and multi-site. In a single-site cluster, you create a server configuration that includes up to 16 nodes all linked to the same shared storage container. Shared storage must be in the form of a storage area network (SAN), iscsi targets or both. In the simplest single-site cluster configuration, one node runs the SQL Server service and the other waits in stand-by to take over the service in the event of a hardware, operating system or application failure on the original node. This is an active-passive cluster, meaning one node is active while the other is passive. When your hardware includes enough spare resources, you can create active-active clusters where each node runs its own SQL Server implementation, but also acts as a stand-by node for the others. While this configuration offers fault tolerance for the SQL Server service, it does nothing for SQL Server data. If the shared storage container fails, then all nodes will lose data. In a multi-site failover cluster configuration, cluster nodes do not rely on shared storage because each node is located in a different site. In many cases, organizations rely on direct-attached storage (DAS) to create the cluster. Note that you can also use SANs, iscsi or both to provide additional storage protection. However, since all data containers must include the same data in order to support a failover, you must use a replication engine to ensure that all copies of the data are in synch at all times. In fact, a third-party replication tool is needed to do so since SQL Server does not include the ability to provide this type of real-time replication service. Failover clusters work at the instance level in SQL Server. Each time you create a SQL Server failover cluster, you create a fault tolerant instance of SQL. Each of the databases you create within the instance then automatically inherit the fault tolerance you prepared for the instance. Failover clusters also require either custom hardware (as in the case of the single-site cluster) or third-party tools (as with multi-site clusters). Finally, failover clusters only protect databases that are contained within clustered SQL Server instances. This is one reason why the Microsoft SQL Server team enhanced the database mirroring engine in SQL Server 2008. With database mirroring you can apply fault tolerance at the database level. What's even better is that database mirroring does not require any special hardware or software tools. Databases can be mirrored from one SQL Server installation to any other. Just keep in mind that you should use the same SQL Server versions and editions to keep it as simple as possible. In addition, the mirrored database can be used to provide additional functionality such as reporting services. Finally, database mirroring offers the same type of fault tolerance as Sponsored by: Page 3 of 11
Creating fault-tolerant SQL Server installations failover clustering, since you can configure the mirrored database to automatically pick up the service should the primary database fail for any reason. Database mirroring is the poor man's failover clustering, and offers unprecedented fault tolerance to organizations of all sizes. Larger organizations that want instant-on fault tolerance and data protection can even combine failover clustering with database mirroring to create more comprehensive fault-tolerant installations. You can even combine physical and virtual machines in any of these fault tolerance scenarios, running a physical machine as the main production system and using virtual machines as the backups. This offers truly low-cost fault tolerance for SQL Server installations. If data availability is something that is important to your organization, then take the time to examine these options to determine which best suits your needs. Creating fault-tolerant virtual installations More and more organizations are moving their physical workloads to virtual machines to reap the benefits of a consolidated datacenter. Database servers are no exception to this process since they can operate quite well in a virtual environment. In fact, the Microsoft SQL Server Support Team has outlined specific strategies for virtualizing SQL Server installations. Both SQL Server 2005 and 2008 are supported on Hyper-V and other, non-microsoft hardware virtualization technologies. One of the great advantages of virtualizing SQL Server installations is that it allows you to create more costeffective fault-tolerant installations. For example, creating a two-node failover cluster in the virtual realm really means creating two virtual machines and linking them to shared storage, usually in the form of an iscsi target which can be either located on a SAN. For those who do not have the means to obtain a SAN, the target can be created on a file server using low-cost software such as Rocket Division Software's StarWind solution. Doing this creates a guest failover cluster one that operates at the virtual machine layer. Guest clusters are sometimes better than host server clusters because they allow the application contained within the guest to be aware of potential failures. In some cases, this can provide better data consistency within the application. While guest clusters are useful, host clusters are an absolute -- especially when 20-plus virtual machines are running on a single host. You simply can't afford to have all of these machines fail in the event of a hardware failure on the host. Using a host cluster will automatically move the VMs from the failing host to another host with spare resources. In addition, a host cluster is an absolute must for SQL Server since the Microsoft Customer Support Services team for SQL Server does not support guest clustering. If you cannot cluster SQL Server in the virtual layer, then one of the only ways to provide fault tolerance for your virtual instance of SQL Server is through host failover clustering. This means all of your virtual SQL Server installations must be standalone. It also means that in the event of a hardware failure, the users connected to the virtual instance of SQL Server will experience a loss of productivity since the VM fails and is restarted on another host. Sponsored by: Page 4 of 11
Creating fault-tolerant SQL Server installations The other means for providing high availability of a virtual SQL Server installation is once again database mirroring. As mentioned before, database mirroring does not require any special hardware or software tools, and databases can be mirrored from one SQL Server virtual machine to another SQL Server VM. In the event of a host server failure or even a VM failure, users will automatically be redirected to the mirror database with little or no service interruption. Using this strategy, you can provide fault tolerance to your virtual installation of SQL Server in a supported configuration. As you can see, database mirroring is an integral part of SQL Server and has been since SQL Server 2005. If you decide to use database mirroring, then you should not make the SQL Server virtual machine highly available through a host cluster, otherwise the host cluster will restart the VM in the case of a failure. This could cause two versions of the same database to be live on the network, something you'll want to avoid at all costs. Instead, configure the SQL Server virtual machine as a standalone VM without fault tolerance, then use the SQL Server management tools to configure database mirroring for the most precious databases you run. This way, your virtual instances of SQL Server will be available on a constant basis and your users will never know the difference. Sponsored by: Page 5 of 11
30% increase in speed and performance. Daniel Cosey, CareerBuilder* Every month, 23 million people use CareerBuilder.com to find their next job. Dell PowerEdge servers and Microsoft SQL Server helped CareerBuilder deliver reports up to 30% faster. With Dell, you can make the most of Microsoft SQL Server. We help speed deployment, simplify management, and reduce costs. That s why we ve sold more SQL Server than anyone else, anywhere in the world. SIMPLIFY your database AT DELL.COM/SQL *Individual results may vary.
The short course on how SQL Server really works The short course on how SQL Server really works Don Jones, Contributor Face it, you never intended to become a SQL Server expert, but the proliferation of this database engine and its many editions requires somebody to feed and care for it. You're the "Microsoft Guy" (or Gal), so whether you wanted to be or not, you were elected. This series of articles is all about making you more effective with SQL Server as an administrator, not a programmer. Before we start diving into real-world tasks, however, a little bit of background information will be helpful. So how does SQL Server work? Believe it or not, understanding this aspect of the "black box" will help you get a handle on nearly every aspect of Microsoft SQL Server, from backups and restores to replication and mirroring. SQL Server stores things on disk in 8 KB chunks called pages. It also manipulates those same 8 KB chunks in memory, meaning the smallest unit of data SQL Server works with is 8 KB. When data is written to disk, an entire row of it must fit within that 8 KB page. It's possible for multiple rows to share a page, but a row cannot span multiple pages. So, if a Customers table has columns for Name, Address, City, State, and Phone, then all of that data combined must be less than 8 KB. An exception is made for certain data types where the actual page only contains a pointer to the real data, such as binary data like photos, or large gobs of text. The real data can then be spread across multiple pages, or even stored in a file (that's the special FILESTREAM type which we'll discuss later). SQL Server gathers all these 8 KB pages into a simple file on disk, which usually has either a.mdf or.ndf filename extension. When SQL Server is told to do something, it's by means of a query written in the Structured Query Language (SQL) syntax. This is what happenes first: SQL Server's internal query optimizer looks at the query and constructs a battle plan for executing it (i.e. figuring out what steps it will need to take in order to get that data off of the disk). This is actually pretty complicated, since SQL Server has a number of techniques it can use, some which are better in certain conditions than others. Once SQL Server has the plan, it executes it and retrieves the needed data off of the disk. In the case of a retrieval query, the data is then streamed to the requesting client across the network. With a modification query, SQL Server modifies the pages of data in memory. It doesn't write those modifications back out to disk oh no, not yet. That would be silly, since there might be additional changes coming along for those pages and the system load might not offer a good disk-writing opportunity right then. What SQL Server does, however, is make a copy of the modification query in a special log file called the transaction log. This file, which has an.ldf filename extension, keeps a record of every transaction SQL Server has executed. Eventually maybe a few seconds later SQL Server will decide to write the modified pages out to disk. When it does so, it goes back to the transaction log and "checks off" the transaction that made the modifications. Essentially, it is saying, "OK, I made that change and it's been written to disk." This way, SQL Server knows that the change is safe on disk. Sponsored by: Page 7 of 11
The short course on how SQL Server really works In the event that SQL Server crashes, it has an automated recovery mode that kicks in when it starts back up. It goes straight to the transaction log and looks for uncommitted transactions, or those which have not yet been checked off. It knows that the checked off transactions are safe on disk; anything else had not been written to disk and was still floating around in memory when the server crashed. So SQL Server reads those transactions out of the log, re-executes them, and immediately writes the affected pages to disk. This process allows SQL Server to catch up with all in-progress work, and ensures that you never lose any data provided your disk files are okay, of course. Now think about this important fact -- EVERYTHING that happens in SQL Server occurs only through the transaction log, and SQL Server can re-read the log to repeat whatever has happened. This process makes nearly everything that SQL Server does possible. Of course, this is only the default, and you can change it. Individual databases can be switched from the full recovery model I've described here to a simple recovery model which doesn't use a transaction log (well, it does, but checked off transactions are automatically removed to keep the log small). Simple recovery is only appropriate for read-only databases that have no changes being made. With no changes, there's no chance of losing data in a crash. So that's how data moves from disk to memory. This entire process is absolutely essential to how most of SQL Server's functionality actually works, as well as how to administer it. In my next article, I'll look at how disaster recovery works in SQL Server, and how you can implement a sensible, safe disaster recovery plan for your databases. Sponsored by: Page 8 of 11
Maintaining a high availability of SQL Server virtual machines Maintaining high availability of SQL Server virtual machines Danielle Ruest and Nelson Ruest, Contributors Since the release of Hyper-V, Microsoft has continued its commitment to server virtualization by releasing new software products that are optimized for just that. This is the case for SQL Server 2008 among other Microsoft products. When previously discussing fault-tolerant virtual installations, the Microsoft SQL Server support team has published specific strategies for virtualizing SQL Server installations. These strategies include different guidelines for SQL Server virtualization, but the most interesting being those used to achieve fault tolerance. The SQL Server support team does not support the creation of a cluster at the virtual machine level. This means you cannot create a fault-tolerant virtual machine by creating a SQL Server cluster. You can, however, create a fault-tolerant VM by creating a cluster at the host server level. It basically works like this. Since each host server in a server virtualization resource pool will run several virtual machines at once, most organizations will create fault-tolerant host server configurations to protect these VMs. Then once the hosts are made redundant through a host cluster, each and every one of the virtual machines running on these hosts will become a protected application and thus gain a certain level of fault tolerance. In the event of a host failure, the VMs running on this host will also fail, but will automatically be restarted on another host in the cluster. This is one strategy that can be used to create SQL Server virtual machines and ensure highly availability. The process is simple: 1. Prepare the physical server nodes as well as the shared storage component they require to join a cluster. 2. Install the hypervisor. For example, with Windows Server 2008, you must first install the operating system and then enable the Hyper-V role. 3. Create a host cluster. This means installing the Failover Clustering feature on both nodes in Windows Server 2008. In Hyper-V, you need to perform two additional actions: a. Create a virtual network. This is performed in the Hyper-V Manager through the Virtual Network Manager. You must add a new external network adapter linked to a physical adapter, and this action must be performed on all nodes of the cluster. In addition, the name of the new virtual adapter must be identical on each cluster node in order for VM failover to work. b. Validate the cluster configuration and create the cluster. This will ensure that all of the components required for cluster operation are in place before you actually create the cluster. 4. Once the cluster is created, you can then create a VM that will host SQL Server and set it up for high availability. First create or copy the VM to the cluster, then use the Failover Clustering Management console to make the VM highly available. Sponsored by: Page 9 of 11
Maintaining a high availability of SQL Server virtual machines You will then have a fault-tolerant SQL Server virtual machine. When and if the host node running the SQL Server VM fails, the VM will automatically be restarted on another node of the cluster. While this does not make SQL Server aware of the failover, it does ensure that the virtual machine is always running (see Figure 1). Figure 1 Sponsored by: Page 10 of 11
Resources from Dell, Inc. Resources from Dell, Inc. Master Guide Migrating SQL Server 2000 to SQL Server 2008 Consolidating Multiple SQL Server 2000 systems using Hyper-V SQL Server 2008-10-20Terabyte Data Warehousing About Dell, Inc.: Dell Inc. (NASDAQ: DELL) listens to customers and delivers innovative technology and services they trust and value. Uniquely enabled by its direct business model, Dell is a leading global systems and services company and No. 34 on the Fortune 500. For more information, visit www.dell.com, or to communicate directly with Dell via a variety of online channels, go to www.dell.com/dellshares. To get Dell news direct, visit www.dell.com/rss. Sponsored by: Page 11 of 11