When you have indexes that are never used for any SELECT queries, the obvious issue is the wasted disk space to store them.  The less obvious is the penalty you pay to maintain the indexes if their underlying data is subject to inserts, updates or deletes.  Whenever the data changes, SQL may need to rearrange and maintain the index trees.

Consider in a replication environment where the updates of tables from the publisher get trickled down to the subscriber.  In the profiler trace against the subscriber, you only see replication calls to insert, update or delete the tables on the subscriber but implicitly all the related indexes of the modified tables are also changing.  By identifying what indexes are not used and removing them, both the publisher and subscriber can benefit from less indexes to maintain.

To find out the index usage, use DMV sys.dm_db_index_usage_stats along with system views sys.indexes , sys.objects and sys.schemas like the script below:

select sysschema.name 'schema_name'

,sysobj.name 'table_name'

,ISNULL(sysidx.name,'HEAP') 'index_name'

,sysidx.index_id

,'is_unused_index' = CASE ISNULL(idxstats.user_seeks,0) + ISNULL(idxstats.user_scans,0) + ISNULL(idxstats.user_lookups,0)

WHEN 0 THEN 1 ELSE 0 END

,sysidx.is_unique

,sysidx.is_unique_constraint

,ISNULL(idxstats.user_updates,0) 'user_updates'

,ISNULL(idxstats.user_seeks,0) 'user_seeks'

,ISNULL(idxstats.user_scans,0) 'user_scans'

,ISNULL(idxstats.user_lookups,0) 'user_lookups'

, DropScript = CASE ISNULL(idxstats.user_seeks,0) + ISNULL(idxstats.user_scans,0) + ISNULL(idxstats.user_lookups,0)

WHEN 0 THEN '' ELSE null END

+ 'IF EXISTS (SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(N''[' + sysschema.name + '].['

