GP DBA基本操做

一、查看队列状况

SELECT * FROM gp_toolkit.gp_resqueue_status;

若是出现了资源占用大于1.1 e+11SQL，则可能存在不合理执行计划的SQL， 基本跑不出来， 库也会很卡。

二、查看用户归属的队列

select * from gp_toolkit.gp_resq_role ;

 

三、查看某帐号下运行中sql

SELECT * from pg_stat_activity  where current_query <> '<IDLE>' and waiting ='f' and usename = 'etl_user';

全部帐号都有权限查看。

Query_start字段就是SQL真正启动时间点

 

四、等待中sql

SELECT * from pg_stat_activity  where current_query <> '<IDLE>' and waiting ='t';

 

五、检查执行时间超长的SQL

执行以下SQL 检查是否有select  * from pg_stat_activity where current_query<>'<IDLE>' and query_start < now() - interval '10 mins';

 

六、终止sql

----终止sql的语句， 下语句的数字是procid，能够经过上一页的语句查到:

      select pg_cancel_backend(27334);

-----终止sql的同时终止会话。

      select pg_terminate_backend(27334);

超级帐号才有终止权限， 如：super_user帐号

      必定要在数据库里终止一个SQL或任务， 由于在ＢＤＩ界面终止一个外部程序任务事实上ＳＱＬ没有终止，还继续运行。

 

七、执行计划：explain  SQL

     执行SQL前用explain  SQL 查看执行计划

    若是执行计划存在针对很大的表作Broadcast Motion 或Nested Loop步骤则 不合理， 则尝试如下动做：

    执行收集表的统计信息语句：ANALYZE 表名; 

     通常analyze 一天的分区: ANALYZE 表名_1_prt_data_part_20150305;

     “_1_prt_”是数据库分区表名固定段。 “data_part_”是咱们自动脚本里生成的分区名前缀。

      从新看执行计划，若是合理了，则表明源表缺乏统计信息致使执行计划不合理。 只有在表的数据量发生大变化时或重来没收集过期须要作一次收集。

 

八、执行计划：explain  SQL

    ANALYZE完源表从新看执行计划，若是还不合理，执行一下set optimizer to on；  更换一个执行计划生成器。

    从新生成执行计划。若是合理了，则后续在在ＳＱＬ前加上：set optimizer to on；  不要全部SQL加这个，由于该特性未发布。

    若是还不合理， 则须要优化SQL， 即把ＳＱＬ由多张表关联拆开。

 

九、后台运行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

 

十、报内存不足

    sql可用内存不够大时，能够用如下方法临时加大。 如选择的表分区数不少可能会报内存不足，可使用该方法。例如：

    SET statement_mem='500MB';

    SELECT * FROM my_big_table WHERE column='value' ORDER BY id limit 10;

    RESET statement_mem;

 

十一、left  join 右表很是庞大

      若是之后业务场景中确实存在left join 右表很是庞大，而且关联字段重复值比较高，能够采起如下方式：

         1，按照关联字段进行数据打散

         2，在会话级别设置如下参数

              set max_statement_mem='8GB'

              set statement_mem='4GB'

              set gp_workfile_per_query=0

 

十二、使用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;

 

 1三、不要建立default分区

       不要建立default分区， 更不要把大量数据放到default分区， 由于default分区在每一个sql都会扫描。

 

1四、找出须要作vacuum的表

        select * from gp_toolkit.gp_bloat_diag ;

        这些表须要作空间回收操做

        通常vacumm 和analyze一块儿执行: vacuum analyze 表名

 

1五、找出没有统计信息须要作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(表名, 日期)收集一个分区表信息。

 

1六、常常检查数据库状态   gpstate -e

 

1七、常常用nmon命令检查seg节点资源占用率

 

1八、常常检查各机器/data目录 gpssh -f allhosts

 

1九、常常检查各模式下表数量，总共不要超过10万 

select schemaname,count(*) from gp_tables group by schemaname order by 2 desc