recover expired segment docs

[gmcgee]

Has anyone had to recover all documents from expired segments.  I have a backup of the arscache from before the segments expired, and am looking for a way to restore the documents to the app group (updated with an extended expiry date). 
Is restoring the backup arscache and index to another system, and then exporting the only option?
Thanks for any alternate suggestions.

[Justin Derrick]

Recovery is complicated.  Can you give us a little more information about what you have (cache backup, what about database & AG metadata), and how the data was lost (deleted AG, bad retention, etc.), and which platforms and database and CMOD versions?

-JD.

[gmcgee]

It was a correct arsmaint expiry of a segment as specified in the application group that happened last week.  But the users would like to keep the documents for that app group.
This shows in the log entry.
Application Group Segment Expire:  Name(blah-blah) Agid(5011) Seg(DAA8)

I have a tar of the full arscache from 3 weeks ago before the expiry (we are cache only).  And we have daily full online db2 backups.  This is AIX 7.1 with CMOD 9.0.

Do you think I should be able to restore the arscache tar back to our dev system, allocate a production instance of a recovered db2 database there, and then replace the config files with production ones.  Would that be enough to start the dev system with the prod data from before the segments expired?  Don't want to spend time on this if I'm missing something basic.  Thx!

[Alessandro Perucchi]

Basically, in your test system you might need to do the following:

- Restore the tablespace containing the segment table DAA8. If you don't have a tablespace per table for the segments, then you will need to restore the complete database.
- Restore the table ARSSEG

So with the table ARSSEG you can discover the row where TABLE_NAME = 'DAA8', this row will need to be put exactly as is in the target ARSSEG.
The table DAA8, will need to be created and filled with the data in the target system (db2dump and db2look are your friend here...)

Concerning the data, you will need to do basically a "SELECT DISTINCT DOC_NAME FROM DAA8", to get the name of the objects in the cache that you need to extract.
Then you can add them back in the target cache FS. Be aware that you need to relink them in the retr directory.
AND in addition to that, you must ensure that the owner/permission are correct in the cache.

Then, once you have that, you can retrieve your documents, BUT BE AWARE that the next time you do a "arsmaint -c" or/and "arsmaint -d", you will loose all your documents again...
To avoid that you can simply use "ARSMAINT" with the option -g in order to tell CMOD which Application Group is allowed to expire or not. and not include this specific application group.
And also to change in the application group the retention of documentation / cache to a bigger number...

Hope that will help you a little bit to solve your problem.

Cheers,
Alessandro

[gmcgee]

Thanks - this is VERY helpful.
We'll try this method right away, given required approvals.

[gmcgee]

We've come down to using this method, and when looking at re-applying the arscache entries, it appears that they are all still there.  Does that make sense?  The db2 segments have been removed for the AG in the database, but after recovering them and cache to another system, and tracking down the matching cache entries (preparing for a large copy session), the current production arscache seems to still contain the no-longer-indexed cache entries.  Shouldn't arsmaint have deleted them also?  Are they scheduled to be removed at a later date, or is there some kind delete only when the space is required going on.  Can we unmark that if it is the case. 

Not that I'm complaining about them still being there, it will save a lot of work.
 
Thanks.

[Justin Derrick]

That's odd, but as long as you restore the database records, you should be good to go.  CMOD typically doesn't delete objects from the cache for which it has records in the database.  (TSM is a different matter though.)

-JD.

[gmcgee]

We ran the same arsmaint on the recovered system, and it deleted the same segments, as expected.

Then we updated the database with the missing segments (tables).
CMOD started right up, and I can query the application group, but the CMOD client can not find the old documents.
I can run sql on the segments and they seem fine.

Can you think of something else that might need to be updated in the database to get the original segments to resolve?

I'll have t see if there are any log messages.

Thanks

[gmcgee]

Looks like the arsseg table index and contents have to be restored for the missing segments, so they can be found.
Going to restore those and get a copy of the sql that the admin client runs to be sure.

[gmcgee]

In case anyone has to try this, recovering the rows to the arsseg table that refer to the deleted segment tables does allow access to the restored segments (that were deleted by arsmaint). 

1) restore cache entries and rebuild links (if required)
2) restore missing segment tables to database
3) copy missing arsseg table rows back

Note: this only works for application groups that are set for segment deletes.