Documentation Source Text

Check-in [51202caa59]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Add documentation for the ".recover" command to the shell tool page.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 51202caa595a26a886239a821a3f21a2ccdf89d95ddc9fdeff917a026dd56727
User & Date: dan 2019-04-29 18:45:44
Context
2019-05-02
19:03
Use freopen() rather than assigning to "stdin" in althttpd.c. check-in: 229fda6dfb user: drh tags: trunk
2019-04-29
18:45
Add documentation for the ".recover" command to the shell tool page. check-in: 51202caa59 user: dan tags: trunk
16:21
Merge changes from the 3.28 branch. check-in: d220b2f30c user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/cli.in.

760
761
762
763
764
765
766





































































767
768
769
770
771
772
773
...
788
789
790
791
792
793
794

795
796
797
798
799
800
801
into other popular SQL database engines.  Like this:</p>


<tclscript>DisplayCode {
$ (((createdb ex2)))
$ (((sqlite3 ex1 .dump | psql ex2)))
}</tclscript>






































































<tcl>hd_fragment dotload</tcl>
<h1>Loading Extensions</h1>

<p>You can add new custom [application-defined SQL functions],
[collating sequences], [virtual tables], and [VFSes] to the command-line
shell at run-time using the ".load" command.  First, convert the
................................................................................
as a second argument to the ".load" command.

<p>Source code for several useful extensions can be found in the
<a href="http://www.sqlite.org/src/tree?name=ext/misc&ci=trunk">ext/misc</a>
subdirectory of the SQLite source tree.  You can use these extensions
as-is, or as a basis for creating your own custom extensions to address
your own particular needs.


<tcl>hd_fragment sha3sum {.sha3sum dot-command}</tcl>
<h1>Cryptographic Hashes Of Database Content</h1>

<p>The ".sha3sum" dot-command computes a
[https://en.wikipedia.org/wiki/SHA-3|SHA3] hash of the <em>content</em>
of the database.  To be clear, the hash is computed over the database content,







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







 







>







760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
...
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
into other popular SQL database engines.  Like this:</p>


<tclscript>DisplayCode {
$ (((createdb ex2)))
$ (((sqlite3 ex1 .dump | psql ex2)))
}</tclscript>

<tcl>hd_fragment recover {.recover dot-command}</tcl>
<h1>Recover Data From a Corrupted Database</h1>

<p>Like the ".dump" command, ".recover" attempts to convert the entire 
contents of a database file to text. The difference is that instead of
reading data using the normal SQL database interface, ".recover"
attempts to reassemble the database based on data extracted directly from 
as many database pages as possible. If the database is corrupt, ".recover"
is usually able to recover data from all uncorrupted parts of the database,
whereas ".dump" stops when the first sign of corruption is encountered.

<p>If the ".recover" command recovers one or more rows that it cannot 
attribute to any database table, the output script creates a "lost_and_found"
table to store the orphaned rows. The schema of the lost_and_found
table is as follows:

<tclscript>DisplayCode {
  CREATE TABLE lost_and_found(
    rootpgno INTEGER,             -- root page of tree pgno is a part of
    pgno INTEGER,                 -- page number row was found on
    nfield INTEGER,               -- number of fields in row
    id INTEGER,                   -- value of rowid field, or NULL
    c0, c1, c2, c3...             -- columns for fields of row
);
}</tclscript>

<p>The "lost_and_found" table contains one row for each orphaned row recovered
from the database. Additionally, there is one row for each recovered index
entry that cannot be attributed to any SQL index. This is because, in an
SQLite database, the same format is used to store SQL index entries and
WITHOUT ROWID table entries.

<table striped=1>
  <tr><th style="width:15ex">Column<th>Contents
  <tr><td>rootpgno<td> Even though it may not be possible to attribute the 
      row to a specific database table, it may be part of a tree structure
      within the database file. In this case, the root page number of that
      tree structure is stored in this column. Or, if the page the row was
      found on is not part of a tree structure, this column stores a copy of
      the value in column "pgno" - the page number of the page the row was
      found on. In many, although not all, cases, all rows in the
      lost_and_found table with the same value in this column belong to the
      same table.

  <tr><td>pgno<td> The page number of the page on which this row was found.

  <tr><td>nfield<td> The number of fields in this row.

  <tr><td>id<td> If the row comes from a WITHOUT ROWID table, this column 
      contains NULL. Otherwise, it contains the 64-bit integer rowid value for
      the row.

  <tr><td>c0,&nbsp;c1,&nbspc2...<td> The values for each column of the row
      are stored in these columns. The ".recover" command creates the
      lost_and_found table with as many columns as required by the longest
      orphaned row.
</table>

<p>If the recovered database schema already contains a table named
"lost_and_found", the ".recover" command uses the name "lost_and_found0". If
the name "lost_and_found0" is also already taken, "lost_and_found1", and so
on. The default name "lost_and_found" may be overridden by invoking ".recover"
with the --lost-and-found switch. For example, to have the output script call
the table "orphaned_rows":

<tclscript>DisplayCode {
  sqlite> .recover --lost-and-found orphaned_rows
}</tclscript>

<tcl>hd_fragment dotload</tcl>
<h1>Loading Extensions</h1>

<p>You can add new custom [application-defined SQL functions],
[collating sequences], [virtual tables], and [VFSes] to the command-line
shell at run-time using the ".load" command.  First, convert the
................................................................................
as a second argument to the ".load" command.

<p>Source code for several useful extensions can be found in the
<a href="http://www.sqlite.org/src/tree?name=ext/misc&ci=trunk">ext/misc</a>
subdirectory of the SQLite source tree.  You can use these extensions
as-is, or as a basis for creating your own custom extensions to address
your own particular needs.


<tcl>hd_fragment sha3sum {.sha3sum dot-command}</tcl>
<h1>Cryptographic Hashes Of Database Content</h1>

<p>The ".sha3sum" dot-command computes a
[https://en.wikipedia.org/wiki/SHA-3|SHA3] hash of the <em>content</em>
of the database.  To be clear, the hash is computed over the database content,