BMC has introduced the Remedy Management console, where you can verify and update the AR System settings in a new way.
There are some Global Settings and Local Settings Managing AR Server Group components by setting global-level and local-level configurations - Documentation for Remedy Ac…
In the case of an recently upgraded environment, the if you look at the Db-Host-Name in Server Group Configuration, it's still a Local setting and you can see it highlighted in yellow, while the Global setting is null.
What you should do is, configure the Db-Host-Name as Global Setting, this should get rid of the message in arerror.log
L.E. The error still shows up in the logs after a while, even with modified settings.
This is fixed in 1808Patch1. Till then please ignore the error message.
Starting 1808 release, there is a new column added for the database table "servgrp_resources " by name "dbResouces"
What does this column contains?
This column will contain an GUID , which will be combination of
- DB Hostname
Now its expected that , all the nodes in the server group ( i.e. all the entries in the database table "servgrp_resources" column dbResouces should have same GUID)
So now when ever AR server is going to start , its going to check uniqueness of this GUID for all the rows and its going to throw an error if does not match , the error will look like this
"> /* Tue Dec 04 2018 10:00:20.1930 */ DB id of current server is not matching with other servers, Please check Db-Host-Name, it should eaxclty match for all the servers in server group"
Why was this needed?
Many a time , whenever database is exported and imported from one machine to other machine ( i.e. from Dev to QA / Prod to QA) , it was found that all the invalid/ old entries where there in this tables "server_resources" and it was creating a problem. although as a best practice it was recommended that it should clean up when ever database was re-used. so this will be an extra hint to check this and clean it up.
Lets take an example , we have two server in server group , lets assume ARSERVER-1 and ARSERVER-2
- ar.conf ( or CCS ) of ARSEVER-1 has following name
2. ar.conf ( or CCS ) of ARSEVER-2 has following name
Please note that ARSEVER-1 has db-host name as "db- server123.xyz.com" (with FQDN) and ARSEVER-2 as "db-server123" ( without FQDN) , so in this case the GUID generated will be NOT same , and you will see and error in arerror logs ,if this is the case , you need to fix it.
The case where database was copied from production machine to a QA machine and the entries where not cleaned up , so in this case its GUID ID of Production and QA machine will have different , so in this case you need to delete Production entries on a QA box.
Will be there any problem if there is mismatch ?
Yes , in both the case there are some serious problem, like one server which has different GUID might not be treated as a member of server group. its recommended to fix this issue.
What was the problem in 1808?
As Santosh said there was some problem in 1808 related to message , even if all the node has SAME entries for db-name,db-hostname, db-type for all the nodes, still it was throwing an error in arerror.log in this case please ignore it , its fixed in 1808Patch1 , so after 1808Patch1 it will throw error only if it has different GUID ID.
Hope this helps
Thanks Rahul for the detailed explanation.
We know about the issue when servers in different server groups/environment still communicate with each other if you don't clean the server group tables
For now the DB ID is identical for both servers, so I will check if the error appears after we deploy the patch for 18.08.
We were fairly certain it was a false/positive as there was no issue with the application in that environment.
BR / Catalin