I didn’t explore few features of SQL Server 2014. Recently, I got to know that in SQL Server 2014 we can create indexes on Table Variable.

If you look into the differences between Temp Table and Table Variable, always you can find one difference like we can’t create an index on Table Variable and we can create an index on the Temp Table.

SQL Server: Difference between Temporary Table and Table Variable

In this post, I am sharing few examples of Table variable with Indexes.
Please check the below samples:

Define Table variable with Primary key and Unique key:

DECLARE @dbrnd TABLE
(
	ID INT PRIMARY KEY
	,Name NVARCHAR(10) UNIQUE
)

Define Table variable with Non-Clustered index:

DECLARE @dbrnd TABLE
(
	ID INT PRIMARY KEY
	,Name NVARCHAR(20)
	,INDEX idx_dbrnd_Name NONCLUSTERED (Name)
)

As I am preparing important scripts for SQL Server DBA, so here I am also sharing one more vital script for finding the unused indexes of SQL Server Database.

The management and maintenance of database index is a day to day exercise for a Database Administrator. The wrong or unused index can create performance issues for a frequently used table.

At every insert and update, the data of an index are also changing, and it requires some IO operations. Better to find the unused index and delete it.
I also added “DropStatement” column in script for dropping unused Indexes.

SELECT 
	OBJECT_NAME(i.OBJECT_ID) AS ObjectName
	,i.name AS UnusedIndexName	
	,8 * SUM(au.used_pages) AS IndexSizeInKB
	,CASE
		WHEN i.type = 0 THEN 'Heap'  
		WHEN i.type= 1 THEN 'Clustered' 
		WHEN i.type=2 THEN 'Non-Clustered'   
		WHEN i.type=3 THEN 'XML'   
		WHEN i.type=4 THEN 'Spatial'  
		WHEN i.type=5 THEN 'Clustered columnstore index'   
		WHEN i.type=6 THEN 'Nonclustered columnstore index'  
		WHEN i.type=7 THEN 'Nonclustered hash index.'
	END index_type
	,'DROP INDEX ' + i.name + ' ON ' + OBJECT_NAME(i.OBJECT_ID) AS DropStatement
FROM sys.indexes AS i 
LEFT JOIN sys.dm_db_index_usage_stats AS dius 
	ON dius.OBJECT_ID = i.OBJECT_ID 
		AND i.index_id = dius.index_id 
		AND dius.database_id = DB_ID() 
INNER JOIN sys.partitions AS p 
	ON p.OBJECT_ID = i.OBJECT_ID 
		AND p.index_id = i.index_id 
INNER JOIN sys.allocation_units AS au 
	ON au.container_id = p.partition_id 
WHERE OBJECTPROPERTY(i.OBJECT_ID, 'IsIndexable') = 1 
	AND OBJECTPROPERTY(i.OBJECT_ID, 'IsIndexed') = 1 
	AND dius.index_id IS NULL
	OR (dius.user_updates > 0 
		AND dius.user_seeks = 0 
		AND dius.user_scans = 0 
		AND dius.user_lookups = 0)
GROUP BY OBJECT_NAME(i.OBJECT_ID), i.name, i.type 
ORDER BY OBJECT_NAME(i.OBJECT_ID)

Other SQL Server Index related DBA Scripts:

SQL Server: Script to find Redundant and Duplicate Indexes

SQL Server: Script to find Index Average Fragmentation in Percentage

SQL Server: Script to find Missing Indexes

SQL Server: Script to find Index Operational Stats

SQL Server 2008 introduced the Filtered Indexes.
In my current organization, I am taking many interviews of Database Developers and Database Administrators.

Most of the people don’t know about the Filtered Indexes, so here, I would like to share a small note about Filtered Indexes and how it improves the query performance.

The Filtered Indexes are recommended to create on a well defined subset of data because it is highly optimized non-clustered index.

