Cisco Cisco Process Orchestrator 3.0 User Guide

Data about completed process instances is available on a long-term basis in the Process 
Orchestrator Reporting database. The Reporting database provides information on which 
processes have run, when they started and ended, whether they were successful or failed, how 
they were started, and who started the processes in long term storage. The Reporting database 
has information about processes only, not activities within the process.

Task instances, such as alerts, incidents, and change requests. These objects are groomed only upon 
their completion, which means that an open or active task can remain in the database forever. By 
default, the tasks can stay in the database for a long time.

Audit data, which is groomed less aggressively because it is more important to keep around longer.

Using the default settings, grooming is automatic, but you can tune these settings to your needs. For 
example, there are options to:

Control how much data is retained for completed instances. 

Mark expired tasks as completed.

Configure a process to archive on failure. This allows low data and performance load during 
normal/successful executions of the process, while archiving failures so that they can be debugged 
and diagnosed.

Start grooming immediately (rather than to wait for the scheduled time).

To change the grooming settings for the Process database, see 

.

Proper database server hardware and routine database maintenance can have substantial effects on 
performance. Although the Process Orchestrator ships with performance-optimized schemas, including 
the relevant indices, you must install and operate these databases. 

Ideally, to optimize performance, a database administrator (DBA) familiar with best practices should 
prescribe and configure the server hosting the database platform containing the Process Orchestrator 
databases. The DBA should also be involved in the installation of the database and should perform 
routine maintenance.

In high performance scenarios, the following best practices can dramatically affect performance:

Run regular backups of the Process Orchestrator database. Without backups, the transactional logs 
of the database will grow fairly substantially, resulting in large files and poor database performance, 
and ultimately affecting Process Orchestrator’s performance.

Always run the database server on physical hardware, not on a VM. 

Use a separate host server for the database instead of running the database server on a Process 
Orchestrator server.

Disk throughput (I/O) is also an important metric for large scale deployments. Use a separate high 
speed disk for the database, operating system, program files, and swap files.

Provide sufficient memory to avoid paging. In very large installations, Process Orchestrator has 
benefited from databases running 16 or even 32GB of RAM.

Use a high-speed network connection. Typically this means the database is “close” to the Process 
Orchestrator server, and certainly in same data center.

For best practices, refer to the documentation associated with your chosen database platform.