For more information on XACT_ABORT, refer to the following:

SET XACT_ABORT (Transact-SQL)
https://msdn.microsoft.com/en-us/library/ms188792.aspx

Below is an example showing orphaned locks and using XACT_ABORT.

First, create a table and load some data:

create table ##test (id int)
go

insert into ##test values (1);
insert into ##test values (2);
insert into ##test values (3);
insert into ##test values (4);
insert into ##test values (5);

Then create a stored procedure that will have enough of a delay to cause a Command Timeout in .NET:

create proc usp_AddNumber
(
    @id int,
    @newid int
)
as
begin tran
    update ##test set id = @newid where id = @id;
    waitfor delay '00:01:00.000';
commit tran
go

The following simple .NET code will call the stored procedure and fail due to a Command Timeout because of the WAITFOR exceeding the timeout allowed by the SqlCommand object (default is 30 seconds):

        private void btn_xact_btn_Click(object sender, EventArgs e)
        {
            SqlConnectionStringBuilder cnString = new SqlConnectionStringBuilder();

            cnString.InitialCatalog = "tempdb";
            cnString.IntegratedSecurity = true;
            cnString.DataSource = ".";

            using (SqlConnection cn = new SqlConnection(cnString.ToString()))
            {
                cn.Open();
                SqlCommand cmd = new SqlCommand("usp_AddNumber", cn);
                cmd.CommandType = CommandType.StoredProcedure;

                SqlParameter p1 = cmd.Parameters.Add("id", SqlDbType.Int);
                p1.Value = 4;

                SqlParameter p2 = cmd.Parameters.Add("newid", SqlDbType.Int);
                p2.Value = 3;

                Int32 RowsAffected = cmd.ExecuteNonQuery();
            }
        }

BEFORE the timeout, we see the locks taken:

AFTER the timeout hits, we see the _same_ locks still in place:

If we search for a request for SPID 55 – the session ID holding the locks, we see nothing:

select * from sys.dm_exec_requests where session_id = 55
  

When the timeout hits and the client sends a cancel or disconnects, we see the Attention event in SQL Server:

For more information on an Attention event, refer to MSDN here:

Attention Event Class
https://msdn.microsoft.com/en-US/library/ms190979(v=sql.110).aspx

One solution may be to terminate the process/application if that is feasible (but may not be if this is a middleware component or application server).  If you see the session id but it has no active request, then killing the session (kill 55) can also release these locks.  If I stop my .NET application – then my locks are gone.  I can also kill the connection.  However be aware that killing the connection (or hard terminating the application) may cause SQL Server to go into a lengthy rollback if the transaction has done a large amount of work.

If you want to know what application did this – which may or may not be useful based on the application architecture (if it is using middleware, etc..) - then we could:

select s.host_name, c.client_net_address, s.host_process_id from sys.dm_exec_sessions s
    inner join sys.dm_exec_connections c
    on s.session_id = c.session_id
    where s.session_id = 55

You could then go to system ASKJ-W520, find process id 5748 and see what it is doing or was doing (again it could be a mid-tier web or application server and may not be useful).

So, if we change the stored procedure to:

alter proc usp_AddNumber
(
    @id int,
    newid int
)
as
    set xact_abort on
    begin tran
        update ##test set id = @newid where id = @id;
        waitfor delay '00:01:00.000';
    commit tran
go

Then, when we hit the timeout, we have no leftover locks:

So this may be as simple as killing the connection and identifying the application to see what was done (though in middleware this may not be very helpful).  Again, remember – killing it may incur a lengthy rollback process. 

If this specific issue is causing you problems, you should start by figuring out why the processing is taking so long to see if you can shorten it through tuning or breaking it into smaller transactions.  Otherwise, you can consider increasing the timeout on the Command object.

- Jay

Sequence Objects are new starting in SQL Server 2012.  They work similarly to an IDENTITY value, but where the IDENTITY value is scoped to a specific column in a specific table, the Sequence Object is scoped to the entire database and controlled by application code.  This can allow you to synchronize seed values across multiple tables that reference one another in a parent child relationship.  Or, with a little bit of code you can also take control on whether or not the next value is used or saved for the next INSERT should the current transaction be rolled back (the IDENTITY value is lost and creates a gap when an INSERT is rolled back).  For applications that require sequence numbering schemes without gaps, Sequence Objects do not solve that entirely.  If a record is deleted or in concurrent inserts with multiple users where one transaction fails – gaps can still appear in your table as the sequence value is not re-used.  To satisfy that requirement, you will still need to create a mechanism (commonly a table of values) yourself and manage them in a way where unused or deleted values are returned to the master table.  However, Sequence Objects give us much greater flexibility in our design with auto-generated number sequences.  To create a Sequence Object in SQL Server 2012, you can simply use the following:

