<toc>
### 一、概述
  Ankole数据库运维平台支持的运维内容比较广泛，包括：主机、Oracle、MySQL、GoldenGate、Oracle ADG复制、MySQL复制等等。
ankole数据库运维平台-功能框架：
```md
1.监控
2.维护
3.诊断
4.备份
5.巡检
6.分析
7.安全
8.业务
```
-----
### 二、Ankole监控告警
##### 1.告警短信数量
 避免无效告警
##### 2.告警平台
 告警集中在白天，总数在百条以下，夜间告警短信控制在1-2条。
##### 3.根据故障场景分级应对
 对于类似“数据库实例的可用性”等故障，要及时发出短信报告故障。而对于“逻辑备份”此类夜间故障，第二天值班人员上班及时处理即可。
 在ankole运维平台中定义的告警场景现在有49种
##### 4.告警方式
 对于未及时处理的告警，无需反复告警。
 ankole运维平台中对各种故障场景定义了告警暂停、恢复机制。
比如：当发生数据库可用性告警，当发送3次告警后，短信告警会暂停发送。如果1小时后数据库可用性故障未修复，那短信告警会继续发送3次。如果数据库可用性故障解决，则短信告警会发出恢复告警信息。
##### 5.告警模版定义
 定义以下内容：告警时间范围、告警日期、告警涉度、告警敏感度、告警骚扰度、告警循环、告警闭环。
以MySQL同步复制场景为例，该故障场景在7*24发生故障都可以直接发送告警短信，发送告警的频率是每10分钟发送1次短信，为了避免误告警，只有在运维平台连续监测到故障2次后才开始发送告警，并且该告警在发送2次后就暂停发送，让运维人员可以专心处理。如果故障3小时没有解决，则3小时后继续发送2次，如果故障处理后，不发送恢复告警。
通过告警模板，定义各种故障场景的短信告警发送时间、发送方式、发送频率等。
##### 6.告警接收人
 某个具体节点的告警，发送到相应的接收人，而不是所有的告警都需要发送到运维值班人员。
##### 7.差异化告警阀值
 日常运维的短信告警，比如：主机文件系统使用百分比，数据库表空间使用百分比，数据库会话数限值百分比等，这类告警的告警阀值，白天需要比夜间低。比如表空间使用率百分比，白天设置告警阀值为85%，夜间设置告警阀值为95%，这样这些日常维护的告警基本发生在白天，避免运维值班人员夜里爬起来扩容表空间。
##### 8.短信告警历史查询
 在短信历史页面，可以通过故障场景和接收人查询，告警短信是否确切地发送给某位责任人。
------
### 三、Ankole自动化故障单
##### 1.需求背景
 让运维平台来告诉我当前所有维护的数据库发生了哪些故障，让我一目了然地知道，不需要到各个功能页面上去一点一点地检查。
##### 2.设计思路
 在前面的发生告警同时，相应自动生成故障单，将故障信息在故障单中统一展现，故障修复后，自动关单并自动删除故障信息。
##### 3.带来运维方式的变化
 只需要关注自动化故障单页面里出现的故障内容，比如：逻辑备份、索引失效等，故障节点一般是主机或相应的数据库或数据库实例等，通过这些简洁明了的故障资源、故障原因的描述，让运维人员可以快速掌握故障信息。
##### 4.进阶需求
 精细化管理需求。比如一位责任人只负责管理少量的几套数据库，在ankole数据库运维平台的数据库收藏夹功能里，将自动化故障单收集的故障信息拆分到了是否在某个数据库上存在故障信息，这样可以只展示对应的故障信息。
----
### 四、Ankole定制化数据采集
##### 1.需求目标
 虽然运维的开发属于devops，但是有些问题需要及时纳入监控、维护，所以ankole运维平台提供了强大的扩展功能。相比oracle安装代理软件的方法【ps：代理软件负责把故障数据推至资料库，与此同时代理软件也入侵了服务器，由于生产服务器的维护人员疏忽代理软件的存在而可能造成错误】，ankole的数据采集模块不需要安装代理软件，也就不侵入服务器。ankole在维护百套数据库时，数据库故障可以在20s内发出告警。
##### 2.实现思路
 ankole数据采集，对于采集的内容按重要层度进行频率梯度划分。对重要的采集内容（比如数据库实时状态），这种采集频率非常高，采集频率设为10分钟级；对参数变化较小的内容，采集频率为小时级。
 数据采集框架按照采集内容进行模块化调度，互不影响，使用多线程方式进行数据采集：
