Help, Corrupt DB - Event ID 116

Help, Corrupt DB - Event ID 116

Post by Stephe » Tue, 20 Nov 2001 11:00:59



Hi All,

Exchange 5.5  SP2,

It appears my Exchange 5.5 SP2 database is corrupt.  It is up and running at
the moment, but a client is getting an error when trying to archive
messages.  I have had a look at the event log and there are a heap of 116
event IDs with occasional 117, and 200.  They all refer to -1018 errors in
the database.  For the 116 errors Technet advises to restore from backup
after determining the source of the problem.  The source is a faulty disk
that I will run checkdisk on (or possibly add a new disk and move the
database to it).  However, the last backup worked OK and therefore removed
the transaction log files, but the Event ID errors started prior to this
backup.  So if I restore this backup, I'll restore the corruption - Yes?  If
I restore from a backup prior to this I'll lose all information after that
backup.

What is the best course of action to limit the amount of data loss.  Should
I just run CheckDisk, and provided it fixes the problem, then restore from
the backup after the errors started appearing then run eseutil /r /is ?  Or,
forget the backup and use eseutil. Or will I just have to suffer the loss
and restore from an earlier backup?

Thanks,

Stephen.

 
 
 

Help, Corrupt DB - Event ID 116

Post by Rich Matheisen [MVP » Tue, 20 Nov 2001 12:15:51



>Exchange 5.5  SP2,

Ummm, why not SP3 -- or even better, SP4? SP2 is years old.

Quote:>It appears my Exchange 5.5 SP2 database is corrupt.  It is up and running at
>the moment, but a client is getting an error when trying to archive
>messages.  I have had a look at the event log and there are a heap of 116
>event IDs with occasional 117, and 200.  They all refer to -1018 errors in
>the database.  

The -1018 is telling you that the data, when read from a page, fails
to recompute the correct checksum. IOW, the page is nt as it was when
it was written.

Quote:>For the 116 errors Technet advises to restore from backup
>after determining the source of the problem.  

That's the correct course of action.

Quote:>The source is a faulty disk
>that I will run checkdisk on (or possibly add a new disk and move the
>database to it).  

It's unlikely that will result in the database being rendered error
free, but it /may/ relocate the damaged sector -- if the problem is
the disk and not the controller or cables (or memory).

Quote:>However, the last backup worked OK and therefore removed
>the transaction log files, but the Event ID errors started prior to this
>backup.  

Are you making on-line backups? An off-line backup will not detect
this damage because it doesn't verify that the checksum for each page
is correct. It allows you to make backups of data that is unusable.

Quote:>So if I restore this backup, I'll restore the corruption - Yes?  

If you were making off-line backups, yes. If you were making ON-LINE
backups and you didn't get any -1018 errors then the backup is okay.

However, if that is the case (that you made on-line backups and didn't
log -1018 errors) then I'd try making another backup and see if you
are successful. If you are, then it's probably NOT the disk, but the
disk controller firmware that's the problem. There's a tool (ESEFILE)
that appeared with SP3 (IIRC) that will read the entire database and
verify the checksums. Since it does so with the Information Store
service stopped it eliminates the load on the controller and simply
reads the file sequentially. SP3 introduce another beneficial feture
-- a retry on -1018 errors that almost always succeeds if the cause is
firmware that delivers disk sectors in the incorrect order.

Quote:>If
>I restore from a backup prior to this I'll lose all information after that
>backup.

Not if the log files are on another disk spindle and that disk is
okay. When you restore the previous ON-LINE backup, the log files will
be replayed when the IS retarts.

Quote:>What is the best course of action to limit the amount of data loss.  

Make an on-line backup and check the logs for success.

Quote:>Should
>I just run CheckDisk,

I'd try the backup first. If the ON-line backup fails, then try to get
an OFF-line backup. That way you'll at least have something to restore
if your earlier backup proves to be unusable.

Quote:>and provided it fixes the problem, then restore from
>the backup after the errors started appearing then run eseutil /r /is ?  

After restoring from an on-line backup, the IS performs a recovery,
which is what that ESEUTIL would do with those parameters.

But, after restoring from the ON-LINE backup, you MUST restart the IS
before you do /anything/ else. Do NOT run ESEUTIL or ISINTEG until
AFTER the IS has had a chance to apply the .PAT file and replay the
.LOG files.

Quote:>Or,
>forget the backup and use eseutil.

ESEUTIL is the /last/ thing to try, not the first.

Quote:>Or will I just have to suffer the loss
>and restore from an earlier backup?

See above.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm

 
 
 

Help, Corrupt DB - Event ID 116

Post by Stephe » Tue, 20 Nov 2001 14:01:21


Thanks Rich for the quick response.

Yes we are making on-line backups with NT Backup.  I'll try another online
backup and make sure I don't get any errors.  If the online backup runs OK
with no errors, can I assume my Database is OK?

The system log is sporadically logging errors with event ID's 41 (source
diskperf);

