C#如何获取exchange2013上的默认数据库

创建数据库

选择开始菜单中→程序→Management SQL Server 2008→SQL Server Management Studio命令，打开SQL Server Management Studio窗口，并使用Windows或 SQL Server身份验证建立连接。

在对象资源管理器窗口中展开服务器，然后选择数据库节点

右键单击数据库节点，从d出来的快捷菜单中选择新建数据库命令。

执行上述 *** 作后，会d出新建数据库对话框。在对话框、左侧有3个选项，分别是常规、选项和文件组。完成这三个选项中的设置会后，就完成了数据库的创建工作，

在数据库名称文本框中输入要新建数据库的名称。例如，这里以“新建的数据库”。

在所有者文本框中输入新建数据库的所有者，如sa。根据数据库的使用情况，选择启用或者禁用使用全文索引复选框。

在数据库文件列表中包括两行，一行是数据库文件，而另一行是日记文件。通过单击下面的添加、删除按钮添加或删除数据库文件。

切换到选项页、在这里可以设置数据库的排序规则、恢复模式、兼容级别和其他属性。

切换到文件组页，在这里可以添加或删除文件组。

完成以上 *** 作后，单击确定按钮关闭新建数据库对话框。至此“新建的数据”数据库创建成功。新建的数据库可以再对象资源管理器窗口看到。

企业管理器中的Tools，Database Maintenance Planner，可以设置数据库的定期自动备份计划。并通过启动Sql server Agent来自动运行备份计划。具体步骤如下:

1、打开企业管理器，在控制台根目录中依次点开Microsoft SQL Server-->SQL Server组-->双击打开你的服务器

2、然后点上面菜单中的工具-->选择数据库维护计划器

3、下一步选择要进行自动备份的数据-->下一步更新数据优化信息，这里一般不用做选择-->下一步检查数据完整性，也一般不选择

4、下一步指定数据库维护计划，默认的是1周备份一次，点击更改选择每天备份后点确定

5、下一步指定备份的磁盘目录，选择指定目录，如您可以在D盘新建一个目录如：d:\databak，然后在这里选择使用此目录，如果您的数据库比较多最好选择为每个数据库建立子目录，然后选择删除早于多少天前的备份，一般设定4－7天，这看您的具体备份要求，备份文件扩展名默认的是BAK

6、下一步指定事务日志备份计划，看您的需要做选择-->下一步要生成的报表，一般不做选择-->下一步维护计划历史记录，最好用默认的选项-->下一步完成

7、完成后系统很可能会提示Sql Server Agent服务未启动，先点确定完成计划设定，然后找到桌面最右边状态栏中的SQL绿色图标，双击点开，在服务中选择Sql Server Agent，然后点击运行箭头，选上下方的当启动OS时自动启动服务

8、可以设置启动启动sql server Agent:运行Servicesmsc，设置sqlserverAgent为自动启动。

修改计划：

打开企业管理器，在控制台根目录中依次点开Microsoft SQL Server-->SQL Server组-->双击打开你的服务器-->管理-->数据库维护计划

　1、打开控制面板，找到Microsoft Exchange Server 2010，选择卸载它。

2、下一步，继续卸载步骤

3、清除要删除的服务器角色框，因为这是一台多角色安装的服务器，这里全部清除，下一步

4、要卸载exchange server 2010，系统会先进行准备情况的检查。

邮箱角色中出现“邮箱数据库不能删除，存在一个或多个邮箱和仲裁邮箱”的报错，如下图：

5、我们将用户邮箱迁移到新服务器数据库，(如果不选择迁移，也可以删除所有用户邮箱，这个过程要慎重 *** 作)过程比较简单，这里就不详细讲解了，接下来我们继续查看系统邮箱。

方法如下：

开始---管理工具--Windows PowerShell Modules PC 命令行工具

运行命令 get-mailbox –database “<数据库ID> “ 查看当前邮箱

