Home
Troubleshooting and Tuning
Performance depends on many factors, including your database and web server configuration, network connectivity and other configurations.
Tuning Guide
Database tuning for Unica Campaign: DB2
A good starting point for tuning your configuration is to use the DB2® AUTOCONFIGURE command. This command generates values for parameters based on your responses to questions about workload characteristics.
Perform database maintenance
For best performance, perform periodic maintenance activity on large tables by running a command such as RUNSTATS.

Troubleshooting and Tuning
Performance depends on many factors, including your database and web server configuration, network connectivity and other configurations.
- Tuning Guide
  - Unica Campaign performance configuration overview
    The purpose of this document is to improve performance of flowchart execution, which is the core of the Unica Campaign application. The performance of Unica Campaign is tied closely to database performance. Optimal settings of database-related parameters can significantly improve overall Unica Campaign application performance.
  - Database tuning for Unica Campaign: DB2
    A good starting point for tuning your configuration is to use the DB2® AUTOCONFIGURE command. This command generates values for parameters based on your responses to questions about workload characteristics.
    - Use database load utilities
      You can improve performance significantly by using a database load utility for all datasources. Database load utilities are available from your database vendors.
    - Spread tablespaces across multiple disks
      A table space is a logical unit of storage in a database. Generally speaking, spreading database table spaces across multiple disks improves performance.
    - Index databases
      In general, the fastest way to access data from a database is to use an index. Indexes increase the efficiency of finding a specific piece of data. Indexing provides an efficient and fast way to identify the data (rows) in a table.
    - Partition databases
      In the case of huge data (millions of records), consider partitioning databases and objects.
    - Partition tables
      Table partitioning can improve performance. Table partitioning is a data organization scheme in which table data is divided across multiple storage objects called data partitions or ranges, according to values in one or more table columns.
    - Perform database maintenance
      For best performance, perform periodic maintenance activity on large tables by running a command such as RUNSTATS.
  - Setting in-database optimization to improve flowchart performance
    Using in-database optimization can improve flowchart performance. When in-database optimization is on, processing is done on the database server and output is stored in temporary tables on the database server whenever possible.
  - Adjusting configuration properties in Unica Campaign to improve performance
    You can adjust configuration properties in Unica Campaign and Unica Platform to improve performance.
  - Troubleshooting Unica Campaign Performance
    Performance depends on many factors, including your database and web server configuration, network connectivity, and Unica Campaign and Unica Platform configuration.
- Troubleshooting Guide

Perform database maintenance

For best performance, perform periodic maintenance activity on large tables by running a command such as RUNSTATS.

The DB2® RUNSTATS command updates statistics in the system catalog about the characteristics of a table and/or associated indexes, or statistical views. It is highly recommended that you use the DB2® RUNSTATS command to collect current statistics on tables and indexes, especially if significant update activity has occurred or new indexes have been created since the last time the RUNSTATS command was run. This command provides the optimizer with the most accurate information with which to determine the best access plan.

Example:

runstats on table DB2INST2.UA_CONTACTHISTORY and detailed indexes all

Consider the case of a table that could have a large variation in the amount of data it contains, at any given moment. The volatility or extreme changeability of this type of table makes reliance on the statistics collected by RUNSTATS inaccurate. Statistics are gathered at, and only reflect, a single point in time.

To generate an access plan that uses a volatile table can result in an incorrect or poorly performing plan. For example, if statistics are gathered when the volatile table is empty, the optimizer tends to favor accessing the volatile table using a table scan rather than an index scan.

To prevent this type of issue, consider declaring the table as volatile using the ALTER TABLE statement. By declaring the table volatile, the optimizer will consider using an index scan rather than a table scan. Access plans that use declared volatile tables do not depend on the existing statistics for that table.

"ALTER TABLE <table_name> VOLATILE CARDINALITY"

Have feedback?
Google Analytics is used to store comments and ratings. To provide a comment or rating for a topic, click Accept All Cookies or Allow All in Cookie Preferences in the footer of this page.