eas迁移 oracle数据,Oracle Hyperion 11.1.2.1 迁移特性与问题

Oracle Hyperion 11.1.2.1包含可以简化移植的新工具，它们在很多情况下能够减少操作步骤。然而，还是有诸如Essbase Studio的一些问题必须在以后的版本中进行修复。

在亲身使用Oracle Hyperion 11.1.2.1 版本几个星期之后，我可以确定地说总体上Oracle团队这次开发出了很好的产品。Hyperion Financial Management (HFM)、Planning、Essbase、Shared Services和Financial Reports都可以顺利地移植。到目前为止，我还没有尝试过移植任何边缘产品，如Interactive Reporting，但是基本的组件肯定是可以运行的。

新的Oracle Hyperion迁移特性

11.1.2.1版本 让人很吃惊的是新工具hssmigrate。在之前的版本中，CSSImportExport确实支持Shared Services安全性移植。通过使用这个工具，您必须从Shared Services上导出安全性，创建一个XML或CSV文件，手动更新文件，然后使用这个文件将安全性导入到目标环境。这听起来很容易，但是该工具是基于Java的，这意味着它会区分大小写。

例如，在开发和生产环境，用户必须从开发环境导出安全性，创建XML或CSV文件，将它转换成生产环境，手动修改文件，以便反映产品和服务器名称，然后从该文件导入安全性。这是一个耗费人力的过程。

此外，工具在区分大小写方面的功能还可能会导致出现棘手的问题。由于在命名规范方面并没有任何针对外部供应商的限制，因此人们都会采用各不同的名称。但是，没有任何限制可以保证外部供应商的源(开发)环境命名与目标(生产)环境是匹配的。要成功实现迁移，外部供应商命名必须是匹配的。

例如，如果您想将安全性从开发环境迁移到生产环境。供应商在开发环境的命名是TOPDOWN(全部大写)。要成功实现迁移，您必须知道供应商在开发时的命名，然后可以使用准确的拼写和大小写在生产环境中相应地创建相同的供应商命名。问题是往往有很多人会在开发环境和生产环境中进行安装。因此，供应商命名最终会无法同步。这时，您就无法完成迁移了。唯一的解决方案是改正其中一个环境的供应商命名。

Oracle意识到了这个问题，并且使用hssmigrate工具来解决这个问题。这个工具会在源环境的Shared Services机器上创建一个hssmigratedata.zip文件。然后，您可以将hssmigratedata.zip文件传输到目标环境的Shared Services机器，启动配置程序，选择Import Data from Earlier Release，这样就可以解决问题。新工具并不受供应商命名的影响。在任何情况下，它都可以将安全性导入到现有外部提供者中。这可以节省大量的时间和精力，同时解决前面提到的服务器命名和产品后缀等问题。

另外一个有用的新特性是Planning application migration向导。迁移一个Planning application的准备步骤仍然是相同的。然而，执行迁移的界面发生了改变。过去的Planning login页面使用的是一个按钮，现在的Planning Administration页面是一个更美观且更直观的向导。不同之处是您必须通过Workspace 进入Planning Administration页面。一旦打开了Planning Administration页面，您就可以选择Migration Wizard选项卡，然后选择您想要迁移的应用程序。

目前，每个人都是通过Workspace登录的，因此通过Planning Web界面查找Migrate按钮的方法并不是很直观。这个过程并没有增加新功能;在11.1.2.1版本中，您可以点击Migration Wizard选项卡，然后选择应用程序，接着安装向导便会对它进行升级。新的过程会更加的直观。

Oracle Hyperion 迁移的缺点

在 11.1.2.1 版本中支持不太好的是 Essbase Studio迁移。虽然安装指南提供详细的操作步骤，但是它是无法生效的，而且我第一次尝试迁移也没有成功完成。

Essbase应用程序迁移也会有一个版本控制问题。传统的方法是通过 Essbase Administration Services (EAS)迁移Essbase 应用程序。它非常简单，就是先登录，然后连接到源Essbase 服务器和目标Essbase 服务器上。然后，您可以启动迁移向导，指定源Essbase 应用程序，在目标Essbase 服务器上创建Essbase 应用程序，只需几个步骤，应用程序就完成了迁移。

在11.1.2.1中，虽然用这个过程来处理Block Storage Option (BSO)数据库的方法是相同的，但是它在处理Aggregate Storage Option (ASO)数据库时抛出一个错误信息。但是，实际上它确实迁移了源数据，而且ASO数据库也成功迁移了。这可以通过执行一个迁移后的高级测试进行确认。但是，我并没有进行过低级测试，因此我无法证明迁移是否完成了。关于Essbase 应用程序迁移的另外一个问题是文档化过程非常冗长。在完成了所有这些步骤之后，您仍然必须将源Essbase服务器的文件转移到目标Essbase服务器上。

结语

Oracle Hyperion的未来版本必须修复Essbase Studio迁移的问题。这意味着，由于它是一个非常新的应用程序，因此还没有很多人开始使用Essbase Studio。虽然之前的版本存在很多缺陷，而且无法完成迁移，但是由于用户群较小，修复这个问题现在可能并不是Oracle优先解决的问题。另外一个很好的修复是ASO数据库问题。即使有这样两个问题，整个 11.1.2.1 迁移过程仍然简单很多。