-- Create a Sequence Object to start at 1 and increment by 1
CREATE SEQUENCE dbo.NextCustomerID
    as BIGINT
    START WITH 1
    INCREMENT BY 1;
GO

-- Get the next available ID
DECLARE @CustID BIGINT;
SELECT @CustID = NEXT VALUE FOR dbo.NextCustomerID;
SELECT @CustID as 'Customer ID';

You can get more information on Sequence Objects here:

Sequence Numbers
https://msdn.microsoft.com/en-us/library/ff878058.aspx

CREATE SEQUENCE (Transact-SQL)
https://msdn.microsoft.com/en-us/library/ff878091.aspx

In SQL Server 2008 R2 and earlier, Sequence objects were not available.  To provide this functionality, we have to build some constructs that allow us to mimic this behavior.

To satisfy the same the requirements as the Sequence Object, a common solution is to build dedicated table with an IDENTITY value where the last IDENTITY value can be returned from within a Stored Procedure or a Function:

CREATE TABLE dbo.GlobalSequence
(
       id INT IDENTITY(1,1)
)
go

BEGIN TRAN

INSERT INTO dbo.GlobalSequence 
       OUTPUT inserted.id
DEFAULT VALUES

ROLLBACK TRAN

If you must not have gaps in your table in the event of a rolled back transaction or deleted record, you could remove the ROLLBACK TRAN operation (replacing it with a COMMIT) and either delete values once they are committed in your application or use a secondary BIT column to “tombstone” values once they are used. 

Finally, in high throughput/high performance situations it is common to want to pre-allocate a block of numbers ahead of time.  In SQL Server 2012 Sequence Objects, this is handled using the CACHE statement.  For the SQL 2008 R2 and earlier solution above, you can do this in a couple of ways.  One way would be to run a background task (a scheduled task in SQL Agent) that handles allocating a configurable block of IDENTITY values during an off-peak time.  Another solution – or perhaps a backup solution – would be to check the amount of remaining values each time or every nth time a value is requested and allocate more one it reaches a low-water mark.  With the latter approach, most requests will not incur any extra overhead besides the size check but occasionally a user will wait while the table is re-populated.   If pre-allocating values and not deleting them once they are committed, you will likely want to schedule a background process to clean up the custom sequence value table when values are not longer needed.

- Jay

Put another way, can Windows preempt our worker thread and perform a context switch even though it has been “scheduled” by the SQL OS (SOS) and SQL thinks it is running?  Of course it can. 

SQL Server implements a cooperative scheduling mechanism to make the most efficient use of the CPUs as it can.  However, Windows ultimately schedules the thread and uses a general purpose pre-emptive scheduler and does not give special considerations to SQL Server when the dispatcher selects a thread – there all just threads to Windows (though they can have priority).  So if a higher priority thread comes in from an interrupt or if we’ve exhausted our quantum at the OS level and another ready thread is waiting from another process to run it’s timeslice, then our worker thread will get preempted, regardless of what SQL wants.  SQL controls this behavior to the best of it’s ability amongst it’s own worker threads by making sure no more threads are viable for scheduling (from within SQL) than the number of CPUs available to SQL Server.  Also, SQL Server realizes there is no sense in scheduling a thread that is waiting on a database resource – like a transactional lock – something that Windows doesn’t understand.  If a thread reaches its quantum at the OS and no other threads are viable to the Windows dispatcher, we can get another quantum and maximize SQL Server’s use of the CPU. In this way, we hope to reduce context switches – pure overhead from an execution standpoint.  SQL controls the scheduling of it’s own worker threads by placing them into wait states with APIs like WaitForSingleObject.  Then when a thread is ready to run because a lock has been freed, a timer has expired, or a task / request has come in from a user, SQL Server signals it to come out of the wait state and execute.  Even as it sits in the RUNNABLE queue, it is actually in one of these wait APIs (though the SQL status will be RUNNABLE).  As the “running” thread leaves, part of it’s “good-citizen” cooperative scheduling responsibilities is to “signal” the next worker thread in the RUNNABLE queue so that it can get it’s 15ms of fame.

This is a good reason to limit as much as possible what other software executes on your SQL Server.  However, let’s see an example stack taken from my machine where just this scenario happened.

First, let’s look at a “normal” example:

