1、查看队列情况
SELECT * FROM gp_toolkit.gp_resqueue_status;
如果出现了资源占用大于1.1 e+11SQL，则可能存在不合理执行计划的SQL， 基本跑不出来， 库也会很卡。
2、查看用户归属的队列
select * from gp_toolkit.gp_resq_role ;
3、查看某账号下运行中sql
SELECT * from pg_stat_activity where current_query <> ‘<IDLE>‘ and waiting =‘f‘ and usename = ‘etl_user‘;
所有账号都有权限查看。
Query_start字段就是SQL真正启动时间点
4、等待中sql
SELECT * from pg_stat_activity where current_query <> ‘<IDLE>‘ and waiting =‘t‘;
5、检查执行时间超长的SQL
执行如下SQL 检查是否有select * from pg_stat_activity where current_query<>‘<IDLE>‘ and query_start < now() - interval ‘10 mins‘;
6、终止sql
----终止sql的语句， 下语句的数字是procid，可以通过上一页的语句查到:
select pg_cancel_backend(27334);
-----终止sql的同时终止会话。
select pg_terminate_backend(27334);
超级账号才有终止权限， 如：super_user账号
一定要在数据库里终止一个SQL或任务， 因为在ＢＤＩ界面终止一个外部程序任务事实上ＳＱＬ没有终止，还继续运行。
7、执行计划：explain SQL
执行SQL前用explain SQL 查看执行计划
如果执行计划存在针对很大的表做Broadcast Motion 或Nested Loop步骤则 不合理， 则尝试以下动作：
执行收集表的统计信息语句：ANALYZE 表名;
一般analyze 一天的分区: ANALYZE 表名_1_prt_data_part_20150305;
“_1_prt_”是数据库分区表名固定段。 “data_part_”是我们自动脚本里生成的分区名前缀。
重新看执行计划，如果合理了，则代表源表缺少统计信息导致执行计划不合理。 只有在表的数据量发生大变化时或重来没收集过时需要做一次收集。
8、执行计划：explain SQL
ANALYZE完源表重新看执行计划，如果还不合理，执行一下set optimizer to on； 更换一个执行计划生成器。
重新生成执行计划。如果合理了，则后续在在ＳＱＬ前加上：set optimizer to on； 不要所有SQL加这个，因为该特性未发布。
如果还不合理， 则需要优化SQL， 即把ＳＱＬ由多张表关联拆开。
9、后台运行SQL， 免输入密码
nohup psql -h 10.154.147.130 -d ‘dbname=gpadmin user=etl_user password=etl_pppp‘ -f /home/bdiunivers/aa.sql -L /home/bdiunivers/aa.log &
用psql 命令跑aa.sql文件，如果文件里有多个SQL， 想一个SQL报错后不往下跑， 则在aa.sql 文件的第一行加上下面内容， 行末没有分号 \set ON_ERROR_STOP
10、报内存不足
sql可用内存不够大时，可以用以下方法临时加大。 如选择的表分区数很多可能会报内存不足，可以使用该方法。例如：
SET statement_mem=‘500MB‘;
SELECT * FROM my_big_table WHERE column=‘value‘ ORDER BY id limit 10;
RESET statement_mem;
11、left join 右表非常庞大
如果以后业务场景中确实存在left join 右表非常庞大，并且关联字段重复值比较高，可以采取以下方式：
1，按照关联字段进行数据打散
2，在会话级别设置以下参数
set max_statement_mem=‘8GB‘
set statement_mem=‘4GB‘
set gp_workfile_per_query=0
12、使用super_user创建外部表的过程：
a. 删除并重建err表。
drop table if exists masadw .err_ext_表名;
CREATE TABLE masadw.err_ext_表名 ( cmdtime timestamp with time zone, relname text, filename text, linenum integer, bytenum integer, errmsg text, rawdata text, rawbytes bytea) DISTRIBUTED RANDOMLY;
b.把err表修改owner为etl_user
ALTER TABLE masadw.err_ext_表名 OWNER TO etl_user;
c. 创建外部表：
drop EXTERNAL TABLE if exists masadw.ext_表名;
CREATE EXTERNAL TABLE masadw.ext_表名 ( time_id integer, area_id integer, grp_code character varying(50), cust_id bigint, usr_id bigint, svc_code character varying(50)) LOCATION ( ‘gphdfs://hacluster/tmp/zht/NEW_表名.TXT‘) FORMAT ‘text‘ (delimiter E‘‘ null E‘‘ escape E‘OFF‘)ENCODING ‘UTF8‘LOG ERRORS INTO masadw.err_ext_表名 SEGMENT REJECT LIMIT 10 PERCENT;
d.把外部表修改owner为etl_user:
ALTER EXTERNAL TABLE masadw.ext_表名 OWNER TO etl_user;
13、不要创建default分区
不要创建default分区， 更不要把大量数据放到default分区， 因为default分区在每个sql都会扫描。
14、找出需要做vacuum的表
select * from gp_toolkit.gp_bloat_diag ;
这些表需要做空间回收操作
一般vacumm 和analyze一起执行: vacuum analyze 表名
15、找出没有统计信息需要做ANALYZE的表
select ‘ANALYZE ‘||smischema||‘.‘||smitable||‘;‘ from gp_toolkit.gp_stats_missing where smisize = ‘f‘ and smitable like ‘%_1_prt_%‘ and smitable not like ‘err_%‘ and smitable not like ‘ext_%‘ and smitable like ‘%201503%‘ order by smitable limit 10;
所有存储过程在最后增加GPDB. analyze_partition(表名, 日期)收集一个分区表信息。
16、经常检查数据库状态 gpstate -e
17、经常用nmon命令检查seg节点资源占用率
18、经常检查各机器/data目录 gpssh -f allhosts
19、经常检查各模式下表数量，总共不要超过10万
select schemaname,count(*) from gp_tables group by schemaname order by 2 desc