Learn how to identify and avoid practical architecture, design, and implementation issues that can limit the scalability of a SQL Server 2012 workload. This course is applicable to anyone who is responsible for improving the performance and scalability of a SQL Server workload, with most topics applicable to SQL Server 2005 onward.
When considering how to improve the scalability of a SQL Server workload, many people jump to the conclusion that scaling up or scaling out are the only answers. This course will show you that there are a huge number of things you can do to improve performance and scalability before you should even think of scale-up or scale-out. The bulk of the course describes architecture and design issues in both the application and the database that can affect scalability, along with demonstrations of some of the issues and detailed scripts to help you find the issues in the first place. The course ends with a section on common indexing problems that can drastically limit a workload's scalability, along with how to identify and fix them. Save your company a bunch of money by postponing the scaling decision through fixing your existing scalability bottlenecks, not ignoring them! This course is perfect for anyone who is responsible for improving the performance and scalability of a SQL Server workload, with most topics applicable to SQL Server 2005 onward.
Glenn works as a Principal Consultant at SQLskills.com. He has been a SQL Server MVP since 2007, and he is also an Adjunct Faculty member at University College - University of Denver. He is the author of the book SQL Server Hardware (Redgate 2011), and he wrote chapters for both SQL Server MVP Deep Dives books.
Postponing the Scaling Decision This is Glenn Berry with SQLskills. com. I'm recording this course for Pluralsight, and this is SQL Server: Scaling SQL Server 2012 - Part 1, and this is Module 3, Postponing the Scaling Decision. So what am I going to talk about in this module? Well, there are many things you can do to help postpone, or avoid the time and expense of scaling up, which is expensive from a capital expense perspective, or scaling out, which takes a lot of engineering resources. Nearly every system I've ever seen has opportunities for performance and scalability improvements, and regardless of what else you might do in terms of scalability, looking into finding and improving your bottleneck just makes a lot of sense. Now, depending on your applications, you may not be able to make certain types of changes. For example, if you've got third-party applications, you can't touch the application itself, and the same thing with some Legacy applications that might've been developed internally. Regardless of that, you really need to do your best to find and improve whatever performance bottlenecks you find. You need to work the problem at all levels, starting with the application itself, the database design, the instance level settings, and database properties, and then your hardware and storage subsystem. And you also need to be persistent. Quite often when you're a DBA, and you find performance problems, you'll go to somebody to ask for a change, or try to do something, and you'll be told no, and you can't just give up and say, okay, that's the way it's going to be. You need to keep trying to do whatever you can to improve performance and scalability.
Database Architecture and Design This is Glenn Berry with SQLskills. com. I'm recording this course for Pluralsight, and this is SQL Server: Scaling SQL Server 2012 - Part 1. This is Module 5, Database Architecture and Design. So what are we going to talk about in this module? Well, as the title suggests, this is going to be focused on database architecture and design issues. Many database level design changes can have a big impact on performance, but unfortunately, you may be restricted from making schema=level changes in many cases. These include third-party software, Legacy internal software, or even newer internal software, where your developers aren't available to work with you as a team when you're trying to make schema-level changes. Good database design actually can help reduce many performance issues. We're talking about things like proper normalization, and foreign key usage. These things, even though you may get some pushback from your developers, quite often you can get better performance when you do this design work ahead of time. It's also very important to use appropriate matching data types to help avoid implicit conversion issues and queries. They'll cause unexpected index scans that can make queries take much longer to execute, and use a lot more resources. You also need to think about your physical database design. This is very important for performance. I would say a huge majority of databases out in the field just have one data file, and one PRIMARY file group, and that doesn't give you a whole lot of flexibility for how you place your files across different LUNs to get more I/O performance, for example, and it makes it harder to maintain these databases.
Indexing Strategy and Maintenance This is Glenn Berry with SQLskills. com. I'm recording this course for Pluralsight, and this is SQL Server: Scaling SQL Server 2012 - Part 1, and this is Module 6, Indexing Strategy and Maintenance. Your overall indexing strategy is extremely important for performance and scalability. Having the correct number of appropriate indexes for your workload is critical for performance and scalability. It's one of the most important things you can do as a DBA. And you are much more likely to have control over your indexing strategy as a DBA, even with third-party applications. And this is where really you can look like a rock star! If you can find an appropriate, high impact missing index, you can make a query go from minutes to seconds, and people really notice that. Index maintenance considerations are also very important. You really want to control the amount of index fragmentation, but you also want to avoid doing excessive index maintenance, and putting a lot of extra load on your system. Index maintenance creates more load on your system in terms of memory pressure, I/O pressure, CPU pressure, and transaction log generation. And this is especially important if you do things like database mirroring, or always on availability groups, or even transaction log shipping.