Foliveirag Absent Member.
Absent Member.
1847 views

Repository Synchronization alarm at Control Center

Hi,

We´ve a monitoring solution based on AppManager 8.2. Solution has a database server to allocate QDB.
Synchronization Errors:
Component:
DB_SERVER_NAME.QDB

STATUS: -9999

Time occurred: it´s happening again and again

Synchronization Command:
EXEC dbo.SyncViewServerGroup N'DB_SERVER_NAME.QDB'

Error message:
[SQL COMMAND: EXEC dbo.SyncViewServerGroup N'DB_SERVER_NAME.QDB'] SyncViewServerGroup: Insert DSViewServerGroup failed.SQLError= Violation of PRIMARY KEY constraint 'PK_DSViewServerGroup'. Cannot insert duplicate key in object 'dbo.DSViewServerGroup'. The duplicate key value is (DB_SERVER_NAME.QDB, 1034, 0). (SQL severity 18)
[SQL COMMAND: EXEC dbo.SyncViewServerGroup N'DB_SERVER_NAME.QDB'] SyncViewServerGroup: Insert DSViewServerGroup failed. SQL Error: SyncServerTree: statement failed. SQL Error: Cannot insert the value NULL into column 'ParentObjID', table 'tempdb.dbo.#ServerTree_________00000001A096';column does not allow nulls. INSERT fails. (SQL severity 18).

How could we troubleshoot this issue?

thank you,
0 Likes
5 Replies
Micro Focus Expert
Micro Focus Expert

Re: Repository Synchronization alarm at Control Center

Foliveirag on %datetime% wrote:

>
>Hi,
>
>We�ve a monitoring solution based on AppManager 8.2. Solution has a
>database server to allocate QDB.
>Synchronization Errors:
>Component:
>DB_SERVER_NAME.QDB
>
>STATUS: -9999
>
>Time occurred: it�s happening again and again
>
>Synchronization Command:
>EXEC dbo.SyncViewServerGroup N'DB_SERVER_NAME.QDB'
>
>Error message:
>[SQL COMMAND: EXEC dbo.SyncViewServerGroup N'DB_SERVER_NAME.QDB']
>SyncViewServerGroup: Insert DSViewServerGroup failed.SQLError=
>Violation of PRIMARY KEY constraint 'PK_DSViewServerGroup'. Cannot
>insert duplicate key in object 'dbo.DSViewServerGroup'. The duplicate
>key value is (DB_SERVER_NAME.QDB, 1034, 0). (SQL severity 18)
>[SQL COMMAND: EXEC dbo.SyncViewServerGroup N'DB_SERVER_NAME.QDB']
>SyncViewServerGroup: Insert DSViewServerGroup failed. SQL Error:
>SyncServerTree: statement failed. SQL Error: Cannot insert the value
>NULL into column 'ParentObjID', table
>'tempdb.dbo.#ServerTree_________00000001A096';column does not allow
>nulls. INSERT fails. (SQL severity 18).
>
>How could we troubleshoot this issue?
>
>thank you,



It sounds like you have some orphan objects preventing the sync between
the QDB and NQCCDB to successfully complete.

Please send an email to support@netiq.com with the above information.
We can open a support ticket and provide you with some queries to
verify and then resolve the issue.

--ebell
0 Likes
andy_doran Absent Member.
Absent Member.

Re: Repository Synchronization alarm at Control Center

Foliveirag;2451797 wrote:
Hi,

We´ve a monitoring solution based on AppManager 8.2. Solution has a database server to allocate QDB.
Synchronization Errors:
Component:
DB_SERVER_NAME.QDB

STATUS: -9999

Time occurred: it´s happening again and again

Synchronization Command:
EXEC dbo.SyncViewServerGroup N'DB_SERVER_NAME.QDB'

Error message:
[SQL COMMAND: EXEC dbo.SyncViewServerGroup N'DB_SERVER_NAME.QDB'] SyncViewServerGroup: Insert DSViewServerGroup failed.SQLError= Violation of PRIMARY KEY constraint 'PK_DSViewServerGroup'. Cannot insert duplicate key in object 'dbo.DSViewServerGroup'. The duplicate key value is (DB_SERVER_NAME.QDB, 1034, 0). (SQL severity 18)
[SQL COMMAND: EXEC dbo.SyncViewServerGroup N'DB_SERVER_NAME.QDB'] SyncViewServerGroup: Insert DSViewServerGroup failed. SQL Error: SyncServerTree: statement failed. SQL Error: Cannot insert the value NULL into column 'ParentObjID', table 'tempdb.dbo.#ServerTree_________00000001A096';column does not allow nulls. INSERT fails. (SQL severity 18).

