Table has 85 GB data space, zero rows

Question

This table has only one column. I ran a transaction that inserted more than a billion rows into this table but then rolled it back before completion.
This table currently has zero rows but a select statement takes about two minutes to complete, and waits on I/O.
The interesting thing here is that previous explanations to this were ghost records in case of deletes,
there are none. m_ghostRecCnt is zeroed for all data pages.
This is obviously not a situation in which the pages were placed in a deferred-drop queue either, or else the page count would be decreasing over time, and it is not.
This is the output of DBCC PAGE for one of the pages:
PAGE: (3:88910)
BUFFER:
BUF @0x0000000A713AD740
bpage = 0x0000000601542000          bhash = 0x0000000000000000          bpageno = (3:88910)
bdbid = 35                          breferences = 0                    
bcputicks = 0
bsampleCount = 0                    bUse1 = 61857                      
bstat = 0x9
blog = 0x15ab215a                   bnext = 0x0000000000000000          
PAGE HEADER:
Page @0x0000000601542000
m_pageId = (3:88910)                m_headerVersion = 1                 m_type = 1
m_typeFlagBits = 0x0                m_level = 0                        
m_flagBits = 0x8208
m_objId (AllocUnitId.idObj) = 99    m_indexId (AllocUnitId.idInd) = 256
Metadata: AllocUnitId = 72057594044416000                                
Metadata: PartitionId = 72057594039697408                                Metadata: IndexId = 0
Metadata: ObjectId = 645577338      m_prevPage = (0:0)                  m_nextPage = (0:0)
pminlen = 4                         m_slotCnt = 0                      
m_freeCnt = 8096
m_freeData = 7981                   m_reservedCnt = 0                   m_lsn
= (1010:2418271:29)
m_xactReserved = 0                  m_xdesId = (0:0)                    m_ghostRecCnt
= 0
m_tornBits = -249660773             DB Frag ID = 1                      
Allocation Status
GAM (3:2) = ALLOCATED               SGAM (3:3) = NOT ALLOCATED          
PFS (3:80880) = 0x40 ALLOCATED   0_PCT_FULL                              DIFF (3:6) = CHANGED
ML (3:7) = NOT MIN_LOGGED           
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Querying the allocation units system catalog shows that all pages are counted as "used".
I saw some articles, such as the ones listed bellow, which addresses similar situations where pages arent deleted in a HEAP after a delete operation. It turns out pages are only deleted in a table when a table level lock is issued.
http://blog.idera.com/sql-server/howbigisanemptytableinsqlserver/
http://www.sqlservercentral.com/Forums/Topic1182140-392-1.aspx
https://support.microsoft.com/kb/913399/en-us
To rule this out, I inserted another 100k rows which caused no change on page counts, and then deleted all entries with a TABLOCK query hint. Only one page was deleted.
So, it appears we have a problem with pages that were created during a transaction that was rolled back, huh? I guess rolling back a transaction doesn't take certain physical factors into consideration.
I've looked everywhere but couldn't find a satisfactory answer to this. Does anybody have any ideas?
Just because there are clouds in the sky it doesn't mean it isn't blue. Some people would disagree.

Answer 1

And this is the reason why you should have heaps (unless your name is Thomas Kejser :-).
Try TRUNCATE TABLE. Or ALTER TABLE tbl REBUILD.
Erland Sommarskog, SQL Server MVP, [email protected]
I rebuilt the HEAP a while ago, and then all pages were gone. I don't know if TRUNCATE would have the same results, I would have to repeat the test to find that out. There are many ways to fix the problem itself, including creating a clustered index as Satish
suggested.
Id like to focus on this interesting fact I wanted to bring to the table for discussion: You open a transaction, insert a huge load of records and then roll back. Why would the engine leave the pages created during the transaction behind? More specifically,
why would they not be marked as "free pages" if they are all empty? Why are they not marked as free so scans would skip them and not generate a lot of I/O throughput and long response times just to query a zero row table? Isn't this like a design
flaw or a bug?
Just because there are clouds in the sky it doesn't mean it isn't blue. But someone will come and argue that in addition to clouds, birds, airplanes, pollution, sunsets, daltonism and nuclear bombs, all adding different colours to the sky, this
is an undocumented behavior and should not be relied upon.