问题
I have recently done some archiving of my data, and performed the following:
I had a database table that had over 33 million records, many of which were duplicates.
I backed up the table and inserted the unique data into a new table, then renamed/swapped the table names, this achieved what I needed.
Now however I am left with two tables...
- Table1 (good/live table) - 10 million records
- Table1_Backup (backup table) - 33 million records
After doing this my SQL mdf/data file has rose to 319.7 GB, and my Log file has rose to 182 GB.
This has taken most of my free OS space and my D drive is now low on space.
My question is, once I am happy with the archive data I am going to delete the _backup table just leaving my good live table.
But as I understand it SQL will not give me back any free space to the OS, what is the best way to reclaim that space from the log/mdf files, I have read much about shrinking the db/log but many people saying this is bad practice, any advice would be great...
回答1:
TL;DR; Do not shrink your database. Ever.
The full answer:
You wrote you've been reading about this - So I hope you've encountered posts like Brent Ozar's What’s So Bad About Shrinking Databases with DBCC SHRINKDATABASE?:
You have high fragmentation, so you rebuild your indexes.
Which leaves a lot of empty space around, so you shrink your database.
Which causes high fragmentation, so you rebuild your indexes, which grows the databases right back out and leaves empty space again, and the cycle keeps perpetuating itself.
Mike Walsh's Don’t Touch that Shrink Database Button In SQL Server! - where he explains the same:
What Happens when you Shrink a Database?
When you shrink a database, you are asking SQL Server to remove the unused space from your database’s files.The process SQL uses can be ugly and result in Index fragmentation. This fragmentation affects performance in the long run. You’ve freed that space and are letting the O/S do what it needs to with it, so you got what you asked for at least. If you have a growing database, this means that database will grow again. Depending on your autogrowth settings, this growth will probably be more than necessary and you will end up shrinking again. At best this is just extra work (shrink grow/shrink grow) and the resulting file fragmentation is handled alright. At worse this is causing index fragmentation, file fragmentation, and potentially causing performance problems during the shrink.
and Aaron Bertrand's answer to SHRINKFILE best practices and experience on dba.StackExchange.com - where he is basically saying that you are free to ignore the good advice from smart, experienced people and assume that your case is different - but at your own risk. This is his closing argument:
It will be a much more expensive operation to shrink the file to 4GB, then force it to grow to accommodate the new data. This is like washing an already clean towel that you're about to use to wipe up a mess..
In conclusion - you really, really should pay attention to what experts are writing. Just to be clear: I'm not considering myself an expert on the subject.
I have a firm grasp of T-SQL from the developer side but I have very little experience from the DBA side - I can count on one hand the number of times I had to write stuff like maintenance plans, database migrations or handle any of the system administration stuff a DBA would.
However, all these guys I've mentioned are leading DBAs: Brent Ozar is a MCM (Microsoft Certified Master), Mike Walsh is a 9 times MVP (since 2011), and Aaron Bertrand is a 22 times MVP (since 1997) - These guys really know what they are writing about.
I would take a free advice from either of them any day of the week and twice on Sunday.
Update - About log files:
Shrinking log files is somewhat of a different story - doing it on a regular basis is bad practice.
A log file size is basically derived from your backup strategy and selected recovery model.
Recommended read: Mike Walsh's self answered post over on dba.stackexchange - If you're up to it, I would advise reading both his full answer as well as Aaron Bertrand's full answer to the same post.
来源：https://stackoverflow.com/questions/57178221/sql-windows-os-releasing-unused-space