|
|
|
date: Fri, 20 Jan 2006 13:15:54 -0000,
group: microsoft.public.exchange2000.information.store
back
Re: Defrag very very slow?
Hi Michael,
One thing to make sure of when doing a defrag is that the command window we
are running the command in is always the active window, otherwise it is
possible the process pauses. If the screensaver pops up or we open another
window or perform any other action on the server, click back on the command
window and hit the spacebar or Enter. If this is not the case, I would
suggest making a copy of the database and moving it to another server and
rerun the defrag and let it run - if there's disk activity, memory usage,
etc. then continue to let it run, even if there doesn't appear to be any
progress on the screen.
The following article will help you run eseutil on a server without having
to install Exchange:
244525 How to run Eseutil on a computer without Exchange Server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;244525
Hope this helps!
--
Eric Tam, MCSE, MCSA
Microsoft Exchange Support
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Michael Salem" wrote in message
news:MPG.1e3af2e9b55204dc98969b@msnews.microsoft.com...
> Exchange Server standard stopped working with errors about the database
> exceeding 16GB in size. This is a known issue, and not what I'm asking
> about.
>
> I ran ESEUTIL /d /p (this is a defragment, storing the defragmented file
> in a specified location instead of overwriting the original; it is not a
> true repair like /p). There is plenty of space on the disc for an extra
> copy of the database.
>
> The process started; after a couple of hours I had two dots (about 4%)
> and the new priv1.edb was about 1 GB (aS shown on a directory listing of
> the destination drive). After 6 more hours it had not moved on at all -
> I killed the process. I tried this twice; in each case the process
> stopped
>
> ESEUTIL /ms runs (in about 6 minutes), and produces what looks like sane
> output.
>
> The diagnostic ESEUTIL /G had made has made no visible progress (no
> dots) after about an hour.
>
> isinteg -test alltests has run tests 1-6 with no errors reported, and is
> hanging at 18% on test 7 (folder).
>
> How long should these processes take on an adequately fast machine (I
> don't have the specifications to hand)? I believe the drives are a RAID
> 5 SCSI array. The machine generally seems to be working OK. I understood
> that ESEUTIL should typically process about 4GB/hour.
>
> Best wishes,
> --
> Michael Salem
date: Sat, 21 Jan 2006 09:47:13 -0500
author: Eric Tam [MSFT]
Re: Defrag very very slow?
Many thanks to Eric Tam [MSFT] for reply to my question on very slow
ESEUTIL operation:
> One thing to make sure of when doing a defrag is that the command window we
> are running the command in is always the active window, otherwise it is
> possible the process pauses. If the screensaver pops up or we open another
> window or perform any other action on the server, click back on the command
> window and hit the spacebar or Enter. If this is not the case, I would
> suggest making a copy of the database and moving it to another server and
> rerun the defrag and let it run - if there's disk activity, memory usage,
> etc. then continue to let it run, even if there doesn't appear to be any
> progress on the screen.
I have the impression this is less of a problem that it was in earlier
versions of Windows. FWIW, in this case the command window had focus all
the time.
While I didn't watch the process all the time (e.g., I got a night's
sleep after starting a run!) the process eventually ran to completion; I
may have underestimated the time required. It sat for a long time
(hours) showing 4%, but when I looked maybe 8 hours later it had
completed successfully.
>
> The following article will help you run eseutil on a server without having
> to install Exchange:
> 244525 How to run Eseutil on a computer without Exchange Server
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;244525
Thanks, interesting reference. Essentially: if you can't run ESEUTIL on
the machine running Exchange Server, you can copy the data and a few
DLLs to another machine and run there. Useful.
Thanks again, and best wishes,
--
Michael Salem
date: Mon, 23 Jan 2006 14:16:59 -0000
author: Michael Salem
Exchange Server defrag (defragmenting), repair very slow with ESEUTIL, ISINTEG
(Followup to my post "Defrag very very slow?")
Summary: ESEUTIL may seem to be hung with no signs of progress, but it
may simply be taking its time.
Following some trouble with ESEUTIL after a routine Exchange Server 2000
problem, I'll make some comments that might help others who find this
posting as the result of a search.
I ran the off-line ESEUTIL on a 16GB Exchange Server database (default
name PRIV1.EDB). It ran for a few hours. At first it showed no dots on
the progress bar; after some time (not hours), one and then two dots
appeared (4 percent?). When checking the sizes of the output files in a
My Computer window, they increased for a while, then remained steady at
about 1GB. After relatively fast progress to the 1GB/2 dots mark, there
was no sign of progress for many hours (8 hours?).
I aborted processes a couple of times after several hours of no visible
progress. Later, I made a run over a weekend. Initial progress was as
before, but after leaving ESEUTIL to run for a longer period, it had
completed when I checked about 9 hours after starting. I wasn't
watching, so don't know when and how the progress indicators woke up.
I'm not sure of the hardware configuration; a fairly old dual-CPU
machine with, I think, 7200 or 10000 rpm RAID5 SCSI drives.
I had similar behaviour with ISINTEG.EXE
Unfortunately I can't give any detailed observations or precise times,
but do be aware that ESEUTIL.EXE can behave this way, and give it lots
of time before giving up. I don't know if the same holds for ESEUTIL as
supplied with Exchange Server 2003 or other versions.
I've posted this message for those who might find it as the result of a
search; if anyone has anything to add, supporting, contradicting, or
clarifying this message even after a long time, it may be worth posting
a followup.
Best wishes,
--
Michael Salem
date: Wed, 25 Jan 2006 07:17:49 -0000
author: Michael Salem
Re: Exchange Server defrag (defragmenting), repair very slow with ESEUTIL, ISINTEG
I'm glad you mentioned Exchange 2000, it gives me a good idea about
the vintage of it. In Exchange 2003 ESE will write an event to the
envent log if an IO operation takes a long time (not present in 2000).
NTFS works in an interesting manner. Even if you're writing to a file
and making it larger, it will not bother to update the file size
reported by 'dir' or explorer. If it did do this for every write,
things would become quite slow. It will update the size value if the
volume is flushed (FlushFileBuffers() ), but this is an expensive
operation so ESE tries to avoid calling it unless necessary.
On a volume with other activity (like the OS drive), it's not uncommon
for some program to call FlushFileBuffers(). But if all you have on
the volume are Exchange files, then this might not happen.
The bottom line is that in order to see if the file is getting any
larger, you should look at something different. Like the amount of CPU
or IO done by eseutil.exe using perfmon, or the IO columns is
taskmgr. The free space on the volume (from dir) should probably get
updated as well.
I just took a very quick look at how the progress bar is updated with
the current code (it should be the same for 2000), and I think it's
only updated once per database table. Although each mail folder in
Outlook corresponds to a table, there are some incredibly large tables
like the message table. My guess is that it looked like it was stuck
at 4% because it was defragmenting one of those large tables.
-martin
Boring-but-necessary-disclaimer: This posting is provided "AS IS" with
no warranties, and confers no rights.
In article ,
Michael Salem wrote:
>
>(Followup to my post "Defrag very very slow?")
>
>Summary: ESEUTIL may seem to be hung with no signs of progress, but it
>may simply be taking its time.
>
>Following some trouble with ESEUTIL after a routine Exchange Server 2000
>problem, I'll make some comments that might help others who find this
>posting as the result of a search.
>
>I ran the off-line ESEUTIL on a 16GB Exchange Server database (default
>name PRIV1.EDB). It ran for a few hours. At first it showed no dots on
>the progress bar; after some time (not hours), one and then two dots
>appeared (4 percent?). When checking the sizes of the output files in a
>My Computer window, they increased for a while, then remained steady at
>about 1GB. After relatively fast progress to the 1GB/2 dots mark, there
>was no sign of progress for many hours (8 hours?).
>
>I aborted processes a couple of times after several hours of no visible
>progress. Later, I made a run over a weekend. Initial progress was as
>before, but after leaving ESEUTIL to run for a longer period, it had
>completed when I checked about 9 hours after starting. I wasn't
>watching, so don't know when and how the progress indicators woke up.
>I'm not sure of the hardware configuration; a fairly old dual-CPU
>machine with, I think, 7200 or 10000 rpm RAID5 SCSI drives.
>
>I had similar behaviour with ISINTEG.EXE
>
>Unfortunately I can't give any detailed observations or precise times,
>but do be aware that ESEUTIL.EXE can behave this way, and give it lots
>of time before giving up. I don't know if the same holds for ESEUTIL as
>supplied with Exchange Server 2003 or other versions.
>
>I've posted this message for those who might find it as the result of a
>search; if anyone has anything to add, supporting, contradicting, or
>clarifying this message even after a long time, it may be worth posting
>a followup.
>
>Best wishes,
>--
>Michael Salem
date: Thu, 26 Jan 2006 21:08:18 +0000 (UTC)
author: Martin Chisholm [MSFT]
Re: Exchange Server defrag (defragmenting), repair very slow with ESEUTIL, ISINTEG
Thanks to Martin Chisholm [MSFT] for his comments on my posting. I had
reported that ESEUTIL appeared to hang with no visible progress, but
eventually did complete after many hours. I'll make a few comments,
without quoting the entire message.
> I'm glad you mentioned Exchange 2000,
I seem to have omitted this vital fact in my original posting, sorry.
> NTFS works in an interesting manner. Even if you're writing to a file
> and making it larger, it will not bother to update the file size
> reported by 'dir' or explorer. ... It will update the size value if the
> volume is flushed (FlushFileBuffers()
> On a volume with other activity (like the OS drive), it's not uncommon
> for some program to call FlushFileBuffers(). But if all you have on
> the volume are Exchange files, then this might not happen.
Useful to know. I had noticed with many prograMS that the file size
reported by Explorer increases by fits and starts, but didn't know why.
The displayed size jumps similarly in FAT32, presumably for the same
reason.
> The bottom line is that in order to see if the file is getting any
> larger, you should look at something different. Like the amount of CPU
> or IO done by eseutil.exe using perfmon, or the IO columns is
> taskmgr. The free space on the volume (from dir) should probably get
> updated as well.
Indeed; but after a few hours you start to think that the program is
stuck in a loop even if executing, maybe generating rubbish output.
> ... I think [the progress bar] is only updated once per database table.
> ... there are some incredibly large tables like the message table.
That explains everything if the message table is a large fraction of the
total database size. It makes a complete nonsense of the "progress" bar.
Best wishes,
--
Michael Salem
date: Fri, 27 Jan 2006 01:52:25 -0000
author: Michael Salem
|
|
