（计算机科学与技术专业论文）综合结算系统在移动事业中的应用.pdf

中文摘要 综合结算系统是天津移动公司业务支撑系统的重要组成部分，天津移动与其 他运营商结算、省间结算、合作伙伴结算均可由综合结算系统在统一平台上承担。 本项目根据业务发展规划以及摊分结算系统的现状，建立基于完成网间结算、网 内清算、s p 结算、漫游结算功能的综合结算系统，以全面地解决各种业务的对 外结算和对内摊分功能的统一在综合结算系统中实现。现有的各类专业结算系 统，因为采用封闭式运作模式，功能界定和接口标准不规范，数据和信息资源无 法实现开放和共享，形成了一个个“信息孤岛”，已经不能适应通信运营业快速 发展的需要，制约了通信事业结算部分的进一步发展。针对这种现状，本项目对 结算系统进行了新的开发，保证在现有专业结算系统的基础上，通过业务流程的 重组，对现有专业结算系统进行升级、改造、扩建与整合，使结算系统能够适应 中国移动的发展需要。本项目不仅要满足目前移动语音，短信网间结算的具体情 况，而且要考虑今后移动高速发展的需要，同时满足信息产业部颁发的“网间互 联结算原则”的相关功能和要求。系统的设计采用了分层的模块化结构设计，共 分为以下几个主要功能：负载均衡模块、预处理模块、计费结算模块、统计分析 模块、数据管理模块、审核校验模块、查询服务模块、系统管理模块和外部接口 模块。同时溶入了参数驱动的设计理念。基于综合结算系统整体架构及性能，可 移植性，可操作性，可维护性考虑，采用c c + + 与p o w e r b u i l d e r 编写而成。综 合结算系统将更好地帮助天津移动完成企业外部和内部在互联互通中的费用结 算摊分，同时对现有业务运营和发展状况进行分析，为天津移动的决策者们提供 决策支持，支持中国移动事业的不断发展。 关键词：综合结算系统，标准话单，异常记录，结算批价。 a b s t r a c t m o b i l eu n i c o r ni n t e g r a t es e t t l es y s t e m ( m u i s ) i st h ei m p o r t a n tp a r to f t i a n j i n m 0 b 丑eb o s s ，b a s e do nw h i c ht i a n j i nm o b i l ec a ns e t t l ew i t ho t h e rc a r r i e r s ，b r o t h e r s u b s i d i a r yo fc h i mm o b i l e ，a n dp a r t n e r so nt h eu n i f o r mp l a t f o r mo fi t t h i sp r o j e c ti s d e s i g n e d ，b a s i n g o nb u s i n e s s d e v e l o p m e n tp l a na n dt h e a m o r t i z a t i o nc l e a r i n g - o f fs y s t e ms oa st os e tu pt h em u i so fg a t e w a yb a l a n c eo f a c c o u n t ，i n t e r n a lb a l a n c eo f a c c o u n t ，s pb a l a n c eo f a c c o u n ta n dr o a m i n gb a l a n c eo f a c c o u n t t h u sc a nt o t a l l yp u tv a r i o u sb u s i n e s ss u m m a r ya n da m o r t i z ei n t ot h em u i s c u r r e n ts u m m a r ys y s t e ma d o p mc l o s e do p e r a t i o nm o d e , w h o s ef u n c t i o ni sn o tw e l l r a n g e da n di n t e r f a c e sh a v en ou n i f o r ms t a n d a r d a l lo ft h e s er e s u l ti nt h ei n a b i l i t yo f t h eo p e n i n ga n ds h a r i n go fd a t aa n di n f o r m a t i o n a n di tr e s u l t si n i s o h t e di s l a n d o f i n f o r m a t i o na n dd o n t f i tt h e r e q u i r e m e n t o ft e l e c o m m u n i c a t i o n o p e r a t i o n d e v e l o p m e n t , a n db o t t l e n e c kt h ec l e a r i n g o f fd e v e l o p m e n to ft e l e c o m m u n i c a t i o n c a r r i e r b a s e do nt h ec u r r e n tc o n d i t i o n s ，t h ep r o j e c tt a k e sn e wr e s e a r c ha n dd e v e l o p m e n t t ou n d e r t a k eu p d a t e ，m o d i f i c a t i o n , e n l a r g e m e n ta n di n t e g r i t y , i no r d e rt h a ts y s t e mf i t s t h ed e v e l o p m e n to fc h i n am o b i l e t h ep r o j e c tm e e tt h en o to n l yd e m a n d so fm o b i l e v o i c e ，i n t e m e tm e s s a g ec l e a r - o f f , b u ta l s oh i g j a - s p e e dp o t e n t i a ld e v e l o p m e n to fc h i n a m o b i l e ，a n dt h er e q u i r e m e n t so f f u n c t i o no f “i n t e m e tc l e a r i n g - o f f p r i n c i p l e i s s u e db y c h i n a si n f o r m a t i o ni n d u s t r ym i n i s t r y t h es y s t e mi sd e s i g n e di nt h em o d e lo fl a y e r s s t r u c t u r e ，i n c l u d i n gl o a db a l a n c i n gm o d e l ，p r e - p r o c e s sm o d e l ，b i l l i n ga n dc l e a r i n g m o d e l ，s t a t i s t i ca n da n a l y s i sm o d e l ，d a t am a n a g e m e n tm o d e la u d i ta n dc h e c km o d e l ， i n q u i r ym o d e l ，s y s t e mm a n a g e m e n tm o d e la n de x t e r n a la c c e s sm o d e l a n di n v o l v e s t h ec o n c e p to f d a m - d r i v c nd e s g i g n t h es y s t e mi sw r i t t e ni nc c 十+ a n dp o w e r b u i l d e r , c o n s i d e r i n gt h es t r u c t u r ea n df u n c t i o n so fi n t e g r a t e dc l e a r i n g , t r a n s p l a n t a b i l i t y , o p e r a b i l i t y a n d m a i n t a i n a b i l i t yi n t e g r a t e db i l l i n gs y s t e m c o n t r i b u t e st ot h e i n t e r c o n n e c t i o nb e t w e e ni n t e r u a la n de x t e r n a lo fc h i n am o b i l et i a n j i n i nt h ef i e l do f t h ea m o r t i z a t i o no fi n t e r c o n n e c t i o ne x p e n s ea n da n a l y s i so f c u r r e n to p e r a t i o nb u s i n e s s a n d d e v e l o p m e n tc o n d i t i o n s ，w h i c hb o o s t st h eq u a l i t yo fd e c i s i o nm a k i n g t o d e c i s i o n - m a k e r sa n ds u p p o r tt h ed e v e l o p m e n to fc h i n am o b i l e k e yw o r d s ：m o b i l eu n i c o mi n t e g r a t es e t t l es y s t e m ，s t a n d a r dr e c o r d s ，r e p e a t r e c o r d s ，b i l l i n gp r i c e 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的 研究成果，除了文中特别加以标注和致谢之处外，论文中不包含其他人已经发表 或撰写过的研究成果，也不包含为获得苤鲞盘鲎或其他教育机构的学位或证 书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中 作了明确的说明并表示了谢意。 学位论文作者签名：才钞什 学位论文版权使用授权书 月f 夕日 本学位论文作者完全了解丞盗盘鲎有关保留、使用学位论文的规定。 特授权丞鲞盘堂可以将学位论文的全部或部分内容编入有关数据库进行检 索，并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校 向国家有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名：导师签名： 厘关镅 签字日期：砷年月夕日签字日期：夕，少年月少日 天津大学硕士学位论文综合结算系统在移动事业中的应用 第一章绪论 1 1 天津移动综合结算系统的目的和意义 综合结算系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结 构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等。 综合结算系统的开发完成为进一步加强各通信企业内部管理和考核，确保网间结算、 网内结算、s p 结算政策的正确执行，提高企业资金及时回笼的能力提供了更为方便 的工具，并进而促进了互联互通工作的健康发展。 1 z 天津移动综合结算系统项目建设背景 随着我国电信市场体制改革的不断深入进行，电信运营业进行了优化重组，使 国内电信运营业呈现出多元化的趋势，近一段时间天津移动通信有限公司推出了大 量的新语音、数据新业务，结算业务种类的不断增加以及结算规则的不断变化，对 结算系统提出了越来越高的要求。中国移动在成功上市后，面临更为激烈的市场竞 争形势。中国移动既要完成与其它电信运营商间的结算处理，又要完成内部各法人 实体( 省公司) 摊分处理，以及专业间成本核算等问题。因此，建立一套完整的综 合结算系统，己成为中国移动当前的重要任务。 综合结算系统将更好地帮助天津移动完成企业外部和内部在互联互通中的费用 结算摊分，同时对现有业务运营和发展状况进行分析，为天津移动的决策者们提供 决策支持，支持中国移动事业的不断发展。 1 3 论文研究的主要内容 本项目系统涵盖结算业务的预处理、批价、排重、审核校验、对帐、查询统计、 安全管理等处理过程。电信运营商各业务的网间结算均应该在综合结算系统中实现。 系统的设计采用了分层的模块化结构设计n 3 ，共分为以下几个主要功能：负载均衡 模块、预处理模块、计费结算模块、统计分析模块、数据管理模块、审核校验模块、 查询服务模块、系统管理模块和外部接口模块。同时溶入了参数驱动的设计理念。 第一章绪论 基于综合结算系统整体架构及性能，可移植性，可操作性，可维护性考虑，综 合结算系统采用c c + + 与p o w e r b u i l d e r 编写2 1 而成。 通过本系统的建设，应要达到以下目标： 1 建设统一集中处理传统网间结算、s p 结算、漫游结算的综合结算平台； 2 采集各交换机结算原始数据等，进行结算处理； 3 接收全国中心集中结算业务通过融合计费系统下发的各种结算数据，进行本 省的结算处理副： 4 接收各结算对象传送的结算结果数据和融合计费系统传送的全国中心的资料 信息，并进行审核校验； 5 按结算对象，对采集、计费等其他功能域传输的数据进行综合结算处理，并 将结算结果数据传送给各结算对象； 6 生成地市问、与其他电信运营商间、合作伙伴运营商间等的结算清算报表， 配合财务部门进行本省综合结算收入的汇总、分摊和划拨工作h 3 ； 无津大学硕士学位论文综合结算系统在移动事业中的应用 第二章综合结算系统总体设计 21 综合结算系统的总体架构设计 综合结算系统的总体结构体系如图2 - 1 所示： 移魂窝鬃静瞍啪 体系 焦# 、负# 集中控瓷柑* 理 信息啬自 一一曼n 4峦 信 - 自棱睦女 - 自m 目 管理 锗单回收 回j 县 ” 一、 世。苎一8 算、8 算“譬- 总- 渭单誊湘螂够 1 月目镕算 月自清算i m 目 缱 l 请单敷姑盼析 数据统” - 魏话出库* 析氍示 月闻结算日内麟萁他项目 图2 - 1结算系统的结构体系图 说明： 1 经过统一的软件传输平台把数据收集到结算中心，系统的负载均衡系统 将根据数据量及系统进程的状态对所要处理的数据进行分通道自动调节； 2 在预处理将对记录进行标准化并根据可以配置的逻辑表达式按照规则 把数据分大类为网间结算、网内清算、s p 结算、漫诂竿结算及其他的业务数据； 3 批价结算模块根据传输来的话单文件，按照定义的业务逻辑规则将结算 第二章综合结算系统总体设计 4 大类的数据具体进行结算原则的标识，以决定其具体的结算的类型，同 时判断其批价、优惠的方法； 5 结算处理模块将对清单进行汇总统计，同时将参数结算摊分的费用， 以形成初步的统计要素，为出报表做相关的准备。 6 数据分析模块将对结算处理的网间结算、网内清算、s p 结算、漫游结 算的数据按照最小粒度进行累加统计，产生不同业务类型的统计信息巧】； 7 处理完成的清单数据和统计等数据由数据分发模块进行数据的分发处 理，系统将对数据进行轻度的数据汇总，并把汇总后的数据交于数据分析功能 部分，用于深层次的分析统计和相应的展示功能。 其他的功能模块将完成相应的功能，其中相关的功能模块将把相关的运行状态 和运行结果传向信息总线，由信息总线统一完成对信息点的处理；其中信息总线是 我公司定义并用于软件内部信息交互的通道1 。 2 1 1 综合结算系统的物理架构 图2 - 2 综合结算系统物理架构 2 1 2 综合结算系统的逻辑架构 目前天津移动存在多种业务同时经营，这样的特点带来众多业务的网间结算、 - 4 - 第二章综合结算系统总体设计 网内清算( 省间摊分和业务间的成本核算) 等需求。随着一些先进的通信技术( 3 g 等) 的引入，将来还会有更多的语音、数据新业务推向市场，新业务同样也需要综 合结算系统的支撑。面对如此复杂的结算需要，如何考虑综合结算系统的建设将直 接关系到各项业务的开展乃至在激烈的市场竞争中的生存和发展。 为此，在此次考虑天津移动综合结算系统的设计框架时，我们参照了以下设计 理念，用以指导本次系统的设计和开发。 1 、 业务参数化、模块化 业务参数化、模型化是指对结算业务的需求进行分析和归纳，建立起统一的结 算模型，使各种业务的特性参数化，从而保证系统的通用性和灵活性h 。同时因为 综合结算所处理的结算业务的多样性，结算、摊分种类的复杂性，因此对结算和摊 分的参数需要进行合理的设置以满足网间结算、s p 结算、漫游结算、网内清算的需 要，在系统参数的设计时把参数中分为公用的参数( 如：区号表、省号表、i m s i 表 等等) 、系统参数( 如：告警方式定义表、模块定义表等等) 、专用参数( 结算规则 定义表、结算原则判断表等等) ，这样将使系统的参数进行合理的设置。 2 、 系统功能组件化 系统功能组件化是指对于系统中的业务功能的实现采用面向对象技术阳3 进行设 计、分析和封装，系统实现被封装成独立的业务组件，不同的业务组件完成不同的 业务处理功能，业务组件为系统开发、维护和升级提供良好的支持，并保证系统的 开放性、可维护性和可扩充性。 3 、 业务的可配置化 业务可配置是指综合结算系统所完成的具体结算业务是通过配置来实现的。结 算业务更改也可以通过对配置更改来实现，而不需要对系统程序的修改。 系统的软件设计模式采用面向对象的设计方法四3 ，把整个系统设计构架分为四 个层次：应用与管理层、业务逻辑对象层、系统管理对象层和物理层。此次设计的 系统构架对不断增长的新业务和新需求的开展具有很大的延续性和扩展性们，对减 少用户的重复投资具有非常大的价值。 第二章综合结算系统总体设计 圈2 _ 3 综合结算系统逻辑架构 在上图中，将综合结算系统从逻辑上分为三个层次：数据服务层、业务处理层和管 理层。 敢据服务层：在省中心建立统一的数据中心，对各个子系统的数据进行集中规划、 分配、存储、安全保护和管理。它不注重数据的业务特性，而只是关注数据本身 的存储和管理，实现数据与业务逻辑的分离。 业务处理层：在数据中心集中存储的基础上，针对不同数据的业务特性，提炼出 企业的核心数据模型；然后根据不同的业务制定相应的规则组件，并将具体的业 务规则组件分解为原子处理过程，通过原子处理过程将数据和业务逻辑关联起 来。一系列的业务流程就构成了一个专业的业务处理子系统。通过这种深入的分 析后，可以形成天津移动综台结算系统的标准业务规则组件，在此基础上可以通 过天津移动综合结算的流程实现灵话的结算业务流程优化和重组。 第二章综合结算系统总体设计 应用与管理层：主要在内部核心处理的基础上提供高层的管理功能，包括系统配 置查询统计 、系统管理、在线分析、操作维护和外围的接口等，为企业领导、 上级业务主管部门、相关业务部门、系统管理维护人员等提供方便实用的管理和 分析工具。 2 2 综合结算系统的软件体系架构 图2 4 综合结算系统软件体系架构 综合结算系统的设计采用了分层的模块化结构设计，共分为以下几个主要功能： 负载均衡模块、后台预处理模块、计费结算模块、统计分析模块、数据管理模块、 审核校验模块、查询服务模块m 3 、系统管理模块和外部接口模块。 第二章综合结算系统总体设计 2 3 综合结算系统的数据库设计 2 3 1 数据库物理结构 为了提高系统性能，应该根据应用情况将数据的易变部分与稳定部分、经常存 取部分和存取频率较低部分分开存放，综合结算系统以此原则将参数、清单、统计、 日志设计为分开存储。 o r a c l e 以表空间形式存储数据库的数据，包括表、索引、对象( o b j e c t ) 、序列 号( s e q u e n c e ) 、存储过程、回滚段和临时段等。表空间是o r a c l e 数据库的逻辑结 构，每个表空间又由若干的物理数据文件组成n 朝。 表空间划分充分考虑了综合结算应用处理的需要，按各表空间所存储的数据库 对象来对表空间进行命名。同时应兼顾性能的优化，尽量将可能并发存取的数据分 布在不同的物理硬盘上使i o 负载均衡，以减少资源竞争和冲突、提高系统处理性 能。 表空间的划分，遵循了如下的原则： 综合结算系统数据必须与系统数据字典的数据分开存储于不同的表 空间。 按数据功能( 静态数据、清单数据、统计数据等) 划分数据，不同 功能的数据应存储于不同的表空间，减小一个表空间的数据影响多个功能 的数据。实际情况下将建多个清单表空间( 提高查询速度，利用并行查询 机制) 按结算业务管理需要独立处理或维护的数据，例如独立进行数据备 份或清理，应考虑存储在独立的表空间。 表和索引应分离，需存储在不同的表空间，以便分布到不同的数据 文件、硬盘上，并分别进行不同的物理存储参数优化。 并行存取的多个分区，应考虑存放在不同的表空间，以控制分区分 布到不同的数据文件、硬盘上。 相对静态的表和频繁变动的表分开存放在不同的表空间以便分别进 行不同的物理参数优化。 所有的表空间管理采用l o c a l m a n a g e r 管理方式，数据段( s e g m e n t ) 采用选用 a u t om a t i c a l l ys e g m e n tf r e e s p a c em a n a g e m e n t 方式。 e x t e n tm a g e m e n tl o c a la u t oa l l o c a t e s e g m e n ts p a c em a n a g e m e n ta u t o - 8 - 第二章综合结算系统总体设计 o r a c l e 的初始化参数的调整( 考虑到系统的实际情况，s g a 可以小一点) 数据库采用o r a c l e 默认安装方式 2 3 2 数据库存储设计 一般数据库里的数据是需要遵守范式的，但是我们根据应用的业务特点，在性 能的要求下，采用一些信息的冗余设计，目的是减少大表关联，减少逻辑i o 和物理 i o 。 按字段值进行的范围划分；按字段的h a s h 函数值进行的h a s h 划分；先按范围 划分，再按h a s h 划分的复合划分：在o r a c l e 9 i 中又增强了按字段值列表进行的列 表( l i s t i n g ) 划分方法。 分区是一种“分而治之”的技术。 考虑的因素： 表的大小 对于大表进行分区，将有益于大表操作的性能和大表的数据维护。通 常当表的大小超过1 5 g b - - 2 g b 应考虑对表进行分区。 对清单表与统计清单表采用分区设计。 清单：月、地区 统计清单表：结束日期 数据访问特性 基于表的大部分查询应用，只访问表中少量的数据。对于这样表进行 分区，可充分利用分区，排除无关数据查询的特性。 数据维护 某些表的数据维护，经常按时间段删除成批的数据，例如按月删除历 史数据。对于这样的表需要考虑进行分区，以满足维护的需要。因为删除 ( d e l e t e ) 大量的数据，对系统开销很大，有时甚至是不可接受的。 并行数据操作( p a r a l l e l d m l ) 对于经常执行并行操作( 如p a r a ll e li n s e r t ，p a r a l le l u p d a t e 等) 的 表应考虑进行分区。需要修改o r a c l e 的初始化配置参数。 当确定分区字段时，有两个主要因素特别需要考虑： 第二章综合结算系统总体设计 增强表的管理和维护性 通过p a r t i t i o n k e y ，可以使数据维护基于某个分区进行，如d r o p 或 t r u n c a t e 一个或多个分区。通过p a r a t i t i o n k e y 可控制只读的数据存储 在相应的分区中，且这些分区存储在只读的表空间里，这将提高数据各份 的性能。这类p a r t i t i o n k e y 通常与时间相关。 提高访问表的性能 通过p a r t i t i o n k e y ，可使查询的数据定位在一个或少量的分区中；这 需要考虑最常用的查询条件。注意在考虑提高查询效率这个因素的同时， 还应兼顾数据维护管理的因素，尽可能地避免相互间地冲突。 考虑到对清单及统计清单的查询主要基于通话结束日期做一些查询统 计，所以我们在相关字段上建分区。 索引的设计： 索引一定是本地索引，不能创建全局索引 索引主要是用来提高查询速度，但在对表进行更新操作时由于牵涉到索引的 更新，速度有所降低。 主要正对经常做查询、分组统计的字段建索引，并存储在与表不同的表空间 中。 2 3 3 数据库备份设计 逻辑备份 采用磁盘阵列的r a i d 方式： e m c 采用r a i d o + i i b m 的s h a r k 阵列采用r a i d 5 数据库系统软件的丢失可能会给正常运行的数据库系统带来不可回避的故障， 数据库的一些系统进程和服务进程的自动重起和自动产生都将终止。数据库系统软 件固然可以通过介质来重新安装，但是恢复步骤比较繁琐和恢复速度缓慢，因此需 要进行数据库系统软件的备份。当发生系统软件丢失时，可以直接通过备份来恢复， 恢复步骤简单，恢复速度迅速。 全库结构备份 每个数据库的全库逻辑备份将使用e x p 的f u l l = yr o w s = nc o m p r e s s = n 模式 进行，备份文件名为： 一f u l 1 d m p 。该备份文件仅是整个数据库的逻 第二章综合结算系统总体设计 辑结构，不包括任何表中的任何数据内容。 全用户备份 对于某些用户，比如省中心库0 z 用户、计费库p a l ( a m 用户、联机指令库 o l c o m 用户等等，整个用户的数据量非常小( 4 g b ) ，则采用全用户备份的方 式模式进行备份。e x p 备份命令参数为：o w n e r - - c o m p r e s s = n ，备份文 件为： 一 d m p 。该备份文件是整个用户的所有对象的，包括 全部数据的备份，在恢复时可以直接恢复整个用户的全部内容，也可以指定个 别表进行表数据的恢复。 分类备份 对于营业、帐务等数据库中的数据表( 相对全局临时表) 实际属主用户， 由于数据量巨大，一般都是在上百个g b ，所以需要对数据表进行分类后进行备 份。表分类主要依据表空间的分类，即认为同一个( 套) 表空间上的数据表为 同一个类别的。 分月备份 某些类别的表，比如帐务中间表、明细帐单表等，都是按照月份进行拆分 的，一个月一张( 套) 表，这些表仅在当前月份才会用户数据处理、存储、更 新，在其他月份仅做查询，而数据是不会发生任何变化的。所以，针对这种情 况，在e x p 逻辑备份其数据时，根据其特征进行分月备份，即仅在当月进行当 前月份表的备份，其他月份的表则不再做重复备份。 特别注意：对于非当前月份的分月备份文件，在主机的备份文件系统上是 不保留的，所以必须要磁带库中对这部分文件一直都保留，直到下一年的该月 备份文件产生才能更新。 备份文件压缩 所有备份出来的备份文件，统一使用g z i p 最大压缩比率( 参数为- 9 ) 进行 压缩。压缩后的文件名上再添加当前日期，最后都存放到磁带库准备目录下， 供磁带库备份。 夺备份文件传输 个别情况下，由于某些主机没有安装自动备份文件到磁带库的软件( 如 v e r i t a s 的n e t b a c k u p 之类) ，则需要将这些主机上备份压缩好的文件传输到相 应已经安装备份软件的主机上，一般可以通过f t p 方式完成各主机之间的备份 文件传输。 存放时限 第二章综合结算系统总体设计 备份的数据量较小，可以在备份文件系统上存放最近2 天的备份文件。而 数据量巨大库，如果多存放一天，往往会影响备份，所以每次开始备份时都要 将前面的备份文件都删除，即只存放最近一次的备份文件。 备份文件在转储到磁带库后，建议至少存放最近一周的全部备份文件。对 于分月备份的，则也必须至少存放备份月份的最后一周的文件。 逻辑备份的恢复策略 逻辑备份主要侧重于对表级的数据备份，针对个别表的数据丢失进行的数据恢 复。即使用i m p 带t a b l e s 参数，将指定的某些表数据从备份文件导入到数据库的对 应数据表。由于，逻辑备份并没有备份整个库中所有数据表，所以使用逻辑备份文 件是无法恢复所有表的数据的。逻辑备份也是仅在每天夜间进行一次备份，备份的 数据是各数据表备份执行时刻的静态数据，所以备份文件的数据也尽是备份时刻的 历史数据 t 4 3 0 如果需要重建整个数据库，可以使用全库各份文件进行整个数据库逻辑结构的 恢复。否则，不建议使用该全库备份文件作任何恢复操作。 如果需要完整恢复某个小数据量的用户，可以使用全用户备份文件进行对整个 用户的内容恢复。当然，也可以通过指定t a b l e s 来对某些表的数据进行恢复。 分类备份的备份文件在用于恢复的时候，必须要指定t a b l e s 内容来确定对具体数据 表的数据的恢复。根据备份文件的文件名中的日期，可以判断是哪一天的备份文件。 不同日期的备份文件数据一般都是不同的，恢复时要明确表要恢复到哪一天的数据。 导入备份数据时，也要确定是否要部分或者全部清除数据表现有数据，避免数据重 复。 物理备份与恢复 使用r m a n 备份数据库常用的方案主要有以下两种： 0 级备份+ 1 级备份+ 归档日志的备份 0 级备份+ 归档日志的备份 前一种方案存在的主要缺点是1 级备份对系统性能影响较大。如果性能变化较 小，推荐就使用这种方案。 对于第二种方案存在的主要缺点是每次直接0 级备份，必然要求0 级备份的频 率很高，直接导致的情况就是：需要的磁带空间非常大，在磁带库资源有限的情况 下导致备份的数据保存的时效较短。 第二章综合结算系统总体设计 以下是关于一个数据库备份的2 种具体安排 ( 1 ) 星期天晚0 级备份+ 1 次日志的备份 星期一晚1 级备份+ 1 次日志的备份 星期二晚 1 级备份+ 1 次日志的备份 星期三晚 1 级备份+ 1 次日志的备份 星期四晚1 级备份+ 1 次日志的备份 星期五晚 1 级备份+ 1 次日志的备份 星期六晚 1 级备份+ 1 次日志的备份 ( 2 ) 每天晚上一次0 级备份+ 1 次日志的备份。其他时间再安排日志的备份。 不过如果系统日志切换频率不高，可以适当延长两次0 级备份之间的时间 间隔。 不论是第一种，还是第二种方案，如果系统日志切换频繁，可以在一天中的合 适的时间，在保证不影响其他备份的前提下，增加一次或者几次日志的备份。根据 目前我公司现有系统性能等各方面的情况，综合考虑，我们采用第二种方案进行物 理备份。 2 3 4 数据库逻辑设计 1 数据库用户设计 s y s ，s y s t e m 系统自带用户。 m u i s s a ：综合结算系统数据库管理员是综合结算数据库中所有对象( 包括表、 规则、存储过程、触发器等) 的所有者，能够对数据库中所有对象进行增加、修改、 删除等操作。 m u i s u s e r ：综合结算系统数据库操作员，具有对数据表对象进行日常管理和维 护的权限，对库表紧限于查询及执行查询所必须的存储过程等。 同时我们可以通过修改o r a c l e 的配置文件n 胡来限制某个i p 地址的机器对数据 库的访问，另外我们针对维护人员的任何一次登陆( w i n 端程序) 及操作都有日志 记录：i p 、机器名、操作对象、日期、进行何种操作等。 第二章综合结算系统总体设计 2 3 5 数据库安全设计 基于权限控制的需求，d b a 组限制使用9 | 。 数据库安装用户 用户名及其口令：o r a c l e 主目录：o r a c l e大小6 9 ，内置盘。 系统文件备份目录：o r a 9 i ，( a i xj f s 2 的r b r wm o u n t 的文件系统) ， 大小l o g ，内置盘。 日志目录：o r a c l e o g ，( a i xj f s 2 的r b r wm o u n t 的文件系统) ，大小4 9 ， 内置盘。 a r c h i v e l o g 目录：a r c h i v e l o g ( a i xj f s 2 的r b r wm o u n t 的文件系统) ， 阵列，根据备份的数据量来计算 权限：d b a 组权限。 令数据库备份用户 用户名及其口令：b o s s b a k 主目录：b o s s b a k ( a i xj f s 2 的r b r wm o u n t 的文件系统) ，阵列， 根据备份的数据量来计算。 权限：s t a f f 组，执行c r o n t a b 权限。 数据库监控用户 用户名及其口令：，m o n i t o r 主目录：m o n i t o r ，大小l o g ，内置盘。 权限：s y s t e m 组，s t a f f 组，执行c r o n t a b 权限。 令网管监控用户 用户名及其口令：t o p t e a 主目录：t o p t e a ，大小5 9 ，内置盘。 权限：s y s t e m 组，s t a f f 组，执行c r o n t a b 权限。 2 3 6 数据库接口设计 通过m u i s u s e r 用户开放外界系统查询权限，通过d b l i n k 与外界的相关接口表 进行交互。 第二章综合结算系统总体设计 2 3 7 数据库监控设计 系统设计监控功能，通过后台字符控制界面或者前台监控功能都可以实时监控 到当前数据库系统的对象，及相关的性能参数。 2 4 数据库对象设计 数据库对象命名设计原则大致有：可读性和易读性；单元含义表述的唯一性； 语义表述短小精悍；功能性n 朝。 为降低维护工作量，此次的系统设计我们采用了“统一标准清单”结构。 命名规则 静态参数表 各省共用的静态参数：以“s 一”作为前缀 各省本地化的参数：以“t p _ ”作为前缀 版本控制表 以“e - ”作为前缀 历史参数表 以“h 一”作为前缀 清单表 以“一”作为前缀 统计要素表 以“t e 一”作为前缀 日志表( 处理日志、操作日志、告警日志等) 以“t g 一”作为前缀 临时表 以“t m p 一”作为前缀 接口表 以“t i 一”作为前 索引命名规则 i d x 一 p k f ku n q 一 一 p k ：用于主键的索引 f k ：用于外键的索引 第二章综合结算系统总体设计 u n q ：唯一性约束索引 ：表名的缩写 ：索引字段名的缩写 约束命名规则 p kf kiu ! n qc h k 一 一 p k ：如果是主键 f k ：如果是外键 u n q ：唯一性约束 c h k ：c h e c k c o n s t r a i n t s ：表名的缩写 ：约束的简单描述。 存储过程命名规则 p _ ：存储过程功能的简单描述。 触发器命名规则 t r a idu i d i u ：表示触发器的触发事件。u ：更新时触发、i ：新增时触发、d ：删 除时触发。 ：表名。 视图命名规则 v ：表名的缩写。 天津大学硕士学位论文 综合结算系统在移动事业中的应用 第三章综合结算系统的设计实现 通过各个功能模块的设计实现了综合结算系统的业务功能。在基本的设计理念 上，后台处理模块采用c + + 前台维护模块采用p w o e r b u i d e r ，均采用面向对象的 设计方式“”。后台系统依赖各种u n i x 系统，前台系统依赖于w i n d o w s 系统。 设计综合结算系统的功雏模块，采用丁以下的主要设计思想： 总统规划，统一架构 参数驱动，尽量将可变量参数化，如果有变动不必更改代码 成熟组件，支撑不同业务处理 前后台模块通过s o c k e t 进行交互“” 模块结构图如图3 - 1 所示： 图3 - 1 模块结构图 采集传输( 数据获取) ：对综合结算系统而言，采集数据源就是集中采集机上面 的各类业务数据。采集传输模块将从集中采集机采集到的数据文件进行改名后 分别传输到系统指定的目录下： 预处理：对原始记录进行转换、检验、归整、标准化等工作，然后按照规则分 拣数据，分为一次预处理和预处理两个过程，一次预处理侧重解析不同交换机格 式，预处理根据解析的格式进行统一处理： 第三章综合结算系统的设计实现 批价处理：对预处理输出的使用记录文件，结合计费规则、优惠规则，完成计 费批价；结合结算类型、结算规则完成结算批价；经过排重处理后输出正常记 录文件( 清单文件) 、错误记录文件、异常记录文件、重复记录文件以及无效记 录文件； 入库统计：对批价排重后的清单数据进行汇总统计，形成最小粒度的统计要素； 对统计数据进行累加，根据结算规则，进行结算处理；可将清单选择导入数据 库； 数据分发：根据需要将清单文件、结算报表、统计数据等以文件方式分发到其 他运营支撑系统、财务系统等； 回收处理( 后台) ：根据前台界面程序传递的回收条件，对存放在异常使用记录 表中的异常使用记录进行回收处理； 对综合结算系统的各种数据文件、日志文件和数据库中的数据( 参数数据、使 用记录数据、报表数据等) 进行存储备份；出现故障时根据备份进行恢复；对超过 在线保存期限的过期数据进行转储和清理。 3 1 预处理模块 3 1 1 预处理文件级校验子模块 1 预处理文件校验子模块的处理流程 预处理文件级校验子模块对采集系统传输过来的原始交换机文件名进行匹配， 搜索出符合文件匹配规则的原始交换机文件名，然后将它们进行改名，即用文件i d 代替原始文件名，便于预处理进行处理。同时，尽量均衡的向各个进程通道下分配 文件，提高系统资源的利用率。这是一个系统的后台进程，由集中监控的代理负责 程序的启停。预处理文件校验子模块由主进程依次调用初始化函数、文件名匹配函 数、文件改名函数、负载均衡函数、文件解压来完成该模块的处理流程，流程图如 图3 2 所示： 第三章综合结算系统的设计实现 写告 图3 2 预处理文件校验子模块的处理流程 经过文件级校验子模块的处理，将从集中采集机上采集过来的各种原始使用记 录文件和其他平台的数据文件改名。改名后的文件命名规则如表3 - i 所示： 表3 1 改名后的命名规则 第三章综合结算系统的设计实现 编号字段类型长度 说明 1 字符型3 位3 位数据源i d ( 通道号) + 分隔符 2字符型8 位8 位日期( 年月日) + 分隔符 3字符型6 位 6 位序列号+ 分隔符 4 字符型2 位2 位模块号 同时在模块运行过程中跟据相应的处理结果，填写日志，以便集中监控系统计 是准确的将告警信息反映给该业务的维护人员。错误控制如表3 - 2 所示： 表3 - 2 错误控制 错误场景错误通告错误日志恢复方法 路径打开错误写告警日志路径打开错误程序退出 搜索文件错误写告警日志搜索文件错误程序退出 文件打开错误 写告警日志文件打开错误跳过该文件 读配置文件信息错写告警日志读配置文件信息错程序退出 文件移动错误写告警日志分拣规则语法错误程序退出 文件解压缩错误写告警日志文件解压缩错误跳过该文件 2 预处理文件级校验子模块的功能 程序初始化 通过读写配置文件( p a s i n i ) 模块和参数( 数据库参数表) 模块，读取并初始 化配置文件中的信息，包括源文件输入通道、与输入通道对应的输出通道、文件名 匹配规则，文件传送规则，源文件备份标志、备份路径等信息。分别调用集中监控 模块和日志告警模块初始化接口，初始化集中监控和日志告警，形成存放在内存的 各种参数。 文件名匹配 按照文件名匹配规则，在输入通道下搜索原始使用记录文件。对搜索到的文件 名进行校验，判断是否为目录，同时校验文件的属性是否正确，然后再进行匹配规 则匹配。对符合匹配条件的文件，如果是压缩文件，则调用系统函数进行解压缩。 对符合匹配条件的非压缩文件，调用文件改名函数进行改名处理。同时忽略不符合 文件名匹配规则的文件。然后，重复以上处理过程，直到该通道下文件已经搜索完 毕，输出符合匹配规则的源文件。 第三章综合结算系统的设计实现 文件改名 按照文件改名规则对文件进行改名处理。用文件i d 代替原始文件名。将当前时 间戳加入文件i d 。向负载均衡函数传送改名后的文件i d 。每个文件改名后生成一条 改名日志，最后输出预处理所需要的文件i d 。 负载均衡 在此次系统中引入了负载均衡的理念，大大提高了系统的处理速度。 负载均衡主要采用了轮循方法，搜索配置文件中配置的该输入通道对应的所有 输出通道，找到一个文件总数最小的通道。向最小通道传送改名后的文件直到所有 输出通道达到文件总量满足配置文件所设定的文件传送标准。根据文件备份标志， 决定原始文件是否备份，如果需要备份，则将原始文件备份到备份路径中，原始文 件名不变，删除原始文件，同时向符合条件的通道分发改名后的文件i d 。 文件解压 本模块能自动对压缩过的原始文件进行解压，以利于预处理进行处理。本模块 支持的压缩文件格式为：z 和g z 。 3 1 2 预处理子模块 1 预处理子模块的处理流程 预处理模块负责对文件校验传送来的文件( 原始记录数据文件、回收的数据文 件) 进行记录的格式转换、原始记录校验、号码规整、记录分拣过滤以及标准化输 出等各种准备工作，以便结算系统进行批价和结算处理。支持在格式转换后生成