คุณสามารถคืนค่าแฟ้มล็อกธุรกรรม (E0n*.log) ไปยังเส้นทางอื่นนอกเหนือจากตำแหน่งที่สำรองข้อมูลต้นฉบับ นี่คือเนื่องจากตำแหน่งที่ตั้งของฐานข้อมูลที่ล็อกธุรกรรมแนบอยู่กับบันทึกล็อกธุรกรรม แต่ฐานข้อมูลไม่บันทึกตำแหน่งที่ตั้งของไฟล์บันทึกของธุรกรรม ในระหว่างการ replay ล็อก "หา" ฐานข้อมูล โดยใช้เส้นทางข้อมูลที่เก็บไว้ในหัวข้อการล็อกธุรกรรม (The online backup API compensates internally for database path changes, and so this limitation does not apply.)
You do not back up or restore the checkpoint file (E0n.chk), but you must know the current location of the checkpoint file because you may need to examine it or delete it during recovery.
How Exchange Database Files Relate to Each Other
The .edb and .stm files are the final repositories for all database information. For most purposes, treat these two files as if they are a single file; back up and restore these files in tandem. These files must stay synchronized chronologically with each other; an .edb file that is backed up on one day cannot be matched with a streaming file that is backed up on another day.
An Exchange 2000 or an Exchange 2003 server can support up to four storage groups, and each storage group can support up to five databases. A storage group is a set of databases that share a common set of transaction log files. Microsoft Exchange Server 5.5 can support a maximum of one storage group, which supports up to two databases (the private and public information stores).
As changes are made to the database, the changes are first written to the current transaction log file, and then to an in-memory cache. As soon as changes are present in the cache, those changes become visible to users. Pages in the cache are flushed to the database file when it is convenient to do so. The checkpoint marks the point in the log file sequence up to which all transactions have been physically flushed to the database file. It is normal for the checkpoint to lag three or more log files behind the current log file.
To avoid confusion about which log files belong to each storage group, Exchange logs that belong to a given storage group are named with a unique log prefix, which is the first three characters of the file name. Valid log prefixes for the four storage groups that are supported on an Exchange 2000 or Exchange 2003 server are E00, E01, E02, and E03. Throughout this article, the log prefix for a storage group is designated as E0n. The current log file for a storage group is always E0n.log.
Transaction logs are a uniform 5 megabytes (MBs) in size. When the current log file is full, it is renamed with a hexadecimal sequence number, called the log generation number, and a new current log file is generated. Log files are numbered as E0n00001.log, E0n00002.log, and so on. Throughout this article, numbered log files are designated generically as E0nxxxxx.log.
ถ้าคุณดูตัวอย่างก่อนหน้านี้ รายการสุดท้ายที่สอดคล้องกันเป็น (0x2CC7, 1F14, 1F7) หมายเลขสามกำหนดล็อกไฟล์ หน้าในล็อกไฟล์นั้น และออฟเซตของไบต์เป็นหน้านั้น แต่ละแฟ้มล็อกประกอบด้วยประมาณ 10000 หน้า 512 ไบต์แต่ละ The page offset gives you a good idea of how close the log file is to being full (the log file in the preceding example is about 80 percent full, because 0x1F14 is equivalent to decimal 7956), but is irrelevant to recovery. Recovery always starts at the beginning of a log file.
In this example, the low anchor log file is E0n02cc7.log.
You may not always see the last consistent log on disk as a numbered log, because the last consistent log may still be named E0n.log. You can see the sequence number E0n.log will eventually be given by examining the log file header while the database is stopped (access is denied to the E0n.log header while the database is running).
To view the internal log generation number, run the following command:
In many circumstances, it is more important to make sure that your log file backups are good than it is to make sure that each database backup is good. This is because each database backup can provide redundancy for the others, but full recovery from any database backup is dependent on the preservation of each and every log file after that backup.
Skip this step if circular logging is enabled. Examine the header of the checkpoint file to determine the highest numbered log file that can be safely removed. The checkpoint tracks the lowest numbered log file that is necessary for automatic recovery if the database is abnormally stopped. To examine the checkpoint file, run the following command:
The third line, the Checkpoint line, contains the relevant information (the LastFullBackupCheckpoint entry is used by online backup, and remains all zeroes if an online backup is never performed against the database). The Checkpoint log position format is the same as the last consistent entry in the database header. In this example, the checkpoint is in E0002cc7.log.
If circular logging is disabled, log files accumulate until they are either manually deleted or removed automatically by the online backup process. If circular logging is enabled, no special management of old log files is required, because the database service automatically deletes old log files after the checkpoint passes through them.
After you back up all of the numbered log files, you can reclaim disk space by removing all of the numbered log files up to, but not including, the checkpoint log.
สิ่งสำคัญ: Do not remove the checkpoint log.
In this example, you can remove all of the logs up to E0002cc6.log.
This step is optional. You can use the Esefile utility to verify the page-level integrity of the copied databases.
The Esefile.exe file is available in the Support folder on the Exchange Server 5.5 Service Pack 3 CD-ROM, the Exchange 2000 Server installation CD-ROM, or the Exchange Server 2003 installation CD-ROM. You can also obtain the Esefile.exe file from Microsoft PSS. The Esefile utility works for .edb files from Exchange Server 5.0 and 5.5, Exchange 2000, and Exchange 2003.
There is currently no method other than online backup to verify the checksums for each page of an .stm file. The .stm file contains raw data. All of the indexes and pointers that organize that data are in the .edb file. A problem in the .stm file causes some specific client data loss, but does not compromise the structural or logical integrity of the database as a whole.
To verify the page checksums for an Exchange database, run the following Esefile utility command:
Uninitialized pages are acceptable, but in a database with no problems, there are 0 bad checksums and 0 wrong page numbers.
If a database does not pass the Esefile utility integrity check, your best option is to restore an earlier backup that you know to be good, and to roll the database forward. If such a backup is not available, consult PSS for advice about how to repair or salvage the database.
This step is optional. You can use the following command to verify the integrity of backed up log files:
In the preceding example, the checkpoint is in the log with the lGeneration of 0x2cc7, which is e00.log. Therefore, the checkpoint can be considered valid.
If the checkpoint is not valid, you might receive a -1216 error message (JET_errAttachedDatabaseMismatch) when you attempt to mount any database in the storage group. This issue can occur even if all of the databases in the storage group are consistent.
Copy the backed up .edb and .stm files to the appropriate database and streaming file locations. (To find these locations, refer to the "Before You Begin" section of this article.) Verify that the restored files are consistent and matched.
หมายเหตุ:: If copies of the database files that you want to restore already exist on the server, back these files up before you restore the database, even if the existing files are not startable. They might be repairable, and you might be able to salvage data from them by using the Exmerge utility.
Mount the restored database. The database attaches itself to the end of the E0n.log file. After the database has been successfully started, no previously existing log files can ever be replayed into the database. Public folder databases that contain thousands of folders in the hierarchy may take a long time to start. Allow for at least one minute for every 1,000 folders in the hierarchy.
In earlier versions of Exchange Server, you usually needed to run theISINTEG -patchcommand after you restored an offline backup of an information store database, to synchronize the information store database with the directory. When patching for an Exchange database is necessary, that patching is done automatically by the system, unless the database is restored to a different server, storage group, or logical database object, or the Active Directory object for the database has been deleted and re-created in Active Directory. In these cases, the following error message is logged in the Application event log.
ชนิดเหตุการณ์: ข้อผิดพลาด Event Source: MSExchangeIS Mailbox Store Event Category: General Event ID: 1087 Date: 5/4/2001 Time: 8:33:42 PM ผู้ใช้: n/a Computer: EXCHANGE1 Description: The information store was restored from an offline backup. In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched.
To resolve this problem, you must click to select theThis database can be overwritten by a restorecheck box in Exchange System Manager, in the Database properties of the database object.
Roll Forward Restoration of an Offline Backup
For the best chance of complete success replaying log files into a restored database:
Preserve a copy of all of the transaction logs that were created after the time of your oldest full backup.
Do not change a database path without making a new full backup immediately afterward.
Do not runESEUTIL /pหรือESEUTIL /dwithout taking a new full backup immediately afterward.
Do not add or remove a database in a storage group without immediately making a full backup of all of the databases in the storage group.
To begin the restoration process:
If the database that you want to restore is mounted, dismount it, and then copy the database files that you want to restore to the appropriate paths on the server. If copies of the database files that you want to restore already exist on the server, back these copies up before you restore the database, even if the existing files are not startable. The files may be repairable, and you may be able to use the Exmerge utility to salvage data from them.
Dismount all of the databases in the storage group, and then run the following command against each database in the current storage group, and against each restored database file:
หมายเหตุ:: Exchange 2000 Service Pack 2 and later do not report the database state as "Consistent" or "Inconsistent" but as "Clean Shutdown" or "Dirty Shutdown." ความหมายของ "ใหม่ทั้งหมดปิดระบบ" จะเหมือนกับ "Consistent" และความหมายของ "สกปรกปิดเครื่อง" จะเหมือนกับ "Inconsistent" สำหรับ Exchange 2000 Service Pack 2 หรือในภาย หลัง เรียกใช้คำสั่งนี้เพิ่มเติมเพื่อตรวจสอบสถานะของแต่ละฐานข้อมูล:
To verify that the database files are each consistent.
To verify that the .edb and .stm files for each database are a matched pair.
To identify the low and high anchor log files, which are the first and last log files that are required to successfully recover all data without generating a -1216 error. The lowest last consistent value across all databases is the low anchor log and the highest last consistent value is the high anchor log.
แม้ว่าคุณสามารถเปลี่ยนเส้นทางการล็อกธุรกรรมหรือเส้นทางการทำงานหลังจากที่คุณทำการสำรองข้อมูล คุณสามารถเพียงทำ replay ในแฟ้มบันทึกถ้าแฟ้มฐานข้อมูลที่อยู่ในตำแหน่งเดียวกันที่จะถูกสำรองไว้จาก If you are unsure of the original locations, run the following command:
eseutil /ml"Last_Consistent"_log| find /i "database name or pattern"
หมายเหตุ:: If the low anchor log is E0n00001.log, it will not have path information in its header, because the header for the first log in a series is generated before the first database is ever attached to the log. In this case, you must look in the next log's header to view database path information. In rare cases, this may also be true for logs later than the first one, because a database was created or attached to the log stream after the log was created.
Gather all of the logs, from the low anchor number as far forward as possible in unbroken sequence, and copy these logs to the current transaction logs path. Do not overwrite logs that are already in place on the server without backing those logs up first. To do this, you may need to restore log files from more than one type of backup media.
In the preceding example, the low anchor is E0002ac8.log and the high anchor is E0002cc7.log. When you examine available logs, the highest numbered log that you can find might be one number less than the necessary number (for example, E0002cc6.log, instead of 2cc7). This usually occurs because the E0n.log has not yet been filled and renamed to its number in the sequence. To determine whether E0n.log is actually the high anchor log, you must use the following command to examine thelGenerationvalue in the log file header:
หมายเหตุ:: To view the header of a log file with the Eseutil utility, use the/mlswitch; to view a database file header, use the/mhสลับไป If you confuse the switches, the output from the commands is incorrect.
Typically, the high anchor log is also the highest log available, but this is not true if:
Log files have been destroyed in a disaster.
หรือ
You are restoring all of the databases at once in a storage group.
In the first case, you are likely to encounter -1216 errors during recovery; in the second case, you can play log files forward, even past the high anchor log, as long as they continue the lGeneration sequence.
Verify that all of the logs share the same log signature and are in unbroken sequence. Run the following command:
d:\mdbdata>eseutil /ml E00 > logverify.txt
d:\mdbdata>type logverify.txt
Microsoft(R) Exchange Server(TM) Database Utilities
Version 6.0
Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.
Initiating FILE DUMP mode...
Verifying log files...
Base name: e00
Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
Log file: D:\exchsrvr\mdbdata\save1\E00.log
No damaged log files were found.
Operation completed successfully in 3.305 seconds.
This Eseutil command does three things: checks each log file for damage, reports any gap in the log file sequence, and detects log signature mismatches.
All log signatures must match between all log files that are replay candidates. You must remove any logs that do not have matching signatures before replay begins.
At this point, after you remove the files that did not pass the verification tests, the only transaction log files in the Transaction Logs folder are files that:
Are in unbroken lGeneration sequence, starting with the low anchor log file and continuing up to at least the high anchor log file, and beyond that, if possible.
Have matching log signatures.
If the high anchor log is not already named E0n.log, rename it.
Remove the E0n.chk file from the System Path folder.
In the absence of a checkpoint file, Exchange Server begins to replay the logs from the lowest numbered log file that is available in the Transaction Logs folder: the low anchor log. If the E0n.chk file exists, Exchange Server begins replay at the checkpoint that is recorded in this file. If E0n.chk points past the low anchor log, replay fails entirely for the restored file set. In many cases, if you make a mistake with the checkpoint file, you must start over restoring database files from backup.
As a final check before you mount the storage group, verify that:
All of the database files are present in their running paths.
The only log files in the running transaction log path are files that start from the low anchor log and continue at least to the high anchor log, with the highest available log named E0n.log.
There is no E0n.chk file in the System Path folder.
You should now be able to successfully mount the storage group and begin to replay transaction logs with this file set. Even after recovery finishes and the database starts, all of the data in all of the log files might not actually be recovered because of DB signature and path issues that are encountered during replay. The "Dealing with Database Signature and Path Mismatches" section of this article provides additional information about these issues.
If the information store is not already running, start it, and then mount at least one database in the storage group. This causes soft recovery to run against all of the databases in the storage group.
In earlier versions of Exchange Server, you usually need to run theISINTEG -patchcommand after you restore an offline backup of an information store database, to synchronize the database with the directory. When patching for an Exchange database is necessary, that patching is done automatically by the system, unless the database is restored to a different server, storage group, or logical database object, or the Active Directory object for the database has been deleted and re-created in Active Directory. In these cases, the following error message is logged in the Application event log.
ชนิดเหตุการณ์: ข้อผิดพลาด Event Source: MSExchangeIS Mailbox Store Event Category: General Event ID: 1087 Date: 5/4/2001 Time: 8:33:42 PM ผู้ใช้: n/a Computer: EXCHANGE1 Description: The information store was restored from an offline backup. In the Microsoft Exchange System Manager, indicate that the database "First Storage Group\Private Information Store" is allowed to be restored to, so that it can be patched.
To resolve this issue, you must click to select theThis database can be overwritten by a restorecheck box in Exchange System Manager, in the Database properties of the database object.
Check the Application event log in the Microsoft Windows NT Event Viewer for any errors or anomalies that might occur when the database starts. An event 301 is displayed for each log file that is replayed. Watch carefully for errors and warnings during the recovery process.
Dealing with Database Signature and Path Mismatches
Databases, like log files, have their own signatures. But although log signatures do not change after the time that the E0n000001.log file is created, database signatures change whenever the physical topology of the database is altered, without the changes being tracked through the log files. Offline defragmentation or repair of a database with Eseutil changes the DB signature. After such an event, the database can be attached to the same log stream as before, but the database does not accept replay of any transactions that were performed while the database had its earlier signature. An earlier copy of the database does not accept replay of any transaction that was performed after the database's signature changed.
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
กลับไปด้านบน
