Reliability: Eliminating Planned Downtime

In our prior post we discussed the issue of recovering from unplanned downtime. The other side of the coin is the time spent in planned downtime for database maintenance and schema revision. Ancelus raises the bar in this set of operations as well. One design objective for the Ancelus system was to improve operational efficiency through enabling live maintenance including schema changes with ZERO downtime.

Every DBA has sweated through a weekend upgrade. Some have seen the Sunday afternoon panic when it doesn’t go as planned, leading to a rapid rollback to the old version. Ancelus eliminates the stress of the weekend upgrade, with its associated customer and user aggravation. The more permanent effect is to professional reputations. I'm reminded of my experience as a young engineer, installing a new packaging machine on a production line. It wasn't going as planned. After having the line down for about 20 minutes the plant manager showed up, leaned over my shoulder and asked "Excuse me son, but not counting tomorrow, how long have you been with us?" We got the line running within 2 minutes.

To avoid this experience we needed a way to fully test the upgrade process offline, then to implement that upgrade in real-time, while the database is in full operational service. That's exactly what Ancelus delivers. Many of the reasons for taking a database out of service have been automated.

The Balanced Binary Tree is re-balanced on every transaction, in real-time, with zero downtime. It happens so fast that users don't notice. This eliminates the need to use “approximations” of the BBT, and the frequent out of service conditions required to regain the performance lost when the tree gets out of balance.

Re-indexing happens on every transaction in the same manner. In the last post we discussed real-time recovery from externally driven index corruption. But in routine maintenance Ancelus raises the bar again. Every new entry into an Ancelus key field is automatically indexed. A delete command purges a record and makes the space instantly available for re-use. The old index structure is revised to accommodate the new reality. The quoted benchmarks include the time required to do these operations.

Schema changes receive the same treatment. Adding a new field to a table is a simple one-command operation. The 7-table join benchmark includes a test that does exactly that in a small fraction of a second, in a billion-record table. You can also delete a field in the same fashion, although this is inherently risky unless you carefully confirm that there is no obscure application routine that looks for that field.

If you'd like to review the entire list of development and operational tasks eliminated in the Ancelus world, contact us a www.ancelus.com.