SQL Server File Initialization

The SQL Server storage engine utilizes an initialization process on data and log files. This process fills the files with zeros in order to overwrite any existing data that may be on disk. The initialization process occurs when you create a database, restore a database or file group, add files to an existing database or increase the size of an existing database file. These disk operations are blocking processes that will cause SQL Server to wait until they are complete.

What is Instant File Initialization?

Simply put, instant file Initialization removes the file initialization penalty by negating the need to fill the newly allocated space with zeros before it can be used. This is incredibly important and can reduce disk allocation times from minutes to milliseconds. This is incredibly important when you think about restoring a VLDB and how long you’ll have to wait just for the empty database files to be initialized.

There are a couple of caveats to mention. The first is that instant file initialization is only available on Windows Server 2003 or later. If you’re on Windows Server 2000 then you’re out of luck. The second is that this only works for database data files and is not available for transaction log allocations. The last thing to note is that this is not available if you’re using Transparent Data Encryption (TDE) in SQL Server.

Am I Using Instant File Initialization?

If you don’t know if you’re using this capability then I recommend you find out as soon as possible. Instant file initialization is only working for you if the SQL Server service account has been granted SE_MANAGE_VOLUME_NAME .

Figuring this out from the comfort of SSMS turns out to be pretty simple but it does require the use of xp_cmdshell in order for the query I’ve provided to work. If your security policies restrict the use of xp_cmdshell then you’ll have to figure this out the hard way or turn on xp_cmdshell before you execute and then turn it off after you’re done. If xp_cmdshell is enabled then execute the following script to see if you’re receiving the benefit:

EXEC xp_cmdshell ‘whoami /priv’;

GO

What have we just done? Well, we’ve just executed the Windows “whoami” command in the context of our database service account. We included the /priv parameter because otherwise this tool returns quite a bit of information and we only need to see the security privileges. It’s important to note that the output will return all the security privileges whether they are granted to the account or not. The key is to look to the right of the privilege to see whether is disabled or enabled. Have a look at the output below:

If you scan down to the bottom of the list you’ll find the SE_MANAGE_VOLUME_PRIVILEGE near the bottom. You’ll see that to the right the privilege it is listed as enabled. This is great news and we’re not paying the initialization penalty during data file allocations.

Wait, Instant File Initialization is not Enabled!

If you executed the query and came to the unfortunate conclusion that instant file initialization is not enabled, don’t worry because it’s very easy to implement.

First off, open up the “Local Policy Editor” on the database server and navigate to the “User Rights Assignment” node under the “Local Policies” node. When you select the “User Rights Assignment” node all of the policies will be displayed in the pane at the right.

You’ll need to scroll down to find policy. It’s named “Perform volume maintenance tasks.” You’ll notice that the users or groups that have been granted this privilege are listed to the right. Open the policy and add the SQL Server service account.

Unfortunately, once this is complete you’re still not finished. You’ll need to restart the SQL Server service for it to take effect.

Conclusion

I think it’s easy to see how this feature will benefit your environment in a number of situations. So, take the time today to check this out and save yourself all the waiting when time matters most.

Scott Caldwell, SQL Server DBA

I’ve been an Oracle Apps DBA for 6 months now and before that I was a RDBAE junior DBA where I troubleshot MSSQL, Oracle, and Oracle Apps issues.  At RDBAE, I have the great opportunity to seek advice from our Oracle Apps team with decades of experience. Also, they have given me a R12 environment that I can practice on whenever I have time.  Working at RDBAE, I get great opportunities to work on some cool projects.  My first big project was a 24-hour downtime in production to apply the ATG RUP7 patch along with other patching.

With that, I plan to write a discussion and troubleshooting post each week depending on my job load.  Every once in a while I’ll also post a quick blog on helpful commands. I hope you find the posts informative and feel free to post comments at any time.  I’ll post the blogs with the beginning titles:

OraAppYP: Discussion: <title_name>

