• Skip to main content
  • Skip to primary sidebar

DallasDBAs.com

SQL Server Database Consulting

  • Services
  • Pocket DBA®
  • Blog
  • Testimonials
  • Contact
  • About

SQL

DBCC Opentran, simplified!

April 3, 2017 by Kevin3NF 2 Comments

In my Top 10 SQL Server Functions post awhile back, I listed DBCC OPENTRAN as one of the top 3, and for good reason.

An Open transaction may simply be something that has not finished yet, or someone issued a BEGIN TRAN without a corresponding COMMIT or ROLLBACK.  Or as we will see at the end, replication is having issues.

You can use this against any database with minimal syntax and get back solid information very quickly.

 
--connect to sample db
use MyDatabase
go

--as generic as this command gets and still runs:
DBCC OPENTRAN
 

Result if nothing is open:

No active open transactions.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

If I start and execute a DML (insert, update or delete) transaction with BEGIN TRAN and leave out the corresponding COMMIT, I get:

Transaction information for database ‘SmallData_BigLog’.
Oldest active transaction:
SPID (server process ID): 64 <———–
UID (user ID) : -1
Name : user_transaction
LSN : (637:4620:1)
Start time : Apr 1 2017 4:59:02:307PM
SID : 0x0105000000000005150000004893a0845595b6fef515cd5de9030000
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Now, if I open a second transaction (in a new query window) and execute any DML statement without the COMMIT, and then run DBCC OPENTRAN again, I get:

Transaction information for database ‘SmallData_BigLog’.
Oldest active transaction:
SPID (server process ID): 64 <———–
UID (user ID) : -1
Name : user_transaction
LSN : (637:4620:1)
Start time : Apr 1 2017 4:59:02:307PM
SID : 0x0105000000000005150000004893a0845595b6fef515cd5de9030000
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Yes…the same output, as this is just showing the ONE oldest transaction.

I can run a query to show that there are two SPIDs with open transactions:

--
SELECT spid, blocked,[dbid],last_batch,open_tran
FROM master.sys.sysprocesses
WHERE open_tran <> 0
 

DBCC Opentran Spid

If I COMMIT spid 64 and re-run DBCC OPENTRAN, the SPID changes to the second transaction I started:

Transaction information for database ‘SmallData_BigLog’.
Oldest active transaction:
SPID (server process ID): 52  <———–
UID (user ID) : -1
Name : user_transaction
LSN : (637:9603:1)
Start time : Apr 1 2017 5:11:20:830PM
SID : 0x0105000000000005150000004893a0845595b6fef515cd5de9030000
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

If I COMMIT spid 52 and re-run DBCC OPENTRAN along with checking sysprocesses for open_tran <> 0 I get:

No active open transactions.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
spid blocked dbid last_batch open_tran
—— ——- —— ———————– ———
(0 row(s) affected)

 

Now, all of that was just running DBCC OPENTRAN by itself.  There are additional options:

--specify dbname, dbid or 0 for the current database
DBCC OPENTRAN (SmallData_BigLog)

You will get results in the same format as the previous examples.

You can suppress all messages, regardless of if a transaction is open or not (but I have no idea why this would help you…)

DBCC OPENTRAN (0) with no_infomsgs

Result:

Command(s) completed successfully.

 

If you needed to periodically capture the oldest transaction, in order to review later, use WITH TABLERESULTS:

-- TableResults only shows the oldest open tran
-- useful running in a loop to load the oldest
-- tran over time.

--create a temp table
CREATE TABLE #OpenTranStatus (
ActiveTransaction varchar(25),
Details sql_variant
);

-- Execute the command, putting the results in the table.
INSERT INTO #OpenTranStatus
EXEC ('DBCC OPENTRAN (SmallData_BigLog) with tableresults')
SELECT * FROM #OpenTranStatus
DROP TABLE #OpenTranStatus
   

In the above, you could create a user table instead of a temp table of course…it depends on your needs.

One more particularly useful item you may see when running DBCC OPENTRAN by itself:

Transaction information for database ‘Music’.
Replicated Transaction Information:
Oldest distributed LSN : (37:143:3)
Oldest non-distributed LSN : (37:144:1)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

 

If your database is participating in Replication as a Publisher, this may show up when running OPENTRAN, but it doesn’t necessarily mean that the transaction is actually open.  I set this up and stopped the Replication Log Reader and Distribution agent jobs.   I then added some data to a published table (article) and ran DBCC OPENTRAN to get the above result.  Note that there are two lines with LSN information in them (no SPIDs)

I then ran the Log Reader Agent job and got back:

Transaction information for database ‘Music’.
Replicated Transaction Information:
Oldest distributed LSN : (37:157:3)
Oldest non-distributed LSN : (0:0:0)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

