In this post, I am sharing one script to find the size of Indexes in SQL Server.

The first step for performance optimization is to measure the size of tables and indexes which helps you to find out more about fragmentation.

I have already shared a couple of articles on SQL Server Indexes like: find duplicate indexes, unused indexes and fragmentation of indexes.

You can also access these articles after below T-SQL.

SELECT
	OBJECT_SCHEMA_NAME(i.OBJECT_ID) AS SchemaName
	,OBJECT_NAME(i.OBJECT_ID) AS TableName
	,i.name AS IndexName
	,8 * SUM(au.used_pages) AS IndexSizeInKB
FROM sys.indexes AS i
JOIN sys.partitions AS p 
	ON p.OBJECT_ID = i.OBJECT_ID 
		AND p.index_id = i.index_id
JOIN sys.allocation_units AS au 
	ON au.container_id = p.partition_id
GROUP BY 
	i.OBJECT_ID
	,i.index_id
	,i.name
ORDER BY OBJECT_NAME(i.OBJECT_ID),i.index_id

Other related articles:

SQL Server: Find the total row count and size of the Tables

SQL Server: Script to find Redundant and Duplicate Indexes

SQL Server: Script to find usage of Database Indexes

SQL Server: Script to find Index Average Fragmentation in Percentage

Recently, I received a message like “ORDER BY clause is not working in PostgreSQL Index”.

One of the users created an index with ORDER BY DESC and whenever he was selecting data at that time Query optimizer was not using INDEX SCAN ONLY.

So here, I demonstrate and validate this:

If we know in which order we are going to SELECT data, we should apply for proper ORDER BY ASC/DESC in the index.

Please check the below full demonstration, and then validate your self:

Create a table with sample records:

CREATE TABLE tbl_testIndex(a INTEGER, b INTEGER);

INSERT INTO tbl_testIndex
SELECT x, x FROM generate_series(1, 5000) AS f(x);

Create a sample index without any ORDER BY:

CREATE INDEX tbl_testIndex_idx ON tbl_testIndex (a, b);

Check the execution plan:
Index only scan is working…

EXPLAIN 
SELECT *FROM tbl_testIndex
ORDER BY a,b;

'Index Only Scan using 
tbl_testindex_idx on tbl_testindex  
(cost=0.28..194.16 rows=5000 width=8)'

Check the below execution plan:
Sequential Scan of the index which is not good.
Because the index is not available for ORDER BY b DESC.

EXPLAIN 
SELECT *FROM tbl_testIndex
ORDER BY a,b DESC;

'Sort  (cost=380.19..392.69 rows=5000 width=8)'
'  Sort Key: a, b DESC'
'  ->  Seq Scan on tbl_testindex  
(cost=0.00..73.00 rows=5000 width=8)'

Now, drop the old index:

DROP INDEX tbl_testIndex_idx;

Create a new index with b DESC:

CREATE INDEX tbl_testIndex_idx ON tbl_testIndex (a, b DESC);

Check the below execution plan:
Index scan is working…

EXPLAIN 
SELECT *FROM tbl_testIndex
ORDER BY a,b DESC;

'Index Only Scan using 
tbl_testindex_idx on tbl_testindex  
(cost=0.28..194.16 rows=5000 width=8)'

Check the below execution plans:
You can find sequential scan of index because we are not using only ORDER BY b DESC

EXPLAIN 
SELECT *FROM tbl_testIndex
ORDER BY a,b;

EXPLAIN 
SELECT *FROM tbl_testIndex
ORDER BY a DESC,b DESC;

'Sort  (cost=380.19..392.69 rows=5000 width=8)'
'  Sort Key: a DESC, b DESC'
'  ->  Seq Scan on tbl_testindex  
(cost=0.00..73.00 rows=5000 width=8)'

Now, check the below execution plan:
You can find like Index scan backward, where we gave ORDER By a DESC and internally, it is using backward index scan.

EXPLAIN 
SELECT *FROM tbl_testIndex
ORDER BY a DESC,b;

'Index Only Scan Backward using 
tbl_testindex_idx on tbl_testindex  
(cost=0.28..194.16 rows=5000 width=8)'

SQL Server 2014 introduced WAIT_AT_LOW_PRIORITY option which enhanced the performance of ONLINE REBUILD INDEX.

In the previous version of SQL Server, REBUILD INDEX had to wait for the running transaction.
But now in SQL Server 2014, you can give options like MAX_DURATION in minutes, ABORT_AFTER_WAIT with different options.

