Skip to main content

MarkView Performance Troubleshooting and Diagnostics

Article # 304361 - Page views: 251



Applies To

  • ERP System: Oracle, SAP
  • MarkView Version: 9.1.1+


  • Troubleshooting application system performance requires a structured approach, analyzing a broad range of components, including:
    • Client Desktop Machine
    • Network
    • Application Servers
    • Database Servers

Beginning Questions

To start, gather some basic data by answering the following questions.

End Users

Use the attached spreadsheet (MarkView_Performance_User_Report.xls) to gather specific performance information from the user community:

  1. Are all hardware and software components at or above the minimum required levels for running the MarkView system? (Consult for details.)
  2. When did this problem start? Did anything change on your system around the time that the problem started?
  3. Is there a specific time of day when performance slows down? Do non-MarkView applications also slow down during that time?
  4. If you know what application causes the slowdown and you restart that application, does the application then perform at normal levels?
  5. 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.
  1. How do users access documents?
    1. From the Web Inbox?
    2. Invoice Workbench > Get Next
    3. Some other components?
      1. Is the performance the same across different components? For example, does performance change when using Get Next vs. Invoice Workbench vs. Process Monitor?
  2. Is the problem related to placement of all markups or only to a specific markup tool?
    1. If this problem is related to markups, examine the package bodies of the following packages:
  3. Is the performance similar across different environments (Production vs. Non-Production)?
    1. If not, what is different about these environments? (process, user load, configuration differences, etc)
  4. Is the performance identical for all users, or do only a subset of users experience the slow down?
    1. Is the problem following a user or specific PC? 
  5. Is the problem to do with slow performance in user's working folder (opening form, pending items)? 


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-Icon.png 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:

  1. Are all of the objects in the MarkView schema valid, including indexes? If not, send us a list of invalid objects and compilation errors.
    1. Use Support Tools to generate the Version Information output and use the save to file button on screen to save locally. 
  2. What is your database optimizer mode?
    1. CHOOSE
    2. RULE
    3. ALL ROWS
  3. If the MarkView Database Objects is version 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?
  4. Provide Technical Support 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';
  5. Is the database instance tuned?
    1. Have you gathered statspack snapshots/AWR reports?
    2. Is there anything in the report that shows problems?
      • Buffer waits
      • Buffer Hit Ratio
      • Library Hit Ratio
      • Lib Cache reloads
    3. Send us the complete Statspack Snapshot/AWR report, or at least the top wait events from the first page.
      1. 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;


Additional Information

Customers should also provide the following information to Kofax Technical Support:

  • Customers should send Support the output of the following:
    • select * from v$parameter;
    • init*.ora
    • 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:

Run the trace file through trace analyzer, and upload both raw trace file and trace analyzer output.

As well as:

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:
    1. 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).
    2. 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.
    3. 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.

    4. Run the spooled my_trace_off.sql to turn off tracing for the Kofax App Server DB sessions.
    5. Take the raw trace files, and run them through Trace Analyzer (preferred) or tkprof, generating the plan for the queries.
    6. 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.