对于常规数据库的运维监控来说,如何能够快速简洁的发现问题,直达问题本质并解决常见问题,是 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 ,交个好朋友!数据驱动,成就未来,云和恩墨,不负所托!
云和恩墨是全球化数据资产端到端解决方案提供商,致力于将数据思维带给每个组织、每个人,构建数据驱动的智能未来。我们在数据服务、运维平台、数据智能、教育培训等领域为企业和个人提供可信赖的产品、解决方案和服务,与业界厂商广泛合作,围绕用户需求,持续为客户创造价值、为行业培养人才,激发数据潜能,为成就未来数字化企业和数据人才而不懈努力。
云和恩墨坚持围绕数据时代客户面临的挑战持续创新,不断加大研发投入,持续完善贯穿业务智能、开发管控、云管平台、分布式存储和基础运维的端到端产品和服务,助力企业和个人成功。