新的 机器，它将工作吗?"。不幸的是，回答这个问题需要大量的分析和工作。配置评估、性能评估 以及其它系统评估可能花费长达30天。客户可能具有上百或者甚至上千的数据库，因此，确 定哪些数据库可以被迀移到新的系统很快会成为非常困难的任务。
[0056] 本文所描述的实施例可以利用现有的企业管理器来一致地和/或定期地对客户数 据库系统进行监视和建模。可以利用企业管理器代理来收集和监视与客户的数据库相关联 的建模数据。这种信息可以通过驻留在客户的企业管理器系统上的网关上传到云服务。云 服务然后可以对由代理记录的数据执行计算和分析，以便为具体的迀移方案提供建议，例 如数据库A和数据库B是否能够被转移到新的系统。此外，可以向工程师提供与数据库迀移 相关的其它分析，诸如安全性考虑、数据完整性考虑、数据关键性考虑等等。
[0057] 图3示出了根据一种实施例的、用于实现数据库建模和分析服务的体系架构的示 图。建模和分析服务可以被设计为帮助客户及其业务团队来执行，例如工作负载映射练习， 以在不降低其现有能力的情况下实现对其目标迀移环境最高效和最经济有效的使用。建模 和分析服务可以利用客户现有的数据库资产作为输入来执行。例如，可以使用客户IT系统 302。客户IT系统302可以包括诸如开发、测试和生产环境的多种环境、数据库等等。在许多 情况下，在客户IT系统302中的数据库可能用不再被认为是先进的传统硬件实现或者在不 再作为平台或作为当前支持的软件版本被支持的系统中实现。
[0058]在一些实施例中，建模和分析服务可以被设计为主动的，因为它在数据库整合过 程的评估阶段期间被执行。可以使用建模和分析服务的结果来计划实际的数据库整合和迀 移步骤。例如，建模和分析服务可以在计划实际的数据库整合之前分析开发、测试和/或生 产系统。这种抢占式服务的一个主要优点是对基于行为、配置和/或输出将类似系统分组的 数据库方案进行建模和调整大小的能力。类似系统的分组可以根据如由客户识别的一组最 佳实践来完成。通过在实际的数据库整合过程之前执行这种分析，该评估阶段可以极大地 降低解决迀移问题导致的成本上升风险。
[0059]为了收集性能数据，代理308可以被部署在客户IT系统302上。例如，可以安装企业 管理器代理作为响应于检测到的事件采集信息的收集器，事件诸如数据库变成离线。这些 代理可以和被配置为向企业管理器314提供性能数据。收集到的数据可以被选择，以便为以 下描述的建模过程提供相关的数据库度量。例如，代理308可以专注于为选择的数据库捕获 生产工作负载，使得这些数据库可以被映射到更新的、更高效的平台上的目的地环境。
[0060]代理308可以将从客户IT系统302收集到的性能数据发送到网关304。在一些实施 例中，收集到的数据可以被发送到驻留在网关内的企业管理器云控制314。网关304可以被 配置为作为用于管理内部用户和/或应用资产如何被暴露给外部系统的控制点在客户系统 上操作。网关304可以提供访问安全性、数据安全性、审核和监视能力、以及与外部系统的集 成。在一种实施例中，网关304可以提供对提供者数据中心318和位于远离客户IT系统302的 云数据中心306的访问。云数据中心306可以通过由客户IT系统302使用的数据库和软件的 提供者来操作。
[0061] 网关304可以包括被配置为与云数据中心306结合操作的一类企业管理器314。云 工具模块312可以与企业管理器314-起操作，以提取和/或修改已经被企业管理器314在正 常操作期间收集的数据。由云工具模块312收集和/或修改的数据可以被选为与建模数据库 操作相关。这些数据然后可以提供给云数据中心306以供处理。在一些实施例中，网关304可 以以对客户透明的方式操作。供在数据库建模中使用的数据可以在正常操作期间在后台进 行收集并且可以被存储在提供者数据中心318处。
[0062] 图4示出了根据一些实施例的、用于对数据库的迀移进行建模的数据存储体系架 构的框图。如上所述，网关404可以在企业管理器中操作，以记录在正常操作期间与数据库 迀移和建模相关的数据。网关404可以包括被配置为存储与一组传统系统402的性能相关联 的信息的数据存储库414。传统系统402可能包括利用关系数据库管理系统(RDBMS)操作的 大量数据库。安装在传统系统402上的代理可以向网关404提供存储在数据存储库414中的 信息。在一些实施例中，数据存储库414可以在传统系统402的正常操作期间连续地用数据 进行填充。
[0063]特殊的整合引擎420可以从数据存储库414中的各种表中读取信息，各种表诸如管 理表、垃圾收集表、读/写日志等等。注意，这允许整合引擎422始终具有历史性能数据。因 此，当客户创建迀移方案时，迀移方案可以利用历史数据来被建模，而不需要为了完成分析 而收集将来的数据。例如，从"MGMT$"表中检索的数据可以经由整合引擎420被处理 (crunch)，并且结果可以被存储在422中，以准备好运回到提供者数据中心418。
[0064]整合引擎420可以从现有的表中提取数据并且将数据拟合到新的数据模型中。在 一些实施例中，随着企业管理器填充数据存储库414中的表，整合引擎420可以检测到变化 并且自动地使用该数据来填充新的数据模型。在一些实施例中，整合引擎420可以代之以在 将数据从旧格式转换到新的数据模型中之前等待，直到迀移方案被用户提供。新的数据模 型可以包括来自数据存储库414内的许多不同数据库的数据。图5示出了根据一些实施例的 一种示例性数据模型的示图500。本领域技术人员将理解，根据每个特定实现的需要可以使 用许多不同类型的数据模型。这种特定的数据模型包括专门用于对迀移方案进行建模的条 目，包括方案定义、候选目标系统参数和方案结果。这个数据模型可以按需为特定实施例进 行扩展和/或更改。因此，将理解到，示图500仅仅是示例性的，并且不是要进行限制。
[0065]图6示出了门户600的结构的框图。门户600可以基于分层体系架构。该门户可以被 分为四层:界面层636、服务层638、公共组件层640和支持储存库层642。这些层可以负责处 理服务和客户信息以及呈现和编制（orchestration)在服务器端的服务。可以使用这些层 与在客户系统上驻留和操作的网关对接和通信，使远程管理员能够与数据和网关交互以交 付服务，和/或使客户能够经由门户接收服务以及与服务提供者合作。
[0066]门户的后台可以包括支持储存库层642。可以使用支持储存库层642来利用各种数 据源丰富和/或交付服务。支持储存库层642可以包括储存库或对储存库的访问，其中储存 库可以包括配置、补丁、SR信息和数据等。
[0067]门户的后台还可以包括公共组件层640。层640的元件可以包括在部署期间和部署 之后用于服务支持的组件。元件可以包括向门户和服务提供认证和授权以及安全性的账户 管理模块616。客户可以被提供对门户的访问，并且也可以被授予对一个或多个服务的访 问/权限。层640还可以包括文档模块618,该文档模块618提供用于利用门户管理文档的方 法。此外，层640包括用于管理在服务的交付中使用的各种请求和步骤的服务请求模块。可 以使用配置管理模块622来管理与客户和服务约定相关联的配置。可以使用商业智能模块 624来识别高价值信息。
[0068]门户600的服务层638可以包括每个服务所需的特定模块和功能。每种类型的服务 可以包括已定义的工作流程和逻辑、安全性等。每种类型的服务可以包括用于管理特定工 作流程、逻辑和该服务的其它要求的模块。用于建模604、迀移606、负载测试608、基准测试 610、云成像612、监视614的模块可以在层638中实现。
[0069]最后，门户600的界面层636提供了诸如图形用户界面602的、可以被客户、服务提 供者和/或管理员使用的界面。界面层表示服务的呈现层。界面层636的用户界面602可以是 响应式网页设计，并且因此可以在多种设备上工作(例如：台式机、智能电话、平板电脑）。门 户的UI可以提供对服务和/或内容的公共服务界面。该UI可以在一致的界面中利用相似的 外观和感觉表示和呈现可用的、安装的、活动的等支持云服务。可以使用公共用户界面组 件。导航方法可以基于利用下拉菜单获取更多细节的丰富的服务汇总报告。服务可以与客 户配置紧紧地耦合。服务交付(分析、验证、报告)所需的技术数据可以被自动地收集。可以 广泛地使用分析来通过创建"易用"的表盘和报告以帮助减少信息过载。
[0070] 图7示出了根据一些实施例的、对多个数据库系统之间的预期数据库迀移进行建 模的方法的流程图700。该方法可以包括收集与第一数据库系统相关联的性能数据(702)。 第一数据库系统可以由多个单独的数据库组成。第一数据库系统可以由数据库的提供者的 客户来操作，并且第一数据库系统也可以被称为传统系统。第一数据库系统可以包括多个 单独的数据库、关系数据库管理系统(RDMS)和数据库系统。
[0071] 性能数据可以由安装在第一数据库系统上的数据库代理来收集。数据库代理可以 被配置为收集与数据库迀移相关的性能数据。性能数据可以包括使用数据库、数据库的版 本、在数据库内存储的信息类型、对数据库的读/写的次数、存储器使用量、CPU使用量、数据 库的大小、所使用的加密方法、所使用的压缩方法、安全性要求、用户分组、标识数据库的关 键性的状态、可接受的宕机时间和/或其它类似类型的信息的不同部分。在一些实施例中， 术语性能数据也可以包括与数据库行为和/或配置相关的数据。
[0072] 性能数据可以在第一数据库系统的正常操作过程中被收集。性能数据可以由企业 管理器收集并且被本地存储在属于客户的数据存储库中。在一些实施例中，性能数据可以 从由企业管理器使用的现有的表中进行收集。这些现有的表可以利用与第一数据库系统的 关系数据库管理器兼容的第一模式或数据格式。在一些实施例中，性能数据可以被变换为 用于对数据库迀移方案进行建模的第二模式或格式。
[0073] 性能数据收集可以由在客户系统上透明地操作的网关来执行。网关可以通过互联 网通信地耦合到位于远程的、地理上远离第一数据库系统的基于云的服务。在一些实施例 中，网关可以定期地将性能数据传送到该基于云的服务，以用于性能分析和诊断目的。
[0074] 性能数据可以在一段时间间隔内进行收集，然后随着它变得过时（stale)而被丢 弃。例如，性能数据可以被收集大约1周、2周、3周、30天、60天、90天等的时间间隔。随着性能 数据变得过时，它可以在数据库中被标记为删除或垃圾收集和/或被更近的新的性能数据 替换。
[0075] 该方法也可以包括接收对要迀移到第二数据库系统的一组数据库的选择(704)。 第二个数据库系统可以由客户选择作为用于数据库迀移的目标。例如，第一数据库系统或 传统系统可能接近其使用寿命的终点。客户可能希望将存储在第一数据库系统中的数据迀 移到更先进的新的数据库系统中。一些实施例会允许客户根据可用的