Labels

Showing posts with label Performance Tuning. Show all posts
Showing posts with label Performance Tuning. Show all posts

Saturday, 16 September 2017

SQL Server Performance Tuning Part 6

Below are the few setting in SQL Server that can improve the performance of your queries.

Ø  Statistics Update – enables the optimizer to create better execution plans
Ø  Tempdb Configuration – improves concurrency
Ø  Max Degree of Parallelism(MAXDOP) – improves query performance
Ø  Cost Threshold for Parallelism - improves query performance
Ø  Instant File Initialization – faster file growth  
Ø  Optimize for Ad Hoc Workloads – reduces cached plan bloat  
Ø  Memory Configuration – how much memory to give to SQL Server
Ø  Lock Pages in Memory – prevents swapping to disk
Ø  Query Governor Cost Limit - allows resources to be shared fairly 
  
Counters from Perfmon :

Ø  Page Reads/​Sec – indicates time spent reading data
Ø  Page Writes/​Sec -indicates time spent writing data
Ø  Page Life Expectancy - how long data lives in cache
Ø  Buffer Cache Hit Ratio – is data coming from cache or disk
Ø  % Processor Time – CPU usage
Ø  Processor Queue Length – waiting on CPU
Ø  Locks – indicates reduced concurrency

DMV’s : 

Ø  sys.​dm_​io_​virtual_​file_​stats – IO and wait information
Ø  sys.​dm_​db_​index_​usage_​stats – how a table/index is used
Ø  sys.​dm_​exec_​query_​stats – records time, IO, CPU etc used by queries
Ø  sys.​dm_​os_​sys_​info – OS information e.g. CPU count, server memory  

Tuesday, 14 March 2017

Where to start performance tuning in SQLServer

There is no special area to start debugging the issue in SQL Server.

Refer the below screens shots for quick idea.
















Monday, 17 October 2016

Troubleshooting CXPACKET wait type in SQL Server

The CXPACKET term came from Class Exchange Packet, This can be described as data rows exchanged among two parallel threads that are the part of a single process. One thread is the “producer thread” and another thread is the “consumer thread”. This wait type is directly related to parallelism and it occurs in SQL Server whenever SQL Server executes a query using parallel plan.

You may consider lowering the degree of parallelism if contention on this wait type becomes a problem.

For more details please refer.


Friday, 23 September 2016

Common Significant Wait types with BOL explanations

                                                          WaitTypes 

Network Related Waits

       ASYNC_NETWORK_IO :Occurs on network writes when the task is blocked behind the network

 Locking Waits

1. LCK_M_IX: Occurs when a task is waiting to acquire an Intent Exclusive (IX) lock.

2. LCK_M_IU: Occurs when a task is waiting to acquire an Intent Update (IU) lock.

3. LCK_M_S: Occurs when a task is waiting to acquire a Shared lock.

I/O Related Waits

1.ASYNC_IO_COMPLETION: Occurs when a task is waiting for I/Os to finish.

2. IO_COMPLETION: Occurs while waiting for I/O operations to complete.              This wait type generally represents non-data page I/Os. Data page I/O completion waits appear  as

 PAGEIOLATCH waits

3. PAGEIOLATCH_SH:Occurs when a task is waiting on a latch for a buffer that is in an I/O request. The latch request is in Shared mode. Long waits may indicate problems with the disk subsystem.

4. PAGEIOLATCH_EX:Occurs when a task is waiting on a latch for a buffer that is in an I/O request.  The latch request is in Exclusive mode. Long waits may indicate problems with the disk subsystem.

5. WRITELOG : Occurs while waiting for a log flush to complete. Common operations that cause log flushes are checkpoints and transaction commits.

6. PAGELATCH_EX: Occurs when a task is waiting on a latch for a buffer that is not in an I/O request. The latch request is in Exclusive mode.

7. BACKUPIO:Occurs when a backup task is waiting for data, or is waiting for a buffer in which to store data

CPU Related Waits

1. SOS_SCHEDULER_YIELD:  Occurs when a task voluntarily yields the scheduler for other tasks to execute. During this wait the task is waiting for its quantum to be renewed.
2. THREAD POOL : Occurs when a task is waiting for a worker to run on.
  This can indicate that the maximum worker setting is too low, or that batch executions are taking  unusually long, thus reducing the number of workers available to satisfy other batches.
3. CX_PACKET: Occurs when trying to synchronize the query processor exchange iterator .You may consider lowering the degree of parallelism if contention on this wait type becomes a problem.

