<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.38 2002/09/25 21:16:10 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.39 2002/10/16 22:06:33 petere Exp $
-->
<book id="admin">
&monitoring;
&diskusage;
&wal;
- &recovery;
®ress;
&release;
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.5 2002/09/21 18:32:52 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.6 2002/10/16 22:06:33 petere Exp $
-->
<chapter id="diskusage">
<title>Monitoring Disk Usage</title>
+ <para>
+ This chapter discusses how to monitor the disk usage of a PostgreSQL
+ database system. In the current release, the database administrator
+ does not have much control over the on-disk storage layout, so this
+ chapter is mostly informative and can give you some ideas how to
+ manage the disk usage with operating system tools.
+ </para>
+
<sect1 id="disk-usage">
- <title>Monitoring Disk Usage</Title>
+ <title>Determining Disk Usage</Title>
<indexterm zone="disk-usage">
<primary>disk usage</primary>
shows disk usage for each database.
</para>
</sect1>
+
+ <sect1 id="disk-full">
+ <title>Disk Full Failure</title>
+
+ <para>
+ The most important disk monitoring task of a database administrator
+ is to make sure the disk doesn't grow full. A filled data disk may
+ result in subsequent corruption of database indexes, but not of the
+ fundamental data tables. If the WAL files are on the same disk (as
+ is the case for a default configuration) then a filled disk during
+ database initialization may result in corrupted or incomplete WAL
+ files. This failure condition is detected and the database server
+ will refuse to start up.
+ </para>
+
+ <para>
+ If you cannot free up additional space on the disk by deleting
+ other things you can move some of the database files to other file
+ systems and create a symlink from the original location. But
+ note that <application>pg_dump</> cannot save the location layout
+ information of such a setup; a restore would put everything back in
+ one place. To avoid running out of disk space, you can place the
+ WAL files or individual databases in other locations while creating
+ them. See the <application>initdb</> documentation and <xref
+ linkend="manage-ag-alternate-locs"> for more information.
+ </para>
+
+ <tip>
+ <para>
+ Some file systems perform badly when they are almost full, so do
+ not wait until the disk is full to take action.
+ </para>
+ </tip>
+ </sect1>
</chapter>
<!-- Keep this comment at the end of the file
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.23 2002/09/25 21:16:10 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.24 2002/10/16 22:06:33 petere Exp $ -->
<!entity history SYSTEM "history.sgml">
<!entity info SYSTEM "info.sgml">
<!entity maintenance SYSTEM "maintenance.sgml">
<!entity manage-ag SYSTEM "manage-ag.sgml">
<!entity monitoring SYSTEM "monitoring.sgml">
-<!entity recovery SYSTEM "recovery.sgml">
<!entity regress SYSTEM "regress.sgml">
<!entity release SYSTEM "release.sgml">
<!entity runtime SYSTEM "runtime.sgml">
+++ /dev/null
-<chapter Id="failure">
- <title>Database Failures</title>
-
- <para>
- Database failures (or the possibility of such) must be assumed to be
- lurking, ready to strike at some time in the future. A prudent
- database administrator will plan for the inevitability of failures
- of all possible kinds, and will have appropriate plans and
- procedures in place <emphasis>before</emphasis> the failure occurs.
- </para>
-
- <para>
- Database recovery is necessary in the event of hardware or software
- failure. There are several categories of failures; some of these
- require relatively minor adjustments to the database, while others
- may depend on the existence of previously prepared database dumps
- and other recovery data sets. It should be emphasized that if your
- data is important and/or difficult to regenerate, then you should
- have considered and prepared for various failure scenarios.
- </para>
-
- <sect1 id="failure-disk-full">
- <title>Disk Filled</title>
-
- <para>
- A filled data disk may result in subsequent corruption of database
- indexes, but not of the fundamental data tables. If the WAL files
- are on the same disk (as is the case for a default configuration)
- then a filled disk during database initialization may result in
- corrupted or incomplete WAL files. This failure condition is
- detected and the database will refuse to start up. You must free
- up additional space on the disk (or move the WAL area to another
- disk; see <xref linkend="wal-configuration">) and then restart the
- <application>postmaster</application> to recover from this condition.
- </para>
- </sect1>
-
- <sect1 id="failure-disk-failed">
- <title>Disk Failed</title>
-
- <para>
- Failure of any disk (or of a logical storage device such as a RAID
- subsystem) involved with an active database will require
- that the database be recovered from a previously prepared database
- dump. This dump must be prepared using
- <application>pg_dumpall</application>, and updates to the database
- occurring after the database installation was dumped will be lost.
- </para>
- </sect1>
-
-<!--
- <sect1>
- <title>File Corrupted</title>
-
- <para>
- </para>
- </sect1>
-
- <sect1>
- <title>Table Corrupted</title>
-
- <para>
- </para>
- </sect1>
-
- <sect1>
- <title></title>
-
- <para>
- </para>
- </sect1>
-
- <sect1>
- <title></title>
-
- <para>
- </para>
- </sect1>
-
- <sect1>
- <title></title>
-
- <para>
- </para>
- </sect1>
--->
-
-</chapter>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode:sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:1
-sgml-indent-data:t
-sgml-parent-document: ("postgres.sgml" "set" "book" "chapter")
-sgml-default-dtd-file:"./reference.ced"
-sgml-exposed-tags:nil
-sgml-local-ecat-files:nil
-End:
--->
projects / postgresql / commitdiff