I have verified that new records I inserted have been read by the log reader, AND distributed to the subscriber(s).  This means that while you are seeing

Oldest distributed LSN : (37:157:3)

There is not an error…just info.

If you have non-distributed LSNs, there is something to troubleshoot in the replication process which is way outside the scope of this post.  A non-distributed replicated transaction/LSN CAN cause some huge Log file growth, and need to be investigated.  If this happens frequently, use the TABLERESULTS option to log to a regular table and alert on it.

Hopefully this gives you some insight into various ways to use DBCC OPENTRAN as well as use cases for the various options.  90% of the time I run this, it is due to application transactions timing out, or log file growth issues.

I love comments….please feel free to leave questions for me in them on this topic.

Thanks for reading!

Kevin3NF

My Pluralsight course for new SQL Server DBAs

Follow @Dallas_DBAs


Filed Under: Accidental DBA, Beginner, EntryLevel, Performance Tuning, SQL

Query your SQL Server ERRORLOGS

April 2, 2017 by Kevin3NF Leave a Comment

Quick post in response to a number of Twitter and Forum questions I’ve seen lately.

Downloadable from the Microsoft code Gallery (with ranking options!)

“How can I search my SQL ERRORLOGS with native tools?”

Create Table #Errorlog 
	(Logdate datetime, 
	 ProcessInfo varchar(50), 
	 LogText varchar(5000))

--Dump all the things into the table
insert into #Errorlog
EXEC sys.xp_readerrorlog 
	0			-- Current ERRORLOG
	,1			-- SQL ERRORLOG (not Agent)

--Query just like you would anything else:
Select * 
from #Errorlog 
Where 1=1
	--and LogText like '(c) Microsoft Corporation%'
	and (LogText like '%Error%'	or LogText like '%Fail%'--or LogText like '%SPN%'
	)
	And Logdate > getdate() -1
	And LogText Not Like '%CheckDB%'
	And LogText not like '%35262%'
	And LogText not like '%35250%'

--Clean up your mess, you weren't raised in a barn!
Drop Table #Errorlog

I run this every morning against my Prod Local Server Group in SSMS Registered Servers

Filed Under: SQL

The Apprentice: Locks and Blocks and Deadlocks….oh my!

March 30, 2017 by Kevin3NF Leave a Comment

I re-posted SQL 101 Blocking vs. Deadlocking – in English for the Non-DBA the other day for two reasons:

  1.  Its good info for new DBAs struggling to understand the interaction and differences in these terms
  2.  It was next on the list to walk the Apprentice through and he reads my Tweets 🙂

We had about an hour to spend working through this so we briefly covered the article, using Starbucks and Chick-Fil-A interchangeably as something you almost always have to wait in line for.

Things we managed to cover, test, or define in that one hour:

  • Lock: When a customer “Sally” (query1) walks up to the cashier “Ken” (Resource1), she has locked him into taking her order.
    • Ken is a CPU here, or a Row/Page/Table…don’t overthink my analogies 😀
  • Block: The dude “Broseph” (query2) behind Sally (query1) has to wait…he’s blocked.
  • If the manager (Query Optimizer) sees that Sally is ordering 20 drinks for the office, he may open a second register and have Joe (Resource2) starting ringing up some of Sally’s orders.  Brospeh is still in line, waiting.  Sally has gone parallel.
  • If the manager decides Ken needs to work all of Sally’s order himself (MAXDOP1), he may open a second register (Joe/resource2) and move Broseph to that line.
  • If Max (query3) walks in, sees what is going on and decides he doesn’t really want coffee…he just rolls on back out the door and leaves a 1-star review on Yelp (failed transaction, retry?)

Other stuff we covered, in no particular order:

  • Deadlocking and the Mom process (see above link)
  • INSERT statements to create sample blocking
  • IMPLICIT and EXPLICIT transactions, so the tests actually work
  • 4 parts of an object name [instance].[database].[schema].[object]
  • Why a sysadmin cannot directly query Instance2 from Instance1, regardless of his level of sysadmin-ness unless…
  • …Linked Server
  • sp_lock
  • master..sysprocesses (old skool)

Good times were had, jokes were made, stuff was learned.  Oh…and every time we meet I ask him random stuff from previous meetings to gauge retention.   So far so good.

Thanks for reading!

Kevin3NF

Filed Under: Accidental DBA, Apprentice, Beginner

xp_CmdShell is not a security risk…people are!

March 22, 2017 by Kevin3NF 4 Comments

Quickie today….

Someone please tell me why this is considered insecure:

A stored procedure that, out of the box, is disabled and has no explicit rights granted (or denied) is locked down to everyone but those in the sysadmin server role.

