In this post, I am sharing a demonstration on how to recover the occupied space by a SQL Server table, after dropping a big size of the column.

Many times, we are getting a request like “No Space in Development Server”. Developers are testing their code and design so they are dropping and creating columns in tables.
But after this, we should refresh the table by rebuilding their indexes.

Please check the below full demonstration on this, and try it yourself:

Create a table with sample data:

CREATE TABLE tbl_TableSize (ID BIGINT, Name CHAR(2000), CONSTRAINT pk_Id PRIMARY KEY(ID))
GO

INSERT INTO tbl_TableSize VALUES
(1,'Anvesh'),(2,'Roy'),(3,'Jenny')
,(4,'Martin'),(5,'Neevan'),(6,'Nupur')
GO

Check the average taken space of a table:

SELECT 
	page_count
	,avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(db_id('db_name'), object_id('tbl_TableSize'), NULL, NULL , 'Detailed')

--Result:
page_count           avg_page_space_used_in_percent
-------------------- ------------------------------
2                    74.7343711391154
1                    0.395354583642204

Now, Drop a CHAR column:

ALTER TABLE tbl_TableSize DROP COLUMN Name
GO

Now check the size again:
No difference found!

SELECT 
	page_count
	,avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(db_id('test'), object_id('tbl_TableSize'), NULL, NULL , 'Detailed')

--Result:
page_count           avg_page_space_used_in_percent
-------------------- ------------------------------
2                    74.7343711391154
1                    0.395354583642204

Now, Rebuild the clustered index:

ALTER INDEX pk_Id ON tbl_TableSize REBUILD
GO

Check the size again:
Now, you can see the huge difference in the table size, and occupied space by dropped column has been recovered.

SELECT 
	page_count
	,avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(db_id('test'), object_id('tbl_TableSize'), NULL, NULL , 'Detailed')

--Result:
page_count           avg_page_space_used_in_percent
-------------------- ------------------------------
1                    1.23548307388189

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

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

For ABORT_AFTER_WAIT, took the reference from Microsoft:

ABORT_AFTER_WAIT = [NONE | SELF | BLOCKERS]

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

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

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

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

Create a sample table:

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

Insert dummy data:

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

Open new session/query window, execute below update:

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

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

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

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

SELECT *FROM sys.dm_tran_locks

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

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

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

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

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

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

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

SELECT *FROM tbl_DumpData

Error:

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

From the MSDN,

“When CHECKSUM is enabled for the PAGE_VERIFY database option, the SQL Server Database Engine calculates a checksum over the contents of the whole page, and stores the value in the page header when a page is written to disk.

When the page read from disk, the checksum is recomputed and compared to the checksum value that stored in the page header. This helps provide a high level of data file integrity.“

Guys, You have two options, wait for huge data corruption and detect it a very first level of data corruption.

Once you enable CHECKSUM, every read off and write off a check for CHECKSUM and validates it. If it finds any mismatch or broken chain of CHECKSUM value, it indicates data corruption immediately.

CHECKSUM option doesn’t prevent the data corruption, it gives you more confidence against data corruption, and you can detect data corruption error faster and solve it in the better way.

It occupies little CPU I/O for maintaining a CHECKSUM values, but it is acceptable.

Find all databases which are not configured for CHECKSUM verification:

USE master
GO

SELECT NAME
        ,page_verify_option_desc
FROM master .sys.databases
WHERE page_verify_option_desc != 'CHECKSUM'
GO

Enable CHECKSUM for your Database:

ALTER DATABASE Database_Name
SET PAGE_VERIFY CHECKSUM WITH NO_WAIT
GO

Important Note:
Once you enable and CHECKSUM for your database, It does not instantly add CHECKSUMs to your existing data pages in the database. You have to read each page using INSERT/UPDATE/DELETE or simply you can execute REBUILD option for your indexes.

Other related articles:

SQL Server: Monitor and Manage Database Corruption

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

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

PostgreSQL provides two ways to perform Reindexing on Database.

Using REINDEX command:

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

Reindex all indexes of Database:

REINDEX DATABASE Database_Name;

Reindex on particular Index:

REINDEX INDEX Index_Name;

Reindex on particular Table:

REINDEX TABLE Table_Name;

Using REINDEXDB.EXE utility:

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

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

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

Reindex all Database of PostgreSQL Server:

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

Reindex on particular Database:

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

Reindex on particular Table:

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

In this post, I am sharing SQL Server Database Administrator script for rebuilding all Indexes of a Database.

To Rebuild or Reorganize the Indexes is a very common task for DBA.
If Index fragmentation is increasing, periodically it requires executing Rebuild Index for better performance.

If we want to Rebuild all Indexes of a Database, we should build and generate the script because using default command we can only perform Rebuild operation on table level.

SQL Server: Script to find Index Average Fragmentation in Percentage

In below script, I commented Fill Factor related changes, and If anyone wants, they uncomment it.
Please SELECT your database and execute the below script.

Note: Database REBUILD INDEX is a very costly operation and It requires an exclusive lock on table so please aware yourself before executing it.

DECLARE @DatabaseName SYSNAME   = DB_NAME()
DECLARE @TableName VARCHAR(256) 
--DECLARE @FILLFACTOR INT = 85
DECLARE @SQL NVARCHAR(MAX) =

 'DECLARE curAllIndex CURSOR FOR SELECT TABLE_SCHEMA +
 ''.'' + TABLE_NAME AS TABLENAME  
 FROM ' + @DatabaseName + '.INFORMATION_SCHEMA.TABLES WHERE
 TABLE_TYPE = ''BASE TABLE'''  
 
BEGIN 
  EXEC sp_executeSQL @SQL  
  OPEN curAllIndex
  FETCH NEXT FROM curAllIndex INTO @TableName  
  WHILE (@@FETCH_STATUS = 0) 
  BEGIN  
       /* -- For using FillFactor setting. 
	   SET @DynamicSQL = 'ALTER INDEX ALL ON ' + @TableName +  
	   ' REBUILD WITH (FILLFACTOR = ' + CONVERT(VARCHAR,@FILLFACTOR) + ')' 
	   */
	   SET @SQL = 'ALTER INDEX ALL ON ' + @TableName +  
	   ' REBUILD ' 
       PRINT @SQL       
       EXEC sp_executeSQL @SQL 
       FETCH NEXT FROM curAllIndex INTO @TableName  
   END   
   CLOSE curAllIndex  
   DEALLOCATE curAllIndex 
END