What is best practice to use shrink SQL Server?

Question

I have read a lot that shrinking database is not recommended practice as it causes a fragmentation that leads to slower performance.

ref :

https://www.brentozar.com/archive/2017/12/whats-bad-shrinking-databases-dbcc-shrinkdatabase/

https://straightpathsql.com/archives/2009/01/dont-touch-that-shrink-button/

But, it appeared to be the case for data file, if the log is full, shrinking log should not be a problem right?

if the data file is huge that takes a lot of space, I do need more space to insert and update some new data, shrinking apparently reduce the size of the file on the drive, which I assumed that I could use the free space to insert new data. but if shrinking is not recommended, how do I resolve this? and when is the best case to use shrink

Answer 1

if the data file is huge that takes a lot of space, I do need more space to insert and update some new data, shrinking apparently reduce the size of the file on the drive, which I assumed that I could use the free space to insert new data.

If your data file takes a lot of space it does not mean that this space is empty .

You should use sp_spaceused to determine if there is unused space within data file.

If there is unused space , it will be already used "to insert and update some new data", and if there isn't doing shrink will change nothing: shrink does not delete your data, all it does is moving data at the beginning of the file to make space at the end in order to give it back to OS .

Shrinking data file can be usefull when you had a data file of 2Tb and 1 Tb of data was deleted and you don't plan to insert another Tb of data in next 10 years.

You can imagine your data file as a box 1m x 1m x 1m. If you have only a half of the box full of toys, even if you don't use shrink you can put other toys into this box (make insert / update ). What instead shrink does, it gathers all the toys in 1 corner and then cut your box in order to make it 50cm x 50cm x 50cm. This way your room (OS) now has more free space because your toyb box takes only the half of space it took prior to shrink.

...And if your box was already full, you cannot add more toys even if you try to do shrink .

if the log is full, shrinking log should not be a problem right?

Shrinkig log is another process, nothing can be moved inside log file , in this sense of course shrink cannot make much harm as in the case of data file : it does not require server recourses, it does not cause any fragmentation, etc. But if it succeeds or not depends on the cause of your "log is full".

If your log is full due to full model , shrinking log file will not change anything: the log is retained to give you the possibility of having the log backup chain (or to make possible mirroring , or log shipping , etc).

If instead your database recovery model is simple , and there was some trouble with a transaction that was open for long period of time, or there was a huge data loading (maybe with full logging such as insert into without tablock ) and your log file became bigger than data file , and you found and fixed the problem and you don't need such a huge log file , yes you can shrink it to a reasonable size, and it's not harmful.