I try to automate the process of releasing the space of the databases in a SQL server, for this I assembled the following script with 3 particular cases (according to the business rules of the institution). The first is the tempdb, I separate this database because I cannot apply thealter ... recovery (I do not know if it is necessary to apply the release of space to this database). The second rule is for a particular database BD_MAIN, which has four data files and four log files, I only apply for the last two files. The third case is by discarding, for all the remaining databases.
EXEC sp_MSforeachdb
'
use [?]
declare
#arch_1 sysname,
#arch_2 sysname,
#bd_name sysname
set #bd_name=(select DB_NAME())
set #arch_1 =(select name FROM SYSFILES
where fileid = ''1'')
set #arch_2 =(select name FROM SYSFILES
where fileid = ''2'')
-- 1st case: If the data base is tempdb:
if (#bd_name=''tempdb'')
begin
select name from sysfiles
DBCC SHRINKFILE (tempdev, 1)
DBCC SHRINKFILE (templog, 1)
end
-- 2nd case: If the data base is BD_MAIN:
else
begin
if (#bd_name=''BD_MAIN'')
begin
select name from sysfiles
DBCC SHRINKFILE (BD_MAIN4 , 1);
ALTER DATABASE BD_MAIN
SET RECOVERY SIMPLE
DBCC SHRINKFILE (BD_MAIN_log4 , 1);
ALTER DATABASE BD_MAIN
SET RECOVERY FULL
end
-- 3rd case: Another data bases:
else
begin
select name from sysfiles
DBCC SHRINKFILE (#arch_1 , 1)
ALTER DATABASE [?]
SET RECOVERY SIMPLE
DBCC SHRINKFILE (#arch_2 , 1)
ALTER DATABASE [?]
SET RECOVERY FULL
end
end
'
The problem that I have with this script is when I am in ´tempdb´, it is supposed that I should not enter the last else (for other cases), however it throws me the following error message (4th line):
DBCC execution completed. If there are error messages, consult your system administrator.
DBCC execution completed. If there are error messages, consult your system administrator.
Mens. 5058, Level 16, State 1, Line 44
The 'RECOVERY' option can not be set in the 'tempdb' database.
DBCC execution completed. If there are error messages, consult your system administrator.
You can not reduce the file '2' in the database 'model' to 128 pages, since it only contains 96 pages.
DBCC execution completed. If there are error messages, consult your system administrator.
DBCC execution completed. If there are error messages, consult your system administrator.
DBCC execution completed. If there are error messages, consult your system administrator.
DBCC execution completed. If there are error messages, consult your system administrator.
I would like to know if the code can be improved to avoid this kind of error messages since I want to incorporate it into a stored procedure or some recommendation about the release of space (how, when and when to do it).
I am trying to insert some data into a table in my database in sql server. It has huge amount of data, I am talking about millions of records.
I kept getting error 9002
The transaction log for database 'GCVS2' is full. To find
out why space in the log cannot be reused, see the log_reuse_wait_desc
column in sys.databases.
When I tried inserting data yesterday, it was fine with no problem, although it did take some time.
I tried it again today but kept getting this error. I checked the log file for my database, and it's auto increment is set to 10% ,unlimited. Is there any way to fix this?
You Can Truncate the transaction log. use the below query
BACKUP LOG databasename WITH TRUNCATE_ONLY
DBCC SHRINKFILE ( databasename_Log, 1)
Check here for more details
You will need to check the Recovery mode of your database. Put it in Full Recovery mode. After that, make sure there is a transaction log backup in place for your database. You will need to dig through it and make a Maintenance plan, depending upon how critical your data is. That will be the long term solution.
For time being you can shrink your log files using following DBCC command -
BACKUP LOG DBName WITH TRUNCATE_ONLY
DBCC SHRINKFILE ( DBNameLog, 1)
Or you can do it through Object Explorer. Refer to this link for details. But you will have to set your Database to Simple Recovery model to use the Shrink command
DBCC CHECKDB shows following error message in my sql server 2008 R2 database
Msg 8921, Level 16, State 1, Line 2
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
What is the solution?
Given that DBCC CHECKALLOC fails too, with no corruption messages, your database has corrupt metadata and you need to restore from your backups (the first thing it does is run some basic checks on the three critical system tables it needs, and if they're badly broken, it will fail with message 8921). You have no other choice here - you can't run repair as you can't get DBCC CHECKDB to run.
It's possible you could narrow down which system table is corrupt using DBCC CHECKTABLE on successive object IDs from sys.objects, and then manually edit around the corruption, but that's very advanced and has a very low chance of success.
If you don't have any backups, you're going to have to create a new database and then export all the schemas and data into the new database.
I have a long running process that holds open a transaction for the full duration.
I have no control over the way this is executed.
Because a transaction is held open for the full duration, when the transaction log fills, SQL Server cannot increase the size of the log file.
So the process fails with the error "The transaction log for database 'xxx' is full".
I have attempted to prevent this by increasing the size of the transaction log file in the database properties, but I get the same error.
Not sure what I should try next. The process runs for several hours so it's not easy to play trial and error.
Any ideas?
If anyone is interested, the process is an organisation import in Microsoft Dynamics CRM 4.0.
There is plenty of disk space, we have the log in simple logging mode and have backed up the log prior to kicking off the process.
-=-=-=-=- UPDATE -=-=-=-=-
Thanks all for the comments so far. The following is what led me to believe that the log would not grow due to the open transaction:
I am getting the following error...
Import Organization (Name=xxx, Id=560d04e7-98ed-e211-9759-0050569d6d39) failed with Exception:
System.Data.SqlClient.SqlException: The transaction log for database 'xxx' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
So following that advice I went to "log_reuse_wait_desc column in sys.databases" and it held the value "ACTIVE_TRANSACTION".
According to Microsoft:
http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx
That means the following:
A transaction is active (all recovery models).
• A long-running transaction might exist at the start of the log backup. In this case, freeing the space might require another log backup. For more information, see "Long-Running Active Transactions," later in this topic.
• A transaction is deferred (SQL Server 2005 Enterprise Edition and later versions only). A deferred transaction is effectively an active transaction whose rollback is blocked because of some unavailable resource. For information about the causes of deferred transactions and how to move them out of the deferred state, see Deferred Transactions.
Have I misunderstood something?
-=-=-=- UPDATE 2 -=-=-=-
Just kicked off the process with initial log file size set to 30GB. This will take a couple of hours to complete.
-=-=-=- Final UPDATE -=-=-=-
The issue was actually caused by the log file consuming all available disk space. In the last attempt I freed up 120GB and it still used all of it and ultimately failed.
I didn't realise this was happening previously because when the process was running overnight, it was rolling back on failure. This time I was able to check the log file size before the rollback.
Thanks all for your input.
To fix this problem, change Recovery Model to Simple then Shrink Files Log
1.
Database Properties > Options > Recovery Model > Simple
2.
Database Tasks > Shrink > Files > Log
Done.
Then check your db log file size at
Database Properties > Files > Database Files > Path
To check full sql server log: open Log File Viewer at
SSMS > Database > Management > SQL Server Logs > Current
I had this error once and it ended up being the server's hard drive that run out of disk space.
Do you have Enable Autogrowth and Unrestricted File Growth both enabled for the log file? You can edit these via SSMS in "Database Properties > Files"
Is this a one time script, or regularly occurring job?
In the past, for special projects that temporarily require lots of space for the log file, I created a second log file and made it huge. Once the project is complete we then removed the extra log file.
This is an old school approach, but if you're performing an iterative update or insert operation in SQL, something that runs for a long time, it's a good idea to periodically (programmatically) call "checkpoint". Calling "checkpoint" causes SQL to write to disk all of those memory-only changes (dirty pages, they're called) and items stored in the transaction log. This has the effect of cleaning out your transaction log periodically, thus preventing problems like the one described.
Try this:
USE YourDB;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE YourDB
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 50 MB.
DBCC SHRINKFILE (YourDB_log, 50);
GO
-- Reset the database recovery model.
ALTER DATABASE YourDB
SET RECOVERY FULL;
GO
I hope it helps.
The following will truncate the log.
USE [yourdbname]
GO
-- TRUNCATE TRANSACTION LOG --
DBCC SHRINKFILE(yourdbname_log, 1)
BACKUP LOG yourdbname WITH TRUNCATE_ONLY
DBCC SHRINKFILE(yourdbname_log, 1)
GO
-- CHECK DATABASE HEALTH --
ALTER FUNCTION [dbo].[checker]() RETURNS int AS BEGIN RETURN 0 END
GO
If your database recovery model is full and you didn't have a log backup maintenance plan, you will get this error because the transaction log becomes full due to LOG_BACKUP.
This will prevent any action on this database (e.g. shrink), and the SQL Server Database Engine will raise a 9002 error.
To overcome this behavior I advise you to check this The transaction log for database ‘SharePoint_Config’ is full due to LOG_BACKUP that shows detailed steps to solve the issue.
I met the error: "The transaction log for database '...' is full due to 'ACTIVE_TRANSACTION' while deleting old rows from tables of my database for freeing disk space. I realized that this error would occur if the number of rows to be deleted was bigger than 1000000 in my case. So instead of using 1 DELETE statement, i divided the delete task by using DELETE TOP (1000000).... statement.
For example:
instead of using this statement:
DELETE FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())
using following statement repeatedly:
DELETE TOP(1000000) FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())
adding up to the answers above, I also want to mention that, if possible, u can also free up the server to fix this issue. If the server is already full due to the database overflow, u can delete some unnecessary files from the SERVER where ur DB is built upon. At least this temporarily fixes the issue and lets you to query the DB
My problem solved with multiple execute of limited deletes like
Before
DELETE FROM TableName WHERE Condition
After
DELETE TOP(1000) FROM TableName WHERECondition
The answer to the question is not deleting the rows from a table but it is the the tempDB space that is being taken up due to an active transaction. this happens mostly when there is a merge (upsert) is being run where we try to insert update and delete the transactions. The only option is is to make sure the DB is set to simple recovery model and also increase the file to the maximum space (Add an other file group). Although this has its own advantages and disadvantages these are the only options.
The other option that you have is to split the merge(upsert) into two operations. one that does the insert and the other that does the update and delete.
Here's my hero code. I've faced this problem. And use this code to fix this.
USE master;
SELECT
name, log_reuse_wait, log_reuse_wait_desc, is_cdc_enabled
FROM
sys.databases
WHERE
name = 'XX_System';
SELECT DATABASEPROPERTYEX('XX_System', 'IsPublished');
USE XX_System;
EXEC sp_repldone null, null, 0,0,1;
EXEC sp_removedbreplication XX_System;
DBCC OPENTRAN;
DBCC SQLPERF(LOGSPACE);
EXEC sp_replcounters;
DBCC SQLPERF(LOGSPACE);
Solved: As per the error the free space left the in the drive is not sufficient.
to resolve it either you can extend the drive space or move the MDF/LDF/LOG file to the drive with enough space.
Note: check the existing path from below steps
Database properties -> Select File option
enter image description here
Try this:
If possible restart the services MSSQLSERVER and SQLSERVERAGENT.
i have a production DB in SQL server and wanted to put the final touches after the functionality is completed. prior to shipping it out i want to make sure i have some clean up in the SQL server DB and truncate and shrink log files?
can i have a nightly job run to truncate logs and shrink files?
this is what i have so far:
ALTER proc [dbo].[UTIL_ShrinkDB_TruncateLog]
as
-- exec sp_helpfile
BACKUP LOG PMIS WITH TRUNCATE_ONLY
DBCC SHRINKFILE (PMIS, 1)
DBCC SHRINKFILE (PMIS, 1)
EDIT:
MY RECOVERY MODEL IS SIMPLE
Since you are performing a Backup on the logfile you shouldn't have to truncate it. Note that this doesn't cause the logfile to shrink it just causes it to overwrite itself. So you need to perform them frequently to maintain a small log file.
Here is a good article on log maintenance.
http://www.emmet-gray.com/Articles/SQL_LogMaintenance.htm