今天我们主要讨论Exchange 2000路由和存储、如何部署路由和存储、以及路由和存储的一些变化。希望Exchange能提供更好的性能，这也需要更正确地部署其规划和实现方法。 [课程要求] 本课假定你了解Exchange Server的一些基本知识，比如它的界面、数据库及消息的传输方式等。如果你了解Exchange 5.5中的信息存储，这将非常有帮助作用。此外，如果你熟悉MTA（消息传输代理），这也很有帮助作用。
[今天的学习内容]
今天将学习哪些内容呢？如何配置Exchange 2000存储组及Exchange 2000的多数据库能力。它可以提供极大的灵活性，因而也使得部署方案更为复杂，因此你必须确定如何以最佳方式使用这些新特性。 我们还将讨论前端和后端服务器，它们可以在Exchange 2000中提供更多的伸缩能力，这是一些重要的伸缩能力。
此外我们还将讨论内容索引、Microsoft Search以及它所具有的帮助作用。
然后我们将讨论日志文件管理、维护备份和恢复、日志文件的一些改进措施，以及一些新的备份和恢复选择。
我们将讨论如何从桌面和Web存储访问Exchange数据。
[今天的学习内容（#2）]
如果从公共文件夹运行一个网站，Exchange数据如何实现任意位置的可用性。 我们将讨论5.5的路由组和路由组连接器、结点的去向等。
我们将讨论连接状态，我们还将监视Exchange管理某向下连接。
[Exchange 2000基本知识]
让我们从学习Exchange的基本知识开始。Exchange 2000只能运行于Windows 2000之上。你需要保持活动目录的运行状态，因为Exchange 2000本身没有目录服务，但它需要活动目录。活动目录包含配置信息，并且提供了地址表。Exchange 2000还依赖于Windows 2000自带的Internet Information Server 5.0。它依赖于SMTP/NNTP传输协议。事实上， IIS 5提供了Exchange 2000所需的全部协议，这些协议组成了一个通用协议结构。
当然，Windows 2000上的所有特性都依赖于DNS（域名系统）才能正确运行。 [Exchange 2000中的存储]
[Exchange 2000中的存储的改变]
让我们从Exchange 2000中的存储和Exchange 2000中的存储改变开始讨论。我们很快就向你们介绍这部分内容，主要讨论多数据库支持、存储组、数据库组合方式、一些随播内容转换及Exchange体系结构等。
[术语]
这里有一些术语。SG就是存储组。存储组就是数据库组，存储组是事务量的单位。每个存储组都有其专用的事务日志组。数据库实际存储的是数据，你可能很熟悉Exchange 5.5的PRIV和PUB，现在每个存储组最多可以拥有6个数据库。这一数字可能随该产品发布日期的临近而发生改变。 我们可以使用数据库文件，每个数据库可以有多个数据库文件，因此我们可以将数据存放于基于该格式的多个位置处，我们将在稍后讨论该问题。目的就是减少内容转换。
[Exchange 2000存储采用了Exchange 5.5的特性]
让我们讨论一下Exchange 2000存储、它的去向及来源。它的来源就是Exchange 5.5。它采用了层次化存储模型--数据库、文件夹和属性。它采用了单字节存储，并采用了企业版上多达17TB的超大数据库容量。它采用了基于事务的可恢复性和复制。它采用了本地Internet访问协议，如POP、IMAP和NNTP等；它采用所有这些特性，完善并增添了一些新功能。
[Exchange 2000添加了以下特性]
每台服务器的多数据库--附加的数据库文件和流式媒体文件。在这部分内容中，我们将讨论公共文件夹树、多公共文件夹树、合作应用的公共文件夹树、添加内容索引、完全URL寻址等。在一般情况下你可以获取Exchange 2000中的所有对象，如果你知道合适的URL。所有内容都有一个友好URL，你可以使用该URL实现这一功能。它还使用了Windows 2000访问控制表。你无须判断"这是不是我将分配权限的邮箱，这是不是我将分配权限的帐户"。所有权限都分配了一个Windows 2000帐户，此外，我们不将过多讨论OLE DB和ADO中对存储中数据访问的增强及同步和异步事件。
[多数据库]
让我们从多数据库开始讨论存储。
[Exchange 5.5存在的问题]
Exchange 5.5存在的问题就是：数据库可能非常庞大。大型数据库可能大到数GB甚至数TB，它们在备份和恢复或日常维护时需要耗费大量的时间。如果出现问题，你将不得不面对很长的停机时间。此外，大型存储的容量有时可能不匹配备份或恢复的容量，因此要使用全功能并将大量用户置于服务器上是很困难的，因为将大量用户置于服务器上的仅有方法就是把它们都放置在同一数据库中。这可能会使你的数据库过于庞大，因而难于管理。 5.5实际上还不够灵活，不能将多个企业组合在同一服务器上，此时需要采用不同的循环日志功能、不同的备份模式和备份进度表。如果你位于同一台服务器上，你将位于同一信息存储上，你将遇到相同的循环日志问题、相同的备份和恢复问题，因此所有用户都将受到影响。同一服务器上的所有用户都将受到损耗、备份和恢复问题的影响。它也不能区分不同的数据类型。
[Exchange 2000多数据库支持]
利用多数据库支持，你将获得更好的可伸缩性，事实上，每台服务器都可以拥有更多的用户数，因为你不再需要将所有鸡蛋放在一个篮子中，你可以在服务器上使用多个数据库。因此你不必将整个企业放置在同一数据库中。你可以将整个企业放置在一个服务器上，并跨多个数据库展开。 你可以选择使用多专用或公共数据库。单个数据库可以脱机、装配和卸下。因此，如果你需要维护某台服务器，并且该服务器上还有其他几个数据库，你就可以使用该特性。你可以将该数据库脱机，卸下该数据库，执行维护操作，执行恢复等，而不会影响到其他数据库的用户。这些用户仍然可以访问服务器，登录、收取邮件等。
此外，你还可以精细地控制备份和恢复哪些数据库，因此你可以同时进行数据库的备份和恢复操作。我们将在稍后讨论恢复，因此暂时保留这些问题。我们将用一整节来讨论备份和恢复。
你必须理解Exchange 5.5中的这一概念--每台服务器都有单实例存储。在Exchange 2000环境下，每个数据库都有单实例存储。如果你向Exchange 5.5服务器的60个用户发送一个消息，该数据库将只有该内容存储的一个副本。现在，利用Exchange 2000，如果这60个用户位于6个不同的数据库上，它们将有内容存储的6个不同副本。因此，每个数据库都是单实例的，这就是主要的区别。通过使用户分布于多个数据库上，你将得到可靠性和易管理性，这样做将影响服务器的总体存储使用情况。 [多数据库：优点]
现在讨论关于多数据库的一些改进。主要优点：所有的数据库不必位于同一位置，所有用户不必位于同一位置。因此如果出现故障，该故障不会影响到所有人。
灵活性和备份进度表是非常有用的，因为你可以选择在11点备份一个数据库，在午夜备份一个数据库，凌晨1点备份一个数据库，凌晨2点备份一个数据库。因此你不会因为大量备份操作而使网络趋于饱和，你可以选择某数据库的备份时间，如果需要，你还可以在不同日期进行数据库备份。 此外还提升备份和恢复性能，因为你将备份更少量的数据，同时也因为数据库要小于所有用户位于同一数据库的情况。
因为数据库的大小可能会缩减，脱机工具将具有更快的速度，因为需要它们操纵的数据减少了。
同时，媒体损坏也不会影响到所有用户。你可以将你的数据库放置于不同的驱动器上，当某个驱动器出错时，它将不会影响到所有数据库。
你可以对不同类型的数据库进行组织和分类。将你的公共文件夹放置在这里，使它成为合作公共文件夹，为一般性用户使用另一个公共文件夹。你可以将不同的部门放置在独立的数据库上，如果你有不同的支持需求或不同的建立需求。如果你是一个ISP，你应该将不同的企业放置于不同的数据库中，原因同上。
[下一行多数据库：缺点]
现在讨论多数据库的一些缺点。数据库中的自由空间不能被其他数据库所使用，因此，如果在另一个文件中有2G的自由空间，这部分空间当然不能被访问。它们是独立的文件、独立的数据库，它们不能被任何其他数据库使用。
不存在跨数据库的单实例。此外，单实例存储以每个数据库为基础。如果你向两个人发送消息，他们位于不同的数据库，该消息的一个副本将驻留于每个数据库中。 管理多数据库可能会比较困难。只要某事物的数量增加，其管理工作必然会趋于复杂化。你需要规划存放数据库的位置和备份这些数据库的方式，备份模式也更为复杂，但从长远来看，这样做肯定可以节省时间。
移动一个数据库，例如，使备份作废。如果你想要将某数据库移动到一个新簇，也就是文件夹中的新目录，你需要在完成该操作后立即备份该数据库，因为如果你不这么做，指针将关闭。路径也将关闭。
[使用多MDB的场合]
使用多数据库的场合：同一服务器上有多个企业。管理型邮箱或VIP邮箱，如果需要恢复单个邮箱，你需要获取备份、重建服务器或恢复整个数据库。这样做很困难，同时也很费时间，如果你有一个VIP邮箱，所有的行政人员将他们的邮件保存在该邮箱中，你就可以将数据分割为较小的数据库，这样做更易于备份和恢复。
你可以分割大型公共文件夹应用。
使用多数据库时需要考虑的一些事项。你需要大量的磁盘空间，以处理存放于该数据库中的消息。处于容错性和性能考虑，你应该让每个数据库位于其独占的簇上。创建附加数据库需要占用一些内存。如果添加一个数据库，Exchange存储服务需要使用10MB的内存。这一情况可能在最终发布版本中有所改变，但它肯定会占用一定的内存，因为它必须管理此类事务。
[什么情况下不使用多数据库]
什么情况下不使用多数据库。它不是设计用于每个数据库一个邮箱的场合。它不是设计用于完成此类事务。所有人都想拥有他自己的邮箱，这当然很好，但这可能不是资源的最佳利用方式。它可能需要使用大量的资源，你必须拥有一个可以容纳90人的强大服务器，但你可能不想这么做。
此外，我们并不运行实际可执行STORE.EXE进程的多实例。每个数据库是由STORE.EXE管理的子进程。STORE.EXE只是一个进程。我们并不运行多个STORE.EXE。
[存储组]
让我们开始讨论存储组。
[存储组]
存储组是5.5中的一个新概念。5.5是服务器支持的单存储组。事务日志以存储组为单位进行维护。注意不是以数据库为单位，而是以存储组为单位。存储组是我们组合数据库的方式。
每个存储组由一个ESE实例所表述，ESE是一个可执行存储引擎，该实例由我们刚才讨论的存储进程管理。
存储组将是典型的备份单元和典型的集群单元。它们将提供数据隔离、不同的备份和恢复策略等。因此，如果你需要改变处理事务日志的方式，你必须让不同的存储组处理这些事务日志。
如果想要使用增量（非差异方式）备份和恢复策略，你也需要在该存储组级上完成该操作。 [存储组和数据库的限制]
存储组有一个通用日志文件组。我们将详细讨论它，但对于系统上的每个存储组，它都有一个日志文件组。每个存储组最多可以有6个数据库，这一数字可能发生改变，我们还没有最终确定这些数字。每个服务器最多可以有15个存储组，相乘后就可得出每台服务器最多可有90个数据库。因此，如果某存储组有6个数据库，我将有一个事务日志组。如果有两个存储组，每个存储组中有几个数据库是无关紧要的，因为我可以管理两组事务日志。这与Exchange 5.5没有太大区别。如果你还记得，Exchange 5.5上的信息存储有两个数据库：PRIV（专用）和PUB（公共），这两个数据库分别有一个事务日志。
此外，数据库并不设计用于单邮箱。
[存储组日志文件]
继续讨论存储组日志文件。存储组内的所有数据库共享通用的存储文件组。每个存储组都有一个标头日志文件，我们将在稍后看到其名称和名称的影响因素。
每个存储在启动时分别恢复，因此不同存储组上的每个数据库将在系统恢复和日志转入时分别恢复。
存储组对于规划备份和恢复是非常重要的，因为你需要备份整个存储组。我们将在备份和恢复一节中讨论它，因为我们必须备份整个存储组才能有效地裁剪日志。我们将在备份和恢复一节中讨论它。
[存储组举例]
我将给出存储组的一个例子。我们运行了存储进程。这里有一个多存储组的概念。每个存储组有自己的ESE实例，它与日志文件组进行对话。每个存储组有多个数据库。你可以看到这里有两个文件：EDB文件和STM文件。EDB文件是映射数据库，STM文件是流式媒体数据库。流式数据库是本地Internet类型内容的存放位置。使用多数据库文件可以减少内容转换。映射类型数据将恢复EDB文件，Internet MIME型内容将被存放于流式文件中。我们将在稍后讨论它。
[多MDB/SG的部署]
为了了解如何在一台服务器上部署多个数据库和存储组，我们将研究具有4个存储组的服务器的例子。系统和分区都有镜像，页文件则位于另一个硬盘上。事务日志分别位于几个镜像驱动器上，因此每个存储组在其镜像驱动器上都有独立的事务日志组。每个存储组的数据库可以跨阵列系统分布，如Ray 5系统等。
[存储组或数据库]
现在讨论以下问题："你想要使用更多的存储组么？或者更多的数据库么？在什么时候使用它们？使用一个新存储组的原因就是，如果你有不同的循环日志需求，比如你有网络新闻馈送，你可能无需禁用循环日志。禁用循环日志可以增加容错能力。这对于邮件数据是非常重要的，因为你需要最大的容错能力。但对于网络新闻馈送，容错能力就不是那么重要。因为网络新闻馈送量相当大，所以你可能不想保存所有这些日志文件，也不想要增加夜间备份作业量。
如果你使用了不同的备份进度表，如果你打算备份整个存储组，那么你可能想要将数据库分割到不同的存储组中，以支持那些不同的完全备份进度表。如果某企业、某分支机构，甚至某办公室需要其数据的硬分区，他们就可以选择该操作，也就是为这些数据库分配独立的存储组。
集群需求：集群是在存储组级别上进行的，如果你想要集群某些数据，而不是其他数据，那么你必须将这些数据分割到独立的存储组中。
如果你需要更多的数据库，你可以使用一个新的存储组。
,
