I have a database table that is being used to store Xml. A lot of the records have a base64 pdf file within the Xml which is taking up a lot of space. If I clear the Xml column out the size of the database doesn't shrink. I've even tried completely deleting every record on our test database and the physical size of the database is still sitting at 300 GB. How do I get SQL to realize that the space is no longer being used and it should re-size?
I've tried DBCC Shrinkfile but it just makes the log file grow by 1GB.
Microsoft Documentation
Exert
To shrink a database
Using SQL Server Management Studio
In Object Explorer, connect to an instance of the SQL Server Database Engine, and then expand that instance.
Expand Databases, and then right-click the database that you want to shrink.
Point to Tasks, point to Shrink, and then click Database.
Database
Displays the name of the selected database.
Current allocated space
Displays the total used and unused space for the selected database.
Available free space
Displays the sum of free space in the log and data files of the selected database.
Reorganize files before releasing unused space
Selecting this option is equivalent to executing DBCC SHRINKDATABASE specifying a target percent option. Clearing this option is equivalent to executing DBCC SHRINKDATABASE with TRUNCATEONLY option. By default, this option is not selected when the dialog is opened. If this option is selected, the user must specify a target percent option.
Maximum free space in files after shrinking
Enter the maximum percentage of free space to be left in the database files after the database has been shrunk. Permissible values are between 0 and 99.
Click OK.
Related
Since there is no space left on my SQL server, I keep getting the following error and I have to delete data to get the system working again.
The hosting company says we do not have unlimited package options. They suggest that we switch to the server. Apart from that, I saw the 'shrink' on the internet, but will this damage the database or will it be the definitive solution for me?
Could not allocate space for object in database because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
As has been mentioned in the comments, Shrink Database won't help you because SQL Server will use all free space in the file before it attempts to grow it.
So your options are as follows:
Archive or delete old data
If you have audit tables, large blobs that no longer need to be accessed, or other data that doesn't need to be accessed within your application any more, you can SELECT it out of the database, store it in a file somewhere as an archive (or retrieve it from an older backup when you need it).
Apply table compression
If you are running Enterprise SQL, or a version of Standard/Express/Web after 2016 SP1, you can apply Compression to larger tables. This converts CHAR columns to be physically stored as VARCHAR columns, among other things, and I have seen it gain 1/3 space back on some SQL databases. However, you will run into the problem of needing space initially to perform the compression in, so you may need to apply this in concert with #1. A restart of the database service may also give you some space back from tempdb in which to operate if your tempdb has filled.
Upgrade storage space
If your host can't meet your storage space needs and #1 and #2 are not possible, it may be time to look at changing hosts. This may be a good idea anyway as your database will no doubt eventually grow back to bigger than its current size.
Keep in mind that if you have microsoft sql express server the license limits you to about 10 GB per database so you cannot increase the primary group more than that. For Sql Express Server before 2008 the size limit is even less.
I have a database of approximately 70GB in size residing on SQL Server 2016 Enterprise on an Azure VM. We decided to move this to an Azure SQL Database.
I accomplished the move via the "Deploy to Azure SQL Database" (right-click on the database and it's under Tasks). This wizard seemed very complete and ran a battery of tests, followed by doing the deployment step-by-very-detailed-step. The full process took about 3 hours, but it finished with all steps marked as success.
The issue is the size of the resulting Azure SQL database is only showing as 31GB?? Is this possible? Is there a possibility that there were 40gb worth of extraneous/temporary/unneeded data that the transition process recognized as unnecessary? As you can imagine, I'm very hesitant to take down the original database and start using the new one given this difference in size.
It could be that you had fragmented indexes and moving them from one place to another allowed for a rebuild eliminating wasted space. It could be that you just had a database that was set to 70gb but only had 31gb of data. The size of your backups should give you an indication of the actual size of the data in your system. Run counts on the tables to ensure that both data sets match.
The size of the data files seen from the operating system is not a good indication of the size of the data they content. Connect with SSMS to the SQL Server instance in your Azure VM, make a right click on the database, make a click on Taks, now select Shrink, then select Files. Look at the "Currently allocated space" and the "Available free space" of the Data file. From the "File type" choose "Log" and that should give the allocated size and the free space of the log also.
I have shrink the large database. I have shrink the database log using SSMS and by query both way. on the properties it is showing the reduced size. But on the drive where it is mounted showing the previous size. What can I do to release the space after shrink of database?
After you shrink database and see the database size is reduced to release the unused empty space to file system, you can execute DBCC SHRINKDATABASE command with TRUNCATEONLY option once more
After I delete huge amount of data from a SQL Server database table, the database size increased.
When I run sp_spaceused it shows me 2625.25 MB. It used to be ~ 1800.00 MB before I deleted from table.
Is there any specific reason it keeps growing even if I delete data?
A temporary transaction log is often the reason for a notable increase of size after a huge delete.
It will eventually disappear on its own but you may remove the files if you need to reclaim the space.
I'm assuming that you are using SQL Server (sp_spaceused). Deleting is logged, so your log file has grown.
See SQL Server 2008 log will not truncate on how to truncate your log (depending on your DB and recovery model), and then you can run
DBCC SHRINKFILE(N)
to reclaim lost space
Edit As per #Aaron, Truncating is also a logged operation. Answer corrected.
First of all, I know it's better not shrink database. But in our situation we had to shrink the data file to claim more space back.
Environment: SQL Server 2005 x64 SP3 Ent running on Windows Server 2003 Enterprise x64.
The database has one single data file and one log file. Before we run DBCC SHRINKFILE, the data file has 640GB, in which 400GB is free, so the data is about 240GB. To speed up the shrink process,we had to defrag the database first then we shrink data file.
However, after we shrinked the database data file using DBCC SHRINKFILE, the data changed to 490GB. How could it happen?
I asked around include Paul Randal. Here's the possible reason:
When I rebuild indexes for those indexes that were dropped, the indexes would not physically removed from data file, they would be put in deferred drop queue, instead they would stay there and would be dropped in batch.