If someone exploits your SQL Server via xp_cmdshell, its because you LET them, either by granting permissions or by putting someone in sysadmin that clearly should not have been there.

Told you it was a quickie 🙂

Thanks for reading!

Kevin3NF

Filed Under: Security

Prediction: SQL server DBA role

March 20, 2017 by Kevin3NF 3 Comments

There have been a lot of questions, posts, answers, guesses and such floating around the SQL blogs lately…most of which seem to suggest that the DBA is going away.

Hogwash.

The DBA position is not going away.  Ever.  Or at least not before I retire to Utah to spend my days mountain biking 😉

But…it is changing and will do so even more over the next 3-5 years.   Long gone are the days where a DBA stays busy backing up databases and creating indexes.   Those are still necessary, or even critical, but thanks to some brilliant minds and thousands of willing testers, the basic tasks of the DBA have largely been scripted away.

Automation.  Powershell.  Cloud technologies.  SQL Server on Linux.

Some of these have been around awhile, some are newer and some are still in CTP.  But they are ABSOLUTELY going to be required knowledge for anyone in or around the database world…admins, developers and managers.

Automation – this is a basic need at this point.   Whether running Ola‘s backup/maintenance scripts, or using Powershell to shut down Virtual SQL Server in Azure, if you are not automating repetitive tasks you are wasting your employer or client’s money.  Simple as that.

Powershell – 10+ years old now, and is really starting to pick up steam in the SQL realm…thanks largely but not solely to the dbatools team. Companies increasing their use of PS are going to make obsolete the “I can do everything I need in T-SQL” argument.  My decision to switch.

Cloud tech – AWS, Azure, Google, Cisco, internal, public, private…lions and tigers and bears, oh my!  As a DBA you are going to have to help guide your firm in the right path when the marketing/sales guys try to influence them.   You cannot do that unless you know the pros and cons…from Data Lakes to simple blob storage for backup.  Learn the lingo so you are not caught unaware.

SQL on Linux – Something I have just started messing around with.  I guarantee you this is going to be huge.  Microsoft made a brilliant decision here and has done an amazing job porting a massive number of SQL features to the Linux based “vNext”.  My prediction – in 5 years if you aren’t competent enough to navigate Linux in order to troubleshoot a SQL issue, your job prospects will be limited.  Just start learning now…free Linux training is all over the place.

This is just touching the surface of how the DBA job will be changing…just like it has been changing for the 18 years I’ve been in it.  Don’t be afraid, just begin adapting now so you are ahead of the game!

I sincerely hope this has been an encouragement to you.  Your job as a DBA is not going away…its actually becoming more necessary.  Are you up to the task of adapting?

Thanks for reading!

Kevin3NF

Filed Under: Career, PowerShell, vNext

TSQL Tuesday: The daily WTW?

March 14, 2017 by Kevin3NF Leave a Comment

T-SQL Tuesday is a monthly blog party for the SQL Server community. It is the brainchild of Adam Machanic (b|t) and this month’s edition is hosted by Kennie N Ponotoppidan (b|t), and covers the topic “The Daily Database WTW” (yes, I know,  I changed it to “What the What”.  Personal preference…)

Kennie is asking us to post about the most insane thing we’ve seen in SQL Server.   Mine was so bad I’ve already blogged about it here, so I’m just going to copy and paste…because I’m lazy 🙂

I walked into a new client in 2015 and found this, all one one server:

o   SQL 2008 R2, RTM
o   Incorrect Memory configuration
o   Full recovery model on data that only changes once a week at most
o   ZERO documentation of server settings
o   New data is imported to a new table and a UNION ALL query is modified to add that table
o   ZERO documentation of code/databases
o   Stored Procedures have no comments, poor formatting and developer names in the name of the proc
o   Autogrow is 1MB, data imports are hundreds of MB each
o   Everyone is sysadmin, probably including you…
o   Change control process is intentionally shortcut and ignored on this internal production system
o   Ownership changed to me in December, then was yanked back 3 weeks later with developers overwriting my fixes in prod.

 

I still feel the stench of that assignment…but its slowly wearing off 🙂
Thanks for reading!
Kevin3NF

Filed Under: TSQL2sday

  • « Go to Previous Page
  • Go to page 1
  • Interim pages omitted …
  • Go to page 29
  • Go to page 30
  • Go to page 31
  • Go to page 32
  • Go to page 33
  • Interim pages omitted …
  • Go to page 37
  • Go to Next Page »

Primary Sidebar

Search

Sign up for blogs, DBA availability and more!

Home Blog About Privacy Policy
  • Home-draft
  • Blog
  • About Us

Copyright © 2026 · WordPress · Log in

 

Loading Comments...