MS_SQL Shrinking Log Files.

Hi Experts,
We have checked the documentation which have been received from SAP (SBO_Customer portal), Based on the Early Watch Alert.
AS per SAP requsition we have minimized the size of 'Test Database Log' file through MS_SQL Management Studio.(Restricted file size 10 percent, size 10 MB)
Initially it was 50 Percent, 1000 MB
Doubt is:
Is that any problem will occur in future regarding this changes of 'LOG FILES'.
Kindly help me.
Based on your reply ...
i will update in live production database....
By
kart

The risk to shrink log file is fairly small. Current hardware and software has much better reliability than before. When you shrink your log file, you just lose some history which nobody even know there is any value in it.
On the contrary, if you keep very large log file, it may cause more troubles than doing anything good.
Thanks,
Gordon

Similar Messages

Shrink Log File on MS sql 2005

Hi all,
My DB has a huge logfile, with more than 100gb.
The idea is to shrink it, but the good way.
I was trying this way:
use P01
go
backup log P01 TO DISK = 'D:\P01LOG1\P01LOG1.bak'
go
dbcc shrinkfile (P01LOG1,250) with no_infomsgs
go
The problem is that the backup file is getting bigger and bigger each backup.
So, my question is, how to shrink the logfile, correctly, with backup, but that backup should not increase but stay at the same level, overwriting the backups.
I have full dayly backup with data protector from HP, but it doesn't clean the log, and it isn't possible to shrink it.

What you want to do with the log backups depends on how you are going to recover the database in case the system/database loss and your backup schedule.
1. If you are not going to do point in time recovery then there is no point in taking a tran log backup to a backup file. You can change the recovery model of the database to "simple". If your recovery model is "simple" you don't have to take transaction log backups at all. The inactive transactions are flushed from the log automatically. You should still be taking full and differential backups so that you can atleast recover your database to last full backup and apply the latest differential backup.
2. If this is a production system then you should definitly be on "full" recovery mode and should be taking regular transaction log backups and storing them in a safe place so that you can use them to recover your system to any point in time. Storing the transaction log backup on the same server kind of defeats the purpose because if you lost the server and disks you will not have the backups either.
3. If you are in full recovery mode and lets assume that you run your transaction log backups every 30 mins then you need your log file to be of the size that can handle the transactions that happen in any given 30 to 60 mins.
There shouldn't be a need to constantly shrink log files if you configure things right.
Edited by: Neeraj Nagpal on Aug 20, 2010 2:48 AM

Cannot shrink log file 2 because the logical log file located at the end of the file is in use ?

HI,
I am getting this error frequently.. any recomendations :
Executed as user: DB0\sqlservices. Processing database: dbin [SQLSTATE 01000] (Message 0)
Cannot shrink log file 2 (DB_log) because the logical log file located at the end of the file is in use. [SQLSTATE 01000] (Message 9008)
Processing database: DB_ [SQLSTATE 01000] (Message 0) DBCC execution completed. If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000] (Message 2528)
Cannot shrink log file 2 (DB_log) because the logical log file located at the end of the file is in use. [SQLSTATE 01000] (Message 9008)
Processing database: DB [SQLSTATE 01000] (Message 0)
DBCC execution completed. If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000] (Message 2528)
Backup, file manipulation operations (such as ALTER DATABASE ADD FILE) and encryption changes on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed. [SQLSTATE 42000] (Error 3023)
Processing database: DB_AC [SQLSTATE 01000] (Error 0)
[SQLSTATE 01000] (Error 0) DBCC execution completed. If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000] (Error 2528).
The step failed.
Please give any receomendations to avoid this error in future :
Yangamuni Prasad M

Hi Yangamuni,
Are there any progress?
Please have a look on the below threads with the similar issues as yours:
http://www.sqlservercentral.com/Forums/Topic652579-146-1.aspx
http://social.msdn.microsoft.com/forums/en-US/sqldatabaseengine/thread/ae4db890-c15e-44de-a2af-e85c04260331
The solution is change the recovery mode to SIMPLE, shrink log files and then change to the FULL recovery mode.
Thanks,
Weilin Qiao
Please remember to mark the replies as answers if they help and unmark them if they provide no help. This can be beneficial to other community members reading the thread.