+ sysobj.name + ']'') AND name = N''' + sysidx.name + ''') '

+ case sysidx.is_unique_constraint -- 1: drop constraint 0: drop index

when 1 then ' ALTER TABLE [' + sysschema.name + '].[' + sysobj.name + '] DROP CONSTRAINT [' + sysidx.name + ']'

else ' DROP INDEX [' + sysidx.name + '] ON [' + sysschema.name + '].[' + sysobj.name + ']'

end

from sys.indexes sysidx

join sys.objects sysobj on sysidx.object_id = sysobj.object_id

join sys.schemas sysschema on sysobj.schema_id = sysschema.schema_id

left join sys.dm_db_index_usage_stats idxstats

on sysidx.object_id=idxstats.object_id

and sysidx.index_id=idxstats.index_id

and idxstats.database_id=db_id()

where sysobj.type_desc = 'USER_TABLE'

and sysidx.index_id > 1

and sysobj.is_ms_shipped = 0 -- exclude object created by an internal SQL Server component such as sysarticleupdates, syspublications, syssubscriptions

order by 1,2

Executing the script, you get a list of unused indexes and also the drop index statements that you can copy and paste as a deployment script.

As I mentioned before, indexes can be used find data (read-only) but they are also subject to updates (write-only) if the underlying data is modified.  By permutating read and write activities on the indexes, we can conclude four types of index usage patterns as the table below:

Row # from output above	Read-only access pattern (scans, seeks and lookups)	Write-only access pattern (updates)	Indexes not used and should be dropped	Will improve performance after dropping indexes
26	Yes	Yes	No	N/A
23, 28	No	No	Yes	No
24, 25	Yes	No	No	N/A
27	No	Yes	Yes	Yes

Let me go over all four of them.

1.     BOTH read and write access patterns: this is indexes that help answering queries and also get updated when underlying data changes.  Let's keep this kind.

2.     No read or write access pattern: although it's not used but it's not hindering system performance.  Removing this kind of indexs saves you disk space at most without influencing performance.

3.     Only read access pattern but not write access pattern: like the first one, this sort helps your joins and the underlying data is never changed so no writes.  Let's also keep it.

4.     Last is the unnecessary indexes that are never used to answer queries but are needed to be updated to maintain index tree structure.  Grab the DropScript column for your convenience where the drop statements are generated.  Getting rid of these indexes should improve your replication performance.

The same exercise can be performed on a non-replication system.  You should get the same performance gain when those unused indexes are dropped.

The gain should be in the form of shorter replication backup on the subscriber when the publisher makes a big push.  Another form of gain, regardless of a replication system or not, should be noticed with lower CPU usage.  The main reason is the reduction of index searches associated with maintaining the index trees.

A few notes of caution:

·         Be aware that the DMV's used in the script accumulates index usages since SQL last restarts.  You should make sure SQL has been running for a while, long enough to capture all patterns of your loads.

·         Some unused indexes can be unique constraints which enforce your business rules.  Carefully examine them to decide if they can be drop without breaking any business rules.

·         Lastly, thoroughly try this out on you test or PPE environment before proceeding to production.

Leave a comment if you see any performance gain and by how much after removing these indexes.

Happy coding!

Mike Chang (Chien-Shen)

SQL SDE, MSDN

However, I have discovered a "defect" that the recompilation thresholds are not always honored.  The anomaly is that if one session has crossed a higher level RT and also incurs a recompilation, a later, different session that populates the temp table with fewer rows and also crossed a RT that equal or less than the RT of the aforementioned session, a recompilation that should have incurred would be skipped.

The best way to explain this anomaly is to show you how to repro it.  I will use an easy to understand example and also screenshots to illustrate the issue.  You don't need to repro it to get the idea it but I bet a lot of you will be intrigued to repro it.  When I first discovered this bug, I thought I was out of my mind during the all time high record hot day in Remond, WA! 

My environment is Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (X64)   Jul  9 2008 14:17:44   Copyright (c) 1988-2008 Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 6.0 <X64> (Build 6001: Service Pack 1)

Here's the repro:

First to create objects we need: one dbo.Num table as the source of the temp table and one dbo.proc1 to be executed on different sessions.

use tempdb

create table dbo.Num( CIKey int primary key)

declare @rowcount int = 2000

declare @i int = 1

while @i <= @rowcount

begin

   insert into dbo.Num(CIKey)

   values (@i)

   select @i += 1

end

select * from dbo.Num -- return 1 - 2000

use tempdb

create procedure Proc1 (@start int, @rowcount int, @filter int)

as

begin

create table #t (

      [CIKey]   [int] identity(1,1) primary key,

      [NCKey] [int] ,

   filler nvarchar(1000) default (replicate('x',1000))

)

create index #t_NCKey on #t(NCKey)

insert into #t ([NCKey])

select cikey from dbo.num

where cikey between @start and @start + @rowcount

-- Where the recompilation occurs

select * from #t

where NCKey >= @filter

end

go

dbcc freeproccache

dbcc dropcleanbuffers

-- get plan compiled and cached

exec proc1 1,1, 1

To catch the anomaly, let's use SQL profiler and select events SP:Completed and SP:Recompile.

That was the setup of our test environment.  We are ready for our repro of the bug. 

Open session 1, and run these four calls, all of them should incur 2 - Statistics changed EventSubClass in the profiler.

exec proc1 1,10, 1

exec proc1 1,515, 1

exec proc1 1,1150, 1

exec proc1 1,1900, 1

Open session2 and run the same four calls but to slightly change the first two parameters to differentiate from session 1.

exec proc1 100,11, 1

exec proc1 100,516, 1

exec proc1 100,1151, 1

exec proc1 100,1901, 1

Here is the screen shot of eight calls from two sessions (SPID 75 vs 76):

It's normal as expected with eight recompilations since each call would populate the temp table with more rows just enough to cross the RT and hence the recompilations.

Now the weird repro

Clear the profiler output but keep it running and make these calls in the following order:

Session 1:

            exec proc1 1,10, 1

Session 2:

            exec proc1 100,11, 1

            exec proc1 100,516, 1

Session 1:

            exec proc1 1,515, 1

            exec proc1 1,1150, 1

Session 2:

            exec proc1 100,1151, 1

            exec proc1 100,1901, 1

Session 1:

            exec proc1 1,1900, 1

I have highlighted the four abnormal calls missing recompilations in the Profiler screenshot below.

The correlation I can draw here is that if a different session has previously populated the temp table with closely same amount of rows, optimality recompilation will be skipped.  Look at the right most column, RowCounts in the above screenshot.  The abnormal ones have rowcounts that are within the same RT boundaries.  For example, the second, normal line has 22 rows while the third, abnormal line has 24.

This has a huge impact on how we use temp table.  Take my test proc for example.  I have a third parameter @filter used to limit the returned recordset:

select * from #t

where NCKey >= @filter

Let's say session 1 filters out a lot of rows by using a large @filter.  For example, exec proc1 1,2000, 1995 statement returns just 6 rows and the good plan is obviously to scan 6 rows on NC plus 6 CI bookmark lookups:

In session 2, without the needed recompilation, when running this call that doesn't do any filtering: exec proc1 1,2000, 1, the above inefficient plan is re-used causing bookmark lookup on the CI for every row (4006 reads)

If the recompilation did happen, SQL would have used a efficient CI scan to dump out the temp table (501 reads).

This unexpected behavior has been reported to SQL team and is confirmed as a bug.  One of the developers put it as "a very astute discovery".  I will update my blogs when I hear a fix.  In the meantime, check your code and see if your application can be affected.  Also feel free to leave a comment on how you would work around this.

Happy coding,

Mike Chang (Chien-Shen)

SQL Dev, MSDN

Bulk loading client side data into a SQL database is a common task in software development.  Sometimes the data is client generated and cached.  When the data accumulates to a specific size or over a specific period time, it's then bulk loaded into the database, for example, web server logs or system events.

On Microsoft platform, several approaches can be used to achieve this goal very effectively.  Here are two approaches, using ADO.Net DataTableReader class and using ADO.Net to construct a Dynamic TSQL.  Both approaches use a new SQL 2008 feature, table valued parameter (TVP) as the vehicle to transmit data to SQL server.  They are all fairly easy to implement and have good performance results which will be detailed later.

First is the setup at the SQL side that we will be utilized by the client ADO.Net code.  We will create a database, a table, a TVP type and a procedure.  The procedure has a TVP type parameter passed in from the client and populates the table.  Here's the script:

CREATE database DemoDB;

GO

CREATE table dbo.MyTvpTargetTable

(

   c1 int

  ,c2 int

)

GO

CREATE TYPE dbo.MyTVP AS TABLE

(

   c1 int

  ,c2 int

)

GO

Create proc MyProc (@tvp dbo.MyTVP readonly)

as

begin

   insert into MyTvpTargetTable (c1,c2)

   select c1, c2 from @tvp

end

GO

Now the first approach, using ADO.Net DataTableReader with TVP

In the nutshell, a DataTable is used to cache our accumulated data.  Once it reaches a size, we use a DataTableReader to read it.  We also create a SqlCommand that is of StoredProcedure CommandType.  The SqlCommand has a SqlParameter which has the value of the DataTableReader.  The code goes like this:

    static void InsertWithDataTableReader(int rowCount)

    {

      // used to time how fast this function runs later

      DateTime dt = DateTime.Now;

      // Create a new DataTable

      DataTable table = new DataTable("tvp");

      // Declare variables for DataColumn and DataRow objects.

      DataColumn column;

      DataRow row;

      // Create new DataColumn, set DataType,

      // ColumnName and add to DataTable.   

      column = new DataColumn();

      column.DataType = System.Type.GetType("System.Int32");

      column.ColumnName = "c1";

      column.ReadOnly = true;

      // Add the Column to the DataColumnCollection.

      table.Columns.Add(column);

      // Create second column.

      column = new DataColumn();

      column.DataType = System.Type.GetType("System.Int32");

     column.ColumnName = "c2";

      column.ReadOnly = true;

      // Add the Column to the DataColumnCollection.

      table.Columns.Add(column);

      // Imagine how you can accumulate your data in this DataTable.

      // When it reaches a size, we will bulk load to SQL

      for (int i = 1; i <= rowCount; i++)

      {

        // Use a DataRow object and add

        // it to the DataTable.

        row = table.NewRow();

        row["c1"] = i;

        row["c2"] = -i;

        table.Rows.Add(row);

      }

      // To read the DataTable and to be passed in as value of the SqlParameter

      DataTableReader dtReader = new DataTableReader(table);

      SqlConnection sqlconnection = new SqlConnection("Persist Security Info=False;Integrated Security=true;Initial Catalog=DemoDB;Server=(local)");

      sqlconnection.Open();

      // Configure the SqlCommand and table-valued parameter.

      SqlCommand insertCommand = new SqlCommand("MyProc", sqlconnection);

      insertCommand.CommandType = CommandType.StoredProcedure;

      SqlParameter tvpParam =

         insertCommand.Parameters.AddWithValue(

         "@tvp", dtReader);

      tvpParam.SqlDbType = SqlDbType.Structured;

      // Execute the command.

      insertCommand.ExecuteNonQuery();

      //Time how fast we run this function

      Console.WriteLine(DateTime.Now - dt);

    }

This function can be used in a console app.  You will also need to reference these assemblies:

using System.Data.SqlClient;

using System.Data.Sql;

using System.Data.Common;

using System.Data;

My test method is to call this method ten times and each time it will "accumulate" 1,000 rows.  So we have a test load of 10,000 rows:

    static void Main(string[] args)

    {

      DateTime dt = DateTime.Now;

      for (int i = 0; i < 10; i++)

          InsertWithDataTableReader(1000);

           // InsertWithDynamicSQL(1000);

      Console.Write("total run time: ");

      Console.WriteLine(DateTime.Now - dt);

      Console.Read();

    }

It took 236 ms on my box to insert 10,000 rows (10 batches x 1000 rows).  It's 42373 rows per second.  Pretty fast.  This approach scales very good too.  I tried a few different batch sizes for a few rounds and the performance is consistent and it has a better throughput when the batch sizes increase.  Since the streaming of data is robust, as the data volume increases, the overhead of various client side .Net classes is also diluted.  The throughput ramps up after reaching 500,000 rows and stay at above 110,000 rows per seconds.  See below for comparison.

On the SQL side, it's pretty calm.  There's no CPU time used to parse and compile.  This is a proc call after all.  Most CPU time is used to insert data.  One million row insertion takes 4,413 ms CPU time.  Not a whole lot of ticks and seems very reasonable to me.

One thing worth mentioning in the profiler trace is the TextData of the RPC:Completed event of the proc call.  It looks like this and is misleading:

declare @p1 dbo.myTVP

insert into @p1 values(1,-1)

insert into @p1 values(2,-2)

insert into @p1 values(3,-3)

insert into @p1 values(4,-4)

insert into @p1 values(5,-5)

......

insert into @p1 values(1000,-1000)

exec MyProc @tvp=@p1

This seems like a bunch of singleton calls  but it's not.  As my colleage Keith Elmore at Microsoft CSS pointed out, that is just the convention used to allow the data to be displayed or copied/pasted into a query window and run.  The TVP isn’t actually implemented in that way—the rows are streamed across just like a bulk insert—but it may have led to this impression that it does simple inserts.

Then there's second approach using ADO.Net to construct a SQL Dynamic TSQL.

This approach is often frowned upon for the SQL injection security concern.  It's got okay performance, compared to the first approach.  It put weights on SQL server and does not scale well.  I listed this approach as a side by side comparison with the first approach.

I am not going to elaborate much.  Basically, in ADO.Net we construct a dynamic SQL to be executed at the SQL server side.  There's not much at the client except the string concatenation.  So what kind of string we should build?  Obviously, you don't want to build a bunch of single inserts like we just saw above in the first approach.  It's running very slow.

So how about a single VALUES set with all the rows like this?

declare @p1 dbo.myTVP;

insert into @p1

select c1, c2 from (values(1,-1),(2,-2),(3,-3),......,(3000,-3000))

as alias (c1,c2)

;exec myproc @tvp=@p1

It works but can't scale.  When I try a batch size of 10,000 rows, my console app times out.  So a compromise is to build batches of 1000 rows and UNION ALL together:

declare @p1 dbo.myTVP;

insert into @p1

select c1, c2 from (values(1,-1),(2,-2),(3,-3),......,(1000,-1000))

as alias (c1,c2)

union all 

select c1, c2 from (values(1001,-1001),(1002,-1002),(1003,-1003),......,(2000,-2000))

as alias (c1,c2)

union all 

select c1, c2 from (values(2001,-2001),(2002,-2002),(2003,-2003),......,(3000,-3000))

as alias (c1,c2)

;exec myproc @tvp=@p1

The C# function to build such a string to be passed to SQL can be seen here:

    static void InsertWithDynamicSQL(int rowCount)

    {

      DateTime dt = DateTime.Now;

      StringBuilder sql = new StringBuilder("declare @p1 dbo.myTVP; insert into @p1 select c1, c2 from (values");

      for (int i = 1; i <= rowCount; i++)

      {

        sql.Append("(");

        sql.Append(i.ToString() + "," + (-i).ToString());

        sql.Append(")");

        if (i == rowCount)

        {

          sql.Append(") as alias (c1,c2)");

          break;

        }

        if (i % 1000 == 0)

          sql.Append(") as a1 (c1,c2) union all  select c1, c2 from (values");

        else

          sql.Append(",");

      }

      sql.Append(";exec myproc @tvp=@p1"); 

      SqlConnection sqlconnection = new SqlConnection("Persist Security Info=False;Integrated Security=true;Initial Catalog=DemoDB;Server=(local)");

      sqlconnection.Open();

      // Configure the SqlCommand and table-valued parameter.

      SqlCommand insertCommand = new SqlCommand(sql.ToString(), sqlconnection);

      insertCommand.CommandType = CommandType.Text;

      // Execute the command.

      insertCommand.ExecuteNonQuery();

      Console.WriteLine(DateTime.Now - dt);

    }

The approach puts a lot of pressures on the SQL side in the form of high CPU usage.  As we remember in the first approach, the CPU time used to insert one million rows into SQL is mere 4.4 seconds.  In this dynamic SQL approach, just to parse and compile a 10,000 row batch takes 4.4 seconds.  We are not even executing the batch yet!

Here's the parsing and compilation time (no execution time) for different rows.  I can't get any higher batch row number as it times out.  You get the idea of how this doesn't scale well.

While compilation is a resource (CPU) intensive operation, all the compiled execution plans are mostly used just once.  Two batches must match character by character so that the execution plan can be reused.  Since our real world data is constantly changing, it's virtually impossible to have two same batches.

Summary

I think we have a clear winner here from all perspectives.

The first approach with DataTable, DataTableReader and TVP is robust, fast and scale well.  It uses much less resource and put less strains on SQL server.  This is important for scale out.  SQL can have multiple clients all streaming data in without bringing down the database.

If you have any better solution, show it off!  Otherwise, leave a comment and let me know if this post is helpful.

Happy coding!

Mike Chang (Chien-Shen)

SQL SDE, MSDN

One of the most challenging aspects of large scale data warehouse development is the sheer immense size.  It’s common to see all sorts of problems once the data warehouse gets larger.  Common problems include performance degradation, out of storage space, long running queries, blocking and failure to keep up with data feeds.

I have compiled a list of tips that help me to manage the size effectively over the years on terabyte DW projects.  I hope they will be beneficial to you as well.   Here we go:

Keep transaction small:  The goal is to reduce blocking or even deadlocks.  In my own implementation, there's almost no usage of BEGIN TRAN...... COMMIT TRAN.  Sometimes, there's obvious place you can tweak to keep transaction small.  For example, let’s say you have a data source that contains both new dimension and fact data.   They should be able to put in two different transactions.  Now, it's not always easy to separate statements of a transaction into individual ones since it may affect the data accuracy.  For example, if you have an ETL workitem queue table where you keep track of what raw data has been processed.  To avoid double counting, the insertion into fact table and updating completion of  the workitem in the queue table are usually in the same transaction.  Separating them can still be achieved and that leads to my next tip, Fault tolerant and robust design. 

Fault tolerant and robust design:  This is a design principle that requires a different approach of schema design and implementation.  With the goal to keep transaction small and short, the goal is to only touch one table at a time.  Using the workitem queue table and fact table example again, without a transaction, the logic goes like this.

1.       Mark workitem processing start time

2.       Delete fact table if there's any row associated with the workitem

3.       Process

4.       Insert fact table with new rows from the workitem

5.       Mark workitem processing end time

The trick is on step 2 where we delete any left over, half way rows associated with the workitem in the fact table.  In normal situation, there's nothing to delete and this step is no ops.  However if there's a failure between 4 and 5, when we reprocess the same workitem, step 2 will remove the previous insertion, reprocess and insert fact table without double counting.

Putting everything in a transaction is an easy implementation and it might have passed test, integration, PPE and runs smoothly in production.  But one day after several months in production, you begin to see long blocking and even deadlocks.  The time you spent on trouble shooting can be several times more expensive than if you'd have implemented differently.  I will explain why this can happen in the next tip, Load as much data as possible in the test phase.

Load as much data as possible in the test phase:   When designed and implemented correctly, the ETL time for the same amount of raw data should remain the same.  However, it's common to see this ETL time taking longer gradually or going up to a cliff.  Common symptoms are index fragmentations, blocking and plan changes.  However they all resulted from the same root cause-- underlying data changes.  Your data may be seasonal where some values become rare or frequent and that can change the stats.  The data may grow too large to use the same access method.  Loop join in a plan can be changed to a hash or merge join.  You bottle neck can hence be interchanged among disk, memory or CPU.  The scenario goes on and on so allocate more time for you load testing and try as much data as possible during the dev/test phases.

Watch the batch size:  This is orthogonal to the first tip.  While we want to keep transaction small by avoiding touching several tables in one same transaction, we also want to make sure each transaction is limited to a manageable batch size.  Other than for the benefit of less blocking, a reasonable batch size can also help to alleviate the pressure on the log file size.

Use partitioned table: This is one of the best new SQL server features for DW development.  By using a rolling sliding window, you can effectively manage your vast amount of data.  Kimberly Tripp has done an excellent white paper on this topic at https://msdn.microsoft.com/en-us/library/ms345146(SQL.90).aspx.  The only thing I want to add is that you should make the sliding window size configurable.  When your data source grows, the DW may not be able to accommodate the same number of partitions.  Simply by decreasing the value of the partition number parameter to the procedure that manages the sliding window will get the disk space back in a split second.

Use Compression: In my application of page level compression on the fact table, I see up to 66% saving on disk space while not observing any changes in the overall performance.  Some people may even see performance increase on IO since less disk space is used to store the same amount of information.  Read more at https://msdn.microsoft.com/en-us/library/cc280449.aspx and https://msdn.microsoft.com/en-us/library/cc280464.aspx.

Use Indexed view for aggregation:  An indexed view is materialized on disk and the rollups are updated whenever the underlying fact data changes.  This feature helps to keep the rollups current without a separate process to manage or calculate the rollups.  The only thing need to be done is to define and create the indexed view.  Read more at https://msdn.microsoft.com/en-us/library/ms187864.aspx.

Design for Scale out:  Two common reasons for scaling out are for processing throughput or storage space.  Unfortunately, most people found out they need to scale out when it’s too late after months in production.  At that awkward moment, it’s going to be really hard to alleviate without a major overhaul if the system is never designed for scaling out.  So always keep scaling out in mind when you architect the DW.  For example, if your data source if file based, then it’s better to use UNC file path than local drive letter file path.  The same idea goes to your destination fact table.  It can be on different servers when scaling out.  Also, try to use procedures and avoid using base tables or views.  With the abstraction of procedure interface, the data processing or retrieving can be from different servers and the insertion of data can scale out to different locations or without breaking the interface.

It's the hottest day I ever have in Seattle with the highest temparature at around 95F. (Don't laugh, Texans :))  I heard it can be triple digit, record setting hot tomorrow.  So leave a comment if I mumble too much or if you think my head is over heated.  :)

Keep it cool and happy coding!

In this post, I will show you an easy to understand, reproducible demo that you can try it out yourself.  I will also use several performance counters to illustrate different anomalies by changing a section of the code.

Preparation:

First, let's create a simple table and a one liner scalar UDF:

create table tblDateDT     (DateID int identity(1,1) primary key, dtDate datetime)

go

declare @i   int = 0,

        @cnt int = 1000000,

        @dt  datetime = '2000-01-01'

-- Populate tblDateDT with one million rows       

while @i < @cnt

begin

   insert tblDateDT     (dtDate) values ( dateadd(day, @i, @dt) )

   select @i = @i + 1

end       

go

Create function dbo.UDF_GetLongDateString (@dtDate datetime)

returns varchar(1000)

as

begin

   return convert(varchar(1000), @dtDate, 109)

end;

Next, select the following performance counters and start a trace:

Object	Counter
Processor	% Processor Time
SQLServer:Access Methods	Index Searches/sec
SQLServer:Access Methods	Page Splits/sec
SQLServer:Transactions	Free Space in tempdb (KB)

Baseline from Perf Counter Perspective:

Let's first establish a "healthy" baseline without CPU and tempDB anomalies.  Run this simple select statement:

declare @temp table (DateID int, strDate varchar(1000), dtDate datetime)

insert @temp(DateID, strDate, dtDate)