📄 fileio.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><title>No Title</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> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head> <link type="text/css" rel="stylesheet" href="images/fileformat/rtdocs.css"> <script type="text/javascript" src=images/fileformat/rtdocs.js></script></head><div id=document_title>SQLite File IO Specification</div><div id=toc_header>Table Of Contents</div><div id=toc> <b>Javascript is required for some features of this document, including table of contents, figure numbering and internal references (section numbers and hyper-links. </b></div><!-- End of standard rt docs header --><h1 id=overview>Overview</h1> <p> SQLite stores an entire database within a single file, the format of which is described in the <i>SQLite File Database File Format</i> document <cite>ff_sqlitert_requirements</cite>. Each database file is stored within a file system, presumably provided by the host operating system. Instead of interfacing with the operating system directly, the host application is required to supply an adaptor component that implements the <i>SQLite Virtual File System</i> interface (described in <cite>capi_sqlitert_requirements</cite>). The adaptor component is responsible for translating the calls made by SQLite to the <i>VFS</i> interface into calls to the file-system interface provided by the operating system. This arrangement is depicted in figure <cite>figure_vfs_role</cite>. <center><img src="images/fileformat/vfs_role.gif"> <p><i>Figure <span class=fig id=figure_vfs_role></span> - Virtual File System (VFS) Adaptor</i> </center> <p> Although it would be easy to design a system that uses the <i>VFS</i> interface to read and update the content of a database file stored within a file-system, there are several complicated issues that need to be addressed by such a system: <ol> <li><p>SQLite is required to <b>implement atomic and durable transactions</b> (the 'A' and 'D' from the ACID acronym), even if an application, operating system or power failure occurs midway through or shortly after updating a database file. <p>To implement atomic transactions in the face of potential application, operating system or power failures, database writers write a copy of those portions of the database file that they are going to modify into a second file, the <i>journal file</i>, before writing to the database file. If a failure does occur while modifying the database file, SQLite can reconstruct the original database (before the modifications were attempted) based on the contents of the <i>journal file</i>. <li><p>SQLite is required to <b>implement isolated transactions</b> (the 'I' from the ACID acronym). <p>This is done by using the file locking facililities provided by the VFS adaptor to serialize writers (write transactions) and preventing readers (read transactions) from accessing database files while writers are midway through updating them. <li><p>For performance reasons, it is advantageous to <b>minimize the quantity of data read and written</b> to and from the file-system. <p>As one might expect, the amount of data read from the database file is minimized by caching portions of the database file in main memory. Additionally, multiple updates to the database file that are part of the same <i>write transaction</i> may be cached in main memory and written to the file together, allowing for more efficient IO patterns and eliminating the redundant write operations that could take place if part of the database file is modified more than once within a single <i>write transaction</i>. </ol> <p class=todo> System requirement references for the above points. <p> This document describes in detail the way that SQLite uses the API provided by the VFS adaptor component to solve the problems and implement the strategies enumerated above. It also specifies the assumptions made about the properties of the system that the VFS adaptor provides access to. For example, specific assumptions about the extent of data corruption that may occur if a power failure occurs while a database file is being updated are presented in section <cite>fs_characteristics</cite>. <p> This document does not specify the details of the interface that must be implemented by the VFS adaptor component, that is left to <cite>capi_sqlitert_requirements</cite>. <h2>Relationship to Other Documents</h2> <p> Related to C-API requirements: <ol> <li>Opening a connection. <li>Closing a connection. </ol> <p> Related to SQL requirements: <ol> <li value=3>Opening a read-only transaction. <li>Terminating a read-only transaction. <li>Opening a read-write transaction. <li>Committing a read-write transaction. <li>Rolling back a read-write transaction. <li>Opening a statement transaction. <li>Committing a statement transaction. <li>Rolling back a statement transaction. <li>Committing a multi-file transaction. </ol> <p> Related to file-format requirements: <ol> <li value=12>Pinning (reading) a database page. <li>Unpinning a database page. <li>Modifying the contents of a database page. <li>Appending a new page to the database file. <li>Truncating a page from the end of the database file. </ol> <h2>Document Structure</h2> <p> Section <cite>vfs_assumptions</cite> of this document describes the various assumptions made about the system to which the VFS adaptor component provides access. The basic capabilities and functions required from the VFS implementation are presented along with the description of the VFS interface in <cite>capi_sqlitert_requirements</cite>. Section <cite>vfs_assumptions</cite> compliments this by describing in more detail the assumptions made about VFS implementations on which the algorithms presented in this document depend. Some of these assumptions relate to performance issues, but most concern the expected state of the file-system following a failure that occurs midway through modifying a database file. <p> Section <cite>database_connections</cite> introduces the concept of a <i>database connection</i>, a combination of a file-handle and in-memory cache used to access a database file. It also describes the VFS operations required when a new <i>database connection</i> is created (opened), and when one is destroyed (closed). <p> Section <cite>reading_data</cite> describes the steps required to open a <i>read transaction</i> and read data from a database file. <p> Section <cite>writing_data</cite> describes the steps required to open a <i>write transaction </i> and write data to a database file. <p> Section <cite>rollback</cite> describes the way in which aborted <i>write transactions</i> may be rolled back (reverted), either as a result of an explicit user directive or because an application, operating system or power failure occured while SQLite was midway through updating a database file. <p> Section <cite>page_cache_algorithms</cite> describes some of the algorithms used to determine exactly which portions of the database file are cached by a <i>page cache</i>, and the effect that they have on the quantity and nature of the required VFS operations. It may at first seem odd to include the <i>page cache</i>, which is primarily an implementation detail, in this document. However, it is necessary to acknowledge and describe the <i>page cache</i> in order to provide a more complete explanation of the nature and quantity of IO performed by SQLite. <h2>Glossary</h2> <p class=todo> After this document is ready, make the vocabulary consistent and then add a glossary here.<h1 id=vfs_assumptions>VFS Adaptor Related Assumptions</h1> <p> This section documents those assumptions made about the system that the VFS adaptor provides access to. The assumptions noted in section <cite>fs_characteristics</cite> are particularly important. If these assumptions are not true, then a power or operating system failure may cause SQLite databases to become corrupted.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -