Database Deployment Issues

(see also Database Issues page)

For best performance with Softdial Campaign Manager™ the database must contain a single unique primary key column for database updates. The following general rules should also be obeyed:

• A separate table per campaign should be used as this provides faster indexing of data.
• If the customer's database has all customer data in a single table then a separate view of just the data to be used by Softdial Campaign Manager™ should be created. This view must include the same columns as the primary table.
• If creating a view based on multiple tables, all columns added by Softdial Campaign Manager™ must be included in the primary table before the view is created.
• If filtering criteria are known in advance then filtered views should also be created.

Users specified in Softdial Campaign Manager™ must have full permissions including permission to create tables.

Note: You cannot generate new columns in a View from Softdial Campaign Manager™ - an error will be thrown if you try to generate a new View column from the the Database Output window. Views should only be used for input data, all output data must be written directly to a table.

Database performance challenges essentially relate to the volume of columns and rows used in the database. Increased volumes of rows and columns affect the speed of data retrieval in a linear manner. This is a consequence of limitations in scalability of the relational model, rather than the host software.

The recommended method for predicting the performance curve for data retrieval is to use the following calculation, based on your own datamodel.

No. of Data Elements = No. of Rows multiplied by No. of Columns
(e.g. 100k rows X 100 Columns = 10Million data elements.)

The speed of retrieval you experience with the element count for your datamodel, can be used to forecast the throughput for any database size.

If the throughput for a 10 million element database table can support 200 agents without any backlog, then doubling the database size to 20 million elements will generally double retrieval and update times, reducing the number of agents it can efficiently support, in this example to around 100.

From our experience with a number of large hosted customers:

A table on a well-tuned SQL database server with 500,000 rows and 300 columns will start to queue transactions with 200 agents doing predictive dialing with low connect rates as would normally be experienced with cold calling.

Based on this scenario we recommend that 200 agents is the absolute agent limit for a database table containing 150 million data elements. Reduce the number of elements to 100 million and you could run 300 agents. Increase to 300 million elements and your limit would be 100 agents.

There is also a practical upper limit to the volume of transactions a single SQL database server can handle. In our experience this is around 500 agents worth of database traffic. With the very latest server architectures this ceiling may well be higher but you must load test this to be sure.

To facilitate retry control, Softdial Campaign Manager™ creates one Audit Table per campaign. These tables are for the application's internal use. Table formats and contents are subject to change without notice and therefore these tables should not be used for user reporting purposes.

When a campaign is running, only the Sytel or 3rd party Campaign Manager application may update the database and only the active record may be updated. Other applications should not perform operations on the database tables being used during a campaign, for example for report generation, unless the employ the API provided to enable this to be done reliably without risk of deadlocks and data corruption. See Updating Campaign Tables for details.

Where report generation using data from tables managed by Softdial Campaign Manager™ is required, the Database Administrator must replicate the tables. Sytel is happy to advise on how this should be done.

The server should be configured to minimise processing interruption on account of operating system activity. These requirements will change based on exact hardware specification but as a general rule the following should be observed:

• System configuration should be such that resident processes and services are a bare minimum set. This precludes active use of anti-spyware and antivirus software. The server will therefore need to be protected by external firewalls.
• Windows Firewall must be disabled. This performs packet inspection which may interrupt operation when running under load.
• Any non-resident antivirus or anti-spyware software should be scheduled to run overnight as part of scheduled outage for the server. In a high-availability environment multiple servers will be required and will need to have different outage periods.
• Automatic updates must be disabled. Automatic downloading of updates must also be disabled.
• The server should be configured to favour background tasks.
• The desktop UI configuration should be the simplest possible, to minimise processor load when administering the system.

The customer database used by Softdial Campaign Manager™ must be run on a dedicated server, physically separate from the dialer and other Softdial Contact Center™ components. No contended access is allowed . If access to the database is required by other applications, this will require decoupling of the Softdial Campaign Manager™ server from the enterprise database. This can be achieved for example, by using database replication with SQL server.

There are essentially three Wintel server options available in respect of database activities with Softdial Campaign Manager™:

• Basic - Core 2 / Duo based Server
  Supports up to 200 agents, or 100 agents if Softdial Reporter™ is also installed.
• Mid - Dual Xeon based Server
  Supports up to 500 agents, or 250 agents if Softdial Reporter™ is also installed.
• High - Clustered Servers
  Consult Sytel if intending to use this technology.