Shrink Log file in log shipping and change the database state from Standby to No recovery mode

Hello all,
I have configured sql server 2008 R2 log shipping for some databases and I have two issues:
can I shrink the log file for these databases: If I change the primary database from full to simple and shrink the log file then change it back to full recovery mode the log shipping will fail, I've seen some answers talked about using "No
Truncate" option, but as I know this option will not affect the log file and it will shrink the data file only.
I also can't create maintenance to reconfigure the log shipping every time I want to shrink the log file because the database size is huge and it will take time to restore in the DR site, so the reconfiguration
is not an option :(
how can I change the secondary database state from Standby to No recovery mode? I tried to change it from the wizard and wait until the next restore for the transaction log backup, but the job failed and the error was: "the step failed". I need
to do this to change the mdf and ldf file location for the secondary databases.
can any one help?
Thanks in advance,
Faris ALMasri
Database Administrator

1. can I shrink the log file for these databases: If I change the primary database from full to simple and shrink the log file then change it back to full recovery mode the log shipping will fail, I've seen some answers talked about using "No Truncate"
option, but as I know this option will not affect the log file and it will shrink the data file only.
I also can't create maintenance to reconfigure the log shipping every time I want to shrink the log file because the database size is huge
and it will take time to restore in the DR site, so the reconfiguration is not an option :(
2. how can I change the secondary database state from Standby to No recovery mode? I tried to change it from the wizard and wait until the next restore for the transaction log backup, but the job failed and the error was: "the step failed". I need to do
this to change the mdf and ldf file location for the secondary databases.
can any one help?
Thanks in advance,
Faris ALMasri
Database Administrator
1. If you change recovery model of database in logshipping to simple and back to full Logshipping will break and logs wont be resored on Secondary server as log chain will be broken.You can shrink log file of primary database but why would you need that
what is schedule of log backup. Frequent log backup is already taking care of log files why to shrink it and create performance load on system when log file will ultimately grow and since because instant file initilaization is not for Log files it takes time
to grow and thus slows performace.
You said you want to shrink as Database size is huge is it huge or does it have lots of free space. dont worry about data file free space it will eventually be utilized by SQL server when more data comes
2. You are following wrong method changing state to no recovery would not even allow you to run select queries which you can run in Standby mode. Please refer below link to move Secondary data and log files
http://www.mssqltips.com/sqlservertip/2836/steps-to-move-sql-server-log-shipping-secondary-database-files/
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it.
My TechNet Wiki Articles

How to know the history of shrinking log files in mssql

hello,
In my SAP system some one shrinked the log file to 100 GB to 5 GB.How we would check when this
was shrinked recently .
Regards,
ARNS.

hi,
Did u check the logfile in sapdirectory.There will be entry of who changed the size and the time.
Also,
Goto the screen where we usually change the logfile size.In that particular field press f1 and goto technical setting screen. Get the program name , table name and field name.
Now using se11 try to open the table and check whether the changed by value is there for that table.
Also open the program and debug at change log file process block.use can see in which table it update the changes.
There is a case of caution in this case.
The size of the application server's System Log is determined by the
following SAP profile parameters. Once the current System Log reaches
the maximum file size, it gets moved to the old_file and and a new
System Log file gets created. The number of past days messages in the
System Log depends on the amount/activity of System Log messages and the
max file size. Once messages get rolled off the current and old files,
they are no longer retrievable.
rslg/local/file /usr/sap/<SID>/D*/log/SLOG<SYSNO>
rslg/local/old_file /usr/sap/<SID>/D*/log/SLOGO<SYSNO>
rslg/max_diskspace/local 1000000
rslg/central/file /usr/sap/<SID>/SYS/global/SLOGJ
rslg/central/old_file /usr/sap/<SID>/SYS/global/SLOGJO
rslg/max_diskspace/central 4000000 .

Shrink Log File on High Availability

Dear support
good day for you,
i using SQL server 2012 and using AlwaysON High Availability (server_SQL1 = Primary & Server_SQL2=Secondary), when i try to shrink the log files he told me you must alter the database to simple recovery mode first but i cant coz using AlwaysON !
thats mean:
remove the DB's from AlwaysON (Server_SQL1)
Shrink Files
remove DB's from Server_SQL2
add again DB's to AlwaysON
any other solution for shrink logs without add/remove DB from AlwaysON
Regards,

The link that Uri has is correct, but let me expand on it for anyone else that runs across this issue:
You don't actually need to be in the simple recovery model to shrink a file or the log. The reason why some people make the switch is because changing to the simple recovery model lets the database automatically clear the logs. This *generally* puts the
VLF in use at the very beginning of the log. Since shrinking a log file works differently from data files (log only works from the end of the log until the first used vlf) it allows for a fast shrink and grow operation to fix up the log.
In the full recovery model it is still possible, the difference being that you'll need to check to see which VLF the database is currently using and you may have to manually cause the log to circle around (by log backups, etc) to get a good shrink so
that you can grow at a proper size.
Sean Gallardy | Blog |
Twitter

Log file shrinking

hi every one
i m very happy getting reply from u all
here my doubt regarding log file shrink.in our environment all high avaliabilities are using (log shippimg,mirroring,replication) now my doubt is if i shrink log file of a database which is these H A what will be the reaction?does i ve to reconfigure or
not?
can i make snapshot database for restoring database?
waiting for replies with anxiety
thanks&regards
chetan.tk

Hi chetan.kt,
What is the purpose of shrinking log file? It is recommend that backup the log file frequently as a period of some minutes if the log file is large. In case of more space is required for operation in SQL Server, you may consider to increase the disk space.
Befor shrinking, you should insight into the reason which leads to the log file grows unexpectedly: A transaction log grows unexpectedly or becomes full on a computer that is running SQL
Server.
For log shipping and database mirroring, you can shrink the log file on primary server with non-truncate, and the shrink operation will be log shipped to the secondary servers.
As for replicated database, you cannot be able to shrink the log file if replication is not completed. You may have a try to mark all replicated transactions as completed by stopping log reader agent and restart after shrinking. For more information:
Unable to shrink transaction log on replicated database - SQL 2008
It is not a good idea to shrink the log file. You may have a look at Tibor’s blog about the problem of shrinking log file:
Why you want to be restrictive with shrink of database files
Best Regards,
Stephanie Lv
Forum Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected]

Database Log File becomes very big, What's the best practice to handle it?

The log of my production Database is getting very big, and the harddisk is almost full, I am pretty new to SAP, but familiar with SQL Server, if anybody can give me advice on what's the best practice to handle this issue.
Should I Shrink the Database?
I know increase hard disk is need for long term .
Thanks in advance.

Hi Finke,
Usually the log file fills up and grow huge, due to not having regular transaction log backups. If you database is in FULL recovery mode, every transaction is logged in Transaction file, and it gets cleared when you take a log backup. If it is a production system and if you don't have regular transaction log backups, the problem is just sitting there to explode, when you need a point in time restore. Please check you backup/restore strategy.
Follow these steps to get transactional file back in normal shape:
1.) Take a transactional backup.
2.) shrink log file. ( DBCC shrinkfile('logfilename',10240)
The above command will shrink the file to 10 GB.(recommended size for high transactional systems)
>
Finke Xie wrote:
> Should I Shrink the Database? .
"NEVER SHRINK DATA FILES", shrink only log file
3.) Schedule log backups every 15 minutes.
Thanks
Mush

