i'm working on huge DB, and while insert\work with big files, log file increase to 60GB and over, and eat all my drive so it can't continue processing.
i tried shrink log file but it work afterwards, and while working it increase again so i thought to move the log file (only) to my 2nd drive where i got more space.
i tried by Detach and Attach but it didnt work , error :
An error occurred when attaching the database(s). Click the hyperlink
in the Message column for details.
i also tried manually by alter command:
ALTER DATABASE [databasename]
MODIFY FILE ( NAME = filename , FILENAME = "new file location and name");
but it make the DB "recovery pending" and i had to restore it back from backup.
any other options?
Since you restored from backup, you can add the MOVE command to your restore command to move the log file to a new drive during the restore.
USE [master]
GO
RESTORE DATABASE [YourDatabase] FROM DISK = 'c:\mssql\backup\Full.bak'
WITH CHECKSUM,
MOVE 'YourDatabase_Log' TO 'E:\newdir\Log.ldf',
RECOVERY, REPLACE;
In order to keep your log file from growing too much, you need to increase the frequency of your log backups, assuming you aren’t on SIMPLE RECOVERY MODEL. Shrinking without backing up is not going to do much, if anything at all. When you backup a log file, the committed transactions are backed up and cleared from the log, freeing up space. As you have witnessed your log file will continue to grow based on the workload. Thus, regular shrinking of the log file isn’t really going to help you.
Related
I have a production DB restored in the dev environment on SQL Server 2012.
I wanted to shrink the log file to save HDD space. I looked through SO and other resources but none of the suggestions work for me.
I took the full DB backup and the Log backup. I set the recovery mode to simple. There's no mirroring set up. Yet the command DBCC SHRINKFILE does not shrink the file, but also does not show any errors. The same command works perfectly well on other DBs in the same server. I also tried right click -> tasks -> shrink -> files -> shrink file to, and got the same result, i.e. no errors but the file size remains unchanged.
What else can I try?
This can happen, even if you've followed the proper instructions of setting the database into SIMPLE recovery mode. Usually this happens because there is a virtual log still being used.
If you run:
DBCC LOGINFO;
You'll see if any virtual logs are in use (Status is 2). When shrinking files, empty virtual logs are physically removed starting at the end of the file until it hits the first used status. This is why shrinking a transaction log file sometimes shrinks it part way, but does remove all free virtual logs which you may expect.
This can happen if there is any active transactions still running, which you can debug by querying sys.dm_tran_active_transactions.
The problem that I encounter, is that the LOG_BACKUP file of one of my databases is full. This is a SQL Server 2012 environemnt. The problem occurs because there is a limited space allocated for the log file. The space on the disk itself is sufficient to do a backup. Normally on test systems I would set the recovery mode from FULL to SIMPLE, do a shrink file, and set it back to FULL.
However, I am now working on another system and I would like to preserve the backup chain. So the next thing I try is to increase the allocated space for the log file. This does not work because of the 9002 message (LOG_BACKUP full). Also doing a full backup of the database does not work, with the same message.
As far as I can find, these are the options to clear your LOG_BACKUP file. How can I resolve this issue?
I had stuck with one of our team issue where database drive size was overfilled due to log file which was around 150 GB and there was no hope of making any space on server. So, they had detached the database and then deleted to log file. But, then they were then not able to attach the mdf file. I then tried to rebuild log file but it was too not successful as there was no clean shutdown in database. Has anyone gone through this problem and successfully recovered the database?
sp_attach_single_file_db followed by a DBCC CHECKDB should do the trick. Any uncommitted transactions that might still be in that log file will be lost.
If you have an offline database in your metadata, delete that one first with DROP DATABASE but make sure you have a backup of your MDF file.
What would happen if I delete the .ldf file that is in the same folder that my .mdf file?
The LDF file is the transaction log and is required for all SQL server configurations. Depending on the recovery mode, will determine how it is used. However all queries basically get stored here until successfully committed to the database (MDF).
You will not be able to delete it while SQL server service is running. You can detach the database, delete the log file (LDF) and reattach the data file (MDF). However it will just create a new log file. You really should not need to delete it. If it is getting too large you will need to manage it, typically through the backup process.
The database will be marked as suspect on SQL Server restart and inaccessible without some in depth fiddling to recover it.
The LDF is an essential part of the database: you need this file.
You can of course ignore us, and delete it and see for yourself...
As already pointed out, the .LDF file is crucial for the DB and the DB will not be available without one. The .LDF can be deleted only if the DB is offline, or detached or SQL Service is stopped.
Assuming that one of the above 3 scenario was true and you did delete the .LDF file, then the DB would be suspect when SQL server is restarted. If the DB was offline and you try to bring it back online, it will give you an error:
File activation failure. The physical file name "<<filename.ldf>>" may be incorrect.
Msg 945, Level 14, State 2, Line 1
Database '<<DB Name>>' cannot be opened due to inaccessible files or insufficient
memory or disk space. See the SQL Server errorlog for details.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
It is quite simple to fix this error, but you will need to delete all the Metadata pertaining to the DB from system files. The easiest way to do that would be to drop the DB. Here is what you will need to do.
Take the DB offline or detach the DB
Make a copy of the .MDF file to your backup directory
Now Drop the DB (You will have to reattach the DB, if you detached, of course)
Copy the .MDF back to the original location
After these steps, run the following:
SP_ATTACH_SINGLE_FILE_DB #dbname='<<DBName>>'
,#physname=N'<<filepath\filename.MDF>>'
This should return you the following:
File activation failure. The physical file name "<<Filepath\filename.ldf>>"
may be incorrect.
New log file '<<Filepath\filename.ldf>>' was created.
That would bring your DB back to an usable state.
The million $$$$ question still remains - why would anyone want to delete the .LDF file???
Raj
The best way to keep the size of .LDF file in check is:
to regularly take transaction log backups at least once a day or
change your recovery model from full to simple ( by default, its full)
I'm trying to manage the size of a SQL Server 2008 log file. I have a reporting database that is loaded once a day. The Simple recovery model is the best fit as there are no transactions other than the morning load, and I can re-create those records. My goals are to have the transaction log at a fixed size, large enough that it doesn't have to allocate new space during the load.
My problem is that the log keeps growing. I know that the log is supposed to be marked for re-use, but why does the log keep growing? The log_reuse_wait_desc shows "Nothing".
I can shrink the log file to 1 MB, so I know there are no transactions in it. I can set up a job to do this, but I would prefer to leave the log at 500MB, which is enough to handle the daily loads. If I do this, the log grows.
How can I keep the log at a consistent size?
Please note: Shrinking the log file does not address this issue. I know how to do that. I'm trying to find a way for space in the transaction log to be re-used.
The log file is used for transactional purposes, even if the database is in SIMPLE RECOVERY MODE. If the LOG size is truly growing beyond 500 MB, then someone is running a query or stored procedure that is requiring that space.
For example, perhaps you are creating indexes against your reporting tables. That will be done inside a transaction so that the changes can be rolled back in case of an error. However, the used space will be released afterward for other transactions once complete.
So, if the log size is starting at 1MB and increasing to say, 700MB, then something is being done that requires that space. If you lock the size to 500MB, you will eventually receive a "log file out of space" error.
But if you really want to fix it at 500MB, you can do the following:
(I'm using SQL Server 2005)
Launch Microsoft SQL Server Management Studio
Locate your database and right-click on it. Select Properties.
Click on Files section
Locate the LOG FILE line.
Change the Initial Size to: 500
Locate the Autogrowth section and click on the ellipse (...)
Uncheck "Enable Autogrowth". Click OK.
Click OK to make the change.
Note: You can also set a maximum log file size in the "autogrowth section".
Alternatively, you can use the following script to make the change. Replace DATABASENAME with the appropriate value. Also change the Log File Name if required.
USE [master]
GO
ALTER DATABASE [DatabaseName] MODIFY FILE ( NAME = N'DATABASENAME_Log', SIZE = 512000KB , FILEGROWTH = 0)
GO
create a maintenance job that backups the DB and shrinks the log
The DBCC Shrinkfile command allows you to specify a target size:
DBCC SHRINKFILE (DataFile1, 7)
Shrinks the file DataFile1 to 7MB
Document at: MSDN
Off the top of my head you can use DBCC SHRINKFILE to do this.