無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

pg_dump

名前

pg_dump --  PostgreSQL データベースをスクリプトファイルまたは他のアーカイブファイルへ抽出する

概要

pg_dump [ connection-option ...] [ option ...] [ dbname ]

説明

pg_dump PostgreSQL データベースをバックアップするユーティリティです。 データベースを使用中であっても一貫性のあるバックアップを作成することができます。 pg_dump は他のユーザによるデータベースへのアクセス(読み書き)をブロックしません。

ダンプはスクリプト形式、または、アーカイブファイル形式で出力することができます。 スクリプトダンプは、保存した時点の状態のデータベースを再構成するために必要なSQLコマンドが書き込まれた平文ファイルです。 このスクリプトを使ってリストアを行うには psql を使用します。 スクリプトファイルを使えば、ダンプを行ったのとは別のマシンや別のアーキテクチャ上でも、データベースを再構築することができます。 また、多少編集すれば他のSQLデータベース製品上でもデータベースの再構築が可能です。

もう1つの形式であるアーカイブファイル形式を使ってデータベースを再構築するには、 pg_restore を使用しなければなりません。 このファイルを使用すると、 pg_restore がリストア対象を選択したり、リストアするアイテムを並び替えたりできます。 アーカイブファイルもまた、アーキテクチャを越えて移植できるように設計されています。

いずれかのアーカイブファイル形式を pg_restore と組み合わせて使用する場合は、 pg_dump の柔軟なアーカイブ/転送機構が利用できます。 具体的には、 pg_dump を使用してデータベース全体をバックアップし、 pg_restore を使用して、アーカイブの内容を検査したり、データベースの一部を選択してリストアしたりすることができます。 最も柔軟な出力ファイル形式は "custom" 形式( -Fc )と "directory" 形式( -Fd )です。 これらはすべての保存された項目の選択や並び換えを行うことができ、部分リストアをサポートし、デフォルトで圧縮されます。 "directory" 形式は、並行ダンプをサポートする唯一の形式です。

pg_dump の実行中は、標準エラーに出力される警告(特に後述の制限に関する警告)が出力されていないか確認してください。

オプション

以下のコマンドラインオプションは出力形式とその内容を制御します。

dbname

ダンプするデータベースの名前を指定します。 指定されていない場合は PGDATABASE 環境変数が使われます。 この変数も設定されていない場合は、接続のために指定されたユーザ名が使用されます。

-a
--data-only

データのみをダンプし、スキーマ(データ定義)はダンプしません。 テーブルデータ、ラージオブジェクト、シーケンス値がダンプされます。

このオプションは --section=data を指定することと似ていますが、歴史的な理由で同一ではありません。

-b
--blobs

ラージオブジェクトをダンプに含めます。 これはデフォルトの動作ですが、 --schema --table --schema-only が指定された場合は例外です。 したがって、 -b オプションは選択的なダンプにラージオブジェクトを追加する場合にのみ有用です。

-c
--clean

データベースオブジェクトを作成するコマンドの前に、データベースオブジェクトを整理(削除)するコマンドを書き出します。 (対象のデータベースの中にオブジェクトがまったくない場合でも、リストア時に害がないエラーがいくつか発生するかもしれません。)

このオプションは平文形式の場合にのみ有効です。 アーカイブ形式では、 pg_restore を呼び出す時にこのオプションを指定することができます。

-C
--create

初めにデータベース自体を作成するコマンドを出力し、その後、作成したデータベースに接続するコマンドを出力します (このようなスクリプトを使用すると、スクリプトを実行する前に対象のインストレーションの中のどのデータベースに接続すればよいかという問題を考える必要がなくなります)。 --clean も同時に指定されている場合、このスクリプトは接続する前に対象データベースを削除し再作成します。

このオプションは平文形式の場合にのみ有効です。 アーカイブ形式では、 pg_restore を呼び出す時にこのオプションを指定することができます。

-E encoding
--encoding= encoding

指定した文字セット符号化方式でダンプを作成します。 デフォルトではダンプはデータベースの符号化方式で作成されます。 ( PGCLIENTENCODING 環境変数を好みのダンプ時の符号化方式に設定することで、同じ結果を得ることができます。)

-f file
--file= file