OraAppYP: Troubleshot: <title_name>

OraAppYP: HelpfulCMD: <title_name>

Enjoy the posts!

Chris Page, Oracle Apps DBA

During this time of data marts, pivot tables made from excel spreadsheets, and data spread throughout the company, this concept has made a big comeback.  Mergers and acquisitions, as well as data being managed by separate departments, contribute to the lack of data consistency across the organization. For example, you would never have your current cable provider calling to inquire if you’d like to switch your cable to… your current cable provider.  This type of mishap usually occurs because there is a ‘sales lead’ database that is not reconciled with a ‘current customer’ database.  Master Data Management (MDM) requires the company to first define their data and agree upon what it all means.

The objective of MDM is to ensure that all of the non-transactional data in the company (what some might call a reporting database or a data warehouse) is consistent throughout the organization.  In other words, the idea is that the ‘right hand’ of the organization will always know what the ‘left hand’ is doing.  Once the data definition is agreed upon, the company must ensure that all data collection and data manipulation follow the data definition perfectly.  The data is then processed and stored in a single location, and all BI, reporting, CRM, ERP, and other functionality feed off of this single repository.

Virtual Master Data Management (VMDM) is considered the fourth generation of MDM solutions.  VMDM uses abstraction layers in the data model to create a metadata catalog.  The data is not actually consolidated into a single storage location, like it is in the more typical MDM solution.  Instead, the catalog contains an index of the information and is used to make sure that all data is consistent across the organization and that the ‘true’ source of each piece of information is known and documented.  The data is dynamically transformed when requested by a BI, CRM, or ERP solution.

There is an obvious time advantage in using VMDM as opposed to a typical MDM solution.  The project life cycle of MDM includes the definition and analysis phase, as well as the development phase, during which ETL processes are written to transform and load the data into the newly defined structures.  Since you are often storing the data both in its originating system, and also in the MDM solution, you can save on storage costs with VMDM.

Although MDM has many positive attributes, many companies have found it cumbersome to implement in its purest form.  The concept of VMDM allows for data governance with a significant time and cost reduction.

Katy Park, SQL Server Team Lead

The Usual Suspect

Generally speaking, the majority of database corruption is caused by hardware errors in the disk sub-system. Our database files are sitting on our SAN, or DAS, and are happily going about their lives without any problem until something goes awry. You may not even know there is a problem until it’s too late and a database is marked suspect.

The most important thing to can do, outside of monitoring for these problems, is to keep your storage system’s firmware and drivers up to date and consistent within the system. Sign-up for notifications with your vendor so you will receive these notices, and when you received them, read the little text file that explains what has changed and what will happen if you don’t update. I can’t tell you how often I’ve read through these and run across verbiage like, “previous version can cause data loss.”

These systems aren’t perfect. Stay on top of your firmware and driver updates or you may be turned down when you make that middle of the night support call and need their help.

Automate the Eights

I’ve got a bag of alerts that I like to implement on each SQL Server that I administer. Three of these alerts are for errors 823, 824 & 825.

Error 823

Sometimes referred to as a hard I/O error, this is alerting SQL Server, and you, that a read or write error has occurred. In the case of a read error, Windows has already attempted a retry four times before sending the message. This error can also be captured by alerting on errors with a severity of 24.

This error will be accompanied by the following entry in the SQL Server error log and Windows event log:

“The operating system returned error 823 to SQL Server during a <<MESSAGE>> at offset <<PHYSICAL OFFSET>> in file <<FILE NAME>>. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online”.

Error 824

Sometimes referred to as a logical consistency error, or soft I/O error, this indicates that Windows was able to read the page from disk but SQL Server has discovered that the page has a problem. This error can be caused when SQL Server determines that there was a checksum error or a torn bits error when it read the page from disk. This is dependent on the page verification option your database is using. This error can also be captured by alerting on errors with a severity of 24.

