Ir para o conteúdo
AZ Tools

Inspetor de bancos de dados SQLite

Lê um arquivo de banco SQLite do mesmo jeito que o próprio SQLite: direto dos bytes, sem motor SQL e sem que nada saia da sua máquina. O cabeçalho de 100 bytes informa o tamanho de página, a codificação do texto, se o banco está em modo rollback ou WAL, quantas páginas estão na lista de livres, o user_version e o application_id que a aplicação guarda ali, e com qual versão do SQLite o arquivo foi escrito pela última vez. Em seguida a árvore b do sqlite_schema, na página um, é percorrida para listar cada tabela, índice, visão e gatilho com a instrução CREATE que o definiu, e a árvore de cada tabela é percorrida até as folhas, de modo que as linhas são contadas e não estimadas. Vale conhecer dois limites antes de confiar em um número. No modo WAL os commits mais recentes costumam ficar no arquivo -wal e não no principal, então um banco sem checkpoint informa menos linhas do que a aplicação enxerga; copie também o -wal, ou rode um checkpoint, se a diferença importar. E uma tabela WITHOUT ROWID guarda as linhas em uma árvore de índice, por isso sua contagem aparece como desconhecida em vez de chutada. Nomes de coluna, tipos declarados e as marcas PRIMARY KEY e NOT NULL saem do texto da instrução CREATE, o que cobre esquemas comuns mas pode tropeçar em um DDL incomum — a instrução é sempre mostrada para você conferir. Bancos criptografados, inclusive com SQLCipher, são recusados em vez de lidos pela metade, porque o cabeçalho também está criptografado e não começa com a assinatura esperada. O conteúdo das linhas não é exibido de propósito: isto responde o que há no arquivo e quanto ele ocupa, não o que diz um registro específico.

Como usar

  1. Solte o arquivo .sqlite, .db ou .sqlite3 sobre a caixa, ou clique para escolher. Ele fica no navegador.
  2. Leia o cabeçalho primeiro: tamanho de página vezes número de páginas dá o tamanho do arquivo, e páginas livres são o que um VACUUM devolveria.
  3. Confira o modo de journal. Se for WAL, os commits ainda no -wal não estão aqui, então trate as linhas como um piso.
  4. Percorra a lista de tabelas para ver as linhas, as colunas com o tipo declarado e os índices de cada tabela.
  5. Abra a instrução CREATE de uma tabela quando a lista de colunas parecer errada — o DDL original é a autoridade.

Perguntas frequentes

Por que a contagem de linhas difere da que minha aplicação mostra?
Quase sempre por causa do log de escrita antecipada. No modo WAL o SQLite acrescenta páginas novas e alteradas a um arquivo -wal separado e só as integra ao banco principal em um checkpoint, então um banco copiado sem esse arquivo é um retrato do último checkpoint. Esta ferramenta lê apenas o arquivo que você entrega, de modo que inserções recentes podem faltar. Rode PRAGMA wal_checkpoint(TRUNCATE) antes de copiar, ou leve junto os arquivos -wal e -shm. A outra causa é uma tabela WITHOUT ROWID, cuja contagem aparece como desconhecida em vez de errada.
Ele abre um banco criptografado, por exemplo com SQLCipher?
Não, e vai dizer isso em vez de mostrar algo sem sentido. O SQLCipher criptografa o cabeçalho junto com as páginas, então um arquivo criptografado não começa com os bytes "SQLite format 3" e não há o que analisar sem a chave. Essa checagem também é o que separa um arquivo criptografado de um corrompido: um banco truncado mas sem criptografia ainda tem cabeçalho legível, e então lemos o que dá e avisamos que o número de páginas não bate com o tamanho do arquivo.
O que são páginas livres? Devo rodar VACUUM?
Apagar linhas não encolhe o arquivo: as páginas que as continham vão para a lista de livres e serão reaproveitadas por inserções futuras. Páginas livres são, portanto, espaço que o arquivo já tem e voltará a usar. O VACUUM reconstrói o banco sem elas e devolve o espaço ao sistema de arquivos, o que compensa depois de uma exclusão grande ou antes de distribuir o banco, mas reescreve o arquivo inteiro e invalida conexões abertas, então não é algo para rodar sem pensar em produção.
O que significam user_version e application_id?
São dois espaços de 32 bits no cabeçalho que o SQLite nunca toca e que as aplicações usam como quiserem. O comum é usar user_version como contador de migrações do esquema — a aplicação compara com a versão que o código espera e roda as migrações do intervalo — e application_id como número mágico que identifica o formato do arquivo, para que file(1) e ferramentas semelhantes distingam um tipo de banco SQLite de outro. Os dois valem zero se ninguém os definiu.
Qual a diferença entre versão e formato do esquema?
A versão do esquema, que o SQLite chama de cookie do esquema, é um contador que sobe a cada mudança de esquema; instruções preparadas o comparam para saber que precisam ser recompiladas. O formato do esquema é a geração do layout do arquivo, de 1 a 4, e diz quais recursos ele pode usar: 4 permite índices descendentes e literais booleanos, e é o que qualquer SQLite das últimas duas décadas escreve.
O arquivo é enviado para algum lugar?
Não. O banco é lido com a File API do próprio navegador e analisado por JavaScript na página; nada vai para um servidor, e não existe componente de servidor para onde mandar. Dá para confirmar abrindo a página, desconectando da rede e inspecionando um arquivo mesmo assim — tudo continua funcionando, porque a ferramenta inteira já está na página.

Ferramentas relacionadas