You can create a non-clustered with desired filters which improve the query and index performance by storing and manipulating indexes only for a subset of the data.

The Filtered Indexes can improve the execution plan quality, can reduce the index maintenance cost, can reduce the storage cost.

For example, I have one sample Students table which contains millions of data.

If I have only non-clustered index including Gender column and I am selecting records bases on Gender, it scans full index pages to find data for particular Gender.

If I create two separate Filtered Indexes for Male and Female, it scans and uses only one Gender index bases on a filter which improves the query performance.

Another example is, If your table column is allowing NULL and table has some NULL values, then you can create Filtered Indexes with NOT NULL on that table column which reduce the unnecessary cost to manage NULL values.

Another example is, There is one process table which contains 0 to 9 different process_id data, but a very less number of records with process_id 0 (10% only) and you need to fetch record for process_id 0.

In this situation, we can create Filtered Index for process_id 0 instead of search all the process_id.

Example to create Filtered Indexes:

Create a sample table:

CREATE TABLE dbo.tbl_Students
(
	StudID INT IDENTITY(1,1)
	,FirstName VARCHAR(50)
	,LastName VARCHAR(50)
	,Gender CHAR(1)
	,DOB DATETIME
	,CONSTRAINT pk_tbl_Students_StudID PRIMARY KEY(StudID)
)
GO

Create a Filtered Index for Male – Gender:

CREATE NONCLUSTERED INDEX idx_tbl_Students_Gender_Male
ON dbo.tbl_Students(Gender)
WHERE Gender = 'M'
GO

Create a Filtered Index for Femail – Gender:

CREATE NONCLUSTERED INDEX idx_tbl_Students_Gender_Female
ON dbo.tbl_Students(Gender)
WHERE Gender = 'F'
GO

First of all, I found this useful script from PostgreSQL WIKI.

For me, this is one of the very useful Index related script to find Which Filter combinations and Operators can be used with PostgreSQL Indexes.
I have already shared a couple of articles on PostgreSQL Indexes which you can also access here.

Before a few days ago, one database developer asked about, How sequence of filter (In WHERE Clause) may affect the Index usage in any RDBMS?

My Simple answer was, a sequence of filter is very important for using Indexes and If we put the wrong sequence or we use filter with any function, It might not be used Index properly.

Once we applied Indexes on Table, we are also responsible for applying proper filters, parameters, operators on that Table to utilize the maximum use of the Indexes.

Using below script, you can find all available different combinations of parameters, filters and operators for a specific Index of PostgreSQL.
In this query, Just provide your Index Name and execute it. The DBA can use this script for performance tuning activity.

SELECT
	pg_get_indexdef(ss.indexrelid, (ss.iopc).n, TRUE) AS IndexColumn
	,amop.amopopr::regoperator AS IndexableOperators
FROM pg_opclass opc, pg_amop amop,
(SELECT indexrelid, information_schema._pg_expandarray(indclass) AS iopc
FROM pg_index
WHERE indexrelid = 'Your_Index_Name'::regclass) ss
WHERE amop.amopfamily = opc.opcfamily 
	AND opc.oid = (ss.iopc).x
ORDER BY IndexableOperators;

In this post, I am sharing one T-SQL script to find a Table which has more than 10 Indexes in SQL Server.

More Indexes on a Table, are creating a performance issue because Indexes also require dedicated CPU I/O for writing it into the Index Pages.
More Indexes will slow down the insertion or any other DML operation of that particular Table.

Below is a script to find out tables which are having more indexes:
You can change the value of @threshold.

DECLARE @threshold INT;
SET @threshold = 10;

SELECT
	[s].[name] + '.' + [t].[name] AS TableName
FROM sys.tables AS t
INNER JOIN sys.schemas AS s
	ON [t].[schema_id] = [s].[schema_id]
WHERE EXISTS
(
	SELECT 1 FROM sys.indexes AS i
    WHERE [i].[object_id] = [t].[object_id]
    GROUP BY [i].[object_id]
    HAVING COUNT(*) > @threshold
)
GO