Log file consumed all drive space; will not commit after adding space

SQL 2008 - Have a drive that is 250GB that holds both the database and log files for a given database; nothing else is on the drive. The database file is ~2GB in size and the log file is ~248GB, filling up the entire drive. I have had
issues in the past where there was not enough free space for the data in the log files to commit to the database file. Since this is a virtual machine I increased the drive to 550GB to give it enough overhead to commit data, and restarted SQL.
The log file data still did not commit. I took a full backup and also tried to shrink the database. Now the database file is ~1GB and the log has grown to ~286GB. Please advise and note I am a systems administrator and not a DBA by trade.

Hi,
I am quite sure your database recovery model is full and you have not taken Transaction log backup, Have you ?
I also doubt you have enough space to take log backup. If you can please take log backup, may be twice to truncate logs and then shrink log file. Only transaction log backup truncates the log ( almost every time unless some long running transaction
is holding the log) and makes it reusable so that either it can be shrinked or reused.
If it is UAT you can change recovery model of database to simple and then shrink the logs. After that change recovery model to full and take full backup of database.
PS: Schedule regular log backup for your databases in full recovery model
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it.
My TechNet Wiki Articles

SQL log file size is extending rapidly

Hello All,
We are using ECC 6.0, our database is SQL 2005 & operating system is Windows NT 4x AMD64 L.
Our database log file size is increasing rapidly, now its size is more than the all 4 data files (near about 300gb).
Last week I tried to shrink log file but it didn't worked.
Now less space is remained on disk, please help me.
Now the system is started giving dump at the time of log in, & the dump is like "START_CALL_SICK ".
I am attaching dump error text file.
Please help why is this happening.
Thanks in advance
Mahendra