出力を指定のファイルに送ります。 ファイルを基にする出力形式ではこのパラメータは省くことができます。 省略時は標準出力が使用されます。 しかしディレクトリ出力形式の場合は、省略することはできず、ファイルではなく対象ディレクトリを指定します。 この場合、ディレクトリは pg_dump が生成しますので、事前に存在してはなりません。

-F format
--format= format

出力形式を選択します。 format には以下のいずれかを取ることができます。

p
plain

平文の SQL スクリプトファイルを出力します(デフォルト)。

c
custom

pg_restore への入力に適したカスタム形式アーカイブを出力します。 ディレクトリ出力形式と一緒に使用する場合、リストア時に手作業で保管された項目の選択、再順序付けできますので、これはもっとも柔軟な出力形式です。 また、この形式はデフォルトで圧縮されます。

d
directory

pg_restore への入力に適したディレクトリ形式のアーカイブを出力します。 これは、ダンプされる各テーブルおよびblobごとに1つのファイル、さらに、 pg_restore から読み取り可能な、機械的に読み取り易い書式でダンプしたオブジェクトを記述する目次ファイルと呼ばれるファイルを持つディレクトリを作成します。 ディレクトリ形式アーカイブは標準Unixツールで操作することができます。 例えば、未圧縮アーカイブ内のファイルを gzip ツールを使用して圧縮することができます。 この形式はデフォルトで圧縮されます。 また並行ダンプをサポートします。

t
tar

pg_restore への入力に適した tar 形式のアーカイブを出力します。 このtar形式はディレクトリ形式と互換性があります。 tar形式アーカイブを展開すると、有効なディレクトリ形式のアーカイブを生成します。 しかしtar形式は圧縮をサポートせず、個々のテーブルのサイズに関して8ギガバイトという上限があります。 またリストア時にテーブルデータ項目の相対的な順序を変更することはできません。

-i
--ignore-version

廃止されたオプションであり、現在は無視されます。

-j njobs
--jobs= njobs

njobs 個のテーブルを同時にダンプすることによって、並行してダンプを実行します。 このオプションはダンプにかかる時間を減らしますが、データベースサーバへの負荷を増やします。 複数のプロセスが同時にそのデータを書き出すことができる唯一の出力形式ですので、このオプションはdirectory出力形式でのみ使用することができます。

pg_dump njobs +1個のデータベース接続を開きます。 このため、すべての接続を収容できる程度に max_connections が高いことを確認してください。

並行ダンプを実行している時にデータベースオブジェクトに対して排他ロックを要求することは、ダンプを失敗させる可能性があります。 理由は、作業用プロセスが後でダンプしようとするオブジェクトに対する共有ロックを、それらを削除するユーザが存在せずにダンプ中になくなることがないことを確実するために、 pg_dump マスタプロセスが要求することです。 その後他のクライアントがテーブルに対する排他ロックを要求すると、 そのロックは許可されませんが、マスタプロセスが共有ロックを解放することを待機するキューに保管されます。 その結果、テーブルへのその他のアクセスは許可されず、排他ロック要求の後のキューに保管されます。 これには、そのテーブルをダンプしようとする作業用プロセスも含まれます。 何らかの注意をしないと、古典的なデッドロック状態になります。 この競合を検知するために pg_dump の作業用プロセスは NOWAIT オプションを使用する別の共有ロックを要求します。 作業用プロセスによる共有ロックが許可されない場合、だれかがその時に排他ロックを要求していることになり、ダンプを継続することができません。 pg_dump には、ダンプを中断するしか選択肢がありません。

一貫したバックアップのためには、データベースサーバは、 PostgreSQL 9.2で導入された機能である、同期されたスナップショットをサポートする必要があります。 この機能を用いて、データベースクライアントは異なる接続を使用していたとしても、確実に同じデータセットを参照することができます。 pg_dump -j は複数のデータベース接続を使用します。 マスタプロセスで1つ、作業用ジョブそれぞれでも1つ、データベースと接続します。 同期されたスナップショット機能がないと、異なる作業用ジョブがそれぞれの接続で同じデータを参照していることが保証されず、一貫性がないバックアップになってしまいます。

9.2より前のサーバで並行ダンプを実行させたいのであれば、データベースの内容が、マスタがデータベースに接続してから最後の作業用ジョブがデータベースに接続するまでの間に変更されないことを確実にしなければなりません。 このためのもっとも簡単な方法は、バックアップを始める前にデータを変更するプロセス(DDLおよびDML)がデータベースにアクセスすることを止めさせることです。 また、9.2より前の PostgreSQL に対して pg_dump -j を実行する場合は --no-synchronized-snapshots パラメータを指定する必要もあります。

