Announcement

Collapse
No announcement yet.

exchange logs not truncating

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • exchange logs not truncating

    Hi guys, I have this issue whereby I have backed up my exchange volume.
    It shows successful but the logs are not being truncated. This is done with circular logging disabled. After backup is done, seeing logs are not truncated, I enabled my circular logging and restarted my Exchange IS service but to no avail.

    The logs is still there, not truncated.

    I'm using DAG (3 Mailboxes - MB1,MB2,MB3). Right now, both passive copies are in failed and suspended state. Due to sufficient storage space issue, I'm trying to fix the growing log file before proceeding with manual reseeding of other 2 passive copy.

    Any advice for me on how to allow my logs to get truncated automatically.

    **Note: Initially when I ran backup, it failed the inconsistency check, I added "EnableVSSWriter" with value "0" in the regedit exchange parameter and the backup manage to complete successfully. Am I missing anything here?

  • #2
    Re: exchange logs not truncating

    If the DAG replication has failed, then the logs will not flush.
    In a DAG the logs are part of the replication, so for the logs to flush, both the DAG replication has to complete, but also a successful backup needs to take place.
    Even with circular logging enabled, if the replication isn't successful then the logs will build up.

    As you have run out of disk space, you have an almost perfect storm.

    You cannot delete the logs to get the space back.
    What I usually do here is compress the logs, using the native tools within Windows. You cannot compress the entire drive or directory though, as that will cause you problems. Select the oldest logs (and ONLY *.log files), then right click on them. Choose Advanced and then compress. Press apply and wait.
    Windows will compress the logs and Exchange will start to immediately use the space. You will need to do that on both sides of the DAG.

    When the logs flush, the compressed files will go as well and the drive performance will return to normal.

    Simon.
    --
    Simon Butler
    Exchange MVP

    Blog: http://blog.sembee.co.uk/
    More Exchange Content: http://exchange.sembee.info/
    Exchange Resources List: http://exbpa.com/
    In the UK? Hire me: http://www.sembee.co.uk/

    Sembee is a registered trademark, used here with permission.

    Comment


    • #3
      Re: exchange logs not truncating

      So the only way now is to make sure the other passive copies are in healthy state before the next backup on the active copy will truncate all of it logs?

      If that is so, this is what I intend to do, let me know if I'm missing anything:
      1. Suspend both passive mailbox database on each of the dag servers (Can skip this since both already in Failed And Suspended state)
      2. Delete passive copy entire file and logs (Does this include the .edb file and those .chk, .jrs files?)
      3. Dismount the active database copy. (Should I do a eseutil /mh at this point to ensure a clean shut down?) My concern at this point is that it has dirty shut down.
      4. Wait until fully dismounted
      5. Move the existing logs (on active server) to another location (Not delete!). At this point, does it means that no log files should be in the same folder as the edb file? Will it cause any errors? (As the log files sum up to 500+ GB, I know this is real bad..).
      6. Copy the active EDB database file and transfer geographically to the other site.
      7. After transfer on all sides are completed (Meaning the 2 passive copies have the update to date edb file, I will then mount the active database copy again.
      8. After mounted, I will either use PowerShell command to resume the replication "Resume-MailboxDatabaseCopy –identity “database\server”" or use GUI to do it.
      9. As long as I start the replication ASAP, the logs are not too far apart, I should be able to get the replicating again, right?

      Based on my procedure above, am I missing anything or do I need to take note of anything in particular?

      ================================================== ========

      Assuming the entire process is a successful (All passive back healthy), am I right to say that the logs will auto flush once it has been committed to the edb file and checked for consistency in the chk file?
      Last edited by xnait; 24th March 2015, 17:50. Reason: Addition info

      Comment


      • #4
        Re: exchange logs not truncating

        You are correct - the DAG has to be healthy before the logs will flush. The next backup has nothing to do with it. As soon as the replication is complete, the logs will flush.

        Moving the logs to another location achieves nothing. It is the same as deleting the logs because they are in a different location to the one that Exchange expects.

        That is why compressing the logs until you get enough space to allow Exchange to bring the two databases back in to sync usually works.

        Simon.
        --
        Simon Butler
        Exchange MVP

        Blog: http://blog.sembee.co.uk/
        More Exchange Content: http://exchange.sembee.info/
        Exchange Resources List: http://exbpa.com/
        In the UK? Hire me: http://www.sembee.co.uk/

        Sembee is a registered trademark, used here with permission.

        Comment


        • #5
          Re: exchange logs not truncating

          I see! Okay, I will do planning for this maintenance and let you know how it turns out.

          Anyway, will compression of transaction logs cause any issue in circumstances that you need to re use the log? Like corruption or anything?

          Comment


          • #6
            Re: exchange logs not truncating

            The compression is using the windows file system and should be completely safe
            Tom Jones
            MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
            PhD, MSc, FIAP, MIITT
            IT Trainer / Consultant
            Ossian Ltd
            Scotland

            ** Remember to give credit where credit is due and leave reputation points where appropriate **

            Comment

            Working...
            X