?? fileformat.html
字號:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><title>SQLite Database File Format (Version 2)</title><style type="text/css">body { margin: auto; font-family: "Verdana" "sans-serif"; padding: 8px 1%;}a { color: #45735f }a:visited { color: #734559 }.logo { position:absolute; margin:3px; }.tagline { float:right; text-align:right; font-style:italic; width:240px; margin:12px; margin-top:58px;}.toolbar { font-variant: small-caps; text-align: center; line-height: 1.6em; margin: 0; padding:1px 8px;}.toolbar a { color: white; text-decoration: none; padding: 6px 12px; }.toolbar a:visited { color: white; }.toolbar a:hover { color: #80a796; background: white; }.content { margin: 5%; }.content dt { font-weight:bold; }.content dd { margin-bottom: 25px; margin-left:20%; }.content ul { padding:0px; padding-left: 15px; margin:0px; }/* rounded corners */.se { background: url(images/se.png) 100% 100% no-repeat #80a796}.sw { background: url(images/sw.png) 0% 100% no-repeat }.ne { background: url(images/ne.png) 100% 0% no-repeat }.nw { background: url(images/nw.png) 0% 0% no-repeat }</style><meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head><body><div><!-- container div to satisfy validator --><a href="index.html"><img class="logo" src="images/SQLite.gif" alt="SQLite Logo" border="0"></a><div><!-- IE hack to prevent disappearing logo--></div><div class="tagline">Small. Fast. Reliable.<br>Choose any three.</div><table width=100% style="clear:both"><tr><td> <div class="se"><div class="sw"><div class="ne"><div class="nw"> <div class="toolbar"> <a href="about.html">About</a> <a href="sitemap.html">Sitemap</a> <a href="docs.html">Documentation</a> <a href="download.html">Download</a> <a href="copyright.html">License</a> <a href="news.html">News</a> <a href="http://www.sqlite.org/cvstrac/index">Developers</a> <a href="support.html">Support</a> </div></div></div></div></div></td></tr></table> <h2>SQLite 2.X Database File Format</h2><p>This document describes the disk file format for SQLite versions 2.1through 2.8. SQLite version 3.0 and following uses a very differentformat which is described separately.</p><h3>1.0 Layers</h3><p>SQLite is implemented in layers.(See the <a href="arch.html">architecture description</a>.)The format of database files is determined by three differentlayers in the architecture.</p><ul><li>The <b>schema</b> layer implemented by the VDBE.</li><li>The <b>b-tree</b> layer implemented by btree.c</li><li>The <b>pager</b> layer implemented by pager.c</li></ul><p>We will describe each layer beginning with the bottom (pager)layer and working upwards.</p><h3>2.0 The Pager Layer</h3><p>An SQLite database consists of"pages" of data. Each page is 1024 bytes in size.Pages are numbered beginning with 1.A page number of 0 is used to indicate "no such page" in theB-Tree and Schema layers.</p><p>The pager layer is responsible for implementing transactionswith atomic commit and rollback. It does this using a separatejournal file. Whenever a new transaction is started, a journalfile is created that records the original state of the database.If the program terminates before completing the transaction, the nextprocess to open the database can use the journal file to restorethe database to its original state.</p><p>The journal file is located in the same directory as the databasefile and has the same name as the database file but with thecharacters "<tt>-journal</tt>" appended.</p><p>The pager layer does not impose any content restrictions on themain database file. As far as the pager is concerned, each pagecontains 1024 bytes of arbitrary data. But there is structure tothe journal file.</p><p>A journal file begins with 8 bytes as follows:0xd9, 0xd5, 0x05, 0xf9, 0x20, 0xa1, 0x63, and 0xd6.Processes that are attempting to rollback a journal use these 8 bytesas a sanity check to make sure the file they think is a journal reallyis a valid journal. Prior version of SQLite used different journalfile formats. The magic numbers for these prior formats are differentso that if a new version of the library attempts to rollback a journalcreated by an earlier version, it can detect that the journal usesan obsolete format and make the necessary adjustments. This articledescribes only the newest journal format - supported as of version2.8.0.</p><p>Following the 8 byte prefix is a three 4-byte integers that tell usthe number of pages that have been committed to the journal,a magic number used forsanity checking each page, and theoriginal size of the main database file before the transaction wasstarted. The number of committed pages is used to limit how farinto the journal to read. The use of the checksum magic number isdescribed below.The original size of the database is used to restore the databasefile back to its original size.The size is expressed in pages (1024 bytes per page).</p><p>All three integers in the journal header and all other multi-bytenumbers used in the journal file are big-endian.That means that the most significant byteoccurs first. That way, a journal file that isoriginally created on one machine can be rolled back by anothermachine that uses a different byte order. So, for example, atransaction that failed to complete on your big-endian SparcStationcan still be rolled back on your little-endian Linux box.</p><p>After the 8-byte prefix and the three 4-byte integers, thejournal file consists of zero or more page records. Each pagerecord is a 4-byte (big-endian) page number followed by 1024 bytesof data and a 4-byte checksum. The data is the original content of the database pagebefore the transaction was started. So to roll back the transaction,the data is simply written into the corresponding page of themain database file. Pages can appear in the journal in any order,but they are guaranteed to appear only once. All page numbers will bebetween 1 and the maximum specified by the page size integer thatappeared at the beginning of the journal.</p><p>The so-called checksum at the end of each record is not really achecksum - it is the sum of the page number and the magic number whichwas the second integer in the journal header. The purpose of thisvalue is to try to detect journal corruption that might have occurredbecause of a power loss or OS crash that occurred which the journalfile was being written to disk. It could have been the case that themeta-data for the journal file, specifically the size of the file, hadbeen written to the disk so that when the machine reboots it appears thatfile is large enough to hold the current record. But even though thefile size has changed, the data for the file might not have made it tothe disk surface at the time of the OS crash or power loss. This meansthat after reboot, the end of the journal file will contain quasi-randomgarbage data. The checksum is an attempt to detect such corruption. Ifthe checksum does not match, that page of the journal is not rolled back.</p><p>Here is a summary of the journal file format:</p><ul><li>8 byte prefix: 0xd9, 0xd5, 0x05, 0xf9, 0x20, 0xa1, 0x63, 0xd6</li><li>4 byte number of records in journal</li><li>4 byte magic number used for page checksums</li><li>4 byte initial database page count</li><li>Zero or more instances of the following: <ul> <li>4 byte page number</li> <li>1024 bytes of original data for the page</li> <li>4 byte checksum</li> </ul></li></ul><h3>3.0 The B-Tree Layer</h3><p>The B-Tree layer builds on top of the pager layer to implementone or more separate b-trees all in the same disk file. Thealgorithms used are taken from Knuth's <i>The Art Of ComputerProgramming.</i></p><p>Page 1 of a database contains a header string used for sanitychecking, a few 32-bit words of configuration data, and a pointerAll other pages in thedatabase are either pages of a b-tree, overflow pages, or unusedpages on the freelist.</p><p>Each b-tree page contains zero or more database entries.Each entry has an unique key of one or more bytes and data ofzero or more bytes.Both the key and data are arbitrary byte sequences. The combinationof key and data are collectively known as "payload". The currentimplementation limits the amount of payload in a single entry to1048576 bytes. This limit can be raised to 16777216 by adjustinga single #define in the source code and recompiling. But most entriescontain less than a hundred bytes of payload so a megabyte limit seemsmore than enough.</p><p>Up to 238 bytes of payload for an entry can be held directly ona b-tree page. Any additional payload is contained on a linked listof overflow pages. This limit on the amount of payload held directlyon b-tree pages guarantees that each b-tree page can hold at least4 entries. In practice, most entries are smaller than 238 bytes andthus most pages can hold more than 4 entries.</p><p>A single database file can hold any number of separate, independent b-trees.Each b-tree is identified by its root page, which never changes.Child pages of the b-tree may change as entries are added and removedand pages split and combine. But the root page always stays the same.The b-tree itself does not record which pages are root pages and whichare not. That information is handled entirely at the schema layer.</p><h4>3.1 B-Tree Page 1 Details</h4><p>Page 1 begins with the following 48-byte string:</p><blockquote><pre>** This file contains an SQLite 2.1 database **</pre></blockquote><p>If you count the number of characters in the string above, you willsee that there are only 47. A '\000' terminator byte is added tobring the total to 48.?? 快捷鍵說明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -