查看原文
其他

打开这份指南,数据库运维也能优雅、简单!

云和恩墨 2024-03-03

对于常规数据库的运维监控来说,如何能够快速简洁的发现问题,直达问题本质并解决常见问题,是 Bethune 的安身立命之本。
简约,优雅,专业,直抵本心,这是用户对 Bethune 的评价。

Bethune X 功能强大,许多特性能够很好地解决DBA日常运维中遇到的问题,本文选取几个场景,介绍如何利用 Bethune X 为你的数据库多添一道保障!



阅读提示:


Part 1:通过空间监控功能分析 AUD$ 的空间

Part 2:通过下钻功能探查数据库深层问题

Part 3:通过SQL自定义监控实现主机日志监控





在Bethune的监控中,针对表空间的空间增长,具有一个曲线监控展示,用于显示空间都变化趋势。
例如如下视图,展示了SYSTEM表空间高达 87%的空间被 AUD$ 占用:

AUD$ 存储的是数据库的审计信息,已经占用了 8G 的存储空间,如果这些信息不被使用,可以考虑通过TRUNCATE清除:
SQL> select segment_name,bytes/1024/1024 MB from dba_segments where segment_name='AUD$';

SEGMENT_NAME                   MB
------------------------------ ----------
AUD$                     8154

SQL>
 truncate table sys.aud$;

Table truncated.

SQL>
 select segment_name,bytes/1024/1024 MB from dba_segments where segment_name='AUD$';

SEGMENT_NAME                   MB
------------------------------ ----------
AUD$                    .0625

这个数据库版本是 11.2.0.4 ,清理空间之后,Bethune 的空间展示变化如下图所示:

Bethune ,空间展示还可以更进一步!


在 Bethune 的监控预警中,当问题具有可追溯性时,在告警右侧就会有一个可点击的小图标,帮助我们进一步分析问题。
下图中,系统监控发现了长事务,对于OLTP系统,长时间运行的 DML 操作是必须要要多加关注的:

进一步的点击追溯,系统会呈现出详细的信息,例如用户和SQL信息等:


点击SQLID,就进入了SQL和执行计划页面。一目了然的可以看到这个 DELETE 语句,因为全表扫描的执行计划而执行缓慢,极度影响性能:


事实上,到这里 Bethune 就已经完成了整个问题的预警、根因追溯。接下来就应该是 DBA 们大显身手的地方了。
注意:监控是发现问题的手段,而如何解决问题,解决问题的时间,则要由 DBA 来决策和抉择。
DBA 可以根据数据和查询字段的选择性,来判断是否可以通过创建索引提高效率。
并且,不能在业务高峰期间进行索引创建操作,避免引发系统竞争。
SQL> select count(*) from TP_SYS_FIELDHISTORY;

  COUNT(*)
----------
   2430863

SQL> select count(distinct(RECORDID)) from CUST_U_ENMOTECH.TP_SYS_FIELDHISTORY;

COUNT(DISTINCT(RECORDID))
-------------------------
          1944293


SQL> explain plan for delete from tp_sys_fieldhistory where recordid=:"SYS_B_0"
  2  ;

Explained.

SQL> set serveroutput on

SQL> select * from table(dbms_xplan.display());

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2894643821

------------------------------------------------------------------------------------------
| Id  | Operation       | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT   |             |     1 |    42 | 10379   (1)| 00:02:05 |
|   1 |  DELETE        | TP_SYS_FIELDHISTORY |   |   |        |      |
|*  2 |   TABLE ACCESS FULL| TP_SYS_FIELDHISTORY |     1 |    42 | 10379   (1)| 00:02:05 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("RECORDID"=:SYS_B_0)

14 rows selected.

SQL> create index idx_tpsys_fldhist_rcd on TP_SYS_FIELDHISTORY(RECORDID) compute statistics;

Index created.

SQL> explain plan for delete from tp_sys_fieldhistory where recordid=:"SYS_B_0";

Explained.

SQL> select * from table(dbms_xplan.display());

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3460354814