##### 3.定制化扩展
 有新的数据采集需求时，在调度框架内开发新的采集模块即可，学习成本较低。
### 五、Ankole自助服务
##### 1.问题
 面对简单重复的问题，业务可以自行解决，不用劳烦运维人员。
##### 2.设计思路
 ankole提供自助服务功能，让业务人员能够自维护，减少对DBA的支持需求，提高工作效率。
 自助服务大的功能模块有：查看数据库**实例性能**、**会话管理**、**失效索引管理**、**SQL性能分析**。
##### 3.实例性能
 在实例性能页面中选中关心的数据库和实例，就可以看到数据库的运行情况。比如：数据库服务器CPU的使用率，数据库的IO响应指标，表空间的使用率，物理备份是否配置，逻辑备份是否配置、备份内容、最近备份时间、备份日志，在上方还有业务人员比较关注的：数据库活跃会话数、会话总数和数据库当前写入的日志量。
 通过查看历史，还可以检查数据库的性能历史，了解数据库的运行情况。
##### 4.会话分析
 使用通过数据库杀会话的命令，经常无法彻底杀掉会话。
 这时侯业务维护人员又要找到数据库运维人员了，数据库运维人员通过一通命令，啪啦啪啦，然后登录到服务器上执行了“kill -9”命令，就将数据库里异常的业务会话给杀掉了，经常麻烦DBA，非常麻烦。
 因为这个原因，ankole运维平台向业务维护人员提供了会话分析功能，如下：
 当业务维护人员发现了异常的数据库会话需要结束时，通过选中数据库实例，输入SID和SERIAL#值，就可以查看到会话的详细信息。包括：会话类型、状态、用户名、客户端程序、客户端机器名、登录时间，还包括一些重要信息：会话正在执行的SQL_ID、会话使用的UNDO量，还有分析的会话是否被其它会话阻塞等。
 如果业务维护人员查看了这些信息，确认无误需要结束掉会话，则点击右边的“杀进程”就可以准确无误、干净利落地杀掉了异常会话。
 会话使用的UNDO量需要说明一下，如果会话使用的UNDO量过大，那杀掉该会话可能会造成数据库长时间地回滚，在“杀进程”按纽在点击时会进行相关校验和提醒。
 如果需要了解这个会话的执行历史，可以点击左边的“会话历史”按钮，就可以将这个会话执行的等待历史情况展现出来，以供专业的DBA检查。
##### 5.失效索引管理
 数据库维护过程，字段等变化造成索引失效，访问量剧增时，全表扫描业务增加，导致cpu、io剧增。
 在失效索引管理模块，可以定期检查数据库中是否有新的索引、失效索引，若有则发出告警。
处理报警时在**自主服务**中的“失效索引管理”进行检查。
<font color=blue>失效索引基线功能：</font>
  某些失效索引的存在不影响数据库性能，一方面这些索引可能在之后会被再次用到；另一方面这些索引占用内存，节约存储资源。
  失效索引基线功能，在新加的运维数据库一开始就发现失效索引，但无法确认rebuild 或者drop时，这部分索引可以加入失效索引基线中，那么这些索引就**不会告警**，在随后维护过程中，如果发生rebuild或drop时，则从“失效索引基线”中移除。慢慢地整个失效索引基线将越来越小，Ankole数据库运维平台将所有数据库的失效索引进行慢慢自愈。
##### 6.AWR TopSQL分析
  AWR TopSQL分析功能，通过选中数据库就可以直观地看到哪些SQL的耗费比较高。
 根据左边桑基图可知，线条越粗，sql耗费越高。
 在AWR topsql分析页面中提供按“执行时间”，“逻辑读”，“CPU”三个维度的分析，在页面中可以显示SQL文本、执行计划、执行次数历史、平均每次执行时间历史等。
##### 7.总结
在ankole数据库运维平台中提供了很多帮助业务自行分析、解决问题的自助服务功能，或者是以短信告警的方式在提供帮助，或者是以很直观的方式供业务来使用。
### 六、Ankole日常检查
##### 1.应对场景
 对于一定数量的数据库的负载、CPU、内存、存储等情况的频繁统计，如何做到快速省时。
##### 2.ankole的设计
Ankole数据库运维平台对DBA的日常维护操作提供了**C/S**的DBA工具，DBA工具采用多层菜单方式，相比B/S有着无可替代的操作便捷性。
##### 3.信息查询
 对于数据库的名称，在表述交流时，常常用“xxIP库”，“xx业务库”这些名称代替，虽然易记，但是不具体。
 Ankole运维平台的**DBA工具**中查询数据库信息，可以通过多种方式，如“IP”、“TNS”、数据库名、实例名、相关注释等，全部是模糊匹配方式查询。通过对方宝贵的只言片语，在信息查询中查到相关信息，再次确认即可。
  比如：临时想找一个10.2.0.5版本的数据库，一下子记不起来，哪个数据库是，则可以通过标题栏的过滤方式来查找。
  比如：过滤某个字段大于某个值的信息、时间大于某个值的信息。在信息查询的每个标题栏都可以进行自定义查找过滤，另外在“Custom……”可以完成更加灵活的查找过滤。
 在ankole运维平台的DBA工具中，可以检索数据库信息、数据库全景视图、ASM信息、OGG信息、逻辑备份信息、数据库同步信息和数据库服务等。
 在每个信息查询界面里，都提供了右键菜单进行更详细内容的查询和设置，比如：空间容量、控制数据库告警、生成数据库巡检报告等等，另外根据选中的数据库可以快速跳转到各个分析界面，极大地提高DBA的效率。
##### 4.数据库全景视图
 在刚登录DBA工具时，首页就是性能全景视图柱状图，包括“CPU使用率 Top20”的主机和“活跃会话数 Top20”的数据库。
 通过首页的性能全景视图，就可以一目了然地知道当前负载较高的数据库和主机。在左上角可以勾选“10秒自动刷新”，进行定时刷新。
 另外在“数据库全景视图”界面里有更详细的性能数据展现。包括数据库当前的“活跃会话数”、“会话数”、“会话数百分比”、“每秒登录数”、“登录时间”、“时间差”、CPU、内存等信息。这些信息都可以通过点击标题栏进行正、倒排序方便检查，也可以进行信息过滤。
##### 5.自定义资料统计
 当前ankole运维平台里可以统计IP、数据库版本、PSU补丁号、数据库参数、是否归档、是否配置了备份、CPU、内存大小信息、数据库7天归档量，数据大小等等相当多的内容。
 当需要的统计资料当前资料库中没有时，就需要运维平台有强大的扩展能力。
 以下是跟据甲方的要求，通过相关资料表关联后得到的资料视图结构，这样就可以轻松应付领导的突击资料要求了。
##### 6.总结
 检查Top负载数据库是日常非常高频的使用点，查询方式需要足够多，足够灵活。Ankole数据库运维平台给DBA提供的DBA工具，通过将每个字段都可以进行过滤的方式，大大提高日常查询检查效率。通过数据库全景视图，将Top负载的数据库、主机信息实时掌握在手。在资料统计方面，如果需要的内容不在资料库，通过强大的数据采集模块扩展采集，补充统计资料内容，并进行更新统计。
### 七、Ankole作业管理、容量分析
##### 1.问题
 在运维过程中，表空间使用率持续告警，经常扩了过不了一阵子，又告警了，这个表空间空间增长情况是怎么样的，具体是哪个对象增长大呢？
 上级部门会来审计数据库的安全情况，数据库里是不是有未经审计的job、主机上是不是有不符合安全手续的crontab任务?
##### 2.作业管理
 Ankole数据库运维平台实现了自已的作业调度管理，可以将所有的这些任务集中在资料库中统一进行管理。避免各个服务器上存在各种crontab计划任务。
  Ankole数据库运维平台的调度方式与crontab的一致，所以主机维护人员、DBA都可以很快上手。在作业调度界面上，清楚地显示了任务的上次调度时间、下次调度时间和最近1次的执行时间。如果发现作业执行失败，在右键菜单中可以进行“立即执行”。
##### 3.容量分析
  当发生表空间的持续告警，DBA需要关注是不是该表空间最近增长异常，如果发现最近空间使用剧烈增多，那得去找业务部门，配合去检查具体是哪些对象空间使用较多。
  有时侯业务因为出现Bug等情况，会导致某个对象空间增长异常，进而导致表空间频繁告警，这时侯就需要先找到告警表空间里比较大的对象，再通过“段对象容量趋势分析”去确认是否最近存在空间增长异常。
  通过表空间、大对象的空间增长情况，可以在发生问题时追溯问题发生的大致时间点或者确认是否业务存在异常。另外如果领导想要规划下一年度所有数据库容量，也都可以通过从资料库中获取所有数据库的容量增长趋势，合理地进行计划与决策。
### 八、Ankole巡检报告
##### 1.传统巡检
 巡检最开始是人工依靠个人经验，再然后就依靠一些自动化工具，但是这些工具需要在每个数据库上部署。还有就是服务商通过开发客户端脚本进行数据采集，再通过云端生成巡检报告，然而这有数据泄露的风险。
