MathJax

MathJax-2

MathJax-3

Google Code Prettify

置頂入手筆記

EnterproseDB Quickstart — 快速入門筆記

由於考慮採用 EnterpriseDB 或是直接用 PostgreSQL 的人,通常需要一些入手的資料。這邊紀錄便提供相關快速上手的簡單筆記 ~ 這篇筆記以 資料庫安裝完畢後的快速使用 為目標,基本紀錄登入使用的範例:

2016年7月30日 星期六

EDB 的資源管理功能 - Resource Manager

EDB 公司的 PostgreSQL 企業版資料庫,除了原生於社群版本的記憶體配置參數 shared_buffer 可以設定之外,還提供了資料庫的 CPU、I/O 資源使用調控參數 edb_dynatune。更進一步,EDB 還能夠針對資料庫總資源進行分配調控。

Resource Manager 是 EDB 用來控制系統資源使用的功能:對於分配給 EnterpriseDB Postgres Advanced Server(EPAS)的作業系統資源。使用 Resource Manager 建立不同的資源使用規則(Resource Group),便能夠對
  1. 當下 session、
  2. 指定帳戶,或
  3. 指定資料庫
套用某一個資源使用規則。被加入同一個 Resource Group 的 Session / Role / Database,會共同限制分用這個 Resource Group 分配的系統資源。

Resource Manager 可以設定的資源使用規則分成
(1) CPU 資源使用,
(2) Shared Buffer 寫入速率,
兩類。以下便依照使用手冊進行演練一次

  1. 首先啟用 Resource Manager
[enterprisedb@localhost ~]$ vi $PGDATA/postgresql.conf
. . .
edb_max_resource_groups = 3    # 指定要設定幾組資源使用規則
. . .
[enterprisedb@localhost ~]$ pg_ctl restart

  1. 建立一個 Resource Group
edb=# CREATE RESOURCE GROUP resource_gp1;
CREATE RESOURCE GROUP

  1. 設定該 Resource Group 的 資源限制:cpu 設置參數是以比例設置,用小數點指定;shared budder 設置參數 dirty_rate_limit 的單位是 KB/sec
edb=# ALTER RESOURCE GROUP resource_gp1
SET cpu_rate_limit TO .3,
dirty_rate_limit TO 500;
ALTER RESOURCE GROUP

    在此設定 resource_gp1

  1. 檢視現有的 Resource Group 與其資源使用規則
edb=# SELECT * FROM  edb_resource_group;
   rgrpname   | rgrpcpuratelimit | rgrpdirtyratelimit
--------------+------------------+-------------------
 resource_gp1 |              0.3 |               500
(1 row)

  1. 建好資源分配群組後,就能將當下 session 、帳戶或 Database 加入一個 Resource Group 中

    1. 當下運行的 session 使用該一 Resource Group
SET edb_resource_group TO resource_gp1;

    1. 將帳戶 test_user 加入一個 Resource Group 中
ALTER USER test_user
SET edb_resource_group
TO resource_gp1;

    1. 將資料庫 testdb 加入一個 Resource Group 中
ALTER DATABASE testdb
SET edb_resource_group
TO resource_gp1;

  1. 檢視目前各個 Resource Group 資源使用狀況的指令
SELECT * FROM  edb_all_resource_groups;


測試

以下測試,在配有 1 core, 2.6 GHz 的 VM 上進行,並使用外部工具監控 CPU 使用量。

  1. CPU 限制的測試:利用 EDB 進行一樣大小的計算階乘,藉以觀察 CPU 使用狀況
edb=# SELECT 30000!;

另外開一個 psql,查看 Resource Group 使用狀況
edb=# \x
Expanded display is on.
edb=# SELECT * FROM edb_all_resource_groups;
-[ RECORD 1 ]----------------+------------------
group_name                   | resource_gp1
active_processes             | 1
cpu_rate_limit               | 0.3
per_process_cpu_rate_limit   | 0.298687974561313
dirty_rate_limit             | 500
per_process_dirty_rate_limit | 16777216

