Space did not gets released after removing data

Question

Space did not gets released after removing data

SQLAli

Ten Centuries

Points: 1109
More actions
November 21, 2013 at 6:52 pm

#286564

Hi,
We have deleted 120GB of data but space did not released even after 2 days. Is there any reason for this? Could any one tell me how exactly it releases the space after truncating a 120GB table?
Thanks.
Thanks,
I’m nobody but still I’m somebody to someone………….

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1004339 More actions · Answer 1

SQLAli (11/21/2013)
Hi,
We have deleted 120GB of data but space did not released even after 2 days. Is there any reason for this? Could any one tell me how exactly it releases the space after truncating a 120GB table?
Thanks.

Space is not deleted from the database after deletes or truncates. It simply becomes unallocated space in the database. Do you have enough room on disk without recovering this space as truly "free space"?

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

pietlinden SSC Guru Points: 63503 More actions · Answer 2

If you absolutely have to get the disk space free, then you can use SHRINKDATABASE or SHRINKFILE, but it does awful things to your databases. You have to reindex them all etc... not pretty. So only do it if you have to. Definitely read up on it in BOL before doing anything drastic like that.

SQLAli Ten Centuries Points: 1109 More actions · Answer 3

Pietlinden,

Yes, we shrunk the .mdf and alert moves to Warning from centreon. But i think it is not right resolution.

Jeff,

I understand that space will simply unallocated rather than releasing. But disk got only 9GB free space. I need at least 50 GB of free space.

Thanks,
I’m nobody but still I’m somebody to someone………….

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 4

SQLAli (11/21/2013)
Pietlinden,
Yes, we shrunk the .mdf and alert moves to Warning from centreon. But i think it is not right resolution.

If you really do want to release space back to the OS, it's the *only* resolution.

I understand that space will simply unallocated rather than releasing. But disk got only 9GB free space. I need at least 50 GB of free space.

Why? What good does 50GB do sitting unallocated and unused on a disk do? You might as well make the disk 50GB smaller.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Steve Jones - SSC Editor SSC Guru Points: 736188 More actions · Answer 5

I'm with Gail on this. If you need the space, then shrink the files, but make sure that you leave space to reindex or perform maintenance.

If you just want xxx space to prevent alarms, you should really evaluate whether you need more space on the drive. If it's for backups, please, please don't store these on the disk with the mdf.

SumLasty SSCommitted Points: 1923 More actions · Answer 6

Did you try rebuilding table including all the indexes? That would release space to database, then shinking file would relase space at OS.

SQLAli Ten Centuries Points: 1109 More actions · Answer 7

Suneel,

No i did not try to rebuild the indexes. As i explained before i just shrunk the .mdf and space gets released.

Thanks,
I’m nobody but still I’m somebody to someone………….

Jeff Moden SSC Guru Points: 1004339 More actions · Answer 8

SQLAli (12/16/2013)
Suneel,
No i did not try to rebuild the indexes. As i explained before i just shrunk the .mdf and space gets released.

You're pretty well screwed then because, except for simple truncation during a shrink, shrink fragments nearly everything to 99% fragmented. You at least need to follow a shrink with a REORGANIZE (although that will only fix the Leaf Level of the indexes and data). Since REORGANIZE doesn't update stats, you should update the stats, as well.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)