"The file system structure on the disk is corrupt and unusable. Please run
the chkdsk utility on the device  with label "User Data". "

This is why I was going to run Chkdsk.

Unfortunately this servers disks aren't configured very well for Exchange -
They are all in one big RAID5.

Thanks again for your help.

Stephen.


>>Exchange 5.5  SP2,

>Ummm, why not SP3 -- or even better, SP4? SP2 is years old.

>>It appears my Exchange 5.5 SP2 database is corrupt.  It is up and running
at
>>the moment, but a client is getting an error when trying to archive
>>messages.  I have had a look at the event log and there are a heap of 116
>>event IDs with occasional 117, and 200.  They all refer to -1018 errors in
>>the database.

>The -1018 is telling you that the data, when read from a page, fails
>to recompute the correct checksum. IOW, the page is nt as it was when
>it was written.

>>For the 116 errors Technet advises to restore from backup
>>after determining the source of the problem.

>That's the correct course of action.

>>The source is a faulty disk
>>that I will run checkdisk on (or possibly add a new disk and move the
>>database to it).

>It's unlikely that will result in the database being rendered error
>free, but it /may/ relocate the damaged sector -- if the problem is
>the disk and not the controller or cables (or memory).

>>However, the last backup worked OK and therefore removed
>>the transaction log files, but the Event ID errors started prior to this
>>backup.

>Are you making on-line backups? An off-line backup will not detect
>this damage because it doesn't verify that the checksum for each page
>is correct. It allows you to make backups of data that is unusable.

>>So if I restore this backup, I'll restore the corruption - Yes?

>If you were making off-line backups, yes. If you were making ON-LINE
>backups and you didn't get any -1018 errors then the backup is okay.

>However, if that is the case (that you made on-line backups and didn't
>log -1018 errors) then I'd try making another backup and see if you
>are successful. If you are, then it's probably NOT the disk, but the
>disk controller firmware that's the problem. There's a tool (ESEFILE)
>that appeared with SP3 (IIRC) that will read the entire database and
>verify the checksums. Since it does so with the Information Store
>service stopped it eliminates the load on the controller and simply
>reads the file sequentially. SP3 introduce another beneficial feture
>-- a retry on -1018 errors that almost always succeeds if the cause is
>firmware that delivers disk sectors in the incorrect order.

>>If
>>I restore from a backup prior to this I'll lose all information after that
>>backup.

>Not if the log files are on another disk spindle and that disk is
>okay. When you restore the previous ON-LINE backup, the log files will
>be replayed when the IS retarts.

>>What is the best course of action to limit the amount of data loss.

>Make an on-line backup and check the logs for success.

>>Should
>>I just run CheckDisk,

>I'd try the backup first. If the ON-line backup fails, then try to get
>an OFF-line backup. That way you'll at least have something to restore
>if your earlier backup proves to be unusable.

>>and provided it fixes the problem, then restore from
>>the backup after the errors started appearing then run eseutil /r /is ?

>After restoring from an on-line backup, the IS performs a recovery,
>which is what that ESEUTIL would do with those parameters.

>But, after restoring from the ON-LINE backup, you MUST restart the IS
>before you do /anything/ else. Do NOT run ESEUTIL or ISINTEG until
>AFTER the IS has had a chance to apply the .PAT file and replay the
>.LOG files.

>>Or,
>>forget the backup and use eseutil.

>ESEUTIL is the /last/ thing to try, not the first.

>>Or will I just have to suffer the loss
>>and restore from an earlier backup?

>See above.

>--
>Rich Matheisen
>MCSE+I, Exchange MVP
>MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm

 
 
 

