Shrink A database in SQL

Don't shrink your databases to free up disk pace.  It's a bad idea. It is generally known as a worst practice to ever shrink a production database or data file...

Follow these tips to reclaim disk space
https://www.mssqltips.com/sqlservertip/1810/out-of-space-on-the-c-drive-of-your-sql-server-and-ways-to-reclaim-disk-space/

Maybe you could just create a new database and migrate data to it.

Can I stop it in the middle?

Shrinking can only help if you have significant amounts of unused space.

You also need to distinguish between data space and log space.  Shrinking a vastly over-sized log can make sense any time.  Shrinking data is very rarely done.

To check for unused data space, run this command:

USE <your_db_name>
DBCC SHOWFILESTATS /*this command does NOT list log space*/
If the "UsedExtents" are significantly lower than the "TotalExtents", it might make sense to shrink the file.

YOU SHOULD ALWAYS SHRINK FILE BY FILE, NEVER THE ENTIRE DATABASE.

You can check all file sizes, including the log file, like so:
EXEC sp_helpfile
If the log file is extremely large/oversized, you can shrink the log file directly.
DBCC SHRINKFILE(2, <total_mb_to_remain_in_log_file>)

Yes, you can safely cancel a shrink.

I ran EXEC sp_helpfile but I do not see any sizes for logs?  As for deleting the logs manually I have no idea where they are
sql.png

I ran this and it didn't do anything EXEC sp_cycle_errorlog

Now how do I shrink the logs? Is there a command?  The logs are about 102400 KB for all 10 but on my master database I have 37712192 KB

it's executing.  I hope this works.  I replaced master with the name of the database - great I reclaimed 133 gigs of space.  thanks you rock! :)  I'll need to save this so I can use it again.

Thanks.  This really helped.

Really glad it helped! ...

... But, for a user db, you want to go back and allocate additional space, since 2GB is probably not enough, especially if the allocation was over 100GB before.

First run these commands:

USE [db_name]
EXEC sp_helpfile
--Copy/save the name in the first column for file#2, the log file.

Then run these commands to gradually increase the log size (yes, there are technical reasons for not going to the total size in one command):
ALTER DATABASE [db_name] MODIFY FILE ( NAME = <copied/saved name from above>, SIZE = 6GB )
ALTER DATABASE [db_name] MODIFY FILE ( NAME = <copied/saved name from above>, SIZE = 10GB )
ALTER DATABASE [db_name] MODIFY FILE ( NAME = <copied/saved name from above>, SIZE = 14GB )
ALTER DATABASE [db_name] MODIFY FILE ( NAME = <copied/saved name from above>, SIZE = 18GB )

Since it doesn't seem to have been mentioned yet ...

Make sure you're backing up your transaction log frequently so that it doesn't need to grow and grow.

A transaction log file will grow forever when your database is in full recovery mode if you're not making transaction log backups.

Actually this database is for Websense and I can detach the older DB's from 2015 so that's going to be my next step.  I don't need to hold information on web activity for years. 6 months is more than enough

USE [db_name]
 EXEC sp_helpfile
 --Copy/save the name in the first column for file#2, the log file.

 Then run these commands to gradually increase the log size (yes, there are technical reasons for not going to the total size in one command):
 ALTER DATABASE [db_name] MODIFY FILE ( NAME = <copied/saved name from above>, SIZE = 6GB )
 ALTER DATABASE [db_name] MODIFY FILE ( NAME = <copied/saved name from above>, SIZE = 10GB )
 ALTER DATABASE [db_name] MODIFY FILE ( NAME = <copied/saved name from above>, SIZE = 14GB )
 ALTER DATABASE [db_name] MODIFY FILE ( NAME = <copied/saved name from above>, SIZE = 18GB )

Does this equal the logfile name?

Yes, the logical log file name, not the physical file name.  You'll see the logical name in the first column in the output from "exec sp_helpfile".  The log file will be file#2.

OK thanks.  I got some serious room back.