SQL Server: Script to find Heap Table without having an Index

SQL Server: Script to find Index Average Fragmentation in Percentage

SQL Server: Script to find Missing Indexes

SQL Server: Script to find usage of Database Indexes

SQL Server: Script to find Index Operational Stats

What is your best practice to perform large-scale Index operations?

Make sure the transaction log has been backed up and truncated before running large-scale index operations online, and that the log has sufficient space to store the projected index and user transactions.

Consider setting the SORT_IN_TEMPDB option to ON for the index operation. This separates the index transactions from the concurrent user transactions. The index transactions will be stored in the tempdb transaction log, and the concurrent user transactions will be stored in the transaction log of the user database.

This allows for the transaction log of the user database to be truncated during the index operation if it is required.

What is Online Indexing?

The ONLINE option allows concurrent user access to the underlying table or clustered index data and any associated nonclustered indexes during these index operations.

DBAs can create, rebuild, or drop indexes online. The index operations on the underlying table can be performed concurrently with update or query operations.

The Online indexing feature is very helpful for environments that run 24 hours a day, seven days a week. The Online Indexing feature is available only in the Enterprise Editions.

Can we create index on table variables?

Creating an index on a table variable can be done implicitly within the declaration of the table variable by defining a primary key and creating unique constraints. The primary key will represent a clustered index, while the unique constraint a non clustered index.

What are your best practices to create an Index?

• Understand the characteristics of the database (OLTP / OLAP).
• Keep indexes lean.
• Understand the characteristics of the most frequently used columns and queries.
• Choose the right index type.
• Create the clustered index on every table.
• Keep the length of the index key short for clustered indexes.
• Columns that are of the ntext, text, image, varchar(max), nvarchar(max), and varbinary(max) data types cannot be specified as index key columns.
• Consider using filtered indexes on columns that have well-defined subsets.
• Be sure to eliminate duplicate indexes, that is, multiple indexes created on the same set of columns.
• Consider the order of the columns if the index will contain multiple columns.
• Determine the Fill Factor.

How more indexes makes your INSERT slower?

The number of indexes on a table is the most dominant factor for insert performance. The more indexes a table has, the slower the execution becomes. The insert statement is the only operation that cannot directly benefit from indexing because it has no where clause.

Adding a new row to a table involves several steps. First, the database must find a place to store the row.

If there are indexes on the table, the database must make sure the new entry is also found via these indexes. For this reason it has to add the new entry to each and every index on that table. The number of indexes is therefore a multiplier for the cost of an insert statement.

Moreover, adding an entry to an index is much more expensive than inserting one into a heap structure because the database has to keep the index order and tree balance. That means the new entry cannot be written to any block—it belongs to a specific leaf node.

Once the correct leaf node has been identified, the database confirms that there is enough free space left in this node. If not, the database splits the leaf node and distributes the entries between the old and a new node.

Generally, when you should perform your index tunning exercise?

Index tuning isn’t something you do once a year. It’s something that you need to do iteratively– that means every month. Over time, data sizes change, user activity changes, and the SQL Server optimizer changes. Each of these things mean that indexes that are best for an application will also change. As you tune indexes, your query plans will change and you’re very likely to see more opportunities to add, drop, and combine indexes emerge. Because of this, you want to do a few changes every month.

Has default Index created on foreign key columns?

When a foreign key constraint is defined for a table, an index is not created by default by SQL Server.

However, it’s not uncommon for developers and database administrators to add them manually.

Indexes on foreign keys can provide performance benefits for table joins involving the primary and foreign key, and they can impact performance when the primary key value is updated, or if the row is deleted.

In which columns, you should consider your indexes?

Indexes should be considered on all columns that are frequently accessed by the WHERE, ORDER BY, GROUP BY, TOP, and DISTINCT clauses. Without an index, each of these operations will require a table scan of your table, potentially hurting performance.

