KnowledgeBase/CII.md

@@ -1539,7 +1539,7 @@ Datapoints are stored in two databases: a document-database (permanent store) fo
 
 **Solution 1**
 
-There is a good chance you can delete the datapoint to clean up the situation (as of [ECII-303](https://jira.eso.org/browse/ECII-303)):
+With DevEnv 4, which contains [ECII-500](https://jira.eso.org/browse/ECII-500), you can probably delete the datapoint to clean up the situation:
 
 ```
 #!/usr/bin/env python
@@ -1556,29 +1556,53 @@ oldb_client.delete_data_point(uri)
 
 **Solution 2**
 
-If the above didn't help, find out which "half" of the datapoint exists:
+If the above didn't help, find out which "half" of the datapoint exists.
 
 1.  The current value exists, and the metadata is missing. This is the case when upgrading DevEnv/CII without deleting the Redis cache.
 
-Run the following command:
-
-Note: enter a search-expression matching the datapoint URI, in the example this is "tempser3".
+2.  The metadata exists, and the current value is missing
 
+Define the following shell functions:
 ```
-# confirm that this is the cause of the problem
-redis-cli KEYS *tempser3*
+function oldb_ela_list { curl -s -X GET localhost:9200/configuration_instance/_search?q=data.uri.value:\"$1\" | jq -r '.hits.hits[]._id' | sort ; }
+
+function oldb_ela_del { curl -s -X POST localhost:9200/configuration_instance/_delete_by_query?q=data.uri.value:\"$1\" | jq -r '.deleted' ; }
+
+function oldb_red_list { redis-cli --scan --pattern *$1* ; }
+
+function oldb_red_del { redis-cli --scan --pattern *$1* | xargs redis-cli del ; }
 ```
 
-If the command is showing the problematic key, we run a similar command to remove that key from the store:
+Then check if the problematic key is in the volatile store:
+
+```
+# Search for path component of dp-uri (here: "device")
+$ oldb_red_list device
+... output will be e.g.:
+/sampleroot/child/device/doubledp444
+/sampleroot/child/device/doubledp445
+/sampleroot/child/device/doubledp111
+/sampleroot/child/device/doubledp2222
 
+# If the problematic key is in the list, delete it:
+$ oldb_red_del device/doubledp444
 ```
-# if so, delete the offending datapoint
-redis-cli --scan --pattern *tempser3* | xargs redis-cli del
+
+Otherwise, check if the problematic key is in the permanent store:
+
 ```
+# Search for path component of dp-uri (whole-word search, e.g. "dev" would not match)
+$ oldb_ela_list device
+... output e.g.:
+oldb___datapoints___sampleroot___child___device___doubledp446___1
 
-2.  The metadata exists, and the current value is missing
+# Delete the offending metadata
+$ oldb_ela_del doubbledp446
+
+# After deletion, restart the internal config server
+$ sudo cii-services stop config ; sudo cii-services start config
+```
 
-Update: As of [ECII-303](https://jira.eso.org/browse/ECII-303), this should no longer be necessary, since the OLDB will make an attempt to automatically re-instate the current value that is missing.
 
 **Solution 3**