SQLancer ist ein Werkzeug, um Datenbankmanagementsysteme (DBMS) automatisch zu testen, um Fehler in deren Implementierung zu finden. Das heißt, es findet Fehler im Code der DBMS-Implementierung und nicht in vom Benutzer geschriebenen Abfragen. SQLancer hat Hunderte von Fehlern in ausgereiften und weit verbreiteten DBMS gefunden.

SQLancer bewältigt zwei wesentliche Herausforderungen beim automatischen Testen von DBMS:

1. Testeingabeerzeugung: SQLancer implementiert Ansätze zur automatischen Generierung von SQL-Anweisungen. Es enthält verschiedene handgeschriebene SQL-Generatoren, die in mehreren Phasen arbeiten. Zunächst wird ein Datenbankschema erstellt, das sich auf eine Menge von Tabellen und deren Spalten bezieht. Dann werden Daten in diese Tabellen eingefügt, zusammen mit der Erstellung verschiedener anderer Arten von Datenbankzuständen wie Indizes, Sichten oder datenbankspezifischen Optionen. Schließlich werden Abfragen generiert, die mithilfe eines von mehreren Ergebnisvalidatoren (auch Test-Orakel genannt) validiert werden können, die SQLancer bereitstellt. Neben dem Standardansatz der ungesteuerten Erstellung von Anweisungen unterstützt SQLancer auch einen feedbackgesteuerten Ansatz zur Testeingabeerzeugung, der darauf abzielt, so viele eindeutige Abfragepläne wie möglich auszuführen, basierend auf der Intuition, dass dadurch viele interessante Verhaltensweisen im Datenbanksystem ausgeführt werden [ICSE '23].
2. Test-Orakel: Eine wichtige Neuerung in SQLancer besteht darin, dass es Wege bietet, tiefgreifende Fehlerarten in DBMS zu finden. Ein Hauptschwerpunkt liegt auf dem Auffinden von Logikfehlern, also Fehlern, die dazu führen, dass das DBMS eine falsche Ergebnismenge zurückgibt (z. B. durch das Auslassen eines Datensatzes). Wir haben mehrere komplementäre Test-Orakel vorgeschlagen, wie Ternary Logic Partitioning (TLP) [OOPSLA '20], Non-optimizing Reference Engine Construction (NoREC) [ESEC/FSE 2020], Pivoted Query Synthesis (PQS) [OSDI '20], Differential Query Plans (DQP) [SIGMOD '24] und Constant Optimization Driven Database System Testing (CODDTest) [SIGMOD '25]. Es kann auch bestimmte Kategorien von Leistungsproblemen finden, die sich auf Fälle beziehen, in denen vernünftigerweise erwartet werden könnte, dass ein DBMS sein Ergebnis effizienter liefert, mithilfe einer Technik namens Cardinality Estimation Restriction Testing (CERT) [ICSE '24]. SQLancer kann unerwartete interne Fehler (z. B. einen Fehler, der auf eine beschädigte Datenbank hinweist) erkennen, indem es alle potenziellen Fehler deklariert, die von einem DBMS für eine bestimmte Abfrage zurückgegeben werden könnten. Schließlich kann SQLancer Absturzfehler finden, also Fehler, die dazu führen, dass der DBMS-Prozess beendet wird. Dafür verwendet es ein implizites Test-Orakel.

Community. Wir haben einen Slack-Arbeitsbereich zur Diskussion über SQLancer und DBMS-Testing im Allgemeinen. Früher hatte SQLancer einen Account auf Twitter/X @sqlancer_dbms, der nicht mehr gepflegt wird. Wir haben einen Blog, der derzeit nur Beiträge von Mitwirkenden des Google Summer of Code-Projekts enthält.

Erste Schritte [Video-Guide]

Mindestanforderungen:

• Java 11 oder höher
• Maven

Die folgenden Befehle klonen SQLancer, erstellen ein JAR und starten SQLancer zum Testen von SQLite mit Non-optimizing Reference Engine Construction (NoREC):``` git clone https://github.com/sqlancer/sqlancer cd sqlancer mvn package -DskipTests cd target java -jar sqlancer-*.jar --num-threads 4 sqlite3 --oracle NoREC

**Ausführung und Beendigung.** Wenn die Ausführung alle fünf Sekunden Fortschrittsinformationen ausgibt, funktioniert das Tool wie erwartet. Mit der Tastenkombination STRG+C kann SQLancer manuell beendet werden. Wenn SQLancer keine Fehler findet, wird es unbegrenzt ausgeführt. Die Option `--num-tries` kann verwendet werden, um festzulegen, nach wie vielen Fehlern SQLancer beendet wird. Alternativ kann die Option `--timeout-seconds` verwendet werden, um die maximale Laufzeit von SQLancer anzugeben.

**Parameter.** Wenn Sie SQLancer ohne Parameter starten, werden verfügbare Optionen und Befehle angezeigt. Beachten Sie, dass allgemeine Optionen, die von allen DBMS-Testimplementierungen unterstützt werden (z. B. `--num-threads`), vor dem Namen des zu testenden DBMS (z. B. `sqlite3`) stehen müssen. Optionen, die nur für bestimmte DBMS unterstützt werden (z. B. `--test-rtree` für SQLite3), oder Optionen, für die jede Testimplementierung unterschiedliche Werte bereitstellt (z. B. `--oracle NoREC`), müssen nach dem DBMS-Namen stehen.

**DBMS.** Um SQLancer auf SQLite auszuführen, war es nicht erforderlich, ein DBMS zu installieren und einzurichten. Der Grund dafür ist, dass eingebettete DBMS im selben Prozess wie die Anwendung ausgeführt werden und daher keine separate Installation oder Einrichtung erfordern. Von SQLancer unterstützte eingebettete DBMS umfassen DuckDB, H2 und SQLite. Ihre Binärdateien sind als [JAR-Abhängigkeiten](https://github.com/sqlancer/sqlancer/blob/main/pom.xml) enthalten. Beachten Sie, dass Abstürze in diesen Systemen auch zu einem Absturz der JVM führen, auf der SQLancer ausgeführt wird.

# Verwendung von SQLancer

**Protokolle.** SQLancer speichert Protokolle im Unterverzeichnis `target/logs`. Standardmäßig ist die Option `--log-each-select` aktiviert, was dazu führt, dass jede an das DBMS gesendete SQL-Anweisung protokolliert wird. Die entsprechenden Dateinamen haben das Suffix `-cur.log`. Darüber hinaus erstellt SQLancer bei Erkennung eines Logikfehlers eine Datei mit der Erweiterung `.log`, in der die Anweisungen zur Reproduktion des Fehlers protokolliert werden, einschließlich nur der zuletzt ausgeführten Abfrage zusammen mit den anderen Anweisungen zum Einrichten des Datenbankzustands.

**Reduzieren von Fehlern.** Nachdem eine fehlerauslösende Testeingabe gefunden wurde, muss die Eingabe in der Regel reduziert werden, um sie weiter zu analysieren, da sie viele SQL-Anweisungen enthalten kann, die für die Reproduktion des Fehlers redundant sind. Eine Möglichkeit besteht darin, dies manuell zu tun, indem nach und nach eine Anweisung oder ein Feature entfernt wird, die fehlerauslösenden Anweisungen wiederholt abgespielt werden und das Testorakel angewendet wird (z. B. würde dies bei Testorakeln wie TLP oder NoREC erfordern, dass überprüft wird, ob beide Abfragen weiterhin ein unterschiedliches Ergebnis liefern). Dieser Prozess kann mit einem sogenannten [Delta-Debugging-Ansatz](https://www.debuggingbook.org/html/DeltaDebugger.html) automatisiert werden. SQLancer enthält eine experimentelle Implementierung eines Delta-Debugging-Ansatzes, der mit `--use-reducer` aktiviert werden kann. In der Vergangenheit haben wir erfolgreich [C-Reduce](https://embed.cs.utah.edu/creduce/) verwendet, was die Angabe des Testorakels in einem Skript erfordert, das von C-Reduce ausgeführt werden kann.