一种事故报警查询优化方法技术

本发明专利技术公开了一种事故报警查询优化方法，包括报警库，界面程序，其特征在于：还包括一个后台程序，配置文件和数据库；查询计划实现包括以下步骤：1、后台程序首先读取配置文件，并将配置文件涉及的测点的属性信息的对应关系写入数据库中；2、用户通过界面程序输入查询条件；3、界面程序将查询条件作为请求参数传递给后台程序；4、后台程序解析请求参数并查询数据库；5、后台程序将查询得到的结果返回给界面程序。本方法具有如下的优势：采用哈希映射属性信息的对应关系，避免了大量重复、无用的操作；查询时间分段，提高查询效率，缩短用户的等待时间；避免造成系统瘫痪这种情况发生。

【技术实现步骤摘要】

本专利技术涉及地铁能源管理系统，尤其涉及。
技术介绍
事故报警查询子系统作为地铁能源管理系统软件的一个组成部分，用于监测、分 析各种生产能源以及设备的使用情况，实现节能管理。当系统一旦出现事故，系统必须给用 户提供一种快速获取故障信息的手段。它需具有相当高的灵活性，用户可以根据一些查询 条件来定位自己关心的事故报警信息。 但在实际情况中，由于报警信息的数量十分巨大，导致查询速度较慢，影响用户体 验，因此对事故报警查询子系统的查询效率和安全提出了更高的要求。 当事故报警发生时，一般只会将事故报警的Time(时间）、Objectld(测点的唯一 性标识）、Text(报警内容）、AlarmBehaviorLink(报警行为）等信息存入报警库中，但是 用户除了需要事故报警的Time(时间）、0bjectld(测点的唯一性标识）、Text(报警内容） 等信息外，还需要Aorld(测点所属的责任区）和Name(测点的名称）信息，其中Aorld和 Name在地铁能源管理系统的报警库中不会存储。 常规的事故报警查询子系统，其做法是通过查询报警库和配置库，通过数据库做 笛卡尔积的方式来获取用户需要的事故报警的全部信息。随着报警库中存放的事故报警信 息越来越多，会导致事故报警查询子系统查询效率越来越低。当报警库中的报警信息达到 一定程度时，如果用户查一个月内全站的所有事故报警记录，可能会导致如下问题出现： 1查询等待时间过长。 2造成系统瘫痪：后台程序在设定的等待时间内，没有收到数据库返回数据，会 结束本次查询，此时会引发最严重的后果。此时数据库查询并没有结束，数据库将会使用 tempdb(临时库）的资源，如果记录数足够多，会将tempdb的资源耗尽，此时如果地铁能源 管理系统有其他的程序需要使用tempdb时，会引发灾难性的后果。 查询计划是用户所提交的SQL语句的集合，执行计划是经过优化处理之后所产生 的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之 后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预 编译模块对语句进行处理并生成执行计划，然后在合适的时间提交给系统处理执行，最后 将执行结果返回给用户。在实际的数据库产品（如Oracel、Sybase等）的高版本中都是 采用基于代价的优化方法，这种优化能根据从系统字典表中所得到的信息来估计不同的查 询计划的代价，然后选择一个较优的执行计划。许多程序员认为查询优化是数据库管理系 统（DBMS)的任务，与程序员所编写的SQL语句关系不大，这是错误的。一个好的查询执行 计划往往可以使程序性能提高数十倍。 查询优化器的主要任务是控制和加快查询执行和数据传输的过程。然而，查询优 化一直是个复杂的问题，理想的、全面的查询优化几乎是不可能的，许多专家和学者在这一 领域曾做出过不少的研究和探讨，但总的说来，不尽人意，往往只能达到局部目标的查询优 化效果，甚至有些理论并不适用。 虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL 语句是系统优化的基础，但很难实现一个原本糟糕的查询计划经过系统的优化之后变得高 效。
技术实现思路
针对现有技术中存在的问题，为保证地铁能源管理系统软件的实时性，本专利技术提 出，在查询执行引擎生成一个执行策略的过程中，尽量使查询 的总开销和总时间达到最小。 实际系统对查询优化的具体实现不同，但一般来说，可以归纳为四个步骤： (1)将查询转换成某种内部表示，通常称之为语法树。 (2)根据一定的等价变换规则把语法树换成优化（标准）形式。 (3)选择底层的操作算法，对于语法树中的每一个操作需要，根据存取路径、数据 的存储分布、存储数据的聚簇等信息来选择具体的执行算法。 (4)生成查询计划。查询计划是由一系列内部操作组成的，这些内部操作按照一定 的次序构成查询的一个执行方案，通常这样的执行方案有很多个，需要对每个执行计划计 算代价，从中选择代价最小的一个。 本专利技术通过优化查询计划来解决以上问题，具体技术方案如下： -种事故报警查询优化方法，包括报警库，界面程序，一个后台程序，配置文件和 数据库； 所述配置文件存放全部测点的数据类型信息；S1 :所述后台程序首先读取所述配置文件，并将所述配置文件涉及的测点的属性 信息的对应关系写入所述数据库中；S2 :用户通过所述界面程序输入查询条件；所述查询条件包括查询时间，测点的 所属责任区Aorld，测点的类型Type，报警等级Severity。S3 :所述界面程序将所述查询条件作为请求参数传递给所述后台程序； S4 :所述后台程序解析所述请求参数并查询所述数据库；查询所述数据库中满足 所述查询条件中的所述Aorld和所述Type的记录，建立所述对应关系，存放在内存中； S5 :根据所述查询时间查询所述报警库，获取测点的测点的唯一性标识等属性信 息；根据所述对应关系，获取测点的名称信息；S6 :所述后台程序将查询得到的结果返回给所述界面程序。 S5中所述后台程序根据所述的查询起始时间和截止时间对所述查询时间进行分 段，当其超过确定阈值，则分割为一个时间段，存放在时间数组中。作为优选，所述确定阈值 设置为一个自然日。 所述时间数组，首先以所述时间段为单位循环查询所述数据库，获取测点的所述 Objectld、所述Text和所述Time;然后根据所述对应关系，获取测点的名称信息。 为所述Time预设最大响应时间，当用户查询的时间段超过了最大响应时间，则将 已经查询得到的结果返回给所述界面程序，并结束查询操作。 所述属性信息包括： Objectld测点的唯一1性标识； Aorld测点的所属责任区； Type测点的类型，所述Type包括SinglePoint、MeasuredValue; Name测点的名称； Time测点的报警时间； Severity报警等级； Text报警内容。 所述对应关系包括：所述Objectld和所述Aorld的Hash映射Hash_0bIdAor、所 述Objectld和所述Name的Hash映射Hash_0bIdName。 本专利技术具有以下有益效果：在分析了数据库查询优化的关键技术的基础上，本发 明研究了一种新的提高事故报警查询效率的方法。首先，本专利技术避免使用笛卡尔积来获取 发生故障报警测点的信息，提高了查询效率，缩短用户的等待时间。其次，避免两个结果集 之间的遍历操作，大幅提高了程序效率。最后，避免造成系统瘫痪这种情况发生：无论用户 设置的查询时间范围有多大，本程序是将查询时间进行分割，然后以天为单位来循环查询 数据库，这样就保证每次从数据库中获取的结果集在可控范围之内。避免了因为查询的结 果集太大，后台程序已经销毁了，单数据库的查询操作还在继续的情况。【附图说明】 图1为本专利技术的查询优化方法处理过程。 图2为本专利技术的查询优化方法流程图。【具体实施方式】 下面结合附图详细说明本专利技术的优选实施例。 1)以配置文件（将用到的测点的数据类型全部存放在该配置文件中，如 SinglePoint、MeasuredValue等）的方式，利用程序将这些测点的0bjectId、Type(测点类 型）、Name(测点的名称本文档来自技高网...

【技术保护点】
一种事故报警查询优化方法，包括报警库，界面程序单元，后台程序单元，配置文件和数据库；其特征在于，具体步骤为：S1：所述后台程序单元首先读取所述配置文件，所述配置文件存放全部测点的数据类型信息；所述后台程序单元将所述配置文件涉及的测点的属性信息的对应关系写入所述数据库中；S2：用户通过所述界面程序单元输入查询条件；所述查询条件包括查询时间，测点的所属责任区AorId，测点的类型Type；S3：所述界面程序单元将所述查询条件作为请求参数传递给所述后台程序单元；S4：所述后台程序单元解析所述请求参数并查询所述数据库；查询所述数据库中满足所述查询条件中的所述AorId和所述Type的记录，建立所述对应关系，存放在内存中；S5：根据所述查询时间查询所述报警库，获取测点的测点的唯一性标识等属性信息；根据所述对应关系，获取测点的名称信息；S6：所述后台程序单元将查询得到的结果返回给所述界面程序单元。

【技术特征摘要】

【专利技术属性】
技术研发人员：岳以洋，李佑文，罗存，包德梅，刘志超，李芳，褚红健，
申请(专利权)人：南京国电南自轨道交通工程有限公司，
类型：发明
国别省市：江苏;32