• What would be Disk and Performance Impact if we rebuild indexes using ONLINE option?

Resumable Online Index Rebuild

This feature allows us to pause index rebuild operation during its execution at any point and resume it later from the point it was paused. You can use this feature in case you get any higher priority tasks or your server is running out of disk space or facing any performance issue. In addition, this feature rebuilds indexes using only a small amount of log space.

This feature allows us to resume an index rebuild operation after an index rebuild failure, such as after a database failover or after running out of disk space. We can also pause an ongoing index rebuild operation and resume it later. Resumable Online Index Rebuild allows us to rebuild large indexes without using a lot of log space.

Read More

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

Points to Consider

Below are the points you must keep in mind if you are choosing resumable online index rebuild operation.

1. When an index operation is paused, both the original index and the the newly created one require disk space and need to be updated during DML operations.
2. Enables truncation of transaction logs during an index rebuild operation (this operation cannot be performed for a regular online index operation).
3. Resumable Online Index Rebuild feature can be used only with Online Index Rebuild operation. You cannot use it for offline index rebuild operation.
4. We cannot rebuild an index that is disabled.
5. We cannot use ALL option to rebuild existing indexes.
6. Resumable Index Rebuild operation cannot be used to rebuild an existing index that has either computed column or timestamp column as part of the index key.
7. We cannot use SORT_IN_TEMPDB=ON option if we choose to use resumable index rebuild option.

How to use Resumable Online Index Rebuild?

I have given multiple examples to demonstrate the different use cases of resumable online index rebuild operation in this section. If we want to use the resumable index rebuild functionality, we need to execute the online index rebuild with RESUMABLE keyword because Resumable index rebuild supports only during online index rebuild, so we must specify ONLINE = ON along with RESUMABLE = ON option. You cannot use this feature until you mention RESUMABLE = ON in your code because RESUMABLE=OFF is the default value. Run below command to rebuild index online as resumable option.

ALTER INDEX INDEX_Name on Table_Name
REBUILD WITH (ONLINE=ON, RESUMABLE=ON) ;

We can also specify MAXDOP settings during online index rebuild as resumable option to use parallelism. Execute an online index rebuild as resumable operation with MAXDOP=1 by running below command.

ALTER INDEX INDEX_Name on Table_Name 
REBUILD WITH (ONLINE=ON, MAXDOP=1, RESUMABLE=ON) ;

We can also control execution or processing time of resumable online index rebuild by specifying MAX_DURATION option. It specifies the number of minutes that the resumable online index operation will be executed, before being paused. Execute an online index rebuild as resumable operation with MAX_DURATION set to 30 minutes.

ALTER INDEX INDEX_Name on Table_Name 
REBUILD WITH (ONLINE=ON, RESUMABLE=ON, MAX_DURATION=30) ;

Next, we will discuss about pausing these index rebuild operations that are running as resumable option in next section.

Pause Online Index Rebuild running with Resumable Option

If you want to manually pause a running resumable online index rebuild then you just need to use PAUSE clause in above ALTER INDEX statements. Run below command to pause a resumable index rebuild operation.

ALTER INDEX INDEX_Name on Table_Name PAUSE ;

Now we will discuss about how to resume a paused online index rebuild operation in next section.

Resume an Online Index Rebuild running with Resumable Option

As I have mentioned above, you can pause online index rebuild due to any reason. Let’s say suppose you pause it because it is taking lot of time to complete and consuming lot of system resources then you can either resume it later when system has enough resource to run this operation or you can resume it specifying a new value for MAXDOP setting that will allow this operation to use parallelism to finish this task.

Suppose you want to resume an online index rebuild for an index rebuild that was executed as resumable operation specifying a new value for MAXDOP set to 8.

ALTER INDEX INDEX_Name on Table_Name 
RESUME WITH (MAXDOP=8) ;

If you want to resume an online index rebuild for an index rebuild that was executed as resumable operation with the same values then you can remove the MAXDOP options from above command and execute the simple command given below.

ALTER INDEX INDEX_Name on Table_Name RESUME;

You can also resume an online index rebuild operation for an index rebuild that was executed as resumable with different parameters like you can set MAXDOP to 2, set the execution time for the index being running as resumable to 60 minutes and in case of an index being blocked on the lock wait 10 minutes and after that kill all blockers. Run below command to rebuild your indexes with above criteria.

ALTER INDEX INDEX_Name on Table_Name
RESUME WITH (MAXDOP=2, MAX_DURATION= 60 MINUTES,
WAIT_AT_LOW_PRIORITY (MAX_DURATION=10, ABORT_AFTER_WAIT=BLOCKERS)) ;

You can test it in your lower life cycle with multiple options and keywords to get in depth knowledge about this feature.

Abort a Resumable Index Rebuild operation

We can also abort resumable index rebuild operation which is running or paused by executing below T-SQL statement.

ALTER INDEX INDEX_Name on Table_Name ABORT ;

Once you will run above command, your index rebuild operation will be aborted.

Monitor Resumable Index Rebuild Operation

