ToB企服应用市场:ToB评测及商务社交产业平台

标题: Exchange数据库无法打开邮箱、被隔离、未装入或不可用等综合问题解决记载 [打印本页]
作者: 立聪堂德州十三局店    时间: 2024-11-24 18:02
标题: Exchange数据库无法打开邮箱、被隔离、未装入或不可用等综合问题解决记载
服务器和数据库环境：服务器ABCD，堕落数据库Archive1位于C，一个数据库仅有一个归档账号
环境说明：本文章仅记载解决过程，各种问题的原因不一样，解决方法也不一样，本记载仅供参考，涉及数据的行为请谨慎利用！！！！！而且我主要技术方向并非Exchange，过程中可能有许多纰漏之处，请谨慎参考，如有错误，敬请指正！
我的大概排查过程是：
数据库隔离 -> 数据库有脏数据进行软修复 -> 数据库损坏进行硬修复 -> 利用下令取归档邮件
假如有类似环境，可以参考其中一部门的解决方法。数据库迁移过程后续择机增补。
该数据库的环境一开始让我摸不着头脑，大概的现象有：
利用Search-Mailbox搜刮邮件时无法打开邮箱、
网页版Outlook登录归档邮箱账号提示被隔离（Quarantined）
ECP查看数据库已装入，但索引表现失败，利用Get-MailboxStatistic提示未装入或不可用。
删除隔离注册表项，过一段时间该项又重新出现
变乱查看器有一些542报错，提示"RepairedPage”的逻辑损坏。
解决过程记载：
1.尝试Search-Mailbox取邮件
在服务器D尝试取邮件报错

在服务器C（数据库位于的服务器）尝试取邮件也报错
[PS] E:\Mailbox DataBase\Archive1>search-mailbox -Identity “数据库Archive1”……
警告: 假如指定搜刮查询，……
无法打开邮箱 /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=服务器C/cn=Microsoft System Attendant。
   + CategoryInfo : ReadError: (0:Int32) [Search-Mailbox], StorageTransientException
   + FullyQualifiedErrorId :[Server=服务器C,RequestId=824d*****,TimeStamp=2024/8/30 8:15:18] [FailureCategory=Cmdlet-StorageTransientException] 66D722EF,Microsoft.Exchange.Management.Tasks.SearchMailbox
   + PSComputerName : 服务器C

2.开端查抄数据库状态
（1）Get-Mailbox、Get-MailBoxDatabase、Get-MailboxDatabaseCopyStatus查询状态正常
（2）Get-MailboxStatistics Archive1
服务器“C”上的被访问数据库“Archive1”未装入或不可用。
   + CategoryInfo  : ResourceUnavailable: (Archive1:MailboxDatabase) [Get-MailboxStatistics], DatabaseUnavailableException
   + FullyQualifiedErrorId : [Server=服务器C,RequestId=8dc4……,TimeStamp=2024/8/30 8:21:08] [FailureCategory=Cmdlet-DatabaseUnavailableException] FBE0DFB1,Microsoft.Exchange.Management.MapiTasks.GetMailboxStatistics
   + PSComputerName : 服务器C
提示的是未装入或不可用。
（3）进入Exchange的网页版，登录该数据库中唯一一个归档邮箱账号，报错：
X-ClientId: C745……
request-id 3f32……
X-OWA-Error Microsoft.Exchange.Data.Storage.StorageTransientException
X-OWA-Version 15.1.……
X-FEServer 服务器B
X-BEServer 服务器C
Date:2024/8/30 8:23:28
InnerException: Microsoft.Mapi.MapiExceptionMailboxQuarantined
可以看到报的是隔离错误
（4）Test-MAPIConnectivity Archive1
MailboxServer      Database           Result    Error
-------------      --------           ------    -----
服务器C        Archive1    *故障*    数据库已卸除。
[PS] E:\Mailbox DataBase\Archive1>Mount-Database Archive1
[PS] E:\Mailbox DataBase\Archive1>Test-MAPIConnectivity Archive1
MailboxServer      Database           Result    Error
-------------      --------           ------    -----
服务器C        Archive1*故障*    数据库已卸除。
挂载不上，但是在ECP查看，数据库是已挂载的，但是索引为失败状态
（5）先取消挂载，然后进入到数据库目次里，利用eseutil查看数据文件状态
[PS] E:\Mailbox DataBase\Archive1>Dismount-Database Archive1
确认
是否确实要执行此利用?
正在卸除数据库"Archive1"。这可能会降低数据库中邮箱的可用性。
[Y] 是(Y)  [A] 满是(A)  [N] 否(N)  [L] 全否(L)  [?] 帮助 (默认值为“Y”): A
[PS] E:\Mailbox DataBase\Archive1>eseutil /mh .\Archive1.edb
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
……
           State: Clean Shutdown
