There is new feature called Resumable Online Index Rebuild introduced in SQL Server 2017 that is an extension of online index rebuild operation. Learn about Resumable Online Index Rebuild operation in SQL Server 2017 in attached article.

Read More:

• What should be best value for fill factor in SQL Server?
• How to Avoid Page Split in SQL Server?
• How to use Resumable Online Rebuild Operation?

ONLINE Index Rebuild Operation

Rebuilding an index drops and re-creates the index. Indexes becomes unavailable during this exercise that causes an outage for that object. Microsoft has given a solution to avoid inaccessibility of the object during index rebuild operation. We can specify ONLINE keyword value as ON in CREATE INDEX or ALTER INDEX to rebuild indexes online.

When you are rebuilding an index and the ONLINE option is set to ON, the underlying objects, the tables and associated indexes, are available for queries and data modification. Row versioning is used to allow for transactional consistency. SQL Server reindex ONLINE option does not work if your table has BLOB data types or index is an XML index or Spatial index.

I have given the list of T-SQL statements that will rebuild indexes ONLINE on your table. You just need to change the index name, table name and column name from below statements.

Below SQL code will rebuild the clustered index on column EMPID on the table dbo.Salary. As we are rebuilding this cluster index using dropping and recreating the cluster indexes so existing index will be dropped in the process, but it will be available during the operation because the ONLINE option is specified.

CREATE CLUSTERED INDEX CI_Salary_EMPID ON dbo.Salary(EMPID)
WITH(DROP_EXISTING = ON, ONLINE = ON)

We can also use ALTER INDEX statement to rebuild a specific index or all indexes on a specified table. The ONLINE syntax remains the same as the CREATE INDEX statement if you want to run this operation online.

ALTER INDEX ALL ON [dbo.Salary]
REBUILD WITH(ONLINE = ON)

Above statement will rebuild all indexes on table Salary keeping everything accessible during this operation. Now, we can also rebuild clustered index only on the dbo.Salary table. The ONLINE option is specified, which means that the table will be accessible during the rebuild operation.

ALTER INDEX CI_Salary_EMPID ON dbo.salary
REBUILD WITH(ONLINE = ON)

But if we will remove ONLINE option from above statement, then table will NOT be accessible during rebuild operation. You can run below command to validate the accessibility of your table for which you are rebuilding the indexes.

ALTER INDEX CI_Salary_EMPID ON dbo.salary
REBUILD

Disk Space Considerations 

Disk space is an important consideration when you create, rebuild, or drop indexes. Inadequate disk space can degrade performance or even cause the index operation to fail. There might be other major performance impact of Online Index Rebuild operation as well. Please consider below recommendations if you are using Online index operations or during SQL Server rebuild index online.

1. During ONLINE index rebuild and index creation, additional space is required in the data file to keep the second copy of the index. This is because SQL Server creates a snapshot of the index and once index rebuild or creation completes, second copy of this index will be removed by SQL Server.
2. Additional disk space is required for the temporary mapping index. This temporary index is used in online index operations that create, rebuild, or drop a clustered index.
3. Make sure the transaction log has been backed up and truncated before running index operations online, and that the log has sufficient space to store the projected index and user transactions.
4. Specify 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. Make sure to keep tempdb log and user database log files on separate drives to avoid any disk space issues.
5. Verify that the tempdb database and transaction log have sufficient disk space to handle the index operation. The tempdb transaction log cannot be truncated until the index operation is completed.
6. Do not run the online index operation in an explicit transaction. The log will not be truncated until the explicit transaction ends.

Performance Considerations

If we think about performance impact of Online Index Rebuild operation on SQL Server then it will put more burden on your database server than offline index operations. Because both the source and target structures are maintained during the online index operation.

ONLINE Index operations will be slower than equivalent offline index operations because insert, update, and delete transactions is increased, potentially up to double. This could cause a decrease in performance and greater resource usage, especially CPU time, during the index operation. Online index operations are enterprise features and are fully logged operations.

It is recommended to use legacy way of index rebuild or index operations if your system allows a maintenance window. Remember users will be restricted to access data during the offline index operation, but the operation finishes faster and uses fewer resources.

If you have a system that runs 24×7 then ONLINE index rebuild or creation will be a better choice but make sure to consider all points described in this article before choosing online index operations. You need to think from disk space and performance both prospect and design your system that can handle the load and sustain during peak hours.

Related Articles

• SQL Server Interview Questions & Answers on Indexes
• Understanding Different types of Indexes in SQL Server

Here, I have described Disk and Performance Impact of Online Index Rebuild operation on SQL Server. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

