Fill Factor and Too Much Space Used

Question

Okay, I am on sql server 2012 sp2.  I am doing a simple update on some large tables where there is an int column that allows nulls and I am changing the null values to be equal to the values in another integer column in the same table.  (Please
don't ask why I am doing dup data as that is a long story!)  
So it's a very simple update and these tables are about 65 million rows I believe and so you can calculate how much space it should increase by.  Basically, it should increase by 8 bytes * 65 million = ~500Mbytes, right?
However, when I run these updates the space increases by about 3 G per table.  What would cause this behavior?
Also, the fill factor on the server is 90% and this column is not in the PK or any of the 7 nonclustered indexes.  The table is used in horizonal partitioning but it is not part of the constraint.
Any help is much appreciated...

Answer 1

Hi CLM,
some information to the INT data type before going into detail of the "update process":
an INT datatype is 4 bytes not 8!
an INT datatype is a fixed length data type
Unfortunatley we don't know anything about the table structure (colums, indexes) but based on your observation I presume a table with multiple indexes. Furthermore I presume a nonclustered non unique index on the column you are updating.
To understand why an update of an INT attribute doesn't affect the space of the table itself you need to know a few things about the record structure. The first 4 bytes of a record header describe the structure and the type of the record! Please take the
following table structure (it is a HEAP) as an example for my ongoing descriptions:
CREATE TABLE dbo.demo
Id INT NOT NULL IDENTITY (1, 1),
c1 INT NULL,
c2 CHAR(100) NOT NULL DEFAULT ('just a filler')
The table is a HEAP with no indexes and the column [c1] is NULLable. After 10,000 records have been added to the table...
SET NOCOUNT ON;
GO
INSERT INTO dbo.demo WITH (TABLOCK) DEFAULT VALUES
GO 10000
... the record structure for the first record looks like the following. I will first evaluate the position of the record and than create an output with DBCC PAGE
SELECT pc.*, d.Id, d.c1
FROM dbo.demo AS d CROSS APPLY sys.fn_PhysLocCracker(%%physloc%%) AS pc
WHERE d.Id = 1;
In my example the first record allocates the page 168. To examine this page you can use DBCC PAGE but keep in mind that it isn't documented. You have to enable the output of DBCC PAGE by usage of DBCC TRACEON with the TF 3604.
DBCC TRACEON (3604);
DBCC PAGE (demo_db, 1, 168, 1);
The output of the above command shows all data records which are allocated on the page 168. The next output represents the first record:
Slot 0, Offset 0x60, Length 115, DumpStyle BYTE
Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Record Size = 115
The above output shows the record header which describes the type of record and it gives some information about the structure of the record. It is a PRIMARY RECORD which contains NULLable columns. The length of the record is 115 bytes.
The next ouptput shows the first bytes of the record and its logical solution:
10 00 PRIMARY RECORD and NULLable columns
70 00 OFFSET for information about number of columns (112)
01 00 00 00 Value of ID
00 00 00 00 Value of C1
6a757374 Value (begin) of C2
If might be complicate but you will get a very good explanation about the record structures in the the Book "SQL Server Internals" from Kalen Delaney.
The first two bytes (0x1000 describe the record type and its structure. Bytes 3 and 4 define the offset in the record where the information about the number of columns can be picked up. As you may see from the value it is "far far" near the end of the record.
The reason is quite simple - these information are stored BEHIND the fixed length data of a record. As you can see from the above "code" the position is 112. 112 - 4 bytes for the record header is 108. Id = 4 + C1 = 4 + C2 = 100 = ??? All the columns are FIXED
length columns so is it with C1 because it has a fixed length data size!
The next 4 bytes represent the value which is stored in Id (0x01000000) which is 1. C1 is filled with placeholders for a possible value. If we update it with a new value the preallocated space in the record structure will be filled and NO extra space will
be used. So - based on the simple table structure - a growth WILL NOT OCCUR!
Based on the given finding the question is WHAT will cause additional allocation of space?
It can only be nonclustered indexes. Let's assume we have an index on c1 (which is full of NULL). If you update the table with values the NCI will be updated, too. For each update from NULL to Value a new record will be added to the NCI. What is the size
of the new record in the NCI?
We have the record header which is 4 bytes. If the table is a heap we have to deal with a RID it is 8 bytes. If your table is a Clustered index the size depends on the size of the Clustered Key(s). If it is only an INT it is 4 bytes. In the given example
I have to add 8 Bytes because it is a HEAP!
On top of the - now 12 bytes - we have to add the size of the column itself which is 4 bytes. Last but not least additional space will be allocated if the index isn't unique (+4 bytes) allows NULL, ...
In the given example a nonlclustered index will consume 4 bytes for the header + 8 bytes for the RID + 4 bytes for C1 + 4 bytes if the index isn't unique + 2 bytes for the NULLable information! = 22 bytes!!!
Now calculate the size by your number of records. And next ... - add the calculated size for EACH additional record and don't forget page splits, too! If the values for the index are not contigious you will have hundreds of page splits when the data will
be added to the index(es) :). In this case the fill factor is worthless because of the huge amount of data...
Get more information about my arguments here:
Calculation of index size:
http://msdn.microsoft.com/en-us/library/ms190620.aspx
Structure of a record:
http://www.sqlskills.com/blogs/paul/inside-the-storage-engine-anatomy-of-a-record/
PS: I remember my first international speaker engagement which was in 2013 in Stockholm (Erland may remember it!). I was talking about the internal structures of the database engine as a starting point for my "INSERT / UPDTAE / DELETE - deep dive" session.
There was one guy who asked in a quite boring manner: "For what do we need to know this nonsence?" I was stumbeling because I didn't had the right answer to this. Now I would answer that knowing about record structure and internals you can calculate in a quite
better way the future storage size :)
You can watch it here but I wouldn't recommend it :)
http://www.sqlpass.org/sqlrally/2013/nordic/Agenda/VideoRecordings.aspx
MCM - SQL Server 2008
MCSE - SQL Server 2012
db Berater GmbH
SQL Server Blog (german only)