Oracle分区技术在C3无线接口监测系统中的应用
2017-01-09邓丽贤孙启民胡莉丽
邓丽贤孙启民胡莉丽
(1.北京全路通信信号研究设计院集团有限公司,北京 100070;
2.北京市高速铁路运行控制系统工程技术研究中心,北京 100070)
Oracle分区技术在C3无线接口监测系统中的应用
邓丽贤1,2孙启民1,2胡莉丽1,2
(1.北京全路通信信号研究设计院集团有限公司,北京 100070;
2.北京市高速铁路运行控制系统工程技术研究中心,北京 100070)
CTCS-3无线接口监测系统是用于监测CTCS-3列控无线通信网络的大数据处理系统,采用Oracle分区技术可大幅提高数据的存储和读取效率,同时可显著降低数据库维护工作的复杂度。
CTCS-3;GSM-R;接口监测系统;数据库分区
1 概述
我国铁路的高速客运专线主要使用CTCS-3级(以下简称C3)列车运行控制系统,该系统基于GSM-R无线通信网络承载。随着客运专线的不断增加,GSM-R网络日益增大, C3无线接口监测系统(以下简称“接口监测系统”)逐渐成为解决列车运行过程中无线通信问题的重要手段之一。
接口监测系统实时采集列车运行过程中的无线通信数据,并对数据进行解析、存储、分析,可及时发现列车运行中存在的无线通信问题。接口监测系统有助于C3无线通信问题的快速发现、及时定位和尽早解决,能够保障C3列控系统的安全稳定运行。列车运行过程中会产生大量的网络信令和C3业务数据,随着客专线路和列车数量的增加,接口监测系统的整体数据量也快速增长,对数据存储、数据查询和分析处理的速度都提出很大的挑战,因此,接口监测系统需采用有效的技术手段来提高自身的数据处理能力。
2 接口监测系统简介
2.1 系统概述
接口监测系统主要对C3列控无线通信网络中Igsm-r、Um、Abis、A、PRI等接口进行监测,具备接口数据采集、解析、关联、存储、查询、故障分析及网络质量分析等基本功能,是GSM-R无线网络维护人员进行C3无线超时问题分析的主要工具。
2.2 系统结构
接口监测系统包括存储、系统同步、网关、网管、综合分析和各单接口监测子系统,其中单接口处理部分又包括Igsm-r接口、Um接口、Abis接口、A接口和PRI接口子系统。系统结构如图1所示。
存储子系统软件采用Oracle 10g数据库软件实现,Oracle的控制文件、日志文件和数据文件分别存放在不同的磁盘分区。为保证接口监测系统的数据处理效率,采用Oracle分区技术进行各接口的数据表和索引的设计。
3 Oracle分区技术研究
3.1 分区技术特点
图1 接口监测系统结构图
分区技术是Oracle数据库为简化对数据库大表的管理而推出的一项重要技术[1],它是Oracle数据库最重要、最成功的功能之一,可以提高数以万计应用程序的性能、可管理性和可用性[2]。分区包括数据表及索引的分区,通过键值将数据表及索引划分为可管理的独立小块,可以提高维护、备份、恢复数据库的效率以及读写数据库的性能。
Oracle数据库分区对应用程序来说是透明的,应用程序可以不知道数据表已经被分区,在数据访问过程中,分区表的访问和普通表的访问没有任何区别,Oracle的查询优化器将自动处理分区表[3]。
3.2 分区技术应用场景
当数据库中的数据满足以下一类或几类场景条件时,应考虑使用分区技术[4],如表1所示。
表1 Oracle数据库分区技术应用场景分类列表
3.3 表分区及索引分区类型
1) 表分区
Oracle 10g提供4种主要的分区类型[5],范围分区、散列分区、列表分区和组合分区(也叫“复合分区”),如表2所示。
表2 数据表分区类型列表
2) 索引分区
索引分区的类型有2种,本地分区索引和全局分区索引[5],如表3所示。
3.4 分区维护技术
Oracle分区维护操作主要包括分区表的建立;表分区的添加、删除、拆分、合并、截断;分区索引的建立和重建。
表3 索引分区类型列表
在进行表分区的删除、拆分等维护操作时,务必通过附加update global indexes语句更新全局分区索引;否则,将导致全局分区索引失效。
在进行表分区的添加操作时,若当前表包含本地分区索引,则Oracle软件将自动在新加表分区所在的表空间中添加对应的索引分区。如需将索引分区和表分区存放在不同的表空间以提高读写性能,可通过alter...rebuild...语句重建索引分区,将索引分区重建到独立的表空间。
4 Oracle分区技术在接口监测系统中的应用
4.1 接口监测系统数据特征分析
接口监测系统是一个典型的大数据处理系统,系统数据具有以下特征。
1) 数据量大:系统中部分数据表单日记录数在2 000万条以上,部分数据表单日数据量在15 G左右。接口监测系统技术条件要求单接口的数据存储期限不小于3个月[6],故部分数据表的数据量将达到TB级别。
2) 存储时延小:发生C3无线超时故障后,需要第一时间对故障进行分析,因此存储时延要求较高。
3) 历史数据多:GSM-R网络维护人员一般仅使用最近一周的接口监测数据,且接口监测系统的软件仅对当日数据进行更新操作,因此接口监测系统中绝大部分数据为使用频率较低的历史数据。
4) 表结构维护频繁:系统配备的存储空间有限,为了保证新数据能够完整写入数据库,需要对数据表结构及存储空间进行频繁的周期性维护。
5) 可用性要求高:接口监测系统是C3无线超时分析的主要工具,因此对系统的可用性提出很高的要求。
对比接口监测系统的数据特征及分区技术的应用场景,为了保证接口监测系统Oracle数据库软件的长期稳定运行,Oracle分区技术是接口监测系统的必然选择。
4.2 分区技术应用方案
在接口监测系统中使用Oracle分区技术时,研发人员首先确定需要分区的表和选用的分区类型,再对选定的数据表进行分区管理工作。在进行数据查询及统计分析时,要利用Oracle分区表和分区索引分而治之的特性,提高数据统计分析的速度。具体应用方案如下。
1) 明确分区范围
接口监测系统中单接口的信令、业务数据及呼叫信息、综合分析子系统的故障分析结果和无线质量统计结果、网管子系统的告警数据和性能数据等数据表的单表数据量都很大,这些表中的数据需要保存较长的期限,故表中都有大量的历史数据,所以需要对相关的数据表进行分区。
2) 选定分区类型
铁路各业务系统在日常维护管理中,需向上级提供日报、周报或者月报用于进行问题分析或故障统计工作,接口监测系统也需要生成故障分析日报和故障统计月报。
接口监测系统的故障分析工作以日为单位进行,对数据进行查询和分析操作时也都指定明确的时间范围,因此,对选定的需要分区的单接口的信令、业务数据和呼叫信息等数据表采用按日范围分区的方式进行分区,对故障分析结果、无线质量统计结果等数据表采用按月范围分区的方式进行分区。同时,为了提高查询分析的速度,还选用了本地分区索引。
3) 分区管理
明确分区表范围且选定分区类型后,需要创建分区表,并根据需要对分区表进行周期性维护。接口监测系统数据库分区管理流程如图2所示。
4) 分区使用规则
在进行数据查询和统计分析操作时,应明确指明时间范围,确保数据能够命中所在的分区。另外,通过使用Oracle提示(Hint)强制修改默认执行计划,提高分区索引的利用率,从而进一步提高数据查询语句的执行速度。
4.3 表分区及索引分区的维护策略
图2 接口监测系统分区管理流程图
接口监测系统网管服务器软件负责Oracle数据库表分区及索引分区的自动维护。为了不影响在列车运行繁忙阶段大量接口监测数据入库和数据读取的速度,网管服务器软件在每天夜里的非繁忙时期进行分区的添加及删除处理。
5 结束语
Oracle分区技术的使用,可大幅提高接口监测系统数据的存储和读取效率,同时显著降低数据库维护工作的复杂度。今后,各路局需要监测的C3线路将持续增加,接口监测系统需要处理的数据量也会不断扩大,Oracle分区技术的使用方案也将根据实际情况进行不断的优化调整。
[1]申红雪,刘育熙.Oracle10g表分区技术管理[J].科技信息, 2008(20):44-98.
[2]孙奕鹏.Oracle分区技术[J].福建电脑,2009(6):70-84.
[3]杨志彬.Oracle表分区管理[J].福建电脑,2007(8):119-169.
[4]王时绘,李正君.Oracle分区技术研究及实现[J].科技广场,2011(9):86-89.
[5] Edward Whalen.基于Linux平台的Oracle Database 10g管理[M].陈曙晖,译.北京:清华大学出版社,2007.
[6]中华人民共和国铁路运输局.运基通信[2010]637号GSM-R数字移动通信网Abis、A、PRI接口监测系统技术条件(V1.0)[S].
The CTCS-3 radio interface monitoring system is a large data processing system used to monitor the radio communication network of CTCS-3 train control system. Using the Oracle partition technology can greatly improve the data storage and reading effi ciency, and signifi cantly reduce the complexity of database maintenance work.
Chinese Train Control System Level 3; Global System for Mobile communications-Railway; interface monitoring system; database partition
10.3969/j.issn.1673-4440.2016.06.003
2015-12-10)