Skip to main content

Does Clustered Index physically orders the data within a table?

Quite a lot of time I have come across people saying "Clustered Index Physically sorts the data inside the table based on the Clustered Index Keys". It's not completely true!

The short answer to them is there is something called "Row offset Array" in a PAGE which manages the order of rows in a PAGE.

For a long answer with a sample script read on...

There can lot of rows inserted one after the other and as we know each row can vary in size. That being the case how does SQL Server know where a row begins and where does it end?

That's where ROW OFFSET table/array comes into picture. A ROW OFFSET array starts at the end of the PAGE, and it contains one entry for each row on the PAGE. Each entry records how far the first Byte of the row is from the start of the PAGE. The entries in the row offset table are in reverse sequence from the sequence of the rows on the PAGE.

CREATE TABLE ci_order_example
(
Sno INT NOT NULL PRIMARY KEY,
Fname VARCHAR(20) NOT NULL
)
GO


INSERT INTO ci_order_example
SELECT 10, 'Vadivel' UNION ALL 
SELECT 12, 'Sailakshmi' UNION ALL
SELECT 31, 'Alpha' 
GO

Lets see how the data has got stored internally. I am testing all this in my testing database named 'TestBed'.

--The below command will inform SQL Server to return the results to the client/console
--instead of to the error log!
DBCC TraceOn(3604)
GO

--We got to make use of DBCC IND for finding out the page IDs to look at using DBCC PAGE
--Pick the PagePID (the page number in the file) whose IAMFID / IAMPID is not NULL
DBCC IND ('TestBed', 'ci_order_example', 1)
GO



--The Offset Table section shows the contents of the row offset array at the end of the page
-- first row will be indicated as Slot 0
DBCC PAGE ('TestBed',1,243,2)
GO


In the above example, while inserting, the records got inserted in these order. Because these records are already entered in a sorted fashion you can see it is in a sequence :)

0 - 96 - Vadivel
1 - 118 - Sailakshmi
2 - 143 - Alpha

Let's add few more records and then check how the records have got stored now.

INSERT INTO ci_order_example
SELECT 1, 'Sneha' UNION ALL
SELECT 2, 'Amala Paul'
GO


DBCC PAGE ('TestBed',1,243,2)
GO



You can see that the place the record got added that location is not changed at all. Instead based on the clustered index key it maintains the correct order within this Row Offset table/array.

0 - 163 - Sneha
1 - 183 - Amala Paul
2 - 96 - Vadivel
3 - 118 - Sailakshmi
4 - 143 - Alpha

Hope this post would help get this misconception cleared (or) Can i say we have tried answering to one of the many SQL Server Myths :)

Comments

Dhananjay said…
then why "select * from tbl" when clustered indexed shows the rows in sorted order ?

Popular posts from this blog

Registry manipulation from SQL

Registry Manupulation from SQL Server is pretty easy. There are 4 extended stored procedure in SQL Server 2000 for the purpose of manupulating the server registry. They are: 1) xp_regwrite 2) xp_regread 3) xp_regdeletekey 4) xp_regdeletevalue Let us see each one of them in detail! About xp_regwrite This extended stored procedure helps us to create data item in the (server’s) registry and we could also create a new key. Usage: We must specify the root key with the @rootkey parameter and an individual key with the @key parameter. Please note that if the key doesn’t exist (without any warnnig) it would be created in the registry. The @value_name parameter designates the data item and the @type the type of the data item. Valid data item types include REG_SZ and REG_DWORD . The last parameter is the @value parameter, which assigns a value to the data item. Let us now see an example which would add a new key called " TestKey ", and a new data item under it called TestKeyValue :

Screen scraping using XmlHttp and Vbscript ...

I wrote a small program for screen scraping any sites using XmlHttp object and VBScript. I know I haven't done any rocket science :) still I thought of sharing the code with you all. XmlHttp -- E x tensible M arkup L anguage H ypertext T ransfer P rotocol An advantage is that - the XmlHttp object queries the server and retrieve the latest information without reloading the page. Source code: < html > < head > < script language ="vbscript"> Dim objXmlHttp Set objXmlHttp = CreateObject("Msxml2.XMLHttp") Function ScreenScrapping() URL == "UR site URL comes here" objXmlHttp.Open "POST", url, False objXmlHttp.onreadystatechange = getref("HandleStateChange") objXmlHttp.Send End Function Function HandleStateChange() If (ObjXmlHttp.readyState = 4) Then msgbox "Screenscrapping completed .." divShowContent.innerHtml = objXmlHttp.responseText End If End Function </ script > < head > < body > &l

Script table as - ALTER TO is greyed out - SQL SERVER

One of my office colleague recently asked me why we are not able to generate ALTER Table script from SSMS. If we right click on the table and choose "Script Table As"  ALTER To option would be disabled or Greyed out. Is it a bug? No it isn't a bug. ALTER To is there to be used for generating modified script of Stored Procedure, Functions, Views, Triggers etc., and NOT for Tables. For generating ALTER Table script there is an work around. Right click on the table, choose "Modify" and enter into the design mode. Make what ever changes you want to make and WITHOUT saving it right click anywhere on the top half of the window (above Column properties) and choose "Generate Change Script". Please be advised that SQL Server would drop actually create a new table with modifications, move the data from the old table into it and then drop the old table. Sounds simple but assume you have a very large table for which you want to do this! Then it woul