sqlancer/sqlancer데이터베이스 시스템에서 로직 및 성능 버그를 찾기 위한 자동화된 테스트
SQLancer는 데이터베이스 관리 시스템(DBMS)의 구현에서 버그를 자동으로 찾기 위한 도구입니다. 즉, 사용자가 작성한 쿼리가 아닌 DBMS 구현 코드 자체의 버그를 찾아냅니다. SQLancer는 성숙하고 널리 알려진 DBMS에서 수백 개의 버그를 발견했습니다.
SQLancer는 DBMS를 자동으로 테스트할 때 두 가지 핵심 과제를 해결합니다.
커뮤니티. SQLancer 및 DBMS 테스트 일반에 대해 논의할 수 있는 Slack 워크스페이스가 있습니다. 이전에는 SQLancer가 Twitter/X에 @sqlancer_dbms 계정을 운영했지만, 현재는 유지 관리되지 않습니다. 블로그도 있으며, 현재로서는 Google Summer of Code 프로젝트 기여자들의 게시물만 포함되어 있습니다.
최소 요구 사항:
다음 명령은 SQLancer를 클론하고, JAR을 생성하며, Non-optimizing Reference Engine Construction (NoREC)을 사용하여 SQLite를 테스트하기 위해 SQLancer를 시작합니다:``` git clone https://github.com/sqlancer/sqlancer cd sqlancer mvn package -DskipTests cd target java -jar sqlancer-*.jar --num-threads 4 sqlite3 --oracle NoREC
**실행 및 종료.** 실행 시 5초마다 진행 정보가 출력된다면, 도구가 예상대로 작동하는 것입니다. CTRL+C 단축키를 사용하여 SQLancer를 수동으로 종료할 수 있습니다. SQLancer가 버그를 찾지 못하면 무한히 실행됩니다. `--num-tries` 옵션을 사용하여 SQLancer가 몇 개의 버그를 찾은 후 종료될지 제어할 수 있습니다. 또는 `--timeout-seconds` 옵션을 사용하여 SQLancer가 실행될 최대 시간을 지정할 수 있습니다.
**매개변수.** 매개변수 없이 SQLancer를 실행하면 사용 가능한 옵션과 명령이 표시됩니다. 모든 DBMS 테스트 구현에서 지원하는 일반 옵션(예: `--num-threads`)은 테스트할 DBMS 이름(예: `sqlite3`) 앞에 와야 합니다. 특정 DBMS에서만 지원되는 옵션(예: SQLite3의 `--test-rtree`) 또는 각 테스트 구현이 서로 다른 값을 제공하는 옵션(예: `--oracle NoREC`)은 DBMS 이름 뒤에 와야 합니다.
**DBMS.** SQLite에서 SQLancer를 실행하기 위해 DBMS를 설치하고 설정할 필요는 없었습니다. 그 이유는 임베디드 DBMS가 애플리케이션과 동일한 프로세스에서 실행되므로 별도의 설치나 설정이 필요 없기 때문입니다. SQLancer가 지원하는 임베디드 DBMS로는 DuckDB, H2, SQLite가 있습니다. 해당 바이너리는 [JAR 종속성](https://github.com/sqlancer/sqlancer/blob/main/pom.xml)으로 포함되어 있습니다. 이러한 시스템의 충돌은 SQLancer가 실행되는 JVM의 충돌도 유발할 수 있습니다.
# SQLancer 사용하기
**로그.** SQLancer는 로그를 `target/logs` 하위 디렉터리에 저장합니다. 기본적으로 `--log-each-select` 옵션이 활성화되어 있어 DBMS로 전송된 모든 SQL 문이 기록됩니다. 해당 파일 이름에는 `-cur.log` 접미사가 붙습니다. 또한 SQLancer가 논리 버그를 발견하면 확장자가 `.log`인 파일을 생성하는데, 여기에는 버그를 재현하기 위한 문장(데이터베이스 상태 설정을 위한 다른 문장과 함께 마지막으로 실행된 쿼리만 포함)이 기록됩니다.
**버그 축소.** 버그를 유발하는 테스트 입력을 찾은 후에는 일반적으로 해당 입력을 축소하여 추가 분석해야 합니다. 버그를 재현하는 데 중복되는 SQL 문이 많을 수 있기 때문입니다. 수동으로 이 작업을 수행하는 방법은 한 번에 하나의 문장이나 기능을 제거하고, 버그 유발 문장을 재생하며 테스트 오라클(예: TLP나 NoREC과 같은 테스트 오라클의 경우 두 쿼리가 여전히 다른 결과를 생성하는지 확인해야 함)을 적용하는 것입니다. 이 과정은 소위 [델타 디버깅 접근 방식](https://www.debuggingbook.org/html/DeltaDebugger.html)을 사용하여 자동화할 수 있습니다. SQLancer에는 `--use-reducer`를 통해 활성화할 수 있는 델타 디버깅 접근 방식의 실험적 구현이 포함되어 있습니다. 과거에는 [C-Reduce](https://embed.cs.utah.edu/creduce/)를 성공적으로 사용한 적이 있으며, C-Reduce에서는 테스트 오라클을 스크립트로 지정하여 실행할 수 있어야 합니다.
**최신 DBMS 버전 테스트.** 대부분의 DBMS에서 SQLancer는 이전 *릴리스* 버전만 지원합니다. 따라서 SQLancer가 발견한 잠재적인 버그는 DBMS의 최신 *개발* 버전에서 이미 수정되었을 수 있습니다. 테스트 중인 DBMS의 개발자가 아니라면, 버그를 보고하기 전에 버그가 여전히 재현되는지 확인하는 것을 권장합니다. SQLancer로 발견한 버그를 보고할 때 SQLancer를 언급해 주시면 감사하겠습니다. 또한 SQLancer 사용 경험이나 관련 사용 사례, 확장에 대한 이야기를 듣게 되어 기쁩니다.
**옵션.** SQLancer는 동작을 사용자 정의할 수 있는 다양한 옵션을 제공합니다. `java -jar sqlancer-*.jar --help`를 실행하면 옵션 목록이 표시되며, 다음과 같은 출력이 출력됩니다:```
Usage: SQLancer [options] [command] [command options]
Options:
--ast-reducer-max-steps
EXPERIMENTAL Maximum steps the AST-based reducer will do
Default: -1
--ast-reducer-max-time
EXPERIMENTAL Maximum time duration (secs) the statement reducer will do
Default: -1
--canonicalize-sql-strings
Should canonicalize query string (add ';' at the end
Default: true
--constant-cache-size
Specifies the size of the constant cache. This option only takes effect
when constant caching is enabled
Default: 100
...
사용할 SQLancer 버전. SQLancer를 사용하는 권장 방법은 GitHub의 최신 소스 버전을 사용하는 것입니다. 드물고 불규칙한 공식 릴리스는 다음 플랫폼에서도 제공됩니다:
SQL 생성 이해하기. 버그를 유발하는 구문을 분석하려면 SQLancer의 특성을 이해하는 것이 도움이 됩니다. 첫째, SQLancer는 테스트 대상 DBMS에 대해 항상 구문적으로 유효한 SQL 문을 생성할 것으로 예상됩니다. 따라서 구문 오류는 절대 관찰되지 않아야 합니다. 둘째, SQLancer는 의미적으로 유효하지 않은 문을 생성할 수 있습니다. 예를 들어, SQLancer는 UNIQUE 제약 조건이 있는 열에 중복 값을 삽입하려고 시도할 수 있습니다. 이러한 의미적 오류를 완전히 피하는 것은 어렵기 때문입니다. 셋째, SQLancer가 보고하는 모든 버그는 실제 버그여야 합니다. 단, CERT가 보고한 경우는 예외입니다 (성능 문제는 다른 종류의 버그만큼 명확하게 정의되지 않기 때문). SQLancer가 버그로 표시했지만 버그라고 생각하지 않는 경우, 설정에 문제가 있을 가능성이 높습니다. 마지막으로, 앞서 언급한 점과 관련하여 SQLancer는 DBMS 버전에 특화되어 있으며, GitHub Actions 워크플로우에서 테스트 중인 버전을 확인할 수 있습니다. 다른 버전에 대해 테스트하는 경우 다양한 오탐(false alarms)이 관찰될 수 있습니다(예: 구문 오류로 인한). SQLancer가 항상 각 DBMS의 최신 개발 버전과 동기화되기를 바라지만, 이를 달성할 리소스가 부족합니다.
지원되는 DBMS. SQLancer는 지원하는 각 DBMS에 대해 DBMS별 코드가 필요합니다. 2025년 1월 기준으로, Citus, ClickHouse, CockroachDB, Databend, (Apache) DataFusion, (Apache) Doris, DuckDB, H2, HSQLDB, MariaDB, Materialize, MySQL, OceanBase, PostgreSQL, Presto, QuestDB, SQLite3, TiDB, 및 YugabyteDB를 지원합니다. 각 DBMS의 지원 정도는 여기에서 다릅니다.
SQLancer는 아래에 시간순으로 설명된 여러 DBMS 테스트 접근법을 개척하고 포함시켰습니다.
.bib 항목은 여기에서 확인하세요. |
지원되는 DBMS의 최신 버전에서 SQLancer를 실행 중입니다. SQLancer가 많은 AssertionErrors를 출력하는 것이 예상됩니까? 많은 경우 SQLancer는 DBMS의 최신 버전을 지원하지 않습니다. .github/workflows/main.yml 파일을 확인하여 CI 테스트에서 사용하는 버전을 확인할 수 있으며, 이는 해당 DBMS의 현재 지원 버전에 해당합니다. SQLancer는 버그를 식별한 경우에만 AssertionError를 출력하고 해당 로그 파일을 생성해야 합니다. SQLancer를 새 DBMS 버전을 지원하도록 업그레이드하려면 두 가지 옵션이 권장됩니다: (1) 생성기를 업데이트하여 오류를 유발할 수 있는 특정 패턴을 더 이상 생성하지 않도록 하거나(예: 키워드나 옵션이 더 이상 지원되지 않는 경우) (2) 새로 나타난 오류를 예상 오류에 추가하여 SQLancer가 해당 오류가 나타날 때 무시하도록 합니다(예: 피하기 어려운 오류 유발 패턴이 있는 경우 유용함).
지원되는 버전에서 여러 실패가 발생하는 또 다른 이유는 오류 메시지가 영어가 아닌 로케일로 인쇄되는 경우일 수 있습니다(스택 추적에서 확인 가능). 이런 경우 DBMS의 로케일을 영어로 설정해 보십시오(예: PostgreSQL 홈페이지 참조).
SQLancer를 시작할 때 "database 'test' does not exist"와 같은 오류가 발생합니다. 이 오류 없이 SQLancer를 실행하려면 어떻게 해야 합니까? 일부 DBMS의 경우 SQLancer는 "test" 데이터베이스가 존재할 것으로 예상하며, 이를 초기 연결 데이터베이스로 사용합니다. 아직 해당 데이터베이스를 생성하지 않은 경우 CREATE DATABASE test와 같은 명령을 사용하여 생성할 수 있습니다(예: PostgreSQL 문서 참조).
문서 및 리소스:
동영상:
밀접하게 관련된 도구:
| 기술 | 발표 장소 | 링크 | 설명 |
|---|
| 피벗 쿼리 합성 (PQS) | OSDI 2020 | 논문 동영상 | PQS는 우리가 설계하고 구현한 첫 번째 기술입니다. 피벗 행이라고 하는 행을 무작위로 선택하고, 해당 행을 가져오는 것이 보장되는 쿼리를 생성합니다. 행이 결과 집합에 포함되지 않으면 버그가 감지된 것입니다. 여기에 자세히 설명되어 있습니다. PQS는 버그를 효과적으로 감지하지만, 메타모픽 테스트나 차등 테스트 방법론을 따르는 다른 테스트 접근법보다 더 많은 구현 노력이 필요합니다. 따라서 현재 유지 관리되지 않습니다. |
| 비최적화 참조 엔진 구축 (NoREC) | ESEC/FSE 2020 | 논문 동영상 | NoREC는 최적화 버그를 찾는 것을 목표로 합니다. DBMS에 의해 최적화될 가능성이 있는 쿼리를 거의 최적화가 적용되지 않는 쿼리로 변환하고, 두 결과 집합을 비교합니다. 결과 집합 간의 불일치는 DBMS의 버그를 나타냅니다. 이 접근법은 주로 필터 조건이 있는 단순한 쿼리에 적용됩니다. |
| 삼진 논리 분할 (TLP) | OOPSLA 2020 | 논문 동영상 | TLP는 쿼리를 세 개의 분할 쿼리로 분할하고, 그 결과를 구성하여 원래 쿼리의 결과 집합과 비교합니다. 결과 집합의 불일치는 DBMS의 버그를 나타냅니다. NoREC 및 PQS와 달리 집계 함수와 같은 고급 기능에서 버그를 감지할 수 있습니다. 가장 널리 채택된 테스트 기술 중 하나입니다. |
| 차등 쿼리 실행 (DQE) | ICSE 2023 | 논문 코드 | DQE는 SELECT, UPDATE 및 DELETE 쿼리의 논리 버그를 감지하는 새롭고 일반적인 접근법입니다. DQE는 동일한 조건 φ를 가진 SELECT, UPDATE 및 DELETE 쿼리를 실행하고, 실행 결과 간의 불일치를 관찰하여 테스트 오라클 문제를 해결합니다. 예를 들어, 조건 φ를 가진 UPDATE 쿼리로 업데이트된 행이 동일한 조건 φ를 가진 SELECT 쿼리의 쿼리 결과에 나타나지 않으면 대상 DBMS에서 논리 버그가 감지됩니다. 각 행을 고유하게 식별하고 행이 수정되었는지 추적하기 위해 데이터베이스의 각 테이블에 두 개의 추가 열을 추가합니다. 또한 SELECT 및 UPDATE 쿼리를 다시 작성하여 액세스된 행을 식별합니다. DQE는 MySQL을 지원합니다. |
| 쿼리 계획 안내 (QPG) | ICSE 2023 | 논문 동영상 코드 | QPG는 피드백 기반 테스트 케이스 생성 접근법입니다. 쿼리 계획이 DBMS 내에서 흥미로운 동작이 실행되는지 포착한다는 통찰에 기반합니다. 여러 쿼리를 실행한 후 새로운 쿼리 계획이 관찰되지 않으면 데이터베이스 상태를 변형하여 새로운 상태가 새로운 쿼리 계획을 트리거할 수 있도록 합니다. 이 접근법은 --qpg-enable 옵션으로 활성화되며 SQLite, CockroachDB, TiDB 및 Materialize에 대해 TLP 및 NoREC 오라클을 지원합니다. 테스트 입력 생성 문제를 구체적으로 다루는 유일한 접근법입니다. |
| 카디널리티 추정 제한 테스트 (CERT) | ICSE 2024 | 논문 코드 | CERT는 예상치 못한 예상 카디널리티(반환된 행의 예상 수)를 통해 성능 문제를 찾는 것을 목표로 합니다. 주어진 입력 쿼리에서 더 제한적인 쿼리를 도출하며, 해당 쿼리의 예상 카디널리티는 원래 쿼리의 예상 카디널리티보다 크지 않아야 합니다. 위반은 잠재적인 성능 문제를 나타냅니다. CERT는 TiDB, CockroachDB 및 MySQL을 지원합니다. CERT는 SQLancer의 일부로 성능 문제를 찾도록 설계된 유일한 테스트 오라클입니다. |
| 차등 쿼리 계획 (DQP) | SIGMOD 2024 | 논문 동영상 코드 | DQP는 주어진 쿼리에 대해 다른 쿼리 계획의 실행을 제어하고 일관된 결과를 생성하는지 검증하여 논리 버그를 찾는 것을 목표로 합니다. DQP는 MySQL, MariaDB 및 TiDB를 지원합니다. |
| 상수 최적화 기반 데이터베이스 시스템 테스트 (CODDTest) | SIGMOD 2025 | 코드 | CODDTest는 서브쿼리와 같은 고급 기능을 포함한 DBMS의 논리 버그를 찾습니다. 데이터베이스 세션에서 데이터베이스 상태가 일정하다고 가정할 수 있다는 통찰에 기반하며, 이를 통해 쿼리의 일부를 결과로 대체할 수 있습니다. 이는 기본적으로 두 가지 전통적인 컴파일러 최적화인 상수 폴딩(constant folding)과 상수 전파(constant propagation)에 해당합니다. |