When index needs change and you want to test how removing an index will affect performance, you have two options – you can disable or drop the index. Which is better?

DISABLING AN INDEX is better than to drop an Index.

When we Disable an Index, The metadata about the index is retained, as are the usage statistics in sys.dm_db_index_usage_stats.

The index is not usable by the query optimizer.

Disabling a nonclustered index will deallocate the index pages – the space is freed in the database.

Disabling a clustered index has additional effects. The data in the table still exists, but will be inaccessible for anything other than a drop or rebuild operation.

T-SQL Script to DISABLE an INDEX?

ALTER INDEX IX_IndexName ON Schema.TableName DISABLE;

How you can re-enable the disable index?

If you want to re-enable the index, you need to rebuild it.

ALTER INDEX IX_IndexName ON Schema.TableName REBUILD;

As a DBA, share your checklists and best practice for performance tuning of Indexes.

• Periodically, run the Database Engine Tuning Advisor against current Profiler traces to identify potentially missing indexes.
• Remove indexes that are never used.
• Don’t accidentally create redundant indexes.
• As a rule of thumb, every table should have at least a clustered index. Generally, but not always, the clustered index should be on a column that monotonically increases — such as an identity column, or some other column where the value is increasing — and is unique. In many cases, the primary key is the ideal column for a clustered index.
• Since you can only create one clustered index per table, take extra time to carefully consider how it will be used. Consider the type of queries that will be used against the table, and make an educated guess as to which query (the most common one run against the table, perhaps) is the most critical, and if this query will benefit most from having a clustered index.
• If a column in a table is not at least 95% unique, then most likely the query optimizer will not use a non-clustered index based on that column. Because of this, you generally don’t want to add non-clustered indexes to columns that aren’t at least 95% unique.
• Keep the “width” of your indexes as narrow as possible. This reduces the size of the index and reduces the number of disk I/O reads required to read the index, boosting performance.
• If possible, avoid adding a clustered index to a GUID column (uniqueidentifier data type).
• Indexes should be considered on all columns that are frequently accessed by the JOIN, WHERE, ORDER BY, GROUP BY, TOP, and DISTINCT clauses.
• Don’t automatically add indexes on a table because it seems like the right thing to do. Only add indexes if you know that they will be used by queries run against the table.
• When creating indexes, try to make them unique indexes if at all possible. SQL Server can often search through a unique index faster than a non-unique index because in a unique index, each row is unique, and once the needed record is found, SQL Server doesn’t have to look any further.
• If you perform regular joins between two or more tables in your queries, performance will be optimized if each of the joined columns have appropriate indexes.
• Don’t automatically accept the default value of 100 for the fill factor for your indexes. It may or may not best meet your needs. A high fill factor is good for seldom changed data, but highly modified data needs a lower fill factor to reduce page splitting.
• Don’t over index your OLTP tables, as every index you add increases the time it takes to perform INSERTS, UPDATES, and DELETES. There is a fine line between having the ideal number of indexes (for SELECTs) and the ideal number to minimize the overhead that occurs with indexes during data modifications.

What happened when we create a Primary Key constraint?

When you create a PRIMARY KEY constraint, a unique clustered index on the column or columns is automatically created if a clustered index on the table does not already exist and you do not specify a unique nonclustered index. The primary key column cannot allow NULL values.

What happened when we create a UNIQUE constraint?

When you create a UNIQUE constraint, a unique nonclustered index is created to enforce a UNIQUE constraint by default. You can specify a unique clustered index if a clustered index on the table does not already exist.

Can you create UNIQUE INDEX on a single column , which has NULL value in more than one row?

You cannot create a unique index on a single column if that column contains NULL in more than one row. Similarly, you cannot create a unique index on multiple columns if the combination of columns contains NULL in more than one row. These are treated as duplicate values for indexing purposes.

What are the benefits of a Unique Index?

