What does 'ok' mean in the integrity_check output?

It means no problems were found. The database is fully consistent.

Can I fix index errors without losing data?

Yes. Running REINDEX rebuilds the index from the table data, which corrects the mismatch without losing any table data.

Is it safe to run integrity_check on a live database?

It is safe, but for important databases, always run the check on a copy to avoid any risk of further damage during repair.

What if I see more than 100 errors?

Run PRAGMA integrity_check(N) with a higher N, such as 1000, to see all errors. Fix the first batch, then run the check again.

Reading PRAGMA integrity_check Output in SQLite

Run PRAGMA integrity_check; on a SQLite file and you get a verdict. Either the file is consistent, or you get specific error messages. This guide decodes the common ones from sqlite integrity_check output and tells you what action to take: REINDEX, VACUUM, or full recovery. Most advice stops at "run the check." Here you learn what the messages mean and what to do next.

Understanding the Default Output

When no problems are found, PRAGMA integrity_check; returns a single row with the word ok. By default it reports at most 100 errors. If your file has more than 100 problems, you only see the first 100. Raise the cap by running PRAGMA integrity_check(N); where N is the maximum number of errors to report. Always run checks on a copy when the data matters.

Index Errors Row Missing or Wrong Entry Count

Row Missing from Index

A message like row N missing from index X means the index X contains no entry for row N, even though the table holds that row. The index is out of sync.

Wrong Number of Entries in Index

A message like wrong # of entries in index X means the index count does not match the table row count. Again, the index is inconsistent.

For both errors, run REINDEX on the affected index. REINDEX rebuilds the index from the table data and corrects the mismatch. If you see multiple index errors, REINDEX the whole file.

Page Never Used

If you see Page N is never used, a page in the file is not referenced by any table, index, or the freelist. This follows a partial write or an interrupted operation. The data on that page is usually intact, but the page is orphaned.

Run VACUUM. VACUUM rebuilds the entire file, copying only pages that are actually in use and discarding orphans. The file shrinks. After a VACUUM, run PRAGMA integrity_check; again to confirm the issue is gone.

B-tree Tree Page and Cell Damage

Errors that mention a tree page and a cell signal damage inside a table's B-tree structure. You might see tree page N is missing or cell N on page N is corrupt. These are serious. The table data itself is corrupted, not just an index.

REINDEX and VACUUM cannot fix B-tree damage. You need full recovery. Export every readable row from the damaged file using SELECT queries or the .dump command, then import into a fresh file. Work on a copy. If command-line recovery is not an option, an online service like sqlite.repair can help.

PRAGMA Quick_check a Faster Alternative

PRAGMA quick_check; runs faster than integrity_check. It skips verifying that index content matches table content. It checks only the internal consistency of each page and the B-tree structure. It will not catch index errors like row missing from index or wrong # of entries in index. Use quick_check for a rapid sanity test. Rely on the full integrity_check when you suspect index corruption.

Step-by-Step Action Plan

Make a copy of the file. Never run repair commands on the original when the data is important.
Run PRAGMA integrity_check; on the copy and note every error.
If you see row missing from index or wrong # of entries in index, run REINDEX on the affected index or on the whole file.
If you see Page N is never used, run VACUUM to reclaim orphaned pages.
If you see errors naming a tree page and a cell, the table data is corrupted. Export the readable data using .dump or SELECT into a fresh file.
After each fix, run PRAGMA integrity_check; again to verify the problem is resolved.

When Full Recovery is Needed

Full recovery is required when B-tree damage is present or when REINDEX and VACUUM do not clear the errors. Extract as much data as possible from the corrupted copy. Use SELECT queries on each table, or use the .dump command to produce a SQL script. Create a fresh file and run the script. Some rows may be lost, depending on the extent of the corruption. For severe cases, reach for a dedicated recovery tool. sqlite.repair handles corrupted SQLite files through a browser if you need an online option.