##### 2.Ankole巡检方式
 Ankole数据库运维平台是本地化部署，无任何云服务端，所有数据都是客户私有的资料库中，巡检报告在客户部署的运维平台中生成，不存在任何数据泄露风险。
 在ankole运维平台管理的数据库中选择“**生成数据库报告**”，就能一键完成数据库巡检报告的生成。当前支持Oracle和MySQL数据库巡检报告的生成，后期可能会增加更多类型的数据库。
##### 3.巡检报告内容
● 基本信息
● 空间信息
● 用户会话信息
● 参数信
● Top进程信
● 应用大对象、失效索引、外键无索引、违规权限
● JOB、并行对象、Sequence、物化视图等应用内容
● 性能视图
----*picture1:目录总览*
----*picture2:基本信息*
----*picture3:会话数信息*
----*picture4:应用信息*
----*picture5:性能视图*
  性能视图是ankole巡检报告中最具特色的内容，在巡检报告中展示出巡检数据库所有实例和主机的相关性能指标曲线图，包括：
● CPU曲线
● 内存曲线
● 活跃会话数
● Redo生成量
● SQL执行数
● 提交数
● 块修改数
● 逻辑读
● 硬解析
● IO事件响应值
● 物理读
● 物理写
##### 4.总结
 通过ankole运维平台生成的巡检报告，可以直观地了解数据库的基本信息和最近的性能情况，帮助DBA全面掌握数据库的运行状态。通过一键化生成方式，按需快速生成巡检报告。资料数据和生成方式的本地化，避免数据泄露。在报告中包含应用关心的内容，让数据库巡检贴合应用。
### 九、Ankole性能分析
##### 1.性能分析需求
 对于数据库当前的性能，可以登陆查看当前性能，但是想要追溯以前的性能问题，比较困难。
 在没有运维平台之前想要回答这些问题可能需要用的到相关命令和工具：sar命令、vmstat命令、OWI诊断方法、OSWatch工具、AWR、ASH等等。
##### 2.数据库性能历史
  DBA接手一个数据库，一般都需要掌握数据库性能历史，了解数据库性能波动的具体规律。Ankole运维平台在《系列5自助服务1》中就可以通过查看数据库实例性能了解一段时间内的性能情况，而如果需要了解长时间（比如1个月）的性能情况，则可以通过DBA工具的数据库分析来达到目的。
 在界面中通过输入不同的快照ID，就可以对多个快照进行性能比对。
##### 3.实时性能分析
 对于正在发生性能问题的数据库，ankole运维平台提供了实时性能视图来进行实时分析。
 实时性能视图对数据库性能数据采集频率较高，该性能视图自动刷新，通过双击各个性能指标视图，可以跳转查看更长时间维度的历史性能曲线。当发生数据库主机异常宕机，无法从AWR中获取宕机时间点的数据库性能数据时，就可以通过这些历史数据，检查问题发生时，数据库是否存在性能问题。
##### 4.数据库性能比对
 对于固定时间跑批量业务的数据库（比如月初出账），在事后去判断本月跑批性能与上月相比是否存在问题，这就需要对数据库性能指标进行跨月比对。AWR报告此时就比较片面。
 在ankole数据库运维平台中，可以对数据库运行的性能历史进行快速比对。如下是数据库月初跑批业务的比对报告：
  比对内容包括：Redo量、物理读、物理写、逻辑读、SQL执行数、硬解析、提交数、活跃会话数、CPU使用率、IO响应时间等。通过这些数据库指标历史的全方位比对，就可以判定执行批量业务时数据库性能是否稳定。
##### 5.历史Top SQL比对
 在ankole数据库运维平台的DBA工具中，提供了TopSQL比对，可以对任意一个（或两个）数据库的TopSQL进行性能分析比对，比对维度有：CPU、逻辑读、执行时间，比对结果如下：
 通过TopSQL比对，就可以回答跑批业务或者数据库迁移后，SQL执行性能稳定或否，进而对性能差异较大的TopSQL进一步分析。
##### 6.实时TopSQL分析
 如果要检查当下数据库有哪些会话执行较慢、耗费较大，可以在ankole运维平台的Top会话中来分析，在Top会话中的分析维度有：CPU、物理读、逻辑读、硬解析等。
##### 7.总结
 Ankole数据库运维平台提供了丰富的性能分析比对方法，通过这些工具，对数据库当前或者历史是否存在性能问题提供了充分的解释。
