Hybrid analysis-enabled metaoutlines are not migrated.
Unicode-enabled metaoutlines are not migrated.
All tables listed in your metaoutline must be present in the source database.
The data types in the Integration Services model must match the data types in the source database. Essbase Studio verifies the data types, and if there is a mismatch, the migration will fail.
Metaoutlines with multiple ODBC DSNs are not migrated.
Metaoutlines with drill-through defined on recursive hierarchies are supported. After migration, those recursive hierarchy drill-through definitions can be used in Essbase Studio.
Metaoutlines that have drill-through defined to alternate data sources can be migrated, but alternate-data sources drill-through functionality is not supported in Essbase Studio.
Essbase Studio uses the bindings of dimension elements to create unique or duplicate outlines. By default, however, the migration studio migrates all metaoutlines as unique. To create duplicate outlines in Essbase Studio, you must modify the key bindings in the dimension elements by providing a key column. The data type of the key column must match the data type of the dimension element.
If a data source column is bound to a level-0 member set, and contains both base members and shared members, it is possible that the data aggregated in the Essbase Studio-generated data load SQL for the specific base members (which have shared members in the same dimension) will be augmented at times, depending on the number of shared members. In this case, Oracle recommends that users define their own custom data load SQL as described in Overriding Standard Data Load SQL. This behavior is true both for Essbase models created from metaoutlines imported from Integration Services, and for Essbase models created from the beginning in Essbase Studio.
For example, using the TBC sample, the data aggregated for 100-10 in the standard data load SQL is twice as much as it should be (doubled) because 100-10 has shared members under “Diet”. To get the correct aggregated data, users can select the Use Custom SQL for data load option, and manually add one more “group by” column, “Family”, to the custom data load SQL.
There are differences in attribute member handling between Integration Services and Essbase Studio.
Integration Server adds all attribute members of an attribute dimension, whether or not the attribute association relationship exists in the corresponding base dimension. To do this,Integration Server produces three types of rules files during member load: one for the base dimension, one for the attribute dimension, and one for the attribute associations.
Essbase Studio creates attribute members only when the corresponding attribute association relationships exist in the base dimension. During cube deployment, it produces just two rules files: one for the base dimension, and one for attribute members and their associations. This helps to speed up cube deployment, but those attribute members without a base member association are dropped in the process.
For example, an outline created by Integration Services using the TBC sample metaoutline has the attribute dimension “Population” with these members:
Small: 3000000, 6000000 Medium: 900000, 1200000, 1500000, 1800000 Large: 21000000, 24000000, 27000000, 30000000, 33000000
However, if the TBC metaoutline is migrated to the Essbase Studio catalog and deployed to Essbase Server, the new outline will have the attribute dimension “Population” with these members:
Small: 3000000, 6000000 Medium: 900000, 1200000, 1500000 Large: 21000000, 33000000
This is because there are no states with the population values 18000000, 24000000, 27000000, or 30000000.
Note that if the attribute dimension is built in a recursive way (from a parent-child table), Essbase Studio will produce three rules files—a for the base dimension, the attribute dimension, and an attribute association rules file—just as is done in Integration Services. As a result, the attribute dimension will have all members regardless of association.