Index: doc/src/sgml/maintenance.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v
retrieving revision 1.56
diff -c -r1.56 maintenance.sgml
*** doc/src/sgml/maintenance.sgml 18 Jun 2006 15:38:35 -0000 1.56
--- doc/src/sgml/maintenance.sgml 15 Jul 2006 02:21:25 -0000
***************
*** 7,48 ****
maintenance
! There are a few routine maintenance chores that must be performed on
! a regular basis to keep a PostgreSQL
! server running smoothly. The tasks discussed here are repetitive
! in nature and can easily be automated using standard Unix tools such
! as cron scripts. But it is the database
! administrator's responsibility to set up appropriate scripts, and to
! check that they execute successfully.
!
! One obvious maintenance task is creation of backup copies of the data on a
! regular schedule. Without a recent backup, you have no chance of recovery
! after a catastrophe (disk failure, fire, mistakenly dropping a critical
! table, etc.). The backup and recovery mechanisms available in
! PostgreSQL are discussed at length in
! .
! The other main category of maintenance task is periodic vacuuming>
! of the database. This activity is discussed in
! .
! Something else that might need periodic attention is log file management.
This is discussed in .
!
! PostgreSQL is low-maintenance compared
! to some other database management systems. Nonetheless,
! appropriate attention to these tasks will go far towards ensuring a
! pleasant and productive experience with the system.
!
Routine Vacuuming
--- 7,46 ----
maintenance
+
+ Routine maintenance
+
+
! PostgreSQL, like any database software, requires that certain tasks
! be performed regularly to achieve optimum performance. The tasks
! discussed here are required, but they
! are repetitive in nature and can easily be automated using standard
! Unix tools such as cron scripts.
!
! PostgreSQL is low-maintenance compared
! to other database management systems. It is also fairly easy, provided
! you read the documentation.
! There are three tasks that must be performed on
! a periodic basis. The first is backups. If you do not have a current backup
! and your system experiences a catastrophic failure, you will lose your data.
! You can read further about backups procedures in .
! The second is vacuum which is discussed in .
! The third is to update the planner statistics using the analyze command as
! discussed in .
! Another task that may need periodic attention is log file management.
This is discussed in .
!
Routine Vacuuming
***************
*** 53,63 ****
PostgreSQL's VACUUM> command
! must be run on a regular basis for several reasons:
! To recover disk space occupied by updated or deleted
rows.
--- 51,61 ----
PostgreSQL's VACUUM> command
! must be run on a regular basis for several reasons:
! To recover or reuse disk space occupied by updated or deleted
rows.
***************
*** 82,92 ****
! The standard form of VACUUM> can run in parallel with
! normal database operations (SELECTs, INSERTs, UPDATEs, DELETEs, but not
! changes to table definitions).
! Beginning in PostgreSQL 8.0, there are
! configuration parameters that can be adjusted to further reduce the
performance impact of background vacuuming. See
.
--- 80,91 ----
! The standard form of VACUUM> does not intefere with production
! database operations. Items such as SELECTS, INSERTS, UPDATES and DELETES
! will continue to function as normal, though you will not be able to modify the
! definition (Such as ALTER TABLE ADD COLUMN) of a table while it is being vacuumed.
! The release of PostgreSQL 8.0, introduced new
! configuration parameters to further reduce the potentially negative
performance impact of background vacuuming. See
.
***************
*** 187,195 ****
! If you have a table whose contents are deleted on a periodic
! basis, consider doing it with TRUNCATE rather
! than using DELETE followed by
VACUUM. TRUNCATE removes the
entire content of the table immediately, without requiring a
subsequent VACUUM or VACUUM
--- 186,194 ----
! If you have a table whose entire contents are deleted on a periodic
! basis, consider doing it with the TRUNCATE rather
! than using the DELETE followed by
VACUUM. TRUNCATE removes the
entire content of the table immediately, without requiring a
subsequent VACUUM or VACUUM