Download - Hyperion System 9 Financial Data Quality Management · The preface for the Hyperion System 9 Financial Data Quality Management (Hyperion FDM) contains the following topics: Purpose

Hyperion® System™ 9 Financial Data Quality Management™

DBA Guide

Hyperion FDM 9.2.0

© 2000 – 2006 - Hyperion Solutions Corporation. All rights reserved. “Hyperion,” the Hyperion logo and Hyperion’s product names are trademarks of Hyperion. No portion hereof may be reproduced or distributed in any form or by any means, electronic or mechanical, including photocopying, recording, or information storage and retrieval systems, for any purpose other than the licensee’s personal use, without the express written permission of Hyperion. This software is licensed according to the conditions set forth in your Hyperion software license agreement.

Hyperion, LedgerLink, Hyperion Enterprise, and Essbase are registered trademarks of Hyperion Solutions Corporation.

Hyperion Solutions, Hyperion Planning, and Hyperion Financial Management are trademarks of Hyperion Solutions Corporation.

Citrix is a registered trademark of Citrix Systems Inc.

Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates.

i

Table of ContentsPreface................................................................................................................................................................iii

PurPose............................................................................................................................................................................. iii

Audience............................................................................................................................................................................. iii

document.structure.......................................................................................................................................................... iii

Document conventions ....................................................................................................................................... iv

dAtAbAse.object.nAming.conventions................................................................................................................................. iv

moDule 1: comPonent integration moDel (cim) overview

comPonent integration moDel (cim) DefineD ....................................................................................................1-1

cim sPecification ..............................................................................................................................................1-1comPonent integration moDel (cim

r) rePository .............................................................................................1-2

cim.relAtionAl.rePository.logicAl.AreAs....................................................................................................................... 1-2cim.File.system.rePository............................................................................................................................................ 1-4exPlAnAtion.oF.subdirectory.usAge:............................................................................................................................... 1-4comPonent.integrAtion.model.(cim

te).trAnsFormAtion.engine......................................................................................... 1-5

comPonent.integrAtion.model.(cimPPi

).Push-Pull.integrAtion......................................................................................... 1-9

moDule 2: HyPerion fDm aPPlication settings tHat imPact Database server resources

Data loaD metHoD (bulk inserts vs. sQl insert statements)............................................................................2-1bulk.inserts.................................................................................................................................................................... 2-1sQl.insert.stAtements................................................................................................................................................... 2-1

transformation rules (cursors vs. Dml statements) ......................................................................................2-1comPlex.logic.or.derived.vAlue.rules........................................................................................................................... 2-1one-to-one,.rAnge,.or.WildcArd.rules.......................................................................................................................... 2-2

moDule 3: general setuP anD tuning oPtions

Data Partitioning ..............................................................................................................................................3-1PArtitioned.tAbles.deFined.............................................................................................................................................. 3-1dAtA.segment.count....................................................................................................................................................... 3-1chAnging.the.dAtA.segment.count.................................................................................................................................. 3-1

rDms Disk i/o oPtimization .............................................................................................................................3-1Work.AreA...................................................................................................................................................................... 3-1

moDule 4: sQl server setuP anD tuning oPtions

rDms Disk i/o oPtimization .............................................................................................................................4-1dAtA.segments.tAbles..................................................................................................................................................... 4-1Work.tAbles.And.Work.tAble.indexes............................................................................................................................. 4-4All.other.tAbles............................................................................................................................................................ 4-5

account Permissions .........................................................................................................................................4-6sQl server client software reQuirements .....................................................................................................4-6

moDule 5: oracle server setuP anD tuning oPtions

ii

recommenDations ..............................................................................................................................................5-1oracle Database instance .................................................................................................................................5-1reDo log buffer size .......................................................................................................................................5-1oPen cursors ...................................................................................................................................................5-1

cursor.shAring.............................................................................................................................................................. 5-2

rDms Disk i/o oPtimization .............................................................................................................................5-2redo.logs....................................................................................................................................................................... 5-2dAtA.segments.tAbles..................................................................................................................................................... 5-2Work.tAbles.And.Work.tAble.indexes............................................................................................................................. 5-6All.other.tAbles............................................................................................................................................................ 5-8

account Permissions .........................................................................................................................................5-9oracle client software reQuirements .............................................................................................................5-9

iii

PrefaceThe preface for the Hyperion System 9 Financial Data Quality Management (Hyperion FDM) contains the following topics:

PurposeAudienceDocument StructureDatabase Object Naming ConventionsAdditional Support

PurposeThis guide provides database administrators (DBAs) with the necessary information to keep a relational database management system performing optimally with Hyperion FDM’s standardized data marts.

