|
Tips for minimizing database growth
Long-lived processes store process data in the AEM forms
database. The growth of the AEM forms database can be minimized
using a few easy process design and product configuration strategies.
Process design tips
Use short-lived processes whenever possible. Short-lived
processes do not store process data in the database. The disadvantage
of using short-lived processes is that their status and state are
not tracked in administration console and there is no history of
the process.
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. For example, you can overwrite variable values
when old values are no longer needed in the process. And delete
any variables that you have created and are not using. You can validate
the process to find unused variables.
Use simple variable types (for example, string or int) and avoid
using complex variable types when possible. Database space is allocated
for variables even when they do not contain a value. Complex variables
typically require more space than simple ones.
Product administration tips
Use global document storage (GDS) effectively. The GDS
directory on the forms server is used to store, among other things,
files that are passed to services that are part of AEM forms in
processes. To improve performance, smaller documents are instead
stored in-memory and persisted in the database.
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. (See
Configure general AEM forms settings
.)
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.
Purging process data
Process data that is generated when a long-lived process
is invoked can become too large, resulting in lower AEM forms performance
and the use of unnecessary disk space. It is good practice to purge
process data when records are no longer necessary. AEM forms provides
several means of purging process data:
-
You can use administration console to perform a one-time
purge of obsolete records related to long-lived processes, or to
schedule regular automatic purges. (See
Purge records from the Job Manager database
.)
-
You can use the AEM forms Java API and web service API to
programmatically purge process data related to long-lived processes.
(See "Purging Process Data" in
Programming with AEM forms
.)
-
Use the process purge tool to purge processes based on the
process name and other parameters. For details, see the process
purge tool readme file, located in
[aem_forms root]
\sdk\misc\Foundation\ProcessPurgeTool\ReadMe.txt.
Microsoft SQL Server database: Fine-tuning the configuration
You should change the default configuration settings when
using Microsoft SQL Server. Right-click the local server in Oracle
Enterprise Manager to access the properties dialog box.
Memory settings
Change the minimum memory allocation to as large a number
as possible. If the database is running on a separate computer,
use all the memory. The default settings do not aggressively allocate
memory, which hinders performance on almost any database. You should
be most aggressive in allocating memory on production machines.
Processor settings
Modify the processor settings and, most importantly, select
the Boost SQL Server Priority On Windows check box so that the server
uses as many cycles as possible. The Use NT Fibers setting is less
important, but you may want to select it too.
Database settings
Change the database settings. The most important setting
is Recovery Interval, which specifies the maximum amount of time
to wait for recovery after a crash. The default setting is one minute.
Using a larger value, from 5 to 15 minutes, improves performance
because it gives the server more time to write changes from the
database log back into the database files.
Note:
This setting does not compromise the transactional
behavior because it changes only the length of the log file replay
that must be done on startup.
Set the Space Allocated size for both the log and the data file
to be much larger than the initial database. Consider how much the
database can grow over of a year. Ideally, the log and data files
are allocated in a contiguous extent so that data does not end up
fragmented all over the disk.
IBM DB2 database: Running commands for regular maintenance
The following IBM DB2 commands are recommended for regular
maintenance of your AEM forms database. For detailed information
about maintenance and performance tuning for your DB2 database,
see
IBM DB2 Administration Guide
.
-
runstats:
This command updates statistics
that describe the physical characteristics of a database table,
along with its associated indexes. Dynamic SQL statements generated
by AEM forms automatically use these updated statistics, but static
SQL statements built inside a database require that the
db2rbind
command
be run as well.
-
db2rbind
:
This command rebinds all the packages
in the database. Use this command after running the
runstats
utility
to revalidate all packages in the database.
-
reorg table
or
index
:
This command
checks whether a reorganization of some tables and indexes is required.
As
your databases grow and change, recalculating table statistics is
critical to improving database performance and should be done regularly.
These commands can be run either manually by using scripts or by
using a cron job.
Note:
Before you run the
runstats
command,
the database must contain data, and at least one directory synchronization
must have been performed.
For a small database, such as for 10,000 users or 2,500 groups,
it is sufficient to invoke the
runstats
command
to reduce the sync timings.
For larger databases, such as for 100,000 users or 10,000 groups,
run the
reorg
command before you run the
runstats
command.
Use the runstats command on your AEM forms database
Run the
runstats
command on the following
AEM forms database tables and indexes.
Note:
The
runstats
command
needs to be run only during the first database synchronization.
However, it must be run twice during that process: once during the synchronization
of Users and Groups and then during the synchronization of Group Members.
Ensure that the script executes completely each time you run it.
For correct syntax and usage, see the database manufacturer’s
documentation. Below,
<schema>
is used to
denote the schema that is associated with your DB2 user name. If
you have a simple default DB2 installation, this is the database schema
name.
TABLE <schema>.EDCPRINCIPALGROUPENTITY
TABLE <schema>.EDCPRINCIPALGRPCTMNTENTITY
TABLE <schema>.EDCPRINCIPALENTITY
TABLE <schema>.EDCPRINCIPALUSERENTITY
TABLE <schema>.EDCPRINCIPALEMAILALIASENTITY
TABLE <schema>.EDCPRINCIPALENTITY FOR INDEXES ALL
TABLE <schema>.EDCPRINCIPALEMAILALIASENTITY FOR INDEXES ALL
TABLE <schema>.EDCPRINCIPALUSERENTITY FOR INDEXES ALL
TABLE <schema>.EDCPRINCIPALGROUPENTITY FOR INDEXES ALL
TABLE <schema>.EDCPRINCIPALGRPCTMNTENTITY FOR INDEXES ALL
Run the reorg command on your AEM forms database
Run the
reorg
command on the following
AEM forms database tables and indexes. For correct syntax and usage,
see the database manufacturer’s documentation.
TABLE <schema>.EDCPRINCIPALGROUPENTITY
TABLE <schema>.EDCPRINCIPALGRPCTMNTENTITY
TABLE <schema>.EDCPRINCIPALENTITY
TABLE <schema>.EDCPRINCIPALUSERENTITY
TABLE <schema>.EDCPRINCIPALEMAILALIASENTITY
INDEXES ALL FOR TABLE <schema>.EDCPRINCIPALENTITY
INDEXES ALL FOR TABLE <schema>.EDCPRINCIPALEMAILALIASENTITY
INDEXES ALL FOR TABLE <schema>.EDCPRINCIPALUSERENTITY
INDEXES ALL FOR TABLE <schema>.EDCPRINCIPALGROUPENTITY
INDEXES ALL FOR TABLE <schema>.EDCPRINCIPALGRPCTMNTENTITY
DB2 database: Running a process weekly
If your AEM forms DB2 database begins to run slowly, running
the following process on a weekly basis can improve its performance:
-
Start DB2 Control Center:
(Windows) Select Start
> Programs > IBM DB2 > General Administratison Tools >
Control Center.
(Linux and UNIX) From a command prompt, type
the
db2jcc
command.
-
In the DB2 Control Center object tree, click All Databases.
-
Click the database you created for AEM forms and click the
Tables folder.
-
Select all the database tables in the contents pane, right-click
them and select Run Statistics.
-
Go to Statistics > Index Statistics.
-
Select Collect Statistics For All Indexes, select Collect
Statistics For Indexes With Extended Detailed Statistics, and then
click OK.
A message appears when the process is completed. Close the message.
Oracle database maximum open cursors threshold
To configure a maximum value for open cursors in Oracle,
you may have to tune this value to a number that is appropriate
to your application. It is evident that under a moderate load, the
average cursors open was 2700. It is recommended that you start
with an upper limit of 3000. For more information, go to
http://www.orafaq.com/node/758
.
|
|
|
