When searching for resource-intensive queries, we can use the sys.dm_exec_query_stats and sys.dm_exec_requests.

These dynamic management views already where introduced in SQL server 2005.
In SQL Server 2008 there are a couple of columns added to the sys.dm_exec_query_stats and sys.dm_exec_requests - The query_hash and the query_plan_hash column.

By using these columns we can find and tune similar queries that collectively consume significant system resources, and help determine the aggregate resource usage for similar queries and similar query execution plans.

First let’s look at the following queries:

use AdventureWorks
go
SELECT SOD.ProductID ,
sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount
FROM Sales.SalesOrderHeader SOH
JOIN Sales.SalesOrderDetail SOD
   ON SOH.SalesOrderID = SOD.SalesOrderID
JOIN Production.Product P
   ON P.ProductID = SOD.ProductID
WHERE SOH.CustomerID = 520
AND SOD.OrderQty > 10
GROUP BY SOD.ProductID;
go

SELECT SOD.ProductID ,sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount
FROM Sales.SalesOrderHeader SOH
JOIN Sales.SalesOrderDetail SOD
   ON SOH.SalesOrderID = SOD.SalesOrderID
JOIN Production.Product P
   ON P.ProductID = SOD.ProductID
WHERE SOH.CustomerID = 523
AND SOD.OrderQty > 10
GROUP BY SOD.ProductID;
go

These queries are only different in the constant value supplied for the CustomerID column; Now let’s look at the Query_Hash values of this both queries:

SELECT st.text AS "Query Text", qs.query_hash AS "Query Hash"
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text (qs.sql_handle) st
WHERE st.text ='SELECT SOD.ProductID ,sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount FROM Sales.SalesOrderHeader SOH JOIN Sales.SalesOrderDetail SOD    ON SOH.SalesOrderID = SOD.SalesOrderID JOIN Production.Product P    ON P.ProductID = SOD.ProductID WHERE SOH.CustomerID = 520 AND SOD.OrderQty > 10 GROUP BY SOD.ProductID;'
OR st.text = ' SELECT SOD.ProductID ,sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount FROM Sales.SalesOrderHeader SOH JOIN Sales.SalesOrderDetail SOD    ON SOH.SalesOrderID = SOD.SalesOrderID JOIN Production.Product P    ON P.ProductID = SOD.ProductID WHERE SOH.CustomerID = 523 AND SOD.OrderQty > 10 GROUP BY SOD.ProductID;'

We can see that although these queries’ text does not exactly match, sql server 2008 identifies these queries as having the same structure and therefore have the same hash values. This gives a significant advantage to help us identifying similar queries. We can for instance use this information to find which queries would benefit from using parameterization to improve performance. For example, let’s change the logic of the queries:

use AdventureWorks
go
SELECT SOD.ProductID , sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount
FROM Sales.SalesOrderHeader SOH
JOIN Sales.SalesOrderDetail SOD
   ON SOH.SalesOrderID = SOD.SalesOrderID
JOIN Production.Product P
   on P.ProductID = SOD.ProductID
WHERE SOH.CustomerID = 520
AND SOD.OrderQty > 10
GROUP BY SOD.ProductID;
go
SELECT  SOD.ProductID , sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount
from Sales.SalesOrderHeader SOH
join Sales.SalesOrderDetail SOD
   on SOH.SalesOrderID = SOD.SalesOrderID
Join Production.Product P
   on P.ProductID = SOD.ProductID
where SOH.CustomerID = 523
OR SOD.OrderQty > 10
GROUP BY SOD.ProductID;

go

Now, let’s find out the query hash for these two queries:

SELECT st.text AS "Query Text", qs.query_hash AS "Query Hash"
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text (qs.sql_handle) st
WHERE st.text ='SELECT SOD.ProductID , sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount FROM Sales.SalesOrderHeader SOH JOIN Sales.SalesOrderDetail SOD    ON SOH.SalesOrderID = SOD.SalesOrderID JOIN Production.Product P    ON P.ProductID = SOD.ProductID WHERE SOH.CustomerID = 520 AND SOD.OrderQty > 10 GROUP BY SOD.ProductID;'
OR st.text = 'SELECT SOD.ProductID , sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount from Sales.SalesOrderHeader SOH join Sales.SalesOrderDetail SOD    ON SOH.SalesOrderID = SOD.SalesOrderID JOIN Production.Product P    ON P.ProductID = SOD.ProductID WHERE SOH.CustomerID = 523 OR SOD.OrderQty > 10 GROUP BY SOD.ProductID;' 