由此可以即時觀察到 CPU 使用率有被 Resource Group 規則限制住。

    再觀察 CPU 使用狀況
圖上顯示了兩組測試的CPU使用率的活動:
第一組是 CPU 利用率 100% 的活動,是在沒有啟用 Resource Group 前進行的 30000 階乘計算,
而第二組 CPU 使用率限制在 30% 的活動,則是在啟用 Resource Group 後進行的 30000 階乘計算

以上可見,Resource Manager 在 CPU 使用量控管的效果。

  1. 要測試 Resource Manager 對 Shared Buffer 的管理,則是利用運作時間來比較。
         為了測試方便,會以修飾語句 WITH (FILLFACTOR = 10)建立表格:該語句會使的 Shared Page 數量增加,以進行此部份 Shared Buffer 限制功能的測試

先建立表格
CREATE TABLE t1 (c1 INTEGER,
c2 CHARACTER(500))
WITH (FILLFACTOR = 10);

以輸入一萬筆資料的方式進行測試。先進行不設定 Resource Group 的部份。
edb=# \timing
Timing is on.
edb=# INSERT INTO t1 VALUES (generate_series (1,10000), 'aaa');
INSERT 0 10000
Time: 266.969 ms

接著,在這個 session 啟用剛剛建立的 Resource Group,並再次插入一樣大筆的資料:
edb=# SET edb_resource_group TO resource_gp1;
SET
Time: 0.341 ms
edb=# INSERT INTO t1 VALUES (generate_series (1,10000), 'aaa');
INSERT 0 10000
Time: 158725.910 ms

比較以上橘色反白所列時間,可見到 Resource Group 限制造成資料寫入的速率影響,由此可見 Resource Group 對 Shared Buffer 限制影響的是在資料寫入速率。

以上便是 EDB 的企業版的資源管理功能。該功能最簡單的應用,就是可以用來建立測試區 Database,並限制住該區的資源,避免去影響到資料庫於線上正式的工作。

2016年7月29日 星期五

PostgreSQL 9.5 的 pg_rewind 工具操作筆記

設置 Streaming Replication 的用途主要是以複寫資料庫作為備份,在工作主機下線時,可以切換(promoting)到其他備份頂替工作。

但是切換後,回復 Streaming Replication 就是首要工作。有時候,這個設置就會變得有點累人:舊的工作機資料已經沒辦法直接和現在運作的資料庫銜接,需要重新從全備份開始,設置 Streaming Replication 才行。資料量大的狀況下,從全備份開始就會耗費不短的時間。
Note:由於 PostgreSQL 的交易紀錄有標記 Timeline,Promoting 之後,Timeline 便脫勾了。因此 Promoting 之後的新舊工作機資料,無法用來建立 Streaming Replication。

在 PostgreSQL 9.5 版,提供了一個叫 pg_rewind 的工具,這工具便能善用舊的工作機資料,和目前線上工作的資料庫銜接資料差異。使的再次建立 Streaming Replication 不用從 pg_basebackup 開始,減輕再次建置 Streaming Replication  的麻煩,更快恢復 Streaming Replication。

pg_rewind 利用比較新舊工作機的交易日誌 WAL,標記兩份資料庫 $PGDATA 的差異並補上,於後就可以啟動 Streaming Replication。

以下練習,將在同一台電腦上開啟兩個之間有 streaming replication 的 Postgres cluster 進行演練。演練中也加上 Physical Replication Slot,便不再去特別點出。

以下為這次練習的設置環境

DB Cluster 資料夾位置
port
WAL archived 目錄
工作的 instance db1
/home/postgres/pgsql/db1/
5432
/home/postgres/pgWALs/db1/
備份的 instance db2
/home/postgres/pgsql/db2/
5433
/home/postgres/pgWALs/db2/


1) Rewinding 相關前置設定
要使用 pg_rewind 功能,需要在設定檔中啟用交易日誌檔 WAL 相關的功能:這需要在建立 Streaming Replication 之前就設置好。
/home/postgres/pgsql/db1/postgresql.conf
port = 5432
wal_level = hot_standby
full_page_writes = on     # Rewinding 所需參數
wal_log_hints = on        # Rewinding 所需參數
archive_mode = on       # Rewinding 所需參數
archive_command = 'cp %p /home/postgres/pgWALs/db1/%f'   # Rewinding 所需參數
max_wal_senders = 3
max_replication_slots = 1
hot_standby = on          # 在 Standby Instance 上面才會載入

2) 接著便繼續完成 Streaming Replication 的設置
[postgres@pgvm ~]$ # db1 的設定
[postgres@pgvm ~]$ echo "host  replication  repuser  127.0.0.1/32  trust" >> /home/postgres/pgsql/db1/pg_hba.conf
[postgres@pgvm ~]$ pg_ctl -D ~/pgsql/db1/ restart
[postgres@pgvm ~]$ psql -p 5432 -c "CREATE USER repuser WITH REPLICATION;"
[postgres@pgvm ~]$ psql -p 5432 -c "SELECT pg_create_physical_replication_slot('myslot1');"
[postgres@pgvm ~]$ # 建立 db2
[postgres@pgvm ~]$ pg_basebackup -h 127.0.0.1 -p 5433 -D ~/pgsql/db2 -U repuser -v -P
[postgres@pgvm ~]$ vi /home/postgres/pgsql/db2/postgresql.conf
port = 5433
archive_command = 'cp %p /home/postgres/pgWALs/db2/%f'
[postgres@pgvm ~]$ vi /home/postgres/pgsql/db2/recovery.conf
standby_mode = 'on'
primary_conninfo = 'host=127.0.0.1 port=5432 user=repuser'
restore_command = 'cp /home/postgres/pgWALs/db1/%f %p'
primary_slot_name = 'myslot1'
trigger_file = '/home/postgres/pg_trigger'
[postgres@pgvm ~]$ pg_ctl -D ~/pgsql/db2/ start

以上便將 Streaming Replication 建立完畢。不熟悉的人,可以參考另一篇 Streaming Replication 的筆記。

3) 在已經建立好的 Streaming Replication 中,在備份程序上執行 promote,使的 streaming replication 結束複寫連線(切換 Timeline),並使的備份機可以接替工作機運作:
[postgres@pgvm ~]$ pg_ctl -D ~/pgsql/db2/ promote

由於現在是執行 promote,db1 其實還在運作。但一般在切換後,db1 便不再工作,而現在db1 還在執行,所以在此把 db1 關掉。
[postgres@pgvm ~]$ pg_ctl -D ~/pgsql/db1/ stop

4) 執行 pg_rewind 之前 ...
一般來說,db2 會工作一段時間之後,才會去進行回復 Streaming Replication 的設置(因為不可能資料庫異常一發生,就馬上去處理 … ),因此 db02 已經會產生一些交易了。於是在這裡我產生一些資料到 db2 裡面,模擬執行 pg_rewind 之前已經產生的交易。
[postgres@pgvm ~]$ psql -p 5433 -c "CREATE TABLE test2 AS SELECT * FROM pg_description, pg_class;"

這個指令在空的 instance 上,會產生約莫 1GB 的資料大小 ...,足以模擬前述狀況了。

