Figure $::SectionNumbers(fig) - $zCaption +
Figure $::SectionNumbers(fig) - $zCaption +
| Auto-vacuum last root-page | A page number stored as 32-bit integer at byte offset 52 of the database file header (see section file_header). In an auto-vacuum database, this is the numerically largest @@ -280,28 +350,28 @@ |
| Well formed database file | An SQLite database file that meets all the criteria laid out in section database_file_format of this document. |
The bulk of this document, section database_file_format, contains the definition of a well-formed SQLite database file. SQLite is required to create database files that meet this definition.
-
Additionally, the database file should contain a serialized version of the logical database produced by the transaction. For all but the most trivial logical databases, there are many possible serial representations.
-
This section describes the various fields and sub-structures that make up the format used by SQLite to serialize a logical SQL database.
@@ -352,11 +422,11 @@ systems using the SQLite database file format should only ever output well-formed SQLite databases. In the case of SQLite itself, the system should ensure that the database file is well-formed at the conclusion of each database transaction. -
A B-Tree is a data structure designed for offline storage of a set of unique key values. It is structured so as to support fast querying for a single key or range of keys. As implemented in SQLite, each entry may be associated with a blob of data that is not part of the @@ -417,20 +487,19 @@ Creates a database file containing three B-Tree structures: one table B-Tree to store the sqlite_master table, one table B-Tree to store table "t1", and one index B-Tree to store index "i1". The B-Tree structures created for the user table and index are populated as shown in figure figure_examplepop. -
- Figure - Example B-Tree Data. -
The following sections and sub-sections describe precisely the format used to house the B-Tree structures within an SQLite database file. -
Each SQLite database file begins with a 100-byte header. The header file consists of a well known 16-byte sequence followed by a series of 1, 2 and 4 byte unsigned integers. All integers in the file header (as well as the rest of the database file) are stored in big-endian format. @@ -447,17 +516,17 @@
The 1, 2 and 4 byte unsigned integers that make up the rest of the database file header are described in the following table. -
| Byte Range | Byte Size | Description - | ||||||
|---|---|---|---|---|---|---|---|---|
| 16..17 | 2 | + [Table] + [Tr] | Byte Range | Byte Size | Description + [Tr] | 16..17 | 2 | Database page size in bytes. See section pages_and_page_types for details. - |
| 18 | 1 | + [Tr] | 18 | 1 |
File-format "write version". Currently, this field is always set to 1. If a value greater than 1 is read by SQLite, then the library will only open the file for read-only access. @@ -468,11 +537,11 @@ that may be safely read but not written by older versions of SQLite, then this field will be set to a value greater than 1 to prevent older SQLite versions from writing to a file that uses the new format. - | |||
| 19 | 1 | + [Tr] | 19 | 1 |
File-format "read version". Currently, this field is always set to 1. If a value greater than 1 is read by SQLite, then the library will refuse to open the database @@ -482,42 +551,42 @@ it is ever required. If a version of SQLite created in the future uses a file format that may not be safely read by older SQLite versions, then this field will be set to a value greater than 1. - | |||
| 20 | 1 | + [Tr] | 20 | 1 | Number of bytes of unused space at the end of each database page. Usually this field is set to 0. If it is non-zero, then it contains the number of bytes that are left unused at the end of every database page (see section pages_and_page_types for a description of a database page). - | |||
| 21 | 1 | + [Tr] | 21 | 1 | Maximum fraction of an index tree page to use for embedded content. This value is used to determine the maximum size of a B-Tree cell to store as embedded content on a page that is part of an index B-Tree. Refer to section index_btree_cell_format for details. - | |||
| 22 | 1 | + [Tr] | 22 | 1 | Minimum fraction of an index B-Tree page to use for embedded content when an entry uses one or more overflow pages. This value is used to determine the portion of a B-Tree cell that requires one or more overflow pages to store as embedded content on a page that is part of an index B-Tree. Refer to section index_btree_cell_format for details. - | |||
| 23 | 1 | + [Tr] | 23 | 1 | Minimum fraction of an table B-Tree leaf page to use for embedded content when an entry uses one or more overflow pages. This value is used to determine the portion of a B-Tree cell that requires one or more overflow pages to store as embedded content on a page that is a leaf of a table B-Tree. Refer to section table_btree_cell_format for details. - | |||
| 24..27 | 4 | + [Tr] | 24..27 | 4 |
The file change counter. Each time a database transaction is committed, the value of the 32-bit unsigned integer stored in this field is incremented. @@ -529,25 +598,25 @@ first process. When the file is relocked, the first process can check if the value of the file change counter has been modified since the file was unlocked. If it has not, then the internal cache may be assumed to be valid and may be reused. - | |||
| 32..35 | 4 | + [Tr] | 32..35 | 4 | Page number of first freelist trunk page. For more details, refer to section free_page_list. - | |||
| 36..39 | 4 | + [Tr] | 36..39 | 4 | Number of free pages in the database file. For more details, refer to section free_page_list. - | |||
| 40..43 | 4 | + [Tr] | 40..43 | 4 | The schema version. Each time the database schema is modified (by creating or deleting a database table, index, trigger or view) the value of the 32-bit unsigned integer stored in this field is incremented. - | |||
| 44..47 | 4 | + [Tr] | 44..47 | 4 |
Schema layer file-format. This value is similar to the "read-version" and "write-version" fields at offsets 18 and 19 of the database file header. If SQLite encounters a database with a schema layer file-format value greater than the file-format @@ -567,32 +636,32 @@ in database records (see section record_format, serial types 8 and 9). - | |||
| 48..51 | 4 | + [Tr] | 48..51 | 4 | Default pager cache size. This field is used by SQLite to store the recommended pager cache size to use for the database. - | |||
| 52..55 | 4 | + [Tr] | 52..55 | 4 | For auto-vacuum capable databases, the numerically largest root-page number in the database. Since page 1 is always the root-page of the schema table (section schema_table), this value is always non-zero for auto-vacuum databases. For non-auto-vacuum databases, this value is always zero. - | |||
| 56..59 | 4 | + [Tr] | 56..59 | 4 | (constant) Database text encoding. A value of 1 means all text values are stored using UTF-8 encoding. 2 indicates little-endian UTF-16 text. A value of 3 means that the database contains big-endian UTF-16 text. - | |||
| 60..63 | 4 | + [Tr] | 60..63 | 4 | The user-cookie value. A 32-bit integer value available to the user for read/write access. - | |||
| 64..67 | 4 | + [Tr] | 64..67 | 4 | The incremental-vacuum flag. In non-auto-vacuum databases this value is always zero. In auto-vacuum databases, this field is set to 1 if "incremental vacuum" mode is enabled. If incremental vacuum mode is not enabled, then the database file is reorganized so that it contains no free pages (section @@ -600,10 +669,11 @@ transaction. If incremental vacuum mode is enabled, then the reorganization is not performed until explicitly requested by the user. |
The four byte block beginning at offset 28 is unused. As is the 32 byte block beginning at offset 68.
@@ -614,64 +684,64 @@ done to artificially constrain the definition of a well-formed database in order to make implementation and testing more practical.
-
Following the 16 byte magic string in the file header is the page size, a 2-byte field. See section pages_and_page_types for details.
-
-
-
-
-
-
-
Following the file change counter in the database header are two 4-byte fields related to the database file free page list. See section free_page_list for details.
-
-
-
-
-
-
-
-
The entire database file is divided into pages, each page consisting of page-size bytes, where page-size is the 2-byte integer value stored at offset 16 of the file header (see above). The page-size is always a power of two between 512 @@ -700,20 +770,20 @@ byte offset 230, if it is large enough to contain such a page, is always left unused.
-
-
-
-
Apart from being the page that contains the file-header, page 1 of the database file is special because it is the root page of the B-Tree structure that contains the schema table data. From the SQL level, the schema table is accessible via the name "sqlite_master". @@ -732,38 +802,38 @@ and view in the logical database. There is also an entry for each UNIQUE or PRIMARY KEY clause present in the definition of a database table. Each record in the schema table contains exactly 5 values, in the following order: -
| Field | Description - | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Schema item type. + [Table] + [Tr] | Field | Description + [Tr] | Schema item type. | A string value. One of "table", "index", "trigger" or "view", according to the schema item type. Entries associated with UNIQUE or PRIMARY KEY clauses have this field set to "index". - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Schema item name. + [Tr] | Schema item name. | A string value. The name of the database schema item (table, index, trigger or view) associated with this record, if any. Entries associated with UNIQUE or PRIMARY KEY clauses have this field set to a string of the form "sqlite_autoindex_<name>_<idx>" where <name> is the name of the SQL table and <idx> is an integer value. - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Associated table name. + [Tr] | Associated table name. | A string value. For "table" or "view" records this is a copy of the second (previous) value. For "index" and "trigger" records, this field is set to the name of the associated database table. - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| The "root page" number. + [Tr] | The "root page" number. | For "trigger" and "view" records, as well as "table" records associated with virtual tables, this is set to NULL. For other "table" and "index" records (including those associated with UNIQUE or PRIMARY KEY clauses), this field contains the root page number (an integer) of the B-Tree structure that contains the table or index data. - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| The SQL statement. + [Tr] | The SQL statement. | A string value. The SQL statement used to create the schema
item (i.e. the complete text of an SQL "CREATE TABLE"
statement). This field contains an empty string for table
entries associated with PRIMARY KEY or UNIQUE clauses.
Refer to some document that describes these
@@ -805,111 +875,111 @@
CREATE VIEW v1 AS SELECT * FROM abc;
Then the schema table would contain a total of 7 records, as follows: -
-
- The following requirements describe "table" records.
-
-
-
-
-
-
- The following requirements describe "implicit index" records.
-
-
-
- The following requirements describe "explicit index" records.
-
-
-
- The following requirements describe "view" records.
-
-
-
- The following requirements describe "trigger" records.
-
-
-
- The following requirements describe the placement of B-Tree root pages in auto-vacuum databases.
-
- B-Tree Structures+ [h2 "B-Tree Structures" "btree_structures"]A large part of any SQLite database file is given over to one or more B-Tree structures. A single B-Tree structure is stored using one or more database pages. Each page contains a single B-Tree node. The pages used to store a single B-Tree structure need not form a @@ -928,15 +998,15 @@ B-Tree structures are described in detail in section index_btrees.
-
- Variable Length Integer Format+ [h3 "Variable Length Integer Format" "varint_format"]In several parts of the B-Tree structure, 64-bit twos-complement signed integer values are stored in the "variable length integer format" described here. @@ -953,21 +1023,21 @@ always encoded using the full nine bytes. Positive integers may be encoded using less space. The following table shows the 9 different length formats available for storing a variable length integer value. -
When using the full 9 byte representation, the first byte contains the 7 most significant bits of the 64-bit value. The final byte of the 9 byte representation contains the 8 least significant bits of @@ -981,34 +1051,34 @@ most compact representation that provides enough storage to accomadate the most significant set bit of the value. This is not required however, using more bytes than is strictly necessary when encoding an integer is valid. -
-
-
-
- Database Record Format+ [h3 "Database Record Format" "record_format"]A database record is a blob of data that represents an ordered list of one or more SQL values. Database records are used in two places in SQLite database files - as the associated data for entries in table B-Tree structures, and as the key values in index B-Tree @@ -1024,67 +1094,66 @@ size of the record header in bytes. The following N variable length integer values each describe the type and size of the records corresponding SQL value (the second integer in the record header describes the first value in the record, etc.). Integer values are interpreted according to the following table: -
Immediately following the record header is the data for each of the record's values. A record containing N values is depicted in figure figure_recordformat. - 
- Figure - Database Record Format. - For each SQL value in the record, there is a blob of data stored in the records data area. If the corresponding integer type value in the record header is 0 (NULL), 8 (integer value 0) or 9 (integer @@ -1095,60 +1164,60 @@ encoded using the database encoding, as defined in the database file header (see section file_header). No nul-terminator character is stored in the database.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- The following database file properties define restrictions on the integer values that may be stored within a database record header.
-
- Index B-Trees+ [h3 "Index B-Trees" index_btrees]As specified in section fileformat_overview, index B-Tree structures store a unique set of the database records described in the previous section. While in some cases, when there are very few entries in the B-Tree, the entire structure may fit on a single @@ -1177,39 +1246,39 @@ index_btree_compare_func. Similarly all records stored in the sub-tree headed by C(n) are considered greater than R(n-1) but less than R(n) for values of n between 1 and N-2, inclusive. All records in the sub-tree headed by C(N-1) are greater than the largest record stored on the internal node. - 
- Figure - Index B-Tree Tree Structure. - Figure figure_indextree depicts one possible record distribution for an index B-Tree containing records R1 to R26, assuming that for all values of N, R(N+1)>R(N). In total the B-Tree structure uses 11 database file pages. Internal tree nodes contain database records and references to child node pages. Leaf nodes contain database records only.
-
-
-
- The precise way in which index B-Tree pages and cells are formatted is described in subsequent sections. - Index B-Tree Content+ [h4 "Index B-Tree Content"]The database file contains one index B-Tree for each database index in the logical database, including those created by UNIQUE or PRIMARY KEY clauses in table declarations. Each record stored in an index B-Tree contains the same number of fields, the number of @@ -1220,22 +1289,22 @@ key are copies of each of the indexed columns of the associated database row, in order, followed by the rowid value of the same row. See figure figure_examplepop for an example.
-
-
-
- Record Sort Order+ [h4 "Record Sort Order" "index_btree_compare_func"]This section defines the comparison function used when database records are used as B-Tree keys for index B-Trees. The comparison function is only defined when both database records contain the same number of fields. @@ -1284,11 +1353,11 @@ Need requirements style statements for this information. Easier to do once collation sequences have been defined somewhere. - Index B-Tree Page Format+ [h4 "Index B-Tree Page Format" index_btree_page_format]Each index B-Tree page is divided into four sections that occur in order on the page:
- Figure - Index B-Tree Page Data. - The 8 (leaf node pages) or 12 (internal tree node pages) byte page header that begins each index B-Tree page is made up of a series of 1, 2 and 4 byte unsigned integer values as shown in the following table. All values are stored in big-endian byte order. -
-
- The following requirements describe the B-Tree page header present at the start of both index and table B-Tree pages.
-
-
-
- This requirement describes the cell content offset array. It applies to both B-Tree variants.
-
-
-
-
- The following requirements govern management of free-space within the page content area (both table and index B-Tree pages).
-
-
-
-
- Index B-Tree Cell Format+ [h4 "Index B-Tree Cell Format" index_btree_cell_format]For index B-Tree internal tree node pages, each B-Tree cell begins with a child page-number, stored as a 4-byte big-endian unsigned integer. This field is omitted for leaf pages, which have no children. @@ -1457,13 +1524,11 @@ bytes. In the formula above, usable-size is the page-size in bytes less the number of unused bytes left at the end of every page (as read from byte offset 20 of the file header), and max-embedded-fraction is the value read from byte offset 21 of the file header. - 
- Figure - Small Record Index B-Tree Cell. - If the cell record is larger than the maximum size identified by the formula above, then only the first part of the record is stored within the cell. The remainder is stored in an overflow-chain (see section overflow_page_chains for details). Following @@ -1485,39 +1550,36 @@ in bytes less the number of unused bytes left at the end of every page (as read from byte offset 20 of the file header), and max-embedded-fraction and min-embedded-fraction are the values read from byte offsets 21 and 22 of the file header, respectively. - 
- Figure - - Large Record Index B-Tree Cell. -
-
-
-
-
- Requirements H31010 and H30990 are similar to the algorithms presented in the text above. However instead of min-embedded-fraction and max-embedded-fraction the requirements use the constant values 32 and 64, as well-formed database files are required by H30080 and H30070 to store these values in the relevant database file header fields. - Table B-Trees+ [h3 "Table B-Trees" table_btrees]As noted in section fileformat_overview, table B-Trees store a set of unique 64-bit signed integer keys. Associated with each key is a database record. As with index B-Trees, the database file pages that make up a table B-Tree are organized into a tree @@ -1537,38 +1599,38 @@ tree nodes, integer I(n) is equal to the largest key value stored in the sub-tree headed by child page C(n) for values of n between 0 and N-2, inclusive. Additionally, all keys stored in the sub-tree headed by child page C(n+1) have values larger than that of I(n), for values of n in the same range. - 
- Figure - Table B-Tree Tree Structure. - Figure figure_tabletree depicts a table B-Tree containing a contiguous set of 14 integer keys starting with 1. Each key n has an associated database record Rn. All the keys and their associated records are stored in the leaf pages. The internal node pages contain no database data, their only purpose is to provide a way to navigate the tree structure.
-
-
-
- The precise way in which table B-Tree pages and cells are formatted is described in subsequent sections. - Table B-Tree Content+ [h4 "Table B-Tree Content" table_btree_content]The database file contains one table B-Tree for each database table in the logical database. Although some data may be duplicated in index B-Tree structures, the table B-Tree is the primary location of table data. @@ -1599,34 +1661,34 @@ columns. Reference to CREATE TABLE syntax. How are default values determined?
-
-
-
- The following database properties discuss table B-Tree records with implicit (default) values.
-
-
- Table B-Tree Page Format+ [h4 "Table B-Tree Page Format"]Table B-Tree structures use the same page format as index B-Tree structures, described in section index_btree_page_format, with the following differences:
-
- Most of the requirements specified in section index_btree_page_format also apply to table B-Tree pages. The wording of the requirements make it clear when this is the case, either by refering to generic "B-Tree pages" or by explicitly stating that the statement applies to both "table and index B-Tree pages". - Table B-Tree Cell Format+ [h4 "Table B-Tree Cell Format" table_btree_cell_format]Cells stored on internal table B-Tree nodes consist of exactly two fields. The associated child page number, stored as a 4-byte big-endian unsigned integer, followed by the 64-bit signed integer value, stored as a variable length integer (section varint_format). This is depicted graphically in figure figure_tablenodecell. - 
- Figure - Table B-Tree Internal Node Cell. - Cells of table B-Tree leaf pages are required to store a 64-bit signed integer key and its associated database record. The first two fields of all table B-Tree leaf page cells are the size of the database record, stored as a variable length integer @@ -1682,13 +1742,11 @@ in bytes less the number of unused bytes left at the end of every page (as read from byte offset 20 of the file header). This scenario, where the entire record is stored within the B-Tree cell, is depicted in figure figure_tableshortrecord. - 
- Figure - Table B-Tree Small Record Leaf Node Cell. - If the record is too large to be stored entirely within the B-Tree cell, then the first part of it is stored within the cell and the remainder in an overflow chain (see section @@ -1709,13 +1767,11 @@ In this case, min-embedded-fraction is the value read from byte offset 22 of the file header. The layout of the cell in this case, when an overflow-chain is required, is shown in figure figure_tablelongrecord. - 
- Figure - Table B-Tree Large Record Leaf Node Cell. - If the leaf page is page 1, then the value of usable-size is as it would be for any other B-Tree page, even though the actual usable size is 100 bytes less than this for page 1 (because the @@ -1726,44 +1782,44 @@ The following requirements describe the format of table B-Tree cells, and the distribution thereof between B-Tree and overflow pages.
-
-
-
-
- Requirement H31190 is very similar to the algorithm presented in the text above. Instead of min-embedded-fraction, it uses the constant value 32, as well-formed database files are required by H30090 to store this value in the relevant database file header field. - Overflow Page Chains+ [h3 "Overflow Page Chains" "overflow_page_chains"]Sometimes, a database record stored in either an index or table B-Trees is too large to fit entirely within a B-Tree cell. In this case part of the record is stored within the B-Tree cell and the remainder stored on one or more overflow pages. The overflow pages are chained together using a singly linked list. The first 4 bytes of each overflow page is a big-endian unsigned integer value containing the page number of the next page in the list. The remaining usable database page space is available for record data. - 
- Figure - Overflow Page Format. - The scenarios in which overflow pages are required and the number of bytes stored within the B-Tree cell in each are described for index and table B-Trees in sections index_btree_cell_format and @@ -1786,22 +1842,22 @@ page in the list contains the remaining data, starting at byte offset 4. The value of the "next page" field on the last page in an overflow chain is undefined.
-
-
-
- The Free Page List+ [h2 "The Free Page List" free_page_list]Sometimes, after deleting data from the database, SQLite removes pages from B-Tree structures. If these pages are not immediately required for some other purpose, they are placed on the free page list. The free page list contains those pages that are not currently being @@ -1829,93 +1885,90 @@ pointers, where usable-size is defined as the page-size in bytes less the number of unused bytes left at the end of every page (as read from byte offset 20 of the file header). - 
- Figure - Free List Trunk Page Format. - All trunk pages in the free-list except for the first contain the maximum possible number of references to leaf pages. Is this actually true in an auto-vacuum capable database? The page number of the first page in the linked list of free-list trunk pages is stored as a 4-byte big-endian unsigned integer at offset 32 of the file header (section file_header).
-
-
-
-
-
-
- The following statements govern the two 4-byte big-endian integers associated with the free page list structure in the database file header.
-
- Pointer Map Pages+ [h2 "Pointer Map Pages" pointer_map_pages]Pointer map pages are only present in auto-vacuum capable databases. A database is an auto-vacuum capable database if the value stored at byte offset 52 of the file-header is non-zero. If they are present, the pointer-map pages together form a lookup table that can be used to determine the type and "parent page" of any page in the database, given its page number. The lookup table classifies pages into the following categories: -
Pointer map pages themselves do not appear in the pointer-map lookup table. Page 1 does not appear in the pointer-map lookup table either. - 
- Figure - Pointer Map Entry Format. - Each pointer-map lookup table entry consumes 5 bytes of space. The first byte of each entry indicates the page type, according to the key described in the table above. The following 4 bytes store the parent page number as a big-endian unsigned integer. This format is @@ -1947,39 +2000,39 @@ pointer-map-page-number := 2 + n * num-entries
-
-
-
-
- The following requirements govern the content of pointer-map entries.
-
-
-
-
- Journal File Format+[h1 "Journal File Format" journal_file_format]This section describes the format used by an SQLite journal file. @@ -1993,11 +2046,11 @@ may contain. Following the journal headers and their accompanying sets of journal records may be the optional master journal pointer. Or, the file may simply end following the final journal record. - Journal Header Format+ [h2 "Journal Header Format" journal_header_format]A journal header is sector-size bytes in size, where sector-size is the value returned by the xSectorSize method of the file handle opened on the database file. Only the first 28 bytes @@ -2004,44 +2057,42 @@ of the journal header are used, the remainder may contain garbage data. The first 28 bytes of each journal header consists of an eight byte block set to a well-known value, followed by five big-endian 32-bit unsigned integer fields. - 
- Figure - Journal Header Format - Figure figure_journal_header graphically depicts the layout of a journal header. The individual fields are described in the following table. The offsets in the 'byte offset' column of the table are relative to the start of the journal header. -
@@ -2049,38 +2100,36 @@ start at a sector size aligned offset. To achieve this, unused space may be left between the start of the second and subsequent journal headers and the end of the journal records associated with the previous header. - Journal Record Format+ [h2 "Journal Record Format" journal_record_format]Each journal record contains the original data for a database page modified by the write transaction. If a rollback is required, then this data may be used to restore the contents of the database page to the state it was in before the write transaction was started. - 
- Figure - Journal Record Format - A journal record, depicted graphically by figure figure_journal_record, contains three fields, as described in the following table. Byte offsets are relative to the start of the journal record. -
|
-