Tuesday, 7 June 2016

SQL Server Performance Tuning Part 5

                                                   LOCKS

Locks:

 SQL Server holds a specific object (tables, database, pages, rows, instance, extent, key……etc) by using this locking concept.

 Locks are very useful to provide consistence data or right data or correct data to the end user
 SQL Server cannot lock the resources.

Note: Lock internally managed by lock manager and takes the decision depend on the transaction what lock to be applied.

LOCK RESOURCES:

ROW LEVEL:  Row identifier used to lock a single row with in a table.

PAGE LEVEL:  8 kilo bytes (kb) data pages or index pages.

(The page is nothing but the fundamental unit of data storage in SQL Server where actual data present)

EXTENT LEVEL: Contiguous group of eight data pages or index pages.

( An extent is a collection of eight physical contiguous pages. )

TABLE LEVEL:  Entire table including all data index.

DATABASE LEVEL: Database

KEY LEVEL: row lock with in an index used to product key ranges in serializable transaction.


How to find locks:

SP_LOCK
       
OR

SELECT FROM SYS.DM_TRAN_LOCKS
               
Output Columns:

Resource type [Database or Page or Object or Row or Extentor table]

Request mode [Lock type]

Request type

Request status [Grant or Wait]

Request Session id

How will u find out which session is doing what work?

SP_WHO2

TYPES OF LOCKS:

1. Shared lock[S]: Multiple users can able to read the data on specific resource. No transaction or query need to wait.
 When transaction starts internally lock manager applies shared lock and once reading completed lock revoked automatically.

2. Exclusive Lock[X]: When we perform any insert and delete operations then an exclusive lock (X) will be placed on the resource.

Note: Always lock manager gives the priority to DML operations compare to any select queries.

3. Update Lock [U]: Whenever we perform any update operations then update lock placed in SQL Server.

Update lock calls most of the time exclusive lock (X) by lock manager.

4. Schema Lock (SCH-L): When performing any locks at schema table then lock manager raise Schema level lock.

5. Bulk Update [BU]: Bulk update lock generally placed by lock manager when there are any bulk transactions.

Ex: Insert into, bulk into, select into

6. Intent lock: Indented to apply desired lock on a  particular lock.

3 Types:

1Intent Shared [IS] -- Indented to read the data
2. Intent Exclusive [IX] -- Intended to write the data

3. Shared with Intent Exclusive [IS] --









Lock Escalation: Process of converting a lot of low level locks such as row level , page level locks into higher level locks such as table level of row level is called as Lock Escalation i.e .

 Instead of multiple row level locks better is table level lock. Which reduces number of locking types and improves the performance by escalating lock

 Instead of multiple page level of locks better is database level lock.

 This decision of Escalation is taken by SQL Server Engine.

 SQL Server supports escalating the locks to the table level. The locks can only be escalated from rows to the table or pages to the table level.

RID --> Pages --> Tables --> DB

Note: In SQL Server locks  can be maintain by lock manger Users or DBA does not have any consoling locking system .


Tuesday, 31 May 2016

SQL Server Performance Tuning Part 4

Working on Performance Tuning is very tough task specially on large scale data hence the minor changes will give dramatic (+ Ve or -Ve) impact on performance.

Before going to tune the query as an experience developer you should aware on

If your application stops working suddenly, it may not be a database issue. For example, maybe you have a network problem. Investigate a bit before you approach the DBA!

The below are the few generic points for tuning.

Stored Procedure Level Tuning Tips

1. Include SET NOCOUNT ON statement:

2. Use schema name with object name:

3. Do not use the prefix “sp_” in the stored procedure name:

4. Use IF EXISTS (SELECT 1) instead of (SELECT *):

5. Use the sp_executesql stored procedure instead of the EXECUTE statement.

6. Try to avoid using SQL Server cursors whenever possible specially avoid cursors over temporary tables.

7. Keep the Transaction as short as possible:

8. Use TRY-Catch for error handling to get the accurate info.

9.  Use the sp_executesql stored procedure instead of temporary stored procedures.

10. Try to avoid using temporary tables inside your stored procedures.

Using temporary tables inside stored procedures reduce the chance to reuse the execution plan.

11. Try to avoid using DDL (Data Definition Language) statements inside your stored procedure.

Using DDL statements inside stored procedures also reduce the chance to reuse the execution plan.

12. Add the WITH RECOMPILE option to the CREATE PROCEDURE statement if you know that your query will vary each time it is run from the stored procedure.


13. Use SQL Server Profiler to determine which stored procedures have been recompiled too often.

