I have created a table on SQL Server then inserted 135 million records in that table.
then I truncate it
then tried to re-insert the same 135 million records again.
but something went wrong and had to restart the computer
I got the recovery mode in my database.
then fixed.
the problem now is C drive has 10GB free only (210GB used) while before that I used to have 105GB free!
I checked folders but the sum of all sizes including hidden ones does not sum to 210GB
what happened and where did these GBs have gone?
The space is not automatically released by the database. In the case of tempdb, if you restart the sql service, tempdb will reinitialize to original size. But, not the case for other databases.
If you want to reclaim the space, there are two approaches:
Cleaner approch:
As suggested by Paul Randal, go for new filegroup for existing tables and then drop the old filegroup.Refer to his article
Create a new filegroup
Move all affected tables and indexes into the new filegroup using the CREATE INDEX … WITH (DROP_EXISTING = ON) ON syntax, to move the
tables and remove fragmentation from them at the same time
Drop the old filegroup that you were going to shrink anyway (or shrink it way down if its the primary filegroup)
Brute Force approach and redmediation
Here, you can use DBCC SHRINKFILE and reduce the size. Keep little more space in the database to avoid frequent autogrowth. Beware that, shrinking file will lead to index fragmentation and you have to rebuild indexes post the shrinking of files.
As Paul Randal recommends:
If you absolutely have no choice and have to run a data file shrink
operation, be aware that you’re going to cause index fragmentation and
you might need to take steps to remove it afterwards if it’s going to
cause performance problems. The only way to remove index fragmentation
without causing data file growth again is to use DBCC INDEXDEFRAG or
ALTER INDEX … REORGANIZE. These commands only require a single 8KB
page of extra space, instead of needing to build a whole new index in
the case of an index rebuild operation (which will likely cause the
file to grow).
Related
I have 2 databases from which I have deleted rows in a specific table in order to decrease the size of the database.
After deleting, the size of DB.mdf does not change.
I also tried to rebuild the index and used cleantable, but to no effect!
ALTER INDEX ALL ON dbo.'Tablename' REBUILD
DBCC CLEANTABLE ('DBname', 'Tablename', 0)
Deleting rows in a database will not decrease the actual database file size.
You need to compact the database after row deletion.
Look for this
After running this, you'll want to rebuild indexes. Shrinking typically causes index fragmentation, and that could be a significant performance cost.
I would also recommend that after you shrink, you re-grow the files so that you have some free space. That way, when new rows come in, they don't trigger autogrowth. Autogrowth has a performance cost and is something you would like to avoid whenever possible.
You need to shrink the db. Right click db, Tasks->Shrink database
Even I faced the same issue, my db was 40MB after deleting some columns still its size was not getting changed..
I installed SQLManager then opened my db and used command 'vaccum' that cleaned my db and its size got reduced to 10MB.
I wrote this after being in the exact same scenario and needing to shrink the database. However, not wanting to use DBCC SHRINFKILE I used Paul Randals method of shrinking the database.
https://gist.github.com/tcartwright/ea60e0a38fac25c847e39bced10ecd04
I have a SQL Server database of size 270GB. Almost 91% of the space is showing up as UNUSED in space report. I know unused space is space allocated to a particular object. App team did a purge operation on the DB but we couldn't really claim space with that.
I have checked index fragmentation on the table but they look good.. What else i need to be checking and what is that i should do to release that space. The DB is not going to use that space anytime in future.
As per my understanding DBCC SHRINKFILE releases only unallocated space. I've read about DBCC CLEANTABLE and DBCC SHRINK DATABASE but not sure if it's good enough to perform.
How to effectively release unused space from objects.
So to my understanding, you first need to shrink the files, then you can shrink the DB:
Using SQL Server Management Studio:
Shrink the files: r-click on DB, 'Tasks', 'Shrink', 'Files': Then pick a new file size value slightly larger than the 'Minimum is' value given in the dialog.
Shrink the database: r-click on DB, 'Tasks', 'Shrink', 'Database' (tick the 'Reorganize files checkbox)
With this, I was able to reduce the percentage of 'unused' space in the Disk report. There is still quite some left though (20%) .. I think 'reorganizing' some indices might help.
If there are only indexes in your database then you can drop your old filegroup after creating a new filegroup and moving all indexes into it.you can move the indexes using CREATE INDEX ... WITH DROP_EXISTING
I have an application that logs to a DB2 database. Each log is stored in a daily table, meaning that I have several tables, one per each day.
Since the application is running for quite some time, I dropped some of the older daily tables, but the disk space was not reclaimed.
I understand this is normal in DB2, so I goggled and found out that the following command can be used to reclaim space:
db2 alter tablespace <table space> reduce max
Since the tablespace that store the daily log tables is called USERSPACE1, I executed the following command successfully:
db2 alter tablespace userspace1 reduce max
Unfortunately the disk space used by DB2 instance is still the same...
I've read somewhere that the REORG command can be executed, but what I've seen it is used to reorganize tables. Since I dropped the tables, how can I use REORG?
Is there any other way to do this?
Thanks
Reduce the size of a tablespace is very complex. The extents (set of contiguous pages; unit of tablespace allocation) of the tables are not distributed sequentially for a same table. When you reorg a table, the rows will be organized in pages, and the new pages will be written normally at the end of the tablespace. Sometimes, the high watermark will be increased, and your tablespace will be bigger.
You need to reorg all tables from a tablespace in order to "defrag" all tables. Then, you have to perform a new reorg in order to use the previous space, because it should be an empty space in the tablespace.
However, there are many criteria that impacts the organization of the tables in a tablespace: New extents are created (new rows, rows overflow due to updates); compression could be activated after reorg.
What you can do is to assign few or just one table per tablespace; however, you will waste a lot of space (overhead, empty pages, etc.)
The command that you are using is an automatic way to do that, but it does not always work as desired: http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.admin.dbobj.doc/doc/c0055392.html
If you want to see the distribution of the tables in your tablespace, you can use db2dart. Then, you can have an idea of which table to reorg (move).
Sorry guys,
The command that I mentioned on the original post works after all, but the space was retrieved very slowly.
Thanks for the help
I'm trying to migrate my pretty big db on SQLServer 2008 from one drive to another with minimum downtime and have some issues.
So , basically, my plan is to use DBCC SHRINKFILE ('filename', EMPTYFILE) for extent movement.
After some period of time, I shrink this file to avoid some space problems with log shipping db's in other server.
Huge amount of extents were moved successfully, but then I've got this error
DBCC SHRINKFILE: System table SYSFILES1 Page 1:21459450 could not be moved to other files because it only can reside in the primary file of the database.
Msg 2555, Level 16, State 1, Line 3
Cannot move all contents of file "filename" to other places to complete the emptyfile operation.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
So, what I've tried already:
manually make my db bigger by adding empty space(just make file bigger by altering database)
work a little bit with files in SECONDARY filegroup
work with db after full\transactional backup
And this didn't work.
Can someone help me to fix this?
Thanks a lot.
As the error message states, there are some things that need to reside in the PRIMARY filegroup. Use the information in sys.allocation_units to find out what user (as opposed to system) objects are still in PRIMARY and move them with create index … with (drop_existing = on) on OTHER_FILEGROUP. Once you've moved all of your objects, you should be able to shrink the file down to as small as it can possibly be. Your final step will be to incur the downtime to move the primary file (in this case, minimal downtime does not mean "no downtime"). Luckily, what actually needs to reside in PRIMARY isn't very much data, so the downtime should be small. But you'll have a good idea once you get everything out of there.
While you're at it, set the default filegroup for your database to something other than primary to avoid putting user objects there in the future.
Using SQL Server 2012 Entreprise.
I have a table of 12 billion rows that takes 700GB on disk, in 30 partitions.
It has only one index, clustered.
I have 500 GB free disk space.
I disabled the index (please don't ask why. If you have to know, I targeted the wrong database).
I now want to enable the index. If I do
alter index x1 on t1 rebuild
I eventually get an error because there is not enough free disk space. That was a painful lesson about disk space requirements for rebuilding a clustered index.
Ideally, I want to rebuild the index one partition at a time. If I do
alter index x1 on t1 rebuild partition = 1
I get the error: Cannot perform the specified operation on disabled index.
Any solution, besides buying more physical disks? The table has not changed since disabling the index (can't be accessed anyway), so I am really looking for a hack that can fool SQL into thinking the index is enabled. Any suggestions?
Thanks
If its a clustered index that you have disabled you have effectively disabled the table the only operations you can execute on this table is "drop" or "rebuild" as far as i am aware.
you could try the deprecated dbbc dbreindex command, maybe you are lucky and it rebuilds more disk space efficiently. Also you might squeeze some more space out if you set a fill factor to 100 when you rebuild. assuming you database table is now only being read.
DBCC DBREINDEX ('Person.Address', 'PK_Address_AddressID', 100)
allows you to reindex just the clustered index.