Help, Corrupt DB - Event ID 116

Post by Stephe » Wed, 21 Nov 2001 08:46:31


OK.  Ran an online backup and it worked OK with no errors at all.

Ran ChkDsk (although didn't see it as the server is at a remote location).
When the server came backup and Exchange started it logged a lot of the 116
errors with the odd 200.  Have not had any more disk errors logged yet
though.

The 116 errors are;

MSExchangeIS ((438) ) Synchronous read page checksum error -1018 ((1:223666
1:223666) (0-29621859) (0-40856619)) occurred. Please restore the databases
from a previous backup.

The 200 errors are;

MSExchangeIS ((438) ) A read of the database file
E:\exchsrvr\MDBDATA\PRIV.EDB between offsets 0x00000000369B3000 and
0x00000000369B3FFF failed after 16 failed read attempts with error -1018.
There is a software or  hardware problem affecting the database drive that
must be corrected to preserve database integrity. Contact Microsoft Product
Support Services.
 For more information, search the Microsoft Knowledge Base at  http: Event
ID number.

When Exchange started it logged about 120 of these 116 errors within 30
seconds.  These are the only errors that have come up, i.e. No more errors
since clients have logged on.

So, if my backups are OK, are my databases OK.  Should I just restore from
the last backup?  Any idea's of what I should do now?

Thanks,

Stephen.



>>Exchange 5.5  SP2,

>Ummm, why not SP3 -- or even better, SP4? SP2 is years old.

>>It appears my Exchange 5.5 SP2 database is corrupt.  It is up and running
at
>>the moment, but a client is getting an error when trying to archive
>>messages.  I have had a look at the event log and there are a heap of 116
>>event IDs with occasional 117, and 200.  They all refer to -1018 errors in
>>the database.

>The -1018 is telling you that the data, when read from a page, fails
>to recompute the correct checksum. IOW, the page is nt as it was when
>it was written.

>>For the 116 errors Technet advises to restore from backup
>>after determining the source of the problem.

>That's the correct course of action.

>>The source is a faulty disk
>>that I will run checkdisk on (or possibly add a new disk and move the
>>database to it).

>It's unlikely that will result in the database being rendered error
>free, but it /may/ relocate the damaged sector -- if the problem is
>the disk and not the controller or cables (or memory).

>>However, the last backup worked OK and therefore removed
>>the transaction log files, but the Event ID errors started prior to this
>>backup.

>Are you making on-line backups? An off-line backup will not detect
>this damage because it doesn't verify that the checksum for each page
>is correct. It allows you to make backups of data that is unusable.

>>So if I restore this backup, I'll restore the corruption - Yes?

>If you were making off-line backups, yes. If you were making ON-LINE
>backups and you didn't get any -1018 errors then the backup is okay.

>However, if that is the case (that you made on-line backups and didn't
>log -1018 errors) then I'd try making another backup and see if you
>are successful. If you are, then it's probably NOT the disk, but the
>disk controller firmware that's the problem. There's a tool (ESEFILE)
>that appeared with SP3 (IIRC) that will read the entire database and
>verify the checksums. Since it does so with the Information Store
>service stopped it eliminates the load on the controller and simply
>reads the file sequentially. SP3 introduce another beneficial feture
>-- a retry on -1018 errors that almost always succeeds if the cause is
>firmware that delivers disk sectors in the incorrect order.

>>If
>>I restore from a backup prior to this I'll lose all information after that
>>backup.

>Not if the log files are on another disk spindle and that disk is
>okay. When you restore the previous ON-LINE backup, the log files will
>be replayed when the IS retarts.

>>What is the best course of action to limit the amount of data loss.

>Make an on-line backup and check the logs for success.

>>Should
>>I just run CheckDisk,

>I'd try the backup first. If the ON-line backup fails, then try to get
>an OFF-line backup. That way you'll at least have something to restore
>if your earlier backup proves to be unusable.

>>and provided it fixes the problem, then restore from
>>the backup after the errors started appearing then run eseutil /r /is ?

>After restoring from an on-line backup, the IS performs a recovery,
>which is what that ESEUTIL would do with those parameters.

>But, after restoring from the ON-LINE backup, you MUST restart the IS
>before you do /anything/ else. Do NOT run ESEUTIL or ISINTEG until
>AFTER the IS has had a chance to apply the .PAT file and replay the
>.LOG files.

>>Or,
>>forget the backup and use eseutil.

>ESEUTIL is the /last/ thing to try, not the first.

>>Or will I just have to suffer the loss
>>and restore from an earlier backup?

>See above.

>--
>Rich Matheisen
>MCSE+I, Exchange MVP
>MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm

 
 
 

Help, Corrupt DB - Event ID 116

Post by Rich Matheisen [MVP » Wed, 21 Nov 2001 10:09:33



>Thanks Rich for the quick response.

>Yes we are making on-line backups with NT Backup.  I'll try another online
>backup and make sure I don't get any errors.  If the online backup runs OK
>with no errors, can I assume my Database is OK?

Yes, you can assume that. But if it were me, I'd be looking for why
you're getting the -1018 errors. As I said, SP3 added additional
checking that offers the opportunity for the firmware/hardware to
redeem itself and deliver the correct sectors. I guess I'd be looking
at the firmware and BIOS on that machine and its controllers, too.

Then I'd get SP4, run ESEFILE on the databases, then ESEUTIL /D, and
ISINTEG, too -- just to be sure.

Quote:>The system log is sporadically logging errors with event ID's 41 (source
>diskperf);

>"The file system structure on the disk is corrupt and unusable. Please run
>the chkdsk utility on the device  with label "User Data". "

>This is why I was going to run Chkdsk.

This is one symptom of either a failing disk/firmware/hardware.
Running chkdsk may fix the problem, but it's not going to fix the
cause.

Quote:>Unfortunately this servers disks aren't configured very well for Exchange -
>They are all in one big RAID5.

That shouldn't make any difference. The problem you're having isn't
perfromance. It is a problem in that losing two of those disks will
cost you the farm.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm

 
 
 

Help, Corrupt DB - Event ID 116

Post by Rich Matheisen [MVP » Wed, 21 Nov 2001 10:21:03



>OK.  Ran an online backup and it worked OK with no errors at all.

Good.

Quote:>Ran ChkDsk (although didn't see it as the server is at a remote location).
>When the server came backup and Exchange started it logged a lot of the 116
>errors with the odd 200.  Have not had any more disk errors logged yet
>though.

That may be good. Or it may just be that the damaged areas haven't
been touched.

However, since the errors happened soon after the server was
restarted, I'd suspect that the database is okay and the the disk
controller is due for either replacement of firmware update. During
startup there's heavy disk activity, and it's probably at this time
that the controller is returning the wrong sector from the disk cache.
Under light/normal load the controller is able to keep itself under
control and you don;t see any errors.

Quote:>The 116 errors are;

>MSExchangeIS ((438) ) Synchronous read page checksum error -1018 ((1:223666
>1:223666) (0-29621859) (0-40856619)) occurred. Please restore the databases
>from a previous backup.

>The 200 errors are;

>MSExchangeIS ((438) ) A read of the database file
>E:\exchsrvr\MDBDATA\PRIV.EDB between offsets 0x00000000369B3000 and
>0x00000000369B3FFF failed after 16 failed read attempts with error -1018.
>There is a software or  hardware problem affecting the database drive that
>must be corrected to preserve database integrity. Contact Microsoft Product
>Support Services.
> For more information, search the Microsoft Knowledge Base at  http: Event
>ID number.

The fact that 16 retries were made and the read still failed isn't
encouraging.

Quote:>When Exchange started it logged about 120 of these 116 errors within 30
>seconds.  These are the only errors that have come up, i.e. No more errors
>since clients have logged on.

>So, if my backups are OK, are my databases OK.  

The databases WERE okay. However, chkdsk may have "repaired" the disk
in a way that damaged the database pages while repairing what it say
as the error.

Quote:>Should I just restore from
>the last backup?  Any idea's of what I should do now?

I'd try to make one more on-line backup. If it completes without error
then I'd say the database is okay and get to work fixing the
underlying cause of the problem.

If the backup /doesn't/ complete, then you have a dilemma on your
hands. Because the log files share the same set of spindles as the
database, and because those log files have no checksums to verify
their contents, can you trust them? If they are dmaged, and you
restore your backup, the replay of the log files may silently corrupt
the database.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm

 
 
 

Help, Corrupt DB - Event ID 116

Post by Stephe » Wed, 21 Nov 2001 13:20:06


Rich,

The Guy who logged the call initially saying he couldn't archive his sent
items could be the problem.  We asked him to try archiving his mail again,
and it failed and we got all the 116 errors in the event log again.  So what
would this suggest?  Damaged disk, Faulty controller, or corrupt database?

I would guess that this problem is not limited to him, but would exporting
all the mail we can to a PST file for him and then deleting and recreating
his mailbox be an option?

Stephen.



>>OK.  Ran an online backup and it worked OK with no errors at all.

>Good.

>>Ran ChkDsk (although didn't see it as the server is at a remote location).
>>When the server came backup and Exchange started it logged a lot of the
116
>>errors with the odd 200.  Have not had any more disk errors logged yet
>>though.

>That may be good. Or it may just be that the damaged areas haven't
>been touched.

>However, since the errors happened soon after the server was
>restarted, I'd suspect that the database is okay and the the disk
>controller is due for either replacement of firmware update. During
>startup there's heavy disk activity, and it's probably at this time
>that the controller is returning the wrong sector from the disk cache.
>Under light/normal load the controller is able to keep itself under
>control and you don;t see any errors.

>>The 116 errors are;

>>MSExchangeIS ((438) ) Synchronous read page checksum error -1018
((1:223666
>>1:223666) (0-29621859) (0-40856619)) occurred. Please restore the
databases
>>from a previous backup.

>>The 200 errors are;

>>MSExchangeIS ((438) ) A read of the database file
>>E:\exchsrvr\MDBDATA\PRIV.EDB between offsets 0x00000000369B3000 and
>>0x00000000369B3FFF failed after 16 failed read attempts with error -1018.
>>There is a software or  hardware problem affecting the database drive that
>>must be corrected to preserve database integrity. Contact Microsoft
Product
>>Support Services.
>> For more information, search the Microsoft Knowledge Base at  http: Event
>>ID number.

>The fact that 16 retries were made and the read still failed isn't
>encouraging.

>>When Exchange started it logged about 120 of these 116 errors within 30
>>seconds.  These are the only errors that have come up, i.e. No more errors
>>since clients have logged on.

>>So, if my backups are OK, are my databases OK.

>The databases WERE okay. However, chkdsk may have "repaired" the disk
>in a way that damaged the database pages while repairing what it say
>as the error.

>>Should I just restore from
>>the last backup?  Any idea's of what I should do now?

>I'd try to make one more on-line backup. If it completes without error
>then I'd say the database is okay and get to work fixing the
>underlying cause of the problem.

>If the backup /doesn't/ complete, then you have a dilemma on your
>hands. Because the log files share the same set of spindles as the
>database, and because those log files have no checksums to verify
>their contents, can you trust them? If they are dmaged, and you
>restore your backup, the replay of the log files may silently corrupt
>the database.

>--
>Rich Matheisen
>MCSE+I, Exchange MVP
>MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm

 
 
 

Help, Corrupt DB - Event ID 116

Post by Rich Matheisen [MVP » Wed, 21 Nov 2001 13:44:43



>The Guy who logged the call initially saying he couldn't archive his sent
>items could be the problem.  We asked him to try archiving his mail again,
>and it failed and we got all the 116 errors in the event log again.  So what
>would this suggest?  Damaged disk, Faulty controller, or corrupt database?

The only thing a -1018 error tells you is that the database page is
damaged. it doesn't tell you how it got that way.

The fact that you were able to make an ON-LINE backup without
generating a -1018 error tells me that, at one point, the database was
okay -- no errors. After you ran the chkdsk (with the /F and /R
switches?) some of the disk sectors may have been relocated and, in
the process, read unsuccessfully by chkdsk. IOW chkdsk, in the act of
repairing the disk, damaged the database.

Quote:>I would guess that this problem is not limited to him, but would exporting
>all the mail we can to a PST file for him and then deleting and recreating
>his mailbox be an option?

No. The database is damaged, not the mailbox. If you removed his
mailbox the space would be reused by something else and you'd probably
wind up in the same predicament.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm

 
 
 

Help, Corrupt DB - Event ID 116

Post by Stephe » Wed, 21 Nov 2001 14:20:34


We ran the online backup without errors AFTER chkdsk, that's why I'm
confused.  The online backup suggests that the database is OK, but this guy
can cause the -1018 errors by trying to archive his mail, which points to
database corruption?

So, if it is the database I can't restore because I'll restore the
corruption.  Am I at the point of looking at ISINTEG and ESEUTIL?

Thanks again for your time Rich.

Stephen.



>>The Guy who logged the call initially saying he couldn't archive his sent
>>items could be the problem.  We asked him to try archiving his mail again,
>>and it failed and we got all the 116 errors in the event log again.  So
what
>>would this suggest?  Damaged disk, Faulty controller, or corrupt database?

>The only thing a -1018 error tells you is that the database page is
>damaged. it doesn't tell you how it got that way.

>The fact that you were able to make an ON-LINE backup without
>generating a -1018 error tells me that, at one point, the database was
>okay -- no errors. After you ran the chkdsk (with the /F and /R
>switches?) some of the disk sectors may have been relocated and, in
>the process, read unsuccessfully by chkdsk. IOW chkdsk, in the act of
>repairing the disk, damaged the database.

>>I would guess that this problem is not limited to him, but would exporting
>>all the mail we can to a PST file for him and then deleting and recreating
>>his mailbox be an option?

>No. The database is damaged, not the mailbox. If you removed his
>mailbox the space would be reused by something else and you'd probably
>wind up in the same predicament.

>--
>Rich Matheisen
>MCSE+I, Exchange MVP
>MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm

 
 
 

Help, Corrupt DB - Event ID 116

Post by Rich Matheisen [MVP » Thu, 22 Nov 2001 10:45:00



>We ran the online backup without errors AFTER chkdsk, that's why I'm
>confused.  The online backup suggests that the database is OK, but this guy
>can cause the -1018 errors by trying to archive his mail, which points to
>database corruption?

Ahh . . . if the on-line backup was made /after/ the chkdsk, and it
didn't report errors, then the database is, in all liklihood, intact
and free of corruption.

Now I suspect problems with your controller (or the firmware on the
disks) more than ever.

Quote:>So, if it is the database I can't restore because I'll restore the
>corruption.  Am I at the point of looking at ISINTEG and ESEUTIL?

If your hardware/firmware are okay, and you've got a usable backup,
then run these, in this order:

1. Run ESEUTIL /D /ISPRIV
2. Run ISINTEG -FIX -PRI -DETAILED -TEST ALLTESTS,ROWCOUNTS

#1 will rewrite the database and recreate any indexes. #2 will make
sure that the internal stuff is all ointing to the right places.

#2 may produce an extraordinary number of "fixes" if you've never run
it before. Run it again, and a third time, until the number of fixes
is zero.

I really can't emphasize how important it is to have reliable disks
and disk controllers.

--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm

 
 
 

Help, Corrupt DB - Event ID 116

Post by Stephen Mont » Thu, 22 Nov 2001 10:45:52


Thanks Rich I'll give that a shot.
 
 
 

1. online defragment fails, event id 116 and event id 160

Problems:
ESE97 errors and warnings, event source id 116 and 160

Questions:
Is it safe to use the Win2k defragemnt tool on a Exchange
5.5 sp4 installation.  

If so, should this be done only when Exchange is offline.

Oh, and will this help anything at all if I can???

State of the world:
I have Exchange 5.5 sp4 installed to a new win2k server
box.  I am getting application event source errors ese97,
event 160 (failed online derfragment of priv.edb.  I am
also getting event id errors 116 on the private.edb
(checksum errors).  I received the same error on an older
nt 4. sp6 box (suspected bad hardware controller), moved
the files offline, to the new win2k server, reinstalled
with the same name, site, etc.  I guess I just moved the
corrupt database from one server to a newer server.  
Eseutil reported orphaned long values in the priv.edb.

Thanks for any help at all.

Gregg

2. Font format in the Exchange...help! please.

3. Event ID: 116, 117, 200

4. No reminders for secondary calendars in OL98

5. event id 116

6. NDR

7. ESE97, Event ID 116

8. Event ID: 116, 117, 200

9. event ID 116 - Synchronous read page checksum error

10. Event ID 116 - any fixes if repair fails?

11. event ID 116, OLEDB

12. ESE97,Event ID 116