I'd like to ask a question that may be a "dumb" one, but I want to be sure about something *before* an actual problem occurs
We're running a number of LiveCycle (ES U1) installations, both in test and productive environments, with quite some user-based processes. We noticed that the size of the LiveCycle database keeps on increasing over time. It's most noticeable on test systems which just use the turnkey MySQL, but it doesn't seem to be that much different with MSSQL.
What I'd like to know is this: What happens with data from processes that have been completed (especially instances of large document variables per step etc.)? Is there some kind of cleanup mechanism and if so, what triggers it? Is there any way to manually perform some maintenance tasks?
I guess every kind of information would be really helpful. Thanks a lot,
It's not a dumb question at all, it's a very good one.
There are two ways you can purge your LiveCycle database.
1. You can use the Adobe PurgeProcessTool. This tool completely deletes all trace of processes that meet a particular criteria (usually, they must be older than a certain date).
After you run the tool, that process and all its data will be gone - there is no record that it ever existed.
You can find a batch file (modify for Unix) at: C:\Adobe\LiveCycle8.2\LiveCycle_ES_SDK\misc\Foundation\ProcessPurgeTool
Note: We've heard one report of corruption that may (or may not) be related to the use of this tool. (This is not FUD, just letting you know.) In this case, the user used "*" to try to delete everything from all categories. We recommend you only purge process types that you have created.
2. You can use the Avoka purge tool. This tool takes a slightly different approach. It leaves the old processes intact, but removes a whole lot of superfluous information that is stored along with the process instance. It removes:
The data associated with certain internal data structures. This data accounts for the vast majority of the size associated with process instances, and is generally completely superfluous. (The only exception is if you're invoking processes programmatically, and polling for the results.)
Optionally, the data associated with attachments within Workspace. It doesn't remove the record that there was an attachment, but if you try to download the attachment, it will be a zero byte file. Note that any attachments are duplicated at every single user step, potentially resulting in very large data in the database.
The bottom line is that it will dramatically reduce your database size, without removing your ability to search and track historical process instances.