ntoskrnl.exe!KiSwapContext+0x7a
ntoskrnl.exe!KeSignalGateBoostPriority+0x1c0
ntdll.dll!ZwWaitForSingleObject+0xa
KERNELBASE.dll!WaitForSingleObjectEx+0x79
sqlservr.exe!SOS_Scheduler::SwitchContext+0x26d
sqlservr.exe!SOS_Scheduler::SuspendNonPreemptive+0xca
sqlservr.exe!SOS_Scheduler::Suspend+0x2d
sqlservr.exe!EventInternal<Spinlock<153,1,0> >::Wait+0x1a8
sqlservr.exe!EventInternal<Spinlock<153,1,0> >::WaitAllowPrematureWakeup+0x59
sqlservr.exe!CXPacketList::RemoveHead+0xf0
sqlservr.exe!CXPipe::Pull+0x8b
sqlservr.exe!CXTransLocal::AllocateBuffers+0x5b
sqlservr.exe!CQScanXProducerNew::AllocateBuffers+0x31
sqlservr.exe!CQScanXProducerNew::GetRowHelper+0x1c2
sqlservr.exe!FnProducerOpen+0x58
sqlservr.exe!FnProducerThread+0x4df
sqlservr.exe!SubprocEntrypoint+0x794
sqlservr.exe!SOS_Task::Param::Execute+0x12a
sqlservr.exe!SOS_Scheduler::RunTask+0x96
sqlservr.exe!SOS_Scheduler::ProcessTasks+0x128
sqlservr.exe!SchedulerManager::WorkerEntryPoint+0x2d2
sqlservr.exe!SystemThread::RunWorker+0xcc
sqlservr.exe!SystemThreadDispatcher::ProcessWorker+0x2db
sqlservr.exe!SchedulerManager::ThreadEntryPoint+0x173
MSVCR80.dll!_callthreadstartex+0x17
MSVCR80.dll!_threadstartex+0x84
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x1d

So here we have a thread that is part of a parallel query that goes into a wait.  Ever see those CXPACKET waits?  Well, you’re looking at one now.  So whlie we wait on CXPACKET or any other wait type – we can’t do anything.  Let’s “switch context” and have the SQL OS (SOS) take us off the scheduler – let someone else have their time – and we can be signaled when it’s time to go again.  As we “switch”, the SOS scheduler puts us in a wait state (waiting on an event) with WaitForSingleObject.  At the frame that reads ZwWaitForSingleObject, you are seeing the transition from user mode into kernel mode as Windows takes over.  Then at the top of the stack, the Windows dispatcher records our context record and switches us off the CPU and finds which thread is ready to run – which is very likely NOT another SQL Server thread in *this case* – but on a dedicated SQL Server we’d like it to be – and most of the time it should be.

Now, let’s see if SQL can have the rug pulled out from under it… Here’s one:

ntoskrnl.exe!KiSwapContext+0x7a
ntoskrnl.exe!KiCommitThreadWait+0x1d2
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!KiSuspendThread+0x54
ntoskrnl.exe!KiDeliverApc+0x201
ntoskrnl.exe!KiApcInterrupt+0xd7
sqlservr.exe!CQScanXProducerNew::GetRowHelper+0x289
sqlservr.exe!FnProducerOpen+0x58
sqlservr.exe!FnProducerThread+0x4df
sqlservr.exe!SubprocEntrypoint+0x794
sqlservr.exe!SOS_Task::Param::Execute+0x12a
sqlservr.exe!SOS_Scheduler::RunTask+0x96
sqlservr.exe!SOS_Scheduler::ProcessTasks+0x128
sqlservr.exe!SchedulerManager::WorkerEntryPoint+0x2d2
sqlservr.exe!SystemThread::RunWorker+0xcc
sqlservr.exe!SystemThreadDispatcher::ProcessWorker+0x2db
sqlservr.exe!SchedulerManager::ThreadEntryPoint+0x173
MSVCR80.dll!_callthreadstartex+0x17
MSVCR80.dll!_threadstartex+0x84
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x1d

Notice at the top – Windows has performed the context switch and let someone else run.  Once again, Windows will save our execution context in something known as a context record (so it knows where it was and what we were doing when we finally do get back on the CPU) and let another thread execute – very likely a thread from a different process.  Also, notice that the last frame from SQL Server (sqlservr!*) is more parallelism code.  There is no call to sleep, no call to SwitchContext, nothing from the SQL OS at all.  We are just rudely interrupted by the kernel (ntoskrnl.exe) and told –  you’re done.  Actually, at this point it was processing the APC queue (part of the kernel) and went into it’s own WaitForSingleObject call as a part of the context switch – but not one invoked by SQL Server.  Also, kernel stacks work the same as user mode stacks – so other kernel code could have already run and been “popped” off the stack at this point.  We’ll get more time in a matter of milliseconds, but the more this happens, the more your SQL code waits, the more the duration goes up – and yet no progress is made.

So you really want to limit how much non-SQL server software you execute on your server, SQL Server can’t control other processes or Window’s scheduling of those processes.

Finally, how did I get this?  First, I used Mark Russinovich’s excellent Process Explorer utility to capture both the user and kernel mode stacks in one nice combined stack trace.  To easily “create” this mess and find an offending thread, I ran a very busy query (a cross join) and also ran an external utility I wrote that does nothing but burn cpu, it’s literally called “EatCPU”.

