I know such situations from the field. In this case, an NDS crash can be assumed. As long as the master is still OK, there are various options. First, check with NDS Trace and corresponding commands whether the background sync of the NDS is still working at all, whether there are obituraries stuck somewhere that are preventing the sync and whether there is perhaps a timestamp (future) or transitive vector problem or the NDS sync fails with -672, -663, -625 or whatever. If something is already recognizable as a problem here, there is usually only one call to open. Depending on the problem, the issue can really be resolved, but not via a forum at the green table. As I said, many things can be analyzed with an NDS trace. It may be that an xk3 ndsrepair on the replica server can sweep out the external references and then be recreated via an ndstrace = *b. I know too little about the disaster and as I said, green table.

Greetings George

I know such situations from the field. In this case, an NDS crash can be assumed. As long as the master is still OK, there are various options. First, check with NDS Trace and corresponding commands whether the background sync of the NDS is still working at all, whether there are obituraries stuck somewhere that are preventing the sync and whether there is perhaps a timestamp (future) or transitive vector problem or the NDS sync fails with -672, -663, -625 or whatever. If something is already recognizable as a problem here, there is usually only one call to open. Depending on the problem, the issue can really be resolved, but not via a forum at the green table. As I said, many things can be analyzed with an NDS trace. It may be that an xk3 ndsrepair on the replica server can sweep out the external references and then be recreated via an ndstrace = *b. I know too little about the disaster and as I said, green table.

Greetings George