Release 9.0.1
Part Number A88720-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle Enterprise Manager Getting Started with the Oracle Management Pack for Oracle Applications Release 9.0.1 Part Number A88720-01 |
|
The Concurrent Processing Tuning Assistant (hereafter referred to as the Tuning Assistant) is a reporting mechanism that allows you to examine historical processing information about Oracle Concurrent Processing requests and concurrent managers. The Tuning Assistant provides information that assists you in achieving better concurrent processing throughput by adjusting concurrent manager assignments and request scheduling.
The Tuning Assistant provides several predefined reports that identify problem areas in concurrent manager processing. The Tuning Assistant generates reports directly against the information stored in the Oracle Application Object Library tables or the Concurrent Processing Tuning Assistant repository.
There are two ways to run the Tuning Assistant:
The following section describes the advantages of both approaches, along with some issues you need to consider when using them.
For the most up-to-date information, generate the reports directly from the information stored in the Application Object Library tables. However, this schema is optimized for data entry, not data analysis. Depending on the amount of data, you may see poor performance when generating reports directly against the live Applications database.
One method for improving Tuning Assistant performance in retrieving data is to periodically use the SQL language ANALYZE command to compute statistics on tables that the Tuning Assistant accesses. These tables include:
See the Oracle SQL documentation for information on how to use the SQL ANALYZE command and the impact it may have on your system.
Tuning Assistant reports are limited by the amount of information stored in FND tables. Since, in a production system, these tables are purged on a regular basis, there is a need to keep the data in a separate repository schema if you want to analyze usage data for an extended period.
Using the Concurrent Processing Tuning Assistant repository solves this problem by allowing you to archive pertinent information before the FND tables are purged. In addition, the report generation will be accelerated because the schema is optimized for data analysis. The only drawback is that the data is only current up to the last data copy. The intention is for administrators to copy the data once a day. If up-to-the-minute information is required, generate the reports directly from the live Applications database.
When you run the 'Load Data into the Concurrent Processing Tuning Assistant Repository' job from the Enterprise Manager console, data will be uploaded from the Applications schema FND tables into the new repository schema. Data will then be aggregated into new tables. Use the Purge Policy field on this job's parameter page to indicate how many days of data should be saved for reporting. If the field is left blank or you enter 0, then the data is not purged.
Oracle recommends that the 'Load Data into the Concurrent Processing Tuning Assistant Repository' job be run on a daily basis to keep the repository data up-to-date. After the first execution of the job, consecutive runs copy only the new information added since the previous execution of the job.
The following section provides scenarios of how you might use the reports to tune your request schedules: concurrent manager balancing and concurrent manager specialization.
To determine concurrent manager balancing, view the Waiting Requests by Hour (24 x 7) report and look for the time periods with the greatest wait times.
If you find a time period that seems to have a relatively great number of backups, examine which requests were run and which requests were waiting during this time period. For selected time periods, drill down to the Requests that Waited report to identify the requests that waited. It may be necessary to schedule these requests during periods with excess concurrent manager capacity.
To find time periods with excess concurrent manager capacity, examine the Concurrent Managers by Hour (24 x 7) report, and look for underutilized time periods. For details about activity during selected time periods, drill down to the Requests that Ran report.
To reduce wait time, consider rescheduling a program to run when the concurrent managers have capacity to spare. Use these reports to identify requests whose schedules can be adjusted to distribute load more evenly.
If all concurrent managers are running at near or maximum capacity, it may be necessary to add more concurrent managers. If system resources are also fully utilized, it may be necessary to add additional hardware to support processing demands.
Designating certain concurrent managers to process either short or long running programs can help to mitigate queue backup. Designating a concurrent manager to process short running jobs can help to prevent short running jobs from getting stuck behind long running jobs.
Look at the Long Running Requests report to determine if any of these requests should be associated with a concurrent manager that will handle long running jobs.
Additionally, look at the Short Running Requests that Waited report to identify if any of these requests should be associated with a concurrent manager that will handle short running jobs.
You can access the Tuning Assistant in the following ways:
The following sections explain how to use these methods.
To start the Tuning Assistant from Oracle Enterprise Manager, highlight the concurrent manager you want to investigate and do one of the following:
The Tuning Assistant is displayed. However, if preferred credentials have not been set or if they are incorrect, the Concurrent Processing Tuning Assistant Login dialog box is displayed. Provide the login information to connect to a valid Applications schema.
Before starting the Tuning Assistant from the UNIX command line, do the following:
Once your Oracle Home is set up, on the command line type:
oemapp cpta
The Concurrent Processing Tuning Assistant Login dialog box is displayed. Provide the login information to connect to a valid Oracle Applications schema.
If the Tuning Assistant is connecting to the Oracle Management Server, the Tuning Assistant lists all discovered concurrent managers in its navigator tree. If the Tuning Assistant connects to an Oracle Applications schema or the Concurrent Processing Tuning Assistant repository, the Tuning Assistant will ensure that it is a valid schema containing Oracle Application Object Library tables.
To start the Tuning Assistant from the Start menu, select Start=>Programs=>ORACLE_HOME=>Management Pack for Oracle Applications=>Concurrent Processing Tuning Assistant. The Concurrent Processing Tuning Assistant Login dialog box is displayed. Provide the login information to connect to a valid Oracle Applications schema, a Concurrent Processing Tuning Assistant repository, or an Oracle Management Server.
If the Tuning Assistant is connecting to the Oracle Management Server, the Tuning Assistant lists all discovered concurrent managers in its navigator tree. If the Tuning Assistant connects to an Oracle Applications schema or the Concurrent Processing Tuning Assistant repository, the Tuning Assistant will ensure that it is a valid schema containing Oracle Application Object Library tables.
The following options are available in the Tuning Assistant:
The Tuning Assistant main window consists of two panes. The left pane displays a navigator tree that lists the Tuning Advisor feature and the various Tuning Assistant reports (concurrent managers, requests, and programs).
When the Tuning Advisor or a report is highlighted in the left pane, the General and Options tabs display in the right pane. Otherwise the Oracle Applications logo displays.
The General tab contains a thorough description of the contents of the report and why the report is useful.
The Options tab shows the current settings for the reporting options, for example, the reporting period, applications included in the report, and requests included in the report. Change the settings in this tab to retrieve the data in which you are most interested. Of the following options, only those appropriate for the particular report will display.
The Reporting Period group includes alternative options, such as previous week, previous four weeks, one week starting, and time period. The time period will be initialized to the minimum and maximum dates available in the current applications schema.
With this option, you can select either one application to be represented in the report or all available applications to be represented. By default, all applications are included.
The Requests Included In Report option has various settings based on the type of report you selected. These settings include:
Only requests with a duration greater than the minimum duration will be included in the report.
Only requests that waited longer than or equal to the minimum wait time will be included in the report.
Only requests that waited less than or equal to the maximum wait time will be included in the report.
Only requests that ran for less time than the maximum runtime will be included in the report.
For each of these options, enter a value in the text field and select the time granularity. The time granularity options are minutes, hours, days, and weeks. If you do not want an available option, set its time granularity to None.
With this option you can limit the number of rows retrieved to a value you specify. Only the number of rows specified are included in the report. If you do not specify the number of rows, all rows that meet the criteria for inclusion are displayed in the report.
To display reports, you can either click Show Report on the right pane or double click on the report node on the report tree.
When a report is opened, information is retrieved from the Application Object Library tables. As the Tuning Assistant retrieves the data, a busy bar appears at the bottom of the display. Some reports will show intermediate data in the display area. If the busy bar is still visible, this indicates that the data is still being retrieved.
A Cancel button is displayed next to the busy bar. Click Cancel to interrupt an operation. Depending on the type of operation that is being performed, the cancel operation may or may not be processed immediately. If partial data is available, Cancel will stop the data retrieval and display the results that were retrieved before the cancellation occurred.
The following are additional characteristics about the reports:
To save reports, click Save As on the toolbar.
Reports can be saved to a file in comma-separated value (CSV) format or HTML format. The file will contain the data that was retrieved for this report. Files saved in CSV format can be uploaded into spreadsheet applications. Files saved in HTML format can be viewed using a Web browser.
For reports that provide you with the ability to manipulate the displayed data, the Tuning Assistant saves the data as it is currently displayed.
To display the properties of a report, click Properties on the toolbar.
The Report Properties option displays information about a report, for example, options selected. Report Properties include the General and Options tabs, as well as a SQL Text tab that displays the SQL text used to generate the report. Drill-down reports include a Drill Source tab which includes information about the parent report for this drill-down report.
Some reports provide the ability to modify or change report properties and redisplay the report with the changed settings.
To drill down to a report, click Drilldown on the toolbar. You can also right-mouse click on a report to access a drill-down report.
Many reports have a drill-down capability. These reports will drill down to data associated with the currently selected items.
To print reports, click Print on the toolbar.
The Print option prints the data that is currently displayed in the report window.
The following reports are available through the Tuning Assistant:
The Concurrent Managers by Hour (24 x 7) report answers the question, "How is my concurrent manager capacity being used?"
The purpose of this report is to identify time periods when concurrent managers had capacity to spare. This report shows the percentage of time each concurrent manager was actually utilized for a block of time periods. By examining the time jobs were run in a concurrent manager against its total capacity, you determine capacity utilization.
This report shows the days of the week in columns and hourly time periods in rows. Each slot in the display contains the utilization for that concurrent manager during that time period. This report provides a graphical display using color and font styles to show time period utilization: red/bold (greatest utilization), yellow/italic (less utilization), and gray/regular (no utilization).
Because this report displays data in a weekly format (24 x 7), when you choose a time period that extends beyond a week, the data displayed is the sum of the data for each hour over the time period. For example, if the time period extends from Monday to Monday (8 days), the Monday column in the report displays the sum of the data for the two Mondays.
The features of this report include:
For this report you can drill down to the Request that Ran report. Select one or more time periods and choose Drilldown from the toolbar. You can also right-mouse click on a row or a cell to access a drill-down report.
The Concurrent Manager Usage by Program report answers the question, "Which programs ran on which concurrent managers?"
You can use this information to determine which concurrent manager and program combinations are potential bottlenecks.
For a given time period, this report provides the following information:
The Program Run Summary by Status report answers the question, "Which programs ran and how long did they take to run?"
This report provides general information about requests summarized by program and grouped by status:
From this report you can drill down to the Requests that Ran report. Select one or more rows, and choose Drilldown from the toolbar. You can also right-mouse click on a selected row to access a drill-down report.
The Program Wait Summary report answers the question, "Which programs had to wait and how long did they wait?"
With this report you can identify programs that have historically long wait times. This information can be used to identify which programs may benefit most from a change in program scheduling. This report provides the following information:
From this report you can drill down to the Requests that Waited report. Select one or more rows, and choose Drilldown from the toolbar. You can also right-mouse click on a selected row(s) to access a drill-down report.
The Waiting Requests by Hour (24 x 7) report answers the question, "What are my problem time periods?"
The resulting report shows the days of the week in columns and hourly time periods in rows. Each square in the display contains the amount of time requests waited (in minutes) during that time period.
This report presents a graphical display using color and font styles to show wait times: red/bold (longest wait times), yellow/italic (middle wait times), and gray/regular (no wait).
The graphical display of this data is useful when tuning concurrent managers by adjusting job schedules and by visually locating the "hot", "warm", and "cold" time periods. You can use this information to adjust request scheduling.
The features of this report include:
From this report you can drill down to the Requests that Waited report. Select one or more time periods, and choose Drilldown from the toolbar. You can also right-mouse click on a row or cell to access a drill-down report.
The Long Running Requests report answers the question, "Which jobs took a long time to run?"
This report shows runtimes for requests started during a given time period that took longer than n minutes to run. This helps you identify slow running requests.
A possible remedy for slow running requests is to schedule requests during off-peak hours. This report also identifies programs that should run in a particular concurrent manager. You can designate a concurrent manager for slow running requests and a concurrent manager for fast running requests. Long running jobs should be delegated to the slow running concurrent manager, and faster jobs should be delegated to the fast running concurrent manager. This prevents fast jobs from being blocked by a slow job, increasing overall throughput.
For all requests with a duration greater than a specified number of minutes, this report provides the following information:
From this report you can drill down to the Request Details report. Select a row, and choose Drilldown from the toolbar. You can also right-mouse click on a selected row to access a drill-down report.
The Short Running Requests that Waited report answers the question, "Which requests waited a long time relative to their runtime?"
This report lists the short running jobs that queue longer than a specified number of minutes.
This report is useful for determining which requests are waiting a relatively long time compared to their runtime. Requests can wait longer than they run. If many requests are identified, consider creating a concurrent manager that specializes in short running requests. This may help to increase the throughput of these requests.
This report provides the following information:
From this report you can drill down to the Request Details report. Select a row, and choose Drilldown from the toolbar. You can also right-mouse click on a selected row to access a drill-down report.
The Request Run Summary by Month report answers the question, "How has my request processing changed over time?"
You can use this information to determine on a monthly basis if overall performance is improving or deteriorating on a month-to-month basis. The average duration of a request (in minutes) is a good indicator of the change in system performance over time.
You can also use this report to note if the number of requests processed is increasing over time.
This report provides the following information:
Drill-down reports display information that is in the context of the report from which the drill-down was invoked. For example, from the Concurrent Managers by Hour (24x7) report, you can drill down to the Requests that Ran report.
The Requests that Ran report answers the question, "Which requests ran in the drill-down context?"
For all requests that ran in this context, this report provides the following information:
From this report you can drill down to the Request Details report. Select a request, and choose Drilldown from the toolbar. You can also right-mouse click on a selected row to access a drill-down report.
The Requests that Waited report answers the question, "Which requests waited in the drill-down context?"
For all requests that waited in this context, this report provides the following information:
From this report you can drill down to the Request Details report. Select a request, and choose Drilldown from the toolbar. You can also right-mouse click on a report to access a drill-down report.
The Request Details report answers the question, "What are the details for a given request ID?"
You can drill down to this information from any report that shows individual requests. This information is compatible with the request detail information presented by Oracle Applications Manager.
The information in this report is provided in the General, Schedule Options, and Completions Options tabs. The information includes:
The Tuning Advisor feature provides information about possible problems that may be impeding the best-possible performance of your concurrent managers.
Once problem areas are identified, suggestions for improving performance include: increasing capacity, rebalancing resources, and rescheduling requests.
There are a number of reports specific to the Tuning Advisor. The reports are:
The Tuning Advisor Report summarizes the information regarding concurrent managers and provides overviews of problem areas.
This report is divided into two tables:
This table lists all the concurrent managers.
This table summarizes the information by day and hour of the week (24 x 7) for the concurrent manager highlighted on the Concurrent Managers table.
Table cells highlighted in red (with bold font) suggest there is a high utilization of the concurrent manager while many requests waited.
Table cells highlighted in yellow (with italic font) suggest there is a low utilization of the concurrent manager while many requests waited.
Table cells highlighted in cyan (with bold italic font) suggest there was no capacity while many requests waited. This could mean the concurrent manager assigned to these requests was down.
Table cells that are not highlighted signify that no problem conditions were found.
To access a Tuning Suggestion report, open a Tuning Advisor report, select a cell on the right-hand 24x7 problem overview table, then drill down to the tuning suggestion reports.
This tuning suggestion report lists the requests that waited while the associated concurrent manager was over utilized. Suggestions are offered of how you might correct the many waiting requests problem.
This report has two parts: the upper part contains general information for this time period and the lower part shows (by default) requests that waited.
To view the specific tuning suggestions for this report, click Suggestions. Suggestions are offered of how you might correct the specific problems.
This tuning suggestion report lists the requests that waited while the associated concurrent manager was under utilized.
This report has two parts: the upper part contains general information for this time period and the lower part shows requests that waited.
This is a puzzling situation where there is no obvious explanation for what could be causing a backup when the concurrent manager is under utilized. While the report identifies that there is a problem, it is not capable of providing any tuning suggestions.
This tuning suggestion report is for the situation where there are many waiting requests and the concurrent manager is not up. It shows the concurrent manager information and lists the requests that waited during that time period and tuning suggestions.
This report has two parts: the upper part contains general information for this time period and the lower part shows (by default) requests that waited.
To view the specific tuning suggestions for this report, click Suggestions. Suggestions are offered of how you might correct the specific problems.
|
 Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|