We see that these 2 queries has different query hashes, so they to do not share the same logic. Now let us examine the query plan hash column, how can we use this column to find performance issues? Consider that you have similar queries like we have seen, but somehow they do not have the same query plan, this sometimes indicates a performance problem; Let’s examine the following example (from SQL 2008 BOL):

USE AdventureWorks;
GO
SET STATISTICS XML ON;

SELECT T.TransactionID, T.TransactionDate, P.ProductID, P.Name
FROM Production.TransactionHistory T
JOIN Production.Product P
   ON T.ProductID = P.ProductID
WHERE P.ProductID = 1;
GO

SELECT T.TransactionID, T.TransactionDate, P.ProductID, P.Name
FROM Production.TransactionHistory T
JOIN Production.Product P
   ON T.ProductID = P.ProductID
WHERE P.ProductID = 3;
GO

SET STATISTICS XML OFF;
GO 

If you examine the query’s plan you will see that they are different, although the query hashes are the same because we just changed the value for the ProductID column.

SELECT ST.text AS "Query Text",QS.query_plan_hash ,QP.query_plan
FROM sys.dm_exec_query_stats QS
CROSS APPLY sys.dm_exec_sql_text (QS.sql_handle) ST
CROSS APPLY sys.dm_exec_query_plan(QS.plan_handle) QP
WHERE ST.text = 'SELECT T.TransactionID, T.TransactionDate, P.ProductID, P.Name FROM Production.TransactionHistory T JOIN Production.Product P ON T.ProductID = P.ProductID WHERE P.ProductID = 1;'
OR ST.text = 'SELECT T.TransactionID, T.TransactionDate, P.ProductID, P.Name FROM Production.TransactionHistory T JOIN Production.Product P    ON T.ProductID = P.ProductID WHERE P.ProductID = 3;'; 

Below you can find a query to find similar queries with differnat query plans, in order to find the cost of each distinct query plan,we will use Xquery on the Query Plan Xml Column :

SELECT max([QueryText]) QueryText , max(SimilarQueries.query_plan.value('(//@StatementSubTreeCost)[1]','float')) QueryCost
FROM (SELECT QS1.*,ST.text AS QueryText,QP1.query_plan
      FROM sys.dm_exec_query_stats QS1
      CROSS APPLY sys.dm_exec_sql_text (QS1.sql_handle) ST
      CROSS APPLY sys.dm_exec_query_plan(QS1.plan_handle) QP1
      JOIN sys.dm_exec_query_stats QS2
         ON QS1.query_hash = QS2.query_hash
      WHERE QS1.query_plan_hash <> QS2.query_plan_hash ) as SimilarQueries
GROUP BY SimilarQueries.query_plan_hash
ORDER BY 1 

We can determine that the second query plan is more costly. it will be much nicer if we can get in the same result set the Xml Query Plan itself; this requires some TSQL juggling around, since the XML data type cannot be used in a group by or with an aggregation function.

SELECT QueryText ,QueryCost,QP.query_plan QueryPlan
FROM (select max(QueryText) QueryText ,max(SimilarQueries.query_plan.value('(//@StatementSubTreeCost)[1]','float')) QueryCost ,max(plan_handle) plan_handle
      FROM  (SELECT QS1.*,ST.text AS QueryText,QP1.query_plan
             FROM sys.dm_exec_query_stats QS1
             CROSS APPLY sys.dm_exec_sql_text (QS1.sql_handle) ST
             CROSS APPLY sys.dm_exec_query_plan(QS1.plan_handle) QP1
             JOIN sys.dm_exec_query_stats QS2
                on QS1.query_hash = QS2.query_hash
             WHERE where QS1.query_plan_hash <> QS2.query_plan_hash ) as SimilarQueries
     GROUP BY SimilarQueries.query_plan_hash) SimilarQueriesCost