- Jay

I had a discussion the other day with someone about worker threads and their relation to tasks.  I thought a quick demo might be worthwhile.  When we have tasks that are waiting on a resource (whether it be a timer or a resource like a lock) we are tying up a worker thread.  A worker thread is assigned to a task for the duration of that task.  For most queries, this means for the duration of the user’s request or query.  Let’s look at two examples below.

We could verify that the worker thread is tied up by verifying the state the worker thread is in and that it is assigned to our tasks through the following two DMVs:

select * from sys.dm_os_workers
select * from sys.dm_os_tasks

If we start a 5 minute delay to tie up a worker thread using session 55 as follows:

waitfor delay '00:05:00'

Then we can use the following to verify our worker thread is assigned to our task and suspended while it waits on the timer:

select 
    w.worker_address,
    w.state,
    w.task_address,
    t.session_id
from sys.dm_os_tasks t
    inner join sys.dm_os_workers w
    on t.worker_address = w.worker_address
    where t.session_id = 55

However, we can also get the worker’s OS thread ID and view the call stack to see that it is not merely waiting for work to do – but is tied up waiting to complete.  For the above worker thread running on SPID 55, we can run the following to get the os thread id:

select os_thread_id from sys.dm_os_tasks t
    inner join sys.dm_os_workers w
    on t.worker_address = w.worker_address
    inner join sys.dm_os_threads o
    on o.worker_address = w.worker_address
 where t.session_id = 55

this gives us:

Now we can get the stack trace of os thread 8376.  And it is:

kernel32.dll!SignalObjectAndWait+0x110
sqlservr.exe!SOS_Scheduler::Switch+0x181
sqlservr.exe!SOS_Scheduler::SuspendNonPreemptive+0xca
sqlservr.exe!SOS_Scheduler::Suspend+0x2d
sqlservr.exe!SOS_Task::Sleep+0xec
sqlservr.exe!CStmtWait::XretExecute+0x38b
sqlservr.exe!CMsqlExecContext::ExecuteStmts<1,1>+0x375
sqlservr.exe!CMsqlExecContext::FExecute+0x97e
sqlservr.exe!CSQLSource::Execute+0x7b5
sqlservr.exe!process_request+0x64b
sqlservr.exe!process_commands+0x4e5
sqlservr.exe!SOS_Task::Param::Execute+0x12a
sqlservr.exe!SOS_Scheduler::RunTask+0x96
sqlservr.exe!SOS_Scheduler::ProcessTasks+0x128
sqlservr.exe!SchedulerManager::WorkerEntryPoint+0x2d2
sqlservr.exe!SystemThread::RunWorker+0xcc
sqlservr.exe!SystemThreadDispatcher::ProcessWorker+0x2db
sqlservr.exe!SchedulerManager::ThreadEntryPoint+0x173
MSVCR80.dll!_callthreadstartex+0x17
MSVCR80.dll!_threadstartex+0x84
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x1d

From the highlighted sections in the stack trace above, we can see this is a worker thread that is processing commands (our WAITFOR DELAY statement).  It has entered a sleep as a result of our WAITFOR DELAY call and SQL Server OS has switched it off the scheduler since there isn’t anything it can do for 5 minutes.  Once the timer expires, the thread will be signaled and can be placed back into the RUNNABLE queue in case there is any more work for it to do.

So our thread is in effect tied up and can’t do any work for 5 minutes.  Extensive use of WAITFOR could be a good way to choke the system.  What about normal resources?  What if we are waiting to obtain a shared lock (LCK_M_S)?  Same story… Let’s look…

We can create a simple table and do an insert without closing the transaction to hold the locks…

create table Customers
(
    ID INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
    FIRSTNAME NVARCHAR(30),
    LASTNAME NVARCHAR(30)
)
ON [PRIMARY]
GO

BEGIN TRAN
    INSERT INTO CUSTOMERS (FIRSTNAME, LASTNAME) VALUES ('John', 'Doe')
    INSERT INTO CUSTOMERS (FIRSTNAME, LASTNAME) VALUES ('Jane', 'Doe')
    INSERT INTO CUSTOMERS (FIRSTNAME, LASTNAME) VALUES ('George', 'Doe')

Now from another session (session 56), we can try to read that table – which will block hopelessly…

select * from Customers

Once again, we use the query from above to get our OS Thread ID:

select os_thread_id from sys.dm_os_tasks t
    inner join sys.dm_os_workers w
    on t.worker_address = w.worker_address
    inner join sys.dm_os_threads o
    on o.worker_address = w.worker_address
 where t.session_id = 56

Again, our worker thread processes our command (the SELECT query) and goes into a sleep.  Notice this is just the name of the method from the “LockOwner” class – not the same sleep as above that is bound to a timer.  The SOS scheduler switches us off and we wait to be signaled that our lock is available.  This thread is “tied up” – waiting to continue.