AudienceThis guide is for DBA’s who are responsible for maintaining and/or monitoring the performance of a Hyperion FDM data mart. The DBA Guide is written for both Microsoft SQL Server and Oracle database administration professionals.

Document StructureThis document contains the following information:

Component Integration Model (CIM) OverviewIntroduces the processes used by the Component Integration Model (CIM) Engine.

Hyperion FDM Application Settings that Impact the Database ServerProvides a general overview of the tuning options embedded in Hyperion FDM’s data architecture.

General Setup and Tuning OptionsProvides a general overview of the tuning options embedded in Hyperion FDM’s data architecture.

SQL Server Specific Setup and Tuning OptionsProvides setup and tuning options specific to SQL Server.

Oracle Specific Setup and Tuning OptionsProvides setup and tuning options specific to Oracle.

•••••

iv

Hyperion FDM DBA Guide

Document ConventionsThe following table shows the conventions used in this document:

Item Meaning

Example Text Courier font is used for all VB / VB Script samples{Your Value} Brackets indicate that your value should be substituted

Table 1 - Conventions Used in This Document

Database Object Naming ConventionsThe following table lists the naming conventions used in this document’s examples:

Object Prefixest = Tablev = View

Table Purpose PrefixestBatch = Batch Processing TablestBhv = Location Workflow Behavior TablestControls = Internal Controls Framework Tablestctrl = Application Control TablestDim = Target System Dimension Caching TablestInt = Integration Block TablestLog = Logging TablestPOV = Point Of View Dimension TablestReport = Report Definition TablestSec = Security TablestStruct = Location Hierarchy TablestData = Non Segmented Data TablestDataSeg = Segmented (Partitioned) Data TablestDataMapSeg = Segmented (Partitioned) Historical Data Map TablestW = Temporary Work Tables

Table 2 - Naming Conventions

Module 1: CoMponent IntegratIon Model (CIM) overvIew

1-1

Module 1 — Component Integration Model (CIM) Overview

Component Integration Model (CIM) DefinedComponent Integration Model (CIM) is a conceptual framework that defines a modular approach to solving complex data integration tasks that are inherent in implementation of analytical applications.

CIM is based on the standardization of both processes and data structures. This approach allows complex integration tasks to be decomposed into manageable projects that meet the specific needs of the business analyst community while providing a scalable and reliable integration platform that can be integrated into any enterprise level data model.

CIM SpecificationThe CIM Specification is defined by the following data transformation management standards:

Standard Schema & File System Storage (CIM Repository)Integrated ETL capabilityIntegrated Data Cleansing CapabilityIntegrated Data Verification CapabilityIntegrated Data Transformation EngineIntegrated Task Scheduling ServiceCommon User InterfaceCommon Process WorkflowComplete Process Transparency and Audit AbilityCommon Set of Audit, Activity, and Performance Monitoring ReportsStandard Upward Data Certification ProcessPush Integration for Executing Calculation, Checking Data QualityPull Integration to allow Easy Data Consumption by other systems

Each independent CIM Repository must exhibit these common characteristics, which enables multiple CIM repositories to be combined and used as the building blocks of a virtual warehouse and/or easily linked into an existing data warehouse.

The CIM specification ensures that the data stored in each CIM Repository is of the highest possible quality and that the quality is measurable and sustainable. This makes a CIM Repository the perfect data source for analytical reporting solutions. Analytical processing is dependent on quality and completeness in order to be effective, the CIM specification ensures that both of these characteristics are inherent in each and every CIM Repository.

Business analyst and information technology professionals can now build independent integration solutions that meet the most detailed business process requirements without sacrificing maintainability and enterprise level data integration goals. Adhering to the CIM Specification results in a consistent data collection and transformation strategy across the entire organization, regardless of the business process or data flow involved in the transformation.

•••••••••••••

1-2


Component Integration Model (CIMr) RepositoryThe Hyperion CIM Repository contains a standard relational database schema and standard file system directory structure used for storing documents, reports, and application server working files. The CIM Repository is usually referred to as an Hyperion FDM application or data set.

There is usually a one-to-one relationship between the number of CIM Repositories (Hyperion FDM Applications) and the number target systems that need to be fed. This is necessitated by the fact that different target systems need different transformation rule sets, so for each different target system that needs to be loaded, a matching CIM Repository is usually created.

Whenever a new Hyperion FDM application is created three events occur.

1. Standard CIM Relational Repository is created

2. Standard CIM File System Directory Structure is created

3. These two repositories are related together and stored as a unit (Hyperion FDM Application) in an XML configuration file by the Hyperion FDM application manager.

The sections below provide a detailed look at the CIM Relational and File System repositories.

