Hyperion Report System Migration

Migration involves migrating information from the source system to Oracle's Hyperion® Shared Services and the Oracle's Hyperion Reporting and Analysis Repository.
Migration involves: users, groups, roles, and repository content. The source systems include:
. Brio Portal 7.0.5 or later

. BrioONE (Brio Portal 7.0.5 or later and OnDemand Server 6.6.4 or later)
. Brio Intelligence Server (OnDemand Server and Broadcast Server 6.6.4 or later)
. Hyperion Analyzer 6.5, 7.0.1, 7.2, or 7.2.1
. Hyperion Performance Suite 8.x
. Hyperion Reports 7.0.x or 7.2
-----------------------------------------------
Prerequisites for Using the Migration Utility:
. Administrator permission on both source and target system
. Disable the Harvester service.
. If your target system is Oracle, set the NLS_LENGTH_SEMANTICS parameter to char.
  nls_length_semantics=char
. For systems using X-Windows on UNIX, start vncserver so that it uses (at a minimum) HiColor.
  For example, vncserver -depth 15 or vncserver -depth 16.
. If the source is Brio Portal or Hyperion Performance Suite 8: turn off the services on the source and target systems
. If the source is Brio Intelligence: 1. Turn off the services on the source system. (The services on the target system should stay running.). 2. For UNIX systems, add the BQ_FONT_PATH to the services.sh file located in the /BrioPlatform/bin directory and restart the services. The BQ_FONT_PATH environment variable is needed by the Interactive Reporting Service on the target system to ensure that BQY jobs and documents are rendered properly in the new environment. 
------------------------------------------------------------
Other Considerations:
. Special Symbols in Users and Groups

. Invalid Characters in Workspace
. SmartCuts - You need reconfigure the SmartCut in source so that the characters are valid in new Hyperion Workspace.
------------------------------------------------------------
Run Migration Wizard and follow the steps:


About Migrating from Brio Portal, steps:
● Defining the Location of the Portal Repository Database
● Identifying Portal Groups with Circular References
● Selecting the Objects to Migrate
● Defining Reporting and Analysis Repository Database Information
● Defining the Location of the Reporting and Analysis Repository Database
● Defining the Location of the Shared Services Server
● Defining User/Group Names, Descriptions and Passwords
● Reviewing User Names
● Reviewing Group Names
● Mapping Hosts
● Defining Additional Migration Options
● Running the Migration
-----------------------------------------------
Other options:
1. LDAP and Shared Service backup
2. Export the security file to external file and modification and load back
3. Source and target run in different computer servers.
4. The migration should not affect the original content in source server normally
5. Migration to a test server first before production migration
6. UNIT test include: 1). general functionality test, such as: can we see the report from workspace? 2). User security test 3). Repository object test, such as the report job, web folder 4).Report modification because of version difference.

MaxL Automation Backup/Recovery

This paper is for the auto backup and recovery process for LDAP Shared Service and Essbase database.
1. In the essbase.cfg file, add:
    SPLITARCHIVEFILE TRUE
    TRANSACTIONLOGDATALOADARCHIVE SERVER_CLIENT

The 1st command will split big archive file into smaller one automatically. The 2nd command will enable the transaction logging.

2.  backupLDAP.bat
The code inside:
@echo off
REM Backup LDAP with HOTBackup
c:\Hyperion\products\Foundation\server\scripts\backup.bat C:\Hyperion\backup\HSS_backup

3. RecoveryLDAP.bat, the code inside:
@echo off

REM Backup LDAP with HOTBackup
c:\Hyperion\products\Foundation\server\scripts\recover.bat C:\Hyperion\backup\HSS_backup

4. BackupEssbaseMaxL.msh
spool on to 'c:\Hyperion\Logs\EssbaseArchive.log';

login $1 $2 on $3;
alter database Sample.Basic force archive to file 'C:\Hyperion\backup\SampleBasic';
alter database Demo.Basic force archive to file 'c:\Hyperion\backup\DemoBasic';
spool off;

5. backupEssbaseBSO.bat
echo off
REM Backup BSO Essbase
set uid=admin
set pwd=password
set svr=bobpc
essmsh "C:\Hyperion\auto\BackupEssbaseMaxL.msh" %uid% %pwd% %svr% %dt% %tm%
ren C:\Hyperion\backup\SampleBasic SampleBasic%date:~4,2%-%date:~7,2%-%date:~10%.arc
ren C:\Hyperion\backup\DemoBasic DemoBasic%date:~4,2%-%date:~7,2%-%date:~10%.arc
The idea is backup with general name, and use bat script rename the backup file with time stamp.

