Multiple DB Service Agents

[Robert Richter]

Hello Community,

we use a DB Service Agent to fullfill the requirement of using VARA SQL objects.

This is a single DB Agent, which runs on one site of our automic servers.
If the server fails, a complex script moves the DB Service Agent to the other side.

Now we would try to install 2 other DB Service Agents on both sides and group them in a hostgroup object.

What we have determined after installing this two additional agents, that the scripts, which access the VARA SQL object fail,
because there wasn't any Login informations stored for those new agents.
It seems that there is a loadbalancing, or round robin mechanism, so sometime the VARA SQL object retrieves the old DB Service Agents, 
for which credentials are configured and sometimes it reaches the 2 new DB Service Agents and fail, because there aren't any configurations in the Login object.

So my question is, how can we tighten or fix the VARA SQL to use this specific DB Service Agent or subsequently the hostgroup?

Is a hostgroup even necessary or is it enough to have all DB Service Agents configured with the same jdbc Drivers and configs?

Thanks
Robert

[Christoph Rekers at Tricise]

Hi Robert

just to make sure: you started an sql agent with parameter -service ? => only if an SQL agent is started with this parameter it gets a "DB Service" that will be used by a VARA.SQL (not VARA.SQLI!  VARA.SQLI is actually a "server functionality", that doesn't require any agent. The AE always runs the SELECT only against its own database.)

• DB_Service agents can not be assigned to a HOSTG
• The AE selects the DB_Service agents using the round-robin method

• A DB_Service agent doesn't require to be enabled for any of your clients:
  

• Only if the CONN object used in the VARA.SQL doesn't contain any Login information a Login object needs to be used:
  
  
  
  
• When creating a CONN object for the DB in question, you can not choose or assign a DB_Service agent, the AE picks any of the existing agents when the VARA.SQL is executed
• when testing a DB-CONN any of the existing DB_Service agents connects to the DB and checks if the connection parameter provided are valid. If there's no DB_Service agent, the connection test can't be executed:
   
  Hope this helps ;-)
  
  Cheers Christoph