File Manager

003 File Manager

Current Path: /usr/local/share/doc/db5/programmer_reference

usr / local / share / doc / db5 / programmer_reference /

📁 ..
📄 BDB_Prog_Reference.pdf(1.9 MB)
📄 am.html(13.27 KB)
📄 am_close.html(4.17 KB)
📄 am_conf.html(13.76 KB)
📄 am_conf_logrec.html(7.32 KB)
📄 am_conf_select.html(24.85 KB)
📄 am_cursor.html(36.58 KB)
📄 am_delete.html(2.95 KB)
📄 am_foreign.html(9.84 KB)
📄 am_get.html(4.07 KB)
📄 am_misc.html(6.3 KB)
📄 am_misc_bulk.html(17.31 KB)
📄 am_misc_db_sql.html(4.79 KB)
📄 am_misc_dbsizes.html(4.06 KB)
📄 am_misc_diskspace.html(11.57 KB)
📄 am_misc_error.html(4.83 KB)
📄 am_misc_faq.html(10.34 KB)
📄 am_misc_partial.html(7.81 KB)
📄 am_misc_perm.html(4.19 KB)
📄 am_misc_stability.html(4.82 KB)
📄 am_misc_struct.html(5.06 KB)
📄 am_misc_tune.html(9.91 KB)
📄 am_opensub.html(7.84 KB)
📄 am_partition.html(17.19 KB)
📄 am_put.html(4.68 KB)
📄 am_second.html(14.76 KB)
📄 am_stat.html(3.11 KB)
📄 am_sync.html(3.63 KB)
📄 am_truncate.html(2.54 KB)
📄 am_upgrade.html(4.72 KB)
📄 am_verify.html(4.77 KB)
📄 apprec.html(8.14 KB)
📄 apprec_auto.html(12.16 KB)
📄 apprec_config.html(10 KB)
📄 apprec_def.html(9.13 KB)
📄 arch.html(11.09 KB)
📄 arch_apis.html(10.27 KB)
📄 arch_bigpic.gif(2.53 KB)
📄 arch_progmodel.html(3.1 KB)
📄 arch_script.html(4.39 KB)
📄 arch_smallpic.gif(1.58 KB)
📄 arch_utilities.html(8 KB)
📄 bdb_usenix.pdf(79.81 KB)
📄 bt_conf.html(29.94 KB)
📄 cam.html(11.77 KB)
📄 cam_app.html(16.91 KB)
📄 cam_fail.html(7.77 KB)
📄 ch13s02.html(4.19 KB)
📄 csharp.html(7.48 KB)
📄 dumpload.html(5.42 KB)
📄 dumpload_format.html(6.58 KB)
📄 dumpload_text.html(3.39 KB)
📄 embedded.html(31.62 KB)
📄 env.html(7.43 KB)
📄 env_create.html(10.06 KB)
📄 env_db_config.html(4.21 KB)
📄 env_encrypt.html(10.19 KB)
📄 env_error.html(4.77 KB)
📄 env_faq.html(5.54 KB)
📄 env_naming.html(15.54 KB)
📄 env_open.html(4.95 KB)
📄 env_region.html(8.11 KB)
📄 env_remote.html(5.28 KB)
📄 env_security.html(5.64 KB)
📄 env_size.html(8.11 KB)
📄 ext.html(7.13 KB)
📄 ext_perl.html(3.84 KB)
📄 ext_php.html(5.47 KB)
📄 general_am_conf.html(21.43 KB)
📄 gettingStarted.css(1.13 KB)
📄 group_membership.html(20.37 KB)
📄 hash_conf.html(6.96 KB)
📄 hash_usenix.pdf(256.14 KB)
📄 heap_conf.html(4.14 KB)
📄 index.html(77.48 KB)
📄 intro.html(9.57 KB)
📄 intro_dbis.html(15.02 KB)
📄 intro_dbisnot.html(13.49 KB)
📄 intro_distrib.html(2.92 KB)
📄 intro_need.html(5.06 KB)
📄 intro_products.html(14.3 KB)
📄 intro_terrain.html(19.43 KB)
📄 intro_what.html(4.94 KB)
📄 intro_where.html(3.75 KB)
📄 java.html(7.62 KB)
📄 java_compat.html(2.57 KB)
📄 java_faq.html(7.5 KB)
📄 java_program.html(6.69 KB)
📄 libtp_usenix.pdf(243.14 KB)
📄 lock.html(11.29 KB)
📄 lock_am_conv.html(10.62 KB)
📄 lock_cam_conv.html(4.95 KB)
📄 lock_config.html(4.67 KB)
📄 lock_dead.html(7.25 KB)
📄 lock_deaddbg.html(10.32 KB)
📄 lock_max.html(11.04 KB)
📄 lock_nondb.html(4.94 KB)
📄 lock_notxn.html(4.55 KB)
📄 lock_page.html(5.71 KB)
📄 lock_stdmode.html(5.27 KB)
📄 lock_timeout.html(6.16 KB)
📄 lock_twopl.html(4.48 KB)
📄 log.html(7.08 KB)
📄 log_config.html(5.06 KB)
📄 log_limits.html(4.24 KB)
📄 magic.s5.be.txt(3.54 KB)
📄 magic.s5.le.txt(3.56 KB)
📄 magic.txt(1.98 KB)
📄 moreinfo.html(7.45 KB)
📄 mp.html(8.86 KB)
📄 mp_config.html(6.08 KB)
📄 mp_warm.html(13.45 KB)
📄 preface.html(5.1 KB)
📄 program.html(7.21 KB)
📄 program_cache.html(3.3 KB)
📄 program_compatible.html(3.66 KB)
📄 program_copy.html(7.35 KB)
📄 program_environ.html(3.58 KB)
📄 program_errorret.html(10.38 KB)
📄 program_faq.html(4.58 KB)
📄 program_mt.html(7.54 KB)
📄 program_namespace.html(5.66 KB)
📄 program_perfmon.html(32.07 KB)
📄 program_ram.html(12.58 KB)
📄 program_runtime.html(7.09 KB)
📄 program_scope.html(9.8 KB)
📄 refs.html(11.84 KB)
📄 rep.html(16.57 KB)
📄 rep_app.html(9.75 KB)
📄 rep_base_meth.html(8.59 KB)
📄 rep_bulk.html(4.01 KB)
📄 rep_clock_skew.html(5.38 KB)
📄 rep_comm.html(11.28 KB)
📄 rep_elect.html(13.17 KB)
📄 rep_ex.html(9.64 KB)
📄 rep_ex_chan.html(8.52 KB)
📄 rep_ex_comm.html(7.58 KB)
📄 rep_ex_rq.html(5.52 KB)
📄 rep_faq.html(9.2 KB)
📄 rep_filename.html(7.7 KB)
📄 rep_id.html(4.76 KB)
📄 rep_init.html(5.14 KB)
📄 rep_lease.html(18.32 KB)
📄 rep_mastersync.html(11.24 KB)
📄 rep_mgr_ack.html(8.5 KB)
📄 rep_mgr_meth.html(11.06 KB)
📄 rep_mgrmulti.html(10.28 KB)
📄 rep_newsite.html(5.29 KB)
📄 rep_partition.html(9.21 KB)
📄 rep_pri.html(3.64 KB)
📄 rep_replicate.html(18.8 KB)
📄 rep_ryw.html(9.82 KB)
📄 rep_trans.html(21.58 KB)
📄 rep_twosite.html(6.76 KB)
📄 repmgr_channels.html(13.34 KB)
📄 rq_conf.html(18.29 KB)
📄 second.javas(3.87 KB)
📄 sequence.html(4.43 KB)
📄 solaris.txt(5.62 KB)
📄 stl.html(16.28 KB)
📄 stl_complex_rw.html(19.31 KB)
📄 stl_container_specific.html(9.04 KB)
📄 stl_db_advanced_usage.html(9.68 KB)
📄 stl_db_usage.html(13.27 KB)
📄 stl_efficienct_use.html(11.87 KB)
📄 stl_examples.html(8.24 KB)
📄 stl_known_issues.html(4.54 KB)
📄 stl_memory_mgmt.html(9.22 KB)
📄 stl_misc.html(8.22 KB)
📄 stl_mt_usage.html(9.06 KB)
📄 stl_persistence.html(14.74 KB)
📄 stl_primitive_rw.html(8.18 KB)
📄 stl_txn_usage.html(4.88 KB)
📄 stl_usecase.html(3.67 KB)
📄 tcl.html(7.88 KB)
📄 tcl_error.html(5.2 KB)
📄 tcl_faq.html(4.89 KB)
📄 tcl_program.html(3.78 KB)
📄 tcl_using.html(4.43 KB)
📄 transapp.cs(10.34 KB)
📄 transapp.html(8.55 KB)
📄 transapp_admin.html(4.8 KB)
📄 transapp_app.html(25.08 KB)
📄 transapp_archival.html(15.5 KB)
📄 transapp_atomicity.html(5.46 KB)
📄 transapp_checkpoint.html(6.18 KB)
📄 transapp_cursor.html(6.79 KB)
📄 transapp_data_open.html(7.52 KB)
📄 transapp_deadlock.html(7.35 KB)
📄 transapp_env_open.html(8.39 KB)
📄 transapp_fail.html(6.8 KB)
📄 transapp_faq.html(11.26 KB)
📄 transapp_filesys.html(5.89 KB)
📄 transapp_hotfail.html(10.54 KB)
📄 transapp_inc.html(8.09 KB)
📄 transapp_journal.html(4.72 KB)
📄 transapp_logfile.html(5.3 KB)
📄 transapp_nested.html(5.42 KB)
📄 transapp_put.html(12.47 KB)
📄 transapp_read.html(9.9 KB)
📄 transapp_reclimit.html(12.6 KB)
📄 transapp_recovery.html(8.74 KB)
📄 transapp_term.html(6.02 KB)
📄 transapp_throughput.html(9.06 KB)
📄 transapp_tune.html(13.99 KB)
📄 transapp_why.html(3.94 KB)
📄 txn.html(8.63 KB)
📄 txn_config.html(4.5 KB)
📄 txn_limits.html(5.77 KB)
📄 witold.html(745 B)
📄 writetest.cs(2.26 KB)
📄 xa.html(6.69 KB)
📄 xa_build.html(19.12 KB)
📄 xa_faq.html(7.27 KB)
📄 xa_xa_config.html(8.1 KB)
📄 xa_xa_intro.html(4.46 KB)
📄 xa_xa_restrict.html(6.02 KB)

