By:
On:
In: configuration, SQL Server, trace flags
With: 0 Comments

Trace flag 1117 is a setting that is often misunderstood.  When enabled it forces any file growth event on a data file to include all data files in the same file group so that the files can remain the same size.  I usually hear it described as a setting that changes how TempDB files are treated as they need to grow. While true, what is interesting is that this is more of a side effect of the flag.  The trace flag is not TempDB specific and affects all databases on a SQL Server instance that have more than 1 file in any file group andRead More →

By:
On:
In: configuration, DMVs, indexes, query tuning, SQL Server, t-sql
With: 6 Comments

Even the most green DBAs know that indexes are a good thing.  A database won’t run well without them.  But it is important to remember that indexes aren’t free.  They have to be created, stored, backed up, consistency checked, updated, defragmented, and have their statistics updated.  That’s a lot of work!  This extra work associated with indexes is sometimes called the “write penalty”.  It is why having too many indexes can be just as bad as not having enough. The goal of the DBA should be to have as many high-value indexes — indexes that will be used often by the workload — as possibleRead More →

By:
On:
In: configuration, DMVs, SQL Server
With: 3 Comments

In this entry I am going to cover a handful of common myths and misconceptions about how SQL Server handles memory.  Each of these comes from repeated instances of confusion in my dealings with other SQL Server users.  Many of these have come up from even very seasoned DBAs so don’t feel bad if you’ve been laboring under a misconception yourself. The Myth: I logged in and found my SQL Server is running at 95% memory utilization.  I restarted the box which fixed it temporarily, but it grew and grew right back to 95% within a few hours!!  SQL Server must have a memory leak!Read More →

By:
On:
In: Basics, configuration, SQL Server
With: 0 Comments

There are a few reasons that one might need to restore a SQL Server backup.  Perhaps it is time to refresh a test database with a copy from production. Maybe there has been a disaster and this is how the disaster recovery plan is getting the system back online.  Another common restore reason is to recover a single data element that was removed or modified in production by accident.  Whatever the reason, being able to restore a database and understanding some of the basic options thereof is an essential skill for the SQL Server DBA. For this demo I will cover the topic using theRead More →

By:
On:
In: configuration, query tuning, Reporting, SQL Server
With: 1 Comment

Meet the Enemy: Sure, it looks all innocent and helpful.  Just sitting there informing you of your business activities.  But all too often I’ve seen this hideous monster ruin a SQL Server.   Let’s take a moment and talk about why this TV is our enemy.  Then we can follow up with a few ways to fix the problem. It’s becoming more and more commonplace to place these monitors around an office.  It’s becoming so common in my industry, transportation, that when I get a call saying that system performance is falling off suddenly I have learned to ask about any new TVs early inRead More →

By:
On:
In: Basics, configuration, SQL Server
With: 0 Comments

In the previous blog entries we talked about the different data files, recovery models, and how they interact.  Today’s entry will talk about Native SQL Server Backups.  Having an understanding of the files and recovery models will help this entry make more sense.  We’ll cover restoring these backup files in the next installment. The most basic backup of a SQL Server database is a full backup.  This takes a snapshot of the data and log files for the moment in time that the backup was invoked.  It includes all of the objects of the database including tables and code objects.  This file can be restoredRead More →