DOCUMENT:Q176239 27-OCT-1999 [exchange] TITLE :XADM: DB Won't Start; Circular Logging Deleted Log File Too Soon PRODUCT :Microsoft Exchange PROD/VER:winnt:5.5 OPER/SYS: KEYWORDS:kbusage exc55 ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Exchange Server, version 5.5 ------------------------------------------------------------------------------- SYMPTOMS ======== With circular logging enabled, the database may not restart after an abnormal stop, and a JET_errFileNotFound error may be displayed numerically in any of the following forms: - -1811 - 4294965485 - 0xfffff8ed In the application event log, events 1120 and 5000 contain the hexadecimal version (0xfffff8ed) of the error. NOTE: Events 1120 and 5000 are generic database start errors; you must interpret the code in their descriptions to understand the exact reason that the database stopped responding. CAUSE ===== This may be caused by a problem in the checkpoint file. If this is the case, and you delete the Edb.chk file, the database starts. However, pay close attention to the cautions listed in the "Resolution" section of this article before you delete the checkpoint file. If circular logging is enabled, Exchange Server deletes transaction log files as soon as all of the data in them has been written out to the main database files. This process is tracked by the checkpoint. The actual checkpoint that the database uses is held in memory, but it is frequently written out to the Edb.chk file. Another process may hold open the Edb.chk file, which prevents Exchange Server from updating the checkpoint file when the checkpoint advances. Applications such as virus scanners and backup programs may "steal" the checkpoint file temporarily. Exchange Server continues to function normally, and to update the checkpoint in memory, while it waits for the other process to release the Edb.chk file. If the Edb.chk file is locked against Exchange Server for more than a short period of time, the log file listed in it may be deleted before the Edb.chk file is updated. If the database stops suddenly, the checkpoint in memory is lost. When the database is restarted, it must rely on the checkpoint recorded in the Edb.chk file. Because the Edb.chk file points to a nonexistent transaction log file, the database does not start, and a JET_errFileNotFound error is displayed. RESOLUTION ========== Remove the Edb.chk file, and then restart the database service. If the Edb.chk file is gone, Exchange Server scans through all the available log files, and then begins recovery using the first log file that it finds. Cautions -------- Do not remove the Edb.chk file unless you know exactly why you need to remove it, and unless you know that you can safely remove it in your current circumstances. Removing the Edb.chk file in certain circumstances may irreparably damage the database. For additional information about the checkpoint, click the article numbers below to view the articles in the Microsoft Knowledge Base: Q240145 XADM: How to Tell Which Transaction Log Files Can Be Safely Removed Q237767 XADM: Making and Restoring Offline Backups If you are experiencing the conditions described here, and if all of the following statements are true, you can safely delete the Edb.chk file: - You have not moved, renamed, deleted, replaced, or otherwise tampered with the database or transaction logs after the abnormal shutdown. For recovery to succeed, the database and transaction logs must be in exactly the same state that they were in when the database stopped. - If you ran the eseutil /r command against the database, and you used the /is or /ds switches to run it. (The eseutil /r /is command is for the information store, and the eseutil /r /ds command is for the directory service.) If you omit the /is or /ds switches, the soft recovery assumes that the log files are in the folder that you ran Eseutil from. If the log files are elsewhere, as they usually are, soft recovery creates a new Edb.log file and tries to recover against the wrong set of log files. You can still delete the Edb.chk file after such an event, but the database still may not start, and you may need to restore it from a backup. - You have circular logging enabled. If circular logging was disabled at the time of the abnormal shutdown, none of the recommendations in this article apply. If circular logging is disabled, transaction log files are not automatically deleted when the checkpoint advances. This means that the cause of the restart problem is different than the cause described here. Additional query words: ====================================================================== Keywords : kbusage exc55 Technology : kbExchangeSearch kbExchange550 kbZNotKeyword2 Version : winnt:5.5 Issue type : kbprb ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 1999.