Contributions by Angela Golla, Infogram Contributor
My Oracle Support Speed Training
Did you know that there are short recorded training sessions available on My Oracle Support? Check out the My Oracle Support Speed Training sessions available from Note:603505.1. Topics covered include using PowerView, Quick Search, Service Request Management and more.
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=603505.1
Wednesday, March 17, 2010
Tuesday, March 16, 2010
OBIEE
OBIEE
While helping out a customer with some OBIEE problems I came across this nicely done posting on Troubleshooting OBIEE : Connectivity and Server Issues over at the Rittman Mead Consulting blog.
Friday, March 12, 2010
Infrastructure Sizing for Essbase (part 1)
This is the first of a series of three blog entries where we discuss estimating infrastructure specifications to support Essbase.
John French
ACS Principal Service Delivery Engineer
Richard (Rick) Sawa
ACS Principal Service Delivery Engineer
Overview
We provide a high-level discussion of what is involved in assessing/sizing a server infrastructure to support Essbase. We start by briefly outlining the requirements and procedures involved with assessing an existing environment. This establishes a frame of reference for the discussion that follows on guidelines for estimating infrastructures to support Essbase when the details of end-user and batch processing requirements have yet to be defined.
Introduction
There is no replacement for systematic testing to determine the specific hardware specifications required to support Essbase, no matter how hard the shoe strikes the podium. We think that everyone knows that this is true. And it’s also true that at the very beginning of a new development initiative, the proverbial cart is before the horse. How does one define hardware specifications for processing requirements that are not yet quantified? The short answer is that you can’t.
In the absence of requirements, every estimation for hardware is based on assumptions.
Essbase Server Assessments
We frame the sizing discussion by briefly presenting how we evaluate existing Essbase servers when processing requirements are fully understood. When the results of the assessment reveal that the infrastructure is found wanting, an estimation of more appropriate server specifications can be brought forward. The criteria used to draw up these new specifications forms an ideal list of criteria for assessing Essbase infrastructures.
Once ideal requirements are understood, you will be able compare them to what is available on more generic assessments. Subtracting the generic criteria from the ideal gives an indication of how accurate the sizing estimate can be expected to be.
Every Essbase server review should look at the Essbase cube designs to determine whether they are following best practices, and whether tuning methodologies can be invoked to increase performance.
Complete application design reviews involve coordinating the detailed business requirements with cube design decisions. Full reviews vary in no significant way from an implementation in terms of the amount of time and resources that they consume. This usually stands far outside of what is possible to do within the timeframes allocated for an assessment.
Once, however, the cubes and their processes have been optimized within time and resource constraints, a more reliable determination of hardware requirements can be made. Sometimes a tuning effort is sufficient to enable the system to perform up to service level agreements, and sometimes not.
In our opinion, tuning is mandatory because it averts the criticism that hardware is simply being thrown at the problem.
Supporting Infrastructure Components
The Essbase configuration and script settings are cross-referenced with infrastructure settings and configuration. The infrastructure (RAM, CPU, etc.) is monitored and measured during Essbase processing.
Infrastructure Analysis
Concurrency is accurately extracted from the Essbase performance logs by identifying overlapping response times. The contents of the manually generated Essbase performance log are correlated with infrastructure performance log statistics, and subjected to analysis.
Correlating the Server Performance Monitoring Logs with Essbase events, enable you to compare what is being allocated to Essbase processes with how the underlying server hardware, operating system and supporting infrastructure components are behaving.
Consider the two following charts created during an infrastructure assessment. They show the saw tooth behavior of both disk and CPU activity. Comparing teeth directly, clearly evident is an inverse relationship between disk and CPU. Vertical lines have been inserted to illustrate:
When disks were busy, CPUs became idle, and vice versa. The activities being measured were data load and aggregation batch process routines. From this we were able to see the disk bottleneck and the impact that it was having on CPU utilization.
This type of measurement makes it possible to assess server behavior, and can be incorporated to provide accurate infrastructure specification criteria.
To sum up, in situ infrastructure assessments analyze detailed Essbase and infrastructure metrics to determine how and why the infrastructure is responding to specific Essbase processing requirements. An analysis is made of Essbase design characteristics, and tuning techniques are applied to ensure that Essbase processes are as efficient as possible. The analysis of Essbase settings and processing requirements enables an accurate estimation of hardware should the current infrastructure be found wanting.
In the final analysis, a complete list of Essbase settings and processing requirements are requisite to estimating infrastructure requirements.
________________________________________
John French
ACS Principal Service Delivery Engineer
Richard (Rick) Sawa
ACS Principal Service Delivery Engineer
Overview
We provide a high-level discussion of what is involved in assessing/sizing a server infrastructure to support Essbase. We start by briefly outlining the requirements and procedures involved with assessing an existing environment. This establishes a frame of reference for the discussion that follows on guidelines for estimating infrastructures to support Essbase when the details of end-user and batch processing requirements have yet to be defined.
Introduction
There is no replacement for systematic testing to determine the specific hardware specifications required to support Essbase, no matter how hard the shoe strikes the podium. We think that everyone knows that this is true. And it’s also true that at the very beginning of a new development initiative, the proverbial cart is before the horse. How does one define hardware specifications for processing requirements that are not yet quantified? The short answer is that you can’t.
In the absence of requirements, every estimation for hardware is based on assumptions.
Essbase Server Assessments
We frame the sizing discussion by briefly presenting how we evaluate existing Essbase servers when processing requirements are fully understood. When the results of the assessment reveal that the infrastructure is found wanting, an estimation of more appropriate server specifications can be brought forward. The criteria used to draw up these new specifications forms an ideal list of criteria for assessing Essbase infrastructures.
Once ideal requirements are understood, you will be able compare them to what is available on more generic assessments. Subtracting the generic criteria from the ideal gives an indication of how accurate the sizing estimate can be expected to be.
Assessment Checklist
The following is a summary list of the objects and information that eServices review in order to complete an Essbase infrastructure server assessment:
1. Essbase Server Configuration
a. Essbase.cfg Settings
2. Essbase Application Settings
a. Application Logs
b. Cube Outlines
c. Cube Statistics
d. Calc Script/Business Rules Procedural Logic and Settings
e. Batch Process Scripts
3. Hardware Server Configuration
a. Operating System
b. Processors (number, speed & architecture)
c. RAM
d. Virtual Machine configuration
e. LPAR definition
f. Server Application profile
g. Disk configuration
h. Network configuration
4. Server Performance Monitoring Logs
a. RAM
b. CPU
c. Network
d. Disk
Items 1 and 2 contain detailed software requirements. These infer specifications for hardware listed in item 3. The first two items really provide specific sizing criteria for hardware.
In an in situ environment, items 1, 2 and 3 are already working together, and have specific content. A sizing assessment where software requirements are minimally known means that assumptions need to be provided. The accuracy of the sizing estimate is strictly correlative with the accuracy of these assumptions.
Assessment Components
Essbase Server
Essbase objects are analyzed for settings (caches, CALCPARALLEL, and so on). Requests for processor, network and disk resources are extracted from the Essbase Application logs in the form of response times for events. Response times are combined manually to provide a single Essbase Performance Log.
Every Essbase server review should look at the Essbase cube designs to determine whether they are following best practices, and whether tuning methodologies can be invoked to increase performance.
Complete application design reviews involve coordinating the detailed business requirements with cube design decisions. Full reviews vary in no significant way from an implementation in terms of the amount of time and resources that they consume. This usually stands far outside of what is possible to do within the timeframes allocated for an assessment.
Once, however, the cubes and their processes have been optimized within time and resource constraints, a more reliable determination of hardware requirements can be made. Sometimes a tuning effort is sufficient to enable the system to perform up to service level agreements, and sometimes not.
In our opinion, tuning is mandatory because it averts the criticism that hardware is simply being thrown at the problem.
Supporting Infrastructure Components
The Essbase configuration and script settings are cross-referenced with infrastructure settings and configuration. The infrastructure (RAM, CPU, etc.) is monitored and measured during Essbase processing.
Infrastructure Analysis
Concurrency is accurately extracted from the Essbase performance logs by identifying overlapping response times. The contents of the manually generated Essbase performance log are correlated with infrastructure performance log statistics, and subjected to analysis.
Correlating the Server Performance Monitoring Logs with Essbase events, enable you to compare what is being allocated to Essbase processes with how the underlying server hardware, operating system and supporting infrastructure components are behaving.
Consider the two following charts created during an infrastructure assessment. They show the saw tooth behavior of both disk and CPU activity. Comparing teeth directly, clearly evident is an inverse relationship between disk and CPU. Vertical lines have been inserted to illustrate:
When disks were busy, CPUs became idle, and vice versa. The activities being measured were data load and aggregation batch process routines. From this we were able to see the disk bottleneck and the impact that it was having on CPU utilization.This type of measurement makes it possible to assess server behavior, and can be incorporated to provide accurate infrastructure specification criteria.
To sum up, in situ infrastructure assessments analyze detailed Essbase and infrastructure metrics to determine how and why the infrastructure is responding to specific Essbase processing requirements. An analysis is made of Essbase design characteristics, and tuning techniques are applied to ensure that Essbase processes are as efficient as possible. The analysis of Essbase settings and processing requirements enables an accurate estimation of hardware should the current infrastructure be found wanting.
In the final analysis, a complete list of Essbase settings and processing requirements are requisite to estimating infrastructure requirements.
________________________________________
Next week we will continue with a general discussion sizing concepts and focusing on how to best understand concurrency and Essbase.
Thursday, March 11, 2010
SOA, EBS, Patching, EBS Patching, Optimizer, PeopleSoft
SOA
Clemens Utschig puts his focus on SOA for the java developer.
EBS
New this week at the Oracle E-Business Suite Technology blog:
OCFS2 for Linux Certified for E-Business Suite Release 12 Application Tiers
Performing Better: Improving Skills and Knowledge of EBS Tools and Technology
E-Business Suite Release 12.1.1 Consolidated Upgrade Patch 1 Now Available
Patching
Also in the realm of EBS this week is this excellent summary of patch types prepared by Renee Van Dusen of Oracle:
Patch Types & Reasons to Patch
Oracle consolidates and releases the following patch types. Patches include bug fixes as well as new functionality.
- Version Maintenance Pack – This would be a large consolidation of patches including all versions up to the latest for all products in the Oracle eBusiness Suite. For example, 11.5.10 would include all version changes prior to 11.5.10 such as 11.5.8, 11.5.9, etc. These patches are cumulative. Maintenance packs include all the relevant Family packs.
- Family Pack – This would be a consolidation of patches for a particular family of products such as Financials which includes General Ledger, Accounts Payable, Cash Management, etc. or CRM which includes Sales, Marketing, Service, etc. These patches are cumulative. Family packs include all the relevant Mini-Packs.
- Product Mini-Pack – This would be a consolidation of patches for a particular product such as General Ledger or Enterprise Budgeting and Planning. These patches are cumulative. For example, General Ledger Mini-Pack C includes mini-packs A, B, and C.
- Consolidated Rollups – These are rollup releases of patches as add-ons or fixes to Mini-packs, Family packs, Maintenance packs, or specific areas within a Mini-pack. Typically these don’t increase the version level of the Maintenance, Family, or Mini pack.
- Quarterly Security Patches – Oracle now releases on a quarterly basis a compilation of High Priority security patches for all tiers of the Oracle Applications: Database, Application Server, or Application. Some patches are cumulative, some aren’t.
- One-offs – One off patches are released to fix specific issues. They are generally smaller patches and usually at some point in time get rolled up into the other patch types described above.
Typically one would apply a patch type to fix a bug, keep current on the latest versions, implement new functionality, or implement a new product of the eBusiness Suite.
EBS Patching
And now the combination of the two articles above, EBS and Patching. There are alerts out this week for our HP users running Oracle EBS 11i and 12i. Please look up the following doc IDs in My Oracle Support:
ADRELINK utility for E-Business Suite Release 12.0 and 12.1.1 result in large executables which may lead to out-of-memory issues (Doc ID 1060979.1) (effects both PA-RISC and Itanium)
and
New E-Business Suite Release 12.0 and 12.1 Operating System Patch Requirements on the HP-UX Itanium platform (Doc ID 1066323.1) (effecting Itanium users).
Optimizer
There will be member of the Oracle optimizer team presenting at ODTUG Kaleidoscope in July in Washington, DC, (who chose that location, the heat and humidity committee?). You can read all about it on their blog: Inside the Oracle Optimizer - Removing the black magic
PeopleSoft and the Optimizer
Speaking of the optimizer, this time from the PeopleSoft side of the equation, there's a handy technique described over at the PeopleSoft DBA blog on: Hinting Dynamic Generated SQL in Application Engine.
Wednesday, March 10, 2010
Contributions by Angela Golla, Infogram Contributor
Oracle E-Business Suite Upgrade to Release 12
Many Oracle E-Business Suite customers are now faced with the task of upgrading to Release 12. Luckily, there are some terrific resources available on TechNet. Check out the following:
Whitepaper: Oracle E-Business Suite Release 12 Technology Stack Documentation Roadmap
Whitepaper: Best Practices for Adopting Oracle E-Business Suite Release 12
Whitepaper: Case Study: Oracle's Own Oracle E-Business Suite Release 12 Upgrade
Forum: Oracle E-Business Suite Release 12 Install/Upgrade
Oracle E-Business Suite Upgrade to Release 12
Many Oracle E-Business Suite customers are now faced with the task of upgrading to Release 12. Luckily, there are some terrific resources available on TechNet. Check out the following:
Whitepaper: Oracle E-Business Suite Release 12 Technology Stack Documentation Roadmap
Whitepaper: Best Practices for Adopting Oracle E-Business Suite Release 12
Whitepaper: Case Study: Oracle's Own Oracle E-Business Suite Release 12 Upgrade
Forum: Oracle E-Business Suite Release 12 Install/Upgrade
Thursday, March 4, 2010
EBS, Blogs of Note, SOA, Oracle Support, Business and IT, APEX, ADF, Hyperion
EBS
At the Oracle E-Business Suite Technology blog this week:
Blogs of Note
Kevin Closson singles out the Oracle-Base blog as one of his favorites, and Kevin's blog is one of my favorites, so I'm passing it along. This is a real technical treasure trove. Consider these samples:
SOA
Over at the Inside scoop on Oracle SOA Suite, BPM and EDA blog we have a link to a good technical article: Setting Web Service and JCA Adapter Endpoints Dynamically in Oracle SOA Suite
Oracle Support
Chris Warticki has moved his postings to Oracle Communities, which makes getting a login there worthwhile by itself. But he is still posting links to his postings at his blog. This one is entitled: Support Synchronization - Best Practices .
Business and IT
Over at the Tech Demo Guy blog there's a good quick set of 5 Rules for Selling Technology to Business Audiences. Worth a read.
APEX
Anton Nielsen brings us a technical hint at this blog: APEX Refresh Classic Report Region AJAX style.
ADF
Keeping the users out of trouble by Integration in Oracle ADF with ADF Task Flows and Dynamic Regions Pending Changes at the Andrejus Baranovskis's Blog.
Hyperion
As Glenn Schwartzberg's Essbase Blog tells us, Kaleidescope is already on the horizon and closing fast on our position. Time to figure out what you want to attend. As I always found at technical conferences, there's always too much interesting stuff going on. There's only one solution, but cloning technology and phase-shifting to attend two events at once are still a ways off. The next best thing is reading up on the schedule in advance and make up your mind.
Wednesday, March 3, 2010
Contributions by Angela Golla, Infogram Contributor
Upgrade to 11g Performance Best Practices
Uday Moogala has written a great whitepaper on best practices of upgrading to 11g for E-Business Suite customers. It can be found at: http://www.oracle.com/apps_benchmark/doc/11g-upgrade-performance-best-practices.pdf
Upgrade to 11g Performance Best Practices
Uday Moogala has written a great whitepaper on best practices of upgrading to 11g for E-Business Suite customers. It can be found at: http://www.oracle.com/apps_benchmark/doc/11g-upgrade-performance-best-practices.pdf
Subscribe to:
Comments (Atom)