SQLite 데이터베이스 검사기

사용법

1. .sqlite, .db, .sqlite3 파일을 상자에 끌어다 놓거나 클릭해서 고르세요. 파일은 브라우저 밖으로 나가지 않습니다.
2. 헤더부터 보세요. 페이지 크기 × 페이지 수가 파일 크기이고, 빈 페이지는 VACUUM으로 되돌려받을 공간입니다.
3. 저널 모드를 확인하세요. WAL이면 -wal 파일에 남은 커밋이 이 파일에 없으므로 행 수는 최솟값으로 보아야 합니다.
4. 테이블 목록에서 행 수, 컬럼과 선언된 타입, 각 테이블에 걸린 인덱스를 확인하세요.
5. 컬럼 해석이 이상하면 테이블 아래의 CREATE 문을 펼쳐 원본 DDL을 기준으로 판단하세요.

자주 묻는 질문

여기 나온 행 수가 애플리케이션이 보는 값과 다릅니다.

대부분 WAL 때문입니다. WAL 모드에서 SQLite는 변경된 페이지를 별도의 -wal 파일에 덧붙이고 체크포인트 때에만 본 파일에 합칩니다. 그래서 -wal 없이 복사한 데이터베이스는 마지막 체크포인트 시점의 스냅숏이고, 최근 삽입이 빠져 보입니다. 복사 전에 PRAGMA wal_checkpoint(TRUNCATE)를 실행하거나 -wal과 -shm 파일을 함께 옮기세요. 다른 원인은 WITHOUT ROWID 테이블인데, 이 경우에는 틀린 수 대신 '알 수 없음'으로 표시합니다.

SQLCipher로 암호화한 데이터베이스도 열 수 있나요?

열 수 없고, 엉뚱한 값을 보여 주는 대신 그렇다고 알려 줍니다. SQLCipher는 헤더까지 암호화하므로 파일이 "SQLite format 3"으로 시작하지 않고, 키 없이는 해석할 것이 없습니다. 이 검사 덕분에 암호화된 파일과 손상된 파일도 구분됩니다. 잘렸을 뿐 암호화되지 않은 파일은 헤더가 읽히므로, 읽을 수 있는 만큼 읽고 페이지 수가 파일 길이와 맞지 않는다고 경고합니다.

빈 페이지는 무엇이고 VACUUM을 해야 하나요?

행을 지워도 SQLite 파일은 줄지 않습니다. 비워진 페이지는 프리리스트에 올라가 이후 삽입에 재사용됩니다. 즉 빈 페이지는 파일이 이미 확보해 둔, 앞으로 다시 쓸 공간입니다. VACUUM은 그 페이지 없이 파일을 다시 만들어 공간을 파일 시스템에 돌려주므로 대량 삭제 후나 배포 전에는 의미가 있지만, 파일 전체를 다시 쓰고 열린 연결을 무효화하므로 운영 중인 데이터베이스에 가볍게 돌릴 작업은 아닙니다.

user_version과 application_id는 무엇인가요?

SQLite가 스스로는 건드리지 않고 애플리케이션이 자유롭게 쓰라고 헤더에 마련한 32비트 칸 두 개입니다. 보통 user_version은 스키마 마이그레이션 번호로 써서 코드가 기대하는 버전과 비교해 그 사이 마이그레이션을 실행하고, application_id는 파일 형식을 구분하는 매직 넘버로 써서 file(1) 같은 도구가 어떤 종류의 SQLite 파일인지 알아보게 합니다. 아무도 설정하지 않았으면 둘 다 0입니다.

스키마 버전과 스키마 형식은 어떻게 다른가요?

스키마 버전(스키마 쿠키)은 스키마가 바뀔 때마다 올라가는 카운터로, 준비된 구문이 다시 컴파일해야 하는지 판단할 때 씁니다. 스키마 형식은 1~4 사이의 파일 레이아웃 세대로, 그 파일이 어떤 기능을 쓸 수 있는지를 뜻합니다. 4면 내림차순 인덱스와 불리언 리터럴이 허용되며, 최근 수십 년의 SQLite는 모두 4로 기록합니다.

파일이 어딘가로 업로드되나요?

아닙니다. 브라우저의 File API로 읽고 페이지 안의 자바스크립트가 직접 해석합니다. 서버로 보내지 않고, 보낼 서버 쪽 구성 요소 자체가 없습니다. 페이지를 연 뒤 네트워크를 끊고 파일을 검사해 보면 그대로 동작하는 것으로 확인할 수 있습니다.

관련 도구