Having had similar performance issues I agree with William. We had two issues with our server that caused slowness: 1. The Clob in-row issue. and 2. Lack of memory on the DB side. Increasing the settings to what remedy recommends helps a lot.
Recommended init.ora settings: _b_tree_bitmap_plans false cursor_sharing similar (10g), force (9i) cursor_space_for_time false db_block_checking false db_block_checksum true db_block_size 8k db_multiblock_readcount 16 log_buffer 10485760 open_cursors 500 optimizer_dynamic_sampling 2 session_cached_cursors 100 statistic_level typical timed_statistics true undo_retention 14400 work_area_policy auto (Page 18 of Performance Tuning for BSM) Page 12-14 covers tuning the mid-tier server. There is a whitepaper out there called "Using Oracle CLOBs with BMC Remedy Action Request System" that covers the clob conversion and its benefits. Here are more tuning suggestions (Page 15 of Performance Tuning for BSM) System components Database size Small Medium Large Suggestions CPUs (typical configuration) 4 Memory (typical configuration) 16 GB Requirements sga_target 6-8 GB db_cache_size 6 GB shared_pool_size 2 GB shared_pool_reserved_size 100 MB pga_aggregate_target 4 GB Sessions 1000 Processes 1000 Temporary tablespace 2-4 GB Log files 3 (500 MB each) In addition making sure that you are using "Cursor Sharing" helps. Here are some AR Server settings I found helpful: Next-ID-Commit: F Next-ID-Block-Size: 50 Oracle-Cursor Sharing: SIMILAR Oracle-Clob-Storage-In-Row: T Server-Side-Table-Chunk-Size: 5000 Clustered-Index: T Oracle-Bulk-Fetch-Count: 100 Oracle-Search-On-Clob: T Next thing I would do is tune the web server. Increasing the memory to the JVM helped a lot there. There are several docs on BMCs web site that helps tune whatever web server you are using. Thanks, Sean From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of William Rentfrow Sent: Wednesday, May 12, 2010 1:25 PM To: [email protected] Subject: Re: Question on Remedy Performance ** You have a remote Oracle instance on Sun. You need to contact support and get the CLOB in-row fix information. This causes severe performance problems in many situations. I've run into this now on a total of 8 Remedy implementations of 7.1 and higher. William Rentfrow Principal Consultant, StrataCom Inc. [email protected]<mailto:[email protected]> Corporate Website, www.stratacominc.com<http://www.stratacominc.com/> Blog, www.williamrentfrow.com<http://www.williamrentfrow.com/> 715-410-8156 C ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Matthew Perrault Sent: Wednesday, May 12, 2010 11:34 AM To: [email protected] Subject: Re: Question on Remedy Performance ** Also, Check you indexes on things like AR System Message Catalog, and the Help desk form. Our otb Help Desk form had 16 indexes on it (17 if you count entry id). That will cause slowness on a save. Danny, We have been having performance problems as well (same versions too) Usually it has to do with someone running a bad query and locking the table. Or fields not getting set, and then a table using an external table qualification with an empty field (translates it into 1 = 1) Any documentation you have I would be very interested in. Thanks, Matt P. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Danny Kellett Sent: Wednesday, May 12, 2010 9:58 AM To: [email protected] Subject: Re: Question on Remedy Performance ** The AR system is very latency bound. E.g. if your end users have a latency above 40ms, then you will start to notice a performance hit. Also, ITSM applications at that version was not built for performance but functionality. I have done some work on this and I am happy to share some documents with you off list. Some of the obvious things that were done include removing the option on "Refresh on entry change" on the tables within the incident form. For example if I remember there were approx 5 tables, so when you open / select an incident, all those refreshed when in reality, you won't want to see the financial information every time etc. Send me an email and I will dig out the docs for you. dkellett (at) javasystemsolutions.com Kind regards Danny Kellett SSO for ARS http://www.javasystemsolutions.com/jss/ssoplugin From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jim Coryat (jcoryat) Sent: 12 May 2010 15:35 To: [email protected] Subject: Question on Remedy Performance ** We are running ARS 7.1 patch 006 with ITSM 7.0.03 patch 007. The applications for the most part have been out of the box implementations, we have made some customizations but they have been minor in scope. Our application servers are dual 3.0ghz Xeon boxes with 8gb of memory running windows 2003 Enterprise. The database is Oracle 11 on a Sun V440 4 CPU 32gb memory dedicated box. Both the application server and database are on gigabit network connections. This has been bugging me for a while and I can't seem to figure out why the application server and database for the most part sit there at an idle, yet we have lackluster performance of the remedy system in regards to the customer experience on the desktop and web client. The performance is not terrible, however due to the under utilization of the hardware I would expect better response than what we are seeing. What I'm looking for is some pointers or documentation someone might know about that would help to identify anything that would be causing this behavior. I have read the scalability white papers published by BMC, which closely mirrors our configuration and this has been of little value. Jim Coryat Micron Technology Inc. _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
