GP DBA基本操作

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