5) “任务查看、导出”部分，在用户发起审核任务后，可在此部分查看进度（处于审核中、还是审核完成）。当审核完成后，可选择审核任务，浏览审核结果或选择导出均可。如果是选择导出的话，会生成异步后台作业生成文件，放置在下载服务器上。
以上就是整个审核的大体流程。后续将看到各部分的详细信息。
模块划分
总结一下，平台主要是由上述四个模块组成：数据采集、规则解析、系统管理、结果展示。后面将针对不同模块的实现，进行详细说明。
5、数据采集采集内容
先来看看数据采集模块。从表格可见，两种类型数据库的采集内容不同。
Oracle提供了较为丰富的信息，需要的基本都可采集到；MySQL功能相对能采集到的信息较少。
表格中的“对号+星号”，表示非定时作业完成，而是后面实时回库抓取的。下面简单说下，各部分的采集内容。
对象级，采集了对象统计信息、存储特征、结构信息、访问特征。
SQL级，采集了SQL文本，执行计划、缓存游标、绑定变量、执行特征等。
这些信息都将作为后面审核的依据。
采集原理
下面简单介绍下采集的与原理：
Oracle部分，是通过定时作业采集的AWR数据，然后转储到一套MongoDB中。这里跟有些类似产品不同，没有直接采集内存中的数据，而是取自离线的数据。其目的是尽量减少对线上运行的影响。Oracle提供的功能比较丰富，通过对AWR及数据字典的访问，基本就可以获得全部的数据。
MySQL部分，情况就要复杂一些，原因是其功能没有那么丰富。多类数据是通过不同源来获取。SQL文本类及执行特征类的，是通过pt工具分析慢查询日志定时入到Anemometer平台库，然后从此库传入MongoDB。其它类信息（包括数据字典类、执行计划类等）是在需要时通过实时回库查询的。为了防止影响主库，一般是通过路由到从库上执行获得的。
6、规则解析概要说明
下面介绍整个系统最为核心的部分—规则解析模块，它所完成的功能是依据定义规则，审核采集的数据，筛选出违反规则的数据。对筛选出的数据进行计分，并记录下来供后续生成审核报告使用。同时还会记录附加信息，用于辅助进行一些判断工作。
这里有个核心的概念—“规则”。后面可以看到一个内置规则的定义，大家就会比较清楚了。从分类来看，可大致分为以下几种。
从数据库类型角度来区分，规则可分为Oracle、MySQL。不是所有规则都区分数据库，文本类的规则就不区分。
从复杂程度来区分，规则可分为简单规则和复杂规则。这里所说的简单和复杂，实际是指规则审核的实现部分。简单规则是可以描述为MongoDB或关系数据库的一组查询语句；而复杂规则是需要在外部通过程序体实现的。
从审核对象角度来区分，规则可分为对象类、文本类、执行计划类和执行特征类。下面会针对每类审核对象，分别做说明。
规则定义
这是一个规则体的声明对象，我说明一下各字段含义，大家也可对规则有个清晰的认识。
db_type：规则的数据库类别，支持Oracle、MySQL。
input_parms：输入参数。规则是可以定义多个输出参数，这是一个参数列表，每个参数自身又是一个字典类，描述参数各种信息。
output_parms：输出参数。类似上面的输入参数，也是一个字典对象列表。描述了根据规则返回信息结构。
rule_complexity：规则是复杂规则还是简单规则。如果是简单规则，则直接取rule_cmd内容作为规则审核的实现。如果是复杂规则，则是从外部定义的rule_name命令脚本中获得规则实现。
rule_cmd：规则的实现部分。规则可能是mongodb的查询语句、可能是一个正则表达式，具体取决于rule_type。
rule_desc：规则描述，仅供显示。
rule_name：规则名称。是规则的唯一标识，全局唯一。
rule_status：规则状态，ON或是OFF。对于关闭的规则，在审核时会忽略它。
rule_summary：一个待废弃的字段，意义同rule_desc。
rule_text：规则类型，分为对象、文本、执行计划、执行特征四类。图中的示例标识一个文本类型的规则，rule_cmd是正则表达式。
solution：触发此规则的优化建议。
weight：权重，即单次违反规则的扣分制。
max_score：扣分上限，为了避免违反一个规则，产生过大影响，设置此参数。
规则定义（对象级）