These are the reasons that massive blocking cases can eventually lead to worker thread depletion – and waits on THREADPOOL.

-Jay

While working with a customer on a SQL port, I came across a system view that was new with SQL Server 2008.  Have you ever needed to check your database code (stored procedures) to see if it references any missing objects?  As of SQL Server 2008 this is easy thanks to:

sys.sql_expression_dependencies

More can be found here:

sys.sql_expression_dependencies (Transact-SQL)
https://msdn.microsoft.com/en-us/library/bb677315

As with my customer’s case, issues like this can creep into code because of SQL Server’s Deferred Name Resolution Feature.  This simply means SQL Server will let you compile a stored procedure that refers to an object that doesn’t yet exist.  You can read more about this here:

https://msdn.microsoft.com/en-us/library/ms190686(v=sql.105).aspx

In this situation, missing objects – and errors – may not be found until runtime.  Using this system view, we can get an idea of what our exposure is to 208 errors = “Invalid Object Name”.

This example is a simple illustration for a table reference, but you can expand this to other object types as well.  First, we create a stored procedure that references a table that doesn’t exist:

create procedure DNRproc
as
    -- select from a non-existent table
    select * from dbo.Address
go

Then, we execute:

exec DNRproc

and get:

Msg 208, Level 16, State 1, Procedure DNRproc, Line 4
Invalid object name 'dbo.Address'.

To find this missing object reference, we can use:

select
    object_name(referencing_id) as 'object making reference',
    referenced_class_desc,
    referenced_schema_name,
    referenced_entity_name as 'object name referenced',
    (select object_id from sys.objects where name = [referenced_entity_name]) as 'Object Found?'
from sys.sql_expression_dependencies e
    left join sys.tables t
    on e.referenced_entity_name = t.name

A “NULL” value in the “Object Found?” column indicates the object was not found in sys.objects.  Therefore, we can easily see that dbo.Address which was referenced by DNRproc was not found. 

This doesn’t replace good coding and migration practices, but can be a helpful tool – and can be expanded upon to check for more objects than just missing tables.

-Jay

Working on a customer project the other day, I needed to load some data into a database that had been scripted and re-created.  The newly created database already had foreign keys in place which means for loading data (this was from SSIS), we had 2 options:

1) drop the foreign key constraints, load the data, re-apply the constraints
2) load the data in the correct order so that parent tables are loaded first, followed by children, followed by grandchildren, etc…

I decided to give option 2 a try.  In our work we were dynamically generating an SSIS package in C# – so we had some flexibility in deciding how to load the data.  So what I needed was a way to identify the correct order described in option #2. 

The idea is fairly straightforward.  We needed to find the parent tables that have references to them but don’t reference anything themselves.  Then find all the objects that reference those tables, and so on…  The system view sys.foreign_keys is our primary tool for this.  We need to track changes at each level because a “child” table could reference tables at difference levels.  In this case, we’re mostly interested in the lowest level reference to be sure all of it’s parent tables are loaded first.  Finally, I found that with this method, self-referencing tables are problematic.  In this version, I simply exclude those.  If the data is loaded into that table in order, everything should be fine.

Here is the script I wrote for this – hope it helps:

DECLARE @FK_TABLE_ORDER TABLE
(
    FKLEVEL INT,
    OBJECTID INT
)

DECLARE @CHILDCOUNT INT, @CURRLEVEL INT
SELECT @CHILDCOUNT = 1, @CURRLEVEL = 0;

WITH Top_Level_Tables
AS
(
    SELECT
        t.object_id,
        t.schema_id,
        f.parent_object_id
    FROM sys.tables t
    INNER JOIN sys.foreign_keys f
    ON t.object_id = f.referenced_object_id
)
INSERT INTO @FK_TABLE_ORDER
SELECT DISTINCT 0, object_id from Top_Level_Tables
    WHERE object_id NOT IN (SELECT parent_object_id FROM Top_Level_Tables)

SELECT @CHILDCOUNT = ( SELECT COUNT(*) FROM sys.foreign_keys 
                        WHERE referenced_object_id IN 
                        (SELECT OBJECTID FROM @FK_TABLE_ORDER WHERE FKLEVEL = @CURRLEVEL)
                     )

