在计算机技术快速发展的今天，各行各业的工作越来越依赖计算机完成。大型的监控系统应用也越来越多。大型监控系统通常都建立在大量的采集数据基础上，合理地部署数据库以及高效地处理数据库数据是大型监控系统工作的关键。从横向来说，各种数据按应用领域的分类至关重要，它决定着任务的分配。从纵向来说，各类数据的实时性要求至关重要，它决定着任务的优先级。
所以，数据库的部署方案应该主要考虑应用领域和实时性，并且兼顾考虑各模块之间的联系。
1 综合监控数据库系统
1.1 概述
综合监控系统的数据库管理系统包括实时数据库管理系统和历史数据库管理系统，其数据库采用实时数据库和商用数据库相结合的方式，由此构成整个综合监控系统支撑平台的核心，为其它各种应用提供统一的实时数据和历史数据的访问接口。
为了使数据访问具有良好的实时性，综合监控系统使用实时数据库管理系统、利用最新自主研发的专用数据库中间件，提供快速实时数据访问。同时，使用商用数据库作为历史数据库，将实时数据库管理和历史数据库管理有机地结合起来，使数据库管理既达到商用数据库的可靠性、适应性，又达到实时数据库的实时性。
1.2 实时数据库管理
综合监控系统的实时数据库管理系统提供高效的实时数据存取，是系统数据的高速缓存，有利于更好地实现综合监控系统的监视、控制和分析等。
实时数据库管理系统具有以下主要特点：
专用数据库中间件，大大加强了应用程序访问实时数据库的速度和效率，同时也使数据库管理更加标准化和层次化；通过数据库维护工具，可以在线查询、监视、增减和修改数据库中的各种数据，大大提高了系统的可维护性；允许不同应用对数据库内的同一数据进行并发访问，通过数据加锁机制，系统保证在并发方式下数据库的完整性和一致性，提高了系统的并发操作性能；用户可以对实时数据的结构进行修改，或者生成新的实时数据库机构，这些修改对原有的各种应用都不会影响；系统平台的数据库同步技术，可以保证不同数据库之间的数据保持高度一致，当任一数据库的数据被合法修改后，所有的数据库都将同时自动更新；无论是应用程序访问数据，还是通过人机界面访问数据，系统都提供完整安全认证服务，保证数据库中数据的安全；支持SQL访问，用户可以使用标准SQL语言访问实时数据库，就像在商用数据库中通过SQL访问历史数据一样。
1.3 历史数据库管理
综合监控系统的历史数据库主要用于存储系统模型和历史数据。历史数据库主要采用商用数据库。并通过平台的数据库同步机制，来保障综合监控系统的多数据库同步，保证了参数模型的准确和历史数据的完整与可靠。
通常情况下，综合监控系统通过数据库中间件VDB实现历史库和实时库统一的接口访问，同时对于不同的商用数据库，VDB提供了统一的接口和调用方式，屏蔽了底层多种商用数据库的不同，对于上层的应用，无需知道商用数据库的类型和版本。
1.4 实时库和历史库的关系
综合监控系统的系统模型保存在历史数据库中。综合监控系统平台根据系统模型生成实时数据库。但实时数据库的建立并不完全依赖于历史数据库，系统平台通过严密的机制保证了实时库能够脱离商用库进行加载，当历史数据库发生异常离线时，整个综合监控系统可以进行正常的监视和控制。
综合监控系统提供数据库维护工具对系统进行模型维护。通过维护工具，可以对参数进行增加、删除、修改等操作，通过系统验证等，保证商用数据库中的系统模型的正确和完整。通过维护工具对系统发出同步命令，实时数据库将在线加载参数模型，并实时更新实时数据库。如图1所示。
2 数据的在线修改与同步
综合监控系统采用多数据库中心的分布模式，实现系统中数据库系统的同步、冗余管理，提高系统的可靠性和抗灾能力。
在综合监控系统中，我们把中央级综合监控系统、车站级综合监控系统等都称为操作站，系统中的所有操作站（系统）均拥有独立的数据库系统，在整个系统中由系统自动或人工指定一个基准数据库（主数据库）。当在任一数据库进行修改，均完整地在基准数据库执行相应的修改，同时在基准数据库记录修改的日志，当发起修改的操作站（系统）执行更新提交后，由基准数据库同步其他操作站（系统）的数据库执行修改，保证数据库的一致。
每个操作站（系统）使用的数据从本地数据库中获得更新。因此每个操作站具有相对的隔离性，保证系统的安全。当基准数据库发生故障时，系统自动或人工指定另一个数据库为基准数据库，保证系统的连续正确运行，大大提高系统的抗灾能力。因此对于地铁综合监控系统，一般指定控制中心为缺省的主数据库中心，可以建立备用中心，也可以利用一个车站或车辆段作为备用中心，甚至每一个操作站都可以备用中心，这样大大提高系统的可靠性。如图2所示。
当基准数据库中心发生故障时，系统可自动或人工指定另一数据库中心切换为基准数据库中心，保证系统数据更新的连续，同时原来的基准数据库中心恢复后切换为普通数据库中心。如图3所示。
通过以上机制，可实现系统在维护、灾害情况的正常运行，实行中心、操作站、变电所等应用功能的有机关联。比如在中心或操作站上对开关进行遥控闭锁、权限转移、挂牌等操作，同时也在变电所的当地后台上有效，保证了系统的安全可靠，将在地理区域上分布的综合监控系统连接成一个有机的整体，同时又保证在故障情况下的分散控制和故障恢复。
2.1 数据在线修改
对于不涉及系统配置和数据结构的数据库修改，即对表格的域不做修改，也就是只是对各数据点记录的增删改，综合监控系统可以实现在线修改，即不需要重启系统的各类应用。
对于各种数据库的在线修改内容，权限配置如下。
对于操作员，可修改如下内容：
模拟量报警上限值；模拟量报警下限值；数据点的人工设置值；数据点报警与否。
对于高级维护人员，除可以进行上述操作员的修改操作外，还可以进行如下修改：
状态量描述；状态量责任区；状态量电压等级；状态量类型；状态量报警级别；状态量报警模式；状态量报警语音；状态量语音报警次数；状态量是否可控；状态量控制起始命令；模拟量描
述；模拟量责任区；模拟量电压等级；模拟量类型；模拟量报警级别；模拟量报警模式；模拟量报警语音；模拟量语音报警次数；模拟量最大采样值；模拟量最小采样值；模拟量最大工程值；模拟量最小工程值；模拟量数据修正方式；模拟量零值范围；模拟量是否能输出；模拟量输出上限；模拟量输出下限
2.2 数据同步
综合监控系统采用多数据库中心的分布模式，在多个数据库系统中实现数据库系统的同步、冗余管理。
在综合监控系统中，中央级综合监控系统、各车站（变电所）级综合监控系统均拥有独立的数据库系统，在整个系统中由系统自动或人工指定一个地点的数据库作为基准数据库（主数据库）。当在任一数据库进行修改，均完整地在基准数据库执行相应的修改，同时在基准数据库记录修改的日志，当发起修改的地点执行更新提交后，由基准数据库同步其他地点的数据库执行修改，保证数据库的一致。
如图4，当调度维护应用模块进行参数修改的操作时，其对数据库的操作最先作用与基准地点的主历史数据库模块（过程1），然后由主历史数据库模块同步到备历史数据库模块（过程2），并且通过通讯主干网络对其他地点发出数据修改通知，其他地点的主历史数据库模块接到通知完成修改（过程3），并且对本地的备历史数据库模块进行同步操作（过程4），各地完成历史数据库修改操作后将修改参数加载至本地的主备实时数据库模块（过程5），最终实现全线所有数据库模块的参数修改。
3 重启进程和服务器的说明
综合监控系统的数据库在线修改（包括同步），若不涉及系统配置和数据结构的修改，即对表格的域不做修改，也就是只是对记录的增删改，表格的增加，均无须重启系统的各类进程。根据数据变化的内容和影响，对系统的进程和服务具体影响如表1所示。
其中，更改系统整体容量等系统性参数，如对数据库整体容量（该容量通常是一个工程数据量的预定义上限，为一个常量值）配置进行重新配置，需要对整个应用系统从底层平台到所有应用的重新启动。除此之外，数据库的任何修改，均无须对系统的底层平台进行重启。
4 结束语
综合监控系统作为当今轨道交通中应用最为广泛和最重要的监控系统，数据库对其的支持至关重要。在本文中，我们探讨了综合监控中的数据库运行机制，讨论了历史数据库的大数据量及其维护。讨论了实时数据库的实时性及其加载同步。通过对这一系列问题的讨论，我们总结出了一整套安全高效的系统数据库方案，在这套数据库方案中，安全性和一致性是遵循的基本原则，高效性和便捷性是可以不断追求提高的方面。在现有以及可以预见的数据规模下，这套数据库方案可以很好的完成对轨道交通综合监控系统的支持。
参考文献
[1]张宝广，隋国栋，李海锋.城市轨道交通工务管理数据库的设计[J].城市轨道交通研究，2010（1）.
[2]王敏慧，李孟恒，董淳，朱扬勇.监控系统数据库的设计与实现[J].计算机工程， 1999（2）.
