4 Replies Latest reply on Dec 6, 2018 7:23 AM by Catalin Pana

    After Remedy 18.08 upgrade error related to DB id

    Catalin Pana

      Hi everyone,

       

      After upgrading to v18.08 (9.1.06) of all the components (AR, AI, AC, ITSM, SLM, SRM) I am seeing an error in the arerror.log on all AR Servers:

       

      "> /* 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"

       

      I checked all the DB related parameters in the ar.conf files on the AR Servers, and everything is according to the environment to which the AR Servers are connected.

      Has anyone seen this also, and did you manage to find a wait to suppress these errors (or fix, if there is indeed anything to fix).

       

      Thanks

      Catalin

        • 1. Re: After Remedy 18.08 upgrade error related to DB id
          Cristian Baltoiu

          Hi Catalin,

          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.

          • 2. Re: After Remedy 18.08 upgrade error related to DB id
            Santosh Kumar Kumar

            This is fixed in 1808Patch1. Till then please ignore the error message.

            • 3. Re: After Remedy 18.08 upgrade error related to DB id
              Rahul (Remedy) Shah

              Hi

               

              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 

              1. DBName
              2. DB Hostname
              3. dbType

               

              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.

               

              Why mismatch?

               

              Lets take an example , we have two server in server group , lets assume ARSERVER-1 and ARSERVER-2

              Case1

               

              1. ar.conf ( or CCS ) of ARSEVER-1 has following name

               

              Db-name: ARSystem

              Db-Host-Name:  db-server123.xyz.com

              Db-Type: sqlserver

               

                2. ar.conf ( or CCS ) of ARSEVER-2 has following name

               

              Db-name: ARSystem

              Db-Host-Name:  db-server123

              Db-Type: sqlserver

               

              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.

               

              Case2

              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

              • 4. Re: After Remedy 18.08 upgrade error related to DB id
                Catalin Pana

                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