Microsoft has given a system view sys.index_resumable_operations that monitors and checks the current execution status for resumable Index rebuild. You can also get the progress details in percentage of resumable index rebuild operation using this system view.

There is a column named state in this system view that will let us know the state of the resumable index rebuild operation whether it is paused or still running. You can query this system view to see all the resumable index rebuild operations that are currently paused or running.

Run below command to list all resumable index rebuild operations that are in the PAUSE state. State column value zero means online index rebuild is running and value 1 means they are paused. You can also check the percent completion of all resumable index rebuild operations from column PERCENT_COMPLETE from the output received by below command.

SELECT * FROM  sys.index_resumable_operations WHERE STATE = 1;

Related Articles

• Performing Online Index Rebuild Operation
• Understanding SQL Server Indexes and difference between Clustered and Nonclustered Indexes
• Difference between Index Rebuild and Index Reorganize Operation

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

The post How to Use Resumable Online Index Rebuild Operation in SQL Server? appeared first on Techyaz.com.

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.

What is Page Split?

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. Data from existing data page first move to new page that is added during Page Split operation and make room to accommodate new records. That is why this operation is resource intensive and create fragmentation. Page splits only occur when data changes in the database. If you are adding all your data at the end of the table then page split will not occur.

If your fill factor is 100 or 0, it will work in a same way. That means there is no room in leaf level page to accommodate future updates. Setting fill factor value to 0 or 100 will increase page split occurrences.

How to Check Page Split in SQL Server?

Here, i will explain how to check page split in SQL Server. Whenever Page split occurs, it will be logged in transaction log file as LOP_DELETE_SPLIT operation. We use fn_dblog function to read SQL Server transaction log file. Run below T-SQL code to see all page splits occurrence using transaction log file.

SELECT *
FROM
fn_dblog (NULL, NULL)
WHERE
[Operation] = N'LOP_DELETE_SPLIT'

You can see LOP_DELETE_SPLIT is logged under operations column. That means it’s a page split operation.

Paul Randel has given very good sql code to check total number of page splits occurrence. Below is the code you need to run to get this details.

SELECT
[AllocUnitName] AS N'Index',
(CASE [Context]
WHEN N'LCX_INDEX_LEAF' THEN N'Nonclustered'
WHEN N'LCX_CLUSTERED' THEN N'Clustered'
ELSE N'Non-Leaf'
END) AS [SplitType],
COUNT (1) AS [SplitCount]
FROM
fn_dblog (NULL, NULL)
WHERE
[Operation] = N'LOP_DELETE_SPLIT'
GROUP BY [AllocUnitName], [Context];
GO

You can check total number of page splits are shown for each indexes in below screenshot. Now we will discuss how to avoid page split in SQL Server for such indexes.

How to Reduce Page Split Occurrences?

An index that has many random inserts and has very full pages will have an increased number of page splits. This causes more fragmentation and that is very bad for performance. We can reduce page splits by keeping some room in the data pages by setting fill factor value less than 100. The extra bytes on each page will help to minimize page splits caused by extra length in the rows. Read attached article to understand the best value for fill factor to avoid such page-split operations.

We can also use index rebuild operation with the FILL FACTOR option that will allow the page fullness to be changed to fit the query pattern on the index. This will also helpful in reducing total page-split counts.
I hope you like this article. You can drop your questions in comment section. Please follow our Facebook page and Twitter handle to get latest updates.

The post How to Avoid Page Split in SQL Server? 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.

1. Identify the Large tables that we will be moving to another filegroup placed on drive E.
2. Create new filegroup on disk E and if you have already a filegroup in this drive you can use that one.
3. Add a data file to this newly created filegroup.
4. Drop the clustered index from the table that has been identified for the movement and recreate it to the another filegroup.
5. Create cluster index on the same table.

Move a table to Another Filegroup

We can move table from one filegroup to another filegroup through dropping and recreating the clustered indexes. Below T-SQL codes that will move your complete table from filegroup1 to filegroup2. Run below ALTER TABLE statement to move a table named TAB1 that has a cluster index named PK_TAB1 to another filegroup TEST_DATA_2.

ALTER TABLE TAB1 DROP CONSTRAINT PK_TAB1 WITH (MOVE TO TEST_DATA_2)
GO
ALTER TABLE TAB1 ADD CONSTRAINT PK_TAB1 PRIMARY KEY(TAB1_ID)
GO

where TAB1 is table name PK_TAB1 is clustered index key and TEST_DATA_2 is target filegroup. It’s not necessary to create the another filegroup in to separate disk. This method will be useful if you want to move a table from one filegroup to another filegroup irrespective of the filegroup drives.

If your table doesn’t have a clustering index by any reason, you can still move table by creating a clustering index and then follow the same process to move it.

Related Articles:

• Understanding SQL Server Indexes and difference between Clustered and Nonclustered Indexes
• Rebuild Index vs Reorganize Index Operations
• Understanding Fill Factor and its value
• Relation between Page Split and Fill Factor

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

The post How to Move Table to Another Filegroup? appeared first on Techyaz.com.