How could we troubleshoot this issue?

thank you,


It looks like you have 2 sync errors. The first one (working backwards) is with the ServerTree sync. Here the procedure "CC_SyncServerTree" is executed in the QDB and the results put into the ServerTree table in the CCDB. Every object inserted here should have a ParentObjID but the error says that at least one does not. I have seen this happen with a custom discovery - have you got any custom discoveries running?

You may be able to find out more by running the procedure manually and verifying the results. Try this query in the QDB. It *should* return no results. Anything it returns needs to be looked into:-

-- SQL START
declare @ServerTree table (RootMachineObjID int, RootSrvObjID int, ObjID int, JobCount int, C1 int, C2 int, C3 int, C4 int, ParentObjID int, Status int, ModTime int, SyncTime datetime, R1 int, R2 nvarchar(1204), Name varchar(128), FCObjID int, RootDeviceObjID int)
insert @ServerTree
exec CC_SyncServerTree 0

select
O.ObjID,
O.Name,
Status = convert(varbinary, O.Status),
TypeName = T.Name
from
@ServerTree S
inner join dbo.Object O
on O.ObjID = S.ObjID
inner join dbo.ObjectType T
on T.TypeID = O.TypeID
where
S.ParentObjID is null
order by
O.Name

-- SQL END

The TypeName for any row returned might help identify the problem objects and what discoveries they came from. Was this a QDB that was upgraded to 8.2 from a previous version? (prior to 8.2 ParentObjID was not part of the Object table so for any existing objects this should have been set in the upgrade).

For the other sync issue, the problem seems to be that some duplicate data is being picked up from the QDB and we are expecting unique rows for the insert into the CCDB. The sync process here is picking up Views and Server Groups to be inserted into the DSViewServerGroup table in the CCDB. The ObjID or ViewID and Type should be unique in the QDB and then is combined with the QDB Repository name in the CCDB (so there the ObjID and Type might not be unique, but when combined with the Reposiroty name - should become unique). The error suggests that the QDB View with ViewID 1034 is not unique here which would be odd. You can run the following SQL in the QDB:-

-- SQL START
declare @VSG table (VSGID int, Type int, VSGName varchar(128), PathToName varchar(max), ModTime int, Status int)
insert @VSG
exec dbo.CC_SyncViewServerGroup

declare @VSG2 table (VSGID int, Type int)
insert @VSG2
select
VSGID,
Type
from
@VSG
group by
VSGID,
Type
having count(1) > 1

select
B.VSGID,
B.Type,
B.VSGName,
B.PathToName,
B.ModTime,
Status = convert(varbinary, B.Status)
from
@VSG2 A
inner join @VSG B
on B.VSGID = A.VSGID
and B.Type = A.Type
-- SQL END

Again - this should return nothing. Anything it does return is "suspect". A Type of 0 means that the row refers to a View (and then VSGID is the ViewID). A Type of 1 means the row refers to a Server Group and then the VSGID is the ObjID of that Server Group.

If nothing is returned from that query you can try looking specifically for the row in the CCDB:-

-- SQL START
select * from DSViewServerGroup where ViewServerGroupID = 1034 and Type = 0
-- SQL END

This should return no more than one row per QDB.

The sync process should be updating this row if it exists in the CCDB and creating it if not. So the suspicion is that somehow the row appears twice in the QDB query ....

Unless it becomes obvious from what the above queries return, it would be faster to log a call with TS to figure out the issues here...
0 Likes
Foliveirag Absent Member.
Absent Member.

Re: Repository Synchronization alarm at Control Center

andy_doran;2451942 wrote:
It looks like you have 2 sync errors. The first one (working backwards) is with the ServerTree sync. Here the procedure "CC_SyncServerTree" is executed in the QDB and the results put into the ServerTree table in the CCDB. Every object inserted here should have a ParentObjID but the error says that at least one does not. I have seen this happen with a custom discovery - have you got any custom discoveries running?

You may be able to find out more by running the procedure manually and verifying the results. Try this query in the QDB. It *should* return no results. Anything it returns needs to be looked into:-

-- SQL START
declare @ServerTree table (RootMachineObjID int, RootSrvObjID int, ObjID int, JobCount int, C1 int, C2 int, C3 int, C4 int, ParentObjID int, Status int, ModTime int, SyncTime datetime, R1 int, R2 nvarchar(1204), Name varchar(128), FCObjID int, RootDeviceObjID int)
insert @ServerTree
exec CC_SyncServerTree 0

