操作的一种类型的企业管理器414。 云工具模块412可与企业管理器414 一起操作以提取和/或修改已由企业管理器414在操 作期间收集的数据或操作的类型。由云工具模块412收集和/或修改的数据可被选择为与 分析数据库操作相关。这些数据可随后被提供给云数据中心406以便处理。在一些实施例 中，网关404可按照对于顾客而言透明的方式操作。用于数据库迀移的数据可在正常操作 期间在后台被收集并且存储在提供商数据中心418中。
[0077] 图5表示根据一个实施例的在数据库迀移期间的网关的方框图。如上所述，网关 504可在企业管理器中操作以在正常操作期间记录与数据库迀移相关的数据。网关504可 包括数据仓库514,数据仓库514被配置为存储与遗留系统502的集合的性能关联的信息。 遗留系统502可包括使用关系数据库管理系统（RDBMS)操作的大量源数据库。安装在遗留 系统502上的代理可将信息提供给网关504,该信息被存储在数据仓库514中。在一些实施 例中，数据仓库514可在遗留系统502的正常操作期间连续地填充有数据。
[0078] 专用合并引擎（consolidation engine)520可从数据仓库514中的各种表（诸如， 管理表、垃圾收集表、读日志/写日志等）读取信息。需要注意的是，这允许合并引擎520 总是在手上具有历史性能数据。因此，当顾客创建迀移场景时，能够使用历史数据而非需要 收集未来数据来分析并且准备该迀移场景以便完成该分析。例如，能够经合并引擎520处 理从"MGMT$"表检索的数据，并且结果可被存储在准备好传送回至提供商数据中心518的 专用结果表522中。
[0079] 合并引擎520可从已有表中提取数据并且将该数据放入新的数据模型中。在一些 实施例中，当企业管理器在数据仓库514中填充表时，合并引擎520可检测到变化并且自动 地使用该数据填充新的数据模型。在一些实施例中，合并引擎520可替代地在将数据从旧 格式转换到新的数据模型中之前等待，直至由用户提供迀移场景为止。该新的数据模型可 包括来自数据仓库514内的许多不同数据库的数据。本领域技术人员将会理解，可根据每 个特定实现方式的需要使用许多不同类型的数据模型。
[0080] 图6表不门户600的结构的方框图。门户600可基于分层架构。该门户可被划分 为四个层：界面层636、服务层638、公共部件层640和支持存储库层642。这些层可负责服 务和顾客信息的处理以及在服务器侧的服务的提供和安排。这些层可被用于与位于顾客系 统上并且在顾客系统上操作的网关连接并且通信，使远程管理员能够与网关交互以提供服 务，和/或使顾客能够经门户接收服务以与服务提供商协作。
[0081] 该门户的后?而可包括支持存储库层642。支持存储库层642可被用于利用各种数 据的源来充实和/或提供服务。支持存储库层642可包括存储库或对存储库的访问，存储 库可包括配置、补丁、SR信息或数据等。
[0082] 该门户的后端还可包括公共部件层640。层640的构件可包括在部署期间以及在 部署之后用于支持服务的部件。构件可包括账号管理模块616,账号管理模块616向门户和 服务提供认证、授权和安全。顾客可被提供对门户的访问，并且还被准许访问一个或多个服 务/对一个或多个服务命名。层640还可包括文档模块618,文档模块618提供用于使用门 户管理文档的方法。此外，层640包括用于管理在提供服务时使用的各种请求和步骤的服 务请求模块。配置管理模块622可被用于管理与顾客关联的配置。商业智能模块624可被 用于识别高价值信息。
[0083] 门户600的服务层638可包括每个服务需要的特定模块和功能。每个类型的服务 可包括定义的工作流、逻辑、安全等。每个类型的服务可包括用于管理用于该服务的特殊工 作流、逻辑和其它要求的模块。用于建模604、迀移606、负荷测试608、基准管理610、云成 像612和/或监测614的模块可被实现在层638中。
[0084] 最后，门户600的界面层636提供可由顾客、服务提供商和/或管理员使用的用户 界面（UI)，诸如图形用户界面602。界面层代表用于服务的呈现层。界面层636的用户界 面602可以是响应式web设计，并且如此，可在多个装置（例如，桌上型计算机、智能电话、 平板计算机等）上工作。门户的UI可提供用于服务和/或内容的公共服务界面。UI可在 具有类似外观和感觉的一致界面中提供可用的、安装的、有效的或支持云服务。可使用公共 用户界面部件。导航方法可基于具有用于更多细节的下钻选项的丰富的服务概况报告。月艮 务可紧密地与顾客配置耦合。服务提供所需的技术数据（分析、核实、报告）可被自动地收 集。分析学可被广泛地用于通过创建"容易消费"仪表盘和报告来帮助减少信息过载。应 该注意的是，除了数据库迀移之外，还可通过门户提供其它数据库生命周期服务。因此，为 数据库迀移收集的数据和执行的分析可被与其它数据库生命周期服务共享，反之亦然。这 增加了数据再使用并且减小了云支持服务的数据占位（data footprint)。
[0085] 图7表示根据一个实施例的用于执行迀移前分析并且产生迀移计划的方法的流 程图700。迀移前分析可被用于分析源数据库并且识别能够在目标数据库上重新配置源数 据库的方法，以便优化性能。在一些实施例中，用于执行迀移前分析的方法可从云建模服务 接收输入。这种服务允许用户指定目标数据库和源数据库，并且作为结果，该建模服务提供 对源系统上的数据对象如何能够被配置为在目标数据库系统上操作的分析。例如，该建模 服务可提供推荐：某些数据库应该被组合到单个系统（诸如，Oracle?的Exedata系统）上。 这可以是平台即服务（PaaS)和/或数据库即服务（DaaS)产品的一部分，其中云服务能够 将几个数据库组合到管理的平台上的单个数据库中。将会理解，该云建模服务的任何方面 可被用作迀移前分析的一部分。在共同受让的于2013年7月9日随本申请同时提交的标 题为"Database Modeling and Analysis for Prospective Migration" 的第 13/937,885 号美国专利申请（律师档案号码88325-870374(0RA130617-US-NP))中描述了基于云的建 模服务的全部细节，该申请的全部公开为了所有目的而通过引用包含于此。
[0086] 迀移前分析可分析并且配置数据库设置704、数据库布局706、迀移执行步骤708 和迀移后分析的执行710。在一些实施例中，迀移前分析还可包括对存储在源数据库内的多 个对象的识别和分类。例如，迀移前分析可识别源数据库中的无效对象，能够在已发生迀移 之后针对目标数据库中的无效对象核实所述源数据库中的无效对象。迀移前分析还可识别 非常大的数据库表，所述非常大的数据库表可能需要被细分成较小单元和/或压缩。迀移 前分析还可识别将会在迀移过程期间需要特殊处理的与安全要求、最大离线要求、数据完 整性要求、冗余要求等关联的对象。
[0087] 迀移前分析还可识别源数据库中的数据库选项，并且确定如何将这些选项转移到 目标数据库。例如，源数据库可包括自动存储管理（ASM)特征，并且其选项可能需要被配置 为在目标数据库系统上运行。这还允许不使用ASM的源系统在目标数据库结构中使用ASM。 迀移前分析还可提供可被推荐给用户或目标数据库系统需要的压缩、加密和/或其它数据 变换选项。例如，迀移前分析可提供可通过实现特定数据压缩方案来获得的空间和成本节 约。
[0088] 迀移前分析可导致指定可被用于创建迀移脚本的多个参数712。这些参数可包括 关于源数据库中的特定数据对象可在何时和/或如何被迀移到目标数据库的约束。如果所 获得的迀移脚本是可接受的714,则参数设置可被保存以用于随后的迀移运行718。然而， 门户可将迀移前分析的结果提供给顾客，顾客可随后人工调整该参数716以便实现想要的 迀移脚本和/或计划。在一些实施例中，也可由顾客分析并且包括来自以前的迀移运行的 结果，以调整用于当前迀移计划的参数720。
[0089] 如上所述，迀移前分析可包括产生迀移脚本。准备数据库迀移的一个有益的方 法是将源数据库"切成"小的可管理的块。在一些实施例中，源数据库可被划分为个体对 象，并且每个个体对象可与它自己的迀移脚本关联。迀移脚本可包括用于将关联的对象 从源数据库迀移到目标数据库的指令或参数。通过产生迀移脚本，迀移的处理不仅可以 被简化，而且在它的执行中可以更加模块化。脚本能够被按照不同次序执行，并且许多脚 本也可被并行地执行。通过将大的数据库分解成能够被并行地执行的许多小的脚本，能 够在本公开之前将会需要的时间的一小部分时间中迀移大的数据库。在共同受让的于 2013年7月9日随本申请同时提交的标题为"Solution to Generate a Script Set for an Automated Database Migration"的第13/937, 988号美国专利申请（律师档案号码 88325-870382 (0RA130627-US-NP))中描述了产生迀移脚本的全部细节，该申请的全部公开 为了所有目的而通过引用包含于此。
[0090] _T0D0 :在提交之前确保这个标题是正确的。
[0091] 图8表示根据一个实施例的用于准备运行迀移计划的方法的流程图800。流程图 800可在流程图700的步骤A继续执行。在产生多个迀移脚本之后，可根据迀移计划对脚本 进行排序和/或安排时间。通过将所有迀移脚本捆绑到单个可执行计数据流中，迀移计划 可包括可用于定制如何执行脚本的所有选项。通常，迀移计划可定义迀移脚本的执行次序。 另外，迀移计划可定义能够被并行化的迀移脚本。迀移计划还可指定定时约束，该定时约束 指示何时能够执行某些迀移脚本、何时可使源数据库的某些部分变得不可用以及将会允许 迀移脚本运行多长时间。在一个例子中，迀移计划可指定数据库分割、迀移、压缩和/或加 密可全部被组合到单个离线会话中，从而可根据迀移计划在单个脚本批次期间执行用于这 些功能中的每个功能的迀移脚本。
[0092] 另外，替代于使整个数据库离线以便迀移，在迀移小的块的同时数据库可通常保 持在线。迀移计划可被配置为使离线时间最小化。然而，某些迀移脚本可能需要数据库 在某些间隔期间不可用。替代于使数据不可用，对已经被迀移到目标数据库的源数据库 材料做出的改变，可保持记录。这些记录可随后被用于确保目标数据库稍后被相应地更 新。在一些实施例中，为了将许多数据库合并到单个目标数据库中，这种机制可经安装器 被一起安装在多个源数据库上。在共同受让的于2013年7月9日随本申请同时提交的标 题为"Online Database Migration"的第13/937,545号美国专利申请（律师档案号码 88325-870410 (0RA130628-US-NP))中描述了在源数据库保持在线的同时迀移数据库对象 的全部细节，该申请的全部公开为了所有目的而通过引用包含于此。
[0093] 为了适当地对迀移脚本进行排序，调度器系统可被配置为管理迀移脚本排序。尽 管许多功能可被并行地执行，但一些脚本可依赖于其它脚本，因此需要有序的串行处理。例 如，仅能在已接收到所有目标数据库信息之后执行用于将要由目标数据库执行的数据库的 索引产生。然而，可独立于第二数据库的复制和索引产生执行第一数据库的复制和索引产 生。
[0094] 调度器系统可被配置为识别利用迀移脚本复制数据库对象的