Database DIP Timeout
The voice system and remote database ORACLE
connection is established when the voice system starts. After the
connection is established, the voice system does not keep track of
status changes on the remote machine. The connection between it and
the voice system is dropped if the remote machine is turned off or
rebooted. If the remote machine is shut down and rebooted while the
voice system is still active, the voice system detects this status
change only when calls come in to the system that involve remote
database access for call processing. The voice system attempts to
reestablish the remote connection and is not able to process calls
during this time.
In certain cases, the database DIP
(oraldb) may not receive a timely response from the server
machine. This may be due to a variety of factors, such as the
server machine being down, the server machine is operating slowly,
an application query of a large non-indexed table, network
congestion, etc.
While the DIP is waiting for a response from
the server machine, the message queue of the DIP may back up. A
full message queue (current maximum is 255) may result in
performance problems for the voice system.
In order to prevent this, the DIP is equipped
with a timeout mechanism. By default, the DIP will timeout every 45
seconds while waiting for a response. After the timeout, the DIP
deletes the messages currently queued and continues to wait for a
response from the database. The DIP continues to timeout every 45
seconds and to empty the message queue. After the default of 300
seconds, the DIP will automatically respawn and
reinitialize.
The 45- and 300-seconds timeout values can be
altered in /vs/data/ldbdip.rc file. This file is included
with the generic package and contains the following default
values:
FIRST_TMOUT=45
SECOND_TMOUT=300
You may change these default values to any
number that is appropriate for your database and applications. If
the ldbdip.rc file is missing, the DIP uses the default
timeout values of 45 and 300 seconds.
WARNING: Always stop the voice system
before shutting down the remote database machine to avoid an
unexpected interruption of service.
Database Cursors
An internal data structure called a database
cursor is used to monitor the point from which the DIP is reading
in a specific database table. One cursor is allocated for each read
of each database table by each channel running a service that
requires access to that database. The cursor remains assigned to
that table until the service ends on the channel for which the
cursor was allocated.
The number of cursors is tunable in the/oracle/dbs/initA.ora file ( open_cursors is a tunable
parameter). At least 500 cursors are supported in INTUITY
CONVERSANT voice system. Once the limit of cursors is reached,
database transactions do not complete successfully; that is, table
reads may fail and inserts or updates may not
occur.
Database Cursor
Calculations
To insure the integrity and consistency of
the data in the database, you must keep this limiting factor in
mind when you design your applications. Use the following formula
to determine the number of database tables that may be accessed by
an application with the voice system:
channel X read X cursor < 500
where:
- channel = number of channels running
application with database access
- read = number of read table operations
performed on different tables by applications (per
channel)
- cursor = number of cursors involved in read
table
NOTE: Multiple reads of the same table
use only one cursor.
The following are sample calculations using
various configurations and numbers of read table
operations.
- If you have a 24-channel system running an
application that performs four read table operations on four
different tables per channel, the calculation is:
24 4 4 4 1 = 96
Since 96 is less than 500, the database
operations proceed properly.
- If you have a 36-channel system running an
application that performs four read table operations on a single
table per channel, the calculation is:
36 4 1 4 1 = 36
Since 36 is less than 500, the database
operations proceed properly.
- If you have a 48-channel system running an
application with five Read table operations on five different
tables per channel, the calculation is:
48 4 5 4 1 = 240
In this case, if all 48 channels are
performing five read table operations, some database operations may
fail because of the multiple read table operations on the same
channels.
- An application developer wants to develop an
application that executed six read table operations on six
different tables per channel:
500 / (6 4 1) = 83.33
Therefore, the application can run on as many
as 80 channels before it encounters database access
problems.
- An application developer wants to develop an
application to run on 72 channels simultaneously:
500 / (72 4 1) = 6.94
Therefore, the application can perform up to
six read table operations on up to six different tables per channel
before it encounters database access problems.
