Tuesday, August 12, 2014


ipconfig /release
ipconfig /flushdns
ipconfig /renew

Friday, July 25, 2014

Optimizing SQL Server CPU Performance.

Performance Counter Counter Object Threshold Notes
% Processor Time Processor > 80% Potential causes include memory pressure, low query plan reuse, non-optimized queries.
Context Switches/sec System > 5000 x processors Potential causes include other applications on the server, more than one instance of SQL Server running on the same server, hyper-threading turned on.
Processor Queue Length System > 5 x processors Potential causes include other applications on the server, high compilations or recompilations, more than one instance of SQL Server running on the same server.
Compilations/sec SQLServer:SQL Statistics Trend Compare to Batch Requests/sec.
Re-Compilations/sec SQLServer:SQL Statistics Trend Compare to Batch Requests/sec.
Batch Request/sec SQLServer:SQL Statistics Trend Compare with the Compilation and Re-Compilations per second.
Page Life Expectancy SQLServer:Buffer Manager < 300 Potential for memory pressure.
Lazy Writes/sec SQLServer:Buffer Manager Trend Potential for large data cache flushes or memory pressure.
Checkpoints/sec SQLServer:Buffer Manager Trend Evaluate checkpoints against PLE and Lazy Writes/sec.
Cache Hit Ratio: SQL Plans SQLServer:Plan Cache < 70% Indicates low plan reuse.
Buffer Cache Hit Ratio SQLServer:Buffer Manager < 97% Potential for memory pressure.

Wednesday, July 9, 2014

Logical Read Vs Physical Read along with Buffer Hit Ratio.

Logical Reads: Reading data pages from Cache.
Physical Reads: Reading Data Pages from Hard Disk
Buffer Cache Hit Ratio: (logical reads-Physical Reads)/logical read*100%
Logical Reads:  Logical read indicates total number of data pages needed to be accessed from data cache to process a query. It is very possible that logical read will access the same data pages many times. So count of logical read value may be higher than actual number of pages in a table. Usually the best way to reduce logical read is to apply correct index or to rewrite the query.
Physical Reads: Physical read indicates the total number of pages that are read from disk. In case no data in data cache, the physical read will be equal to number of logical read. And usually it happens for first query request. And for subsequent same query request the number will be substantially decreased because the data pages have been in the data cache.
Buffer Cache Hit Ratio:  Buffer hit ratio will be calculated based on these two kinds of read as the following formula:
(Logical Reads-Physical Reads)/logical read*100%
The High Buffer hit ratio (if possible near to 100%) indicates good database performance on SQL Server level. So use information from Physical read and Buffer hit ratio to measure performance in server level and logical read to measure individual Query level.
Excess of the logical reads tends high memory usage. There are some ways by which we can reduce logical reads
1)      Improper/Useless/Insufficient Indexes:   Indexes should be built on the basis of data access or retrieval process if any of the indexes is built on the columns which are not used in a query will lead to High logical reads and will degrade the performance while reads and writing the data.
2)      Poor Fill Factor/Page Density:  Page use should not be very less .Otherwise large number of page will be used for small amount of data which will also leads to High Logical Reads
3)      Wide Indexes:  Indexing on the large number columns will lead to High logical Reads
4)       Index Scanning:  If a Query is leads to index scanning on the table then logical reads will be high.
How to get the Logical Read Count?
      Below are the ways to check logical Reads
2)  SYS.DM_EXEC_QUERY_STATS:  By executing the below statements we can find detailed info about read and write
SELECT * FROM sys.dm_exec_query_stats
3) SQL Profiler:  By executing the sql profiler on that database we can find out logical reads
There are also some other DMV’s which will aslo help us to get logical reads

Monday, January 13, 2014

"Log On Error"

Some times we my get "Log on Error" while we are trying to start the SQL Services.You can find the below error while you are trying to start "SQL Server Agent".And the reason would be we will periodically change the password for Windows.If we change the password for windows and if we did not change it to SQL Service. We may encounter this problem.So if we change the password for SQL Service similar to windows password then this problem would resolve.

Tuesday, December 17, 2013

Analyzing sys.dm_os_wait_stats

The below link is explaining about the "Wait Stats" of SQL Server which was described by Paul Randal.

Analyzing sys.dm_os_wait_stats

Monday, December 16, 2013

Analyzing sys.dm_db_index_physical_stats results.

In this post i am analyzing the "sys.dm_db_index_physical_stats" results by with some production data.
By seeing this we can come to below conclusions.
First condition is
1) Focus on those rows which has page_count >1000 on those rows you can come to below conclusions.

If fragmentation(avg_fragmentation_in_percent) is less than 5 % (avg_fragmentation_in_percent)--> Leave as it is
If fragmentation(avg_fragmentation_in_percent) is more than 5 % and less than 30% - Reorganize the index
If fragmentation(avg_fragmentation_in_percent) is more than 30% - Rebuild index
and PageDencity we can caculated based on "avg_page_space_used_in_percent" column but here it is very good and it nearly 80 percent. You have to check for those columns which has page_count is >1000

Monday, December 9, 2013

What is Sleeping/Awaiting Command Session

A session with the status of Sleeping/awaiting command is simply client connection with no active query to the sql server.The table below shows transitions from "running" to "sleeping" states for a session.

The question usually around a session that is holding locks and its state is sleeping/Awaiting command.If the client has a open transaction and the client did not submit Commit or Rollback command the state is showing as Sleeping/Awaiting command.

We can examine this by running the below query. Open a new query window in AdventureWorks database. And run the below query.
Now go to another window run the below query and see the state. It is in Sleeping mode.

Giving some more in depth explanation about :
A thread is using the CPU (called RUNNING) until it needs to wait for a resource. It then moves to an unordered list of threads that are SUSPENDED. In the meantime, the next thread on the FIFO (first-in-first-out) queue of threads waiting for the CPU (called being RUNNABLE) is given the CPU and becomes RUNNING. If a thread on the SUSPENDED list is notified that it’s resource is available, it becomes RUNNABLE and is put on the bottom of the RUNNABLE queue. Threads continue this clockwise movement from RUNNING to SUSPENDED to RUNNABLE to RUNNING again until the task is completed. You can see processes in these states using the sys.dm_exec_requests DMV.