Hi,
I have backed up log file & shrink the file but it didn't worked for me
What is the result? It shrinks the log and release all the space (for all committed transactions).
How can i add another log file?
Can i delete old log file after adding new log file.
You can add another log file by following below steps. but in your case, this is not the right solution because you have good amount of log file configuration for your database (now its size is more than the all 4 data files (near about 300gb)).
Open SQL server management studio > Expand database > Right click on database > Select Files > Click on Add > Give the input parameters (Logical file name, path, initial size etc.) click on OK
If system is not allowing you to shrink the log file, it means you have active transactions in system which are continuously using your log file.
Regards,
Nick Loy

Does shrinking LDF file have any impact on restoration?

Right now my LDF file is almost 50GB. My database is only of 10 GB size.
Here are my questions:
1. Why is the LDF file so huge?
2. Is there any way to avoid the LDF file to grow so big?
3. If I use shrink, will I have any issue while I am restoring the database in the future.

Hi,
1. Can be many reason , do you take frequent transaction log backups.
2. yes by taking proper transaction log backup and putting correct and reasonable value of autogrwth for data and log file
3. No, not at all. Shrinking log file only removes free space.
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
My Technet Wiki Article
MVP

Shrinking database file

Hi experts,
According to the reference guide(4.9 Diskspace Requirements), BDB does not return the freed space to underlying file system by deleting entries. And it also says that we need to create a new database and copy the records from the old one into it.
Followings are my questions...
Q1. In case of BTree, there is 'compact' api. Which one is better in performance of other view points between using 'compact' and copying into new DB?
Q2. Is it the only way for Hash?
Q3. The guide also saying that pages that key/data pairs are deleted from, can be reused where possible. Is there any criteria or rule for reusing it or not? Can we control it?
Q4. What about with in-memory configuration? Are these same?
Thank you.

Hello,
First SQL server 2000 is totally outdated and is no longer supported in any kind by Microsoft.
>>However, in the Recovery option if I switch it to simple and then shrink the database it will shrink
Shrinking of database is most evil operation you can do in SQL Server it causes massive fragmentation so please don't do it.You can go for data file shrink IF THERE IS GRAVE requirement to shrink it.SQL server data file might not
always respond to shrink command as release space.From what you posted seems like you are trying to shrink log file .You cannot shrink log file if last Virtual Log file( VLF) is still required by some transaction.To make sure it is marked as reusable you need
to take log backups at frequent interval ONLY LOG backup can truncate the logs and make VLF reusable and then you can shrink( A long running transaction can still hold VLF hostage and wont allow it to be marked as reusable).
When yo change recovery model to simple you force checkpoint which causes VLF to truncate and thus you can free space.
Further reading
http://technet.microsoft.com/en-us/magazine/2009.02.logging.aspx
http://technet.microsoft.com/en-us/library/ms178037%28v=sql.90%29.aspx
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers

Sharepoint 2013 - WSS content LOG file very very big

Hi there.
Sharepoint 2013 with latest updates.
WSS CONTENT database size is cca 110GB, LOG FILE is 90GB.
Even if we did FULL backup of databes that does not decrease LOG file size.
Any hints how to lower the size of LOG data file?
With best regards
bostjanc

Hi Bostjan,
I wonder whether the issue can be resolved by shrinking log file.
Shrinking data files recovers space by moving pages of data from the end of the file to unoccupied space closer to the front of the file. When enough free space is created at the end of the file, data pages at end of the file can deallocated and returned
to the file system.
Here is the reference for Shrink a File in SQL 2012 for your convenience:
https://technet.microsoft.com/en-us/library/ms190757(v=sql.110).aspx
Regards,
Rebecca Tu
TechNet Community Support
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact
[email protected]

