Who is Active ? October 25, 2010
Posted by furrukhbaig in DMV's, Execution Plan, Optimize, Queries running on the server, sp_who, sp_who2, sp_whoisactive, system monitoring, Tips, XML Execution Plan.Tags: dmv, optimize, sp_who, sp_who2, sp_whoisactive, system monitoring, xml execution plan
add a comment
Adam Machanic has released new build of system monitoring stored procedure SP_WhoIsActive. Its really useful and I would like to congratulate him for his efforts.
check out the link below for his original post and to download the code.
Enjoy !!
Rowcount for Large Tables July 24, 2008
Posted by furrukhbaig in DMV's, Performance, SQL Server 2005, SQL Server 2005 features, Tips, TSQL.Tags: large tables, rowcount, rowcount scan, sys.dm_db_partition_stats
15 comments
Ever wondered why simple statements like SELECT COUNT(*) FROM [Table_Name] takes forever to return row count on large tables? Its because it uses full table scan to count number of rows. The instant way to get the row count on any table is to query new Dynamic Management Views (DMV) in SQL Server 2005 sys.dm_db_partition_stats. DMV contains row count and page counts for any table including all the partitions. Please note even you did not create partition for your table, your table still going to be created on single default partition so this will include all the tables.
Following are some useful queries that will return row count almost instantly. In SQL Server 2000 sysindexes system table is used to get the number of rows for large table to avoid full table scan.
Comments are welcome.
— All the tables having ZERO rows
— compatable with partitioned tables
SELECT
Table_Name = object_name(object_id),
Total_Rows = SUM(st.row_count)
FROM
sys.dm_db_partition_stats st
GROUP BY
object_name(object_id)
HAVING
SUM(st.row_count) = 0
ORDER BY
object_name(object_id)
— Row Count without doing full table Scan
— This will include provide total number of rows in all partition (if table is partitioned)
SELECT
Total_Rows= SUM(st.row_count)
FROM
sys.dm_db_partition_stats st
WHERE
object_name(object_id) = ‘Your_Table_Name_Goes_Here’
AND (index_id < 2) — Only Heap or clustered index
Find out whats running on SQL Server 2005 December 13, 2007
Posted by furrukhbaig in DMV's, Execution Plan, Optimize, Performance, Performance Tuning, Profiler, Queries running on the server, SQL Server 2005, SQL Server 2005 features, XML Execution Plan.Tags: dmv, execution plan, profiler, queries running on server, whats running on sql server
2 comments
Everyone wants to know whats running on the box. Specially if your job is to stabalise server you always concern what is killing the box.
A Friend of mine has published very usefull post with scripts to find out whats running on the SQL Server with their execution plan.
http://www.proteanit.com/b/2007/01/22/a-useful-script-to-analyse-current-activity-on-your-box/
The same can also be managed if you run profiler and capture XML execution plan which is not always possible due to security issue and overhead of profiler itself.
Index Fragmentation and dm_db_index_physical_stats December 12, 2007
Posted by furrukhbaig in DMV's, dm_db_index_physical_stats, Fragmentation, Index Fragmentation, Index tuning, Index usefulness, Indexes, Optimize, Performance, Performance Tuning, SQL Server 2005, SQL Server 2005 features, Tips.Tags: clustered on business key, compound clustered index fragmentation, dm_db_index_physical_stats, fillfactor, find out fragmentation, index fragmentation, sql server fragmentation
1 comment so far
Fragmentation can cause serious performance issues and its vital to understand how this can impact performance before I tell you how to fix it.
Fragmentation can cause slow running queries due to more disk IO then usual which itself cause by page spliting. Fragmentation not only cause query performance it can also slow down write operation such as INSERT, DELETE and UPDATE.
SQL Server write data on 8k data pages. This limit can be reached very quickly, for wide tables storing lots of varchar/nvarchar columns (nvarchar take 2 bytes to store 1 character), will cause request for more data pages. When SQL Sever uses whole page then it occupy another page to store more data. If table has got cluster index then data needs to be stored in sorted order as cluster index ensure physical order of data according to the cluster key and thats why you can only have one clustered index per table.
Now assume you have compound clustered index on CountryID and CustomerNo colums on a transactional table which recieve 10 transactions per minute for an online car rental portal. Clustered index will make sure that data is stored in sorted order on CountryID and CustomerNo. Having millions of rows in table consider what will happen when you recieve transaction row which needs to be inserted on page 1 (CountryId = 1, CustomerId = 100) . Above will require to make some room on 1st data page (depending on FILLFACTOR, default is 100%). If require data page has not got enough room for the row to fit then rows on the data pages needs to be move forward (called PageSplit) in order to make some room for new row to fit on page in sorted order. This can cause lot of page split and fragmentation as new pages required (caused by page splits on existing data pages) can not be guarantee to be in sequence with other page. This can seriously hurt performance for data modification (due to pagesplit) and data read (due to out of order pages) operations.
dm_db_index_physical_stats can be used to check fragmentation.
SELECT * FROM sys.dm_db_index_physical_stats(DB_ID(N’YourDB’), OBJECT_ID(N’dbo.CarRental’), NULL, NULL , ‘DETAILED’);
The above SQL will return fragmentation information for given Database name (Parameter 1) and Table Name (Parameter 2). Last parameter suggest the mode of analysis.
It is good practice to create clustered indexes on incrementing value (e.g. IDENTITY) to avoid page splits and out of order pages.
INDEX / Statistics Age August 17, 2007
Posted by furrukhbaig in DMV's, Indexes, Performance, SQL Server 2005, TSQL.2 comments
When I was working with a major cable provider in UK I had a task to tune performance of a billing engine that runs over night and produced millions of rows in tables and suddenly start taking more then double time to finish.But after struggling many hours to find out why index has not been selected by optimizer I realized that optimizer has old statistics for that index that does not represent the current state of data and therefore stats needs to be updated. Production DBAs has disabled the index rebuild job by mistake that runs after billing engine inserts millions of rows. I often heard from production DBA that they don’t have enough overnight window to rebuild indexes. Which makes database developer’s life misery in fixing performance without realizing that statistics are not up-to-date. I have experienced significant performance difference after updating statistics or rebuilding indexes.
Always check your index age before start looking into execution plan. Here is some very handy query to find out age of index / statistics. Replace Table_Name with your table name.
SELECT ‘Index Name’ = ind.name, ‘Statistics Date’ = STATS_DATE(ind.object_id, ind.index_id) FROM SYS.INDEXES ind WHERE OBJECT_NAME(ind.object_id) = ‘Table_Name’
SEEK is better then SCAN August 17, 2007
Posted by furrukhbaig in DMV's, dm_db_index_physical_stats, dm_db_index_usage_stats, Execution Plan, Index tuning, Index usefulness, Indexes, Optimize, Performance, Performance Tuning, Query hint, SEEK vs Scan, SQL Server 2005, SQL Server 2005 features, TSQL, XML Execution Plan.add a comment
I have been involved in performance tuning for several databases and usually come across a situation where indexes has been created but due to poorly written SQL Code those indexes are not utilized or badly used by optimizer. To find out how optimizer using your index use query below. This will provide you the frequency optimizer is uses SEEK, SCAN and LOOKUP operation on indexes.
As a rule of thumb SEEK is better then SCAN. But there are few scenarios where SCAN operator perform better then SEEK specially when large number of rows are expected to return by operation.
SELECT Table_Name = OBJECT_NAME(usg.object_id), ind.name, usg.user_seeks, user_scans, user_lookups, last_user_seek, last_user_scan, last_user_lookup FROM sys.dm_db_index_usage_stats usg INNER JOIN sys.indexes ind ON usg.object_id = ind.object_id AND usg.index_id = ind.index_id WHERE — Your table list goes here OBJECT_NAME(usg.object_id) IN ( ‘Table_Name1’, ‘Table_Name2’ ) ORDER BY Table_Name
Is this Index useful ? August 17, 2007
Posted by furrukhbaig in DMV's, dm_db_index_usage_stats, Index tuning, Index usefulness, Indexes, Optimize, Performance, Performance Tuning, SQL Server 2005, SQL Server 2005 features, TSQL.Tags: dmv, dm_db_index_usage_stats, index usage, indexes, Performance Tuning, sql 2012 indexes, sql server 2005, SQL server 2008 R2, sql server 2012, sql tips
1 comment so far
Creating indexes on tables always been a tricky question. Creating a index does not mean that optimizer will use that index to solve queries. SQL Server 2005 introduced a dynamic management view sys.dm_db_index_usage_stats to capture the use of indexes by SELECT, INSERT, UPDATE and DELETE. Thus any index or table which does not exists in this view is overhead to system and not useful.
Following query will return all the indexes and tables which never get used by SQL Server since the service started. The best way to check is to create index and run the data work load or regression test that should make use of all indexes and run following query.see full article on SQL Server Customer Advisory Team (CAT) How can SQL Server 2005 help me evaluate and manage indexes
SELECT ObjectName = OBJECT_NAME(ind.object_id), IndexName = ind.name FROM Sys.Indexes ind INNER JOIN Sys.Objects obj ON obj.object_id = ind.object_id WHERE OBJECTPROPERTY(obj.object_id,‘IsUserTable’) = 1 AND NOT EXISTS ( SELECT 1 FROM Sys.dm_db_index_usage_stats usg WHERE usg.object_id = ind.object_id AND usg.index_id = ind.index_id AND ind.index_id = usg.index_id ) ORDER BY ObjectName, IndexNameWorst Performing Queries August 17, 2007
Posted by furrukhbaig in DMV's, Indexes, Performance, SQL Server 2005, TSQL.Tags: dmv, dm_exec_query_stats, Performance Tuning, query performance, query tuning, TSQL, worst performing query
8 comments
I have been looking for a easy way to find worst performing queries without runing Profiler and I come across very interesting DMV’s dm_exec_query_stats and dm_exec_sql_text.Microsoft has introduced Dynamic Management Views (sys.dm_exec_query_stats, sys.dm_exec_sql_text) in SQL Server 2005 which provide a way to fetch information related to resources used by SQL Server for executing SQL statements.
Following query will return TOP 100 worst performing SQL Statement with the name of object that contain those statements e.g. Stored Procedure, Trigger and Function. Current database context will be used so change the database before executing query. The result will be sorted by CPU time in descending order.
SELECT TOP 100 [Object_Name] = object_name(st.objectid), creation_time, last_execution_time, total_cpu_time = total_worker_time / 1000, avg_cpu_time = (total_worker_time / execution_count) / 1000, min_cpu_time = min_worker_time / 1000, max_cpu_time = max_worker_time / 1000, last_cpu_time = last_worker_time / 1000, total_time_elapsed = total_elapsed_time / 1000 , avg_time_elapsed = (total_elapsed_time / execution_count) / 1000, min_time_elapsed = min_elapsed_time / 1000, max_time_elapsed = max_elapsed_time / 1000, avg_physical_reads = total_physical_reads / execution_count, avg_logical_reads = total_logical_reads / execution_count, execution_count, SUBSTRING(st.text, (qs.statement_start_offset/2) + 1, ( ( CASE statement_end_offset WHEN –1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END – qs.statement_start_offset ) /2 ) + 1 ) as statement_text FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st WHERE Object_Name(st.objectid) IS NOT NULL AND st.dbid = DB_ID() ORDER BY db_name(st.dbid), total_worker_time / execution_count DESC