These two technologies can make a very big — and very bad — difference in how your SQL Server performs. Wouldn’t it be great if you could get the real, honest lowdown from a virtualization administrator, a SAN administrator, and a DBA? Wouldn’t it be even better if one person had done all three, and could give you the pros and cons of each point of view?
In this one-hour session, I explain how virtualization changes CPU, memory, and monitoring, and I show how to get specific recommendations for your make & model of SAN:
The links I discuss in the video are BrentOzar.com/go/san and BrentOzar.com/go/virtual.
If you like the one-hour free session and you’d like to learn more, I’ve got upcoming four-hour webcasts on virtualization and on storage.
Storage Area Networks (SANs) for DBAs
Learn what’s happening inside the black box! Brent Ozar is a Microsoft Certified Master of SQL Server who got fed up with his SAN admin saying, “Everything’s fine – it must be a SQL Server problem.” When the SAN admin quit, Brent took over, learned how SANs worked, and started putting the pieces back together.
In this four-hour session, production DBAs will learn what happens inside the SAN including:
- The differences between RAID levels (5, 6, 10, DP)
- How pools of disks are shared between servers, and why you might like it
- Pathing: the route between your server and your data
- How solid state PCI Express drives like Fusion-IO work differently
After that, you’ll understand how SQL Server interacts with storage. We’ll cover:
- Why the SAN admin always thinks you’re not pushing the SAN hard enough
- When you don’t need to separate your data and log files – and when you do
- Why pathing may determine the number of data files you need for speed
- When you might actually need two log files in your database – despite what the “experts” say
- And a start-to-finish storage setup and testing checklist
This session is for DBAs who are frustrated with slow or unreliable SAN performance, or DBAs who are about to embark on buying a new SAN. Register today.
Tuning SQL Server on VMware vSphere
SQL Servers can run faster and more reliably under VMware vSphere, but they can also run craptastically. You can’t just use the defaults and expect databases to fly, but thankfully, it’s not that hard to get high performance and uptime with just a few important tweaks.
In this four-hour session, production DBAs will learn why:
- Virtual CPUs are different – and sometimes less is more
- Virtual memory is different – and how to set SQL Server max memory under VMware
- Virtual storage is different – and whether we should use VMDKs or raw LUNs
- Virtual networking is different – and why we have to do our backups differently
- VIrtual monitoring is different – and why Task Manager is a dirty, filthy liar
This session is for DBAs who are frustrated with slow or unpredictable SQL Server performance inside VMware, or DBAs who are about to embark on virtualizing their first SQL Server. Register today.
Brent Ozar
Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.
Follow Me:
