Resource and Maintenance Problems

Good performance requires planning and regular maintenance. Make sure your operating system is configured with sufficient resources for Vector. Insufficient system resources cause poor performance or prevent Vector from starting.

The following tools can help you identify operating system resource problems:

• Review the minimum requirements for a basic Vector installation given in the Readme file. If your particular environment requires more resources, use the Vector utilities to verify that there are enough resources.

• System resources can be monitored by some operating system utilities. Syntax details are described in Linux Operating System Utilities.

pstat utility—to display the status of Linux system tables and system swap space

• sar utility—to display activity of various system resources such as CPU utilization, swapping activity, and disk activity.

• show memory—displays the system memory resources and the amount of non-paged dynamic memory (total, free and in use).

• show process/id=pid/continuous—displays the amount of page faulting, working set, buffered I/O, and direct I/O the server is doing.

• show device—indicates if a particular disk drive is out of disk space.

• show device /files—if there is a problem starting an installation, this command can be used to make sure that a Vector process is not holding on to a mailbox.

The installation utility allows the examination of all Vector installed images, showing the amount of global pages and sections available and used.

If Vector seems slow or unresponsive for no apparent reason, system resources may be insufficient. Follow these steps to diagnose the problem. Write down any error messages you receive when performing these steps:

a. First display the server_number of your DBMS Server using the iinamu utility:

b. Connect to the DBMS Server monitor by typing the command:

c. To see the DBMS Server sessions, at the iimonitor prompt type:

d. Check the status of the sessions to determine which one is making excessive use of the server. (You can use VDBA to check session status.)

For syntax details, see the sections iimonitor and iinamu in the Command Reference.

2. If repeated “show sessions” commands in iimonitor show that the query session is continually in a CS_EVENT_WAIT (LOCK) state, the problem involves concurrency and locking.

Alternatively, you can use the VDBA Performance Monitor to check for this problem.

a. Select Servers in the left pane of the Performance Monitor.

3. If the session alternates between CS_EVENT_WAIT and CS_COMPUTABLE, this indicates that the query is processing. However, if the query is taking an excessive amount of time, set up a trace on it, as described in Trace Utilities.

• Interactively, use Ctrl+C and wait.

• In batch or background mode, use the following command to terminate:

Windows: In the Task Manager, highlight iidbmst and click on End Process

The command format “stop proc” must be used only as a last resort. Use of this option can cause more problems than it solves.

• Rerun the query. This outputs a query execution plan.

• Alternatively, start an SQL window on the database in VDBA and click the Display Query Execution Plan button to graphically display the query plan.

• Interrupting a query requires some time because Vector is optimized to commit rather than back out of transactions. It takes at least as long to back out of a transaction as to process the transaction normally. The transaction must be fully backed out before sessions can resume and locks are freed.

4. It is useful to note whether the query runs differently when called from other Vector tools. For example, try issuing the same query from Interactive SQL, and Embedded SQL

5. Determine if you can access all of the data in the tables in all components of the query.

This verifies that Vector can sequentially access every row in the table and indicates that other access paths (secondary indexes, hash pointers, B-Tree page pointers, and so on) can cause the problem. Queries using restrictive where clauses probably are using these secondary access methods.

b. Check for permits that apply to this data by typing the following command from the Terminal Monitor: