EDB Postgres™Advanced Server Guide
 
 
EDB Postgres™Advanced Server 11
2018年11月20日
 
1 はじめに
このガイドでは、 EDB Postgres Advanced Server(Advanced Server) の機能について説明します
Advanced Serverは、オープンソースのPostgreSQLデータベースに拡張機能を追加します。拡張機能は、データベース管理、拡張SQL機能、データベースとアプリケーションのセキュリティー、パフォーマンスの監視と分析、およびアプリケーション開発ユーティリティーをサポートします。このガイドでは、Advanced Server専用の機能について説明します。
強化された互換性機能。第2章では、Advanced Serverでサポートされている互換性機能の概要について説明します。
データベース管理。第3章では、データベース管理者に役立つ機能やツールについて説明します。
セクション3.2で説明した索引アドバイザーは、アプリケーションのパフォーマンスを向上させるために表に必要な追加索引を判別するのに役立ちます。

セクション3.3で説明したSQLプロファイラは、アプリケーションで不適切に実行されているSQLクエリを検出して診断します。
3.4節で説明するpgsnmpdは、Advanced Serverの現在の状態に関する階層的な監視情報を返すSNMPエージェントです。
セキュリティ。第4章では、Advanced Serverでサポートされているセキュリティ機能について説明します。
セクション4.1で説明したSQL / Protectは、SQLインジェクション攻撃に対する保護機能を提供します。

セクション4.2で説明した仮想プライベートデータベースは、きめ細かな行レベルのアクセスを提供します。
セクション4.3で説明したsslutilsは、SSL証明書生成関数を提供します。
セクション4.4で説明されているデータの改ざんは、機密データの暴露から保護します。
EDBリソースマネージャ。第5章では、Advanced Serverプロセスによるシステムリソースの使用を制御する機能を提供するEDB Resource Manager機能について説明します。
5.1節で説明するリソースグループは、リソース制限を定義できるグループを作成して維持する方法を示しています。
セクション5.2で説明されているCPU使用量制限は、Advanced ServerプロセスによるCPU使用率を制御する方法を提供します。
セクション5.3で説明したDirty Buffer Throttlingは、Advanced Serverプロセスによる共有バッファのダーティレートを制御する方法を提供します。
libpq Cライブラリ。6章で説明するlibpq Cライブラリは、Advanced Server用のCアプリケーションプログラミングインタフェース(API)言語です。
PLデバッガ。7章で説明したPLデバッガは、PL / pgSQL用のグラフィカルなデバッグツールです。
パフォーマンス分析とチューニング。8章では、アプリケーションおよびデータベース・サーバーのパフォーマンスを分析および改善するためのさまざまなツールについて説明します。
セクション8.1で説明されているDynatuneは、アプリケーション使用のタイプに応じてAdvanced Serverを設定するためのすばやく簡単な手段を提供します。
セクション8.2で説明したEDB待機状態は、パフォーマンス診断のために待機イベントやその他のデータを取得する方法を提供します。
EDBクローンスキーマ。9章では、単一のデータベース内またはあるデータベースから別のデータベースにスキーマとそのデータベースオブジェクトをコピーする機能を提供するEDBクローンスキーマ機能について説明します。
PL / Java。10章で説明するPL / Javaは、JDBCインタフェースを使用してJavaストアドファンクション、プロシージャ、およびトリガにアクセスするためのパッケージです。
拡張されたSQLおよびその他のその他の機能11章では、拡張されたSQLの機能と、柔軟性と利便性を高めるその他の機能について説明します。
システムカタログテーブル。12章には、Advanced Server固有のデータベース・オブジェクト用に追加された追加システム・カタログ表が含まれています。
高度なサーバーのキーワード。13章では、Advanced Serverがキーワードとして認識する単語について説明します。
Advanced ServerとPostgreSQLで共有される機能については、PostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/index.html
 
1.1 新機能
Advanced Server 11を作成するために、EDB Postgres Advanced Server 10で以下の機能が変更されました。
Advanced Serverは、データベースにdboシステムカタログを作成しなくなりました。詳細は、 11.3項を参照してください。
Advanced Serverは、機密データの特定のユーザーへの公開を制限するための技術であるデータの変更を サポートします。データを編集すると、そのようなユーザーに表示されるデータが変更されます。これは、機密データを持つテーブルの修正ポリシーを定義することによって実現されます。詳細は、 4.4項を参照してください。
Advanced Serverは 、データベース接続、ログインしているユーザー、実行中のクエリ、および待機イベントなどの情報を収集する定期的な間隔で各実行中のセッションを調査するバックグラウンドワーカーであるEDB待ち状態を サポートするようになりました。詳細は、 8.2項を参照してください。
Advanced Serverでは、 edb_custom_plan_triesパラメータを-1 設定することで、カスタムプランの生成を無限に試行できるようになりました 。詳細は、第3.1.3.5.1項を参照してください。
version()関数の出力形式は 、PostgreSQLコミュニティバージョンの出力と一貫して表示されるように変更されました。詳細は、 11.2項を参照してください。
edb _ filter _ log 使用することができ logredact _ password _ commands拡張子を使用して、ログファイルから保存されたパスワードを変更するようサーバーに指示します。詳細は、 3.5.7項を参照してください
1.2 このガイドで使用される表記規則
このマニュアルでは、さまざまなコマンド、文、プログラム、例などの意味と使用法を明確にするために、特定の表記規則が使用されています。このセクションでは、これらの規則の概要を説明します。
以下の説明では、 用語は、言語キーワード、ユーザ提供値、リテラルなどの任意の単語または単語群を指す。用語の正確な意味は、それが使用される文脈に依存する。
イタリック体のフォントでは、通常、最初に定義された文章に新しい用語が導入されています。
Fixed-width (mono-spaced) fontは、SQLコマンド、例で使用されている特定のテーブルとカラム名、プログラミング言語キーワード、ディレクトリパスとファイル名、パラメータ値など、文字通り与えなければならない用語に使用されます。 postgresql.confSELECT * FROM emp;
Italic fixed-width fontは、ユーザーが実際の使用で値を置き換える必要がある用語に使用されます。たとえば、 DELETE FROM table_name ;
角括弧[]は、囲まれた用語の1つまたはいずれかが置換されている可能性があることを示します。たとえば、 [ a | b ] 、「 a 」または「 b 」のいずれかを選択するか、またはどちらも選択しないことを意味します。
中括弧{}は、囲まれた選択肢のうちの1つを指定する必要があることを示します。たとえば、 { a | b } 、 " a "または " b "のうちの1つを指定する必要があることを意味します。
楕円形...とは、進行中の用語を繰り返すことができることを意味します。たとえば、 [ a | b ] ...は、あなたがシーケンス「 baaba 」を持っているかもしれないことを意味します。
1.3 このガイドで使用されているその他の表記規則
以下は、この文書全体で使用されている他の表記規則の一覧です。
このドキュメントの情報の一部は、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 このガイドで使用されているサンプルについて
このガイドの例は、以下に示すタイプとバックグラウンドで示されています。
Examples and output from examples are shown in fixed-width, blue font on a light blue background.
この例では、 Advanced Serverのインストール時に作成およびロードされるサンプル表 deptempおよびjobhist 使用しています
サンプルデータベース内のテーブルとプログラムは、次のスクリプトを実行することによっていつでも再作成できます。
/usr/edb/as xx /share /pg-sample.sql
どこ xx Advanced Serverのバージョン番号です。
さらに、Oracleデータベースと互換性のある構文を使用して作成されたデータベース・オブジェクトを含むスクリプトが、同じディレクトリにあります。このスクリプトファイルは edb-sample.sqlです。
スクリプト:
テーブルとプログラムは、現在のユーザーがテーブルとプロシージャを作成する権限を持っている検索パスの最初のスキーマに作成されます。検索パスを表示するには、次のコマンドを発行します。
SHOW SEARCH_PATH;
PSQLコマンドを使用して検索パスを変更できます。
1.4.1 サンプルデータベースの説明
サンプルデータベースは、組織内の従業員を表します。従業員、部署、および従業員の履歴レコードの3種類のレコードが含まれています。
各従業員には、識別番号、名前、雇用日、給与、および管理者があります。一部の従業員は給与に加えて手数料をもらう。従業員関連の情報はすべて empテーブルに格納されます。
サンプル企業は地域的に多様なため、部門の所在を追跡します。各社員は部門に割り当てられています。各部門は、固有の部門番号と短い名前で識別されます。各部門は1つの場所に関連付けられています。部門に関するすべての情報は、 deptテーブルに保管されます。
同社はまた、従業員が保有する雇用に関する情報を追跡します。従業員の中には、長年にわたり会社と一緒にいて、異なるポジション、昇給、交換部門などを持っている人もいます。従業員ステータスの変更が発生すると、会社は元のポジションの終了日を記録します。新しいジョブレコードが追加され、開始日と新しい職務、部門、給与、およびステータス変更の理由が記録されます。すべての従業員履歴は、 jobhistテーブルに保持されます。
次は pg-sample.sqlスクリプトです。
SET datestyle TO 'iso, dmy';
 
--
-- Script that creates the 'sample' tables, views
-- functions, triggers, etc.
--
-- Start new transaction - commit all or nothing
--
BEGIN;
--
-- Create and load tables used in the documentation examples.
--
-- Create the 'dept' table
--
CREATE TABLE dept (
deptno NUMERIC(2) NOT NULL CONSTRAINT dept_pk PRIMARY KEY,
dname VARCHAR(14) CONSTRAINT dept_dname_uq UNIQUE,
loc VARCHAR(13)
);
--
-- Create the 'emp' table
--
CREATE TABLE emp (
empno NUMERIC(4) NOT NULL CONSTRAINT emp_pk PRIMARY KEY,
ename VARCHAR(10),
job VARCHAR(9),
mgr NUMERIC(4),
hiredate DATE,
sal NUMERIC(7,2) CONSTRAINT emp_sal_ck CHECK (sal > 0),
comm NUMERIC(7,2),
deptno NUMERIC(2) CONSTRAINT emp_ref_dept_fk
REFERENCES dept(deptno)
);
--
-- Create the 'jobhist' table
--
CREATE TABLE jobhist (
empno NUMERIC(4) NOT NULL,
startdate TIMESTAMP(0) NOT NULL,
enddate TIMESTAMP(0),
job VARCHAR(9),
sal NUMERIC(7,2),
comm NUMERIC(7,2),
deptno NUMERIC(2),
chgdesc VARCHAR(80),
CONSTRAINT jobhist_pk PRIMARY KEY (empno, startdate),
CONSTRAINT jobhist_ref_emp_fk FOREIGN KEY (empno)
REFERENCES emp(empno) ON DELETE CASCADE,
CONSTRAINT jobhist_ref_dept_fk FOREIGN KEY (deptno)
REFERENCES dept (deptno) ON DELETE SET NULL,
CONSTRAINT jobhist_date_chk CHECK (startdate <= enddate)
);
--
-- Create the 'salesemp' view
--
CREATE OR REPLACE VIEW salesemp AS
SELECT empno, ename, hiredate, sal, comm FROM emp WHERE job = 'SALESMAN';
--
-- Sequence to generate values for function 'new_empno'.
--
CREATE SEQUENCE next_empno START WITH 8000 INCREMENT BY 1;
--
-- Issue PUBLIC grants
--
--GRANT ALL ON emp TO PUBLIC;
--GRANT ALL ON dept TO PUBLIC;
--GRANT ALL ON jobhist TO PUBLIC;
--GRANT ALL ON salesemp TO PUBLIC;
--GRANT ALL ON next_empno TO PUBLIC;
--
-- Load the 'dept' table
--
INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK');
INSERT INTO dept VALUES (20,'RESEARCH','DALLAS');
INSERT INTO dept VALUES (30,'SALES','CHICAGO');
INSERT INTO dept VALUES (40,'OPERATIONS','BOSTON');
--
-- Load the 'emp' table
--
INSERT INTO emp VALUES (7369,'SMITH','CLERK',7902,'17-DEC-80',800,NULL,20);
INSERT INTO emp VALUES (7499,'ALLEN','SALESMAN',7698,'20-FEB-81',1600,300,30);
INSERT INTO emp VALUES (7521,'WARD','SALESMAN',7698,'22-FEB-81',1250,500,30);
INSERT INTO emp VALUES (7566,'JONES','MANAGER',7839,'02-APR-81',2975,NULL,20);
INSERT INTO emp VALUES (7654,'MARTIN','SALESMAN',7698,'28-SEP-81',1250,1400,30);
INSERT INTO emp VALUES (7698,'BLAKE','MANAGER',7839,'01-MAY-81',2850,NULL,30);
INSERT INTO emp VALUES (7782,'CLARK','MANAGER',7839,'09-JUN-81',2450,NULL,10);
INSERT INTO emp VALUES (7788,'SCOTT','ANALYST',7566,'19-APR-87',3000,NULL,20);
INSERT INTO emp VALUES (7839,'KING','PRESIDENT',NULL,'17-NOV-81',5000,NULL,10);
INSERT INTO emp VALUES (7844,'TURNER','SALESMAN',7698,'08-SEP-81',1500,0,30);
INSERT INTO emp VALUES (7876,'ADAMS','CLERK',7788,'23-MAY-87',1100,NULL,20);
INSERT INTO emp VALUES (7900,'JAMES','CLERK',7698,'03-DEC-81',950,NULL,30);
INSERT INTO emp VALUES (7902,'FORD','ANALYST',7566,'03-DEC-81',3000,NULL,20);
INSERT INTO emp VALUES (7934,'MILLER','CLERK',7782,'23-JAN-82',1300,NULL,10);
--
-- Load the 'jobhist' table
--
INSERT INTO jobhist VALUES (7369,'17-DEC-80',NULL,'CLERK',800,NULL,20,'New Hire');
INSERT INTO jobhist VALUES (7499,'20-FEB-81',NULL,'SALESMAN',1600,300,30,'New Hire');
INSERT INTO jobhist VALUES (7521,'22-FEB-81',NULL,'SALESMAN',1250,500,30,'New Hire');
INSERT INTO jobhist VALUES (7566,'02-APR-81',NULL,'MANAGER',2975,NULL,20,'New Hire');
INSERT INTO jobhist VALUES (7654,'28-SEP-81',NULL,'SALESMAN',1250,1400,30,'New Hire');
INSERT INTO jobhist VALUES (7698,'01-MAY-81',NULL,'MANAGER',2850,NULL,30,'New Hire');
INSERT INTO jobhist VALUES (7782,'09-JUN-81',NULL,'MANAGER',2450,NULL,10,'New Hire');
INSERT INTO jobhist VALUES (7788,'19-APR-87','12-APR-88','CLERK',1000,NULL,20,'New Hire');
INSERT INTO jobhist VALUES (7788,'13-APR-88','04-MAY-89','CLERK',1040,NULL,20,'Raise');
INSERT INTO jobhist VALUES (7788,'05-MAY-90',NULL,'ANALYST',3000,NULL,20,'Promoted to Analyst');
INSERT INTO jobhist VALUES (7839,'17-NOV-81',NULL,'PRESIDENT',5000,NULL,10,'New Hire');
INSERT INTO jobhist VALUES (7844,'08-SEP-81',NULL,'SALESMAN',1500,0,30,'New Hire');
INSERT INTO jobhist VALUES (7876,'23-MAY-87',NULL,'CLERK',1100,NULL,20,'New Hire');
INSERT INTO jobhist VALUES (7900,'03-DEC-81','14-JAN-83','CLERK',950,NULL,10,'New Hire');
INSERT INTO jobhist VALUES (7900,'15-JAN-83',NULL,'CLERK',950,NULL,30,'Changed to Dept 30');
INSERT INTO jobhist VALUES (7902,'03-DEC-81',NULL,'ANALYST',3000,NULL,20,'New Hire');
INSERT INTO jobhist VALUES (7934,'23-JAN-82',NULL,'CLERK',1300,NULL,10,'New Hire');
--
-- Populate statistics table and view (pg_statistic/pg_stats)
--
ANALYZE dept;
ANALYZE emp;
ANALYZE jobhist;
--
-- Function that lists all employees' numbers and names
-- from the 'emp' table using a cursor.
--
CREATE OR REPLACE FUNCTION list_emp() RETURNS VOID
AS $$
DECLARE
v_empno NUMERIC(4);
v_ename VARCHAR(10);
emp_cur CURSOR FOR
SELECT empno, ename FROM emp ORDER BY empno;
BEGIN
OPEN emp_cur;
RAISE INFO 'EMPNO ENAME';
RAISE INFO '----- -------';
LOOP
FETCH emp_cur INTO v_empno, v_ename;
EXIT WHEN NOT FOUND;
RAISE INFO '% %', v_empno, v_ename;
END LOOP;
CLOSE emp_cur;
RETURN;
END;
$$ LANGUAGE 'plpgsql';
--
-- Function that selects an employee row given the employee
-- number and displays certain columns.
--
CREATE OR REPLACE FUNCTION select_emp (
p_empno NUMERIC
) RETURNS VOID
AS $$
DECLARE
v_ename emp.ename%TYPE;
v_hiredate emp.hiredate%TYPE;
v_sal emp.sal%TYPE;
v_comm emp.comm%TYPE;
v_dname dept.dname%TYPE;
v_disp_date VARCHAR(10);
BEGIN
SELECT INTO
v_ename, v_hiredate, v_sal, v_comm, v_dname
ename, hiredate, sal, COALESCE(comm, 0), dname
FROM emp e, dept d
WHERE empno = p_empno
AND e.deptno = d.deptno;
IF NOT FOUND THEN
RAISE INFO 'Employee % not found', p_empno;
RETURN;
END IF;
v_disp_date := TO_CHAR(v_hiredate, 'MM/DD/YYYY');
RAISE INFO 'Number : %', p_empno;
RAISE INFO 'Name : %', v_ename;
RAISE INFO 'Hire Date : %', v_disp_date;
RAISE INFO 'Salary : %', v_sal;
RAISE INFO 'Commission: %', v_comm;
RAISE INFO 'Department: %', v_dname;
RETURN;
EXCEPTION
WHEN OTHERS THEN
RAISE INFO 'The following is SQLERRM : %', SQLERRM;
RAISE INFO 'The following is SQLSTATE: %', SQLSTATE;
RETURN;
END;
$$ LANGUAGE 'plpgsql';
--
-- A RECORD type used to format the return value of
-- function, 'emp_query'.
--
CREATE TYPE emp_query_type AS (
empno NUMERIC,
ename VARCHAR(10),
job VARCHAR(9),
hiredate DATE,
sal NUMERIC
);
--
-- Function that queries the 'emp' table based on
-- department number and employee number or name. Returns
-- employee number and name as INOUT parameters and job,
-- hire date, and salary as OUT parameters. These are
-- returned in the form of a record defined by
-- RECORD type, 'emp_query_type'.
--
CREATE OR REPLACE FUNCTION emp_query (
IN p_deptno NUMERIC,
INOUT p_empno NUMERIC,
INOUT p_ename VARCHAR,
OUT p_job VARCHAR,
OUT p_hiredate DATE,
OUT p_sal NUMERIC
)
AS $$
BEGIN
SELECT INTO
p_empno, p_ename, p_job, p_hiredate, p_sal
empno, ename, job, hiredate, sal
FROM emp
WHERE deptno = p_deptno
AND (empno = p_empno
OR ename = UPPER(p_ename));
END;
$$ LANGUAGE 'plpgsql';
--
-- Function to call 'emp_query_caller' with IN and INOUT
-- parameters. Displays the results received from INOUT and
-- OUT parameters.
--
CREATE OR REPLACE FUNCTION emp_query_caller() RETURNS VOID
AS $$
DECLARE
v_deptno NUMERIC;
v_empno NUMERIC;
v_ename VARCHAR;
v_rows INTEGER;
r_emp_query EMP_QUERY_TYPE;
BEGIN
v_deptno := 30;
v_empno := 0;
v_ename := 'Martin';
r_emp_query := emp_query(v_deptno, v_empno, v_ename);
RAISE INFO 'Department : %', v_deptno;
RAISE INFO 'Employee No: %', (r_emp_query).empno;
RAISE INFO 'Name : %', (r_emp_query).ename;
RAISE INFO 'Job : %', (r_emp_query).job;
RAISE INFO 'Hire Date : %', (r_emp_query).hiredate;
RAISE INFO 'Salary : %', (r_emp_query).sal;
RETURN;
EXCEPTION
WHEN OTHERS THEN
RAISE INFO 'The following is SQLERRM : %', SQLERRM;
RAISE INFO 'The following is SQLSTATE: %', SQLSTATE;
RETURN;
END;
$$ LANGUAGE 'plpgsql';
--
-- Function to compute yearly compensation based on semimonthly
-- salary.
--
CREATE OR REPLACE FUNCTION emp_comp (
p_sal NUMERIC,
p_comm NUMERIC
) RETURNS NUMERIC
AS $$
BEGIN
RETURN (p_sal + COALESCE(p_comm, 0)) * 24;
END;
$$ LANGUAGE 'plpgsql';
--
-- Function that gets the next number from sequence, 'next_empno',
-- and ensures it is not already in use as an employee number.
--
CREATE OR REPLACE FUNCTION new_empno() RETURNS INTEGER
AS $$
DECLARE
v_cnt INTEGER := 1;
v_new_empno INTEGER;
BEGIN
WHILE v_cnt > 0 LOOP
SELECT INTO v_new_empno nextval('next_empno');
SELECT INTO v_cnt COUNT(*) FROM emp WHERE empno = v_new_empno;
END LOOP;
RETURN v_new_empno;
END;
$$ LANGUAGE 'plpgsql';
--
-- Function that adds a new clerk to table 'emp'.
--
CREATE OR REPLACE FUNCTION hire_clerk (
p_ename VARCHAR,
p_deptno NUMERIC
) RETURNS NUMERIC
AS $$
DECLARE
v_empno NUMERIC(4);
v_ename VARCHAR(10);
v_job VARCHAR(9);
v_mgr NUMERIC(4);
v_hiredate DATE;
v_sal NUMERIC(7,2);
v_comm NUMERIC(7,2);
v_deptno NUMERIC(2);
BEGIN
v_empno := new_empno();
INSERT INTO emp VALUES (v_empno, p_ename, 'CLERK', 7782,
CURRENT_DATE, 950.00, NULL, p_deptno);
SELECT INTO
v_empno, v_ename, v_job, v_mgr, v_hiredate, v_sal, v_comm, v_deptno
empno, ename, job, mgr, hiredate, sal, comm, deptno
FROM emp WHERE empno = v_empno;
RAISE INFO 'Department : %', v_deptno;
RAISE INFO 'Employee No: %', v_empno;
RAISE INFO 'Name : %', v_ename;
RAISE INFO 'Job : %', v_job;
RAISE INFO 'Manager : %', v_mgr;
RAISE INFO 'Hire Date : %', v_hiredate;
RAISE INFO 'Salary : %', v_sal;
RAISE INFO 'Commission : %', v_comm;
RETURN v_empno;
EXCEPTION
WHEN OTHERS THEN
RAISE INFO 'The following is SQLERRM : %', SQLERRM;
RAISE INFO 'The following is SQLSTATE: %', SQLSTATE;
RETURN -1;
END;
$$ LANGUAGE 'plpgsql';
--
-- Function that adds a new salesman to table 'emp'.
--
CREATE OR REPLACE FUNCTION hire_salesman (
p_ename VARCHAR,
p_sal NUMERIC,
p_comm NUMERIC
) RETURNS NUMERIC
AS $$
DECLARE
v_empno NUMERIC(4);
v_ename VARCHAR(10);
v_job VARCHAR(9);
v_mgr NUMERIC(4);
v_hiredate DATE;
v_sal NUMERIC(7,2);
v_comm NUMERIC(7,2);
v_deptno NUMERIC(2);
BEGIN
v_empno := new_empno();
INSERT INTO emp VALUES (v_empno, p_ename, 'SALESMAN', 7698,
CURRENT_DATE, p_sal, p_comm, 30);
SELECT INTO
v_empno, v_ename, v_job, v_mgr, v_hiredate, v_sal, v_comm, v_deptno
empno, ename, job, mgr, hiredate, sal, comm, deptno
FROM emp WHERE empno = v_empno;
RAISE INFO 'Department : %', v_deptno;
RAISE INFO 'Employee No: %', v_empno;
RAISE INFO 'Name : %', v_ename;
RAISE INFO 'Job : %', v_job;
RAISE INFO 'Manager : %', v_mgr;
RAISE INFO 'Hire Date : %', v_hiredate;
RAISE INFO 'Salary : %', v_sal;
RAISE INFO 'Commission : %', v_comm;
RETURN v_empno;
EXCEPTION
WHEN OTHERS THEN
RAISE INFO 'The following is SQLERRM : %', SQLERRM;
RAISE INFO 'The following is SQLSTATE: %', SQLSTATE;
RETURN -1;
END;
$$ LANGUAGE 'plpgsql';
--
-- Rule to INSERT into view 'salesemp'
--
CREATE OR REPLACE RULE salesemp_i AS ON INSERT TO salesemp
DO INSTEAD
INSERT INTO emp VALUES (NEW.empno, NEW.ename, 'SALESMAN', 7698,
NEW.hiredate, NEW.sal, NEW.comm, 30);
--
-- Rule to UPDATE view 'salesemp'
--
CREATE OR REPLACE RULE salesemp_u AS ON UPDATE TO salesemp
DO INSTEAD
UPDATE emp SET empno = NEW.empno,
ename = NEW.ename,
hiredate = NEW.hiredate,
sal = NEW.sal,
comm = NEW.comm
WHERE empno = OLD.empno;
--
-- Rule to DELETE from view 'salesemp'
--
CREATE OR REPLACE RULE salesemp_d AS ON DELETE TO salesemp
DO INSTEAD
DELETE FROM emp WHERE empno = OLD.empno;
--
-- After statement-level trigger that displays a message after
-- an insert, update, or deletion to the 'emp' table. One message
-- per SQL command is displayed.
--
CREATE OR REPLACE FUNCTION user_audit_trig() RETURNS TRIGGER
AS $$
DECLARE
v_action VARCHAR(24);
v_text TEXT;
BEGIN
IF TG_OP = 'INSERT' THEN
v_action := ' added employee(s) on ';
ELSIF TG_OP = 'UPDATE' THEN
v_action := ' updated employee(s) on ';
ELSIF TG_OP = 'DELETE' THEN
v_action := ' deleted employee(s) on ';
END IF;
v_text := 'User ' || USER || v_action || CURRENT_DATE;
RAISE INFO ' %', v_text;
RETURN NULL;
END;
$$ LANGUAGE 'plpgsql';
CREATE TRIGGER user_audit_trig
AFTER INSERT OR UPDATE OR DELETE ON emp
FOR EACH STATEMENT EXECUTE PROCEDURE user_audit_trig();
--
-- Before row-level trigger that displays employee number and
-- salary of an employee that is about to be added, updated,
-- or deleted in the 'emp' table.
--
CREATE OR REPLACE FUNCTION emp_sal_trig() RETURNS TRIGGER
AS $$
DECLARE
sal_diff NUMERIC(7,2);
BEGIN
IF TG_OP = 'INSERT' THEN
RAISE INFO 'Inserting employee %', NEW.empno;
RAISE INFO '..New salary: %', NEW.sal;
RETURN NEW;
END IF;
IF TG_OP = 'UPDATE' THEN
sal_diff := NEW.sal - OLD.sal;
RAISE INFO 'Updating employee %', OLD.empno;
RAISE INFO '..Old salary: %', OLD.sal;
RAISE INFO '..New salary: %', NEW.sal;
RAISE INFO '..Raise : %', sal_diff;
RETURN NEW;
END IF;
IF TG_OP = 'DELETE' THEN
RAISE INFO 'Deleting employee %', OLD.empno;
RAISE INFO '..Old salary: %', OLD.sal;
RETURN OLD;
END IF;
END;
$$ LANGUAGE 'plpgsql';
CREATE TRIGGER emp_sal_trig
BEFORE DELETE OR INSERT OR UPDATE ON emp
FOR EACH ROW EXECUTE PROCEDURE emp_sal_trig();
COMMIT;
2 強化された互換性機能
Advanced Serverには、Oracleアプリケーションでサポートされている構文との互換性を提供する拡張機能が含まれています。 Advanced Serverで サポートされているすべての互換性機能の 詳細は、「Oracleデベロッパー・ガイドのデータベース互換性」を参照してください。情報は4つのガイドに分かれています。
Oracle Database開発者のため データベース互換性ガイド」 では、Advanced Serverでサポートされている互換性のあるプロシージャ言語、プロファイル管理、パーティション構文およびサンプル・アプリケーションの概要を説明します。
EDB * Plusは、EDB * Loaderの、EDB *ラップ、そして DRITA:Oracleの開発者ツールおよびユーティリティ・ガイドのためのデータベースの互換性は、Advanced Serverによってサポート互換性ツールに関する情報を提供します。
Oracle Developerの組み込みパッケージ データベース互換性ガイドで、組み込みパッケージで使用可能な互換構文の使用方法について説明します。
Oracle Database開発者のため データベース互換性リファレンス・ガイド」では、SQL構文、互換ビューおよびシステム表、およびデータ型など、Advanced Server互換機能の使用に関する参照情報を提供します。
バージョン固有のガイドは次の場所で入手できます。
https://www.enterprisedb.com/resources/product-documentation
以下のセクションでは、Advanced Serverでサポートされている互換性機能の一部について説明します。
2.1 互換機能の有効化
互換性機能を利用できるようにするAdvanced Serverをインストールするには、いくつかの方法があります。
クラスタを初期化する前に、 - redwood - likeを指定するには、Advanced Serverサービス設定ファイル INITDBOPTS変数を使用します。
呼び出すとき initdb -あなたのクラスタを初期化するために、含まredwood - likeオプションを選択します。
Advanced Serverインストーラでサポートされているインストールオプションの詳細については、EDB WebサイトのEDB Postgres Advanced Server Installation Guideを参照してください。
https://www.enterprisedb.com/resources/product-documentation
2.2 ストアドプロシージャ言語
Advanced Serverは、生産性の高い手続き型言語をサポートしており、カスタムプロシージャ、関数、トリガ、およびパッケージを記述できます。手続き型言語:
ストアド・プロシージャ言語の使用方法の詳細は 、次のOracle Developer's GuideのDatabase Compatibilityを 参照してください
https://www.enterprisedb.com/resources/product-documentation
2.3 オプティマイザのヒント
DELETEINSERTSELECT 、またはUPDATEコマンドを呼び出すと、サーバーは一連の実行計画を生成します。それらの実行計画を分析した後、サーバーは、(最も)最も時間のかかる結果セットを返すプランを選択します。サーバーの計画の選択は、いくつかの要素に依存します。
ANALYZEコマンドによって収集された列統計
原則として、クエリプランナは最もコストの安いプランを選択します。オプティマイザヒントを使用して、クエリプランを選択するときにサーバーに影響を与えることができます。
オプティマイザ・ヒントは、 DELETEINSERTSELECTまたはUPDATEコマンドの直後にあるコメントのような構文に埋め込まれたディレクティブ(または複数のディレクティブ)です。コメント内のキーワードは、結果セットを作成するときに特定のプランを採用または回避するようサーバーに指示します。オプティマイザ・ヒントの使用方法の詳細は、次のOracle Developer's GuideのDatabase Compatibilityを参照してください。
https://www.enterprisedb.com/resources/product-documentation
2.4 データ・ディクショナリ・ビュー
Advanced Serverには、Oracleデータ・ディクショナリ・ビューと互換性のある方法でデータベース・オブジェクトに関する情報を提供する一連のビューが含まれています。 Advanced Serverで利用可能なビューの詳細については、次のURLにある「 Oracle Developer Reference Guide」のデータベース互換性 を参照してください
https://www.enterprisedb.com/resources/product-documentation
2.5 dblink_ora
dblink _ oraは、Advanced Server内からOracleシステムに格納されたデータのSELECTINSERTUPDATEまたはDELETEを可能にするOCIベースのデータベース・リンクを提供します。 dblink _ ora使用dblinkとサポートされている関数とプロシージャの詳細については、次のURLにある「Oracleデベロッパーズ・ガイド」のデータベース互換性を参照してください。
https://www.enterprisedb.com/resources/product-documentation
2.6 プロファイル管理
Advanced Serverは、プロファイル管理用の互換SQL構文をサポートしています。プロファイル管理コマンドを使用すると、データベースのスーパーユーザーは、名前付き プロファイル 。各プロファイルは、 passwordmd5認証を強化するpassword管理のルールを定義しています。プロファイル内のルールは次のことができます。
プロファイルは、同等の認証要件を共有するロールのグループを簡単に管理できる、名前付きの一連の属性です。パスワード要件が変更された場合、そのプロファイルに関連付けられている各ユーザーに新しい要件が適用されるようにプロファイルを変更できます。
プロファイルを作成したら、そのプロファイルを1人以上のユーザーに関連付けることができます。ユーザーがサーバーに接続すると、サーバーはログインロールに関連付けられているプロファイルを適用します。プロファイルはクラスタ内のすべてのデータベースで共有されますが、各クラスタには複数のプロファイルが存在する場合があります。複数のデータベースにアクセスできる1人のユーザーは、クラスタ内の各データベースに接続するときに同じプロファイルを使用します。
プロファイル管理コマンドの使用方法については、次の URLにある「Oracleデベロッパーズ・ガイド」のデータベース互換性を 参照してください
https://www.enterprisedb.com/resources/product-documentation
2.7 組み込みパッケージ
Advanced Serverは、Oracleのプロシージャおよびファンクションとの互換性を提供する多数のビルトイン・パッケージをサポートしています。
各パッケージで使用可能なプロシージャおよびファンクションの詳細は、「 Oracle Developerの組み込みパッケージ データベース互換性ガイド」 を参照してください
https://www.enterprisedb.com/resources/product-documentation
2.8 Open Client Library
以前は今、アプリケーション・コードを変更せずに、最小限でAdvanced ServerまたはOracleデータベースのいずれかで動作することができ、「固定」されたアプリケーション- オープンクライアントライブラリでは、Oracle Call Interfaceのとアプリケーションの相互運用性を提供します。 Open Client LibraryのEnterpriseDB実装はC言語で記述されています。
次の図は、 Open Client LibraryOracle Call Interfaceのアプリケーション・スタックを比較したものです。
C:\ Users \ susan \ Desktop \ Screen Shot 2017-08-18 at 12.55.39 PM.png
図2.1 - オープン・クライアント・ライブラリ。
Open Client Libraryでサポートされている機能の詳細については、次のURLにある「EDB Postgres Advanced Server OCI Connector Guide」を参照してください。
https://www.enterprisedb.com/resources/product-documentation
2.9 ユーティリティ
下記のユーティリティでサポートされている互換構文の詳細については、次の URLにある「Oracle Developer Tools and Utilities Guide」 データベース互換性を 参照してください
https://www.enterprisedb.com/resources/product-documentation
EDB * Plus
EDB * Plusは、Advanced Serverへのコマンドライン・ユーザー・インタフェースを提供するユーティリティ・プログラムです。これは、Oracleの開発者やユーザーにとって使い慣れたものです。 EDB * Plusは、SQLコマンド、SPL匿名ブロック、およびEDB * Plusコマンドを受け入れます。
EDB * Plusを使用すると、
EDB * Plusの詳細については、 EDB * Plusユーザーズガイド を参照してください
EDB *ローダー
EDB * Loaderは、Advanced Server用Oracleデータベースと互換性のあるインタフェースを提供する高性能バルク・データ・ローダーです。 EDB * Loaderコマンドライン・ユーティリティは、Oracle SQL * Loaderによって提供されるパラメータのサブセットを使用して、入力ソース(通常はファイル)から1つ以上の表にデータをロードします。
EDB *ローダの機能は次のとおりです。
EDB *ラップ
EDB * Wrapユーティリティは、独自のソースコードとプログラム(関数、ストアドプロシージャ、トリガ、およびパッケージ)を不正な調査から保護します。 EDB * Wrapプログラムは、SPLまたはPL / pgSQLのソースコード(平文)を含むファイルを、ほぼ不可能な形式で同じコードを含むファイルに変換します。難読化されたコードがあれば、そのコードをAdvanced Serverに送信して、そのプログラムを難読化された形式で保存します。 EDB * Wrapはあいまいなコードですが、テーブル定義はまだ公開されています。
ラップするものはすべて難読化された形式で保存されます。パッケージ全体をラップすると、パッケージ本体に含まれるプロトタイプとパッケージヘッダに含まれる関数およびプロシージャは、難読化された形式で格納されます。
ダイナミックランタイム計測ツールアーキテクチャ(DRITA)
DRITA(Dynamic Runtime Instrumentation Tools Architecture)を使用すると、DBAはカタログ・ビューを問い合せて 、個々のセッションまたはシステム全体のパフォーマンスに影響を及ぼす待機イベント を判別できます 。 DRITAには、各イベントの発生回数と待機時間が記録されています。この情報を使用してパフォーマンスの問題を診断できます。 DRITAは最小のシステムリソースを消費しながらこの機能を提供します。
DRITAは、 スナップショット比較してシステムのパフォーマンスを評価します。スナップショットは、特定の時点におけるシステムパフォーマンスデータの保存されたセットです。各スナップショットは一意のID番号で識別されます。 DRITAレポート機能でスナップショットID番号を使用してシステムパフォーマンス統計を返すことができます。
2.10 ECPGPlus
EnterpriseDBは、ECPG(PostgreSQLプリコンパイラ)を拡張してECPGPlusを作成しました。 ECPGPlusを使用すると、Cアプリケーションに埋め込みSQLコマンドを含めることができます。 ECPGPlusを使用して埋め込みSQLコマンドを含むアプリケーションをコンパイルすると、SQLコードは構文チェックされ、Cに変換されます。
ECPGPlusは、Advanced Serverデータベースに接続されている場合、CプログラムでPro * C構文をサポートしています。 ECPGPlusは次をサポートします:
Oracleデータベースと互換性のある CALL
ECPGPlusの使用方法については、以下のEnterpriseDB Webサイトから入手可能なEDB Postgres Advanced Server ECPG Connector Guide を参照してください
https://www.enterprisedb.com/resources/product-documentation
2.11 テーブルのパーティション化
パーティション化されたテーブルでは、論理的に大きな1つのテーブルがより小さな物理的な部分に分割されます。パーティショニングにはいくつかの利点があります。
パーティション設計にその要件を計画する場合は、パーティションを追加または削除してバルクロード(またはアンロード)を実装できます。 ALTER TABLE は、一括操作よりはるかに高速です。また 、バルク DELETE によって引き起こされる VACUUM オーバーヘッドを 完全に回避し ます。
テーブル分割は、さもなければテーブルが非常に大きくなる場合にのみ価値があります。テーブルがパーティショニングの恩恵を受ける正確なポイントは、アプリケーションによって異なります。経験則として、テーブルのサイズがデータベースサーバーの物理メモリを超えている必要があります。
Advanced Serverでサポートされているデータベース互換性機能の詳細は、次の Oracle Developer's GuideのDatabase Compatibilityを 参照してください
https://www.enterprisedb.com/resources/product-documentation
3 データベース管理
この章では、Advanced Serverデータベースの管理と管理を支援する機能について説明します。
3.1 構成パラメータ
この節では、Advanced Serverのデータベースサーバー構成パラメータについて説明します。これらのパラメータは、データファイルとログファイルの場所、接続、認証、セキュリティの設定、リソースの割り当てと使用、アーカイブとレプリケーションの設定、エラーのログと統計の収集、最適化とパフォーマンスのチューニングなどのデータベースサーバーの動作と環境のさまざまな側面を制御します。ロケールと書式設定などが含まれます。
これらの設定パラメータのほとんどは、PostgreSQLにも適用されます。 Advanced Serverにのみ適用される構成パラメータについては、セクション 3.1.2
設定パラメータに関する追加情報は、次のURLにあるPostgreSQLコアマニュアルを参照してください。
https://www.postgresql.org/docs/11/static/runtime-config.html
 
3.1.1 設定パラメータの設定
このセクションでは、構成パラメーターの指定および設定方法の概要について説明します。
各構成パラメーターは、名前と値のペアを使用して設定されます。パラメータ名は大文字と小文字を区別しません。パラメータ名は通常、オプションの等号( = )でその値から区切られます
次に、 postgresql.confファイルの設定パラメータの設定例を示します。
# This is a comment
log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB
パラメータ値は、5つのタイプの1つとして指定されます。
ブール値。許容値は、のように記述することができるonofftruefalseyesno10 、またはこれらのいずれかの明確なプレフィックス。
整数。小数部のない数値。
浮動小数点。オプションの小数部分を小数点で区切った数値。
文字列。テキスト値。値が単純な識別子または数値でない場合(つまり、値にスペースやその他の句読記号などの特殊文字が含まれている場合)、単一引用符で囲みます。
列挙型。文字列値の特定のセット。許可される値はシステムビューpg_settings.enumvalsます。 Enum値は大文字と小文字を区別しません。
設定によっては、メモリまたは時間の値を指定するものがあります。これらはそれぞれ暗黙の単位を持ちます。単位はキロバイト、ブロック(通常は8キロバイト)、ミリ秒、秒、または分です。デフォルトの単位は、システムビュー pg_settings.unit 参照することで見つけることができます 。異なる単位を明示的に指定することができます。
有効なメモリ単位は、 kB (キロバイト)、 MB (メガバイト)、 GB (ギガバイト)です。有効な時間単位はms (ミリ秒)、 s (秒)、 min (分)、 h (時間)、 d (日)です。メモリ単位の乗数は1024です。
設定パラメータの設定は、さまざまな方法で設定できます。
データベースクラスタ全体のほとんどすべての設定可能なパラメータの初期設定は、設定ファイル postgresql.conf リストされています 。これらの設定は、データベースサーバーの起動または再起動時に有効になります。これらの初期パラメータ設定の一部は、次の点で説明するようにオーバーライドできます。すべての構成パラメーターには、明示的にオーバーライドされなければ有効な組み込みのデフォルト設定があります。
同じパラメータがpostgresql.auto.confファイルに含まれている場合 postgresql.confファイルの設定パラメータは上書きされます。 ALTER SYSTEMコマンドは、 postgresql.auto.confファイルの設定パラメータを管理するために使用されます。
SQLコマンド ALTER DATABASEALTER ROLE 、またはALTER ROLE IN DATABASEを使用して、特定のパラメータ設定を変更できます。変更されたパラメータ設定は、コマンドの実行後に新しいセッションに反映されます。 ALTER DATABASEは、指定されたデータベースに接続する新しいセッションに影響します。 ALTER ROLEは、指定されたロールによって開始された新しいセッションに影響します。 ALTER ROLE IN DATABASEは、指定されたデータベースに接続する指定されたロールによって開始された新しいセッションに影響します。これらのSQLコマンドによって確立されたパラメータ設定は、データベースサーバーの再起動によって無期限に有効なまま残り、第2および第3の箇条書きで説明した方法で設定された設定を上書きします。パラメータ設定を使用して確立ALTER DATABASEALTER 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 構成パラメータの概要
このセクションには、すべてのAdvanced Server構成パラメーターと、パラメーターの多くの重要な属性をリストした要約表が含まれています。
これらの属性は、サマリー表の次の列で表されます。
パラメータ。構成パラメータ名。
効果の範囲。構成パラメーター設定の有効範囲。 'クラスタ' - 設定はデータベースクラスタ全体(つまり、データベースサーバインスタンスによって管理されるすべてのデータベース)に影響します。 'データベース' - 設定はデータベースごとに異なり、データベースの作成時に設定されます。ロケール設定に関連する少数のパラメータに適用されます。 'セッション' - 設定は、個々のセッションの粒度に応じて変更できます。つまり、以下のエンティティに対して異なる設定を行うことができます。このリストの後の設定は、以前の設定を上書きします。a)データベースクラスタ全体、b)データベースクラスタ内の特定のデータベース、c)特定のロール、d) e)特定のセッション。
効果が発揮されるとき。変更されたパラメータ設定が有効になったとき。 'プリセット' - Advanced Server製品が構築されたとき、または特定のデータベースが作成されたときに確立されます。これは読み取り専用パラメータであり、変更することはできません。 'Restart' - データベースサーバーを再起動する必要があります。 'リロード' - 構成ファイルを再ロードする必要があります(またはデータベースサーバーを再起動できます)。 'Immediate' - PGOPTIONS環境変数またはSETコマンドを使用して現在のセッションの設定を変更すると、セッションですぐに有効にPGOPTIONSます。 ALTER DATABASEALTER 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にも適用されることを示していません。
注:決して変更する必要のないいくつかのパラメーターがあります。これらは、[説明]列の[ 注:内部使用のみ]として指定されています。
表3-1 - 構成パラメータの概要
" is allowed in string literals. Sets whether " \' " is allowed in string literals. Sets whether " " is allowed in string literals.
n/a
CREATE FUNCTION Check function bodies during .
X
n/a
X
X
X
n/a
X
X
X
X
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.
X
X
X
X
X
X
X
X
X
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.
X
X
X
X
X
X
X
X
X
DATE should behave like a TIMESTAMP should behave like a Determines whether should behave like a TIMESTAMP or not.
X
GREATEST and LEAST functions should handle NULL parameters. Determines how functions should handle NULL parameters.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
items beyond which GEQO is used. FROM items beyond which GEQO is used. Sets the threshold of items beyond which GEQO is used.
n/a
X
X
n/a
JOIN constructs are not flattened. FROM -list size beyond which Sets the constructs are not flattened.
n/a
n/a
n/a
n/a
n/a
X
X
X
X
autoprewarm background worker. Enables the background worker.
X
X
X
X
X
n/a
n/a
n/a
n/a
ssl
X
X
LISTEN and NOTIFY Generates debugging output for .
pg_stat_activity.current_query Sets the size reserved for , in bytes. Sets the size reserved for , in bytes.
Treats " expr=NULL " as " expr IS NULL ". " as " expr IS NULL ".
X
X
n/a
n/a
 
3.1.3 機能別の構成パラメータ
このセクションでは、特定のグループの構成パラメーターの詳細について説明します。
各パラメータのセクション見出しの後に、属性のリストが続きます。
パラメータタイプ。パラメーターが受け入れることができる値のタイプ。パラメータ型の値については、第3.1.1項を参照してください。
デフォルト値。設定ファイルに値が明示的に設定されていない場合のデフォルト設定。
範囲。許容される値の範囲。
効果の最小範囲。明確な設定が可能な最小の範囲。一般的に、別個の設定の最小範囲は、 クラスタ全体(設定はすべてのデータベースとそのセッション、クラスタ内で同じ)またはセッションごと (設定はロール、データベース、または個々のセッションによって異なる場合があります)です。 (この属性はセクション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 BYDISTINCT 、およびマージ・ジョインに使用されDISTINCT 。ハッシュ・テーブルは、ハッシュ・ジョイン、ハッシュ・ベースの集計、およびINサブクエリのハッシュ・ベースの処理で使用されます。
合理的な値は、マシンのサイズ、同時接続数( max_connections 決まる )、およびクエリの複雑さに応じて、通常4MB〜64MBです。
3.1.3.1.3 maintenance_work_mem
パラメータタイプ:整数
デフォルト値: 16MB
範囲: 1024kB〜2097151kB
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
VACUUMCREATE INDEXALTER TABLE ADD FOREIGN KEY など、メンテナンス操作で使用するメモリの最大量を指定します。デフォルトは16メガバイト( 16MB )です。これらの操作の1つのみがデータベースセッションによって一度に実行され、通常はインストールで同時に実行されていないので、この値をwork_memよりも大幅に大きく設定することは安全work_mem 。設定を大きくすると、バキューム処理やデータベース・ダンプのリストアのパフォーマンスが向上する可能性があります。
自動バキュームが実行されているときは、 autovacuum_max_workers回までこのメモリが割り当てられる可能性があるので、デフォルト値を高く設定しないように注意してください。
経験則では、これをシステムメモリの約5%に設定しますが、約512MBを超えないように設定してください。値を大きくしても必ずしもパフォーマンスが向上するとは限りません。
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_segments
現在は廃止予定です。このパラメータは、サーバーバージョン9.5以降ではサポートされていません。
3.1.3.1.6 checkpoint_completion_target
パラメータタイプ:浮動小数点
デフォルト値: 0.5
範囲: 0〜1
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
チェックポイントの完了のターゲットを、チェックポイント間の合計時間の割合で指定します。これにより、システムが次のチェックポイントに向かって作業を開始する間にチェックポイントの書き込みが広がります。
デフォルトの0.5は、次のチェックポイントの50%が準備完了であるときに、チェックポイントの書き込みを終了することを意味します。値が0.9の場合は、次のチェックポイントの90%が完了したときにチェックポイントの書き込みを終了することを意味します。したがって、チェックポイントの書き込み時間が長くなり、パフォーマンスのボトルネックが発生することがありません。
3.1.3.1.7 checkpoint_timeout
パラメータタイプ:整数
デフォルト値: 5分
範囲: 30〜3600
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
自動WALチェックポイント間の最大時間(秒)。デフォルトは5分( 5min )です。このパラメータを増やすと、クラッシュリカバリに必要な時間が長くなります。
checkpoint_timeoutを15分などの大きな値に増やすと 、特にshared_buffers大きな値を使用すると、システムのI / O負荷が軽減されます。
前述のチェックポイントパラメータを調整することの欠点は、ご使用のシステムがわずかなディスク容量を使用し、クラッシュが発生した場合に回復に時間がかかることです。ただし、ほとんどのユーザーにとって、これは パフォーマンスの大幅な向上の ために支払う小さな値段 です。
3.1.3.1.8 max_wal_size
パラメータタイプ: 整数
デフォルト値: 1 GB
範囲: 2〜2147483647
効果の最小範囲: クラスター
値の変更が反映されるとき: リロード
有効 化に必要な権限: EPASサービスアカウント
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
効果の最小範囲: クラスター
値の変更が反映されるとき: リロード
有効 化に必要な権限: EPASサービスアカウント
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コマンドを参照してください )。
デフォルト値はキャッシングをほとんど想定していないため、頻繁に減らすことをお勧めします。データベースが物理メモリよりも大幅に大きい場合でも、このパラメータを1より小さく(デフォルト値1ではなく)設定して、より良いクエリプランが得られるかどうかを確認してください。データベースがメモリ内に完全に収まる場合は、この値をさらに0.1に下げることができます。
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できます。
デフォルト値はキャッシングをほとんど想定していないため、頻繁に減らすことをお勧めします。データベースが物理メモリよりも大幅に大きい場合でも、この方法でより良いクエリプランが得られるかどうかを確認するには、このパラメータを2(既定値4ではなく)に設定します。データベースがメモリ内に完全に収まる場合は、この値をさらに0.1に下げることができます。
システムはそれを許可しますが、 random_page_costよりもseq_page_cost小さく設定しないでseq_page_cost 。しかし、データベースをメモリ内に大部分または完全に収めると、それらを等しく(または非常に近くに)設定することは理にかなっています。その場合、順不同のページに触れるためのペナルティはないからです。また、大量にキャッシュされたデータベースでは、RAM内のページをフェッチするコストが通常よりもはるかに小さいため、両方の値をCPUパラメータに対して低くする必要があります。
3.1.3.1.13 effective_cache_size
パラメータタイプ:整数
デフォルト値: 128MB
範囲: 8kB〜17179869176kB
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
単一のクエリで使用可能なディスクキャッシュの有効サイズに関する計画者の前提を設定します。これは、索引を使用するコストの見積りに考慮されます。値が大きいほど索引スキャンが使用される可能性が高くなりますが、値が小さいほど逐次スキャンが使用される可能性が高くなります。このパラメータを設定するときは、Advanced Serverの共有バッファと、Advanced Serverデータファイルに使用されるカーネルのディスクキャッシュの部分の両方を考慮する必要があります。また、使用可能な領域を共有する必要があるため、異なる表の同時問合せの予想数も考慮してください。このパラメータは、Advanced Serverによって割り当てられた共有メモリのサイズに影響を与えません。また、カーネルディスクキャッシュも予約しません。推定目的でのみ使用されます。デフォルトは128メガバイト( 128MB )です。
このパラメータがあまりにも低く設定されている場合、計画者は有益な場合でもインデックスを使用しないことを決定する可能性があります。 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を適用します。
これは、NUMA(非一様なメモリアクセス)アーキテクチャを使用するシステムに有用です。
3.1.3.1.16 pg_prewarm.autoprewarm
パラメータタイプ:ブール値
デフォルト値: true
範囲: { true | false }
効果の最小範囲:クラスター
値の変更が有効になった場合:再起動
有効化に必要な権限: EPASサービスアカウント
このパラメータは 、シャットダウン前に自動的に共有バッファをディスクにダンプするバックグラウンドワーカープロセスであるautoprewarmを データベースサーバが実行するかどうかを制御します 。次に、次回のサーバ起動時に共有バッファをプリウォームします。つまり、ディスクからブロックをバッファプールにロードします。
利点は、シャットダウンする前にディスクにダンプされたデータをロードして、サーバーを再起動した後のウォームアップ時間を短縮することです。
場合 pg_prewarm.autoprewarm onに設定されている、 autoprewarm作業員が有効になっています。パラメータがoffに設定されていると、 autoprewarmは無効になります。パラメータはデフォルトでオンになっています。
autoprewarmを使用する前に 、次の例に示すように、 postgresql.confファイルのshared_preload_libraries構成パラメータにリストされているライブラリに$libdir/pg_prewarmを追加する必要があります。
shared_preload_libraries = '$libdir/dbms_pipe,$libdir/edb_gen,$libdir/dbms_aq,$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.1.16については、 autoprewarm背景労働者を。
 
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)、ホスト・マシンのリソースの最小量がデータベース・サーバーに割り当てられます。この設定は、他の多くのアプリケーションが使用されている開発マシンで使用されます。
34〜66の範囲の値は、適度な量のリソースをデータベース・サーバーに割り当てます。この設定は、Advanced Serverと同じマシン上で実行されている固定数の他のアプリケーションを持つ専用アプリケーションサーバーに使用される場合があります。
最高値(67〜100など)は、サーバーのリソースのほとんどをデータベースサーバーに割り当てます。この設定は、Advanced Serverの実行専用のホストマシンで使用されます。
edb_dynatune が選択されると、 postgresql.confファイル内の他の設定パラメータを調整することによって、データベースサーバのパフォーマンスをさらに微調整することができます。調整された設定は、 edb_dynatuneによって選択された対応する値を上書きします。パラメーターの値を変更するには、構成パラメーターをコメント解除し、目的の値を指定して、データベース・サーバーを再始動します。
3.1.3.2.2 edb_dynatune_profile
パラメータタイプ:列挙
デフォルト値: oltp
範囲: { oltp | reporting | mixed }
効果の最小範囲:クラスター
値の変更が有効になった場合:再起動
有効化に必要な権限: EPASサービスアカウント
このパラメーターは、データベース・サーバー上の予期されたワークロード・プロファイルに基づいてチューニング・アスペクトを制御するために使用されます。
可能な値は次のとおりです。
oltp。データベースサーバーが過度のオンライントランザクション処理ワークロードを処理している場合に推奨されます。
報告。重いデータの報告に使用されるデータベースサーバーに推奨されます。
混合。トランザクション処理とデータ報告が混在するサーバーに適しています。
 
3.1.3.3 リソース使用量/ EDBリソースマネージャ
このセクションの構成パラメータは、EDB Resource Managerを使用してリソースの使用を制御します。
3.1.3.3.1 edb_max_resource_groups
パラメータタイプ:整数
デフォルト値: 16
範囲: 0〜65536
効果の最小範囲:クラスター
値の変更が有効になった場合:再起動
有効化に必要な権限: EPASサービスアカウント
このパラメータは、EDB Resource Managerが同時に使用できるリソースグループの最大数を制御します。 edb_max_resource_groups指定された値より多くのリソースグループを作成できますが 、これらのグループ内のプロセスがアクティブに使用しているリソースグループの数はこの値を超えることはできません。
パラメータ edb_max_resource_groupsは、 edb_max_resource_groupsないように維持すると予想されるグループの数よりも大きく設定する必要があります。
3.1.3.3.2 edb_resource_group
パラメータタイプ:文字列
デフォルト値:なし
範囲:該当なし
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
設定し edb_resource_group現在のセッションは、グループのリソースタイプの設定に応じてEDBリソースマネージャによって制御されるべきリソース・グループの名前にパラメータを。
パラメータが設定されていない場合、現在のセッションはEDB Resource Managerを使用しません。
 
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
効果の最小スコープ: セッションごと
値の変更が有効になったとき: 即時
アクティブ化に必要な承認: セッションユーザー
この構成パラメータは、プランナが一般的な実行計画に定める前に、プランナが考慮するカスタム実行計画の数を制御します。
クライアントアプリケーションが準備されたステートメントを繰り返し実行する場合、サーバーは カスタム プランまたは 汎用 プランの 選択を決定する前にいくつかの実行プランを評価することを決定することがあります
デフォルトでは、オプティマイザは汎用プランを評価する前に5つのカスタムプランを生成します。つまり、プリペアド・ステートメントを6回実行すると、オプティマイザは5つのカスタム・プランを生成し、次に1つの汎用プランを生成し、次にジェネリック・プランに従うかどうかを決定します。
特定のワークロードでは、この余分な計画がパフォーマンスに悪影響を与える可能性があります。 edb_custom_plan_tries 構成パラメーターを 調整して 、一般プランを評価する前に考慮するカスタム計画の数を減らす ことができ ます。
edb_custom_plan_tries 0 設定 すると、カスタムプランの生成が効果的に無効になります。
edb_custom_plan_tries -1 設定 する と、無限試行のカスタムプラン生成が可能になります。
以下のクエリを考えてみましょう。
PREPARE custQuery AS SELECT * FROM customer WHERE salesman >= $1
このクエリ $1 トークンはパラメータマーカーです。クライアントアプリケーションは、ステートメントが実行されるたびに各パラメータマーカーの値を提供する必要があります。
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 = literalWHERE deptno = 10 )の制約を持つ簡単なクエリでのみ利用できます。
アーリー・プルーニングは、 WHERE column = expression などのより複雑な照会には使用されません (例: WHERE deptno = 10 + 5 )。
 
3.1.3.6 レポート作成とロギング/ログの内容
このセクションの構成パラメータは、レポートとログを制御します。
3.1.3.6.1 trace_hints
パラメータタイプ:ブール値
デフォルト値: false
範囲: { true | false }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
オプティマイザヒント機能を使用して、ヒントがプランナによって使用されたかどうかに関するより詳細な情報を提供します。設定する client_min_messagestrace_hints次のように設定パラメータを:
SET client_min_messages TO info;
SET trace_hints TO true;
SELECTを使用してコマンドNO_INDEX以下に示すヒントは、上記の設定パラメータが設定されているときに生じる付加的な情報を示しています。
EXPLAIN SELECT /*+ NO_INDEX(accounts accounts_pkey) */ * FROM accounts WHERE aid = 100;
 
INFO: [HINTS] Index Scan of [accounts].[accounts_pkey] rejected because of NO_INDEX hint.
 
INFO: [HINTS] Bitmap Heap Scan of [accounts].[accounts_pkey] rejected because of NO_INDEX hint.
QUERY PLAN
-------------------------------------------------------------
Seq Scan on accounts (cost=0.00..14461.10 rows=1 width=97)
Filter: (aid = 100)
(2 rows)
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 監査設定
この項では、Advanced Serverデータベース監査機能で使用される構成パラメータについて説明します。
3.1.3.7.1 edb_audit
パラメータタイプ:列挙
デフォルト値: none
範囲: { none | csv | xml }
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
データベース監査を有効または無効にします。値 xmlまたはcsvは、データベース監査を有効にします。これらの値は、監査情報が取り込まれるファイル形式を表します。 noneはデータベース監査を無効にし、デフォルトでもあります。
3.1.3.7.2 edb_audit_directory
パラメータタイプ:文字列
デフォルト値: edb_audit
範囲:該当なし
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
監査ログファイルを作成するディレクトリを指定します。ディレクトリのパスは、Advanced Server dataディレクトリの絶対パスまたは相対パスにすることができます
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
範囲: { none | every | sun | mon | tue | wed | thu | fri | sat } ...
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
監査ファイルをローテーションする曜日を指定します。有効な値は、 sunmontuewedthufrisatevery 、およびnoneです。回転を無効にするには、値をnone設定します。ファイルを毎日ローテーションするには、 edb_audit_rotation_day値をevery設定しevery 。特定の曜日にファイルを回転するには、値を希望の曜日に設定します。
3.1.3.7.5 edb_audit_rotation_size
パラメータタイプ:整数
デフォルト値: 0MB
範囲: 0MB〜5000MB
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
ファイルのローテーションが強制的に発生する場合のファイルサイズのしきい値をメガバイト単位で指定します。デフォルト値は0MBです。パラメータがコメントアウトされているか、または0に設定されている場合、サイズベースでのファイルのローテーションは発生しません。
3.1.3.7.6 edb_audit_rotation_seconds
パラメータタイプ:整数
デフォルト値: 0
範囲: 0〜2147483647s
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
新しいログファイルを作成する必要がある回転時間を秒単位で指定します。この機能を無効にするには、このパラメータを0に設定します。
3.1.3.7.7 edb_audit_connect
パラメータタイプ:列挙
デフォルト値: failed
範囲: { none | failed | all }
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
ユーザーによるデータベース接続試行の監査を有効にします。すべての接続試行の監査を無効にするには、 edb_audit_connectnone に設定します。失敗したすべての接続試行を監査するには、値をfailed設定します。すべての接続試行を監査するには、値をall設定します。
3.1.3.7.8 edb_audit_disconnect
パラメータタイプ:列挙
デフォルト値: none
範囲: { none | all }
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
接続されたユーザーによるデータベースの切断を監査できるようにします。切断の監査を有効にするには、値を all 設定します 。無効にするには、値をnone設定します。
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 設定し errorCREATE TABLEALTER TABLEなどのすべてのDDL文を監査するには、パラメータ値をddl設定します。特定のタイプのDDL文を監査するには、パラメータ値に特定のSQLコマンド( createdrop 、またはalter )を含めることができます。また、オブジェクト・タイプは、次のようなコマンドに続く指定することができるcreate tablecreate viewdrop roleなどのすべての変更文など、 INSERTUPDATEDELETEまたはTRUNCATE設定することにより、監査することができるedb_audit_statementするdml 。特定のタイプのDML文を監査するには、パラメータ値に特定のSQLコマンド、 insertupdatedeleteまたはtruncateを含めることができます。これらのSQLコマンドに関する監査ステートメントには、パラメーター値selectgrantrevoke 、またはrollbackを組み込みます。値をall設定するとall文が監査され、 noneするとこの機能は無効になります。
3.1.3.7.10 edb_audit_tag
パラメータタイプ:文字列
デフォルト値:なし
効果の最小範囲:セッション
値の変更が有効になったとき:即時
アクティブ化に必要な承認:ユーザー
使用 edb_audit_tagする際、監査ログに含まれる文字列値を指定するedb_auditパラメータがに設定されcsvまたはxml
3.1.3.7.11 edb_audit_destination
パラメータタイプ:列挙
デフォルト値: file
範囲: { file | syslog }
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: 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_value
edb_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記憶域パラメーターがCREATE TABLEコマンドから省略されたときに、表のfillfactorを設定します。
テーブルのfillfactorは10〜100のパーセンテージです。100(完全詰め)がデフォルトです。より小さいfillfactorが指定されると、 INSERT操作は表のページを指定されたパーセンテージにのみパックします。各ページの残りのスペースは、そのページの行を更新するために予約されています。これにより、 UPDATEは更新された行のコピーを元のページと同じページに配置することができます。これは、別のページに配置するよりも効率的です。エントリが決して更新されないテーブルでは、完全なパッキングが最適ですが、大きく更新されたテーブルでは、より小さいfillfactorsが適切です。
3.1.3.9.2 edb_data_redaction
パラメータタイプ:ブール値
デフォルト値: true
範囲: { true | false }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
データの修正は、表示された情報を変更することによって、特定のユーザーに特定の機密データの公開を制限するポリシーのサポートです。
デフォルト設定は TRUEなので、スーパーユーザーとテーブル所有者以外のすべてのユーザーにデータの変更が適用されます。
パラメータを FALSE設定して無効にすると 、次のようになります。
データの修正については、 4.4 項を参照してください
 
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構成パラメータ)を正しく設定する必要があります。
Windowsの場合のみ: postgresql.confファイルにoracle_home構成パラメータを設定するには、ファイルを編集して次の行を追加します。
oracle_home = ' lib_directory '
oci.dll含むWindowsディレクトリの名前に oci.dlllib_directory
oracle_home構成パラメータを設定した後は、変更を有効にするためにサーバーを再起動する必要があります。 Windowsサービスコンソールからサーバーを再起動します。
3.1.3.10.2 odbc_lib_path
パラメータタイプ:文字列
デフォルト値:なし
範囲:該当なし
効果の最小範囲:クラスター
値の変更が有効になった場合:再起動
有効化に必要な権限: EPASサービスアカウント
ODBCドライバ・マネージャを使用し、非標準の場所にインストールされている場合は、 postgresql.confファイルにodbc_lib_path構成パラメータを設定して場所を指定します。
odbc_lib_path = ' complete_path_to_libodbc.so '
設定ファイルには、ドライバマネージャ共有ライブラリ(通常は libodbc.soへの完全なパス名を含める必要があります
 
3.1.3.11 互換性オプション
このセクションで説明する構成パラメータは、さまざまなデータベース互換機能を制御します。
3.1.3.11.1 edb_redwood_date
パラメータタイプ:ブール値
デフォルト値: false
範囲: { true | false }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
場合 DATEコマンドの列のデータ・タイプとして表示され、それに変換されTIMESTAMP設定パラメータ場合、テーブル定義はデータベースに格納された時点でedb_redwood_dateに設定されているTRUE 。したがって、時間成分も日付とともに列に格納されます。
edb_redwood_dateが FALSE 設定されている FALSECREATE 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
範囲: { true | false }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
GREATEST関数は、パラメータのリストから最大の価値を持つパラメータを返します。 LEAST関数は、パラメータのリストから最小の値を持つパラメータを返します。
edb_redwood_greatest_leastTRUEに設定されている場合GREATESTおよびLEAST関数は、少なくとも1つのパラメータがnullの場合にnullを返します。
SET edb_redwood_greatest_least TO on;
 
SELECT GREATEST(1, 2, NULL, 3);
 
greatest
----------
(1 row)
とき edb_redwood_greatest_leastに設定されているFALSE 、NULLのパラメータは、すべてのパラメータが関数によって返される場合はnullではNULLであるとき以外は無視されます。
SET edb_redwood_greatest_least TO off;
 
SELECT GREATEST(1, 2, NULL, 3);
 
greatest
----------
3
(1 row)
 
SELECT GREATEST(NULL, NULL, NULL);
 
greatest
----------
(1 row)
3.1.3.11.3 edb_redwood_raw_names
パラメータタイプ:ブール値
デフォルト値: false
範囲: { true | false }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
場合 edb_redwood_raw_namesそのデフォルト値に設定されているFALSEレッドウッド・カタログから見たとき、等テーブル名、カラム名、トリガー名、プログラム名、ユーザ名、などのデータベース・オブジェクト名は、すなわち、接頭辞システムカタログである(大文字で表示されますALL_DBA_ 、またはUSER_ )。さらに、引用符は、囲み引用符で作成された名前を囲みます。
場合 edb_redwood_raw_namesに設定されているTRUE 、データベース・オブジェクト名は、レッドウッド・カタログから見たとき、それらはPostgreSQLのシステムカタログに格納されているとおりに表示されています。したがって、引用符を囲まずに作成された名前は、PostgreSQLで期待どおり小文字で表示されます。囲み引用符で作成された名前は、作成されたとおりに正確に表示されますが、引用符は使用しません。
たとえば、次のユーザー名が作成され、そのユーザーがセッションを開始します。
CREATE USER reduser IDENTIFIED BY password;
edb=# \c - reduser
Password for user reduser:
You are now connected to database "edb" as user "reduser".
reduser としてデータベースに接続すると、次の表が作成されます。
CREATE TABLE all_lower (col INTEGER);
CREATE TABLE ALL_UPPER (COL INTEGER);
CREATE TABLE "Mixed_Case" ("Col" INTEGER);
レッドウッドのカタログから見た場合、 USER_TABLES 、とedb_redwood_raw_namesデフォルト値に設定FALSE 、名前が以外の大文字で表示されMixed_Case作成とも引用符を囲むと同じように表示される名前、。
edb=> SELECT * FROM USER_TABLES;
schema_name | table_name | tablespace_name | status | temporary
-------------+--------------+-----------------+--------+-----------
REDUSER | ALL_LOWER | | VALID | N
REDUSER | ALL_UPPER | | VALID | N
REDUSER | "Mixed_Case" | | VALID | N
(3 rows)
で見た場合 edb_redwood_raw_namesに設定TRUE 、名前はを除いて、小文字で表示されMixed_Case作成として表示されますが、今で囲む引用符名、。
edb=> SET edb_redwood_raw_names TO true;
SET
edb=> SELECT * FROM USER_TABLES;
schema_name | table_name | tablespace_name | status | temporary
-------------+------------+-----------------+--------+-----------
reduser | all_lower | | VALID | N
reduser | all_upper | | VALID | N
reduser | Mixed_Case | | VALID | N
(3 rows)
これらの名前は、PostgreSQLの pg_tablesカタログから見た場合と一致します。
edb=> SELECT schemaname, tablename, tableowner FROM pg_tables WHERE tableowner = 'reduser';
schemaname | tablename | tableowner
------------+------------+------------
reduser | all_lower | reduser
reduser | all_upper | reduser
reduser | Mixed_Case | reduser
(3 rows)
3.1.3.11.4 edb_redwood_strings
パラメータタイプ:ブール値
デフォルト値: false
範囲: { true | false }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
場合 edb_redwood_stringsパラメータが設定されているTRUE 、文字列はヌル変数またはnullカラムと連結されている場合、結果は元の文字列です。 edb_redwood_stringsFALSEに設定されていると、ネイティブのPostgreSQLの動作が維持されFALSE 。これは、文字列とnull変数またはnullカラムを連結するとnullの結果になります。
次の例は、その違いを示しています。
サンプルアプリケーションには従業員のテーブルが含まれています。この表には、ほとんどの従業員にとってNULLであるcommという名前の列があります。次のクエリは、 edb_redwood_stringFALSE設定して実行しFALSE 。ヌル列と空でない文字列を連結すると、最終的な結果がNULLになるため、コミッションを持つ従業員だけがクエリ結果に表示されます。他のすべての従業員の出力行はNULLです。
SET edb_redwood_strings TO off;
 
SELECT RPAD(ename,10) || ' ' || TO_CHAR(sal,'99,999.99') || ' ' || TO_CHAR(comm,'99,999.99') "EMPLOYEE COMPENSATION" FROM emp;
 
EMPLOYEE COMPENSATION
----------------------------------
 
ALLEN 1,600.00 300.00
WARD 1,250.00 500.00
 
MARTIN 1,250.00 1,400.00
 
 
 
 
TURNER 1,500.00 .00
 
 
(14 rows)
以下は、 edb_redwood_stringsTRUE設定されているときに実行される同じクエリです。ここでは、NULL列の値は空の文字列として扱われます。空の文字列を空でない文字列と連結すると、空でない文字列が生成されます。
SET edb_redwood_strings TO on;
 
SELECT RPAD(ename,10) || ' ' || TO_CHAR(sal,'99,999.99') || ' ' || TO_CHAR(comm,'99,999.99') "EMPLOYEE COMPENSATION" FROM emp;
 
EMPLOYEE COMPENSATION
----------------------------------
SMITH 800.00
ALLEN 1,600.00 300.00
WARD 1,250.00 500.00
JONES 2,975.00
MARTIN 1,250.00 1,400.00
BLAKE 2,850.00
CLARK 2,450.00
SCOTT 3,000.00
KING 5,000.00
TURNER 1,500.00 .00
ADAMS 1,100.00
JAMES 950.00
FORD 3,000.00
MILLER 1,300.00
(14 rows)
3.1.3.11.5 edb_stmt_level_tx
パラメータタイプ:ブール値
デフォルト値: false
範囲: { true | false }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
文レベルのトランザクション分離 という用語は、SQLコマンドで実行時エラーが発生したときに、その単一のコマンドによって引き起こされたデータベース上のすべての更新をロールバックする動作を記述しています。たとえば、1つのUPDATEコマンドが5行を正常に更新するが、6行目を更新しようとすると例外が発生した場合、このUPDATEコマンドによって作成された6行すべての更新がロールバックされます。コミットまたはロールバックされていない以前のSQLコマンドの影響は、 COMMITコマンドまたはROLLBACKコマンドが実行されるまで保留されます。
Advanced Serverでは、SQLコマンドの実行中に例外が発生した場合、トランザクションの開始以降、データベース上のすべての更新がロールバックされます。さらに、トランザクションは中止状態のままであり、別のトランザクションを開始する前にCOMMITまたはROLLBACKコマンドを発行する必要があります。
edb_stmt_level_txTRUEに設定されている場合 、例外は未コミットのデータベース更新を自動的にロールバックしません。 edb_stmt_level_txFALSEに設定されているFALSE 、例外はコミットされていないデータベースの更新をロールバックします。
注意:絶対に必要な場合にのみ、 edb_stmt_level_txTRUE設定してください。パフォーマンスに悪影響を与える可能性があります。
次の例では、 edb_stmt_level_txFALSE 、2番目のINSERTコマンドのアボートによって最初のINSERTコマンドがロールバックされることがPSQLで示されてい FALSE 。 PSQLでは、コマンド\set AUTOCOMMIT off発行\set AUTOCOMMIT off必要があります。そう\set AUTOCOMMIT offないと、すべての文が自動的にedb_stmt_level_txの効果のデモンストレーションの目的をedb_stmt_level_txます。
\set AUTOCOMMIT off
SET edb_stmt_level_tx TO off;
 
INSERT INTO emp (empno,ename,deptno) VALUES (9001, 'JONES', 40);
INSERT INTO emp (empno,ename,deptno) VALUES (9002, 'JONES', 00);
ERROR: insert or update on table "emp" violates foreign key constraint "emp_ref_dept_fk"
DETAIL: Key (deptno)=(0) is not present in table "dept".
 
COMMIT;
SELECT empno, ename, deptno FROM emp WHERE empno > 9000;
 
empno | ename | deptno
-------+-------+--------
(0 rows)
次の例では、 edb_stmt_level_txTRUEに設定して、2番目のINSERTコマンドで最初のINSERTコマンドがエラーの後にロールバックされていません。この時点で、最初のINSERTコマンドをコミットまたはロールバックできます。
\set AUTOCOMMIT off
SET edb_stmt_level_tx TO on;
 
INSERT INTO emp (empno,ename,deptno) VALUES (9001, 'JONES', 40);
INSERT INTO emp (empno,ename,deptno) VALUES (9002, 'JONES', 00);
ERROR: insert or update on table "emp" violates foreign key constraint "emp_ref_dept_fk"
DETAIL: Key (deptno)=(0) is not present in table "dept"
 
SELECT empno, ename, deptno FROM emp WHERE empno > 9000;
 
empno | ename | deptno
-------+-------+--------
9001 | JONES | 40
(1 row)
 
COMMIT;
ROLLBACKコマンドが代わりに発行されている可能性がCOMMIT従業員番号の挿入、その場合には、コマンド9001同様にロールバックされていたであろう。
3.1.3.11.6 db_dialect
パラメータタイプ:列挙
デフォルト値: postgres
範囲: { postgres | redwood }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
ネイティブの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
範囲: { true | false }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
onに設定すると、 CREATE TABLEは、新しく作成されたテーブルにROWID列が含まれROWID列はSQLコマンドで参照できます。
3.1.3.11.8 optimizer_mode
パラメータタイプ:列挙
デフォルト値: choose
範囲: { choose | ALL_ROWS | FIRST_ROWS | FIRST_ROWS_10 | FIRST_ROWS_100 | FIRST_ROWS_1000 }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
オプティマイザヒントを解析するためのデフォルトの最適化モードを設定します。
表示される値は次のとおりです。
表3-2 - オプティマイザモード
これらの最適化モードは、SQLコマンドを送信するクライアントが結果セットの最初の "n"行だけを表示することに関心があり、結果セットの残りを放棄するという仮定に基づいています。クエリに割り当てられたリソースは、そのように調整されます。
 
3.1.3.12 カスタマイズされたオプション
Advanced Serverの以前のリリースでは、通常、アドオンモジュール(手続き型言語など)によって追加されることが知られていないパラメータによってcustom_variable_classesが必要でした。
3.1.3.12.1 custom_variable_classes
custom_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サービスアカウント
DBMS_PIPE パッケージに 使用されるバッファの合計サイズを指定し ます。
3.1.3.12.4 index_advisor.enabled
パラメータタイプ:ブール値
デフォルト値: true
範囲: { true | false }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
EDB-PSQLセッションまたはPSQLセッションでIndex Advisorを一時的に中断する機能を提供します。 index_advisor.enabled構成パラメーターを使用するには、 索引アドバイザー・プラグイン index_advisor EDB-PSQLまたはPSQLセッションにロードする必要があります。
索引アドバイザー・プラグインは、次の例のようにロードできます。
$ psql -d edb -U enterprisedb
Password for user enterprisedb:
psql (10.0.1)
Type "help" for help.
 
edb=# LOAD 'index_advisor';
LOAD
SETコマンドを使用して 、次の例に示すように、インデックスアドバイザが代替クエリプランを生成するかどうかを制御するようにパラメータ設定を変更します。
edb=# SET index_advisor.enabled TO off;
SET
edb=# EXPLAIN SELECT * FROM t WHERE a < 10000;
QUERY PLAN
-------------------------------------------------------
Seq Scan on t (cost=0.00..1693.00 rows=9864 width=8)
Filter: (a < 10000)
(2 rows)
 
edb=# SET index_advisor.enabled TO on;
SET
edb=# EXPLAIN SELECT * FROM t WHERE a < 10000;
QUERY PLAN
-----------------------------------------------------------------------------
Seq Scan on t (cost=0.00..1693.00 rows=9864 width=8)
Filter: (a < 10000)
Result (cost=0.00..327.88 rows=9864 width=8)
One-Time Filter: '===[ HYPOTHETICAL PLAN ]==='::text
-> Index Scan using "<hypothetical-index>:1" on t (cost=0.00..327.88 rows=9864 width=8)
Index Cond: (a < 10000)
(6 rows)
3.1.3.12.5 edb_sql_protect.enabled
パラメータタイプ:ブール値
デフォルト値: false
範囲: { true | 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
範囲: { learn | passive | active }
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
保護されたロールによってSQLステートメントが発行されたときにSQL / Protectが実行するアクションを設定します。
edb_sql_protect.level構成パラメータは、モード、受動モードまたはアクティブモードを使用するかについては、以下のいずれかの値に設定することができます。
学ぶ。保護された役割の活動を追跡し、役割によって使用される関係を記録する。これは、SQL / Protectを最初に構成して、保護されたアプリケーションの予想される動作を学習するときに使用されます。
受動的。保護されたロールが定義されたルールを破るが、SQLステートメントの実行を停止しない場合、警告を発行します。これは、SQL / Protectが保護された役割の予想される動作を学習した後の次のステップです。これは基本的に侵入検知モードで動作し、適切に監視されている場合は本番環境で実行できます。
アクティブ。保護された役割のすべての無効なステートメントを停止します。これは、SQLファイアウォールとして動作し、危険なクエリの実行を防ぎます。これは、攻撃者がアプリケーションの背後にある脆弱点とデータベースの種類を判断しようとしている場合に、早期侵入テストに対して特に効果的です。 SQL / Protectはこれらの脆弱点を閉じるだけでなく、ブロックされたクエリを追跡して、攻撃者がシステムに侵入する別の方法を見つける前に管理者に警告することができます。
初めてSQL / Protectを使用している場合は、 edb_sql_protect.levellearnするように設定learn
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の値)に設定されているときにサーバーを起動すると 、警告メッセージがデータベース・サーバーのログ・ファイルに記録されます。
2014-07-18 16:04:12 EDT WARNING: invalid value for parameter "edb_sql_protect.max_protected_relations": "2147483648"
2014-07-18 16:04:12 EDT HINT: Value exceeds integer range.
データベースサーバーは正常に起動しますが、 edb_sql_protect.max_protected_relationsはデフォルト値の1024に設定されています。
パラメータの上限は整数データ型の最大値としてリストされますが、実用的な設定は、使用可能な共用メモリの量と、データベースサーバーの起動時に使用されるパラメータ値によって異なります。
必要なスペースが共有メモリーに予約されていれば、その値は許容されます。共有メモリー内の領域を予約できないような値の場合、データベース・サーバーの始動は失敗し、次のようなエラー・メッセージが表示されます。
2014-07-18 15:22:17 EDT FATAL: could not map anonymous shared memory: Cannot allocate memory
2014-07-18 15:22:17 EDT HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space or huge pages. To reduce the request size (currently 2070118400 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
そのような場合は、データベースサーバーが正常に開始されるまでパラメーター値を減らしてください。
3.1.3.12.8 edb_sql_protect.max_protected_roles
パラメータタイプ:整数
デフォルト値: 64
範囲: 1〜2147483647
効果の最小範囲:クラスター
値の変更が有効になった場合:再起動
有効化に必要な権限: EPASサービスアカウント
保護できるロールの最大数を設定します。
すべての保護された役割は共有メモリ内の領域を消費します。サーバが保護された役割回数保護関係の数(のためのスペースを確保することに注意してください edb _ sql _ protectmax _ protected _ relations )。可能な最大保護ロールのスペースは、データベースサーバーの起動時に予約されます。
edb_sql_protect.max_protected_rolesが有効な範囲外の値(たとえば、2,147,483,648の値)に設定されているときにデータベースサーバーが起動されると、データベースサーバーのログファイルに警告メッセージが記録されます。
2014-07-18 16:04:12 EDT WARNING: invalid value for parameter "edb_sql_protect.max_protected_roles": "2147483648"
2014-07-18 16:04:12 EDT HINT: Value exceeds integer range.
データベースサーバーは正常に起動しますが、 edb_sql_protect.max_protected_rolesはデフォルト値の64に設定されています。
パラメータの上限は整数データ型の最大値としてリストされますが、実用的な設定は、使用可能な共用メモリの量と、データベースサーバーの起動時に使用されるパラメータ値によって異なります。
必要なスペースが共有メモリーに予約されていれば、その値は許容されます。共有メモリー内の領域を予約できないような値の場合、データベース・サーバーの始動は失敗し、次のようなエラー・メッセージが表示されます。
2014-07-18 15:22:17 EDT FATAL: could not map anonymous shared memory: Cannot allocate memory
2014-07-18 15:22:17 EDT HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space or huge pages. To reduce the request size (currently 2070118400 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
そのような場合は、データベースサーバーが正常に開始されるまでパラメーター値を減らしてください。
3.1.3.12.9 edb_sql_protect.max_queries_to_save
パラメータタイプ:整数
デフォルト値: 5000
範囲: 100〜2147483647
効果の最小範囲:クラスター
値の変更が有効になった場合:再起動
有効化に必要な権限: EPASサービスアカウント
ビュー edb_sql_protect_queries に保存する違反クエリの最大数を設定します
保存されるすべてのクエリは、共有メモリ内の領域を消費します。データベースサーバーの起動時に、保存できる最大限のクエリの領域が予約されています。
edb_sql_protect.max_queries_to_saveが有効な範囲外の値(たとえば値10)に設定されているときにデータベース・サーバーが起動されると、警告メッセージがデータベース・サーバーのログ・ファイルに記録されます。
2014-07-18 13:05:31 EDT WARNING: 10 is outside the valid range for parameter "edb_sql_protect.max_queries_to_save" (100 .. 2147483647)
データベースサーバーは正常に起動しますが、 edb_sql_protect.max_queries_to_saveがデフォルト値の5000に設定されています。
パラメータの上限は整数データ型の最大値としてリストされますが、実用的な設定は、使用可能な共用メモリの量と、データベースサーバーの起動時に使用されるパラメータ値によって異なります。
必要なスペースが共有メモリーに予約されていれば、その値は許容されます。共有メモリー内の領域を予約できないような値の場合、データベース・サーバーの始動は失敗し、次のようなエラー・メッセージが表示されます。
2014-07-18 15:22:17 EDT FATAL: could not map anonymous shared memory: Cannot allocate memory
2014-07-18 15:22:17 EDT HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space or huge pages. To reduce the request size (currently 2070118400 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
そのような場合は、データベースサーバーが正常に開始されるまでパラメーター値を減らしてください。
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サービスアカウント
EDB待ち状態のログファイルが削除されるまでの時間を設定します。デフォルトは604800秒(7日)です。 EDB待機状態については、 8.2 項を参照してください
3.1.3.12.12 edb_wait_states.sampling_interval
パラメータタイプ:整数
デフォルト値: 1s
範囲: 1〜2147483647s
効果の最小範囲:クラスター
値の変更が反映されるとき:リロード
有効化に必要な権限: EPASサービスアカウント
EDB待機状態の2つのサンプリング・サイクル間のタイミング間隔を設定します。デフォルト設定は1秒です。 EDB待機状態については、 8.2 項を参照してください
3.1.3.12.13 edbldr.empty_csv_field
パラメータタイプ:列挙
デフォルト値: NULL
範囲: { NULL | empty_string | pgsql }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
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開発者ツールおよびユーティリティ・ガイドのためのデータベースの互換性を参照してください。
https://www.enterprisedb.com/resources/product-documentation
3.1.3.12.14 utl_encode.uudecode_redwood
パラメータタイプ:ブール値
デフォルト値: false
範囲: { true | 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のみがファイルに対する読み取りと書き込みの権限を持ちます。
-rw------- 1 enterprisedb enterprisedb 21 Jul 24 16:08 utlfile
 
3.1.3.13 グループ化されていない
このセクションの構成パラメータはAdvanced Serverにのみ適用され、特定の限定された目的のためのものです。
3.1.3.13.1 nls_length_semantics
パラメータタイプ:列挙
デフォルト値: byte
範囲: { byte | char }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な権限:スーパーユーザ
このパラメータはAdvanced Serverでは無効です。
たとえば、 ALTER SESSIONコマンドの形式は、 Advanced Serverでは構文エラーをスローせずに受け入れられますが、セッション環境は変更されません。
ALTER SESSION SET nls_length_semantics = char;
注意:このパラメータの設定はサーバ環境には影響しないため、システムビューpg_settingsは表示されません。
3.1.3.13.2 query_rewrite_enabled
パラメータタイプ:列挙
デフォルト値: false
範囲: { true | false | force }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
このパラメータはAdvanced Serverでは無効です。
たとえば、次の形式の ALTER SESSIONコマンドは、構文エラーを投げずにAdvanced Serverで受け入れられますが、セッション環境は変更されません。
ALTER SESSION SET query_rewrite_enabled = force;
注意:このパラメータの設定はサーバ環境には影響しないため、システムビューpg_settingsは表示されません。
3.1.3.13.3 query_rewrite_integrity
パラメータタイプ:列挙
デフォルト値: enforced
範囲: { enforced | trusted | stale_tolerated }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な権限:スーパーユーザ
このパラメータはAdvanced Serverでは無効です。
たとえば、次の形式の ALTER SESSIONコマンドは、構文エラーを投げずにAdvanced Serverで受け入れられますが、セッション環境は変更されません。
ALTER SESSION SET query_rewrite_integrity = stale_tolerated;
注意:このパラメータの設定はサーバ環境には影響しないため、システムビューpg_settingsは表示されません。
3.1.3.13.4 timed_statistics
パラメータタイプ:ブール値
デフォルト値: true
範囲: { true | false }
効果の最小スコープ:セッションごと
値の変更が有効になったとき:即時
アクティブ化に必要な承認:セッションユーザー
DRITA(Dynamic Runtime Instrumentation Tools Architecture)機能のタイミングデータの収集を制御します。オンに設定すると、タイミングデータが収集されます。
注意: Advanced Serverがインストールされている場合、 postgresql.confファイルにはtimed_statisticsをoffに設定した明示的なエントリが含まれています。 timed_statisticsをデフォルトに設定してこのエントリをコメントアウトし、設定ファイルをリロードすると、定期的な統計収集が有効になります。
 
3.2 索引アドバイザー
索引アドバイザー・ユーティリティーは、特定のワークロードのパフォーマンスを向上させるために索引付けする列を判別するのに役立ちます。索引アドバイザーは、Bツリー(単一列または複合)索引タイプを考慮し、パフォーマンスを向上させる可能性のある他の索引タイプ(GIN、GiST、Hash)を識別しません。 Index Advisorは、EDB Postgres Advanced Serverとともにインストールされます。
Index Advisorは、Advanced Serverのクエリプランナと連携して、クエリプランナが実行コストを計算するために使用する インデックス作成します。索引アドバイザーは、ワークロードで提供されるSQL照会を分析して索引を識別します。
索引アドバイザーを使用してSQL照会を分析するには、次の3つの方法があります。
https://www.enterprisedb.com/resources/product-documentation
索引アドバイザーは、 INSERTUPDATEDELETEおよびSELECTステートメントで索引付けの推奨を行います。索引アドバイザーを呼び出すときは、一連の照会(SQLファイルでコマンドを提供する場合)またはEXPLAINステートメント(psqlコマンド行でSQLステートメントを指定する場合)の形式でワークロードを提供します。索引アドバイザーは、提供された照会の照会計画および推定実行コストを表示しますが、照会を実際には実行しません。
分析中、索引アドバイザーは、照会実行コストを仮想索引の有無と比較します。仮説索引を使用した実行コストが実行コスト未満であれば、両方の計画が EXPLAINステートメント出力に報告され 、改善を定量化するメトリックが計算され、索引アドバイザーがINDEX作成に必要なCREATE INDEXステートメントを生成します。
実行コストを削減する仮想索引が見つからない場合、索引アドバイザーは EXPLAINステートメントの元の照会プラン出力のみを表示します
索引アドバイザーは実際には表に索引を作成しません。索引アドバイザーが提供するCREATE INDEXステートメントを使用して、表に推奨索引を追加します。
Advanced Serverに付属のスクリプトは、索引アドバイザーが分析によって生成された索引推奨事項を保管する表を作成します。スクリプトはまた、結果の検索および解釈を単純化するために、関数およびテーブルのビューを作成する。
スクリプトを実行しないように選択した場合、索引アドバイザーは、索引アドバイザーセッションの間だけ使用可能な一時表に推奨事項を記録します。
3.2.1 索引アドバイザー・コンポーネント
索引アドバイザー共有ライブラリーは、索引付け推奨を行うために照会プランナーと対話します。 Windowsの場合、Advanced Serverインストーラは、 Advanced Serverホームディレクトリのlibdirサブディレクトリに次の共有ライブラリを作成します 。 Linuxの場合、インストールedb-as xx -server-indexadvisor RPMパッケージxx Advanced Serverのバージョン番号です。
Linuxの場合:
index_advisor.so
Windowsの場合:
index_advisor.dll
libdirディレクトリにあるライブラリは、スーパーユーザだけが読み込むことができます。データベース管理者は、インデックス・アドバイザ・ファイルをlibdirディレクトリからlibdir/pluginsディレクトリ(Advanced Serverホーム・ディレクトリの下)に手動でコピーすることにより、スーパー・ユーザー以外のユーザーが索引アドバイザーを使用できるようにすることができます。信頼できる非スーパーユーザーにのみ、プラグインへのアクセスを許可する必要があります。これは実稼働環境では安全ではない方法です。
インストーラーは、索引アドバイザー・ユーティリティー・プログラムとセットアップ・スクリプトも作成します。
pg_advise_index
pg_advise_indexは、SQL照会を含むユーザー提供の入力ファイルを読み取り、索引アドバイザーが推奨する索引の作成に使用できるCREATE INDEXステートメントを含むテキスト・ファイルを作成するユーティリティー・プログラムです。 pg_advise_indexプログラムは、Advanced Serverホームディレクトリのbinサブディレクトリにあります。
index_advisor.sql
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ます。索引アドバイザーがユーザーの検索パスでindex_advisor_log表を見つけられない場合、索引アドバイザーは同じ名前の一時表に索引推奨を保管します。一時テーブルは、現在のセッションの期間だけ存在します。
show_index_recommendations()
show_index_recommendations()は、特定の索引アドバイザー・セッション中に行われた推奨事項(バックエンド・プロセスIDによって識別される)を解釈して表示するPL / pgSQL関数です。
index_recommendations
索引アドバイザーは、照会分析中に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特権を持っている必要があることに注意してください。スキーマは、索引アドバイザーと対話しているすべてのユーザーの検索パスになければなりません。
1。
選択したスキーマを search_pathパラメータの先頭に配置します 。たとえば、検索パスが現在の場合:
search_path=public, accounting
advisor という名前のスキーマに索引アドバイザー・オブジェクトを作成するには、次のコマンドを使用します。
SET search_path = advisor, public, accounting;
2。
index_advisor.sqlスクリプトを実行して、データベース・オブジェクトを作成します。 psqlクライアントを実行している場合は、次のコマンドを使用できます。
\i full _ pathname /index_advisor.sql
パス名を指定し index_advisor.sqlの代わりにスクリプトfull_pathname
3。
index_advisor_log表の権限をすべてのIndex Advisorユーザーに付与します。索引アドバイザー・ユーザーがスーパーユーザーまたはこれらのデータベース・オブジェクトの所有者である場合、このステップは不要です。
グラント SELECTINSERTの権限をindex_advisor_logユーザーが索引アドバイザーを呼び出すことができるようにテーブル。
グラントは、 DELETEの権限をindex_advisor_log指定したユーザーが、テーブルの内容を削除することを可能にするために、テーブル。
グラント SELECT上の権限をindex_recommendations眺め。
次の例では、 ia という名前のスキーマに索引アドバイザー・データベース・オブジェクトを作成する方法を示します。このスキーマに ia 、ユーザー名ia_user持つ索引アドバイザー・ユーザーがアクセスできるようになります。
$ edb-psql -d edb -U enterprisedb
psql.bin (11.0.2, server 11.0.2)
Type "help" for help.
 
edb=# CREATE SCHEMA ia;
CREATE SCHEMA
edb=# SET search_path TO ia;
SET
edb=# \i /usr/edb/as11/share/contrib/index_advisor.sql
CREATE TABLE
CREATE INDEX
CREATE INDEX
CREATE FUNCTION
CREATE FUNCTION
CREATE VIEW
edb=# GRANT USAGE ON SCHEMA ia TO ia_user;
GRANT
edb=# GRANT SELECT, INSERT, DELETE ON index_advisor_log TO ia_user;
GRANT
edb=# GRANT SELECT ON index_recommendations TO ia_user;
GRANT
索引アドバイザーを使用しているときは、指定されたスキーマ( ia )をia_usersearch_pathパラメーターに含める必要があります。
 
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;
ANALYZE t;
結果の表には、次の行が含まれます。
a | b
-------+-------
0 | 99999
1 | 99998
2 | 99997
3 | 99996
.
.
.
99997 | 2
99998 | 1
99999 | 0
3.2.3.1 pg_advise_indexユーティリティの使用
呼び出すとき pg_advise_indexユーティリティを、次の方法で実行されるクエリが含まれるファイルの名前を含める必要がありますpg_advise_index 。クエリは同じ行にあっても、別々の行にあっても構いませんが、各クエリはセミコロンで終了する必要があります。ファイル内の照会は、 EXPLAINキーワードで始めるべきではありません。
次の例は、サンプルの workload.sqlファイルの内容を示しています。
SELECT * FROM t WHERE a = 500;
SELECT * FROM t WHERE b < 1000;
次のコードサンプルに示すように pg_advise_indexプログラムを実行します。
$ pg_advise_index -d edb -h localhost -U enterprisedb -s 100M -o advisory.sql workload.sql
poolsize = 102400 KB
load workload from file 'workload.sql'
Analyzing queries .. done.
size = 2184 KB, benefit = 1684.720000
size = 2184 KB, benefit = 1655.520000
/* 1. t(a): size=2184 KB, benefit=1684.72 */
/* 2. t(b): size=2184 KB, benefit=1655.52 */
/* Total size = 4368KB */
コードサンプルでは、 -d-h 、および-Uオプションはpsql接続オプションです。
-s
-sは、索引アドバイザーが推奨する索引の最大サイズを制限するオプションのパラメーターです。索引アドバイザーが結果セットを戻さない場合、 -sが小さすぎる可能性があります。
-o
推奨インデックスは、 -oオプションの後に指定されたファイルに書き込まれます。
pg_advise_indexプログラムによって表示される情報は、 index_advisor_logテーブルに記録されます。この例に示すコマンドに応答して、索引アドバイザーは次のCREATE INDEXステートメントをadvisory.sql出力ファイルに書き込みます
create index idx_t_1 on t (a);
create index idx_t_2 on t (b);
推奨索引は、ファイル内のCREATE INDEXステートメントを使用してpsqlコマンド行で作成するか、 advisory.sqlスクリプトを実行して索引を作成します。
$ edb-psql -d edb -h localhost -U enterprisedb -e -f advisory.sql
create index idx_t_1 on t (a);
CREATE INDEX
create index idx_t_2 on t (b);
CREATE INDEX
3.2.3.2 psqlコマンドラインでのIndex Advisorの使用
索引アドバイザーを使用して、edb-psql(またはpsql)コマンド行で入力されたSQL文を分析できます。次のステップでは、索引アドバイザー・プラグインのロードと索引アドバイザーの使用について詳しく説明します。
1。
edb-psqlコマンドラインユーティリティを使用してサーバーに接続し、 Index Advisorプラグインをロードします。
$ edb-psql -d edb -U enterprisedb

edb=# LOAD 'index_advisor';
LOAD
2。
edb-psqlコマンド行を使用して、索引アドバイザーが分析する各SQLコマンドを呼び出します。索引アドバイザーは、照会の推奨事項をindex_advisor_log表にindex_advisor_logます。 index_advisor_logテーブルがユーザのsearch_path存在しない場合は、同じ名前のテンポラリテーブルが作成されます。この一時テーブルは、ユーザーのセッションの間だけ存在します。
索引アドバイザー・プラグインをロードすると、索引アドバイザーはすべてのSQL文を分析し、セッション中の索引推奨事項を記録します。
索引アドバイザーが実際に照会を実行せずに照会を分析(および索引付け推奨)する場合は、SQLステートメントの前に EXPLAINキーワードを付けて EXPLAIN
ステートメントを EXPLAINキーワードのindex_advisor_log ないと 、索引アドバイザーはステートメントの実行中にステートメントを分析し、後で検討するために索引推奨事項をindex_advisor_log表にindex_advisor_logます。
次の例では、 EXPLAIN文は、クエリが推奨された仮想インデックスを使用していた場合、通常のクエリプランと、同じクエリのクエリプランを表示します。
edb=# EXPLAIN SELECT * FROM t WHERE a < 10000;
QUERY PLAN
-----------------------------------------------------------------------------
Seq Scan on t (cost=0.00..1693.00 rows=10105 width=8)
Filter: (a < 10000)
Result (cost=0.00..337.10 rows=10105 width=8)
One-Time Filter: '===[ HYPOTHETICAL PLAN ]==='::text
-> Index Scan using "<hypothetical-index>:1" on t
(cost=0.00..337.10 rows=10105 width=8)
Index Cond: (a < 10000)
(6 rows)
 
 
edb=# EXPLAIN SELECT * FROM t WHERE a = 100;
QUERY PLAN
-----------------------------------------------------------------------------
Seq Scan on t (cost=0.00..1693.00 rows=1 width=8)
Filter: (a = 100)
Result (cost=0.00..8.28 rows=1 width=8)
One-Time Filter: '===[ HYPOTHETICAL PLAN ]==='::text
-> Index Scan using "<hypothetical-index>:3" on t
(cost=0.00..8.28 rows=1 width=8)
Index Cond: (a = 100)
(6 rows)
Index Advisorプラグインをロードすると、 index_advisor.enabled のデフォルト値onます。 index_advisor.enabled現在の値を表示するには、 SETまたはSHOWコマンドを使用するために索引アドバイザー・プラグインをロードする必要があります。
index_advisor.enabledパラメータを使用すると 、psqlセッションを中断せずにIndex Advisorを一時的に無効にすることができます
edb=# SET index_advisor.enabled TO off;
SET
索引アドバイザーを使用可能にするには、パラメーターを on 設定します
edb=# SET index_advisor.enabled TO on;
SET
 
3.2.4 索引アドバイザーの推奨事項の確認
索引アドバイザーによって生成された索引推奨事項を確認するには、いくつかの方法があります。あなたはできる:
index_advisor_logテーブルを照会します。
show_index_recommendations関数を実行します。
index_recommendationsビューを照会します。
 
3.2.4.1 show_index_recommendations()関数の使用
show_index_recommendations()関数を使用してIndex Advisorユーティリティの推奨事項を確認するには、セッションのプロセスIDを指定して関数を呼び出します。
SELECT show_index_recommendations( pid );
ここで、 pidは現在のセッションのプロセスIDです。現在のセッションのプロセスIDがわからない場合は、 NULL値を渡すと、現在のセッションの結果セットも返されNULL
次のコードは、結果セットの行の例を示しています。
edb=# SELECT show_index_recommendations(null);
show_index_recommendations
---------------------------------------------------------------------
create index idx_t_a on t(a);/* size: 2184 KB, benefit: 3040.62,
gain: 1.39222666981456 */
(1 row)
この例では、 t(a) on create index idx_t_aは、Index Advisorによって提案された索引を作成するために必要なSQLステートメントです。結果セットの各行には次の情報が表示されます。
すべてのIndex Advisorセッションの結果は、次のビューから表示できます。
SELECT * FROM index_recommendations;
3.2.4.2 index_advisor_logテーブルのクエリ
索引アドバイザーは、索引推奨事項を index_advisor_log という名前の表に index_advisor_logます。 index_advisor_log表の各行には、索引アドバイザーが仮想索引を推奨してその照会の実行コストを削減できると判断した照会の結果が入っています。
oid
psqlコマンドラインでindex_advisor_logテーブルを問い合わせることができます 。次の例は、2つの索引アドバイザー・セッションに起因するindex_advisor_log表の項目を示しています。各セッションには2つのクエリが含まれており、異なるbackend_pid値で識別できます(下の表を参照)。各セッションについて、索引アドバイザーは2つの索引推奨を生成しました。
edb=# SELECT * FROM index_advisor_log;
reloid | relname | attrs | benefit | index_size | backend_pid | timestamp
--------+---------+-------+---------+------------+-------------+----------------------------------
16651 | t | {1} | 1684.72 | 2184 | 3442 | 22-MAR-11 16:44:32.712638 -04:00
16651 | t | {2} | 1655.52 | 2184 | 3442 | 22-MAR-11 16:44:32.759436 -04:00
16651 | t | {1} | 1355.9 | 2184 | 3506 | 22-MAR-11 16:48:28.317016 -04:00
16651 | t | {1} | 1684.72 | 2184 | 3506 | 22-MAR-11 16:51:45.927906 -04:00
(4 rows)
索引アドバイザーは、 pg_advise_indexユーティリティーによって実行される次の2つの照会を分析した後、最初の2行を表に追加しました
 
SELECT * FROM t WHERE a = 500;
SELECT * FROM t WHERE b < 1000;
backend_pid の値 3442は、プロセスID 3442セッションからの結果であることを示します。
最初の行のattrsの値 1は、仮説索引が表の最初の列(表ta )にaを示します。
2番目の行のattrs 2 の値は 、仮想インデックスが表の2番目の列(表tbを示します。
索引アドバイザーは、次の2つの照会(psqlコマンド行で実行)を分析した後、最後の2行を表に追加しました。
edb=# EXPLAIN SELECT * FROM t WHERE a < 10000;
QUERY PLAN
----------------------------------------------------------------------------------------------
Seq Scan on t (cost=0.00..1693.00 rows=10105 width=8)
Filter: (a < 10000)
Result (cost=0.00..337.10 rows=10105 width=8)
One-Time Filter: '===[ HYPOTHETICAL PLAN ]==='::text
-> Index Scan using "<hypothetical-index>:1" on t (cost=0.00..337.10 rows=10105 width=8)
Index Cond: (a < 10000)
(6 rows)
 
edb=# EXPLAIN SELECT * FROM t WHERE a = 100;
QUERY PLAN
----------------------------------------------------------------------------------------
Seq Scan on t (cost=0.00..1693.00 rows=1 width=8)
Filter: (a = 100)
Result (cost=0.00..8.28 rows=1 width=8)
One-Time Filter: '===[ HYPOTHETICAL PLAN ]==='::text
-> Index Scan using "<hypothetical-index>:3" on t (cost=0.00..8.28 rows=1 width=8)
Index Cond: (a = 100)
(6 rows)
index_advisor_logテーブルのbenefitカラムの値は 、次の式を使用して計算されます。
benefit = (normal execution cost) - (execution cost with hypothetical index)
index_advisor_log表の最後の行(この例に示されている) benefitの値は 、次のSQL文の問合せ計画を使用して計算されます。
EXPLAIN SELECT * FROM t WHERE a = 100;
異なる実行計画の実行コストが評価され、比較されます。
benefit = (Seq Scan on t cost) - (Index Scan using <hypothetical-index>)
メリットがテーブルに追加されます。
benefit = 1693.00 - 8.28
benefit = 1684.72
行に格納されているクエリの結果を確認する必要がなくなったときに index_advisor_logテーブルから行を削除できます。
3.2.4.3 index_recommendationsビューのクエリ
index_recommendationsビューは、計算されたメトリックが含まれており、 CREATE INDEXその結果に現在あるすべてのセッションのために推奨されるインデックスを作成するためのステートメントをindex_advisor_logテーブル。格納されているすべてのIndex Advisorセッションの結果を表示するには、 index_recommendationsビューを次のように照会します。
SELECT * FROM index_recommendations;
index_recommendationsビューには、 前のセクション( index_advisor_logテーブルのクエリ )に示す例を使用して 、次の情報が表示されます。
edb=# SELECT * FROM index_recommendations;
backend_pid | show_index_recommendations
-------------+---------------------------------------------------------------------------------------------
3442 | create index idx_t_a on t(a);/* size: 2184 KB, benefit: 1684.72, gain: 0.771392654586624 */
3442 | create index idx_t_b on t(b);/* size: 2184 KB, benefit: 1655.52, gain: 0.758021539820856 */
3506 | create index idx_t_a on t(a);/* size: 2184 KB, benefit: 3040.62, gain: 1.39222666981456 */
(3 rows)
各セッション内で、同じ推奨インデックスから恩恵を受けるすべてのクエリの結果を組み合わせて、推奨インデックスごとに1セットのメトリックを作成します 。これは、 benefitおよびgain というフィールドに反映されます
フィールドの数式は次のとおりです。
size = MAX(index size of all queries)
benefit = SUM(benefit of each query)
gain = SUM(benefit of each query) / MAX(index size of all queries)
たとえば、 backend_pid3506 プロセスの次のクエリ結果を使用します
reloid | relname | attrs | benefit | index_size | backend_pid | timestamp
--------+---------+-------+---------+------------+-------------+----------------------------------
16651 | t | {1} | 1355.9 | 2184 | 3506 | 22-MAR-11 16:48:28.317016 -04:00
16651 | t | {1} | 1684.72 | 2184 | 3506 | 22-MAR-11 16:51:45.927906 -04:00
backend_pid 3506 index_recommendationsビューから表示されるメトリックは、次のとおりです。
backend_pid | show_index_recommendations
-------------+---------------------------------------------------------------------------------------------
3506 | create index idx_t_a on t(a);/* size: 2184 KB, benefit: 3040.62, gain: 1.39222666981456 */
ビューからのメトリックは次のように計算されます。
benefit = (benefit from 1st query) + (benefit from 2nd query)
benefit = 1355.9 + 1684.72
benefit = 3040.62
そして
gain = ((benefit from 1st query) + (benefit from 2nd query)) / MAX(index size of all queries)
gain = (1355.9 + 1684.72) / MAX(2184, 2184)
gain = 3040.62 / 2184
gain = 1.39223
利得メトリックは、特定のセッション中に導出された異なる推奨インデックスの相対的な優位性を比較する場合に役立ちます。ゲイン値が大きければ大きいほど、インデックスから得られるコスト効率は、インデックスのディスク容量の消費量に比例します。
3.2.5 制限事項
索引アドバイザーは索引のみのスキャンは考慮しません。推奨事項を作成する際にIndexスキャンを検討します。
索引アドバイザーは、 WHEREにある計算を無視します 。効果的に、推奨事項のインデックスフィールドはどんな種類の表現でもありません。フィールドは単純な列名になります。
索引アドバイザーは仮想索引を推薦する際に継承を考慮しません。照会が親表を参照する場合、索引アドバイザーは子表に関する索引推奨を行いません。
復元 pg_dump含むバックアップファイルindex_advisor_logテーブルまたはインデックス作成の推奨がなさに記憶されたため、任意のテーブルindex_advisor_log間の「リンク切れ」をもたらすことができるテーブル、 index_advisor_logの行によって参照されるテーブルと復元テーブルindex_advisor_logテーブルためにオブジェクト識別子(OID)の変更について説明します。
バックアップの前に推奨事項を表示する必要がある場合は 、SQL UPDATE文を使用して、 index_advisor_log表のreloid列の古い OIDを、参照先表の新しいOIDに置き換えることができます。
UPDATE index_advisor_log SET reloid = new_oid WHERE reloid = old_oid;
 
3.3 SQLプロファイラ
非効率的なSQLコードは、データベースのパフォーマンス問題の主な原因ではないにしても、その1つです。データベース管理者と開発者の課題は、大規模で複雑なシステムでこのコードを見つけて最適化することです。
SQLプロファイラは、実行中のSQLコードを見つけて最適化するのに役立ちます。
SQLプロファイラの特長と利点は次のとおりです。
オンデマンドトレース。手動でパラメータを設定し、トレースを開始することで、いつでもSQLトレースを取得できます。
スケジュールされたトレース。不都合な場合は、トレースパラメータを指定して後で実行するようにスケジュールすることもできます。
トレースを保存します。トレースを実行し、後で見直すために保存します。
トレースフィルタ。 SQLキャプチャをデータベースおよびユーザーごとに選択してフィルタ処理するか、またはすべてのユーザーがすべてのデータベースに対して送信したすべてのSQL文を取得します。
トレース出力アナライザ。グラフィカル・テーブルを使用すると、期間または文で問合せをすばやくソートしてフィルタ処理でき、グラフィカルまたはテキストベースのEXPLAINプランによって、クエリ・パスとジョインがレイアウトされます。
索引アドバイザーの統合。低速の問合せを見つけて最適化したら、索引アドバイザーが基礎となる表索引の作成を推奨して、パフォーマンスをさらに向上させることもできます。
次に、インストールプロセスについて説明します。
手順1: SQLプロファイラをインストールする
SQLプロファイラは、Windows上のAdvanced Serverインストーラまたは Linux上 edb-as xx -server-sqlprofiler RPMパッケージ( xxはAdvanced Serverバージョン番号) からインストールされます
手順2: SQLプロファイラライブラリを追加する
インスタンス postgresql.confパラメータファイルを変更して 、SQLプロファイラライブラリをshared_preload_librariesコンフィグレーションパラメータに含めます。
Linuxインストールの場合、パラメータ値には次のものを含める必要があります。
$libdir/sql-profiler
Windowsの場合、パラメータ値には以下が含まれている必要があります。
$libdir\sql-profiler.dll
手順3: SQLプロファイラで使用する関数を作成する
SQLプロファイラインストールプログラムは、SQLスクリプト( sql-profiler.sql )を次の場所に配置します
Linuxの場合:
/usr/edb/as11/share/contrib/
Windowsの場合:
C:\Program Files\edb\as11\share\contrib\
psqlコマンドラインインタフェースを使用して、 sql-profiler.sqlするサーバのメンテナンスデータベースとして指定されたデータベースでsql-profiler.sqlスクリプトを実行します。 Advanced Serverを使用している場合、デフォルトの保守データベースの名前はedbです。 PostgreSQLインスタンスを使用している場合、デフォルトのメンテナンスデータベースの名前はpostgresです。
次のコマンドは、 psqlコマンドラインを使用して、Linuxシステム上でsql-profiler.sqlスクリプトを呼び出します。
$ /usr/edb/as11/bin/psql -U user_name database_name < /usr/edb/as11/share/contrib/sql-profiler.sql
手順4:サーバーを停止して再起動し、変更を有効にします。
SQLプロファイラを設定すると、サーバー上のすべてのデータベースで使用できる状態になります。 EDB Postgres Enterprise ManagerでSQLプロファイラ機能を利用できます。 Postgres Enterprise Managerの詳細については、次のEnterpriseDB Webサイトを参照してください。
https://www.enterprisedb.com/resources/product-documentation
トラブルシューティング
新しいバージョンのSQLプロファイラにアップグレードした後、次のテキストを含むエラーが発生した場合:
An error has occurred:
ERROR: function return row and query-specified return row do not match.
DETAIL: Returned row contains 11 attributes, but the query expects 10.
このエラーを修正するには、既存のクエリセットを新しいクエリセットに置き換える必要があります。まず、起動することによって、SQLプロファイラをアンインストールし uninstall-sql-profiler.sqlスクリプトを、次に起動することによって、SQLプロファイラを再インストールしsql-profiler.sqlスクリプトを。
3.4 pgsnmpd
pgsnmpdは、Linuxシステム上のAdvanced Serverの現在の状態に関する階層情報を返すことができるSNMPエージェントです。 pgsnmpdedb-as xx -pgsnmpd RPMパッケージを使用して配布され、インストールされます。ここで、 xxはAdvanced Serverのバージョン番号です。 pgsnmpdエージェントは、スタンドアロンSNMPエージェント、パススルーサブエージェント、またはAgentXサブエージェントとして動作できます。
Advanced Serverのインストール後、 LD_LIBRARY_PATH変数を更新する必要があります。次のコマンドを使用します。
$ export LD_LIBRARY_PATH=/usr/edb/as11/lib:$LD_LIBRARY_PATH
このコマンドは、 LD_LIBRARY_PATH の値を永続的に変更しませんLD_LIBRARY_PATHの値を永続的に設定する方法については、Linuxディストリビューションのドキュメントを参照してください。
以下の例は、 pgsnmpd の最も単純な使い方を pgsnmpd 、読み取り専用アクセスを実装しています。 pgsnmpdはnet-snmpライブラリに基づいています。 net-snmpの詳細については、次のサイトを参照してください。
http://net-snmp.sourceforge.net/
3.4.1 pgsnmpdの設定
pgsnmpd設定ファイルの名前はsnmpd.conf 。設定ファイルで指定できるディレクティブについては、 snmpd.conf manページ( man snmpd.conf )を参照してください。
設定ファイルは手作業で作成することも、 snmpconf perlスクリプトを使って設定ファイルを作成することもできます。 perlスクリプトはnet-snmpパッケージとともに配布されています。
net-snmpは以下から入手可能なオープンソースのパッケージです:
http://www.net-snmp.org/
snmpconf設定ファイルウィザードを使用するには、net-snmpをダウンロードしてインストールします。インストールが完了したら、コマンドラインを開いて次のように入力します。
snmpconf
構成ファイルウィザードが開くと、既存の構成ファイルを読み込むように指示することがあります。既存の設定ファイルに基づいていない新しい設定ファイルを生成するには、 none入力します。
snmpconfはメニュー駆動のウィザードです。メニュー項目1: snmpd.confを選択して設定ウィザードを開始します。 snmpconfで表示される各トップレベルメニューオプションを選択すると、ウィザードで一連の質問が表示され、設定ファイルのビルドに必要な情報が表示されます。ご使用のシステムに関連するカテゴリーごとに情報を入力したら、 Finishedを入力してsnmpd.confという名前の構成ファイルを生成します。ファイルを次の場所にコピーします。
/usr/edb/as11/share/
3.4.2 リスナー・アドレスの設定
デフォルトでは、 pgsnmpdはポート161リッスンします。リスナーポートが既に別のサービスによって使用されている場合、次のエラーが発生することがあります。
Error opening specified endpoint "udp:161".
snmpd.confファイルに次の行を追加することによって、代替リスナー・ポートを指定することができます
agentaddress $host_address :2000
この例では、 pgsnmpdがUDPポート2000でリッスンするように指示します。 $host_addressはサーバーのIPアドレスです(例: 127.0.0.1 )。
3.4.3 pgsnmpdの呼び出し
Advanced Serverのインスタンスが稼働していることを確認します( pgsnmpdはこのサーバーに接続します)。次の形式のコマンドを使用してpgsnmpdを呼び出す前に、コマンドラインを開いてスーパーユーザー権限を引き受けます。
POSTGRES_INSTALL_HOME /bin/pgsnmpd -b
-c POSTGRES_INSTALL_HOME /share/snmpd.conf
-C "user=enterprisedb dbname=edb password=safe_password
port=5444"
どこ POSTGRES_INSTALL_HOME Advanced Serverのインストールディレクトリを指定します。
pgsnmpdをバックグラウンドで実行するように指定するには、 -bオプションを指定します。
pgsnmpd構成ファイルのパスと名前を指定して -cオプションを含めます。
-Cオプションの後に、 Advanced Serverをインストールするための接続情報( libpq接続文字列形式)を含めます。
3.4.4 pgsnmpdヘルプの表示
他のpgsnmpdコマンドラインオプションを表示するためにpgsnmpdユーティリティを呼び出すときに--helpオプションをインクルードします:
pgsnmpd --help
Version PGSQL-SNMP-Ver1.0
usage: pgsnmpd [-s] [-b] [-c FILE ] [-x address ] [-g] [-C "Connect String"]
-s : run as AgentX sub-agent of an existing snmpd process
-b : run in the background
-c : configuration file name
-g : use syslog
-C : libpq connection string
-x : address:port of a network interface
-V : display version strings
3.4.5 pgsnmpdからの情報の要求
net-snmpコマンドを使用して、 pgsnmpdサービスに問い合わせることができます 。例えば:
snmpgetnext -v 2c -c public localhost .1.3.6.1.4.1.5432.1.4.2.1.1.0
上記の例では、
-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など)。
任意のオブジェクトを照会するのに必要なエンコーディングは、MIB(管理情報ベース)で定義されています。 SNMPクライアントは、さまざまなサーバーを監視できます。サーバーの種類によって、特定のサーバーによって公開される情報が決まります。各SNMPサーバーは、公開されたデータをMIB(管理情報ベース)の形式で記述します。デフォルトでは、pgsnmpdは次の場所にあるMIBを検索します。
/usr/share/snmp/mibs
 
$HOME/.snmp/mibs
3.5 EDB監査ロギング
Advanced Serverを使用すると、データベース管理者、監査者、およびオペレータは、 EDB監査ログ機能を使用して、データベースアクティビティを追跡および分析できます 。 EDB監査ログは、すべての関連情報を含む監査ログファイルを生成します。監査ログは、次のような情報を記録するように構成できます。
設定ファイル postgresql.confまたはpostgresql.auto.conf指定されたパラメータは、監査ログに含まれる情報を制御します。
3.5.1 監査ログ設定パラメータ
データベース監査を制御するには、次の構成パラメータを使用します。 3.1.2 項を参照して、構成パラメータへの変更がすぐに有効になるか、構成を再ロードする必要があるか、またはデータベース・サーバーを再起動する必要があるかどうかを確認してください。
edb_audit
データベース監査を有効または無効にします。値 xmlまたはcsvは、データベース監査を有効にします。これらの値は、監査情報が取り込まれるファイル形式を表します。 noneはデータベース監査を無効にし、デフォルトでもあります。
edb_audit_directory
ログファイルを作成するディレクトリを指定します。ディレクトリのパスは、データフォルダの相対パスまたは絶対パスにすることができます。デフォルトは、 PGDATA/edb_auditディレクトリです。
edb_audit_filename
監査情報が格納される監査ファイルのファイル名を指定します。デフォルトのファイル名は audit-%Y%m%d_%H%M%Sです。エスケープシーケンス%Y%mなどは、システムの日付と時刻に従って適切な現在の値に置き換えられます。
edb_audit_rotation_day
監査ファイルをローテーションする曜日を指定します。有効な値は、 sunmontuewedthufrisatevery 、およびnoneです。回転を無効にするには、値をnone設定します。ファイルを毎日ローテーションするには、 edb_audit_rotation_day値をevery設定しevery 。特定の曜日にファイルを回転するには、値を希望の曜日に設定します。 everyがデフォルト値です。
edb_audit_rotation_size
ファイルのローテーションが強制的に発生する場合のファイルサイズのしきい値をメガバイト単位で指定します。デフォルト値は0 MBです。パラメータがコメントアウトされているか、または0に設定されている場合、サイズベースでのファイルのローテーションは発生しません。
edb_audit_rotation_seconds
新しいログファイルを作成する必要がある回転時間を秒単位で指定します。この機能を無効にするには、このパラメータをデフォルトの0に設定します。
edb_audit_connect
ユーザーによるデータベース接続試行の監査を有効にします。すべての接続試行の監査を無効にするには、 edb_audit_connectnone に設定します。失敗したすべての接続試行を監査するには、値をfailedに設定します。これがデフォルトです。すべての接続試行を監査するには、値をall設定します。
edb_audit_disconnect
接続されたユーザーによるデータベースの切断を監査できるようにします。切断の監査を有効にするには、値を all 設定します 。無効にするには、値をnoneに設定します。これはデフォルトです。
edb_audit_statement
この構成パラメーターは、さまざまなカテゴリーのSQLステートメントの監査を指定するために使用されます。 nonedmlinsertupdatedeletetruncateselecterrorrollbackddlcreatedropaltergrantrevoke 、およびall さまざまな組み合わせを指定できます 。デフォルトはddlerrorです。このパラメータの設定については、 3.5.2項を参照してください。
edb_audit_tag
この構成パラメータを使用して、各エントリの監査ログファイルに追跡タグとして含める文字列値を指定します。
edb_log_every_bulk_value
一括処理は、結果のステートメントをAdvanced ServerログファイルとEDB監査ログファイルの両方に記録します。しかし、一括処理における各ステートメントのロギングにはコストがかかります。これは、 edb_log_every_bulk_value構成パラメーターによって制御することができます。 trueに設定すると、一括処理のすべてのステートメントがログに記録されます。 falseに設定するfalse 、一括処理ごとにログメッセージが1回記録されます。さらに、持続時間は一括処理ごとに1回発行されます。デフォルトはfalseです。
edb_audit_destination
監査ログ情報を edb_audit_directoryパラメータで指定されたディレクトリに記録するか、 syslogプロセスで管理されているディレクトリとファイルにedb_audit_directoryするかを指定します。デフォルトの設定であるedb_audit_directoryで指定されたディレクトリを使用するようにfileに設定しfile 。設定syslogに設定されたsyslogプロセスとその場所を使用し/etc/syslog.confファイル。 注:最近のLinuxバージョンでは、syslogがrsyslogのに置き換えられていると設定ファイルがである/etc/rsyslog.conf
次のセクションでは、 edb_audit_statementパラメーターを使用して監査する特定のSQLステートメントの選択について説明します。
3.5.2 監査するSQL文の選択
edb_audit_statementステートメントが監査されるべきSQLを制御するための1つ以上、カンマ区切り値の包含を可能にします。一般的な形式は次のとおりです。
edb_audit_statement = ' value_1 [, value_2 ]...'
カンマ区切りの値には、カンマの後に空白文字を含めるか省略することができます。値は、小文字または大文字の任意の組み合わせで指定できます。
基本的なパラメータ値は次のとおりです。
all - ステートメントのエラーメッセージを含む、すべてのステートメントの監査とロギングを行います。
none - すべての監査とロギングを無効にします。 noneの値は、リストに含まれる他の値を上書きします。
ddl - すべてのデータ定義言語(DDL)文( CREATEALTER 、およびDROP )およびGRANTおよびREVOKEデータ制御言語(DCL)文の監査を行います。
dml - すべてのデータ操作言語(DML)文( INSERTUPDATEDELETE 、およびTRUNCATE )の監査を行います。
select - SELECTステートメントの監査を行います。
rollback - ROLLBACK文の監査を行いROLLBACK
error - 発生したすべてのエラーメッセージのログを記録します。 error値が含まれていないかぎり、 allが使用されている場合を除いて、前述の他のパラメータ値に関連するSQL文で発生するエラーに関するエラー・メッセージは記録されません。
3.5.2.1 項では 、監査用に特定のDDLまたはDCL文を選択するための追加のパラメータ値について説明します。
3.5.2.2 項では 、監査のために特定のDML文を選択するための追加のパラメータ値について説明します。
サポートされていない値が edb_audit_statementパラメーターに含まれている場合は 、データベース・サーバーに設定を適用するときにエラーが発生します。 create materialized vwれたcreate materialized vwでエラーが発生create materialized vw次の例のようなエラーについては、データベースサーバーのログファイルを参照してください。 (正しい値はcreate materialized viewです。)
2017-07-16 11:20:39 EDT LOG: invalid value for parameter "edb_audit_statement": "create materialized vw, create sequence, grant"
2017-07-16 11:20:39 EDT FATAL: configuration file "/var/lib/edb/as11/data/postgresql.conf" contains errors
以下のセクションでは、SQL言語タイプDDL、DCL、およびDMLの値について説明します。
3.5.2.1 データ定義言語およびデータ制御言語文
この項では、 DDLおよびDCL文を監査するために edb_audit_statementパラメータに含めることができる値について説明します
次の一般規則が適用されます。
edb_audit_statementパラメーターにddlまたはall含まれている場合は 、すべてのDDLステートメントが監査されます。さらに、DCLステートメントGRANTおよびREVOKEも監査されます。
edb_audit_statementnoneに設定されている場合、 DDL文もDCL文も監査されnone
DDL文のedb_audit_statementパラメータ値を指定するには、次の構文を使用します
{ create | alter | drop } [ object_type ]
object_typeは次のいずれかです。
ACCESS METHOD
AGGREGATE
CAST
COLLATION
CONVERSION
DATABASE
EVENT TRIGGER
EXTENSION
FOREIGN TABLE
FUNCTION
INDEX
LANGUAGE
LARGE OBJECT
MATERIALIZED VIEW
OPERATOR
OPERATOR CLASS
OPERATOR FAMILY
POLICY
PUBLICATION
ROLE
RULE
SCHEMA
SEQUENCE
SERVER
SUBSCRIPTION
TABLE
TABLESPACE
TEXT SEARCH CONFIGURATION
TEXT SEARCH DICTIONARY
TEXT SEARCH PARSER
TEXT SEARCH TEMPLATE
TRANSFORM
TRIGGER
TYPE
USER MAPPING
VIEW
SQLコマンドで使用されるオブジェクトタイプの説明については、次のPostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/sql-commands.html
object_typeがパラメータ値から省略された場合 、指定されたすべてのコマンド文( createalter 、またはdropいずれか)が監査されます。
DCL文のedb_audit_statementパラメータ値を指定するには、次の構文を使用します
{ grant | revoke }
以下は、DDLとDCLの例です。
例1
以下は、 edb_audit_connectおよびedb_audit_statementが次のデフォルト以外の値で設定されている例です。
edb_audit_connect = 'all'
edb_audit_statement = 'create, alter, error'
したがって、 CREATEコマンドとALTERコマンドによって呼び出されたSQL文だけが監査されます。エラーメッセージも監査ログに含まれます。
発生するデータベースセッションは次のとおりです。
$ psql edb enterprisedb
Password for user enterprisedb:
psql.bin (10.0.1)
Type "help" for help.
 
edb=# SHOW edb_audit_connect;
edb_audit_connect
-------------------
all
(1 row)
 
edb=# SHOW edb_audit_statement;
edb_audit_statement
----------------------
create, alter, error
(1 row)
 
edb=# CREATE ROLE adminuser;
CREATE ROLE
edb=# ALTER ROLE adminuser WITH LOGIN, SUPERUSER, PASSWORD 'password';
ERROR: syntax error at or near ","
LINE 1: ALTER ROLE adminuser WITH LOGIN, SUPERUSER, PASSWORD 'passwo...
^
edb=# ALTER ROLE adminuser WITH LOGIN SUPERUSER PASSWORD 'password';
ALTER ROLE
edb=# CREATE DATABASE auditdb;
CREATE DATABASE
edb=# ALTER DATABASE auditdb OWNER TO adminuser;
ALTER DATABASE
edb=# \c auditdb adminuser
Password for user adminuser:
You are now connected to database "auditdb" as user "adminuser".
auditdb=# CREATE SCHEMA edb;
CREATE SCHEMA
auditdb=# SET search_path TO edb;
SET
auditdb=# CREATE TABLE department (
auditdb(# deptno NUMBER(2) NOT NULL CONSTRAINT dept_pk PRIMARY KEY,
auditdb(# dname VARCHAR2(14) CONSTRAINT dept_dname_uq UNIQUE,
auditdb(# loc VARCHAR2(13)
auditdb(# );
CREATE TABLE
auditdb=# DROP TABLE department;
DROP TABLE
auditdb=# CREATE TABLE dept (
auditdb(# deptno NUMBER(2) NOT NULL CONSTRAINT dept_pk PRIMARY KEY,
auditdb(# dname VARCHAR2(14) CONSTRAINT dept_dname_uq UNIQUE,
auditdb(# loc VARCHAR2(13)
auditdb(# );
CREATE TABLE
監査ログファイルには、次のものが含まれます。
各監査ログエントリは複数の行に分割されて表示され、結果の外観をより明確にするために、監査ログエントリ間に空白行が挿入されています。
2017-07-16 12:59:42.125 EDT,"enterprisedb","edb",3356,"[local]",
596b9b7e.d1c,1,"authentication",2017-07-16 12:59:42 EDT,6/2,0,AUDIT,00000,
"connection authorized: user=enterprisedb database=edb",,,,,,,,,"","",""
 
2017-07-16 12:59:42.125 EDT,"enterprisedb","edb",3356,"[local]",
596b9b7e.d1c,2,"idle",2017-07-16 12:59:42 EDT,6/6,0,AUDIT,00000,
"statement: CREATE ROLE adminuser;",,,,,,,,,"psql.bin","CREATE ROLE",""
 
2017-07-16 13:00:28.469 EDT,"enterprisedb","edb",3356,"[local]",
596b9b7e.d1c,3,"idle",2017-07-16 12:59:42 EDT,6/7,0,ERROR,42601,
"syntax error at or near "",""",,,,,,
"ALTER ROLE adminuser WITH LOGIN, SUPERUSER, PASSWORD 'password';",32,,"psql.bin","",""
 
2017-07-16 13:00:28.469 EDT,"enterprisedb","edb",3356,"[local]",
596b9b7e.d1c,4,"idle",2017-07-16 12:59:42 EDT,6/8,0,AUDIT,00000,
"statement: ALTER ROLE adminuser WITH LOGIN SUPERUSER PASSWORD 'password';",,,,,,,,,
"psql.bin","ALTER ROLE",""
 
2017-07-16 13:00:28.469 EDT,"enterprisedb","edb",3356,"[local]",
596b9b7e.d1c,5,"idle",2017-07-16 12:59:42 EDT,6/9,0,AUDIT,00000,
"statement: CREATE DATABASE auditdb;",,,,,,,,,"psql.bin","CREATE DATABASE",""
 
2017-07-16 13:00:28.469 EDT,"enterprisedb","edb",3356,"[local]",
596b9b7e.d1c,6,"idle",2017-07-16 12:59:42 EDT,6/10,0,AUDIT,00000,
"statement: ALTER DATABASE auditdb OWNER TO adminuser;",,,,,,,,,"psql.bin","ALTER DATABASE",""
 
2017-07-16 13:01:13.735 EDT,"adminuser","auditdb",3377,"[local]",
596b9bd9.d31,1,"authentication",2017-07-16 13:01:13 EDT,4/15,0,AUDIT,00000,
"connection authorized: user=adminuser database=auditdb",,,,,,,,,"","",""
 
2017-07-16 13:01:13.735 EDT,"adminuser","auditdb",3377,"[local]",
596b9bd9.d31,2,"idle",2017-07-16 13:01:13 EDT,4/17,0,AUDIT,00000,
"statement: CREATE SCHEMA edb;",,,,,,,,,"psql.bin","CREATE SCHEMA",""
 
2017-07-16 13:01:13.735 EDT,"adminuser","auditdb",3377,"[local]",
596b9bd9.d31,3,"idle",2017-07-16 13:01:13 EDT,4/19,0,AUDIT,00000,
"statement: CREATE TABLE department (
deptno NUMBER(2) NOT NULL CONSTRAINT dept_pk PRIMARY KEY,
dname VARCHAR2(14) CONSTRAINT dept_dname_uq UNIQUE,
loc VARCHAR2(13)
);",,,,,,,,,"psql.bin","CREATE TABLE",""
 
2017-07-16 13:01:13.735 EDT,"adminuser","auditdb",3377,"[local]",
596b9bd9.d31,4,"idle",2017-07-16 13:01:13 EDT,4/21,0,AUDIT,00000,
"statement: CREATE TABLE dept (
deptno NUMBER(2) NOT NULL CONSTRAINT dept_pk PRIMARY KEY,
dname VARCHAR2(14) CONSTRAINT dept_dname_uq UNIQUE,
loc VARCHAR2(13)
);",,,,,,,,,"psql.bin","CREATE TABLE",""
adminuserロールおよびauditdbデータベース CREATEおよびALTERステートメントが監査されます。エラーがedb_audit_statementパラメーターに含まれているため、 ALTER ROLE adminuserステートメントのエラーも記録されます。
同様に、スキーマedbおよび表departmentおよびdept CREATEステートメントが監査されます。
正常に処理されたDROPステートメント( ddlall 、またはdropなど)の監査にedb_audit_statement設定がないため DROP TABLE departmentステートメントは監査ログにはないことに注意してください
例2
以下は、 edb_audit_connectおよびedb_audit_statementが次のデフォルト以外の値で設定されている例です。
edb_audit_connect = 'all'
edb_audit_statement = create view,create materialized view,create sequence,grant'
したがって、 CREATE VIEWCREATE MATERIALIZED VIEWCREATE SEQUENCEおよびGRANTコマンドによって呼び出されたSQL文だけが監査されます。
発生するデータベースセッションは次のとおりです。
$ psql auditdb adminuser
Password for user adminuser:
psql.bin (10.0.1)
Type "help" for help.
 
auditdb=# SHOW edb_audit_connect;
edb_audit_connect
-------------------
all
(1 row)
 
auditdb=# SHOW edb_audit_statement;
edb_audit_statement
------------------------------------------------------------
create view,create materialized view,create sequence,grant
(1 row)
 
auditdb=# SET search_path TO edb;
SET
auditdb=# CREATE TABLE emp (
auditdb(# empno NUMBER(4) NOT NULL CONSTRAINT emp_pk PRIMARY KEY,
auditdb(# ename VARCHAR2(10),
auditdb(# job VARCHAR2(9),
auditdb(# mgr NUMBER(4),
auditdb(# hiredate DATE,
auditdb(# sal NUMBER(7,2) CONSTRAINT emp_sal_ck CHECK (sal > 0),
auditdb(# comm NUMBER(7,2),
auditdb(# deptno NUMBER(2) CONSTRAINT emp_ref_dept_fk
auditdb(# REFERENCES dept(deptno)
auditdb(# );
CREATE TABLE
auditdb=# CREATE VIEW salesemp AS
auditdb-# SELECT empno, ename, hiredate, sal, comm FROM emp WHERE job = 'SALESMAN';
CREATE VIEW
auditdb=# CREATE MATERIALIZED VIEW managers AS
auditdb-# SELECT empno, ename, hiredate, sal, comm FROM emp WHERE job = 'MANAGER';
SELECT 0
auditdb=# CREATE SEQUENCE next_empno START WITH 8000 INCREMENT BY 1;
CREATE SEQUENCE
auditdb=# GRANT ALL ON dept TO PUBLIC;
GRANT
auditdb=# GRANT ALL ON emp TO PUBLIC;
GRANT
監査ログファイルには、次のものが含まれます。
各監査ログエントリは複数の行に分割されて表示され、結果の外観をより明確にするために、監査ログエントリ間に空白行が挿入されています。
2017-07-16 13:20:09.836 EDT,"adminuser","auditdb",4143,"[local]",
596ba049.102f,1,"authentication",2017-07-16 13:20:09 EDT,4/10,0,AUDIT,00000,
"connection authorized: user=adminuser database=auditdb",,,,,,,,,"","",""
 
2017-07-16 13:20:09.836 EDT,"adminuser","auditdb",4143,"[local]",
596ba049.102f,2,"idle",2017-07-16 13:20:09 EDT,4/16,0,AUDIT,00000,
"statement: CREATE VIEW salesemp AS
SELECT empno, ename, hiredate, sal, comm FROM emp WHERE job = 'SALESMAN';",,,,,,,,,"psql.bin","CREATE VIEW",""
 
2017-07-16 13:20:09.836 EDT,"adminuser","auditdb",4143,"[local]",
596ba049.102f,3,"idle",2017-07-16 13:20:09 EDT,4/17,0,AUDIT,00000,
"statement: CREATE MATERIALIZED VIEW managers AS
SELECT empno, ename, hiredate, sal, comm FROM emp WHERE job = 'MANAGER';",,,,,,,,,"psql.bin","CREATE MATERIALIZED VIEW",""
 
2017-07-16 13:20:09.836 EDT,"adminuser","auditdb",4143,"[local]",
596ba049.102f,4,"idle",2017-07-16 13:20:09 EDT,4/18,0,AUDIT,00000,
"statement: CREATE SEQUENCE next_empno START WITH 8000 INCREMENT BY 1;",,,,,,,,,"psql.bin","CREATE SEQUENCE",""
 
2017-07-16 13:20:09.836 EDT,"adminuser","auditdb",4143,"[local]",
596ba049.102f,5,"idle",2017-07-16 13:20:09 EDT,4/19,0,AUDIT,00000,
"statement: GRANT ALL ON dept TO PUBLIC;",,,,,,,,,"psql.bin","GRANT",""
 
2017-07-16 13:20:09.836 EDT,"adminuser","auditdb",4143,"[local]",
596ba049.102f,6,"idle",2017-07-16 13:20:09 EDT,4/20,0,AUDIT,00000,
"statement: GRANT ALL ON emp TO PUBLIC;",,,,,,,,,"psql.bin","GRANT",""
CREATE VIEWおよびCREATE MATERIALIZED VIEW文が監査されます。以前のCREATE TABLE empステートメントは、 createcreate tableddl 、またはalledb_audit_statementパラメーターに含まれていないので、監査されないことに注意してください。
CREATE SEQUENCEGRANT文は、それらの値が含まれているため監査されedb_audit_statementパラメータ。
3.5.2.2 データ操作言語ステートメント
この項では、 DML文を監査するために edb_audit_statementパラメータに含めることができる値について説明します
次の一般規則が適用されます。
edb_audit_statementパラメータにdmlまたはallいずれかが含まれている場合は 、すべてのDML文が監査されます。
edb_audit_statementnoneに設定されている場合、 DML文は監査されnone
SQL INSERTUPDATEDELETE 、またはTRUNCATEステートメントのedb_audit_statementパラメーター値を指定するには、次の構文を使用します
{ insert | update | delete | truncate }
以下は、 edb_audit_connectおよびedb_audit_statementが次のデフォルト以外の値で設定されている例です。
edb_audit_connect = 'all'
edb_audit_statement = 'UPDATE, DELETE, error'
したがって、 UPDATEおよびDELETEコマンドによって呼び出されたSQL文だけが監査されます。すべてのエラーは、監査ログにも含まれます( UPDATEおよびDELETEコマンドに関連しないエラーでさえも)。
発生するデータベースセッションは次のとおりです。
$ psql auditdb adminuser
Password for user adminuser:
psql.bin (10.0.1)
Type "help" for help.
 
auditdb=# SHOW edb_audit_connect;
edb_audit_connect
-------------------
all
(1 row)
 
auditdb=# SHOW edb_audit_statement;
edb_audit_statement
-----------------------
UPDATE, DELETE, error
(1 row)
 
auditdb=# SET search_path TO edb;
SET
auditdb=# INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK');
INSERT 0 1
auditdb=# INSERT INTO dept VALUES (20,'RESEARCH','DALLAS');
INSERT 0 1
auditdb=# INSERT INTO dept VALUES (30,'SALES','CHICAGO');
INSERT 0 1
auditdb=# INSERT INTO dept VALUES (40,'OPERATIONS','BOSTON');
INSERT 0 1
auditdb=# INSERT INTO emp VALUES (7369,'SMITH','CLERK',7902,'17-DEC-80',800,NULL,20);
INSERT 0 1
auditdb=# INSERT INTO emp VALUES (7499,'ALLEN','SALESMAN',7698,'20-FEB-81',1600,300,30);
INSERT 0 1
auditdb=# INSERT INTO emp VALUES (7521,'WARD','SALESMAN',7698,'22-FEB-81',1250,500,30);
INSERT 0 1
.
.
.
auditdb=# INSERT INTO emp VALUES (7934,'MILLER','CLERK',7782,'23-JAN-82',1300,NULL,10);
INSERT 0 1
auditdb=# UPDATE dept SET loc = 'BEDFORD' WHERE deptno = 40;
UPDATE 1
auditdb=# SELECT * FROM dept;
deptno | dname | loc
--------+------------+----------
10 | ACCOUNTING | NEW YORK
20 | RESEARCH | DALLAS
30 | SALES | CHICAGO
40 | OPERATIONS | BEDFORD
(4 rows)
 
auditdb=# DELETE FROM emp WHERE deptno = 10;
DELETE 3
auditdb=# TRUNCATE employee;
ERROR: relation "employee" does not exist
auditdb=# TRUNCATE emp;
TRUNCATE TABLE
auditdb=# \q
監査ログファイルには、次のものが含まれます。
各監査ログエントリは複数の行に分割されて表示され、結果の外観をより明確にするために、監査ログエントリ間に空白行が挿入されています。
2017-07-16 13:43:26.638 EDT,"adminuser","auditdb",4574,"[local]",
596ba5be.11de,1,"authentication",2017-07-16 13:43:26 EDT,4/11,0,AUDIT,00000,
"connection authorized: user=adminuser database=auditdb",,,,,,,,,"","",""
 
2017-07-16 13:43:26.638 EDT,"adminuser","auditdb",4574,"[local]",
596ba5be.11de,2,"idle",2017-07-16 13:43:26 EDT,4/34,0,AUDIT,00000,
"statement: UPDATE dept SET loc = 'BEDFORD' WHERE deptno = 40;",,,,,,,,,"psql.bin","UPDATE",""
 
2017-07-16 13:43:26.638 EDT,"adminuser","auditdb",4574,"[local]",
596ba5be.11de,3,"idle",2017-07-16 13:43:26 EDT,4/36,0,AUDIT,00000,
"statement: DELETE FROM emp WHERE deptno = 10;",,,,,,,,,"psql.bin","DELETE",""
 
2017-07-16 13:45:46.999 EDT,"adminuser","auditdb",4574,"[local]",
596ba5be.11de,4,"TRUNCATE TABLE",2017-07-16 13:43:26 EDT,4/37,0,ERROR,42P01,
"relation ""employee"" does not exist",,,,,,"TRUNCATE employee;",,,"psql.bin","",""
 
2017-07-16 13:46:26.362 EDT,,,4491,,596ba59c.118b,1,,2017-07-16 13:42:52 EDT,,0,LOG,00000,
"database system is shut down",,,,,,,,,"","",""
UPDATE deptDELETE FROM empステートメントが監査されます。以前のINSERTステートメントはalledb_audit_statementパラメーターにinsertdml 、またはall値が含まれていないため、監査されないことに注意してください。
SELECT * FROM dept文はどちら以来、同様に監査されていないselectall含まれedb_audit_statementパラメータ。
以来 errorで指定されたedb_audit_statementパラメータではなく、 truncate値を、上のエラーTRUNCATE employee文は成功した監査ファイルに記録していないが、 TRUNCATE emp声明を。
3.5.3 監査ログの有効化
次の手順では、すべての接続、切断、DDL文、DCL文、DML文、およびエラーが発生した文をすべて記録するようにAdvanced Serverを構成する方法を説明します。
1。
edb_auditパラメータをxmlまたはcsv 設定して監査を有効にします。
2。
3。
4。
5。
DDL、DCL、DMLなどの文を監査するには、 3.5.2項の手順に従ってedb_audit_statement パラメータを設定します
構成ファイル内 edb_audit_statementパラメーターの設定は、データベース・クラスター全体に影響します。
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に設定しallその中に示されているようpostgresql.confファイル:
edb_audit_statement = 'all' # Statement type to be audited:
# none, dml, insert, update, delete, truncate,
# select, error, rollback, ddl, create, drop,
# alter, grant, revoke, all
edb_audit_statementパラメータの次の設定でデータベースとロールが確立されます。
ddlinsertupdate 、およびdelete データベース auditdb
selecttruncateによるロール admin
create tableinsert 、およびupdatecreate tableしたデータベースauditdb ロール admin
データベースとロールの作成と変更は、次のように表示されます。
$ psql edb enterprisedb
Password for user enterprisedb:
psql.bin (10.0.1)
Type "help" for help.
 
edb=# SHOW edb_audit_statement;
edb_audit_statement
---------------------
all
(1 row)
 
edb=# CREATE DATABASE auditdb;
CREATE DATABASE
edb=# ALTER DATABASE auditdb SET edb_audit_statement TO 'ddl, insert, update, delete';
ALTER DATABASE
edb=# CREATE ROLE admin WITH LOGIN SUPERUSER PASSWORD 'password';
CREATE ROLE
edb=# ALTER ROLE admin SET edb_audit_statement TO 'select, truncate';
ALTER ROLE
edb=# ALTER ROLE admin IN DATABASE auditdb SET edb_audit_statement TO 'create table, insert, update';
ALTER ROLE
以下は、3つのケースで行われた変更と結果の監査ログファイルを示しています。
事例1:役割enterprisedbによってデータベースauditdb行われた変更。 ddlinsertupdate 、およびdelete文だけが監査されます。
$ psql auditdb enterprisedb
Password for user enterprisedb:
psql.bin (10.0.1)
Type "help" for help.
 
auditdb=# SHOW edb_audit_statement;
edb_audit_statement
-----------------------------
ddl, insert, update, delete
(1 row)
 
auditdb=# CREATE TABLE audit_tbl (f1 INTEGER PRIMARY KEY, f2 TEXT);
CREATE TABLE
auditdb=# INSERT INTO audit_tbl VALUES (1, 'Row 1');
INSERT 0 1
auditdb=# UPDATE audit_tbl SET f2 = 'Row A' WHERE f1 = 1;
UPDATE 1
auditdb=# SELECT * FROM audit_tbl; <== Should not be audited
f1 | f2
----+-------
1 | Row A
(1 row)
 
auditdb=# TRUNCATE audit_tbl; <== Should not be audited
TRUNCATE TABLE
次の監査ログファイルには、 CREATE TABLEINSERT INTO audit_tbl 、およびUPDATE audit_tblステートメントのエントリのみが表示されますSELECT * FROM audit_tblおよびTRUNCATE audit_tbl文は監査されませんでした。
各監査ログエントリは複数の行に分割されて表示され、結果の外観をより明確にするために、監査ログエントリ間に空白行が挿入されています。
2017-07-13 15:26:17.426 EDT,"enterprisedb","auditdb",4024,"[local]",
5967c947.fb8,1,"idle",2017-07-13 15:25:59 EDT,7/4,0,AUDIT,00000,
"statement: CREATE TABLE audit_tbl (f1 INTEGER PRIMARY KEY, f2 TEXT);",,,,,,,,,
"psql.bin","CREATE TABLE",""
 
2017-07-13 15:26:17.426 EDT,"enterprisedb","auditdb",4024,"[local]",
5967c947.fb8,2,"idle",2017-07-13 15:25:59 EDT,7/5,0,AUDIT,00000,
"statement: INSERT INTO audit_tbl VALUES (1, 'Row 1');",,,,,,,,,"psql.bin","INSERT",""
 
2017-07-13 15:26:17.426 EDT,"enterprisedb","auditdb",4024,"[local]",
5967c947.fb8,3,"idle",2017-07-13 15:25:59 EDT,7/6,0,AUDIT,00000,
"statement: UPDATE audit_tbl SET f2 = 'Row A' WHERE f1 = 1;",,,,,,,,,"psql.bin","UPDATE",""
ケース2:データベースに加えた変更edbの役割によってadminselect文とtruncate文だけが監査されます。
$ psql edb admin
Password for user admin:
psql.bin (10.0.1)
Type "help" for help.
 
edb=# SHOW edb_audit_statement;
edb_audit_statement
---------------------
select, truncate
(1 row)
 
edb=# CREATE TABLE edb_tbl (f1 INTEGER PRIMARY KEY, f2 TEXT) <== Should not be audited
CREATE TABLE
edb=# INSERT INTO edb_tbl VALUES (1, 'Row 1'); <== Should not be audited
INSERT 0 1
edb=# SELECT * FROM edb_tbl;
f1 | f2
----+-------
1 | Row 1
(1 row)
 
edb=# TRUNCATE edb_tbl;
TRUNCATE TABLE
監査ログファイルの続きが次のように表示されます。 2番目のケースを表す最後の2つのエントリは、 SELECT * FROM edb_tblおよびTRUNCATE edb_tblだけを示します。 CREATE TABLE edb_tblおよびINSERT INTO edb_tblステートメントは監査されませんでした。
2017-07-13 15:26:17.426 EDT,"enterprisedb","auditdb",4024,"[local]",
5967c947.fb8,1,"idle",2017-07-13 15:25:59 EDT,7/4,0,AUDIT,00000,
"statement: CREATE TABLE audit_tbl (f1 INTEGER PRIMARY KEY, f2 TEXT);",,,,,,,,,
"psql.bin","CREATE TABLE",""
 
2017-07-13 15:26:17.426 EDT,"enterprisedb","auditdb",4024,"[local]",
5967c947.fb8,2,"idle",2017-07-13 15:25:59 EDT,7/5,0,AUDIT,00000,
"statement: INSERT INTO audit_tbl VALUES (1, 'Row 1');",,,,,,,,,"psql.bin","INSERT",""
 
2017-07-13 15:26:17.426 EDT,"enterprisedb","auditdb",4024,"[local]",
5967c947.fb8,3,"idle",2017-07-13 15:25:59 EDT,7/6,0,AUDIT,00000,
"statement: UPDATE audit_tbl SET f2 = 'Row A' WHERE f1 = 1;",,,,,,,,,"psql.bin","UPDATE",""
 
2017-07-13 15:29:45.616 EDT,"admin","edb",4047,"[local]",
5967ca05.fcf,1,"idle",2017-07-13 15:29:09 EDT,4/33,0,AUDIT,00000,
"statement: SELECT * FROM edb_tbl;",,,,,,,,,"psql.bin","SELECT",""
 
2017-07-13 15:29:45.616 EDT,"admin","edb",4047,"[local]",
5967ca05.fcf,2,"idle",2017-07-13 15:29:09 EDT,4/34,0,AUDIT,00000,
"statement: TRUNCATE edb_tbl;",,,,,,,,,"psql.bin","TRUNCATE TABLE",""
ケース3:役割のadminによってデータベースのauditdb行われた変更。 create tableinsert 、およびupdate文だけが監査されます。
$ psql auditdb admin
Password for user admin:
psql.bin (10.0.1)
Type "help" for help.
 
auditdb=# SHOW edb_audit_statement;
edb_audit_statement
------------------------------
create table, insert, update
(1 row)
 
auditdb=# CREATE TABLE audit_tbl_2 (f1 INTEGER PRIMARY KEY, f2 TEXT);
CREATE TABLE
auditdb=# INSERT INTO audit_tbl_2 VALUES (1, 'Row 1');
INSERT 0 1
auditdb=# SELECT * FROM audit_tbl_2; <== Should not be audited
f1 | f2
----+-------
1 | Row 1
(1 row)
 
auditdb=# TRUNCATE audit_tbl_2; <== Should not be audited
TRUNCATE TABLE
監査ログファイルの続きが次のように表示されます。 3番目のケースを表す最後の2つのエントリの次に、 CREATE TABLE audit_tbl_2INSERT INTO audit_tbl_2ステートメントのみが表示されます。 SELECT * FROM audit_tbl_2およびTRUNCATE audit_tbl_2ステートメントは監査されませんでした。
2017-07-13 15:26:17.426 EDT,"enterprisedb","auditdb",4024,"[local]",
5967c947.fb8,1,"idle",2017-07-13 15:25:59 EDT,7/4,0,AUDIT,00000,
"statement: CREATE TABLE audit_tbl (f1 INTEGER PRIMARY KEY, f2 TEXT);",,,,,,,,,
"psql.bin","CREATE TABLE",""
 
2017-07-13 15:26:17.426 EDT,"enterprisedb","auditdb",4024,"[local]",
5967c947.fb8,2,"idle",2017-07-13 15:25:59 EDT,7/5,0,AUDIT,00000,
"statement: INSERT INTO audit_tbl VALUES (1, 'Row 1');",,,,,,,,,"psql.bin","INSERT",""
 
2017-07-13 15:26:17.426 EDT,"enterprisedb","auditdb",4024,"[local]",
5967c947.fb8,3,"idle",2017-07-13 15:25:59 EDT,7/6,0,AUDIT,00000,
"statement: UPDATE audit_tbl SET f2 = 'Row A' WHERE f1 = 1;",,,,,,,,,"psql.bin","UPDATE",""
 
2017-07-13 15:29:45.616 EDT,"admin","edb",4047,"[local]",
5967ca05.fcf,1,"idle",2017-07-13 15:29:09 EDT,4/33,0,AUDIT,00000,
"statement: SELECT * FROM edb_tbl;",,,,,,,,,"psql.bin","SELECT",""
 
2017-07-13 15:29:45.616 EDT,"admin","edb",4047,"[local]",
5967ca05.fcf,2,"idle",2017-07-13 15:29:09 EDT,4/34,0,AUDIT,00000,
"statement: TRUNCATE edb_tbl;",,,,,,,,,"psql.bin","TRUNCATE TABLE",""
 
2017-07-13 15:35:45.309 EDT,"admin","auditdb",4085,"[local]",
5967cb81.ff5,1,"idle",2017-07-13 15:35:29 EDT,4/72,0,AUDIT,00000,
"statement: CREATE TABLE audit_tbl_2 (f1 INTEGER PRIMARY KEY, f2 TEXT);",,,,,,,,,
"psql.bin","CREATE TABLE",""
 
2017-07-13 15:35:45.309 EDT,"admin","auditdb",4085,"[local]",
5967cb81.ff5,2,"idle",2017-07-13 15:35:29 EDT,4/73,0,AUDIT,00000,
"statement: INSERT INTO audit_tbl_2 VALUES (1, 'Row 1');",,,,,,,,,"psql.bin","INSERT",""
 
2017-07-13 15:38:42.028 EDT,,,3942,,5967c934.f66,1,,2017-07-13 15:25:40 EDT,,0,LOG,00000,"database system is shut down",,,,,,,,,"","",""
3.5.4 監査ログファイル
edb_audit構成パラメーターの設定に応じて、監査ログ・ファイルをCSVまたはXML形式で生成することができます。 XML形式には、CSV形式よりも少ない情報が含まれています。
監査ログの情報は、PostgreSQLのコアドキュメントのセクション19.8「エラー報告とログ」のセクション19.8.4「CSV形式のログ出力の使用」で説明したPostgreSQLのロギングに基づいています。
https://www.postgresql.org/docs/11/static/runtime-config-logging.html
次の表に、CSV監査ログ形式で表示されるフィールドの一覧を示します。この表には、次の情報が含まれています。
フィールド。前に参照したPostgreSQLドキュメントのサンプルテーブル定義に示されているフィールドの名前。
XML要素/属性。 XML形式では、XML要素の名前とその属性(使用されている場合)が値を参照します。 注: n/aは、このフィールドのXML表現がないことを示します。
データ・タイプ。 PostgreSQLサンプルテーブル定義によって与えられたフィールドのデータ型。
説明。フィールドの説明。特定のフィールドでは、監査ログで出力が生成されないため、これらのフィールドは監査でサポートされていません。これらのフィールドは「サポートされていません」と表示されます。
「サポートされていません」 Descriptionがあるフィールドは、CSV形式で連続したカンマ( ,, )として表示されます。
表3-3 - 監査ログのフィールド
n/a
n/a
n/a
n/a
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.
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
parameter in the configuration file. audit_tag parameter in the configuration file. Value specified by the parameter in the configuration file.
以下の例は、CSV形式とXML形式で生成されます。
postgresql.confファイルのデフォルト以外の監査設定は、次のとおりです。
edb_audit = 'csv'
edb_audit_connect = 'all'
edb_audit_disconnect = 'all'
edb_audit_statement = 'ddl, dml, select, error'
edb_audit_tag = 'edbaudit'
edb_auditパラメータを次のように変更されたxml XMLフォーマットを生成するとき。
監査されるセッションは次のとおりです。
$ psql edb enterprisedb
Password for user enterprisedb:
psql.bin (10.0.1)
Type "help" for help.
 
edb=# CREATE SCHEMA edb;
CREATE SCHEMA
edb=# SET search_path TO edb;
SET
edb=# CREATE TABLE dept (
edb(# deptno NUMBER(2) NOT NULL CONSTRAINT dept_pk PRIMARY KEY,
edb(# dname VARCHAR2(14) CONSTRAINT dept_dname_uq UNIQUE,
edb(# loc VARCHAR2(13)
edb(# );
CREATE TABLE
edb=# INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK');
INSERT 0 1
edb=# UPDATE department SET loc = 'BOSTON' WHERE deptno = 10;
ERROR: relation "department" does not exist
LINE 1: UPDATE department SET loc = 'BOSTON' WHERE deptno = 10;
^
edb=# UPDATE dept SET loc = 'BOSTON' WHERE deptno = 10;
UPDATE 1
edb=# SELECT * FROM dept;
deptno | dname | loc
--------+------------+--------
10 | ACCOUNTING | BOSTON
(1 row)
 
edb=# \q
CSV監査ログファイル
監査ログファイルのCSV形式は次のとおりです。
各監査ログエントリは複数の行に分割されて表示され、結果の外観をより明確にするために、監査ログエントリ間に空白行が挿入されています。
2017-07-17 13:28:44.235 EDT,"enterprisedb","edb",4068,"[local]",
596cf3cc.fe4,1,"authentication",2017-07-17 13:28:44 EDT,6/2,0,AUDIT,00000,
"connection authorized: user=enterprisedb database=edb",,,,,,,,,"","","edbaudit"
 
2017-07-17 13:28:44.235 EDT,"enterprisedb","edb",4068,"[local]",
596cf3cc.fe4,2,"idle",2017-07-17 13:28:44 EDT,6/4,0,AUDIT,00000,
"statement: CREATE SCHEMA edb;",,,,,,,,,"psql.bin","CREATE SCHEMA","edbaudit"
 
2017-07-17 13:28:44.235 EDT,"enterprisedb","edb",4068,"[local]",
596cf3cc.fe4,3,"idle",2017-07-17 13:28:44 EDT,6/6,0,AUDIT,00000,
"statement: CREATE TABLE dept (
deptno NUMBER(2) NOT NULL CONSTRAINT dept_pk PRIMARY KEY,
dname VARCHAR2(14) CONSTRAINT dept_dname_uq UNIQUE,
loc VARCHAR2(13)
);",,,,,,,,,"psql.bin","CREATE TABLE","edbaudit"
 
2017-07-17 13:28:44.235 EDT,"enterprisedb","edb",4068,"[local]",
596cf3cc.fe4,4,"idle",2017-07-17 13:28:44 EDT,6/7,0,AUDIT,00000,
"statement: INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK');",,,,,,,,,
"psql.bin","INSERT","edbaudit"
 
2017-07-17 13:28:44.235 EDT,"enterprisedb","edb",4068,"[local]",
596cf3cc.fe4,5,"idle",2017-07-17 13:28:44 EDT,6/8,0,AUDIT,00000,
"statement: UPDATE department SET loc = 'BOSTON' WHERE deptno = 10;",,,,,,,,,
"psql.bin","UPDATE","edbaudit"
 
2017-07-17 13:29:59.833 EDT,"enterprisedb","edb",4068,"[local]",
596cf3cc.fe4,6,"UPDATE",2017-07-17 13:28:44 EDT,6/8,0,ERROR,42P01,
"relation ""department"" does not exist",,,,,,
"UPDATE department SET loc = 'BOSTON' WHERE deptno = 10;",8,,"psql.bin","","edbaudit"
 
2017-07-17 13:29:59.833 EDT,"enterprisedb","edb",4068,"[local]",
596cf3cc.fe4,7,"idle",2017-07-17 13:28:44 EDT,6/9,0,AUDIT,00000,
"statement: UPDATE dept SET loc = 'BOSTON' WHERE deptno = 10;",,,,,,,,,
"psql.bin","UPDATE","edbaudit"
 
2017-07-17 13:29:59.833 EDT,"enterprisedb","edb",4068,"[local]",
596cf3cc.fe4,8,"idle",2017-07-17 13:28:44 EDT,6/10,0,AUDIT,00000,
"statement: SELECT * FROM dept;",,,,,,,,,"psql.bin","SELECT","edbaudit"
 
2017-07-17 13:29:59.833 EDT,"enterprisedb","edb",4068,"[local]",
596cf3cc.fe4,9,"idle",2017-07-17 13:28:44 EDT,,0,AUDIT,00000,
"disconnection: session time: 0:02:01.511 user=enterprisedb database=edb host=[local]",,,,,,,,,"psql.bin","SELECT","edbaudit"
 
2017-07-17 13:30:53.617 EDT,,,3987,,596cf3b3.f93,1,,2017-07-17 13:28:19 EDT,,0,LOG,00000,
"database system is shut down",,,,,,,,,"","","edbaudit"
XML監査ログファイル
次に、監査ログファイルのXML形式を示します。出力は、例の外観をより明確にするためにフォーマットされています。
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="596cf5b7.12a8" process_id="4776" time="2017-07-17 13:36:55 EDT"
transaction_id="0" type="connect" audit_tag="edbaudit">
<message>AUDIT: connection authorized: user=enterprisedb database=edb</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="596cf5b7.12a8" process_id="4776" time="2017-07-17 13:37:02 EDT"
transaction_id="0" type="create" command_tag="CREATE SCHEMA" audit_tag="edbaudit">
<message>AUDIT: statement: CREATE SCHEMA edb;</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="596cf5b7.12a8" process_id="4776" time="2017-07-17 13:37:19 EDT"
transaction_id="0" type="create" command_tag="CREATE TABLE" audit_tag="edbaudit">
<message>AUDIT: statement: CREATE TABLE dept (
deptno NUMBER(2) NOT NULL CONSTRAINT dept_pk PRIMARY KEY,
dname VARCHAR2(14) CONSTRAINT dept_dname_uq UNIQUE,
loc VARCHAR2(13));
</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="596cf5b7.12a8" process_id="4776" time="2017-07-17 13:37:29 EDT"
transaction_id="0" type="insert" command_tag="INSERT" audit_tag="edbaudit">
<message>AUDIT: statement: INSERT INTO dept VALUES
(10,&apos;ACCOUNTING&apos;,&apos;NEW YORK&apos;);
</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="596cf5b7.12a8" process_id="4776" time="2017-07-17 13:37:40 EDT"
transaction_id="0" type="update" command_tag="UPDATE" audit_tag="edbaudit">
<message>AUDIT: statement: UPDATE department SET
loc = &apos;BOSTON&apos; WHERE deptno = 10;
</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="596cf5b7.12a8" process_id="4776" time="2017-07-17 13:37:40 EDT"
transaction_id="0" type="error" audit_tag="edbaudit">
<message>ERROR: relation &quot;department&quot; does not exist at character 8
</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="596cf5b7.12a8" process_id="4776" time="2017-07-17 13:37:51 EDT"
transaction_id="0" type="update" command_tag="UPDATE" audit_tag="edbaudit">
<message>AUDIT: statement: UPDATE dept SET loc = &apos;BOSTON&apos; WHERE deptno = 10;
</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="596cf5b7.12a8" process_id="4776" time="2017-07-17 13:37:59 EDT"
transaction_id="0" type="select" command_tag="SELECT" audit_tag="edbaudit">
<message>AUDIT: statement: SELECT * FROM dept;</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="596cf5b7.12a8" process_id="4776" time="2017-07-17 13:38:01 EDT"
transaction_id="0" type="disconnect" command_tag="SELECT" audit_tag="edbaudit">
<message>AUDIT: disconnection: session time: 0:01:05.814
user=enterprisedb database=edb host=[local]
</message>
</event>
<event process_id="4696" time="2017-07-17 13:38:08 EDT"
transaction_id="0" type="shutdown" audit_tag="edbaudit">
<message>LOG: database system is shut down</message>
</event>
3.5.5 エラー・コードを使用した監査ログのフィルタリング
Advanced Serverには、ユーザー指定のエラーコードを含むログファイルエントリをAdvanced Serverログファイルから除外するために使用できる拡張機能が含まれています。監査ログエントリをフィルタリングするには、まず postgresql 変更して拡張機能を有効にする必要がありますconfファイルで、 shared _ preload _ librariesパラメータで指定された値に次の値を追加します。
$libdir/edb_filter_log
次に、 edb _ filter _ log 使用し logerrcodesパラメーターを使用して、ログ・ファイルから省略したいエラー・コードを指定します。
edb_filter_log.errcode = 'error _ code'
どこ error_code 、ログファイルから省略したい1つ以上のエラー・コードを指定します。複数のエラーコードをカンマ区切りリストで指定します。
例えば、場合 edb _ filter _ log有効になっている、とedb _ filter _ logerrcode'23505,23502,22012'設定され、次のいずれかのSQLSTATEエラーを返すログ・エントリーがあります。
23505 (ユニーク制約に違反するため)
23502 (非null制約に違反するため)
22012 (ゼロで割るため)
ログファイルから省略されます。
Advanced Server監査ログのフィルタリングでサポートされているエラーコードの完全なリストについては、次のコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/errcodes-appendix.html
3.5.6 コマンド・タグを使用した監査ログのフィルタリング
エラーメッセージを表示するものを除くログファイルの各エントリには、その特定のログエントリに対して実行されるSQLコマンドであるコマンドタグ が含まれています。
コマンドタグを使用すると、その後のツールを使用してログファイルをスキャンして、特定のSQLコマンドに関連するエントリを見つけることができます。
以下は、XML形式の例です。出力は、この例で見やすくなるようにフォーマットされています。
この例では、コマンド・タグはeventエレメントのcommand_tag属性として、 CREATE ROLEALTER ROLE 、およびDROP ROLE値で表示されます。
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="595e8537.10f1" process_id="4337" time="2017-07-06 14:45:18 EDT"
transaction_id="0" type="create"
command_tag="CREATE ROLE">
<message>AUDIT: statement: CREATE ROLE newuser WITH LOGIN;</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="595e8537.10f1" process_id="4337" time="2017-07-06 14:45:31 EDT"
transaction_id="0" type="error">
<message>ERROR: unrecognized role option &quot;super&quot; at character 25
STATEMENT: ALTER ROLE newuser WITH SUPER USER;</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="595e8537.10f1" process_id="4337" time="2017-07-06 14:45:38 EDT"
transaction_id="0" type="alter" command_tag="ALTER ROLE">
<message>AUDIT: statement: ALTER ROLE newuser WITH SUPERUSER;</message>
</event>
<event user="enterprisedb" database="edb" remote_host="[local]"
session_id="595e8537.10f1" process_id="4337" time="2017-07-06 14:45:46 EDT"
transaction_id="0" type="drop" command_tag="DROP ROLE">
<message>AUDIT: statement: DROP ROLE newuser;</message>
</event>
以下は、CSV形式の同じ例です。コマンドタグは、各エントリの最後の列の次のものです。 (最後の列は ""と表示され、 edb_audit_tagパラメータで指定された値にedb_audit_tagます)。
各監査ログエントリは複数の行に分割されて表示され、結果の外観をより明確にするために、監査ログエントリ間に空白行が挿入されています。
2017-07-06 14:47:22.294 EDT,"enterprisedb","edb",4720,"[local]",
595e85b2.1270,1,"idle",2017-07-06 14:47:14 EDT,6/4,0,AUDIT,00000,
"statement: CREATE ROLE newuser WITH LOGIN;",,,,,,,,,"psql.bin","CREATE ROLE",""
 
2017-07-06 14:47:29.694 EDT,"enterprisedb","edb",4720,"[local]",
595e85b2.1270,2,"idle",2017-07-06 14:47:14 EDT,6/5,0,ERROR,42601,
"unrecognized role option ""super""",,,,,,"ALTER ROLE newuser WITH SUPER USER;",25,,
"psql.bin","",""
 
2017-07-06 14:47:29.694 EDT,"enterprisedb","edb",4720,"[local]",
595e85b2.1270,3,"idle",2017-07-06 14:47:14 EDT,6/6,0,AUDIT,00000,
"statement: ALTER ROLE newuser WITH SUPERUSER;",,,,,,,,,"psql.bin","ALTER ROLE",""
 
2017-07-06 14:47:29.694 EDT,"enterprisedb","edb",4720,"[local]",
595e85b2.1270,4,"idle",2017-07-06 14:47:14 EDT,6/7,0,AUDIT,00000,
"statement: DROP ROLE newuser;",,,,,,,,,"psql.bin","DROP ROLE",""
3.5.7 監査ログからのパスワードの修正
edb _ filter _ log 使用することができ logredact _ 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 } ]
このような文が log _ statement によって log 記録されると、サーバは古いパスワードと新しいパスワードを 'x'に書き換えます。たとえば、次のコマンドを実行します。
ALTER USER carol PASSWORD '1safepwd' REPLACE 'old_pwd';
ログファイルに次のように追加されます。
statement: ALTER USER carol PASSWORD 'x' REPLACE 'x';
編集されたパスワードを含む文がログに記録されると、サーバは文のテキストを変更します。ステートメントが他のメッセージのコンテキストとして記録されると、サーバーはコンテキストからステートメントを省略します。
パスワードの変更を有効にするには、まず postgresql 変更して拡張機能を有効にする必要がありますconfファイルで、 shared _ preload _ librariesパラメータで指定された値に次の値を追加します。
$libdir/edb_filter_log
次に、 edb _ filter _ log 設定し log redact_password_commands true redact_password_commands true
edb_filter_log.redact_password_commands = true
postgresql 変更した後 conf ファイルは、変更を有効にするためにサーバーを再起動する必要があります。
3.6 Unicode照合アルゴリズム
Unicode照合アルゴリズム (UCA)は、照合およびUnicodeデータを比較するカスタマイズ可能な方法を定義する仕様( ユニコードテクニカルレポート#10)です。 照合とは、 SELECT … ORDER BY節のようにデータがどのようにソートされるかを意味します。 比較は、演算子がより小さい、より大きい、または等しい演算子を持つ範囲を使用する検索に関連します。
カスタマイズ性は、以下のようなさまざまな理由から重要な要素です。
Unicodeでサポートされている膨大な数の言語を使用したこれらのバリエーションのすべてを考慮すると、照合順序を決定するための特定の基準を選択する方法が必要です。これは、Unicode照合アルゴリズムで定義されています。
注意:さらに、ICU照合(Unicode照合アルゴリズムの実装)を使用するもう1つの利点は、パフォーマンスのためです。 Bツリーインデックスの作成を含むソートタスクは、ICU以外の照合に要する時間の半分以下で完了することができます。パフォーマンスの向上は、オペレーティングシステムのバージョン、テキストデータの言語、およびその他の要因によって異なります。
以下のセクションでは、統一照合アルゴリズムの概念の簡潔な説明を提供します。アルゴリズムとその使用法は非常に複雑で、さまざまなバリエーションがあるため、詳細については、これらのセクションで引用した公式文書を参照してください。
 
3.6.1 基本的なUnicode照合アルゴリズムの概念
Unicode照合アルゴリズムの正式な情報は、Unicode テクニカルレポート#10規定されてい ます 。これは、The Unicode ConsortiumのWebサイトにあります。
http://www.unicode.org/reports/tr10/
ICU - Unicodeの国際コンポーネントは、多くの有用な情報も提供します。照合の概念の説明は、次のWebサイトにあります。
http://userguide.icu-project.org/collat​​ion/concepts
Unicode照合アルゴリズムの背後にある基本的なコンセプトは、マルチレベル比較の使用です。これは、いくつかのレベルが定義されていることを意味し、以下の箇条書きのレベル1〜レベル5としてリストされています。各レベルは比較のタイプを定義します。まずレベル1と呼ばれるプライマリレベルを使用して文字列を比較します。
プライマリレベルに基づいて注文を決定できる場合、アルゴリズムが実行されます。 1次レベルに基づいて注文を判別できない場合、2次レベル、レベル2が適用されます。 2次レベルに基づいて順序を決定することができる場合、アルゴリズムが実行され、そうでなければ3次レベルが適用され、以下同様である。以前のレベルで解決できない場合は、通常、順序を決定するための最終的なタイブレークレベルがあります。
レベル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ライブラリのセットです。
Advanced Serverを使用してICUコンポーネントを呼び出して照合を作成する照合を作成すると、その結果は ICU照合 と呼ばれ ます
3.6.2.1 ロケールの照合順序
ロケールの照合を作成するときは、通常、所定のロケールのICUショートフォーム名が事前定義されています。
ICUショートフォームは、照合の特性である照合属性を指定する方法です。 3.6.2.2項で照合属性に関する追加情報を示します。
ロケール用の事前定義されたICUショートフォームがあります。ロケールのICU短縮形には、特定のロケールで通常使用される照合属性の設定が組み込まれています。これにより、そのロケールの照合属性のリスト全体を指定する必要がなくなり、照合作成プロセスが簡素化されます。
システムカタログ pg_catalog.pg_icu_collate_namesは、ロケールのICU短縮形の名前のリストが含まれています。 ICU短縮形名はicu_short_form列にリストされています。
edb=# SELECT icu_short_form, valid_locale FROM pg_icu_collate_names ORDER BY valid_locale;
icu_short_form | valid_locale
----------------+--------------
LAF | af
LAR | ar
LAS | as
LAZ | az
LBE | be
LBG | bg
LBN | bn
LBS | bs
LBS_ZCYRL | bs_Cyrl
LROOT | ca
LROOT | chr
LCS | cs
LCY | cy
LDA | da
LROOT | de
LROOT | dz
LEE | ee
LEL | el
LROOT | en
LROOT | en_US
LEN_RUS_VPOSIX | en_US_POSIX
LEO | eo
LES | es
LET | et
LFA | fa
LFA_RAF | fa_AF
.
.
.
必要に応じて、特定のロケールのICU短縮形の既定の特性は、照合属性を指定してそのプロパティを上書きすることによって上書きできます。これについては、次のセクションで説明します。
3.6.2.2 照合属性
ICU照合を作成する場合、照合の望ましい特性を指定する必要があります。セクション 3.6.2.1説明したように 、これは通常、目的のロケールのICU短縮形式で実行できます。ただし、より具体的な情報が必要な場合は、 照合属性を使用して照合プロパティの指定を行うことができます
照合属性は、テキスト文字列の照合順序を決定するために文字をどのように比較するかの規則を定義します。 Unicodeは国、地域、文化に応じてさまざまなバリエーションの膨大な言語をカバーしているため、これらの照合属性は非常に複雑です。
照合属性の完全で正確な意味と使用法については、ICUのUnicode Webサイトの「International Components for Unicode」Webサイトのセクション14「Collat​​or Naming Scheme」を参照してください。
http://userguide.icu-project.org/collat​​ion/concepts
以下は、照合属性の簡単な概要と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より大きい値を有する。
照合属性とその値のセットは、目的の属性値と連結された照合属性文字で構成されるテキスト文字列で表されます。各属性/値のペアは、次の例に示すように、アンダースコア文字で次のペアに結合されます。
AN_CX_EX_FX_HX_NO_S3
照合属性は、ロケールのデフォルトの属性設定を上書きするために、ロケールのICU短縮形名とともに指定することができます。
次の例は、 LROOT という名前のICU短縮形が他の多くの照合属性と値のLROOTで変更された例です。
AN_CX_EX_LROOT_NO_S3
前の例では、代替属性( A )は無視できない( N )に設定されています。ケースファースト属性( C )はオフ( X )に設定されています。ケースレベル属性( E )はオフ( X )に設定されています。正規化属性( N )はオン( O )に設定されます。強度属性( S )は、第3レベル3設定されます。 LROOTは、これらの他の属性が変更を適用しているICU短縮形式です。
 
3.6.3 ICUの照合順序の作成
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 "などの式。
ICU照合を作成するさまざまな方法について、以下に説明します。
3.6.3.1 COLLATIONの作成
ICU照合を作成するには、 CREATE COLLATIONコマンドでICU_SHORT_FORMパラメーターを使用します。
CREATE COLLATION collation_name (
[ LOCALE = locale , ]
[ LC_COLLATE = lc_collate , ]
[ LC_CTYPE = lc_ctype , ]
[ ICU_SHORT_FORM = icu_short_form ]
);
照合を作成するには、照合が存在する宛先スキーマに対して CREATE特権が必要です。
CREATE COLLATIONコマンドの一般的な使用方法については 、次のURLにあるPostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/sql-createcollat​​ion.html
データベースのUTF-8文字エンコーディングが必要です。任意 LOCALE 、またはLC_COLLATELC_CTYPE UTF-8エンコーディングで受け付けられた設定を使用することができます。
パラメーター
collation_name
追加する照合の名前。 collat​​ion_nameはスキーマで修飾されています。
locale
使用するロケール。 LC_COLLATELC_TYPE を設定するためのショートカットLOCALEが指定されている場合は、 LC_COLLATEおよびLC_TYPE省略する必要があります。
lc_collate
使用される照合。 LC_CTYPEが指定されている場合は、 LC_COLLATEも指定する必要があり、 LOCALE省略する必要がありLOCALE
lc_ctype
使用される文字の分類。 LC_COLLATEが指定されている場合は、 LC_CTYPEも指定する必要があり、 LOCALE省略する必要がありLOCALE
icu_short_form
照合属性とその設定を指定するテキスト文字列。これは、通常、追加の照合属性と値のペアが付加されたICUショートフォーム名で構成されます。 ICU短縮形名のリストは 、システムカタログpg_catalog.pg_icu_collate_names icu_short_form から入手でき pg_catalog.pg_icu_collate_names
以下は、 LROOT ICU短縮形を使用して照合を作成します
edb=# CREATE COLLATION icu_collate_a (LOCALE = 'en_US.UTF8', ICU_SHORT_FORM = 'LROOT');
CREATE COLLATION
新しい照合の定義は、次の psqlコマンドで確認できます
edb=# \dO
List of collations
Schema | Name | Collate | Ctype | ICU
--------------+---------------+------------+------------+-------
enterprisedb | icu_collate_a | en_US.UTF8 | en_US.UTF8 | LROOT
(1 row)
3.6.3.2 CREATE DATABASEを
ICU照合でデータベースを作成する構文は次のとおりです。
CREATE DATABASE database_name
[ [ WITH ] [ OWNER [=] user_name ]
[ TEMPLATE [=] template ]
[ ENCODING [=] encoding [ ENCODING [=] encoding ]
[ LC_COLLATE [=] lc_collate ]
[ LC_CTYPE [=] lc_ctype ]
[ TABLESPACE [=] tablespace_name ]
[ CONNECTION LIMIT [=] connlimit ]
[ ICU_SHORT_FORM [=] icu_short_form ]];
CREATE DATABASEコマンドの一般的な使用法、構文、およびパラメータの詳細については、次のURLにあるPostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/sql-createdatabase.html
使用する際に CREATE DATABASE ICU照合を使用してデータベースを作成するコマンドを、 TEMPLATE template0句を指定する必要があり、データベースのエンコーディングはUTF-8でなければなりません。
以下は、 LROOT ICU短縮形照合を使用してデータベースを作成する例ですが、小文字の対応( CU )の前に大文字のソートをソートし、可変文字を無視しない( AN )として扱います。
CREATE DATABASE collation_db
TEMPLATE template0
ENCODING 'UTF8'
ICU_SHORT_FORM = 'AN_CU_EX_NX_LROOT';
次の psqlコマンドは、新しく作成されたデータベースを表示します。
edb=# \l collation_db
List of databases
Name | Owner | Encoding | Collate | Ctype | ICU | Access privileges
--------------+--------------+----------+-------------+-------------+-------------------+-------------------
collation_db | enterprisedb | UTF8 | en_US.UTF-8 | en_US.UTF-8 | AN_CU_EX_NX_LROOT |
(1 row)
次の表が作成され、データベースの行が移入されます。
CREATE TABLE collate_tbl (
id INTEGER,
c2 VARCHAR(2)
);
 
INSERT INTO collate_tbl VALUES (1, 'A');
INSERT INTO collate_tbl VALUES (2, 'B');
INSERT INTO collate_tbl VALUES (3, 'C');
INSERT INTO collate_tbl VALUES (4, 'a');
INSERT INTO collate_tbl VALUES (5, 'b');
INSERT INTO collate_tbl VALUES (6, 'c');
INSERT INTO collate_tbl VALUES (7, '1');
INSERT INTO collate_tbl VALUES (8, '2');
INSERT INTO collate_tbl VALUES (9, '.B');
INSERT INTO collate_tbl VALUES (10, '-B');
INSERT INTO collate_tbl VALUES (11, ' B');
次のクエリは、大文字の文字が同じ基本文字の小文字の前にソートされていることを示しています。さらに、ソートリストの先頭に表示されるように並べ替えられたときに可変文字も考慮されます。 en_US.UTF-8 のデフォルトの動作は、同じ基本文字の大文字の前にある小文字の書式をソートし、可変文字を無視することです。
collation_db=# SELECT id, c2 FROM collate_tbl ORDER BY c2;
id | c2
----+----
11 | B
10 | -B
9 | .B
7 | 1
8 | 2
1 | A
4 | a
2 | B
5 | b
3 | C
6 | c
(11 rows)
3.6.3.3 initdb
initdbコマンドで--icu-short-formオプションを使用すると、クラスタ内のすべてのデータベースのデフォルトのICU照合でデータベースクラスタを作成できます
initdbコマンドの一般的な使用法、構文、およびパラメータの詳細については、次のURLにあるPostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/app-initdb.html
以下に、このプロセスを示します。
$ su enterprisedb
Password:
$ /usr/edb/as11/bin/initdb -U enterprisedb -D /tmp/collation_data --encoding UTF8 --icu-short-form 'AN_CU_EX_NX_LROOT'
The files belonging to this database system will be owned by user "enterprisedb".
This user must also own the server process.
 
The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".
 
Data page checksums are disabled.
 
creating directory /tmp/collation_data ... ok
creating subdirectories ... ok
.
.
.
Success. You can now start the database server using:
 
/usr/edb/as11/bin/edb-postgres -D /tmp/collation_data
or
/usr/edb/as11/bin/pg_ctl -D /tmp/collation_data -l logfile start
以下は、クラスタ内で作成されたデータベースのうち、すべてが AN_CU_EX_NX_LROOT ICU照合順序を持つことを示しています
edb=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | ICU | Access privileges
-----------+--------------+----------+-------------+-------------+-------------------+-------------------------------
edb | enterprisedb | UTF8 | en_US.UTF-8 | en_US.UTF-8 | AN_CU_EX_NX_LROOT |
postgres | enterprisedb | UTF8 | en_US.UTF-8 | en_US.UTF-8 | AN_CU_EX_NX_LROOT |
template0 | enterprisedb | UTF8 | en_US.UTF-8 | en_US.UTF-8 | AN_CU_EX_NX_LROOT | =c/enterprisedb +
| | | | | | enterprisedb=CTc/enterprisedb
template1 | enterprisedb | UTF8 | en_US.UTF-8 | en_US.UTF-8 | AN_CU_EX_NX_LROOT | =c/enterprisedb +
| | | | | | enterprisedb=CTc/enterprisedb
(4 rows)
 
3.6.4 照合順序の使用
新たに定義されたICUの照合は、 COLLATION " collation_name "句をCREATE TABLEコマンドの列指定などのSQLコマンドで使用したり、 SELECTコマンドのORDER BY句の式に追加することができます。
以下は、米国の英語に基づくICU照合の作成と使用の例です( en_US.UTF8 )。
これらの例では、以下の特性を持つICU照合が作成されます。
照合 icu_collate_lowercaseは、文字の小文字を強制的に大文字の対応( CL )の前にソートします。
照合 icu_collate_uppercaseは、文字の大文字を小文字の対応文字( CU )の前にソートします。
照合 icu_collate_ignore_punctは、ソート( AS )中に可変文字(空白および句読点)を無視します。
照合 icu_collate_ignore_white_spは、ソート時に空白やその他の不可視の可変文字を無視しますが、表示される可変文字(句読点)は無視されません( AST0020 )。
CREATE COLLATION icu_collate_lowercase (
LOCALE = 'en_US.UTF8',
ICU_SHORT_FORM = 'AN_CL_EX_NX_LROOT'
);
 
CREATE COLLATION icu_collate_uppercase (
LOCALE = 'en_US.UTF8',
ICU_SHORT_FORM = 'AN_CU_EX_NX_LROOT'
);
 
CREATE COLLATION icu_collate_ignore_punct (
LOCALE = 'en_US.UTF8',
ICU_SHORT_FORM = 'AS_CX_EX_NX_LROOT_L3'
);
 
CREATE COLLATION icu_collate_ignore_white_sp (
LOCALE = 'en_US.UTF8',
ICU_SHORT_FORM = 'AS_CX_EX_NX_LROOT_L3_T0020'
);
注意:照合順序を作成するときに、 LROOT照合を変更する属性が与えられた場合、ICUは通知および警告メッセージを生成することがあります。
次の psqlコマンドは、照合をリストします。
edb=# \dO
List of collations
Schema | Name | Collate | Ctype | ICU
--------------+-----------------------------+------------+------------+----------------------------
enterprisedb | icu_collate_ignore_punct | en_US.UTF8 | en_US.UTF8 | AS_CX_EX_NX_LROOT_L3
enterprisedb | icu_collate_ignore_white_sp | en_US.UTF8 | en_US.UTF8 | AS_CX_EX_NX_LROOT_L3_T0020
enterprisedb | icu_collate_lowercase | en_US.UTF8 | en_US.UTF8 | AN_CL_EX_NX_LROOT
enterprisedb | icu_collate_uppercase | en_US.UTF8 | en_US.UTF8 | AN_CU_EX_NX_LROOT
(4 rows)
次の表が作成され、入力されます。
CREATE TABLE collate_tbl (
id INTEGER,
c2 VARCHAR(2)
);
 
INSERT INTO collate_tbl VALUES (1, 'A');
INSERT INTO collate_tbl VALUES (2, 'B');
INSERT INTO collate_tbl VALUES (3, 'C');
INSERT INTO collate_tbl VALUES (4, 'a');
INSERT INTO collate_tbl VALUES (5, 'b');
INSERT INTO collate_tbl VALUES (6, 'c');
INSERT INTO collate_tbl VALUES (7, '1');
INSERT INTO collate_tbl VALUES (8, '2');
INSERT INTO collate_tbl VALUES (9, '.B');
INSERT INTO collate_tbl VALUES (10, '-B');
INSERT INTO collate_tbl VALUES (11, ' B');
次のクエリは、デフォルト照合を使用して列 c2ソートします 。その可変文字(空白や句読点)注idの列の値910 、及び11無視され、文字でソートされているB
edb=# SELECT * FROM collate_tbl ORDER BY c2;
id | c2
----+----
7 | 1
8 | 2
4 | a
1 | A
5 | b
2 | B
11 | B
10 | -B
9 | .B
6 | c
3 | C
(11 rows)
次のクエリは 、照合icu_collate_lowercaseを使用して列 c2ソートします 。これは、小文字の書式を同じ基本文字の大文字の前にソートするよう強制します。また、ご注意AN持つ行ように、基本文字を比較するとき、同じレベルのソート順に含まれるように力変数の文字属性idの値が910 、および11 、すべての文字と数字の前にソートリストの先頭に表示されます。
edb=# SELECT * FROM collate_tbl ORDER BY c2 COLLATE "icu_collate_lowercase";
id | c2
----+----
11 | B
10 | -B
9 | .B
7 | 1
8 | 2
4 | a
1 | A
5 | b
2 | B
6 | c
3 | C
(11 rows)
次のクエリは 、照合icu_collate_uppercaseを使用して列 c2ソートします 。これは、大文字の書体を同じ基本文字の小文字の前にソートすることを強制します。
edb=# SELECT * FROM collate_tbl ORDER BY c2 COLLATE "icu_collate_uppercase";
id | c2
----+----
11 | B
10 | -B
9 | .B
7 | 1
8 | 2
1 | A
4 | a
2 | B
5 | b
3 | C
6 | c
(11 rows)
カラム上の次のクエリソート c2照合使用icu_collate_ignore_punct持つ行に無視する変数文字を生じ、 id910 、および11文字でソートBそれは直ちに無視可変文字の次の文字であるようにします。
edb=# SELECT * FROM collate_tbl ORDER BY c2 COLLATE "icu_collate_ignore_punct";
id | c2
----+----
7 | 1
8 | 2
4 | a
1 | A
5 | b
11 | B
2 | B
9 | .B
10 | -B
6 | c
3 | C
(11 rows)
次の照会は 、照合icu_collate_ignore_white_spを使用して列 c2ソートします 。照合のASおよびT0020属性は、16進数0020以下のコード・ポイントを持つ可変文字を無視し、16進数0020以上のコード・ポイントを持つ可変文字を無視します。
空白文字(16進数0020 )で始まるid値が11 の行は 、文字Bソートされます。これらの特定の可変文字は、基本文字の比較時に同じレベルのソート順に含まれるため、ソートリストの先頭には、16進数の0020よりも目に見える句読点で始まる910 id値を持つ行がソートリストの先頭に表示されます。
edb=# SELECT * FROM collate_tbl ORDER BY c2 COLLATE "icu_collate_ignore_white_sp";
id | c2
----+----
10 | -B
9 | .B
7 | 1
8 | 2
4 | a
1 | A
5 | b
11 | B
2 | B
6 | c
3 | C
(11 rows)
 
3.7 カスタマイズ可能なWALセグメントファイルサイズ
initdbユーティリティー・プログラムを使用してデータベース・クラスターを作成する場合、各WALセグメント・ファイルのデフォルト・サイズは16 MBです。
Advanced Server initdbユーティリティーは、新しいデータベース・クラスターを作成するときにWALセグメント・ファイルのサイズを指定するための追加の--wal-segsizeオプションを提供します。
initdb --wal-segsize= size [ options ]... -D directory
sizeはメガバイト単位のWALセグメントファイルサイズで、2の累乗でなければなりません(たとえば、1,2,4,8,16,32など)。 sizeの最小許容値は1、最大許容値は1024です。データベースクラスタはdirectoryに作成されます。
initdbユーティリティとその他のoptions詳細については initdbあるPostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/app-initdb.html
次の例は、WALセグメントファイルサイズが1024 MB(1 GBに相当)として指定されているデータベースクラスタの作成を示しています。
bash-4.1$ initdb -D /opt/data_1024 -U enterprisedb --wal-segsize 1024
The files belonging to this database system will be owned by user "enterprisedb".
This user must also own the server process.
 
The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
 
Data page checksums are disabled.
 
fixing permissions on existing directory /opt/data_1024 ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
creating edb sys ... ok
loading edb contrib modules ...
edb_redwood_bytea.sql ok
edb_redwood_date.sql ok
dbms_alert_public.sql ok
.
.
.
Success. You can now start the database server using:
 
pg_ctl -D /opt/data_1024 -l logfile start
以下は、WALファイルを1.0 GBとして示しています。
bash-4.1$ pwd
/opt/data_1024/pg_wal
bash-4.1$ ls -lh
total 1.1G
-rw------- 1 enterprisedb enterprisedb 1.0G Jul 24 14:42 000000010000000000000001
drwx------ 2 enterprisedb enterprisedb 4.0K Jul 24 14:42 archive_status
データベースサーバの起動後、 wal_segment_sizeパラメータの表示によってファイルサイズが確認されます。
edb=# SHOW wal_segment_size;
wal_segment_size
------------------
1GB
(1 row)
4 セキュリティ
この章では、セキュリティを強化するためのさまざまな機能について説明します。
4.1 SQLインジェクション攻撃からの保護
Advanced Serverは、SQLインジェクション攻撃に対する保護機能を提供します。 SQLインジェクション攻撃は、その結果、そのデータベースの内容、構造、またはセキュリティに関しては、攻撃者への手がかりを提供するSQL文を実行してデータベースを侵害しようとする試みです。
SQLインジェクション攻撃を防ぐことは、通常、アプリケーション開発者の責任です。通常、データベース管理者は潜在的な脅威をほとんどまたはまったく制御しません。データベース管理者の難しさは、アプリケーションが適切に機能するためにデータにアクセスする必要があることです。
SQL / Protectは、データベース管理者がSQLインジェクション攻撃からデータベースを保護するためのモジュールです。 SQL / Protectは、通常のデータベースセキュリティポリシーに加えて、一般的なSQLインジェクションプロファイルの入力クエリを調べることによって、セキュリティレイヤーを提供します。
SQL / Protectは、管理者に潜在的に危険な照会を警告し、これらの照会をブロックすることによって、データベース管理者に制御を戻します。
 
4.1.1 SQL /保護の概要
このセクションでは、さまざまなタイプのSQLインジェクション攻撃の概要と、SQL / Protectがそれを守る方法について説明します。
4.1.1.1 SQLインジェクション攻撃のタイプ
SQLインジェクション攻撃を阻止するために使用されるさまざまな手法がいくつかあります。各手法は、特定の シグネチャ によって特徴付けられ ます 。 SQL / Protectは、次のシグネチャの照会を検査します。
権限のない関係
Advanced Serverでは管理者がリレーション(テーブル、ビューなど)へのアクセスを制限できますが、多くの管理者はこの面倒な作業を実行しません。 SQL / Protectは 、ユーザーがアクセスする関係を追跡する 学習モードを提供します。
これにより、管理者はアプリケーションの作業負荷を調べることができます。また、SQL / Protectでは、ロール内の特定のユーザーまたはユーザーグループに対して、アプリケーションがどのような関係でアクセスできるかを知ることができます。
SQL / Protectを パッシブモードまたはアクティブモードに切り替えると、入力クエリは学習されたリレーションのリストと照合されます。
ユーティリティコマンド
SQLインジェクション攻撃で使用される一般的な手法は、通常はSQLデータ定義言語(DDL)文であるユーティリティー・コマンドを実行することです。一例は、他のシステムリソースにアクセスできるユーザー定義関数を作成することです。
SQL / Protectは、標準のアプリケーション処理中には通常必要ではないすべてのユーティリティー・コマンドの実行をブロックすることができます。
SQLトートロジー
SQLインジェクション攻撃で最も頻繁に使用される手法は、同義語 WHERE句の条件を発行することです(つまり、常に真である条件を使用する)。
次はその例です。
WHERE password = 'x' OR 'x'='x'
攻撃者は通常、この手法を使用してセキュリティの弱点を特定し始めます。 SQL / Protectは、同意条件節を使用するクエリをブロックできます。
無制限のDML文
SQLインジェクション攻撃中に行われる危険なアクションは、無制限のDMLステートメントの実行です。これらは WHERE句のないUPDATE文とDELETE文です。たとえば、攻撃者は、すべてのユーザーのパスワードを既知の値に更新したり、キーテーブル内のすべてのデータを削除してサービス拒否攻撃を開始することがあります。
4.1.1.2 SQLインジェクション攻撃の監視
このセクションでは、SQL / ProtectがSQLインジェクション攻撃を監視および報告する方法について説明します。
4.1.1.2.1 保護されたロール
SQLインジェクション攻撃を監視するには、セッションの現在のユーザーが保護された役割であるデータベースセッションで発生したSQLステートメントを分析する必要があります。 保護された役割は、データベース管理者は、保護/ SQLを使用して監視することを選択したAdvanced Serverのユーザーまたはグループです。 (Advanced Serverでは、ユーザーとグループを総称してロールと呼びます 。)
各保護された役割は、監視対象のSQLインジェクション攻撃の種類に合わせてカスタマイズすることができるため、役割ごとに異なるレベルの保護を提供し、DBAのユーザーメンテナンス負荷を大幅に削減します。
注:スーパーユーザー権限を持つロールを保護されたロールにすることはできません。保護されていない非スーパーユーザーロールがその後スーパーユーザーになるように変更された場合、そのスーパーユーザーがコマンドを発行しようとするたびに特定の動作が表示されます。
edb_sql_protect_stats superusers の統計は 、保護されたスーパーユーザーが発行するすべてのコマンドによって増分されます。セクションを参照してください。 4.1.1.2.2については、 edb_sql_protect_statsビューを。
スーパーユーザー権限を持つ保護された役割は、もはやスーパーユーザーにならないように変更するか、保護されていない役割に戻す必要があります。
4.1.1.2.2 攻撃試行統計
SQL / Protectによる攻撃と見なされる保護された役割によるコマンドの各使用法が記録されます。統計は、第 4.1.1.1 項で説明したSQLインジェクション攻撃のタイプによって収集されます
これらの統計は、 edb_sql_protect_stats ビューからアクセスすることができ、潜在的な攻撃の開始を容易に監視することができます。
edb_sql_protect_stats の列は 、以下を監視します。
ユーザー名。保護された役割の名前。
スーパーユーザ。保護された役割がスーパーユーザーである場合に発行されたSQLステートメントの数。事実上、保護されたスーパーユーザーによって発行されたSQLステートメントは、この統計を増加させます。保護されたスーパーユーザについては、 4.1.1.2.1項を参照してください。
関係。保護された役割によって学習されなかったリレーションを参照して発行されたSQL文の数。 (つまり、役割の保護関係リストにない関係)。
コマンド。保護されたロールによって発行されたDDLステートメントの数。
トートロジー。トートロジ状態を含む保護された役割によって発行されたSQLステートメントの数。
dml。 WHERE句を含まない保護されたロールによって発行されたUPDATEおよびDELETEステートメントの数。
これにより、データベース管理者は貴重なデータやその他の悪意のある行為の盗難を予防的に予防する機会を得られます。
ロールが複数のデータベースで保護されている場合、各データベースの攻撃の統計情報は別々に管理され、それぞれのデータベースに接続されている場合にのみ表示されます。
注: SQL / Protectの統計情報は、データベースサーバーの稼動中にメモリに保持されます。データベースサーバーがシャットダウンされると、統計はAdvanced Serverホームディレクトリのdata/globalサブディレクトリにあるedb_sqlprotect.statという名前のバイナリファイルに保存されます。
4.1.1.2.3 攻撃試行クエリ
SQL / Protectによって攻撃と見なされる保護された役割によるコマンドの使用は、それぞれ edb_sql_protect_queries ビューに記録されます
ビュー edb_sql_protect_queriesは、次の列があります。
ユーザー名。データベースサーバーにログインするために使用された攻撃者のデータベースユーザー名。
IPアドレス。攻撃が開始されたマシンのIPアドレス。
港。攻撃が発生したポート番号。
machine_name。既知の場合、攻撃の起源となったマシンの名前。
日付時刻。クエリがデータベースサーバーによって受信された日時。時間は1分の精度で保存されます。
クエリ。攻撃者が送信したクエリ文字列。
edb_sql_protect_queries 保存される違反クエリの最大数は 、構成パラメータedb_sql_protect.max_queries_to_saveによって制御されます。
ロールが複数のデータベースで保護されている場合、各データベースの攻撃のクエリは別々に管理され、それぞれのデータベースに接続されている場合にのみ表示されます。
 
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のバージョン番号です。
Advanced Serverホームディレクトリのshare/contribサブディレクトリにあるSQLスクリプトファイル sqlprotect.sql も必要です。
SQL / Protectを使用するようにデータベースサーバーを構成し、SQL / Protectで監視する各データベースを構成する必要があります。
データベース・サーバー構成ファイル postgresql.conf 、SQL / Protectで使用される構成パラメーターを追加して使用可能にすることによって変更する必要があります。
手順1: Advanced Serverホームディレクトリのdataサブディレクトリにあるpostgresql.confファイルの次の設定パラメータを編集します。
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項を参照してください。
次の例は、 postgresql.confファイルのこれらのパラメータの設定を示しています
shared_preload_libraries = '$libdir/dbms_pipe,$libdir/edb_gen,$libdir/sqlprotect'
# (change requires restart)
.
.
.
edb_sql_protect.enabled = off
edb_sql_protect.level = learn
edb_sql_protect.max_protected_roles = 64
edb_sql_protect.max_protected_relations = 1024
edb_sql_protect.max_queries_to_save = 5000
ステップ2: postgresql.confファイルを変更した後、データベースサーバを再起動します。
Linuxの場合: restartオプションを指定してAdvanced Serverサービス・スクリプトをrestartます。
RedhatまたはCentOS 6.xインストールでは、次のコマンドを使用します。
/etc/init.d/edb-as-11 restart
RedhatまたはCentOS 7.xインストールでは、次のコマンドを使用します。
systemctl restart edb-as-11
Windowsの場合: Windows Servicesアプレットを使用して、 edb-as-11という名前のサービスを再始動します。
手順3: SQLインジェクション攻撃から保護するデータベースごとに、スーパーユーザー(インストールオプションに応じてenterprisedbまたはpostgresいずれか)としてデータベースに接続し、 sqlprotect.sqlスクリプトをshare/contribサブディレクトリに実行します。 Advanced Serverのホームディレクトリ。スクリプトは、 sqlprotectという名前のスキーマにSQL / Protectデータベースオブジェクトを作成します。
次の例は、 edb というデータベースの保護を設定するこのプロセスを示しています
$ /usr/edb/as11/bin/psql -d edb -U enterprisedb
Password for user enterprisedb:
psql.bin (11.0.2, server 11.0.2)
Type "help" for help.
 
edb=# \i /usr/edb/as11/share/contrib/sqlprotect.sql
CREATE SCHEMA
GRANT
SET
CREATE TABLE
GRANT
CREATE TABLE
GRANT
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
DO
CREATE FUNCTION
CREATE FUNCTION
DO
CREATE VIEW
GRANT
DO
CREATE VIEW
GRANT
CREATE VIEW
GRANT
CREATE FUNCTION
CREATE FUNCTION
SET
4.1.2.1 保護するロールの選択
SQL / Protectデータベース・オブジェクトがデータベースに作成された後、保護のためにSQL照会を監視する役割と保護レベルを選択します。
4.1.2.1.1 保護されたロールリストの設定
保護するデータベースごとに、監視する役割を決定し、その役割をそのデータベースの保護された役割のリスト追加する必要があります。
ステップ1: psqlまたはPostgres Enterprise Manager Clientを使用して保護するデータベースにスーパーユーザーとして接続します。
$ /usr/edb/as11/bin/psql -d edb -U enterprisedb
Password for user enterprisedb:
psql.bin (11.0.2, server 11.0.2)
Type "help" for help.
 
edb=#
手順2: SQL / Protectテーブル、関数、およびビューはsqlprotectスキーマで構築されるため、 SET search_pathコマンドを使用して、検索パスにsqlprotectスキーマを含めます。これにより、SQL / Protectデータベース・オブジェクトに関連する操作または問合せをスキーマ修飾する必要がなくなります。
edb=# SET search_path TO sqlprotect;
SET
ステップ3:保護する役割を保護された役割のリストに追加する必要があります。このリストは、 edb_sql_protectテーブルで管理されています。
役割を追加するには、 protect_role(' rolename ') 関数を使用します
次の例では、 appuser という名前のロールを保護してい appuser
edb=# SELECT protect_role('appuser');
protect_role
--------------
 
(1 row)
次の問合せを発行すると、保護ロールリストに追加されたロールをリストできます。
edb=# SELECT * FROM edb_sql_protect;
dbid | roleid | protect_relations | allow_utility_cmds | allow_tautology | allow_empty_dml
-------+--------+-------------------+--------------------+-----------------+-----------------
13917 | 16671 | t | f | f | f
(1 row)
オブジェクト識別番号(OID)の代わりにオブジェクト名を使用して同じ情報を提供するビューも提供されています。
edb=# \x
Expanded display is on.
edb=# SELECT * FROM list_protected_users;
-[ RECORD 1 ]------+--------
dbname | edb
username | appuser
protect_relations | t
allow_utility_cmds | f
allow_tautology | f
allow_empty_dml | f
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 /保護のデフォルトの動作は受動的です。
初めてSQL / Protectを使用している場合は、 edb_sql_protect.levellearnするように設定learn
4.1.2.2 保護されたロールの監視
データベースにSQL / Protectを構成し、保護ロールのリストにロールを追加し、必要な保護レベルを設定したら、学習モード、パッシブモード、またはアクティブモードのいずれかでSQL / Protectをアクティブにできます。その後、アプリケーションの実行を開始できます。
新しいSQL / Protectインストールでは、最初に、保護されたロールが通常の操作中にアクセスできるようにする関係を決定します。ラーニングモードでは、SQL / Protectがアクセスされたリレーションを記録している間に、ロールを使用してアプリケーションを実行できます。これらは 、表edb_sql_protect_rel格納されているロールの 保護関係リストに追加されます。
SQL / Protectがパッシブモードまたはアクティブモードで実行されている場合、攻撃に対する保護の監視が開始されます。受動的および能動的モードでは、役割は保護された関係リスト内の関係にアクセスすることが許可される。なぜなら、これらの関係は、典型的な使用中に役割がアクセスできるべきであると決定されたからである。
ただし、ロールが保護リレーションシップ・リストにないリレーションにアクセスしようとすると、 SQL / ProtectによってWARNINGまたはERROR重大度のメッセージが戻されます。その関係が受動的であるか能動的であるかに応じて、その役割に関する試行された行動が実行されてもされなくてもよい。
4.1.2.2.1 学習モード
ステップ1: SQL / Protectを学習モードでアクティブにするには、以下のようにpostgresql.confファイルで次のパラメータを設定します。
edb_sql_protect.enabled = on
edb_sql_protect.level = learn
ステップ2: postgresql.confファイルをリロードします。
「Advanced Configuration」を選択し、「Advanced Server」アプリケーション・メニューから「Reload Configuration」を選択します。
注:構成ファイルを再ロードする別の方法については、 pg_reload_conf関数を使用してpg_reload_conf 。次の例に示すように、スーパーユーザーとしてデータベースに接続し、関数pg_reload_confを実行してpg_reload_conf
edb=# SELECT pg_reload_conf();
pg_reload_conf
----------------
t
(1 row)
ステップ3:保護されたロールでアプリケーションを実行できるようにします。
例として、次のクエリが psqlアプリケーション内でprotected role appuserによって発行されてい appuser
edb=> SELECT * FROM dept;
NOTICE: SQLPROTECT: Learned relation: 16384
deptno | dname | loc
--------+------------+----------
10 | ACCOUNTING | NEW YORK
20 | RESEARCH | DALLAS
30 | SALES | CHICAGO
40 | OPERATIONS | BOSTON
(4 rows)
 
edb=> SELECT empno, ename, job FROM emp WHERE deptno = 10;
NOTICE: SQLPROTECT: Learned relation: 16391
empno | ename | job
-------+--------+-----------
7782 | CLARK | MANAGER
7839 | KING | PRESIDENT
7934 | MILLER | CLERK
(3 rows)
SQL / Protectは 、ロールの保護関係リストにリレーションが追加されたことを示すNOTICE重大度メッセージを生成します。
SQL / Protect学習モードでは、疑念の原因となっているSQL文は実行されませんが、次の例に示すように、潜在的に危険なステートメントをユーザーに警告するメッセージが発行されます。
edb=> CREATE TABLE appuser_tab (f1 INTEGER);
NOTICE: SQLPROTECT: This command type is illegal for this user
CREATE TABLE
edb=> DELETE FROM appuser_tab;
NOTICE: SQLPROTECT: Learned relation: 16672
NOTICE: SQLPROTECT: Illegal Query: empty DML
DELETE 0
ステップ4:保護されたロールがアプリケーションを実行するときに、SQL / Protectテーブルを照会して、ロールの保護されたリレーションリストへのリレーションシップの追加を観察できます。
監視するデータベースにスーパーユーザーとして接続し、 sqlprotectスキーマを含むように検索パスを設定します。
edb=# SET search_path TO sqlprotect;
SET
edb_sql_protect_relテーブルを照会して、保護関係リストに追加された関係を確認します。
edb=# SELECT * FROM edb_sql_protect_rel;
dbid | roleid | relid
-------+--------+-------
13917 | 16671 | 16384
13917 | 16671 | 16391
13917 | 16671 | 16672
(3 rows)
list_protected_rels ビューが提供され、OIDの代わりにオブジェクト名とともにより包括的な情報が得られます。
edb=# SELECT * FROM list_protected_rels;
Database | Protected User | Schema | Name | Type | Owner
----------+----------------+--------+-------------+-------+--------------
edb | appuser | public | dept | Table | enterprisedb
edb | appuser | public | emp | Table | enterprisedb
edb | appuser | public | appuser_tab | Table | appuser
(3 rows)
4.1.2.2.2 受動モード
ロールのアプリケーションが必要なすべてのリレーションシップにアクセスしたことを確認すると、保護レベルを変更できるようになり、SQL / ProtectがSQLクエリをアクティブに監視してSQLインジェクション攻撃から保護できるようになります。
パッシブモードは、パッシブモードとアクティブモードの2つの保護モードのうち、あまり制限的ではありません。
ステップ1:パッシブモードでSQL / Protectを有効にするには、以下のようにpostgresql.confファイルに次のパラメータを設定します。
edb_sql_protect.enabled = on
edb_sql_protect.level = passive
ステップ2:セクション4.1.2.2.1のステップ2に示すように、コンフィギュレーションファイルをリロードします。
SQL / Protectはパッシブ・モードになりました。以前の例 deptテーブルやempテーブルなどで学習されたリレーションについては、SQL / Protectによってクライアントに特別な通知をせずに、user appuserによって実行される次のクエリのようにSQLステートメントが許可されますappuser
edb=> SELECT * FROM dept;
deptno | dname | loc
--------+------------+----------
10 | ACCOUNTING | NEW YORK
20 | RESEARCH | DALLAS
30 | SALES | CHICAGO
40 | OPERATIONS | BOSTON
(4 rows)
 
edb=> SELECT empno, ename, job FROM emp WHERE deptno = 10;
empno | ename | job
-------+--------+-----------
7782 | CLARK | MANAGER
7839 | KING | PRESIDENT
7934 | MILLER | CLERK
(3 rows)
SQL / Protectは、SQL文の実行を妨げませんが、学習されなかったリレーションに対して実行されたSQL文、または禁止された署名を含むSQL文に対して、次の例に示すようなWARNING重大度のメッセージを発行します
edb=> CREATE TABLE appuser_tab_2 (f1 INTEGER);
WARNING: SQLPROTECT: This command type is illegal for this user
CREATE TABLE
edb=> INSERT INTO appuser_tab_2 VALUES (1);
WARNING: SQLPROTECT: Illegal Query: relations
INSERT 0 1
edb=> INSERT INTO appuser_tab_2 VALUES (2);
WARNING: SQLPROTECT: Illegal Query: relations
INSERT 0 1
edb=> SELECT * FROM appuser_tab_2 WHERE 'x' = 'x';
WARNING: SQLPROTECT: Illegal Query: relations
WARNING: SQLPROTECT: Illegal Query: tautology
f1
----
1
2
(2 rows)
ステップ3:不審な活動の統計情報を監視する。
edb_sql_protect_stats ビューを照会すると、ロールの保護されたリレーションリストに含まれていないリレーションやSQLインジェクション攻撃シグネチャを含むリレーションを参照したSQL文の実行回数を確認できます。セクションを参照してください。 4.1.1.2.2をビューの詳細については、 edb_sql_protect_stats
次は edb_sql_protect_stats クエリ edb_sql_protect_stats
edb=# SET search_path TO sqlprotect;
SET
edb=# SELECT * FROM edb_sql_protect_stats;
username | superusers | relations | commands | tautology | dml
----------+------------+-----------+----------+-----------+-----
appuser | 0 | 3 | 1 | 1 | 0
(1 row)
ステップ4:特定の攻撃に関する情報を表示します。
edb_sql_protect_queries ビューを照会すると、ロールの保護されたリレーションリストにないリレーションを参照する、またはSQLインジェクション攻撃シグネチャが含まれているSQL文が表示されます。セクションを参照してください。 4.1.1.2.3をビューの詳細については、 edb_sql_protect_queries
以下は、 edb_sql_protect_queries クエリ edb_sql_protect_queries
edb=# SELECT * FROM edb_sql_protect_queries;
-[ RECORD 1 ]+---------------------------------------------
username | appuser
ip_address |
port |
machine_name |
date_time | 20-JUN-14 13:21:00 -04:00
query | INSERT INTO appuser_tab_2 VALUES (1);
-[ RECORD 2 ]+---------------------------------------------
username | appuser
ip_address |
port |
machine_name |
date_time | 20-JUN-14 13:21:00 -04:00
query | CREATE TABLE appuser_tab_2 (f1 INTEGER);
-[ RECORD 3 ]+---------------------------------------------
username | appuser
ip_address |
port |
machine_name |
date_time | 20-JUN-14 13:22:00 -04:00
query | INSERT INTO appuser_tab_2 VALUES (2);
-[ RECORD 4 ]+---------------------------------------------
username | appuser
ip_address |
port |
machine_name |
date_time | 20-JUN-14 13:22:00 -04:00
query | SELECT * FROM appuser_tab_2 WHERE 'x' = 'x';
注意:攻撃がUnixドメインソケットを使用するデータベースサーバと同じホスト(つまり、 pg_hba.conf接続タイプlocal )で起きた場合、 ip_addressおよびportカラムは情報を返しません。
4.1.2.2.3 アクティブモード
アクティブ・モードでは、許可されていないSQL文は実行できません。また、SQL / Protectによって発行されるメッセージは、 WARNINGではなくERROR 重大度が高くなっています
ステップ1:アクティブモードでSQL / Protectを有効にするには、以下のようにpostgresql.confファイルで次のパラメータを設定します。
edb_sql_protect.enabled = on
edb_sql_protect.level = active
ステップ2:セクション4.1.2.2.1のステップ2に示すように、コンフィギュレーションファイルをリロードします。
次の例では、セクションのステップ2の例で与えられたものと同様のSQL文示す 4.1.2.2.2が、ユーザーによって実行さappuser場合edb_sql_protect.levelに設定されているactive
edb=> CREATE TABLE appuser_tab_3 (f1 INTEGER);
ERROR: SQLPROTECT: This command type is illegal for this user
edb=> INSERT INTO appuser_tab_2 VALUES (1);
ERROR: SQLPROTECT: Illegal Query: relations
edb=> SELECT * FROM appuser_tab_2 WHERE 'x' = 'x';
ERROR: SQLPROTECT: Illegal Query: relations
結果は次のようになります。
edb=# SELECT * FROM sqlprotect.edb_sql_protect_stats;
username | superusers | relations | commands | tautology | dml
----------+------------+-----------+----------+-----------+-----
appuser | 0 | 5 | 2 | 1 | 0
(1 row)
以下は、 edb_sql_protect_queries クエリ edb_sql_protect_queries
edb=# SELECT * FROM sqlprotect.edb_sql_protect_queries;
-[ RECORD 1 ]+---------------------------------------------
username | appuser
ip_address |
port |
machine_name |
date_time | 20-JUN-14 13:21:00 -04:00
query | CREATE TABLE appuser_tab_2 (f1 INTEGER);
-[ RECORD 2 ]+---------------------------------------------
username | appuser
ip_address |
port |
machine_name |
date_time | 20-JUN-14 13:22:00 -04:00
query | INSERT INTO appuser_tab_2 VALUES (2);
-[ RECORD 3 ]+---------------------------------------------
username | appuser
ip_address | 192.168.2.6
port | 50098
machine_name |
date_time | 20-JUN-14 13:39:00 -04:00
query | CREATE TABLE appuser_tab_3 (f1 INTEGER);
-[ RECORD 4 ]+---------------------------------------------
username | appuser
ip_address | 192.168.2.6
port | 50098
machine_name |
date_time | 20-JUN-14 13:39:00 -04:00
query | INSERT INTO appuser_tab_2 VALUES (1);
-[ RECORD 5 ]+---------------------------------------------
username | appuser
ip_address | 192.168.2.6
port | 50098
machine_name |
date_time | 20-JUN-14 13:39:00 -04:00
query | SELECT * FROM appuser_tab_2 WHERE 'x' = 'x';
 
4.1.3 一般的な保守作業
次に、他の一般的な操作の実行方法について説明します。
これらの操作を実行するには、スーパーユーザーとして接続し、スキーマ sqlprotectを検索パスに含める sqlprotectがあります。
4.1.3.1 保護されたロールリストへのロールの追加
保護されたロールリストにロールを追加するには、 protect_role(' rolename ')ます。
protect_role( ' rolename ')
これは次の例で示されます。
edb=# SELECT protect_role('newuser');
protect_role
--------------
 
(1 row)
 
4.1.3.2 保護されたロールリストからのロールの削除
保護された役割リストから役割を削除するには、次のいずれかの機能を使用します。
unprotect_role( ' rolename ')
unprotect_role( roleoid )
注意:保護ロールリストからロールを削除する前に、 DROP ROLEまたはDROP USER SQL文を使用してロールを削除すると、OIDを使用するファンクションのバリエーションが役立ちます。 SQL / Protectリレーションに対するクエリで、ユーザー名にunknown (OID=16458)などの値が返された場合は、関数のunprotect_role( roleoid )形式を使用して、削除されたロールのエントリを保護ロールリストから削除します。
これらの機能を使用して役割を削除すると、役割の保護関係リストも削除されます。
あなたが使用するまで削除されている役割の統計情報は削除されません drop_statsセクションで説明したように機能を4.1.3.5
削除されたロールの問合せは、 4.1.3.6項で説明し drop_queries関数を使用するまで削除されません
unprotect_role関数の例を次に示します。
edb=# SELECT unprotect_role('newuser');
unprotect_role
----------------
 
(1 row)
あるいは、その役割は、 16693 OIDを与えることで削除できます
edb=# SELECT unprotect_role(16693);
unprotect_role
----------------
 
(1 row)
 
4.1.3.3 ロールの保護のタイプの設定
特定のタイプのSQLインジェクション攻撃からロールを保護するかどうかを変更することができます。
役割の保護を無効または有効にするSQLインジェクション攻撃の種類に対応するedb_sql_protect の列のブール値を変更します。
edb_sql_protectを更新する文のWHERE句で、 次の列を修飾してください
dbid。変更を行うデータベースのOID
roleid。 Boolean設定を変更するロールのOID
たとえば、特定のロールがユーティリティコマンドを発行できるようにするには、 allow_utility_cmdsカラムを次のように更新します。
UPDATE edb_sql_protect SET allow_utility_cmds = TRUE WHERE dbid = 13917 AND roleid = 16671;
変更が行われたことを確認するには、 edb_sql_protectまたはlist_protected_users 照会します。次のクエリノートでは、列allow_utility_cmdstが含まれています。
edb=# SELECT dbid, roleid, allow_utility_cmds FROM edb_sql_protect;
dbid | roleid | allow_utility_cmds
-------+--------+--------------------
13917 | 16671 | t
(1 row)
更新されたルールは、変更が行われてからロールによって開始された新しいセッションに反映されます。
4.1.3.4 保護関係リストからの関係の削除
特定のロールに対して特定のリレーションシップがアクセス可能であることがSQL / Protectによって判明した場合、その後、そのリレーションをロールの保護リレーションシップリストから削除できます。
次のいずれかの機能を使用して、 edb_sql_protect_relテーブルからエントリを削除します。
unprotect_rel( ' rolename ', ' relname ')
unprotect_rel( ' rolename ', ' schema ', ' relname ')
unprotect_rel( roleoid , reloid )
relnameで指定された関係が現在の検索パスにない場合は 、2番目の関数形式を使用して関係のスキーマを指定します。
3番目の関数形式では、テキスト名ではなく、ロールとリレーションのOIDをそれぞれ指定できます。
次の例は、 public.empの保護関係リストからpublic.emp関係を削除する方法を示してい appuser
edb=# SELECT unprotect_rel('appuser', 'public', 'emp');
unprotect_rel
---------------
 
(1 row)
次のクエリは、 emp関係のエントリが存在しないことを示しています
edb=# SELECT * FROM list_protected_rels;
Database | Protected User | Schema | Name | Type | Owner
----------+----------------+--------+-------------+-------+--------------
edb | appuser | public | dept | Table | enterprisedb
edb | appuser | public | appuser_tab | Table | appuser
(2 rows)
SQL / Protectは 、ロールがそのリレーションを利用しようとするたびに、 警告を出したり、アクセスを完全にブロックしたりします( edb_sql_protect.level の設定に応じて )。
4.1.3.5 統計情報の削除
次の2つの関数のいずれかを使用して、ビュー edb_sql_protect_stats から統計を削除できます。
drop_stats( ' rolename ')
drop_stats( roleoid )
注意: 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ます。
drop_stats関数の例を次に drop_statsます。
edb=# SELECT drop_stats('appuser');
drop_stats
------------
 
(1 row)
 
edb=# SELECT * FROM edb_sql_protect_stats;
username | superusers | relations | commands | tautology | dml
----------+------------+-----------+----------+-----------+-----
(0 rows)
以下は、ロールを削除して統計を削除する前に、関数 drop_stats( roleoid )形式を使用した例です
edb=# SELECT * FROM edb_sql_protect_stats;
username | superusers | relations | commands | tautology | dml
---------------------+------------+-----------+----------+-----------+-----
unknown (OID=16693) | 0 | 5 | 3 | 1 | 0
appuser | 0 | 5 | 2 | 1 | 0
(2 rows)
 
edb=# SELECT drop_stats(16693);
drop_stats
------------
 
(1 row)
 
edb=# SELECT * FROM edb_sql_protect_stats;
username | superusers | relations | commands | tautology | dml
----------+------------+-----------+----------+-----------+-----
appuser | 0 | 5 | 2 | 1 | 0
(1 row)
 
4.1.3.6 不快なクエリの削除
次の2つの関数のいずれかを使用して、 edb_sql_protect_queries ビューから問題のあるクエリを削除できます。
drop_queries( ' rolename ')
drop_queries( roleoid )
注意: 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ます。
drop_queries関数の例を次に drop_queriesます。
edb=# SELECT drop_queries('appuser');
drop_queries
--------------
5
(1 row)
 
edb=# SELECT * FROM edb_sql_protect_queries;
username | ip_address | port | machine_name | date_time | query
----------+------------+------+--------------+-----------+-------
(0 rows)
以下は、クエリを削除する前にロールを削除したときに、関数 drop_queries( roleoid )形式を使用する例です。
edb=# SELECT username, query FROM edb_sql_protect_queries;
username | query
---------------------+----------------------------------------------
unknown (OID=16454) | CREATE TABLE appuser_tab_2 (f1 INTEGER);
unknown (OID=16454) | INSERT INTO appuser_tab_2 VALUES (2);
unknown (OID=16454) | CREATE TABLE appuser_tab_3 (f1 INTEGER);
unknown (OID=16454) | INSERT INTO appuser_tab_2 VALUES (1);
unknown (OID=16454) | SELECT * FROM appuser_tab_2 WHERE 'x' = 'x';
(5 rows)
 
edb=# SELECT drop_queries(16454);
drop_queries
--------------
5
(1 row)
 
edb=# SELECT * FROM edb_sql_protect_queries;
username | ip_address | port | machine_name | date_time | query
----------+------------+------+--------------+-----------+-------
(0 rows)
 
4.1.3.7 監視の無効化と有効化
有効にしたらSQL / Protect監視をオフにするには、次の手順を実行します。
ステップ1: postgresql.confファイルで、構成パラメータedb_sql_protect.enabledoffに設定します。
edb_sql_protect.enabled のエントリは 、次のようになります。
edb_sql_protect.enabled = off
ステップ2:セクション4.1.2.2.1のステップ2に示すように、コンフィギュレーションファイルをリロードします。
SQL / Protect監視を再度有効にするには、次の手順を実行します。
ステップ1: postgresql.confファイルで、構成パラメータedb_sql_protect.enabledonに設定します。
edb_sql_protect.enabled のエントリは 、次のようになります。
edb_sql_protect.enabled = on
ステップ2:セクション4.1.2.2.1のステップ2に示すように、コンフィギュレーションファイルをリロードします。
 
4.1.4 SQL / Protectデータベースのバックアップと復元
SQL / Protectで構成されたデータベースをバックアップし、バックアップファイルを新しいデータベースに復元するには、通常、バックアップと復元の手順に関連する事項を考慮する必要があります。これは主に、このセクションで説明するSQL / Protectテーブルのオブジェクト識別番号(OID)の使用によるものです。
注意:このセクションは、バックアップおよびリストア手順によって、 pg_dumpバックアッププログラムを使用する場合のように、新しいOIDを使用して新しいデータベースにデータベースオブジェクトを再作成する場合に適用されます。
オペレーティング・システムのコピー・ユーティリティーを使用してAdvanced Serverデータ・ファイル(ファイル・システム・バックアップ方式)のバイナリー・イメージを作成するだけで、Advanced Serverデータベース・サーバーをバックアップする場合、このセクションは適用されません。
4.1.4.1 SQL / Protectテーブルのオブジェクト識別番号
SQL / Protectは2つのテーブル edb_sql_protectedb_sql_protect_relを使用して、データベース、ロール、リレーションなどのデータベースオブジェクトに関する情報を格納します。これらのテーブル内のこれらのデータベースオブジェクトへの参照は、オブジェクトのテキスト名ではなく、オブジェクトのOIDを使用して行われます。 OIDは、Advanced Serverが各データベースオブジェクトを一意に識別するために使用する数値データ型です。
データベース・オブジェクトが作成されると、Advanced ServerはオブジェクトにOIDを割り当てます.OIDは、データベース・カタログ内のオブジェクトへの参照が必要な場合に使用されます。 2つのデータベース(同じ CREATE TABLEステートメントを持つテーブルなど)に同じデータベースオブジェクトを作成すると 、各テーブルには各データベースの異なるOIDが割り当てられます。
バックアップおよびリストア操作で、バックアップされたデータベースオブジェクトが再作成されると、復元されたオブジェクトは元のデータベースで割り当てられたものとは異なる新しいOIDで新しいデータベースに格納されます。その結果、に保存されているデータベース、役割、および関係参照のOID edb_sql_protectedb_sql_protect_relこれらのテーブルは、単にバックアップファイルにダンプし、新しいデータベースに復元されたときに、テーブルは、もはや有効ではありません。
以下のセクションでは、 export_sqlprotectimport_sqlprotect 2つの関数について説明します。 export_sqlprotect 関数は、 SQL / ProtectテーブルのOIDがSQL / Protectテーブルの復元後に正しいデータベースオブジェクトを参照するように、SQL / Protectテーブルのバックアップと復元に使用されます。
4.1.4.2 データベースのバックアップ
SQL / Protectで構成されたデータベースをバックアップする手順は次のとおりです。
ステップ1: pg_dumpを使用してバックアップファイルを作成します。
次の例はpg_dumpユーティリティプログラムを使用してedbデータベースから作成された /tmp/edb.dmp という名前のプレーンテキストのバックアップファイルを示しています
$ cd /usr/edb/as11/bin
$ ./pg_dump -U enterprisedb -Fp -f /tmp/edb.dmp edb
Password:
$
手順2:スーパーユーザーとしてデータベースに接続し、 export_sqlprotect(' sqlprotect_file ')関数を使用してSQL / Protectデータをエクスポートします。ここでsqlprotect_fileは、SQL / Protectデータを保存するファイルの完全修飾パスです。
enterprisedb 、オペレーティング・システム・アカウント( postgresあなたは、PostgreSQLの互換モードでAdvanced Serverをインストールした場合)読みとで指定されたディレクトリへのアクセスの書き込みしている必要がありますsqlprotect_file
edb=# SELECT sqlprotect.export_sqlprotect('/tmp/sqlprotect.dmp');
export_sqlprotect
-------------------
 
(1 row)
/tmp/edb.dmpおよび/tmp/sqlprotect.dmp ファイルは、データベース全体のバックアップを構成します。
4.1.4.3 バックアップファイルからの復元
手順1:バックアップファイルを新しいデータベースに復元します。
次の例では、 psqlユーティリティー・プログラムを使用して 、プレーン・テキスト・バックアップ・ファイル/tmp/edb.dmpnewdbという名前の新しく作成されたデータベースにリストアします。
$ /usr/edb/as11/bin/psql -d newdb -U enterprisedb -f /tmp/edb.dmp
Password for user enterprisedb:
SET
SET
SET
SET
SET
COMMENT
CREATE SCHEMA
.
.
.
ステップ2:新しいデータベースにスーパーユーザーとして接続し、 edb_sql_protect_relテーブルからすべての行を削除します。
この手順は 、元のデータベースからバックアップされた edb_sql_protect_relテーブル内の既存の行をすべて削除します。これらの行には、バックアップ・ファイルがリストアされたデータベースに対する正しいOIDは含まれていません。
$ /usr/edb/as11/bin/psql -d newdb -U enterprisedb
Password for user enterprisedb:
psql.bin (11.0.2, server 11.0.2)
Type "help" for help.
 
newdb=# DELETE FROM sqlprotect.edb_sql_protect_rel;
DELETE 2
ステップ3: edb_sql_protectテーブルからすべての行を削除します。
この手順では 、元のデータベースからバックアップされた edb_sql_protectテーブル内の既存の行がすべて削除されます。これらの行には、バックアップ・ファイルがリストアされたデータベースに対する正しいOIDは含まれていません。
newdb=# DELETE FROM sqlprotect.edb_sql_protect;
DELETE 1
ステップ4:データベースに存在する可能性のある統計情報をすべて削除します。
この手順では、バックアップを復元するデータベースに存在する既存の統計情報をすべて削除します。次のクエリは、既存の統計情報を表示します。
newdb=# SELECT * FROM sqlprotect.edb_sql_protect_stats;
username | superusers | relations | commands | tautology | dml
----------+------------+-----------+----------+-----------+-----
(0 rows)
前のクエリに表示される各行に対して 、エントリのロール名を指定するdrop_stats関数を使用します
たとえばusername列にappuser行が表示された場合は 、次のコマンドを実行して削除します。
newdb=# SELECT sqlprotect.drop_stats('appuser');
drop_stats
------------
 
(1 row)
手順5:データベースに存在する可能性のある問題のあるクエリをすべて削除します。
この手順では、バックアップを復元するデータベースに存在する既存のクエリがすべて削除されます。次のクエリは、既存のクエリをすべて表示します。
edb=# SELECT * FROM sqlprotect.edb_sql_protect_queries;
username | ip_address | port | machine_name | date_time | query
----------+------------+------+--------------+-----------+-------
(0 rows)
前のクエリに表示される各行について 、エントリのロール名を指定するdrop_queries関数を使用します
たとえばusername列にappuser行が表示された場合は 、次のコマンドを実行して削除します。
edb=# SELECT sqlprotect.drop_queries('appuser');
drop_queries
--------------
 
(1 row)
手順6:元のデータベースのSQL / Protectで保護されていた役割名が、新しいデータベースが存在するデータベースサーバーに存在することを確認します。
元のデータベースと新しいデータベースが同じデータベースサーバーにある場合、データベースサーバーからこれらの役割のいずれも削除していないと仮定すると、何もする必要はありません。
手順7:関数import_sqlprotect(' sqlprotect_file ')ここで、 sqlprotect_fileは、 4.1.4.2項の手順2で作成したファイルへの完全修飾パスです
newdb=# SELECT sqlprotect.import_sqlprotect('/tmp/sqlprotect.dmp');
import_sqlprotect
-------------------
 
(1 row)
テーブル edb_sql_protectおよびedb_sql_protect_relに、新しいデータベースに割り当てられたデータベースオブジェクトのOIDを含むエントリが入力されるようになりました。統計ビューedb_sql_protect_statsも元のデータベースからインポートされた統計が表示されるようになりました。
このデータベースのSQL / Protectテーブルおよび統計情報が適切に復元されるようになりました。これは、Advanced Serverシステムカタログの次のクエリによって検証されます。
newdb=# SELECT datname, oid FROM pg_database;
datname | oid
-----------+-------
template1 | 1
template0 | 13909
edb | 13917
newdb | 16679
(4 rows)
 
newdb=# SELECT rolname, oid FROM pg_roles;
rolname | oid
--------------+-------
enterprisedb | 10
appuser | 16671
newuser | 16678
(3 rows)
 
newdb=# SELECT relname, oid FROM pg_class WHERE relname IN ('dept','emp','appuser_tab');
relname | oid
-------------+-------
appuser_tab | 16803
dept | 16809
emp | 16812
(3 rows)
 
newdb=# SELECT * FROM sqlprotect.edb_sql_protect;
dbid | roleid | protect_relations | allow_utility_cmds | allow_tautology | allow_empty_dml
-------+--------+-------------------+--------------------+-----------------+-----------------
16679 | 16671 | t | t | f | f
(1 row)
 
newdb=# SELECT * FROM sqlprotect.edb_sql_protect_rel;
dbid | roleid | relid
-------+--------+-------
16679 | 16671 | 16809
16679 | 16671 | 16803
(2 rows)
 
newdb=# SELECT * FROM sqlprotect.edb_sql_protect_stats;
username | superusers | relations | commands | tautology | dml
----------+------------+-----------+----------+-----------+-----
appuser | 0 | 5 | 2 | 1 | 0
(1 row)
 
newedb=# \x
Expanded display is on.
nwedb=# SELECT * FROM sqlprotect.edb_sql_protect_queries;
-[ RECORD 1 ]+---------------------------------------------
username | appuser
ip_address |
port |
machine_name |
date_time | 20-JUN-14 13:21:00 -04:00
query | CREATE TABLE appuser_tab_2 (f1 INTEGER);
-[ RECORD 2 ]+---------------------------------------------
username | appuser
ip_address |
port |
machine_name |
date_time | 20-JUN-14 13:22:00 -04:00
query | INSERT INTO appuser_tab_2 VALUES (2);
-[ RECORD 3 ]+---------------------------------------------
username | appuser
ip_address | 192.168.2.6
port | 50098
machine_name |
date_time | 20-JUN-14 13:39:00 -04:00
query | CREATE TABLE appuser_tab_3 (f1 INTEGER);
-[ RECORD 4 ]+---------------------------------------------
username | appuser
ip_address | 192.168.2.6
port | 50098
machine_name |
date_time | 20-JUN-14 13:39:00 -04:00
query | INSERT INTO appuser_tab_2 VALUES (1);
-[ RECORD 5 ]+---------------------------------------------
username | appuser
ip_address | 192.168.2.6
port | 50098
machine_name |
date_time | 20-JUN-14 13:39:00 -04:00
query | SELECT * FROM appuser_tab_2 WHERE 'x' = 'x';
edb_sql_protectおよびedb_sql_protect_rel 列については、次の点に注意してください
dbid。 newdb pg_databaseoidカラムの値と一致します。
roleid。 pg_rolesoidカラムの値と一致しますappuser
またedb_sql_protect_rel テーブルでは、 relidカラムの値は、リレーションdeptappuser_tab pg_classoidカラムの値と一致します。
ステップ8:新しいデータベースを実行しているデータベースサーバのpostgresql.confファイルにSQL / Protect設定パラメータが必要に応じて設定されていることを確認します。データベースサーバーを再起動するか、必要に応じて構成ファイルを再ロードしてください。
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 sslutils
sslutilsは、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_key
openssl_rsa_generate_key機能は、RSA秘密鍵を生成します。関数のシグネチャは次のとおりです。
openssl_rsa_generate_key( integer ) RETURNS text
関数を呼び出すときは、ビット数を整数値として渡します。この関数は生成されたキーを返します。
4.3.2 openssl_rsa_key_to_csr
openssl_rsa_key_to_csr機能は、証明書署名要求(CSR)を生成します。署名は次のとおりです。
openssl_rsa_key_to_csr( text , text , text , text , text , text , text ) RETURNS text
この関数は、証明書の署名要求を生成して返します。
パラメーター
parameter 1
RSAキーファイルの名前。
parameter 2
署名要求を使用するエージェントの共通名( agentN )。
parameter 3
サーバーが存在する国の名前。
parameter 4
サーバーが存在する状態の名前。
parameter 5
サーバーが存在する州内のロケーション(都市)。
parameter 6
証明書を要求している組織ユニットの名前。
parameter 7
証明書を要求しているユーザーの電子メールアドレス。
4.3.3 openssl_csr_to_crt
openssl_csr_to_crt機能は、自己署名証明書または認証局の証明書を生成します。署名は次のとおりです。
openssl_csr_to_crt( text , text , text ) RETURNS text
この関数は、自己署名証明書または認証局証明書を返します。
パラメーター
parameter 1
要求に署名する証明書の名前。
parameter 2
認証局証明書へのパス 。認証局証明書を生成する場合はNULL
parameter 3
認証局の秘密鍵へのパスまたは(引数2が NULL 場合 )秘密鍵へのパス。
4.3.4 openssl_rsa_generate_crl
openssl_rsa_generate_crl機能は、デフォルトの証明書失効リストを生成します。署名は次のとおりです。
openssl_rsa_generate_crl( text , text ) RETURNS text
この関数は、証明書失効リストを返します。
パラメーター
parameter 1
認証局証明書へのパス。
parameter 2
認証局の秘密鍵へのパス。
 
4.4 データの改ざん
データの改ざんは、特定のユーザーに対して表示されるデータを動的に変更することによって機密データの暴露を制限する手法です。
たとえば、社会保障番号(SSN)は 021-23-9567 として格納され 021-23-9567 。特権ユーザーには完全なSSNが表示され、他のユーザーには最後の4桁のxxx-xx-9567しか表示されxxx-xx-9567
データの修正は、修正が適用される各フィールドの関数を定義することによって実装されます。この関数は、データの再編集の対象となるユーザーに表示する必要がある値を返します。
したがって、たとえば、SSNフィールドの場合、redaction関数は xxx-xx-9567の入力SSNに対してxxx-xx-9567021-23-9567ます。
給与項目では、入力機能の給与値に関係なく、編集機能は常に $0.00 返します。
これらの関数は、 CREATE REDACTION POLICYコマンドを使用して、変更ポリシーに組み込まれます。このコマンドは、ポリシーが適用されるテーブル、指定された編集機能によって影響を受けるテーブルの列、影響を受けるセッションユーザーを決定する式、およびその他のオプションを指定します。
postgresql.confファイル edb_data_redactionパラメータは、データの改訂を適用するかどうかを決定します。
デフォルトでは、パラメータが有効になっているので、編集ポリシーが有効になり、次のようになります。
セッション中にパラメータが FALSE設定されて無効にされている FALSEは、次のようになります。
変更ポリシーは、 ALTER REDACTION POLICYコマンドを使用して変更することも、 DELETE REDACTION POLICYコマンドを使用してDELETE REDACTION POLICYすることもできます。
編集ポリシーのコマンドについては、以降のセクションで詳しく説明します。
 
4.4.1 リセッション・ポリシーの作成
CREATE REDACTION POLICYは、テーブルの新しいデータ変更ポリシーを定義します。
シノプシス
CREATE REDACTION POLICY name ON table_name
[ FOR ( expression ) ]
[ ADD [ COLUMN ] column_name USING funcname_clause
[ WITH OPTIONS ( [ redaction_option ]
[, redaction_option ] )
]
] [, ...]
ここで、 redaction_optionは次のとおりです。
{ SCOPE scope_value |
EXCEPTION exception_value }
説明
CREATE REDACTION POLICYコマンドが改訂関数を使用して列データをredactingによってテーブルの新しい列レベルのセキュリティポリシーを定義します。新しく作成されたデータ変更ポリシーは、デフォルトで有効になります。ポリシーは、 ALTER REDACTION POLICY ... DISABLEを使用して無効にすることができます。
FOR ( expression )
このフォームは、改ざんポリシーの式を追加します。
ADD [ COLUMN ]
このオプションのフォームは、テーブルの列をデータ編集ポリシーに追加します。 USING改訂の関数式を指定します。複数のADD [ COLUMN ]フォームを使用して、テーブルの複数の列を作成するデータ書き換えポリシーに追加することができます。オプションのWITH OPTIONS ( ... )句は、適用されるデータ変更ポリシーの有効範囲および/または例外を指定します。スコープおよび/または例外を指定しない場合、スコープおよび例外のデフォルト値はそれぞれqueryおよびnoneなりquery
パラメーター
name
作成されるデータ変更ポリシーの名前。これは、テーブルの他の既存のデータ変更ポリシーの名前とは異なる名前でなければなりません。
table_name
データ変更ポリシーが適用されるテーブルの名前(スキーマ修飾名でも可)。
expression
データ修正ポリシーの式。この式が偽と評価された場合、修正は適用されません。
column_name
データ変更ポリシーが作成されるテーブルの既存の列の名前。
funcname_clause
編集された列の値をどのように計算するかを決定するデータ修正機能。リダクション関数の戻り値の型は、データ書き換え方針が追加される列の型と同じでなければなりません。
scope_value
スコープでは、列に適用される編集が行われるクエリ部分が特定されました。スコープ値は、 querytop_tlistまたはtop_tlist_or_errorです。スコープがquery場合、 queryに表示される場所に関係なく、列に適用されます。スコープがtop_tlist場合は、クエリの最上位のターゲットリストに表示されたときにのみ、列に適用されます。スコープがある場合top_tlist_or_error動作と同じになりますtop_tlistが、カラムは、クエリのどこにも表示されたときにエラーがスローされます。
exception_value
例外は、除外されるべき編集部分を特定した。例外値は、 noneequalまたはleakproofです。例外がnone場合、免除はありません。例外がequal場合は、等価テストで使用されたときには列は編集されません。例外がleakproof場合、漏れ防止機能が適用されても列は編集されません。
ノート:
テーブルの所有者で、データの変更ポリシーを作成または変更する必要があります。
スーパーユーザーとテーブルの所有者は、データ変更ポリシーから免除されます。
以下は、この機能を本番環境でどのように使用できるかの例です。 employeesテーブルのデータ修正ポリシーのコンポーネントを作成します。
CREATE TABLE employees (
id integer GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
name varchar(40) NOT NULL,
ssn varchar(11) NOT NULL,
phone varchar(10),
birthday date,
salary money,
email varchar(100)
);
 
-- Insert some data
INSERT INTO employees (name, ssn, phone, birthday, salary, email)
VALUES
( 'Sally Sample', '020-78-9345', '5081234567', '1961-02-02', 51234.34, 'sally.sample@enterprisedb.com'),
( 'Jane Doe', '123-33-9345', '6171234567', '1963-02-14', 62500.00, 'jane.doe@gmail.com'),
( 'Bill Foo', '123-89-9345', '9781234567','1963-02-14', 45350, 'william.foe@hotmail.com');
 
-- Create a user hr who can see all the data in employees
CREATE USER hr;
-- Create a normal user
CREATE USER alice;
GRANT ALL ON employees TO hr, alice;
 
-- Create redaction function in which actual redaction logic resides
CREATE OR REPLACE FUNCTION redact_ssn (ssn varchar(11)) RETURN varchar(11) IS
BEGIN
/* replaces 020-12-9876 with xxx-xx-9876 */
return overlay (ssn placing 'xxx-xx' from 1) ;
END;
 
CREATE OR REPLACE FUNCTION redact_salary () RETURN money IS BEGIN return 0::money; END;
employeesに対して、デフォルトのスコープと例外を使用して等価条件とsalaryでアクセス可能である列ssn編集するためのデータ整理ポリシーを作成します。 redactionポリシーは、 hrユーザーには適用されません。
CREATE REDACTION POLICY redact_policy_personal_info ON employees FOR (session_user != 'hr')
ADD COLUMN ssn USING redact_ssn(ssn) WITH OPTIONS (SCOPE query, EXCEPTION equal),
ADD COLUMN salary USING redact_salary();
hrユーザーの表示可能なデータは次のとおりです。
-- hr can view all columns data
edb=# \c edb hr
edb=> SELECT * FROM employees;
id | name | ssn | phone | birthday | salary | email
----+--------------+-------------+------------+--------------------+------------+-------------------------------
1 | Sally Sample | 020-78-9345 | 5081234567 | 02-FEB-61 00:00:00 | $51,234.34 | sally.sample@enterprisedb.com
2 | Jane Doe | 123-33-9345 | 6171234567 | 14-FEB-63 00:00:00 | $62,500.00 | jane.doe@gmail.com
3 | Bill Foo | 123-89-9345 | 9781234567 | 14-FEB-63 00:00:00 | $45,350.00 | william.foe@hotmail.com
(3 rows)
通常のユーザー alice の表示データは次のようになります。
-- Normal user cannot see salary and ssn number.
edb=> \c edb alice
edb=> SELECT * FROM employees;
id | name | ssn | phone | birthday | salary | email
----+--------------+-------------+------------+--------------------+--------+-------------------------------
1 | Sally Sample | xxx-xx-9345 | 5081234567 | 02-FEB-61 00:00:00 | $0.00 | sally.sample@enterprisedb.com
2 | Jane Doe | xxx-xx-9345 | 6171234567 | 14-FEB-63 00:00:00 | $0.00 | jane.doe@gmail.com
3 | Bill Foo | xxx-xx-9345 | 9781234567 | 14-FEB-63 00:00:00 | $0.00 | william.foe@hotmail.com
(3 rows)
しかし、 ssnデータは、 exception_value設定のために等価チェックに使用されたときにアクセス可能です。
-- Get ssn number starting from 123
edb=> SELECT * FROM employees WHERE substring(ssn from 0 for 4) = '123';
id | name | ssn | phone | birthday | salary | email
----+----------+-------------+------------+--------------------+--------+-------------------------
2 | Jane Doe | xxx-xx-9345 | 6171234567 | 14-FEB-63 00:00:00 | $0.00 | jane.doe@gmail.com
3 | Bill Foo | xxx-xx-9345 | 9781234567 | 14-FEB-63 00:00:00 | $0.00 | william.foe@hotmail.com
(2 rows)
警告
1。
https://www.postgresql.org/docs/11/static/ddl-inherit.html
2。
スーパーユーザーまたは表の所有者が表にマテリアライズド・ビューを作成し、その表に GRANT SELECTおよびマテリアライズド・ビューをスーパーユーザー以外のユーザーにアクセス権を付与した場合、非スーパーユーザーは非編集対象のユーザーにアクセスできますマテリアライズド・ビューを介して
3。
互換性
CREATE REDACTION POLICYは、EnterpriseDBの拡張機能です。
関連項目
ALTER REDACTIONポリシーDROP REDACTIONポリシー
 
4.4.2 ALTER REDACTION POLICY
ALTER REDACTION POLICYは、表のデータ変更ポリシーの定義を変更します。
シノプシス
ALTER REDACTION POLICY name ON table_name RENAME TO new_name
 
ALTER REDACTION POLICY name ON table_name FOR ( expression )
 
ALTER REDACTION POLICY name ON table_name { ENABLE | DISABLE}
 
ALTER REDACTION POLICY name ON table_name
ADD [ COLUMN ] column_name USING funcname_clause
[ WITH OPTIONS ( [ redaction_option ]
[, redaction_option ] )
]
 
ALTER REDACTION POLICY name ON table_name
MODIFY [ COLUMN ] column_name
{
[ USING funcname_clause ]
|
[ WITH OPTIONS ( [ redaction_option ]
[, redaction_option ] )
]
}
 
ALTER REDACTION POLICY name ON table_name
DROP [ COLUMN ] column_name
ここで、 redaction_optionは次のとおりです。
{ SCOPE scope_value |
EXCEPTION exception_value }
説明
ALTER REDACTION POLICYは、既存のデータ修正ポリシーの定義を変更します。
ALTER REDACTION POLICY を使用するには、データ変更ポリシーが適用されるテーブルを所有している必要があります。
FOR ( expression )
このフォームは、データ変更ポリシーの式を追加または置き換えます。
ENABLE
以前に無効化されたテーブルのデータ変更ポリシーを有効にします。
DISABLE
テーブルのデータ変更ポリシーを無効にします。
ADD [ COLUMN ]
このフォームは、既存の編集ポリシーにテーブルの列を追加します。詳細については、 CREATE REDACTION POLICYを参照してください。
MODIFY [ COLUMN ]
このフォームは、表の列に対するデータ変更ポリシーを変更します。列のredaction function節および/またはredactionオプションを更新できます。 USING句は、改訂の関数式を更新する指定し、 WITH OPTIONS ( ... )句は、適用範囲および/または例外を指定します。 redaction関数節、redactionスコープ、およびredaction例外の詳細については、「 CREATE REDACTION POLICY 」を参照してください。
DROP [ COLUMN ]
このフォームは、データ変更ポリシーからテーブルの列を削除します。
パラメーター
name
変更する既存のデータ修正ポリシーの名前。
table_name
データ変更ポリシーが適用されているテーブルの名前(スキーマ修飾名でも可)。
new_name
データ変更ポリシーの新しい名前。これは、テーブルの他の既存のデータ変更ポリシーの名前とは異なる名前でなければなりません。
expression
データ修正ポリシーの式。
column_name
データ変更ポリシーが変更または削除されるテーブルの既存の列の名前。
funcname_clause
列のデータ修正関数式。詳細については、 CREATE REDACTION POLICYを参照してください。
scope_value
スコープでは、列に適用される編集が行われるクエリ部分が特定されました。詳細については、 CREATE REDACTION POLICYを参照してください。
exception_value
例外は、除外されるべき編集部分を特定した。詳細については、 CREATE REDACTION POLICYを参照してください。
employeesという名前のテーブルのredact_policy_personal_infoという名前のデータ変更ポリシーを更新します
ALTER REDACTION POLICY redact_policy_personal_info ON employees
FOR (session_user != 'hr' AND session_user != 'manager');
同じポリシーで ssn データ変更機能を更新するには:
ALTER REDACTION POLICY redact_policy_personal_info ON employees
MODIFY COLUMN ssn USING redact_ssn_new(ssn);
互換性
ALTER REDACTION POLICYは、EnterpriseDBの拡張機能です。
関連項目
取り消しポリシーの作成取り消しポリシーの削除
 
4.4.3 ドロップ・リセッション・ポリシー
DROP REDACTION POLICYは、テーブルからデータ変更ポリシーを削除します。
シノプシス
DROP REDACTION POLICY [ IF EXISTS ] name ON table_name
[ CASCADE | RESTRICT ]
説明
DROP REDACTION POLICYは、指定されたデータ変更ポリシーをテーブルから削除します。
DROP REDACTION POLICY を使用するには、変更ポリシーが適用されるテーブルを所有している必要があります。
パラメーター
IF EXISTS
データ変更ポリシーが存在しない場合は、エラーをスローしないでください。この場合、通知が発行されます。
name
ドロップするデータ変更ポリシーの名前。
table_name
データ変更ポリシーが適用されているテーブルの名前(スキーマ修飾名でも可)。
CASCADE
RESTRICT
これらのキーワードは、データ変更ポリシーに依存しないため、何の効果もありません。
employeesという名前のテーブルにredact_policy_personal_info というデータ変更ポリシーをドロップするには、 redact_policy_personal_infoにします。
DROP REDACTION POLICY redact_policy_personal_info ON employees;
互換性
DROP REDACTION POLICYは、EnterpriseDBの拡張機能です。
関連項目
リダイレクトポリシーの作成ALTER REDACTION POLICY
 
4.4.4 システムカタログ
このセクションでは、変更ポリシー情報を格納するシステムカタログについて説明します。
4.4.4.1 edb_redaction_column
カタログ edb_redaction_columnは、表の列にアタッチされたデータ変更ポリシーの情報が格納されます。
oid
oid
oid
oid
The redaction scope: 1 = query, 2 = top_tlist, 4 = top_tlist_or_error
The redaction exception: 8 = none, 16 = equal, 32 = leakproof
注:表の編集ポリシーedb_redaction_column.rdpolicyidが有効になっていて、編集ポリシー表現edb_redaction_policy.rdexprがtrueと評価された場合は、記述された列が編集されます。
4.4.4.2 edb_redaction_policy
カタログ edb_redaction_policyは、表の編集ポリシーの情報が保管されます。
oid
oid
oid
注:テーブルが有効で、式が真に評価された場合は、データ変更ポリシーがテーブルに適用されます。
5 EDBリソースマネージャ
EDBリソースマネージャは、Advanced Serverプロセスで使用されるオペレーティングシステムリソースの使用を制御する機能を提供するAdvanced Server機能です。
この機能により、特定のシステムリソースを過度に使いすぎて独占する可能性のあるプロセスからシステムを保護することができます。
以下は、EDB Resource Managerの使用に関する重要なポイントです。
EDB Resource Managerの基本コンポーネントはリソースグループです。 リソース・グループは、さまざまなリソースの使用制限が定義可能なAdvanced Serverのインスタンス内のすべてのデータベースに利用できるという名前の、グローバルグループ、です。特定のリソースグループのメンバとして割り当てられているAdvanced Serverプロセスは、EDBリソースマネージャによって制御され、グループ内のすべてのプロセスの集約リソース使用率がグループに定義された制限の近くに保持されます。
リソースグループに属するすべてのプロセスの望ましい消費レベルは、 リソースタイプのパラメータ によって定義され ます 。 EDB Resource Managerが現在サポートしているさまざまな種類のシステムリソースには、異なるリソースタイプのパラメータがあります。
edb_max_resource_groups構成パラメータは、実行中のプロセスで同時にアクティブにできるリソース・グループの最大数を設定します。デフォルト設定は16リソースグループです。このパラメータの変更は、データベースサーバの再起動時に有効になります。
現在のプロセスを指定されたリソースグループに割り当てるには SET edb_resource_group TO group_nameコマンドを使用し group_name 。現在のプロセスをリソースグループから削除するには、 RESET edb_resource_groupコマンドまたはSET edb_resource_group TO DEFAULTコマンドを使用します。
デフォルトのリソースグループは、 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 group _ name ;
説明
CREATE RESOURCE GROUPコマンドは、指定された名前を持つリソース・グループを作成します。 ALTER RESOURCE GROUPコマンドを使用して、グループでリソース制限を定義できます。リソースグループは、Advanced Serverインスタンスのすべてのデータベースからアクセスできます。
CREATE RESOURCE GROUPコマンドを使用するには、スーパーユーザー権限が必要です。
パラメーター
group_name
リソース・グループの名前。
次の例では、 resgrp_aresgrp_b 、およびresgrp_c という3つのリソースグループが作成されます。
edb=# CREATE RESOURCE GROUP resgrp_a;
CREATE RESOURCE GROUP
edb=# CREATE RESOURCE GROUP resgrp_b;
CREATE RESOURCE GROUP
edb=# CREATE RESOURCE GROUP resgrp_c;
CREATE RESOURCE GROUP
次のクエリは、 edb_resource_groupカタログ内のリソースグループのエントリを示しています
edb=# SELECT * FROM edb_resource_group;
rgrpname | rgrpcpuratelimit | rgrpdirtyratelimit
----------+------------------+--------------------
resgrp_a | 0 | 0
resgrp_b | 0 | 0
resgrp_c | 0 | 0
(3 rows)
5.1.2 ALTER RESOURCE GROUP
既存のリソースグループの属性を変更するには、 ALTER RESOURCE GROUPコマンドを使用します。コマンド構文には3つの形式があります。
最初のフォームは、リソースグループの名前を変更します。
ALTER RESOURCE GROUP group_name RENAME TO new _ name ;
2番目の形式は、リソースグループにリソースタイプを割り当てます。
ALTER RESOURCE GROUP group_name SET
resource_type { TO | = } { value | DEFAULT };
3番目の形式では、リソースタイプのグループ内でのデフォルトへの割り当てがリセットされます。
ALTER RESOURCE GROUP group _ name RESET resource_type ;
説明
ALTER RESOURCE GROUPコマンドは、既存のリソース・グループの特定の属性を変更します。
RENAME TOを含む最初の形式は、既存のリソースグループに新しい名前を割り当てます。
SET resource_type TO句を使用する2番目の形式は、指定されたリテラル値をリソース・タイプに割り当てるか、またはDEFAULTが指定されたときにリソース・タイプをリセットします。リソースタイプをDEFAULTリセットまたは設定するということは、リソースグループにそのリソースタイプに定義された制限がないことを意味します。
RESET resource_type句を使用する3番目の形式は、前述のようにグループのリソースタイプをリセットします。
ALTER RESOURCE GROUPコマンドを使用するには、スーパーユーザー権限が必要です。
パラメーター
group_name
変更されるリソース・グループの名前。
new_name
リソースグループに割り当てる新しい名前。
resource_type
使用量を設定するリソースのタイプを指定するリソースタイプパラメータ。
value | DEFAULT
ときに value指定され、リテラル値がに割り当てられるresource_typeDEFAULTを指定すると、リソース・グループのresource_typeの割り当てがリセットされます。
次に、 ALTER RESOURCE GROUPコマンドの例を示します。
edb=# ALTER RESOURCE GROUP resgrp_a RENAME TO newgrp;
ALTER RESOURCE GROUP
edb=# ALTER RESOURCE GROUP resgrp_b SET cpu_rate_limit = .5;
ALTER RESOURCE GROUP
edb=# ALTER RESOURCE GROUP resgrp_b SET dirty_rate_limit = 6144;
ALTER RESOURCE GROUP
edb=# ALTER RESOURCE GROUP resgrp_c RESET cpu_rate_limit;
ALTER RESOURCE GROUP
以下の照会は、 ALTER RESOURCE GROUPコマンドの結果を edb_resource_groupカタログの項目にedb_resource_groupます。
edb=# SELECT * FROM edb_resource_group;
rgrpname | rgrpcpuratelimit | rgrpdirtyratelimit
----------+------------------+--------------------
newgrp | 0 | 0
resgrp_b | 0.5 | 6144
resgrp_c | 0 | 0
(3 rows)
5.1.3 DROP RESOURCE GROUP
DROP RESOURCE GROUPを削除するには、 DROP RESOURCE GROUPコマンドを使用します。
DROP RESOURCE GROUP [ IF EXISTS ] group _ name ;
説明
DROP RESOURCE GROUPコマンドは、指定した名前のリソース・グループを削除します。
DROP RESOURCE GROUPコマンドを使用するには、スーパーユーザー権限が必要です。
パラメーター
group_name
削除されるリソース・グループの名前。
IF EXISTS
リソース・グループが存在しない場合は、エラーをスローしないでください。この場合、通知が発行されます。
次の例では、リソースグループ newgrp 削除します。
edb=# DROP RESOURCE GROUP newgrp;
DROP RESOURCE GROUP
5.1.4 リソース・グループへのプロセスの割当て
次のように、 SET edb_resource_group TO group_nameコマンドを使用して、現在のプロセスを指定されたリソースグループに割り当てます。
edb=# SET edb_resource_group TO resgrp_b;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
resgrp_b
(1 row)
グループのリソースタイプの設定は、現在のプロセスでただちに有効になります。コマンドを使用して現在のプロセスに割り当てられているリソースグループを変更すると、直ちに新しく割り当てられたグループのリソースタイプ設定が有効になります。
プロセスは、デフォルトでは、ロール、データベース、またはデータベースサーバーインスタンス全体にデフォルトのリソースグループを割り当てることによって、リソースグループにデフォルトで含めることができます。
ALTER ROLE ... SETコマンドを使用して、デフォルトのリソースグループを役割に割り当てることができますALTER ROLEコマンドの詳細については、次のURLにあるPostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/sql-alterrole.html
デフォルトのリソースグループは、 ALTER DATABASE ... SETコマンドによってデータベースに割り当てることができますALTER DATABASEコマンドの詳細については、次のURLにあるPostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/sql-alterdatabase.html
postgresql.confファイルのedb_resource_group構成パラメータをedb_resource_groupように設定すると、 データベース・サーバー・インスタンス全体にデフォルト・リソース・グループを割り当てることができます。
# - EDB Resource Manager -
#edb_max_resource_groups = 16 # 0-65536 (change requires restart)
edb_resource_group = 'resgrp_b'
postgresql.confファイルのedb_resource_group変更するには、データベースサーバインスタンスで有効になる前に設定ファイルのリロードが必要です。
5.1.5 リソース・グループからのプロセスの削除
edb_resource_groupDEFAULT 設定するか、 RESET edb_resource_groupを使用してリソース・グループから現在のプロセスを削除します。
edb=# SET edb_resource_group TO DEFAULT;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
(1 row)
役割からデフォルトのリソース・グループを除去するには、 ALTER ROLEコマンド ALTER ROLE ... RESET形式を使用します。
データベースからデフォルトのリソースグループを削除するには、 ALTER DATABASEコマンド ALTER DATABASE ... RESET形式を使用します
デフォルトのリソースグループをデータベースサーバインスタンスから削除するには、 postgresql.confファイルでedb_resource_group設定パラメータを空の文字列に設定し、設定ファイルをリロードします。
5.1.6 リソース・グループ内のプロセスの監視
リソースグループの作成後、これらのリソースグループを使用しているプロセスの数は、 edb_all_resource_groups ビューから取得できます
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=# SELECT * FROM edb_all_resource_groups ORDER BY group_name;
-[ RECORD 1 ]----------------+------------------
group_name | resgrp_a
active_processes | 0
cpu_rate_limit | 0.5
per_process_cpu_rate_limit |
dirty_rate_limit | 12288
per_process_dirty_rate_limit |
-[ RECORD 2 ]----------------+------------------
group_name | resgrp_b
active_processes | 2
cpu_rate_limit | 0.4
per_process_cpu_rate_limit | 0.195694289022895
dirty_rate_limit | 6144
per_process_dirty_rate_limit | 3785.92924684337
-[ RECORD 3 ]----------------+------------------
group_name | resgrp_c
active_processes | 1
cpu_rate_limit | 0.3
per_process_cpu_rate_limit | 0.292342129631091
dirty_rate_limit | 3072
per_process_dirty_rate_limit | 3072
これらのリソースグループに割り当てられているCPUレート制限およびダーティレート制限の設定は、次のとおりです。
edb=# SELECT * FROM edb_resource_group;
rgrpname | rgrpcpuratelimit | rgrpdirtyratelimit
----------+------------------+--------------------
resgrp_a | 0.5 | 12288
resgrp_b | 0.4 | 6144
resgrp_c | 0.3 | 3072
(3 rows)
edb_all_resource_groupsことに注意し、表示per_process_cpu_rate_limitper_process_dirty_rate_limit値はおおよそアクティブなプロセスの数で割った、対応するCPUレート制限や汚れレートリミットです。
 
5.2 CPU使用量の調整
リソースグループのCPU使用率は、 cpu_rate_limitリソースタイプパラメータを設定することによって制御されます。
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%に維持されます。
edb=# ALTER RESOURCE GROUP resgrp_a SET cpu_rate_limit TO .5;
ALTER RESOURCE GROUP
edb=# ALTER RESOURCE GROUP resgrp_b SET cpu_rate_limit TO .4;
ALTER RESOURCE GROUP
edb=# ALTER RESOURCE GROUP resgrp_c SET cpu_rate_limit TO .3;
ALTER RESOURCE GROUP
次のクエリは 、カタログ内 cpu_rate_limit の設定を示しています
edb=# SELECT rgrpname, rgrpcpuratelimit FROM edb_resource_group;
rgrpname | rgrpcpuratelimit
----------+------------------
resgrp_a | 0.5
resgrp_b | 0.4
resgrp_c | 0.3
(3 rows)
リソースグループのcpu_rate_limit変更すると、そのグループに割り当てられている新しいプロセスに影響するだけでなく、そのグループのメンバーである現在実行中のプロセスは、変更の影響を直ちに受けます。つまり、 cpu_rate_limitが.5から.3に変更された場合、グループ内の現在実行中のプロセスは、グループ全体のCPU使用率が50%ではなく30%近くになるように、下向きに抑制されます。
リソースグループのCPUレート制限を設定する効果を説明するために、次の例では、 SELECT 20000!; クエリによって実行される20000階乗(20000 * 19999 * 19998などの乗算)のCPU集約的な計算を使用しています SELECT 20000!; psqlコマンドラインユーティリティで実行します。
これらの例では、前のクエリで示されているCPUレート制限設定のリソースグループが使用されています。
5.2.2 例 - 単一グループ内の単一プロセス
以下は、現在のプロセスがリソース・グループ resgrp_b を使用するように設定されていることを示しています。階乗計算が開始されます。
edb=# SET edb_resource_group TO resgrp_b;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
resgrp_b
(1 row)
edb=# SELECT 20000!;
2番目のセッションでは、Linux topコマンドを使用して%CPU列の下に示すようにCPU使用率を表示します。以下は、 topコマンドの出力が定期的に変化するときの任意の時点でのスナップショットです。
$ top
top - 16:37:03 up 4:15, 7 users, load average: 0.49, 0.20, 0.38
Tasks: 202 total, 1 running, 201 sleeping, 0 stopped, 0 zombie
Cpu(s): 42.7%us, 2.3%sy, 0.0%ni, 55.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0
Mem: 1025624k total, 791160k used, 234464k free, 23400k buffers
Swap: 103420k total, 13404k used, 90016k free, 373504k cached
 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28915 enterpri 20 0 195m 5900 4212 S 39.9 0.6 3:36.98 edb-postgres
1033 root 20 0 171m 77m 2960 S 1.0 7.8 3:43.96 Xorg
3040 user 20 0 278m 22m 14m S 1.0 2.2 3:41.72 knotify4
.
.
.
psql階乗演算を行うセッションは、行によって示されているedb-postgres下に表示されるCOMMANDカラム。 %CPU列の下に表示されるセッションのCPU使用率は39.9です。これはリソースグループresgrp_b設定されている40%CPU制限に近い値resgrp_b
対照的に、 psqlセッションがリソースグループから削除され、階乗計算が再度実行されると、CPU使用率がはるかに高くなります。
edb=# SET edb_resource_group TO DEFAULT;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
(1 row)
 
edb=# SELECT 20000!;
edb-postgres %CPU列の下では 、CPU使用率は93.6になりました。これは、プロセスがリソースグループの一部であったときの39.9よりも大幅に高くなっています。
$ top
top - 16:43:03 up 4:21, 7 users, load average: 0.66, 0.33, 0.37
Tasks: 202 total, 5 running, 197 sleeping, 0 stopped, 0 zombie
Cpu(s): 96.7%us, 3.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0
Mem: 1025624k total, 791228k used, 234396k free, 23560k buffers
Swap: 103420k total, 13404k used, 90016k free, 373508k cached
 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28915 enterpri 20 0 195m 5900 4212 R 93.6 0.6 5:01.56 edb-postgres
1033 root 20 0 171m 77m 2960 S 1.0 7.8 3:48.15 Xorg
2907 user 20 0 98.7m 11m 9100 S 0.3 1.2 0:46.51 vmware-user-lo
.
.
.
5.2.3 例 - 単一グループ内の複数のプロセス
前述のように、CPUレート制限は、リソースグループ内のすべてのプロセスの集約に適用されます。この概念を次の例に示します。
階乗の計算は、2つの別々に同時に行われる psqlグループリソースに追加された各々がセッション、 resgrp_bcpu_rate_limit 0.4(40%のCPU使用率)に設定します。
セッション1:
edb=# SET edb_resource_group TO resgrp_b;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
resgrp_b
(1 row)
 
edb=# SELECT 20000!;
セッション2:
edb=# SET edb_resource_group TO resgrp_b;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
resgrp_b
(1 row)
 
edb=# SELECT 20000!;
3番目のセッションは、CPU使用率を監視します。
$ top
top - 16:53:03 up 4:31, 7 users, load average: 0.31, 0.19, 0.27
Tasks: 202 total, 1 running, 201 sleeping, 0 stopped, 0 zombie
Cpu(s): 41.2%us, 3.0%sy, 0.0%ni, 55.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0
Mem: 1025624k total, 792020k used, 233604k free, 23844k buffers
Swap: 103420k total, 13404k used, 90016k free, 373508k cached
 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29857 enterpri 20 0 195m 4708 3312 S 19.9 0.5 0:57.35 edb-postgres
28915 enterpri 20 0 195m 5900 4212 S 19.6 0.6 5:35.49 edb-postgres
3040 user 20 0 278m 22m 14m S 1.0 2.2 3:54.99 knotify4
1033 root 20 0 171m 78m 2960 S 0.3 7.8 3:55.71 Xorg
.
.
.
%CPU値が19.9と19.6のedb-postgres という2つのプロセスがあり 、その合計はリソースグループresgrp_b設定されたCPU使用率の40%に近くなっています。
次のコマンドシーケンスは、半分の時間間隔でサンプリングされたすべての edb-postgresプロセスの合計を表示します。これは、EDB Resource Managerがプロセスを抑制して、リソースグループ全体のCPU使用率を40%近くに抑えるように、リソースグループ内のプロセスのCPU使用率がどのように変化するかを示しています。
$ while [[ 1 -eq 1 ]]; do top -d0.5 -b -n2 | grep edb-postgres | awk '{ SUM += $9} END { print SUM / 2 }'; done
37.2
39.1
38.9
38.3
44.7
39.2
42.5
39.1
39.2
39.2
41
42.85
46.1
.
.
.
5.2.4 例 - 複数のグループの複数のプロセス
この例では、2つの追加の psqlセッションが前の2つのセッションとともに使用されています。 3番目と4番目のセッションでは、リソースグループresgrp_c内でcpu_rate_limit.3 (CPU使用率が30%)という同じ階乗計算が実行されます。
セッション3:
edb=# SET edb_resource_group TO resgrp_c;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
resgrp_c
(1 row)
 
edb=# SELECT 20000!;
セッション4:
edb=# SET edb_resource_group TO resgrp_c;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
resgrp_c
(1 row)
 
edb=# SELECT 20000!;
topコマンドは次の出力が表示されます。
$ top
top - 17:45:09 up 5:23, 8 users, load average: 0.47, 0.17, 0.26
Tasks: 203 total, 4 running, 199 sleeping, 0 stopped, 0 zombie
Cpu(s): 70.2%us, 0.0%sy, 0.0%ni, 29.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0
Mem: 1025624k total, 806140k used, 219484k free, 25296k buffers
Swap: 103420k total, 13404k used, 90016k free, 374092k cached
 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29857 enterpri 20 0 195m 4820 3324 S 19.9 0.5 4:25.02 edb-postgres
28915 enterpri 20 0 195m 5900 4212 R 19.6 0.6 9:07.50 edb-postgres
29023 enterpri 20 0 195m 4744 3248 R 16.3 0.5 4:01.73 edb-postgres
11019 enterpri 20 0 195m 4120 2764 R 15.3 0.4 0:04.92 edb-postgres
2907 user 20 0 98.7m 12m 9112 S 1.3 1.2 0:56.54 vmware-user-lo
3040 user 20 0 278m 22m 14m S 1.3 2.2 4:38.73 knotify4
使用されている2つのリソースグループのCPU使用率は、40%と30%です。最初の2つのedb-postgresプロセス %CPUの合計は39.5(約40%、 resgrp_bの制限)、3番目と4番目のedb-postgresプロセスの%CPU列の合計は31.6(約30%、これはresgrp_cの制限です)。
これらのプロセスが属する2つのリソースグループのCPU使用制限の合計は70%です。次の出力は、4つのプロセスの合計が約70%に接していることを示しています。
$ while [[ 1 -eq 1 ]]; do top -d0.5 -b -n2 | grep edb-postgres | awk '{ SUM += $9} END { print SUM / 2 }'; done
61.8
76.4
72.6
69.55
64.55
79.95
68.55
71.25
74.85
62
74.85
76.9
72.4
65.9
74.9
68.25
対照的に、3つのセッションが処理中で、2つのセッションが resgrp_b残っているが、3つ目のセッションがどのリソースグループにも属していない場合、 topコマンドは次の出力を示します。
$ top
top - 17:24:55 up 5:03, 7 users, load average: 1.00, 0.41, 0.38
Tasks: 199 total, 3 running, 196 sleeping, 0 stopped, 0 zombie
Cpu(s): 99.7%us, 0.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0
Mem: 1025624k total, 797692k used, 227932k free, 24724k buffers
Swap: 103420k total, 13404k used, 90016k free, 374068k cached
 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29023 enterpri 20 0 195m 4744 3248 R 58.6 0.5 2:53.75 edb-postgres
28915 enterpri 20 0 195m 5900 4212 S 18.9 0.6 7:58.45 edb-postgres
29857 enterpri 20 0 195m 4820 3324 S 18.9 0.5 3:14.85 edb-postgres
1033 root 20 0 174m 81m 2960 S 1.7 8.2 4:26.50 Xorg
3040 user 20 0 278m 22m 14m S 1.0 2.2 4:21.20 knotify4
CPU使用率が40%に制限されているリソースグループに属している2番目と3番目の edb-postgresプロセスの総CPU使用量は37.8です。しかし、最初のedb-postgresプロセスは、リソースグループ内にないため、58.6%のCPU使用率を持ち、基本的に残りの使用可能なCPUリソースをシステム上で利用します。
同様に、次の出力では、3つのセッションの合計が、セッションの1つにCPU使用率に制限がないため、約95%です。
$ while [[ 1 -eq 1 ]]; do top -d0.5 -b -n2 | grep edb-postgres | awk '{ SUM += $9} END { print SUM / 2 }'; done
96
90.35
92.55
96.4
94.1
90.7
95.7
95.45
93.65
87.95
96.75
94.25
95.45
97.35
92.9
96.05
96.25
94.95
.
.
.
 
5.3 ダーティバッファースロットル
共有バッファへの書き込みは、 dirty_rate_limitリソースタイプパラメータを設定することによって制御されます。
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キロバイト/秒に維持されます。
edb=# ALTER RESOURCE GROUP resgrp_a SET dirty_rate_limit TO 12288;
ALTER RESOURCE GROUP
edb=# ALTER RESOURCE GROUP resgrp_b SET dirty_rate_limit TO 6144;
ALTER RESOURCE GROUP
edb=# ALTER RESOURCE GROUP resgrp_c SET dirty_rate_limit TO 3072;
ALTER RESOURCE GROUP
次のクエリは 、カタログ内 dirty_rate_limit の設定を示しています
edb=# SELECT rgrpname, rgrpdirtyratelimit FROM edb_resource_group;
rgrpname | rgrpdirtyratelimit
----------+--------------------
resgrp_a | 12288
resgrp_b | 6144
resgrp_c | 3072
(3 rows)
リソースグループのdirty_rate_limit変更すると、そのグループに割り当てられている新しいプロセスに影響するだけでなく、そのグループのメンバーである現在実行中のプロセスは、変更の影響を直ちに受けます。つまり、 dirty_rate_limitが12288から3072に変更された場合、グループ内で現在実行されているプロセスは、グループ全体のダーティレートが1秒当たり12288キロバイトではなく、1秒あたり3072キロバイトになるように、
リソースグループのダーティレート制限を設定する効果を説明するために、次の例では集中I / O操作に次の表を使用しています。
CREATE TABLE t1 (c1 INTEGER, c2 CHARACTER(500)) WITH (FILLFACTOR = 10);
FILLFACTOR = 10で句の結果INSERTコマンドは、1ページあたり10%まで行を梱包します。これは、これらの例の目的のために、ダーティな共有ブロックのより大きなサンプリングをもたらす。
pg_stat_statementsモジュールは、SQLコマンドとコマンドの実行にかかった時間の量によって汚される共有バッファブロックの数を表示するために使用されます。これは、SQLコマンドの実際のキロバイト/秒の書き込み速度を計算するための情報を提供し、それをリソースグループに設定されたダーティレート制限と比較します。
pg_stat_statementsモジュールを使用するには 、次の手順を実行します。
ステップ1: postgresql.confファイルで、 $libdir/pg_stat_statementsshared_preload_libraries設定パラメータに次のように追加します。
shared_preload_libraries = '$libdir/dbms_pipe,$libdir/edb_gen,$libdir/pg_stat_statements'
手順2:データベースサーバーを再起動します。
ステップ3: CREATE EXTENSIONコマンドを使用して、 pg_stat_statementsモジュールの作成を完了します。
edb=# CREATE EXTENSION pg_stat_statements SCHEMA public;
CREATE EXTENSION
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のブロックをダーティにします。
edb=# CREATE TABLE t1 (c1 INTEGER, c2 CHARACTER(500)) WITH (FILLFACTOR = 10);
CREATE TABLE
edb=# SET edb_resource_group TO resgrp_b;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
resgrp_b
(1 row)
 
edb=# SELECT pg_stat_statements_reset();
pg_stat_statements_reset
--------------------------
(1 row)
 
edb=# INSERT INTO t1 VALUES (generate_series (1,10000), 'aaa');
INSERT 0 10000
INSERTコマンドの結果を次に示します
edb=# SELECT query, rows, total_time, shared_blks_dirtied FROM pg_stat_statements;
-[ RECORD 1 ]-------+--------------------------------------------------
query | INSERT INTO t1 VALUES (generate_series (?,?), ?);
rows | 10000
total_time | 13496.184
shared_blks_dirtied | 10003
実際の汚れ率は次のように計算されます。
1ミリ秒(ms) あたりのダーティブロック数 は10003ブロック/ 13496.184ミリ秒で、 ミリ秒あたり0.74117247ブロックになります
結果に1000を掛けて、1秒 あたりのダーティー (1秒= 1000ミリ秒)された共有ブロックの数を 求めます.1秒あたり741.17247ブロックになります。
実際のダーティ・レートは毎秒6072キロバイトで、リソース・グループのダーティ・レート制限(6144キロバイト/秒)に近いことに注意してください。
対照的に、任意のリソースグループに属するプロセスなしでステップが再度繰り返されると、ダーティバッファー速度ははるかに高くなります。
edb=# CREATE TABLE t1 (c1 INTEGER, c2 CHARACTER(500)) WITH (FILLFACTOR = 10);
CREATE TABLE
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
(1 row)
 
edb=# SELECT pg_stat_statements_reset();
pg_stat_statements_reset
--------------------------
(1 row)
 
edb=# INSERT INTO t1 VALUES (generate_series (1,10000), 'aaa');
INSERT 0 10000
次に 、リソースグループを使用しないINSERTコマンドの結果を示します
edb=# SELECT query, rows, total_time, shared_blks_dirtied FROM pg_stat_statements;
-[ RECORD 1 ]-------+--------------------------------------------------
query | INSERT INTO t1 VALUES (generate_series (?,?), ?);
rows | 10000
total_time | 2432.165
shared_blks_dirtied | 10003
第1に、合計時間は、ダーティー・レート制限が6144キロバイト/秒に設定されたリソース・グループが使用された場合の13496.184ミリ秒と比較して、わずか2432.165ミリ秒であったことに注意してください。
リソースグループを使用しない実際のダーティレートは、次のように計算されます。
1ミリ秒(ms) あたりのダーティブロック数 は10003ブロック/ 2432.165ミリ秒で、 ミリ秒あたり4.112797ブロックになります
結果に1000を掛けて、1秒 あたりのダーティー (1秒= 1000ミリ秒)された共有ブロックの数を 求めます.1秒あたり4112.797ブロックになります。
結果に8.192を掛けて、 1秒あたりのダーティー・バイト数 (1ブロック= 8.192キロバイト)を 求めますこれは、 1秒あたり 33692キロバイトになります
1秒あたり33692キロバイトの実際のダーティ・レートは、1秒当たり6144キロバイトのダーティ・レート制限を持つリソース・グループが使用された場合よりもかなり高いことに注意してください。
5.3.3 例 - 単一グループ内の複数のプロセス
前述のように、ダーティ・レート制限は、リソース・グループ内のすべてのプロセスの集約に適用されます。この概念を次の例に示します。
この例では、挿入は2つの別々の psqlセッションで2つの異なるテーブルで同時に実行され 、各セッションはresgrp_bが1秒あたり6144キロバイトに設定されたdirty_rate_limitリソースグループに追加されています。
セッション1:
edb=# CREATE TABLE t1 (c1 INTEGER, c2 CHARACTER(500)) WITH (FILLFACTOR = 10);
CREATE TABLE
edb=# SET edb_resource_group TO resgrp_b;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
resgrp_b
(1 row)
 
edb=# INSERT INTO t1 VALUES (generate_series (1,10000), 'aaa');
INSERT 0 10000
セッション2:
edb=# CREATE TABLE t2 (c1 INTEGER, c2 CHARACTER(500)) WITH (FILLFACTOR = 10);
CREATE TABLE
edb=# SET edb_resource_group TO resgrp_b;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
resgrp_b
(1 row)
 
edb=# SELECT pg_stat_statements_reset();
pg_stat_statements_reset
--------------------------
(1 row)
 
edb=# INSERT INTO t2 VALUES (generate_series (1,10000), 'aaa');
INSERT 0 10000
注意:セッション1とセッション2のINSERTコマンドは、セッション2のSELECT pg_stat_statements_reset()コマンドの実行後に開始されました。
以下は、 2つのセッションにおけるINSERTコマンドの結果を示しています。 RECORD 3はセッション1の結果を示しますRECORD 2はセッション2の結果を示します。
edb=# SELECT query, rows, total_time, shared_blks_dirtied FROM pg_stat_statements;
-[ RECORD 1 ]-------+--------------------------------------------------
query | SELECT pg_stat_statements_reset();
rows | 1
total_time | 0.43
shared_blks_dirtied | 0
-[ RECORD 2 ]-------+--------------------------------------------------
query | INSERT INTO t2 VALUES (generate_series (?,?), ?);
rows | 10000
total_time | 30591.551
shared_blks_dirtied | 10003
-[ RECORD 3 ]-------+--------------------------------------------------
query | INSERT INTO t1 VALUES (generate_series (?,?), ?);
rows | 10000
total_time | 33215.334
shared_blks_dirtied | 10003
まず、セッション1の合計時間は33215.334ミリ秒であり、セッション2の場合は30591.551ミリ秒であったことに注意してください。最初の例で示されているのと同じリソースグループで1つのセッションのみがアクティブだった場合、時間は13496.184ミリ秒でした。したがって、リソースグループ内のアクティブなプロセスが多いほど、グループ内の各アクティブなプロセスのダーティレートが遅くなります。これを以下の計算に示します。
セッション1の実際のダーティレートは、次のように計算されます。
1ミリ秒(ms) あたりのダーティブロック数 は10003ブロック/33215.334ミリ秒で、 ミリ秒あたり0.30115609ブロックになります
結果に1000を掛けて、1秒 あたりのダーティー・ダーティー・ブロック数 (1秒= 1000ミリ秒)を 求めますこれにより、 301.15609ブロック/秒 が得 られます
セッション2の実際のダーティレートは、次のように計算されます。
1ミリ秒(ms) あたりのダーティブロック数 は10003ブロック/ 30591.551ミリ秒で、 ミリ秒あたり0.32698571ブロックになります
結果に1000を掛けて、1秒間に ダーティー される共有ブロックの数(1秒= 1000ミリ秒)を 求めますこれにより、 1秒あたり326.98571ブロックになります。
結果に8.192を掛けて、 1秒あたりのダストキロバイト数 (1ブロック= 8.192キロバイト)を 求めますこれは約 2679キロバイト/秒になります。
セッション1(2467キロバイト/秒)とセッション2(2679キロバイト/秒)の合計ダーティ・レートは5146キロバイト/秒で、リソース・グループの設定されたダーティ・レート制限(6144キロバイト/秒)を下回ります。
5.3.4 例 - 複数のグループの複数のプロセス
この例では、2つの追加の psqlセッションが前の2つのセッションとともに使用されています。第三及び第四のセッションは、同じ実行INSERTリソースグループ内のコマンドresgrp_c有するdirty_rate_limit毎秒3072キロバイトの。
リソースグループ resgrp_b を使用して、前の例に示すように、セッション1と2が繰り返されます。 dirty_rate_limitは1秒あたり6144キロバイトです。
セッション3:
edb=# CREATE TABLE t3 (c1 INTEGER, c2 CHARACTER(500)) WITH (FILLFACTOR = 10);
CREATE TABLE
edb=# SET edb_resource_group TO resgrp_c;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
 
resgrp_c
(1 row)
 
edb=# INSERT INTO t3 VALUES (generate_series (1,10000), 'aaa');
INSERT 0 10000
セッション4:
edb=# CREATE TABLE t4 (c1 INTEGER, c2 CHARACTER(500)) WITH (FILLFACTOR = 10);
CREATE TABLE
edb=# SET edb_resource_group TO resgrp_c;
SET
edb=# SHOW edb_resource_group;
edb_resource_group
--------------------
resgrp_c
(1 row)
 
edb=# SELECT pg_stat_statements_reset();
pg_stat_statements_reset
--------------------------
(1 row)
 
edb=# INSERT INTO t4 VALUES (generate_series (1,10000), 'aaa');
INSERT 0 10000
注意: 4つのセッションすべてのINSERTコマンドは、セッション4のSELECT pg_stat_statements_reset()コマンドの実行後に開始されました。
以下は、 4つのセッションにおけるINSERTコマンドの結果を示しています。 RECORD 3はセッション1の結果を示していますRECORD 2はセッション2の結果を示していますRECORD 4はセッション3の結果を示していますRECORD 5はセッション4の結果を示しています。
edb=# SELECT query, rows, total_time, shared_blks_dirtied FROM pg_stat_statements;
-[ RECORD 1 ]-------+--------------------------------------------------
query | SELECT pg_stat_statements_reset();
rows | 1
total_time | 0.467
shared_blks_dirtied | 0
-[ RECORD 2 ]-------+--------------------------------------------------
query | INSERT INTO t2 VALUES (generate_series (?,?), ?);
rows | 10000
total_time | 31343.458
shared_blks_dirtied | 10003
-[ RECORD 3 ]-------+--------------------------------------------------
query | INSERT INTO t1 VALUES (generate_series (?,?), ?);
rows | 10000
total_time | 28407.435
shared_blks_dirtied | 10003
-[ RECORD 4 ]-------+--------------------------------------------------
query | INSERT INTO t3 VALUES (generate_series (?,?), ?);
rows | 10000
total_time | 52727.846
shared_blks_dirtied | 10003
-[ RECORD 5 ]-------+--------------------------------------------------
query | INSERT INTO t4 VALUES (generate_series (?,?), ?);
rows | 10000
total_time | 56063.697
shared_blks_dirtied | 10003
セッション1(28407.435)とセッション2(31343.458)の時間は、セッション3(52727.846)の時間とセッションに比べて、 両方が同じリソースグループにあり、 dirty_rate_limit6144に設定されているため、互いに近いことに注意してください 4(56063.697)、これはリソースグループ内にあり、 dirty_rate_limit設定されています。後者のグループのダーティレートの制限が遅いため、セッション3および4の場合と同様に予想される処理時間が長くなります。
セッション1の実際のダーティレートは、次のように計算されます。
1ミリ秒当たりのダーティブロック数 (ms)は10003ブロック/ 28407.435ミリ秒であり、 ミリ秒あたり0.35212612ブロックになります
結果に1000を掛けて、1秒間に ダーティー される共有ブロックの数(1秒= 1000ミリ秒)を 求めます.1秒あたり352.12612ブロックになります。
セッション2の実際のダーティレートは、次のように計算されます。
1ミリ秒(ms) 当たりのダーティブロック数 は10003ブロック/ 31343.458ミリ秒で、 ミリ秒あたり0.31914156ブロックになります
結果に1000を掛けて、1秒 あたりのダーティー・ダーティー・ブロック数 (1秒= 1000ミリ秒)を 求めます.1秒あたり319.14156ブロックになります。
セッション1(2885キロバイト/秒)とセッション2(2614キロバイト/秒)との合計ダーティ・レートは5499キロバイト/秒で、リソース・グループの設定されたダーティ・レート制限(6144キロバイト/秒)に近くなります。
セッション3の実際のダーティレートは、次のように計算されます。
1ミリ秒(ms) あたりのダーティブロック数 は10003ブロック/ 52727.846ミリ秒であり、 ミリ秒当たり0.18971001ブロックになります
結果に1000を掛けて、1秒 あたりのダーティー・ダーティー・ブロック数 (1秒= 1000ミリ秒)を 求めます.1秒あたり189.71001ブロックになります。
セッション4の実際のダーティレートは、次のように計算されます。
1ミリ秒(ms) 当たりのダーティブロック数 は10003ブロック/ 56063.697ミリ秒で、 ミリ秒当たり0.17842205ブロックになります
結果に1000を掛けて、1秒 あたりのダーティー (1秒= 1000ミリ秒)する共有ブロックの数を 求めます.1秒あたり178.42205ブロックになります。
セッション3(1554キロバイト/秒)とセッション4(1462キロバイト/秒)との合計ダーティ・レートは、リソース・グループの設定されたダーティ・レート制限(3072キロバイト/秒)に近い3016キロバイト/秒になります。
したがって、これは、EDBリソースマネージャが、各グループに対して設定されたダーティレート制限に近いグループ内のアクティブプロセスの集約ダーティレートをどのように維持するかを示しています。
 
5.4 システムカタログ
この項では、EDB Resource Managerで使用されるリソース・グループ情報を格納するシステム・カタログについて説明します。
5.4.1 edb_all_resource_groups
次の表に、 edb_all_resource_groupsカタログで使用可能な情報を示します
5.4.2 edb_resource_group
次の表に、 edb_resource_groupカタログで使用可能な情報を示します
6 libpq Cライブラリ
libpqは、CアプリケーションプログラマーのAdvanced Serverへのインターフェースです。 libpqは、クライアントプログラムがアドバンストサーバにクエリを渡し、これらのクエリの結果を受け取るためのライブラリ関数のセットです。
libpqは、C ++、Perl、Python、Tcl、ECPG用に書かれたものも含め、いくつかの他のEnterpriseDBアプリケーション・インターフェースの基盤となるエンジンです。したがって、libpqの動作のいくつかの側面は、それらのパッケージの1つが使用されている場合、ユーザにとって重要になります。
libpqを使用するクライアントプログラムには、ヘッダファイル libpq-fe.hていなければならず、 libpqライブラリにリンクする必要があります。
6.1 EnterpriseDB SPLでのlibpqの使用
EnterpriseDB SPL言語は、libpqインタフェースライブラリで使用することができ、以下をサポートします。
structsと型typedefs
IN/OUT/IN OUTパラメータ
6.2 REFCURSORのサポート
以前のリリースでは、Advanced Server は以下のlibpq関数 REFCURSORs して REFCURSORs サポートし ていました。これらの関数は廃止予定とみなされるべきです:
SPL(またはPL / pgSQL)関数によって返され REFCURSOR を取得するために、 PQexec() および PQgetvalue() 使用することができ ます。 REFCURSOR カーソルの名前を示すヌル終了文字列の形式で返されます。カーソルの名前 を取得すると、 1つまたは複数の FETCH 文を 実行 して、カーソルで公開される値を取得 でき ます。
以下のサンプルには、実際のクライアントアプリケーションで必要となるエラー処理コードは含まれていないことに注意してください。
単一のREFCURSORを返す
次の例は、 REFCURSOR 型の値を返すSPL関数を示しています
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 という名前 )に 格納します 。この関数は、カーソルの名前を呼び出し元に返します。
libpqを使用してCクライアントからこの関数を呼び出すには、 PQexec() PQgetvalue() 使用します
#include <stdio.h>
#include <stdlib.h>
#include "libpq-fe.h"

static void fetchAllRows(PGconn *conn,
const char *cursorName,
const char *description);
static void fail(PGconn *conn, const char *msg);

int
main(int argc, char *argv[])
{
PGconn *conn = PQconnectdb(argv[1]);
PGresult *result;

if (PQstatus(conn) != CONNECTION_OK)
fail(conn, PQerrorMessage(conn));

result = PQexec(conn, "BEGIN TRANSACTION");

if (PQresultStatus(result) != PGRES_COMMAND_OK)
fail(conn, PQerrorMessage(conn));

PQclear(result);

result = PQexec(conn, "SELECT * FROM getEmployees(10)");

if (PQresultStatus(result) != PGRES_TUPLES_OK)
fail(conn, PQerrorMessage(conn));

fetchAllRows(conn, PQgetvalue(result, 0, 0), "employees");

PQclear(result);

PQexec(conn, "COMMIT");

PQfinish(conn);

exit(0);
}

static void
fetchAllRows(PGconn *conn,
const char *cursorName,
const char *description)
{
size_t
commandLength = strlen("FETCH ALL FROM ") +
strlen(cursorName) + 3;
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);
}
コードサンプルには、 getEmployees() 関数 を呼び出し、 部門 10 すべての従業員を含む結果セットを返す コード行が 含まれています
result = PQexec(conn, "SELECT * FROM getEmployees(10)");
PQexec() 関数は、Cプログラムにハンドルを結果セットを返します。結果セットにはちょうど1つの値が含まれます。その値は、 getEmployees() によって返されるカーソルの名前です
カーソルの名前 を取得 すると、SQL FETCH ステートメントを使用してそのカーソル内の行を取り出す ことができ ます。関数 fetchAllRows() FETCH 構築し fetchAllRows() ALL 文を実行し、その文を実行した後、 FETCH 結果セットを出力します ALL ステートメント。
このプログラムの出力を以下に示します。
-- employees --
7782,CLARK,MANAGER,7839,09-JUN-81 00:00:00,2450.00,,10
7839,KING,PRESIDENT,,17-NOV-81 00:00:00,5000.00,,10
7934,MILLER,CLERK,7782,23-JAN-82 00:00:00,1300.00,,10
複数のREFCURSORの返却
次の例は、2つの REFCURSORs 返します
最初の REFCURSOR には 、呼び出し元が指定した範囲内の部門で働くすべての従業員を含む カーソル( employees の名前が​​含まれています
2番目の REFCURSOR には 、呼び出し元によって指定された範囲内のすべての departments を含む カーソル( departments の名前が​​含まれます
この例では、単一の REFCURSOR を返す代わりに 、この関数は SETOF REFCURSOR 0 以上の REFCURSORS を意味し 0 )。もう1つの重要な相違点は、libpqプログラムが 結果セット内の 単一の REFCURSOR 期待するべきではなく 、それぞれが単一の値を含む2つの行を期待すべきです(最初の行には employees カーソルの 名前が含まれ、 departments カーソルの 名前が入ってい ます)。
CREATE OR REPLACE FUNCTION getEmpsAndDepts(p_min NUMERIC,
p_max NUMERIC)
RETURN SETOF REFCURSOR AS
employees REFCURSOR;
departments REFCURSOR;
BEGIN
OPEN employees FOR
SELECT * FROM emp WHERE deptno BETWEEN p_min AND p_max;
RETURN NEXT employees;

OPEN departments FOR
SELECT * FROM dept WHERE deptno BETWEEN p_min AND p_max;
RETURN NEXT departments;
END;
前の例のように、 PQexec()およびPQgetvalue()使用してSPL関数を呼び出すことができます
#include <stdio.h>
#include <stdlib.h>
#include "libpq-fe.h"

static void fetchAllRows(PGconn *conn,
const char *cursorName,
const char *description);
static void fail(PGconn *conn, const char *msg);

int
main(int argc, char *argv[])
{
PGconn *conn = PQconnectdb(argv[1]);
PGresult *result;

if (PQstatus(conn) != CONNECTION_OK)
fail(conn, PQerrorMessage(conn));

result = PQexec(conn, "BEGIN TRANSACTION");

if (PQresultStatus(result) != PGRES_COMMAND_OK)
fail(conn, PQerrorMessage(conn));

PQclear(result);

result = PQexec(conn, "SELECT * FROM getEmpsAndDepts(20, 30)");

if (PQresultStatus(result) != PGRES_TUPLES_OK)
fail(conn, PQerrorMessage(conn));

fetchAllRows(conn, PQgetvalue(result, 0, 0), "employees");
fetchAllRows(conn, PQgetvalue(result, 1, 0), "departments");

PQclear(result);

PQexec(conn, "COMMIT");

PQfinish(conn);

exit(0);
}

static void
fetchAllRows(PGconn *conn,
const char *cursorName,
const char *description)
{
size_t commandLength = strlen("FETCH ALL FROM ") +
strlen(cursorName) + 3;
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);
}
getEmpsAndDepts(20, 30) を呼び出すと、サーバーは部門20または30で働くすべての従業員を含むカーソルと、部門20および30説明を含む2番目のカーソルを返します。
-- employees --
7369,SMITH,CLERK,7902,17-DEC-80 00:00:00,800.00,,20
7499,ALLEN,SALESMAN,7698,20-FEB-81 00:00:00,1600.00,300.00,30
7521,WARD,SALESMAN,7698,22-FEB-81 00:00:00,1250.00,500.00,30
7566,JONES,MANAGER,7839,02-APR-81 00:00:00,2975.00,,20
7654,MARTIN,SALESMAN,7698,28-SEP-81 00:00:00,1250.00,1400.00,30
7698,BLAKE,MANAGER,7839,01-MAY-81 00:00:00,2850.00,,30
7788,SCOTT,ANALYST,7566,19-APR-87 00:00:00,3000.00,,20
7844,TURNER,SALESMAN,7698,08-SEP-81 00:00:00,1500.00,0.00,30
7876,ADAMS,CLERK,7788,23-MAY-87 00:00:00,1100.00,,20
7900,JAMES,CLERK,7698,03-DEC-81 00:00:00,950.00,,30
7902,FORD,ANALYST,7566,03-DEC-81 00:00:00,3000.00,,20
-- departments --
20,RESEARCH,DALLAS
30,SALES,CHICAGO
6.3 配列バインディング
Advanced Serverのアレイバインディング機能を使用すると、1回のラウンドトリップでネットワーク上のデータアレイを送信できます。バックエンドがバルクデータを受信すると、データを使用して挿入操作または更新操作を実行できます。
準備されたステートメントでバルク操作を実行します。次の関数を使用して文を準備します。
PGresult *PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid *paramTypes);
PQprepare() 詳細は PQprepare() statementセクションにあります。
バルク操作を実行するには、次の機能を使用できます。
PQBulkStart6.3.1項を参照)
PQexecBulk (セクション6.3.2を参照)
PQBulkFinish6.3.3項を参照)
PQexecBulkPrepared6.3.4項を参照)
6.3.1 PQBulkStart
PQBulkStart()は、サーバー上のバルク操作を初期化します。バルクデータをサーバーに送信する前に、この関数を呼び出す必要があります。 PQBulkStart()で指定された準備された文初期化stmtNameによって指定された形式でデータを受信するparamFmts
API定義
PGresult * PQBulkStart(PGconn *conn,
const char * Stmt_Name,
unsigned int nCol,
const int *paramFmts);
6.3.2 PQexecBulk
PQexecBulk()データ(供給するために使用されるparamValues使用して、以前に一括操作のために初期化された文に対して) PQBulkStart()
この関数は 、複数のデータブロックを送信するためにPQBulkStart() 後に複数回使用することができます。詳細については、例を参照してください。
API定義
PGresult *PQexecBulk(PGconn *conn,
unsigned int nRows,
const char *const * paramValues,
const int *paramLengths);
6.3.3 PQBulkFinish
この関数は、現在の一括操作を完了します。準備済みのステートメントは、再準備することなく、再度使用することができます。
API定義
PGresult *PQBulkFinish(PGconn *conn);
6.3.4 PQexecBulkPrepared
また、 PQexecBulkPrepared()関数は、単一の関数呼び出しで一括操作を実行します。 PQexecBulkPrepared()は、指定されたパラメータでプリペアドステートメントを実行する要求を送信し、結果を待ちます。この関数は、 PQbulkStart()PQexecBulk() 、およびPQBulkFinish()機能を組み合わせています。この機能を使用する場合、一括操作を初期化または終了する必要はありません。この関数は、バルク操作を開始し、そのデータをサーバーに渡し、バルク操作を終了します。
stmtName の代わりに事前に準備されたステートメントを指定します。繰り返し使用されるコマンドは、実行されるたびに解析されるのではなく、1回だけ解析および計画されます。
API定義
PGresult *PQexecBulkPrepared(PGconn *conn,
const char *stmtName,
unsigned int nCols,
unsigned int nRows,
const char *const *paramValues,
const int *paramLengths,
const int *paramFormats);
6.3.5 サンプルコード(PQBulkStart、PQexecBulk、PQBulkFinishを使用)
次の例では、 PGBulkStartPQexecBulk 、およびPQBulkFinishます。
void InsertDataUsingBulkStyle( PGconn *conn )
{
PGresult *res;
Oid paramTypes[2];
char *paramVals[5][2];
int paramLens[5][2];
int paramFmts[2];
int i;
 
int a[5] = { 10, 20, 30, 40, 50 };
char b[5][10] = { "Test_1", "Test_2", "Test_3", "Test_4", "Test_5" };
 
 
paramTypes[0] = 23;
paramTypes[1] = 1043;
res = PQprepare( conn, "stmt_1", "INSERT INTO testtable1 values( $1, $2 )", 2, paramTypes );
PQclear( res );
 
paramFmts[0] = 1; /* Binary format */
paramFmts[1] = 0;
 
for( i = 0; i < 5; i++ )
{
a[i] = htonl( a[i] );
paramVals[i][0] = &(a[i]);
paramVals[i][1] = b[i];
 
paramLens[i][0] = 4;
paramLens[i][1] = strlen( b[i] );
}
 
res = PQBulkStart(conn, "stmt_1", 2, paramFmts);
PQclear( res );
printf( "< -- PQBulkStart -- >\n" );
 
res = PQexecBulk(conn, 5, (const char *const *)paramVals, (const int *)paramLens);
PQclear( res );
printf( "< -- PQexecBulk -- >\n" );
 
res = PQexecBulk(conn, 5, (const char *const *)paramVals, (const int *)paramLens);
PQclear( res );
printf( "< -- PQexecBulk -- >\n" );
 
res = PQBulkFinish(conn);
PQclear( res );
printf( "< -- PQBulkFinish -- >\n" );
}
6.3.6 サンプルコード(PQexecBulkPreparedを使用)
次の例では、 PQexecBulkPrepared 使用してい PQexecBulkPrepared
void InsertDataUsingBulkStyleCombinedVersion( PGconn *conn )
{
PGresult *res;
Oid paramTypes[2];
char *paramVals[5][2];
int paramLens[5][2];
int paramFmts[2];
int i;
 
int a[5] = { 10, 20, 30, 40, 50 };
char b[5][10] = { "Test_1", "Test_2", "Test_3", "Test_4", "Test_5" };
 
paramTypes[0] = 23;
paramTypes[1] = 1043;
res = PQprepare( conn, "stmt_2", "INSERT INTO testtable1 values( $1, $2 )", 2, paramTypes );
PQclear( res );
 
paramFmts[0] = 1; /* Binary format */
paramFmts[1] = 0;
 
for( i = 0; i < 5; i++ )
{
a[i] = htonl( a[i] );
paramVals[i][0] = &(a[i]);
paramVals[i][1] = b[i];
 
paramLens[i][0] = 4;
paramLens[i][1] = strlen( b[i] );
}
 
res = PQexecBulkPrepared(conn, "stmt_2", 2, 5, (const char *const *)paramVals,(const int *)paramLens, (const int *)paramFmts);
PQclear( res );
}
7 デバッガ
デバッガは、開発者とDBAがグラフィカルな動的環境を使用してサーバー側のプログラムをテストおよびデバッグする機能を提供するツールです。デバッグできるプログラムのタイプは、SPLのストアドプロシージャ、関数、トリガ、およびPL / pgSQLの関数とトリガです。
デバッガは pgAdmin 4 と統合され、 pgAdmin 4 から呼び出されます。 Linuxでは、 edb-as xx -server-pldebugger RPMパッケージ( xxはAdvanced Serverのバージョン番号)もインストールする必要があります。 pgAdmin 4の情報は次の場所から入手できます:
https://www.pgadmin.org/
デバッガを使用してプログラムをテストするには、2つの基本的な方法があります。
スタンドアロンデバッグ。デバッガは、テストするプログラムを起動するために使用されます。プログラムが必要とする入力パラメータ値を指定すると、プログラムのコードをただちに観察してステップ実行することができます。スタンドアロンデバッグは、新しいプログラムや初期の問題調査に使用される典型的な方法です。
インコンテキストデバッグ。テストするプログラムは、デバッガ以外のアプリケーションによって開始されます。まず、テストするプログラムにグローバルブレークポイントを設定します 。プログラムへの最初の呼び出しを行うアプリケーションは、グローバルブレークポイントを検出します。アプリケーションは実行を中断し、デバッガが呼び出されたプログラムを制御します。コールされたアプリケーションのコンテキスト内で実行されるので、呼び出されたプログラムのコードを観察し、ステップ実行することができます。デバッガで呼び出されるプログラムのコードを完全に踏んだら、中断したアプリケーションは実行を再開します。インコンテキストデバッグは、呼び出し元アプリケーションとの複雑な相互作用により、スタンドアロンデバッグを使用して問題を再現することが困難な場合に便利です。
スタンドアロンまたはコンテキスト内のデバッグを使用する場合でも、デバッグツールと操作は同じです。違いは、デバッグするプログラムがどのように呼び出されるかです。
以下のセクションでは、スタンドアロンデバッグ方法を使用したデバッガの機能について説明します。コンテキスト内デバッグのためのデバッガの起動方法は、 7.5.3 項で説明しています。
7.1 デバッガの設定
デバッガを使用する前に、 shared_preload_libraries構成パラメータにリストされているライブラリに$libdir/plugin_debuggerを追加して postgresql.confファイル(Advanced Serverホームディレクトリのdataサブディレクトリにあります)を$libdir/plugin_debuggerします。
shared_preload_libraries = '$libdir/dbms_pipe,$libdir/edb_gen,$libdir/plugin_debugger'
変更後 shared _ preload _ librariesのパラメータを、データベース・サーバーを再起動する必要があります。
7.2 デバッガの起動
スタンドアロンデバッグのためにデバッガにアクセスするには、pgAdmin 4を使用します。デバッガを開くには、pgAdmin 4 Browserパネルで、デバッグするストアドプロシージャまたはファンクションの名前を強調表示します 。次に、 ObjectメニューからDebuggingメニューまでナビゲートし、サブメニューからDebugを選択します。
図7.1 - オブジェクトメニューからのデバッガの起動
また、pgAdminで4でストアドプロシージャまたは関数の名前を右クリックすることができ Browser 、および選択Debugging 、およびDebugコンテキストメニューから。
図7.2 - オブジェクトのコンテキストメニューからデバッガを起動する
スタンドアロンデバッグを使用してトリガをデバッグすることはできません。トリガーは、コンテキスト内のデバッグを使用してデバッグする必要があります。コンテキスト内デバッグ用のグローバルブレークポイントの設定については、 7.5.3 項を参照してください
パッケージをデバッグするには、デバッグするパッケージのパッケージノードの下にある特定のプロシージャまたはファンクションを強調表示し、ストアドプロシージャおよびファンクションの場合と同じ指示に従います。
7.3 デバッガウィンドウ
Debuggerウィンドウを使用して、スタンドアロン時にパラメータ値を渡して、パラメータを必要とするプログラムをデバッグすることができます。デバッガを起動すると、 Debuggerウィンドウが自動的に開き、プログラムが期待するINまたはIN OUTパラメータが表示されます。プログラムがINまたはIN OUTパラメーターを宣言していない場合、 Debuggerウィンドウはオープンしません。
図7.3 - デバッガウィンドウ
[ Debuggerウィンドウの各フィールドを使用して、各パラメータの値を指定します。
[ Nameフィールドに仮パラメータ名が含まれます。
Typeフィールドには、パラメータのデータ型が含まれています。
Null? チェックし Null?パラメータがNULL値であることを示すチェックボックス。
Expression? 確認し Expression? Valueフィールドに式が含まれている場合はチェックボックスをオンにします。
Valueフィールドには、プログラムに渡すパラメーター値が入っています。
Use Default? チェックし Use Default?チェックボックスを使用して、プログラムがDefault Valueフィールドの値を使用する必要があることを示します。
Default Valueフィールドには、パラメータのデフォルト値が含まれています。
Tabキーを押してリスト内のデータ入力用の次のパラメータを選択するか、またはValueフィールドをクリックしてデータ入力用のパラメータを選択します。
初期化セクションを持つパッケージのメンバであるプロシージャまたはファンクションをデバッグする場合は、[ Debug Package Initializerチェックボックスをオンにして、デバッガがパッケージ初期化セクションに入るように指示し、デバッグ前に初期化セクションコードをデバッグできるようにしますプロシージャまたは関数このチェックボックスをオンにしないと、デバッガはパッケージの初期化セクションを実行します。実行されるとコードの個々の行を表示またはステップ実行することはできません。
目的のパラメータ値を入力し Debug 、[ Debug ]ボタンをクリックしてデバッグプロセスを開始します。 [ Cancel ]ボタンをクリックして、デバッガを終了します。
注意:コンテキスト内のデバッグ中は、[ Debuggerウィンドウは開きません。代わりに、デバッグするプログラムを呼び出すアプリケーションは、必要な入力パラメーター値を指定する必要があります。
プログラムコードをステップ実行して完全なデバッグサイクルを完了すると、 Debuggerウィンドウが再び開き、新しいパラメータ値を入力してデバッグサイクルを繰り返すか、デバッグセッションを終了できます。
7.4 メインデバッガウィンドウ
Main Debuggerウィンドウには2つのパネルがあります。
一番上の Program Bodyパネルにプログラムのソースコードが表示されます。
下部の[ Tabs ]パネルには、さまざまな情報のための一連のタブが用意されています。
トップパネルにあるTool Barアイコンを使用して、デバッグ機能にアクセスします。
図7.4 - メインデバッガウィンドウ
2つのパネルについては、次のセクションで説明します。
7.4.1 プログラム本体パネル
Program Bodyパネルがデバッグされているプログラムのソースコードが表示されます。
図7.5 - プログラム本体
図7.5は、デバッガが SELECTを実行しようとしていることを示しています。プログラム本体の青色のインジケータは、次に実行する文を強調表示します。
7.4.2 タブパネルは、
下部の Tabs を使用して、パラメータ値またはローカル変数を表示または変更したり、 RAISE INFOおよび関数結果によって生成されたメッセージを表示することができます。
パネルのタブに表示される情報は次のとおりです。
[ Parameters ]タブに現在のパラメータ値が表示されます。
[ Local variables ]タブには、プログラム内で宣言された変数の値が表示されます。
[ Messages ]タブには、プログラムの実行時に返される結果が表示されます。
Resultsタブには、関数のRETURNステートメントからの値などのプログラム結果(該当する場合)が表示されます。
Stackタブには、 7.4.3項で説明した機能があります。
次の図は、さまざまなタブの結果を示しています。
図7.6 - [パラメータ]タブ
図7.7 - [ローカル変数]タブ
図7.8 - [メッセージ]タブ
図7.9 - [結果]タブ
7.4.3 スタックタブ
[ Stack ]タブには、現在コールスタック上にあるプログラムのリスト(呼び出されたがまだ完了していないプログラム)のリストが表示されます。プログラムが呼び出されると、 Stackタブに表示されるリストの一番上にプログラムの名前が追加されます。 Wプログラムが終了鶏は、その名前がリストから削除されます。
Stackタブには、プログラム呼び出しに関する情報も表示されます。この情報には、
コールスタックを確認すると、一連のネストされたプログラムによって実行の経過を追跡するのに役立ちます。
図7.10 - サブプログラムを呼び出すデバッグされたプログラム
図7.10は、 emp_query_calleremp_queryという名前のサブプログラムを呼び出すことを示しています。 emp_query_callerは現在コールスタックの最上位にあります。
emp_query の呼び出しが実行されると、 Stackタブの上部にemp_queryが表示され、そのコードが図7.11に示すようにProgram Bodyパネルに表示されます。
図7.11 - 呼び出されたサブプログラムのデバッグ
サブプログラムの実行が完了すると、制御は呼び出しプログラム( emp _ query _ caller )に戻り 、図7.12に示すようにStackタブの上部に表示されます。
図7.12 - デバッグされたサブプログラムからのコントロールの戻り値
7.5 プログラムのデバッグ
プログラムをデバッグするには、次の操作を実行できます。
7.5.1 コードの実行
ツールバーのアイコンを使用して、デバッガでプログラムをステップ実行します。
図7.13 - ツールバーのアイコン
アイコンは次の目的で使用されます。
に入る。 Step intoアイコンをクリックして、現在強調表示されているコード行を実行します。
ステップオーバー。 Step overアイコンをクリックしてコード行を実行し、コードによって呼び出されたすべてのサブ関数をStep over実行します。サブファンクションは実行されますが、ブレークポイントが含まれていない限りデバッグは行われません。
続行/開始。強調表示されたコードを実行するには、 Continue/Startアイコンをクリックし、プログラムがブレークポイントに遭遇するか完了するまで続行します。
やめる。 Stopアイコンをクリックすると、プログラムの実行を停止します。
7.5.2 ブレークポイントの使用
デバッガはプログラムを実行すると、ブレークポイントに達するたびに一時停止します。デバッガが一時停止すると、ローカル変数を監視または変更したり、コールスタック内のエントリにナビゲートして変数を観察したり、その他のブレークポイントを設定することができます。次のステップは、ブレークポイントに続く次のコード行でデバッガに実行を再開させます。ブレークポイントには2種類あります。
ローカルブレークポイント - ローカルブレークポイントは、プログラム内の実行可能なコード行に設定できます。デバッガは、ローカルブレークポイントが設定されている行に到達すると、実行を一時停止します。
グローバルブレークポイント - すべての セッションがそのブレークポイントに達すると 、グローバルブレークポイントがトリガーさ れます。プログラムのコンテキスト内デバッグを実行する場合は、グローバルブレークポイントを設定します。グローバルブレークポイントがプログラムに設定されると、グローバルブレークポイントを設定するデバッグセッションは、そのプログラムが別のセッションで呼び出されるまで待機します。グローバルブレークポイントは、スーパーユーザーだけが設定できます。
ローカルブレークポイントを作成するには、ローカルブレークポイントを設定するコード行の左側にある灰色の影付きマージン内を左クリックします。クリックすると、灰色の影付き余白は、図7.14のソースコード行12にブレークポイントドットが表示されている場所のように、余白の右側に近づくはずです。
作成されると、デバッガはマージンに黒い点を表示し、選択されたコード行にブレークポイントが設定されていることを示します。
図7.14 - 左側の余白をクリックしてブレークポイントを設定する
必要なだけ多くのローカルブレークポイントを設定できます。ローカルブレークポイントは、デバッグセッションが終了するまで有効です。
ローカルブレークポイントの削除
ローカルブレークポイントを削除するには、 Program Bodyパネルの灰色で塗りつぶされた余白にあるブレークポイントの点をマウスで左クリックします 。点が消え、ブレークポイントが削除されたことを示します。
[ all breakpoints Clear all ]アイコンをクリックすると、現在 Program Bodyフレームに表示されている Program からすべてのブレークポイントを削除できます。
図7.15 - すべてのブレークポイントの消去アイコン
注:上記のいずれかの操作を実行すると、 Program Bodyパネルに現在表示されているProgram Body内のブレークポイントだけが削除されます。現在Program Bodyパネルに表示されているプログラムを呼び出すプログラム内の呼び出されたサブプログラムまたはブレークポイントのブレークポイントは削除されません。
7.5.3 コンテキスト内デバッグ用のグローバルブレークポイントの設定
コンテキスト内デバッグのグローバルブレークポイントを設定するには、 Browserパネルでブレークポイントを設定するストアドプロシージャ、関数、またはトリガを強調表示します 。 [ Object ]メニューから[ Debugging ]、[ Breakpoint Set ]の順に選択します。
図7.16 - オブジェクトメニューからグローバルブレークポイントを設定する
または、グローバルブレークポイントを設定するストアドプロシージャ、関数、またはトリガの名前を右クリックし 、コンテキストメニューからDebugging を選択し 、次にSet BreakpointSet Breakpointすることもできます。
図7.17 - オブジェクトのコンテキストメニューからグローバルブレークポイントを設定する
トリガにグローバルブレークポイントを設定するには、トリガを含むテーブルノードを展開し、デバッグする特定のトリガを強調表示し、ストアドプロシージャおよび関数と同じ指示に従います。
パッケージ内にグローバルブレークポイントを設定するには、デバッグするパッケージのパッケージノードの下にある特定のプロシージャまたは関数を強調表示し、ストアドプロシージャおよび関数と同じ指示に従います。
[ Breakpoint Set を選択すると、[デバッガ]ウィンドウが開き、アプリケーションがデバッグ対象のプログラムを呼び出すのを待ちます。
図7.18 - デバッグするプログラムの呼び出し待ち
PSQLクライアントは、 select_emp関数(グローバルブレークポイントが設定されている)を呼び出します
$ psql edb enterprisedb
psql.bin (11.0.2, server 11.0.2)
Type "help" for help.
 
edb=# SELECT select_emp(7900);
select_empデバッガでプログラムをステップ実行するまでの機能は完了しません。
図7.19 - グローバルブレークポイントが設定されているプログラム
ステップイン、ステップオーバー、および続行、またはローカルブレークポイントの設定など、前述の操作のいずれかを使用してプログラムをデバッグできるようになりました。プログラムの実行をステップ実行すると、呼び出し元のアプリケーション(PSQL)が制御を取り戻し、 select_emp関数の実行が完了し、その出力が表示されます。
$ psql edb enterprisedb
psql.bin (11.0.2, server 11.0.2)
Type "help" for help.
 
edb=# SELECT select_emp(7900);
INFO: Number : 7900
INFO: Name : JAMES
INFO: Hire Date : 12/03/1981
INFO: Salary : 950.00
INFO: Commission: 0.00
INFO: Department: SALES
select_emp
------------
(1 row)
この時点で、セクション 7.5.4に 示すようにデバッガセッションを終了することができます 。デバッガセッションを終了しないと、プログラムを呼び出す次のアプリケーションにグローバルブレークポイントが発生し、デバッグサイクルが再び開始されます。
7.5.4 デバッガの終了
デバッガセッションを終了し、デバッガを終了するには、ツールの使用を終了したときに、右上隅にある閉じるアイコン( x )をクリックしてタブを閉じます。
図7.20 - デバッガからの終了
8 パフォーマンスの分析とチューニング
Advanced Serverは、パフォーマンス分析とチューニングのためのさまざまなツールを提供します。これらの機能については、このセクションで説明します。
 
8.1 ダイナネ
Advanced Serverは、インストールされているホストマシンでシステムリソースを最適に使用できるように、データベースサーバーの動的調整をサポートしています。この機能を制御する2つのパラメータは、 postgresql.confファイルにあります。これらのパラメータは次のとおりです。
8.1.1 edb_dynatune
edb_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)、ホスト・マシンのリソースの最小量がデータベース・サーバーに割り当てられます。この設定は、他の多くのアプリケーションが使用されている開発マシンで使用されます。
34〜66の範囲の値は、適度な量のリソースをデータベース・サーバーに割り当てます。この設定は、Advanced Serverと同じマシン上で実行されている固定数の他のアプリケーションを持つ専用アプリケーションサーバーに使用される場合があります。
最高値(67〜100など)は、サーバーのリソースのほとんどをデータベースサーバーに割り当てます。この設定は、Advanced Serverの実行専用のホストマシンで使用されます。
edb_dynatune が選択されると、 postgresql.confファイル内の他の設定パラメータを調整することによって、データベースサーバのパフォーマンスをさらに微調整することができます。調整された設定は、 edb_dynatuneによって選択された対応する値を上書きします。パラメーターの値を変更するには、構成パラメーターをコメント解除し、目的の値を指定して、データベース・サーバーを再始動します。
8.1.2 edb_dynatune_profile
edb_dynatune_profileパラメータは、データベース・サーバー上で予想されるワークロードのプロファイルに基づいて調整局面を制御するために使用されます。このパラメータは、データベースサーバの起動時に有効になります。
edb_dynatune_profile できる値は edb_dynatune_profileです。
8.2 EDB待機状態
EDBの状態を待つ貢献モジュールは、2つの主要なコンポーネントが含まれています。
EDB待機状態のバックグラウンドワーカー(EWSBW)
待機状態のバックグラウンドワーカーが共有プリロードライブラリの1つとして登録されると、EWSBWは実行中の各セッションを定期的にプローブします。
セッションごとに、接続先のデータベース、セッションのログインユーザー、そのセッションで実行中のクエリ、および待機中の待機イベントなどの情報が収集されます。
この情報はpostgresql.confファイルに追加されるedb_wait_states.directoryパラメータで指定された、ユーザが設定可能なパスとディレクトリフォルダ内の一連のファイルに保存されます。指定されたパスは完全パスで、相対パスではありません。
EDB待機状態は、 edb-as xx -server-edb-modules RPMパッケージとともにインストールされます。ここで、 xxはAdvanced Serverのバージョン番号です。
ワーカを起動するにはshared_preload_librariesパラメータを使用して postgresql.confファイルに登録する必要があります。たとえば、次のようになります。
shared_preload_libraries = '$libdir/edb_wait_states'
データベースサーバーを再起動し、次の拡張機能を作成します。
CREATE EXTENSION edb_wait_states;
EDB待ち状態ワーカを終了するには、 shared_preload_librariesパラメータから$libdir/edb_wait_states 削除し 、データベースサーバを再起動します。
この情報を読むためのインターフェース
読み取りインタフェースには、以下のセクションに記載されている機能が含まれています。これらの関数のそれぞれは、共通の入力および出力パラメータを有する。これらのパラメータは次のとおりです。
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つのクエリに基づいています。
SELECT schemaname FROM pg_tables, pg_sleep(15) WHERE schemaname <> 'pg_catalog'; /* ran on 2 sessions */
SELECT tablename FROM pg_tables, pg_sleep(10) WHERE schemaname <> 'pg_catalog';
SELECT tablename, schemaname FROM pg_tables, pg_sleep(10) WHERE schemaname <> 'pg_catalog';
8.2.1 edb_wait_states_data
この機能は、EWSBWによって収集されたデータを読み取るために使用されます。
edb_wait_states_data(
IN 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 text
)
この関数を使用して、以下を見つけることができます:
すべてのセッションで指定された期間( start_tsおよびend_ts 定義 )で実行されているクエリと、待機していた待機イベント(待機中)。例えば:
SELECT query, session_id, wait_event_type, wait_event
FROM edb_wait_states_data(start_ts, end_ts);
指定された期間内のセッションの進行状況(つまり、セッションで実行されたクエリ(session_id = 100000)およびクエリが待機した待機イベント)。例えば:
SELECT query, wait_event_type, wait_event
FROM edb_wait_states_data(start_ts, end_ts)
WHERE session_id = 100000;
サンプルが利用可能な期間。例えば:
SELECT min(sample_time), max(sample_time)
FROM edb_wait_states_data();
パラメーター
前述の共通パラメータに加えて、出力の各行には次のものがあります。
dbname
セッションのデータベース
username
セッションにログインしているユーザー
query
セッションで実行中のクエリ
query_start_time
クエリが開始された時刻
sample_time
待機イベント・データが収集された時刻
wait_event_type
セッション(バックエンド)が待機している待機イベントのタイプ
wait_event
セッション(バックエンド)が待機している待機イベント
以下は、 edb_wait_states_data()関数の出力例です。
edb=# SELECT * FROM edb_wait_states_data();
-[ RECORD 1 ]----+-------------------------------------------------------------------------
session_id | 4398
dbname | edb
username | enterprisedb
query | SELECT schemaname FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
query_start_time | 17-AUG-18 11:56:05.271962 -04:00
sample_time | 17-AUG-18 11:56:19.700236 -04:00
wait_event_type | Timeout
wait_event | PgSleep
-[ RECORD 2 ]----+-------------------------------------------------------------------------
session_id | 4398
dbname | edb
username | enterprisedb
query | SELECT schemaname FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
query_start_time | 17-AUG-18 11:56:05.271962 -04:00
sample_time | 17-AUG-18 11:56:18.699938 -04:00
wait_event_type | Timeout
wait_event | PgSleep
-[ RECORD 3 ]----+-------------------------------------------------------------------------
session_id | 4398
dbname | edb
username | enterprisedb
query | SELECT schemaname FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
query_start_time | 17-AUG-18 11:56:05.271962 -04:00
sample_time | 17-AUG-18 11:56:17.700253 -04:00
wait_event_type | Timeout
wait_event | PgSleep
.
.
.
8.2.2 edb_wait_states_queries
この関数は、EWSBWによってサンプリングされたクエリに関する情報を提供します。
edb_wait_states_queries(
IN start_ts timestamptz default '-infinity'::timestamptz,
IN end_ts timestamptz default 'infinity'::timestamptz,
OUT query_id int8,
OUT query text,
OUT ref_start_ts timestamptz
OUT ref_end_ts timestamptz
)
新しいクエリファイルは定期的に作成されるため、特定の間隔に対応して生成された複数のクエリファイルが存在する可能性があります。
この関数は、指定された時間間隔で重複するクエリファイル内のすべてのクエリを返します。次のようなクエリは、 start_tsend_ts 間のクエリを含むクエリファイル内のすべてのクエリを提供します
言い換えると、関数は、指定された間隔で実行されなかったクエリを出力することがあります。ユーザーが edb_wait_states_data() を使用する必要があることを正確に知る
SELECT query FROM edb_wait_states_queries(start_ts, end_ts);
パラメーター
前述の共通パラメータに加えて、出力の各行には次のものがあります。
query
正規化されたクエリテキスト
以下は、 edb_wait_states_queries()関数の出力例です。
edb=# SELECT * FROM edb_wait_states_queries();
-[ RECORD 1 ]+-----------------------------------------------------------------------------
query_id | 4292540138852956818
query | SELECT schemaname FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts | 18-AUG-18 11:52:38.698793 -04:00
-[ RECORD 2 ]+-----------------------------------------------------------------------------
query_id | 3754591102365859187
query | SELECT tablename FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts | 18-AUG-18 11:52:38.698793 -04:00
-[ RECORD 3 ]+-----------------------------------------------------------------------------
query_id | 349089096300352897
query | SELECT tablename, schemaname FROM pg_tables, pg_sleep($1) WHERE schemaname <> $2
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts | 18-AUG-18 11:52:38.698793 -04:00
8.2.3 edb_wait_states_sessions
この関数は、EWSBWによってサンプリングされたセッションに関する情報を提供します。
edb_wait_states_sessions(
IN 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 timestamptz
OUT ref_end_ts timestamptz
)
この関数を使用して、接続されたデータベースおよび/またはそれらのセッションを開始したユーザーを特定できます。例えば:
SELECT dbname, username, session_id
FROM edb_wait_states_sessions();
edb_wait_states_queries() と同様に 、この関数は、指定された間隔内でサンプリングされたセッションを含むセッションファイルに記録されたすべてのセッションを出力します。 edb_wait_states_data()を使うべきであることを特定する。
パラメーター
前述の共通パラメータに加えて、出力の各行には次のものがあります。
dbname
セッションが接続されているデータベース
username
セッションのログインユーザー
以下は、 edb_wait_states_sessions()関数の出力例です。
edb=# SELECT * FROM edb_wait_states_sessions();
-[ RECORD 1 ]+---------------------------------
session_id | 4340
dbname | edb
username | enterprisedb
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts | 18-AUG-18 11:52:38.698793 -04:00
-[ RECORD 2 ]+---------------------------------
session_id | 4398
dbname | edb
username | enterprisedb
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts | 18-AUG-18 11:52:38.698793 -04:00
-[ RECORD 3 ]+---------------------------------
session_id | 4410
dbname | db1
username | user1
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts | 18-AUG-18 11:52:38.698793 -04:00
-[ RECORD 4 ]+---------------------------------
session_id | 4422
dbname | db2
username | user2
ref_start_ts | 17-AUG-18 11:52:38.698793 -04:00
ref_end_ts | 18-AUG-18 11:52:38.698793 -04:00
8.2.4 edb_wait_states_samples
この関数は、EWSBWによってサンプリングされた待機イベントに関する情報を提供します。
edb_wait_states_samples(
IN 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 text
)
通常、この関数を直接呼び出す必要はありません。
パラメーター
前述の共通パラメータに加えて、出力の各行には次のものがあります。
query_start_time
このセッションでクエリが開始された時刻
sample_time
待機イベント・データが収集された時刻
wait_event_type
セッションが待機している待機イベントのタイプ
wait_event
セッション(バックエンド)が待機している待機イベント
以下は、 edb_wait_states_samples()関数の出力例です。
edb=# SELECT * FROM edb_wait_states_samples();
-[ RECORD 1 ]----+---------------------------------
query_id | 4292540138852956818
session_id | 4340
query_start_time | 17-AUG-18 11:56:00.39421 -04:00
sample_time | 17-AUG-18 11:56:00.699934 -04:00
wait_event_type | Timeout
wait_event | PgSleep
-[ RECORD 2 ]----+---------------------------------
query_id | 4292540138852956818
session_id | 4340
query_start_time | 17-AUG-18 11:56:00.39421 -04:00
sample_time | 17-AUG-18 11:56:01.699003 -04:00
wait_event_type | Timeout
wait_event | PgSleep
-[ RECORD 3 ]----+---------------------------------
query_id | 4292540138852956818
session_id | 4340
query_start_time | 17-AUG-18 11:56:00.39421 -04:00
sample_time | 17-AUG-18 11:56:02.70001 -04:00
wait_event_type | Timeout
wait_event | PgSleep
-[ RECORD 4 ]----+---------------------------------
query_id | 4292540138852956818
session_id | 4340
query_start_time | 17-AUG-18 11:56:00.39421 -04:00
sample_time | 17-AUG-18 11:56:03.700081 -04:00
wait_event_type | Timeout
wait_event | PgSleep
.
.
.
8.2.5 edb_wait_states_purge
この関数は、 start_ts 後に作成され、 start_ts前にend_tsされた(回転された) すべてのサンプリングされたデータファイル(クエリ、セッション、および待機イベントサンプル)を end_tsます。
edb_wait_states_purge(
IN start_ts timestamptz default '-infinity'::timestamptz,
IN end_ts timestamptz default 'infinity'::timestamptz
)
通常、この機能を実行する必要はありません。バックエンドは保持期限に応じてそれらをパージする必要がありますが、何らかの理由でそれが発生しない場合は、この機能を使用できます。
サンプルが保持されている期間を知るには 、その関数の前の例で説明したように、 edb_wait_states_data()使用します。
$PGDATA/edb_wait_states実行する前にディレクトリをedb_wait_states_purge()
[root@localhost data]# pwd
/var/lib/edb/as11/data
[root@localhost data]# ls -l edb_wait_states
total 12
-rw------- 1 enterprisedb ... 253 Aug 17 11:56 edb_ws_queries_587836358698793_587922758698793
-rw------- 1 enterprisedb ... 1600 Aug 17 11:56 edb_ws_samples_587836358698793_587839958698793
-rw------- 1 enterprisedb ... 94 Aug 17 11:56 edb_ws_sessions_587836358698793_587922758698793
edb_wait_states_purge()実行した後 $PGDATA/edb_wait_statesディレクトリ:
edb=# SELECT * FROM edb_wait_states_purge();
edb_wait_states_purge
-----------------------
(1 row)
 
[root@localhost data]# pwd
/var/lib/edb/as11/data
[root@localhost data]# ls -l edb_wait_states
total 0
9 EDBクローンスキーマ
EDB Clone Schemaは、Advanced Serverの拡張モジュールで、スキーマとそのデータベースオブジェクトをローカルデータベースまたはリモートデータベース(ソースデータベース)から受信側データベース(ターゲットデータベース)にコピーすることができます。
ソース・データベースとターゲット・データベースは、同じ物理データベース、または同じデータベース・クラスタ内の異なるデータベース、または別々のデータベース・サーバー・ホスト上の異なるデータベース・クラスタの下で実行される別々のデータベースにすることができます。
EDBクローンスキーマで次の機能を使用します。
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 OracleCompatible ある方言が指定されている場合、またはテキストモードインストールまたはクラスタ初期化中に - redwood likeキーワードが含まれている場合にのみAdvanced Serverで Compatibleされます。
リモート・クローニングの場合、ソース・スキーマ内のオブジェクトが拡張機能に依存している場合 、リモート・クローニング機能を呼び出す前に、 この拡張機能をリモート・データベースのpublicスキーマに作成する必要があります
次のセクションでは、データベースでEDBクローンスキーマを設定する方法について説明します。
9.1 セットアッププロセス
EDB Clone Schema機能によって、ソースデータベースまたはターゲットデータベースとして使用するために、PL / Perl言語とともにいくつかの拡張機能を任意のデータベースにインストールする必要があります。
さらに 、データベースサーバのpostgresql.confファイル内のいくつかの設定パラメータには 、いくつかの変更がpostgresql.confです。
これらの要件の設定手順は次のとおりです。
9.1.1 拡張機能とPL / Perlのインストール
次に、必要な拡張機能とPL / Perl言語をインストールする手順を説明します。
これらの手順は、EDBクローンスキーマ機能によってソースデータベースまたはターゲットデータベースとして使用されるすべてのデータベースで実行する必要があります。
手順1:次の拡張機能をデータベースにインストールする必要があります。
pgagent拡張を作成する前に、pgAgentがインストールされていることを確認してください 。 Linuxでは、 edb-as xx -pgagent RPMパッケージを使用できます。ここで、 xxはpgAgentをインストールするAdvanced Serverのバージョン番号です。 Windowsでは、StackBuilder Plusを使用してpgAgentをダウンロードしてインストールします。
前述の拡張機能は、次のコマンドが存在しない場合にインストールすることができます。
CREATE EXTENSION postgres_fdw SCHEMA public;
CREATE EXTENSION dblink SCHEMA public;
CREATE EXTENSION adminpack;
CREATE EXTENSION pgagent;
CREATE EXTENSIONコマンドの使用方法の詳細については、PostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/sql-createextension.html
ステップ2: postgresql.confファイルを変更します。
次の例に示すように、 $libdir/parallel_cloneshared_preload_libraries構成パラメータに追加して postgresql.confファイルを変更します。
shared_preload_libraries = '$libdir/dbms_pipe,$libdir/dbms_aq,$libdir/parallel_clone'
ステップ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言語パックガイド」を参照してください。
https://www.enterprisedb.com/resources/product-documentation
手順4:スーパーユーザーとしてデータベースに接続し、次のコマンドを実行します。
CREATE TRUSTED LANGUAGE plperl;
CREATE LANGUAGEコマンドの使用方法の詳細については、PostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/sql-createlanguage.html
9.1.2 設定パラメータの設定
以下のセクションでは、 postgresql.confファイルで変更する必要のある特定の設定パラメータについて説明します。
9.1.2.1 パフォーマンスの構成パラメータ
大規模なスキーマを1つのトランザクションの一部としてコピーするには、システムをチューニングする必要があります。
構成パラメーターのチューニングは、クローニング機能で参照されるソース・データベース・サーバー用です。
postgresql.confファイルの設定パラメータには、次のものがあります。
work_mem。一時ディスクファイルに書き込む前に内部ソート操作およびハッシュテーブルで使用されるメモリ量を指定します。
maintenance_work_mem。 VACUUMCREATE INDEXALTER 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。このパラメータは、トランザクションごとに割り当てられるオブジェクトロックの平均数を制御します。個々のトランザクションは、すべてのトランザクションのロックがロックテーブルに収まる限り、より多くのオブジェクトをロックできます。
設定パラメータの詳細については、PostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/runtime-config.html
9.1.2.2 ステータスロギング
クローニング機能による状態ロギングは、クローン機能を呼び出すときに接続しているデータベースサーバのpostgresql.confファイルのlog_directoryパラメータで指定されたディレクトリにログファイルを作成します
デフォルトの場所は 、次のようにPGDATA/log です
#log_directory = 'log' # directory where log files are written,
# can be absolute or relative to PGDATA
このディレクトリは、クローン機能を実行する前に存在していなければなりません。
ログ・ファイルの名前は、クローン機能を呼び出すときにパラメーター・リストで指定したものによって決まります。
ログファイルからステータスを表示するには、第9.2.5項の説明に従ってprocess_status_from_log関数を使用します
ログファイルを削除するには、使用 remove_log_file_and_jobセクションで説明したように機能を9.2.6 、または単にログディレクトリに移動し、手動で削除します。
9.1.3 EDBクローン・スキーマのインストール
EDB Clone Schemaのインストール手順は次のとおりです。
これらの手順は、EDBクローンスキーマ機能によってソースデータベースまたはターゲットデータベースとして使用されるすべてのデータベースで実行する必要があります。
手順1:以前のバージョンのedb_cloneschema拡張を以前にインストールしていた場合は、次のコマンドを実行する必要があります。
DROP EXTENSION parallel_clone CASCADE;
このコマンドは、 edb_cloneschema拡張も削除します。
ステップ2:次のコマンドを使用して拡張機能をインストールします。
CREATE EXTENSION parallel_clone SCHEMA public;
CREATE EXTENSION edb_cloneschema;
あなたが作成していることを確認し parallel_clone作成前に拡張をedb_cloneschema拡張子を。
9.1.4 外部サーバーおよびユーザー・マッピングの作成
ローカルクローン機能 localcopyschemaまたはlocalcopyschema_nbいずれかを使用する場合、必要なパラメータの1つに、データベースサーバを識別するための単一の外部サーバと、クローンされたスキーマの送信元および受信者であるデータベースが含まれます。
リモートクローン機能の1つ、 remotecopyschemaまたはremotecopyschema_nb を使用する場合は 、2つの必須パラメータに2つの外部サーバが含まれます。最初のパラメータとして指定された外部サーバーは、クローンされたスキーマのプロバイダであるデータベースと共にソースデータベースサーバーを識別します。 2番目のパラメータとして指定された外部サーバーは、クローンされたスキーマの受信者であるデータベースと共に、ターゲットデータベースサーバーを識別します。
各外部サーバーに対して、ユーザー・マッピングを作成する必要があります。選択したデータベースのスーパーユーザーがクローニング機能を呼び出すと、その関数を呼び出すデータベーススーパーユーザーは、クローニング機能のパラメータとして指定されている外部サーバーにアクセスできるデータベースユーザー名とパスワードにマップされている必要があります。
外部データ、外部サーバ、ユーザマッピングに関する一般的な情報については、以下のPostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/ddl-foreign-data.html
次の2つのセクションでは、これらの外部サーバーとユーザーのマッピングがどのように定義されているかについて説明します。
9.1.4.1 ローカル・クローニング機能用の外部サーバーおよびユーザー・マッピング
ため localcopyschemalocalcopyschema_nb機能、ソースとターゲットスキーマは、同じデータベースサーバの同じデータベース内の両方です。したがって、これらの機能には1つの外部サーバーしか定義および指定する必要がありません。この外部サーバーは、 ローカルサーバーとも呼ばれます
localcopyschemaまたはlocalcopyschema_nb関数を呼び出すときにこのサーバーを接続する必要があるため、このサーバーはローカルサーバーと呼ばれます。
ユーザーマッピングは、外部サーバーの接続および認証情報を定義します。
この外部サーバーとユーザーのマッピングは、クローンを作成するローカルサーバーのデータベース内に作成する必要があります。
ユーザーマッピングが定義されているデータベースユーザーは、スーパーユーザーである必要があり、ユーザーはEDBクローンスキーマ機能を呼び出すときにローカルサーバーに接続する必要があります。
次の例では、複製するスキーマを含むデータベースの外部サーバーを作成し、複製されたスキーマも同様に受信します。
CREATE SERVER local_server FOREIGN DATA WRAPPER postgres_fdw
OPTIONS(
host 'localhost',
port '5444',
dbname 'edb'
);
CREATE SERVERコマンドの使用の詳細については、PostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/sql-createserver.html
このサーバーのユーザーマッピングは次のとおりです。
CREATE USER MAPPING FOR enterprisedb SERVER local_server
OPTIONS (
user 'enterprisedb',
password 'password'
);
CREATE USER MAPPINGコマンドの使用方法の詳細については、PostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/sql-createusermapping.html
次の psqlコマンドは、外部サーバーとユーザーのマッピングを示しています。
edb=# \des+
List of foreign servers
-[ RECORD 1 ]--------+----------------------------------------------
Name | local_server
Owner | enterprisedb
Foreign-data wrapper | postgres_fdw
Access privileges |
Type |
Version |
FDW options | (host 'localhost', port '5444', dbname 'edb')
Description |
 
edb=# \deu+
List of user mappings
Server | User name | FDW options
--------------+--------------+----------------------------------------------
local_server | enterprisedb | ("user" 'enterprisedb', password 'password')
(1 row)
データベーススーパーユーザー enterprisedbがクローン機能を呼び出すと、データベースユーザーenterprisedbとパスワードが使用され、 localhost local_serverにポート5444でデータベースedbに接続します。
この場合、マッピングされたデータベースユーザー enterprisedbおよびデータベースユーザーenterprisedbは、ローカルのedbデータベースに接続するために使用され、同一のデータベースユーザーとなりますが、絶対的な要件ではありません。
これらの外部サーバーとユーザーのマッピングの具体例については、 9.2.1 項の例を参照してください
9.1.4.2 リモート・クローニング機能用の外部サーバーおよびユーザー・マッピング
remotecopyschemaremotecopyschema_nb機能、ソースとターゲットスキーマは、同じまたは異なるデータベース・サーバの異なるデータベースです。したがって、これらの機能には、2つの外部サーバーを定義して指定する必要があります。
元のデータベースサーバーを定義する外部サーバーと、複製されるソーススキーマを含むそのデータベースは、 ソースサーバーまたはリモートサーバー と呼ばれ ます
クローン作成するスキーマを受け取るデータベースサーバーとそのデータベースを定義する外部サーバーは、 ターゲットサーバーまたはローカルサーバー と呼ばれ ます
このサーバーは、 remotecopyschemaまたはremotecopyschema_nb関数を呼び出すときに接続する必要があるため、ターゲットサーバーはローカルサーバーとも呼ばれます。
ユーザーマッピングは、外部サーバーの接続および認証情報を定義します。
これらの外部サーバーとユーザーのマッピングはすべて、ターゲット/ローカルサーバーのターゲットデータベース内に作成する必要があります。
ユーザーマッピングが定義されているデータベースユーザーは、スーパーユーザーである必要があり、ユーザーはEDBクローンスキーマ機能を呼び出すときにローカルサーバーに接続する必要があります。
次の例では、複製されたスキーマを受信するローカルのターゲット・データベース用の外部サーバーを作成します。
CREATE SERVER tgt_server FOREIGN DATA WRAPPER postgres_fdw
OPTIONS(
host 'localhost',
port '5444',
dbname 'tgtdb'
);
このサーバーのユーザーマッピングは次のとおりです。
CREATE USER MAPPING FOR enterprisedb SERVER tgt_server
OPTIONS (
user 'tgtuser',
password 'tgtpassword'
);
次の例では、複製されたスキーマのソースとなるリモートのソース・データベース用の外部サーバーを作成します。
CREATE SERVER src_server FOREIGN DATA WRAPPER postgres_fdw
OPTIONS(
host '192.168.2.28',
port '5444',
dbname 'srcdb'
);
このサーバーのユーザーマッピングは次のとおりです。
CREATE USER MAPPING FOR enterprisedb SERVER src_server
OPTIONS (
user 'srcuser',
password 'srcpassword'
);
次の psqlコマンドは、外部サーバとユーザのマッピングを示しています。
tgtdb=# \des+
List of foreign servers
-[ RECORD 1 ]--------+---------------------------------------------------
Name | src_server
Owner | tgtuser
Foreign-data wrapper | postgres_fdw
Access privileges |
Type |
Version |
FDW options | (host '192.168.2.28', port '5444', dbname 'srcdb')
Description |
-[ RECORD 2 ]--------+---------------------------------------------------
Name | tgt_server
Owner | tgtuser
Foreign-data wrapper | postgres_fdw
Access privileges |
Type |
Version |
FDW options | (host 'localhost', port '5444', dbname 'tgtdb')
Description |
 
tgtdb=# \deu+
List of user mappings
Server | User name | FDW options
------------+--------------+--------------------------------------------
src_server | enterprisedb | ("user" 'srcuser', password 'srcpassword')
tgt_server | enterprisedb | ("user" 'tgtuser', password 'tgtpassword')
(2 rows)
データベーススーパーユーザー 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ユーザーマッピング。
# TYPE DATABASE USER ADDRESS METHOD
 
# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
host srcdb srcuser 192.168.2.27/32 md5
これらの外部サーバーとユーザーのマッピングの具体例については、 9.2.3 項の例を参照してください
9.2 EDBクローンスキーマ関数
parallel_cloneedb_cloneschema拡張がインストールされている場合、 EDB Clone Schema関数は edb_utilスキーマで作成されます。
EDB Clone Schema機能を使用する前に、次の条件を確認してください。
ターゲット・データベースまたはローカル・データベースの外部サーバーの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権限を持つすべてのロールがターゲットデータベースクラスタに存在します。そうでない場合、それらのロールに対する権限の付与はターゲットで失敗しますスキーマこれは、クローニングプロセスの失敗を引き起こします。
pgAgentの詳細については、次のpgAdminドキュメントの次のセクションを参照してください。
https://www.pgadmin.org/docs/pgadmin4/dev/pgagent.html
pgAgentはAdvanced Serverのコンポーネントとして提供されることに注意してください。
9.2.1 localcopyschema
localcopyschema関数内に指定されたローカル・データベース内にコピースキーマとそのデータベース・オブジェクトsource_fdw同じデータベース内で指定されたターゲット・スキーマにソース・スキーマから外部サーバ。
localcopyschema(
source_fdw TEXT,
source_schema TEXT,
target_schema TEXT,
log_filename TEXT
[, on_tblspace BOOLEAN
[, verbose_on BOOLEAN
[, copy_acls BOOLEAN
[, worker_count INTEGER ]]]]
)
この関数はBOOLEAN値を返します。関数が成功するとtrueが返されます。関数が失敗すると、 falseが返されます。
source_fdwsource_schematarget_schema 、およびlog_filename 、他のすべてのパラメータはオプションでありながら必要なパラメータです。
パラメーター
source_fdw
データベースオブジェクトを複製する postgres_fdw外部データラッパーによって管理される外部サーバーの名前
source_schema
データベースオブジェクトがクローン作成されるスキーマの名前。
target_schema
ソース・スキーマからデータベース・オブジェクトをクローンするスキーマの名前。
log_filename
ファンクションからの情報が記録されるログ・ファイルの名前。ログファイルはpostgresql.confファイルのlog_directory設定パラメータで指定されたディレクトリの下に作成されます。
on_tblspace
BOOLEAN値を使用して、データベース・オブジェクトを表領域内に作成するかどうかを指定します。 falseを指定すると、 TABLESPACE句は、ターゲット・スキーマに追加されたときに、該当するCREATE DDL文に含まれません。 trueを指定すると、ターゲット・スキーマに追加するときに、 TABLESPACE句がCREATE DDL文に含まれます。 on_tblspaceパラメータを省略すると、デフォルト値はfalse
verbose_on
BOOLEAN値を使用して、ターゲット・スキーマにオブジェクトを作成するときにDDLをlog_filenameに出力するかどうかを指定します。 falseを指定すると、DDLは出力されません。 trueを指定すると、DDLが出力されます。省略された場合、デフォルト値はfalseです。
copy_acls
BOOLEAN値を使用して、ターゲット・スキーマでオブジェクトを作成する際にアクセス制御リスト(ACL)を含めるかどうかを指定します。アクセス制御リストは、 GRANT特権文のセットです。 falseを指定すると、アクセス制御リストはターゲット・スキーマに含まれません。 trueを指定すると、アクセス制御リストがターゲット・スキーマに含まれます。 copy_aclsパラメータを省略すると、デフォルト値はfalse
worker_count
クローンを並行して実行するバックグラウンドワーカーの数。省略された場合、デフォルト値は 1です。
次の例では、スキーマのクローニング示す edbスキーマターゲットにデータベース・オブジェクトのセットを含むedbcopyデータベース内の両方、 edbによって定義されるようlocal_server
この例は、次の環境に適しています。
前述の箇条書きの情報を持つ外部サーバー( local_server )とユーザーマッピング( 9.1.4.1項を参照
関数を呼び出す前に、データベースユーザー enterprisedbがデータベースedb 接続します。
edb=# SET search_path TO "$user",public,edb_util;
SET
edb=# SHOW search_path;
search_path
---------------------------
"$user", public, edb_util
(1 row)
 
edb=# SELECT localcopyschema ('local_server','edb','edbcopy','clone_edb_edbcopy');
localcopyschema
-----------------
t
(1 row)
次に、 process_status_from_log関数を使用してロギングのステータスを表示します
edb=# SELECT process_status_from_log('clone_edb_edbcopy');
process_status_from_log
------------------------------------------------------------------------------------------------
(FINISH,"2017-06-29 11:07:36.830783-04",3855,INFO,"STAGE: FINAL","successfully cloned schema")
(1 row)
クローンが完了すると、 edbcopyスキーマにコピーされたデータベースオブジェクトの一部が次のように表示されます。
edb=# SET search_path TO edbcopy;
SET
edb=# \dt+
List of relations
Schema | Name | Type | Owner | Size | Description
---------+---------+-------+--------------+------------+-------------
edbcopy | dept | table | enterprisedb | 8192 bytes |
edbcopy | emp | table | enterprisedb | 8192 bytes |
edbcopy | jobhist | table | enterprisedb | 8192 bytes |
(3 rows)
 
edb=# \dv
List of relations
Schema | Name | Type | Owner
---------+----------+------+--------------
edbcopy | salesemp | view | enterprisedb
(1 row)
 
edb=# \di
List of relations
Schema | Name | Type | Owner | Table
---------+---------------+-------+--------------+---------
edbcopy | dept_dname_uq | index | enterprisedb | dept
edbcopy | dept_pk | index | enterprisedb | dept
edbcopy | emp_pk | index | enterprisedb | emp
edbcopy | jobhist_pk | index | enterprisedb | jobhist
(4 rows)
 
edb=# \ds
List of relations
Schema | Name | Type | Owner
---------+------------+----------+--------------
edbcopy | next_empno | sequence | enterprisedb
(1 row)
 
edb=# SELECT DISTINCT schema_name, name, type FROM user_source WHERE schema_name = 'EDBCOPY' ORDER BY type, name;
schema_name | name | type
-------------+--------------------------------+--------------
EDBCOPY | EMP_COMP | FUNCTION
EDBCOPY | HIRE_CLERK | FUNCTION
EDBCOPY | HIRE_SALESMAN | FUNCTION
EDBCOPY | NEW_EMPNO | FUNCTION
EDBCOPY | EMP_ADMIN | PACKAGE
EDBCOPY | EMP_ADMIN | PACKAGE BODY
EDBCOPY | EMP_QUERY | PROCEDURE
EDBCOPY | EMP_QUERY_CALLER | PROCEDURE
EDBCOPY | LIST_EMP | PROCEDURE
EDBCOPY | SELECT_EMP | PROCEDURE
EDBCOPY | EMP_SAL_TRIG | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_a_19991" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_a_19992" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_a_19999" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_a_20000" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_a_20004" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_a_20005" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_c_19993" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_c_19994" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_c_20001" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_c_20002" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_c_20006" | TRIGGER
EDBCOPY | "RI_ConstraintTrigger_c_20007" | TRIGGER
EDBCOPY | USER_AUDIT_TRIG | TRIGGER
(24 rows)
9.2.2 localcopyschema_nb
localcopyschema_nb関数コピースキーマと内に指定されたローカルデータベース内のデータベースオブジェクトsource_fdw同じデータベース内で指定されたターゲット・スキーマにソース・スキーマから外部サーバが、pgAgentに提出されたジョブ等の非ブロッキング様式です。
localcopyschema_nb(
source_fdw TEXT,
source TEXT,
target TEXT,
log_filename TEXT
[, on_tblspace BOOLEAN
[, verbose_on BOOLEAN
[, copy_acls BOOLEAN
[, worker_count INTEGER ]]]]
)
INTEGER値ジョブIDは、pgAgentに投入されたジョブのための関数によって返されます。関数が失敗すると、nullが返されます。
source_fdwsourcetarget 、およびlog_filename 、他のすべてのパラメータはオプションでありながら必要なパラメータです。
pgAgentジョブが完了したら、 remove_log_file_and_job関数を使用してジョブを削除します( 9.2.6項を参照 )。
パラメーター
source_fdw
データベースオブジェクトを複製する postgres_fdw外部データラッパーによって管理される外部サーバーの名前
source
データベースオブジェクトがクローン作成されるスキーマの名前。
target
ソース・スキーマからデータベース・オブジェクトをクローンするスキーマの名前。
log_filename
ファンクションからの情報が記録されるログ・ファイルの名前。ログファイルはpostgresql.confファイルのlog_directory設定パラメータで指定されたディレクトリの下に作成されます。
on_tblspace
BOOLEAN値を使用して、データベース・オブジェクトを表領域内に作成するかどうかを指定します。 falseを指定すると、 TABLESPACE句は、ターゲット・スキーマに追加されたときに、該当するCREATE DDL文に含まれません。 trueを指定すると、ターゲット・スキーマに追加するときに、 TABLESPACE句がCREATE DDL文に含まれます。 on_tblspaceパラメータを省略すると、デフォルト値はfalse
verbose_on
BOOLEAN値を使用して、ターゲット・スキーマにオブジェクトを作成するときにDDLをlog_filenameに出力するかどうかを指定します。 falseを指定すると、DDLは出力されません。 trueを指定すると、DDLが出力されます。省略された場合、デフォルト値はfalseです。
copy_acls
BOOLEAN値を使用して、ターゲット・スキーマでオブジェクトを作成する際にアクセス制御リスト(ACL)を含めるかどうかを指定します。アクセス制御リストは、 GRANT特権文のセットです。 falseを指定すると、アクセス制御リストはターゲット・スキーマに含まれません。 trueを指定すると、アクセス制御リストがターゲット・スキーマに含まれます。 copy_aclsパラメータを省略すると、デフォルト値はfalse
worker_count
クローンを並行して実行するバックグラウンドワーカーの数。省略された場合、デフォルト値は 1です。
セクション 9.2.1 の例と同じクローニング操作が実行されますが 、非ブロック化関数localcopyschema_nbます。
次のコマンドを使用して、pgAgentが適切なローカルデータベースで実行されているかどうかを確認できます。
[root@localhost ~]# ps -ef | grep pgagent
root 4518 1 0 11:35 pts/1 00:00:00 pgagent -s /tmp/pgagent_edb_log hostaddr=127.0.0.1 port=5444 dbname=edb user=enterprisedb password=password
root 4525 4399 0 11:35 pts/1 00:00:00 grep --color=auto pgagent
pgAgentが実行されていない場合は、次のように起動できます。 pgagentプログラムファイルは次の場所にあります。 bin Advanced Serverのインストールディレクトリのサブディレクトリ。
[root@localhost bin]# ./pgagent -l 2 -s /tmp/pgagent_edb_log hostaddr=127.0.0.1 port=5444 dbname=edb user=enterprisedb password=password
注: pgagent -l 2オプションは、 DEBUGモードでpgAgentを開始します。 DEBUGモードでは、 -sオプションで指定されたログファイルに継続的なデバッグ情報が記録されます。 -lオプションにはより低い値を使用するか、より少ない情報を記録するために完全に省略します。
localcopyschema_nb関数は、として示されるジョブIDを返し4の例です。
edb=# SELECT edb_util.localcopyschema_nb ('local_server','edb','edbcopy','clone_edb_edbcopy');
localcopyschema_nb
--------------------
4
(1 row)
次のようにジョブのステータスが表示されます。
edb=# SELECT edb_util.process_status_from_log('clone_edb_edbcopy');
process_status_from_log
---------------------------------------------------------------------------------------------------
(FINISH,"29-JUN-17 11:39:11.620093 -04:00",4618,INFO,"STAGE: FINAL","successfully cloned schema")
(1 row)
次は、pgAgentジョブを削除します。
edb=# SELECT edb_util.remove_log_file_and_job (4);
remove_log_file_and_job
-------------------------
t
(1 row)
9.2.3 remotecopyschema
remotecopyschema関数内に指定されたリモート・ソース・データベース内のソース・スキーマからコピースキーマとそのデータベース・オブジェクトsource_fdw内で指定されたローカル・ターゲット・データベース内のターゲットスキーマに外部サーバtarget_fdw外部サーバ。
remotecopyschema(
source_fdw TEXT,
target_fdw TEXT,
source_schema TEXT,
target_schema TEXT,
log_filename TEXT
[, on_tblspace BOOLEAN
[, verbose_on BOOLEAN
[, copy_acls BOOLEAN
[, worker_count INTEGER ]]]]
)
この関数はBOOLEAN値を返します。関数が成功するとtrueが返されます。関数が失敗すると、 falseが返されます。
source_fdwtarget_fdwsource_schematarget_schema 、およびlog_filename 、他のすべてのパラメータはオプションでありながら必要なパラメータです。
パラメーター
source_fdw
データベースオブジェクトを複製する postgres_fdw外部データラッパーによって管理される外部サーバーの名前
target_fdw
データベースオブジェクトを複製する postgres_fdw外部データラッパーによって管理される外部サーバーの名前
source_schema
データベースオブジェクトがクローン作成されるスキーマの名前。
target_schema
ソース・スキーマからデータベース・オブジェクトをクローンするスキーマの名前。
log_filename
ファンクションからの情報が記録されるログ・ファイルの名前。ログファイルはpostgresql.confファイルのlog_directory設定パラメータで指定されたディレクトリの下に作成されます。
on_tblspace
BOOLEAN値を使用して、データベース・オブジェクトを表領域内に作成するかどうかを指定します。 falseを指定すると、 TABLESPACE句は、ターゲット・スキーマに追加されたときに、該当するCREATE DDL文に含まれません。 trueを指定すると、ターゲット・スキーマに追加するときに、 TABLESPACE句がCREATE DDL文に含まれます。 on_tblspaceパラメータを省略すると、デフォルト値はfalse
注意: trueが指定され、データベース・オブジェクトにTABLESPACE句があり、その表領域がターゲット・データベース・クラスタに存在しない場合、クローニング機能は失敗します。
verbose_on
BOOLEAN値を使用して、ターゲット・スキーマにオブジェクトを作成するときにDDLをlog_filenameに出力するかどうかを指定します。 falseを指定すると、DDLは出力されません。 trueを指定すると、DDLが出力されます。省略された場合、デフォルト値はfalseです。
copy_acls
BOOLEAN値を使用して、ターゲット・スキーマでオブジェクトを作成する際にアクセス制御リスト(ACL)を含めるかどうかを指定します。アクセス制御リストは、 GRANT特権文のセットです。 falseを指定すると、アクセス制御リストはターゲット・スキーマに含まれません。 trueを指定すると、アクセス制御リストがターゲット・スキーマに含まれます。 copy_aclsパラメータを省略すると、デフォルト値はfalse
注意: trueを指定し、 GRANT権限を持つロールがターゲット・データベース・クラスタに存在しない場合、クローニング機能は失敗します。
worker_count
クローンを並行して実行するバックグラウンドワーカーの数。省略された場合、デフォルト値は 1です。
次の例では、スキーマのクローニング示す srcschemaデータベース内srcdbによって定義されるようsrc_serverスキーマターゲットにtgtschemaデータベース内tgtdbによって定義されるようtgt_server
ソースサーバー環境:
前述の箇条書きの情報をsrc_server 外部サーバー( src_server )とユーザーマッピング src_server項を参照
ターゲットサーバー環境:
前述の箇条書きの情報をtgt_server 外部サーバー( tgt_server )とユーザーマッピング tgt_server項を参照
関数を呼び出す前に、データベースユーザー enterprisedbがデータベースtgtdb 接続します。この関数には、 worker_count 4が指定されています。
tgtdb=# SELECT edb_util.remotecopyschema ('src_server','tgt_server','srcschema','tgtschema','clone_rmt_src_tgt',worker_count => 4);
remotecopyschema
------------------
t
(1 row)
以下は、クローニングプロセスのさまざまな段階でログファイルからステータスを表示します。
tgtdb=# SELECT edb_util.process_status_from_log('clone_rmt_src_tgt');
process_status_from_log
-----------------------------------------------------------------------------------------------------------------------------------------
---
(RUNNING,"28-JUN-17 13:18:05.299953 -04:00",4021,INFO,"STAGE: DATA-COPY","[0][0] successfully copied data in [tgtschema.pgbench_tellers]
")
(1 row)
 
tgtdb=# SELECT edb_util.process_status_from_log('clone_rmt_src_tgt');
process_status_from_log
-----------------------------------------------------------------------------------------------------------------------------------------
---
(RUNNING,"28-JUN-17 13:18:06.634364 -04:00",4022,INFO,"STAGE: DATA-COPY","[0][1] successfully copied data in [tgtschema.pgbench_history]
")
(1 row)
 
tgtdb=# SELECT edb_util.process_status_from_log('clone_rmt_src_tgt');
process_status_from_log
-----------------------------------------------------------------------------------------------------------------------------------------
--
(RUNNING,"28-JUN-17 13:18:10.550393 -04:00",4039,INFO,"STAGE: POST-DATA","CREATE PRIMARY KEY CONSTRAINT pgbench_tellers_pkey successful"
)
(1 row)
 
tgtdb=# SELECT edb_util.process_status_from_log('clone_rmt_src_tgt');
process_status_from_log
-----------------------------------------------------------------------------------------------------------------
(FINISH,"28-JUN-17 13:18:12.019627 -04:00",4039,INFO,"STAGE: FINAL","successfully clone schema into tgtschema")
(1 row)
次に、クローンテーブルを示します。
tgtdb=# \dt+
List of relations
Schema | Name | Type | Owner | Size | Description
-----------+------------------+-------+--------------+------------+-------------
tgtschema | pgbench_accounts | table | enterprisedb | 256 MB |
tgtschema | pgbench_branches | table | enterprisedb | 8192 bytes |
tgtschema | pgbench_history | table | enterprisedb | 25 MB |
tgtschema | pgbench_tellers | table | enterprisedb | 16 kB |
(4 rows)
とき remotecopyschema関数が呼び出された、4人のバックグラウンドの労働者が指定されました。
ログファイル clone_rmt_src_tgt の次の部分は、 4人のバックグラウンドワーカーを使用する並列データコピー操作のステータスを示しています。
Wed Jun 28 13:18:05.232949 2017 EDT: [4019] INFO: [STAGE: DATA-COPY] [0] table count [4]
Wed Jun 28 13:18:05.233321 2017 EDT: [4019] INFO: [STAGE: DATA-COPY] [0][0] worker started to copy data
Wed Jun 28 13:18:05.233640 2017 EDT: [4019] INFO: [STAGE: DATA-COPY] [0][1] worker started to copy data
Wed Jun 28 13:18:05.233919 2017 EDT: [4019] INFO: [STAGE: DATA-COPY] [0][2] worker started to copy data
Wed Jun 28 13:18:05.234231 2017 EDT: [4019] INFO: [STAGE: DATA-COPY] [0][3] worker started to copy data
Wed Jun 28 13:18:05.298174 2017 EDT: [4024] INFO: [STAGE: DATA-COPY] [0][3] successfully copied data in [tgtschema.pgbench_branches]
Wed Jun 28 13:18:05.299913 2017 EDT: [4021] INFO: [STAGE: DATA-COPY] [0][0] successfully copied data in [tgtschema.pgbench_tellers]
Wed Jun 28 13:18:06.634310 2017 EDT: [4022] INFO: [STAGE: DATA-COPY] [0][1] successfully copied data in [tgtschema.pgbench_history]
Wed Jun 28 13:18:10.477333 2017 EDT: [4023] INFO: [STAGE: DATA-COPY] [0][2] successfully copied data in [tgtschema.pgbench_accounts]
Wed Jun 28 13:18:10.477609 2017 EDT: [4019] INFO: [STAGE: DATA-COPY] [0] all workers finished [4]
Wed Jun 28 13:18:10.477654 2017 EDT: [4019] INFO: [STAGE: DATA-COPY] [0] copy done [4] tables
Wed Jun 28 13:18:10.493938 2017 EDT: [4019] INFO: [STAGE: DATA-COPY] successfully copied data into tgtschema
ように注意し DATA-COPYログメッセージは、2つ、角括弧の数値を含む(例えば、 [0][3]
最初の数値はジョブインデックスであり、2番目の数値はワーカーインデックスです。労働者のインデックス値は範囲 03 4人の背景の労働者のために。
2つのクローンスキーマジョブが並行して実行されている場合、最初のログファイルはジョブインデックスとして0 を持ち 、2番目のログファイルはジョブインデックスとして1を持ちます。
9.2.4 remotecopyschema_nb
remotecopyschema_nb関数コピー内で指定されたリモート・ソース・データベース内のソース・スキーマからスキーマとそのデータベース・オブジェクトsource_fdw内で指定されたローカル・ターゲット・データベース内のターゲットスキーマに外部サーバtarget_fdw外部サーバが、非ブロッキング様式でジョブがpgAgentに送信されました。
remotecopyschema_nb(
source_fdw TEXT,
target_fdw TEXT,
source TEXT,
target TEXT,
log_filename TEXT
[, on_tblspace BOOLEAN
[, verbose_on BOOLEAN
[, copy_acls BOOLEAN
[, worker_count INTEGER ]]]]
)
INTEGER値ジョブIDは、pgAgentに投入されたジョブのための関数によって返されます。関数が失敗すると、nullが返されます。
source_fdwtarget_fdwsourcetarget 、およびlog_filename 、他のすべてのパラメータはオプションでありながら必要なパラメータです。
pgAgentジョブが完了したら、 remove_log_file_and_job関数を使用してジョブを削除します( 9.2.6項を参照 )。
パラメーター
source_fdw
データベースオブジェクトを複製する postgres_fdw外部データラッパーによって管理される外部サーバーの名前
target_fdw
データベースオブジェクトを複製する postgres_fdw外部データラッパーによって管理される外部サーバーの名前
source
データベースオブジェクトがクローン作成されるスキーマの名前。
target
ソース・スキーマからデータベース・オブジェクトをクローンするスキーマの名前。
log_filename
ファンクションからの情報が記録されるログ・ファイルの名前。ログファイルはpostgresql.confファイルのlog_directory設定パラメータで指定されたディレクトリの下に作成されます。
on_tblspace
BOOLEAN値を使用して、データベース・オブジェクトを表領域内に作成するかどうかを指定します。 falseを指定すると、 TABLESPACE句は、ターゲット・スキーマに追加されたときに、該当するCREATE DDL文に含まれません。 trueを指定すると、ターゲット・スキーマに追加するときに、 TABLESPACE句がCREATE DDL文に含まれます。 on_tblspaceパラメータを省略すると、デフォルト値はfalse
注意: trueが指定され、データベース・オブジェクトにTABLESPACE句があり、その表領域がターゲット・データベース・クラスタに存在しない場合、クローニング機能は失敗します。
verbose_on
BOOLEAN値を使用して、ターゲット・スキーマにオブジェクトを作成するときにDDLをlog_filenameに出力するかどうかを指定します。 falseを指定すると、DDLは出力されません。 trueを指定すると、DDLが出力されます。省略された場合、デフォルト値はfalseです。
copy_acls
BOOLEAN値を使用して、ターゲット・スキーマでオブジェクトを作成する際にアクセス制御リスト(ACL)を含めるかどうかを指定します。アクセス制御リストは、 GRANT特権文のセットです。 falseを指定すると、アクセス制御リストはターゲット・スキーマに含まれません。 trueを指定すると、アクセス制御リストがターゲット・スキーマに含まれます。 copy_aclsパラメータを省略すると、デフォルト値はfalse
注意: trueを指定し、 GRANT権限を持つロールがターゲット・データベース・クラスタに存在しない場合、クローニング機能は失敗します。
worker_count
クローンを並行して実行するバックグラウンドワーカーの数。省略された場合、デフォルト値は 1です。
セクション 9.2.3 の例と同じクローニング操作が実行されますが 、非ブロック化関数remotecopyschema_nbます。
次のコマンドは、ターゲットデータベース tgtdb 上でpgAgentを開始しますpgagentプログラムファイルは、Advanced Serverインストールディレクトリのbinサブディレクトリにあります。
[root@localhost bin]# ./pgagent -l 1 -s /tmp/pgagent_tgtdb_log hostaddr=127.0.0.1 port=5444 user=enterprisedb dbname=tgtdb password=password
remotecopyschema_nb関数は、として示されるジョブIDを返し2例です。
tgtdb=# SELECT edb_util.remotecopyschema_nb ('src_server','tgt_server','srcschema','tgtschema','clone_rmt_src_tgt',worker_count => 4);
remotecopyschema_nb
---------------------
2
(1 row)
完了したジョブのステータスは、次のように表示されます。
tgtdb=# SELECT edb_util.process_status_from_log('clone_rmt_src_tgt');
process_status_from_log
-----------------------------------------------------------------------------------------------------------------
(FINISH,"29-JUN-17 13:16:00.100284 -04:00",3849,INFO,"STAGE: FINAL","successfully clone schema into tgtschema")
(1 row)
次のコマンドは、ログファイルとpgAgentジョブを削除します。
tgtdb=# SELECT edb_util.remove_log_file_and_job ('clone_rmt_src_tgt',2);
remove_log_file_and_job
-------------------------
t
(1 row)
9.2.5 process_status_from_log
process_status_from_log関数は、ログファイルからクローニング機能のステータスを提供します。
process_status_from_log (
log_file TEXT
)
この関数は、ログファイルから次のフィールドを返します。
表9-1 - スキーマ・ログ・ファイルのクローン作成
STARTING , RUNNING , FINISH , or FAILED Displays either .
pid
INFO , ERROR , or SUCCESSFUL Displays either .
STARTUP , INITIAL , DDL-COLLECTION , PRE-DATA , DATA-COPY , POST-DATA , or FINAL Displays either .
パラメーター
log_file
クローン機能が呼び出されたときに指定されたスキーマのクローンを記録するログ・ファイルの名前。
次に、 process_status_from_log関数の使用法を示します
edb=# SELECT edb_util.process_status_from_log('clone_edb_edbcopy');
process_status_from_log
---------------------------------------------------------------------------------------------------
(FINISH,"26-JUN-17 11:57:03.214458 -04:00",3691,INFO,"STAGE: FINAL","successfully cloned schema")
(1 row)
9.2.6 remove_log_file_and_job
remove_log_file_and_job機能は、スキーマのクローニング機能によって作成されたログファイルと、非ブロッキング機能によって作成されたジョブを削除することによってクリーンアップタスクを実行します。
remove_log_file_and_job (
{ log_file TEXT |
job_id INTEGER |
log_file TEXT, job_id INTEGER
}
)
remove_log_file_and_job関数を呼び出すときに、2つのパラメータのいずれかまたは両方の値を指定 remove_log_file_and_jobます。
log_file のみが指定されている場合 、関数はログファイルを削除します。
job_id のみが指定されている場合 、関数はジョブを削除します。
パラメーター
log_file
削除するログファイルの名前。
job_id
削除するジョブのジョブID。
次の例では、ログファイル名を指定してログファイルのみを削除します。
edb=# SELECT edb_util.remove_log_file_and_job ('clone_edb_edbcopy');
remove_log_file_and_job
-------------------------
t
(1 row)
次の例では、ジョブIDを指定してジョブのみを削除します。
edb=# SELECT edb_util.remove_log_file_and_job (3);
remove_log_file_and_job
-------------------------
t
(1 row)
次の例では、両方の値を指定してログファイルとジョブを削除します。
tgtdb=# SELECT edb_util.remove_log_file_and_job ('clone_rmt_src_tgt',2);
remove_log_file_and_job
-------------------------
t
(1 row)
10 PL / Java
PL / Javaパッケージは、JDBCインタフェースを介してJavaストアド・プロシージャ、トリガ、およびファンクションへのアクセスを提供します。特に指定のないかぎり、次のセクションで説明するコマンドとパスは、 edb-as xx -pljava RPMパッケージ( xxはAdvanced Serverのバージョン番号)でインストールを実行したことを前提としています
Linuxシステムで標準のJava仮想マシン(JVM)を使用するためにPL / Javaをインストールする前に、まずJavaランタイム環境(バージョン1.8)がシステムにインストールされていることを確認する必要があります。 Java開発キットをインストールすると、Javaランタイム環境も提供されます。
10.1 LinuxへのPL / Javaのインストール
次の手順は、LinuxシステムにPL / Javaをインストールするプロセスの概要を示しています。
手順1: Advanced Serverインストールのdataディレクトリの下にあるpostgresql.confファイルを編集し、次の設定を追加(または変更)します。
pljava.classpath = ' path_to_pljava.jar '
pljava.libjvm_location = ' path_to_libjvm.so '
どこ path_to_pljava.jarの場所を指定pljava.jarファイルをし、 path_to_libjvm.soの場所を指定libjvm.soファイルを。
たとえば、Javaバージョン1.8を使用したデフォルトインストールのパスを次に示します。
pljava.classpath = '/usr/edb/as11/share/pljava/pljava-1.5.0.jar'
pljava.libjvm_location = '/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-1.b14.el6.x86_64/jre/lib/amd64/server/libjvm.so'
手順2:データベースサーバーを再起動します。
ステップ3: CREATE EXTENSIONコマンドを使用してPL / Javaをインストールできます。 PL / Java拡張機能をインストールするには、psqlまたはpgAdminクライアントを使用してPL / Javaをインストールするデータベースにログインし、次のコマンドを実行します。
CREATE EXTENSION pljava;
ステップ4: PL / Javaがインストールされていることを確認するには、次のコマンドを実行します。
SELECT * FROM pg_language WHERE lanname LIKE 'java%';
edb-psqlクライアントがあることを示す2つの行を表示javajavau (Javaの信頼できない)は、データベースにインストールされています。
edb=# SELECT * FROM pg_language WHERE lanname LIKE 'java%';
lanname | lanowner | lanispl | lanpltrusted | lanplcallfoid | laninline | lanvalidator | lanacl
---------+----------+---------+--------------+---------------+-----------+--------------+-------------------------------
java | 10 | t | t | 16462 | 0 | 0 | {enterprisedb=U/enterprisedb}
javau | 10 | t | f | 16463 | 0 | 0 |
(2 rows)
10.2 WindowsへのPL / Javaのインストール
次の手順は、WindowsシステムにPL / Javaをインストールするプロセスの概要を示しています。
ステップ1: postgresql.confファイルを編集し、次の設定を追加(または変更)します。
pljava.classpath = ' POSTGRES_INSTALL_HOME \lib\pljava.jar'
pljava.libjvm_location = ' path_to_libjvm.so '
どこ POSTGRES_INSTALL_HOME Advanced Serverのインストールの場所を指定します。たとえば、次の設定はデフォルトインストールの設定です。
pljava.classpath = 'C:\Program Files\edb\as11\lib\pljava.jar'
手順2:データベースサーバーを再起動します。
手順3:サーバーで使用されるPATH設定を変更し、次の2つのエントリを追加します。
% JRE_HOME %\bin;% JRE_HOME %\bin\client
どこで JRE_HOMEあなたのJavaランタイム環境のインストールディレクトリを指定します。 Java開発キットをお持ちの場合は、 $JDK_HOME/jre場所をJRE_HOME
ステップ4: Postgres CREATE EXTENSIONコマンドを使用してPL / Javaをインストールします。インストール・スクリプトを実行するには、psqlまたはpgAdminクライアントを使用して、PL / Javaをインストールするデータベースに接続し、次のコマンドを実行します。
CREATE EXTENSION pljava;
ステップ5: PL / Javaがインストールされていることを確認するには、次のコマンドを実行します。
SELECT * FROM pg_language WHERE lanname LIKE 'java%';
クライアントはjavaとjavau(Java Untrusted)を含む結果セットを返します。
10.3 PL / Javaの使用
PL / Javaプログラムを作成するには、少なくとも1つの静的メソッドを含むJavaクラスを作成してから、そのクラスを .classまたは.jarファイルにコンパイルする必要があります。次に、 CREATE FUNCTIONコマンドを使用してSQL内のJava関数を宣言します。 CREATE FUNCTIONコマンドは、関数にSQL名を与え、コンパイルされたクラス(およびメソッド名)をその関数名に関連付けます。
たとえば、次の CREATE FUNCTION文は、 getsyspropという名前の関数を作成します。
CREATE FUNCTION getsysprop(VARCHAR)
RETURNS VARCHAR
AS 'java.lang.System.getProperty'
LANGUAGE java;
呼び出されると、 getsyspropjava.lang.Systemクラス内で定義されたgetProperty (静的)メソッドを実行しjava.lang.System
SELECT getsysprop('user.home');
 
getsysprop
---------------
/usr/edb/as11
(1 row)
以下の例は、単純な HelloWorldプログラムを作成してインストールする手順を示しています
手順1:次のコードサンプルをHelloWorld.javaという名前のファイルに保存します。
package com.mycompany.helloworld;
public class HelloWorld
{
public static String helloWorld()
{
return "Hello World";
}
}
ステップ2:ファイルをコンパイルします。
$ javac HelloWorld.java
それをフォルダ階層に保存します:
com/mycompany/helloworld/HelloWorld.class
手順3: helloworld.jarというアーカイブファイル(JARファイル)を作成します。
jar cf helloworld.jar com/mycompany/helloworld/HelloWorld.class
ステップ4: edb-psqlクライアントを開き、次のコマンドでjarファイルをインストールします。
SELECT sqlj.install_jar('file:/// file_path /helloworld.jar', 'helloworld', true);
ここで、 file_pathhelloworld.jarファイルを含むディレクトリです。たとえば、 /tmpディレクトリがfile_path場合、
SELECT sqlj.install_jar('file:///tmp/helloworld.jar', 'helloworld', true);
jarファイルが正しくロードされたことを確認するには、 sqlj.jar_entryおよびsqlj.jar_repository表でSELECT文を実行します。
edb=# SELECT entryid, entryname FROM sqlj.jar_entry;
entryid | entryname
---------+-------------------------------------------
1 | com/mycompany/helloworld/HelloWorld.class
(1 row)
 
edb=# SELECT jarid, jarname, jarorigin, jarowner FROM sqlj.jar_repository;
jarid | jarname | jarorigin | jarowner
-------+------------+----------------------------+--------------
4 | helloworld | file:///tmp/helloworld.jar | enterprisedb
(1 row)
ステップ5:クラスパスを次のように設定します。
edb=# SELECT sqlj.set_classpath('public', 'helloworld');
sqlj.classpath_entryテーブルは現在のエントリが含まれますhelloworldクラスファイルを。
edb=# SELECT * FROM sqlj.classpath_entry;
schemaname | ordinal | jarid
------------+---------+-------
public | 1 | 4
(1 row)
ステップ6: Javaを使用してjarファイルで宣言された静的関数を呼び出す関数を作成します。
CREATE OR REPLACE FUNCTION helloworld()
RETURNS "varchar"
AS
'com.mycompany.helloworld.HelloWorld.helloWorld'
LANGUAGE 'java' VOLATILE;
ステップ7:関数を実行する:
edb=# SELECT * FROM helloworld();
次の出力が表示されます。
helloworld
-------------
Hello World
(1 row)
公式のPL / Javaディストリビューションには、サンプルとドキュメントが配布されています。 PL / Javaの使用の詳細については、次のプロジェクトページを参照してください。
https://github.com/tada/pljava/wiki
ノート:
Advanced Server 11ではPL / Javaパッケージは推奨されておらず、サーバーバージョン12以降では使用できなくなります。
11 拡張されたSQLおよびその他のその他の機能
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'
ここで、 aggregate _ signatureあります。
* |
[
argmode ] [ argname ] argtype [ , ... ] |
[ [
argmode ] [ argname ] argtype [ , ... ] ]
ORDER BY [
argmode ] [ argname ] argtype [ , ... ]
Parameters
object_name
The name of the object on which you are commenting.
AGGREGATE aggregate _ name ( aggregate _ signature )
集約についてのコメントを作成するには、 AGGREGATE句を含めますaggregate _ nameaggregate 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 ( source _ type AS target _ type )
キャストに関するコメントを作成するには、 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 relation _ name . column _ name
列に関するコメントを作成するには、 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.
CONSTRAINT constraint _ name ON table _ name
CONSTRAINT
constraint _ name ON DOMAIN domain _ name
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.
FUNCTION func _ name ([[ argmode ] [ argname ] argtype [, ...]])
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
large_object_oid is the system-assigned OID of the large object about which you are commenting.
OPERATOR operator _ name (left_type, right_type)
オペレータに関するコメントを追加するには、 OPERATOR句を含めますoperator _ nameは、コメントしている演算子の名前(スキーマ修飾名でも可)を指定します。 left _ typeおよびright _ type are the (optionally schema-qualified) data type(s) of the operator's arguments.
OPERATOR CLASS object _ name USING index _ method
演算子クラスについてのコメントを追加するには、 OPERATOR CLASS句を含めますobject _ nameは、コメントしている演算子の名前(スキーマ修飾名でも可)を指定します。 index_method specifies the associated index method of the operator class.
OPERATOR FAMILY object _ name USING index _ method
OPERATOR FAMILYについてのコメントを追加するには、 OPERATOR FAMILY句を含めますobject _ nameは、コメントしている演算子ファミリの名前(スキーマ修飾名でも可)を指定します。 index_method specifies the associated index method of the operator family.
POLICY policy _ name ON table _ name
ポリシーに関するコメントを追加するには、 POLICY句を含めますpolicy _ nameポリシーの名前を指定し、 table _ nameポリシーが関連付けられているテーブルを指定します。
PROCEDURE proc _ name [([[ argmode ] [ argname ] argtype [, ...]])]
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.
RULE rule _ name ON table _ name
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.
TRANSFORM FOR type _ name LANGUAGE lang _ name |
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 trigger _ name ON table _ name
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.
text
The comment, written as a string literal; or NULL to drop the comment.
Notes:
Names of tables, aggregates, collations, conversions, domains, foreign tables, functions, indexes, operators, operator classes, operator families, packages, procedures, sequences, text search objects, types, and views can be schema-qualified.
Example:
The following example adds a comment to a table named new_emp The following example adds a comment to a table named :
COMMENT ON TABLE new_emp IS 'This table contains information about new employees.';
COMMENT command, please see the PostgreSQL core documentation at: For more information about using the command, please see the PostgreSQL core documentation at:
https://www.postgresql.org/docs/11/static/sql-comment.html
11.2 機能バージョン()の出力
version()関数のテキスト文字列出力は、製品の名前、バージョン、およびそれがインストールされているホストシステムを表示します。
Advanced Serverの場合、 version()出力形式は、PostgreSQLコミュニティバージョンと似た形式ですversion() Advanced Serverバージョン10以前のように、最初のテキストワードはPostgreSQLEnterpriseDBではなく)。
version()出力の一般的な形式は次のとおりです。
PostgreSQL $PG_VERSION_EXT (EnterpriseDB Advanced Server $PG_VERSION) on $host
したがって、現在のAdvanced Serverでは、バージョン文字列は次のようになります。
edb@45032=#select version();
version
-----------------------------------------------------------------------------------------------------------------------------------------------
PostgreSQL 11.0 (EnterpriseDB Advanced Server 11.0.0) on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit
(1 row)
対照的に、Advanced Server 10の場合、バージョン文字列は次のとおりです。
edb=# select version();
version
-------------------------------------------------------------------------------------------------------------
EnterpriseDB 10.4.9 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit
(1 row)
11.3 SQL Serverのdboスキーマ
Advanced Server 11より前は、 dbo という名前のシステムカタログが利用可能でした。 dboシステムカタログには、Microsoft®SQLServer®と類似しているデータベースオブジェクトのビューが含まれていました。
現在、Advanced Serverでは 、どのデータベースにもdboシステムカタログやdboというスキーマは存在しません。
SQL Server互換のビューを持つスキーマが必要な場合は、 CREATE EXTENSION edb_dboコマンドを使用して、 dboスキーマとその内容を作成します。
次の例は、 dboスキーマとそのビューの作成を示しています。
edb=# CREATE EXTENSION edb_dbo;
CREATE EXTENSION
edb=# \dn
List of schemas
Name | Owner
--------+--------------
dbo | enterprisedb
public | enterprisedb
(2 rows)
 
edb=# SET search_path TO dbo;
SET
edb=# \dv
List of relations
Schema | Name | Type | Owner
--------+------------+------+--------------
dbo | sysindexes | view | enterprisedb
dbo | sysobjects | view | enterprisedb
dbo | systables | view | enterprisedb
dbo | systypes | view | enterprisedb
dbo | sysusers | view | enterprisedb
(5 rows)
12 システムカタログテーブル
以下のシステムカタログ表には、データベースオブジェクトの定義が含まれています。システムテーブルのレイアウトは変更される可能性があります。システムテーブルに格納されている情報に依存するアプリケーションを作成する場合は、既存のカタログビューを使用するか、カタログビューを作成してアプリケーションをシステムテーブルの変更から分離することが賢明です。
12.1 edb_dir
edb _ dir表は、で作成したディレクトリを指し、各エイリアスの1つの行が含まCREATE DIRECTORYコマンド。ディレクトリは、ユーザーがホストファイルシステムに限定してアクセスできるようにするパス名のエイリアスです。
ディレクトリを使用して、ファイルシステム内の特定のディレクトリツリーにユーザを囲むことができます。例えば、 UTL _ FILEパッケージには、ホストファイルシステム内のファイルおよびディレクトリを読み書きするためのユーザを許可する機能を提供していますが、唯一のデータベース管理者が経由へのアクセスを許可されたパスにアクセスすることができますCREATE DIRECTORYコマンドを。
oid
12.2 edb_all_resource_groups
edb_all_resource_groups表は、で作成された各リソースグループの1つの行を含んCREATE RESOURCE GROUPコマンドと各リソースグループ内のアクティブなプロセスの数を表示します。
12.3 edb_password_history
edb _ password_history表は、各パスワード変更のために1行が含まれます。この表は、クラスタ内のすべてのデータベースで共有されます。
oid
12.4 edb_policy
edb _ policyテーブルは、ポリシーごとに1つの行が含ま。
oid
oid
oid
12.5 edb_profile
edb _ profileの表は、使用可能なプロファイルに関する情報を格納します。 edb _ profilesは、クラスタ内のすべてのデータベースで共有されます。
oid
oid
oid
oid
12.6 edb_redaction_column
カタログ edb_redaction_columnは、表の列にアタッチされたデータ変更ポリシーの情報が格納されます。
oid
oid
oid
oid
The redaction scope: 1 = query, 2 = top_tlist, 4 = top_tlist_or_error
The redaction exception: 8 = none, 16 = equal, 32 = leakproof
注:表の編集ポリシーedb_redaction_column.rdpolicyidが有効になっていて、編集ポリシー表現edb_redaction_policy.rdexprがtrueと評価された場合は、記述された列が編集されます。
12.7 edb_redaction_policy
カタログ edb_redaction_policyは、表の編集ポリシーの情報が保管されます。
oid
oid
oid
注:テーブルが有効で、式が真に評価された場合は、データ変更ポリシーがテーブルに適用されます。
12.8 edb_resource_group
edb_resource_group表は、で作成された各リソースグループに対して1つの行含まれているCREATE RESOURCE GROUPコマンド。
12.9 edb_variable
edb _ variableテーブルには、各パッケージレベルの変数(パッケージ内で宣言された各変数)のための1つの行が含ま。
oid
oid
12.10 pg_synonym
pg _ synonymテーブルには、各同義語で作成するための1つの行含まCREATE SYNONYMコマンドまたはCREATE PUBLIC SYNONYMコマンド。
oid
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
oid
12.11 product_component_version
product _ component _ versionテーブルは、特徴の互換性についての情報を含みます。アプリケーションはインストール時または実行時にこのテーブルを照会して、このデプロイメントでアプリケーションで使用される機能が使用可能であることを確認できます。
13 高度なサーバーキーワード
キーワードは、Advanced Serverパーサによって特別な意味または関連があると認識される単語です。 pg_get_keywords()関数を使用すると、Advanced Serverのキーワードの最新リストを取得できます
acctg=#
acctg=# SELECT * FROM pg_get_keywords();
word | catcode | catdesc
---------------------+---------+---------------------------------
abort | U | unreserved
absolute | U | unreserved
access | U | unreserved
...
pg_get_keywordsは、Advanced Serverによって認識されるキーワードを含むテーブルを返します。
word列には、キーワードを表示します。
catcode列には、カテゴリコードを表示します。
catdesc列には、キーワードが属するカテゴリの簡単な説明が表示されます。
名前が二重引用符で囲まれている場合は、識別子に任意の文字を使用できます。 pg_get_keywords()関数を選択的に照会して、特定のカテゴリに属する​​Advanced Serverキーワードの最新リストを取得することができます。
SELECT * FROM pg_get_keywords() WHERE catcode = 'code' ;
どこ code次のとおりです。
R - 言葉が予約されています。予約されたキーワードは決して識別子として使用できません。それらはサーバーで使用するために予約されています。
U - その言葉は予約されていません。未予約語は、一部のコンテキストでは内部的に使用されますが、データベースオブジェクトの名前として使用できます。
T - このワードは内部的に使用されますが、関数またはタイプの名前として使用できます。
C - この単語は内部的に使用され、関数や型の名前として使用することはできません。
Advanced Serverの識別子とキーワードの詳細については、PostgreSQLのコアドキュメントを参照してください。
https://www.postgresql.org/docs/11/static/sql-syntax-lexical.html

目次

1はじめに
1.1新機能
1.2このガイドで使用される表記規則
1.3このガイドで使用されているその他の表記規則
1.4このガイドで使用されているサンプルについて
1.4.1サンプルデータベースの説明
2強化された互換性機能
2.1互換機能の有効化
2.2ストアドプロシージャ言語
2.3オプティマイザのヒント
2.4データ・ディクショナリ・ビュー
2.5 dblink_ora
2.6プロファイル管理
2.7組み込みパッケージ
2.8 Open Client Library
2.9ユーティリティ
2.10 ECPGPlus
2.11テーブルのパーティション化
3データベース管理
3.1構成パラメータ
3.1.1設定パラメータの設定
3.1.2構成パラメータの概要
3.1.3機能別の構成パラメータ
3.1.3.1上位パフォーマンス関連パラメータ
3.1.3.1.1 shared_buffers
3.1.3.1.2 work_mem
3.1.3.1.3 maintenance_work_mem
3.1.3.1.4 wal_buffers
3.1.3.1.5 checkpoint_segments
3.1.3.1.6 checkpoint_completion_target
3.1.3.1.7 checkpoint_timeout
3.1.3.1.8 max_wal_size
3.1.3.1.9 min_wal_size
3.1.3.1.10 bgwriter_delay
3.1.3.1.11 seq_page_cost
3.1.3.1.12 random_page_cost
3.1.3.1.13 effective_cache_size
3.1.3.1.14 synchronous_commit
3.1.3.1.15 edb_max_spins_per_delay
3.1.3.1.16 pg_prewarm.autoprewarm
3.1.3.1.17 pg_prewarm.autoprewarm_interval
3.1.3.2リソース使用量/メモリ
3.1.3.2.1 edb_dynatune
3.1.3.2.2 edb_dynatune_profile
3.1.3.3リソース使用量/ EDBリソースマネージャ
3.1.3.3.1 edb_max_resource_groups
3.1.3.3.2 edb_resource_group
3.1.3.4問合せのチューニング
3.1.3.4.1 enable_hints
3.1.3.5クエリのチューニング/プランナ・メソッドの構成
3.1.3.5.1 edb_custom_plan_tries
3.1.3.5.2 edb_enable_pruning
3.1.3.6レポート作成とロギング/ログの内容
3.1.3.6.1 trace_hints
3.1.3.6.2 edb_log_every_bulk_value
3.1.3.7監査設定
3.1.3.7.1 edb_audit
3.1.3.7.2 edb_audit_directory
3.1.3.7.3 edb_audit_filename
3.1.3.7.4 edb_audit_rotation_day
3.1.3.7.5 edb_audit_rotation_size
3.1.3.7.6 edb_audit_rotation_seconds
3.1.3.7.7 edb_audit_connect
3.1.3.7.8 edb_audit_disconnect
3.1.3.7.9 edb_audit_statement
3.1.3.7.10 edb_audit_tag
3.1.3.7.11 edb_audit_destination
3.1.3.7.12 edb_log_every_bulk_value
3.1.3.8クライアント接続のデフォルト/ロケールと書式設定
3.1.3.8.1 icu_short_form
3.1.3.9クライアント接続のデフォルト/文の動作
3.1.3.9.1 default_heap_fillfactor
3.1.3.9.2 edb_data_redaction
3.1.3.10クライアント接続のデフォルト/その他のデフォルト
3.1.3.10.1 oracle_home
3.1.3.10.2 odbc_lib_path
3.1.3.11互換性オプション
3.1.3.11.1 edb_redwood_date
3.1.3.11.2 edb_redwood_greatest_least
3.1.3.11.3 edb_redwood_raw_names
3.1.3.11.4 edb_redwood_strings
3.1.3.11.5 edb_stmt_level_tx
3.1.3.11.6 db_dialect
3.1.3.11.7 default_with_rowids
3.1.3.11.8 optimizer_mode
3.1.3.12カスタマイズされたオプション
3.1.3.12.1 custom_variable_classes
3.1.3.12.2 dbms_alert.max_alerts
3.1.3.12.3 dbms_pipe.total_message_buffer
3.1.3.12.4 index_advisor.enabled
3.1.3.12.5 edb_sql_protect.enabled
3.1.3.12.6 edb_sql_protect.level
3.1.3.12.7 edb_sql_protect.max_protected_relations
3.1.3.12.8 edb_sql_protect.max_protected_roles
3.1.3.12.9 edb_sql_protect.max_queries_to_save
3.1.3.12.10 edb_wait_states.directory
3.1.3.12.11 edb_wait_states.retention_period
3.1.3.12.12 edb_wait_states.sampling_interval
3.1.3.12.13 edbldr.empty_csv_field
3.1.3.12.14 utl_encode.uudecode_redwood
3.1.3.12.15 utl_file.umask
3.1.3.13グループ化されていない
3.1.3.13.1 nls_length_semantics
3.1.3.13.2 query_rewrite_enabled
3.1.3.13.3 query_rewrite_integrity
3.1.3.13.4 timed_statistics
3.2索引アドバイザー
3.2.1索引アドバイザー・コンポーネント
3.2.2索引アドバイザーの構成
3.2.3索引アドバイザーの使用
3.2.3.1 pg_advise_indexユーティリティの使用
3.2.3.2 psqlコマンドラインでのIndex Advisorの使用
3.2.4索引アドバイザーの推奨事項の確認
3.2.4.1 show_index_recommendations()関数の使用
3.2.4.2 index_advisor_logテーブルのクエリ
3.2.4.3 index_recommendationsビューのクエリ
3.2.5制限事項
3.3 SQLプロファイラ
3.4 pgsnmpd
3.4.1 pgsnmpdの設定
3.4.2リスナー・アドレスの設定
3.4.3 pgsnmpdの呼び出し
3.4.4 pgsnmpdヘルプの表示
3.4.5 pgsnmpdからの情報の要求
3.5 EDB監査ロギング
3.5.1監査ログ設定パラメータ
3.5.2監査するSQL文の選択
3.5.2.1データ定義言語およびデータ制御言語文
3.5.2.2データ操作言語ステートメント
3.5.3監査ログの有効化
3.5.4監査ログファイル
3.5.5エラー・コードを使用した監査ログのフィルタリング
3.5.6コマンド・タグを使用した監査ログのフィルタリング
3.5.7監査ログからのパスワードの修正
3.6 Unicode照合アルゴリズム
3.6.1基本的なUnicode照合アルゴリズムの概念
3.6.2 Unicodeのための国際コンポーネント
3.6.2.1ロケールの照合順序
3.6.2.2照合属性
3.6.3 ICUの照合順序の作成
3.6.3.1 COLLATIONの作成
3.6.3.2データベースの作成
3.6.3.3 initdb
3.6.4照合順序の使用
3.7カスタマイズ可能なWALセグメントファイルサイズ
4セキュリティ
4.1 SQLインジェクション攻撃からの保護
4.1.1 SQL /保護の概要
4.1.1.1 SQLインジェクション攻撃のタイプ
4.1.1.2 SQLインジェクション攻撃の監視
4.1.1.2.1保護されたロール
4.1.1.2.2攻撃試行統計
4.1.1.2.3攻撃試行クエリ
4.1.2 SQL / Protectの構成
4.1.2.1保護するロールの選択
4.1.2.1.1保護されたロールリストの設定
4.1.2.1.2保護レベルの設定
4.1.2.2保護されたロールの監視
4.1.2.2.1学習モード
4.1.2.2.2受動モード
4.1.2.2.3アクティブモード
4.1.3一般的な保守作業
4.1.3.1保護されたロールリストへのロールの追加
4.1.3.2保護されたロールリストからのロールの削除
4.1.3.3ロールの保護のタイプの設定
4.1.3.4保護関係リストからの関係の削除
4.1.3.5統計情報の削除
4.1.3.6不快なクエリの削除
4.1.3.7監視の無効化と有効化
4.1.4 SQL / Protectデータベースのバックアップと復元
4.1.4.1 SQL / Protectテーブルのオブジェクト識別番号
4.1.4.2データベースのバックアップ
4.1.4.3バックアップファイルからの復元
4.2仮想プライベートデータベース
4.3 sslutils
4.3.1 openssl_rsa_generate_key
4.3.2 openssl_rsa_key_to_csr
4.3.3 openssl_csr_to_crt
4.3.4 openssl_rsa_generate_crl
4.4データの改ざん
4.4.1リセッション・ポリシーの作成
4.4.2 ALTER REDACTION POLICY
4.4.3ドロップ・リセッション・ポリシー
4.4.4システムカタログ
4.4.4.1 edb_redaction_column
4.4.4.2 edb_redaction_policy
5 EDBリソースマネージャ
5.1リソースグループの作成と管理
5.1.1リソースグループの作成
5.1.2 ALTER RESOURCE GROUP
5.1.3 DROP RESOURCE GROUP
5.1.4リソース・グループへのプロセスの割当て
5.1.5リソース・グループからのプロセスの削除
5.1.6リソース・グループ内のプロセスの監視
5.2 CPU使用量の調整
5.2.1リソース・グループのCPUレート制限の設定
5.2.2例 - 単一グループ内の単一プロセス
5.2.3例 - 単一グループ内の複数のプロセス
5.2.4例 - 複数のグループの複数のプロセス
5.3ダーティバッファースロットル
5.3.1リソース・グループのダーティ・レート制限の設定
5.3.2例 - 単一グループ内の単一プロセス
5.3.3例 - 単一グループ内の複数のプロセス
5.3.4例 - 複数のグループの複数のプロセス
5.4システムカタログ
5.4.1 edb_all_resource_groups
5.4.2 edb_resource_group
6 libpq Cライブラリ
6.1 EnterpriseDB SPLでのlibpqの使用
6.2 REFCURSORのサポート
6.3配列バインディング
6.3.1 PQBulkStart
6.3.2 PQexecBulk
6.3.3 PQBulkFinish
6.3.4 PQexecBulkPrepared
6.3.5サンプルコード(PQBulkStart、PQexecBulk、PQBulkFinishを使用)
6.3.6サンプルコード(PQexecBulkPreparedを使用)
7デバッガ
7.1デバッガの設定
7.2デバッガの起動
7.3デバッガウィンドウ
7.4メインデバッガウィンドウ
7.4.1プログラム本体パネル
7.4.2タブパネル
7.4.3スタックタブ
7.5プログラムのデバッグ
7.5.1コードの実行
7.5.2ブレークポイントの使用
7.5.3コンテキスト内デバッグ用のグローバルブレークポイントの設定
7.5.4デバッガの終了
8パフォーマンスの分析とチューニング
8.1ダイナネ
8.1.1 edb_dynatune
8.1.2 edb_dynatune_profile
8.2 EDB待機状態
8.2.1 edb_wait_states_data
8.2.2 edb_wait_states_queries
8.2.3 edb_wait_states_sessions
8.2.4 edb_wait_states_samples
8.2.5 edb_wait_states_purge
9 EDBクローンスキーマ
9.1セットアッププロセス
9.1.1拡張機能とPL / Perlのインストール
9.1.2設定パラメータの設定
9.1.2.1パフォーマンスの構成パラメータ
9.1.2.2ステータスロギング
9.1.3 EDBクローン・スキーマのインストール
9.1.4外部サーバーおよびユーザー・マッピングの作成
9.1.4.1ローカル・クローニング機能用の外部サーバーおよびユーザー・マッピング
9.1.4.2リモート・クローニング機能用の外部サーバーおよびユーザー・マッピング
9.2 EDBクローンスキーマ関数
9.2.1 localcopyschema
9.2.2 localcopyschema_nb
9.2.3 remotecopyschema
9.2.4 remotecopyschema_nb
9.2.5 process_status_from_log
9.2.6 remove_log_file_and_job
10 PL / Java
10.1 LinuxへのPL / Javaのインストール
10.2 WindowsへのPL / Javaのインストール
10.3 PL / Javaの使用
11拡張されたSQLおよびその他のその他の機能
11.1コメント
11.2機能バージョン()の出力
11.3 SQL Serverのdboスキーマ
12システムカタログテーブル
12.1 edb_dir
12.2 edb_all_resource_groups
12.3 edb_password_history
12.4 edb_policy
12.5 edb_profile
12.6 edb_redaction_column
12.7 edb_redaction_policy
12.8 edb_resource_group
12.9 edb_variable
12.10 pg_synonym
12.11 product_component_version
13高度なサーバーキーワード