CROSS APPLY sys.dm_exec_query_plan(plan_handle) QP
ORDER BY 1

In SQL 2008 Management Studio when we will click the Query Plan Xml Column you will immediately get the graphical representation of the query plan, this enables us to examine immediately the execution plan of the costly query plans.

• TRUNCATE
• DELETE

The two commands achieve the same result; however, each of the commands acts a little bit different. Each of the two commands have advantages, limitations, and consequences, which have to be considered when deciding which method to use.

In this post we will concentrate in one aspect of these commands usage – the ability to rollback each operation.

DELETE statements delete rows one at a time, logging each row in the transaction log and maintaining the log sequence number (LSN) information.
Even though it will consumes more database resources, it comes in handy as these transactions can be rolled back if necessary by using the log files, when the recovery model of the database is set to full.

But what happens when you issue the TRUNCATE command?

The TRUNCATE statement is much faster statement than the DELETE command.
It deletes all records in a table by deallocating the data pages used to store the table’s data. This operation has a limited logging in the transaction log (only the page deallocations are recorded in the transaction log). In addition fewer locks are acquired with this statement in compare to the DELETE statement.
As a result of the above it is commonly believed that records removed by the TRUNCATE statement cannot be restored – rolled back.

It is true in most cases, however DELETE and TRUNCATE can both be rolled back when they are executed inside a ‘BEGIN TRANSACTION’ block and the current session has not yet ended.
In other words, when the TRUNCATE statement has not been committed yet, it can be rolled back

The following code demonstrates a scenario when a TRUNCATE can be rolled back for that particular session.

--Creating a testTable for the demonstration
CREATE TABLE TESTTABLE (ID INT)

--Inserting rows into the testTable.
INSERT INTO TESTTABLE
SELECT TOP 1000 OBJECT_ID FROM SYS.OBJECTS
BEGIN TRAN
   --Truncating the table
   TRUNCATE TABLE TESTTABLE
   --No rows will return
   SELECT * FROM TESTTABLE
ROLLBACK

--The original rows from testTable will return
SELECT * FROM TESTTABLE

--Dropping the testTable.
DROP TABLE TESTTABLE

To summarize,
DELETE can always be rolled back-

• When the recovery model of the database is set to SIMPLE, the statement can be rolled back – when the statement is executed inside a ‘BEGIN TRANSACTION’ block.
• When the recovery model of the database is set to FULL, the statement can also be recovered from the log files.

TRUNCATE can or cannot be rolled back, depends if it is executed from within a ‘BEGIN TRANSACTION’ block.

(I have written it for SQL 2005 but I guess it runs both on 2000 and 2008 versions)

declare @startupDate datetime
,		@days bigint
,		@hours bigint
,		@minutes bigint
,		@seconds bigint

select	@startupDate = CrDate
,		@seconds = DateDiff(second, CrDate, getdate())
,		@days = @seconds/60/60/24
,		@seconds = @seconds - (@days*60*60*24)
,		@hours = @seconds/60/60
,		@seconds = @seconds - (@hours*60*60)
,		@minutes = @seconds/60
,		@seconds = @seconds - (@minutes*60)

from	sysdatabases (nolock)
where	[name] = 'TempDb'

select	@startupDate startup_time
,		cast(@days as varchar) + ' days ' +
		case when @hours < 10 then '0' else '' end + cast(@hours as varchar) + ':' +
		case when @minutes < 10 then '0' else '' end + cast(@minutes as varchar) + ':' +
		case when @seconds < 10 then '0' else '' end + cast(@seconds as varchar)
		as online_duration

You can use this query to determine which indexes are used only lightly by your applications. You can also use the query to determine which indexes are incurring maintenance overhead. You may want to consider dropping indexes that incur maintenance overhead, but are not used for queries, or are only infrequently used for queries.

The query is based on the DMV sys.dm_db_index_usage_stats. The counters in the view are initialized to empty whenever the SQL Server (MSSQLSERVER) service is started.

Every individual seek, scan, lookup, or update on the specified index by one query or DML execution is counted as a use of that index and increments the corresponding counter in this view.
The index information is gathered both for user operations (e.g. submitted queries), and for internal operations (e.g. scans for gathering statistics).

SELECT
sys.objects.name AS object_name,
sys.indexes.name AS index_name,
case
when (is_unique = 1 and is_primary_key = 1) then 'PK UNIQUE '
when is_unique = 1  then 'UNIQUE '
else ''
end + sys.indexes.type_desc type_desc,
c.index_columns AS index_columns_key,
sys.dm_db_index_usage_stats.user_seeks,
sys.dm_db_index_usage_stats.user_scans,
sys.dm_db_index_usage_stats.user_lookups,
sys.dm_db_index_usage_stats.user_updates,
sys.dm_db_index_usage_stats.last_user_seek,
sys.dm_db_index_usage_stats.last_user_scan,
sys.dm_db_index_usage_stats.last_user_lookup,
sys.dm_db_index_usage_stats.last_user_update
FROM sys.objects
JOIN sys.indexes
ON sys.indexes.object_id=sys.objects.object_id
JOIN
(SELECT distinct
object_id,
index_id,
stuff((SELECT ','+col_name(object_id,column_id ) as 'data()'
FROM sys.index_columns t2
WHERE t1.object_id =t2.object_id
and t1.index_id = t2.index_id
FOR XML PATH ('')),1,1,'') as 'index_columns'
FROM sys.index_columns t1
) c
ON c.index_id = sys.indexes.index_id
AND c.object_id = sys.indexes.object_id
LEFT OUTER JOIN sys.dm_db_index_usage_stats
ON sys.indexes.index_id=sys.dm_db_index_usage_stats.index_id
AND sys.indexes.object_id=sys.dm_db_index_usage_stats.object_id
AND (
(sys.dm_db_index_usage_stats.user_seeks is null)
OR  (
( sys.dm_db_index_usage_stats.user_seeks < 100 )
AND ( sys.dm_db_index_usage_stats.user_scans < 100 )
AND ( sys.dm_db_index_usage_stats.user_lookups < 100 )
)
)
WHERE sys.objects.type='u'                 --Only UserTables will be selected
AND sys.indexes.type_desc  <> 'HEAP'       --Only indexes will appear, not HEAP tables
--AND sys.objects.name = ''                --In case you would like to monitor only a specific table, put the table name
ORDER BY 1

Information about the main columns in this DMV:

User Seeks: the number of times the index has been used by a user query in a seek operation (one specific row)

User Scans: the number of times the index has been used by scanning the leaf pages of the index for data

User Lookup: for clustered indexes only, this is the number of times the index has been used in a “bookmark lookup” to fetch the full row. This is because non-clustered indexes use the clustered indexes key as the pointer to the base row

This depends on how we add the column.
We have four different options to add a new column to an existing table:

• Adding a nullable column with no default value – in this case the column will be added to the table, and will be null in all existing rows.
• Adding a “no null” column without default value – this option will return an error. Existing rows will have null value in the new column and this is not legal. In order to add this type of column is to add a nullable column, update all the rows to have values for this column, and then change it to “not null”.
• Adding a “nullable” column with default value – in this case, existing rows will have null for this column, but new rows will get the default value.
• Adding a “no null” column with default value-after adding this type of column, existing rows will get the default value for this column and it will be not null.

Adding a column as described in one of the first 3 options will complete quickly, as only the definition of the table changes.
We have to be careful when using the last option will. Adding a column as described in the last option will implicitly cause an update of all the existing rows in the table and may take a long time to complete.

Transaction log files are copied from the production SQL server, and then restoring them onto a standby server. But this is not all. The key feature of log shipping is that is will automatically backup transaction logs throughout the day (for whatever interval you specify) and automatically restore them on the standby server. This in effect keeps the two SQL Servers in “synch”. Should the production server fail, all you have to do is point the users to the new server, and you are all set. Well, its not really that easy, but it comes close if you put enough effort into your log shipping setup.