1)     Objectives

This document is to describe the methodology employed and process involved in the recovery of the Hyperion system currently operated in the company.This document will be updated and maintained by IT department, and posted in the Hyperion Planning Implementation Database for access by project members as well as the end-users.

2)     Applicability

This applies to the following server components of the Hyperion applications.

o   Application and Web Server (Application)

o   Reports Server  (Application)

o   Essbase Server  (Transaction Data)

o   Oracle Server (Application Configuration/Reports Definition Data)

These servers are located in the computer room controlled and managed by IT Department.

3)     Responsibility

IT department is responsible for the managed operation of the application, which involves systems installation, systems upgrade, backup, recovery, and technical infrastructure support while the systems owner is responsible for the maintenance of the models/reports built on the application.

Primary Support              Secondary Support

IT    Department:            ….

Application Owner:        ….

4)     Processes

4.1)  Normal Recovery

This refers to the situation where a server is corrupted due to hard disk failure and requires re-built, or alternatively, the database is corrupted and requires recovery. Advanced approval is required from the site IT Manager prior to the recovery is executed.

4.1.1 Application & Web Server (Hy-web) & Reports Server (Hy-rpt)

1. Get the hardware ready for restore.
2. Identify and restore the latest system backup/Ghost image of Hy-web & Hy-rpt’s C: Drive.
3. Open the latest daily Hy-web & Hy-rpt’s ArcServe backup and restore all directories & files (i.e. Overwrite all existing directories and files).
4. Logon to the Planning, Analyzer, and Reports on Web to test out the access and the data availability.

Essbase (Hy-Ess)

The following is for a complete rebuilt when the hard disk is totally damaged. Should only the database restore is required; the last step is needed to be executed.

1. Get the hardware ready for restore
2. Re-install Sun Solaris 8
3. Re-create a user called “essbase” with home directory set to /essbase
4. Restore root’s profile
5. Restore the crontab file: /var/spool/cron/crontabs/root.
6. Restore the latest daily backup (please refer to the procedures posted under “Essbase Data Restoration” in the Hyperion Planning Implementation Database). Logon to Essbase to do a sample checking of the reports in order to verify data is restored properly.

Oracle

If a complete rebuilt of the Hyperion instance is required, go to step e directly.

1. Get the hardware ready for restore
2. Install Oracle 8.1.6. rc2 Enterprise Server
3. Create an instance called “hysi”
4. Locate the latest daily Oracle backup.
5. Run the command in DOS prompt: IMP system/manager FULL=Y IGNORE=Y FILE=<exported file> where currently, the name of the export file is called “daily_hysl_fullexp.dmp”.
6. Logon to the Planning and do a sample checking for dimension, scenarios.
7. Logon to Analyzer and Reports to retrieve one of the reports to see whether the data is displayed properly.

4.2)  Disaster Recovery

Disaster recovery refers to a situation where all of the server hardware is completely lost or damaged. Changeover to a temporary application infrastructure is required in order to provide minimal survival services to the user community. It is intended not to cover the entire user community, but 50% only. The fall back period is estimated to be 4-8 weeks prior to the new production hardware is acquired and set-up.

4.2.1        Backup Application Infrastructure

During the fall back period, it is planned to use a single Intel PC as a temporary machine with all products/system components installed which includes web/application, Analyzer, Report, Essbase, and Oracle. The machine should satisfy the following minimum configuration in order not to have significant performance degrade.

–          CPU of at least 2GHz,

–          At least 4G RAM,

–          At least a 100G hard disk

–          10/100M Ethernet Connection

This machine will be located in the IT area at the another Office, and it is controlled, and reserved by IT for such purpose.

4.2.2.       Recovery SLA

* Concurrent event

4.2.3        Server Recovery

Procedures to recover servers as follow

1. Install Windows 2000 sp3 in an Intel based machine.
2. Install Hyperion Analyzer Server, JRUN 4.0, Hyperion Planner, JRE 1.3, and Hyperion Report client in the machine used in Step 1.
3. Install Essbase Server, create the MDS database, restore the outline files from the backup tape, and then perform full load of the Mds Application to the MDS database in the machine used in Step 1.
4. Install Oracle 8.1.6 rc2 Enterprise Server, create a new Oracle instance called HYSL in Step 1, and then perform full import using the daily backup dump files stored in backup tape.

4.2.4        Network Connection

1. Configure the new machine in Step 1 so that both Hyperion Analyzer, and Hyperion Planner are pointing to the Essbase database & Oracle database created in step 3 & 4.

4.2.5        Client Recovery

1. Reinstall all the necessary thick client in each user’s PC (For those user that use thin client to access Hyperion, there is no need to perform reinstallation.

4.2.6       People Organization

During the Disaster Recovery, a project team is set-up comprising of the Application owner, site IT Manager, and the IT support staff. The Application Owner will assume the lead for this process and will co-ordinate and communicate with the user community for any systems arrangement while IT will be responsible to make sure the backup infrastructure is established, data is restored and system connection is normal.

4.2.7        Rehearsal Run

A yearly rehearsal run should be executed to ensure the above stated process is working properly. The results of the rehearsal will be documented and filed for reference.

1)     Objectives

This document is to describe the methodology employed and process involved in the backup of the Hyperion system currently operated in the company. This document will be updated and maintained by IT department for access by project members as well as the end-users. Read More

1)     Objectives

This document is to describe the user accounts administration process for the Hyperion Planning/Analyzer applications currently operated in the company. This document will be updated and maintained by IT department as required.

2)     Applicability

This procedure is applicable for all employees who wish to apply for an access to the Hyperion Planning system located in the company.

3)     Responsibility

4)     User Security Profile

Hyperion uses the Windows Logon ID as the ID for logging into various components of the systems including:

o   Planning,

o   Reports, and

o   Analyzer

Each of the components will have its own access control, and security level in respect to the functionality and the data held on the system.

A user security profile is a set of pre-defined access rights attempting to fulfill certain needs of an individual. Should a requester requires access falling out of these pre-defined access rights, he or should has to contact the Systems Administrator to formulate a custom profile.  

4.1 Planning/Reports

4.2 Analyzer

5)    Processes

5.1)      Add/Change User Accounts

5.1.1    Requester obtains a copy of the User Accounts Maintenance Form from the Systems Administrator. Fill in the following information and submit it to the Systems Owner

o   Personal Details

o   Application

o   Data Base

o   Selected Security Profile

o   Reasons/business justification

5.1.2    On receipt, the Systems Owner reviews the requested profile, and the justification, and approves/disapproves the request.

5.1.3    Approved request should be forwarded to the systems administrator for processing. Any disapproved request should be sent back to the requester stating the reasons of disapproval.

5.1.4    Systems Administrator, on receipt of the approved request, use the admin id and password to logon to the application and make the changes

5.1.5        Print out the screen where it shows the new setting or changes

5.1.6        File the screen print together with the request form.

5.1.7    Email the requester and copy to the systems owner of the completion of the request together with the login information/instructions.

5.2       Delete user Accounts

5.2.1    Once a month, the systems administrator should check with the HRM of each site as to whether any active users have left the organization.

If HR confirms a user as “left”, the systems administrator complete the Hyperion User Maintenance Form and send to the system owner via email.

On receipt of the approval from the systems owner, the systems administrator removes the accounts from all systems components and informs the systems owner of completion. File all of the communications.

5.2.2    At times, Site HR or Site IT may inform the Systems Administrator of the employee termination, same process as described, should be followed.

Appendices A

Hyperion User Accounts Maintenance Form

(A)      Requester Information                                     Action: Add/Change/Delete

(B)      Access Rights

Planning/Reports

Please         circle the selection.

Analyzer

Please circle the selection.

(C)      Approval Process