BOSS广电运营商（精选7篇）
BOSS广电运营商 篇1
当前,广电网络正处于从数字电视迈向互动电视的过渡时期,新的业务不断涌现。无论是基于三网融合下行业发展的需求,还是在互联网、新媒体浪潮下市场竞争的需求,业务运营的多元化以及管理服务水平的提升都是有线运营商迫切需要解决的问题,这必然对其运营的业务支撑平台提出更高的要求。
如何结合广播电视实际情况,运用信息技术在在整体层面上构建广电网络业务运营支撑系统(BOSS),以快速提升其运营水平、管理效率及服务能力,真正实现企业转型,成为全行业共同面临的课题。
起源
BOSS是业务运营支撑系统的简称,通常所说的BOSS系统涵盖了计费和结算系统、营业与账务系统、客户服务系统、决策支持系统等功能,可对各种业务功能进行集中、统一的规划和整合,是一体化的、信息资源充分共享的支撑系统,是网络运营商的一个综合业务运营及管理平台。
业界一个普遍的看法是,BOSS起源于电信。在电信业务运营的初期,由于系统建设经验不足,各业务系统建设分割独立,自成体系,数据无法共享,严重影响了业务运营和客户服务,基于此,建设一套统一的、能覆盖所有业务的综合业务运营支撑系统成为现实之需,而计算机技术的快速发展也为建设这样的系统提供了可能。特别是分拆出来的中国移动基于全程全网和管理众多增值业务的需要,提出了“业务支撑网建设五年规划”,率先在2002 年完成了初步的BOSS集中化和客户集中化,对多元化业务形成了支撑。随后以固网业务为主体的中国电信和中国网通等也纷纷完成BOSS系统主体建设。
在电信行业得到广泛应用的业务运营支撑系统被证明是一种精细化、集约化的管理工具,能够不断优化多元化业务运营能力,提升管理和服务水平,特别是可为各项基础业务以及增值业务的运营提供持续有力的支撑。
同样的道理,广电业务管理系统的信息化以SMS为开端,当时全国很多广电网络公司均部署了这套系统,但是随着有线电视数字化、双向化的转型,有线电视的业务逐渐多元化,除了直播频道之外,不仅包括付费频道、点播业务、宽带业务以及各类数据增值业务,而且还涉及到呼叫客服系统、线上/线下营业系统、缴费系统等外围配套设施,SMS已经越来越不适应企业需求。
其主要体现在:1)早期模拟电视或数字电视产品很少、运营模式单一,用户在订购模式上大多使用购买一年、半年等按时段订购,而随着广电业务的快速发展,由于SMS难以扩展不支持多业务,导致分业务独立建设,信息资源无法共享,客户资料不统一,难以打包优惠融合计费,非常不利于市场工作的开展;2)SMS系统在流程支持上重点解决信息管理问题,这在模拟电视乃至早期数字电视是没有问题的,但是在业务多元化时代对流程的支撑力度不足,不支持多产品、使用量的产品计费,不支持预后付费业务产品,非常不利于业务的上线、管理和结算。
正是在此背景下,广电网络逐渐从SMS升级过渡到BOSS,以提升自身的运营水平、管理效率和服务能力。
作用
整体而言,在目前的大环境下,广电网络建设BOSS主要可归纳为以下三方面的作用。
1. 增值业务的需要。
BOSS系统能够将现有分散的数字电视业务、互动电视业务、数据宽带业务以及众多的卡拉OK、教育、游戏、商城等增值业务进行全面整合,更为重要的是,广电网络公司依托BOSS系统,能够根据用户需求改变、竞争对手产品改变等反馈信息,快速将各类视频、宽带、增值业务等多业务进行整合,在业务流程上可以通过人工工单流转和电子工单流转对业务流程进行订制,并且可以按账期计费、出账,实现对不断变化业务流程的支持,从而获得用户认可,提高了市场竞争力。同时,通过向IT要生产力,运营商逐步从单一的频道传输角色向综合业务提供商角色转变。
2. 后网络整合的需要。
在一省一网整合政策推动下,目前全国绝大部分省份都已经完成了一省一网整合,而且这种整合正在从行政层面向网络及业务层面深化,之前各地市独立前端平台的管理系统需要迁移到统一的省网平台中去,在便于数字电视业务的统一管理和增值业务的统一运营的同时,发挥用户规模优势。因此,无论各地市的BOSS系统是否完备和具有前瞻性,网络整合的下一步都将需要建设全省统一的,适应多业务发展需要的BOSS系统。
3. 外围支撑的需要。
在三网融合背景下,有线电视所面临的市场竞争压力越来越大,这种竞争压力不单纯是业务层面的,更是管理与服务水平的竞争,用户理所当然的要拿广电的服务水平与电信乃至互联网的服务水平PK,他需要的是随时随地的业务咨询和开通,需要的是便捷的业务办理与支付。而广电网络传统的业务管理系统主要是从“客户”角度出发的,管理味道浓、服务味道弱,对这种新需求并不适应。而BOSS系统能够与客服体系、营业体系、支付系统等外围支撑形成统一系统,实现统一的客户模型、账务模型、产品模型,提高业务管理与服务水平。
因此,无论从哪方面来讲,BOSS已经成为广电网络必不可少的系统,所不同的只是系统的规模大小及部署前瞻性。
部署
对于正在转型中的广电网络,选择BOSS至少需要关注两个因素,其一是稳定性,因为运营商转型多业务之后,系统的复杂性变大,作为企业的核心产品,BOSS必须具备安全和可靠性;其二是可扩展性,随着广电网络的业务不断增长,其用户数、整合的业务内容不断增加,对BOSS的灵活性与可配置性要求将不断提高。
因此,虽然BOSS发源于电信,甚至很多广电行业的BOSS厂商背后或多或少都有电信行业的身影,但是广电在网络、业务等方面的特点却决定了广电BOSS绝不能照搬电信。其一,广电网络许多环节的设备和系统都不具有统一的接口标准规范,其对广电业务的统一运营造成了很多不便,无法像电信一样有非常统一的业务运营流程和规范;其二,广电网络相对分散,规模均较小,且各个网络之间没有互联互通,而电信网络不仅运营商互联互通,且是全程全网的。这些差异让广电BOSS的定制化色彩更浓,单用户成本也比电信高的多。
广电网络在建设BOSS系统过程中需要充分考虑与电信的各种差异性,才能真正为实际的业务运营带来支撑,否则这个BOSS就是一个好看不中用的系统。目前全国许多省份都已经上线BOSS系统,比如广州珠江数码、重庆有线、东方有线、山东广电网络、河北广电网络、江苏广电网络、新疆广电网络等,有一些是网络整合后建设新的统一系统,有一些是在原有建设基础上继续升级。但都不同程度地与BOSS系统建设厂商结成了紧密的合作关系,就是因为定制化、个性化的东西较多。
从包含模块来看,普遍包含了网上营业厅、CRM、PBOSS、鉴权平台、账务和计费管理以及综合结算功能,并且拥有与客服、网管及相关合作伙伴的接口,可实现业务的运营、分析与管理。
从部署实践来看,虽然BOSS对于业务、管理和服务水平的提升已经达成共识,但整个行业还是存在一些问题,主要包括:
(1)信息化投入比例偏低,影响了企业的持续性发展。
与电信6~8%的投入比例相比,广电网络通常都在3~4%左右,差了一倍多。同时,广电网络在BOSS建设年份投入很大,但是持久性的投入却不足,而BOSS系统更多的工作是在“润物细无声”的状态,需要持续性的投入和维护,如果信息化投入比例分摊到各年处于较低水平的话,将影响BOSS系统对业务支持的持续性演进。
(2)行业盘子太小造成技术迭代能力弱。
目前整个广电行业BOSS市场的规模仅为10亿级,与电信差了一个数量级以上,这还不算广电网络条块分割造成的厂商单用户投入更高的情况。在这种状况下,BOSS企业无论是重视程度还是投入精力均较为有限,行业规划、企业规划、人员派驻等均与电信的差别较大。这意味着基于原有BOSS框架下的迭代更新肯定要打折扣,对运营商新需求的反馈将较为迟缓。
(3)网络公司IT力量薄弱造成主导性不足。
目前,很多网络公司的IT部门要么是组建不久,要么是人员很少,无论是人力还经验均不足以应付越来越复杂的信息化建设要求。这就造成了很多地方BOSS系统建设均由厂商来主导,运营商比较被动。网络公司IT人员的重要性在于结合公司发展战略规划制订出信息化规划,并有效组织厂商力量参与,目前有一些网络公司已经意识到这一点,开始做一些规划和相关的标准规范。
上述问题不是一朝一夕能解决的,电信在BOSS上也付出了血的教训。结合有线电视2 亿多用户的盘子,需要聚合政府、运营商、厂商等多方面的力量一起来推动广电BOSS行业朝好的方向前进,少走弯路。
思考
互联网、移动互联网的快速发展对整个商业社会都提出了新的和挑战。一方面,借助于大数据、云计算等技术,企业与用户的接触更加扁平化、透明化,社会化营销、移动支付、免费+增值等各种模式不断涌现,这是一套完全不同于以往的游戏规则。除了业务层面的竞争之外,广电网络的BOSS及IT支撑也是非常重要的,能够为产品的快速迭代、用户精准分析、营销精准定位带来支持。
另一方面,广电网络的传统电视业务正日益面临着发展的天花板问题,靠用户增长驱动的时代正渐渐远去,广电网络亟需在用户运营层面有所突破,展开精细化运营,而这也不开BOSS系统等IT支撑的支持。
因此,广电网络在BOSS建设方面仍需要继续探索,以应对互联网的挑战,支持企业的进一步转型。
1. 精细化运营要求广电网络围绕BOSS建设下一代IT支撑系统。
以大数据、云计算为代表的新技术的显现让用户行为更加容易被感知,并反过来更好地指导运营企业的产品设计和改进。有线电视用户的消费特征是什么?使用行为是什么?如何指导我们的产品改进?如何完善我们的服务体系?这些都是需要广电网络进一步分析、解决的问题,需要广电网络运用大数据、云计算等技术,在现有传统业务和创新增值业务基础上展开精细化运营,将业务、产品、服务送达用户,获得认可,贯彻“用户体验为王“这一口号。
精细化运营要求广电网络必须抛弃粗放式经营之路,要向管道要收入,向用户要ARPU值。而这些都离不开广电网络IT信息化支撑体系的进一步完善,用信息技术去理解用户、经营用户。
从精细化运营角度对对业务支撑(BSS)、运营支撑(OSS)、管理支撑(MSS)和决策支撑(DSS)各域系统进行规划和设计,引入面向内容、用户层面的大数据分析技术,打造出BOSS系统、精分系统、客服系统、财务系统、网管系统、网格化管理系统等一整套具有广电特色的IT支撑体系,以支持企业应对激烈市场竞争,促进信息资产的保值与增值,将是BOSS系统建设未来的目标。
从上面可以看出,在精细化运营导向下,从BOSS系统出发,广电网络的IT信息化范畴已经大大外扩。
2. 重视BOSS系统整体规划以支持系统持续性演进。
从电信业的发展来看,目前一个普遍性的看法是电信运营商的发展经历了从语音产品到业务服务,再到用户运营的的多个阶段,而不同阶段对于BOSS系统的要求存在很大的差异性。为了避免推倒重来、前期投资浪费的局面,需要运营商对公司整体发展及相关信息化支撑有一个比较明晰的规划。在业务演进过程中,有一个整体性的演进判断,通过对BOSS系统功能模块的重新定义、删减等来实现系统升级。
对于广电网络来说,比电信运营商面临的局面更加复杂。不同地区的运营商发展水平参差不齐,有些地方仍以数字电视为主,有些地方的宽带及增值业务均已大规模上线,而有些地方还在忙着模转数。由于运营商在BOSS层面的需求差异很大,因此BOSS企业很难提供全行业性普适的东西,这就需要运营商对企业未来的发展方向、业务产品等有一个比较清晰的认识,哪个阶段该干什么事,从而在BOSS系统规划中能够短期与长期结合,做到有的放矢。虽然说规划对于保证10 年以上的目标是一个很困难的事情,但是起码得对3~5年有一个比较清晰的规划,5~10年有一个轮廓性规划。
3. 抓好人才队伍建设,形成主导力量。
由于广电网络目前缺乏IT技术人才,难以主导BOSS系统的建设,而厂商绝大部分具有电信行业背景,而广播电视行业的视频业务维度和数据维度均与电信存在很大差别,双方有时候连基本的需求沟通都存在一些困难,这无疑不利于功能完备的BOSS系统建设。
因此,无论是从企业内部培养,还是从企业外部招聘,广电网络需要有计划地抓好既懂传统广播电视技术,又懂IT技术的复合型人才队伍建设,既能够从网络公司大局出发去构建、规划,又能从广电的角度与厂商进行需求、建设、维护沟通,以支撑BOSS及整体IT支撑系统的建设。
在互联网、移动互联网广泛兴起背景下,以大数据、云计算为依托的用户行为分析、用户管理服务等正在走向一个新台阶,这对于正在发展中的广电BOSS提出了新的命题,需要建设一整套完备的IT支撑体系以更好的指导用户运营,在这方面整个行业仍在探索之中。
BOSS广电运营商 篇2
整合广电和电信业务特点
CCBN2012上广电厂商展示的BOSS系统的特点是整合了广电和电信的业务,除了传统的互动业务和VOD业务,还加入了自助服务业务解决方案,支持网上营业厅、短信订购、充值卡系统和呼叫中心系统。据了解,大多数厂商自去年下半年便开始了这项工作,并且已与一些县级广电运营商合作应用。
例如数码视讯的GTBOSS运营支撑系统整合进了基于广电的VOD和基于电信的宽带用户管理等三网融合业务解决方案,以及套餐管理和区域定价管理等基础业务解决方案,同时也支持充值卡和呼叫中心系统等自主服务业务解决方案,是基于“三户模型”的架构。据介绍,此系统已经在上海及浙江的一些省、市、县级地区广电运营商中应用。
借鉴电信标准
广播电视规划院秦所长表示,由于广电之前的业务单一,随着各种增值业务的增多,广电的BOSS系统也在升级。需要借鉴电信运营商的国际BOSS系统标准,但是也要结合广电特殊的业务形式进行整合。
永新视博此次展出的广电综合业务支撑运营系统可以同时定制广电增值业务和IPTV业务,采取多业务的产品套餐和组合营销策略。据了解,目前负责这套BOSS系统的技术总监便拥有电信BOSS系统技术背景,借鉴电信BOSS系统技术经验,负责整合广电和电信业务支撑系统。另一方面,由于广电厂商更了解广电内容的制作流程和播出方式,拥有非常丰富的经验,不能从电信运营商那里照搬解决方案。
广电运营商区别于电信运营商BOSS系统最大的特点是在计费或增值业务支撑上,广电运营商比较注重内容。据永新视博介绍,他们已经做过上千个运营商的BOSS系统,此次展出的广电综合业务支撑运营系统提供融合计费、支持包月、按次、按时长、按流量等计费方式,以适应广电业务的打包计费方式。同时,支持Pro DRM数字电视授权、VOD以及宽带、互动游戏等增值业务的统一接入与统一认证。
资源存在浪费问题
通过采访了解到,目前BOSS系统存在的主要问题是资源浪费。广电厂商在软件和硬件上都进行了升级,可以支持多用户点播的需求,然而目前的用户数尚没有那么多,造成很多资源浪费。
BOSS广电运营商 篇3
昆山广电在完成全市双向网改造后, 在有线电视网络上开展了以数字广播电视 (DVB) 、视频点播 (Vo D) 和宽带接入为中心的三大支柱业务。但是现有各个业务运营系统还是独立运作, 缺乏灵活性, 无法实现高效统一管理。因此, 应建设自己的综合业务运营支撑系统 (BOSS) , 集DVB、Vo D、宽带和模拟业务为一体, 并能扩充支持新兴业务运营, 实现广电多业务用户的统一管理, 迎合市场竞争的多变性, 加大业务的可扩展性, 从而提高企业的竞争力。
2 策略管理功能设计
BOSS系统中的策略管理部分好比是整个系统的“大脑”, 企业所有运营政策的定制都通过策略管理来实现, 因此策略管理是BOSS系统灵活性和开放性最重要的体现。为充分满足BOSS系统对多种运营政策的支持, 昆山广电的BOSS系统策略管理部分采用了以服务管理、产品管理、套餐管理、促销管理和用户自选优惠政策管理为基础的资费管理模型, 如图1所示[1,2]。
2.1 服务管理
服务是面向市场推出的“原子功能项”, 服务管理就是对系统中的服务项进行设定编辑。一个服务项定义的逻辑描述表示为
Service= (Sequence, Name, Type, Character, Provider) 式中:Sequence表示服务编号, 若该服务为数字电视时即为系统和CAS对接的CA编号, 限定此时Sequence∈[1, 65 535], 当服务类型为非DVB业务时, 该项为一个设定的负值以区分和DVB中CA的对接号, 取值范围NO∈[-65 536, 0) ;Name表示服务名称如“考试在线”;Type表示服务类型, 在此Type的可选范围有“数字电视”、“视频点播”和“宽带上网”这3种现有主营业务类型;Provider为内容供应商名称, 如提供“考试在线”节目的“鼎视传媒集团”;Character是节目针对数字电视的特性选项, 包括“节目自选”、“卫视基本频道”、“高清节目”、“特别服务”, 其中“特别服务”是面向集团机构用户的特定节目。
2.2 产品管理
产品即对服务进行定量标价的过程。产品定义的逻辑描述为
产品的定义是根据服务类型的不同而分别定义的。产品的名称 (Name) 、价格 (Price) 、订购时间 (Time) 和退订规则 (Rule) 是服务类型中共同具备的属性。不同的是当服务类型为数字电视时, 参数服务内容 (Content) 对应与服务管理中定义的与CAS对接的数字电视节目, 参数Self Choose表示该节目是否为自选节目;当服务类型为视频点播时, 参数计费类型 (Billing) 涵盖了包年制和包月制这两种计费模式;当服务类型为宽带上网的时候, 参数宽带类 (Band Type) 是对宽带上网速率的设置, 此时的属性项计费类型 (Billing) 包括了包月模式和线性费率两种宽带收费方式, 参数允许上网时间 (Allow Time) 的功能则提供用户对上网时间段的选择, 符合家庭中对学龄儿童上网的监控需求。
2.3 用户自选节目优惠规则
部分高附加值的单一频道销售, 可以进行多买多打折扣的优惠定义, 规则可描述为
式中:Rule表示某项折扣率规则;Number1和Number2分别表示用户定购频道产品数量的最小值和最大值;Agio表示折扣率。在实际的运营过程中, 往往在定购数量不同区间采取不同的折扣率以鼓励用户更多的消费, 而这时整个BOSS系统的优惠规则即为多个订购节目数量区间段中各优惠规则的一个并集, 其形式描述为
2.4 套餐和促销管理
套餐的制定是将不同产品打包进行组合捆绑的过程。套餐定义的逻辑描述为
式中:Name表示套餐名称;Price是套餐价格;Time是套餐购买时间;Accessory表示了一些附属选项如一次性优惠收费项目和赠送资源等;Rule表示套餐的退定规则;Product是产品管理中定义的产品项, 一个Package可将多个Product捆绑成一个集合项后变成自身定义的一部分。Product可指向的产品类型包括“数字电视”、“视频点播”和“宽带上网”, 这样系统可以实现不同业务类型产品之间的组合捆绑。
促销在定义形式上与套餐相同, 但是在使用的过程中则不同。例如准备在国庆假日推出促销活动, 用户购买产品CHC电影频道一个月将赠送动感音乐频道一个月。而这种活动只能在国庆假日才有, 当用户过了国庆假日来购买同样的CHC电影频道, 花同样的钱则无任何赠送产品。套餐有其相对的固定性, 在制定套餐后, 只要这个套餐在BOSS系统中有效, 用户任何时候来购买这个套餐对应的价格和享受的产品服务是不会改变的。
套餐和促销是直接面向用户的主要销售模式, 其属性参数基本相同, 因此设定流程也类似, 如图2所示。设定成功保存后套餐或促销就在系统中生效。
3 部署中的问题及解决
BOSS系统建设在进入实际部署阶段, 应该重点考虑以下问题[3]:
第一, BOSS系统同外部系统的接口对接, 包括了和数字电视认证系统、Vo D认证系统、宽带接入系统和银行划账系统等的数据对接, 以实现BOSS直接对终端用户设备进行授权和接入控制, 实现业务的综合管理。
第二, BOSS系统将全面取代原有的模拟电视和数字电视的用户管理系统SMS, 因此其数据库中将导入原有系统的历史记录。这部分的工作重点是导入前应对原系统的有效数据进行分析, 导入过程确保现有系统的稳定运行以及导入数据之后BOSS系统的稳定运行, 确保系统间平滑切换。
第三, 建立在系统试运营阶段的及时响应、修改更新机制。BOSS系统在投入生产的初期, 必然会出现因系统在设计过程需求分析不全面而导致的功能性欠缺或业务操作流程上不适, 这就需要运营商和开发商建立一种有效的响应机制, 如图3所示。开发商根据系统建设初期制定的需求分析进行初步开发, 完成之后进入系统的部署试运营阶段。在试运营阶段运营商需要及时总结BOSS系统在投产后暴露出来的功能设计上的不足, 同时对企业自身各项操作流程进行详细的调整以尽量配合BOSS系统的部署。开发商根据BOSS系统出现的各种问题对系统进行修改优化, 如此往复至系统稳定运行。
4 小结
昆山广电BOSS系统对原宽带系统、数字电视用户管理系统及视频点播业务系统进行整合, 在策略管理部分实现了对上述各业务的统一管理, 各产品可根据需求组合后捆绑打包, 形成面向市场的各种套餐及促销活动。通过策略的制定和运作, 能够使企业实现高效的管理, 快速积极地迎合市场需求, 灵活部署, 提高企业的市场竞争力, 真正实现以客户为中心, 从而为用户提供富有特色的个性化服务。
参考文献
[1]王斌.广州市广电网络BOSS系统的建设历程及发展展望[J].电视技术, 2005 (8) :7-9.
[2]王斌.论建设和实施广电网络BOSS系统的几个关键技术[J].电视技术, 2005 (4) :4-6.
BOSS广电运营商 篇4
一、BOSS系统的总体设计
1. 设计的基本原则。
在设计广电BOSS系统时, 依据广电的基本业务构架, BOSS系统的整体设计可才遵循“一个中心、三层结构”的基本原则, 其中所谓一个中心是指在设计过程中将计收费处理、结算处理、营业受理、信息统计、业务管理以及账务管理等各种数据资源进行合理的统一规划, 进而使得BOSS系统逐渐形成一个综合化、统一化、信息共享化以及模板化的支撑系统;“三层结构”是在设计和构建系统时, 其逻辑结构应遵循相应的三层标准, 即接入层、业务逻辑层、数据核心层。
2. 系统逻辑结构。
BOSS系统的内部构架中, 开放性的接入层、灵活性的业务逻辑层以及信息数据相对集中的数据核心层等三层结构共同构成了系统的逻辑结构, 其中结构中的数据核心层又可以分为服务子层、数据子层, 而且两个层次之间实现了其功能模块的互联调用, 此外, 各个层次的内部也使用其各自的功能模块结构。
(1) 数据核心层。在整个BOSS系统中, 数据核心层是其基础, 它的主要任务是将客户的档案、相关账务以及业务等信息资料数据进行集中统一存储, 同时将包含个人用户资料、使用记录以及服务记录在内的全部信息数据集中统一起来, 形成一体化的“统一的数据中心”, 但是在这个环节中, 所需数据的输入和输出都是通过其中的服务子层来完成的, 该层通过操作和访问相应的数据子层, 以实现以相同的接口方式, 为业务逻辑层提供其所需的基本数据以及相应的功能服务。
(2) 业务逻辑层。业务逻辑层是支撑整个系统正常运行的逻辑平台, 它通过对系统内部的相关原子服务进行重新组合来实现对数据核心层的各种信息数据进行相应的操作, 并使得各种应用功能模块逐渐适用不同的业务的业务需求, 此外, 它可以依据其功能划分成为多个业务模块, 比如受理业务模块、计收费处理模块、账务管理模块等。而且系统中的具体业务模块是通过调用其内部的相关原子服务功能来实现, 如果日后运营商推出其他新业务时, 只需要在原系统的基础之上增加相对应的业务模块以及相关的调度规则以及业务逻辑即可。
(3) 接入层。在BOSS系统中, 接入层是其客户界面, 也是运营支撑系统实现与外部相关数据进行交换的平台, 而且它包含了客户同系统进行相互交互的各种手段, 在这个环节中, 是准许客户使用各种多样、灵活的接入方法与业务逻辑层相关联的, 而且为了更好地实现服务的多样式, 满足客户的个性化、多样化以及跨区服务的要求, 客户可以直接通过相应的营业厅、电话等多种不同的方式连接到BOSS系统, 此外, 为了更好地将客户统一接入的概念体现出来, 在构建系统时可以使用Potalr技术来实现多种接入方式的统一连接接入。
一个中心、三层结构的基本建设原则, 在一定程度上确保了系统中存储数据的唯一性以及统一性, 而且也为客户提供了较为规范、完整的服务, 杜绝了只有一个客户却有多个账单产生的情况。此外, 系统内部的三个层次, 它们每个层次都需要完成不同的功能, 并依据系统内部逻辑上的不同组合来, 满足系统运行过程中所需的业务功能, 并在一定程度上提升了系统的灵活性以及可扩展性, 同时也符合运营商相关业务变化和发展的需求。
二、BOSS系统的维护开发方案
BOSS系统在设计、研究、开发完成之后, 伴随着业务量以及业务板块和经营模式的不断变化和调整, 因此广电网络的BOSS系统还需要不断升级和改革, 所以这就要为我们依此制定一套科学、完整的维护方案。
1. BOSS系统的版本管理。
对研究开发中的应用型业务系统软件, 其版本管理的任务主要是通过频繁的软件测试、修改以及相应的版本更新等, 对于已经开发完成的应用型系统软件, 其版块管理的任务主要是对软件进行升级、并更新软件功能以及设立相应的文档资料等。其中版本管理的基本要素有:软件的名称、版本号、使用时间、检测时间以及源代码本号等。
2. 对系统中技术资料进行相应的归档处理。
在业务系统软件投入使用之后, 要进行相应的归档处理, 各个版本之间的安装程序、信息参数、源代码以及软件文档等都需要进行分类处理, 并配分统一的归档编号, 认真保存, 此外还应依据实际情况填写相应的软件安装记录表。
对软件进行修改和调整时, 应有与其相对应的文档说明, 说明内容包含新版本与旧版本之间的功能差异以及相应的修改方案, 此外在修改源代码时, 需标注修改的人员以及日期。而对于业务系统内部的配置参数以及源代码要进行加密处理, 未经批准, 不得擅自借阅或复制。
3. 制定科学、合理的应用软件维护作业计划。
对BOSS系统制定相应的软件维护作业计划实际上就是对系统进行主动维护, 提高系统的使用性能并尽可能的降低系统故障发生率的有效手段。
在通过统计业务系统进行相应的业务数据统计分析时, 查询和找出系统在处理某些数据时遇到的瓶颈, 针对出现的瓶颈, 制定一个科学、合理的维护作业计划, 主要通过平衡负载或者增加资源等有效措施。
在通过分析业务系统在对相关业务数据进行分析整理时, 应与开发商一起查询和找出业务系统在运行过程中存在的问题, 并依此制定一个科学、合理的维护作业计划, 以提高软件系统的整体质量。
在实施维护作业计划前后, 都需据实填写维护作业登记表, 并将维护作业过程中相关的文档资料连通维护作业登记表一起合并保存并进行归档处理。
4. 设计、编码以及测试修改和测试。
BOSS系统应确保在非生产的环境中进行, 而且需要对BOSS系统的非生产环境以及生产环境进行严格区分。完成维护工作之后, 填写相应的维护记录, 维护记录填写的内容包括:程序名称, 源代码的行数;编写代码时所使用的设计语言;完成程序编写的日期;程序开发投入使用以后发生故障的次数等内容。
总结
随着社会的进步以及科学技术的不断发展, 广电网络BOSS系统的建设与维护已经受到越来越多的网络公司重视。这就要求我们要依据构建系统的基本原则切实做好系统的建设以及维护工作。
参考文献
[1]新一代移动BOSS解决方案[N].人民邮电, 2009-08-22.
BOSS广电运营商 篇5
随着三网融合的发展，广电市场的竞争在不断激化，如何在现有数字平台上开展各项增值业务，成为了各广电运营商面前的头等问题。苏州有线经过深入考察比较，引入了数字电视多媒体视讯系统（Media Information System，以下简称MIS）。该产品主要功能是将多媒体信息内容（包括图文、音视频等内容）在指定频道、指定时段播出并可实时更新，通过数字机顶盒集成软件模块实现多媒体信息内容接收显示。通过该系统，数字电视用户能享受到更丰富实用的资讯信息，对数字电视将有全新的体验。但是其中的定点投放功能需要获得BOSS中的相关信息，因而，需要在BOSS和MIS之间建立一个接口，实现两者之间的通讯。笔者在项目实践中通过研究，从基于Socket的设计出发，提出了解决这一问题的一种思路和实现方案。
2 Socket概述
Socket也叫做套接字，是建立在传输层协议上的一种跨平台的应用程序进程之间通信规范。如图1所示，用一个抽象的“通道”来形容，它的两端就是两个Socket。Socket对于进程来说屏蔽了底层的通信软件以及各种操作系统之间的差异，它为进程提供的通讯接口使得进程在网络上的数据传输以及数据接收得以实现。对某个网络连接来说，Socket不会因为在服务器端还是在客户端而产生不同的级别，它是平等无差别的。
协议、远程IP地址、远程端口、本地IP地址、本地端口这个五个元素可以用来表征Socket。对于应用程序的进程来说，只要有协议、远程IP地址、远程端口即可以像使用文件句柄一样，直接对Socket进行读、写操作，以达到与远端进程进行通信的目的。
3 BOSS与MIS系统接口的设计与实现
3.1 业务需求
BOSS系统涉及业务办理、授权、客户服务、计费运营维护等，通常要求7×24小时运行，其数据的准确性及稳定的运行非常关键，若发生重大故障将会给运营商带来严重的社会压力及信誉损失，并且BOSS中所涉及的各种数据信息，牵涉到客户隐私和商业机密问题，不可能让MIS系统厂家直接对BOSS数据库进行操作。
鉴于以上原因，有必要在BOSS与MIS之间建立一个接口系统来实现两者之间的数据传递问题。
3.2 设计的基本思想
接口系统的结构如图2所示。
本接口系统通过Socket和如家MIS进行通信，它是整个系统的核心，是BOSS和MIS之间数据交换的接口。接口系统包括接口数据库、Web管理系统和Windows服务三部分。
(1）接口数据库
接口数据库起到了一个中转的作用，它存储了所要进行定点投放的信息，如投放时间、投放目标、投放信息等。
(2) Web管理系统
Web管理系统的作用是对定点投放的信息进行管理。它采用直接读取BOSS数据库的方式获得相应的BOSS信息，如机顶盒号码、智能卡号、小区信息、广电站信息等。然后可以对指定的单个机顶盒或某个小区涉及的用户进行信息的定点投放。
(3) Windows服务
这是整个系统的核心，担负着对定点投放信息的监视、读取以及与MIS系统之间的通信。它将接口数据库中的定点投放信息按照与MIS之间约定的封装规范进行封装，封装完毕后将消息发往MIS系统，并对MIS系统的返回信息进行解析。
3.3 接口数据库的实现
在这个项目中，针对系统功能的要求，笔者设计了如表1所示的数据库表结构，数据库平台使用的是Oracle 9i。
发送标识有以下几种分类：0代表信息未发送，1代表信息已经发送成功，2代表信息发送失败。默认情况下为0。
3.4 Web管理系统的实现
Web管理系统界面如图3所示，主要实现以下两类功能：
(1）单个定点信息投放
即允许操作员通过输入机顶盒号码、智能卡或客户证号等信息，对单个用户进行定点信息的投放，本系统中对应的功能模块是单卡发信息。
(2）批量定点信息投放
即允许操作员对某个小区、某个街道或者某个广电站下面的所有用户进行批量定点信息的投放，本系统中所对应的功能模块是小区发信息、街道发信息和单位发信息。
Web管理系统的一个关键技术是对Oracle数据库的读写。在Web管理系统的模块中，多次用到了对数据库的操作。为了增强系统的清晰度和简洁性，减少代码的重复性，提高系统开发的工作效率，笔者编写了一个DBOperation类，其结构如图4所示，专门用于与数据库的交互。
3.5 Windows服务的实现
Windows服务是在Windows操作系统下，运行于后台的一种可长时间运行的可执行应用程序。它们中的一些服务是随系统启动而自动的启动，也有些服务必须在用户的手工启动下才可以运行。对于那些自动启动的服务，它们的启动是随着Windows的启动或者重启之后用户登陆以前就开始执行，随着Windows的关闭而停止运行。用户可以通过选择控制面板—>管理工具—>服务来查看管理系统中的Windows服务，如图5所示。其中选中的服务MisService就是本接口系统对应的Windows服务。
作为整个接口系统的核心，Windows服务的关键技术涉及到Windows服务本身的实现以及与MIS之间的Socket通信。下面就这两个关键技术进行描述。
(1) Windows服务
本Windows服务采用.NET平台进行创建。在.NET平台中，把复杂的操作封装在.NET类中，简化了Windows服务的创建和控制过程。本接口系统的Windows服务的类结构如图6所示。
本服务添加了一个名称为timer1的System.Timers.Timer组件作为实践触发器，用于定时对接口数据库中的数据进行访问，查询是否有需要定点投放的信息。在OnStart方法中对timer1的属性进行设置，其中Interval表示触发频率，单位为毫秒，Enabled表示是否启用计时器，以定义的Interval的时间间隔激发事件timer1＿Elapsed。另外在OnStart方法中还对配置信息进行读取，获得对应的主机（host）和端口（port）信息，用于Socket连接。OnStop方法中设置了timer1的Enabled为false，表示停止计时器的运行。其中，对数据库的检查以及与MIS之间的通信放在了Check () 函数中。
为了增强服务的可移植性，减少代码的改动，本Windows服务还自定义了配置文件，用来管理服务的设置，配置文件采用XML形式，结构如下：
其中Host代表MIS所在的服务器的IP地址，Port代表MIS系统接收Socket信息的端口，Time Interval用于设置timer1时间间隔，DataSource存储着与接口数据库的连接字符串，LogPath表示本Windows的日志存放路径，本例表示日志文件存在C盘下的log文件夹里。每次更改配置文件后，需要重新启动服务才能生效。
.NET为服务的安装提供了Install Util.exe工具。选择Visual Studio Tools—>Visual Studio命令提示，会显示一个命令窗口，在此命令窗口中通过执行Install Util命令来进行安装或卸载Windows服务。
安装命令为：Install Util.exe服务名。
卸载命令为：Install Util.exe/u服务名。
(2) Socket通信
本接口系统中Socket通信涉及到发往MIS的Socket信息的封装、MIS返回信息的解析以及Socket本身的发送。所对应的结构如图7所示。
类ByteBuffer主要用于创建一个可变长的Byte数组，以方便Push数据和Pop数据；类Common是公用方法的集合；类Mis Interface主要用于对Socket信息的封装以及Socket信息的发送；类MisData主要是对Socket封装过程中的一些功能进行函数封装，以供MisInterface调用；类Write Log包含与日志相关的一些方法。
4 结束语
本接口系统在BOSS与MIS对接方面创全国广电先例，它在苏州广电的应用是成功的，在实践中已经得到了检验。接口系统把广电BOSS和MIS有机的联系在一起，实现了无缝连接。降低了由于建设MIS而对BOSS产生的风险，有效的保障了BOSS数据库的安全性。接口系统是建设MIS的基础，同时也是BOSS与MIS之间数据交互的纽带。
摘要：BOSS作为广电的核心生产系统, 如何实现与MIS进行数据交换显得至关重要。本文对两个系统进行深入的研究, 从基于Socket的设计出发, 提出了一个合理可行的接口应用方案。
关键词：Socket,BOSS,MIS,Windows,服务
参考文献
[1]朱三元等.网络通信软件设计指南.北京:清华大学出版社, 1995, 53-72.
[2]叶德谦, 马勤勇.使用ADO.NET实现对关系数据库的访问[J].电脑编程技巧与维护, 2002, (01) .
[3]杨静, 梁浩峰, 高鑫.用socket实现服务器/客户机的数据交换[J].甘肃科技, 2002, (7) .
[4]TCP/IP网络互联技术 (卷3) :客户-服务器编程与应用[M].Douglas Comer, David L Stevens.清华大学出版社, 2004年10月.
BOSS广电运营商 篇6
关键词：BOSS广电业务,数字化整转,Oracle特性,容灾,备份,高可用
1 架构简介
目前BOSS系统生产中心有小型机2台, 配有磁盘阵列。容灾中心有容灾服务器1台, 配有磁盘阵列。系统的数据容灾通过Oracle Data Guard来实现。逻辑拓扑如图1所示。
如果考虑数据库Rman备份存储空间、数据库归档日志存储空间 (根据业务量不同可以考虑数据文件大小的三分之二左右) 、逻辑备份存储空间等因素, 面临数字化整转的广电企业有必要充分考虑并合理规划存储空间。下文也会讲解因前期考虑不到位而空间不足时的可选措施, 但这些措施以消耗CPU资源为代价的。
2 广电业务特色与Oracle特性
为了更好地提高性能, 除了很好地理解Oracle外, 理解广电业务及其数据是很有必要的, 如下通过具体案例来介绍几个重点因素。
2.1 日常业务与报表的分离
从生产系统运维的实际经验来看, 威胁系统稳定性的最大因素是在业务时间进行大量报表查询。具体体现在月底出账后的月统计报表、每周扎帐、业务相关部门节假日后进行的大并发报表查询等。随着数字化整转的顺利开展, 在BOSS系统中将会出现大量的用户数据及业务数据, 业务部门为了及时地了解数据的动态变化需要大量的客户及业务统计汇总数据。而此类数据提取方式会做成报表或者后台编写SQL直接提取等方式来处理, 一般广电BOSS的系统, 承担着多个分公司及外拓单位客户及业务资料, 因此很难避免这些单位同时查询统计数据。有效的解决的思路就是将报表系统和OLTP系统从业务和数据库层面进行分离。因业务层的分离涉及到程序的改动, 一般可以采取数据库层面的分离。
在数据量并不是很大的情况下 (也适用于单实例环境) , 也可以采取通过DB link方式 (或impdp/expdp的network_link方式) , 每晚将常用报表相关数据同步至报表库, 将报表查询Web应用与业务受理Web应用完全分离并直接读取报表库的方式也是值得尝试, 具体结构如图2所示。
如果业务层面也能实现直接读取报表库, 则完全可以避免报表查询对生产数据库服务器的压力 (尤其对内存结构的压力) 。
如果数据库不是很大, 也可以从采用生产库导出后传送到报表服务器并导入到报表库的同步方式, 这样对生产库几乎不会产生什么性能影响。
数据同步另一个理想方案是采用Oracle Data Guard的逻辑灾备 (Logical standby) 模式, 不过此模式对要求DBA具备一定的专业职能, 要求企业具备一定的硬件环境。
2.2 对关键业务采取针对性优化措施来排除性能瓶颈
平时可以通过针对业务部门进行调研、对其需求进行总结分析等措施来排除系统瓶颈。如下关于所谓的“BOSS系统慢”的几个常见问题:
(1) 营销计划变更时, 查询界面等待时间较长。
(2) 新装用户时, 查询标准地址等待时间较长。
(3) 资源查询、资源调配, 查询速度较慢。
(4) 营业厅下午做资源扎帐时, 等待时间较长, 做受理扎帐, 无数据显示。
(5) 下午6:30分, 报表权限打开后, 查询某某报表速度较慢。
实际上这几个问题就是天天困扰每个业务人员的问题, 针对这些问题提取相关SQL后进行针对性的分析和SQL优化后, 对于业务部门来说性能有了很大的提升。简要的分析结果如下:
问题1通过SQL优化得到了很大的改善。
问题2是项目初期因为数字化整转业务中安装地址不好找而实现的地址查询 (完全模糊) 功能模块, 如果针对此问题单纯从数据库层面考虑则优化的效果并不明显, 因此个人觉得有必要在程序层面改进查询方式更为有效。经询问业务部门, 改进后的查询方式 (半模糊) 也能满足他们现有的需求。
问题3的整个过程涉及到十几个表及DML操作, 而其中有些表既然已经接近几个亿的数据行数, 因此不仅对SQL语句进行优化, 而且对相关数据表进行了重构, 同时对过期数据进行了清理归档等。
问题4和5分析后发现不仅报表SQL需要优化, 而且相关业务核对流程也有待提高。因此独立建立报表库 (图2) 的同时对业务流程也进行了相应的调整。
2.3 TOP SQL的优化
随着数据量不断增长, 业务相关数据查询也开始呈现出低效。比如原有CA授权日志表、产品订购表、账本及账单详单表、业务受理记录表等, 在短短的一年中, 从百万行增加到千万行甚至几个亿行记录。如果没有对此采取相关措施, 服务器硬件配置总是显得不够, 需要扩容。
如图3所示, CPU占用率分布中16点左右发生CPU高消耗的来源实际上也是一个根据地址查询大量数据的SQL语句导致的。在SQL优化中希望记住的一点是SQL的优化离不开索引的优化, 但是索引的优化并不等同于SQL语句中where条件的字段上增加索引。很有必要根据数据访问路径和查询条件的特点, 创建战略性的组合索引。
2.4 合理规划及部署后台作业
通过如下查询语句, 我们很容易看到数据库存在的后台作业:
select*from dba_jobs job where job.BROKEN=’N’
BOSS系统涉及到综合业务、多种接口, 承担着很多任务, 因此相应的每天必须执行日帐、接口同步、托收、欠费催缴、OSD/MAIL发送、各类统计报表等很多任务。明确每个作业用途及执行时长, 合理安排其执行时间也是很有必要。曾经在Oracle的警告日志文件的夜晚时段经常出现checkpoint not complete提示, 合理调整完相关作业执行时间后出现的频率有了很大的改善。
2.5 充分利用Oracle新特性, 将常用参考表放到keep pool
BOSS系统虽然很庞大, 但是其中有些常用的小表, 例如产品、组织结构、营销计划、各类Enum (代表类别的元数据) 等。如果采用数据库为Oracle10g或以上版本的话, 我们可以将这类表的Default Pool属性设为Keep pool, 这样可以避免这类常用表的“过时”而引起不必要I/O的同时, 减少SQL解析量, 进一步提高系统性能。
2.6 Cursor相关初始化参数的调整
如果系统上SQL没有足够的共享则会出现大量不必要的解析调用, 这些解析会占用大量的CPU资源, 从而严重地影响系统的性能。解决问题的最佳方法还是应该在程序中使用绑定变量, 但是这又涉及程序的修改。如果无法通过修改程序使用绑定变量来解决这个问题, 那么修改CURSOR_SHARING应该是解决这个性能瓶颈的简单且行之有效的方法。
2.7 合理规划及安排备份策略
随着数据的不断增量, 系统备份所需要时间也会逐渐增长, 当数据库增加到500G以上时, 再不重视合理规划及安排备份策略, 这些因素将会成为系统性能问题。
BOSS数据是公司核心数据, 因此一般对此类重要的数据, 数据库将会运行在归档日志模式外, 还要实现Rman备份 (出于性能可以采用Rman增量备份) 、逻辑备份等。在实际应用中如下几点需要注意。
(1) 给数据库分配足够的备份空间
在数字化整转时期数据库的增长是非常快, 因此在存储的规划过程中要充分考虑相关因素。同时BOSS系统数据库是公司的核心数据, 因此数据库肯定会在归档模式下运行, 也需要足够归档日志 (Archived log) 空间, 否则系统会因归档日志空间满的原因导致经常挂起。这些因素从侧面反映BOSS系统稳定性和可靠性。
(2) 逻辑备份时段及出账时期的合理安排
一般除了Rman备份外, 附加采用逻辑备份来进一步保证数据的可恢复性。当数据库变得越来越庞大时, 每个月初的出账计算及销账等过程中, 如果没有合理安排数据库逻辑备份与出账时间关系, 将直接影响出账过程和效率。在特殊时期做一些特殊方法来避免系统资源竞争是很有必要的。
(3) 充分发挥Oracle备份恢复新特性
Oracle数据库备份还是离不开Rman备份。例如, 当初我们BOSS系统备份因空间不足, 而导致没法正常备份时, Rman压缩备份使得我们避免重复的硬件投资, 很轻易地度过难关。
3 突破局限、整体分析, 充分利用现有资源
从图3 CPU占用率分布中可以看出来, CUP占用率较高的时间段主要分布在两个时间段段, 即21:30至23:20和6:30至9:00。接下来将介绍怎样结合整体架构和业务特性避免高负载时间段的重现, 从而进一步提高BOSS系统的稳定性。
3.1 生产中心与灾备中心之间备份的分离
在数据库服务器上通过执行Crontab–l可以看到从6:00开始的数据库Rman增量备份。
从Oracle 10G的特性可以知道, 在Data Guard的Physical Standby环境下, Rman能够从Physical Standby上创建生产库的备份, 但此时Rman要求要具备Catalog database。如果按照该思路, 可以将生产库上的Rman备份迁移到灾备库, 则6:00至9:00的CPU高负载可以避免。当然, 如果灾备中心和生产中心之间网络带宽为100M并备份大小超过200G, 则不推荐采用此方法。因为一旦需要恢复, 则两点之间数据库备份数据的传输就会占用客观的时间。
另外, 仔细观察rman备份脚本也可以发现 (backup incremental level=0 as compressed backupset database) , 脚本中含compressed选项, 该选项是以CPU负载为代价而节省磁盘空间, 如果磁盘空间足够, 也可以取消compressed选项, 在我们的实际案例中取消后的CPU占用率分布如图4所示。
针对4:00开始的逻辑备份, 将其迁移至灾备中心也很容易实现。实现方式是先将容灾库状态改为只读方式 (open read only) , 打开后导出数据, 导出后将数据库状态改回mount状态后, 恢复Dataguard的日志应用模式即可。而这些处理过程可以通过脚本语句来实现, 不必天天人工参与。
3.2 日账、月账相关存储过程 (或包) 的调优
每日账务的批量处理过程分布在如图3 CPU占用率分布中的21:30至23:30时间段, 而这一时间段也是呼叫中心调用BOSS系统的高峰期。
将呼叫中心调用BOSS高峰期和日帐批处理时间段相互分开也是解决问题有效措施之一。这样可以避免在批处理过程中对Undo表空间的争用, 同时对CPU占用率的降低也有一定的贡献。
通过对账务相关存储过程的SQL进行优化也可以降低CPU占用率。对于存储过程的优化, DBMS_PROFIL-ER软件包可以帮助用户测试PL/SQL的性能。除此之外, 个人还是建议在对出账的整体过程有了一定认识的基础上, 再参考DBMS_PROFILER等工具, 进行全面的调整, 这样可以取消一些不必要的环节或有利于减少不必要的逻辑和物理读。
从Oracle Database 10g开始, Oracle在建库后就默认创建了一个名为GATHER_STATS_JOB的定时任务, 用于自动收集CBO的统计信息。缺省情况下, 这个job是从周一至周五的晚上22点开始执行, 运行8小时到次日凌晨6点;周末则是从周六凌晨0点开始执行两天。
通常情况下, 晚上22点及周末全天是用户使用的高峰期 (账务处理、呼叫中心调用、催缴) , 所以在此期间如果系统资源出现紧张, 需要将job运行的时间调整为跟业务高峰避开的时间段。
随着时间和业务的扩展, 在广电BOSS中将会两类数据变得越来越庞大, 其一是认证接口类, 其二是工单类。从实际经验来看, 曾经出现过部分表大小超过12G (未分区) 的情况, 这类数据不仅对性能, 而且针对备份恢复时间、CPU、系统I/O等产生负面影响。因此有必要建立相应的数据归档及清理机制。针对那些特殊大表, 根据相关表的表间关系, 可采取如下简便的处理方法:
(1) 清理之前, 对所要清理的表做一个逻辑备份, 以便今后查询。
(2) 根据归档计划周期 (时间点) , 查找满足条件的主键值。
(3) 导出满足条件的数据。
(4) 导入前清空已备份过的表。
(5) 重新导入。
对以上过程的几点说明:如果表中索引较多或表很大, 可以考虑先删除表上的索引后进行导入, 等导入完毕重建索引等方式, 这样可以减少导入时间。
4 展望高可靠高可用 (RAC+DG) 系统架构
如果将图1逻辑拓扑图中两个小型机之间“HA”改成“RAC”, 则可以搭建Data Gurad加RAC的Oracle所称为MAA架构 (Maximum Available Architecture) 。在这种架构中, 选择比较高效的存储方案是值得投入的, 因为在后期扩容中, 节点很容易增加, 但是存储的调整及升级不仅涉及到较大改动 (可能需要数据迁移) 。在节点数增加和性能的线性提升之间起到关键作用。
随着RAC Cache Fusion功能不断改进, 对各类应用程序的要求越来越降低, 但是根据BOSS系统表结构和业务特性进行长远考虑, 如下几点还是值得关注的:
(1) 在系统初始化初期, 应该对客户、账户、用户、受理记录等基表的常用查询关键字段 (客户编号、账户编号、用户编号、受理编号) 进行附加区域编码的编码方案。这样在未来3至5年生成的海量数据中, 通过根据这些关键字段对这些表进行分区等措施很容易减少不同节点之间Global Cache等待和Enqueue等待事件。也能保证节点数量和性能提升之间的线性增长。
(2) 用户资源、产品订购一类的表有必要在表结构和应用程序方面做些二次开发。这类表不但变更率较高 (建表时需要调整pct free参数) , 而且在单实例环境下锁相关等待事件 (LocksRelated Wait Events:Buffer Busy Waits、Latch Free等) 较严重的表。
(3) 在RAC中, 多个节点可以同时访问数据库, 因此针对BOSS系统的不同子模块建立不同服务 (services) 的方式分别部署到不同的节点, 也是提升系统稳定性和性能的有效措施。如再结合Oracle 10g的基于服务 (services) 的资源管理 (Resource Manager) 功能, 则完全能够避免关键业务和非关键业务之间的资源耗用冲突的现象。以报表模块为例, RAC和BOSS业务特性讲, 可以将报表子模块和OLTP业务的分离按不同服务分解到不同节点。
(4) 对于较繁忙的环境来说, 触发remastering事件的默认参数值通常过低, 因此导致了频繁的对象remastering。建议设置_gc_affinity_limit和_gc_affinity_minimum参数到一个较高值, 比如说1千万。将参数_gc_affinity_time设置为0也可以完全禁用DRM, 但是这也意味着再也无法手工remaster对象了 (这些是隐含参数, 在修改这些参数之前确认Oracle Support同意你的举动) 。
5 Oracle数据库性能调优重点公共部分
Oracle数据库性能优化的重点部分无非是实例 (SGA、PGA、Share Pool、redo bufer) 和数据库 (日志文件、临时文件、回滚段) 等大小的合理配置。在Oracle 10g中也推出了一系列顾问属性的动态视图, 这些视图有助于实例参数的正确调整。另外, 还需关注Oracle不同文件存储位置的合理部署来降低系统I/O。
6 存储的合理规划及分配
(1) 数据文件和归档日志文件与备份文件硬盘分离
对于数据库安全及性能, 数据文件与归档日志文件需要与备份文件硬盘分离。从安全性方面讲, 避免存储数据文件硬盘出现问题。从性能方面讲数据文件和归档日志文件的分离可以避免磁盘争用, 有效降低了log file parallel write的等待时间。
(2) 数据文件和索引的分离
数据和索引分别独立存储的数据存储结构具有非常重要的意义。表和索引相互分离、各自作为不同的对象存储是关系型数据库中最常见的数据存储方式。同样, 作为这些对象集合的数据文件和索引文件的分离在数据库性能的提升方面具有相当重要的作用。
7 总结
BOSS广电运营商 篇7
3月23日、24日, 本刊记者在与几位广电行业BOSS系统提供商进行沟通和交流后发现, 虽然代表不同的软件企业, 但他们对当前的广电系统有一个共同的认知, 即“目前广电BOSS系统的技术架构参照了电信行业的管理运营支撑系统的先进经验, 但在业务流程、业务模式, 具有广电行业的自身特色”。
在BOSS系统的初期阶段SMS时代, 广电运营商几乎对运营支撑系统没有经济上的投入, 通常被作为一种免费服务项目使用在广电网数字化和双向化的改造中。目前, 广电运营商对运营支撑系统的使用仍不普遍, 短期内无法刺激用户需求, 但随着向综合业务服务的转型, 广电运营商大规模使用BOSS系统的时间拐点将在几年后到来。
认知度初步提高
2009年CCBN期间, 本刊记者曾对广电行业的BOSS系统进行过了解, 当时业内人士表示, 广电行业的运营支撑系统基础薄弱, 各地运营商对BOSS的认识, 仅限于普遍使用的SMS系统管理软件。
在CCBN2010上, 通过对多家软件提供商的走访, 记者了解到, 在2009年到2010年间, 基于在电信行业所获得的成熟的软件系统经验, 软件提供商将完善的模块化管理经验和可视化、一体化的理念引入了广电行业BOSS系统中。同时, 广电行业对BOSS系统的认识和了解进一步增加。
业务设计具行业特色
由于广电行业所具有的特殊性, 导致广电BOSS的建设启动较晚, 因此, 广电运营商采取电信行业BOSS相关标准和规范成为必然, 但广电与电信行业之间的差异性, 导致广电的BOSS系统设计具有其行业特殊性。
深圳市迪威特数字视讯技术有限公司的董书海、王书庆两位副总经理告诉记者, 电信的BOSS系统经历过以产品为中心向以客户为中心的转变, 这种转变对广电颇具借鉴意义。因此, 虽然广电BOSS系统的研究起步晚, 但站在巨人的肩膀上, 属于高起点的建设。本次展会, 他们即推出了以NGB为主题的BOSS系统, 采用了以客户为中心的设计, 并以零入门的护航计划, 来争取运营商的认可。该系统与电信系统的不同之处, 体现在用户数据管理和账户模式的业务模型设计上。
“规划与需求双向驱动”。董书海认为, 针对广电运营商的抽象总体需求, BOSS的前瞻性规范要符合未来统一网络的全业务运营需求。
华为展台专门展示了为广电运营商提供的BOSS整体解决方案, 据现场的工作人员周义华介绍说, 总体来看, 广电BOSS系统脱胎于电信行业的成熟经验, 但与电信BOSS系统有所区别。
从中兴通讯展台上的展板看, 中兴通讯已经将BOSS系统完全集成在CMMB系统管理的整体解决方案中, 并未单独展示运营支撑系统的架构。而天柏的综合业务运营支撑系统, 已能支持模拟与数字等多种融合的计费需求, 能够满足多种业务集成的需要。
综观多家对BOSS系统进行展示的解决方案, 电信行业中所具有的灵活的模块化设计、融合的多种计费方式、统一的可视化管理视图等特色, 都已经在广电BOSS系统中有所体现。正如王书庆所言, 软件提供商们通过对运营商需求的深入了解, 提供量身定制的业务模型设计, 才是开拓广电行业市场的关键。
以永新视博为例, 该企业去年展会期间即推出了BOSS系统, 全面支持有线网、无线网、卫星网的业务运营, 至今未有一项具体的落地项目, 其用户集中在2003年推出的Miracle SMS运营管理支撑软件平台上, 有60多家数字电视平台仍在使用SMS软件平台。究其原因, 该公司展台工作人员认为, 在过去的一年中, 老客户在上马新业务之前对运营管理系统的需求尚不明显, 但随着三网融合的进程, 行业转型将促进对BOSS系统的需求。
天柏今年展出了新的综合业务运营支撑 (DVN-BOSS) 系统, 据该展台的工作人员吴丹丹介绍, 在展会的第一天, 参观者多为其老客户, 他们希望通过了解新版本的情况, 为将来的系统升级做打算。
而诚毅软件的大区经理梅杨则认为, 广电行业对BOSS系统的认知度初步提高, 一是运营商对用户管理开始重视, 二是部分运营商在经历了从SMS到BOSS的对比之后, 发现了BOSS的强大功能。