Re: public and private mailboxes randomly dismounting
- From: "SuperGumby [SBS MVP]" <not@xxxxxxxxxxx>
- Date: Tue, 4 Dec 2007 13:15:44 +1100
Is 08:30 before or after you turned off AV scanning of the files in
\mdbdata?
HINT: When posting logs an important piece is the Event ID and Source. Go to
www.eventid.net and you will find out why. Timestamp also helps but I
suspect you have listed earliest to latest.
"jaime alonzo" <jaimealonzo@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1E539819-A1EB-425D-A9AB-67B0F909BDAD@xxxxxxxxxxxxxxxx
Yes, I was able to run three full backups starting Friday.
I have excluded the stm data from the av.
Here is a list of error events from 8:30 this morning:
A non-delivery report with a status code of 5.4.0 was generated for
recipient rfc822;adison@xxxxxxxxxxxxxxxxxxx (Message-ID
<24D1ADB7AF661F47B4D8FC48210F549C1B1C25@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>).
Causes: This message indicates a DNS problem or an IP address
configuration
problem
Solution: Check the DNS using nslookup or dnsq. Verify the IP address is
in
IPv4 literal format.
---
Windows has detected that Offline Caching is enabled on the Roaming
Profile
share - to avoid potential profile corruption, Offline Caching must be
disabled on shares where roaming user profiles are stored.
---
Information Store (3308) First Storage Group: An attempt to move the file
"C:\Program Files\Exchsrvr\mdbdata\E00.log" to "C:\Program
Files\Exchsrvr\mdbdata\E0001768.log" failed with system error 32
(0x00000020): "The process cannot access the file because it is being used
by
another process. ". The move file operation will fail with error -1032
(0xfffffbf8).
---
Information Store (3308) First Storage Group: Unable to create a new
logfile
because the database cannot write to the log drive. The drive may be
read-only, out of disk space, misconfigured, or corrupted. Error -1032.
---
An error occurred while writing to the database log file of storage group
"First Storage Group". Attempting to unmount all databases in this storage
group.
---
Information Store (3308) First Storage Group: The logfile sequence in
"C:\Program Files\Exchsrvr\mdbdata\" has been halted due to a fatal error.
No further updates are possible for the databases that use this logfile
sequence. Please correct the problem and restart or restore from backup.
---
Information Store (3308) First Storage Group: Unable to rollback operation
#756902 on database C:\Program Files\Exchsrvr\mdbdata\priv1.edb.
Error: -510.
All future database updates will be rejected.
---
Information Store (3308) First Storage Group: Unable to rollback operation
#756878 on database C:\Program Files\Exchsrvr\mdbdata\priv1.edb.
Error: -510.
All future database updates will be rejected.
---
Error Fail when writing to log file occurred on message 1-1F4607 during a
background cleanup on database "First Storage Group\Mailbox Store
(myserver)".
---
Database error 0xfffffbbe occurred in function JetRollbackTransaction
while
accessing the database "First Storage Group\Mailbox Store (myserver)".
---
Error 0xfffffbbe occurred during message background cleanup on database
"First Storage Group\Mailbox Store (myserver)".
---
Error 0xfffffbbe returned from closing database table, called from
function
JTAB_BASE::EcCloseTable on table DeletedFolders.
---
Database error 0xfffffbbe occurred in function JTAB_BASE::EcConfig while
accessing the database "First Storage Group\Mailbox Store (myserver)".
---
Database error 0xfffffbbe occurred in function JTAB_BASE::EcConfig while
accessing the database "First Storage Group\Mailbox Store (myserver)".
---
Database error 0xfffffbbe occurred in function
JTAB_BASE::EcSetCurrentIndex
while accessing the database "First Storage Group\Mailbox Store
(myserver)".
---
Error 0xfffffbbe returned from closing database table, called from
function
JTAB_BASE::EcCloseTable on table ReplidMap.
---
Error 0xfffffbbe returned from closing database table, called from
function
JTAB_BASE::EcCloseTable on table Folders.
---
Error 0xfffffbbe returned from closing database table, called from
function
JTAB_BASE::EcCloseTable on table Folders.
-----------------------------------
It would be great, if you could post those links.
Thank you.
Jaime Alonzo
"SuperGumby [SBS MVP]" wrote:
OK, so it's not an excessive number of log files either. I was wondering
because you suggested backups had stopped working, it appears however
that
you have been able to perform a backup recently, all your logs are
commited
previous to today.
You should also exclude the STM (Streaming) data from AV. The 'store' is
the
combined edb+stm.
You don't mention anything about logs (System or Application Event Logs),
anything in there at the times the store goes down?
I'd be tempted to now copy the store somewhere (after dismounting, or
stopping services) and see the result of integrity check of the current
store. I'll post some links but I'm working on something else at the
moment.
"jaime alonzo" <jaimealonzo@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1006EB9F-DCEF-4251-8FFB-91BFFBEA0E0E@xxxxxxxxxxxxxxxx
This is what I have in the exchange directory:
Directory of c:\Program Files\Exchsrvr\MDBDATA
12/03/2007 12:46 PM <DIR> .
12/03/2007 12:46 PM <DIR> ..
12/03/2007 12:35 PM 8,192 E00.chk
12/03/2007 12:46 PM 5,242,880 E00.log
12/03/2007 01:33 AM 5,242,880 E0001759.log
12/03/2007 01:49 AM 5,242,880 E000175A.log
12/03/2007 04:40 AM 5,242,880 E000175B.log
12/03/2007 04:55 AM 5,242,880 E000175C.log
12/03/2007 05:06 AM 5,242,880 E000175D.log
12/03/2007 05:18 AM 5,242,880 E000175E.log
12/03/2007 05:27 AM 5,242,880 E000175F.log
12/03/2007 06:46 AM 5,242,880 E0001760.log
12/03/2007 06:46 AM 5,242,880 E0001761.log
12/03/2007 06:46 AM 5,242,880 E0001762.log
12/03/2007 07:01 AM 5,242,880 E0001763.log
12/03/2007 07:36 AM 5,242,880 E0001764.log
12/03/2007 08:07 AM 5,242,880 E0001765.log
12/03/2007 08:11 AM 5,242,880 E0001766.log
12/03/2007 08:24 AM 5,242,880 E0001767.log
12/03/2007 08:31 AM 5,242,880 E0001768.log
12/03/2007 09:06 AM 5,242,880 E0001769.log
12/03/2007 09:14 AM 5,242,880 E000176A.log
12/03/2007 09:37 AM 5,242,880 E000176B.log
12/03/2007 09:37 AM 5,242,880 E000176C.log
12/03/2007 10:02 AM 5,242,880 E000176D.log
12/03/2007 10:10 AM 5,242,880 E000176E.log
12/03/2007 10:11 AM 5,242,880 E000176F.log
12/03/2007 10:31 AM 5,242,880 E0001770.log
12/03/2007 10:57 AM 5,242,880 E0001771.log
12/03/2007 11:35 AM 5,242,880 E0001772.log
12/03/2007 11:58 AM 5,242,880 E0001773.log
12/03/2007 12:26 PM 5,242,880 E0001774.log
12/03/2007 12:46 PM 5,242,880 E0001775.log
12/03/2007 12:46 PM 1,048,576 E00tmp.log
12/03/2007 09:02 AM 10,053,820,416 priv1.edb
12/03/2007 09:02 AM 532,684,800 priv1.stm
2/03/2007 09:02 AM 29,368,320 pub1.edb
12/03/2007 09:02 AM 2,105,344 pub1.stm
06/14/2007 08:32 PM 5,242,880 res1.log
06/14/2007 08:32 PM 5,242,880 res2.log
12/03/2007 09:02 AM 1,056,768 tmp.edb
39 File(s) 10,787,864,576 bytes
2 Dir(s) 417,813,905,408 bytes free
As of now, I have excluded the extensions: edb, log and chk from being
scanned by the AV. I don't know whether this change will make an
impact.
However, how can I test it without waiting a full day?
For your question:
Do you have other partitions or are you just running a single part
(C:)?
A/ Single partition on the C:
For your statement:
"With your available space it may be worthwhile stopping the Exchange
services and making a complete copy of the mdbdata folder. We can then
repair/recover the existing store and if we lose significant amounts of
data
possibly mount the copy to retrieve missing bits."
if the AV is not the issue causing those random dismounts, how can we
start
the process of repair/recover of the edb?
TIA
Jaime Alonzo
"SuperGumby [SBS MVP]" wrote:
You're not hitting a limit based on those sizes. By default the
Exchange
logs are located in the same folder, how many logfiles do you have?
Other thing would be to ensure your AntiVirus is not scannng the store
files.
Do you have other partitions or are you just running a single part
(C:)?
Either way I'd be inclined to create a new folder for the store,
exclude
it
and the current folder from AV, and attempt to move both the store and
logfiles to it (using Exchange System Manager). If the move fails it
should
retain the existing store/log location and our next move would be
creation
of a 'dialtone store' then exmerge from the current store mounted as a
recovery storage group into the newly created store. THIS BREAKS
'Single
Instance Storage' and should be avoided but if my _guess_ is correct
it
may
be an easy way to get back to a known good state. There are other
options
regarding repairing rather than 'tossing' the existing store. I
suspect
that
something in the store is corrupt, your random stops are occurring
when
some
process (user activity or a management process) is attempting to
access
the
corrupt area of the store. It is likely that repair operations on the
store
will result in loss of some information.
With your available space it may be worthwhile stopping the Exchange
services and making a complete copy of the mdbdata folder. We can then
repair/recover the existing store and if we lose significant amounts
of
data
possibly mount the copy to retrieve missing bits.
"jaime alonzo" <jaimealonzo@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:BA07C267-AE62-40D5-BCF4-76BF70C57AD2@xxxxxxxxxxxxxxxx
Larry, thank you for responding.
For your questions, here is what I could gather:
from the c:\Program Files\Exchsrvr\MDBDATA
the priv1.edb = 9,818,184 kb
the priv1.stm = 520,200 kb
the pub1.edb = 28,680 kb
the pub1.stm = 2,056 kb
The partition has 1tb of space and 750gb available.
Let me know, if I could provide you more information
TIA
Jaime Alonzo
"Larry Struckmeyer" wrote:
Hi:
How big is the exchange store, and how much room is available on
the
partition where you are running the exutil?
--
Larry
"sbcglobal" <jalonzo@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:NhY3j.25136$JD.105@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hello,
My company is hosting an exchange environment under win 2003 sbs.
We're
experiencing a random problem. The public and private mailboxes
keep
dismounting. Every time it happens, I access the server and
mount
the
public and private mailboxes by going to the
domain(exchange)\servers\myserver\first storage group\ and
everything
works ok after that process. I noticed the daily backup has
stopped
working. I don't know, if there's any relation between these two
applications.
I was following a thread from Robert Li "exchange infromation
store
won't
mount URGENT HELP GREATLY APPRECIATED." I tried running the
following
command eseutil /mh. I got the follwing:
"c:\Program Files\Exchsrvr\bin>eseutil /mh "c:\program
files\exchsrvr\mdbdata\priv1.edb"
Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Database: c:\program files\exchsrvr\mdbdata\priv1.edb
Operation terminated with error -1032 (JET_errFileAccessDenied,
cannot
access fi
le, the file is locked or in use) after 33.47 seconds.
Questions:
1) Because the backup hasn't worked for a long time, just in case
of
a
major disaster, how and what can I backup manually for the
exchange
database including logs?
2) How can I checked the integrety of the exchange database?
Your help is appreciated
tia
Jaime Alonzo
.
- Follow-Ups:
- Re: public and private mailboxes randomly dismounting
- From: jaime alonzo
- Re: public and private mailboxes randomly dismounting
- References:
- Re: public and private mailboxes randomly dismounting
- From: Larry Struckmeyer
- Re: public and private mailboxes randomly dismounting
- From: jaime alonzo
- Re: public and private mailboxes randomly dismounting
- From: SuperGumby [SBS MVP]
- Re: public and private mailboxes randomly dismounting
- From: jaime alonzo
- Re: public and private mailboxes randomly dismounting
- From: SuperGumby [SBS MVP]
- Re: public and private mailboxes randomly dismounting
- From: jaime alonzo
- Re: public and private mailboxes randomly dismounting
- Prev by Date: Re: same Home Page for all users
- Next by Date: Re: catalog synchronized failed?
- Previous by thread: Re: public and private mailboxes randomly dismounting
- Next by thread: Re: public and private mailboxes randomly dismounting
- Index(es):
Relevant Pages
|