Need information on how  AR System Server connects to the Database server.
How ARAdmin connects to the Database server and make the connections?

Legacy ID:KA372871

Note: This article applies for versions 8.x and lower since AR Server is C based.
For versions higher than 8.x please check the following article below:
Remedy - Server - How the NumberOfConnections are getting established by the ARAdmin user in the database?

The arserver product is multithreaded and each thread creates and maintains a dedicated database login.
So ARAdmin is a default schema owner of AR System tablespace in the database.

If for example AR System opens 20 threads with the database then you will see roughly 20 connections created by ARAdmin user with database separately.
Since we have 1=1 relationship, each database connection is opened when the thread starts and will not be closed until the thread terminates -- usually when the remedy application process is shutdown.
AR System does not use SQL Server connection pooling and arserver does not generates keepalives directly, this would be something done by the database client software:

Remedy cannot hold the connections if they are closed from database or somewhere in network.
As mentioned above AR System opens the connection to the database via the client software. The connection would only be closed if thread dies or our application service is shutdown.
There is no way to keep connection open with database even it is already closed by database.
Whenever there is closure in connection or the Database refuses more connections then we will get a timeout or database not available error message .

AR System does not manage connections with the database. When Remedy service stops then we expect that all connections should be closed by database automatically.

So having said this:
- Arserver starts, AR System makes a request to the database client software.
- Then sends a request to database server on Remedy Server's behalf and it returns back via the same channel.
- It opens number of SQL connections and keep them alive.
- When arserver needs to retrieve data from the Database, it will grab one of the connections (threads) and use it.
- If any thread is not being used by the Remedy application then that thread connection is kept in idle state in the database until any activity is triggered by same thread, then Remedy re-uses the connection.
- Whereas AR System does not open or close connections so frequently unless there is any failure in connection (like a Remedy thread dies on its own or there is a connectivity problem between Remedy and the Database server ).
- If any error is returned due to database connection or of any kind then related error will be displayed in remedy error logs. In other word we just trap the errors in arerror.log and not generating them.

Example:
Note: assuming ARAdmin is the Database user:
SQL> select sid, spid from v$session s, v$process p where s.paddr = p.addr and s.username like 'AR%';

       SID SPID
---------- ------------
       142 4023
       151 4153
       132 4167
       135 4174
       140 4176
       131 4183
       153 4185
       138 4187
       145 4189
       139 4192
       128 4194

       SID SPID
---------- ------------
       143 4202
       136 4204
       134 4208
       133 4212
       127 6729
       129 8707

- 17 rows selected. Which means 17 connections (sessions) to the database by the ARAdmin user.

The correlation with ar.conf/ar.cfg can be found by checking in the AR Server side.

[root@vm-rlnx-rds562 conf]# grep RPC- ar.conf

Plugin-Loopback-RPC-Socket: 390626
Private-RPC-Socket:  390601   1   1
Private-RPC-Socket:  390603   1   1
Private-RPC-Socket:  390620   2   6
Private-RPC-Socket:  390626   2   2
Private-RPC-Socket:  390635   2   3

Explanation:
390600 - Admin thread  1 connection
390601 - Alert thread 1 connection
390603 - Escalation thread - 1 connection
390620 - Fast queue thread - 6 connection
390635 - List queue thread - 3 connection
390626 - Plugin Loopback socket - 2 connection

There will be 3 or 4 other threads to handle background processes.
1+1+1+6+3+2+3 = 17 connections made to database via the ARAdmin user.
Note: there are chances that you may see more or less threads depending on your firewall configuration/network configuration etc.

The actual connection made from AR Server to the database is done as a user called ARAdmin that exists within the database.
This is the case regardless of how many users are logged in through Remedy clients to the AR Server.