No matter which occurred, there’s a problem with the page and the following error message will be reported in the SQL Server error log and the Windows event log:

“SQL Server detected a logical consistency-based I/O error: <<ERROR TYPE DESCRIPTION>>. It occurred during a <<Read/Write>> of page <<PAGEID>> in database ID <<DBID>> at offset <<PHYSICAL OFFSET>> in file <<FILE NAME>>. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.”

Error 825

This error also falls in the hard I/O error category. When this error is received, it indicates that Windows requested a read and the read failed at least one time. Oftentimes, this is the first indication that there’s trouble brewing in the disk sub-system. This error can also be captured by alerting on errors with a severity of 10.

You’ll find the following error message in the SQL Server error log and Windows event log:

“A read of the file <<FILE NAME>> at offset <<PHYSICAL OFFSET>> succeeded after failing<<FAILURE COUNT>> time(s) with error: <<MESSAGE>>. Additional messages in the SQL Server error log and system event log may provide more detail. This error condition threatens database integrity and must be corrected. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.”

Conclusion

You’re going to receive one, or more, of these errors during your career as a Database Administrator. No one is immune. Bad things happen to hardware, and most of the time there’s not a lot you can do to prevent it. However, you can be prepared to respond.

If you receive one of these errors, don’t wait around before you investigate. You’re response is critical to the health of the data you’re sworn to protect. These types of problems don’t go away on their own. Don’t make the mistake of thinking that they will.

So, keep your storage system firmware and drivers up to date, implement these alerts and systematically plan your response. These actions will give you the best chance of a speedy recovery when database corruption strikes.

Scott Caldwell, SQL Server DBA

• I confirmed the ports were open
• Confirmed DNS
• Even confirmed the netcards

Since we were able to narrow the issue down to bad communication between 2 servers, one of which the DTC and SQL Services had already been restarted, that left us with one and only one potential candidate. So the DTC services were restarted and everything worked.

Checklist

• Confirm that DTC is running properly on servers involved and restart one by one if it’s possible.
• I’d run DTCTest first rather than DTCPing because in my case DTCPing confirmed connectivity. However, I was unable to enlist a transaction which is what I wanted to do at the end of the day.
• If you need additional output, fallback to DTCPing.

Attached are a few more screenshots should you encounter this issue.

Initial Error:

Accompanying Error:

Successful DTCTest display after restarting DTC on the server with the issue:

Thanks,

James Shropshire MCDBA, MCITP SQL Server

Here was the setup of the problem:

1. User 1 on computer 1 is connecting to computer 2, which reads a file on computer 3.  It is a DTS package and we are using Windows authentication throughout the process.
2. We are receiving an O/S error 5 in the package, which is denying access to the SQL Server Windows account on a file we need to open.  We have made sure the proper permissions are granted on the file to be opened, read, and written to.
3. Trying to connect to computer 3 is giving me the “Cannot generate SSPI context” error when connecting from computer 1.
4. It was working just fine a few days ago.

First, let’s take a look at two of the types of authentication SQL Server can use.  The first is NTLM.  This protocol is a challenge/response where the client sends a user name to the server, it sends back a challenge which is encrypted by the user’s password and sent back to the server for authentication.  If the user is a domain user, then it is forwarded off to the domain controller for authentication and otherwise it is checked locally by the Security Account Manager.

The second type of authentication is Kerberos.  This method is a Third Party Trust Scheme.  It is a little more complicated as the following items work in tandem to authenticate a user: Key Distribution Center, Authentication Service, Ticket Granting Service, Ticket Grant Ticket,  and Server Principal Name.  The main advantage with Kerberos is that it gives us the ability to use the double hop authentication.  We want to use this authentication method because of the DTS package.

Now that we know which authentication we should be using, let’s tackle some of the other issues.  How can we know which authentication method we are using?  It is easy for SQL Server 2005 and 2008.  We simply connect to management studio, open up the object browser and open a query window to the server we want to test.  Then, we run the following:

select auth_scheme from sys.dm_exec_connections where session_id=@@spid

One thing that I’ve found when running this query is that it should be opened from another server on the domain.  Do not remote desktop directly to the machine and run it on the server you want to test. I have found that to be unreliable.  Now that we see that the server is running under NTLM and not Kerberos, how can we change it?  That part is easy.

To ensure that we are using Kerberos, we need to make sure of a few things first:

1. Both the client and server must be running in the same domain or a trusted domain.
2. The Server Principal Name (SPN) must be registered in Active Directory.
3. The SQL Server instance must have the TCP/IP protocol enabled and be used with the client connection.  An easy way to make sure you are using TCP/IP is to connect to the server with management studio as such: tcp:servername or IP address.  This will ensure you are using TCP/IP.

If we are using Kerberos, then we just need to make sure that the account that is starting SQL Server on computer 2, where the DTS package is located, has the “Account is Trusted for Delegation” in active directory.  If we are not using Kerberos, then we need to look at the Server Principal Name (SPN) and possibly delete and manually recreate the entries.  Using the SetSPN.exe tool that is available on the Windows 2003 support tools, we can list the entries with the –l switch, delete entries with the –d switch, or add entries with the –a switch.  In my case, I found that the entries were already there, but since the user running the SQL Server service was recently changed, they needed to be deleted and recreated.  This is because entries are not supposed to be registered under two different containers.  This would also explain why Kerberos was not being used and why it was working just a few days ago.

In conclusion, the error occurred because of many reasons. First, we recently changed the service account causing errors in the SPN and not allowing Kerberos authentication to run.  The fall back authentication is NTLM, which does not allow for delegation of the authentication which did not allow the DTS package to open the file with the correct credentials.  Using the correct authentication along with “Account is Trusted for Delegation” in Active Directory solved the problem.  Hope this helps anyone else running into this same type of situation.

Tim Foley, Sr. SQL Server Database Administrator

mysql> drop table if exists mytable1;

Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> begin;

Query OK, 0 rows affected (0.00 sec)

mysql> create table mytable1 (idontfeellucky int) ;

Query OK, 0 rows affected (0.44 sec)

mysql> show create table mytable1;

+——-+—————————————————————————————-+

| Table | Create Table |

+——-+—————————————————————————————-+