-n schema
--schema= schema

schema に一致するスキーマのみをダンプします。 これはスキーマ自体とそこに含まれるオブジェクトすべてを選択します。 このオプションが指定されなければ、対象データベース内にあるシステム以外のスキーマ全てがダンプされます。 複数の -n オプションを記述することで、複数のスキーマを選択することができます。 また、 schema パラメータは psql \d コマンドと同じ規則に従うパターン( パターン 参照)として解釈されます。 ですので、ワイルドカード文字をパターン内に記述することで、複数のスキーマを選択することもできます。 ワイルドカードを使用する時は、シェルによりそのワイルドカードを展開させないように、パターンを引用符で括ってください。 を参照してください。

注意: -n が指定されると、 pg_dump は選択したスキーマ内のオブジェクトが依存する可能性がある、その他のデータベースオブジェクトのダンプを行いません。 したがって、スキーマ指定のダンプ結果を初期状態のデータベースに正常にリストアできるかどうかの保証はありません。

注意: -n が指定されると、blobなどの非スキーマオブジェクトはダンプされません。 --blobs オプションをつけてダンプを行うことでblobも追加されます。

-N schema
--exclude-schema= schema

schema パターンに一致するスキーマをダンプしません。 このパターンは -n と同様の規則に従って解釈されます。 -N を複数指定して、複数のパターンのいずれかに一致するスキーマを除外することができます。

-n -N の両方が指定された場合、少なくとも1つの -n に一致し -N オプションに一致しないスキーマだけがダンプされます。 -n なしで -N が指定された場合、 -N に一致するスキーマが通常のダンプから除外されます。

-o
--oids

各テーブルのオブジェクト識別子( OID )をデータの一部としてダンプします。 アプリケーションで OID 列を(外部キー制約など)何らかの形で使用している場合は、このオプションを使用してください。 その他の場合は、このオプションは使用しないでください。

-O
--no-owner

オブジェクトの所有権を元のデータベースに一致させるためのコマンドを出力しません。 デフォルトでは、 pg_dump は、 ALTER OWNER 文または SET SESSION AUTHORIZATION 文を発行して、作成したデータベースオブジェクトの所有権を設定します。 スーパーユーザ(もしくは、そのスクリプト内の全てのオブジェクトを所有するユーザ)以外のユーザがスクリプトを実行した場合、これらの文は失敗します。 任意のユーザがリストアできるスクリプトを作成するには、 -O を指定してください。 ただし、この場合は、全てのオブジェクトの所有者がリストアしたユーザとなってしまいます。

このオプションは平文形式の場合にのみ有効です。 アーカイブ形式では、 pg_restore を呼び出す時にこのオプションを指定することができます。

-R
--no-reconnect

このオプションは廃止されましたが、後方互換性を保持するため受け入れられます。

-s
--schema-only

データ定義(スキーマ)のみをダンプし、データはダンプしません。

このオプションは --data-only の逆です。 これは --section=pre-data --section=post-data を指定することと似ていますが、歴史的な理由のため同一ではありません。

(これと --schema オプションと混乱しないでください。 "schema" という単語を異なる意味で使用しています。)

データベース内の一部のみのテーブルのテーブルデータを除外するためには --exclude-table-data を参照してください。

-S username
--superuser= username

トリガを無効にする場合に使用する、スーパーユーザのユーザ名を指定します。 これは --disable-triggers を使う場合にのみ使用されます。 (通常は このオプションを使うよりも、出力されたスクリプトをスーパーユーザ権限で実行する方が良いでしょう。)

-t table
--table= table

table に一致するテーブル(またはビュー、シーケンス、外部テーブル)のみをダンプします。 複数の -t オプションを記述することで複数のテーブルを選択することができます。 また、 table パラメータは psql \d コマンドで使用される規則( パターン 参照)と同じ規則に従うパターンとして解釈されます。 ですので、ワイルドカード文字をパターン内に記述することで、複数のテーブルを選択することもできます。 ワイルドカードを使用する時は、シェルによりそのワイルドカードを展開させないように、パターンを引用符で括ってください。 を参照してください。