CIM Relational Repository Logical AreasThe CIM Repository’s relational schema can be broken down into three areas.

Work AreaData MartPull Area

Work AreaThe work area is used by the transformation engine to stage, cleanse, and transform the incoming source data. This area is used for temporary table creation and data cleansing purposes by the transformation engine. All of the objects created in this area are temporary in nature and they all begin with the prefix “tw” which indicates that they are working (Temporary) tables. The transformation engine manages the RDMS objects in this area by creating and dropping objects as needed. However, RDMS specific options are available to control which RDMS disk I/O resources are used by the transformation engine.

Data MartThe Data Mart contains the cleansed and transformed external data as well as the metadata, log data, push integration instruction set, and non-partition application data. The transformation engine posts data from the work area to the Data Mart following the data transformation process. Also, any recalculation or retransformation task are done by pulling the most recent data from the Data Mart into the work area, executing the transformation processes and then posting the refreshed data back to the Data Mart.

Pull AreaThe Pull Area of the CIM Repository contains a standard set of views that provide easy access to the cleansed data residing in the Data Mart. These views consist of “UNION ALL” statements to reassemble the partitioned tables into one logical table view.

In addition, an overall fact table view “vDataFact” provides simplified access to all incoming vales and transformed values in one place. These views provide a layer of insulation from the full CIM dimensional

•••

1-3


model by relating the most commonly used tables and there by creating a standardized consumption layer analytical applications.

The diagram below highlights the three logical areas of the CIM Relational Repository.

1-4


CIM File System RepositoryThe CIM Repository’s file system directory structure is used for Document Archiving, Custom Script Storage, Application Server Processing Space (inbox, outbox, templates, and logs) and Report format files. This directory structure must be created on a file server that can be accessed by all application servers in the application server cluster and for SQL Server the data server service may to read from the Inbox directory. The diagram below illustrates the standard CIM File System Directory Structure:

Explanation of Subdirectory Usage:Data — Used to store document archive files (.ua1, .ua2 extensions)

Scripts (Custom, Event, Import) — Used to store VB script files accessed by the transformation engine

Inbox — Used as an application server workspace for storing incoming files.

Archive Restore — Temporary storage containing incoming documents restored from the document archive location.Batches (OpenBatch) — Location used for file harvesting by the batch process component of the transformation engine. This folder will contain time stamped folders for with the contents of the OpenBatch folder for each file harvesting or batch processing task that executes.

Outbox — Used as an application server workspace for storing incoming files.

Archive Restore — Temporary storage containing outgoing documents restored from the document archive location.ExcelFiles — Temporary storage containing information exported to Microsoft Excel by an application server process.Logs — Temporary storage containing processing and error log files created by an application server process.Templates — Storage location for Microsoft Excel or other document templates that users may need to download.

Reports — Storage location for report format files.

1-5


Component Integration Model (CIMte) Transformation EngineThis section introduces Hyperion FDM’s data transformation engine and how it uses the relational schema to transform source system information through a standard workflow process.

CIM Transformation Engine DefinedThe Hyperion CIM Transformation Engine is comprehensive set of software libraries used for data staging, cleansing, and transformation. The CIM Transformation engine was built to deliver highly reliable analytical data sources that are delivered as standardized data marts. The CIM Transformation Engine is the nucleus of Hyperion’s component integration model. A published API guide and software development kit with examples is available for customers interested in extending the functionality of the transformation engine.

Transformation Process Resource ImpactThis section describes the server and disk I/O activities that occur for the three main transformation engine processes (data staging and cleansing tasks). Each process is described in a tabular format that highlights which servers are impacted from a processing perspective and which servers have the most disk I/O activity.

Table 1 — File Based Import (Bulk Insert)Table 2 — File Based Import (SQL Insert Statement)Table 3 — Database Level Integration (OLEDB / ADO Cursor)

1-6


These data transformation tasks are the most resource intensive tasks that are executed during the load process and are the most likely processes to cause resource bottlenecks. Understanding how these processes consume server resources will help focus your tuning efforts.

Sequence Task I/O Location Active Server

1 File Transferred from Web server to App server. Inbox Directory App Server

2

Transformation Engine pre-stages source file into a clean delimited text file for Bulk insert to RDMS. The clean file is then copied to the Inbox.

App Server Temp Directory & Inbox Directory

App Server

3 Source file is added to the document archive directory. Data Directory App Server

4 User specific temporary table is created for staging clean data.

Data Server (Work Area) Data Server

5

SQL Server Bulk Insert Statement is called to process bulk load file. Note: SQL Server service account must be able to read from the application Inbox directory.

InboxDirectory Data Server

