Although this is a warning it is actually an error, the cdr define fails, the time delta between the servers is too large
15:24:03 CDR NIF site: 1 <grp_student3> clocks differ by -77279 seconds
15:24:03 Warning - The operating system time of day clock at the
remote site differs from the local site. This can
slow down the data-sync apply performace at the
target server. This happens only if timestamp or
stored procedure conflict resolution rules are
being used.
15:24:03 CDR NIF site: 1 <grp_student3> clocks differ by -77279 seconds
This is an easy one to miss especially if the machines are in different timezones
Back in the day the smart spaces didn't need to be unlogged but that is no longer the case so how do you fix it. It's an easy fix
onstat –g ddr onstat –g rqm BRIEF onstat –g smb lod
In the syscdr database, you need to examine the deltabdef table. The tabname, owner, and dbname are the names of the table that the delete table is a shadow of. The deltabid is the number portion of the delete tabe id. (the # part of cdr_deltab_######). The orphans can be identified by comparing the number part of cdr_del_###### with the deltabid within the deltabdef table. If the number is not found in the deltabdef column, then it is an orphan and can (or rather should) be dropped. N.B. If you manually delete the syscdr database, then you must manually drop the shadow delete tables as well. If this is not done, then you can run into a 57 error when trying to add replicates later on.
The preferred way to get rid of the syscdr DB is to run cdr remove (if ER is down) or cdr delete server (if ER is running).
Neat Trick
A neat trick to start HDR without backing up to somewhere real
ontape –s –L 0 –F –t STDIO | ssh <secondary> “. /etc/profile.d/ids_env.sh; ontape –p –t STDIO”