| Details | |
| Product: | Exchange |
| Event ID: | 500 |
| Source: | ESE98 |
| Version: | 6.0 |
| Component: | Extensible Store Engine |
| Symbolic Name: | REPAIR_BAD_PAGE_ID |
| Message: | {process name} ({process id}) The database engine lost one page of bad data. It is highly recommended that an application-level integrity check of the database be run to ensure application-level data integrity. |
| Explanation | |
| The database may have been repaired, which may result in lost data. Although the Repair process attempts to validate all system tables and indexes, any data that cannot be repaired is discarded. If the database cannot be repaired, a run-time error occurs. | |
| User Action | |
| Perform an application-level integrity check of the database to ensure application-level data integrity. | |
Tag: Event 500
The DNS server has detected that the zone %1 has invalid or corrupted registry data. To correct the problem, you can delete the applicable zone subkey, located under DNS server parameters in the Windows 2000 registry. You can then recreate the zone using the DNS console. For more information, see “Tuning advanced server parameters” and “Add and Remove Zones” in the online Help.
| Details | |
| Product: | Windows Operating System |
| Event ID: | 500 |
| Source: | DNS |
| Version: | 5.0 |
| Symbolic Name: | DNS_EVENT_INVALID_REGISTRY_ZONE |
| Message: | The DNS server has detected that the zone %1 has invalid or corrupted registry data. To correct the problem, you can delete the applicable zone subkey, located under DNS server parameters in the Windows 2000 registry. You can then recreate the zone using the DNS console. For more information, see “Tuning advanced server parameters” and “Add and Remove Zones” in the online Help. |
| User Action | |
|
To delete the zone from the registry: 1. Click Start, and then click Run. |
|
Related:
%1 (%2) %3The database engine lost one page of bad data. It is highly recommended that an application-level integrity check of the database be run to ensure application-level data integrity.
| Details | |
| Product: | Exchange |
| Event ID: | 500 |
| Source: | ESE |
| Version: | 8.0 |
| Symbolic Name: | REPAIR_BAD_PAGE_ID |
| Message: | %1 (%2) %3The database engine lost one page of bad data. It is highly recommended that an application-level integrity check of the database be run to ensure application-level data integrity. |
| Explanation | |
|
This Warning event indicates that a database repair process may have caused data to be lost. Although the repair process tries to validate all system tables and indexes, any data that cannot be repaired is discarded. If the database cannot be repaired, an error occurs. When a database is in an inconsistent condition and a repair is performed by using eseutil /p, ESE event 500 may be logged during the repair operation. ESE event 500 indicates that the repair process found a bad page and tried to repair it, but the repair of the page was unsuccessful and the page was discarded. ESE event 500 is a serious error that frequently indicates that the database is damaged. |
|
| User Action | |
|
To resolve this warning, run isinteg -fix on the database. After a successful repair that indicates some lost data, run eseutil /d to defragment the database and rebuild indexes, and then run isinteg -fix to restore referential integrity between tables in the database. Repair may not have corrected all problems in the database. To completely guarantee database integrity, you may want to use the Move Mailbox tool to move all mailboxes temporarily to a different database. You can then delete the files for this database. Exchange will create new database files when you mount the database, and you can then move mailboxes back to the database. If this is a public folder database, replicate all folders to a different public folder database and verify that replication has completed for all folders. You can then delete the files for this database. Exchange will create new database files when you mount the database, and all folders will automatically replicate back to this database after a period of time. If the repair process fails because the database is too damaged even for a repair, you must restore from Exchange-aware online backup. If there is no valid backup available, check to determine if users are storing their data locally in .pst files on their client computers. If they are, create a new blank database and use the .pst files to recover as much data as possible. |
|
Related:
process name (process id) %3The database engine lost one page of bad data. It is highly recommended that an application-level integrity check of the database be run to ensure application-level data integrity.
| Details | |
| Product: | Exchange |
| Event ID: | 500 |
| Source: | ESE |
| Version: | 6.5.0000.0 |
| Message: | process name (process id) %3The database engine lost one page of bad data. It is highly recommended that an application-level integrity check of the database be run to ensure application-level data integrity. |
| Explanation | |
|
The database may have been repaired, which may result in lost data. Although the Repair process attempts to validate all system tables and indexes, any data that cannot be repaired is discarded. If the database cannot be repaired, a run-time error occurs.
You will receive the following phrase in the event Description: ESEUTIL (number) The database engine lost one page of bad data. It is highly recommended that an application-level integrity check of the database be run to ensure application-level data integrity. When a database is in an inconsistent condition and a repair using Eseutil /p is performed on the database, an ESE Event ID 500 has been known to occur during the repair. The event indicates that the repair process found a bad page and attempted to repair it, but the repair of the page was unsuccessful and the page was discarded. ESE Event ID 500 has been found to be a serious error which can be indicative of a damaged database |
|
| User Action | |
|
If the repair process is successful, run Isinteg -fix on the database. Then use ExMerge to save the data to .pst files, create a blank database and ExMerge the data back into the new database. As an hardware problems are the root cause of the database damage, do not ExMerge or move mailbox back until the root cause has been fixed.
If the repair process fails because the database is too damaged even for a repair, then you must restore from Exchange-aware online backup. If there is no valid backup available, check to find out if users are storing their data locally in .pst files on their client machines. If they are, create a new blank database and use the .pst files to recover as much data as possible. |
|