6. RecoveryEssbaseMaxL.msh
spool on to 'c:\Hyperion\Logs\EssbaseArchive.log';

alter database Sample.Basic force restore from file 'C:\Hyperion\backup\SampleBasic.arc';
alter database Demo.Basic force restore from file 'c:\Hyperion\backup\DemoBasic.arc';
alter database Sample.Basic replay transactions using sequence_id_range 2 to 2;
alter database Demo.Basic replay transactions using sequence_id_range 2 to 2;
spool off;

Please select the sequence id range by query
query database Sample.Basic list transactions;



7. RecoveryEssbaseBSO.bat
@echo off
REM Recovery BSO Essbase
essmsh "C:\Hyperion\auto\RecoveryEssbaseMaxL.msh"

The bat file for backup can be scheduled to run daily using Windows Scheduler.

Cold backup - LDAP & Shared Service

1 Stop OpenLDAP and Shared Services.
2 Back up the Shared Services directory from the file system.Shared Services files are in HYPERION_HOME/deployments and HYPERION_HOME/products/Foundation.
3 Optional:
* Windows—Back up these Windows registry entries using REGEDIT and export:
HKLM/SOFTWARE/OPENLDAP
HKLM/SOFTWARE/Hyperion Solutions
* UNIX—Back up these items:
.hyperion.* files in the home directory of the user name used for configuring the
product user profile (.profile or equivalent) file for the user name used for configuring the product
4 Shut down the Shared Services relational database and perform a cold backup using RDBMS tools.

To recover Shared Services from a cold backup:
1 Restore the OS.
2 Using Oracle Hyperion Enterprise Performance Management System Installer, Fusion Edition, install Shared Services binaries. Note: Do not configure the installation.
OpenLDAP Services is created during installation.
3 Restore the Shared Services cold backup directory from the file system.
4 Restore the cold backup of the Shared Services relational database using database tools.
5 Optional: Restore the Windows registry entries from the cold backup.
6 (Windows) If Shared Services Web application service must be recreated, run HYPERION_HOME/deployments/AppServer/bin/installServiceSharedServices9.bat.
7 Start the OpenLDAP service and Oracle's Hyperion Shared Services.

Hot backup - LDAP & Shared Service

Steps:
1 Back up any related components, including Shared Services relational database and the OpenLDAP database. Note: The Shared Services relational database and the OpenLDAP database must be backed up at the same time. Ensure that the administrator does not register a product application or create an application group at backup time.
2. Run this command to create a hot backup of OpenLDAP:
Windows:
c:/Hyperion/products/Foundation/server/scripts/backup.bat HSS_backup
UNIX:
/home/username/Hyperion/products/Foundation/server/scripts/backup.sh /home/username/backups/HSS_backup

To recover Shared Services from a hot backup:
1 Stop OpenLDAP and Shared Services.
2 Recover the Shared Services relational database with RDBMS tools, using the backup with the same date as the OpenLDAP backup.
3 If you use OpenLDAP as Native Directory, recover the OpenLDAP database by running: Examples:
Windows noncatastrophic recovery—C:/Hyperion/products/Foundation/server/scripts/recover.bat c:/HSS_backup
UNIX catastrophic recovery—/home/username/Hyperion/products/Foundation/server/scripts/recover.sh /home/username/HSS_backup catRecovery
----------------------------------
Note: Physical backup and logical backup. A physical backup can be hot or cold:
*. Hot backup—Users can make changes to the database during a hot backup. Log files of changes made during the backup are saved, and the logged changes are applied to synchronize the database and the backup copy. A hot backup is used when a full backup is needed and the service level does not allow system downtime for a cold backup.
*. Cold backup—Users cannot make changes to the database during a cold backup, so the database and the backup copy are always synchronized. Cold backup is used only when the service level allows for the required system downtime.
Note: A cold full physical backup is recommended.

* Full—Creates a copy of data that can include parts of a database such as the control file,transaction files (redo logs), archive files, and data files. This backup type protects data from application error and safeguards against unexpected loss by providing a way to restore original data. Perform this backup weekly, or biweekly, depending on how often your data changes. Making full backups cold, so that users cannot make changes during the backups, is recommended.
Note: The database must be in archive log mode for a full physical backup.

* Incremental—Captures only changes made after the last full physical backup. The files differ for databases, but the principle is that only transaction log files created since the last backup are archived. Incremental backup can be done hot, while the database is in use, but it slows database performance.
In addition to backups, consider the use of clustering or log shipping to secure database content.

Logical Backup
A logical backup copies data, but not physical files, from one location to another. A logical backup is used for moving or archiving a database, tables, or schemas and for verifying the structures in a database.