How does Service Desk communicate with the DBMS where the mdb is installed?
search cancel

How does Service Desk communicate with the DBMS where the mdb is installed?

book

Article ID: 26307

calendar_today

Updated On:

Products

CA IT Asset Manager CA Software Asset Manager (CA SAM) ASSET PORTFOLIO MGMT- SERVER SUPPORT AUTOMATION- SERVER CA Service Desk Manager - Unified Self Service CA Service Desk Manager CA Service Management - Asset Portfolio Management CA Service Management - Service Desk Manager

Issue/Introduction

How does Service Desk communicate with the DBMS where the mdb is installed?

 

 

 

Environment

Service Desk Manager 17.x

Resolution

Service Desk uses database agents to communicate with the DBMS where the mdb is installed. These agents provide the link between Service Desk and the database. This document will provide information about how this process works, and what configuration can be done.

Database agents and the Virtual Database process

Control of the Service Desk database agents is done by the Virtual Database process (bpvirtdb_srvr). When Service Desk starts, the bpvirtdb_srvr process starts an initial number of database agents. When the system is busy, the bpvirtdb_srvr can start more agents, and conversely, when the system is lightly loaded, it can stop agents until it gets back to the initial number of agents.

The bpvirtdb_srvr process starts two different sorts of agents:

  • Update agents - These agents are responsible for updating information in the mdb tables. By default there are 10 update agents. These are numbered 0 through to 9. 1 through to 9 are assigned to a particular database table:
    • Agent1=Call_Req
    • Agent2=Act_Log
    • Agent3=Change_Request
    • Agent4=Change_Act_Log
    • Agent5=Issue
    • Agent6=Issue_Act_Log
    • Agent7=Audit_Log, event_log, session_log
    • Agent8=EBR_FULLTEXT, EBR_FULLTEXT_ADM, BU_TRANS
    • Agent9=CREATE_INDEX

    Agent 0 is a general update agent, and will update any table which doesn't have an update agent assigned to it.

  • Select agents - These agents will handle any SELECT query for any database table.

The number of update agents is fixed for any Service Desk installation, whereas the number of select agents can be anywhere between the defined maximum and minimum.

Configuring the maximum number of database agents

To configure the maximum number of database agents, you need to edit two files:

$NX_ROOT/NX.env
$NX_ROOT/pdmconf/NX.env.tpl

(Since the NX.env file is re-created when you run pdm_configure, making the change in the .tpl file will ensure that the change is preserved, should pdm_configure be run at a later date).

You need to change the line:

@NX_MAX_DBAGENT=6

and modify the number from the default value of 6.

Note there is a comment in the NX.env that states

# Set NX_MAX_DBAGENT to a number between 6 and 10

This statement can partly be ignored. There is no maximum number of dbagents so the value can be set to higher than 10.
However, the more dbagents you configure the more resource you will be using up that could potentially be used by other processes.

Once you've done this, you then need to restart Service Desk for this to take effect.

Configuring the minimum number of database agents

To configure the minimum number of database agents, you need to edit two files:

pdm_startup.i
pdm_startup.i.tpl

(Again, since the pdm_startup.i file is re-created when you run pdm_configure, making the change in the .tpl file will ensure that the change is preserved, should pdm_configure be run at a later date).

You need to change the line:

command = "$NX_ROOT/bin/bpvirtdb_srvr -n 6 -x $NX_MAX_DBAGENT"

and modify the number from the default value of 6. Once you've done this, you then need to restart Service Desk for this to take effect.

Configuring update agents

Update agents are configured in the NX.env file, in this section:

    # NX_VIRTDB_AGENTn defines update agents that manage
    # all updates for a particular table(s).
    # These agents are not part of $NX_MAX_DBAGENT count
    @NX_VIRTDB_AGENT1=Call_Req
    @NX_VIRTDB_AGENT2=Act_Log
    @NX_VIRTDB_AGENT3=Change_Request
    @NX_VIRTDB_AGENT4=Change_Act_Log
    @NX_VIRTDB_AGENT5=Issue
    @NX_VIRTDB_AGENT6=Issue_Act_Log
    @NX_VIRTDB_AGENT7=Audit_Log, event_log, session_log
    @NX_VIRTDB_AGENT8=EBR_FULLTEXT, EBR_FULLTEXT_ADM, BU_TRANS
    @NX_VIRTDB_AGENT9=CREATE_INDEX

Only agents 1 through to 9 are specified. Agent 0 always starts, and is not assigned to any particular table. If you find that your Service Desk usage pattern means that a table without a dedicated update agent is being heavily used, and you want to add a dedicated update agent, you simply add another line to this section:

    @NX_VIRTDB_AGENT10=<another table>

You should only ever specify one update agent per database table. More than one may seem like a way of updates being done more quickly, but it can also lead to deadlock situations.

When making any configuration changes, you need to be cautious as the wrong change can massively degrade performance. If you have any doubt, please seek help from CA before making these changes.