The post Disk and Performance Impact of Online Index Rebuild Operation appeared first on Techyaz.com.

Related Articles:

• SQL Server Interview Q&A on Alwayson Availability Group
• SQL Server DBA Interview Questions & Answers
• SQL Server Backup & Recovery Interview Questions & Answers
• SQL Server Architecture Interview Questions & Answers
• Index Rebuild vs Index Reorganize Operation

SQL Server Interview Questions & Answers on Indexes

Question – How data stores in Indexes?

Answer – Data stores in indexes or in tables on a series of 8 kb data pages. Indexes Data on these data pages are organized in a B-Tree structure that supports fast retrieval of the rows, based on their index key values. Each page in an index B-tree is called an index node. The top node of the B-tree is called the root node. The bottom level of nodes in the index is called the leaf nodes. The leaf nodes of a nonclustered index is made up of index pages instead of data pages whereas in a clustered index, the leaf nodes contain the data pages.

Question – What is Fill Factor and what should be the perfect value for it?

Answer – A fill factor value determines the percentage of space on each leaf-level page to be filled with data, reserving the remainder on each page as free space for future growth. Fill factor values 0 and 100 are the same in all respects. The fill-factor option is provided for fine-tuning index data storage and performance. Although, there is no defined value that we can say is perfect value for fill factor. You can set it to somewhere around 80% and monitor fragmentation over time. Then, you can tweak its value up or down depending on how fragmented the indexes get. Read more about fill factor and its best value.

Question – Explain Page Split and whether it is good for SQL Server or bad?

Answer – Whenever you update existing rows with the data that is bigger in size to save on their data page then Page Split operation occur to make space for this new update. Page split reduces performance so we can say page split is not at all a good thing for our database.

Question – How page split is bad for performance?

Answer – Page split is a resource intensive operation and causes fragmentation that leads to deficient performance in terms of increased I/O operations. We should take it seriously if there are frequent page splits occur and consider reducing its occurrences

Question – What is Difference between clustered and nonclustered Indexes?

Answer – Clustered indexes sort and store the data rows in the table or view based on their key values. There can be only one clustered index per table, because the data rows themselves can be sorted in only one order.

Nonclustered indexes have the same B-tree structure as clustered indexes. The data rows of the underlying table are not sorted and stored in order based on their non clustered keys. The leaf layer of a nonclustered index is made up of index pages instead of data pages. You can create up to 999 nonclustered indexes on a table. 

Question – Does indexes always improve database performance?

Answer – NO, sometimes indexes can reduce your database performance if you are running a bulk data upload or your application has a nature of frequent data Insert operations. Indexes are very useful if you are accessing or reading the data.

Question – What is filter index?

Answer –  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.  

Question – What is covering index?

Answer – A covering index is one which can satisfy all requested columns in a query without performing a further lookup into the clustered index.

Question – Explain column store index?

Answer – An in-memory columnstore index stores and manages data by using column-based data storage and column-based query processing.

Columnstore indexes work well for data warehousing workloads that primarily perform bulk loads and read-only queries. 

Question – Why can’t a table have more than one clustered indexes?

Answer – Clustered indexes sort and store the data rows in the table or view based on their key values so you can’t store data in table based on two index key that’s why you can create only one cluster index on a table.

Question -What is Heap and when it is useful from clustered table?

Answer – Heap is a table without having cluster indexes. Heaps are generally useful if you are running huge bulk data load or frequent DML operations.

Question – How do you find about missing indexes that you need to create to improve database performance?

Answer – We can run SQL Server database Tuning Advisor that will suggests us about all the missing indexes that we should create to improve db performance. We can also use DMVs related to missing indexes sys.dm_db_missing_index_details, sys.dm_db_missing_index_groups and sys.dm_db_missing_index_columns to get these details.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

The post SQL Server Interview Questions & Answers on Indexes appeared first on Techyaz.com.

Index Rebuild vs Index Reorganize

Index Rebuild operation first drops and then recreates the index. This removes fragmentation, reclaims disk space by compacting the pages based on the specified or existing fill factor setting. Microsoft recommends Index Rebuild operation to defrag indexes if the fragmentation level of your index is greater than 30%. You can execute Index rebuild operation online as well as offline. Online index rebuild operation is enterprise only feature and you can use it if you have SQL Server Enterprise edition.

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. Microsoft recommends using Index Reorganize operation to defrag indexes if the fragmentation level of your index is greater than 5% and less than or equal to 30%. Reorganizing an index is always executed online.

Read More:

• What should be best value for fill factor in SQL Server?
• How to Avoid Page Split in SQL Server?
• SQL Server Interview Questions & Answers on Indexes

How to Check Fragmentation Level?

First, we detect the fragmentation level of the indexes. Once we have the details about fragmented indexes then we can decide whether to rebuild that index or reorganize it. We can get index fragmentation level using DMV sys.dm_db_index_physical_stats or by launching dashboard report. Find the average fragmentation percentage of all indexes in the table dbo.Salary of database techyaz by running below T-SQL script.

USE Techyaz;
GO
SELECT a.index_id, name, avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (DB_ID(N'Techyaz'),
OBJECT_ID(N'dbo.salary'), NULL, NULL, NULL) AS a
JOIN sys.indexes AS b
ON a.object_id = b.object_id AND a.index_id = b.index_id;
GO

We can see the output of this code in below image. As i have only one table and two indexes in my database but if you have multiple tables and indexes then output will look accordingly.

Another way to check the fragmentation level of your indexes is by running dashboard report.  Right click on your database, click on “Reports” then “Standard Reports” then finally click on “Index Physical Statistics” report. You can see this in below screenshot.

Once you click on “Index Physical Statistics” report, a dashboard report will run and appear on right side pane as per below screenshot. You will get fragmentation level for each index here.

How to Remove Fragmentation Level?

There are two ways to remove fragmentation level of indexes. These are by either using Index Rebuild Operation or by using Index Reorganize Operation. Here, i will show you how to remove fragmentation using both ways one after another.

Remove Fragmentation using Index Reorganize Operation

We can see our index has very low fragmentation level that is less than 30% in above images so we will reorganize it rather than rebuild. We will rebuild only those indexes that have more than 30% of fragmentation level. Run below T-SQL command to reorganize index IX_Salary_EMPID.

USE Techyaz;
GO

ALTER INDEX IX_Salary_EMPID
ON dbo.Salary
REORGANIZE ;
GO

If you want to reorganize all indexes of this table dbo.salary in one shot, you can use ALL keyword in Alter Index command. Run below command to reorganize all indexes of table dbo.salary in one go.

USE Techyaz;
GO

ALTER INDEX ALL ON dbo.Salary
REORGANIZE;
GO

Remove fragmentation using Index Rebuild Operation

Similarly, we will rebuild all those indexes that are highly fragmented. As I don’t have any such index but if you will get any index that has more than 30% of fragmentation then you can run below command to rebuild that index.

USE Techyaz;
GO
ALTER INDEX PK_Salary_EMPCODE ON dbo.Salary
REBUILD;
GO

If you want to REBUILD all indexes of dbo.salary table in go then again we will use ALL keyword in ALTER Index statement as we did in above example during REORGANIZE.

USE Techyaz;
GO
ALTER INDEX ALL ON dbo.Salary
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON);
GO

If your system does not allow any maintenance window and run 24×7 then you can use online method to rebuild these indexes. Read attached article to learn how to rebuild indexes online in SQL Server. Even SQL Server 2017 has given more control on index rebuild operation by introducing a new feature called Resumable Online Index Rebuild. Read the attached article to learn about this feature in which we can pause a index rebuild operation and resume it later from the point it was stopped.

I hope you like this article. You can drop your questions and feedback in comment section. Please follow our Facebook page and Twitter handle to get latest updates.

The post Difference between Index Rebuild and Reorganize appeared first on Techyaz.com.

A fill factor value determines the percentage of space on each leaf-level page to be filled with data, reserving the remainder on each page as free space for future growth. For example, If we specify a fill factor value of 95 means that 5% of each leaf-level page will be left empty, providing space for future index expansion as data is added to the underlying table. The empty space is reserved between the index rows rather than at the end of the index.

Fill factor values 0 and 100 are the same in all respects. The fill-factor option is provided for fine-tuning index data storage and performance. Setting inappropriate fillfactor value will increase the page split occurrence that is not good from SQL Server performance point of view. A correctly chosen value can reduce potential page splits by providing enough space for index expansion.

Although, there is no defined value that we can say is perfect value for fill factor. You can set it to somewhere around 80% and monitor fragmentation over time. Then, you can tweak its value up or down depending on how fragmented the indexes get.

There is a myth that Database engine considers fill factor value during every INSERT or UPDATE transaction. But it’s not true. Database engine does not consider fill factor value during normal DML (insert / update / delete) operations. This value comes into picture only during index creation or rebuild operation. So whenever you insert or load data in your database data pages will be filled 100% irrespective of your fill-factor value.

How to specify a fill factor in an index by using GUI in SSMS

