Remove .ldf file from Nav DB.

manikandan
manikandan Member Posts: 160
edited 2013-06-13 in NAV Three Tier
Hi All,
If there is any impact ,while i am removing ".ldf" file from SQL Server. :?:

Regards,
Muthusubramanian.M

Comments

  • bbrown
    bbrown Member Posts: 3,268
    Can you explain what you are tying to accomplish? The LDF file is the SQL transaction log. A read/write SQL database will not function without it.
    There are no bugs - only undocumented features.
  • manikandan
    manikandan Member Posts: 160
    bbrown wrote:
    Can you explain what you are tying to accomplish? The LDF file is the SQL transaction log. A read/write SQL database will not function without it.

    Log file size is 110 GB for our customer.This may be affect the performance ?
    So this is the reason for raising a question.

    Regards,
    Muthusubramanian.M
  • bbrown
    bbrown Member Posts: 3,268
    Why would it be affecting performance? The log is a sequentially written file. It should be on a dedicated RAID 1 or RAID 10 array. Is it? Placing the log file on a shared drive can have a performance impact. How much will depend on the system's activity level.

    The physical size of the log file is not important. What matters is that it maintains enough free space (internally) to log activity without the need to auto-expand. If you find your log auto-expanding, you can control it by either increasing the size or the frequency of transaction log backups. As with any NTFS drive, you should maintain a minimum of 10% free space on the drive.

    How large is your database? What is your recovery model?
    There are no bugs - only undocumented features.
  • davmac1
    davmac1 Member Posts: 1,283
    Some people don't know you need to backup the transaction log, so it keeps growing until they run out of space.
    If you are not running simple recovery, then do at least 1 transaction log backup after your database backup.
    Also create notifications for when either fails.
    Simple recovery is generally not recommended for production environments unless you can live with going back to your last good database backup.
    David Machanick
    http://mibuso.com/blogs/davidmachanick/

Categories