-t が使用されると、 -n および -N オプションの効果はなくなります。 -t で選択したテーブルが、これらのオプションとは関係なくダンプされ、また、非テーブルオブジェクトはダンプされないためです。

注意: -t が指定されると、 pg_dump は選択したテーブル内のオブジェクトが依存する可能性がある他のデータベースオブジェクトのダンプを行いません。 したがって、テーブル指定のダンプ結果を初期化されたデータベースに正常にリストアできるかどうかの保証はありません。

注意: -t オプションの動作は8.2より前のバージョンの PostgreSQL と完全な互換性はありません。 以前は、 -t tab と記述することで tab という名前のテーブルをすべてダンプしていました。 しかし現在は、デフォルトの検索パスで可視のものだけがダンプされます。 過去の動作を行うためには、 -t '*.tab' と記述してください。 また、特定のスキーマ内のテーブルを選択するためには、以前は -n sch -t tab と記述していましたが、 -t sch.tab などと記述しなければなりません。

-T table
--exclude-table= table

tables パターンに一致するテーブルをまったくダンプしません。 このパターンは -t と同じ規則に従って解釈されます。 -T を複数指定することで、複数のパターンに一致するテーブルを除外させることができます。

-t -T の両方が指定された場合、少なくとも1つの -t オプションに一致し、 -T オプションに一致しないテーブルのみがダンプされます。 -t なしで -T が指定された場合、通常のダンプから -T に一致するテーブルが除外されます。

-v
--verbose

冗長モードを指定します。 これを指定すると、 pg_dump は、詳細なオブジェクトコメント、開始時刻、終了時刻をダンプファイルに、進行状況メッセージを標準エラーに出力します。

-V
--version

pg_dump のバージョンを表示し、終了します。

-x
--no-privileges
--no-acl

アクセス権限(grant/revokeコマンド)のダンプを抑制します。

-Z 0..9
--compress= 0..9

使用する圧縮レベルを指定します。 ゼロは圧縮無しを意味します。 カスタムアーカイブ形式では、これは個々のテーブルデータセグメントの圧縮を指定するもので、デフォルトでは中間レベルで圧縮されます。 平文出力では、非ゼロの圧縮レベルの指定によりあたかも gzip に渡されたかのように出力ファイル全体が圧縮されます。 しかしデフォルトは圧縮無しです。 tarアーカイブ形式では現在圧縮を全くサポートしていません。

--binary-upgrade

このオプションは現位置でのアップグレード用のユーティリティにより使用されるものです。 他の目的での使用は推奨されませんし、サポートもされません。 このオプションの動作は、将来注意することなく変更される可能性があります。

--column-inserts
--attribute-inserts

明示的に列名を付けた INSERT コマンド( INSERT INTO table ( column , ...)VALUES... )としてデータをダンプします。 これによりリストアは非常に遅くなります。 主に PostgreSQL 以外のデータベースへロード可能なダンプを作成する時に有用です。 しかし、このオプションは各行に対して別々のコマンドを生成しますので、一行を再ロードする時にエラーになったとしても、テーブルの内容まるごと失われることなく、一行のみが失われるだけです。

--disable-dollar-quoting

このオプションは、関数本体用のドル引用符の使用を無効にし、強制的に標準SQLの文字列構文を使用した引用符付けを行います。

--disable-triggers

このオプションは、データのみのダンプを作成する場合にしか適用されません。 データの再ロード中に、 pg_dump に対し、対象テーブル上のトリガを一時的に無効にするコマンドを出力するよう指示します。 このオプションは、データの再ロード中には呼び出したくない参照整合性検査やその他のトリガがテーブル上にある場合に使用します。

現在のところ、 --disable-triggers を指定してコマンドを実行するのは、スーパーユーザでなければなりません。 そのため、ユーザは -S でスーパーユーザを指定するか、あるいは、十分に注意してスーパーユーザ権限でスクリプトを開始する必要があります(後者の方がより望ましい方法です)。

このオプションは平文形式の場合にのみ有効です。 他の形式では、 pg_restore を呼び出す時にこのオプションを指定することができます。

--exclude-table-data= table

