Here is the scenario. You have a table that is transactional. You only care about the most recent record for your system, but need to have historical data available for reporting and/or [...]]]> As we all know, and some of us hate, triggers are not the best thing for performance. Enter SQL 2005+ with the Output clause.

Here is the scenario. You have a table that is transactional. You only care about the most recent record for your system, but need to have historical data available for reporting and/or auditing purposes. The prior developer created a trigger on the primary table that inserts the old information into an audit table on update of the primary table. That’s not a bad solution, but there is an alternative that will work as well.  Below is a very simple example of how this may work.

IF OBJECT_ID(’tempdb..#Current’) IS NOT NULL
DROP TABLE #Current

IF OBJECT_ID(’tempdb..#Hist’) IS NOT NULL
DROP TABLE #Hist

CREATE TABLE #Current(ID int IDENTITY(1,1) , Key varchar(20), Val varchar(255))
CREATE TABLE #Hist(HistID int IDENTITY(1,1) ,OriginalID int, Key varchar(20), Val varchar(255))

INSERT INTO #Current(Key,Val) VALUES(’Root Dir’,'X:\Files’)
INSERT INTO #Current(Key,Val) VALUES(’Temp Dir’,'C:\’)

SELECT ID,Key,Val FROM #Current

– now we realise that C:\ is not the correct value for the temp dir setting, we want to update it but track history…

UPDATE #Current
SET Val = ‘C:\Temp\’
OUTPUT DELETED.ID,DELETED.Key,DELETED.Val INTO #Hist(OriginalId,Key,Val)
WHERE Key = ‘Temp Dir’

SELECT ID, Key, Val FROM #Current
SELECT HistId,OriginalId,Key,Val FROM #Hist
IF OBJECT_ID(’tempdb..#Current’) IS NOT NULL
DROP TABLE #Current

IF OBJECT_ID(’tempdb..#Hist’) IS NOT NULL
DROP TABLE #Hist

CREATE TABLE #Current(ID int IDENTITY(1,1) , Key varchar(20), Val varchar(255))
CREATE TABLE #Hist(HistID int IDENTITY(1,1) ,OriginalID int, Key varchar(20), Val varchar(255))

INSERT INTO #Current(Key,Val) VALUES(’Root Dir’,'X:\Files’)
INSERT INTO #Current(Key,Val) VALUES(’Temp Dir’,'C:\’)

SELECT ID,Key,Val FROM #Current

– now we realise that C:\ is not the correct value for the temp dir setting, we want to update it but track history…

UPDATE #Current
SET Val = ‘C:\Temp\’
OUTPUT DELETED.ID,DELETED.Key,DELETED.Val INTO #Hist(OriginalId,Key,Val)
WHERE Key = ‘Temp Dir’

SELECT ID, Key, Val FROM #Current
SELECT HistId,OriginalId,Key,Val FROM #Hist

This is something similar to the CDC functionality in SQL 2008 and should work better on sets of data than a trigger on the table. I hope to provide some benchmarks in a future post.

(NOTE: This is derrived from another post I made several months ago on my personal blog.)

I wrote a quick audit procedure to basically monitor connections to every instance in my environment by simply querying sysperfinfo. Well, for the most part the data is spot on. Except for two instances. The cntr_value in sysprocesses for counter_name = ‘user connections’ is [...]]]> So this was an interesting one, never seen such a thing before.

I wrote a quick audit procedure to basically monitor connections to every instance in my environment by simply querying sysperfinfo. Well, for the most part the data is spot on. Except for two instances. The cntr_value in sysprocesses for counter_name = ‘user connections’ is showing about 2,000 for two instances yet sysprocesses shows no more than 30-40 at a time for these instances. I have verified that using perfmon on the server, does indeed report the same number that sysperfinfo does.

I am polling data from over 200 instances, and only these two are showing inaccurate numbers. To add to the mystery, these servers are pretty much the same. One is a virtual and one is a physical, with the exact same layout, databases, etc. The virtual was to be a proof of concept that the physical could be turned into a virtual. The physical is in use whereas the virtual is not, yet they both have this same problem in regards to sysperfinfo not being anywhere near the actual number of connections, and the number for both is extremely high.

Wasn’t able to find much of anything relevant online, so I restarted the instance and the counters in sysperfinfo went back to normal. They now match sysprocesses. I’m going to keep an eye on this to see if the problem returns, but for now, all is well.