Oracle SQL-Loader is launched on application server to process bulk load file.

InboxDirectory

App Server & Data Server

6 Indexes are added to the user specific temporary table.


7 Transformation Engine executes all calculations and data transformation rules.

Data Server (Work Area)

Data Server and/or App Server

8If new data is replacing existing data, a delete is executed against the live Data Mart data segment table.

Data Server (Data Mart) Data Server

9Clean and transformed user specific temporary table data is posted into the Data Marts data segment table.

Data Server (Work Area & Data Mart)

Data Server

10 User specific temporary table used for staging data is dropped.


Table 1: File Based Import (Bulk Insert)

1-7



1 File Transferred from Web server to App server. Inbox Directory App Server

2Transformation Engine pre-stages source file into a clean delimited text file for Bulk insert to RDMS. The clean file is then copied to the Inbox.

App Server Temp Directory & Inbox Directory

App Server

3 Source file is added to the document archive directory. Data Directory App Server

4 User specific temporary table is created for staging clean data.


5

Read clean delimited text file and run SQL Insert Statements in batches of 100 statements at a time. Note: Batch Size is stored as a system option and can be changed.

Inbox Directory Data Server










Data Server



Table 2: File Based Import (SQL Insert Statement)

1-8



1 User-specific temporary table is created for staging clean data.


2

Integration script is used to execute as SQL Select to populate an ADO Recordset with source system values. Cursor is iterated in order to write all source records to the User specific temporary table.



3 Integration script is added to the document archive directory for audit purposes. Data Directory App Server










Data Server



Table 3: Database Level Integration (OLEDB / ADO Cursor)

1-9


Component Integration Model (CIMppi) Push-Pull IntegrationThe Component Integration Model supports two types of integration techniques.

Push IntegrationPush integration is based on a sophisticated understanding of the target system and involves pushing the data into the target system, executing calculation, and verifying the quality of the information in the target system by extracting and evaluating both loaded and calculated values.

One important characteristic about CIM Push Integration is that the integration instruction set used for interacting with the target system is stored in the CIM Repository. The fact that the integration instruction set (Integration block) is stored in the CIM Relational Repository means that the CIM Transformation Engine can use any CIM Repository and use its integration instruction set to interact and remote control the target system.

Storing integration instruction sets in the relational repository is a key feature of the component integration model because it allows for very sophisticated integration to the target analytical system that is still loosely coupled from a programming dependency perspective.

Pull IntegrationPull integration is a more common type of integration that is implemented by allowing the target system to consume the data stored in the CIM Relational Repository. The standardized nature of the each CIM Relational Repository makes Pull Integration tasks extremely simple.

The standard data views defined in the Pull Area of the CIM Relational Repository simplify the process consuming data from a Hyperion FDM Data Mart. The transformed and cleansed data as well as data quality/workflow status information is readily accessible through these standard views. This means that when a target system needs to pull information from a CIM Repository it is very easy to determine where to find the data and what data is ready for consumption.

1-10


Module 2: HyperIon FdM applICatIon SettIngS tHat IMpaCt

databaSe Server reSourCeS

2-1

Module 2 — Hyperion FDM Application Settings that Impact DB Server Resources

Data Load Method (Bulk Inserts vs. SQL Insert State-ments)Each Location (Data Transformation Profile) that is setup in a CIM Repository can use one of two methods to insert data into the Work Area.

Bulk InsertsSelecting the Bulk Insert method allows the CIM Transformation Engine to engage the Bulk Insert utility of the RDMS being used. These utilities provide very fast insert capabilities but they may not be able to use existing disk space in the tables that they are writing or appending into. The CIM Transformation only uses Bulk Inserts to insert into Work Area temporary tables that are dropped later in the process, but the disk resource being used for the Work Area should be monitored overtime.

SQL Server Specific Considerations:The “Bulk Insert Statement” that the transformation engine issues to SQL Server is limited to one statement per processor on the data server. This means that in situations of high concurrency on a data server with a low processor count could result in queuing of Bulk Insert Requests. In this case, locations that do not import high data volumes could be switched to the SQL Insert Statement load method.Executing a “Bulk Insert Statement” against SQL Server requires that the SQL Server Service account be able to read data from the File System Repository.

Oracle-Specific ConsiderationsThe transformation engine uses the Oracle SQL-Loader utility to execute an “Unrecoverable Direct-Path” insert. This process will always insert data after the High-Water-Mark of the table. This may result in disk space consumption in the Work Area tablespace over time.

SQL Insert StatementsSelecting the SQL Insert Statement method allows the CIM Transformation Engine to create a batch of SQL Insert Statements. This process is not as efficient as bulk loading but generally provides better throughput due to smaller transaction sizes. This method will also create increase network activity between the CIM Engine application servers and the database server.