WHILE (@CHILDCOUNT > 0)
 BEGIN
    
    SELECT @CURRLEVEL = @CURRLEVEL + 1;

    INSERT INTO @FK_TABLE_ORDER
    SELECT DISTINCT
        @CURRLEVEL,
        parent_object_id
    FROM sys.foreign_keys 
    WHERE referenced_object_id IN 
        (SELECT OBJECTID FROM @FK_TABLE_ORDER
            WHERE FKLEVEL = (@CURRLEVEL - 1)
        ) AND
        referenced_object_id IS NOT NULL AND
        referenced_object_id != parent_object_id

    SELECT @CHILDCOUNT = ( SELECT COUNT(*) FROM sys.foreign_keys    
                            WHERE referenced_object_id IN 
                            (SELECT OBJECTID FROM @FK_TABLE_ORDER WHERE FKLEVEL = @CURRLEVEL)
                         )

    
 END

 INSERT INTO @FK_TABLE_ORDER
 SELECT 0, t.object_id FROM sys.tables t
 WHERE t.object_id NOT IN (SELECT OBJECTID FROM @FK_TABLE_ORDER)

 SELECT OBJECT_NAME(OBJECTID) as 'Table Name', MAX(FKLEVEL) as 'Load Order'
     FROM @FK_TABLE_ORDER GROUP BY OBJECTID 
     ORDER BY [Load Order] ASC

-Jay

select database_name, max(backup_finish_date) as 'last backup' from dbo.backupset
    group by database_name

And the error log records the last DBCC. 

Also, if you have access to the backup file, you can get the last backup timestamp and database version (in the backup file) using the RESTORE HEADERONLY command.

Though most of this is maintained and available in MSDB and other system base tables (database create date), I wanted to introduce you to the database boot page.  This information (and other information) is also stored in each database on the Database Boot Page.  Not sure which page that is?  Well, there are 2 ways you can get to this information stored on it.

First, we can use DBCC DBINFO:

use scratchdb
go

dbcc traceon(3604)
go

dbcc dbinfo()
go

And we get our answers (results truncated):

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBINFO STRUCTURE:


DBINFO @0x000000001A2DD520

dbi_dbid = 15                        dbi_status = 65536                   dbi_nextid = 2105058535
dbi_dbname = scratchdb               dbi_maxDbTimestamp = 2000            dbi_version = 661
dbi_createVersion = 661              dbi_ESVersion = 0                    
dbi_nextseqnum = 1900-01-01 00:00:00.000                                  dbi_crdate = 2012-07-29 18:43:55.670
dbi_filegeneration = 0               
dbi_checkptLSN

m_fSeqNo = 28                        m_blockOffset = 54                   m_slotId = 64
dbi_RebuildLogs = 0                  dbi_dbccFlags = 2                    
dbi_dbccLastKnownGood = 1900-01-01 00:00:00.000                           
dbi_dbbackupLSN

m_fSeqNo = 28                        m_blockOffset = 54                   m_slotId = 64

dbi_oldestBackupXactLSN

m_fSeqNo = 0                         m_blockOffset = 0                    m_slotId = 0
dbi_LastLogBackupTime = 2012-07-29 18:44:37.040                           
dbi_differentialBaseLSN

Here you can see our information as well as the original database creation version, database status, it’s DB ID, and other information that is needed by SQL Server at startup when mounting a database.

So my database is version 661 (SQL Server 2008 R2 SP1), and the log was just backed up (and the database created just before that), and has never had DBCC CHECKDB run.  As mentioned, this information is stored on the database boot page (pagetype 13).  That is page #10 or ordinal position 9 starting from 0.  You can find it with DBCC PAGE (the page will have just 1 slot for the DBINFO structure):

dbcc traceon(3604)
go

dbcc page(15, 1, 9, 3)
go

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

PAGE: (1:9)


BUFFER:


BUF @0x00000000B8FDBE80

bpage = 0x00000000B89FC000           bhash = 0x0000000000000000           bpageno = (1:9)
bdbid = 15                           breferences = 0                      bcputicks = 0
bsampleCount = 0                     bUse1 = 57609                        bstat = 0xc00009
blog = 0x89898989                    bnext = 0x0000000000000000           

PAGE HEADER:


Page @0x00000000B89FC000

m_pageId = (1:9)                     m_headerVersion = 1                  m_type = 13
m_typeFlagBits = 0x0                 m_level = 0                          m_flagBits = 0x200
m_objId (AllocUnitId.idObj) = 99     m_indexId (AllocUnitId.idInd) = 0    Metadata: AllocUnitId = 6488064
Metadata: PartitionId = 0            Metadata: IndexId = 0                Metadata: ObjectId = 99
m_prevPage = (0:0)                   m_nextPage = (0:0)                   pminlen = 0
m_slotCnt = 1                        m_freeCnt = 6650                     m_freeData = 1540
m_reservedCnt = 0                    m_lsn = (28:85:3)                    m_xactReserved = 0
m_xdesId = (0:0)                     m_ghostRecCnt = 0                    m_tornBits = –223305262

<truncated>

DBINFO @0x000000001857A060