table に一致するすべてのテーブルのデータをダンプしません。 パターンは -t 用の規則と同じ規則にしたがって解釈されます。 複数のパターンのいずれかに一致するテーブルを除外することができるように、 --exclude-table-data を複数回与えることができます。 このオプションは、特定のテーブルに関してデータを格納する必要がないがテーブル定義が必要である場合に有用です。

データベース内のすべてのテーブルに関してデータを除外するためには、 --schema-only を参照してください。

--inserts

データを( COPY ではなく) INSERT コマンドの形式でダンプします。 これを行うとリストアに非常に時間がかかります。 主に PostgreSQL 以外のデータベースへロード可能なダンプを作成する時に有用です。 しかし、このオプションは各行に対して別々のコマンドを生成しますので、一行を再ロードする時にエラーになったとしても、テーブルの内容まるごと失われることなく、一行のみが失われるだけです。 列の順序を変更した場合はリストアが失敗する可能性があることに注意してください。 --column-inserts の方がより処理が遅くなりますが、列の順序変更に対して安全です。

--lock-wait-timeout= timeout

ダンプの開始時に共有テーブルのロックを永遠に待ちません。 代わりに指定した timeout 内にテーブルロックを獲得できなければ失敗します。 タイムアウトには SET statement_timeout で受け付けられるすべての書式を指定できます。 (使用可能な値はダンプの元となるサーバのバージョンに依存して異なります。 しかし、7.3以降ではミリ秒単位の整数値を受け付けられます。 7.3より前のサーバからダンプする場合、このオプションは無視されます。)

--no-security-labels

セキュリティラベルをダンプしません。

--no-synchronized-snapshots

このオプションにより、9.2より前のサーバに対して pg_dump -j を実行することができます。 詳細については -j パラメータの説明を参照してください。

--no-tablespaces

テーブル空間を選択するコマンドを出力しません。 このオプションを使用すると、すべてのオブジェクトはリストア時のデフォルトのテーブル空間の中に作成されます。

このオプションは平文書式でのみ有意です。 アーカイブ書式では、 pg_restore を呼び出す時にこのオプションを指定することができます。

--no-unlogged-table-data

ログを取らないテーブルの内容をダンプしません。 このオプションはテーブル定義(スキーマ)をダンプするかどうかには影響しません。 そのテーブルデータのダンプを抑制するだけです。 スタンバイサーバからダンプを行う場合、ログを取らないテーブル内のデータは常に除外されます。

--quote-all-identifiers

強制的にすべての識別子に引用符を付与します。 追加のキーワードが導入されている可能性がある将来のバージョンへの移行用にデータベースをダンプする場合に有用かもしれません。

--section= sectionname

指名した部分のみをダンプします。 部分名は pre-data data post-data のいずれかを取ることができます。 複数の部分を選択するために、このオプションは複数回指定することができます。 デフォルトではすべての部分をダンプします。

data部分には、実際のテーブルデータとラージオブジェクトの中身、シーケンス値が含まれます。 Post-data項目は、インデックス定義、トリガ定義、ルール定義、有効化された検査制約以外の制約定義が含まれます。 Pre-data項目は、他のすべてのデータ定義項目が含まれます。

--serializable-deferrable

使用されるスナップショットがその後のデータベース状態と一貫性を持つことを保証するために、ダンプ時に serializable トランザクションを使用します。 ダンプが失敗したり、 serialization_failure により他のトランザクションがロールバックしたりする危険がないように、トランザクションストリーム内で異常が発生することがない時点まで待つことでこれを行います。 トランザクション隔離および同時実行性の制御については 第13章 を参照してください。

このオプションは障害対策のリカバリのみを目的とするダンプでは利点はありません。 元のデータベースを継続して更新しながら、レポート処理や他の読み取りのみの負荷分散のためにデータベースのコピーをロードするために使用されるダンプとして有用になります。 こうしないと、ダンプには 何らかのトランザクションの直列実行が結局コミットした状態と一貫性がない状態が反映される可能性があります。 例えば、バッチ処理技術が使用される場合、 バッチは、バッチ内で存在するすべての項目を持たないダンプ内でクローズしたものと表示される可能性があります。

pg_dumpを始めた時に読み書きを行うトランザクションが存在しない場合、このオプションには違いはありません。 読み書きを行うトランザクションが活動している場合、ダンプの起動が確定できない期間、遅延される可能性があります。 動き出してからの性能は、このスイッチがある場合とない場合とで違いはありません。

--use-set-session-authorization