get-mailbox –database “<数据库ID>” -arbitration 查看当前仲裁邮箱

6、系统邮箱都显示出来了，下面我们把系统邮箱从mailbox01迁移到新服务器数据库mailbox02,执行如下命令，

Get-Mailbox –Database mailbox01 -arbitration | New-MoveRequest –TargetDatabase mailbox02

如果是选择彻底删除系统邮箱，请执行以下命令：

Get-Mailbox -Database "mailbox01" –arbitration | Remove-Mailbox -Arbitration -RemoveLastArbitrationMailboxAllowed

7、我们继续exchange server 2010，卸载成功了，是不是这样就行了呢？明显是不行的。>

使用EMC控制台，可以在服务器配置菜单下面找到需要切换的数据库，右击对应的被动副本，选择Active即可将其切换为主动，或者使用EMS，输入命令active-mailboxdatabase命令进行切换。

可以使用ESEUTIL工具对该数据库进行修复，大致步骤如下：

查看数据库状态是否为Dirty Shutdown（即有transaction log丢失）

使用命令：eseutil /mh “database name”（该命令需要在cdm下进入exchange安装路径下输入才能够生效）；

如果为Dirty Shutdown，使用命令eseutil /r“database nameedb”进行软修复，或者使用命令eseutil /p“database nameedb”进行硬修复（会删除corrupt page并创建白空间）；

修复完成后查看如果DB为Clean Shotdown即可成功mount数据库。

我给你找了一些资料,希望对你有帮助 一 Exchange的备份与恢复概谈

Exchange备份分为联机备份和脱机备份两种。顾名思义，当运行exchange时执行的备份为联机备份，这类备份往往需要支持exchange的程序来完成，如NTBACKUP以及第三方备份软件针对exchange的数据库提供的解决方案。这类程序按逻辑备份数据，也就是说，备份所有与信息存储相关的数据和所有与目录服务相关的数据。脱机备份则是在服务停止时执行的文件级的备份。

联机备份

Exchange 支持四种类型的联机备份：常规或完全、复制、增量和差异。常规备份先备份您的数据库文件，然后备份事务日志文件，之后再从目录中删除事务日志文件。这意味着您可禁用循环日志记录，因为您的备份软件会删除日志文件。因此如果执行常规备份，您就不会遇到日志文件充满驱动器的问题。要还原常规备份，只需要还原上次常规备份集并启动该服务即可。

增量备份只作用于日志文件，因此仅适用于禁用循环日志记录的情况。象常规备份一样，增量备份也会在备份后将日志文件清除。因此，它提供了在不损害可恢复性的情况下去掉日志文件的另一种方法。要还原增量备份，必须返回到上次常规备份集（其中包含您的数据库文件）。还原这些数据库文件，再还原常规备份后的每个增量备份集，然后启动该服务。请注意，只有当您还原所有的备份集之后，才能启动该服务，否则在备份集之后还原的任何日志都不能向前运行。

象增量备份一样，差异备份也作用于日志文件，因此若要使用它，就必须禁用循环日志记录。然而与增量备份不同的是，差异备份不删除日志文件。要还原差异备份集，请返回到上次常规备份并还原您的差异备份集（它包含上次常规备份后产生的所有日志文件）。使用增量备份时，只有当您还原了所有的备份集之后，才能启动该服务。

脱机备份，任何备份软件都可以执行脱机备份。不过，在还原时脱机备份不能象对应的联机备份一样自动放出所有日志文件。因此，Microsoft 不推荐使用脱机备份进行每日备份。但是，当联机备份失败后，脱机备份就非常重要。

恢复

恢复数据的方式取决于您是返回到联机备份还是返回到脱机备份，而还原联机备份比还原脱机备份要容易一些。在每日常规备份中，您只是简单地还原上次常规备份并启动该服务。在常规加增量备份中，您将还原上次常规备份和所有增量集并启动该服务，而 Exchange 会放出所有日志文件。在常规加差异备份中，您将还原上次常规备份，还原上次差异备份，并启动该服务。

在脱机备份中，您将执行还原目录服务的一个步骤和还原信息存储的另一个步骤。对于目录服务，应还原 DSADATA 目录，必要时使用 Windows NT 注册表在各个不同的驱动器上找到多个 DSADATA 目录。然后，启动该服务。对于信息存储，应还原 MDBDATA 目录（其位置也出现在注册表中），然后运行 Microsoft Exchange Server 下 bin 目录中的 ISINTEGEXE 程序，并给此程序提供 -patch 命令行选项。然后，停止该服务，它自己应当再次启动。

二 如何做

联机备份

要使用“备份向导”对 Exchange Server 计算机执行联机备份，单击开始，指向程序，指向附件，指向系统工具，然后单击备份。或者，在命令提示符处键入 ntbackup。

在“要备份的内容”对话框中，选择“备份选定的文件、驱动器或网络数据”，然后单击下一步。这将启动联机备份。

在“要备份的项目”对话框中，展开 Exchange Server 树，选择单位中要备份的任何或所有 Exchange Server 计算机，然后单击下一步。

备注：您不能选择词语“Microsoft Exchange”旁边变灰的框。必须双击 Microsoft Exchange 或单击加号 (+) 展开 Exchange Server 树。您可以将此树向下展开到任何服务器的目录或信息存储区。确认“备份媒体或文件名”框中列出的文件是您要将数据备份到的文件，然后单击下一步。 单击完成继续进行备份。

要不使用向导备份 Exchange Server 计算机，请按照以下步骤 *** 作：

单击开始，指向程序，指向附件，指向系统工具，然后单击备份。或者，在命令提示符处键入 ntbackup。

在“欢迎使用 Windows 2000 备份及故障恢复工具”对话框中，单击备份选项卡，然后展开 Microsoft Exchange 树。选择单位中要备份的任何或所有 Exchange Server 计算机。备注：您无法选择词语“Microsoft Exchange”旁边变灰的框。您必须双击 Microsoft Exchange 或单击加号 (+) 展开 Exchange Server 树。您可以将此树向下展开到任何服务器的目录或信息存储区。

确认“备份媒体或文件名”框中列出的文件是您要将数据备份到的文件，然后单击开始备份。 验证备份作业信息对话框中的信息，然后单击开始备份

脱机备份与恢复

检查工作:

确定是否为存储组启用循环日志(不要启用）。(exchange系统管理器>存储组->属性->通用，不钩选启用循环日志。)

确定 Exchange 数据库、流、事务日志和检查点文件的路径位置以及存储组的日志文件前缀。(exchange系统管理器>存储组->属性->通用,记录日志文件前缀（E0n）,事务日志位置 (E0nlog)系统路径位置 (E0nchk), 数据库路径列在每个 database_name 对象的 Database 属性中,stm,edb)Dismount 要备份的数据库。

脱机备份

1 验证验证数据库文件（edb 和 stm 文件）一致且相互匹配。为此，请对每个文件运行以下命令

eseutil /mh database（edb） file | find /i "DB Signature"

eseutil /mh database file (stm)| find /i "DB Signature"

若两个文件DB签名相同，则说明属于同一文件集。

eseutil /mh database file ,state=clean shutdown

2 将edb,stm文件备份。

3 装入已备份的数据库。

4 若稍后要钱滚，则备份所有带编号的事务日志文件（E0nxxxxxlog 文件）。不要备份 E0nlog、Res1log 和 Res2log 文件。

5 查看检查点文件的标头，以确定可以安全删除的编号最大的日志文件。如果数据库异常停止，检查点将跟踪自动恢复所需的编号最小的日志文件。要查看检查点文件，运行以下命令:eseutil /mk E0nchk

6 令验证已备份日志文件的完整性：eseutil /ml E0n

脱机恢复

“时点”恢复。日志文件不会重放到数据库中。备份后所创建的所有数据都将丢失。存储组中的所有已停止数据库必须一致，并且必须存在有效的检查点文件。不要删除当前的检查点文件或任何现有的日志文件。

“前滚”恢复。备份后所创建的日志文件将被播放到数据库中。如果所有日志文件都可用，则备份后所创建的全部数据都可保存下来。如果启用了循环记录，则必须对脱机备份执行“时点”恢复，而不能选择“前滚”恢复。存储组中的所有数据库必须停止且一致，并且生成备份后创建的所有日志文件都必须存在（包括当前的 E0nlog）。必须删除检查点文件。

“时点”恢复

1 卸除掉要恢复的数据库，并验证其一致,匹配，且检查点有效。

eseutil /mk E0nchk | FIND /i "checkpoint"

eseutil /ml E0nlog | FIND /i "lgeneration" 看检查点是否位于日志中。

2 将已备份的 edb 和 stm 文件复制到适当的数据库和流式文件位置。

3 在Exchange 系统管理器中数据库对象的“数据库”属性内单击以选中 This database can be overwritten by a restore（可以用恢复覆盖此数据库）复选框。

4 装入已恢复的数据库。

“前滚恢复”

1 卸除掉要恢复的数据库。

2 检查一致性。

3 检查每个数据库标头中记录的日志签名是否为低锚定日志的签名。运行以下命令：

eseutil /mh database_name | find /i "Log Signature"

eseutil /ml low_anchor_log | find /i "Signature"

4 检查当前数据库路径位置是否与创建备份时的路径位置相同。

eseutil /ml "Last_Consistent"_log | find /i "database name or pattern"

5 从连续序列中尽可能靠前的低锚定编号开始，收集所有日志，并将这些日志复制到当前的事务日志路径中。

6 验证所有日志是否共享同一日志签名并处于连续序列中。

eseutil /ml E0n > 20049995942htmtxt

7 如果高锚定日志尚未命名为 E0nlog，则重命名它。

8 从“系统路径”文件夹中删除 E0nchk 文件。

9 作为装入存储组前的最后一步检查，请验证以下几个方面：

 所有数据库文件都存在于其运行路径中。

 运行事务日志路径中仅有的日志文件从低锚定日志开始，并至少持续到高锚定日志，其中编号最大的可用日志名为 E0nlog。

 “系统路径”文件夹中没有 E0nchk 文件。

10 如果信息存储尚未运行，请启动它，然后至少在存储组中装入一个数据库。

三 数据库故障处理

当无法mount上数据库时，按下列步骤 *** 作

1 尝试启动信息存储，看错误提示和事件日志。

2 检查一致性

eseutil /mh databasename

3 若state=dirty shutdown,则不要remove log

若state=clean shutdown,则把log移出，转到第11步。

4 不一致执行软恢复eseutil /r

成功再检查一致性，转到第9步。

5 若磁盘空间不足，执行碎片整理(eseutil /d)

6 数据库不一致并且软恢复不成功

删除mdbdata中的所有Log文件，还有chk文件，以及tempedb文件。

7 执行eseutil /p,恢复到一致状态。

8 将数据库装入一次，并马上卸除。

9 使用 Isintegexe 修复 Pub1edb 数据库和 Priv1edb 数据库(isinteg -s (servername) -fix -test alltests)

10 如果能够启动信息存储服务，而且信息存储较为稳定，并且在多次运行 Isintegexe 后仍报告同样的错误和警告，请使用 ExMerge 实用工具，通过将数据导出为 pst 格式，然后将其重新导入新的或干净的数据库结构中来重建信息存储。

11 重新启动信息存储,mount 存储。

12 做一次全备份。

四 其它信息

edb 和 stm 文件是所有数据库信息的最终储存库。在大多数情况下，应将这两个文件视为一个文件；请一前一后地备份和恢复这两个文件。这两个文件必须在时间上相互保持同步；在某一天备份的 edb 文件不能匹配在另一天备份的流式文件。为避免对哪些日志文件属于各个存储组产生混乱，以唯一的日志前缀命名属于指定存储组的 Exchange 日志，该前缀是文件名的前三个字符，存储组的当前日志文件总是 E0nlog。事务日志的大小统一为 5 MB。如果当前日志文件已满，将用十六进制序列号（称为日志生成编号）将其重命名，并生成新的当前日志文件。日志文件被编号为 E0n00001log、E0n00002log，依此类推。带编号的日志文件一般被指定为 E0nxxxxxlog。

如果数据库异常停止，则检查点文件 (E0nchk) 将记录作为恢复起点的事务日志，恢复必须从此起点处开始重放，以恢复数据库一致性。该过程称为“软恢复”。软恢复与“硬恢复”相对，后者是在恢复联机备份后重放日志文件的过程。软恢复和硬恢复之间最重要的区别是：在硬恢复期间，将修补文件数据插入了日志文件重放过程。不一致的 Exchange 数据库文件是没有将所有未完成事务全部写入其中的文件。在正常 *** 作期间，Exchange 数据库文件是不一致的，因为在缓存中存在尚未物理写入该文件的信息。通常，只有数据库服务正常关闭后，Exchange 数据库文件才被认为是一致的。不过，数据库作为一个整体（该整体被认为是事务日志和数据库文件中的信息总和）始终是一致的，除非所需的日志文件被过早删除。

处理数据库签名与路径不匹配问题

与日志文件一样，数据库也有自己的签名。不同的是，虽然自创建 E0n000001log 文件之后日志签名不会再更改，但每当数据库的物理拓扑改变时，数据库签名将会更改，并且不通过日志文件对这些更改进行跟踪。使用 Eseutil 对数据库进行脱机碎片整理或修复时，会更改 DB 签名。经过这样的事件后，数据库可以附加到先前的同一日志流，但它将不接受数据库具有先前签名时所执行的所有事务的重放。数据库的以前副本不接受数据库签名更改后所执行的任何事务的重放。由于数据库签名以这种方式重置，因此强烈建议您在对数据库进行脱机碎片整理或修复后，立即创建完全数据库备份。如果您以后恢复具有旧签名的数据库副本，将会成功重放到签名更改点，但您将会丢失该点之后的所有更改。如果在日志流中间更改了数据库路径，其效果与更改签名类似：重放将在更改点中断。（联机备份 API 提供了一种手段，可以在恢复过程中重新映射路径；因此，即使在创建备份后更改了路径，联机备份 API 也可以完全重放日志。）

右键mailstore--数据库，应该有一个选项是允许被还原覆盖，点上即可

如果还是不行的话，你就要看看事务日志了

本文以数据库的基本原理为基础，分析了EXCHANGE SERVER的存储系统，并说明了各部分的作用。

一、IS服务和ESE的层次关系

IS服务是EXCHANGE服务器中重要的服务之一，它控制着对邮箱和PF的存储 *** 作请求，EXCHANGE服务器的存储实际上是由ESE的数据库引擎来管理的。这个ESE引擎是微软专门为保存非关系型数据而开发的，目前在微软的很多产品中都有广泛的应用，如：AD数据库、DHCP、WINS、SRS等等。

EXCHANGE的数据库是由EDB文件、STM文件和LOG文件组成。在这些文件里，微软使用了“B+树”的内部数据结构。ESE的引擎的任务之一，就是当IS服务请求访问数据库的时候，把这些请求转化为对内部数据结构的读写访问。B+树的特点是能够对存储在硬盘上的数据提供快速访问能力。微软利用“B+树”作为ESE的后台结构的主要原因，就是尽可能的提高访问数据时I/O性能。当然，这些结构对于EXCHANGE STORE来说是透明的。

另外，作为一个数据库系统，ESE有责任提供事务级别的 *** 作的支持，并维护数据库的完整性和一致性。对数据库系统而言，我们提到事务时，一般用ACID来描述事务的特点。

A--Atomic（原子的）：事务必须是全或全无的 *** 作，要么全部成功更新，要么全部不被更新

C--Consistent（一致的）：一个成功提交的事务必须使数据库处于一个一致的状态。

I--Isolated（孤立的）：所有未提交的更改都必须能够和其他事务孤立。

D--Durable（持久的）：当事务一旦提交，所做的更改必须存储到稳定的介质上，防止系统失败导致的数据库不一致。（此点非常重要！！）

二、EXCHANGE 2000/2003存储系统的新特点

在EX55中，ESE的版本为ESE97，而在EX2000/2003里，ESE版本已经升级ESE98了。ESE引起在以下方面得到了改进：

I/O性能进一步提高和优化

对日志文件增加了计算校验 *** 作

提高了ESEUTIL等工具的维护速度

而IS也在以下方面有了更新：

在每个SERVER上提供多个SG支持

数据库STM文件格式的引入，提高了INTERNET邮件的性能

WSS的引入，用户可以使用多种协议访问数据库

三、EDB和STM的关系

常有人问，EDB文件是数据库，那STM文件是做什么用的？可以删除吗？

在EX55里，只有EDB文件，因为在EX55发布时，微软主推的是内部邮件系统，因此其主要协议为MAPI，这是微软的私有邮件西医，EDB文件是专门为此协议优化过的。因此在EX55中，为了支持INTERNET邮件，必须在每次处理INTERNET邮件时，做一个格式转换。这显然带来了性能的损失。

在EX2000里，微软加大了对INTERNET邮件的支持，这就是STM文件的来源。MAPI格式是RPC和二进制标准的，而STM是纯文本加上一些MIME编码格式，这样的区别使得它们不可能存储在同一数据库里。因此EX2000中，微软开始使用EDB和STM两个文件来分别保存两种格式的邮件。并且在两个文件之间建立了引用和关联。对于用户来说，它的邮箱实际上是跨越了EDB和STM文件共同组成的。另外，需要注意的是，EDB文件中还保留着用户的邮箱结构。所以EDB文件更加重要。那么EDB和STM是怎么协同工作的呢？我们以几个情景来分析之。

情景一：用户使用OUTLOOK（MAPI）发送接收邮件

在该情景下，用户将邮件通过MAPI协议提交给数据库，直接被保存EDB文件中。当用户通过MAPI访问邮箱里的邮件时，如果被访问的邮件在EDB里，直接返回，如果在STM里（如外来邮件），则执行转换，将STM转换为EDB文件格式，再返回用户。

情景二：用户使用标准SMTP/POP3/IMAP4等协议访问

用户使用非MAPI协议提交的邮件，内容保存在STM文件里，但是由于EDB里有邮箱结构，STM没有，因此系统会把邮件的重要信息提取出来，放在EDB里。当用户用MAPI提取邮件时，过程同上，当用户通过标准协议访问时，同样需要进行格式转换，转换为STM文件格式返回。 这些转换是在后台发生的。对用户来说是透明的。通过上面的描述，你会看到，这两个文件是紧密联系的缺一不可。所以，在任何时间我们都不要单独 *** 作这两个文件，它们是一个整体。同时也要注意的是，无论用户使用何方式访问邮箱，都需要向EDB文件请求邮箱结构信息，这是需要注意的。

四、LOG文件的重大作用

在论坛里经常会看到有人说我的硬盘怎么很快就没了，一看原来是日志文件搞的鬼，于是就有人删除日志文件，甚至使用循环日志来强制减少日志，甚至有人提出这样的疑问，日志到底有什么用？是不是多余的'？那我们来看看日志的重大作用。

对于一个SG来说，系统会产生一系列的日志，这些日志的扩展名为LOG，前缀一般是E00、E01……除了这些连续的日志文件外，还有一些特殊的日志文件（res1log,res2log,e0xchk））），它们又有什么用呢？我们的管理员通常不喜欢备份这一 *** 作，因此对这些日志是痛恨不已啊。那么微软在EXCHANGE数据库系统中引入日志的作用难道真的是多此一举吗？我们从以下几个方面来考察一下日志的作用：

1、作为一个企业级的邮件系统，必须要保证数据安全和完整。必须能够面对随时可能发生的意外灾难，把数据损失降低到最小。

2、必须提供高性能的邮件处理能力，对数据库中的邮件的事务 *** 作在完成后必须马上（或是说立即）被记录在存储介质上（见前面的事务持久性说明）

3、灾难发生后，使用数据库备份恢复必须要返回到灾难发生前一刻的数据库状态（这是至关重要的！！）

现在我们来更进一步的看一下，当用户要修改邮箱中的内容时，被修改的内容首先被提取出来放到内存中，实际的修改是发生在内存里的，这是众所周知的，当修改完成后，这些内容必须被尽快写回存储介质，这样才表示一个事务成功完成了。

从事务的描述中我们可以看到，事务是具有原子特性的，为了保证数据库的一致和完整，事务必须全部成功或全部失败，如果事务失败，则必须回滚到事务开始的状态。而当邮件在内存中修改完成后，此时事务并没有完成（为什么呢？）因为一旦系统崩溃，这些修改就丢失了。所以要确保事务修改完成，必须尽快将修改写回到数据库里去（也就是硬盘上）。这也是事务的持久性要求。注意，我们这里说的第一时间或是尽快，是一个什么样的概念。如果我们直接修改EDB文件，由于EDB

文件比较大，那么在硬盘上修改一个大文件，就 需要花费大量的时间在等待和寻找数据存储块上（见 *** 作系统原理），当系统出现高负载的繁忙状态时，这将是一个非常大的瓶颈。也就无法做到“尽快”了。那怎么办呢？所以数据库系统使用了日志，而日志通常很小（EXCHANGE的日志只有5MB），向这些文件写入修改结果是很快速的，因此当内存的修改完成后，这些结果就会立即写入日志中，以保证了事务的持久性。当成功写入日志后，该事务就成功完成了（现在在硬盘上了，不会因为当机丢失了）接下来，ESE引擎会在后台慢慢将这些日志里的修改记录写回真正的数据库里去（这对用户来说已经不是那么重要了），这就是日志的第一个作用：确保事务在第一时间（尽可能快的）保存到非易失存储器上（提供了事务持久性支持）。

根据上面的藐视，我们看到运行中的EXCHANGE数据库，是由三个部分组成的：

内存中已经完成处理还没有写会到日志里的内容（Dirt page）

还没有写到数据库文件里的日志内容

EDB和STM数据库文件

对于第一个部分，一旦掉电就回丢失的，是最不安全的。而对于第二部分的内容，系统通过检查点文件（CHK）来标记哪些日志已经被写入数据库了，而哪些还没有。CHK文件类似一个指针。我们可以用“ESEUTIL /MK”来检查CHK文件里的内容，在该命令的输出中的checkpoint:<0x8,26d1,29>这样的东西就是检查点位置，它表示E0x00008的日志的页面序号已经被成功写入数据库了。大家可以自己看看。。：）

前面提到过，EXCHANGE系统在出现灾难时，应能恢复到灾难发生前的时刻的状态。这是非常重要的。但即使是最勤快的管理员，也只能在指定的预定时间内做系统备份，而不可能时时刻刻的都在备份。那么在备份完成后到灾难发生之前的这段数据该如何保护呢？是不是就任由它丢失呢？显然是不可能的。那答案是什么呢？就是日志文件。前面我们知道，任何对数据库的更改都先写入日志里，再由日志写入数据库，这样我们只要找到日志文件，就可以重新进行模拟的 *** 作来完成备份后的数据库文件的更改了，我们举个例子来看看：

假设我们在凌晨3点完成了一次FULLBACKUP，备份完成后，系统正常运行，到下午4点的时候，系统突然崩溃。管理员用凌晨3点的数据恢复了数据库，那么从凌晨3点到下午4点这段时间的数据变更，就只能依赖于日志了。当完成数据库恢复后，系统会自动的跟踪到关联的日志文件，如果发现有比当前数据库还新的日志存在，系统就会自动的按照日志的顺序将更改写回到数据库中去。因此这样一来，从凌晨3点到下午4点的数据变更就被完整的恢复了。这就是日志的第二个作用：保证系统备份和恢复的完整性。当然前提是没有使用循环日志！！（看到了吧，使用循环日志的危害是相当大的，比起你的数据来说，多做几次备份不是没有意义的吧？

说到这里，有人可能要问，如果数据库和日志同时损坏，如何办？答案是：尽量避免这样的情况发生。首先数据库损坏的几率要大于日志，另外，微软建议将数据库和日志分别存储在不同的磁盘上，要是这样还会同时坏，那就没有办法了，呵呵。。对于管理员对日志文件的抱怨，合理的解决方法是定期做备份。启用循环日志是不正确的做法，当启用循环日志后，一旦系统发生灾难恢复，将有可能不能将系统恢复到灾难发生时的状态，磁盘和数据谁更重要，管理员自己要考虑考虑了。

五、ESE与IS服务的启动和关闭

ESE引擎在加载数据库文件时，会去检查数据库文件的标志。这个标志保留了上次关闭数据库的状态，当状态为正常关闭说，系统将直接加载该数据库，当数据库标志为非正常关闭时，系统将先进行一个软恢复过程（你可以在事件里看到它），然后再加载。

那么，正常关闭和非正常关闭有什么区别呢？一个正常关闭的数据库，表示所有的日志信息都已经正确的写入数据库了。反之一个非正常关闭的数据库，则表示至少有一部分数据未能正确的从日志写入数据库。要注意的是，非正常关闭的数据库并不等于已经被破坏的数据库。只表示有数据没有提交到数据库文件。

使用ESEUTIL/MH命令可以看到数据库的该状态，其中的STATE字段标记的就是这个状态，“CLEANSHUTDOWN”表示数据库正常关闭。当系统加载处于非正常关闭的数据库时，就会根据检查点文件确定日志文件的位置，并做重放 *** 作。当检查点文件丢失或损坏时，系统将从最早的日志文件开始处理。有的时候，系统不能自动的修复数据库，这时我们也可以用“ESEUTIL /R”命令手工的恢复处于非正常关闭状态的数据库。强烈推荐在系统异常关闭后执行此命令。在执行前最好前确定数据库文件的状态确实为非正常关闭，不要对正常关闭的数据库执行该恢复命令！

由此可见，EXCHANGE系统对数据库有自我修复能力，能确保系统在发生意外后恢复正确的状态。但这并不是说我们可以随意的关闭系统，仍要UPS等必要的保护措施。

六、关于M盘

在EX2000里，有一个M盘的映射。这个映射只是提供开发人员通过API访问邮箱和邮件用的。因此对M盘的手工 *** 作都可能带来数据库的破坏，请注意，另外，有一种观点认为备份了M盘就备份了邮件，这是绝对错误的。M盘虽然是数据库的映射，但已经去掉了很多的关联和内在联系。因此备份M盘是不能恢复数据库的。所有的EXCHANGE管理员必须按规定认真的备份系统状态和SG。切不可偷懒哦。

如果是Hub服务器且设置了NLB，需要将服务器从NLB中删除。

如果是mailbox服务器且配置了DAG，需要先将所有数据库删除，之后将服务器从DAG中删除。

最后卸载对应的exchange角色。

以上就是关于C#如何获取exchange2013上的默认数据库全部的内容，包括:C#如何获取exchange2013上的默认数据库、超易备备份Exchange数据库问题、如何手动删除 Exchange 2010等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！