An automatic job running to do the DBCC CheckDB for all of our database on SQL Server 2008 R2.
we have 22 DBs, and 1 of the db has about 160GB, I relocate a hard drive around 70 GB for the tempdb but it failed.
CheckDB Error : 1105 : Could not allocate space for object 'dbo.SORT temporary run storage: 172324227579904' in database 'tempdb' 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. [SQLSTATE 01000]
I would like to know how much size I need for this db check.
After using the Estimateonly check, it only gives me an answer 45MB....which is a bug in MS SQL SEVER 2008 R2, so I try to connect to the database via SQL Serever 2012 and lanch the Estimateonly but the same answer.
Any guy could help me about how to get the exact size I need for a big DB DBCC check?
Sincerely
For more information.
#TheGameiswar. I did a check on our SQL Server Pack. we already have the latest version of the SQL Server...
enter image description here
Related
I've got a database on SQL Server 2008 R2 that has grown to 10GB (log file is tiny). Users cannot work because they get the message about not being able to allocate space, filegroup PRIMARY being full.
Database is in simple mode, the .mdf file is set to unlimited growth, the initial size says 10240MB and when I change it trough the manager it just goes back up.
Naturally shrinking trough Manager or T-SQL DBCC SHRINKFILE or SHRINKDATABASE does not work because of that (IIRC, shrink cannot go below minimal size).
What are my options now?
Create a new filegroup?
Why can't I reduce initial size?
SEE IMAGE
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.
I have a database with 468 MB.
I deleted all tables and the size of this database is the same.
Why size of this database is the same?
You need to Shrink or Compact the database to reclaim the empty space in the database file.
See this blog post: SqlCeEngine/ISSCEEngine: Shrink Vs Compact
I have a SQL Server 2008 Express Database which is 7.8 GB in size
DataFile 1.2 GB
LogFile 6.6 GB
Recovery Model = Full
Auto Shrink = False
On a Live database, what is the best way to reduce the size of this database?
Before you can shrink a database running in full recovery model, you must backup the transaction log. So the procedure is to run a transaction log backup, and then shrink the log file.
If you have never performed a transaction log backup then you will continue to suffer from run-away log files and shrinking it will only be a band-aid solution.
You can also identify unused tables and remove those tables(if there is)
you can create Archive database that will stored some old unused data
you can normalize your database more to reduce table size.
hope this information helps you.
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.