Multicolumn unique indexes guarantee that each combination of values in the index key is unique. For example, if a unique index is created on a combination of LastName, FirstName, and MiddleName columns, no two rows in the table could have the same combination of values for these columns.

Provided that the data in each column is unique, you can create both a unique clustered index and multiple unique nonclustered indexes on the same table.

Unique indexes ensure the data integrity of the defined columns.

Unique indexes provide additional information helpful to the query optimizer that can produce more efficient execution plans.

When we should consider a Filtered Index in Designing?

When a column only has a small number of relevant values for queries, you can create a filtered index on the subset of values. For example, when the values in a column are mostly NULL and the query selects only from the non-NULL values, you can create a filtered index for the non-NULL data rows. The resulting index will be smaller and cost less to maintain than a full-table nonclustered index defined on the same key columns.

When a table has heterogeneous data rows, you can create a filtered index for one or more categories of data. This can improve the performance of queries on these data rows by narrowing the focus of a query to a specific area of the table. Again, the resulting index will be smaller and cost less to maintain than a full-table nonclustered index.

What are the benefits of the Filtered Index?

• Improved query performance and plan quality.
• Reduced index maintenance costs.
• Reduced index storage costs.
• Online index rebuilds.

What is the advantage of Covered Index?

There can be data types which not allowed as Index key columns called as a nonkey columns.

Using include keyword you can add nonkey columns in the primary index.

An index with nonkey columns can significantly improve query performance when all columns in the query are included in the index either as key or nonkey columns. Performance gains are achieved because the query optimizer can locate all the column values within the index; table or clustered index data is not accessed resulting in fewer disk I/O operations.

During an index reorganization operation, if the index spans multiple files, will pages be allowed to migrate between files.

No: pages will not migrate between files during an index reorganization.

How to make forcefully use an index in a query? Or What table hint needs to be specified to forcefully use an index in a query?

We can specify “Index” table hint in a query to forcefully use an index.

SELECT Emp_ID, Name FROM tbl_Employee WITH(INDEX(idx_tbl_Employee_Name));

What kind of data structure is an index?

B- trees are the most commonly used data structures for indexes. The reason B- trees are the most popular data structure for indexes is due to the fact that they are time efficient because look-ups, deletions, and insertions can all be done in logarithmic time. And, another major reason B- trees are more commonly used is because the data that is stored inside the B- tree can be sorted.

Can you create Indexed Views?

The first index created on a view must be a unique clustered index. After the unique clustered index has been created, you can create more nonclustered indexes. Creating a unique clustered index on a view improves query performance because the view is stored in the database in the same way a table with a clustered index is stored. The query optimizer may use indexed views to speed up the query execution.

What is an Index Scan and Index Seek operation?

Database Theory: Table Scan vs Index Scan vs Index Seek

What is a Database Engine Tuning Advisor in the SQL Server?

Microsoft SQL Server Database Engine Tuning Advisor helps you select and create an optimal set of indexes, indexed views, and partitions without requiring an expert understanding of the structure of the database or the internals of Microsoft SQL Server.

Database Engine Tuning Advisor analyzes a workload and the physical implementation of one or more databases. A workload is a set of Transact-SQL statements that execute against a database or databases that you want to tune. Database Engine Tuning Advisor uses trace files, trace tables, or Transact-SQL scripts as workload input when tuning databases.

How Index partitioning help in improving overall performance?

Although partitioned indexes can be implemented independently from their base tables, it generally makes sense to design a partitioned table and then create an index on the table. When you do this, SQL Server automatically partitions the index by using the same partition scheme and partitioning column as the table.

When a table and its indexes are in alignment, SQL Server can switch partitions quickly and efficiently while maintaining the partition structure of both the table and its indexes.

What is a Bookmark Lookup operator in SQL Server?

The Bookmark Lookup operator uses a bookmark (row ID or clustering key) to look up the corresponding row in the table or clustered index. The Argument column contains the bookmark label used to look up the row in the table or clustered index.

