What Is The Best Way To Restore From An Imexpire Accident? (Doc ID 2732158.1)

Last updated on JULY 08, 2021

Applies to:

Goal

Qn1:  What is the best way to restore from an imexpire accident?
An imexpire was run with a broken expire rule file. All mail older than 1 day was removed from all the folders of 14K users.
Expurge was stopped.
Running "mboxutil -R" with destination folder requires generating a list of all folders and turning that into a script. We want to restore only those messages effected by the imexpire accident; not the ones deleted in the last 2 weeks.
We are wondering if removing the most recent store.exp* files and then running a reconstruct will help?
 
Qn2:  If an imexpire process was hit with a HUP signal (because the VPN session of the user who started it timed out and they didn't use screen or nohup or anything like that...), would imexpire stop when it finished the folders it was currently working on?  Would it report a "total expired" message as if it had completed normally -- but only report the numbers for the ones it actually did?
Imexpire was run with the defaults for number of threads (50) and threads per partition (1).
Thus, if it ended prematurely (which is what is being observed), would it have been doing them in alphabetical order by username (the order shown in mboxutil -l)?
As reconstructing progresses, if it is performed in the same order, should we eventually hit users who were not impacted?

Qn3:  What is the limit on the number of processes that can have the sleepycat/mboxlist databases open at the same time?
For example, how many reconstruct processes can be run in parallel?
 
Qn4:  Performing "Ctrl/C(SIGINT)" causes the imexpire process to exit, whereas imexpire is not interrupted with a HUP signal. Ideally, HUP is ignored. Thus, imexpire will not stop the job when it encounters a HUP signal.
In a recent scenario, a question was raised on whether a user had accidentally closed the terminal or performed a Ctrl-C in the terminal.  It wasn't thought that the user hit Ctrl/C. It was thought that they ran it in the background ("&" at the end of the command) but (fortunately) forgot to use nohup.
If Ctrl/C was performed, it is assumed imexpire would have printed something to the terminal to ACK that it handled the SIGINT and would shut down after completing current operations.
Does it also record that same type of info to the default log?
 

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.