……
无脏数据，假如这里表现为Dirty，那么就是有数据尚未写入。
（6#）假如为Dirty的环境，需要进行软修复，注意，不建议非技术职员进行该利用：
参数详细解释：
/r E00：指定恢复利用，而且 E00 是数据库的日记文件前缀（根据数据库的现实日记文件前缀调整，例如 E01，E02 等）。
/l：这里的 /l 是小写的字母 "L"，表现 事务日记文件的路径，例如 D:\ExchangeLogs 是存放 Exchange 数据库日记文件的目次。
/d：表现数据库文件的路径，例如 D:\ExchangeDatabases 是存放.edb 数据库文件的目次。
等待软修复完成，然后重新挂载，启动服务，此时查询状态应为Clean Shutdown

3.主要排查方向是数据库隔离
（1）查抄是否是被隔离了
Get-MailboxStatistics -Database Archive1(数据库名) | Where-Object {$_IsQuarantined -eq $true}
可以查到确实被隔离了
查询数据库的GUID，找到出问题的数据库：
Get-MailboxDatabase | Select-Object Name, Guid
查询这个数据库的归档邮箱的GUID：
Get-Mailbox -Identity “Archive1@test.local” | Select-Object Guid
（2）进入到数据库所在的服务器C，regedit进入注册表路径：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\服务器C\Private-数据库Archive1的GUID\QuarantinedMailboxes
在QuarantinedMailboxes下，假如有一个注册表项名称是归档邮箱的GUID，那么说明确实被隔离了
Services.msc停止Microsoft Exchange Information Store服务
（3）删除注册表
删除”HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\服务器C\Private-数据库Archive1的GUID\QuarantinedMailboxes\隔离邮箱GUID”这个注册表项
（4）查询Exchange的安装目次
进入HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Setup，各版本可能不一样，以此类推。查看MsiInstallPath的值，我的是C:\Program Files\Microsoft\Exchange Server\V15
那么就需要进入到C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Archive1\MailboxQuarantine，假如有隔离邮箱GUID的相关文件，进行备份后删除。假如没有上述文件，则忽略该步。
（5）Services.msc启动Microsoft Exchange Information Store服务
（6）此时再对该数据库的状态进行查询，测试访问等。一般环境下，这个时候是能够挂在并访问了的，但是我的数据库仍未恢复正常，只要重启了Exchange存储服务之后，过一段时间，注册表中隔离邮件的GUID项照旧会出现，访问也不乐成


4.考虑是数据库有损坏，进行修复
我先是利用了eseutil /r进行了软修复，但是仍旧无效，因此计划进行硬修复。
注意，硬修复有可能会导致数据库损坏，因此肯定要先备份再进行修复
（1）停止服务
我本次的履历，是需要先停止下列服务
存储（Microsoft Exchange Information Store）
Microsoft Exchange 复制
Microsoft Exchange 搜刮
Microsoft Exchange 邮箱助理
搜刮主机控制器（Microsoft Exchange Search Host Controller）
具体各服务器环境不一样，建议先进入任务管理器 - 资源监视器 - CPU - 关联的句柄，通过停止进程的相关服务来确保已经对数据库没有进行任何读写利用了。

好比我碰到的就另有一个备份软件正在读写，因此还要停息该备份服务。
（2）修改文件夹名称，确保无读写
进入到数据库所在盘符，进入MailBox Database，然后尝试将Archive1文件夹修改名称为Archive1.bak，假如能修改乐成，说明可以进行下一步备份利用了。
（3）准备另一新盘
复制粘贴整个Mailbox Database文件夹过去，接下来我称这个复制得到的数据库为新数据库。
（4）验证数据库文件完整性
对数据库目次里的数据文件完整性进行校验，一般是范例为edb而且文件最大的谁人文件
分别对源数据库和新数据库的这个文件进行哈希校验。
可以通过powershell下令的Get-FileHash ./Archive1.edb来获取文件的哈希值，我这里获取到的哈希值是SHA256范例的，确保双方的哈希值一致即可进行修复利用。
（5）修改盘符
先将源数据库的盘符修改为X，然后再把新数据库盘符修改成E（源数据库原来的盘符），然后就可以对新数据库进行修复利用了（不对源数据库利用，相当于只是把它移动到了一边，放起来）
（6）硬修复，此利用可能会导致数据丢失或损坏
假如之前已经执行过软修复了不起效果，可以先将文件夹内的下列文件移动走：
.single结尾的文件夹，一般为索引文件
IgnoredLogs文件夹、incseedInspect文件夹、inspector文件夹
.chk范例的文件
.log范例的文件
.jrs范例的文件

移动走之后，先Exchange Management Shell里cd进入到新数据库Archive1文件夹中，再利用eseutil /p ./Archive1.edb，就会开始硬修复
（7）修复完成
我在此步完成了修复，重启服务、Mount-Database后，查询数据库状态已正常，已经能登录网页版的邮箱账号，也能利用Search-Mailbox等下令。不外由于之前为了清除影响因素，把.single文件夹移动走了，因此索引要等系统重新创建。
利用Get-MailboxDatabaseCopyStatus下令可以查询数据库状态，假如Status是Crawling的话，说明仍在索引中，这个时候假如进行邮件搜刮，那么搜刮的结果可能会是不全的，要等待状态变为Healthy

5.从数据库中恢复邮件
（1）直接登录网页控制台
由于我的数据库Archive1只有一个归档邮箱账号Archive1@test.local，那么直接登这个账号就可以看到数据库中的所有归档邮件，但是谁人数据库是1TB左右，得用下令查。
（2）Search-Mailbox
Exchange Management Shell里，利用这条下令：
search-mailbox -Identity "Archive1（数据库名）" -SearchQuery 'From:"发件人地址a" AND To:"收件人地址b" AND HasAttachment:True' -TargetMailbox "archiverestore01@test.local" -TargetFolder "Archive1恢复"
其中SearchQuery是查询邮件的条件，这里是搜刮发件人地址为a，收件人地址为b，而且邮件中带有附件的邮件。TargetMailbox是恢复的目标邮箱地址，假如搜刮到了邮件，就会恢复到archiverestore01@test.local邮箱的“Archive1恢复”文件夹（若无会主动创建）。
推荐这个archiverestore01账号是新创建的，方便背面导出邮件。
（3）New-MailboxSearch
Search-Mailbox有结果数目限制，利用New-MailboxSearch可以返回一万个以上的结果，用法类似于Search-Mailbox，可以百度查查看。
（4）New-MailboxExportRequest
这条下令可以导出邮箱PST文件，举例如下
New-MailboxExportRequest -Mailbox "archiverestore01@test.local" -FilePath "\\服务器C的盘算机名\SearchResults\SearchResults.pst"
导出的FilePath路径，需要是一个共享文件夹路径，不能是本地路径，这条下令会把archiverestore01的邮箱导出成一个PST文件，方便在别处导入。

6. 迁移数据库
虽然已经通过硬修复已经能够访问数据库，并恢复邮件了，但是在变乱查看器中，仍旧可以看到40025报错，大意是数据库出现了问题，需要尽快逃离。这个找一个时间，新建一个数据库，然后把谁人数据库内的邮箱迁移走就可以了，在ECP有图形化界面可以直接利用，也可以利用下令行来利用。而且，迁移数据库可以解决大部门数据库的问题，假如实在有上面各种方法都解决不了的环境，可以考虑一下迁移数据库。
40025变乱报错如下：
Database Archive1 (528*****) has been offline-repaired (by eseutil.exe) one or more times in the past. However, although this ensures database-level logical consistency and may permit the database to be successfully mounted, Exchange-level logical consistency can no longer be guaranteed. Therefore, all mailboxes should be evacuated from the database and the database should be retired as soon as possible in order to eliminate the potential for unexpected behaviour caused by Exchange-level logical inconsistency.
This event will continue to be emitted once per hour while the database is mounted as an urgent reminder to evacuate and retire the database as soon as possible.
Database last repaired: 2024/9/11 8:48:57
Repair count since the database was last offline-defragmented: 6
Repair count before the database was last offline-defragmented: 0
Recovery database?: False
翻译是
数据库Archive1（528*****）过去已脱机修复过一次或多次（通过eseutil.exe）。然而，尽管这确保了数据库级的逻辑一致性，并可能允许乐成装载数据库，但Exchange级的逻辑连贯性已不再得到保证。因此，应从数据库中疏散所有邮箱，并尽快停用数据库，以消除Exchange级别逻辑不一致导致的意生手为的可能性。
在装载数据库时，此变乱将继续每小时发出一次，作为告急提示，要求尽快撤离和退役数据库。
数据库上次修复时间：2024/9/11 8:48:57
自上次脱机碎片整理数据库以来的修复计数：6
上次脱机碎片整理数据库之前的修复计数：0
恢复数据库？：错误的

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4