5) pg_rewind 前置作業
由於 pg_rewind 需要比對新舊資料庫的 WAL 交易日誌,找出分歧點,並設置 Timeline。所以在執行 pg_rewind 之前,我們需要提供足夠的 WAL 檔案。
[postgres@pgvm ~]$ # 把 db1 切換前產生的 WAL 移回 db1/pg_xlog
[postgres@pgvm ~]$ mv ~/pgWALs/db1/* ~/pgsql/db1/pg_xlog/
[postgres@pgvm ~]$ # 把 db2 切換後產生的 WAL 「複製到」
[postgres@pgvm ~]$ # db1/pg_xlog 裡(不是 db2/pg_xlog/!)
[postgres@pgvm ~]$ cp ~/pgWALs/db2/* ~/pgsql/db1/pg_xlog/

上面複製了新舊的 WAL 備份檔到 db1 的 pg_xlog/。這是為了提供追溯比對交易分歧點之用。目前沒有方式估計究竟需要回溯多久的 WAL 備份檔,只知道越快進行 pg_rewind,所需的 WAL archives 檔越少。
另外,運作中的 DB Master (db2)的 pg_xlog/ 目錄會清理(Rotation),所以得將 db2 的 WAL archives 都塞到舊的 DB Master (db1)的 pg_xlog/ 裡面,而非複製回 db2 的 pg_xlog/ 裡。

6) 執行 pg_rewind:這個指令,要在 db1 所在的主機上執行,並指定到連線到目前工作中的 db2
[postgres@pgvm ~]$ pg_rewind -D ~/pgsql/db1/ --source-server="host=localhost port=5433 user=postgres dbname=postgres" -P

這個過程,pg_rewind 會從原先留在 db1、db2 雙邊 pg_xlog/ 裡,最新的 WAL 檔開始回溯比較,再比較到新舊 Master 的 WAL archives(剛剛已經都被我們複製到 db1/pg_xlog/ 裡面了),直至分歧點,放上標籤,並開始複製需要的「差異資料」內容。

7) 修改 db1 設定檔內容:pg_rewind 會連同設定檔一起「同步」到 db1,所以 db1 上舊的設定檔就被 db2 的蓋掉了,於是要作一些必要調整。

/home/postgres/pgsql/db1/postgresql.conf
port = 5432
archive_command = 'cp %p /home/postgres/pgWALs/db1/%f'

把 db1 上的 recovery.done 更名為 reocvery.conf 並修改內容
[postgres@pgvm ~]$ mv ~/pgsql/db1/recovery.done ~/pgsql/db1/recovery.conf
[postgres@pgvm ~]$ vi ~/pgsql/db1/recovery.conf
primary_conninfo = 'host=127.0.0.1 port=5433 user=repuser'
restore_command = 'cp /home/enterprisedb/pgWALs/db2/%f %p'

8) 啟動 db1,成為 db2 的複寫備份
[postgres@pgvm ~]$ pg_ctl -D ~/pgsql/db1/ start

這過程中,如同一般 Streaming Replication 一樣,會進行交易日誌的重演(Replay),然後進入同步的唯讀模式

9) 檢查 Streaming Replication 狀態
就像檢視一般 Streaming Replication 同步一樣,連線到 db2 上檢視 Streaming Replication
[postgres@pgvm ~]$ psql -p 5433 -c "SELECT * FROM pg_stat_replication;"

檢視切換資料庫後的狀況
  • db1 目前狀況工作程序
[postgres]$ pg_controldata -D /home/postgres/pgsql/db1/ | grep "cluster state"
Database cluster state:               in archive recovery

  • db2 instance(現在是工作機了)
[postgres]$ pg_controldata -D /home/postgres/pgsql/db2/ | grep "cluster state"
Database cluster state:               in production

以上可見, Streaming Replication 已經再次設置成功了。
以上就是 pg_rewind 的操作範例。


最後再提醒一下,
(1)要使用 pg_rewind 功能,需要在新舊 Master 資料庫上,有分別留下 WAL 交易日誌,才能正常操作。
(2)此外,pg_rewind 還不會回溯到 WAL Archives,因此資料庫脫勾時間過得久了,pg_rewind 就不夠幫忙了:需要把「足夠的」舊資料庫 WAL 交易日誌檔,「以及新資料庫的 WAL 交易日誌檔」,放進去準備要進行 Rewinding 的 pg_xlog/ (Old Master)裡面才行。至於這個「足夠」是多少... 可能得等其他專家來解謎了。或是期待 pg_rewind 可以提供追溯 WAL archive 目錄的功能了。
(3)其實這個工具,在 PostgreSQL 9.5 之前就存在了,只是還沒正式納入 PostgreSQL 工具裡面而已。

雖然目前有上述複製 WAL 檔案的小小不便,但相較於之前都得把 db1 打掉重練,有了這個 pg_rewind,看起來就好多了...


參考資料


相關:Logical Decoding 功能

2016年7月26日 星期二

PL/PerlU 練習筆記

PostgreSQL提供內嵌 Perl、Python ... 等 Script 作為它的 Stored Function,稱作 PL/Perl、PL/Python ...。在此演練一個 PL/Perl 的例子。

在此之前,在這裡先描述一下,PostgreSQL 的擴充模組 Procedural Language(PL/***)。它的設計理念是只為資料庫增加一般程式語言的撰寫風格。因此預設狀況下,這些 PL/*** 只能接觸到資料庫裡面的物件,無法跨出資料庫程序可控制的外部環境,像是存取作業系統目錄、寄一封信之類的。
然而,在 PostgreSQL 裡還是能夠用 PL/*** 「接觸」外面的;這些 Procedural Language,在 PostgreSQL 的術語,被稱為 Untrusted Language,例如 PL/PerlU,而這些 Untrusted Language 這基本上就是完全功能的 Perl 了。
由於 Untrusted Language 能存取外部環境,所以只有資料庫的 Super User  帳戶才能執行這些 Untrusted Language。

下面的小小練習,便把一般 Perl Script 以及相對應的 PL/PerlU Script 相互對照。

2016年7月21日 星期四

EDB 的 Statspack 報表 - Dynamic Runtime Instrumentation Tools Architecture

PostgreSQL 原生的資料庫監控功能,大多散布在各式系統資料表裡面;此外,有些內建系統表還沒有設置,有時也需要額外安裝,像是 pg_stat_statements;更甚者,可能還需要確認發行版有沒有支援(Dynamic Tracing)。截至 9.5 版,還沒有原生於 PostgreSQL 簡單易用的整合的效能監控工具。

對於資深的 Oracle 使用者,常常會提到 Oracle 有很多效能監控工具,像是常會提到 Oracle Statspack / Oracle AWR,並尋找在 PostgreSQL 裡面相似的工具。

EnterpriseDB 在其企業版資料庫中提供一個叫 Dynamic Runtime Instrumentation Tools Architecture(EDB DRITA)的功能,可以用來衡量資料庫運行效能的紀錄。DRITA 其實是將現有的 PostgreSQL 資料庫效能監控工具(例如  pg_stat_statements,或是 pg_buffercache),並以一個 Oracle 資料庫的用戶所習慣的統合性報表格式呈現。

DRITA 功能不用像 Oracle Statspack/AWR 一樣,先設置專屬空間存放,而是直接存放在同一個 Postgres Instance 裡。


DRITA 的使用方法有兩種:
(1) 在一個 Session 當中,執行兩次系統資訊收集(起、迄 DRITA 快照),然後用這兩次快照,產生快照間資料庫活動的報告(使用上,與 Oracle Statspack 相仿)

(2) 在一段期間中,產生些許系統資訊快照,然後依照需要,選取數個相連續的快照,彙整出資料庫活動的報告

在此以 EDB Postgres Advanced Server 9.5 進行演練:

首先,要啟用 DRITA 功能,有兩種方式。
  • 啟用 postgresql.conf 裡面的參數 timed_statistics(on),並重新載入
  • 這個參數也可以只在一個 Session 當中啟用,如下列指令:
edb=# SET timed_statistics TO true;
SET

用法:
(1) 在一個 Session 中執行:
  • 手動執行一次進行 DRITA 快照(第一次)
edb=# SELECT * FROM edbsnap();
       edbsnap      
----------------------
 Statement processed.
(1 row)

  • 一些資料庫活動:如,執行一個指令(計算階乘)
edb=# select 10000!;

  • 等到所需要觀察、了解的資料庫活動告一段落,再執行一次 DRITA 快照
edb=# SELECT edbsnap();
       edbsnap      
----------------------
 Statement processed.
(1 row)

  • 先來觀察一下,目前累積的快照列表
edb=# SELECT get_snaps();
         get_snaps        
-----------------------------
1 20-JUL-16 07:58:24.869467
2 20-JUL-16 08:10:30.570358
(2 rows)

上面便已經有足夠快照,來列出 Wait Event 報告了。

這個部份,有三種報告模式:
  • sys_rpt(起始快照ID, 末快照ID, 列舉筆數) 用來列舉 wait events
  • sessid_rpt(起始快照ID, 末快照ID, pid) 用來列舉某個 Process ID 活動時造成的 wait events
  • sesshist_rpt(快照ID,pid) 用來列舉指定快照中,紀錄到的某 Process ID 活動
以下列出執行範例,指定當前 Session 的活動:
edb=# SELECT sys_rpt(1,2,5);
                                  sys_rpt                                 
-----------------------------------------------------------------------------
 WAIT NAME                                COUNT      WAIT TIME       % WAIT
---------------------------------------------------------------------------
 db file read                             70         0.078344        61.42
 query plan                               14         0.048646        38.14
 db file extend                           52         0.000559        0.44
(5 rows)

edb=# SELECT sessid_rpt(1,2,pid) FROM pg_stat_activity WHERE pid = pg_backend_pid();
                                            sessid_rpt                                            
-----------------------------------------------------------------------------------------------------
 ID    USER       WAIT NAME                      COUNT TIME(ms)     % WAIT SES % WAIT ALL
---------------------------------------------------------------------------------------------------
 1919 enterprise db file read                   50    0.034929     70.32      70.32
 1919 enterprise query plan                     14    0.014214     28.62      28.62
 1919 enterprise db file extend                 50    0.000528     1.06       1.06
(5 rows)

edb=# SELECT sesshist_rpt(1,pid) FROM pg_stat_activity WHERE pid = pg_backend_pid();
                                                 sesshist_rpt                                                
-----------------------------------------------------------------------------------------------------------------
 ID    USER      SEQ   WAIT NAME                ELAPSED(ms)  File   Name                 # of Blk   Sum of Blks
---------------------------------------------------------------------------------------------------
 1919 enterprise 1     query plan               9            0      N/A                  0          0         
 1919 enterprise 1     query plan               9            0      edb_password_history 0          0         
 1919 enterprise 1     query plan               9            0      edb_password_history 0          0         
 1919 enterprise 1     query plan               9            0      edb_password_history 0          0         
 1919 enterprise 1     query plan               9            0      edb_profile          0          0         
(... 以下略)

註:
除了上述函數觀看 Wait event 之外,EnterpriseDB 裡有提供對應 Oracle 資料庫中 V$SYSTEM_EVENTV$SESSION_WAIT 以及 V$SESSION_WAIT_HISTORY 的 View,分別稱作 edb$system_waits、edb$session_waits 及 edb$session_wait_history,用來觀察當前 Wait event 狀況。相關資訊參考 8.12 Catalog Views 以及 8.11 Event Descriptions


(2) 看總結報告
以下函數,可以指定中長期累積 DRITA 快照報告
edb=# SELECT edbreport(1, 4);\g /path/to/output/file

在 psql 界面下,上面會把報告內容輸出到 /path/to/output/file 所指定檔案位置。

以下列舉出 edbreport(起始快照ID, 末快照ID) 報告內容類型:
Size of the current database
     Tablespace: list, size and owner

Schema: list, size and owner
Top 10 Relations by pages
Top 10 Indexes by pages
Top 10 Relations by DML
DATA from pg_stat_database
DATA from pg_buffercache not included because pg_buffercache is not installed
DATA from pg_stat_all_tables ordered by seq scan
DATA from pg_stat_all_tables ordered by rel tup read
DATA from pg_statio_all_tables
DATA from pg_stat_all_indexes
DATA from pg_statio_all_indexes
System Wait Information
Database Parameters from postgresql.conf

整份報表內容有點長,在此就不提供內容,有興趣可以到使用手冊中查看,並自己試一試。
報表內容描述
Size of the current database
     Tablespace: list, size and owner

Schema: list, size and owner
當前連線資料庫的 database、tablespace、schema 的大小
Top 10 Relations by pages
大小為前十大的資料表格
Top 10 Indexes by pages
大小為前十大的 Index 表
Top 10 Relations by DML
資料更動活動最頻繁的十個資料表格
DATA from pg_stat_database
目前資料庫資訊:當前連線數、交易活動的 Commit/Rollback 次數、硬碟 Blocks 存取次數資訊、Buffer Cache 的 Hit Ratio
DATA from pg_buffercache
列出佔前十多 Buffer Cache 大小的表格
DATA from pg_stat_all_tables ordered by seq scan
依照 Sequential Scan 次數排列的表格列表
DATA from pg_stat_all_tables ordered by rel tup read
依照被撈的資料筆數排列的表格列表(資訊
DATA from pg_statio_all_tables
表格在硬碟上的 Blocks 被讀取的數量的資訊
DATA from pg_stat_all_indexes
Index 被使用的次數資訊
DATA from pg_statio_all_indexes
Index 表在硬碟上的 Blocks 被讀取的數量的資訊
System Wait Information
Wait Events 的類型發生的次數
Database Parameters from postgresql.conf
當前 postgresql.conf 設定檔參數列表

在這裡列出可以注意的幾點:
  • DRITA 報告是針對一個 PostgreSQL Database 收集的,並不是收集整個 PostgreSQL Instance 的資訊。

  • 這份報表,主要收集的是表格與 Index 的資訊

  • 列舉 postgresql.conf 當前參數,可以由以下兩種方式達成
edb=# SELECT name,unit,boot_val,setting,current_setting(name) FROM pg_settings;
edb=# SHOW all;

  • 上面標明紅色的部份「DATA from pg_buffercache not included because pg_buffercache is not installed」,說明 pg_buffercache 這個套件沒有被啟用;需要的話,在收集 DRITA 快照前,先用以下指令,便能夠啟用它:
edb=# CREATE EXTENSION pg_buffercache;

  • 除了 edbreport 函數之外,EDB 再特別對 DRITA 報告內五類資訊,提供能夠單獨取得報告的函數,並且能用分別五個函數去存取:
子報表函數
對應 edbreport 報表部份
stat_db_rpt
DATA from pg_stat_database
stat_tables_rpt
DATA from pg_stat_all_tables ordered by seq scan
DATA from pg_stat_all_tables ordered by rel tup read
statio_tables_rpt
DATA from pg_statio_all_tables
stat_indexes_rpt
DATA from pg_stat_all_indexes
statio_indexes_rpt
DATA from pg_statio_all_indexes

使用方法,可以參考使用手冊


以上大致演練過 DRITA 工具的功能了。最後是清理掉 DRITA 快照資料的方式:
  • 指定清掉某個範圍的 DRITA 快照:
edb=# SELECT purgesnap(1, 2);
             purgesnap            
------------------------------------
 Snapshots in range 1 to 2 deleted.
(1 row)

  • 清除所有 DRITA 快照(重設 DRITA 資料)
edb=# SELECT truncsnap();
      truncsnap
----------------------
 Snapshots truncated.
(1 row)


與  Oracle Statspack / Oracle AWR 的功能相比較,就我目前所知,目前還沒有像 Oracle AWR 一樣,自動產生快照以及設定快照保存策略等功能。有需要的話,就得自己去設置定時收集與清理 DRITA 快照了。


報表內容,目前(9.5 版)與 Oracle 的工具相比,還差一點東西:例如 top sql(吃資源的 SQL 指令)、資料庫參數的使用狀況(例如,Oracle 上能顯示 SGA 及 PGA 的記憶體使用狀況,但在 EDB 裡面沒有這種對等資訊)等;此外, DRITA 功能也沒有紀錄 OS 功能資訊,這需要額外工具才行(例如 Postgres Enterprise ManagerOpen PostgreSQL Monitoring 等)


參考:
使用手冊
其他使用筆記



其他資訊:
在 PostgreSQL 9.6 原生版,將要有內建的 wait event 監控功能,在下面便是一篇相關功能介紹

什麼是Oracle Statspack/Oracle AWR