White Paper Oracle's Cursor Sharing for BMC Remedy Products

White Paper Oracle's Cursor Sharing for BMC Remedy Products January 2007 www.bmc.com

Contacting BMC Software You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities. United States and Canada Address BMC SOFTWARE INC 2101 CITYWEST BLVD HOUSTON TX 77042-2827 USA Outside United States and Canada Telephone 713 918 8800 or 800 841 2031 Telephone (01) 713 918 8800 Fax (01) 713 918 8000 Fax 713 918 8000 If you have comments or suggestions about this documentation, contact Information Development by email at doc_feedback@bmc.com. Copyright 1991 2007 BMC Software, Inc., as an unpublished work. All rights reserved. BMC Software, the BMC Software logos, and all other BMC Software product or service names are registered trademarks or trademarks of BMC Software, Inc. All other trademarks belong to their respective companies. BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices included in this documentation. Restricted Rights Legend U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX 77042-2827, USA. Any contract notices should be sent to this address.

Customer Support You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer Support by telephone or email. To expedite your inquiry, please see Before Contacting BMC Software. Support website You can obtain technical support from BMC Software 24 hours a day, 7 days a week at http://www.bmc.com/support_home. From this website, you can Read overviews about support services and programs that BMC Software offers. Find the most current information about BMC Software products. Search a database for problems similar to yours and possible solutions. Order or download product documentation. Report a problem or ask a question. Subscribe to receive email notices when new product versions are released. Find worldwide BMC Software support center locations and contact information, including email addresses, fax numbers, and telephone numbers. Support by telephone or e-mail In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or send an email message to support@bmc.com. Outside the United States and Canada, contact your local support center for assistance. Before contacting BMC Software Have the following information available so that Customer Support can begin working on your issue immediately: Product information Product name Product version (release number) License number and password (trial or permanent) Operating system and environment information Machine type Operating system type, version, and service pack System hardware configuration Serial numbers Related software (database, application, and communication) including type, version, and service pack or maintenance level Sequence of events leading to the problem Commands and options that you used Messages received (and the time and date that you received them) Product error messages Messages from the operating system, such as file system full Messages from related software 3

4 Oracle's Cursor Sharing for BMC Remedy Products

White Paper Oracle's Cursor Sharing for BMC Remedy Products Cursor sharing has substantial benefits, and using it is a clear best practice for BMC Remedy products. This white paper summarizes the expected benefits and the risks from using this setting. Those already familiar with this technology can go to BMC Remedy product interaction and settings on page 7 for specific usage recommendations. Oracle shared pool usage and functionality of cursor sharing Oracle's primary central memory structure is called the System Global Area (SGA). The SGA has two primary parts:! Buffer cache Used to cache data! Shared pool Used to cache SQL statements When an SQL statement is to be executed, a cursor is opened in the shared pool, the statement is parsed, and it is associated with the open cursor and is ready to execute. The next time that statement is encountered, if it is still in the shared pool then it can be reused immediately (if the cursor is programmatically left open) and after a soft parse operation (if the cursor has been closed). Scalable use of an Oracle database depends on achieving good reuse of SQL statements, and soft parsing of such SQL is very efficient. If the SQL statement cannot be reused, then it will again be parsed entirely (called a hard parse), which is an expensive operation. An SQL statement will have variables, and if these variables are hardcoded into the text of the SQL statement, then they are called literal variables. If, on the other hand, a variable is included in the SQL statement (in the format of :variable_name), and that variable is instantiated before execution of the statement, then the statement is using a bind variable. SQL statements that use literals are generally not reusable as the shared pool stores a different copy of the SQL statement for each literal used in the statement. These SQL statements cannot share an existing cursor because the literal is changed during application execution. Conversely, statements with bind variables are reused no matter how many different instantiations of the variable there are, and hence result in better shared pool use. Oracle's Cursor Sharing for BMC Remedy Products! 5

