1 はじめに
• 強化された互換性機能。第2章では、Advanced Serverでサポートされている互換性機能の概要について説明します。
• データベース管理。第3章では、データベース管理者に役立つ機能やツールについて説明します。セクション3.2で説明した索引アドバイザーは、アプリケーションのパフォーマンスを向上させるために表に必要な追加索引を判別するのに役立ちます。
セクション3.3で説明したSQLプロファイラは、アプリケーションで不適切に実行されているSQLクエリを検出して診断します。
• セキュリティ。第4章では、Advanced Serverでサポートされているセキュリティ機能について説明します。セクション4.1で説明したSQL / Protectは、SQLインジェクション攻撃に対する保護機能を提供します。
セクション4.2で説明した仮想プライベートデータベースは、きめ細かな行レベルのアクセスを提供します。
• EDBリソースマネージャ。第5章では、Advanced Serverプロセスによるシステムリソースの使用を制御する機能を提供するEDB Resource Manager機能について説明します。セクション5.3で説明したDirty Buffer Throttlingは、Advanced Serverプロセスによる共有バッファのダーティレートを制御する方法を提供します。
•
• パフォーマンス分析とチューニング。第8章では、アプリケーションおよびデータベース・サーバーのパフォーマンスを分析および改善するためのさまざまなツールについて説明します。
• EDBクローンスキーマ。第9章では、単一のデータベース内またはあるデータベースから別のデータベースにスキーマとそのデータベースオブジェクトをコピーする機能を提供するEDBクローンスキーマ機能について説明します。
•
• 拡張されたSQLおよびその他のその他の機能第11章では、拡張されたSQLの機能と、柔軟性と利便性を高めるその他の機能について説明します。
•
• 高度なサーバーのキーワード。第13章では、Advanced Serverがキーワードとして認識する単語について説明します。
1.1 新機能
•
•
• Advanced Serverは、機密データの特定のユーザーへの公開を制限するための技術であるデータの変更を サポートします。データを編集すると、そのようなユーザーに表示されるデータが変更されます。これは、機密データを持つテーブルの修正ポリシーを定義することによって実現されます。詳細は、 4.4項を参照してください。
• Advanced Serverは 、データベース接続、ログインしているユーザー、実行中のクエリ、および待機イベントなどの情報を収集する定期的な間隔で各実行中のセッションを調査するバックグラウンドワーカーであるEDB待ち状態を サポートするようになりました。詳細は、 8.2項を参照してください。
• Advanced Serverでは、 edb_custom_plan_triesパラメータを-1 設定することで、カスタムプランの生成を無限に試行できるようになりました 。詳細は、第3.1.3.5.1項を参照してください。
1.2 このガイドで使用される表記規則以下の説明では、 用語は、言語キーワード、ユーザ提供値、リテラルなどの任意の単語または単語群を指す。用語の正確な意味は、それが使用される文脈に依存する。
• イタリック体のフォントでは、通常、最初に定義された文章に新しい用語が導入されています。
• Fixed-width (mono-spaced) fontは、SQLコマンド、例で使用されている特定のテーブルとカラム名、プログラミング言語キーワード、ディレクトリパスとファイル名、パラメータ値など、文字通り与えなければならない用語に使用されます。 postgresql.conf 、 SELECT * FROM emp;
•
• 角括弧[]は、囲まれた用語の1つまたはいずれかが置換されている可能性があることを示します。たとえば、 [ a | b ] 、「 a 」または「 b 」のいずれかを選択するか、またはどちらも選択しないことを意味します。
•
•
• このドキュメントの情報の一部は、PostgreSQLおよびEDB Postgres Advanced Serverデータベースシステムに互換的に適用される場合があります。 Advanced Server という用語は、EDB Postgres Advanced Serverを指すのに使用されます。 Postgresという用語は、一般にPostgreSQLとAdvanced Serverの両方を指しています。これらの2つのデータベースシステムを区別する必要がある場合は、PostgreSQLまたはAdvanced Serverという特定の名前が使用されます。
• PostgreSQLまたはAdvanced Server製品のインストールディレクトリパスは、 POSTGRES_INSTALL_HOME と呼ばれます。 PostgreSQL Linuxインストールの場合、デフォルトは/opt/PostgreSQL/ x . xはバージョン10以前のバージョンです。それ以降のバージョンでは、PostgreSQLコミュニティパッケージを使用してください。バージョン10以前のバージョンで対話型インストーラを使用してAdvanced Server Linuxをインストールする場合、デフォルトは/opt/edb/as x . x 。 RPMパッケージを使用してAdvanced Server Linuxをインストールする場合、デフォルトは/usr/edb/as xxです。 Advanced Server Windowsインストールの場合、デフォルトはC:\Program Files\edb\as xxです。製品のバージョン番号はxで表され. xまたはxx (バージョン10以降)
1.4 このガイドで使用されているサンプルについてどこ xx Advanced Serverのバージョン番号です。さらに、Oracleデータベースと互換性のある構文を使用して作成されたデータベース・オブジェクトを含むスクリプトが、同じディレクトリにあります。このスクリプトファイルは edb-sample.sqlです。
• 1.4.1 サンプルデータベースの説明サンプル企業は地域的に多様なため、部門の所在を追跡します。各社員は部門に割り当てられています。各部門は、固有の部門番号と短い名前で識別されます。各部門は1つの場所に関連付けられています。部門に関するすべての情報は、 deptテーブルに保管されます。同社はまた、従業員が保有する雇用に関する情報を追跡します。従業員の中には、長年にわたり会社と一緒にいて、異なるポジション、昇給、交換部門などを持っている人もいます。従業員ステータスの変更が発生すると、会社は元のポジションの終了日を記録します。新しいジョブレコードが追加され、開始日と新しい職務、部門、給与、およびステータス変更の理由が記録されます。すべての従業員履歴は、 jobhistテーブルに保持されます。次は pg-sample.sqlスクリプトです。
Advanced Serverには、Oracleアプリケーションでサポートされている構文との互換性を提供する拡張機能が含まれています。 Advanced Serverで サポートされているすべての互換性機能の 詳細は、「Oracleデベロッパー・ガイドのデータベース互換性」を参照してください。情報は4つのガイドに分かれています。
•
• EDB * Plusは、EDB * Loaderの、EDB *ラップ、そして DRITA:Oracleの開発者ツールおよびユーティリティ・ガイドのためのデータベースの互換性は、Advanced Serverによってサポート互換性ツールに関する情報を提供します。
•
•
2.1 互換機能の有効化
•
2.2 ストアドプロシージャ言語
2.3 オプティマイザのヒントDELETE 、 INSERT 、 SELECT 、またはUPDATEコマンドを呼び出すと、サーバーは一連の実行計画を生成します。それらの実行計画を分析した後、サーバーは、(最も)最も時間のかかる結果セットを返すプランを選択します。サーバーの計画の選択は、いくつかの要素に依存します。
•
• ANALYZEコマンドによって収集された列統計 。オプティマイザ・ヒントは、 DELETE 、 INSERT 、 SELECTまたはUPDATEコマンドの直後にあるコメントのような構文に埋め込まれたディレクティブ(または複数のディレクティブ)です。コメント内のキーワードは、結果セットを作成するときに特定のプランを採用または回避するようサーバーに指示します。オプティマイザ・ヒントの使用方法の詳細は、次のOracle Developer's GuideのDatabase Compatibilityを参照してください。
2.4 データ・ディクショナリ・ビューAdvanced Serverには、Oracleデータ・ディクショナリ・ビューと互換性のある方法でデータベース・オブジェクトに関する情報を提供する一連のビューが含まれています。 Advanced Serverで利用可能なビューの詳細については、次のURLにある「 Oracle Developer Reference Guide」のデータベース互換性 を参照してください 。
2.5 dblink_oradblink _ oraは、Advanced Server内からOracleシステムに格納されたデータのSELECT 、 INSERT 、 UPDATEまたはDELETEを可能にするOCIベースのデータベース・リンクを提供します。 dblink _ ora使用dblinkとサポートされている関数とプロシージャの詳細については、次のURLにある「Oracleデベロッパーズ・ガイド」のデータベース互換性を参照してください。
2.6 プロファイル管理Advanced Serverは、プロファイル管理用の互換SQL構文をサポートしています。プロファイル管理コマンドを使用すると、データベースのスーパーユーザーは、名前付き プロファイル 。各プロファイルは、 passwordとmd5認証を強化するpassword管理のルールを定義しています。プロファイル内のルールは次のことができます。
2.7 組み込みパッケージ
以前は今、アプリケーション・コードを変更せずに、最小限でAdvanced ServerまたはOracleデータベースのいずれかで動作することができ、「固定」されたアプリケーション- オープンクライアントライブラリでは、Oracle Call Interfaceのとアプリケーションの相互運用性を提供します。 Open Client LibraryのEnterpriseDB実装はC言語で記述されています。
2.9 ユーティリティ下記のユーティリティでサポートされている互換構文の詳細については、次の URLにある「Oracle Developer Tools and Utilities Guide」 の データベース互換性を 参照してください 。
• DRITA(Dynamic Runtime Instrumentation Tools Architecture)を使用すると、DBAはカタログ・ビューを問い合せて 、個々のセッションまたはシステム全体のパフォーマンスに影響を及ぼす待機イベント を判別できます 。 DRITAには、各イベントの発生回数と待機時間が記録されています。この情報を使用してパフォーマンスの問題を診断できます。 DRITAは最小のシステムリソースを消費しながらこの機能を提供します。
2.10 ECPGPlus
• Oracleデータベースと互換性のある CALL文ECPGPlusの使用方法については、以下のEnterpriseDB Webサイトから入手可能なEDB Postgres Advanced Server ECPG Connector Guide を参照してください 。
2.11 テーブルのパーティション化
• パーティション設計にその要件を計画する場合は、パーティションを追加または削除してバルクロード(またはアンロード)を実装できます。 ALTER TABLE は、一括操作よりはるかに高速です。また 、バルク DELETE によって引き起こされる VACUUM オーバーヘッドを 完全に回避し ます。Advanced Serverでサポートされているデータベース互換性機能の詳細は、次の Oracle Developer's GuideのDatabase Compatibilityを 参照してください 。
3 データベース管理
3.1 構成パラメータ
3.1.1 設定パラメータの設定
•
• 整数。小数部のない数値。
• 浮動小数点。オプションの小数部分を小数点で区切った数値。
• 文字列。テキスト値。値が単純な識別子または数値でない場合(つまり、値にスペースやその他の句読記号などの特殊文字が含まれている場合)、単一引用符で囲みます。
• 列挙型。文字列値の特定のセット。許可される値はシステムビューpg_settings.enumvalsます。 Enum値は大文字と小文字を区別しません。設定によっては、メモリまたは時間の値を指定するものがあります。これらはそれぞれ暗黙の単位を持ちます。単位はキロバイト、ブロック(通常は8キロバイト)、ミリ秒、秒、または分です。デフォルトの単位は、システムビュー pg_settings.unit 参照することで見つけることができます 。異なる単位を明示的に指定することができます。有効なメモリ単位は、 kB (キロバイト)、 MB (メガバイト)、 GB (ギガバイト)です。有効な時間単位はms (ミリ秒)、 s (秒)、 min (分)、 h (時間)、 d (日)です。メモリ単位の乗数は1024です。
• データベースクラスタ全体のほとんどすべての設定可能なパラメータの初期設定は、設定ファイル postgresql.conf リストされています 。これらの設定は、データベースサーバーの起動または再起動時に有効になります。これらの初期パラメータ設定の一部は、次の点で説明するようにオーバーライドできます。すべての構成パラメーターには、明示的にオーバーライドされなければ有効な組み込みのデフォルト設定があります。
•
• SQLコマンド ALTER DATABASE 、 ALTER ROLE 、またはALTER ROLE IN DATABASEを使用して、特定のパラメータ設定を変更できます。変更されたパラメータ設定は、コマンドの実行後に新しいセッションに反映されます。 ALTER DATABASEは、指定されたデータベースに接続する新しいセッションに影響します。 ALTER ROLEは、指定されたロールによって開始された新しいセッションに影響します。 ALTER ROLE IN DATABASEは、指定されたデータベースに接続する指定されたロールによって開始された新しいセッションに影響します。これらのSQLコマンドによって確立されたパラメータ設定は、データベースサーバーの再起動によって無期限に有効なまま残り、第2および第3の箇条書きで説明した方法で設定された設定を上書きします。パラメータ設定を使用して確立ALTER DATABASE 、 ALTER ROLE 、またはALTER ROLE IN DATABASEコマンドはのみによって変更することができます。異なるパラメータ値を持つa)の再発行、これらのコマンド、またはb)のいずれかを使用して、これらのコマンドを発行してSET parameter TO DEFAULT RESET parameter句をparameter 。これらの句は、パラメータを、以前の箇条書きに記載された方法によって確立された設定を使用して変更する。これらのSQLコマンドの正確な構文については、 PostgreSQLコアマニュアルの第VI章「リファレンス」の項I「SQLコマンド」を参照してください。
• PGOPTIONS環境変数を使用するか、EDB-PSQLまたはPSQLコマンドライン端末プログラム内のSETコマンドを使用して、個々のセッションの継続時間中の特定のパラメータ設定を変更できます 。このようにして行われたパラメータ設定は、第2、第3、および第4の箇条書きで説明された方法のいずれかを使用して確立された設定よりも優先されます。
3.1.2 構成パラメータの概要
• パラメータ。構成パラメータ名。
• 効果の範囲。構成パラメーター設定の有効範囲。 'クラスタ' - 設定はデータベースクラスタ全体(つまり、データベースサーバインスタンスによって管理されるすべてのデータベース)に影響します。 'データベース' - 設定はデータベースごとに異なり、データベースの作成時に設定されます。ロケール設定に関連する少数のパラメータに適用されます。 'セッション' - 設定は、個々のセッションの粒度に応じて変更できます。つまり、以下のエンティティに対して異なる設定を行うことができます。このリストの後の設定は、以前の設定を上書きします。a)データベースクラスタ全体、b)データベースクラスタ内の特定のデータベース、c)特定のロール、d) e)特定のセッション。
• 効果が発揮されるとき。変更されたパラメータ設定が有効になったとき。 'プリセット' - Advanced Server製品が構築されたとき、または特定のデータベースが作成されたときに確立されます。これは読み取り専用パラメータであり、変更することはできません。 'Restart' - データベースサーバーを再起動する必要があります。 'リロード' - 構成ファイルを再ロードする必要があります(またはデータベースサーバーを再起動できます)。 'Immediate' - PGOPTIONS環境変数またはSETコマンドを使用して現在のセッションの設定を変更すると、セッションですぐに有効にPGOPTIONSます。 ALTER DATABASE 、 ALTER ROLE 、またはALTER ROLE IN DATABASEコマンドを使用して設定を変更すると、新しいセッションで効果的です。
• 許可ユーザー。パラメーター設定を有効にするために使用するオペレーティング・システム・アカウントまたはデータベース・ロールのタイプ。 'EPASサービスアカウント' - EDB Postgres Advanced Serverサービスアカウント(Oracleデータベースと互換性のあるインストールの場合はenterprisedb 、PostgreSQL互換モードインストールの場合はpostgres ) 'Superuser' - スーパーユーザー権限を持つデータベースの役割。 'User' - 影響を受けるデータベースオブジェクト( ALTERコマンドで変更されるデータベースまたはロール)に関する権限を持つデータベースロール。 'n / a' - 任意のユーザーがパラメータ設定を変更することはできません。
• 説明。構成パラメータの簡単な説明。
• EPASのみ。 'X' - 設定パラメータは、EDB Postgres Advanced Serverにのみ適用されます。このカラムには、設定パラメータがPostgreSQLにも適用されることを示していません。注:決して変更する必要のないいくつかのパラメーターがあります。これらは、[説明]列の[ 注:内部使用のみ]として指定されています。
" is allowed in string literals. Sets whether " \' " is allowed in string literals. Sets whether " " is allowed in string literals. or syslog as the destination directory for audit files. edb_audit_directory or syslog as the destination directory for audit files. Sets or syslog as the destination directory for audit files. ORDER BY to depth-first order. Note: For internal use only. queries with no CONNECT BY queries with no Sort results of to depth-first order. Note: For internal use only. Sort results of to depth-first order. Note: For internal use only. DATE should behave like a TIMESTAMP should behave like a Determines whether should behave like a TIMESTAMP or not. GREATEST and LEAST functions should handle NULL parameters. Determines how functions should handle NULL parameters. items beyond which GEQO is used. FROM items beyond which GEQO is used. Sets the threshold of items beyond which GEQO is used. Disables reading from system indexes. (Can also be set with at session start.) PGOPTIONS at session start.) Disables reading from system indexes. (Can also be set with at session start.) JOIN constructs are not flattened. FROM -list size beyond which Sets the constructs are not flattened. Lists shared libraries to preload into each backend. (Can also be set with at session start.) PGOPTIONS at session start.) Lists shared libraries to preload into each backend. (Can also be set with at session start.) Logs each successful connection. (Can also be set with at session start.) PGOPTIONS at session start.) Logs each successful connection. (Can also be set with at session start.) Logs end of a session, including duration. (Can also be set with at session start.) PGOPTIONS at session start.) Logs end of a session, including duration. (Can also be set with at session start.) Waits N seconds on connection startup after authentication. (Can also be set with at session start.) PGOPTIONS at session start.) Waits N seconds on connection startup after authentication. (Can also be set with at session start.) pg_stat_activity.current_query Sets the size reserved for , in bytes. Sets the size reserved for , in bytes. Umask used for files created through the UTL_FILE package. Umask used for files created through the package.
3.1.3 機能別の構成パラメータ
• デフォルト値。設定ファイルに値が明示的に設定されていない場合のデフォルト設定。
• 範囲。許容される値の範囲。
• 効果の最小範囲。明確な設定が可能な最小の範囲。一般的に、別個の設定の最小範囲は、 クラスタ全体(設定はすべてのデータベースとそのセッション、クラスタ内で同じ)またはセッションごと (設定はロール、データベース、または個々のセッションによって異なる場合があります)です。 (この属性はセクション2.1.2の表の "有効範囲"列と同じ意味です)。
• 値の変更が有効になるときパラメータ値の変更を有効にするために必要な最小限の侵略的アクション。構成ファイルで行われたすべてのパラメータ設定の変更は、データベースサーバーの再起動時に有効になります。ただし、特定のパラメータにはデータベースサーバの再起動が必要です。いくつかのパラメータ設定の変更は、データベースサーバを停止させずに設定ファイルをリロードすることで有効になります。最後に、結果が即時であるクライアント側のアクションによっては、他のパラメータ設定の変更を有効にすることができます。 (この属性はセクション2.1.2の表の "When Takes Effect"列と同じ意味です)。
• 有効にするための必要な承認。パラメータの設定を変更するためのユーザ権限のタイプ。データベースサーバーの再起動または構成ファイルの再ロードが必要な場合、ユーザーはEPASサービスアカウント(Advanced Serverの互換性インストールモードに応じて、 enterprisedbまたはpostgresなければなりません。この属性は、第2.1.2項の表の「許可ユーザー」列と同じ意味を持ちます。
3.1.3.1 上位パフォーマンス関連パラメータ3.1.3.1.1 shared_buffersデフォルト値: 32MB範囲:システムに依存する128kB効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントデータベースサーバが共有メモリバッファに使用するメモリ量を設定します。デフォルトは通常32メガバイト( 32MB ) ですが、( initdb決定されたinitdb )カーネル設定がそれをサポートしていない場合は少なくなります。この設定は少なくとも128キロバイトでなければなりません。 ( BLCKSZデフォルト以外の値では、最小値が変更されます)。ただし、通常、パフォーマンスを向上させるには最小値よりも大幅に高い設定が必要です。1GB以上のRAMを持つ専用のデータベースサーバーを使用している場合、 shared_buffers 適切な開始値はシステムのメモリの25%です。 shared_buffers大きな設定でも有効な作業負荷がありますが、Advanced Serverもオペレーティングシステムのキャッシュに依存しているため、 shared_buffersへのRAMの割り当てが40%を超える場合は、より少ないメモリ量で動作する可能性は低いです。RAMが1GB未満のシステムでは、オペレーティングシステムに十分な領域を確保するために、RAMの割合がより小さくなります(これらの状況では、メモリの15%がより一般的です)。また、Windowsでは、 shared_buffers 値が大きいほど有効ではありません。設定を比較的低く保ち、オペレーティングシステムのキャッシュを使用する方が良い結果が得られます。 Windowsシステム上のshared_buffersの有用な範囲は、通常64MBから512MBです。このパラメータを増やすと、Advanced Serverは、オペレーティングシステムのデフォルト構成で許可されているよりも多くのSystem V共有メモリを要求する可能性があります。必要に応じて、これらのパラメータを調整する方法については、 PostgreSQLコア文書の 第17.4.1項「共有メモリとセマフォ」を参照してください。3.1.3.1.2 work_memデフォルト値: 1MB範囲: 64kB〜2097151kB効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザー一時ディスクファイルに書き込む前に内部ソート操作およびハッシュテーブルで使用されるメモリ量を指定します。値のデフォルトは1メガバイト( 1MB )です。複雑なクエリの場合、いくつかのソート操作またはハッシュ操作が並行して実行されている可能性があります。各操作では、一時ファイルにデータを書き込む前にこの値で指定された量のメモリーを使用することができます。また、いくつかの実行中のセッションは、そのような操作を同時に行うことができます。したがって、使用されるメモリの総量は、 work_memの値の何倍でもwork_memません。値を選択するときは、この事実を念頭に置いておく必要があります。ソート操作は、 ORDER BY 、 DISTINCT 、およびマージ・ジョインに使用されDISTINCT 。ハッシュ・テーブルは、ハッシュ・ジョイン、ハッシュ・ベースの集計、およびINサブクエリのハッシュ・ベースの処理で使用されます。3.1.3.1.3 maintenance_work_memデフォルト値: 16MB範囲: 1024kB〜2097151kB効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーVACUUM 、 CREATE INDEX 、 ALTER TABLE ADD FOREIGN KEY など、メンテナンス操作で使用するメモリの最大量を指定します。デフォルトは16メガバイト( 16MB )です。これらの操作の1つのみがデータベースセッションによって一度に実行され、通常はインストールで同時に実行されていないので、この値をwork_memよりも大幅に大きく設定することは安全work_mem 。設定を大きくすると、バキューム処理やデータベース・ダンプのリストアのパフォーマンスが向上する可能性があります。自動バキュームが実行されているときは、 autovacuum_max_workers回までこのメモリが割り当てられる可能性があるので、デフォルト値を高く設定しないように注意してください。3.1.3.1.4 wal_buffersデフォルト値: 64kB範囲: 32kBからシステムに依存効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントWALデータの共有メモリーで使用されるメモリー量。デフォルトは64キロバイト( 64kB )です。この設定は、1回の通常のトランザクションによって生成されるWALデータの量を保持するのに十分なだけ大きくする必要があります。これは、トランザクションコミットごとにデータがディスクに書き出されるためです。このパラメータを増やすと、Advanced Serverは、オペレーティングシステムのデフォルト構成で許可されているよりも多くのSystem V共有メモリを要求する可能性があります。必要に応じて、これらのパラメータを調整する方法については、 PostgreSQLコア文書の 第17.4.1項「共有メモリとセマフォ」を参照してください。この非常に小さな設定でも問題は必ずしも発生しませんが、余分な fsync呼び出しが発生し、システム全体のスループットが低下する可能性があります。この値を1MB程度に増やすことで、この問題を軽減することができます。非常に忙しいシステムでは、最大約16MBのさらに高い値が必要になることがあります。 shared_buffersと同様に、このパラメータはAdvanced Serverの初期共有メモリ割り当てを増加させるため、Advanced Serverの起動に失敗する場合は、オペレーティングシステムの制限を増やす必要があります。3.1.3.1.5 checkpoint_segments3.1.3.1.6 checkpoint_completion_targetパラメータタイプ:浮動小数点デフォルト値: 0.5範囲: 0〜1効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウント3.1.3.1.7 checkpoint_timeoutデフォルト値: 5分範囲: 30〜3600効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウント自動WALチェックポイント間の最大時間(秒)。デフォルトは5分( 5min )です。このパラメータを増やすと、クラッシュリカバリに必要な時間が長くなります。前述のチェックポイントパラメータを調整することの欠点は、ご使用のシステムがわずかなディスク容量を使用し、クラッシュが発生した場合に回復に時間がかかることです。ただし、ほとんどのユーザーにとって、これは パフォーマンスの大幅な向上の ために支払う小さな値段 です。3.1.3.1.8 max_wal_sizeパラメータタイプ: 整数デフォルト値: 1 GB範囲: 2〜2147483647効果の最小範囲: クラスター値の変更が反映されるとき: リロードmax_wal_size は、自動WALチェックポイント間でWALが到達する最大サイズを指定します。これはソフトな制限です。 特殊な状況(重い負荷、失敗したarchive_command、または高いwal_keep_segments設定の場合)では、 WALサイズが max_wal_size を超えることがあり ます。このパラメータを増やすと、クラッシュリカバリに必要な時間が長くなります。このパラメータは、 postgresql でのみ設定できます 。 conf ファイルまたはサーバーのコマンドラインで実行します。3.1.3.1.9 min_wal_sizeパラメータタイプ: 整数デフォルト値: 80 MB範囲: 2〜2147483647効果の最小範囲: クラスター値の変更が反映されるとき: リロードWALディスクの使用量が min_wal_size で 指定された値を下回っている場合 、古いWALファイルは、後でチェックポイントで使用するためにリサイクルされます。これにより、(大きなバッチジョブを実行する場合のように)WAL使用のスパイクを処理するのに十分なWALスペースが確保されます。このパラメータは、postgresql.confファイルまたはサーバのコマンドラインでのみ設定できます。3.1.3.1.10 bgwriter_delayデフォルト値: 200ms範囲: 10ms〜10000ms効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウントバックグラウンドライターのアクティビティラウンド間の遅延を指定します。各ラウンドでは、いくつかのダーティバッファ( bgwriter_lru_maxpagesおよびbgwriter_lru_multiplierパラメータで制御可能)の書き込みを書き込みます。その後、 bgwriter_delayミリ秒間スリープして繰り返します。デフォルト値は200ミリ秒(ある 200ms )。多くのシステムでは、スリープ遅延の実効分解能は10ミリ秒であることに注意してください。 bgwriter_delayを10の倍数以外の値に設定すると、10の次の高い倍数に設定する場合と同じ結果になることがあります。通常、 bgwriter_delay チューニングするときは、デフォルト値から減らす必要があります。おそらく、利用率が非常に低いシステムで消費電力を節約することを除いて、このパラメータはほとんど増加しません。3.1.3.1.11 seq_page_costパラメータタイプ:浮動小数点デフォルト値: 1範囲: 0〜1.79769e + 308効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーシーケンシャルフェッチの一部であるディスクページフェッチのコストのプランナの見積もりを設定します。デフォルトは1.0です。この値は、同じ名前の表領域パラメータを設定することによって、特定の表領域に対してオーバーライドできます。 ( PostgreSQL Core Documentationの ALTER TABLESPACEコマンドを参照してください )。3.1.3.1.12 random_page_costパラメータタイプ:浮動小数点デフォルト値: 4範囲: 0〜1.79769e + 308効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザープランナが非シーケンシャルフェッチディスクページのコストの見積もりを設定します。デフォルトは4.0です。この値は、同じ名前の表領域パラメータを設定することによって、特定の表領域に対してオーバーライドできます。 ( PostgreSQL Core Documentationの ALTER TABLESPACEコマンドを参照してください )。この値を seq_page_costと比較して seq_page_costすると、システムは索引スキャンを優先します。索引スキャンを比較的高価に見せることになります。 cpu_tuple_costおよびcpu_index_tuple_costパラメータで記述されているCPUコストに比例したディスクI / Oコストの重要度を変更するには、両方の値を一緒にcpu_index_tuple_costできます。システムはそれを許可しますが、 random_page_costよりもseq_page_cost小さく設定しないでseq_page_cost 。しかし、データベースをメモリ内に大部分または完全に収めると、それらを等しく(または非常に近くに)設定することは理にかなっています。その場合、順不同のページに触れるためのペナルティはないからです。また、大量にキャッシュされたデータベースでは、RAM内のページをフェッチするコストが通常よりもはるかに小さいため、両方の値をCPUパラメータに対して低くする必要があります。3.1.3.1.13 effective_cache_sizeデフォルト値: 128MB範囲: 8kB〜17179869176kB効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーこのパラメータがあまりにも低く設定されている場合、計画者は有益な場合でもインデックスを使用しないことを決定する可能性があります。 effective_cache_sizeを物理メモリの50%に設定するのは、通常の保守的な設定です。より積極的な設定は、物理メモリの約75%になります。3.1.3.1.14 synchronous_commitパラメータタイプ:ブール値デフォルト値: true範囲: { true | false }効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーコマンドがクライアントに「成功」指示を返す前に、WALレコードがディスクに書き込まれるのをトランザクションコミットが待機するかどうかを指定します。デフォルトの安全な設定はオンです。オフにすると、成功がクライアントに報告されてから、トランザクションが実際にサーバークラッシュに対して安全であることが保証されるまでの間に遅延が生じる可能性があります。 (最大遅延は wal_writer_delay 3倍です)。fsync とは異なり 、このパラメータをoffに設定してもデータベースの矛盾が発生することはありません。オペレーティングシステムやデータベースのクラッシュにより、最近却下されたトランザクションの一部が失われる可能性がありますが、データベースの状態は、きれいに打ち切った。したがって、トランザクションの耐久性について正確な確信度よりもパフォーマンスが重要である場合、 synchronous_commitオフにすることは有用な選択肢になります。詳細については、「 PostgreSQL Core Documentation 」のセクション29.3「 非同期 コミット 」を参照してください。このパラメータはいつでも変更できます。任意の1つのトランザクションの動作は、コミット時に有効な設定によって決まります。したがって、いくつかのトランザクションを同期的にコミットし、他のトランザクションを非同期的にコミットすることが可能であり、有用です。たとえば、単一のマルチステートメント・トランザクションをデフォルトが反対の場合に非同期にコミットするには 、トランザクション内でSET LOCAL synchronous_commit TO OFFます。3.1.3.1.15 edb_max_spins_per_delayデフォルト値: 1000範囲: 10〜1000効果の最小範囲:クラスタごと有効化に必要な権限: EPASサービスアカウントedb_max_spins_per_delayを使用して、スピンロックを待機している間にセッションが「スピンする」最大回数を指定します。ロックが取得されない場合、セッションはスリープ状態になります。 edb_max_spins_per_delay代替値を指定しない場合、サーバーはデフォルト値の1000を適用します。3.1.3.1.16 pg_prewarm.autoprewarmパラメータタイプ:ブール値デフォルト値: true効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントこのパラメータは 、シャットダウン前に自動的に共有バッファをディスクにダンプするバックグラウンドワーカープロセスであるautoprewarmを データベースサーバが実行するかどうかを制御します 。次に、次回のサーバ起動時に共有バッファをプリウォームします。つまり、ディスクからブロックをバッファプールにロードします。場合 pg_prewarm.autoprewarm onに設定されている、 autoprewarm作業員が有効になっています。パラメータがoffに設定されていると、 autoprewarmは無効になります。パラメータはデフォルトでオンになっています。autoprewarmを使用する前に 、次の例に示すように、 postgresql.confファイルのshared_preload_libraries構成パラメータにリストされているライブラリに$libdir/pg_prewarmを追加する必要があります。shared _ preload _ librariesパラメータを変更した後 、データベースサーバを再起動してから、サーバが一貫性のある状態になった直後にautoprewarmバックグラウンドワーカーを起動します。autoprewarmプロセスは、以前に記録したブロックのロードを開始します$PGDATA/autoprewarm.blocksバッファプールに残された空きバッファスペースがなくなるまでに。このようにして、リカバリプロセスまたはクエリクライアントによってロードされた新しいブロックはすべて置換されません。いったん autoprewarmプロセスがディスクからバッファをロードし終えた、それは定期的にで指定した間隔でディスクに共有バッファをダンプしますpg_prewarm.autoprewarm_interval (節参照パラメータ3.1.3.1.17を )。次回のサーバーの再起動時に、 autoprewarmプロセスは最後にディスクにダンプされたブロックで共有バッファを予熱します。3.1.3.1.17 pg_prewarm.autoprewarm_intervalデフォルト値: 300秒範囲: 0〜2147483秒効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウントこれは、 autoprewarmバックグラウンドワーカーが共有バッファをディスクにダンプするまでの最小秒数です 。デフォルトは300秒です。 0に設定すると、共有バッファは定期的にダンプされませんが、サーバーがシャットダウンされたときにのみダンプされます。
3.1.3.2 リソース使用量/メモリ3.1.3.2.1 edb_dynatuneデフォルト値: 0範囲: 0〜100効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントAdvanced Serverを最初にインストールすると、 edb_dynatuneパラメータは、それがインストールされているホストマシン(開発マシン、混在マシン、または専用サーバー)の選択された使用状況に従って設定されます。ほとんどの場合、パフォーマンスを向上させるためにデータベース管理者がpostgresql.confファイルのさまざまな設定パラメータを調整する必要はありません。edb_dynatuneパラメータは、0以上100以下の任意の整数値に設定することができます。値0を指定すると、動的チューニング機能がオフになり、データベースサーバのリソース使用量はpostgresql.confファイルの他の設定パラメータの制御下に完全にpostgresql.confます。非ゼロの値が小さければ(例えば、1〜33)、ホスト・マシンのリソースの最小量がデータベース・サーバーに割り当てられます。この設定は、他の多くのアプリケーションが使用されている開発マシンで使用されます。edb_dynatune 値が選択されると、 postgresql.confファイル内の他の設定パラメータを調整することによって、データベースサーバのパフォーマンスをさらに微調整することができます。調整された設定は、 edb_dynatuneによって選択された対応する値を上書きします。パラメーターの値を変更するには、構成パラメーターをコメント解除し、目的の値を指定して、データベース・サーバーを再始動します。3.1.3.2.2 edb_dynatune_profileデフォルト値: oltp効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウント
• oltp。データベースサーバーが過度のオンライントランザクション処理ワークロードを処理している場合に推奨されます。
• 報告。重いデータの報告に使用されるデータベースサーバーに推奨されます。
• 混合。トランザクション処理とデータ報告が混在するサーバーに適しています。
3.1.3.3 リソース使用量/ EDBリソースマネージャ3.1.3.3.1 edb_max_resource_groupsデフォルト値: 16範囲: 0〜65536効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントこのパラメータは、EDB Resource Managerが同時に使用できるリソースグループの最大数を制御します。 edb_max_resource_groupsで指定された値より多くのリソースグループを作成できますが 、これらのグループ内のプロセスがアクティブに使用しているリソースグループの数はこの値を超えることはできません。3.1.3.3.2 edb_resource_groupパラメータタイプ:文字列デフォルト値:なし範囲:該当なし効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザー設定し edb_resource_group現在のセッションは、グループのリソースタイプの設定に応じてEDBリソースマネージャによって制御されるべきリソース・グループの名前にパラメータを。
3.1.3.4 問合せのチューニング3.1.3.4.1 enable_hintsパラメータタイプ:ブール値デフォルト値: true範囲: { true | false }効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーenable_hintsがオンの場合、SQLコマンドに埋め込まれたオプティマイザヒントが利用されます。オプティマイザのヒントは、このパラメータがオフの場合は無視されます。3.1.3.5 クエリのチューニング/プランナ・メソッドの構成3.1.3.5.1 edb_custom_plan_triesパラメータタイプ: 整数デフォルト値: 5範囲: -1〜100効果の最小スコープ: セッションごとアクティブ化に必要な承認: セッションユーザークライアントアプリケーションが準備されたステートメントを繰り返し実行する場合、サーバーは カスタム プランまたは 汎用 プランの 選択を決定する前にいくつかの実行プランを評価することを決定することがあります 。特定のワークロードでは、この余分な計画がパフォーマンスに悪影響を与える可能性があります。 edb_custom_plan_tries 構成パラメーターを 調整して 、一般プランを評価する前に考慮するカスタム計画の数を減らす ことができ ます。customer.salesman 索引が定義されている場合、 オプティマイザーは、順次スキャンを使用してこの照会を実行するか、索引スキャンを使用するかを選択できます。場合によっては、インデックスがシーケンシャルスキャンより高速です。それ以外の場合は、順次スキャンが勝利します。最適な計画は、テーブル内のセールスマン値の分布と検索値($ 1パラメーターに指定された値)によって異なります。クライアント・アプリケーションが custQuery prepared文を 繰り返し実行する と、オプティマイザはいくつかのパラメータ値固有の実行計画(カスタム計画)を生成し、その後に汎用計画(パラメータ値を無視する計画)を生成し、ジェネリックプランに固執するか、実行ごとにカスタムプランを作成し続ける必要があります。決定プロセスでは、計画を実行するコストだけでなく、カスタム計画を作成するコストも考慮されます。3.1.3.5.2 edb_enable_pruningパラメータタイプ:ブール値デフォルト値: true範囲: { true | false }効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーTRUEに設定すると 、 edb_enable_pruning使用すると、問合せプランナはパーティション表を早期にプルーニングできます。 早剪定は、クエリプランナは「プルーン」のクエリ・プランを生成する前に 、クエリで検索されないパーティション(すなわち、無視)をできることを意味します。これにより、検索されないパーティションのクエリプランが生成されなくなるため、パフォーマンスの向上に役立ちます。逆に、 遅延プルーニングとは、クエリプランナが各パーティションのクエリプランを生成した後にパーティションをプルーニングすることを意味します。 ( constraint_exclusion設定パラメータは、late-pruningを制御します。)初期プルーニング機能は、 WHERE句でのクエリの性質に依存します 。アーリー・プルーニングは、タイプWHERE column = literal ( WHERE deptno = 10 )の制約を持つ簡単なクエリでのみ利用できます。
3.1.3.6 レポート作成とロギング/ログの内容3.1.3.6.1 trace_hintsパラメータタイプ:ブール値デフォルト値: false範囲: { true | false }効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーオプティマイザヒント機能を使用して、ヒントがプランナによって使用されたかどうかに関するより詳細な情報を提供します。設定する client_min_messagesとtrace_hints次のように設定パラメータを:SELECTを使用してコマンドNO_INDEX以下に示すヒントは、上記の設定パラメータが設定されているときに生じる付加的な情報を示しています。3.1.3.6.2 edb_log_every_bulk_valueパラメータタイプ:ブール値デフォルト値: false範囲: { true | false }効果の最小スコープ:セッションごとアクティブ化に必要な権限:スーパーユーザ一括処理は、結果のステートメントをAdvanced ServerログファイルとEDB監査ログファイルの両方に記録します。しかし、一括処理における各ステートメントのロギングにはコストがかかります。これは、 edb_log_every_bulk_value構成パラメーターによって制御することができます。 trueに設定すると、一括処理のすべてのステートメントがログに記録されます。 falseに設定するfalse 、一括処理ごとにログメッセージが1回記録されます。さらに、持続時間は一括処理ごとに1回発行されます。デフォルトはfalse設定されていfalse 。
3.1.3.7 監査設定3.1.3.7.1 edb_auditデフォルト値: none効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウントデータベース監査を有効または無効にします。値 xmlまたはcsvは、データベース監査を有効にします。これらの値は、監査情報が取り込まれるファイル形式を表します。 noneはデータベース監査を無効にし、デフォルトでもあります。3.1.3.7.2 edb_audit_directoryパラメータタイプ:文字列デフォルト値: edb_audit範囲:該当なし効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウント3.1.3.7.3 edb_audit_filenameパラメータタイプ:文字列デフォルト値: audit-%Y%m%d_%H%M%S範囲:該当なし効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウント監査情報が格納される監査ファイルのファイル名を指定します。デフォルトのファイル名は audit-%Y%m%d_%H%M%Sです。エスケープシーケンス%Y 、 %mなどは、システムの日付と時刻に従って適切な現在の値に置き換えられます。3.1.3.7.4 edb_audit_rotation_dayパラメータタイプ:文字列デフォルト値: every効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウント監査ファイルをローテーションする曜日を指定します。有効な値は、 sun 、 mon 、 tue 、 wed 、 thu 、 fri 、 sat 、 every 、およびnoneです。回転を無効にするには、値をnone設定します。ファイルを毎日ローテーションするには、 edb_audit_rotation_day値をevery設定しevery 。特定の曜日にファイルを回転するには、値を希望の曜日に設定します。3.1.3.7.5 edb_audit_rotation_sizeデフォルト値: 0MB範囲: 0MB〜5000MB効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウント3.1.3.7.6 edb_audit_rotation_secondsデフォルト値: 0範囲: 0〜2147483647s効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウント3.1.3.7.7 edb_audit_connectデフォルト値: failed効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウントユーザーによるデータベース接続試行の監査を有効にします。すべての接続試行の監査を無効にするには、 edb_audit_connectをnone に設定します。失敗したすべての接続試行を監査するには、値をfailed設定します。すべての接続試行を監査するには、値をall設定します。3.1.3.7.8 edb_audit_disconnectデフォルト値: none効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウント3.1.3.7.9 edb_audit_statementパラメータタイプ:文字列デフォルト値: ddl, error範囲: { none | ddl | dml | insert | update | delete | truncate | select | error | create | drop | alter | grant | revoke | rollback | all }} ...効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウントこの構成パラメーターは、さまざまなカテゴリーのSQLステートメント、および特定のSQLコマンドに関連するステートメントの監査を指定するために使用されます。エラーを記録するには、パラメータ値を error 設定し error 。 CREATE TABLE 、 ALTER TABLEなどのすべてのDDL文を監査するには、パラメータ値をddl設定します。特定のタイプのDDL文を監査するには、パラメータ値に特定のSQLコマンド( create 、 drop 、またはalter )を含めることができます。また、オブジェクト・タイプは、次のようなコマンドに続く指定することができるcreate table 、 create view 、 drop roleなどのすべての変更文など、 INSERT 、 UPDATE 、 DELETEまたはTRUNCATE設定することにより、監査することができるedb_audit_statementするdml 。特定のタイプのDML文を監査するには、パラメータ値に特定のSQLコマンド、 insert 、 update 、 deleteまたはtruncateを含めることができます。これらのSQLコマンドに関する監査ステートメントには、パラメーター値select 、 grant 、 revoke 、またはrollbackを組み込みます。値をall設定するとall文が監査され、 noneするとこの機能は無効になります。3.1.3.7.10 edb_audit_tagパラメータタイプ:文字列デフォルト値:なし効果の最小範囲:セッションアクティブ化に必要な承認:ユーザー3.1.3.7.11 edb_audit_destinationデフォルト値: file効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウント監査ログ情報を edb_audit_directoryパラメータで指定されたディレクトリに記録するか、 syslogプロセスで管理されているディレクトリとファイルにedb_audit_directoryするかを指定します。 edb_audit_directory指定されたedb_audit_directory (デフォルト設定)を使用するようにfileに設定しfile 。設定syslogに設定されたsyslogプロセスとその場所を使用し/etc/syslog.confファイル。 注:最近のLinuxバージョンでは、syslogがrsyslogのに置き換えられていると設定ファイルがである/etc/rsyslog.conf 。3.1.3.7.12 edb_log_every_bulk_valueedb_log_every_bulk_value 、節参照3.1.3.6.2を 。
3.1.3.8 クライアント接続のデフォルト/ロケールと書式設定3.1.3.8.1 icu_short_formパラメータタイプ:文字列デフォルト値:なし範囲:該当なし効果の最小範囲:データベース値の変更が有効になった場合:該当なし構成パラメータ icu_short_formは、データベースまたはAdvanced Serverインスタンスに割り当てられたデフォルトのICU短縮形名を含むパラメータです。 ICU短縮形とUnicode照合アルゴリズムの一般的な情報については、 3.6節を参照してください。この構成パラメータは、 CREATE DATABASEコマンドをICU_SHORT_FORMパラメータ( ICU_SHORT_FORM項を参照 )とともに使用する場合に設定されます。この場合、指定された短縮形名が設定され、このデータベースに接続するときにicu_short_form構成パラメータに表示されます。 Advanced Serverインスタンスは、-- --icu_short_form option ( --icu_short_form option項を参照 )で使用されるinitdbコマンドで作成されます。この場合、指定された短縮名が設定され、そのAdvanced Serverインスタンス内のデータベースに接続されたときにicu_short_form構成パラメータに表示されますデータベースは、別の短い形式の独自のICU_SHORT_FORMパラメーターでそれをオーバーライドしません。上記の方法で確立されると、 icu_short_form設定パラメータを変更することはできません。3.1.3.9 クライアント接続のデフォルト/文の動作3.1.3.9.1 default_heap_fillfactorデフォルト値: 100範囲: 10〜100効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーテーブルのfillfactorは10〜100のパーセンテージです。100(完全詰め)がデフォルトです。より小さいfillfactorが指定されると、 INSERT操作は表のページを指定されたパーセンテージにのみパックします。各ページの残りのスペースは、そのページの行を更新するために予約されています。これにより、 UPDATEは更新された行のコピーを元のページと同じページに配置することができます。これは、別のページに配置するよりも効率的です。エントリが決して更新されないテーブルでは、完全なパッキングが最適ですが、大きく更新されたテーブルでは、より小さいfillfactorsが適切です。3.1.3.9.2 edb_data_redactionパラメータタイプ:ブール値デフォルト値: true範囲: { true | false }効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーデフォルト設定は TRUEなので、スーパーユーザーとテーブル所有者以外のすべてのユーザーにデータの変更が適用されます。
3.1.3.10 クライアント接続のデフォルト/その他のデフォルト3.1.3.10.1 oracle_homeパラメータタイプ:文字列デフォルト値:なし範囲:該当なし効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントOracleサーバーへのOracle Call Interface(OCI)データベース・リンクを作成する前に、Advanced Serverを正しいOracleホーム・ディレクトリに誘導する必要があります。 Linux(またはWindowsの場合はPATH ) の LD_LIBRARY_PATH環境変数をOracleクライアントのインストールディレクトリのlibディレクトリに設定します。Windowsの場合のみ、 oracle_home構成パラメータの値を postgresql.confファイルに設定できます。 oracle_home構成パラメーターで指定された値は、Windows PATH環境変数よりも優先されます。Advanced Serverを起動するたびに、Linux の LD_LIBRARY_PATH環境変数( PATH環境変数またはWindowsのoracle_home構成パラメータ)を正しく設定する必要があります。oracle_home = ' lib_directory 'oracle_home構成パラメータを設定した後は、変更を有効にするためにサーバーを再起動する必要があります。 Windowsサービスコンソールからサーバーを再起動します。3.1.3.10.2 odbc_lib_pathパラメータタイプ:文字列デフォルト値:なし範囲:該当なし効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントodbc_lib_path = ' complete_path_to_libodbc.so '
3.1.3.11 互換性オプション3.1.3.11.1 edb_redwood_dateパラメータタイプ:ブール値デフォルト値: false効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザー場合 DATEコマンドの列のデータ・タイプとして表示され、それに変換されTIMESTAMP設定パラメータ場合、テーブル定義はデータベースに格納された時点でedb_redwood_dateに設定されているTRUE 。したがって、時間成分も日付とともに列に格納されます。edb_redwood_dateが FALSE 設定されている FALSE 、 CREATE TABLE ALTER TABLEコマンドまたはALTER TABLEコマンドの列のデータ型は、元のPostgreSQL DATEデータ型のままで、そのままデータベースに格納されます。 PostgreSQLのDATEデータ型は、列に時間コンポーネントを含まない日付のみを格納します。edb_redwood_date の設定にかかわらず、 DATEがSPL宣言セクションの変数のデータ型やSPLプロシージャまたはSPL関数の仮パラメータのデータ型などの他のコンテキストのデータ型として表示されるか、 SPL関数の戻り型では、常に内部的にTIMESTAMP変換されるため、存在する場合は時間コンポーネントを処理できTIMESTAMP 。3.1.3.11.2 edb_redwood_greatest_leastパラメータタイプ:ブール値デフォルト値: true効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーGREATEST関数は、パラメータのリストから最大の価値を持つパラメータを返します。 LEAST関数は、パラメータのリストから最小の値を持つパラメータを返します。とき edb_redwood_greatest_leastに設定されているFALSE 、NULLのパラメータは、すべてのパラメータが関数によって返される場合はnullではNULLであるとき以外は無視されます。3.1.3.11.3 edb_redwood_raw_namesパラメータタイプ:ブール値デフォルト値: false効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザー場合 edb_redwood_raw_namesそのデフォルト値に設定されているFALSEレッドウッド・カタログから見たとき、等テーブル名、カラム名、トリガー名、プログラム名、ユーザ名、などのデータベース・オブジェクト名は、すなわち、接頭辞システムカタログである(大文字で表示されますALL_ 、 DBA_ 、またはUSER_ )。さらに、引用符は、囲み引用符で作成された名前を囲みます。場合 edb_redwood_raw_namesに設定されているTRUE 、データベース・オブジェクト名は、レッドウッド・カタログから見たとき、それらはPostgreSQLのシステムカタログに格納されているとおりに表示されています。したがって、引用符を囲まずに作成された名前は、PostgreSQLで期待どおり小文字で表示されます。囲み引用符で作成された名前は、作成されたとおりに正確に表示されますが、引用符は使用しません。reduser としてデータベースに接続すると、次の表が作成されます。レッドウッドのカタログから見た場合、 USER_TABLES 、とedb_redwood_raw_namesデフォルト値に設定FALSE 、名前が以外の大文字で表示されMixed_Case作成とも引用符を囲むと同じように表示される名前、。3.1.3.11.4 edb_redwood_stringsパラメータタイプ:ブール値デフォルト値: false効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザー場合 edb_redwood_stringsパラメータが設定されているTRUE 、文字列はヌル変数またはnullカラムと連結されている場合、結果は元の文字列です。 edb_redwood_stringsがFALSEに設定されていると、ネイティブのPostgreSQLの動作が維持されFALSE 。これは、文字列とnull変数またはnullカラムを連結するとnullの結果になります。サンプルアプリケーションには従業員のテーブルが含まれています。この表には、ほとんどの従業員にとってNULLであるcommという名前の列があります。次のクエリは、 edb_redwood_stringをFALSE設定して実行しFALSE 。ヌル列と空でない文字列を連結すると、最終的な結果がNULLになるため、コミッションを持つ従業員だけがクエリ結果に表示されます。他のすべての従業員の出力行はNULLです。以下は、 edb_redwood_stringsがTRUE設定されているときに実行される同じクエリです。ここでは、NULL列の値は空の文字列として扱われます。空の文字列を空でない文字列と連結すると、空でない文字列が生成されます。3.1.3.11.5 edb_stmt_level_txパラメータタイプ:ブール値デフォルト値: false効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザー文レベルのトランザクション分離 という用語は、SQLコマンドで実行時エラーが発生したときに、その単一のコマンドによって引き起こされたデータベース上のすべての更新をロールバックする動作を記述しています。たとえば、1つのUPDATEコマンドが5行を正常に更新するが、6行目を更新しようとすると例外が発生した場合、このUPDATEコマンドによって作成された6行すべての更新がロールバックされます。コミットまたはロールバックされていない以前のSQLコマンドの影響は、 COMMITコマンドまたはROLLBACKコマンドが実行されるまで保留されます。Advanced Serverでは、SQLコマンドの実行中に例外が発生した場合、トランザクションの開始以降、データベース上のすべての更新がロールバックされます。さらに、トランザクションは中止状態のままであり、別のトランザクションを開始する前にCOMMITまたはROLLBACKコマンドを発行する必要があります。edb_stmt_level_txがTRUEに設定されている場合 、例外は未コミットのデータベース更新を自動的にロールバックしません。 edb_stmt_level_txがFALSEに設定されているFALSE 、例外はコミットされていないデータベースの更新をロールバックします。次の例では、 edb_stmt_level_txがFALSE 、2番目のINSERTコマンドのアボートによって最初のINSERTコマンドがロールバックされることがPSQLで示されてい FALSE 。 PSQLでは、コマンド\set AUTOCOMMIT off発行\set AUTOCOMMIT off必要があります。そう\set AUTOCOMMIT offないと、すべての文が自動的にedb_stmt_level_txの効果のデモンストレーションの目的をedb_stmt_level_txます。次の例では、 edb_stmt_level_txをTRUEに設定して、2番目のINSERTコマンドで最初のINSERTコマンドがエラーの後にロールバックされていません。この時点で、最初のINSERTコマンドをコミットまたはロールバックできます。ROLLBACKコマンドが代わりに発行されている可能性がCOMMIT従業員番号の挿入、その場合には、コマンド9001同様にロールバックされていたであろう。3.1.3.11.6 db_dialectデフォルト値: postgres効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーネイティブのPostgreSQLシステムカタログ pg_catalogに加えて 、Advanced Serverには拡張カタログビューが含まれています。これは、拡張カタログ・ビューのsysカタログです。 db_dialectパラメーターは、これらのカタログが名前解決のために検索される順序を制御します。postgresに設定すると、名前空間の優先順位はpg_catalog 、次にsysになり、PostgreSQLカタログに最高の優先順位が与えられます。 redwoodに設定すると、名前空間の優先順位はsys 、次にpg_catalogになり、拡張カタログビューに最高の優先順位が与えられます。3.1.3.11.7 default_with_rowidsパラメータタイプ:ブール値デフォルト値: false効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザー3.1.3.11.8 optimizer_modeデフォルト値: choose効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザー
3.1.3.12 カスタマイズされたオプションAdvanced Serverの以前のリリースでは、通常、アドオンモジュール(手続き型言語など)によって追加されることが知られていないパラメータによってcustom_variable_classesが必要でした。3.1.3.12.1 custom_variable_classescustom_variable_classesパラメータは、Advanced Serverの9.2では推奨されていません。以前はこのパラメータに依存していたパラメータはもはやそのサポートを必要としません。3.1.3.12.2 dbms_alert.max_alertsデフォルト値: 100範囲: 0〜500効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントDBMS_ALERTSパッケージを使用して、システムで同時に許可されるアラートの最大数を指定します。3.1.3.12.3 dbms_pipe.total_message_bufferパラメータタイプ: 整数デフォルト値: 30 Kb範囲: 30 Kb〜256 Kb効果の最小範囲: クラスター値の変更が有効になった場合: 再起動有効化に必要な権限: EPASサービスアカウント3.1.3.12.4 index_advisor.enabledパラメータタイプ:ブール値デフォルト値: true効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーEDB-PSQLセッションまたはPSQLセッションでIndex Advisorを一時的に中断する機能を提供します。 index_advisor.enabled構成パラメーターを使用するには、 索引アドバイザー・プラグイン index_advisor EDB-PSQLまたはPSQLセッションにロードする必要があります。SETコマンドを使用して 、次の例に示すように、インデックスアドバイザが代替クエリプランを生成するかどうかを制御するようにパラメータ設定を変更します。3.1.3.12.5 edb_sql_protect.enabledパラメータタイプ:ブール値デフォルト値: false効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウントこれらのロールによって発行されたSQL文を解析し、 edb_sql_protect.level の設定に従って edb_sql_protect.level することによって、SQL / Protectが保護されたロールをアクティブに監視するかどうかを制御します 。 SQL / Protectで監視を開始する準備ができたら、このパラメーターをonに設定します。3.1.3.12.6 edb_sql_protect.levelデフォルト値: passive効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウントedb_sql_protect.level構成パラメータは、モード、受動モードまたはアクティブモードを使用するかについては、以下のいずれかの値に設定することができます。
• 学ぶ。保護された役割の活動を追跡し、役割によって使用される関係を記録する。これは、SQL / Protectを最初に構成して、保護されたアプリケーションの予想される動作を学習するときに使用されます。
• 受動的。保護されたロールが定義されたルールを破るが、SQLステートメントの実行を停止しない場合、警告を発行します。これは、SQL / Protectが保護された役割の予想される動作を学習した後の次のステップです。これは基本的に侵入検知モードで動作し、適切に監視されている場合は本番環境で実行できます。
• アクティブ。保護された役割のすべての無効なステートメントを停止します。これは、SQLファイアウォールとして動作し、危険なクエリの実行を防ぎます。これは、攻撃者がアプリケーションの背後にある脆弱点とデータベースの種類を判断しようとしている場合に、早期侵入テストに対して特に効果的です。 SQL / Protectはこれらの脆弱点を閉じるだけでなく、ブロックされたクエリを追跡して、攻撃者がシステムに侵入する別の方法を見つける前に管理者に警告することができます。3.1.3.12.7 edb_sql_protect.max_protected_relationsデフォルト値: 1024範囲: 1〜2147483647効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントedb_sql_protect.max_protected_relationsが有効範囲外の値(たとえば、2,147,483,648の値)に設定されているときにサーバーを起動すると 、警告メッセージがデータベース・サーバーのログ・ファイルに記録されます。データベースサーバーは正常に起動しますが、 edb_sql_protect.max_protected_relationsはデフォルト値の1024に設定されています。3.1.3.12.8 edb_sql_protect.max_protected_rolesデフォルト値: 64範囲: 1〜2147483647効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントすべての保護された役割は共有メモリ内の領域を消費します。サーバが保護された役割回数保護関係の数(のためのスペースを確保することに注意してください edb _ sql _ protect 。 max _ protected _ relations )。可能な最大保護ロールのスペースは、データベースサーバーの起動時に予約されます。edb_sql_protect.max_protected_rolesが有効な範囲外の値(たとえば、2,147,483,648の値)に設定されているときにデータベースサーバーが起動されると、データベースサーバーのログファイルに警告メッセージが記録されます。データベースサーバーは正常に起動しますが、 edb_sql_protect.max_protected_rolesはデフォルト値の64に設定されています。3.1.3.12.9 edb_sql_protect.max_queries_to_saveデフォルト値: 5000範囲: 100〜2147483647効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントedb_sql_protect.max_queries_to_saveが有効な範囲外の値(たとえば値10)に設定されているときにデータベース・サーバーが起動されると、警告メッセージがデータベース・サーバーのログ・ファイルに記録されます。データベースサーバーは正常に起動しますが、 edb_sql_protect.max_queries_to_saveがデフォルト値の5000に設定されています。3.1.3.12.10 edb_wait_states.directoryパラメータタイプ:文字列デフォルト値: edb_wait_states範囲:該当なし効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウントEDB待機状態のログファイルが格納されるディレクトリパスを設定します。指定されたパスは絶対パスであり、相対パスではありません。ただし、デフォルトの設定は edb_wait_states 、 $PGDATA/edb_wait_statesがデフォルトのディレクトリ位置になります。 EDB待機状態については、 8.2項を参照してください。3.1.3.12.11 edb_wait_states.retention_periodデフォルト値: 604800s範囲: 86400〜2147483647効果の最小範囲:クラスター有効化に必要な権限: EPASサービスアカウント3.1.3.12.12 edb_wait_states.sampling_intervalデフォルト値: 1s範囲: 1〜2147483647s効果の最小範囲:クラスター値の変更が反映されるとき:リロード有効化に必要な権限: EPASサービスアカウント3.1.3.12.13 edbldr.empty_csv_fieldデフォルト値: NULL効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーedbldr.empty_csv_fieldパラメータを使用して、 EDB * Loaderが空の文字列を処理する方法を指定します。 edbldr.empty_csv_fieldパラメーターの有効な値は次のedbldr.empty_csv_fieldです。
An empty field is treated as a if it does not contain quotes and as an empty string if it contains quotes. An empty field is treated as a NULL if it does not contain quotes and as an empty string if it contains quotes. An empty field is treated as a if it does not contain quotes and as an empty string if it contains quotes.詳細については edbldr.empty_csv_field EDB * Loaderの中のパラメータ、EnterpriseDBのウェブサイトでのOracle開発者ツールおよびユーティリティ・ガイドのためのデータベースの互換性を参照してください。3.1.3.12.14 utl_encode.uudecode_redwoodパラメータタイプ:ブール値デフォルト値: false効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーTRUEに設定すると 、Advanced ServerのUTL_ENCODE.UUDECODEファンクションは、 UTL_ENCODE.UUENCODEファンクションのOracle実装によって作成されたUTL_ENCODE.UUDECODE符号化データをデコードできます。デフォルト設定の FALSEに設定されている FALSE 、Advanced ServerのUTL_ENCODE.UUDECODEファンクションは、Advanced ServerのUTL_ENCODE.UUDECODEファンクションによって作成されたUTL_ENCODE.UUENCODEされたデータをデコードできます。3.1.3.12.15 utl_file.umaskパラメータタイプ:文字列デフォルト値: 0077範囲: umask設定の8進数効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーutl_file.umaskパラメータは、Linuxと同様に、 ファイルモード作成マスクあるいは単に、 マスクを設定umaskコマンド。これは、Advanced Server UTL_FILEパッケージ内でのみ使用できます。注: utl_file.umaskパラメーターは、Windowsシステムではサポートされていません。utl_file.umask 指定された値は、Linuxのumaskコマンドで有効な3文字または4文字の8進数の文字列です。この設定によって、 UTL_FILEファンクションおよびプロシージャによって作成されるファイルに対するパーミッションが決定されます。 (ファイル権限とumaskコマンドの使用法については、LinuxまたはUnixシステムに関する情報源を参照してください)。以下は、デフォルトの結果を示して utl_file.umaskすべての権限はに属するユーザに拒否されている0077.注の設定enterprisedbグループだけでなく、他のすべてのユーザーを。ユーザーenterprisedbのみがファイルに対する読み取りと書き込みの権限を持ちます。
3.1.3.13 グループ化されていない3.1.3.13.1 nls_length_semanticsデフォルト値: byte効果の最小スコープ:セッションごとアクティブ化に必要な権限:スーパーユーザ注意:このパラメータの設定はサーバ環境には影響しないため、システムビューpg_settingsは表示されません。3.1.3.13.2 query_rewrite_enabledデフォルト値: false効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザーたとえば、次の形式の ALTER SESSIONコマンドは、構文エラーを投げずにAdvanced Serverで受け入れられますが、セッション環境は変更されません。注意:このパラメータの設定はサーバ環境には影響しないため、システムビューpg_settingsは表示されません。3.1.3.13.3 query_rewrite_integrityデフォルト値: enforced効果の最小スコープ:セッションごとアクティブ化に必要な権限:スーパーユーザたとえば、次の形式の ALTER SESSIONコマンドは、構文エラーを投げずにAdvanced Serverで受け入れられますが、セッション環境は変更されません。注意:このパラメータの設定はサーバ環境には影響しないため、システムビューpg_settingsは表示されません。3.1.3.13.4 timed_statisticsパラメータタイプ:ブール値デフォルト値: true効果の最小スコープ:セッションごとアクティブ化に必要な承認:セッションユーザー注意: Advanced Serverがインストールされている場合、 postgresql.confファイルにはtimed_statisticsをoffに設定した明示的なエントリが含まれています。 timed_statisticsをデフォルトに設定してこのエントリをコメントアウトし、設定ファイルをリロードすると、定期的な統計収集が有効になります。
3.2 索引アドバイザーIndex Advisorは、Advanced Serverのクエリプランナと連携して、クエリプランナが実行コストを計算するために使用する 仮 インデックスを作成します。索引アドバイザーは、ワークロードで提供されるSQL照会を分析して索引を識別します。
• 索引アドバイザー・ユーティリティー・プログラムを呼び出して、分析したいSQL照会を含むテキスト・ファイルを提供します。索引アドバイザーは 、推奨索引のCREATE INDEXステートメントを使用してテキスト・ファイルを生成します。
• 索引アドバイザーは、 INSERT 、 UPDATE 、 DELETEおよびSELECTステートメントで索引付けの推奨を行います。索引アドバイザーを呼び出すときは、一連の照会(SQLファイルでコマンドを提供する場合)またはEXPLAINステートメント(psqlコマンド行でSQLステートメントを指定する場合)の形式でワークロードを提供します。索引アドバイザーは、提供された照会の照会計画および推定実行コストを表示しますが、照会を実際には実行しません。分析中、索引アドバイザーは、照会実行コストを仮想索引の有無と比較します。仮説索引を使用した実行コストが実行コスト未満であれば、両方の計画が EXPLAINステートメント出力に報告され 、改善を定量化するメトリックが計算され、索引アドバイザーがINDEX作成に必要なCREATE INDEXステートメントを生成します。3.2.1 索引アドバイザー・コンポーネント索引アドバイザー共有ライブラリーは、索引付け推奨を行うために照会プランナーと対話します。 Windowsの場合、Advanced Serverインストーラは、 Advanced Serverホームディレクトリのlibdirサブディレクトリに次の共有ライブラリを作成します 。 Linuxの場合、インストールedb-as xx -server-indexadvisor RPMパッケージxx Advanced Serverのバージョン番号です。libdirディレクトリにあるライブラリは、スーパーユーザだけが読み込むことができます。データベース管理者は、インデックス・アドバイザ・ファイルをlibdirディレクトリからlibdir/pluginsディレクトリ(Advanced Serverホーム・ディレクトリの下)に手動でコピーすることにより、スーパー・ユーザー以外のユーザーが索引アドバイザーを使用できるようにすることができます。信頼できる非スーパーユーザーにのみ、プラグインへのアクセスを許可する必要があります。これは実稼働環境では安全ではない方法です。pg_advise_indexは、SQL照会を含むユーザー提供の入力ファイルを読み取り、索引アドバイザーが推奨する索引の作成に使用できるCREATE INDEXステートメントを含むテキスト・ファイルを作成するユーティリティー・プログラムです。 pg_advise_indexプログラムは、Advanced Serverホームディレクトリのbinサブディレクトリにあります。index_advisor.sqlは、永続的な索引アドバイザー・ログ表を作成し、ログ表からの推奨事項の報告を容易にするための関数およびビューを作成するスクリプトです。このスクリプトは、Advanced Serverディレクトリのshare/contribサブディレクトリにあります。index_advisor.sqlスクリプトが作成index_advisor_logテーブル、 show_index_recommendations()関数とindex_recommendationsビューを。これらのデータベース・オブジェクトは、Index Advisorを呼び出すロールの検索パスにアクセスできるスキーマに作成する必要があります。索引アドバイザーは、索引の推奨事項を index_advisor_log表にindex_advisor_logます。索引アドバイザーがユーザーの検索パスでindex_advisor_log表を見つけられない場合、索引アドバイザーは同じ名前の一時表に索引推奨を保管します。一時テーブルは、現在のセッションの期間だけ存在します。show_index_recommendations()は、特定の索引アドバイザー・セッション中に行われた推奨事項(バックエンド・プロセスIDによって識別される)を解釈して表示するPL / pgSQL関数です。索引アドバイザーは、照会分析中にindex_advisor_log表に保管された情報に基づいて、 index_recommendationsビューを作成します。このビューは、 show_index_recommendations()関数と同じ形式で出力を生成しますが、すべての格納されたセッションに対するIndex Advisorの推奨事項を含んでいますが、 show_index_recommendations()関数によって返される結果セットは指定されたセッションに制限されます。3.2.2 索引アドバイザーの構成索引アドバイザーは、現行セッションの間だけ使用可能な推奨事項を生成するための構成を必要としません。複数のセッションの結果を格納するには、 index_advisor_log表(Advanced Serverで索引アドバイザーの推奨事項が格納される)を作成する必要があります 。 index_advisor_log表を作成するには、 index_advisor.sqlスクリプトを実行する必要があります。索引アドバイザー・テーブル、関数、およびビューのストレージ・スキーマを選択するときは、索引アドバイザーを呼び出す(および結果セットを照会する)すべてのユーザーがスキーマに対して USAGE特権を持っている必要があることに注意してください。スキーマは、索引アドバイザーと対話しているすべてのユーザーの検索パスになければなりません。advisor という名前のスキーマに索引アドバイザー・オブジェクトを作成するには、次のコマンドを使用します。
2。 index_advisor.sqlスクリプトを実行して、データベース・オブジェクトを作成します。 psqlクライアントを実行している場合は、次のコマンドを使用できます。
3。
•
•
• 次の例では、 ia という名前のスキーマに索引アドバイザー・データベース・オブジェクトを作成する方法を示します。このスキーマに ia 、ユーザー名ia_user持つ索引アドバイザー・ユーザーがアクセスできるようになります。
3.2.3 索引アドバイザーの使用索引アドバイザーを呼び出すときは、ワークロードを提供する必要があります。ワークロードは、クエリ(コマンドラインで指定されたもの)またはクエリのセット( pg_advise_index()関数によって実行されるもの) を含むファイルです 。ワークロードを分析した後、索引アドバイザーは、結果セットを一時表または永続表に保管します。索引アドバイザーによって生成された索引推奨事項を確認し、索引アドバイザーによって生成されたCREATE INDEXステートメントを使用して、推奨索引を作成することができます。次の例では、スーパーユーザー enterprisedbが索引アドバイザー・ユーザーであり、索引アドバイザー・データベース・オブジェクトがスーパーユーザーenterprisedb search_path内のスキーマに作成されていると想定しています 。CREATE TABLE t( a INT, b INT );
INSERT INTO t SELECT s, 99999 - s FROM generate_series(0,99999) AS s;呼び出すとき pg_advise_indexユーティリティを、次の方法で実行されるクエリが含まれるファイルの名前を含める必要がありますpg_advise_index 。クエリは同じ行にあっても、別々の行にあっても構いませんが、各クエリはセミコロンで終了する必要があります。ファイル内の照会は、 EXPLAINキーワードで始めるべきではありません。-sは、索引アドバイザーが推奨する索引の最大サイズを制限するオプションのパラメーターです。索引アドバイザーが結果セットを戻さない場合、 -sが小さすぎる可能性があります。pg_advise_indexプログラムによって表示される情報は、 index_advisor_logテーブルに記録されます。この例に示すコマンドに応答して、索引アドバイザーは次のCREATE INDEXステートメントをadvisory.sql出力ファイルに書き込みます3.2.3.2 psqlコマンドラインでのIndex Advisorの使用
1。 edb-psqlコマンドラインユーティリティを使用してサーバーに接続し、 Index Advisorプラグインをロードします。
2。 edb-psqlコマンド行を使用して、索引アドバイザーが分析する各SQLコマンドを呼び出します。索引アドバイザーは、照会の推奨事項をindex_advisor_log表にindex_advisor_logます。 index_advisor_logテーブルがユーザのsearch_path存在しない場合は、同じ名前のテンポラリテーブルが作成されます。この一時テーブルは、ユーザーのセッションの間だけ存在します。ステートメントを EXPLAINキーワードのindex_advisor_log ないと 、索引アドバイザーはステートメントの実行中にステートメントを分析し、後で検討するために索引推奨事項をindex_advisor_log表にindex_advisor_logます。次の例では、 EXPLAIN文は、クエリが推奨された仮想インデックスを使用していた場合、通常のクエリプランと、同じクエリのクエリプランを表示します。Index Advisorプラグインをロードすると、 index_advisor.enabled のデフォルト値がonます。 index_advisor.enabled現在の値を表示するには、 SETまたはSHOWコマンドを使用するために索引アドバイザー・プラグインをロードする必要があります。
3.2.4 索引アドバイザーの推奨事項の確認
• index_advisor_logテーブルを照会します。
• show_index_recommendations関数を実行します。
• index_recommendationsビューを照会します。show_index_recommendations()関数を使用してIndex Advisorユーティリティの推奨事項を確認するには、セッションのプロセスIDを指定して関数を呼び出します。この例では、 t(a) on create index idx_t_aは、Index Advisorによって提案された索引を作成するために必要なSQLステートメントです。結果セットの各行には次の情報が表示されます。索引アドバイザーは、索引推奨事項を index_advisor_log という名前の表に index_advisor_logます。 index_advisor_log表の各行には、索引アドバイザーが仮想索引を推奨してその照会の実行コストを削減できると判断した照会の結果が入っています。
psqlコマンドラインでindex_advisor_logテーブルを問い合わせることができます 。次の例は、2つの索引アドバイザー・セッションに起因するindex_advisor_log表の項目を示しています。各セッションには2つのクエリが含まれており、異なるbackend_pid値で識別できます(下の表を参照)。各セッションについて、索引アドバイザーは2つの索引推奨を生成しました。index_advisor_logテーブルのbenefitカラムの値は 、次の式を使用して計算されます。3.2.4.3 index_recommendationsビューのクエリindex_recommendationsビューは、計算されたメトリックが含まれており、 CREATE INDEXその結果に現在あるすべてのセッションのために推奨されるインデックスを作成するためのステートメントをindex_advisor_logテーブル。格納されているすべてのIndex Advisorセッションの結果を表示するには、 index_recommendationsビューを次のように照会します。各セッション内で、同じ推奨インデックスから恩恵を受けるすべてのクエリの結果を組み合わせて、推奨インデックスごとに1セットのメトリックを作成します 。これは、 benefitおよびgain というフィールドに反映されます 。3.2.5 制限事項復元 pg_dump含むバックアップファイルindex_advisor_logテーブルまたはインデックス作成の推奨がなさに記憶されたため、任意のテーブルindex_advisor_log間の「リンク切れ」をもたらすことができるテーブル、 index_advisor_logの行によって参照されるテーブルと復元テーブルindex_advisor_logテーブルためにオブジェクト識別子(OID)の変更について説明します。バックアップの前に推奨事項を表示する必要がある場合は 、SQL UPDATE文を使用して、 index_advisor_log表のreloid列の古い OIDを、参照先表の新しいOIDに置き換えることができます。
3.3 SQLプロファイラ非効率的なSQLコードは、データベースのパフォーマンス問題の主な原因ではないにしても、その1つです。データベース管理者と開発者の課題は、大規模で複雑なシステムでこのコードを見つけて最適化することです。SQLプロファイラは、実行中のSQLコードを見つけて最適化するのに役立ちます。
• オンデマンドトレース。手動でパラメータを設定し、トレースを開始することで、いつでもSQLトレースを取得できます。
• スケジュールされたトレース。不都合な場合は、トレースパラメータを指定して後で実行するようにスケジュールすることもできます。
• トレースを保存します。トレースを実行し、後で見直すために保存します。
• トレースフィルタ。 SQLキャプチャをデータベースおよびユーザーごとに選択してフィルタ処理するか、またはすべてのユーザーがすべてのデータベースに対して送信したすべてのSQL文を取得します。
• トレース出力アナライザ。グラフィカル・テーブルを使用すると、期間または文で問合せをすばやくソートしてフィルタ処理でき、グラフィカルまたはテキストベースのEXPLAINプランによって、クエリ・パスとジョインがレイアウトされます。
• 索引アドバイザーの統合。低速の問合せを見つけて最適化したら、索引アドバイザーが基礎となる表索引の作成を推奨して、パフォーマンスをさらに向上させることもできます。手順1: SQLプロファイラをインストールするSQLプロファイラは、Windows上のAdvanced Serverインストーラまたは Linux上の edb-as xx -server-sqlprofiler RPMパッケージ( xxはAdvanced Serverバージョン番号) からインストールされます 。手順2: SQLプロファイラライブラリを追加する手順3: SQLプロファイラで使用する関数を作成するpsqlコマンドラインインタフェースを使用して、 sql-profiler.sqlするサーバのメンテナンスデータベースとして指定されたデータベースでsql-profiler.sqlスクリプトを実行します。 Advanced Serverを使用している場合、デフォルトの保守データベースの名前はedbです。 PostgreSQLインスタンスを使用している場合、デフォルトのメンテナンスデータベースの名前はpostgresです。手順4:サーバーを停止して再起動し、変更を有効にします。このエラーを修正するには、既存のクエリセットを新しいクエリセットに置き換える必要があります。まず、起動することによって、SQLプロファイラをアンインストールし uninstall-sql-profiler.sqlスクリプトを、次に起動することによって、SQLプロファイラを再インストールしsql-profiler.sqlスクリプトを。
3.4 pgsnmpdpgsnmpdは、Linuxシステム上のAdvanced Serverの現在の状態に関する階層情報を返すことができるSNMPエージェントです。 pgsnmpdはedb-as xx -pgsnmpd RPMパッケージを使用して配布され、インストールされます。ここで、 xxはAdvanced Serverのバージョン番号です。 pgsnmpdエージェントは、スタンドアロンSNMPエージェント、パススルーサブエージェント、またはAgentXサブエージェントとして動作できます。このコマンドは、 LD_LIBRARY_PATH の値を永続的に変更しません 。 LD_LIBRARY_PATHの値を永続的に設定する方法については、Linuxディストリビューションのドキュメントを参照してください。以下の例は、 pgsnmpd の最も単純な使い方を pgsnmpd 、読み取り専用アクセスを実装しています。 pgsnmpdはnet-snmpライブラリに基づいています。 net-snmpの詳細については、次のサイトを参照してください。3.4.1 pgsnmpdの設定pgsnmpd設定ファイルの名前はsnmpd.conf 。設定ファイルで指定できるディレクティブについては、 snmpd.conf manページ( man snmpd.conf )を参照してください。設定ファイルは手作業で作成することも、 snmpconf perlスクリプトを使って設定ファイルを作成することもできます。 perlスクリプトはnet-snmpパッケージとともに配布されています。snmpconfはメニュー駆動のウィザードです。メニュー項目1: snmpd.confを選択して設定ウィザードを開始します。 snmpconfで表示される各トップレベルメニューオプションを選択すると、ウィザードで一連の質問が表示され、設定ファイルのビルドに必要な情報が表示されます。ご使用のシステムに関連するカテゴリーごとに情報を入力したら、 Finishedを入力してsnmpd.confという名前の構成ファイルを生成します。ファイルを次の場所にコピーします。3.4.2 リスナー・アドレスの設定snmpd.confファイルに次の行を追加することによって、代替リスナー・ポートを指定することができます 。agentaddress $host_address :20003.4.3 pgsnmpdの呼び出しAdvanced Serverのインスタンスが稼働していることを確認します( pgsnmpdはこのサーバーに接続します)。次の形式のコマンドを使用してpgsnmpdを呼び出す前に、コマンドラインを開いてスーパーユーザー権限を引き受けます。POSTGRES_INSTALL_HOME /bin/pgsnmpd -b-c POSTGRES_INSTALL_HOME /share/snmpd.confどこ POSTGRES_INSTALL_HOME Advanced Serverのインストールディレクトリを指定します。3.4.4 pgsnmpdヘルプの表示3.4.5 pgsnmpdからの情報の要求-v 2cオプションは、SNMPバージョン2c形式で要求を送信するようにsnmpgetnextクライアントに指示します。-c publicコミュニティ名を指定します。localhostは、 pgsnmpdサーバーを実行するホストマシンを示します。.1.3.6.1.4.1.5432.1.4.2.1.1.0は、要求されたオブジェクトの識別情報です。すべてのデータベースのリストを表示するには、最後の数字を1だけ増やします(たとえば、1.1、.1.2、.1.3など)。
3.5 EDB監査ロギングAdvanced Serverを使用すると、データベース管理者、監査者、およびオペレータは、 EDB監査ログ機能を使用して、データベースアクティビティを追跡および分析できます 。 EDB監査ログは、すべての関連情報を含む監査ログファイルを生成します。監査ログは、次のような情報を記録するように構成できます。3.5.1 監査ログ設定パラメータデータベース監査を制御するには、次の構成パラメータを使用します。 3.1.2 項を参照して、構成パラメータへの変更がすぐに有効になるか、構成を再ロードする必要があるか、またはデータベース・サーバーを再起動する必要があるかどうかを確認してください。データベース監査を有効または無効にします。値 xmlまたはcsvは、データベース監査を有効にします。これらの値は、監査情報が取り込まれるファイル形式を表します。 noneはデータベース監査を無効にし、デフォルトでもあります。ログファイルを作成するディレクトリを指定します。ディレクトリのパスは、データフォルダの相対パスまたは絶対パスにすることができます。デフォルトは、 PGDATA/edb_auditディレクトリです。監査情報が格納される監査ファイルのファイル名を指定します。デフォルトのファイル名は audit-%Y%m%d_%H%M%Sです。エスケープシーケンス%Y 、 %mなどは、システムの日付と時刻に従って適切な現在の値に置き換えられます。監査ファイルをローテーションする曜日を指定します。有効な値は、 sun 、 mon 、 tue 、 wed 、 thu 、 fri 、 sat 、 every 、およびnoneです。回転を無効にするには、値をnone設定します。ファイルを毎日ローテーションするには、 edb_audit_rotation_day値をevery設定しevery 。特定の曜日にファイルを回転するには、値を希望の曜日に設定します。 everyがデフォルト値です。ユーザーによるデータベース接続試行の監査を有効にします。すべての接続試行の監査を無効にするには、 edb_audit_connectをnone に設定します。失敗したすべての接続試行を監査するには、値をfailedに設定します。これがデフォルトです。すべての接続試行を監査するには、値をall設定します。この構成パラメーターは、さまざまなカテゴリーのSQLステートメントの監査を指定するために使用されます。 none 、 dml 、 insert 、 update 、 delete 、 truncate 、 select 、 error 、 rollback 、 ddl 、 create 、 drop 、 alter 、 grant 、 revoke 、およびall さまざまな組み合わせを指定できます 。デフォルトはddlとerrorです。このパラメータの設定については、 3.5.2項を参照してください。一括処理は、結果のステートメントをAdvanced ServerログファイルとEDB監査ログファイルの両方に記録します。しかし、一括処理における各ステートメントのロギングにはコストがかかります。これは、 edb_log_every_bulk_value構成パラメーターによって制御することができます。 trueに設定すると、一括処理のすべてのステートメントがログに記録されます。 falseに設定するfalse 、一括処理ごとにログメッセージが1回記録されます。さらに、持続時間は一括処理ごとに1回発行されます。デフォルトはfalseです。監査ログ情報を edb_audit_directoryパラメータで指定されたディレクトリに記録するか、 syslogプロセスで管理されているディレクトリとファイルにedb_audit_directoryするかを指定します。デフォルトの設定であるedb_audit_directoryで指定されたディレクトリを使用するようにfileに設定しfile 。設定syslogに設定されたsyslogプロセスとその場所を使用し/etc/syslog.confファイル。 注:最近のLinuxバージョンでは、syslogがrsyslogのに置き換えられていると設定ファイルがである/etc/rsyslog.conf 。3.5.2 監査するSQL文の選択edb_audit_statementステートメントが監査されるべきSQLを制御するための1つ以上、カンマ区切り値の包含を可能にします。一般的な形式は次のとおりです。
• all - ステートメントのエラーメッセージを含む、すべてのステートメントの監査とロギングを行います。
• none - すべての監査とロギングを無効にします。 noneの値は、リストに含まれる他の値を上書きします。
•
•
• select - SELECTステートメントの監査を行います。
•
• error - 発生したすべてのエラーメッセージのログを記録します。 error値が含まれていないかぎり、 allが使用されている場合を除いて、前述の他のパラメータ値に関連するSQL文で発生するエラーに関するエラー・メッセージは記録されません。サポートされていない値が edb_audit_statementパラメーターに含まれている場合は 、データベース・サーバーに設定を適用するときにエラーが発生します。 create materialized vwれたcreate materialized vwでエラーが発生create materialized vw次の例のようなエラーについては、データベースサーバーのログファイルを参照してください。 (正しい値はcreate materialized viewです。)3.5.2.1 データ定義言語およびデータ制御言語文
• edb_audit_statementパラメーターにddlまたはall含まれている場合は 、すべてのDDLステートメントが監査されます。さらに、DCLステートメントGRANTおよびREVOKEも監査されます。
•
• edb_audit_statementパラメーター内に値の組み合わせを含めることにより、監査用に特定のタイプのDDLステートメントとDCLステートメントを選択できます。DDL文のedb_audit_statementパラメータ値を指定するには、次の構文を使用します 。{ create | alter | drop } [ object_type ]object_typeは次のいずれかです。DCL文のedb_audit_statementパラメータ値を指定するには、次の構文を使用します 。adminuserロールおよびauditdbデータベースの CREATEおよびALTERステートメントが監査されます。エラーがedb_audit_statementパラメーターに含まれているため、 ALTER ROLE adminuserステートメントのエラーも記録されます。正常に処理されたDROPステートメント( ddl 、 all 、またはdropなど)の監査にedb_audit_statement設定がないため、 DROP TABLE departmentステートメントは監査ログにはないことに注意してください 。CREATE VIEWおよびCREATE MATERIALIZED VIEW文が監査されます。以前のCREATE TABLE empステートメントは、 create 、 create table 、 ddl 、またはallがedb_audit_statementパラメーターに含まれていないので、監査されないことに注意してください。CREATE SEQUENCEとGRANT文は、それらの値が含まれているため監査されedb_audit_statementパラメータ。3.5.2.2 データ操作言語ステートメント
•
•
• したがって、 UPDATEおよびDELETEコマンドによって呼び出されたSQL文だけが監査されます。すべてのエラーは、監査ログにも含まれます( UPDATEおよびDELETEコマンドに関連しないエラーでさえも)。UPDATE deptとDELETE FROM empステートメントが監査されます。以前のINSERTステートメントはall 、 edb_audit_statementパラメーターにinsert 、 dml 、またはall値が含まれていないため、監査されないことに注意してください。SELECT * FROM dept文はどちら以来、同様に監査されていないselectもall含まれedb_audit_statementパラメータ。以来 errorで指定されたedb_audit_statementパラメータではなく、 truncate値を、上のエラーTRUNCATE employee文は成功した監査ファイルに記録していないが、 TRUNCATE emp声明を。3.5.3 監査ログの有効化
1。
2。
3。
4。
5。 edb_audit_statementパラメータによって制御されて監査される文のタイプは 、使用中のデータベースおよびセッションを実行するデータベース・ロールに従ってさらに洗練されます。
• edb_audit_statementパラメータを持つ指定されたデータベースの属性として設定することができますALTER DATABASE dbname SET edb_audit_statementコマンド。この設定は、データベースdbnameに接続したときに実行されるステートメントの構成ファイルのedb_audit_statementパラメーターをオーバーライドします。
• edb_audit_statementパラメータを持つ指定されたロールの属性として設定することができますALTER ROLE rolename SET edb_audit_statementコマンド。この設定は、構成ファイル内のedb_audit_statementパラメータと、指定されたロールが現在のセッションを実行しているときに前述のALTER DATABASEコマンドによってデータベースに割り当てられた設定を上書きします。
• edb_audit_statementで指定されたデータベースを使用するときにパラメータが指定されたロールの属性として設定することができますALTER ROLE rolename IN DATABASE dbname SET edb_audit_statementコマンド。この設定は、構成ファイル内のedb_audit_statementパラメーターと、前述のALTER DATABASEコマンドによってデータベースに割り当てられた設定と、前述のIN DATABASE節なしでALTER ROLEコマンドを使用して役割に割り当てられたすべての設定をオーバーライドします。edb_audit_statementパラメータの次の設定でデータベースとロールが確立されます。
•
•
• 次の監査ログファイルには、 CREATE TABLE 、 INSERT INTO audit_tbl 、およびUPDATE audit_tblステートメントのエントリのみが表示されます 。 SELECT * FROM audit_tblおよびTRUNCATE audit_tbl文は監査されませんでした。監査ログファイルの続きが次のように表示されます。 2番目のケースを表す最後の2つのエントリは、 SELECT * FROM edb_tblおよびTRUNCATE edb_tbl文だけを示します。 CREATE TABLE edb_tblおよびINSERT INTO edb_tblステートメントは監査されませんでした。監査ログファイルの続きが次のように表示されます。 3番目のケースを表す最後の2つのエントリの次に、 CREATE TABLE audit_tbl_2とINSERT INTO audit_tbl_2ステートメントのみが表示されます。 SELECT * FROM audit_tbl_2およびTRUNCATE audit_tbl_2ステートメントは監査されませんでした。3.5.4 監査ログファイルedb_audit構成パラメーターの設定に応じて、監査ログ・ファイルをCSVまたはXML形式で生成することができます。 XML形式には、CSV形式よりも少ない情報が含まれています。
• フィールド。前に参照したPostgreSQLドキュメントのサンプルテーブル定義に示されているフィールドの名前。
•
• データ・タイプ。 PostgreSQLサンプルテーブル定義によって与えられたフィールドのデータ型。
• 説明。フィールドの説明。特定のフィールドでは、監査ログで出力が生成されないため、これらのフィールドは監査でサポートされていません。これらのフィールドは「サポートされていません」と表示されます。
Statement severity. Values are for audited statements and Statement severity. Values are AUDIT for audited statements and for any resulting error messages. ERROR for any resulting error messages. parameter in the configuration file. audit_tag parameter in the configuration file. Value specified by the parameter in the configuration file.postgresql.confファイルのデフォルト以外の監査設定は、次のとおりです。edb_auditパラメータを次のように変更されたxml XMLフォーマットを生成するとき。3.5.5 エラー・コードを使用した監査ログのフィルタリングAdvanced Serverには、ユーザー指定のエラーコードを含むログファイルエントリをAdvanced Serverログファイルから除外するために使用できる拡張機能が含まれています。監査ログエントリをフィルタリングするには、まず postgresql 変更して拡張機能を有効にする必要があります 。 confファイルで、 shared _ preload _ librariesパラメータで指定された値に次の値を追加します。どこ error_code 、ログファイルから省略したい1つ以上のエラー・コードを指定します。複数のエラーコードをカンマ区切りリストで指定します。例えば、場合 edb _ filter _ log有効になっている、とedb _ filter _ log 。 errcodeは'23505,23502,22012'設定され、次のいずれかのSQLSTATEエラーを返すログ・エントリーがあります。23505 (ユニーク制約に違反するため)23502 (非null制約に違反するため)22012 (ゼロで割るため)3.5.6 コマンド・タグを使用した監査ログのフィルタリング以下は、CSV形式の同じ例です。コマンドタグは、各エントリの最後の列の次のものです。 (最後の列は ""と表示され、 edb_audit_tagパラメータで指定された値にedb_audit_tagます)。3.5.7 監査ログからのパスワードの修正edb _ filter _ log 使用することができ log 。 redact _ password _ commands拡張子を使用して、ログファイルから保存されたパスワードを変更するようサーバーに指示します。モジュールは次の構文のみを認識することに注意してください。{CREATE|ALTER} {USER|ROLE|GROUP} identifier { [WITH] [ENCRYPTED] PASSWORD 'nonempty _ string _ literal' | IDENTIFIED BY { 'nonempty _ string _ literal' | bareword } } [ REPLACE { 'nonempty _ string _ literal' | bareword } ]パスワードの変更を有効にするには、まず postgresql 変更して拡張機能を有効にする必要があります 。 confファイルで、 shared _ preload _ librariesパラメータで指定された値に次の値を追加します。
3.6 Unicode照合アルゴリズムUnicode照合アルゴリズム (UCA)は、照合およびUnicodeデータを比較するカスタマイズ可能な方法を定義する仕様( ユニコードテクニカルレポート#10)です。 照合とは、 SELECT … ORDER BY節のようにデータがどのようにソートされるかを意味します。 比較は、演算子がより小さい、より大きい、または等しい演算子を持つ範囲を使用する検索に関連します。注意:さらに、ICU照合(Unicode照合アルゴリズムの実装)を使用するもう1つの利点は、パフォーマンスのためです。 Bツリーインデックスの作成を含むソートタスクは、ICU以外の照合に要する時間の半分以下で完了することができます。パフォーマンスの向上は、オペレーティングシステムのバージョン、テキストデータの言語、およびその他の要因によって異なります。
3.6.1 基本的なUnicode照合アルゴリズムの概念
• レベル1 - ベースキャラクタのプライマリレベル。文字や数字などの基本文字の順番によって、 A < Bなどの違いが決まります。
• レベル2 - アクセントのセカンダリレベル。主要なレベルの違いがない場合、アクセントやその他の文字の有無によって、 a < áなどの順序が決まります。
• レベル3 - ケースの第3レベル。プライマリレベルまたはセカンダリレベルの違いがない場合、大文字と小文字の違いによってa < Aなどの順序が決まります。
• レベル4 - 句読点のための第4レベル。 1次、2次、3次のレベル差がない場合、空白文字、制御文字、および句読点の有無により、 -A < Aなどの順序が決まります。
• レベル5 - タイブレークのための同一レベル。第1、第2、第3、または第4レベル差がない場合、コードポイント値などの他の相違によって順序が決定されます。
3.6.2 Unicodeのための国際コンポーネントUnicode照合アルゴリズムは、 International Components for Unicode (ICU)が提供するオープンソースソフトウェアによって実装されています 。このソフトウェアは、C / C ++およびJavaライブラリのセットです。3.6.2.1 ロケールの照合順序システムカタログ pg_catalog.pg_icu_collate_namesは、ロケールのICU短縮形の名前のリストが含まれています。 ICU短縮形名はicu_short_form列にリストされています。3.6.2.2 照合属性ICU照合を作成する場合、照合の望ましい特性を指定する必要があります。セクション 3.6.2.1で説明したように 、これは通常、目的のロケールのICU短縮形式で実行できます。ただし、より具体的な情報が必要な場合は、 照合属性を使用して照合プロパティの指定を行うことができます 。各照合属性は、大文字で表され、次の箇条書きのポイントにリストされています。各属性の可能な有効値は、カッコ内に示されたコードによって与えられます。コードによっては、すべての属性に一般的な意味があります。 Xは属性をオフにすることを意味します。 Oは属性をオンにすることを意味します。 Dは属性をデフォルト値に設定することを意味します。
• A - 代替(N、S、D)。空白、句読点、記号などの可変文字の処理を処理します 。無視できない(N)に設定すると、可変文字の違いは文字の違いと同じ重要性で扱われます。シフト(S)に設定すると、可変文字の違いは重要ではありません(つまり、可変文字は基本文字の比較時に無視されます)。
• C - ケースファースト(X、L、U、D)。小文字が同じ大文字(L)の前にソートされるか、大文字が同じ小文字(U)の前にソートされるかを制御します。消灯(X)は、通常小文字の最初(L)が必要な場合に指定されます。
• E - ケースレベル(X、O、D)。 Strength属性と組み合わせて設定すると、アクセントを無視するが大文字小文字を区別しない場合は、大文字小文字のレベル属性が使用されます。
• F - フランス語照合(X、O、D)。オンに設定すると、フランス語のカナダロケールで行われているように、二次的な違い(アクセントの存在)がストリングの後ろからソートされます。
• H - ひらがな第四紀(X、O、D)。日本語文字列のJIS X 4061照合との互換性のため、ひらがなとカタカナの文字を区別するための追加レベルを導入しました。
• N - 正規化チェック(X、O、D)。比較のためにテキストを完全に正規化するかどうかを制御します。正規化は、異なるコードポイントシーケンスが同じ文字を表すテキストの標準的な等価性の問題を扱い、その文字をソートまたは比較する際に問題を提示する。アラビア語、古代ギリシア語、ヘブライ語、ヒンディー語、タイ語、ベトナム語などの言語は、正規化チェックをオンに設定して使用する必要があります。
• S - 強さ(1、2、3、4、I、D)。比較に使用される照合レベルの最大値。文字列を照合または比較するときにアクセントまたは大文字小文字を使用するかどうかに影響します。各数字はレベルを表します。 Iの設定は、同じ強さ(すなわち、レベル5)を表します。
• T - 変数トップ(16進数)。代替属性が無視できない値(N)に設定されていない場合にのみ適用されます。 16進数は、無視できると見なされる最も高い文字シーケンスを指定します。たとえば、空白を無視できるようにするには、表示可能な変数の文字を無視できないようにするには、Variable Topを0020に設定し、Alternate属性をSに設定し、Strength属性を3に設定します。バックスペース、タブ、改行、改行などの他の目立たない可変文字は、0020より小さい値を有する。すべての見える句読点は、0020より大きい値を有する。前の例では、代替属性( A )は無視できない( N )に設定されています。ケースファースト属性( C )はオフ( X )に設定されています。ケースレベル属性( E )はオフ( X )に設定されています。正規化属性( N )はオン( O )に設定されます。強度属性( S )は、第3レベル3設定されます。 LROOTは、これらの他の属性が変更を適用しているICU短縮形式です。
3.6.3 ICUの照合順序の作成
• initdbコマンドで新しいデータベースクラスタを作成する場合 、クラスタ内のすべてのデータベースでデフォルトで使用されるICU照合を定義するために、 --icu-short-formオプションを指定できます。
• CREATE DATABASEコマンドを使用して新しいデータベースを作成する場合 、 ICU_SHORT_FORMパラメーターを指定して、そのデータベースでデフォルトで使用されるICU照合を定義することができます。
• 既存のデータベースでは、 CREATE COLLATIONコマンドをICU_SHORT_FORMパラメータとともに使用して、特定のテーブルの選択されたカラムにCOLLATE句を割り当てた場合やCOLLATE句を追加した場合など、特定の状況下で使用するICU照合を定義することができます。 ORDER BY expr COLLATE " collation_name "などの式。3.6.3.1 COLLATIONの作成CREATE COLLATIONコマンドの一般的な使用方法については 、次のURLにあるPostgreSQLのコアドキュメントを参照してください。照合属性とその設定を指定するテキスト文字列。これは、通常、追加の照合属性と値のペアが付加されたICUショートフォーム名で構成されます。 ICU短縮形名のリストは 、システムカタログpg_catalog.pg_icu_collate_names 列 icu_short_form から入手でき pg_catalog.pg_icu_collate_names 。3.6.3.2 CREATE DATABASEをCREATE DATABASE database_nameCREATE DATABASEコマンドの一般的な使用法、構文、およびパラメータの詳細については、次のURLにあるPostgreSQLのコアドキュメントを参照してください。使用する際に CREATE DATABASE ICU照合を使用してデータベースを作成するコマンドを、 TEMPLATE template0句を指定する必要があり、データベースのエンコーディングはUTF-8でなければなりません。次の psqlコマンドは、新しく作成されたデータベースを表示します。次のクエリは、大文字の文字が同じ基本文字の小文字の前にソートされていることを示しています。さらに、ソートリストの先頭に表示されるように並べ替えられたときに可変文字も考慮されます。 en_US.UTF-8 のデフォルトの動作は、同じ基本文字の大文字の前にある小文字の書式をソートし、可変文字を無視することです。3.6.3.3 initdbinitdbコマンドの一般的な使用法、構文、およびパラメータの詳細については、次のURLにあるPostgreSQLのコアドキュメントを参照してください。
3.6.4 照合順序の使用新たに定義されたICUの照合は、 COLLATION " collation_name "句をCREATE TABLEコマンドの列指定などのSQLコマンドで使用したり、 SELECTコマンドのORDER BY句の式に追加することができます。以下は、米国の英語に基づくICU照合の作成と使用の例です( en_US.UTF8 )。注意:照合順序を作成するときに、 LROOT照合を変更する属性が与えられた場合、ICUは通知および警告メッセージを生成することがあります。次の psqlコマンドは、照合をリストします。次のクエリは 、照合icu_collate_lowercaseを使用して列 c2をソートします 。これは、小文字の書式を同じ基本文字の大文字の前にソートするよう強制します。また、ご注意AN持つ行ように、基本文字を比較するとき、同じレベルのソート順に含まれるように力変数の文字属性idの値が9 、 10 、および11 、すべての文字と数字の前にソートリストの先頭に表示されます。カラム上の次のクエリソート c2照合使用icu_collate_ignore_punct持つ行に無視する変数文字を生じ、 id値9 、 10 、および11文字でソートBそれは直ちに無視可変文字の次の文字であるようにします。次の照会は 、照合icu_collate_ignore_white_spを使用して列 c2をソートします 。照合のASおよびT0020属性は、16進数0020以下のコード・ポイントを持つ可変文字を無視し、16進数0020以上のコード・ポイントを持つ可変文字を無視します。空白文字(16進数0020 )で始まるid値が11 の行は 、文字Bソートされます。これらの特定の可変文字は、基本文字の比較時に同じレベルのソート順に含まれるため、ソートリストの先頭には、16進数の0020よりも目に見える句読点で始まる9と10 id値を持つ行がソートリストの先頭に表示されます。
initdbユーティリティー・プログラムを使用してデータベース・クラスターを作成する場合、各WALセグメント・ファイルのデフォルト・サイズは16 MBです。Advanced Server initdbユーティリティーは、新しいデータベース・クラスターを作成するときにWALセグメント・ファイルのサイズを指定するための追加の--wal-segsizeオプションを提供します。sizeはメガバイト単位のWALセグメントファイルサイズで、2の累乗でなければなりません(たとえば、1,2,4,8,16,32など)。 sizeの最小許容値は1、最大許容値は1024です。データベースクラスタはdirectoryに作成されます。
4 セキュリティ
Advanced Serverは、SQLインジェクション攻撃に対する保護機能を提供します。 SQLインジェクション攻撃は、その結果、そのデータベースの内容、構造、またはセキュリティに関しては、攻撃者への手がかりを提供するSQL文を実行してデータベースを侵害しようとする試みです。SQL / Protectは、データベース管理者がSQLインジェクション攻撃からデータベースを保護するためのモジュールです。 SQL / Protectは、通常のデータベースセキュリティポリシーに加えて、一般的なSQLインジェクションプロファイルの入力クエリを調べることによって、セキュリティレイヤーを提供します。
4.1.1 SQL /保護の概要4.1.1.1 SQLインジェクション攻撃のタイプSQLインジェクション攻撃を阻止するために使用されるさまざまな手法がいくつかあります。各手法は、特定の シグネチャ によって特徴付けられ ます 。 SQL / Protectは、次のシグネチャの照会を検査します。Advanced Serverでは管理者がリレーション(テーブル、ビューなど)へのアクセスを制限できますが、多くの管理者はこの面倒な作業を実行しません。 SQL / Protectは 、ユーザーがアクセスする関係を追跡する 学習モードを提供します。SQLインジェクション攻撃中に行われる危険なアクションは、無制限のDMLステートメントの実行です。これらは WHERE句のないUPDATE文とDELETE文です。たとえば、攻撃者は、すべてのユーザーのパスワードを既知の値に更新したり、キーテーブル内のすべてのデータを削除してサービス拒否攻撃を開始することがあります。4.1.1.2 SQLインジェクション攻撃の監視4.1.1.2.1 保護されたロールSQLインジェクション攻撃を監視するには、セッションの現在のユーザーが保護された役割であるデータベースセッションで発生したSQLステートメントを分析する必要があります。 保護された役割は、データベース管理者は、保護/ SQLを使用して監視することを選択したAdvanced Serverのユーザーまたはグループです。 (Advanced Serverでは、ユーザーとグループを総称してロールと呼びます 。)注:スーパーユーザー権限を持つロールを保護されたロールにすることはできません。保護されていない非スーパーユーザーロールがその後スーパーユーザーになるように変更された場合、そのスーパーユーザーがコマンドを発行しようとするたびに特定の動作が表示されます。
• 4.1.1.2.2 攻撃試行統計SQL / Protectによる攻撃と見なされる保護された役割によるコマンドの各使用法が記録されます。統計は、第 4.1.1.1 項で説明したSQLインジェクション攻撃のタイプによって収集されます 。edb_sql_protect_stats の列は 、以下を監視します。
• ユーザー名。保護された役割の名前。
•
• 関係。保護された役割によって学習されなかったリレーションを参照して発行されたSQL文の数。 (つまり、役割の保護関係リストにない関係)。
• コマンド。保護されたロールによって発行されたDDLステートメントの数。
• トートロジー。トートロジ状態を含む保護された役割によって発行されたSQLステートメントの数。
• 注: SQL / Protectの統計情報は、データベースサーバーの稼動中にメモリに保持されます。データベースサーバーがシャットダウンされると、統計はAdvanced Serverホームディレクトリのdata/globalサブディレクトリにあるedb_sqlprotect.statという名前のバイナリファイルに保存されます。4.1.1.2.3 攻撃試行クエリビュー edb_sql_protect_queriesは、次の列があります。
• ユーザー名。データベースサーバーにログインするために使用された攻撃者のデータベースユーザー名。
• IPアドレス。攻撃が開始されたマシンのIPアドレス。
• 港。攻撃が発生したポート番号。
• machine_name。既知の場合、攻撃の起源となったマシンの名前。
• 日付時刻。クエリがデータベースサーバーによって受信された日時。時間は1分の精度で保存されます。
• クエリ。攻撃者が送信したクエリ文字列。
4.1.2 SQL / Protectの構成ライブラリファイル( sqlprotect.so Linuxでは、上のsqlprotect.dll保護/ SQLを実行するために必要なWindows上では)にインストールする必要がありますlibあなたのAdvanced Serverのホーム・ディレクトリのサブディレクトリ。 Windowsの場合、これはAdvanced Serverインストーラで行う必要があります。 Linuxの場合、 edb-as xx -server-sqlprotect RPMパッケージをインストールします。ここで、 xxはAdvanced Serverのバージョン番号です。
• データベース・サーバー構成ファイル postgresql.conf 、SQL / Protectで使用される構成パラメーターを追加して使用可能にすることによって変更する必要があります。
• shared_preload_libraries。 $libdir/sqlprotectをライブラリのリストに追加します。
• edb_sql_protect.enabled。これらのロールによって発行されたSQL文を解析し、 edb_sql_protect.levelの設定に従ってedb_sql_protect.levelすることによって、SQL / Protectが保護されたロールをアクティブに監視するかどうかを制御します。 SQL / Protectで監視を開始する準備ができたら、このパラメーターをon設定します。このパラメータを省略すると、デフォルトはoffます。
• edb_sql_protect.level。保護されたロールによってSQLステートメントが発行されたときにSQL / Protectが実行するアクションを設定します。このパラメータを省略すると、デフォルトの動作はpassiveます。最初に、 learnするようにこのパラメータを設定します。このパラメータの詳細については、 4.1.2.1.2項を参照してください。
• edb_sql_protect.max_protected_roles。保護できるロールの最大数を設定します。このパラメータを省略すると、デフォルト設定は64ます。このパラメータの最大範囲については、 3.1.3.12.8項を参照してください。
• edb_sql_protect.max_protected_relations。ロールごとに保護できるリレーションの最大数を設定します。このパラメータを省略すると、デフォルト設定は1024ます。このパラメータの最大範囲については、 3.1.3.12.7 項を参照してください 。
• edb_sql_protect.max_queries_to_save。 edb_sql_protect_queriesビューに保存する違反クエリの最大数を設定します。このパラメータを省略すると、デフォルト設定は5000ます。問題のクエリの数が制限に達すると、追加のクエリはビューには保存されませんが、データベースサーバーのログファイルにはアクセスできます。 注:このパラメーターの有効な最小値は100です。 100未満の値が指定された場合、データベースサーバーはデフォルト設定5000を使用し始めます。警告メッセージがデータベースサーバーのログファイルに記録されます。このパラメータの最大範囲については、 3.1.3.12.9項を参照してください。ステップ2: postgresql.confファイルを変更した後、データベースサーバを再起動します。手順3: SQLインジェクション攻撃から保護するデータベースごとに、スーパーユーザー(インストールオプションに応じてenterprisedbまたはpostgresいずれか)としてデータベースに接続し、 sqlprotect.sqlスクリプトをshare/contribサブディレクトリに実行します。 Advanced Serverのホームディレクトリ。スクリプトは、 sqlprotectという名前のスキーマにSQL / Protectデータベースオブジェクトを作成します。4.1.2.1 保護するロールの選択4.1.2.1.1 保護されたロールリストの設定ステップ1: psqlまたはPostgres Enterprise Manager Clientを使用して保護するデータベースにスーパーユーザーとして接続します。手順2: SQL / Protectテーブル、関数、およびビューはsqlprotectスキーマで構築されるため、 SET search_pathコマンドを使用して、検索パスにsqlprotectスキーマを含めます。これにより、SQL / Protectデータベース・オブジェクトに関連する操作または問合せをスキーマ修飾する必要がなくなります。ステップ3:保護する役割を保護された役割のリストに追加する必要があります。このリストは、 edb_sql_protectテーブルで管理されています。4.1.2.1.2 保護レベルの設定構成パラメーター edb_sql_protect.levelは保護レベルを設定します。保護レベルは、保護されたロールがSQLステートメントを発行するときのSQL / Protectの動作を定義します。 定義された動作は、データベースサーバー内のSQL / Protectで構成されたすべてのデータベースの保護された役割リスト内のすべての役割に適用されます。postgresql.confファイルedb_sql_protect.level設定パラメータは、モード、パッシブモード、またはアクティブモードを使用するかについては、以下のいずれかの値に設定することができます。
• 学ぶ。保護された役割の活動を追跡し、役割によって使用される関係を記録する。これは、SQL / Protectを最初に構成して、保護されたアプリケーションの予想される動作を学習するときに使用されます。
• 受動的。保護されたロールが定義されたルールを破るが、SQLステートメントの実行を停止しない場合、警告を発行します。これは、SQL / Protectが保護された役割の予想される動作を学習した後の次のステップです。これは基本的に侵入検知モードで動作し、適切に監視されている場合は本番環境で実行できます。
• アクティブ。保護された役割のすべての無効なステートメントを停止します。これは、SQLファイアウォールとして動作し、危険なクエリの実行を防ぎます。これは、攻撃者がアプリケーションの背後にある脆弱点とデータベースの種類を判断しようとしている場合に、早期侵入テストに対して特に効果的です。 SQL / Protectはこれらの脆弱点を閉じるだけでなく、ブロックされたクエリを追跡して、攻撃者がシステムに侵入する別の方法を見つける前に管理者に警告することができます。場合 edb_sql_protect.levelパラメータが設定されていないか、構成ファイルから省略され、SQL /保護のデフォルトの動作は受動的です。4.1.2.2 保護されたロールの監視新しいSQL / Protectインストールでは、最初に、保護されたロールが通常の操作中にアクセスできるようにする関係を決定します。ラーニングモードでは、SQL / Protectがアクセスされたリレーションを記録している間に、ロールを使用してアプリケーションを実行できます。これらは 、表edb_sql_protect_rel格納されているロールの 保護関係リストに追加されます。ただし、ロールが保護リレーションシップ・リストにないリレーションにアクセスしようとすると、 SQL / ProtectによってWARNINGまたはERROR重大度のメッセージが戻されます。その関係が受動的であるか能動的であるかに応じて、その役割に関する試行された行動が実行されてもされなくてもよい。4.1.2.2.1 学習モードステップ1: SQL / Protectを学習モードでアクティブにするには、以下のようにpostgresql.confファイルで次のパラメータを設定します。ステップ2: postgresql.confファイルをリロードします。注:構成ファイルを再ロードする別の方法については、 pg_reload_conf関数を使用してpg_reload_conf 。次の例に示すように、スーパーユーザーとしてデータベースに接続し、関数pg_reload_confを実行してpg_reload_conf 。ステップ3:保護されたロールでアプリケーションを実行できるようにします。ステップ4:保護されたロールがアプリケーションを実行するときに、SQL / Protectテーブルを照会して、ロールの保護されたリレーションリストへのリレーションシップの追加を観察できます。edb_sql_protect_relテーブルを照会して、保護関係リストに追加された関係を確認します。list_protected_rels ビューが提供され、OIDの代わりにオブジェクト名とともにより包括的な情報が得られます。4.1.2.2.2 受動モードステップ1:パッシブモードでSQL / Protectを有効にするには、以下のようにpostgresql.confファイルに次のパラメータを設定します。ステップ2:セクション4.1.2.2.1のステップ2に示すように、コンフィギュレーションファイルをリロードします。SQL / Protectはパッシブ・モードになりました。以前の例の deptテーブルやempテーブルなどで学習されたリレーションについては、SQL / Protectによってクライアントに特別な通知をせずに、user appuserによって実行される次のクエリのようにSQLステートメントが許可されますappuserSQL / Protectは、SQL文の実行を妨げませんが、学習されなかったリレーションに対して実行されたSQL文、または禁止された署名を含むSQL文に対して、次の例に示すようなWARNING重大度のメッセージを発行します 。ステップ3:不審な活動の統計情報を監視する。edb_sql_protect_stats ビューを照会すると、ロールの保護されたリレーションリストに含まれていないリレーションやSQLインジェクション攻撃シグネチャを含むリレーションを参照したSQL文の実行回数を確認できます。セクションを参照してください。 4.1.1.2.2をビューの詳細については、 edb_sql_protect_stats 。ステップ4:特定の攻撃に関する情報を表示します。edb_sql_protect_queries ビューを照会すると、ロールの保護されたリレーションリストにないリレーションを参照する、またはSQLインジェクション攻撃シグネチャが含まれているSQL文が表示されます。セクションを参照してください。 4.1.1.2.3をビューの詳細については、 edb_sql_protect_queries 。注意:攻撃がUnixドメインソケットを使用するデータベースサーバと同じホスト(つまり、 pg_hba.conf接続タイプlocal )で起きた場合、 ip_addressおよびportカラムは情報を返しません。4.1.2.2.3 アクティブモードステップ1:アクティブモードでSQL / Protectを有効にするには、以下のようにpostgresql.confファイルで次のパラメータを設定します。ステップ2:セクション4.1.2.2.1のステップ2に示すように、コンフィギュレーションファイルをリロードします。次の例では、セクションのステップ2の例で与えられたものと同様のSQL文示す 4.1.2.2.2が、ユーザーによって実行さappuser場合edb_sql_protect.levelに設定されているactive 。
4.1.3 一般的な保守作業4.1.3.1 保護されたロールリストへのロールの追加4.1.3.2 保護されたロールリストからのロールの削除注意:保護ロールリストからロールを削除する前に、 DROP ROLEまたはDROP USER SQL文を使用してロールを削除すると、OIDを使用するファンクションのバリエーションが役立ちます。 SQL / Protectリレーションに対するクエリで、ユーザー名にunknown (OID=16458)などの値が返された場合は、関数のunprotect_role( roleoid )形式を使用して、削除されたロールのエントリを保護ロールリストから削除します。unprotect_role関数の例を次に示します。4.1.3.3 ロールの保護のタイプの設定役割の保護を無効または有効にするSQLインジェクション攻撃の種類に対応するedb_sql_protect の列のブール値を変更します。
• dbid。変更を行うデータベースのOID
• roleid。 Boolean設定を変更するロールのOID変更が行われたことを確認するには、 edb_sql_protectまたはlist_protected_users 照会します。次のクエリノートでは、列allow_utility_cmdsはtが含まれています。4.1.3.4 保護関係リストからの関係の削除relnameで指定された関係が現在の検索パスにない場合は 、2番目の関数形式を使用して関係のスキーマを指定します。SQL / Protectは 、ロールがそのリレーションを利用しようとするたびに、 警告を出したり、アクセスを完全にブロックしたりします( edb_sql_protect.level の設定に応じて )。4.1.3.5 統計情報の削除注意: DROP ROLEまたはDROP USER SQL文を使用してロールを削除してからdrop_stats(' rolename ')を使用してロールの統計を削除すると、OIDを使用するファンクションのバリエーションが役立ちます。 edb_sql_protect_stats問合せで、ユーザー名にunknown (OID=16458)などの値がunknown (OID=16458)れた場合は、関数のdrop_stats( roleoid )形式を使用して、削除されたロールの統計をedb_sql_protect_statsからedb_sql_protect_statsます。4.1.3.6 不快なクエリの削除次の2つの関数のいずれかを使用して、 edb_sql_protect_queries ビューから問題のあるクエリを削除できます。注意: DROP ROLEまたはDROP USER SQL文を使用してロールを削除してから、 drop_queries(' rolename ')を使用してロールの問合せを削除すると、OIDを使用する関数のバリエーションが役立ちます。 edb_sql_protect_queries問合せで、ユーザー名にunknown (OID=16454)などの値がunknown (OID=16454)れた場合は、関数のdrop_queries( roleoid )形式を使用して、削除されたロールの問題のある問合せをedb_sql_protect_queriesからedb_sql_protect_queriesます。4.1.3.7 監視の無効化と有効化edb_sql_protect.enabled のエントリは 、次のようになります。ステップ2:セクション4.1.2.2.1のステップ2に示すように、コンフィギュレーションファイルをリロードします。edb_sql_protect.enabled のエントリは 、次のようになります。ステップ2:セクション4.1.2.2.1のステップ2に示すように、コンフィギュレーションファイルをリロードします。
注意:このセクションは、バックアップおよびリストア手順によって、 pg_dumpバックアッププログラムを使用する場合のように、新しいOIDを使用して新しいデータベースにデータベースオブジェクトを再作成する場合に適用されます。4.1.4.1 SQL / Protectテーブルのオブジェクト識別番号SQL / Protectは2つのテーブル edb_sql_protectとedb_sql_protect_relを使用して、データベース、ロール、リレーションなどのデータベースオブジェクトに関する情報を格納します。これらのテーブル内のこれらのデータベースオブジェクトへの参照は、オブジェクトのテキスト名ではなく、オブジェクトのOIDを使用して行われます。 OIDは、Advanced Serverが各データベースオブジェクトを一意に識別するために使用する数値データ型です。データベース・オブジェクトが作成されると、Advanced ServerはオブジェクトにOIDを割り当てます.OIDは、データベース・カタログ内のオブジェクトへの参照が必要な場合に使用されます。 2つのデータベース(同じ CREATE TABLEステートメントを持つテーブルなど)に同じデータベースオブジェクトを作成すると 、各テーブルには各データベースの異なるOIDが割り当てられます。バックアップおよびリストア操作で、バックアップされたデータベースオブジェクトが再作成されると、復元されたオブジェクトは元のデータベースで割り当てられたものとは異なる新しいOIDで新しいデータベースに格納されます。その結果、に保存されているデータベース、役割、および関係参照のOID edb_sql_protectとedb_sql_protect_relこれらのテーブルは、単にバックアップファイルにダンプし、新しいデータベースに復元されたときに、テーブルは、もはや有効ではありません。以下のセクションでは、 export_sqlprotectとimport_sqlprotect 2つの関数について説明します。 export_sqlprotect 関数は、 SQL / ProtectテーブルのOIDがSQL / Protectテーブルの復元後に正しいデータベースオブジェクトを参照するように、SQL / Protectテーブルのバックアップと復元に使用されます。4.1.4.2 データベースのバックアップステップ1: pg_dumpを使用してバックアップファイルを作成します。手順2:スーパーユーザーとしてデータベースに接続し、 export_sqlprotect(' sqlprotect_file ')関数を使用してSQL / Protectデータをエクスポートします。ここでsqlprotect_fileは、SQL / Protectデータを保存するファイルの完全修飾パスです。enterprisedb 、オペレーティング・システム・アカウント( postgresあなたは、PostgreSQLの互換モードでAdvanced Serverをインストールした場合)読みとで指定されたディレクトリへのアクセスの書き込みしている必要がありますsqlprotect_file 。4.1.4.3 バックアップファイルからの復元手順1:バックアップファイルを新しいデータベースに復元します。次の例では、 psqlユーティリティー・プログラムを使用して 、プレーン・テキスト・バックアップ・ファイル/tmp/edb.dmpをnewdbという名前の新しく作成されたデータベースにリストアします。ステップ2:新しいデータベースにスーパーユーザーとして接続し、 edb_sql_protect_relテーブルからすべての行を削除します。この手順は 、元のデータベースからバックアップされた edb_sql_protect_relテーブル内の既存の行をすべて削除します。これらの行には、バックアップ・ファイルがリストアされたデータベースに対する正しいOIDは含まれていません。ステップ3: edb_sql_protectテーブルからすべての行を削除します。この手順では 、元のデータベースからバックアップされた edb_sql_protectテーブル内の既存の行がすべて削除されます。これらの行には、バックアップ・ファイルがリストアされたデータベースに対する正しいOIDは含まれていません。ステップ4:データベースに存在する可能性のある統計情報をすべて削除します。手順5:データベースに存在する可能性のある問題のあるクエリをすべて削除します。手順6:元のデータベースのSQL / Protectで保護されていた役割名が、新しいデータベースが存在するデータベースサーバーに存在することを確認します。手順7:関数import_sqlprotect(' sqlprotect_file ')ここで、 sqlprotect_fileは、 4.1.4.2項の手順2で作成したファイルへの完全修飾パスです 。テーブル edb_sql_protectおよびedb_sql_protect_relに、新しいデータベースに割り当てられたデータベースオブジェクトのOIDを含むエントリが入力されるようになりました。統計ビューedb_sql_protect_statsも元のデータベースからインポートされた統計が表示されるようになりました。
•
• ステップ8:新しいデータベースを実行しているデータベースサーバのpostgresql.confファイルにSQL / Protect設定パラメータが必要に応じて設定されていることを確認します。データベースサーバーを再起動するか、必要に応じて構成ファイルを再ロードしてください。
4.2 仮想プライベートデータベース仮想プライベート・データベースは、セキュリティ・ポリシーを使用したファイングレイン・アクセス制御の一種です。バーチャルプライベートデータベースでのきめ細かなアクセス制御とは、データへのアクセスをセキュリティポリシーで定義されている特定の行まで制御できることを意味します。セキュリティポリシーをエンコードするルールは、特定の入力パラメータと戻り値を持つSPL関数であるポリシー関数で定義されます。 セキュリティポリシーは、特定のデータベースオブジェクト(通常はテーブル)に対するポリシー関数の名前付きの関連付けです。注意: Advanced Serverでは、SPLに加えてSQLやPL / pgSQLなどのAdvanced Serverでサポートされている言語でポリシー機能を記述できます。注意: Advanced Server Virtual Private Databaseで現在サポートされているデータベースオブジェクトはテーブルです。ポリシーをビューまたは同義語に適用することはできません。
• 細かいレベルのセキュリティを提供します。 GRANTコマンドで指定されたデータベース・オブジェクト・レベルの権限は、データベース・オブジェクトのインスタンス全体に対するアクセス権限を決定し、仮想プライベート・データベースはデータベース・オブジェクト・インスタンスの個々の行に対するアクセス制御を提供します。
• 注:セキュリティーポリシーを迂回させる唯一の方法は、 EXEMPT ACCESS POLICYシステム特権がユーザーに与えられている場合です。 EXEMPT ACCESS POLICY権限は、この権限を持つユーザーがデータベース内のすべてのポリシーから免除されるため、細心の注意を払って付与する必要があります。DBMS_RLSパッケージには、ポリシーを、ポリシーを作成したポリシーを削除し、ポリシーを有効、または無効にする手順を説明します。
4.3 sslutilssslutilsは、EDB Postgres Enterprise Managerサーバで使用するためにSSL証明書生成機能をAdvanced Serverに提供するPostgres拡張sslutilsです。 sslutils使用してインストールされるedb-as xx -server-sslutils RPMパッケージxx Advanced Serverのバージョン番号です。sslutilsパッケージには、以下のセクションに示す機能を提供します。これらのセクションでは、関数のパラメータリスト内の各パラメータによって記述される parameter n パラメータ項の下でn指すn関数のパラメータリスト内の順序位置番目(例えば、第一、第二、第三、等)。4.3.1 openssl_rsa_generate_keyopenssl_rsa_generate_key機能は、RSA秘密鍵を生成します。関数のシグネチャは次のとおりです。4.3.2 openssl_rsa_key_to_csropenssl_rsa_key_to_csr機能は、証明書署名要求(CSR)を生成します。署名は次のとおりです。署名要求を使用するエージェントの共通名( agentN )。4.3.3 openssl_csr_to_crtopenssl_csr_to_crt機能は、自己署名証明書または認証局の証明書を生成します。署名は次のとおりです。認証局証明書へのパス 。認証局証明書を生成する場合はNULL 。4.3.4 openssl_rsa_generate_crlopenssl_rsa_generate_crl機能は、デフォルトの証明書失効リストを生成します。署名は次のとおりです。
4.4 データの改ざんデータの改ざんは、特定のユーザーに対して表示されるデータを動的に変更することによって機密データの暴露を制限する手法です。たとえば、社会保障番号(SSN)は 021-23-9567 として格納され 021-23-9567 。特権ユーザーには完全なSSNが表示され、他のユーザーには最後の4桁のxxx-xx-9567しか表示されxxx-xx-9567 。これらの関数は、 CREATE REDACTION POLICYコマンドを使用して、変更ポリシーに組み込まれます。このコマンドは、ポリシーが適用されるテーブル、指定された編集機能によって影響を受けるテーブルの列、影響を受けるセッションユーザーを決定する式、およびその他のオプションを指定します。
4.4.1 リセッション・ポリシーの作成CREATE REDACTION POLICYは、テーブルの新しいデータ変更ポリシーを定義します。[ FOR ( expression ) ]ここで、 redaction_optionは次のとおりです。CREATE REDACTION POLICYコマンドが改訂関数を使用して列データをredactingによってテーブルの新しい列レベルのセキュリティポリシーを定義します。新しく作成されたデータ変更ポリシーは、デフォルトで有効になります。ポリシーは、 ALTER REDACTION POLICY ... DISABLEを使用して無効にすることができます。このオプションのフォームは、テーブルの列をデータ編集ポリシーに追加します。 USING改訂の関数式を指定します。複数のADD [ COLUMN ]フォームを使用して、テーブルの複数の列を作成するデータ書き換えポリシーに追加することができます。オプションのWITH OPTIONS ( ... )句は、適用されるデータ変更ポリシーの有効範囲および/または例外を指定します。スコープおよび/または例外を指定しない場合、スコープおよび例外のデフォルト値はそれぞれqueryおよびnoneなりquery 。スコープでは、列に適用される編集が行われるクエリ部分が特定されました。スコープ値は、 query 、 top_tlistまたはtop_tlist_or_errorです。スコープがquery場合、 queryに表示される場所に関係なく、列に適用されます。スコープがtop_tlist場合は、クエリの最上位のターゲットリストに表示されたときにのみ、列に適用されます。スコープがある場合top_tlist_or_error動作と同じになりますtop_tlistが、カラムは、クエリのどこにも表示されたときにエラーがスローされます。例外は、除外されるべき編集部分を特定した。例外値は、 none 、 equalまたはleakproofです。例外がnone場合、免除はありません。例外がequal場合は、等価テストで使用されたときには列は編集されません。例外がleakproof場合、漏れ防止機能が適用されても列は編集されません。employeesに対して、デフォルトのスコープと例外を使用して等価条件とsalaryでアクセス可能である列ssnを編集するためのデータ整理ポリシーを作成します。 redactionポリシーは、 hrユーザーには適用されません。hrユーザーの表示可能なデータは次のとおりです。
2。 スーパーユーザーまたは表の所有者が表にマテリアライズド・ビューを作成し、その表に GRANT SELECTおよびマテリアライズド・ビューをスーパーユーザー以外のユーザーにアクセス権を付与した場合、非スーパーユーザーは非編集対象のユーザーにアクセスできますマテリアライズド・ビューを介して
3。 CREATE REDACTION POLICYは、EnterpriseDBの拡張機能です。
4.4.2 ALTER REDACTION POLICYALTER REDACTION POLICYは、表のデータ変更ポリシーの定義を変更します。[ WITH OPTIONS ( [ redaction_option ][, redaction_option ] )MODIFY [ COLUMN ] column_name[ USING funcname_clause ][ WITH OPTIONS ( [ redaction_option ][, redaction_option ] )DROP [ COLUMN ] column_nameここで、 redaction_optionは次のとおりです。ALTER REDACTION POLICYは、既存のデータ修正ポリシーの定義を変更します。ALTER REDACTION POLICY を使用するには、データ変更ポリシーが適用されるテーブルを所有している必要があります。このフォームは、表の列に対するデータ変更ポリシーを変更します。列のredaction function節および/またはredactionオプションを更新できます。 USING句は、改訂の関数式を更新する指定し、 WITH OPTIONS ( ... )句は、適用範囲および/または例外を指定します。 redaction関数節、redactionスコープ、およびredaction例外の詳細については、「 CREATE REDACTION POLICY 」を参照してください。列のデータ修正関数式。詳細については、 CREATE REDACTION POLICYを参照してください。ALTER REDACTION POLICYは、EnterpriseDBの拡張機能です。
4.4.3 ドロップ・リセッション・ポリシーDROP REDACTION POLICYは、テーブルからデータ変更ポリシーを削除します。DROP REDACTION POLICYは、指定されたデータ変更ポリシーをテーブルから削除します。DROP REDACTION POLICY を使用するには、変更ポリシーが適用されるテーブルを所有している必要があります。employeesという名前のテーブルにredact_policy_personal_info というデータ変更ポリシーをドロップするには、 redact_policy_personal_infoにします。DROP REDACTION POLICYは、EnterpriseDBの拡張機能です。
4.4.4 システムカタログ4.4.4.1 edb_redaction_columnカタログ edb_redaction_columnは、表の列にアタッチされたデータ変更ポリシーの情報が格納されます。
注:表の編集ポリシーedb_redaction_column.rdpolicyidが有効になっていて、編集ポリシー表現edb_redaction_policy.rdexprがtrueと評価された場合は、記述された列が編集されます。4.4.4.2 edb_redaction_policyカタログ edb_redaction_policyは、表の編集ポリシーの情報が保管されます。
注:テーブルが有効で、式が真に評価された場合は、データ変更ポリシーがテーブルに適用されます。
EDBリソースマネージャは、Advanced Serverプロセスで使用されるオペレーティングシステムリソースの使用を制御する機能を提供するAdvanced Server機能です。
• EDB Resource Managerの基本コンポーネントはリソースグループです。 リソース・グループは、さまざまなリソースの使用制限が定義可能なAdvanced Serverのインスタンス内のすべてのデータベースに利用できるという名前の、グローバルグループ、です。特定のリソースグループのメンバとして割り当てられているAdvanced Serverプロセスは、EDBリソースマネージャによって制御され、グループ内のすべてのプロセスの集約リソース使用率がグループに定義された制限の近くに保持されます。
• リソースグループに属するすべてのプロセスの望ましい消費レベルは、 リソースタイプのパラメータ によって定義され ます 。 EDB Resource Managerが現在サポートしているさまざまな種類のシステムリソースには、異なるリソースタイプのパラメータがあります。
•
• edb_max_resource_groups構成パラメータは、実行中のプロセスで同時にアクティブにできるリソース・グループの最大数を設定します。デフォルト設定は16リソースグループです。このパラメータの変更は、データベースサーバの再起動時に有効になります。
•
• デフォルトのリソースグループは、 ALTER ROLE ... SETコマンドを使用してロールに割り当てることも 、 ALTER DATABASE ... SETコマンドを使用してデータベースに割り当てることもできます 。 postgresql.confファイルでパラメータを設定することによって、データベースサーバインスタンス全体にデフォルトのリソースグループを割り当てることができます。
• データベースサーバインスタンスのバックアップファイルにリソースグループを含めるには、デフォルト設定でpg_dumpallバックアップユーティリティを使用します(つまり、 --globals-only 、-- --roles-only 、または--tablespaces-onlyいずれも指定しないで--tablespaces-onlyオプション。)
5.1 リソースグループの作成と管理5.1.1 リソースグループの作成新しいリソース・グループを作成するには、 CREATE RESOURCE GROUPコマンドを使用します。CREATE RESOURCE GROUPコマンドは、指定された名前を持つリソース・グループを作成します。 ALTER RESOURCE GROUPコマンドを使用して、グループでリソース制限を定義できます。リソースグループは、Advanced Serverインスタンスのすべてのデータベースからアクセスできます。CREATE RESOURCE GROUPコマンドを使用するには、スーパーユーザー権限が必要です。5.1.2 ALTER RESOURCE GROUPALTER RESOURCE GROUPコマンドは、既存のリソース・グループの特定の属性を変更します。RENAME TO句を含む最初の形式は、既存のリソースグループに新しい名前を割り当てます。SET resource_type TO句を使用する2番目の形式は、指定されたリテラル値をリソース・タイプに割り当てるか、またはDEFAULTが指定されたときにリソース・タイプをリセットします。リソースタイプをDEFAULTリセットまたは設定するということは、リソースグループにそのリソースタイプに定義された制限がないことを意味します。ALTER RESOURCE GROUPコマンドを使用するには、スーパーユーザー権限が必要です。value | DEFAULT5.1.3 DROP RESOURCE GROUPDROP RESOURCE GROUPコマンドは、指定した名前のリソース・グループを削除します。DROP RESOURCE GROUPコマンドを使用するには、スーパーユーザー権限が必要です。5.1.4 リソース・グループへのプロセスの割当てプロセスは、デフォルトでは、ロール、データベース、またはデータベースサーバーインスタンス全体にデフォルトのリソースグループを割り当てることによって、リソースグループにデフォルトで含めることができます。ALTER ROLE ... SETコマンドを使用して、デフォルトのリソースグループを役割に割り当てることができます 。 ALTER ROLEコマンドの詳細については、次のURLにあるPostgreSQLのコアドキュメントを参照してください。デフォルトのリソースグループは、 ALTER DATABASE ... SETコマンドによってデータベースに割り当てることができます 。 ALTER DATABASEコマンドの詳細については、次のURLにあるPostgreSQLのコアドキュメントを参照してください。postgresql.confファイルのedb_resource_group構成パラメータをedb_resource_groupように設定すると、 データベース・サーバー・インスタンス全体にデフォルト・リソース・グループを割り当てることができます。5.1.5 リソース・グループからのプロセスの削除デフォルトのリソースグループをデータベースサーバインスタンスから削除するには、 postgresql.confファイルでedb_resource_group設定パラメータを空の文字列に設定し、設定ファイルをリロードします。5.1.6 リソース・グループ内のプロセスの監視edb_all_resource_groups の列は次のとおりです。
• グループ名。リソースグループの名前。
• アクティブプロセス。リソースグループ内のアクティブなプロセスの数。
• cpu_rate_limit。リソースグループに割り当てられたCPUレート制限リソースタイプの値。
• per_process_cpu_rate_limit。リソースグループ内の個々のアクティブなプロセスに適用されるCPUレート制限。
• dirty_rate_limit。リソースグループに割り当てられたダーティレート制限リソースタイプの値。
• per_process_dirty_rate_limit。リソースグループ内の個々のアクティブプロセスに適用されるダーティレート制限。注: per_process_cpu_rate_limitおよびper_process_dirty_rate_limit列には、プロセスで使用される実際のリソース消費は表示されませんが、リソースグループ内のアクティブなプロセスの数に基づいて、個々のプロセスのリソース制限がEDB Resource Managerによってどのように設定されるかが示されます。次に示し edb_all_resource_groupsリソースグループときresgrp_aアクティブなプロセスが含まれていない、リソースグループresgrp_b二つの活性プロセスを含み、リソースグループresgrp_c一つの活性プロセスを含んでいます。edb_all_resource_groupsことに注意し、表示per_process_cpu_rate_limitとper_process_dirty_rate_limit値はおおよそアクティブなプロセスの数で割った、対応するCPUレート制限や汚れレートリミットです。
5.2 CPU使用量の調整cpu_rate_limitパラメータを、グループ内のすべてのプロセスのCPU同時使用が同時に超過しないように、ウォールクロック時間を超えるCPU時間の割合に設定します。したがって、 cpu_rate_limit割り当てられる値は、通常、1以下である必要があります。cpu_rate_limitパラメータの有効範囲は 0〜1.67772e + 07です。 0に設定すると、リソースグループにCPUレート制限が設定されていないことを意味します。100を掛け合わせると、 cpu_rate_limitはリソースグループのCPU使用率として解釈することもできます。EDBリソースマネージャは 、 cpu_rate_limitパラメータで指定された制限内で、グループ内のすべてのプロセスのCPU使用量を集計するためにCPUスロットルを使用します。グループ内のプロセスは、定義された制限を維持するために中断され、短時間の間スリープモードに入ることがあります。このような中断がいつどのように発生するかは、EDB Resource Managerが使用する独自のアルゴリズムによって定義されます。5.2.1 リソース・グループのCPUレート制限の設定ALTER RESOURCE GROUPでコマンドSET cpu_rate_limit句は、リソースグループのCPUレート制限を設定するために使用されます。次の例では、CPU使用率の上限は resgrp_aでは50%、 resgrp_aでは40%、 resgrp_b 30%にresgrp_cます。これは、 resgrp_a割り当てられたすべてのプロセスのCPU使用率のresgrp_aが約50%に維持されていることを意味します。同様に、 resgrp_bすべてのプロセスで、CPU使用率の合計は約40%に維持されます。リソースグループのcpu_rate_limitを変更すると、そのグループに割り当てられている新しいプロセスに影響するだけでなく、そのグループのメンバーである現在実行中のプロセスは、変更の影響を直ちに受けます。つまり、 cpu_rate_limitが.5から.3に変更された場合、グループ内の現在実行中のプロセスは、グループ全体のCPU使用率が50%ではなく30%近くになるように、下向きに抑制されます。リソースグループのCPUレート制限を設定する効果を説明するために、次の例では、 SELECT 20000!; クエリによって実行される20000階乗(20000 * 19999 * 19998などの乗算)のCPU集約的な計算を使用しています SELECT 20000!; psqlコマンドラインユーティリティで実行します。5.2.2 例 - 単一グループ内の単一プロセス2番目のセッションでは、Linux topコマンドを使用して%CPU列の下に示すようにCPU使用率を表示します。以下は、 topコマンドの出力が定期的に変化するときの任意の時点でのスナップショットです。psql階乗演算を行うセッションは、行によって示されているedb-postgres下に表示されるCOMMANDカラム。 %CPU列の下に表示されるセッションのCPU使用率は39.9です。これはリソースグループresgrp_b設定されている40%CPU制限に近い値resgrp_b 。対照的に、 psqlセッションがリソースグループから削除され、階乗計算が再度実行されると、CPU使用率がはるかに高くなります。5.2.3 例 - 単一グループ内の複数のプロセス次のコマンドシーケンスは、半分の時間間隔でサンプリングされたすべての edb-postgresプロセスの合計を表示します。これは、EDB Resource Managerがプロセスを抑制して、リソースグループ全体のCPU使用率を40%近くに抑えるように、リソースグループ内のプロセスのCPU使用率がどのように変化するかを示しています。5.2.4 例 - 複数のグループの複数のプロセスこの例では、2つの追加の psqlセッションが前の2つのセッションとともに使用されています。 3番目と4番目のセッションでは、リソースグループresgrp_c内でcpu_rate_limitが.3 (CPU使用率が30%)という同じ階乗計算が実行されます。topコマンドは次の出力が表示されます。使用されている2つのリソースグループのCPU使用率は、40%と30%です。最初の2つのedb-postgresプロセスの %CPU列の合計は39.5(約40%、 resgrp_bの制限)、3番目と4番目のedb-postgresプロセスの%CPU列の合計は31.6(約30%、これはresgrp_cの制限です)。CPU使用率が40%に制限されているリソースグループに属している2番目と3番目の edb-postgresプロセスの総CPU使用量は37.8です。しかし、最初のedb-postgresプロセスは、リソースグループ内にないため、58.6%のCPU使用率を持ち、基本的に残りの使用可能なCPUリソースをシステム上で利用します。
5.3 ダーティバッファースロットルdirty_rate_limitパラメータを、グループ内のすべてのプロセスが共有バッファに書き込むか、または「ダーティ」にする結合レートの1秒あたりのキロバイト数に設定します。設定例は3072キロバイト/秒です。dirty_rate_limitパラメータの有効範囲は 0〜1.67772e + 07です。 0に設定すると、リソースグループにダーティレート制限が設定されていないことを意味します。EDBリソース・マネージャは 、 dirty_rate_limitパラメータで指定された限界に近いグループ内のすべてのプロセスの集約された共有バッファ書き込み率を維持するために、 ダーティ・バッファ・スロットルを使用します。グループ内のプロセスは、定義された制限を維持するために中断され、短時間の間スリープモードに入ることがあります。このような中断がいつどのように発生するかは、EDB Resource Managerが使用する独自のアルゴリズムによって定義されます。5.3.1 リソース・グループのダーティ・レート制限の設定ALTER RESOURCE GROUPでコマンドSET dirty_rate_limit句は、リソースグループの汚れたレート制限を設定するために使用されています。次の例では、ダーティレートの制限は resgrp_a 場合は12288キロバイト/秒、 resgrp_a場合は6144キロバイト/秒、 resgrp_b 3072キロバイト/秒にresgrp_cます。これは、 resgrp_a割り当てられたすべてのプロセスの共有バッファへの合計書き込み速度が約12288キロバイト/秒に維持されることをresgrp_aます。同様に、 resgrp_b内のすべてのプロセスについて、共有バッファへの結合書き込み速度は約6144キロバイト/秒に維持されます。リソースグループのdirty_rate_limitを変更すると、そのグループに割り当てられている新しいプロセスに影響するだけでなく、そのグループのメンバーである現在実行中のプロセスは、変更の影響を直ちに受けます。つまり、 dirty_rate_limitが12288から3072に変更された場合、グループ内で現在実行されているプロセスは、グループ全体のダーティレートが1秒当たり12288キロバイトではなく、1秒あたり3072キロバイトになるように、FILLFACTOR = 10で句の結果INSERTコマンドは、1ページあたり10%まで行を梱包します。これは、これらの例の目的のために、ダーティな共有ブロックのより大きなサンプリングをもたらす。pg_stat_statementsモジュールは、SQLコマンドとコマンドの実行にかかった時間の量によって汚される共有バッファブロックの数を表示するために使用されます。これは、SQLコマンドの実際のキロバイト/秒の書き込み速度を計算するための情報を提供し、それをリソースグループに設定されたダーティレート制限と比較します。pg_stat_statementsモジュールを使用するには 、次の手順を実行します。手順2:データベースサーバーを再起動します。pg_stat_statements_reset()関数をクリアするために使用されるpg_stat_statements各実施例を明確にするための図。5.3.2 例 - 単一グループ内の単一プロセス次の一連のコマンドは、テーブル t1 作成を示しています 。現在のプロセスはリソースグループresgrp_bを使用するように設定されています。 pg_stat_statementsビューは、 pg_stat_statements_reset()関数を実行することでクリアされます。最後に、 INSERTコマンドは、1から10,000の一連の整数を生成してテーブルを作成し、約10,000のブロックをダーティにします。INSERTコマンドの結果を次に示します 。
•
•
•
•
•
• 5.3.3 例 - 単一グループ内の複数のプロセスこの例では、挿入は2つの別々の psqlセッションで2つの異なるテーブルで同時に実行され 、各セッションはresgrp_bが1秒あたり6144キロバイトに設定されたdirty_rate_limitリソースグループに追加されています。
•
•
•
•
•
• 5.3.4 例 - 複数のグループの複数のプロセスこの例では、2つの追加の psqlセッションが前の2つのセッションとともに使用されています。第三及び第四のセッションは、同じ実行INSERTリソースグループ内のコマンドresgrp_c有するdirty_rate_limit毎秒3072キロバイトの。以下は、 4つのセッションにおけるINSERTコマンドの結果を示しています。 RECORD 3はセッション1の結果を示していますRECORD 2はセッション2の結果を示していますRECORD 4はセッション3の結果を示していますRECORD 5はセッション4の結果を示しています。セッション1(28407.435)とセッション2(31343.458)の時間は、セッション3(52727.846)の時間とセッションに比べて、 両方が同じリソースグループにあり、 dirty_rate_limitが6144に設定されているため、互いに近いことに注意してください 4(56063.697)、これはリソースグループ内にあり、 dirty_rate_limit設定されています。後者のグループのダーティレートの制限が遅いため、セッション3および4の場合と同様に予想される処理時間が長くなります。
•
•
• 結果に8.192を掛けて、1秒あたりのダストキロバイト数(1ブロック= 8.192キロバイト)を求めます。これは約 2885キロバイト/秒になります。
•
•
•
•
•
•
•
•
•
5.4 システムカタログ5.4.1 edb_all_resource_groups
5.4.2 edb_resource_group
•
•
•
• structsと型typedefs
•
• IN/OUT/IN OUTパラメータ
6.2 REFCURSORのサポート以前のリリースでは、Advanced Server は以下のlibpq関数 を REFCURSORs して REFCURSORs を サポートし ていました。これらの関数は廃止予定とみなされるべきです:SPL(またはPL / pgSQL)関数によって返され た REFCURSOR を取得するために、 PQexec() および PQgetvalue() を 使用することができ ます。 REFCURSOR カーソルの名前を示すヌル終了文字列の形式で返されます。カーソルの名前 を取得すると、 1つまたは複数の FETCH 文を 実行 して、カーソルで公開される値を取得 でき ます。CREATE OR REPLACE FUNCTION getEmployees(p_deptno NUMERIC) RETURN REFCURSOR AS
result REFCURSOR;
BEGIN
OPEN result FOR SELECT * FROM emp WHERE deptno = p_deptno;
RETURN result;
END;このファンクションは、単一のパラメータ p_deptno を必要と し、 OPEN 文に 示される SELECT 問合せの 結果セットを保持 する REFCURSOR を 戻します 。 OPEN 文は、クエリを実行し、カーソルに設定された結果を格納します。サーバーはそのカーソルの名前を作成し、その名前を変数( result という名前 )に 格納します 。この関数は、カーソルの名前を呼び出し元に返します。char *commandText = malloc(commandLength);
PGresult *result;
int row;
sprintf(commandText, "FETCH ALL FROM \"%s\"", cursorName);
result = PQexec(conn, commandText);
if (PQresultStatus(result) != PGRES_TUPLES_OK)
fail(conn, PQerrorMessage(conn));
printf("-- %s --\n", description);
for (row = 0; row < PQntuples(result); row++)
{
const char *delimiter = "\t";
int col;
for (col = 0; col < PQnfields(result); col++)
{
printf("%s%s", delimiter, PQgetvalue(result, row, col));
delimiter = ",";
}
printf("\n");
}
PQclear(result);
free(commandText);
}
static void
fail(PGconn *conn, const char *msg)
{
fprintf(stderr, "%s\n", msg);
if (conn != NULL)
PQfinish(conn);
exit(-1);
}PQexec() 関数は、Cプログラムにハンドルを結果セットを返します。結果セットにはちょうど1つの値が含まれます。その値は、 getEmployees() によって返されるカーソルの名前です 。カーソルの名前 を取得 すると、SQL FETCH ステートメントを使用してそのカーソル内の行を取り出す ことができ ます。関数 fetchAllRows() は FETCH 構築し fetchAllRows() ALL 文を実行し、その文を実行した後、 FETCH 結果セットを出力します ALL ステートメント。
•
•
6.3 配列バインディング
• PQBulkStart ( 6.3.1項を参照)
• PQexecBulk (セクション6.3.2を参照)
• PQBulkFinish ( 6.3.3項を参照)
• PQexecBulkPrepared ( 6.3.4項を参照)6.3.1 PQBulkStartPQBulkStart()は、サーバー上のバルク操作を初期化します。バルクデータをサーバーに送信する前に、この関数を呼び出す必要があります。 PQBulkStart()で指定された準備された文初期化stmtNameによって指定された形式でデータを受信するparamFmts 。6.3.2 PQexecBulk6.3.3 PQBulkFinish6.3.4 PQexecBulkPreparedまた、 PQexecBulkPrepared()関数は、単一の関数呼び出しで一括操作を実行します。 PQexecBulkPrepared()は、指定されたパラメータでプリペアドステートメントを実行する要求を送信し、結果を待ちます。この関数は、 PQbulkStart() 、 PQexecBulk() 、およびPQBulkFinish()機能を組み合わせています。この機能を使用する場合、一括操作を初期化または終了する必要はありません。この関数は、バルク操作を開始し、そのデータをサーバーに渡し、バルク操作を終了します。stmtName の代わりに事前に準備されたステートメントを指定します。繰り返し使用されるコマンドは、実行されるたびに解析されるのではなく、1回だけ解析および計画されます。
7 デバッガデバッガは pgAdmin 4 と統合され、 pgAdmin 4 から呼び出されます。 Linuxでは、 edb-as xx -server-pldebugger RPMパッケージ( xxはAdvanced Serverのバージョン番号)もインストールする必要があります。 pgAdmin 4の情報は次の場所から入手できます:
• スタンドアロンデバッグ。デバッガは、テストするプログラムを起動するために使用されます。プログラムが必要とする入力パラメータ値を指定すると、プログラムのコードをただちに観察してステップ実行することができます。スタンドアロンデバッグは、新しいプログラムや初期の問題調査に使用される典型的な方法です。
• インコンテキストデバッグ。テストするプログラムは、デバッガ以外のアプリケーションによって開始されます。まず、テストするプログラムにグローバルブレークポイントを設定します 。プログラムへの最初の呼び出しを行うアプリケーションは、グローバルブレークポイントを検出します。アプリケーションは実行を中断し、デバッガが呼び出されたプログラムを制御します。コールされたアプリケーションのコンテキスト内で実行されるので、呼び出されたプログラムのコードを観察し、ステップ実行することができます。デバッガで呼び出されるプログラムのコードを完全に踏んだら、中断したアプリケーションは実行を再開します。インコンテキストデバッグは、呼び出し元アプリケーションとの複雑な相互作用により、スタンドアロンデバッグを使用して問題を再現することが困難な場合に便利です。
7.1 デバッガの設定デバッガを使用する前に、 shared_preload_libraries構成パラメータにリストされているライブラリに$libdir/plugin_debuggerを追加して、 postgresql.confファイル(Advanced Serverホームディレクトリのdataサブディレクトリにあります)を$libdir/plugin_debuggerします。
7.2 デバッガの起動スタンドアロンデバッグのためにデバッガにアクセスするには、pgAdmin 4を使用します。デバッガを開くには、pgAdmin 4 Browserパネルで、デバッグするストアドプロシージャまたはファンクションの名前を強調表示します 。次に、 ObjectメニューからDebuggingメニューまでナビゲートし、サブメニューからDebugを選択します。スタンドアロンデバッグを使用してトリガをデバッグすることはできません。トリガーは、コンテキスト内のデバッグを使用してデバッグする必要があります。コンテキスト内デバッグ用のグローバルブレークポイントの設定については、 7.5.3 項を参照してください 。
7.3 デバッガウィンドウDebuggerウィンドウを使用して、スタンドアロン時にパラメータ値を渡して、パラメータを必要とするプログラムをデバッグすることができます。デバッガを起動すると、 Debuggerウィンドウが自動的に開き、プログラムが期待するINまたはIN OUTパラメータが表示されます。プログラムがINまたはIN OUTパラメーターを宣言していない場合、 Debuggerウィンドウはオープンしません。
• [ Nameフィールドに仮パラメータ名が含まれます。
• Typeフィールドには、パラメータのデータ型が含まれています。
•
•
• 「 Valueフィールドには、プログラムに渡すパラメーター値が入っています。
•
• Default Valueフィールドには、パラメータのデフォルト値が含まれています。初期化セクションを持つパッケージのメンバであるプロシージャまたはファンクションをデバッグする場合は、[ Debug Package Initializerチェックボックスをオンにして、デバッガがパッケージ初期化セクションに入るように指示し、デバッグ前に初期化セクションコードをデバッグできるようにしますプロシージャまたは関数このチェックボックスをオンにしないと、デバッガはパッケージの初期化セクションを実行します。実行されるとコードの個々の行を表示またはステップ実行することはできません。注意:コンテキスト内のデバッグ中は、[ Debuggerウィンドウは開きません。代わりに、デバッグするプログラムを呼び出すアプリケーションは、必要な入力パラメーター値を指定する必要があります。プログラムコードをステップ実行して完全なデバッグサイクルを完了すると、 Debuggerウィンドウが再び開き、新しいパラメータ値を入力してデバッグサイクルを繰り返すか、デバッグセッションを終了できます。
7.4 メインデバッガウィンドウ
• 一番上の Program Bodyパネルにプログラムのソースコードが表示されます。
• 下部の[ Tabs ]パネルには、さまざまな情報のための一連のタブが用意されています。トップパネルにあるTool Barアイコンを使用して、デバッグ機能にアクセスします。7.4.1 プログラム本体パネルProgram Bodyパネルがデバッグされているプログラムのソースコードが表示されます。7.4.2 タブパネルは、
• [ Parameters ]タブに現在のパラメータ値が表示されます。
• [ Local variables ]タブには、プログラム内で宣言された変数の値が表示されます。
• [ Messages ]タブには、プログラムの実行時に返される結果が表示されます。
• 7.4.3 スタックタブ[ Stack ]タブには、現在コールスタック上にあるプログラムのリスト(呼び出されたがまだ完了していないプログラム)のリストが表示されます。プログラムが呼び出されると、 Stackタブに表示されるリストの一番上にプログラムの名前が追加されます。 Wプログラムが終了鶏は、その名前がリストから削除されます。
•
7.5 プログラムのデバッグ7.5.1 コードの実行
• に入る。 Step intoアイコンをクリックして、現在強調表示されているコード行を実行します。
• ステップオーバー。 Step overアイコンをクリックしてコード行を実行し、コードによって呼び出されたすべてのサブ関数をStep over実行します。サブファンクションは実行されますが、ブレークポイントが含まれていない限りデバッグは行われません。
• 続行/開始。強調表示されたコードを実行するには、 Continue/Startアイコンをクリックし、プログラムがブレークポイントに遭遇するか完了するまで続行します。
• やめる。 Stopアイコンをクリックすると、プログラムの実行を停止します。7.5.2 ブレークポイントの使用ローカルブレークポイント - ローカルブレークポイントは、プログラム内の実行可能なコード行に設定できます。デバッガは、ローカルブレークポイントが設定されている行に到達すると、実行を一時停止します。グローバルブレークポイント - すべての セッションがそのブレークポイントに達すると 、グローバルブレークポイントがトリガーさ れます。プログラムのコンテキスト内デバッグを実行する場合は、グローバルブレークポイントを設定します。グローバルブレークポイントがプログラムに設定されると、グローバルブレークポイントを設定するデバッグセッションは、そのプログラムが別のセッションで呼び出されるまで待機します。グローバルブレークポイントは、スーパーユーザーだけが設定できます。ローカルブレークポイントを削除するには、 Program Bodyパネルの灰色で塗りつぶされた余白にあるブレークポイントの点をマウスで左クリックします 。点が消え、ブレークポイントが削除されたことを示します。[ all breakpoints Clear all ]アイコンをクリックすると、現在 Program Bodyフレームに表示されている Program からすべてのブレークポイントを削除できます。注:上記のいずれかの操作を実行すると、 Program Bodyパネルに現在表示されているProgram Body内のブレークポイントだけが削除されます。現在Program Bodyパネルに表示されているプログラムを呼び出すプログラム内の呼び出されたサブプログラムまたはブレークポイントのブレークポイントは削除されません。コンテキスト内デバッグのグローバルブレークポイントを設定するには、 Browserパネルでブレークポイントを設定するストアドプロシージャ、関数、またはトリガを強調表示します 。 [ Object ]メニューから[ Debugging ]、[ Breakpoint Set ]の順に選択します。または、グローバルブレークポイントを設定するストアドプロシージャ、関数、またはトリガの名前を右クリックし 、コンテキストメニューからDebugging を選択し 、次にSet BreakpointをSet Breakpointすることもできます。パッケージ内にグローバルブレークポイントを設定するには、デバッグするパッケージのパッケージノードの下にある特定のプロシージャまたは関数を強調表示し、ストアドプロシージャおよび関数と同じ指示に従います。select_empデバッガでプログラムをステップ実行するまでの機能は完了しません。ステップイン、ステップオーバー、および続行、またはローカルブレークポイントの設定など、前述の操作のいずれかを使用してプログラムをデバッグできるようになりました。プログラムの実行をステップ実行すると、呼び出し元のアプリケーション(PSQL)が制御を取り戻し、 select_emp関数の実行が完了し、その出力が表示されます。この時点で、セクション 7.5.4に 示すようにデバッガセッションを終了することができます 。デバッガセッションを終了しないと、プログラムを呼び出す次のアプリケーションにグローバルブレークポイントが発生し、デバッグサイクルが再び開始されます。7.5.4 デバッガの終了
8.1 ダイナネAdvanced Serverは、インストールされているホストマシンでシステムリソースを最適に使用できるように、データベースサーバーの動的調整をサポートしています。この機能を制御する2つのパラメータは、 postgresql.confファイルにあります。これらのパラメータは次のとおりです。8.1.1 edb_dynatuneedb_dynatuneは、ホスト・マシンの使用可能リソースの合計とホスト・マシンの使用目的に基づいて、データベース・サーバーが使用するホスト・システムのリソースの量を決定します。Advanced Serverを最初にインストールすると、 edb_dynatuneパラメータは、インストールされたホストマシン(開発マシン、混在マシン、専用サーバー)の選択された使用状況に従って設定されます。ほとんどの場合、パフォーマンスを向上させるためにデータベース管理者がpostgresql.confファイルのさまざまな設定パラメータを調整する必要はありません。postgresql.confファイルを編集することにより、Advanced Serverの初期インストール後にedb_dynatuneパラメータの値を変更できます。新しい設定を有効にするには、postmasterを再起動する必要があります。edb_dynatuneパラメータは、包括的、0と100の間の任意の整数値に設定することができます。値0を指定すると、動的チューニング機能がオフになり、データベースサーバのリソース使用量はpostgresql.confファイルの他の設定パラメータの制御下に完全にpostgresql.confます。非ゼロの値が小さければ(例えば、1〜33)、ホスト・マシンのリソースの最小量がデータベース・サーバーに割り当てられます。この設定は、他の多くのアプリケーションが使用されている開発マシンで使用されます。edb_dynatune 値が選択されると、 postgresql.confファイル内の他の設定パラメータを調整することによって、データベースサーバのパフォーマンスをさらに微調整することができます。調整された設定は、 edb_dynatuneによって選択された対応する値を上書きします。パラメーターの値を変更するには、構成パラメーターをコメント解除し、目的の値を指定して、データベース・サーバーを再始動します。8.1.2 edb_dynatune_profileedb_dynatune_profileパラメータは、データベース・サーバー上で予想されるワークロードのプロファイルに基づいて調整局面を制御するために使用されます。このパラメータは、データベースサーバの起動時に有効になります。
8.2 EDB待機状態EDBの状態を待つ貢献モジュールは、2つの主要なコンポーネントが含まれています。この情報は 、 postgresql.confファイルに追加されるedb_wait_states.directoryパラメータで指定された、ユーザが設定可能なパスとディレクトリフォルダ内の一連のファイルに保存されます。指定されたパスは完全パスで、相対パスではありません。
• start_tsおよびend_ts(IN)。これらは一緒に時間間隔とその中のデータが読み取られることを指定する。唯一の場合start_ts指定されている、から始まるデータstart_ts出力されます。 end_tsのみをend_tsと、 end_tsまでのデータが出力されます。いずれも提供されていない場合、すべてのデータが出力されます。すべての関数は異なるデータを出力します。以下、各機能の出力について説明します。
• query_id(OUT)。正規化されたクエリを識別します。クエリから計算された内部ハッシュコードです。
• session_id(OUT)。セッションを識別します。
• ref_start_tsおよびref_end_ts(OUT)。特定のデータポイントを含むファイルのタイムスタンプを提供します。データポイントは、待機イベントサンプルレコード、クエリレコードまたはセッションレコードです。注:以下のセクションに示す例は、異なるユーザーを使用して異なるデータベースに接続された4つの異なるセッションで同時に実行される次の3つのクエリに基づいています。8.2.1 edb_wait_states_dataIN start_ts timestamptz default '-infinity'::timestamptz,IN end_ts timestamptz default 'infinity'::timestamptz,OUT session_id int4,OUT dbname text,OUT username text,OUT query text,OUT query_start_time timestamptz,OUT sample_time timestamptz,OUT wait_event_type text,OUT wait_event text8.2.2 edb_wait_states_queriesIN start_ts timestamptz default '-infinity'::timestamptz,IN end_ts timestamptz default 'infinity'::timestamptz,OUT query_id int8,OUT query text,OUT ref_start_ts timestamptzOUT ref_end_ts timestamptzこの関数は、指定された時間間隔で重複するクエリファイル内のすべてのクエリを返します。次のようなクエリは、 start_tsとend_ts 間のクエリを含むクエリファイル内のすべてのクエリを提供します 。8.2.3 edb_wait_states_sessionsIN start_ts timestamptz default '-infinity'::timestamptz,IN end_ts timestamptz default 'infinity'::timestamptz,OUT session_id int4,OUT dbname text,OUT username text,OUT ref_start_ts timestamptzOUT ref_end_ts timestamptzedb_wait_states_queries() と同様に 、この関数は、指定された間隔内でサンプリングされたセッションを含むセッションファイルに記録されたすべてのセッションを出力します。 edb_wait_states_data()を使うべきであることを特定する。8.2.4 edb_wait_states_samplesIN start_ts timestamptz default '-infinity'::timestamptz,IN end_ts timestamptz default 'infinity'::timestamptz,OUT query_id int8,OUT session_id int4,OUT query_start_time timestamptz,OUT sample_time timestamptz,OUT wait_event_type text,OUT wait_event text8.2.5 edb_wait_states_purgeこの関数は、 start_ts 後に作成され、 start_ts前にend_tsされた(回転された) すべてのサンプリングされたデータファイル(クエリ、セッション、および待機イベントサンプル)を end_tsます。IN start_ts timestamptz default '-infinity'::timestamptz,IN end_ts timestamptz default 'infinity'::timestamptz$PGDATA/edb_wait_states実行する前にディレクトリをedb_wait_states_purge()
EDB Clone Schemaは、Advanced Serverの拡張モジュールで、スキーマとそのデータベースオブジェクトをローカルデータベースまたはリモートデータベース(ソースデータベース)から受信側データベース(ターゲットデータベース)にコピーすることができます。
• localcopyschema。この関数は、元のデータベースとは異なるスキーマ名を使用して、元のデータベースのスキーマとそのデータベースオブジェクトのコピーを同じデータベース(ターゲット)に戻します。元のソーススキーマとその結果のコピーが同じデータベース内に常駐する場合は、この関数を使用します。 localcopyschema関数については、第9.2.1項を参照してください。
• localcopyschema_nb。この関数は、 localcopyschemaと同じ目的を実行しますが、バックグラウンドジョブとして実行し、関数が開始された端末を解放します。これは、 非ブロッキング関数と呼ばれます。 localcopyschema_nb関数については、 9.2.2項を参照してください。
• remotecopyschema。この関数は、スキーマとそのデータベースオブジェクトのコピーをソースデータベースから別のターゲットデータベースに作成します。元のソーススキーマと結果コピーが2つの別々のデータベースに存在する場合に、この関数を使用します。別々のデータベースは、同じAdvanced Serverデータベースクラスタまたは別のAdvanced Serverデータベースクラスタに存在できます。 remotecopyschema関数については、 9.2.3項を参照してください。
• remotecopyschema_nb。この関数は、 remotecopyschemaと同じ目的を果たしますが、バックグラウンドジョブとして機能し、関数が開始された端末を解放します。これは、 非ブロッキング関数と呼ばれます。 remotecopyschema_nb関数については、第9.2.4項を参照してください。
• process_status_from_log。この機能は、クローニング機能の状態を表示します。情報は、クローン機能が呼び出されたときに指定されなければならないログファイルから取得されます。 process_status_from_log関数の詳細は、 9.2.5項を参照してください。
• remove_log_file_and_job。この関数は、クローン作成関数によって作成されたログファイルを削除します。この関数は、関数のノンブロッキング形式によって作成されたジョブを削除するためにも使用できます。 remove_log_file_and_job関数については、第9.2.6項を参照してください。
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
• EDB Clone Schemaは 、インストール時にAdvanced Server Dialectダイアログwith OracleとCompatible ある方言が指定されている場合、またはテキストモードインストールまたはクラスタ初期化中に - redwood likeキーワードが含まれている場合にのみAdvanced Serverで Compatibleされます。
• リモート・クローニングの場合、ソース・スキーマ内のオブジェクトが拡張機能に依存している場合 、リモート・クローニング機能を呼び出す前に、 この拡張機能をリモート・データベースのpublicスキーマに作成する必要があります 。
9.1 セットアッププロセス9.1.1 拡張機能とPL / Perlのインストール手順1:次の拡張機能をデータベースにインストールする必要があります。
•
• pgagent拡張を作成する前に、pgAgentがインストールされていることを確認してください 。 Linuxでは、 edb-as xx -pgagent RPMパッケージを使用できます。ここで、 xxはpgAgentをインストールするAdvanced Serverのバージョン番号です。 Windowsでは、StackBuilder Plusを使用してpgAgentをダウンロードしてインストールします。CREATE EXTENSIONコマンドの使用方法の詳細については、PostgreSQLのコアドキュメントを参照してください。ステップ2: postgresql.confファイルを変更します。ステップ3: Perl手続き言語(PL / Perl)をデータベースにインストールし、 CREATE TRUSTED LANGUAGE plperlコマンドを実行する必要があります。 Linuxの場合、使用したPL / Perlをインストールedb-as xx -server-plperl RPMパッケージxx Advanced Serverのバージョン番号です。 Windowsの場合は、EDB Postgres言語パックを使用します。 EDB言語パックについては、次のURLにある「 EDB Postgres言語パックガイド」を参照してください。手順4:スーパーユーザーとしてデータベースに接続し、次のコマンドを実行します。CREATE LANGUAGEコマンドの使用方法の詳細については、PostgreSQLのコアドキュメントを参照してください。9.1.2 設定パラメータの設定9.1.2.1 パフォーマンスの構成パラメータpostgresql.confファイルの設定パラメータには、次のものがあります。
• work_mem。一時ディスクファイルに書き込む前に内部ソート操作およびハッシュテーブルで使用されるメモリ量を指定します。
• maintenance_work_mem。 VACUUM 、 CREATE INDEX 、 ALTER TABLE ADD FOREIGN KEYなど、メンテナンス操作で使用するメモリの最大量を指定します。
• max_worker_processes。システムがサポートできるバックグラウンドプロセスの最大数を設定します。
• checkpoint_timeout。自動WALチェックポイント間の最大時間(秒)。
• checkpoint_completion_target。チェックポイントの完了の目標を、チェックポイント間の合計時間の割合で指定します。
• checkpoint_flush_after。 checkpoint_flush_after実行中にcheckpoint_flush_after bytes以上のbytesが書き込まれた場合は常に、OSがこれらの書き込みを下位のストレージに発行するようにしてください。
• max_wal_size。 WALを自動WALチェックポイント間に拡大できる最大サイズ。
• max_locks_per_transaction。このパラメータは、トランザクションごとに割り当てられるオブジェクトロックの平均数を制御します。個々のトランザクションは、すべてのトランザクションのロックがロックテーブルに収まる限り、より多くのオブジェクトをロックできます。9.1.2.2 ステータスロギングクローニング機能による状態ロギングは、クローン機能を呼び出すときに接続しているデータベースサーバのpostgresql.confファイルのlog_directoryパラメータで指定されたディレクトリにログファイルを作成します 。9.1.3 EDBクローン・スキーマのインストール手順1:以前のバージョンのedb_cloneschema拡張を以前にインストールしていた場合は、次のコマンドを実行する必要があります。ステップ2:次のコマンドを使用して拡張機能をインストールします。9.1.4 外部サーバーおよびユーザー・マッピングの作成ローカルクローン機能 localcopyschemaまたはlocalcopyschema_nbいずれかを使用する場合、必要なパラメータの1つに、データベースサーバを識別するための単一の外部サーバと、クローンされたスキーマの送信元および受信者であるデータベースが含まれます。リモートクローン機能の1つ、 remotecopyschemaまたはremotecopyschema_nb を使用する場合は 、2つの必須パラメータに2つの外部サーバが含まれます。最初のパラメータとして指定された外部サーバーは、クローンされたスキーマのプロバイダであるデータベースと共にソースデータベースサーバーを識別します。 2番目のパラメータとして指定された外部サーバーは、クローンされたスキーマの受信者であるデータベースと共に、ターゲットデータベースサーバーを識別します。ため localcopyschemaとlocalcopyschema_nb機能、ソースとターゲットスキーマは、同じデータベースサーバの同じデータベース内の両方です。したがって、これらの機能には1つの外部サーバーしか定義および指定する必要がありません。この外部サーバーは、 ローカルサーバーとも呼ばれます 。CREATE SERVERコマンドの使用の詳細については、PostgreSQLのコアドキュメントを参照してください。CREATE USER MAPPINGコマンドの使用方法の詳細については、PostgreSQLのコアドキュメントを参照してください。次の psqlコマンドは、外部サーバーとユーザーのマッピングを示しています。データベーススーパーユーザー enterprisedbがクローン機能を呼び出すと、データベースユーザーenterprisedbとパスワードが使用され、 localhost local_serverにポート5444でデータベースedbに接続します。この場合、マッピングされたデータベースユーザー enterprisedbおよびデータベースユーザーenterprisedbは、ローカルのedbデータベースに接続するために使用され、同一のデータベースユーザーとなりますが、絶対的な要件ではありません。remotecopyschemaとremotecopyschema_nb機能、ソースとターゲットスキーマは、同じまたは異なるデータベース・サーバの異なるデータベースです。したがって、これらの機能には、2つの外部サーバーを定義して指定する必要があります。次の psqlコマンドは、外部サーバとユーザのマッピングを示しています。データベーススーパーユーザー enterprisedbがクローン機能を呼び出すと、パスワードtgtpassword持つデータベースユーザーtgtuserを使用して、 localhost tgt_serverにポート5444でデータベースtgtdbに接続します。さらに、パスワードsrcpasswordを持つデータベースユーザ srcuserは、ホストsrc_server 192.168.2.28 src_serverに接続し、ポート5444を使用してデータベースsrcdb接続します。注:必ずpg_hba.confソース・データベース・実行しているデータベース・サーバのファイルsrcdbターゲットサーバの場所(アドレスからの接続許可する適切なエントリ有する192.168.2.27データベースユーザーとの接続次の例では) srcuserに含まれていましたソースサーバーとデータベースを定義する外部サーバーsrc_serverユーザーマッピング。
9.2 EDBクローンスキーマ関数
• ターゲット・データベースまたはローカル・データベースの外部サーバーのCREATE USER MAPPINGコマンドで定義されたデータベース・スーパーユーザーとして、ターゲット・データベースまたはローカル・データベースに接続しています。 localcopyschemaまたはlocalcopyschema_nb関数のユーザマッピングについては、第9.1.4.1項を参照してください。 remotecopyschemaまたはremotecopyschema_nb関数のユーザー・マッピングの詳細は、第9.1.4.2項を参照してください。
• edb_utilスキーマは、検索パス内にある、またはクローニング機能を用いて呼び出されるedb_util接頭辞。
• リモート・コピー機能を使用する場合、 on_tblspaceパラメータをtrueに設定すると、ソース・スキーマ内のオブジェクトによって参照されるすべての表領域がターゲット・データベース・クラスタに格納されます。ターゲットスキーマ。これは、クローニングプロセスの失敗を引き起こします。
• リモートコピー機能を使用する場合、 copy_aclsパラメータをtrueに設定すると、ソーススキーマのオブジェクトに対するGRANT権限を持つすべてのロールがターゲットデータベースクラスタに存在します。そうでない場合、それらのロールに対する権限の付与はターゲットで失敗しますスキーマこれは、クローニングプロセスの失敗を引き起こします。9.2.1 localcopyschemalocalcopyschema関数内に指定されたローカル・データベース内にコピースキーマとそのデータベース・オブジェクトsource_fdw同じデータベース内で指定されたターゲット・スキーマにソース・スキーマから外部サーバ。[, on_tblspace BOOLEAN[, verbose_on BOOLEAN[, copy_acls BOOLEAN[, worker_count INTEGER ]]]]source_fdw 、 source_schema 、 target_schema 、およびlog_filename 、他のすべてのパラメータはオプションでありながら必要なパラメータです。ファンクションからの情報が記録されるログ・ファイルの名前。ログファイルは 、 postgresql.confファイルのlog_directory設定パラメータで指定されたディレクトリの下に作成されます。BOOLEAN値を使用して、データベース・オブジェクトを表領域内に作成するかどうかを指定します。 falseを指定すると、 TABLESPACE句は、ターゲット・スキーマに追加されたときに、該当するCREATE DDL文に含まれません。 trueを指定すると、ターゲット・スキーマに追加するときに、 TABLESPACE句がCREATE DDL文に含まれます。 on_tblspaceパラメータを省略すると、デフォルト値はfalse 。BOOLEAN値を使用して、ターゲット・スキーマにオブジェクトを作成するときにDDLをlog_filenameに出力するかどうかを指定します。 falseを指定すると、DDLは出力されません。 trueを指定すると、DDLが出力されます。省略された場合、デフォルト値はfalseです。BOOLEAN値を使用して、ターゲット・スキーマでオブジェクトを作成する際にアクセス制御リスト(ACL)を含めるかどうかを指定します。アクセス制御リストは、 GRANT特権文のセットです。 falseを指定すると、アクセス制御リストはターゲット・スキーマに含まれません。 trueを指定すると、アクセス制御リストがターゲット・スキーマに含まれます。 copy_aclsパラメータを省略すると、デフォルト値はfalse 。次の例では、スキーマのクローニング示す edbスキーマターゲットにデータベース・オブジェクトのセットを含むedbcopyデータベース内の両方、 edbによって定義されるようlocal_server 。
• データベース・サーバーが実行されているホスト: localhost
• データベース・サーバーのポート: 5444
•
• ソーススキーマ: edb
• ターゲットスキーマ: edbcopy
• 9.2.2 localcopyschema_nblocalcopyschema_nb関数コピースキーマと内に指定されたローカルデータベース内のデータベースオブジェクトsource_fdw同じデータベース内で指定されたターゲット・スキーマにソース・スキーマから外部サーバが、pgAgentに提出されたジョブ等の非ブロッキング様式です。[, on_tblspace BOOLEAN[, verbose_on BOOLEAN[, copy_acls BOOLEAN[, worker_count INTEGER ]]]]INTEGER値ジョブIDは、pgAgentに投入されたジョブのための関数によって返されます。関数が失敗すると、nullが返されます。source_fdw 、 source 、 target 、およびlog_filename 、他のすべてのパラメータはオプションでありながら必要なパラメータです。ファンクションからの情報が記録されるログ・ファイルの名前。ログファイルは 、 postgresql.confファイルのlog_directory設定パラメータで指定されたディレクトリの下に作成されます。BOOLEAN値を使用して、データベース・オブジェクトを表領域内に作成するかどうかを指定します。 falseを指定すると、 TABLESPACE句は、ターゲット・スキーマに追加されたときに、該当するCREATE DDL文に含まれません。 trueを指定すると、ターゲット・スキーマに追加するときに、 TABLESPACE句がCREATE DDL文に含まれます。 on_tblspaceパラメータを省略すると、デフォルト値はfalse 。BOOLEAN値を使用して、ターゲット・スキーマにオブジェクトを作成するときにDDLをlog_filenameに出力するかどうかを指定します。 falseを指定すると、DDLは出力されません。 trueを指定すると、DDLが出力されます。省略された場合、デフォルト値はfalseです。BOOLEAN値を使用して、ターゲット・スキーマでオブジェクトを作成する際にアクセス制御リスト(ACL)を含めるかどうかを指定します。アクセス制御リストは、 GRANT特権文のセットです。 falseを指定すると、アクセス制御リストはターゲット・スキーマに含まれません。 trueを指定すると、アクセス制御リストがターゲット・スキーマに含まれます。 copy_aclsパラメータを省略すると、デフォルト値はfalse 。pgAgentが実行されていない場合は、次のように起動できます。 pgagentプログラムファイルは次の場所にあります。 bin Advanced Serverのインストールディレクトリのサブディレクトリ。注: pgagent -l 2オプションは、 DEBUGモードでpgAgentを開始します。 DEBUGモードでは、 -sオプションで指定されたログファイルに継続的なデバッグ情報が記録されます。 -lオプションにはより低い値を使用するか、より少ない情報を記録するために完全に省略します。localcopyschema_nb関数は、として示されるジョブIDを返し4の例です。9.2.3 remotecopyschemaremotecopyschema関数内に指定されたリモート・ソース・データベース内のソース・スキーマからコピースキーマとそのデータベース・オブジェクトsource_fdw内で指定されたローカル・ターゲット・データベース内のターゲットスキーマに外部サーバtarget_fdw外部サーバ。[, on_tblspace BOOLEAN[, verbose_on BOOLEAN[, copy_acls BOOLEAN[, worker_count INTEGER ]]]]source_fdw 、 target_fdw 、 source_schema 、 target_schema 、およびlog_filename 、他のすべてのパラメータはオプションでありながら必要なパラメータです。ファンクションからの情報が記録されるログ・ファイルの名前。ログファイルは 、 postgresql.confファイルのlog_directory設定パラメータで指定されたディレクトリの下に作成されます。BOOLEAN値を使用して、データベース・オブジェクトを表領域内に作成するかどうかを指定します。 falseを指定すると、 TABLESPACE句は、ターゲット・スキーマに追加されたときに、該当するCREATE DDL文に含まれません。 trueを指定すると、ターゲット・スキーマに追加するときに、 TABLESPACE句がCREATE DDL文に含まれます。 on_tblspaceパラメータを省略すると、デフォルト値はfalse 。BOOLEAN値を使用して、ターゲット・スキーマにオブジェクトを作成するときにDDLをlog_filenameに出力するかどうかを指定します。 falseを指定すると、DDLは出力されません。 trueを指定すると、DDLが出力されます。省略された場合、デフォルト値はfalseです。BOOLEAN値を使用して、ターゲット・スキーマでオブジェクトを作成する際にアクセス制御リスト(ACL)を含めるかどうかを指定します。アクセス制御リストは、 GRANT特権文のセットです。 falseを指定すると、アクセス制御リストはターゲット・スキーマに含まれません。 trueを指定すると、アクセス制御リストがターゲット・スキーマに含まれます。 copy_aclsパラメータを省略すると、デフォルト値はfalse 。次の例では、スキーマのクローニング示す srcschemaデータベース内srcdbによって定義されるようsrc_serverスキーマターゲットにtgtschemaデータベース内tgtdbによって定義されるようtgt_server 。
• ソースデータベースサーバーを実行しているホスト: 192.168.2.28
• ソースデータベースサーバーのポート: 5444
• クローンのデータベースソース: srcdb
• ソーススキーマ: srcschema
• ターゲット・データベース・サーバーが実行されているホスト: localhost
• ターゲットデータベースサーバーのポート: 5444
• クローンのデータベースターゲット: tgtdb
• ターゲットスキーマ: tgtschema
• とき remotecopyschema関数が呼び出された、4人のバックグラウンドの労働者が指定されました。9.2.4 remotecopyschema_nbremotecopyschema_nb関数コピー内で指定されたリモート・ソース・データベース内のソース・スキーマからスキーマとそのデータベース・オブジェクトsource_fdw内で指定されたローカル・ターゲット・データベース内のターゲットスキーマに外部サーバtarget_fdw外部サーバが、非ブロッキング様式でジョブがpgAgentに送信されました。[, on_tblspace BOOLEAN[, verbose_on BOOLEAN[, copy_acls BOOLEAN[, worker_count INTEGER ]]]]INTEGER値ジョブIDは、pgAgentに投入されたジョブのための関数によって返されます。関数が失敗すると、nullが返されます。source_fdw 、 target_fdw 、 source 、 target 、およびlog_filename 、他のすべてのパラメータはオプションでありながら必要なパラメータです。ファンクションからの情報が記録されるログ・ファイルの名前。ログファイルは 、 postgresql.confファイルのlog_directory設定パラメータで指定されたディレクトリの下に作成されます。BOOLEAN値を使用して、データベース・オブジェクトを表領域内に作成するかどうかを指定します。 falseを指定すると、 TABLESPACE句は、ターゲット・スキーマに追加されたときに、該当するCREATE DDL文に含まれません。 trueを指定すると、ターゲット・スキーマに追加するときに、 TABLESPACE句がCREATE DDL文に含まれます。 on_tblspaceパラメータを省略すると、デフォルト値はfalse 。BOOLEAN値を使用して、ターゲット・スキーマにオブジェクトを作成するときにDDLをlog_filenameに出力するかどうかを指定します。 falseを指定すると、DDLは出力されません。 trueを指定すると、DDLが出力されます。省略された場合、デフォルト値はfalseです。BOOLEAN値を使用して、ターゲット・スキーマでオブジェクトを作成する際にアクセス制御リスト(ACL)を含めるかどうかを指定します。アクセス制御リストは、 GRANT特権文のセットです。 falseを指定すると、アクセス制御リストはターゲット・スキーマに含まれません。 trueを指定すると、アクセス制御リストがターゲット・スキーマに含まれます。 copy_aclsパラメータを省略すると、デフォルト値はfalse 。次のコマンドは、ターゲットデータベース tgtdb 上でpgAgentを開始します 。 pgagentプログラムファイルは、Advanced Serverインストールディレクトリのbinサブディレクトリにあります。remotecopyschema_nb関数は、として示されるジョブIDを返し2例です。9.2.5 process_status_from_logprocess_status_from_log関数は、ログファイルからクローニング機能のステータスを提供します。
9.2.6 remove_log_file_and_jobremove_log_file_and_job機能は、スキーマのクローニング機能によって作成されたログファイルと、非ブロッキング機能によって作成されたジョブを削除することによってクリーンアップタスクを実行します。{ log_file TEXT |
10 PL / JavaPL / Javaパッケージは、JDBCインタフェースを介してJavaストアド・プロシージャ、トリガ、およびファンクションへのアクセスを提供します。特に指定のないかぎり、次のセクションで説明するコマンドとパスは、 edb-as xx -pljava RPMパッケージ( xxはAdvanced Serverのバージョン番号)でインストールを実行したことを前提としています 。
pljava.classpath = ' path_to_pljava.jar 'pljava.libjvm_location = ' path_to_libjvm.so '手順2:データベースサーバーを再起動します。ステップ3: CREATE EXTENSIONコマンドを使用してPL / Javaをインストールできます。 PL / Java拡張機能をインストールするには、psqlまたはpgAdminクライアントを使用してPL / Javaをインストールするデータベースにログインし、次のコマンドを実行します。ステップ4: PL / Javaがインストールされていることを確認するには、次のコマンドを実行します。edb-psqlクライアントがあることを示す2つの行を表示javaとjavau (Javaの信頼できない)は、データベースにインストールされています。
ステップ1: postgresql.confファイルを編集し、次の設定を追加(または変更)します。pljava.classpath = ' POSTGRES_INSTALL_HOME \lib\pljava.jar'pljava.libjvm_location = ' path_to_libjvm.so 'どこ POSTGRES_INSTALL_HOME Advanced Serverのインストールの場所を指定します。たとえば、次の設定はデフォルトインストールの設定です。手順2:データベースサーバーを再起動します。手順3:サーバーで使用されるPATH設定を変更し、次の2つのエントリを追加します。ステップ4: Postgres CREATE EXTENSIONコマンドを使用してPL / Javaをインストールします。インストール・スクリプトを実行するには、psqlまたはpgAdminクライアントを使用して、PL / Javaをインストールするデータベースに接続し、次のコマンドを実行します。ステップ5: PL / Javaがインストールされていることを確認するには、次のコマンドを実行します。
10.3 PL / Javaの使用PL / Javaプログラムを作成するには、少なくとも1つの静的メソッドを含むJavaクラスを作成してから、そのクラスを .classまたは.jarファイルにコンパイルする必要があります。次に、 CREATE FUNCTIONコマンドを使用してSQL内のJava関数を宣言します。 CREATE FUNCTIONコマンドは、関数にSQL名を与え、コンパイルされたクラス(およびメソッド名)をその関数名に関連付けます。手順1:次のコードサンプルをHelloWorld.javaという名前のファイルに保存します。ステップ2:ファイルをコンパイルします。手順3: helloworld.jarというアーカイブファイル(JARファイル)を作成します。ステップ4: edb-psqlクライアントを開き、次のコマンドでjarファイルをインストールします。SELECT sqlj.install_jar('file:/// file_path /helloworld.jar', 'helloworld', true);ステップ5:クラスパスを次のように設定します。sqlj.classpath_entryテーブルは現在のエントリが含まれますhelloworldクラスファイルを。ステップ6: Javaを使用してjarファイルで宣言された静的関数を呼び出す関数を作成します。ステップ7:関数を実行する:
Advanced Serverには、拡張されたSQL機能とその他の柔軟性と利便性を提供するさまざまな機能が含まれています 。この章では、これらの追加について説明します。
11.1 コメントPostgreSQLの COMMENTコマンドでサポートされているオブジェクトにコメントするだけでなく、Advanced Serverは追加のオブジェクトタイプに関するコメントをサポートしています。サポートされている完全な構文は次のとおりです。COMMENT ON
{
AGGREGATE aggregate _ name ( aggregate _ signature ) |
CAST ( source _ type AS target _ type ) |
COLLATION object _ name |
COLUMN relation _ name . column _ name |
CONSTRAINT constraint _ name ON table _ name |
CONSTRAINT constraint _ name ON DOMAIN domain _ name |
CONVERSION object _ name |
DATABASE object _ name |
DOMAIN object _ name |
EXTENSION object _ name |
EVENT TRIGGER object _ name |
FOREIGN DATA WRAPPER object _ name |
FOREIGN TABLE object _ name |
FUNCTION func _ name ([[ argmode ] [ argname ] argtype [, ...]])|
INDEX object _ name |
LARGE OBJECT large _ object _ oid |
MATERIALIZED VIEW object _ name |
OPERATOR operator _ name (left_type, right_type) |
OPERATOR CLASS object _ name USING index _ method |
OPERATOR FAMILY object _ name USING index _ method |
PACKAGE object _ name
POLICY policy _ name ON table _ name |
[ PROCEDURAL ] LANGUAGE object _ name |
PROCEDURE proc _ name [([[ argmode ] [ argname ] argtype [, ...]])]
PUBLIC SYNONYM object _ name
ROLE object _ name |
RULE rule _ name ON table _ name |
SCHEMA object _ name |
SEQUENCE object _ name |
SERVER object _ name |
TABLE object _ name |
TABLESPACE object _ name |
TEXT SEARCH CONFIGURATION object _ name |
TEXT SEARCH DICTIONARY object _ name |
TEXT SEARCH PARSER object _ name |
TEXT SEARCH TEMPLATE object _ name |
TRANSFORM FOR type _ name LANGUAGE lang _ name |
TRIGGER trigger _ name ON table _ name |
TYPE object _ name |
VIEW object _ name
} IS 'text'* |
[ argmode ] [ argname ] argtype [ , ... ] |
[ [ argmode ] [ argname ] argtype [ , ... ] ]
ORDER BY [ argmode ] [ argname ] argtype [ , ... ]集約についてのコメントを作成するには、 AGGREGATE句を含めます 。 aggregate _ nameはaggregate name指定し、 aggregate _ signatureは関連する署名を次のいずれかの形式で指定します。* |
[ argmode ] [ argname ] argtype [ , ... ] |
[ [ argmode ] [ argname ] argtype [ , ... ] ]
ORDER BY [ argmode ] [ argname ] argtype [ , ... ]どこ argmode is the mode of a function, procedure, or aggregate argument; argmode may be IN , OUT , INOUT , or VARIADIC , or VARIADIC . If omitted, the default is IN .argname is the name of an aggregate argument.argtype is the data type of an aggregate argument.キャストに関するコメントを作成するには、 CAST句を含めます 。 When creating a comment about a cast, source_type When creating a comment about a cast, specifies the source data type of the cast, and specifies the target data type of the cast. target_type specifies the source data type of the cast, and specifies the target data type of the cast.列に関するコメントを作成するには、 COLUMN句を含めます。 column_name specifies name of the column to which the comment applies. relation_name is the table, view, composite type, or foreign table in which a column resides.clause to add a comment about a constraint. When creating a comment about a constraint, Include the CONSTRAINT clause to add a comment about a constraint. When creating a comment about a constraint, Include the clause to add a comment about a constraint. When creating a comment about a constraint, constraint_name specifies the name of the constraint; table_name or domain_name specifies the name of the table or domain on which the constraint is defined. domain_name specifies the name of the table or domain on which the constraint is defined.clause to add a comment about a function. Include the FUNCTION clause to add a comment about a function. Include the clause to add a comment about a function. func _ nameは、関数の名前を指定します。 argmode specifies the mode of the function; argmode may be IN , OUT , INOUT , or VARIADIC , or VARIADIC . If omitted, the default is IN . argname specifies the name of a function, procedure, or aggregate argument. argtype specifies the data type of a function, procedure, or aggregate argument.large_object_oid is the system-assigned OID of the large object about which you are commenting.オペレータに関するコメントを追加するには、 OPERATOR句を含めます 。 operator _ nameは、コメントしている演算子の名前(スキーマ修飾名でも可)を指定します。 left _ typeおよびright _ type are the (optionally schema-qualified) data type(s) of the operator's arguments.演算子クラスについてのコメントを追加するには、 OPERATOR CLASS句を含めます 。 object _ nameは、コメントしている演算子の名前(スキーマ修飾名でも可)を指定します。 index_method specifies the associated index method of the operator class.OPERATOR FAMILYについてのコメントを追加するには、 OPERATOR FAMILY句を含めます 。 object _ nameは、コメントしている演算子ファミリの名前(スキーマ修飾名でも可)を指定します。 index_method specifies the associated index method of the operator family.clause to add a comment about a procedure. Include the PROCEDURE clause to add a comment about a procedure. Include the clause to add a comment about a procedure. proc _ name specifies the name of the procedure. argmode specifies the mode of the procedure; argmode may be IN , OUT , INOUT , or VARIADIC , or VARIADIC . If omitted, the default is IN . argname specifies the name of a function, procedure, or aggregate argument. argtype specifies the data type of a function, procedure, or aggregate argument.Include the RULE clause to specify a COMMENT oルールNAが. rule _ name specifies the name of the rule, and name specifies the name of the table on which the rule is defined. table _ name specifies the name of the table on which the rule is defined.Include the TRANSFORM Include the FOR clause to specify a on a TRANSFORM COMMENT clause to specify a . type _ name specifies the name of the data type of the transform and name specifies the name of the language of the transform. lang _ name specifies the name of the language of the transform.TRIGGER clause to specify a Include the COMMENT o NAトリガclause to specify a . trigger _ name specifies the name of the trigger, and name specifies the name of the table on which the trigger is defined. table _ name specifies the name of the table on which the trigger is defined.The following example adds a comment to a table named new_emp The following example adds a comment to a table named :COMMENT command, please see the PostgreSQL core documentation at: For more information about using the command, please see the PostgreSQL core documentation at:
11.2 機能バージョン()の出力version()関数のテキスト文字列出力は、製品の名前、バージョン、およびそれがインストールされているホストシステムを表示します。Advanced Serverの場合、 version()出力形式は、PostgreSQLコミュニティバージョンと似た形式ですversion() Advanced Serverバージョン10以前のように、最初のテキストワードはPostgreSQLでEnterpriseDBではなく)。
11.3 SQL ServerのdboスキーマAdvanced Server 11より前は、 dbo という名前のシステムカタログが利用可能でした。 dboシステムカタログには、Microsoft®SQLServer®と類似しているデータベースオブジェクトのビューが含まれていました。
12 システムカタログテーブル
12.1 edb_diredb _ dir表は、で作成したディレクトリを指し、各エイリアスの1つの行が含まCREATE DIRECTORYコマンド。ディレクトリは、ユーザーがホストファイルシステムに限定してアクセスできるようにするパス名のエイリアスです。ディレクトリを使用して、ファイルシステム内の特定のディレクトリツリーにユーザを囲むことができます。例えば、 UTL _ FILEパッケージには、ホストファイルシステム内のファイルおよびディレクトリを読み書きするためのユーザを許可する機能を提供していますが、唯一のデータベース管理者が経由へのアクセスを許可されたパスにアクセスすることができますCREATE DIRECTORYコマンドを。
edb_all_resource_groups表は、で作成された各リソースグループの1つの行を含んCREATE RESOURCE GROUPコマンドと各リソースグループ内のアクティブなプロセスの数を表示します。
12.3 edb_password_historyedb _ password_history表は、各パスワード変更のために1行が含まれます。この表は、クラスタ内のすべてのデータベースで共有されます。
12.4 edb_policyedb _ policyテーブルは、ポリシーごとに1つの行が含ま。
12.5 edb_profileedb _ profileの表は、使用可能なプロファイルに関する情報を格納します。 edb _ profilesは、クラスタ内のすべてのデータベースで共有されます。
12.6 edb_redaction_columnカタログ edb_redaction_columnは、表の列にアタッチされたデータ変更ポリシーの情報が格納されます。
注:表の編集ポリシーedb_redaction_column.rdpolicyidが有効になっていて、編集ポリシー表現edb_redaction_policy.rdexprがtrueと評価された場合は、記述された列が編集されます。
12.7 edb_redaction_policyカタログ edb_redaction_policyは、表の編集ポリシーの情報が保管されます。
注:テーブルが有効で、式が真に評価された場合は、データ変更ポリシーがテーブルに適用されます。
12.8 edb_resource_groupedb_resource_group表は、で作成された各リソースグループに対して1つの行含まれているCREATE RESOURCE GROUPコマンド。
12.9 edb_variableedb _ variableテーブルには、各パッケージレベルの変数(パッケージ内で宣言された各変数)のための1つの行が含ま。
12.10 pg_synonympg _ synonymテーブルには、各同義語で作成するための1つの行含まCREATE SYNONYMコマンドまたはCREATE PUBLIC SYNONYMコマンド。
synowner Replaces . Contains the OID of the row where the synonym is stored . Contains the OID of the pg_namespace row where the synonym is stored . Contains the OID of the pg_namespace . Contains the OID of the
product _ component _ versionテーブルは、特徴の互換性についての情報を含みます。アプリケーションはインストール時または実行時にこのテーブルを照会して、このデプロイメントでアプリケーションで使用される機能が使用可能であることを確認できます。
13 高度なサーバーキーワードキーワードは、Advanced Serverパーサによって特別な意味または関連があると認識される単語です。 pg_get_keywords()関数を使用すると、Advanced Serverのキーワードの最新リストを取得できます 。pg_get_keywordsは、Advanced Serverによって認識されるキーワードを含むテーブルを返します。
• word列には、キーワードを表示します。
• catcode列には、カテゴリコードを表示します。
• catdesc列には、キーワードが属するカテゴリの簡単な説明が表示されます。名前が二重引用符で囲まれている場合は、識別子に任意の文字を使用できます。 pg_get_keywords()関数を選択的に照会して、特定のカテゴリに属するAdvanced Serverキーワードの最新リストを取得することができます。どこ code次のとおりです。R - 言葉が予約されています。予約されたキーワードは決して識別子として使用できません。それらはサーバーで使用するために予約されています。U - その言葉は予約されていません。未予約語は、一部のコンテキストでは内部的に使用されますが、データベースオブジェクトの名前として使用できます。T - このワードは内部的に使用されますが、関数またはタイプの名前として使用できます。C - この単語は内部的に使用され、関数や型の名前として使用することはできません。
目次