Transformation Rules (Cursors vs. DML Statements)The types of data transformation rules that are setup in a Hyperion FDM application have an impact on the distribution of the work load between the application server and data server.

Complex Logic or Derived Value Rules In general, transformation rules that require complex logic evaluation or on the fly derivation of the target value from the source value require the use of a client side cursor. These types of rules put a much greater burden on the application server and only place update responsibilities on the data server.

•

•

•

2-2


One-to-One, Range, or Wildcard Rules Transformation rules that can be formulated into a SQL update statement packed by the application and sent to the data server for processing. These types of rules are most widely used because of the inherent performance benefit.

Module 3: general Setup and tunIng optIonS

3-1

Module 3 — General Setup & Tuning Options

Data PartitioningEach CIM Relational repository uses table partitioning for data table throughput optimization. Since the primary duty of a CIM Relational repository is to process many batch insert processes at one time, table contention can become an issue. This issue is solved by horizontally partitioning the Data Mart tables that will be subjected to batch inserts and batch deletes.

Partitioned Tables DefinedPartitioned tables are assigned a prefix of “tDataSeg” or “tDataMapSeg” followed by a numeric value indicating the partition ID number. Each Location (Data Transformation Profile) that is setup in a CIM Relational Repository is assigned to a data segment which identifies which data segment tables the location will use within the Data Mart. The CIM Transformation Engine assigns data segment key values to locations when they are initially created.

Data Segment CountThe number of data segments can be adjusted by changing the configuration option titled “Total No. of Data Segments”. This value is initially set at 50 segments. The number 50 was found to be optimal based on stress testing results for 500 concurrent data loads of 20,000 records. At this high level of concurrent batch loads 50 segments provided good throughput and no deadlocking.

Changing the Data Segment CountOnce a CIM Relational Repository has been used to load data the “Total No. of Data Segments” configuration option can only be increased. In order for the data segment count to be decreased, all existing segment tables would have to be dropped and then recreated which would result in the loss of all existing segment data.

RDMS Disk I/O OptimizationEach CIM Relational repository can utilize up to five different RDMS disk I/O resources. Two different disk resources can be used in the Work Area and three different resources can be used in the Data Mart. This section provides an overview of how to optimize disk I/O resource utilization from a general RDMS approach. The SQL Server and Oracle specific tuning sections go into more depth on the specific options for each respective RDMS.

Work AreaThe Work Area supports the usage of two disk resources for use by the transformation engine during the data staging process. The first resource can be used for the staging tables and the second resource can be used for the indexes created against the staging tables. However, Hyperion’s stress testing results have not shown a benefit to splitting the table and index I/O to different resources and in fact there may be addition overhead incurred by the RDMS if the indexes located on a different disk resource. It is Hyperion’s recommendation that one disk resource be used for both Work Tables and Work Table Indexes.

3-2


The tables below list the SQL Server and Oracle configuration options used to set Work Area disk resource values:

SQL Server

Option Key Default Value Option DescriptionFileGroupWorkTable PRIMARY Work Table File GroupFileGroupWorkTableIndex PRIMARY Work Table Index File Group

Oracle

Option Key Default Value Option Descriptionora_WorkTableSpace Users Oracle Work TableSpaceNameora_WorkIXTableSpace Users Oracle Work Table Index TableSpaceName

Data MartThe Data Mart supports the usage of three disk resources. One disk resource can be used for the main Data Segment tables. A second disk resource can be used for the Data Map Segment tables. Finally all other tables and indexes can be kept on the default resource. Please note that when the CIM Repository is initially created all objects will be created on the default disk resource. If you plan to optimize the RDMS disk resources utilization you will need to drop and recreate the data segment tables after changing these options. This task is covered in more detail in the following sections.

The tables below list the SQL Server and Oracle configuration options used to set Data Mart disk resource values:

SQL Server

Option Key Default Value Option DescriptionFileGroupDataSeg PRIMARY Data Seg Table File GroupFileGroupDataMapSeg PRIMARY Data Map Seg Table File Group

Oracle

Option Key Default Value Option Descriptionora_DSegTableSpace Users Oracle Data Seg TableSpace Nameora_DMSegTableSpace Users Oracle Data Map Seg TableSpace Name

3-3

Module 3 — General Setup & Tuning Options

Disk Resource Diagram

The diagram below illustrates the disk I/O resources that can be used with the CIM Rela-tional Repository.

3-4


Module 4: SQl Server Setup and tunIng optIonS

4-1

Module 4 — SQL Server Setup & Tuning Options