| mytable1 | CREATE TABLE `mytable1` (

`idontfeellucky` int(11) DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8 |

+——-+—————————————————————————————-+

1 row in set (0.00 sec)

mysql> insert into mytable1 values (1);

Query OK, 1 row affected (0.90 sec)

mysql> rollback;

Query OK, 0 rows affected (0.00 sec)

mysql> show tables;

+—————-+

| Tables_in_test |

+—————-+

| exmpl_tbl |

| mytable1 |

| users |

+—————-+

3 rows in set (0.00 sec)

mysql> select * from mytable1;

+——+

| idontfeellucky |

+——+

| 1 |

+——+

1 row in set (0.00 sec)

mysql> select version();

+———–+

| version() |

+———–+

| 5.5.6-rc |

+———–+

1 row in set (0.00 sec)

If you need your relational sql database to be ACID compliant in areas like this, you should consider other options such as PostgreSQL which is also free but fully supports this feature.  Or, you could go with DB2, Oracle etc.

Thanks,

Brad Arrington, Unix/MySQL/PostgreSQL DBA

Right now, some of you may be wondering what I’m talking about and some of you may be nodding your head in confirmation. Neither of these responses is surprising, as this topic is somewhat obscure, unless you just like reading about SQL Server internals as much as I do.

What is a VLF?

The transaction log of a SQL Server database is always most evident as one or more physical files on disk; however, the transaction log is internally managed as a set of virtual log files (VLFs) within the physical files. This type of internal configuration makes it easier for the storage engine to manage the transaction log and control the reuse of internal space efficiently and effectively.

How is the Number of VLFs Determined?

When you create the transaction log for your database, it will have between 2 and 16 VLF’s. The number of VLF’s is determined by the size of the log when it is first created. SQL Server uses a simple formula to determine the number of VLF’s created.

If the file size is between 1 MB and 64 MB, the storage engine will allocate 4 VLFs inside the file. If the file size is greater than 64 MB, but less than or equal to 1 GB in size, the storage engine will allocate 8 VLFs inside the file. If the file size is greater than 1 GB, then the storage engine will allocate 16 VLFs inside the file.

This formula is also used when “growing” the transaction log too. Furthermore, the transaction log will always grow and shrink along full VLF boundaries. It’s the smallest unit of change allowed within the file.

Visualizing our VLF Count

Now that we a good understanding of how the storage engine will allocate VLFs inside our transaction log, let’s take a look at how we actually see the VLFs in an active database. We’ll be using an undocumented DBCC command to have a look.

First, let’s create a simple database using the following settings.

USE [master]

GO

CREATE DATABASE [myTestDatabase] ON PRIMARY

( NAME = N’myDatabase’, FILENAME = N’C:\myDatabase.mdf’

,SIZE = 3072KB

,MAXSIZE = UNLIMITED

,FILEGROWTH = 1024KB )

LOG ON

( NAME = N’myDatabase_log’, FILENAME = N’C:\myDatabase_log.ldf’

,SIZE = 1024KB

,MAXSIZE = 2048GB

,FILEGROWTH = 1024KB)

GO

Now that the database has been created, let’s take a look at the number of VLFs that were created inside the transaction log.

We’ll be using the undocumented DBCC command called “LOGINFO” to view the VLF count for our database.

USE myTestDatabase;

GO

DBCC LOGINFO;

GO

The execution of the DBCC LOGINFO command outputs the results listed below.

The results of DBCC LOGINFO have a lot to tell us; however, to determine the number of VLFs in our database, we only need to count the number of records. Each record returned from the command represents a single VLF in our transaction log. You can see that the database we created earlier has a total of 4 VLFs.

As you can see, the formula illustrated previously has been used, and since the initial size of the log was between 1 MB and 64 MB, the storage engine created exactly 4 VLFs in this transaction log.

VLFs and Auto-growth

The SQL Server storage engine uses the same formula when allocating additional space to the transaction log file during an auto-growth event. Let’s simulate 5 auto-growth events of 1 MB each and then have a look at our VLF count.

If you remember the formula from above, you know that the storage engine will allocate 4 VLFs per auto-growth event, or a total of 20 additional VLFs.

When we execute DBCC LOGINFO again, we can see that our estimate was correct and we now have a total of 24 VLFs in our transaction log. We have 4 VLFs from the original creation of the 1 MB transaction log and we have an additional 20 VLFs from the five 1 MB auto-growth events.

At first glance, this type of behavior may not alarm you. In fact, this database may go on to have a happy, healthy life under the right workload. However, if this database is placed into production as a data warehouse or as the backend for a high transaction OLTP application then we’ll have problems.

For example, if this transaction log were to grow to 50 GB, or 51,200 MB, it would have a total of 204,824 VLFs. We got 4 VLFs during the initial file creation, then an additional 20 VLFs during the five 1 MB auto-growth events. Then, to top it all off, we got another 204,800 VLFs from the numerous auto-growth events needed to increase the log by 50 GB.

If this database continues to experience auto-growth at this rate, we can expect to see significant performance problems. We need to get this transaction log under control and implement the proper configuration changes to reign in this excessive VLF creation.

Implications and Mitigations

Simply put, having too many, or too few, VLFs in your transaction log file can seriously degrade all transaction log file related processes. These impacts will most likely occur during transaction log backups, service restarts when database recovery is running, transaction log clearing, etc. The good news is that this problem is easy to address, and with proper pre-allocation, unlikely to reoccur.

Generally speaking, if you find that you have a database transaction log with more than 50 VLFs you may want to perform some maintenance to reduce the count. Also, you’ll need to review the auto-growth settings and make the changes necessary to alleviate the problem from reoccurring in the future. The steps required to make these changes are fairly simple; however, you may need to experiment a bit in order the get the VLF count set properly.

You can use the following steps to adjust the VLF count for your transaction log. These steps should only be performed during a period of low activity.

First, perform a transaction log backup.

BACKUP LOG [myTestDatabase] TO DISK =

N’C:\myTestDatabase.bak’

GO

Once the transaction log backup has been completed, you are ready to shrink the transaction log and prepare for the pre-allocation steps.

USE myTestDatabase;

GO

DBCC SHRINKFILE(‘myTestDatabase_log’, TRUNCATEONLY)

GO

After this step, the transaction log has returned to its default initial size of 1 MB and is ready for pre-allocation.

I’m not going to go into all the factors used to determine the proper size for this transaction log. Instead, we’ll make an assumption that 60 GB is large enough, paired with consistent transaction log backups, to hold the largest individual transaction without requiring an auto-growth.

We’ll grow the transaction log to 60 GB by executing the following three queries.

ALTER DATABASE myTestDatabase

MODIFY FILE

(

NAME = myTestDatabase_log

, SIZE = 20 GB

)

GO

ALTER DATABASE myTestDatabase

MODIFY FILE

(

NAME = myTestDatabase_log

, SIZE = 40 GB

)

GO

ALTER DATABASE myTestDatabase

MODIFY FILE

(

NAME = myTestDatabase_log

, SIZE = 60 GB

)

GO

Based on our knowledge of the storage engine formula for VLF allocation, we know we will get 16 VLFs after executing each of the queries list above. This equals a total of 48 VLFs in our transaction log. When we add this to the already existing 4 VLFs, we have a total of 52 VLFs. We’re right on target.

Assuming our transaction log configuration is appropriate for our workload, and no auto-growth is required, we can expect our new VLF count to remain stable; however, if auto-growth should occur, we will add some number of additional VLFs to our transaction log. Due to this, it’s important to configure the initial size of our transaction log, and our auto-growth increment, to values that won’t cause our VLF count to spiral out of control again.

Conclusion

I encourage you to continue to research the internals of the transaction log. A thorough knowledge of this critical mechanism will be highly beneficial as you strive to enhance you own database environments.

Scott Caldwell, SQL Server DBA

However, the profiler has a fatal flaw.  It puts a bit of burden on the system.  Also, you have to run it on the production system in order to get the true test of throughput!  Or you must have a very sophisticated way of playing back the throughput on a test box that matches production.  Hmm.  Then, some DBAs starting thinking…What if I ran the trace from another box!  Viola, the server side trace.  For any production system, the server side trace is a fantastic tool for gaining statistics on deadlocks, indexes, long running queries, and a wealth of other statistical information that can help you improve the setup of your server as well as your code.  Was this the holy grail of tuning that us DBAs had been looking for?

In SQL Server 2005, Microsoft provided the Dynamic Management Views (DMVs).  These provide a constant, real-time view of the database and server.  No trace needs to be run, no data needs to be collected over time, no load on the system, no huge files to figure out where to put on another server, and no rotating file where you are trying to make sure you are not writing over the event that you are trying to capture.  All of the data is right there in the system for you!  You just have query it.  But wait, you say.  I tried to query the views and they weren’t there!   You may need to enable permissions to these views.  You do this through these commands:

• GRANT VIEW SERVER STATE to <Login>
• GRANT VIEW DATABASE STATE to <User>

A few helpful queries I have found to get information from the DMV are listed below. The following shows useful information about all indexes in a database:

SELECT object_id, index_id, user_seeks, user_scans, user_lookups

FROM  sys.dm_db_index_usage_stats

ORDER BY object_id, index_id

The following shows indexes which have never been used:

SELECT object_name(i.object_id),

i.name,

d.user_updates,

d.user_seeks,

d.user_scans,

d.user_lookups

FROM sys.indexes i

LEFT JOIN sys.dm_db_index_usage_stats d

ON d.object_id = i.object_id and

i.index_id = d.index_id and d.database_id = 5

WHERE objectproperty(i.object_id, ‘IsIndexable’) = 1 and

d.index_id is null or

(d.user_updates > 0 and d.user_seeks = 0

And d.user_scans = 0 and d.user_lookups = 0)

ORDER BY object_name(i.object_id)

The following query will tell what each connection is actually performing in SQL Server:

SELECT session_id, status, command, sql_handle, database_id

FROM sys.dm_exec_requests

WHERE session_id >=51

There is a wealth of information available on the DMVs both online and in books.  These views are a DBA’s best friend, and should be the first go-to for tuning opportunities.  There are still times when a server side trace can give more in depth information, such as when performance may differ at different times of day.  But for your average, run-of-the-mill tuning question, nothing can touch the DMVs for their ease of use and their lack of impact to the server.

Katy Park, SQL Server Team Lead

Is the Default Trace Running?

Before we begin, we need to determine a few things. First off, is the default trace running? You can use the following query to determine if the default trace is currently running on your system.

– Is the default trace running
SELECT *
FROM sys.configurations
WHERE configuration_id = 1568

You can see from the output of this query that the default trace is indeed running and the necessary trace files will be available for us to access and investigate.

Uh, Oh! The Default Trace is Disabled!

If the Default Trace has been turned off by a wary Database Administrator, you can turn it back on using the following command. You must have enabled the “show advanced options.”

– Turn on advanced options
sp_configure ‘show advanced options’, 1 ;
GO
RECONFIGURE ;
GO
— Turn on the default trace
sp_configure ‘default trace enabled’, 1 ;
GO
RECONFIGURE ;
GO

Where are the Trace Files Located?

Now we know the default trace is running, we need to determine where the trace files are being stored on the system. The query listed below will return this information.

– Get the path to the current trace rollover file
SELECT *
FROM ::FN_TRACE_GETINFO(0)

The results of this query have provided the path to the current rollover trace file. We can see that the file is located inside the “Log” directory in the SQL Server installation path.

How Can I View the Trace File Information?

Now that we know where the rollover trace files are located, we can begin to investigate the information they contain. We could just double-click on the file listed above and open it in SQL Server Profiler. This would load the trace and show us its contents. I’d like to show you a more robust method of viewing this information.

Use the file path from above in the query that follows to inspect the contents of the trace as if it were a table in SQL Server.

SELECT loginname,
spid,
applicationname,
DatabaseId,
cat.name AS [CategoryName],
starttime,
e.name AS EventName
FROM ::FN_TRACE_GETTABLE(‘C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\log_12.trc’,
0)
INNER JOIN sys.trace_events e ON eventclass = trace_event_id
INNER JOIN sys.trace_categories cat ON e.category_id = cat.category_id
WHERE cat.category_id = 2

In this query I’m only returning events that occurred in the “Database” category. The “Database” category includes the events “Data File Auto Grow”, “Data File Auto Shrink“, “Log File Auto Grow”, “Log File Auto Shrink” and “Database Mirroring Status Change.”

You’ll see from the results above that there is a SQL Agent Job that causes a “Data File Auto Grow” every time it executes. This is probably something that warrants additional investigation.

In this case, I discovered a SQL Server database that was using a data file “Autogrowth” increment of 1 MB. This database was also receiving a substantial data load via a SQL Agent job every 1 second.

Conclusion

The SQL Server default trace captures 32 unique events across 6 categories. The example illustrated above is just a small sampling of the information that is available. I recommend you take some time to experiment with the other events and categories the next time you’re checking the health of your SQL Server environment. You never know what you might discover.

Scott Caldwell, SQL Server DBA