We are running our project in TFS using Git. Recently it started giving Error
TF30042: The database is full. Contact your Team Foundation Server
administrator. Server: ATSS-P-AAI\SqlExpress01, Error: 1105, Message:
'Could not allocate space for object
'dbo.tbl_Content'.'PK_tbl_Content' in database 'Tfs_DefaultCollection'
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.
I have checked and found that the tbl_content itself has occupied around 9.5GB of space while the total DB size is 10GB. One of my teammate had mistakenly checked in a repository with huge binary files before this happened. He has deleted the repository but seems like the tbl_content is still having same space.
I have tried setting autogrowth as well, but nothing seems to be working. We are now not able to use it anymore.
Any solutions are suggested.
Restricted File Growth in autogrowth will not work in your situation. Since the 10GB limitation is from SQL Express s Daniel mentioned.
SQL Server Express: Limitations of the free version of SQL Server
The most important limitation is that SQL Server Express does not
support databases larger than 10 GB. This will prevent you from
growing your database to be large.
What you can do at present:
Clean the drive to free up space. Delete transaction logs, look for extraneous test case attachments, build drops checked into source that sort of thing.
Restore your prior back-up database
Use SQL Server Standard instead
This is because you're using SQL Express. SQL Express is limited to databases of up to 10 GB.
The easy answer here is that you should upgrade your SQL edition. It may be possible to remove data from the database, but doing so without explicit instructions from Microsoft is not recommended.
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 a database that has lost one of its .ndf files and have been unable to get at the data. The .ndf file in question was added last Thursday and placed in a temporary storage location by a colleague (d'oh!). There is no backup available from this database since prior to this .ndf being created. I have seen numerous solutions to similar problems when the .ndf in question is its own filegroup, but in this case it actually is in a filegroup with an additional file which I want to try and get data from. I am pretty sure what I am trying to do is not possible but there is always a chance right?
The database setup
PRIMARY: Data.mdf -200mb
Data Filegroup 1: Data_1.ndf - 2.9gb
Data_2.ndf - 64gb (newly added file that is now lost - I believe it is just preallocated space)
LOG: Log.ldf - 128mb
When we logged into the VM this morning (hosted in Azure), we were presented with an unexpected shutdown notification from Windows (it seems there was a powerloss/shutdown at 1am) and our application was not reaching the database. Looking in SQL Server Management Studio I could see that it was Recovery Pending status. Trying to bring the db online lead me to an error about Data_2.ndf not being found (located at D:\SQL\Data\Data_2.ndf).
When I accessed the D drive (temporary storage drive) I was presented with a wonderful blank Windows Explorer window - completely blank drive.
I was able to set the Data_2.ndf file offline and bring the database itself online, however I am not able to query any of the data (as all tables were in Data Filegroup 1) due to the filegroup being offline. The other 3 files (mdf, ndf, ldf) are all online.
Is there any way out of this? Any way to perhaps recover any remaining data from Data_1.ndf or is it completely toast?
(This was a hastily stood up development server and there was no backup/recovery strategy for it, as "Azure never crashes" :)).
(Edit:formatting)
You are hosed. Its a miracle you can bring up your database. Are you sure you can retrieve data - have you tried doing selects? You probably will receive more extensive answers on the Database Administrators group.
When a database in the Treeview of SQL Server Management Studio is right-clicked and is taken offline and then the Delete option is chosen, is all space allocated to the database released back to the o/s file system pool?
If you take the database offline before deleting it, data files will not be deleted from disk. Please see this section of the books online.
http://msdn.microsoft.com/en-us/library/ms178613.aspx
Dropping a database deletes the database from an instance of SQL
Server and deletes the physical disk files used by the database. If
the database or any one of its files is offline when it is dropped,
the disk files are not deleted. These files can be deleted manually by
using Windows Explorer. To remove a database from the current server
without deleting the files from the file system, use sp_detach_db.
Yes and no. As long as all of the database files related to the database are deleted (happens when the delete option is chosen) then yes, that space is now freed back to the OS. However there is some data related to the database in the system databases. The best example is the backup history (which you can choose to delete when you drop the database as well). This doesn't seem like much but the data on several years worth of backups can add up. Particularly if you are doing transaction log backups say every 5 minutes.
Also of course your backup files will still exist and take up space on the drives.
The transaction log file for the ReportServerTempDB database (database installed with Reporting Services) is has grown to over 100GB. And I'm not sure why.
Here are the file sizes:
D:\SQLDatabases\ReportServer.mdf - 0.7GB
G:\SQLDatabases\ReportServer.ldf - 1.8GB
E:\SQLDatabases\ReportServerTempDB.mdf - 5GB
G:\SQLDatabases\ReportServerTempDB.ldf - 107.6GB
Recovery mode for all these database is SIMPLE.
We are using SQL Server 2008 R2 Standard Edition.
EDIT: Something that is unique to the reporting services databases:
The collation for these databases is Latin1_General_CI_AS_KS_WS. But for all other database it is Latin1_General_CI_AS.
I don't want to just shink the log files and carry on, because they might just grow again. And I can't see why they should be so large.
Does anyone know what could cause the log file (and the data file) for the ReportServerTempDB database to grow so much
And what I should do about it?
Could this indicate a problem with our Report Server?
You are sure that your temp DB is on recovery model - simple as well?
At least you can shrink the database so you get your disk space back using SHRINK DBCC, check this link for more details: http://msdn.microsoft.com/en-us//library/ms190488.aspx
We had renamed SSRS, but the cleanup / archive procs were still trying to cleanup the old database names. When we changed that, out problem stopped.