Salesforce

For Tridion Sites 9.1, how to fix broken mappings in the Discovery database?

« Go Back

Information

 
Article TypeSolution Article
Scope/EnvironmentTridion Sites 9.1 (also applicable to earlier and later product versions)
Symptoms/Context
The Discovery service contains certain configurations (other than Environment which is the root item) without a parent. This will cause issues when trying to load the parent item or in some cases batch requests from the  TopologyManager start to fail.

Symptoms of this are:
1. Batch request(s) fail with error message such as "The INSERT statement conflicts with the FOREIGN KEY constraint"
2. The Discovery logs contains errors such as 
No value found in the database for a non-nullable property: 'WebCapability' in the type: Tridion.WebDelivery.Platform.WebApplication
"An error occurred while trying to load the configuration resource 'Web'
com.sdl.delivery.configuration.ConfigurationException: Could not locate the root of the configuration"
3. The Content Service logs contains errors such as
{"error":{"code":"9000","message":"java.lang.RuntimeException: Not possible to retrieve the dynamic configuration"}}
4. The Content Service logs contains errors such as
Could not locate the root of the configuration.

To confirm whether the issue is due to data inconsistency in the Discovery service, check the following:
1. Browse to the Discovery service URL
http://<discoveryhost>:<discoveryport>/discovery.svc/ConfigurationItems?$filter=Area eq 'Web'&$expand=UsedBy
From the response of the query, the administrator needs to verify if there are entities with UsedBy being empty. Only Environment can have UsedBy as empty.  All other entities withempty UsedBy means that they don't have a linked parent (and are consequently an orphan).
2. Using a database Query
select * from CONFIGURATION_ITEM where ID<>'DefaultEnvironment' and ID not in 
(select distinct ITEM_ID from CONFIGURATION_ITEMS_LINKS) and ID not in (select distinct LINKED_ITEM_ID from CONFIGURATION_ITEMS_LINKS);
The above query should return NO rows, as only 'DefaultEnvironment' is required (DefaultEnvironment will not be returned in the query). If more rows are returned, then there are entities without a parent which have to be removed.
Resolution
Ensure there is a working Discovery database backup before performing the below steps.

1. Database cleanup.
If there are items other than DefaultEnvironment without a parent, they have to be removed from the CONFIGURATION_VALUE and CONFIGURATION_ITEM tables. Note that if the orphaned entry has a child in the CONFIGURATION_ITEMS_LINKS table, then the entire child tree needs to be removed.
select ID from CONFIGURATION_ITEM where ID<>'DefaultEnvironment' and ID not in (select distinct ITEM_ID from CONFIGURATION_ITEMS_LINKS) and ID not in (select distinct LINKED_ITEM_ID from CONFIGURATION_ITEMS_LINKS);
// Used ID's obtained above other than 'DefaultEnvionment' in the delete queries as in below example
// next 2 SQL commented due to provided better solution
// delete from CONFIGURATION_VALUE where ITEM_ID in ('id1','id2');
//  delete from CONFIGURATION_ITEM where ID in ('id1','id2');
// or even better
delete from CONFIGURATION_VALUE where ITEM_ID in (select ID from CONFIGURATION_ITEM where ID <> 'DefaultEnvironment' and ID not in (select distinct ITEM_ID from CONFIGURATION_ITEMS_LINKS) and ID not in (select distinct LINKED_ITEM_ID from CONFIGURATION_ITEMS_LINKS));
delete from CONFIGURATION_ITEM where ID in (select ID from CONFIGURATION_ITEM where ID <> 'DefaultEnvironment' and ID not in (select distinct ITEM_ID from CONFIGURATION_ITEMS_LINKS) and ID not in (select distinct LINKED_ITEM_ID from CONFIGURATION_ITEMS_LINKS));
//after doing that (2 previous rows) next query should now return 0 rows
select ID from CONFIGURATION_ITEM where ID<>'DefaultEnvironment' and ID not in (select distinct ITEM_ID from CONFIGURATION_ITEMS_LINKS) and ID not in (select distinct LINKED_ITEM_ID from CONFIGURATION_ITEMS_LINKS);
// To find child tree in CONFIGURATION_ITEM_LINKS, use the id obtained in first query
select * from CONFIGURATION_ITEMS_LINKS where ITEM_ID='id1';

2. Hotfix (Discovery service)
a. The above queries will fix the existing Discovery database but since there are mappings which have been removed, these have to be synced from the Topology database. To prevent future incidents, apply a Discovery hotfix* to better handle large batch requests.
- For 8.1.1 - CD_8.1.1.4472 or later
- For 8.5 - CD_8.5.0.4472 or later
- For 9.5 - CD_11.5.0_21391 (latest as of Nov 2021)
See KB article below for instructions on how to download the hotfix.
Where can I find hotfixes for SDL Tridion Sites/Web?
b.    Add FlushInterval**="1000" attribute to <Storage....> configuration and restart the discovery service
<Storage Class="com.tridion.storage.persistence.JPADAOFactory".... FlushInterval="1000">
* Note that the FlushInterval may need to be increased further depending on the number of mappings, for example 5000 or 10000.
** This hotfix includes catching the general exception on datalayer to rollback if there is an unexpected error. It also includes closing the entity manager in case of standalone transaction and adding the missing commit on deleteLink method.
c. Run the Sync-TtmCdEnvironment command to resync from the Topology Manager database.
d. Recheck for any orphaned items in Discovery DB after the sync.
Root Cause
Reference
Also see KB article In SDL Web 8.5, Topology mapping cannot be synchronized between the Topology and Discovery database when large amount of mapping is loaded and updated.
Also see KB article For Tridion Sites 9.1, error "unable to load the DynamicContentModule" while browsing the DXA 2.2 website
Also see KB article For Tridion Sites 9+, what is the unit of measure for FlushInterval, seconds?
An administrator may choose to rebuild the Discovery database entirely, instead of fixing the existing Discovery database.  For this see KB article For Tridion Sites 9.1, how to rebuild the Discovery database?
Previous version of this KB article is below for reference.


 
Attachment 1
Attachment 2 
Attachment 3 
Attachment 4 
Attachment 5 

Powered by