I have a customer with EV 9.0.2 that has built up a large backlog of items awaiting backup. I took a look at how they were doing their partition backups and identified some problems but that didn't explain the high number (over 7.5 million items). I ran queries against the watchfile and journalarchive tables to see what was there and came up with this:
indexcommited | backupcomplete | count |
0 | 0 | 64044 |
1 | 0 | 7623934 |
0 | 1 | 63882 |
itemsecured | count |
|
0 | 591032 |
|
1 | 7096946 |
|
I tried to replicate what was going on in my lab but couldn't. When I test in the lab I find that as items get archived, rows are added to watchfile with itemsecured=0 and to journalarchive with backupcomplete=0. After backups of the partitions, the watchfile rows get changed to itemsecured=1 first and then the corresponding journalarchive rows get updated to backupcomplete=1 and the watchfile rows are deleted. That's not what I'm seeing in the customer data. For some reason, the journalarchive table rows are never getting set to backupcomplete=1 and the watchfile rows are not getting purged. This would seem to indicate that the trigger files were picked up and processed but the second pass through the tables never occurred. Has anyone seen this before and knew of a cause/resolution?
thanks,
Mark