RDMS Disk I/O OptimizationWhen a new Hyperion FDM Application is created, all of the Hyperion FDM SQL objects are created in the Primary file group by default. Using the Primary file group will work fine in most situations, but disk contention could hinder I/O performance when processing large amounts of data. To help balance the I/O and minimize disk contention, the following is recommended:

Data Segments TablesTo minimize disk contention, create a file group for the Data Segments tables and store the data files for this file group on a separate physical disk. After creating a new file group for the Data Segments tables, the Data Map Seg Table File Group and Data Seg Table File Group configuration settings will have to be modified from Primary to the new file group name as shown below:

Launch the Hyperion FDM Workbench and select Tools > Configuration Settings as shown below.

4-2


Select Data Map Seg Table File Group from the Options list and enter the name of the new file group in the Name text box and click the Save button.

Select Data Seg Table File Group from the Options list and enter the name of the new file group in the Name text box and click the Save button.

Click the Close button to exit Configuration Settings.

Note: The Data Map and Data Seg tables can also be separated into their own file groups, but no significant increase in performance was observed during our testing.

After the new file group names have been specified, the Data Map and Data Seg tables will need to be deleted from the Primary file group and recreated in the new file group.

Note: Deleting and recreating the Data Map and Data Seg tables will truncate all of the existing data in the tables. Changing the file group names and recreating the tables should be done when the application is created and prior to loading any data.

4-3


To recreate the Data Map and Data Seg tables, select Manage Data Segments > Delete, Recreate, and Reassign All Segments from the Tools menu located on the Hyperion FDM Workbench screen.

The Recreate Segments screen will be displayed. Select the number of segments to be created (default is 50 segments) and click the Save button to continue.

The dialog will be displayed to verify that all of the data in the Data Map and Data Seg tables should be deleted. Click the Yes button to continue.

4-4


Once the Data Map and Data Seg tables have been recreated, they should now be located in the new file groups that were specified under the Configuration Settings.

Work Tables and Work Table IndexesTo minimize disk contention, create a file group for the Work tables and Work table indexes and store the data files for this file group on a separate physical disk. After creating a new file group for the Work tables and indexes, the Work Table File Group and Work Table Index File Group configuration settings will have to be modified from Primary to the new file group name as shown below:

Launch the Hyperion FDM Workbench and select Tools > Configuration Settings.

4-5


Select Work Table File Group from the Options list and enter the name of the new file group in the Name text box and click the Save button.

Select Work Table Index File Group from the Options list and enter the name of the new file group in the Name text box and click the Save button.


All of the Work table and indexes that are created and dropped during data processing will now be located in the new file group.

Note: The Work tables and indexes can also be separated into their own file groups, but no significant increase in performance was observed during our testing.

All Other TablesThe remaining tables that are created and used by Hyperion FDM are stored in the Primary file group.

4-6


Account PermissionsThe Hyperion FDM SQL Server Account is the account Hyperion FDM will use to access the Hyperion FDM SQL Server database. Hyperion FDM can use Windows Integrated Security when accessing the SQL Server database or a specified SQL Server Account can be used. If using Windows Integrated Security when accessing the SQL Server database, the Hyperion FDM Application Server account will be used to logon to the SQL Server database when accessing Hyperion FDM via the Web. When using the Hyperion FDM Workbench, the logon name used to logon to the Workbench is used to logon to the SQL Server Database.

When creating a new Hyperion FDM database, the account must either be a SQL Server System Administrator OR have Database Creator rights and Bulk Insert Administrator rights. If desired, after the database has been created, this account can be changed to have only Bulk Insert Administrator and db_Owner rights. The Windows account that is running the MSSQLServer Windows Service must have read access to the Hyperion FDM Inbox folder.

SQL Server Client Software RequirementsAppServers

Microsoft OLE DB Provider for SQL Server

LoadBalancerMicrosoft OLE DB Provider for SQL Server

•

•

Module 5: oraCle Server Setup and tunIng optIonS

5-1

Module 5 — Oracle Server Setup & Tuning Options

RecommendationsThe following list describes recommendations for a successful Hyperion FDM Oracle configuration. Detailed descriptions can be found in subsequent sections.

An Oracle database instance should be created and exclusively used for Hyperion FDM.Minimum of one gigabyte of memory should be allocated for the database instance (recommended). Configure the following Oracle initialization parameters:- log_buffer- open_cursors - cursor_sharing

Separate redo logs from other database files.Create separate tablespaces for Hyperion FDM Data Seg, Data Map Seg, and Work tables.

The Hyperion FDM Work tables’ tablespace should be configured with no logging. Minimum tablespace size is one gigabyte (recommended). The tablespace size requirement is dependant on the amount of data and the size of the applications.

