How To Minimize Database Growth

Long-lived processes store process data in the LiveCycle database. The growth of the LiveCycle database can be minimized using a few easy process design and product configuration strategies.

Process Design

Use short-lived processes. Short-lived processes don’t store process data in the database. The downside is that you can’t use Adobe Administration Console to track process status and state. Also, you won’t have a history of the process or any BAM reports.

Some service operations, such as the Assign Task operation (User service), require that they are used in long-lived processes. In this case, you can segment the process into several subprocesses and make them short-lived when possible. If you use this strategy, short-lived subprocesses should handle large data items, such as document values.

Use variables sparingly. When using long-lived processes, for every process instance, space is allocated on the database for each variable in the process. Strategic use of variables can save a considerable amount of space:

Use the fewest number of variables that is possible. For example, you can overwrite variable values when old values are no longer needed in the process. And delete any variables that you’ve created and are not using. (Tip for LiveCycle ES Update 1 users: Validate the process to find unused variables.)
Use simple variable types (such as string, int, etc) and avoid using complex variable types when possible. Database space is allocated for variables even when they don’t contain a value. Complex variables typically require more space than simple ones.

Product Administration

Use Global Document Storage (GDS) effectively. The global document storage directory on the LiveCycle ES server is used to store, among other things, files that are passed to LiveCycle ES services in processes. To improve performance, smaller documents are instead stored in-memory and persisted in the database.

Adobe Administration Console exposes the Default Document Max Inline Size property for configuring the maximum size of documents that are stored in-memory and persisted in the database. If you set this property to a low value, most documents are persisted in the GDS directory instead of in the database. The advantage is that you can more easily delete the files when they are no longer needed when they are stored in the GDS directory.

Some background references:

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

3 Responses to How To Minimize Database Growth

  1. Parth Pandya says:

    Hi Scott,I’ve a question regarding the GDS and cleanup procedure for it.As per the documentation (Administering LiveCycle ES) all of the files with Session[NNNN] name can be removed from filesystem to free up the space. I just looked at one of our servers and found that those files are of 0kb. Is it suppose to be like that? I am looking at a JBoss-SQLServer installation on windows 2003 server. ES version is 8.0.1 SP1.Thanks in Advance,Parth

  2. Rob Ryan says:

    The full quote is below BTW…Note that it talks about Session[NNN] *subdirectories*, not files. This content was originally targetted at LC7.x, and you might still have some such directories if you upgraded.You cannot delete .session* *files* in LC8.x without considerable care. In LC8.2.1 a process purge feature was introduced which allows you to safely purge processes and corresponding content you no longer need.The .session* files are zero-length by design, they merely mark the lifetime of other files.Unlike the Session[NNN] subdirectories, some of the .session* files mark the lifetime of DSC or LCA content. Deleting all .session* files would render the system inoperable.When a process is executed, temporary files are placed in the GDS directory, but they are not deleted whenthe process is complete. These files are placed under subdirectories with the name, Session[NNNN], whereNNNN is the process ID. To prevent running out of disk space, you must regularly remove the Sessiondirectories for processes that are not running.

  3. Parth Pandya says:

    Thanks a lot Rob.Much appreciate your help in clarifying things.