Which Index operations do not required additional Disk Space?

• ALTER INDEX REORGANIZE; however, log space is required.
• DROP INDEX when you are dropping a nonclustered index.
• DROP INDEX when you are dropping a clustered index offline without specifying the MOVE TO clause and nonclustered indexes do not exist.
• CREATE TABLE (PRIMARY KEY or UNIQUE constraints)

What is a Columnstore index of SQL Server 2012?

A columnstore index is a technology for storing, retrieving and managing data by using a columnar data format, called a columnstore.

A columnstore is data that is logically organized as a table with rows and columns, and physically stored in a column-wise data format.

Columnstore indexes work well for data warehousing workloads that primarily perform bulk loads and read-only queries. Use the columnstore index to achieve up to 10x query performance gains over traditional row-oriented storage, and up to 7x data compression over the uncompressed data size.

What are the advantages of Columnstore index?

Columns store values from the same domain and commonly have similar values, which results in high compression rates. This minimizes or eliminates IO bottleneck in your system while reducing the memory footprint significantly.

High compression rates improve query performance by using a smaller in-memory footprint. In turn, query performance can improve because SQL Server can perform more query and data operations in-memory.

Batch execution improves query performance, typically 2-4x, by processing multiple rows together.

Queries often select only a few columns from a table, which reduces total I/O from the physical media.

When I should use clustered column stored index?

Use a clustered columnstore index to store fact tables and large dimension tables for data warehousing workloads. This improves query performance and data compression by up to 10x.

When I should use non-clustered column stored index?

Use a nonclustered columnstore index to perform analysis in real-time on an OLTP workload.

How do I choose between a rowstore index and a columnstore index?

Rowstore indexes perform best on queries that seek into the data, searching for a particular value, or for queries on a small range of values. Use rowstore indexes with transactional workloads since they tend to require mostly table seeks instead of table scans.

Columnstore indexes give high performance gains for analytic queries that scan large amounts of data, especially on large tables. Use columnstore indexes on data warehousing and analytics workloads, especially on fact tables, since they tend to require full table scans rather than table seeks.

What do you know about the Column store Data compression?

Columnstore indexes read compressed data from disk, which means fewer bytes of data need to be read into memory.

Columnstore indexes store data in compressed form in memory which reduces IO by reducing the number of times the same data is read into memory.

Columnstore indexes compress data by columns instead of by rows which achieves high compression rates and reduces the size of the data stored on disk. Each column is compressed and stored independently.

What is fill factor and pad index?

A fill factor is a specification done during the creation of indexes so that a particular amount of space can be left on a leaf level page to decrease the occurrence of page splits when the data has to be accommodated in the future.

A pad index specifies index padding. When it is set to ON, then the free space percentage per the fill factor specification is applied to the intermediate-level pages of the index. When it is set to OFF, the fill factor is not specified and enough space is left for a maximum size row.

What is it unwise to create wide clustered index keys?

A clustered index is a good choice for searching over a range of values. After an indexed row is found, the remaining rows being adjacent to it can be found easily. However, using wide keys with clustered indexes is not wise because these keys are also used by the non-clustered indexes for look ups and are also stored in every non-clustered index leaf entry.

Explain the ‘Fill factor’ concept in Indexes.

• The fill factor option is provided for smoothening index data storage and performance.
• The percentage of space on each leaf level page to be filled with data is determined by the fill factor value when an index is created.
• This reserves a percentage of free space for future growth.
• This option is provided for fine tuning index data storage and performance.
• The fill factor value is a percentage from 1 to 100 and the server-wide default is 0 which means that the leaf-level pages are filled to capacity.

How do you maintain a fill factor in existing indexes?