dbi_dbid = 15                        dbi_status = 65536                   dbi_nextid = 2105058535
dbi_dbname = scratchdb               dbi_maxDbTimestamp = 2000            dbi_version = 661
dbi_createVersion = 661              dbi_ESVersion = 0                    
dbi_nextseqnum = 1900-01-01 00:00:00.000                                  dbi_crdate = 2012-07-29 18:43:55.670
dbi_filegeneration = 0               
dbi_checkptLSN

m_fSeqNo = 28                        m_blockOffset = 54                   m_slotId = 64
dbi_RebuildLogs = 0                  dbi_dbccFlags = 2                    
dbi_dbccLastKnownGood = 1900-01-01 00:00:00.000                           
dbi_dbbackupLSN

m_fSeqNo = 28                        m_blockOffset = 54                   m_slotId = 64

dbi_oldestBackupXactLSN

m_fSeqNo = 0                         m_blockOffset = 0                    m_slotId = 0
dbi_LastLogBackupTime = 2012-07-29 18:44:37.040                           
dbi_differentialBaseLSN

-Jay

I have a couple of posts I wanted to write to answer some questions I get from customers in our SQL Server Performance Tuning and Optimization Workshops – and to get back into updating my blog.  So the question for this post:

Question:  What is captured by the default trace?

This is actually a pretty simple question to answer if you know the right function to query in SQL Server – and you can undoubtedly find it by Binging it.  However, I’m going to go ahead and outline it here combined with the system_health extended events trace – new starting in SQL Server 2008.

SQL Trace Default Trace

To get the events captured in SQL Server by the default trace, we just need to supply the trace id for the default trace to the fn_trace_geteventinfo function and join this to sys.trace_events to map the event id’s to their event names:

declare @handle int = (select id from sys.traces where is_default = 1);
select distinct e.eventid, n.name from
    fn_trace_geteventinfo(@handle) e
    join sys.trace_events n
    on e.eventid = n.trace_event_id
    order by n.name asc

which gives us the event id and it’s event name captured by the default trace:

if you wish to get the actual data out of the default trace files – there are 5 by default, then you can do the following to see what configuration and schema changes have been made on your system in the last 5 restarts of your SQL Service or in the last 100 MB of trace data – whichever comes first (the default trace automatically starts a new file at 20MB and maintains 5 files):

declare @def_trace nvarchar(250) = (select path from sys.traces where is_default = 1)
select e.name, x.* from         
    fn_trace_gettable(@def_trace, 5) x
    join sys.trace_events e
    on x.EventClass = e.trace_event_id

System Health Extended Event Trace

Starting with SQL Server 2008, we have a new tracing and diagnostic capability known as Extended Events.  Extended Events is a much more robust way of collecting diagnostic and performance data on your SQL Server.  It’s designed to be much more efficient when firing events.  Additionally, filtering has been pushed down to the code level so that if the event doesn’t meet the criteria, it isn’t published.

In SQL Server 2008 you had to learn the syntax for creating Extended Event Sessions.  The syntax isn’t bad, but the XPath style queries to process the results into rowsets is a bit tricky.  In SQL Server 2012, we have a UI Wizard to help us perform these collections with ease:

In fact, SQL Trace is being deprecated in favor of Extended Events:

Deprecated Database Engine Features in SQL Server 2012
https://technet.microsoft.com/en-us/library/ms143729(SQL.110).aspx

I don’t want to go into explaining how Extended Events work – or how to use them here.  Virtual reams have already been written on those topics.  Just know that in SQL Server 2012 the number of events has increased dramatically and it’s hard to imagine something you can’t capture using Extended Events.   Jonathan Kehayias does a good job of explaining how to use Extended Events in a nice lesson-per-day format here:

An XEvent A Day: 31 days of Extended Events
https://sqlblog.com/blogs/jonathan_kehayias/archive/2010/12/01/a-xevent-a-day-31-days-of-extended-events.aspx

In this post, I simply wanted to show you how to see which events are being captured in the new default system_health extended event session – much like the default trace above.  You can see which sessions are active using:

select * from sys.dm_xe_sessions

Where you should see at least:

This new system_health extended events session is there to help product support troubleshooting basic, common performance problems.  But what is it capturing?  That information can be found using this query:

select * from sys.dm_xe_session_events e
    inner join sys.dm_xe_sessions s
    on e.event_session_address = s.address

which gives us:

Now some of these events have predicates for filtering what is captured.  The predicate is used to filer what is captured so we don’t try to gather too much information – information that may not be useful to product support – like waits that aren’t common causes of performance problems.  Extended event sessions have “targets” where they write their data to.   The system_health session logs all data into a ring_buffer (and an event_file in SQL Server 2012 – called an asynchronous_file_target in SQL Server 2008).  The ring_buffer is a circular buffer in memory that will wrap around and overwrite old records once it fills up.  So how do you read the contents?  Cast the data to XML and then extract it with an XPath query:

