- ERP System: Oracle, SAP, Peoplesoft.
- MarkView Version: 6.x and above.
- Troubleshooting application system performance requires a structured approach, analyzing a broad range of components, including:
- Client Desktop Machine
- Application Servers
- Database Servers
To start, gather some basic data by answering the following questions.
For end user questions, you should use the attached spreadsheet (MarkView_Performance_User_Report.xls) to gather specific performance information from the user community:
- Are all hardware and software components at or above the minimum required levels for running the MarkView system? (Consult for details.)
- When did this problem start? Did anything change on your system around the time that the problem started?
- Is there a specific time of day when performance slows down? Do non-MarkView applications also slow down during that time?
- If you know what application causes the slowdown and you restart that application, does the application then perform at normal levels?
- What aspects of the system seem slow?
Possible answers include:
- When opening first doc
- When opening subsequent docs.
- When applying markups.
- When selecting LOVs.
- When saving markups.
- How do users access docs? In other words, are they accessing docs through the Web Inbox, Invoice Workbench Get Next, or some other component? Is the performance the same across different components? For example, does performance change when using Get Next rather than Invoice Workbench?
- Is this problem related to all markups or only to specific markups?
- If this problem is related to markups, examine the package bodies of the following packages:
- Is the performance similar across different environments (development, testing, production)? If not, what is different about these environments - process / user load, configuration differences, etc.?
- Is the performance identical for all users, or do only a subset of users experience the slow down?
You will typically need to rely on network engineers to use the tools at their disposal for investigating network performance. To help point engineers in the right direction, you can use some simple tests, such as ping, traceroute and pathping, between the machines in question.
Note: Simple tests like ping are very rudimentary, and will only highlight if a problem exists; if the results of a ping show no latency, that is NOT proof that there is no network issue. Because ping uses a simple packet test, if ping is slow, the network is slow, but if ping is fast, the network may not necessarily be fast.
Because most of the work in MarkView occurs in the database, most performance troubleshooting involves researching the database.
You must explore the following questions:
- Are all of the objects in the MarkView schema valid, including indexes? If not, send us a list of invalid objects and compilation errors.
- What is your database optimizer mode,
- If the MarkView Database Objects is version 220.127.116.11 or higher, gather schema stats for the MarkView schema by answer the following:
- When were statistics gathered last?
- How were statistics gathered?
- How often were statistics gathered?
- Send us the output of the following SQL commands:
- select table_name, last_analyzed, sample_size from dba_tables where owner = 'MARKVIEW';
- select index_name, last_analyzed, sample_size from dba_indexes where owner = 'MARKVIEW';
- Is the database instance tuned? Have you gathered statspack snapshots/AWR reports, and is there anything in the report that shows problems?
(Buffer waits, Buffer Hit Ratio, Library Hit Ratio, Lib Cache reloads, etc.)
Send us the complete Statspack Snapshot/AWR report, or at least the top wait events from the first page.
Also, you should have the snapshots taken at least every 15 minutes. (Info on AWR Reports)
- If you are using a pre-9i Release 2 DB, determine whether the SYS schema has been analyzed by mistake by issuing the following commands:
connect sys select count(*) from user_tables where last_analyzed is not null;
Read the following Support Web answers for additional information:
Note known issues with some older solutions and schema stats:
Customers should also provide the following information to Kofax Technical Support:
- Customers should send Support the output of the following:
- select * from v$parameter;
- any ifile
- The output from the Performance Information section of the Support Diagnostic Tools (available to MarkView Administrators from the MarkView Home).
- Customers should run the following to get the MarkView Database Objects version output:
- SQL> set serveroutput on size 50000
- SQL> exec mv_version.showall
- SQL> exec sf_version.showall
- Customers should generate a trace of the database process by doing the following:
- Make sure that timed_statistics=true before tracing.
- Use DBMS_SUPPORT, as it is the supported wrapper around "set events":
dbms_support.start_trace( waits=>true, binds=>true ) dbms_support.start_trace_in_session( sid , serial, waits=>true, binds=>true ) Please see: http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id= 62294.1
Run the trace file through trace analyzer, and upload both raw trace file and trace analyzer output.
As well as: http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=224270.1
If you don't have trace analyzer, then send the raw trace files from the 10046 trace and tkprof output.
- To run a trace on the Viewer Module:
- Modify the attached Get_Set_EV_10046.sql, to correctly identify the v$session records for the Kofax Application Server OC4J modules (usually program like 'java' and machine is the Application Server name).
- Run the modified Get_Set_EV_10046.sql from (a) above, and the spooled my_trace.sql to turn on SQL Tracing for the Kofax Application Server DB sessions.
- Perform reproduce steps of DFM LOVs.
Note: Even if you don't reproduce the end-user perceived slowdown, if you are following the same steps as the end user follows when encountering the slowdown (invoking the LOVs or coding the DFM in the same manner), then we can at least capture the DB behavior. On a quiet instance, the end-user may not see a slowdown, because the DB instance can handle the procedures that on a normal, active instance cause a tipping point.
- Run the spooled my_trace_off.sql to turn off tracing for the Kofax App Server DB sessions.
- Take the raw trace files, and run them through Trace Analyzer (preferred) or tkprof, generating the plan for the queries.
- Provide both the raw trace files and Trace Analyzer / tkprof output here.
- Are there any errors in the alert log?
- Are trace files being generated?
- Are there any errors in the OS logs (e.g
/var/log/messages). Send Support the output from top run in batch mode (top -b -n 5) when there is a problem.