• Usually the data keeps getting added, deleted, or updated in the table due to which the fill factor is implemented during the index creation itself. Fill factor is not maintained after an index is created.
• The changes in the future can be determined only when a new index is created on a table that has an existing data. It is beneficial to set the fill factor then itself.
• Maintaining extra space on the data pages obviates the purpose of using the fill factor. The SQL Server would then have to split pages to maintain an amount of free space per the fill factor, on each page.
• Thus, when data is added filling up the empty space, an index can be created and the fill factor can be re-specified distribute the data again.

Difference between Unique Index vs Unique Constraint.

Unique Index and Unique Constraint are the same and achieve same goal. SQL performance is same for both.

What are the primary differences between an index reorganization and an index rebuild?

• Reorganization is an “online” operation by default; a rebuild is an “offline” operation by default
• Reorganization only affects the leaf level of an index.
• Reorganization swaps data pages in-place by using only the pages already allocated to the index; a rebuild uses new pages/allocations
• Reorganization is always a fully-logged operation; a rebuild can be a minimally-logged operation.
• Reorganization can be stopped mid-process and all completed work is retained; a rebuild is transactional and must be completed in entirety to keep changes.

If you need to REBUILD a non-clustered index that is 10GB in size and have 5GB of free data-file space available with no room to grow the data file(s), how can you accomplish the task?

When rebuilding an existing non-clustered index, you typically require free space that is approximately equivalent to 2.2 times the size of the existing index, since during a rebuild operation, the existing index is kept until the rebuilt structure is complete and an additional approximately 20% free space for temporary sorting structures used during the rebuild operation.

In this case, you would require at least an additional 10+ GB of free space for the rebuild operation to succeed, since the index itself is 10GB in size.

Using SORT_IN_TEMPDB would not suffice in this case, since only the temporary sort tables are stored in tempdb in this case, and at least 10 GB of free space would still be required in the database data files.

Why most of the DBAs recommended Index Reorganizing instead of Index Rebuilding?

Reorganizing an index uses minimal system resources. It defragments the leaf level of clustered and nonclustered indexes on tables and views by physically reordering the leaf-level pages to match the logical, left to right, order of the leaf nodes. Reorganizing also compacts the index pages.

Compaction is based on the existing fill factor value.

Reorganize a index after one or more data loads to achieve query performance benefits as quickly as possible. Reorganizing will initially require additional CPU resources to compress the data, which could slow overall system performance. However, as soon as the data is compressed, query performance can improve.

What is SORT_IN_TEMPDB option for Indexes?

When you create or rebuild an index, by setting the SORT_IN_TEMPDB option to ON you can direct the SQL Server Database Engine to use tempdb to store the intermediate sort results that are used to build the index.

When SORT_IN_TEMPDB is set to OFF, the default, the sort runs are stored in the destination filegroup.

Do you think, INDEX REORGANIZE operation requires additional free disk space?

No, INDEX REORGANIZE does not require additional free disk space, but related transaction log is required free space to log the operation information.

What is a Clustered Index?

Clustered Index stores a key value in the same data or row page. It is attached with data rows.

Clustered indexes sort and store the data rows in the table or view based on their key values.

For example, each and every book has attached one page number on each page so this called clustered index of that book.

How many clustered indexes there can be in one table?

You can create only one clustered index.

What is a Non-clustered Index?

Nonclustered indexes have a structure separate from the data rows. A nonclustered index contains the nonclustered index key values and each key value entry has a pointer to the data row that contains the key value.

The pointer from an index row in a nonclustered index to a data row is called a row locator. The structure of the row locator depends on whether the data pages are stored in a heap or a clustered table. For a heap, a row locator is a pointer to the row. For a clustered table, the row locator is the clustered index key.

You can add nonkey columns to the leaf level of the nonclustered index to by-pass existing index key limits, 900 bytes and 16 key columns, and execute fully covered, indexed, queries.

Can you make non-clustered indexes as unique index?

Yes, you can create unique non-clustered index in which no two rows can have the same value for the index key.

What is a Hash Index?

