Wednesday, September 24, 2008

Oracle World 2008, 9/24, 1pm

SARM BEST PRACTICESSiebel Application Response ManagementShould help address these questions:*where is the bottleneck for transaction x by user y*which screen/view/bizcomp/script/wf were involved*how much cpu and memory was consumed*how many times were vaious components invoked*how has transaction processiona nd resource consumption changed from release to release

SARM consists of framework, instrumentation, and toolsOracle Enterprise Manager - management of the entire stack (app, middle, db) became available for Siebel 7.7 and up

Siebel Transaction Diagnostic Tool*guidance: turn on SARM, level 1 w/ no overhead*sarm is saved into a memory buffer to alleviate disk IO*sarm data is flushed into the siebel file system in binary which can be converted to csv post processing (command line tool)*sarm takes 3 to 4 % cpu*sarm calls are < 40 microseconds per call*based on benhcmark with 500 concurrent users, 30 seconds think time, on call center

level 1 is considered best practice, you want it turned on for the obj manager that end users interact with

siebel 7.5, requires a bounce of servers.. later versions do not requiresiebel 8 allows you to turn it on for a specific user

Best practices:Use SARM throughout app lifecycleUse SARM during pre-prod load testsUse SARM for monitoring in productionTake SARM snapshots periodically (before a change to the prod environment) for comparisons

DEMO: featuring oracle enterprise manager, to find slow performance by user CCHENG*report generated based on filtering on start/end dates showing summary of performance of each transaction request*each sarm request can be drilled down to get to the bottleneck but cannot get to the sql statement by drilldown, but its in progress for a future release. *for now, use sarm id to correlate to generated sql.*if a scripting issue, the SARM tool will indicate script name!