-------------------------------------------------------------------------------------------
| Id  | Operation      | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT  |              | 1 |    42 | 3   (0)| 00:00:01 |
|   1 |  DELETE       | TP_SYS_FIELDHISTORY   |   |   |        |      |
|*  2 |   INDEX RANGE SCAN| IDX_TPSYS_FLDHIST_RCD |    1 |    42 | 3   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("RECORDID"=:SYS_B_0)

    从以上的测试效果来看,通过一个索引的创建,原SQL的成本降低到3,效率大大提升。
    Bethune 在下一个版本中,将完全实现到创建之前的所有建议,实现智能化的索引推荐。


    Bethune X 支持 SQL 自定义监控,通过添加一个SQL采集任务,配置告警策略来实现数据库内数据的监控。对于日志,Bethune X 已经预设了Oracle alert 日志监控:

    除了Oracle的alert 日志,其他日志可以通过添加Oracle 外部表的方式实现监控,以下例子就是实现了Linux 上secure 日志监控的配置过程。

    第一步:必要的赋权

    在root 用户下将/var/log/secure 的读权限给到Oracle 用户:
    chmod 744 /var/log/secure
    第二步:创建外部表
    登陆到 Oracle 数据库创建 directory,确保 数据库能够读取该路径下的日志:/var/log/
    create or replace directory var_log as '/var/log’;
    如果外部表不在sys底下创建,则需要对该目录进行赋权,例如在BP_QUERY下创建外部表,则需要将该目录读写权限赋权给BP_QUERY用户:
    grant read,write on directory var_log to BP_QUERY;
    以/var/log/secure 日志文件创建外部表,这个外部表只有一个字段,每行日志一行数据:
    CREATE TABLE secure_log
    (
     text varchar2(4000)
    )
    ORGANIZATION EXTERNAL
     (TYPE ORACLE_LOADER
      DEFAULT DIRECTORY var_log
      ACCESS PARAMETERS
        (RECORDS DELIMITED BY NEWLINE
         nobadfile
         nodiscardfile
         nologfile
        )
      LOCATION ('secure')
     )
     reject limit unlimited ;
    创建好之后可以测试一下改外部表是否创建成功:
    select * from secure_log where rownum<10
    将该读权限赋给Bethune X 采集用户:BP_QUERY。如果这个外部表是在BP_QUERY用户下创建则不用:
    grant select on secure_log to BP_QUERY;

    第三步:添加SQL自定义采集任务
    在Bethune X 设置/采集任务配置 里面添加一个SQL类的采集任务。示例图如下:
    采集任务选择Oracle,采集频率按需配置。
    SQL 脚本我用 instr+substr+to_date 的方式把日志里面的日期部分转成了Oracle 可以识别的日期,并做了最近一小时的限定(>sysdate-1/24)。


    配置好SQL脚本之后,需要选择相应的数据库进行测试,因为我们是在Enmotech 这个数据库上做的这个外部表,所以选择Enmotech 作为测试数据库,测试通过的数据库才能启动这个采集项。

    第四步:创建告警策略,添加到模板,使用到目标数据库

    保存好采集任务之后,在告警策略里针对这个数据采集项:「安全日志外部采集」创建告警策略。监控类型选择「数据库」—>「Oracle」—>「自定义」;
    SQL 自定义采集任务通过对采集SQL返回的字段进行规则配置。这儿我们返回了通过日志截取转化的时间字段「log_date」和内容字段「text」;
    这儿我们对「TEXT 」字段进行规则配置,利用like 表达式做全模糊查询,包含这段关键字的日志都会触发该告警规则。
    告警模板的配置,需要通过变量的方式将主机名,数据名等预设变量和字段变量加入到告警模板里。字段变量需要用 ${字段名} 的方式包起来,配置方式可以数据悬停告警模板旁边的 i 展示出来。


    配置好告警策略后,配置到相应的模板,再把相应的库配置上该告警策略。如果触发了告警,就可以在 控制台/告警看板 里面看到该告警。也可以在「数据库详情」页面最近告警里面看到告警信息。


    以上就是利用 Oracle 外部表+Bethune X 自定义 SQL 监控的方式实现主机日志监控的一个例子。
    总结一下:
    1.通过赋权让Oracle用户有权限读取日志的权限;
    2.创建外部表,让Oracle 数据库能访问该日志;
    3.在Bethune X 里面创建采集任务,并保证目标数据库的采集任务能测试成功;
    4.针对这个采集任务创建个告警策略,添加到模板里面,应用到数据库上。


    2020 ,对你的 DBA 好一点,一套 Bethune ,交个好朋友!
    (阅读原文,立即体验!)

    数据驱动,成就未来,云和恩墨,不负所托!

    云和恩墨是全球化数据资产端到端解决方案提供商,致力于将数据思维带给每个组织、每个人,构建数据驱动的智能未来。我们在数据服务、运维平台、数据智能、教育培训等领域为企业和个人提供可信赖的产品、解决方案和服务,与业界厂商广泛合作,围绕用户需求,持续为客户创造价值、为行业培养人才,激发数据潜能,为成就未来数字化企业和数据人才而不懈努力。

    云和恩墨坚持围绕数据时代客户面临的挑战持续创新,不断加大研发投入,持续完善贯穿业务智能、开发管控、云管平台、分布式存储和基础运维的端到端产品和服务,助力企业和个人成功。

    继续滑动看下一个

    打开这份指南,数据库运维也能优雅、简单!

    向上滑动看下一个

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存