BT’s Bridge is a BT Exact infrastructure database application that is used for internal support within BT. Four help desks with 250 agents take calls from internal BT users and open up case records in Bridge. It actually uses a ClarifyCRM database. The servers are Sun Solaris F12s and a Sun StorEdge SAN is used as the storage medium.

Some 5,000 new case records were added each day in 2002. When a case is closed it is kept in the database for a while and then archived to disk. The problem is that ClarifyCRM’s ability to archive off old cases is a lot, a lot, slower than its ability to create new case records. Since 2003 new record creation rates have soared with 12,000 to 20,000 new cases being added a day.

By early 2002, BT knew that the accelerating database growth was gradually degrading response time. Robert Parker, Bridge application manager at BT, said, “We had already bought more storage and processors for the application, as the transaction rate increased.” Naturally there was a cost to this and it didn’t solve the database closed record removal issue.

Eventually BT built up a closed record load of 1.2 million records. Bridge availability was being increasingly impacted by this mass of dead records. Clarify’s own DATAX facility could only get rid of them at a rate of a few hundred records a day, around a tenth or so of the rate at which new case records were being created. Parker describes this slow removal of closed cases as, “like draining the Titanic with a teaspoon”.

The Bridge application is mission-critical and it has to have 24x7 availability and keep to rigorous SLAs. The closed case backlog was prejudicing these needs. So BT looked to fix the problem, to get a much larger teaspoon. Clarify’s DATAX was rejected because, Parker says, it was “woefully inadequate.”

A product from a company called First Choice was looked at. According to Parker, “It didn’t handle the vary complex relationships that Clarify cases have. (Also its) performance was still not good enough either.”

This was the rub. If you are archiving records from a relational database then you need to preserve the relationships in the structure. Colin Privett, regional VP for N Europe and Africa at Princeton Softech, says, “Princeton has relational engine technology able to extract a relationally intact subset of the production database without screwing the database up.” He adds, “You need a database-aware archiving engine and the ability to do that through the existing user interface is crucial.”

In other words, you need an archiving facility that’s aware of the potential relationships in and the infrastructure of the particular relational database product you have. A generic file archiving facility is no use, no use whatsoever.

BT thought about building its own facility but rejected it on cost and indeterminable cost-of-ownership grounds. Then BT encountered Princeton Softech and its Archive for Servers product set. There was a ClarifyCRM Edition, one designed specifically to work with ClarifyCRM. At the time it was a beta version but BT used it anyway; the need was so pressing, and became a beta test site.

The software worked. Hundreds of thousands of records a day are purged, in fact more than 50,000 an hour. Old cases are archived to disk with the case priority determining how long it’s held on the production database before being archived off. Bridge availability and SLA observance is back on track. The closed case record burden is manageable once more and BT will now tell anyone who cares to listen that a relational database purging tool has to be tailored for the relational database it’s purging.