Question

We have a table that has a blob column along with other simple fields. Number of rows is about 6K, and sum of length of the blob column for all rows accounted for about 30MB. however when we ran a query to find the actual table space occupied, it was about 10GB(Database size itself is 11GB). We are wondering if,

1. Would aborting transaction still block the space allocated for blob as though it’s committed?

2. Though number of records did not increase significantly, size of database jumps from 2GB to about 1OGB in couple of days. Running the query to find the real table space showed that the single table which had the blob, had about 8GB of data (there are only 6K records and sum of datalength of the blobs gives only 30MB).

Anything we can do to resolve the space issue and address why sizeof of database has to increase so much?

Answer 1

Would aborting transaction still block
the space allocated for blob as though
it’s committed?

Index physical changes occur on separate transactions from logical changes. When an INSERT needs to allocate a new page for the table in order to acomodate the new row, the page allocation occurs on a different transaction that is immediately commited. If the INSERT rolls back, the page allocation is unaffected. Think what would happen if the page allocation would be rolled back and another insert had already allocated a different row slot in it and commited that insert.

Things are a bit more complicated, specially for BLOB storage hobts, but the idea is that a high rate of modifications in the BLOB columns may cause a high ratio of unused pages. A high rate of rollbacks may accentuate the problem. sys.allocation_units will easily reveal this if total_pages is much higher than used_pages for allocation units of type 2 and 3.

You can try an (online) index rebuild macking sure LOB_COMPACTION is ON.