Migrating Essbase cube across versions via file system

Question

A large BSO cube has been taking much longer to complete a 'calc all' in Essbase 11.1.2.2 than on Essbase 9.3.1 despite all Essbase.cfg, app and db settings being same (https://forums.oracle.com/thread/2599658).
As a last resort, I've tried the following-
1. Calc the cube on the 9.3.1 server.
2. Use EAS Migration Wizard to migrate the cube from the 9.3.1 server to the 11.1.2.2 server.
3. File system transfer of all ess*.ind and ess*.pag from 9.3.1\app\db folder to 11.1.2.2\app\db folder (at this point a retrieval from the 11.1.2.2 server does not yet return any data).
4. File system transfer of the dbname.esm file from 9.3.1\app\db folder to 11.1.2.2\app\db folder (at this point a retrieval from the 11.1.2.2 server returns an "unable to load database dbname" error and an "Invalid transaction status for block -- Please use the IBH Locate/Fix utilities to find/fix the problem" error).
5. File system transfer of the dbname.tct file from 9.3.1\app\db folder to 11.1.2.2\app\db folder (and voila! Essbase returns data from the 11.1.2.2 server and numbers match with the 9.3.1 sever).
This almost seems too good to be true. Can anyone think of any dangers of migrating apps this way? Has nothing changed in file formats between Essbase 9.x and 11.x? Won't not transferring the dbname.ind and dbname.db files cause any issues down the road? Thankfully we are soon moving to ASO for this large BSO cube, so this isn't a long term worry.

Answer 1

Freshly install the Essbase 11.1.2.2 on Window server 2008 r-2 with the recommended hardware specification. After Installation configure 11.1.2.2 with the DB/Schema
Take the all data back up of the essbase applications using script export or directly exporting from the cube.
Use the EAS Migration wizard to migrate the essbase applications
After the Migrating the applications successfully,reLoad all the data into cube.
For the 4th Point
IBH error generally caused when there is a mismatch in the index file and the PAG file while e executing the calculation script .Possible solutions are available
The recommended procedure is:
a)Disable all logins.
alter application sample disable connects;
b)Forcibly log off all users.
alter system logout session on database sample.basic;
c)Run the MaxL statement to get invalid block header information.
alter database sample.basic validate data to local logfile 'invalid_blocks';
d)Repair invalid block headers
alter database sample.basic repair invalid_block_headers;
Thanks,
Sreekumar Hariharan