Set the Hyperion FDM Configuration Settings for the Oracle tablespaces as described in the sections that follow.

Set the Work Table Bitmap Index Switch to ON for Oracle 9i or OFF for Oracle 10g.

Oracle Database InstanceHyperion recommends creating an Oracle database instance that will be exclusively used for Hyperion FDM. This will allow the database administrator to tune the Oracle instance for Hyperion FDM without affecting the performance of other applications. A minimum of one gigabyte of memory should be allocated for the database instance (recommended). Multiple Hyperion FDM application schemas can reside in this database instance.

Redo Log Buffer SizeThe default value for the redo log buffer size is operating system-specific, but for most systems, it is usually 500 KB. If the size of the redo log buffer is increased, the frequency of I/O operations is reduced, and the performance of the Oracle server is increased. A log buffer that is too small will keep the log writer process excessively busy, the log writer process will be constantly writing to disk, and it will frequently run out of space to accommodate new redo entries. You will run into more problems with a log buffer size that is too small rather than one that is too large.

To set the redo log buffer size manually, the log_buffer initialization parameter needs to be configured in the init.ora file. A redo log buffer size between 1 to 7 megabytes has shown excellent results during our testing.

Open CursorsThe open_cursors initialization parameter sets the maximum number of cursors each session can have open. If open_cursors is set to 100, for example, then each session can have up to 100 cursors open at one time. If a single session has 100 cursors open, it will get an ORA-1000 error “Maximum open cursors exceeded” when it tries to open one more cursor.

The default value for open_cursors is 50, but Oracle recommends that you set this to at least 500 for most applications.

•••

••

••

•

•

5-2


Cursor SharingBecause Hyperion FDM does not use bind variables, Hyperion recommends setting the cursor_sharing initialization parameter to SIMILAR instead of the default value of EXACT. Cursor sharing is an “auto binder.” It causes the database to rewrite queries using bind variables before parsing it.

RDMS Disk I/O OptimizationWhen a new Hyperion FDM application is created, all of the Hyperion FDM Oracle objects are created in the USERS tablespace by default unless other tablespaces were specified when the Hyperion FDM application was created. Using a single tablespace could hinder I/O performance when processing large amounts of data. To help balance the I/O and minimize disk contention, the following is recommended:

Redo LogsAn easy way to ensure that the redo logs will not cause any I/O performance issues is to separate them from other database files onto their own physical devices. For example, separating redo logs from data files generally helps performance since the I/O activity of the former is typically sequential and the I/O activity of the latter is random. Separating these can help devices more efficiently perform their I/O activities. When the redo logs are separated from the other database files, they should be placed on the fastest devices available.

If the redo logs are too few or if they are too small relative to the DML activity in the database, the archiver process will have to work extra hard to archive the filled redo log files. This may cause a slowdown in the instance. It’s easy to resize the redo logs or add more redo log groups. You must ensure that the redo logs are sized large enough to avoid additional checkpointing. As a rule of thumb, Oracle recommends that you size the log files so they switch every 20 minutes.

Data Segments TablesTo minimize disk contention, create a tablespace for the Data Segments tables and store the data files for this tablespace on a separate physical disk. After creating a new tablespace for the Data Segments tables, the Oracle Data Map Seg TableSpace Name and Oracle Data Seg TableSpace Name configuration settings will have to be modified from the USERS tablespace to the new tablespace name as shown below:

5-3


Launch the Hyperion FDM Workbench and select Tools > Configuration Settings

Select Oracle Data Map Seg TableSpace Name from the Options list and enter the name of the new tablespace in the Name text box and click the Save button.

Select Oracle Data Seg TableSpace Name from the Options list and enter the name of the new tablespace in the Name text box and click the Save button.

5-4



Note: The Data Map and Data Seg tables can also be separated into their own tablespaces, but no significant increase in performance was observed during our testing.

After the new tablespace names have been specified, the Data Map and Data Seg tables will need to be deleted from the USERS tablespace and recreated in the new tablespace.

Note: The Data Map and Data Seg tables do not need to be deleted and recreated if the new tablespace names were specified on the DB Options dialog when the Hyperion FDM application was created. The tables will have to be deleted if they need to be moved into the new tablespaces.

Warning: Deleting and recreating the Data Map and Data Seg tables will truncate all of the existing data in the tables. Changing the tablespace names and recreating the tables should be done when the application is created and prior to loading any data.

To recreate the Data Map and Data Seg tables, select Manage Data Segments > Delete, Recreate, and Reassign All Segments from the Tools menu located on the Hyperion FDM Workbench screen.

