Often when I speak at user groups and conferences, I ask attendees what versions of SQL Server they are running. As you may expect, I hear from attendees who are running the entire gamut of SQL Server versions, from SQL Server 6.5 up to SQL Server 2012. While it is an unscientific poll, it seems that most people are still running SQL Server 2005 and SQL Server 2008.
The SQL Server 2012 and SharePoint Connections conference agenda brings together more than 40 top-ranking experts from Microsoft, along with leading independent presenters to deliver in-depth sessions on how to succeed with SharePoint and SQL Server based on real life production deployments with the latest hot news from Microsoft’s biggest launch this year for SQL Server 2012.
The event will include a SQLServerCentral.com track consisting of six sessions from two SQL Server MVPs that I selected to participate in the track: Constantin Klein and Satya Jayanty. Their sessions include:
- New T-SQL Features in SQL Server 2012
- SQL Server for Developers
- Fun Managing Documents with SQL Server
- Upgrading SQL Server: Tools and Best Practices
- DMVs – Best of the Bunch. Troubleshoot Your Data Platform Like a Pro
- SQL Server High Availability Concepts and Solution Guidance: 2008 R2 & 2012
There is one thing every DBA knows with certainty, and that is that databases grow with time. MDFs grow, backups grow, and it never stops. The more data we have, the more work SQL Server has to perform in order to deal with it all; whether it’s executing a query on a table with 10 million rows, or backing up a 5 TB database. Whether we like it or not, we are fighting a losing battle, and DBA’s can’t reverse the information explosion. Or can we?
If you are attending the PASS SQLRally this May in Dallas, I will be presenting a one day preconference session called “How to Perform a SQL Server Health Check”. Here’s the abstract for the session:
Are all the SQL Server instances you manage healthy, running optimally, and providing the high availability your organization expects of them? If you don’t know, or if you have inherited, or are consulting with some SQL Server instances you are not familiar with, then you need to perform a SQL Server Health Check in order to find out.
Think of a SQL Server health check similarly to a health check with your physician. On your visit, the doctor will record your basic stats, take a medical history, and perform a number of tests. In many ways, what the doctor does is to document your health, and then compares what he finds to medical health best practices, to determine your current health. The next year at your annual check-up, the doctor will examine your again and then compare it to the baseline from the initial checkup. This helps the doctor determine if your health is the same, getting better, or getting worse. A SQL Server health check is very similar.
In this day-long session, you will learn how to document your SQL Server instances and how to determine if your instances are employing generally accepted best practices. Based on this information, you will be able to conclude if your instances are healthy, which means that they are running optimally and providing the level of high availability your organization expects of them. If not, you will learn how to fix any problems you find.
More specifically, you will learn about how to document your instances, and learn best practices in all of the following areas: Hardware Setup & Configuration, Operating System Setup & Configuration, SQL Server Instance Level Settings, Database Level Settings, Security Settings, Database Maintenance, SQL Server Jobs, Logs to Monitor and Review, SQL Server Monitoring, Performance Optimization, and High Availability. In many ways, this session will bring together all the best practices every DBA should know about administering a SQL Server instance.
This session will cover hundreds of health checklist items and their best practices. To help you keep track of all this information, you will be provided with scripts to collect the data, and a spreadsheet in order to collect and analyze the data.
This session is designed for database administrators from novice to intermediate level. After attending this session, attendees will be able to go back to their organizations and begin to immediately perform their own SQL Server health checks.
For more information on the event, visit the PASS SQLRally website.
I was very surprised to see the results of my latest poll, which asked “When was the last time you tuned your transaction logs?”
According to those DBAs who responded to the poll, about 60% of them said they didn’t know transaction logs could be tuned. And just over 19% said they have never tuned their transaction logs. Sadly, only about 21% said they have tuned their transaction logs in the past.
If you are one of those DBAs who don’t know transaction logs can be tuned, you need to take the time as soon as possible to learn about this topic.Why? First, every data modification made in SQL Server must be logged. Second, no transaction can complete until all of the related data modification are written to the transaction log. And third, writing to a transaction log is a single thread process. On a busy SQL Server instance, writing to the transaction log can become a bottleneck, preventing transactions from being completed on a timely basis, slowing down the entire instance.
There are many ways to tune a transaction log, some very simple, and others slightly more complicated, but it is not beyond the ability of most DBAs. To learn more about transaction log performance tuning, download my presentation slides on “Inside the SQL Server Transaction Log”, which will give you a good start on learning the basics of this important topic.
Later this year, a new book by author Grant Fritchey, called Learn SQL Server in a Month of Lunches, will be released by Manning Publications. Below is a preliminary excerpt from the book on “Creating a Full Backup”. The book is geared toward readers new to SQL Server.
Creating a Full Backup
The full backup is a complete copy of the database. It copies everything. Not just all the data, but all the tables and all the indexes and all the stored procedures; everything that makes up the database gets copied. That’s what makes this so important for protection in the event of some type of catastrophic loss. As with most everything else in SQL Server, you can perform a full backup using either the SQL Server Management Studio (SSMS) graphical user interface (GUI), or you can use Transact SQL (TSQL) to make the backups happen. Let’s start with the GUI.