Rephrasing Rules for Off-The-Shelf SQL Database Servers

Abstract

We have reported previously [1] results of a study with a sample of bug reports from four off-the-shelf SQL servers. We checked whether these bugs caused failures in more than one server. We found that very few bugs caused failures in two servers and none caused failures in more than two. This would suggest a fault-tolerant server built with diverse off-the-shelf servers would be a prudent choice for improving failure detection. To study other aspects of fault tolerance, namely failure diagnosis and state recovery, we have studied the "data diversity" mechanism and we defined a number of SQL rephrasing rules. These rules transform a client sent statement to an additional logically equivalent statement, leading to more results being returned to an adjudicator. These rules therefore help to increase the probability of a correct response being returned to a client and maintain a correct state in the database.

Fault Tolerance via Diversity for Off-the-Shelf Products: A Study with SQL Database Servers

“…with translation, as we have shown in [22]) and/or clients to be limited to using a common subset among the features of the diverse DBMS products. In addition, many aspects of database operation are specified in a nondeterministic fashion, making the goal of ensuring consistency among replicas difficult, even with sameproduct replication and more so with diverse replication.…”

“…Thanks to the redundancy in the SQL language, a sequence of one or more SQL statements can be "rephrased" into a different but logically equivalent sequence to produce redundant executions, reducing the risk of a failure being repeated when the rephrased sequence is executed on the same or another replica of even the same DBMS product. Two of the present authors have reported in [22] a set of "rephrasing rules" that would tolerate at least 60 percent of the bugs examined in our studies. Another possibility is varying the "hints" to the "query optimizer" of the DBMS that are included with SQL statements.…”

“…A possibility is not to offer masking but simply a clean failure to be followed by manual diagnosis of the problem. Alternatively, additional redundant execution can be run by replaying the statements, possibly with "data diversity," that is, rephrasing the statements [22]. Depending on how redundant executions are organized, the middleware may need to resolve rather complex scenarios.…”

“…After a failure, a database replica is restored to its last checkpointed state, and the middleware replays the sequence of (all or just write) statements (since then, the redo log provided in some DBMS products cannot be used because it might contain erroneous writes). For finer granularity of recovery, the checkpoint-rollback mechanism can be used within transactions: This allows for the handling of exceptions within transactions and should be applied when using data diversity through "rephrasing" [22]. .…”

Reliability Modeling of a 1-Out-Of-2 System: Research with Diverse Off-The-Shelf SQL Database Servers

“…Also we have observed in earlier research [4], [3] that AB-faults can fail in different ways in the two DBMS products, and hence can be detected (and potentially corrected [16]). As a result, the estimates that we get using our models for the reliability benefits of diversity will most probably be underestimates: the true benefits may be higher.…”