White Paper Cursor_sharing is the Oracle technology that automatically replaces literal variables with system-generated bind variables. Setting cursor_sharing to force or similar enables sharing of literal SQL statements. When cursor_sharing is enabled, the system generated bind variables are visible in the SQL being executed, as literals are replaced with binds of the format ":sys_b_n", where n is an integer, indicating a system-generated bind variable has been created. The difference between force and similar is somewhat subtle, so it is generally less important which setting to use. More important is to make sure that one of these settings is enabled for an application that does not use bind variables. With the setting of similar, SQL statements that are likely to change their execution plan (especially when histograms are present) will not have automatically generated bind variables used. Force will generate these bind variables even in such cases. Performance effects of cursor sharing Any application that uses all literals without cursor sharing enabled is not a very scalable application. It is assumed that any good database application finds the majority of its SQL statements available for reuse in a shared pool when they are executed. Poor reuse of the shared pool means that Oracle must find a new space to allocate a cursor within the shared pool every time a statement is encountered. A least-recently-used (LRU) algorithm is used to determine what cursors should be removed if Oracle needs to create new free space in the shared pool. As the shared pool gets full with unshared statements, then the overhead in finding such memory to free gets higher. Larger shared pools actually increase this overhead as the larger shared pool becomes full and fragmented, and the LRU algorithm has higher cost to evaluate. Applications that do not reuse SQL often run better with smaller shared pools rather than larger ones. Additionally, to remove existing cursors and open new ones, Oracle must latch some memory structures. Specifically, it takes out library cache latches and shared pool latches, which may result in latch contention in a database running such an application. Specific diagnostics that indicate poor reuse of SQL are found in statspack (Oracle 8i and Oracle 9i) and AWR reports (oracle 10g). In the shared pool summary on the first page of the report, the shared pool memory grows quickly until its percentage used is roughly 90%. It never reaches 100%, as the LRU freeing algorithm continues to remove cursors to make more space for new statements. The next line in the report shows that the percentage of statements run more than once (that is, >1) is relatively low, such as 20 40%. Similarly the amount of memory allocated to statements that are run more than once is between 20% and 50% (depending on how large the reused statements happen to be). Next, such an application should show latch contention. In AWR reports, this is stated explicitly as library cache and shared pool latch wait events in the wait event list. The statspack indicates only that there is a latch free wait event, and then later in the report, it indicates which latch is under contention (typically, library cache latch first, and shared pool latch second). 6 "Oracle's Cursor Sharing for BMC Remedy Products

Oracle's Cursor Sharing for BMC Remedy Products Enabling cursor_sharing significantly reduces the shared pool maintenance overhead, as well as the latch contention overhead. The benefits for high-load online transaction processing (OLTP) applications can be as much as 10% or 20% CPU utilization reduction, as well as an inherently more scalable application profile. The benefits will be higher for higher load applications, and may reduce response time and provide better database performance overall. BMC Remedy product interaction and settings There is one significant conflict between the use of cursor_sharing and BMC Remedy products. Inserts into a Long Raw column while cursor_sharing is enabled can cause the BMC Remedy Action Request System (AR System ) server thread to hang. Such inserts are commonly done as part of the Email Engine activity when attachments are included in email messages. To avoid any impact from this issue, AR System server code explicitly disables cursor_sharing (that is, sets it to exact) when doing such an insert into a Long Raw column. However, it first needs to know that the current setting is not already exact. To get the current setting, the AR System server looks in the ar.conf file, where the cursor_sharing setting must be set to reflect the init.ora settings from Oracle. If the ar.conf file does not reflect the init.ora settings, then the AR System server assumes the value is already exact and, therefore, will not reset it when doing inserts into Long Raw columns. This issue was first fixed in AR System server version 6.0.1. However, the workaround above was only done for the case of cursor_sharing=force. Users of this server version should only set cursor_sharing=force and always reflect that setting in ar.conf. In versions 6.3 and 7.0, both settings cursor_sharing=force and cursor_sharing=similar are respected, and the workaround is implemented for both cases. So users of these product versions can use either setting, and once again need to reflect that setting in the ar.conf file. Best practices mandate specifically that, with 6.0.1, users should use force, and with 6.3 or 7.0, users should use similar, but the difference between the two settings is small. The syntax of the cursor_sharing setting in the ar.conf file is as follows (set only one):! Oracle-Cursor-Sharing: SIMILAR! Oracle-Cursor-Sharing: FORCE Resolved defects related to cursor_sharing include:! SW00168835! SW00172819! SW00202422 BMC Remedy product interaction and settings! 7

White Paper! SW00209632! SW00219469 8 "Oracle's Cursor Sharing for BMC Remedy Products

*67831* *67831* *67831* *67831* *67831*