Truncate Table Statement (Difference between Truncate and Delete)

Thursday, August 28, 2008 2 comments

Truncate table statement can delete all record of table. There is no where clause uses with truncate command. Delete command removes record for the table and put entry in transaction log of every deleted record. Truncate table removes the data by de-allocating the data pages and records only the page de-allocations in the transaction log. Table records are store in data pages.
The actual data in your table is stored in Data Pages. The Page is the smallest unit of data storage in Microsoft SQL Server. A page contains the data in the rows. A row can only reside in one page. Each Page can contain 8KB of information, due to this; the maximum size of a Row is 8KB. A group of 8 adjacent pages is called an extent.
For better explanation of data pages, we take one example. Suppose I have 100 records in Employee table. These 100 records divided into 10 pages.
Records (rows of a table) keep in data page. After using truncate command, every pages deallocation entry would be maintain in transaction log. Truncate command can also be roll back. When we roll back the Truncate command, de-allocated pages would be roll back

For Example:- tbl_Employee table has 100 records. After executing the first 2 step, record would be zero in tbl_Employee table.
1) Begin Transaction
2) TRUNCATE TABLE tbl_Employee
Run the following select command for verifying the output.
3) Select * from tbl_Employee
Result would be zero record.
Now rollback the transaction
4) Rollback Transaction
Run the following select command again and find the output of 100 records.
5) Select * from tbl_Employee

Truncate command has following advantage over Delete command

->The DELETE command removes rows one at a time and records an entry in the transaction log for each deleted row. TRUNCATE command removes the data by de-allocating the data pages (used to store the table data) and records only the page de-allocations in the transaction log.

->When the DELETE command is executed using a row lock, each row in the table is locked for deletion. TRUNCATE command always locks the table and page, not each row.

->Truncate command de-allocates the pages that why it is faster than delete command.

->After a DELETE statement is executed, the table can still contain empty pages. For example, empty pages in a heap cannot be de-allocated. For indexes, the delete operation can leave empty pages behind, although these pages will be de-allocated quickly by a background cleanup process.

TRUNCATE TABLE command removes all rows from a table, not the structure (columns, constraints, indexes, etc) of the table. Table structure and its columns, constraints, indexes, etc remain as it is. To remove the table definition, structure and its data in one go, use the DROP TABLE statement.

Truncate table has following limitation

->You can’t use TRUNCATE TABLE statement on a table which is referenced by a FOREIGN KEY constraint. (You can truncate a table that has a foreign key that references itself.)

->You can’t use “where” clause with TRUNCATE TABLE statement.

Truncate command de-allocates the pages which hold multiple records that why we can’t use “where” clause with truncate command.

Delete Duplicate Records from Table in SQL Server

Wednesday, August 13, 2008 0 comments

I have found the best way to delete duplicate records in a table which has IDENTITY Column. For example, we have an employee table which has duplicate data of EmployeeName and Salary field.

TableName : tbl_Employee

Field Name -------------- FieldType
---------------------------------------------------
EmployeeID ------------- int (IDENTITY)
EmployeeName ----------varchar(50)
Salary --------------------int


Table Records

EmployeeID EmployeeName Salary
----------------------------------------------------------------
1 ----------- AAA ----------- 15000
2 ----------- BBB ----------- 10000
3 ----------- CCC ------------20000
4 ----------- BBB ----------- 10000
5 ----------- CCC ----------- 20000
6 ----------- AAA ---------- 15000
7 ----------- BBB ----------- 10000


DELETE
FROM tbl_Employee
WHERE EmployeeID NOT IN
(
SELECT MAX(EmployeeID)
FROM tbl_Employee
GROUP BY EmployeeName, Salary)


Output ( After executing this query)
---------------------------------------------------------------------------------------


EmployeeID EmployeeName Salary
----------------------------------------------------------------
5 ----------- CCC ----------- 20000
6 ----------- AAA ---------- 15000
7 ----------- BBB -----------10000

Another way

We can do it in another way when table has not any Identity field. First we have to insert the unique record by using distinct command.

Select distinct * into tempEmployee from tbl_Employee

Now delete all record from tbl_Employee

Truncate table tbl_Employee

Now insert unique record in tbl_Employee table from tmpEmployee.

Insert into tbl_Employee
Select * from tempEmployee

After that we can drop that temporary table.

Drop table tempEmployee

I know only these two ways if anyone know any other way. Please share his/her knowledge.

Maximum Capacity Specifications for SQL Server 2000 and SQL Server 2005

Wednesday, July 30, 2008 0 comments

The following table specifies the maximum sizes and numbers of various objects defined in SQL Server 2000/2005 databases or referenced in Transact-SQL statements. The table does not include Microsoft SQL Server 2000 Windows CE Edition and Microsoft SQL Server 2005 Windows CE Edition.
1 Network Packet Size is the size of the tabular data stream (TDS) packets used to communicate between applications and the relational Database Engine. The default packet size is 4 kilobytes (KB), and is controlled by the network packet size configuration option.

2 The maximum number of bytes in any index key cannot exceed 900 in SQL Server 2005. You can define a key using variable-length columns whose maximum sizes add up to more than 900, provided no row is ever inserted with more than 900 bytes of data in those columns. In SQL Server 2005, you can include nonkey columns in a nonclustered index to avoid the maximum index key size of 900 bytes.

3 Database objects include objects such as tables, views, stored procedures,user-defined functions, triggers, rules, defaults, and constraints.The sum of the number of all objects in a database cannot exceed 2,147,483,647.

4 Although a table can contain an unlimited number of FOREIGN KEY constraints, the recommended maximum is 253. Depending on the hardware configuration hosting SQL Server, specifying additional foreign key constraints may be expensive for the query optimizer to process.

5 This value is for static lock llocation. Dynamic locks are limited only by memory.

6 If a stored procedure accesses more than 8 databases, or more than 2 databases in interleaving, you will receive an error.

7 If the table contains one or more XML indexes, the clustering key of the user table is limited to 15 columns because the XML column is added to the clustering key of the primary XML index. In SQL Server 2005, you can include nonkey columns in a nonclustered index to avoid the limitation of a maximum of 16 key columns.

8 SQL Server 2005 supports row-overflow storage which enables variable length columns to be pushed off-row. Only a 24-byte root is stored in the main record for variable length columns pushed out of row; because of this, the effective row limit is higher than in previous
releases of SQL Server. SQL Server 2005 Books Online.


References:

SQL Server 2005 Books Online

Introduction of SQL Server Integration Services in SQL Server 2005

Wednesday, July 16, 2008 0 comments

SQL Server took a leap forward in database maintenance functionality with the introduction of SSIS (SQL Server Integration Services) in SQL Server 2005. The SQL Server Development Team at Microsoft adapted SSIS to offer point-and-click database maintenance, offering vast improvements over DTS (Database Transformation Services) and SQLMaint in SQL Server 2000. The Database Maintenance Wizard still exists to build the initial process, but the modifications are all made to an SSIS package stored locally on the server. Compared to the SQLMaint black box, the new interface will be easier to understand and less intimidating for DBAs. Therefore, database maintenance will be conducted on a more regular basis and overall performance will improve; a little SQL Server care and attention can go along way in improving performance.
That is not to say that DBAs following sophisticated maintenance regimens should abandon them; they should just leverage SSIS' new functionality to simplify the maintenance process. I wholeheartedly praise database administrators who have built such maintenance plans, but I have also worked with DBAs who have no procedures in place. I believe the SSIS interface offers a key stepping stone toward performing regularly scheduled maintenance.In turn, this plan should ensure that overall SQL Server performance is at a consistently high level to suit the organization.