1. Connect to SQL Server Instance using SSMS.
2. Expand Database folder followed by the database that contains the table on which you want to specify an index’s fill factor.
3. Expand the Tables folder.
4. Click the plus sign to expand the table on which you want to specify an index fill-factor.
5. Click the plus sign to expand the Indexes
6. Right-click the index with the fill factor that you want to specify and select Properties.
7. Under Select a page, select Options.
8. In the Fill factor row, enter the fill factor that you want.
9. Click OK.

You can check fill factor value in below screenshot as well. Fill factor value is showing zero because of its default value. Change it for this particular index if you want.

How to specify a fill factor in an index using Transact-SQL

We can determine fill factor either during Index REBUILD operation or during Index creation. Below is the T-SQL codes that we can use to specify fill factor for an index.

To specify a fill factor in an existing index

Run below T-SQL command to determine fill factor for an existing index during Rebuild operation.

-- Rebuilds the IX_Salary_EMPID index with a fill-factor of 95 on the dbo.Salary table.
USE Techyaz
GO

ALTER INDEX IX_Salary_EMPID ON dbo.Salary
REBUILD WITH (FILLFACTOR = 95);
GO

To specify a fill-factor during create index

Run below command to specify a fill-factor during index creation.

--Drops and re-creates the IX_Salary_EMPID index on the dbo.Salary table with a fill-factor of 95.
USE Techyaz;
GO

CREATE INDEX IX_Salary_EMPID ON dbo.Salary
(EMPID)
WITH (DROP_EXISTING = ON, FILLFACTOR = 95);
GO

Related Articles

• Understanding SQL Server Indexes
• What is difference between Rebuild and Reorganize Indexes?
• Table Row Count is showing incorrect in sys.partitions
• How to get Total Row Count of all tables of a database

I hope you like this article. Drop your questions and feedbacks in comment section. Please follow our Facebook page and Twitter handle to get latest updates.

The post What should be the Best Value for Fill Factor in SQL Server appeared first on Techyaz.com.

• Root Level
• Intermediate Level
• leaf Level.

Clustered index leaf-level pages contain the data in the table whereas Non Clustered index leaf-level pages contain the key value and a pointer to the data row in the clustered index or heap.

Read More

• How to use Resumable Online Index Rebuild Operation?
• Understanding Online Index Rebuild Operation
• SQL Server Interview Questions & Answers on Indexes

If your table does not have SQL Server indexes and you want to access data from the table then database engine will take more time and performance because full table scan will be performed to get that data. However, if your table has an index on column, SQL Server can seek directly on the value and retrieve the rows.

Index Types

There are multiple types of indexes in SQL Server. Below is the list of such indexes.

Clustered Index

• Clustered indexes sort and store the data rows in the table or view based on their key values. There can be only one clustered index per table, because the data rows themselves can be sorted in only one order.
• The only time the data rows in a table are stored in sorted order is when the table contains a clustered index. When a table has a clustered index, the table is called a clustered table. If a table has no clustered index, its data rows are stored in an unordered structure called a heap.

Nonclustered Index

• Nonclustered indexes have the same B-tree structure as clustered indexes.
• The data rows of the underlying table are not sorted and stored in order based on their nonclustered keys.
• The leaf layer of a nonclustered index is made up of index pages instead of data pages.
• You can create upto 999 nonclustered indexes on a table.

Memory-optimized nonclustered indexes

• For memory-optimized nonclustered indexes, memory consumption is a function of the row count and the size of the index key columns

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.

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.

Columnstore Index

• An in-memory columnstore index stores and manages data by using column-based data storage and column-based query processing.
• 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.

Index with included columns

• A nonclustered index that is extended to include nonkey columns in addition to the key columns.

Index on computed columns  

• An index on a column that is derived from the value of one or more other columns, or certain deterministic inputs.

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.

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.

XML Index

• A shredded, and persisted, representation of the XML binary large objects (BLOBs) in the xml data type column.

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.

How SQL Server Indexes are used by Query Optimizer

When a query is executed, the query optimizer evaluates each available method for retrieving the data and selects the most efficient method. The method may be a table scan, or may be scanning one or more indexes if they exist. When performing a table scan, the query optimizer reads all the rows in the table, and extracts the rows that meet the criteria of the query. A table scan generates many disk I/O operations and can be resource intensive. However, a table scan could be the most efficient method if, for example, the result set of the query is a high percentage of rows from the table.

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.

Your task is to design and create SQL Server indexes that are best suited to your environment so that the query optimizer has a selection of efficient indexes from which to select. SQL Server provides the Database Engine Tuning Advisor to help with the analysis of your database environment and in the selection of appropriate indexes.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

The post Understanding SQL Server Indexes appeared first on Techyaz.com.