hendersj Acclaimed Contributor.
Acclaimed Contributor.

Re: Error -659 troubleshooting

On Tue, 03 Oct 2017 18:28:55 +0000, ab wrote:

> On 10/03/2017 11:26 AM, joe fortier wrote:
>>
>> FWIW, some more info about ndsrepair -R efforts The summary shows (on
>> one sample/representative replica)
>> NOTICE: 2259 more illegal timestamps found in current partition
>>
>> There are numerous timestamp errors of the form
>>
>> ERROR: Illegal timestamps were found in this replica.
>> You may need to run 'Repair Timestamps'
>> Value: 5bbf65dd, ID: 00008090, DN: OU=Students.O=Augsburg.T=AUGSBURG
>> Time stamp: October 11, 2018 03:01:49 PM ; rep # = 0004; event = f6ed
>>
>> The summary shows total errors = 33
>>
>> This is fairly consistent, which suggests that the error's are not
>> being resolved.

>
> Sure; the system will not change timestamps until the values change, and
> that's a problem when the changes will not come until the future,
> particularly when the "future" may be months/years out. You can wait,
> or you can delete/recreate the objects with problems (can be difficult),
> or you can declare a partition epoch which is a big deal, and should
> usually only be done when you are sure you want to, usually with Support
> guiding you. It is also good to be sure that the root cause is handled
> so this does not happen again long before you look into declaring
> epochs.
>
> Declaring an epoch with a lot of replicas is a bigger deal than with
> only a few. You can try to repair timestamps, but I am not convinced
> that will help; I do not ever remember using that a lot, so either I
> used it very little, or it is new (unlikely).


As I recall, it only really helps if you have future timestamps that are
a long time in the future. A -659 error won't be generated (or at least,
it wasn't generated) for data issues, generally.

But I also have a very vague memory of a situation where the error would
be thrown that seemed to me (at the time) to be incorrectly - and that
was a data corruption issue. I'd probably advise not messing with the
environment but opening a call with support and having someone look at
it. This is one of those situations where someone needs to dig into the
DIB to see the underlying cause of the error.

Jim
--
Jim Henderson, CNA6, CDE, CNI, LPIC-1, CLA10, CLP10
Novell/SUSE/NetIQ Knowledge Partner
0 Likes
Knowledge Partner
Knowledge Partner

Re: Error -659 troubleshooting

Jim Henderson wrote:

> As I recall, it only really helps if you have future timestamps that are
> a long time in the future.


Which is easy to find out by checking partition roots in iMonitor, btw.


--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
hendersj Acclaimed Contributor.
Acclaimed Contributor.

Re: Error -659 troubleshooting

On Thu, 05 Oct 2017 07:54:45 +0000, Lothar Haeger wrote:

> Jim Henderson wrote:
>
>> As I recall, it only really helps if you have future timestamps that
>> are a long time in the future.

>
> Which is easy to find out by checking partition roots in iMonitor, btw.


Yep, that's certainly true.

Jim

--
Jim Henderson, CNA6, CDE, CNI, LPIC-1, CLA10, CLP10
Novell/SUSE/NetIQ Knowledge Partner
0 Likes
hendersj Acclaimed Contributor.
Acclaimed Contributor.

Re: Error -659 troubleshooting

On Tue, 03 Oct 2017 18:28:55 +0000, ab wrote:

> On 10/03/2017 11:26 AM, joe fortier wrote:
>>
>> FWIW, some more info about ndsrepair -R efforts The summary shows (on
>> one sample/representative replica)
>> NOTICE: 2259 more illegal timestamps found in current partition
>>
>> There are numerous timestamp errors of the form
>>
>> ERROR: Illegal timestamps were found in this replica.
>> You may need to run 'Repair Timestamps'
>> Value: 5bbf65dd, ID: 00008090, DN: OU=Students.O=Augsburg.T=AUGSBURG
>> Time stamp: October 11, 2018 03:01:49 PM ; rep # = 0004; event = f6ed
>>
>> The summary shows total errors = 33
>>
>> This is fairly consistent, which suggests that the error's are not
>> being resolved.

>
> Sure; the system will not change timestamps until the values change, and
> that's a problem when the changes will not come until the future,
> particularly when the "future" may be months/years out. You can wait,
> or you can delete/recreate the objects with problems (can be difficult),
> or you can declare a partition epoch which is a big deal, and should
> usually only be done when you are sure you want to, usually with Support
> guiding you. It is also good to be sure that the root cause is handled
> so this does not happen again long before you look into declaring
> epochs.
>
> Declaring an epoch with a lot of replicas is a bigger deal than with
> only a few. You can try to repair timestamps, but I am not convinced
> that will help; I do not ever remember using that a lot, so either I
> used it very little, or it is new (unlikely).


As I recall, it only really helps if you have future timestamps that are
a long time in the future. A -659 error won't be generated (or at least,
it wasn't generated) for data issues, generally.

But I also have a very vague memory of a situation where the error would
be thrown that seemed to me (at the time) to be incorrectly - and that
was a data corruption issue. I'd probably advise not messing with the
environment but opening a call with support and having someone look at
it. This is one of those situations where someone needs to dig into the
DIB to see the underlying cause of the error.

Jim
--
Jim Henderson, CNA6, CDE, CNI, LPIC-1, CLA10, CLP10
Novell/SUSE/NetIQ Knowledge Partner
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.