Editing: transapp_archival.html

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Database and log file archival</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="transapp.html" title="Chapter 11.  Berkeley DB Transactional Data Store Applications" />
    <link rel="prev" href="transapp_checkpoint.html" title="Checkpoints" />
    <link rel="next" href="transapp_logfile.html" title="Log file removal" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 11.2.5.3</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Database and log file archival</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="transapp_checkpoint.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 11. 
		Berkeley DB Transactional Data Store Applications
        </th>
          <td width="20%" align="right"> <a accesskey="n" href="transapp_logfile.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="transapp_archival"></a>Database and log file archival</h2>
          </div>
        </div>
      </div>
      <p>
        The third component of the administrative infrastructure, archival
        for catastrophic recovery, concerns the recoverability of the
        database in the face of catastrophic failure.  Recovery after
        catastrophic failure is intended to minimize data loss when
        physical hardware has been destroyed — for example, loss of a
        disk that contains databases or log files.  Although the
        application may still experience data loss in this case, it is
        possible to minimize it.
    </p>
      <p>
        First, you may want to periodically create snapshots (that is,
        backups) of your databases to make it possible to recover from
        catastrophic failure.  These snapshots are either a standard
        backup, which creates a consistent picture of the databases as of a
        single instant in time; or an on-line backup (also known as a
        <span class="emphasis"><em>hot</em></span> backup), which creates a consistent
        picture of the databases as of an unspecified instant during the
        period of time when the snapshot was made.  The advantage of a hot
        backup is that applications may continue to read and write the
        databases while the snapshot is being taken.  The disadvantage of a
        hot backup is that more information must be archived, and recovery
        based on a hot backup is to an unspecified time between the start
        of the backup and when the backup is completed.
    </p>
      <p>
        Second, after taking a snapshot, you should periodically archive
        the log files being created in the environment.  It is often
        helpful to think of database archival in terms of full and
        incremental filesystem backups.  A snapshot is a full backup,
        whereas the periodic archival of the current log files is an
        incremental backup.  For example, it might be reasonable to take a
        full snapshot of a database environment weekly or monthly, and
        archive additional log files daily.  Using both the snapshot and
        the log files, a catastrophic crash at any time can be recovered to
        the time of the most recent log archival; a time long after the
        original snapshot.
    </p>
      <p>
        When incremental backups are implemented using this procedure, it
        is important to know that a database copy taken prior to a bulk
        loading event (that is, a transaction started with the
        <a href="../api_reference/C/txnbegin.html#txnbegin_DB_TXN_BULK" class="olink">DB_TXN_BULK</a> flag) can no longer be used as the target of an
        incremental backup.  This is true because bulk loading omits
        logging of some record insertions, so these insertions cannot be
        rolled forward by recovery.  It is recommended that a full backup
        be scheduled following a bulk loading event.
    </p>
      <p>
        To create a standard backup of your database that can be used to
        recover from catastrophic failure, take the following steps:
    </p>
      <div class="orderedlist">
        <ol type="1">
          <li>
            Commit or abort all ongoing transactions.
        </li>
          <li>
            Stop writing your databases until the backup has completed.
            Read-only operations are permitted, but no write operations and
            no filesystem operations may be performed (for example, the
            <a href="../api_reference/C/envremove.html" class="olink">DB_ENV-&gt;remove()</a> and <a href="../api_reference/C/dbopen.html" class="olink">DB-&gt;open()</a> methods may not be called).
        </li>
          <li>
            Force an environment checkpoint (see the <a href="../api_reference/C/db_checkpoint.html" class="olink">db_checkpoint</a> utility for
            more information).
        </li>
          <li>
            <p>
                Run the <a href="../api_reference/C/db_archive.html" class="olink">db_archive</a> utility with option <span class="bold"><strong>-s</strong></span> to identify all the database data
                files, and copy them to a backup device such as CD-ROM, alternate
                disk, or tape.
            </p>
            <p>
                If the database files are stored in a separate directory from the
                other Berkeley DB files, it may be simpler to archive the directory
                itself instead of the individual files (see <a href="../api_reference/C/envset_data_dir.html" class="olink">DB_ENV-&gt;set_data_dir()</a> for
                additional information).  
            </p>
            <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
              <h3 class="title">Note</h3>
              <p>
                    If any of the database files did not have an open <a href="../api_reference/C/db.html" class="olink">DB</a>
                    handle during the lifetime of the current log files,
                    the <a href="../api_reference/C/db_archive.html" class="olink">db_archive</a> utility will not list them in its output. This
                    is another reason it may be simpler to use a separate
                    database file directory and archive the entire
                    directory instead of archiving only the files listed by
                    the <a href="../api_reference/C/db_archive.html" class="olink">db_archive</a> utility.
                </p>
            </div>
          </li>
          <li>
            Run the <a href="../api_reference/C/db_archive.html" class="olink">db_archive</a> utility with option <span class="bold"><strong>-l</strong></span> to identify all the log files,
            and copy the last one (that is, the one with the highest
            number) to a backup device such as CD-ROM, alternate disk, or
            tape.
        </li>
        </ol>
      </div>
      <p>
        To create a <span class="emphasis"><em>hot</em></span> backup of your database that
        can be used to recover from catastrophic failure, take the
        following steps:
    </p>
      <div class="orderedlist">
        <ol type="1">
          <li>
            Set the <a href="../api_reference/C/envset_flags.html#set_flags_DB_HOTBACKUP_IN_PROGRESS" class="olink">DB_HOTBACKUP_IN_PROGRESS</a> flag in the environment.
            This affects the behavior of transactions started with the
            <a href="../api_reference/C/txnbegin.html#txnbegin_DB_TXN_BULK" class="olink">DB_TXN_BULK</a> flag.
        </li>
          <li>
            <p>
                Archive your databases, as described in the previous step
                #4.  You do not have to halt ongoing transactions or force
                a checkpoint.  As this is a hot backup, and the databases
                may be modified during the copy, it is critical that
                database pages be read atomically as described by
                <a class="xref" href="transapp_reclimit.html" title="Berkeley DB recoverability">Berkeley DB recoverability</a>.
            </p>
            <p>
                Note that only UNIX based systems are known to support the
                atomicity of reads.  These systems include: Solaris, Mac OSX,
                HPUX and various BSD based systems.  Linux and Windows
                based systems do not support atomic filesystem reads
                directly.  The XFS file system supports atomic reads
                despite the lack of it in Linux.  On systems that do not
                support atomic file system reads, the <a href="../api_reference/C/db_hotbackup.html" class="olink">db_hotbackup</a> utility 
                should be used or a tool can be constructed 
                using the <a href="../api_reference/C/envbackup.html" class="olink">DB_ENV-&gt;backup()</a> method. Alternatively, you can
                construct a tool using the the <a href="../api_reference/C/db_copy.html" class="olink">db_copy()</a> method. You can
                also perform a hot backup of just a single database in your
                environment using the <a href="../api_reference/C/envdbbackup.html" class="olink">DB_ENV-&gt;dbbackup()</a> method.
            </p>
          </li>
          <li>
            <p>
                Archive <span class="bold"><strong>all</strong></span> of the log files.
                The order of these two operations is required, and the database
                files must be archived <span class="bold"><strong>before</strong></span>
                the log files.  This means that if the database files and log
                files are in the same directory, you cannot simply archive the
                directory; you must make sure that the correct order of
                archival is maintained.
            </p>
            <p>
                To archive your log files, run the <a href="../api_reference/C/db_archive.html" class="olink">db_archive</a> utility using the
                <span class="bold"><strong>-l</strong></span> option to identify all the
                database log files, and copy them to your backup media.  If the
                database log files are stored in a separate directory from the
                other database files, it may be simpler to archive the
                directory itself instead of the individual files (see the
                <a href="../api_reference/C/envset_lg_dir.html" class="olink">DB_ENV-&gt;set_lg_dir()</a> method for more information).
            </p>
          </li>
          <li>
           Reset the <a href="../api_reference/C/envset_flags.html#set_flags_DB_HOTBACKUP_IN_PROGRESS" class="olink">DB_HOTBACKUP_IN_PROGRESS</a> flag.
        </li>
        </ol>
      </div>
      <p>
        To minimize the archival space needed for log files when doing a
        hot backup, run db_archive to identify those log files which are
        not in use.  Log files which are not in use do not need to be
        included when creating a hot backup, and you can discard them or
        move them aside for use with previous backups (whichever is
        appropriate), before beginning the hot backup.
    </p>
      <p>
        After completing one of these two sets of steps, the database
        environment can be recovered from catastrophic failure (see 
        <a class="xref" href="transapp_recovery.html" title="Recovery procedures">Recovery procedures</a> 
        for more information).
    </p>
      <p>
        To update either a hot or cold backup so that recovery from
        catastrophic failure is possible to a new point in time, repeat
        step #2 under the hot backup instructions and archive 
        <span class="bold"><strong>all</strong></span> of the log files in the
        database environment.  Each time both the database and log files
        are copied to backup media, you may discard all previous database
        snapshots and saved log files.  Archiving additional log files does
        not allow you to discard either previous database snapshots or log
        files.  Generally, updating a backup must be integrated with the
        application's log file removal procedures.
    </p>
      <p>
        The time to restore from catastrophic failure is a function of the
        number of log records that have been written since the snapshot was
        originally created.  Perhaps more importantly, the more separate
        pieces of backup media you use, the more likely it is that you will
        have a problem reading from one of them.  For these reasons, it is
        often best to make snapshots on a regular basis.
    </p>
      <p>
        <span class="bold"><strong>Obviously, the reliability of your archive
            media will affect the safety of your data.  For archival
            safety, ensure that you have multiple copies of your database
            backups, verify that your archival media is error-free and
            readable, and that copies of your backups are stored
            offsite!</strong></span>
    </p>
      <p>
        The functionality provided by the <a href="../api_reference/C/db_archive.html" class="olink">db_archive</a> utility is also available
        directly from the Berkeley DB library.  The following code fragment
        prints out a list of log and database files that need to be
        archived:
    </p>
      <pre class="programlisting">void
log_archlist(DB_ENV *dbenv)
{
    int ret;
    char **begin, **list;

/* Get the list of database files. */
    if ((ret = dbenv-&gt;log_archive(dbenv,
        &amp;list, DB_ARCH_ABS | DB_ARCH_DATA)) != 0) {
        dbenv-&gt;err(dbenv, ret, "DB_ENV-&gt;log_archive: DB_ARCH_DATA");
        exit (1);
    }
    if (list != NULL) {
        for (begin = list; *list != NULL; ++list)
            printf("database file: %s\n", *list);
        free (begin);
    }

/* Get the list of log files. */
    if ((ret = dbenv-&gt;log_archive(dbenv,
        &amp;list, DB_ARCH_ABS | DB_ARCH_LOG)) != 0) {
        dbenv-&gt;err(dbenv, ret, "DB_ENV-&gt;log_archive: DB_ARCH_LOG");
        exit (1);
    }
    if (list != NULL) {
        for (begin = list; *list != NULL; ++list)
            printf("log file: %s\n", *list);
        free (begin);
    }
}</pre>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="transapp_checkpoint.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="transapp.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="transapp_logfile.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Checkpoints </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Log file removal</td>
        </tr>
      </table>
    </div>
  </body>
</html>

003 File Manager

Editing: transapp_archival.html

Upload File

Create Folder