オブジェクトの所有権を決定するために、 ALTER OWNER コマンドの代わりに標準SQLの SET SESSION AUTHORIZATION コマンドを出力します。 これにより、ダンプの標準への互換性が高まりますが、ダンプ内のオブジェクトの履歴によっては正しくリストアされない可能性が生じます。 また、 SET SESSION AUTHORIZATION を使用したダンプを正しくリストアするためには、確実にスーパーユーザ権限が必要となります。 ALTER OWNER で必要な権限はこれよりも少なくなります。

-?
--help

pg_dump のコマンドライン引数の使用方法を表示し、終了します。

以下のコマンドラインオプションは、データベース接続パラメータを制御します。

-d dbname
--dbname= dbname

接続するデータベースの名前を指定します。 コマンドラインでオプション以外の最初の引数として dbname を指定することと同じです。

このパラメータに = 記号が含まれる場合や有効な URI 接頭辞( postgresql:// または postgres:// )から始まる場合、 conninfo として扱われます。 詳細については 項31.1 を参照してください。

-h host
--host= host

サーバが稼働しているマシンのホスト名を指定します。 この値がスラッシュから始まる場合、Unixドメインソケット用のディレクトリとして使用されます。 デフォルトは、設定されていれば PGHOST 環境変数から取得されます。 設定されていなければ、Unixドメインソケット接続と仮定されます。

-p port
--port= port

サーバが接続を監視するTCPポートもしくはローカルUnixドメインソケットファイルの拡張子を指定します。 デフォルトは、設定されている場合、 PGPORT 環境変数の値となります。設定されていなければ、コンパイル時のデフォルト値となります。

-U username
--username= username

接続ユーザ名です。

-w
--no-password

パスワードの入力を促しません。 サーバがパスワード認証を必要とし、かつ、 .pgpass ファイルなどの他の方法が利用できない場合、接続試行は失敗します。 バッチジョブやパスワードを入力するユーザが存在しない場合にこのオプションは有用かもしれません。

-W
--password

データベースに接続する前に、 pg_dump は強制的にパスワード入力を促します。

サーバがパスワード認証を要求する場合 pg_dump は自動的にパスワード入力を促しますので、これが重要になることはありません。 しかし、 pg_dump は、サーバにパスワードが必要かどうかを判断するための接続試行を無駄に行います。 こうした余計な接続試行を防ぐために -W の入力が有意となる場合もあります。

--role= rolename

ダンプを作成する際に使用するロール名を指定します。 このオプションにより pg_dump はデータベースに接続した後に SET ROLE rolename コマンドを発行するようになります。 認証に使用したユーザ( -U で指定されたユーザ)が pg_dump で必要とされる権限を持たないが、必要な権限を持つロールに切り替えることができる場合に有用です。 一部のインストレーションではスーパーユーザとして直接ログインさせないポリシーを取ることがありますが、このオプションを使用することでポリシーに反することなくダンプを作成することができます。

環境

PGDATABASE
PGHOST
PGOPTIONS
PGPORT
PGUSER

デフォルトの接続パラメータです。

また、このユーティリティは、他のほとんどの PostgreSQL ユーティリティと同様、 libpq でサポートされる環境変数を使用します( 項31.14 を参照してください)。

診断

pg_dump は内部で SELECT 文を実行します。 pg_dump の実行時に問題が発生する場合は、 psql などを使用して、そのデータベースから情報を選択できることを確認してください。 また、 libpq フロントエンドライブラリで使用されるデフォルトの接続設定や環境変数も適用されます。

通常 pg_dump のデータベースに対する活動は統計情報コレクタにより収集されます。 これを望まない場合、 PGOPTIONS または ALTER USER コマンドを使用して track_counts パラメータを偽に設定してください。

注釈

データベースクラスタにおいて template1 データベースに対し独自の変更を行っている場合、 pg_dump の出力は、確実に空のデータベースにリストアするように注意してください。 そうしないと、おそらく追加されたオブジェクトの重複定義によってエラーが発生します。 独自の追加が反映されていない空のデータベースを作成するには、 template1 ではなく template0 をコピーしてください。 以下に例を示します。

CREATE DATABASE foo WITH TEMPLATE template0;

--disable-triggers オプションを使用し、データのみのダンプを行う場合、 pg_dump はデータを挿入する前にユーザテーブルにトリガを無効にする問い合わせを発行し、データの挿入が完了した後で、それらを再び有効にする問い合わせを発行します。 リストアが途中で停止した場合、システムカタログが不適切な状態のままになっている可能性があります。

tarアーカイブのメンバのサイズは、8ギガバイト未満に制限されています (これはtarファイル形式自体が持っている制限です)。 そのため、いずれか1つのテーブルのテキスト表現がこのサイズを越える場合、この形式は使用できません。 tarアーカイブとその他の出力形式の合計サイズには制限がありません。 ただしオペレーティングシステムによる制限がある場合があります。

pg_dump が生成するダンプファイルには、オプティマイザが問い合わせ計画を決定する際に使用される統計情報が含まれていません。 そのため、最適な性能を発揮するために、ダンプファイルからリストアした後で ANALYZE を実行することをお勧めします。 詳しくは 項23.1.3 および 項23.1.6 を参照してください。 ダンプファイルはまた ALTER DATABASE ... SET コマンドがまったく含まれません。 これらの設定はデータベースユーザと他のインストレーション全体の設定に従って pg_dumpall によってダンプされます。

pg_dump は新しいバージョンの PostgreSQL へのデータ移行に使用されますので、 pg_dump の出力は pg_dump のバージョンより新しいバージョンの PostgreSQL データベースへロード可能と想定できるようになっています。 また、 pg_dump は自身より古いバージョンの PostgreSQL データベースを読み取ることもできます。 (現在はバージョン7.0までのサーバをサポートします。) しかし、 pg_dump はそのメジャーバージョンより新しい PostgreSQL サーバのダンプを取ることはできません。 試そうとしても、無効なダンプが作成される危険はなく、失敗します。 また、 pg_dump の出力がメジャーバージョンが古いサーバにロードできるとは、たとえ同じバージョンのサーバから取得したダンプであっても、保証されていません。 より古いサーバへのダンプファイルのロードには、古いサーバでは理解できない構文を削除するために、ダンプファイルの手作業による修正が必要になることがあります。

mydb という名前のデータベースをSQLスクリプトファイルにダンプします。


$
 
pg_dump mydb > db.sql

newdb という名前の(新規に作成した)データベースにスクリプトを再ロードします。


$
 
psql -d newdb -f db.sql

カスタム形式のアーカイブファイルにデータベースをダンプします。


$
 
pg_dump -Fc mydb > db.dump

ディレクトリ形式アーカイブにデータベースをダンプします。


$
 
pg_dump -Fd mydb -f dumpdir

5個の作業用ジョブを使用してデータベースをdirectory形式のアーカイブにダンプします。


$
 
pg_dump -Fd mydb -j 5 -f dumpdir

newdb という名前の(新規に作成した)データベースにアーカイブファイルを再ロードします。


$
 
pg_restore -d newdb db.dump

mytab という名前の単一のテーブルをダンプします。


$
 
pg_dump -t mytab mydb > db.sql

detroit スキーマ内の emp から始まる名前のテーブルをすべてダンプします。 ただし、 employee_log という名前のテーブルは除きます。


$
 
pg_dump -t 'detroit.emp*' -T detroit.employee_log mydb > db.sql

east または west で始まり gsm で終わるスキーマをすべてダンプします。 ただし、 test という単語を含む場合は除きます。


$
 
pg_dump -n 'east*gsm' -n 'west*gsm' -N '*test*' mydb > db.sql

正規表現記法を使用してオプションをまとめた形で同じことを行います。


$
 
pg_dump -n '(east|west)*gsm' -N '*test*' mydb > db.sql

ts_ から始まる名前のテーブルを除き、すべてのデータベースオブジェクトをダンプします。


$
 
pg_dump -T 'ts_*' mydb > db.sql

大文字または大文字小文字混在の名前を -t などのスイッチに指定するには、名前を二重引用符で括らなければなりません。 さもないと小文字に変換されます。( パターン を参照してください。) しかし、二重引用符はシェルでも特別に扱われますので、これも引用符で括らなければなりません。 したがって、大文字小文字混在の名前を持つテーブルを1つダンプするには、以下のようにしなければなりません。


$
 
pg_dump -t "\"MixedCaseName\"" mydb > mytab.sql

関連項目

pg_dumpall , pg_restore , psql

powered by SEO.CUG.NET