declare @sys_health xml;

set @sys_health = ( select cast(t.target_data as xml)
                    from sys.dm_xe_session_targets t
                    join sys.dm_xe_sessions s
                    on t.event_session_address = s.address
                    where s.name = 'system_health' )       

select
    n.value('(@name)', 'nvarchar(50)') as [event name],
    n.value('(data[@name="wait_type"]/text)[1]', 'nvarchar(50)') as wait_type,
    n.value('(data[@name="duration"]/value)[1]', 'bigint') as duration,
    n.value('(action[@name="sql_text"]/value)[1]', 'nvarchar(4000)') as stmt_text
from @sys_health.nodes('/RingBufferTarget/event') as q(n)

and on my server we get:

-  Jay

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL

EDIT:

If you are looking for 32 bit instances on a 64 bit OS, you will need to look here:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\Instance Names\SQL

All we need to do is query this registry key to get the list of instances installed on a machine.   On my personal machine, I have the following instances installed:

SQLEXPRESS   
MSSQLSERVER   
CRASH   
DEBUG   
MICROSOFT##SSEE
SQL2005  

Below are a few ways we can get this information for 64 bit instances on 64 bit Windows:

Command shell “reg.exe” utility:

reg query "HKLM\Software\Microsoft\Microsoft SQL Server\Instance Names\SQL"

In PowerShell:

Get-ItemProperty 'HKLM:\Software\Microsoft\Microsoft SQL Server\Instance Names\SQL'

In .NET:

RegistryKey baseKey = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
RegistryKey key = baseKey.OpenSubKey(@"SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL");

foreach (string s in key.GetValueNames())
{
    MessageBox.Show(s);
}

key.Close();
baseKey.Close();

If you need to read the registry from another computer, then the RegistryKey class has a “OpenRemoteBaseKey” static method that you can use. 

- Jay

The Parameters of xp_readerrorlog
https://blogs.msdn.com/b/askjay/archive/2010/09/19/the-parameters-of-xp-readerrorlog.aspx

I thought I’d go ahead and extend that methodology in a new post.  A few things on this first…  This is nice for DBAs because it’s likely to use the skills a DBA is already familiar with – namely TSQL.  It also runs from within SQL Server instead of running a PowerShell or Batch File script from within the shell.  However, just to be clear – we have announced that Extended Stored Procedures are being deprecated in SQL Server 2008 R2.  For more information on this:

Deprecated Database Engine Features in SQL Server 2008 R2
https://msdn.microsoft.com/en-us/library/ms143729.aspx

Work going forward should be done using CLR stored procedures.  I do not know whether or not we’ll be providing a CLR replacement for this out of the box.  If not, it would be a fairly simple procedure to write.

With xp_readerrorlog, we can only read 1 error log at time by using the first parameter to specify the file extension and the second to specify whether we wish to read the SQL Server Errorlog or the SQL Agent Errorlog.   To read all the logs – we just need to loop through reading all the logs and load them into a table (or return multiple result sets if we are ok with this).   Below is a script that does just this:

    if exists (select * from tempdb.sys.tables where name like '#Errorlog%')
        drop table #Errorlog;

    create table #ErrorLog
    (
        LogDate datetime,
        ProcessInfo nvarchar(16),
        [Text] nvarchar(2048)
    )
    go

    declare @p1 nvarchar(64);
    declare @p2 nvarchar(64);
    declare @logNum int;
    declare @NumErrorLogs int;

    -- add search conditions here
    select @p1 = null;
    select @p2 = null;
   
    --get the value of max errorlogs from registry
    exec master.dbo.xp_instance_regread N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'NumErrorLogs', @NumErrorLogs OUTPUT

    -- init counter
    set @logNum = 0;

    while (@logNum <= @NumErrorLogs)
     begin
        declare @exists int
        exec xp_fileexist 'c:\windows\notepad.exe', @exists out
        if (@exists = 1)
            begin
            insert into #Errorlog
                exec xp_readerrorlog @logNum, 1, @p1, @p2
            end
        select @logNum = (@logNum + 1);
     end

    select * from #ErrorLog

Briefly, we check to see if the table exists, if it does DELETE it.  Then create a temporary table to hold our executions of xp_readerrorlog.  Next, we read the registry to get the configured max number of Errorlogs for our loop.  Then we loop and load each execution into the temporary table.  Once everything is in the temporary table we can obviously narrow down items further by adding a predicate to our SELECT statement.

You could encounter a problem with this for servers that do not have all the log files configured by the maximum value set in SSMS.  This situation would arise with new servers and with servers that have recently had this value increased.  Therefore, with each loop we test to verify the file exists before attempting to execute xp_readerrorlog with xp_fileexist.

Remember, there are many ways to accomplish this.  I hope this is useful for those that like using xp_readerrorlog.

-Jay