Log File size & Locations

[Former Member]

Dear Experts,

my SAP production server log fine is more than 180GB & i want to move their Location as well as replace the same with new log file.

KIndly please provide solution for this.

Regards,

jitendra

[Former Member]

If the database is being backed up correctly, then it should shrink the log file. If yours has reached that size, I would suggest that something is not right either with the backup function or an associated service. You need to address this as a matter of urgency.

If you want to reduce the log file size in order to keep things running, then a straight forward way to do this is to use the SQL Studio and perform a full manual backup; first of the database itself, then of the trans log. If you don't have space on the specific server, you can always direct the backup to a networked resource.

Once the backup is complete, you can then shrink the log file (make sure that you do NOT try to shrink the database!). You may then need to backup the translog a second time (which will take less time) and then try shrinking again.

If the problem has been growing over a period of time (rather than as a specific action) it may be necessary to repeat this a few times before the translog shrinks to a more normal size.

But once again, note that this is only for a quick and dirty fix; it is not a replacement for a proper backup procedure and it is vital that you address any backup issues as soon as possible.

Regards

Tony

[clas_hortien]

 If the database is being backed up correctly, then it should shrink the log file. 

This is not true. The log backup (and only the log backup) might clear the log within the log file, but it will never shrink the file.

 You may then need to backup the translog a second time (which will take less time) and then try shrinking again. 

Why should this be necessary ? Once you have backed up the log, the log should be truncated. Only if you had an open transaction which hindered the truncation, a second log backup (once the transaction is done) and a second shrink might be necessary.

 If the problem has been growing over a period of time (rather than as a specific action) it may be necessary to repeat this a few times before the translog shrinks to a more normal size.

The problem is not dependent on the way how it builds up. It makes no difference if you get an huge transaction log due to a hugh data modification action or through not-backing-up-the-log over a longer time. The solution to fix it and the result is the same.

Regards

Clas

[clas_hortien]

Hello,

the CSS note 363018 explains the shrink of the log file, the note 151603 how to move the files.

Best regards

Clas