For ABORT_AFTER_WAIT, took the reference from Microsoft:

ABORT_AFTER_WAIT = [NONE | SELF | BLOCKERS]

NONE: Continue waiting for the lock with normal (regular) priority.

SELF: Exit the online index rebuild DDL operation currently being executed without taking any action.

BLOCKERS: Kill all user transactions that block the online index rebuild DDL operation so that the operation can continue. The BLOCKERS option requires the login to have ALTER ANY CONNECTION permission.

Please check the below demonstration, where I am comparing old and new approach of REBUILD INDEX:

Create a sample table:

CREATE TABLE tbl_DumpData
(
	ID INT 
	,RandomID VARCHAR(MAX)
	,CONSTRAINT pk_tbl_DumpData_ID PRIMARY KEY(ID)
)
GO

Insert dummy data:

;WITH CTE AS
(
	SELECT 1 ID
	UNION all
	SELECT ID + 1
	FROM CTE   
	WHERE ID + 1 <= 100000
)
INSERT INTO tbl_DumpData(ID,RandomID)
SELECT 
	ID
	,NEWID() AS RandomID
FROM CTE 
OPTION (MAXRECURSION 0)
GO

Open new session/query window, execute below update:

BEGIN TRANSACTION
UPDATE tbl_DumpData SET RandomID = 39840972340234 WHERE ID = 8

Jump to old session window, and execute below REBUILD:
It is Running… Running… Running…, because table is locked by another transaction

ALTER INDEX pk_tbl_DumpData_ID ON tbl_DumpData REBUILD
WITH
(
   ONLINE = ON
)
GO

Check the lock table:
You can find that your REBUILD query is in WAIT mode.

SELECT *FROM sys.dm_tran_locks

Now stop the execution of the previous REBUILD, and execute below REBUILD WITH WAIT_AT_LOW_PRIORITY:
Set MAX_DURATION for one minute and ABORT_AFTER_WAIT type is SELF.

ALTER INDEX pk_tbl_DumpData_ID ON tbl_DumpData REBUILD
WITH
(
   ONLINE = ON
   (
	WAIT_AT_LOW_PRIORITY 
	(
		MAX_DURATION = 1
		,ABORT_AFTER_WAIT = SELF
	)
   )
)
GO

Above REBUILD will wait for One minute and then it will throw an error message:

Msg 1222, Level 16, State 56, Line 1
Lock request time out period exceeded.

Now, test with BLOCKER option:
It will wait for one minute, and then it will kill the open UPDATE transaction to finish the REBUILD operation.

ALTER INDEX pk_tbl_DumpData_ID ON tbl_DumpData REBUILD
WITH
(
   ONLINE = ON
   (
	WAIT_AT_LOW_PRIORITY 
	(
		MAX_DURATION = 1
		,ABORT_AFTER_WAIT = BLOCKERS 
	)
   )
)
GO

Now, go to another transaction where UPDATE transaction was there:
Try to execute any query, you will get below error message because this session is terminated by REBUILD + BLOCKERS.

SELECT *FROM tbl_DumpData

Error:

Msg 0, Level 20, State 0, Line 0
The connection is broken and recovery is not possible.  The connection is marked by the server as unrecoverable.  No attempt was made to restore the connection.

In this post, I am sharing the use of sp_MSforeachtable stored procedure of SQL Server.
This is an undocumented object of SQL Server, but still, you can use this stored procedure.

When we require executing same T-SQL command for all the tables, we can use this stored procedure.
Many times we need to run drop/truncate command for all tables or REINDEX all tables, at that point instead of the manual script we can use this stored procedure.

Sharing few examples:

Truncate all tables of current database:

EXEC sp_MSforeachtable 'TRUNCATE TABLE ?'

Check the count of all tables:

EXEC sp_MSforeachtable 'TRUNCATE TABLE ?'

Drop all tables of current database:

EXEC sp_MSforeachtable 'DROP TABLE ?'

REINDEX all tables of current database:

EXEC sp_MSforeachtable 'DBCC DBREINDEX(''?'')'

In this post, I am sharing an interesting SQL Server Interview Question which may ask in the interview of SQL Server Database Developer.

As a database developer, we are executing COUNT(*) many times to check the total number of table records. But have you ever check the execution plan of your COUNT(*) statement?

If your answer is No, then you should check below demonstration.
If your answer is Yes, then don’t be surprised by checking below demonstration because COUNT(*) statement first uses a lightweight index of a table. If an index does not present, it will do a Table Scan.