With a hash index, data is accessed through an in-memory hash table. Hash indexes consume a fixed amount of memory, which is a function of the bucket count.

hash indexes are used is because hash tables are extremely efficient when it comes to just looking up values. So, queries that compare for equality to a string can retrieve values very fast if they use a hash index.

What is the main disadvantage of the Hash Index?

Hash tables are not sorted data structures, and there are many types of queries which hash indexes can not even help with.

For instance, suppose you want to find out all of the employees who are less than 40 years old. How could you do that with a hash table index? Well, it’s not possible because a hash table is only good for looking up key value pairs – which means queries that check for equality condition.

What is a Unique Index?

A unique index ensures that the index key contains no duplicate values and therefore every row in the table or view is in some way unique.

Uniqueness can be a property of both clustered and nonclustered indexes.

Why CLUSTERED INDEX is a Special Index in the SQL Server?

The clustered index in any table has special uses and significance. This index is the data itself, and it will be used in every nonclustered index in the table. If you are defining a new clustered index or changing a clustered index, SQL Server will need to do IO on every nonclustered index on the table as well.

T-SQL Script to create a CLUSTERED INDEX.

CREATE CLUSTERED INDEX Index_Name ON Schema.TableName(Column);

T-SQL Script to create a NONCLUSTERED INDEX.

CREATE NONCLUSTERED INDEX Index_Name ON Schema.TableName(Column);

T-SQL Script to create a NONCLUSTERED INDEX with covered nonkey columns.

CREATE NONCLUSTERED INDEX Index_Name ON Schema.TableName(Column) INCLUDE (ColumnA, ColumnB);

What is a Filtered Index?

An optimized nonclustered index, especially suited to cover queries that select from a well-defined subset of data. It uses a filter predicate to index a portion of rows in the table. A well-designed filtered index can improve query performance, reduce index maintenance costs, and reduce index storage costs compared with full-table indexes.

What is a Full-text Index?

A special type of token-based functional index that is built and maintained by the Microsoft Full-Text Engine for SQL Server. It provides efficient support for sophisticated word searches in character string data.

What is a Spatial Index?

A spatial index provides the ability to perform certain operations more efficiently on spatial objects (spatial data) in a column of the geometry data type. The spatial index reduces the number of objects on which relatively costly spatial operations need to be applied.

What are Covering Indexes and Covered Queries in SQL Server?

If all the columns requested in the select list of query, are available in the index, then the query engine doesn’t have to lookup the table again which can significantly increase the performance of the query. Since all the requested columns are available with in the index, the index is covering the query. So, the query is called a covering query and the index is a covering index.

A clustered index can always cover a query, if the columns in the select list are from the same table.

How Indexes are used by the Query Optimizer?

Well-designed indexes can reduce disk I/O operations and consume fewer system resources therefore improving query performance. Indexes can be helpful for a variety of queries that contain SELECT, UPDATE, DELETE, or MERGE statements.

When the query optimizer uses an index, it searches the index key columns, finds the storage location of the rows needed by the query and extracts the matching rows from that location. Generally, searching the index is much faster than searching the table because unlike a table, an index frequently contains very few columns per row and the rows are in sorted order.

In this post, I am sharing a script to check a Fillfactor value, for tables or indexes of PostgreSQL Database Server.

I have already published importance of Fillfactor in PostgreSQL.

When we are working with the large database system, and we set Fillfactor value of multiple objects, sometimes it is required to check the value of current Fillfactor for those objects.

I prepared one script with “reloptions” column in which you can find “{fillfactor=value}” if it is assigned then only otherwise it is NULL.

SELECT 
	pc.relname AS ObjectName 
       ,pc.reloptions AS ObjectOptions
FROM pg_class AS pc
INNER JOIN pg_namespace AS pns 
	ON pns.oid = pc.relnamespace
WHERE pns.nspname = 'public'
	AND pc.relname = 'Table_Name';