SQL Server Performance Tuning Part 3

Before going to tune the query as an experience developer you should aware on

If your application stops working suddenly, it may not be a database issue. For example, maybe you have a network problem. Investigate a bit before you approach the DBA!

The below are the few generic points for tuning.

Transaction Level Tuning Tips

1. Avoid long-running transactions.

2.  Avoid transactions that require user input to commit.

3.  Access heavily used data at the end of the transaction.

4.  Try to access resources in the same order.

5. Use isolation level hints to minimize locking. For more information about isolation level please click here


6. Ensure that explicit transactions commit or roll back.

SQL Server Performance Tuning Part 2

Working on Performance Tuning is very tough task specially on large scale data hence the minor changes will give dramatic (+ Ve or -Ve) impact on performance.

Working on Performance Tuning is very tough task specially on large scale data hence the minor changes will give dramatic (+ Ve or -Ve) impact on performance.

Before going to tune the query as an experience developer you should aware on

If your application stops working suddenly, it may not be a database issue. For example, maybe you have a network problem. Investigate a bit before you approach the DBA!

The below are the few generic points for tuning.

Index Level Performance Tuning

1. Create indexes based on use. i.e don't create the index on the column where data type length is >=1000.

2.  Keep clustered index keys as small as possible.

3.  Consider range data for clustered indexes.

4. Create an index on all foreign keys.

5. Create highly selective indexes.

6.  Create a covering index for often-used, high-impact queries.

7. Use multiple narrow indexes rather than a few wide indexes.

8. Create composite indexes with the most restrictive column first otherwise it will leads key lockups in execution plan.

9. Consider indexes on columns used in WHERE, ORDER BY, GROUP BY, and DISTINCT clauses.

10.  Remove unused indexes.

11. Use the Index Tuning Wizard to identify the columns required index.


Algorithm or Tuning Mantra for SQL Code





SQL Server Performance tuning - Part 1

Working on Performance Tuning is very tough task specially on large scale data hence the minor changes will give dramatic (+ Ve or -Ve) impact on performance.

Before going to tune the query as an experience developer you should aware on

If your application stops working suddenly, it may not be a database issue. For example, maybe you have a network problem. Investigate a bit before you approach the DBA!

The below are the few generic points for tuning.

Query Level Tuning


1. Return only the rows and columns needed.

2. Avoid expensive operators such as NOT LIKE in filtered clauses.

3.  Avoid explicit or implicit functions in WHERE clauses.

4.  Use locking and isolation level hints to minimize locking.

5. Use stored procedures or parameterized queries.

6. Minimize cursor use.

7. Use temporary tables and table variables appropriately i.e keep heavy transactions table and function results in the  temp table table with required columns and then create the index on this temp table.

8. Limit query and index hint use.

9. Fully qualify database objects i.e keep <Database Name>.<Schema Name>.<Table Name>.



Sunday, 22 May 2016

Indexes in SQL Server

                                                    INDEXES
                                                                                                                                               
                Indexes are used for faster access of data. If you apply too many indexes on tables then performance will decrease.

Types of Indexes

                                * Clustered Index
                                * Non-Clustered Index
                                * XML Index
                                * Spatial Index

Clustered Index:

A table can contain only one clustered index. If primary key is created on column in a table
then cluste index will be created automatically . Clustered Index will change the physical order of the records in a table.

CREATE TABLE emp (EmpID INT,EName VARCHAR(10),Sal INT )
CREATE CLUSTERED INDEX <INDEX-NAME> ON <Table-Name>(Column-Name)

CREATE CLUSTERED INDEX my_clustered ON Emp(EmpID)

Non-Clustered Index:

A table can contain 249 non-clustered indexes up to SQL 2005 and 999 non-clustered indexes from SQL 2008. If unique constraint is created on columns in a table then Non-Clustered index will be created automatically. It will not  change the physical order of the records in a table.

CREATE NONCLUSTERED INDEX NIX ON Emp(EmpID) include (Ename,Sal)

XML Index:

This is the new index introduced in sqlserver 2005,it is placed on a column whose datatype is XML.

Spatial Index:

This is the new index introduced in sqlserver 2008 R2 , it is placed on a column whose datatype is Spatial.

Disabling an index:

ALTER INDEX < INDEX - NAME > ON < TABLE - NAME > disable


Dropping an index:

DROP INDEX <TABLE-NAME>.<INDEX-NAME>

Rebuilding an index:

ALTER INDEX INDEX NAME ON <TABLE-NAME> rebuild


Index rebuild means it drops the existing index and recreates the index.

Reorganizing an index:

ALTER INDEX INDEX NAME ON < TABLE - NAME > reorganize


Index reorganize means physically reorganize the leaf-nodes of the page.

Advantages:

It increases the select query performance.

Drawbacks:

 Increase the size of the database.

 Data modification performance become slow.

Points to Remember

We can't apply indexes on columns whose data type is nvarchar(max) , text and ntext.

Monday, 2 May 2016

SQL Server Performance Tuning guidelines

The below are the generic points needs to be considered while doing performance tuning.

1. If the stats are up to date then estimated rows and estimated execution will be approximately same in the execution plan. If there is huge difference then stats are outdated and required update.

2. Rebuild or re-organize the indexes and also create if the indexes are not available.

3. If update statistics or rebuilding the indexes doesn't help you bringing down the CPU then tune the query one by one.

3. If the procedure is causing the CPU spike then

a. Use SET NOCOUNT ON to disable no of effected rows message. It is required only to test or debug the code.

b. Use schema name with the object name if multiple schemas exist in the database. This will helpful in directly finding the compiled plan instead of searching for the object in other schema. This process of searching schema for an object leads to COMPILE lock on SP and decreases the SP's performance. So always its better to refer the objects with the qualified name in the SP.

c. Do not use the prefix "sp_" in the stored procedure name . If you use then it will search in the master database. Searching in the master database causes extra over head and also there are changes to get wrong resulyt if the same SP found in the master database.

d. Use IF EXISTS (SELECT 1) instead of (SELECT * ) to check the existence of a record in another table. Hence EXIST will use True or False.

e. If the query which is spiking linked server query try changing the security of linked server to ensure liked server user has ddl_admin or dba/sysadmin on the remote server.

f. Try to avoid using the SQL Server cursors when ever possible and use while loop to process the records one by one.

g. Keep the transaction as short as possible - The length of transaction affects blocking and deadlocking.Exclusive lock is not released until the end of transaction. For faster execution and less blocking the transaction should be kept as short as possible.


h. Use Try-Catch for error handling it will help full to easily debug and fix  the issues in case of big portion of code.

i. Return only the Rows and Columns needed.

j. Avoid expensive operators such as Not Like , != etc.

k.If you are checking the existance then use only IF EXISTS or IF NOT EXISTS instead <> or NOT LIKE or != .

k.  Transaction usage should be :

     Avoid long-running transactions.
     Avoid transactions that require user input to commit.
     Access heavily used data at the end of the transactions.
     Try to access resources in the same order.
     Use isolation level hints to minimize the locks.
     Ensure that explicit transactions commit or roll back.

l . Avoid interleaving DDL and DML in Stored Procedure

   Interleaving DDL and DML in stored procedures is one of the most common causes of store procedure recompiles. A common scenario is to create a temporary table , to insert data into that table , to create index and then to select the data from the table. This sequence of events typically causes a recompile . To avoid recompiles put all the DDL at the beginning of the stored procedures and put the DML after the DDL.

m. If you are using embedded SQL then follow the below steps to tune the queries .

      a. Use table joins in place of sub query.

           Ex: If A , B is many to one or one to one relationship.
         
           Replace
           
             SELECT *
 FROM A
 WHERE a.city IN (
   SELECT b.city
   FROM B
   )
   
           With

            SELECT A.*
       FROM A ,B
       WHERE A.city = B.City

      b. Replace Outer Join with Union

        Replace

          SELECT A.City  ,B.City
      FROM A  ,B
      WHERE A.STATE = B.STATE (+)

    
 With

     SELECT A.City ,B.CITY
     FROM A  ,B
     WHERE A.STATE = B.STATE

     UNION

     SELECT NULL  ,B.City
      FROM B
     WHERE NOT EXISTS (
  SELECT 'X'
  FROM A
  WHERE A.STATE = B.STATE
  ) 

n. If you are trying to filter number values then use >0 instead of null in where clause.
o. At SQL Query Level
Avoid
* Cross Join.
* Co-Related Subquery.
* Don't use distinct use Group by.
* Avoid in equality queries like
Select * from emp where empno<>30 instead of it write
Select * from emp where empno in (10,20,40 ...etc)
* Use Exist clause instead of IN clause.
* Create Indexes on source table so that data retrieved fastly.
* Use column names instead of * in Select clause.
* Don't use built-in functions unnecessarily like IsNull after where clause if you want you can
use it along with Select statement.