5-5


The Recreate Segments screen will be displayed. Select the number of segments to be created (default is 50 segments) and click the Save button to continue.

5-6


The dialog shown in the figure below will be displayed to verify that all of the data in the Data Map and Data Seg tables should be deleted. Click the Yes button to continue.

Once the Data Map and Data Seg tables have been recreated, they should now be located in the new tablespaces that were specified under the Configuration Settings.

Work Tables and Work Table IndexesTo minimize disk contention and logging, create a tablespace with NOLOGGING for the Work tables and indexes and store the data files for this tablespace on a separate physical disk. The create tablespace command for the HyperionWORK tablespace with NOLOGGING looks like this:

CREATE TABLESPACE HyperionWORK DATAFILE ‘H:\ORACLE\ORADATA\HyperionWORK.ORA ‘ SIZE 5120M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITEDNOLOGGINGONLINEPERMANENTEXTENT MANAGEMENT LOCAL UNIFORM SIZE 1MBLOCKSIZE 8KSEGMENT SPACE MANAGEMENT AUTO;

Since the Work tables are created and dropped during data processing, creating a separate tablespace for the Work tables without logging has shown to improve performance. After creating a new tablespace for the Work tables and indexes, the Oracle Work TableSpaceName and Oracle Work Table Index TableSpaceName configuration settings will have to be modified from the USERS tablespace to the new tablespace name as shown below:

5-7


Launch the Hyperion FDM Workbench and select Tools > Configuration Settings

Select Oracle Work TableSpaceName from the Options list and enter the name of the new tablespace in the Name text box and click the Save button.

Select Oracle Work Table Index TableSpaceName from the Options list and enter the name of the new tablespace in the Name text box and click the Save button.

5-8


Select Oracle Work Table Bitmap Index Switch from the Options list and set the value to ON if you are using Oracle 9i or OFF if you are using Oracle 10g and click the Save button.


All of the Work table and indexes that are created and dropped during data processing will now be located in the new tablespace.

Note: The Work tables and indexes can also be separated into their own tablespaces, but no significant increase in performance was observed during our testing.

All Other TablesThe remaining Oracle objects created and used by Hyperion FDM are stored in the USERS tablespace. To further help improve performance and reduce disk contention, the USERS tablespace can also be separated from the other database files and moved to a separate disk.

5-9


Account PermissionsThe Hyperion FDM Oracle Account is the account that Hyperion FDM will use to access the Hyperion FDM Oracle database. Hyperion FDM can use Windows Integrated Security when accessing the Oracle database or a specified Oracle account can be used. If using Windows Integrated Security when accessing the Oracle database, the Hyperion FDM Application Server account will be used to logon to the Oracle database when accessing Hyperion FDM via the Web. When using the Hyperion FDM Workbench, the logon name used to logon to the Workbench is used to logon to the Oracle database.

In order to properly connect via Windows Integrated Security, Oracle must be configured to allow such connections. By default, the sqlnet.ora file contains the entry that enables operating system authentication. The SQLNET.AUTHENTICATION_SERVICES= (NTS) entry allows for authentication by the operating system. In order to create an Oracle account to connect via Windows Integrated Security, you will need to know the value of the os_authent_prefix parameter. Oracle uses this parameter when it is authenticating external users. The value of this parameter is prefixed to the operating system username. The default value for this parameter is OPS$, but it may be different on your system. If the value is OPS$, the Oracle account will be formatted as OPS$hostname\username, where hostname is the machine name or domain name, and username is the Windows username.

When creating a new Hyperion FDM account, the account must either be granted the DBA role OR be granted the following system privileges:

CREATE PROCEDURECREATE SEQUENCECREATE SESSIONCREATE TABLECREATE TRIGGERCREATE VIEW

The default tablespace for this account should be USERS and have an unlimited quota on the USERS tablespace. If you wish to make sure that the user does not exceed a space-used threshold, or if you have any questions about the appropriate value for the quota, consult with your database administrator.

Note: If separate tablespaces were created for the Work Tables, Work Table Indexes, or Data Segments Tables as described in the previous section, the account will need to have a quota set for these as well.

Oracle Client Software RequirementsThe following Oracle Client software is required to be installed on the App Server and Loan Balancer machines:

App ServersOracle Database Utilities (including SQL*Loader)Oracle Windows Interfaces (including Oracle Provider for OLE DB)

Load BalancerOracle Windows Interfaces (including Oracle Provider for OLE DB)

••••••

••

•

Download - Hyperion System 9 Financial Data Quality Management · The preface for the Hyperion System 9 Financial Data Quality Management (Hyperion FDM) contains the following topics: Purpose

Top Related