Debugging transactions and tracking their provenance with reenactment

Abstract

Debugging transactions and understanding their execution are of immense importance for developing OLAP applications, to trace causes of errors in production systems, and to audit the operations of a database. However, debugging transactions is hard for several reasons: 1) after the execution of a transaction, its input is no longer available for debugging, 2) internal states of a transaction are typically not accessible, and 3) the execution of a transaction may be affected by concurrently running transactions. We present a debugger for transactions that enables non-invasive, postmortem debugging of transactions with provenance tracking and supports what-if scenarios (changes to transaction code or data). Using reenactment, a declarative replay technique we have developed, a transaction is replayed over the state of the DB seen by its original execution including all its interactions with concurrently executed transactions from the history. Importantly, our approach uses the temporal database and audit logging capabilities available in many DBMS and does not require any modifications to the underlying database system nor transactional workload.

You Say 'What', I Hear 'Where' and 'Why': (Mis-)Interpreting SQL to Derive Fine-Grained Provenance

“…We believe that the idea of non-standard interpretation does not break if further SQL constructs are added to the dialect. Currently, we explore the treatment of SQL DML statements (INSERT, UPDATE, DELETE) and functions defined in PL/SQLthis is also related to recent work on the re-enactment of transactions [39]. Further, the provenance model realized by the approach is subject to tuning.…”