商用库服务培训.docx
《商用库服务培训.docx》由会员分享，可在线阅读，更多相关《商用库服务培训.docx（16页珍藏版）》请在冰豆网上搜索。
商用库服务培训
商用库部分系统培训
国电南瑞科技股份有限公司电网控制分公司
新系统平台开发组
2005年01月
目录
引言3
一.历史数据服务的定义以及在新系统中的定位4
二．历史数据服务包含的内容和相应的分类8
三．历史数据服务和数据库服务器的联接方式10
四．数据复制与同步服务的实现方式12
五．新系统中1+N功能的实现机制15
六．数据库服务器的异常处理和切换机制16
七．历史数据采样简介18
八．缓存机制以及缓存目录20
九．数据追捕的作用以及工作流程21
十．其他服务21
1.模型更新服务21
2.直接SQL服务21
3．历史数据查询以及统计服务22
4．历史数据修改服务22
5．商用库告警服务22
引言
在新一代电力调度自动化系统的统一支撑平台中，历史数据服务作为数据库管理系统的重要组成部分，扮演着重要的角色。
这些服务和其它各类服务之间的一个最重要的区别就是它们需要直接和商用数据库进行联接并交换数据，要注意的是这些服务的运行往往需要数据库（ORACLE、SYBASE等）客户端动态库支持。
由于读写商用数据库的实质是磁盘文件的I/O操作，在三层体系结构中还需要通过网络进行访问，其速度和实时系统有着数量级上的差别，所以对于历史数据服务来说，首先需要解决的是相对慢的读写速度和系统连续不断读写需求（如高频率采样、画面上的不间断查询）之间的矛盾，确保商用数据库的操作不会成为整个系统正常运转的瓶颈。
另外，由于系统中存在着冗余配置的数据库服务器，包括主备数据库服务器、镜像服务器、灾备服务器以及在安全隔离区以外的WEB服务器等。
系统需要保证在各种配置和各种情况下数据库服务器之间数据的同步和一致，因此，数据的复制和同步机制变得非常重要。
再者，考虑到调度自动化系统的高可靠性要求，系统不仅在正常情况下能够高效处理数据，还必须具备在恶劣的外部环境下确保可靠运行。
例如，在数据库损坏或者网络异常中断的情况下如何保证系统还能保持大部分的功能不受影响，在切换的过程中如何保证数据没有丢失等等。
因此，数据库服务器以及相关的应用服务器的异常处理和切换机制也是新系统平台中十分关注并且需要很好解决的问题。
一.历史数据服务的定义以及在新系统中的定位
在新系统的统一平台中，十分强调服务的概念。
所谓服务（SERVANT），也就是一个或者一组运行在相关服务器上的后台进程（多线程），它们为其它的各个客户进程提供数据的查询、更新以及应用逻辑的处理，使得数据的处理能够集中在服务器上，客户端只要关注自己的人机交互以及某些应用逻辑。
这同时也是新系统C/S/S结构的要求。
在新系统的平台设计中，存在着众多的服务。
例如，下装服务、数据更新服务、查询服务、任务管理服务、告警服务、系统配置服务、日志管理服务、历史数据采样服务等等。
在这些众多的服务当中，有一类服务需要直接和商用数据库打交道，如下装、数据更新、查询、历史数据采样等（实际上，在商用库部分实现中，诸如历史数据采样等的服务我们并不划分在历史数据服务中，以后的篇幅中我们会逐步阐述其中的原因）。
我们将所有和商用数据库打交道的服务以及支持商用数据库之间复制和同步的服务统称为历史数据服务。
那么，在整个新系统的体系当中，历史数据服务究竟处于什么位置，完成什么样的功能呢？
在回答这个问题之前，我们先要阐明几个和C/S/S结构有关的概念。
所谓C/S/S结构，简单地说，指的是系统硬件和软件的三层体系结构。
一方面是将整个系统的结点划分为客户机、应用服务器和数据库服务器三个层次，另一方面是将所有的软件划分为客户应用软件、应用服务软件和数据库管理软件三个层次。
其中，客户应用软件主要处理人机交互以及某些应用逻辑；应用服务软件完成大部分的应用逻辑处理以及和数据库的交互；数据库管理软件完成数据的存储、组织和管理。
具体应用到我们的新一代调度自动化系统中，上述所有的那些服务在物理上就应该驻留在应用服务器当中。
结合新系统的体系结构设计方案，应用服务器又可以分为SCADA应用服务器、PAS应用服务器、前置应用服务器等，根据每个服务的不同性质，将这些服务分布在各个服务器结点当中，相互配合、协调来完成整个系统的功能。
那么，我们提到的历史数据服务应该位于哪个应用服务器上呢？
为了解答这个问题，我们需要将各种类型的服务器进行一些概念上的定义和明确。
这些术语贯串了整个设计方案。
Ø数据库服务器
安装了具体商用数据库（ORACLE）的服务器结点。
Ø应用服务器
专门负责处理应用或者业务逻辑的服务器，其上运行着众多的服务进程。
但是，这些进程不和商用数据库直接联系。
Ø历史数据服务器
专门负责处理和商用数据库直接交换数据的服务器，其上运行着我们的历史数据服务进程。
必须指出，所谓的应用服务器和历史数据服务器都是逻辑上的概念，其逻辑划分是以服务的性质来决定的，并不是一个系统中必须在物理上配置这些独立的硬件。
也就是说，应用服务器完全可以和历史数据服务器共存于一个物理结点中，或者，三种服务器都共存于一个物理结点中。
但是，在逻辑上，特别是软件的逻辑划分上我们采用这些术语，以方便整个方案的阐述，不致引起概念的混淆。
现在，我们可以比较明确地回答上面遗留的问题了。
历史数据服务在逻辑上分布于历史数据服务器当中（不得不再次强调历史数据服务器是一个逻辑概念），它们主要完成和商用数据库直接交换数据的功能，其结果（数据的查询和更新）被其它服务进程或者客户应用进程引用。
为什么要单独将历史数据服务以及历史数据服务器划分为一个逻辑上的概念呢？
其一，这主要是为了解决在引言部分提出来的第一个问题，即商用数据库相对实时系统较慢的处理速度不能成为整个系统正常运转的瓶颈。
例如，在很多调度系统中，包括现在的OPEN2000系统，历史数据采样进程在一个时间周期内（通常是5秒），既要从实时库中读取所有需要采样的遥测的数据和状态值，又要将这些数据拼接成相应的SQL并在数据库中执行。
在数据量较大或者突发紧急事件（CPU负荷短暂地升高）的情况下，这些涉及到磁盘I/O操作的SQL执行根本就来不及处理，以至于会经常造成漏掉采样点的情形。
为了避免这种情况，我们需要将SQL执行的部分单独提取出来作为一个服务，使得采样服务专心处理实时数据的读取（在内存中处理），而不至于因为SQL的执行速度慢导致漏掉下一个采样周期。
这也是前面提到历史数据采样服务不被划分在历史数据服务中的最重要的原因。
其二，由于系统中分布着各种应用服务器（SCADA，PAS，前置等），出于效率上的考虑（主要是尽量避免从网络上读取实时数据），一些服务进程会同时分布于各台应用服务器上。
同样以采样为例，新系统中采样服务是作为公用服务提供给各个应用使用，也就是每个应用都拥有自己的数据采样服务。
由于不同应用在物理上可能的不同分布，所以采样服务也会同时分布于各个应用服务器中。
如果不将其中的SQL执行部分划分出来，则势必在每个应用服务器上都需要相应的商用数据库客户端软件。
这样，和我们的C/S/S结构就存在一些冲突，同时也会潜在地增加系统的成本。
其三，这样的划分有助于简化数据库服务器的复制、同步、异常以及切换时的处理机制。
在考虑上述可靠性要求的时候，我们的视线只要集中于那些直接和商用数据库打交道的服务进程，也就是我们的历史数据服务。
这样，可以对历史数据服务采用统一的机制来解决这些问题。
将来增加其它的服务或者应用进程时，只需要将和数据库相关的部分提交给历史数据服务来处理，而无须关心数据库服务器的诸多可靠性要求。
图1表示了各种服务器和相应的服务在整个系统中的分布。
图2表示了各种服务器以及客户机在数据处理上的层次关系。
图1数据库服务器、历史数据服务器、应用服务器以及各种服务在系统中的分布
图2各种服务器以及客户机在数据处理上的层次关系
二．历史数据服务包含的内容和相应的分类
从前面给出的定义可以看出，所有和商用数据库直接进行数据交换以及支持数据库服务器的复制和同步的服务都属于历史数据服务。
所以，历史数据服务实质上是一个服务包。
这个包中拥有下列服务进程：
Ødb_modify_server模型更新服务
提供客户端或者应用进程通过约定的接口进行数据库更新操作的服务。
该服务的特点是调用方需要立即知道执行的结果，并且需要同步更新每个应用服务器上的实时数据库。
Øsql_sp_server直接SQL以及存储过程服务
提供客户端或者应用进程通过直接SQL语句或者执行存储过程来进行数据库更新操作的服务。
该服务的特点是调用方需要立即知道执行的结果，但是无需同步更新实时数据库。
Ødb_commit数据提交服务
提供给一些需要更新商用数据库数据的服务进程（如采样、告警登录等）提交各自形成的SQL命令的服务。
该服务的特点是调用方并不等待（或者说不关心）SQL命令执行的结果，但是存在着时序相关和时序无关两种类型。
基于效率的和并行操作的考虑，该服务其实包含2个进程。
db_commitsample（采样）
db_commitscada（除采样外的其它数据）
Ødownload_server数据下装服务
提供将商用数据库的数据下装到实时数据库的服务。
该服务的特点是没有数据库更新操作，本质上属于查询操作。
Øquery_sample_server历史数据查询统计类服务
提供客户端或者应用进程进行历史数据查询以及统计的服务。
该服务的特点也是没有数据库更新操作。
Ødb_replicate复制处理服务
所有上述这些服务进程并不直接同步其它的数据库服务器，而是统一通过调用复制动态库来完成上述工作。
该动态库的特点是并不直接和数据库打交道，仅仅将数据复制请求写入复制请求文件队列。
然后再由db_replicate程序处理相应的文件队列，并对远程数据库服务器进行实际的数据复制和同步工作。
因此针对系统中的每一个数据库服务器，都有一个db_replicate服务进程与之对应。
从上面的分析可以看出，虽然同属于历史数据服务，但是各个不同的服务完成不同的功能，并且具有不同的特点。
而这些特点决定了其在数据提交、复制以及后面要讨论的数据库服务器切换过程中的机制会有所不同。
为了方便阐述，我们根据它们不同的特点将这些服务划分为以下五类：
Ø查询类服务
包括download_server，数据查询和数据统计服务。
Ø需要知道执行结果的数据更新类服务，简称为更新类服务
包括db_modify_server，sql_sp_server两个服务，本质上是时序相关的。
Ø时序相关的数据提交服务，简称相关提交类服务
包括和时序相关的数据提交服务。
如发生遥信变位后，将开关状态写入开关表中，这种数据提交操作无论在复制还是切换过程中都有着严格的时间顺序要求，否则将可能产生错误的结果。
Ø时序无关的数据提交服务，简称无关提交类服务
包括和时序无关的数据提交服务。
如采样或者事件登录，由于形成的SQL命令中本身带有时标，所以在复制或者切换过程中无所谓执行的先后顺序。
Ø复制类服务
包括db_replicate服务进程，负责数据复制和同步工作。
在下面的篇幅中，我们将使用以上的分类方法和对应的术语。
三．历史数据服务和数据库服务器的联接方式
前面提到，所谓历史数据服务，都是需要直接和商用数据库交换数据的服务进程。
那么，在明确了历史数据服务的定义以及其包括的内容以后，我们需要关注一下它们和数据库服务器的联接方式。
根据系统的不同规模和用户的不同要求，系统中存在各种各样的数据库服务器。
一般说来，我们可以将系统中的数据库服务器分为以下几种类型：
主数据库服务器、备数据库服务器、灾难备份数据库服务器、镜像数据库服务器以及WEB数据库服务器。
其中，主备数据库服务器是系统运转的核心数据存储结点，其它的数据库服务器都通过系统的复制机制保持同步。
其实，主备数据库服务器可以不止两台，可以是多台，而且并不是传统的主备之分，只有优先级之设定，个中理由将在后续篇幅中逐步阐明。
之所以称为主备数据库服务器，主要是为了叙述上的方便。
每个历史数据服务进程根据不同的性质都需要建立和上述的各种数据库服务器的联接，才能和数据库进行通讯和交换数据。
基于系统的三层架构，这些服务和数据库的联接只能通过网络方式进行，即通过指定主机、端口号以及数据库实例和特定的数据库建立联接。
由于我们在系统中采用双网的连接方式，所以我们首先要考虑和解决的就是如何克服单网卡故障带来的数据库联接的中断问题。
幸运的是，在新系统的平台设计中，网络管理服务恰好提供了上述问题的解决方案。
该服务（net_pathing）的一个重要功能就是能够完全屏蔽结点的多个网卡地址，提供给其它应用和服务进程的是一个该结点的虚拟地址。
对于系统中所有的应用和服务进程来说，面对的只是一个地址，对于目标结点来说，只有网络正常和网络中断两种状态，而无须考虑双网（或者多网）的切换。
这样，在和数据库服务器的联接中我们完全不需要考虑单网卡故障带来的中断和切换问题。
接下来，我们需要关注每个具体的历史数据服务和前面提到的各种数据库服务器的联接方式。
经过分析我们发现，由于系统的主备数据库服务器是数据复制的源头，所以除了db_replicate进程以外，其它所有的历史数据服务进程都只需要和主数据库服务器通讯。
而db_replicate需要和所有的数据库服务器相连（WEB的情况比较特殊，因为其在安全隔离区之外，在后面的数据复制与同步机制中有详细讨论）。
另外，需要指出的是，复制动态库不和任何数据库服务器联接。
在系统正常运转的情况下，所有的历史数据服务进程（无论是在主历史数据服务器还是备历史数据服务器上）都和当前的主数据库服务器建立联接并交换数据，备数据库服务器的数据通过复制机制进行同步。
当主数据库服务器的联接发生中断，这些进程重新建立和备数据库服务器的联接，同时备升为主，并保持主服务器状态。
这样的处理方式使得历史数据服务进程的数据流程比较简明、清晰，并且可以有效地克服交叉故障的情况。
在以后的章节里将详细阐述各种情况下数据库服务器的复制、异常和切换机制。
图3表示了各历史数据服务进程和各个数据库服务器的联接方式。
其中，虚线代表了在备数据库服务器值班的情况下的联接。
图3历史数据服务进程和数据库服务器的联接方式
四．数据复制与同步服务的实现方式
数据的复制与同步，也就是各个数据库服务器中的数据保持一致，一直是困扰着国内各EMS和DMS厂商的一个大问题。
这个问题如果不能真正解决好，系统的可靠性也就会相应地大打折扣。
因此，在新系统的整体设计，特别是数据库系统的设计中，这个问题得到了我们特别的关注。
我们一直在寻求一些比较成功和可靠的商业解决方案。
不幸的是，由于电力调度系统具有连续运行、实时、数据量大、切换速度要求很高以及自身特殊的安全性规定等特点，使得目前我们还没有找到合适的产品。
主要的原因有以下三点：
Ø这些商业解决方案基本上都必须通过数据库日志来实现。
而我们的系统由于数据量非常大，一般不能保存这些日志，否则数据库的日志会很快占满整个数据库空间。
这也是我们为什么需要选择自动清除日志的数据库选项（SYBASE），或者必须运行在非归档模式（ORACLE）下的根本原因。
Ø电力调度系统要求的切换速度很高，一般的商业解决方案无法达到这些时间指标。
Ø对于和调度系统不在一个安全隔离区的WEB数据库来说，中间隔着一个电力系统专用物理隔离设备，该隔离装置只能允许TCP/IP的单向访问。
这直接造成了所有的商业软件无法得到应用。
因此，在新系统的设计中，我们只能自己来实现数据的复制和同步机制。
首先，我们需要明确数据复制的概念和范围。
我们所说的数据复制与同步，是指所有系统中涵盖的各种数据库服务器中商用数据库里的数据保持实时的同步。
这些数据库服务器包括系统的主备数据库服务器、灾备数据库服务器、镜像数据库服务器以及WEB数据库服务器等，正如我们前面已经提到的那样；另外，这种复制和同步在系统的主备数据库服务器之间是双向的，而对于其它的数据库服务器而言是单向的，即只能由主备数据库服务器向其它的服务器同步和复制数据，这些服务器只是起到一个备份或者只读访问的功能；再有，我们需要保证在各种恶劣的情况下依然能够维持数据的一致。
接下来，我们阐述在本设计方案中数据复制和同步的实现方式。
前面我们已经介绍了在历史数据服务器（逻辑概念）上的复制类服务进程。
其中，复制动态库libdb_rep.so负责接收由db_modify_server、sql_sp_server以及db_commit等服务调用的已经在当前主数据库服务器上执行完毕的SQL复制请求（这里，SQL请求其实包含了诸如存储过程请求，为了方便，我们统称为SQL请求）。
注意一点，对于db_commit服务来说，无论执行成功与否，均需要同步复制。
然后复制动态库将这些请求按照接收的顺序（时间顺序）写入本地文件队列，交由db_replicate进程负责处理，这个队列我们称为复制请求队列。
db_replicate是一组完全相同的进程，其个数n等于系统中所有数据库服务器的数目。
每个db_replicate进程联接自己的那个目标数据库服务器（见图3），负责按照顺序读取相应复制请求队列的SQL请求并在自己的目标数据库服务器中执行。
如果目标数据库服务器连接中断或正在启动关闭中，db_replicate则一直等待，直到联接恢复；如果SQL请求执行失败，则同样地需要写入ErrorLog文件当中，以便日后查询或者进行人工干预。
无论SQL执行是否成功，db_replicate都需要立即从复制请求队列中删除该SQL请求。
对于处于安全隔离区外的WEB数据库服务器来说，其运行db_replicate进程的实现和其它进程略有不同，因为普通的db_replicate无法跨越这个物理隔离设备连接WEB数据库。
因此WEB数据库的复制程序实际上调用网络服务提供的文件传输动态库将本地缓存的SQL文件传输到WEB一侧，另外WEB上将运转一个接收程序（实际上是两个db_rep_recv/db_rep_recv_lob）将接收的文件写入本地复制队列，再由WEB本地的普通db_replicate写入WEB数据库。
由于存在n个db_replicate进程，所以复制动态库维护和管理的是n个复制请求队列，也就是说复制动态库在接收到复制请求以后，需要同时在n个复制请求队列的末尾添加新的请求。
而每个db_replicate进程负责处理某一个特定的复制请求队列中的数据。
但是实际上，复制动态库在接收到复制请求以后，只需要根据系统中的数据库服务器配置情况（通过读取相应的配置参数得到）写入n-1个复制请求队列即可，那个联接到当前主数据库服务器的db_replicate进程所对应的复制请求队列无须写入。
这是因为，当前主数据库服务器已经执行了该SQL请求（通过db_commit），不再需要进行复制。
那么，我们为什么还设立这个进程和复制请求队列呢？
这牵涉到在新系统中1+N功能的实现机制，我们将在下一节中阐述。
历史数据服务器上的复制类进程或动态库无须判断自己是主还是备，复制动态库只要接收到请求就开始处理，而db_replicate则不断地处理相应的复制请求队列。
另外，它们也无须判断数据库服务器的主和备，每个db_replicate进程都和特定的数据库服务器相连，如果联接中断，则一直等待，联接恢复时继续进行复制工作。
五．新系统中1+N功能的实现机制
首先，我们要给“1+N”功能在新系统中一个准确的定位。
所谓“1+N”，其本意是指在一个分布式的计算机系统中，任何一个结点的退出或者故障都不会引起整个系统功能的丧失，直到只剩最后一个结点。
但是，在C/S/S结构中，每个结点都承担着不同的任务，这种理想状况是当然无法达到的。
分析我们的系统，其中最重要也是最核心的结点应该是主备数据库服务器，如果由于各种情况（特别是硬件故障的情况下）导致数据库服务器瘫痪，不仅历史数据会丢失，整个系统也将处于崩溃的边缘。
因此，在新系统中，我们对“1+N”的定位是：
当主备数据库服务器都发生故障的情况下（包括数据库退出、机器宕机、网络中断等），系统仍然保持正常运转，除数据更新类和查询类服务暂停以外，其它运行功能不受影响，期间发生的历史数据不会丢失，并且在系统恢复正常时能够自动恢复。
我们把系统的这种状态称为“1+N”状态（也许需要对1+N重新命名，这里姑且借用这个名称）。
当主备数据库服务器都发生故障时，也就是系统处于“1+N”状态时，db_modify_server、sql_sp_server以及所有数据库查询类服务均不再接受服务，所有客户端的调用都将有“暂停服务”的提示。
因此，我们只需要关注和处理db_commit服务进程和复制类的进程。
db_commit依然接收服务请求，当发现处于“1+N”状态时，跳过向数据库提交这个环节，直接将SQL复制请求发送给复制动态库，并由其将这些请求写入n个复制请求队列（注意，不是n-1个）中，即主数据库也出现复制队列。
除主备数据库服务器以外的其它数据库服务器都可以进行正常复制，而退出运行的主备数据库服务器对应的db_replicate进程会发现当前联接中断，于是一直等待。
待系统恢复正常后，db_replicate仍然会通过正常的数据处理流程将SQL请求从复制请求队列中读出，然后按照时间顺序复制到主备数据库服务器当中去。
可以看到，我们只是多设了一个db_replicate进程，其处理流程并没有因为“1+N”的状态而发生任何改变，但是，的的确确，我们轻松而且巧妙地实现了“1+N”的功能！
六．数据库服务器的异常处理和切换机制
前面的章节主要讲述了历史数据服务包含的内容以及每个服务进程的基本实现方式，接下来两部分我们开始讨论在异常情况下系统的处理和切换机制，以及每个历史数据服务的相应对策。
首先要考虑的是当系统的主备数据库服务器发生异常时我们的应对策略。
其它的数据库服务器发生故障时其对应的db_replicate进程保持等待状态（详见第6和第7部分）。
我们已经提到，系统中的主备数据库服务器其实并没有真正意义上的主和备之分，只是具有不同的优先级别。
所谓主指的是当前历史数据服务所联接的那个数据库服务器，是一个相对和动态的概念。
我们为每个系统的数据库服务器设定一个优先级，这样的优先级划分只是为了在系统刚启动或者当前主数据库服务器发生故障时历史数据服务进程能够知道应该重新建立和哪一个数据库服务器的联接。
通过这样的定义，实际上，一个系统中的数据库服务器可以完全不止两个，可以是三个、四个或者更多（当然，多数据库服务器体系的配置需要很高的资金投入）。
另外需要明确的是，什么是数据库服务器的故障状态。
我们认为，所谓数据库服务器发生故障，是指该数据库服务器宕机、数据库退出或者网络中断。
这三种情况所表现出来的共同特征是历史数据服务进程和该数据库服务器的联接发生中断。
所以，在所有的历史数据服务进程当中，都会周期性地判断当前数据库联接是否正常（由于历史数据服务进程都是被动地接收请求，所以也可以在处理请求时发现联接正常与否），这是我们对数据库服务器故障的唯一判据。
现在我们可以研究一下在数据库服务器故障的情况下，系统的异常处理和切换机制了。
我们以两台系统数据库服务器为例进行说明，两台以上的配置情况可以依次类推。
1．系统正常运转
当系统正常运转时，所有历史数据服务均联接在当前主数据库服务器上，备数据库服务器通过复制机制完成数据的同步。
2．主数据库服务器故障
当主数据库服务器发生故障，所有历史数据服务进程将能够立即发现，各进程开始根据系统设置的优先级寻找下一个可用的数据库服务器，并启用该联接。
如果找不到一个可用的联接（即可用的数据库服务器全部中断），系统进入“1+N”状态，开始启动“1+N”流程（见第7部分）。
虽然我们已经启用了备数据
升级会员 