|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.57 2006/08/01 00:09:06 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.58 2006/08/01 19:17:17 alvherre Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="maintenance">
|
4 | 4 | <title>Routine Database Maintenance Tasks</title>
|
|
8 | 8 | </indexterm>
|
9 | 9 |
|
10 | 10 | <indexterm zone="maintenance">
|
11 |
| - <primary>Routine maintenance</primary> |
| 11 | + <primary>routine maintenance</primary> |
12 | 12 | </indexterm>
|
13 | 13 |
|
14 | 14 | <para>
|
15 |
| - PostgreSQL, like any database software, requires that certain tasks |
16 |
| - be performed regularly to achieve optimum performance. The tasks |
| 15 | + <productname>PostgreSQL</>, like any database software, requires that certain tasks |
| 16 | + be performed regularly to achieve optimum performance. The tasks |
17 | 17 | discussed here are <emphasis>required</emphasis>, but they
|
18 |
| - are repetitive in nature and can easily be automated using standard |
19 |
| - Unix tools such as <application>cron</application> scripts. |
| 18 | + are repetitive in nature and can easily be automated using standard |
| 19 | + Unix tools such as <application>cron</application> scripts or |
| 20 | + Windows' <application>Task Scheduler</>. But it is the database |
| 21 | + administrator's responsibility to set up appropriate scripts, and to |
| 22 | + check that they execute successfully. |
20 | 23 | </para>
|
21 |
| - |
| 24 | + |
22 | 25 | <para>
|
23 |
| - <productname>PostgreSQL</productname> is low-maintenance compared |
24 |
| - to other database management systems. It is also fairly easy, provided |
25 |
| - you read the documentation. |
| 26 | + One obvious maintenance task is creation of backup copies of the data on a |
| 27 | + regular schedule. Without a recent backup, you have no chance of recovery |
| 28 | + after a catastrophe (disk failure, fire, mistakenly dropping a critical |
| 29 | + table, etc.). The backup and recovery mechanisms available in |
| 30 | + <productname>PostgreSQL</productname> are discussed at length in |
| 31 | + <xref linkend="backup">. |
26 | 32 | </para>
|
27 | 33 |
|
28 | 34 | <para>
|
29 |
| - There are three tasks that <emphasis>must</emphasis> be performed on |
30 |
| - a periodic basis. The first is backups. If you do not have a current backup |
31 |
| - and your system experiences a catastrophic failure, you will lose your data. |
32 |
| - You can read further about backups procedures in <xref linkend="backup">. |
33 |
| - The second is vacuum which is discussed in <xref linkend="routine-vacuuming">. |
34 |
| - The third is to update the planner statistics using the analyze command as |
35 |
| - discussed in <xref linkend="vacuum-for-statistics">. |
| 35 | + The other main category of maintenance task is periodic <quote>vacuuming</> |
| 36 | + of the database. This activity is discussed in |
| 37 | + <xref linkend="routine-vacuuming">. Closely related to this is to update |
| 38 | + the statistics that will be used by the query planner, as discussed in |
| 39 | + <xref linkend="vacuum-for-statistics">. |
36 | 40 | </para>
|
37 | 41 |
|
38 | 42 | <para>
|
39 |
| - Another task that may need periodic attention is log file management. |
| 43 | + Another task that might need periodic attention is log file management. |
40 | 44 | This is discussed in <xref linkend="logfile-maintenance">.
|
41 | 45 | </para>
|
42 | 46 |
|
43 |
| - |
| 47 | + <para> |
| 48 | + <productname>PostgreSQL</productname> is low-maintenance compared |
| 49 | + to some other database management systems. Nonetheless, |
| 50 | + appropriate attention to these tasks will go far towards ensuring a |
| 51 | + pleasant and productive experience with the system. |
| 52 | + </para> |
44 | 53 |
|
45 | 54 | <sect1 id="routine-vacuuming">
|
46 | 55 | <title>Routine Vacuuming</title>
|
|
80 | 89 | </para>
|
81 | 90 |
|
82 | 91 | <para>
|
83 |
| - The standard form of <command>VACUUM</> does not intefere with production |
84 |
| - database operations. Items such as SELECTS, INSERTS, UPDATES and DELETES |
| 92 | + The standard form of <command>VACUUM</> can run in parallel with production |
| 93 | + database operations. Commands such as SELECTs, INSERTs, UPDATEs and DELETEs |
85 | 94 | will continue to function as normal, though you will not be able to modify the
|
86 |
| - definition (Such as ALTER TABLE ADD COLUMN) of a table while it is being vacuumed. |
87 |
| - The release of <productname>PostgreSQL</productname> 8.0, introduced new |
88 |
| - configuration parameters to further reduce the potentially negative |
| 95 | + definition of a table with commands such as ALTER TABLE ADD COLUMN |
| 96 | + while it is being vacuumed. |
| 97 | + Beginning in <productname>PostgreSQL</productname> 8.0, there are |
| 98 | + configuration parameters that can be adjusted to further reduce the |
89 | 99 | performance impact of background vacuuming. See
|
90 | 100 | <xref linkend="runtime-config-resource-vacuum-cost">.
|
91 | 101 | </para>
|
|
187 | 197 |
|
188 | 198 | <para>
|
189 | 199 | If you have a table whose entire contents are deleted on a periodic
|
190 |
| - basis, consider doing it with the <command>TRUNCATE</command> rather |
191 |
| - than using the <command>DELETE</command> followed by |
| 200 | + basis, consider doing it with <command>TRUNCATE</command> rather |
| 201 | + than using <command>DELETE</command> followed by |
192 | 202 | <command>VACUUM</command>. <command>TRUNCATE</command> removes the
|
193 | 203 | entire content of the table immediately, without requiring a
|
194 | 204 | subsequent <command>VACUUM</command> or <command>VACUUM
|
|
0 commit comments