Create a table with sample data:

CREATE TABLE tbl_Count
(ID1 INT IDENTITY, ID2 SMALLINT DEFAULT 1, Name CHAR(500) DEFAULT 'dbrnd.com')

INSERT INTO tbl_Count DEFAULT VALUES;
GO 10000

Check query execution plan of COUNT statement:
It performed Table scan because didn’t find any indexes on a table.

SELECT COUNT(1) FROM tbl_Count

Now create an index on NAME column:

CREATE NONCLUSTERED INDEX idx_tbl_Count_Name ON tbl_Count (Name)
GO

Check query execution plan of COUNT statement:
You can find Index scan for idx_tbl_Count_Name.

SELECT COUNT(1) FROM tbl_Count

Now create an index on ID2 column:

CREATE NONCLUSTERED INDEX idx_tbl_Count_ID2 ON tbl_Count (ID2)
GO

Check query execution plan of COUNT statement:
You can find Index scan for idx_tbl_Count_ID2 (smallint) because it lightweight than idx_tbl_Count_Name (char).

SELECT COUNT(1) FROM tbl_Count

This post is for SQL Server developers who are in intermediate level. Why people are asking this question because when you are performing any optimization related activity at that time, you need to test lots of indexes.

In that case, I have found many of developers who are dropping and creating indexes again and again for their testing purpose.

If you are good T-SQL Developer, you must know that you can also enable and disable the indexes. So I am sharing this interview question…

How to disable the index?

ALTER INDEX index_name ON table_name DISABLE
GO

How to enable the index?

ALTER INDEX index_name ON table_name REBUILD
GO

How to check the status?

SELECT	  
	name AS IndexName
	,type_desc AS IndexType
	, CASE IS_DISABLED
			WHEN 0 THEN 'Enabled'
			ELSE 'Disabled'
	END AS IndexStatus
FROM SYS.INDEXES

If you are SQL DBA and if I am taking your interview, definitely I will ask this question to you.
If you don’t know about Filtered Index and how to create a Table Partition in SQL Server, please visit below articles:

SQL Server: Filtered Indexes – Improved the query performance

SQL Server 2016: Introduce New TRUNCATE by Partitions Number

Filtered Index:

• You can store a portion of your dataset in Filtered Index. For example, Created a filtered index on Gender column for only ‘Male’, then it stores only ‘Male’ detailed index data.
• Filtered index only applies to a subset of the base table which is not allowing a fast switching.
• You can reduce the CPU I/O by reading a particular value of a Filtered Index.
• The Filtered index stores only keys and reference of data.
• Once you create a Filtered Index on the PartitionScheme, you have to create same Filtered Index for every new table partitions which create a problem because a combination of Filtered indexes may contain the different value.
• If you already apply table partition, you should not apply filtered indexes on those partitions.

Table Partition:

• The Table Partitioning breaks your main table into small groups of tables based on defined partitioning key.
  The data physically divided for better management and fast retrieval.
• For example, you have a 20GB of a table, and it contains total 5 years of data so you can partition your table base on years which will create five table partitions with each size of 4GB.
• To implement Table partitioning, you need to create .ndf files for each partition, partition function, partition scheme.
• It stores all columns of your table in partitions; it is not just storing the key of data like Filtered Index.
  You can define indexes on each table partitions.
• The maintenance of Table Partitions is costly and time taking.

I have given one assignment to a database developer team for preparing general database development practices.
I have found one point in that document: “Do not create Indexes on Temp Tables”.

The use of Temp Tables is very common in SQL Server. Most of the SQL database developers are storing their data into temp tables.
Let me, explore something about, the best practices of Temp Tables.

In general advice, we should avoid the use of temp tables because it requires more CPU/IO while accessing the TempDB.
When you are storing data into temp tables, it stores in TempDB files means the physical disk operation is involved.

Like any other regular table, temp table also requires disk space to store temporary data and other resources for manipulation.

I have seen that many developers are saving a significant number of records in Temp Tables and they are not thinking even for Indexing on Temp Tables.

If you don’t know, please note: You can create a Clustered and Non-Clustered Indexes on Temp Tables which improves your query performance.

Again, more indexes will create more problems because it needs space and manipulation.
First, you should analyze the volume of data, execution plan and accordingly you should apply indexes on Temp tables.

Personally, I have checked the performance of Temp Tables with Clustered Index, which is much better than Temp Table without an Indexes.

I am rejecting all comments and points which say that ” we should not apply Indexes on Temp Tables. “

SQL Server: Difference between Temporary Table and Table Variable

I am also adding a Database Design category for this post, because what I am feeling that you guys must know about this before designing tables or indexes.

You can create Indexes on VARCHAR columns, but you should not create indexes on big size of VARCHAR Columns.

Indexes also require storing data as key for accessing associated records. There is a size limitation of index key values.

Before SQL Server 2016, Index key size limitation was 900 bytes for Clustered and Non-Clustered index column.
SQL Server 2016 increased this limitation for Non-Clustered Index and now it is up to 1700 bytes, but for Clustered Index column it is still 900 bytes.

Let me demonstrate this.

Create a sample table with Nonclustered Index:

CREATE TABLE tbl_TestVarcharNonClustered
(
	ID INT
	,Name VARCHAR(2000)
)
GO

CREATE NONCLUSTERED INDEX idx_tbl_TestVarcharNonClustered_Name ON tbl_TestVarcharNonClustered(Name)
GO

You will get a below warning:
Because we have set Name VARCHAR(2000).

Warning! The maximum key length for a nonclustered index is 1700 bytes. The index 'idx_tbl_TestVarcharNonClustered_Name' has maximum length of 2000 bytes. For some combination of large values, the insert/update operation will fail.

Try to insert 1701 bytes data:

INSERT INTO tbl_TestVarcharNonClustered 
VALUES (1,REPLICATE('a',1701))
GO

You will get a below error:

Msg 1946, Level 16, State 3, Line 1
Operation failed. The index entry of length 1701 bytes for the index 'idx_tbl_TestVarcharNonClustered_Name' exceeds the maximum length of 1700 bytes for nonclustered indexes.

You can successfully run below INSERT, because it inserts only 1700 bytes:

INSERT INTO tbl_TestVarcharNonClustered 
VALUES (1,REPLICATE('a',1700))
GO

Now, create a sample table with Clustered Index:

CREATE TABLE tbl_TestVarcharClustered
(
	ID INT
	,Name VARCHAR(2000)
)
GO

CREATE CLUSTERED INDEX idx_tbl_TestVarcharClustered_Name ON tbl_TestVarcharClustered(Name)
GO

You will get a below warning:
Because we have set Name VARCHAR(2000) on cluster index column.

Warning! The maximum key length for a clustered index is 900 bytes. The index 'idx_tbl_TestVarcharClustered_Name' has maximum length of 2000 bytes. For some combination of large values, the insert/update operation will fail.

Try to insert a over size data like more than 900 bytes:

INSERT INTO tbl_TestVarcharClustered 
VALUES (1,REPLICATE('a',1001))
GO

You will get a below error:

Msg 1946, Level 16, State 3, Line 1
Operation failed. The index entry of length 1001 bytes for the index 'idx_tbl_TestVarcharClustered_Name' exceeds the maximum length of 900 bytes for clustered indexes.

You can successfully run below INSERT, because it inserts only 900 bytes:

INSERT INTO tbl_TestVarcharClustered 
VALUES (1,REPLICATE('a',900))
GO

The Index Rebuilding is a very common and routine task for a Database Administrator.

All types of RDBMS system have various types of Reindexing option.
The Index Rebuilding is necessary periodically to remove fragmentation of Indexes.

PostgreSQL provides two ways to perform Reindexing on Database.

Using REINDEX command:

You can execute REINDEX command on Database, Table and Index.
You can connect PostgreSQL using PGAdmin or PSQL tools to execute this command.

Reindex all indexes of Database:

REINDEX DATABASE Database_Name;

Reindex on particular Index:

REINDEX INDEX Index_Name;

Reindex on particular Table:

REINDEX TABLE Table_Name;

Using REINDEXDB.EXE utility:

A REINDEXDB is a one type of utility of PostgreSQL. It is an executable file which we can run without connect to database server.

A REINDEXDB requires command line arguments like database_username, database_name.
We can execute REINDEXDB using command prompt of the Operating System.

Below an example of Windows Command Prompt, the same way you can also execute in Linux.

Reindex all Database of PostgreSQL Server:

C:\Program Files\PostgreSQL\9.5\bin> reindexdb.exe -U user_name -a
Password:****

Reindex on particular Database:

C:\Program Files\PostgreSQL\9.5\bin> reindexdb.exe -d database -U user_name
Password:****

Reindex on particular Table:

C:\Program Files\PostgreSQL\9.5\bin> reindexdb.exe -d database_name -U user_name -t table_name
Password:****