1<?xml version="1.0" encoding="UTF-8" standalone="no"?> 2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3<html xmlns="http://www.w3.org/1999/xhtml"> 4 <head> 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 6 <title>A Note on System Failure</title> 7 <link rel="stylesheet" href="gettingStarted.css" type="text/css" /> 8 <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /> 9 <link rel="start" href="index.html" title="Getting Started with Berkeley DB Transaction Processing" /> 10 <link rel="up" href="introduction.html" title="Chapter��1.��Introduction" /> 11 <link rel="prev" href="introduction.html" title="Chapter��1.��Introduction" /> 12 <link rel="next" href="apireq.html" title="Application Requirements" /> 13 </head> 14 <body> 15 <div class="navheader"> 16 <table width="100%" summary="Navigation header"> 17 <tr> 18 <th colspan="3" align="center">A Note on System Failure</th> 19 </tr> 20 <tr> 21 <td width="20%" align="left"><a accesskey="p" href="introduction.html">Prev</a>��</td> 22 <th width="60%" align="center">Chapter��1.��Introduction</th> 23 <td width="20%" align="right">��<a accesskey="n" href="apireq.html">Next</a></td> 24 </tr> 25 </table> 26 <hr /> 27 </div> 28 <div class="sect1" lang="en" xml:lang="en"> 29 <div class="titlepage"> 30 <div> 31 <div> 32 <h2 class="title" style="clear: both"><a id="sysfailure"></a>A Note on System Failure</h2> 33 </div> 34 </div> 35 </div> 36 <p> 37 From time to time this manual mentions that transactions 38 protect your data against 'system or application failure.' This 39 is true up to a certain extent. However, not all failures are 40 created equal and no data protection mechanism can protect you 41 against every conceivable way a computing system can find to 42 die. 43 </p> 44 <p> 45 Generally, when this book talks about protection against 46 failures, it means that transactions offer protection against 47 the likeliest culprits for system and application crashes. So 48 long as your data modifications have been committed to disk, 49 those modifications should persist even if your application or 50 OS subsequently fails. And, even if the application or OS 51 fails in the middle of a transaction commit (or abort), the 52 data on disk should be either in a consistent state, or there 53 should be enough data available to bring your databases into a 54 consistent state (via a recovery procedure, for example). You 55 may, however, lose whatever data you were committing at the 56 time of the failure, but your databases will be otherwise 57 unaffected. 58 </p> 59 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> 60 <h3 class="title">Note</h3> 61 <p> 62 Be aware that many disks have a disk write cache and on 63 some systems it is enabled by default. This means that 64 a transaction can have committed, and to your 65 application the data may appear to reside on disk, but 66 the data may in fact reside only in the write cache at 67 that time. This means that if the disk write cache is 68 enabled and there is no battery backup for it, data can 69 be lost after an OS crash even when maximum durability 70 mode is in use. For maximum durability, disable the 71 disk write cache or use a disk write cache with a 72 battery backup. 73 </p> 74 </div> 75 <p> 76 Of course, if your <span class="emphasis"><em>disk</em></span> fails, then the transactional benefits described in this book 77 are only as good as the backups you have taken. 78 79 80 <span> 81 By spreading your data and log files across separate disks, 82 you can minimize the risk of data loss due to a disk 83 failure, but even in this case it is possible to conjure a 84 scenario where even this protection is insufficient (a fire 85 in the machine room, for example) and you must go to your 86 backups for protection. 87 </span> 88 </p> 89 <p> 90 Finally, by following the programming examples shown in this book, you can write your code so as to protect 91 your data in the event that your code crashes. However, no programming API can protect you against logic 92 failures in your own code; transactions cannot protect you from simply writing the wrong thing to your 93 databases. 94 </p> 95 </div> 96 <div class="navfooter"> 97 <hr /> 98 <table width="100%" summary="Navigation footer"> 99 <tr> 100 <td width="40%" align="left"><a accesskey="p" href="introduction.html">Prev</a>��</td> 101 <td width="20%" align="center"> 102 <a accesskey="u" href="introduction.html">Up</a> 103 </td> 104 <td width="40%" align="right">��<a accesskey="n" href="apireq.html">Next</a></td> 105 </tr> 106 <tr> 107 <td width="40%" align="left" valign="top">Chapter��1.��Introduction��</td> 108 <td width="20%" align="center"> 109 <a accesskey="h" href="index.html">Home</a> 110 </td> 111 <td width="40%" align="right" valign="top">��Application Requirements</td> 112 </tr> 113 </table> 114 </div> 115 </body> 116</html> 117