select
O.ObjID,
O.Name,
Status = convert(varbinary, O.Status),
TypeName = T.Name
from
@ServerTree S
inner join dbo.Object O
on O.ObjID = S.ObjID
inner join dbo.ObjectType T
on T.TypeID = O.TypeID
where
S.ParentObjID is null
order by
O.Name

-- SQL END

The TypeName for any row returned might help identify the problem objects and what discoveries they came from. Was this a QDB that was upgraded to 8.2 from a previous version? (prior to 8.2 ParentObjID was not part of the Object table so for any existing objects this should have been set in the upgrade).

For the other sync issue, the problem seems to be that some duplicate data is being picked up from the QDB and we are expecting unique rows for the insert into the CCDB. The sync process here is picking up Views and Server Groups to be inserted into the DSViewServerGroup table in the CCDB. The ObjID or ViewID and Type should be unique in the QDB and then is combined with the QDB Repository name in the CCDB (so there the ObjID and Type might not be unique, but when combined with the Reposiroty name - should become unique). The error suggests that the QDB View with ViewID 1034 is not unique here which would be odd. You can run the following SQL in the QDB:-

-- SQL START
declare @VSG table (VSGID int, Type int, VSGName varchar(128), PathToName varchar(max), ModTime int, Status int)
insert @VSG
exec dbo.CC_SyncViewServerGroup

declare @VSG2 table (VSGID int, Type int)
insert @VSG2
select
VSGID,
Type
from
@VSG
group by
VSGID,
Type
having count(1) > 1

select
B.VSGID,
B.Type,
B.VSGName,
B.PathToName,
B.ModTime,
Status = convert(varbinary, B.Status)
from
@VSG2 A
inner join @VSG B
on B.VSGID = A.VSGID
and B.Type = A.Type
-- SQL END

Again - this should return nothing. Anything it does return is "suspect". A Type of 0 means that the row refers to a View (and then VSGID is the ViewID). A Type of 1 means the row refers to a Server Group and then the VSGID is the ObjID of that Server Group.

If nothing is returned from that query you can try looking specifically for the row in the CCDB:-

-- SQL START
select * from DSViewServerGroup where ViewServerGroupID = 1034 and Type = 0
-- SQL END

This should return no more than one row per QDB.

The sync process should be updating this row if it exists in the CCDB and creating it if not. So the suspicion is that somehow the row appears twice in the QDB query ....

Unless it becomes obvious from what the above queries return, it would be faster to log a call with TS to figure out the issues here...


Hi,

Thank you for your quick response,

The result of the first query is the following:

ObjID Name Status TypeName
1 26631 local 0x10000000 NETWORKDEVICE_RoutingProtocol
2 26633 local 0x10000000 NETWORKDEVICE_RoutingProtocol
3 26635 local 0x10000000 NETWORKDEVICE_RoutingProtocol
4 26637 local 0x10000000 NETWORKDEVICE_RoutingProtocol

And the results of the second query are the following:

VSGID Type VSGName PathToName ModTime Status
1 0 0 Master Master 1418652480 0x00000000
2 0 0 local local 1481933378 0x10000000
3 0 0 local local 1481933378 0x10000000
4 0 0 local local 1482019842 0x10000000
5 0 0 local local 1482019842 0x10000000
6 1034 0 local local 1489362017 0x10000000
7 1034 0 local local 1489362017 0x10000000
8 1034 0 local local 1489362017 0x10000000
9 1034 0 local local 1489362017 0x10000000
10 1059 0 NetworkDevice NetworkDevice 1421252352 0x00000000
11 1059 0 local local 1481933378 0x10000000
12 1059 0 local local 1481933378 0x10000000
13 1059 0 local local 1482019842 0x10000000
14 1059 0 local local 1482019842 0x10000000
15 1041 0 local local 1489362020 0x10000000
16 1041 0 local local 1489362020 0x10000000
17 1041 0 local local 1489362020 0x10000000
18 1041 0 local local 1489362020 0x10000000
19 1101 0 local local 1489362024 0x10000000
20 1101 0 local local 1489362024 0x10000000
21 1101 0 local local 1489362024 0x10000000
22 1101 0 local local 1489362024 0x10000000
23 1033 0 local local 1489362014 0x10000000
24 1033 0 local local 1489362014 0x10000000
25 1033 0 local local 1489362014 0x10000000
26 1033 0 local local 1489362014 0x10000000

How could we solve this synchronization issue?

Thank you in advance,
0 Likes
andy_doran Absent Member.
Absent Member.

Re: Repository Synchronization alarm at Control Center

Foliveirag;2452684 wrote:
Hi,

Thank you for your quick response,

The result of the first query is the following:

ObjID Name Status TypeName
1 26631 local 0x10000000 NETWORKDEVICE_RoutingProtocol
2 26633 local 0x10000000 NETWORKDEVICE_RoutingProtocol
3 26635 local 0x10000000 NETWORKDEVICE_RoutingProtocol
4 26637 local 0x10000000 NETWORKDEVICE_RoutingProtocol

And the results of the second query are the following:

VSGID Type VSGName PathToName ModTime Status
1 0 0 Master Master 1418652480 0x00000000
2 0 0 local local 1481933378 0x10000000
3 0 0 local local 1481933378 0x10000000
4 0 0 local local 1482019842 0x10000000
5 0 0 local local 1482019842 0x10000000
6 1034 0 local local 1489362017 0x10000000
7 1034 0 local local 1489362017 0x10000000
8 1034 0 local local 1489362017 0x10000000
9 1034 0 local local 1489362017 0x10000000
10 1059 0 NetworkDevice NetworkDevice 1421252352 0x00000000
11 1059 0 local local 1481933378 0x10000000
12 1059 0 local local 1481933378 0x10000000
13 1059 0 local local 1482019842 0x10000000
14 1059 0 local local 1482019842 0x10000000
15 1041 0 local local 1489362020 0x10000000
16 1041 0 local local 1489362020 0x10000000
17 1041 0 local local 1489362020 0x10000000
18 1041 0 local local 1489362020 0x10000000
19 1101 0 local local 1489362024 0x10000000
20 1101 0 local local 1489362024 0x10000000
21 1101 0 local local 1489362024 0x10000000
22 1101 0 local local 1489362024 0x10000000
23 1033 0 local local 1489362014 0x10000000
24 1033 0 local local 1489362014 0x10000000
25 1033 0 local local 1489362014 0x10000000
26 1033 0 local local 1489362014 0x10000000

How could we solve this synchronization issue?

Thank you in advance,


I would advise you to log this issue with Technical Support. The problems look like they are both related to a NetworkDevice discovery, specifically with these objects:-

ObjID Name Status TypeName
1 26631 local 0x10000000 NETWORKDEVICE_RoutingProtocol
2 26633 local 0x10000000 NETWORKDEVICE_RoutingProtocol
3 26635 local 0x10000000 NETWORKDEVICE_RoutingProtocol
4 26637 local 0x10000000 NETWORKDEVICE_RoutingProtocol


It might be as simple as using the UI to delete these 4 objects and re-running the discovery (or just re-running the discovery). But might need these objects to be updated in the database. And doing that through instructions in the forum is not a good idea. TS can walk through the steps required.

For some reason these objects have no Parent set in the Object table. So the first thing to do would be to see if they have a Parent set in the ViewHierarchy table by running this query in the QDB:-

-- SQL START
select
O.ObjID,
ObjectName = O.Name,
ObjectStatus = convert(varbinary, O.Status),
HStatus = convert(varbinary, H.Status),
O.ParentObjID,
O.RootMachineObjID,
V.ViewID,
ViewName = V.Name,
ParentObjIDFromH = H.ParentObjID,
ParentName = P.Name,
ParentStatus = convert(varbinary, P.Status),
MachineName = M.Name,
ParentMachineName = PM.Name,
PMStatus = convert(varbinary, PM.Status)
from
dbo.Object O with (nolock)
inner join dbo.ViewHierarchy H with (nolock)
on H.ObjID = O.ObjID
inner join dbo.Views V
on V.ViewID = H.ViewID
left join Object P with (nolock)
on P.ObjID = H.ParentObjID
left join Object M with (nolock)
on M.ObjID = O.RootMachineObjID
left join Object PM with (nolock)
on PM.ObjID = P.RootMachineObjID
where
O.ObjID in (26631, 26633, 26635, 26637)
order by
O.ObjID,
V.ViewID
-- SQL END

This should return a Parent for the Objects in the Master View (and that is what should be set as the parent in the Object table but appears not to be). So it's possible also that if this does return valid parents in from the Master view, those Parents could be manually set in the Object table. But again - doing that involves updating the Object table manually and that should not be done on the basis of information or instructions through the forum.
0 Likes
Foliveirag Absent Member.
Absent Member.

Re: Repository Synchronization alarm at Control Center

Thank you for your time and advice, I´ll do that so.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.