WebAnalyticsServiceApplication_ReportingDB log file and secondary DB files issue

Hello everyone,
So we have a problem, a customer has a SP2010 farm, SP on one server and SQL 2008r2 on another. Little (read none by the looks of things) maintenance has been applied to the server (both SQL and SP other than patching and windows backups) over nearly a year
and we are here now to upgrade to SQL 2012, found the current state and the situation is as follows (up-to now):
The SP install was done from the search server binaries to give better search options (thought this may be prudent to disclose)
The WebAnalyticsServiceApplication_ReportingDB log file is HUGE and will not truncate, Ive done the following:
backed up (full) the DB for web analytics
backed up log files for same DB (with truncate selected) (both through gui in SQL MS)
Tried to shrink log file (this told me through the gui that 99% was free in the log file, but it freed up only 1%, even after trying again and selecting 'reorganise pages before releasing unused space' and selecting 0MB for the 'shrink to' size)
Also, there are over 30 secondary DB files for this database, Ive seen other threads about these files but am stuck as how to do the following...
no one uses the web analytics
the data is not needed
I understand it maybe needed in the future
we do not need the data
how should I get rid and stop future log file and secondary DB file growth?
Anyone's help would be greatly appreciated.

For reference, you can control how long SP keeps the Web analytics data (which does generate one extra .ndf per week).
To set the limit on the data retention period:
On the Central Administration Web site, in the Application Management section, click
Manage service applications.
Click the Web Analytics Service Application row to select it and in the
Operations group of the ribbon click Properties.
In the dialog box, in the Data Retention Period section, set the data retention period, which can range from 1 month to 25 months.
See
https://technet.microsoft.com/en-us/library/ee620541.aspx#section1 for more info

SQL Server 2012 DB log file doesn't shrink (simple recovery model)

I've found several similar questions in this forum, but none of the answers have resolved my problem: I have a SQL Server 2012 DB using simple recovery model. The MDF file is 12 GB and the LDF file is 10 GB. I'm trying to shrink the size of the
LDF file. I've read that for simple recovery model DBs there are reasons for delaying log file shrinking, but I still can't find a solution based on these reasons.
When I try to shrink it using this command:
DBCC SHRINKFILE(MyDB_log, 1000000)
I get these results, and no change of file size:
DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages8 2 1241328 128 1241328 128
The same results running this:
DBCC SHRINKFILE(MyDB_log, 1000000, TRUNCATEONLY)
There doesn't appear to be any open transactions:
DBCC OPENTRAN()No active open transactions.DBCC execution completed. If DBCC printed error messages, contact your system administrator.
And this returns NOTHING:
SELECT name, database_id, log_reuse_wait_desc FROM sys.databases WHERE database_id = DB_ID()name database_id log_reuse_wait_descMyDB 8 NOTHING
I've also tried running the following, but nothing useful is returned:
SELECT * FROM sys.dm_tran_database_transactionsSELECT * FROM sys.dm_exec_requests WHERE database_id=DB_ID()SELECT * FROM sys.dm_tran_locks WHERE resource_database_id=DB_ID()
Any other suggestions of what I can do to shrink this log file? Or perhaps someone can justify its enormous size?
David Collacott

The answer is pretty simple.
The following code is the problem:
DBCC SHRINKFILE(MyDB_log, 1000000)
You are telling SQL Server that you want to "shrink" the MyDB_log file and the target size is 1TB. Well according to you the MyDB_Log file is well below the 1TB size you are targeting, in fact it's only 10GB so SQL Server is doing precisely what you
are telling it to do.
See, according to the SQL Server documentation
here, target size "Is the size for the file in megabytes, expressed as an integer."
Now if you'd like to actually shrink the log file down to, oh say 1GB, then you should try the following command:
DBCC SHRINKFILE(MyDB_log, 1000)
The theory being 1000 * 1048576 (i.e. 1MB) is equal to 1GB.

MS_SQL Shrinking Log Files.

Similar Messages

Maybe you are looking for