数据库应用程序中的一种进程日志和调度机制

在复杂应用程序中,实现进程日志和调度机制可能是一个巨大的挑战。对于拥有许多嵌套进程的应用程序而言,跟踪正在进行的进程及其完成阶段可能非常重要。用户往往需要了解异常终止的进程的重启能力。而且,复杂进程和子进程可能需要进行调度,以便它们能够自动化,只需最小的用户干预就能启动。本文介绍了满足这些要求的一种容易实现的机制。

Arindam Chakraborty, 信息架构师, IBM

Arindam Chakraborty 的照片Arindam Chakraborty 是 Enterprise Application Development and Management Practice 的一位数据架构师。Chakraborty 拥有超过 13 年的数据库设计和咨询经验,重点关注技术管理、软件生命周期方法系统、数据库管理、性能、架构设计、以及应用程序开发和实现。他曾管理 Information Services 和业务单位高级管理层之间的关系,计划、开发和实现了大量应用程序,提供实际业务问题的解决方案。他的软件专长领域包括通过竞争激烈的考试获取的一个 Oracle DBA 和 DB2 认证,以及根据 IBM 可靠的方法系统推动咨询方案。Chakraborty 还擅长数据架构、数据建模、企业数据仓库设计和数据市场、以及基于性能优化的数据库管理。



2010 年 12 月 20 日

简介

对于通过适当的排序调度和监控而言,多个应用程序之间的数据传输可能是一个巨大的挑战,这些应用程序是由各种资源构成的并涉及众多相互依赖的进程。异常终止的进程通常需要从它们的故障转移点重新启动,以实现它们的业务要求。另外,用户常常需要接收关于进程历史的信息,以进行审计跟踪和监控。

本文介绍一个解决方案,事实证明,该方案在应对这些要求和挑战方面非常有用,可以使用最小的资源构建。该解决方案可以使用 IBM® DB2® 关系数据库功能或其他关系数据库系统构建。无需使用任何特定调度程序或昂贵的监控工具即可监控和调度复杂的进程。该方案非常经济实惠,只需很少的技术即可开发和维护。

业务问题

有一些业务问题与数据库进程和调度相关。这些问题可能会影响盈利能力,阻止用户实现它们的功能和经营目标。

  • 不能在数据库之外跟踪的内部数据库进程的执行和完成,通常需要经过培训的资源来在数据库级别或运营系统的级别理解和监控。
  • 有些进程可能会成功完成,但需要的执行时间不正常,可能会导致意想不到的值,这是一个真正的业务威胁。这种情况可能会发生在附属进程的最低级别,这还会导致其他主要进程的操作失败和功能异常。公司需要确保那些小型附属进程的完美执行。
  • 多个源可能会以不同的顺序和时间轴将数据传递到各种进程中。这些进程必须被适当管理和调度,以避免数据不一致和进程重叠。在多格式的复杂数据集成项目中,实现适当的调度可能是一个艰巨的任务。
  • 异常的进程终止或进程完成失败是数据集成进程流中的一个常见情况。根据业务需求,数据可能需要立即通过人工干预从故障转移点恢复或者自动恢复。

用例

以下的用例有效地回答了这些业务问题。

  1. 第一个用例是进程执行的参与者查询进程历史。
  2. 第二个用例是业务活动监控。业务活动监控存储、查询、或者分析进程执行日志来找到关于进程的有用统计信息。例如,这种监控能够反映进程的每个步骤平均花费的时间和瓶颈出现的位置。
  3. 第三个用例是取消功能和恢复某些失败的进程。进程日志可用于取消和恢复不成功的进程。
  4. 最后一个用例是进程调度程序,它能够满足复杂的数据加载频率的要求。

要解决这些问题,首先必须根据组件的功能特性识别它们,设计数据模型来为日志存储和检索关键的数据元素。识别组件并准备好数据模型后,就可以像使用操作和功能测试用例一样开发和测试进程模块。开发的模块可用作现有 ETL 系统的插件,也可以用于插入和更新各个数据库实体中的数据。日志操作从数据库中的一个进程日志足迹开始,然后继续记录日志直到进程完成, 不管执行成功还是失败。

架构

系统架构包含三个主要组件:

  • 进程日志组件:适用用例 1、2 和 3。
    这个组件负责为模块中的特定进程生成进程相关信息。每当一个新进程启动时,组件使用一个预定义的执行状态记录其信息。在进程成功完成或被弃用之前,组件保持活动状态,并尝试记录该进程在数据库中的最新状态。组件在进程启动之时与进程调度组件交互,并与进程错误管理组件交互,记录处理过程中发生的错误。
  • 进程和程序调度组件:适用用例 4。
    这个组件控制进程的启动顺序。这是个附属组件,与进程日志组件交互,按计划执行与进程关联的代码。
  • 进程错误管理组件:适用用例 2、3 和 4。
    这个组件负责从预定义的错误列表生成和更新错误数据,并将信息更新到进程日志组件。

设计和开发

这个问题的解决方案非常有效,尤其是在数据集成和数据转换(ETL)应用程序中。这个解决方案在其他消息驱动的集成项目中也有效,在那些项目中,许多进程以固定的间隔执行。图 1 展示了解决方案数据流。

图 1. 数据流图表
进程启动并将一个条目放置到 process_log 中。如果成功,它输出数据或进程,并返回进程完成消息。如果不成功,则更新错误日志并返回消息到 process_log。

这个解决方案有两个主要部分:

  1. 设计数据模型
  2. 设计和构建操作逻辑

逻辑数据模型包含以下实体:

  • Process Master
  • Process Program
  • Process Program Schedule
  • Process Log Detail
  • Error Master

图 2 展示了这个逻辑数据模型。

图 2. 逻辑数据模型图表
图表展示 Process Master 和 Process Program、Process Program Schedule、Process Log 的关系。process log 还关联到 Process Error Master。

以下小节将分别检查这些实体。

Process Master

这个实体包含应用程序中的所有进程的有关信息,这是以层级格式存储在表中的主信息,即,一个进程可以有一个父进程,也可以拥有祖父进程。进程层级需要精确定义,以确保相互链接的进程的正确排序。其他信息对于存储也是有用的,但不是强制的。

在一个数据仓库系统中,涉及大量进程,比如元数据的阶段化(staging),数据质量分析、转换和合并,将数据加载到数据市场,等等。为了将那些进程定义并分发到 Process Master 中,我们可以通过以下方式安排数据:

表 1. Process Master
进程描述进程 ID父进程 ID注释
Database Process0000000000从 “00000” 开始的数据库进程
Source Data Staging Process1000000000在三个主进程中,“Source Data Staging” 是第一个父进程为 “Database Process” 的进程,这个 Process ID 从 1 开始(10000)
Staging Source System -11100010000有多个源系统,“Source System -1” 的 Process ID 为 “11000”,即,系统可以处理 9000 个源系统
Staging Source System -1 – Subsystem – 11110011000有许多 Subsystems 链接到 “Source System -1”,因此 “Subsystem -1” 的 Process ID 为 “11100”,这意味着系统最多可以处理 900 个子系统
Staging Source System -1 – Subsystem – 1 – Europe Data1110111100这个子系统在一些不同国家运行,源数据也可以从那些国家获取,这里,系统最多可以处理 90 个国家
Data Transformation Process2000000000转换进程是父 “Database Process” 的第二个主要进程,它的 ID 从 2 开始
Transform Source System -1 2100020000与 “Staging processes” 的方式相同,这个转换进程可以被分发,都带有前缀 “2”,确定每个 “Staging Process” 的 “Transformation Process
Transform Source System -1 – Subsystem – 1 211002100021000 的子进程
Transform Source System -1 – Subsystem – 1 – Europe Data211012110021100 的子进程
Hyperion Module Process 9000090000这是一个不同的独立模块,可以加入 process master(或者,也连接到 “Database Process”)
Hyperion Module Process – Data Manipulation Process -1 9100090000它拥有自己的进程分发,但也可以在输出流中调度和记录
表 2. Process Master 实体结构
列描述数据类型和宽度默认值强制(M)或可选(O)
Process ID包含 Unique Process Identification NumberChar 5NAM
Process Parent ID包含一个特定进程的 Parent Process ID并建立一个层级Char 5NAM
Process Description进程的描述Varchar 200NAM
Process Sequence进程在其层级中的序列编号(比如,此进程是其父层级中的第 5 个进程,因此值应该为 “5”)Char 2NAO
Process CL ParametersProcess Command Line 参数Varchar 2000NAO
Process Max Error Allowed这个进程允许的错误数量(系统可以查询这个数字并可以据此强制终止进程)Char 3999O
Application Name此进程针对其定义的应用程序的名称Varchar 1000NAM
Module Name此进程针对其定义的模块的名称Varchar 1000NAO
Process Logging Flag进程是否需要进行日志记录Char 1YM
Scheduler Flag调度程序是否连接到这个进程Char 1YM

Process Program

一个进程可以包含一个或多个程序(代码和数据结构)。一旦一个进程被执行,系统开始从数据库表搜索关联的程序。(注意:这种情况仅当调度程序没有连接到这个进程时发生。请查看 Process Master 表中的 Scheduler Flag。) 一个进程可以关联到多个程序,因此,这个实体具有从进程到程序的 “一对多” 基数性。

表 3. Process-Program 实体结构
列描述数据类型和宽度默认值强制(M)或可选(O)
Process Program Surrogate Key包含这个实体的 Surrogate 键IntegerNAM
Program Name包含程序名称(我们可以在这里分别保存 Program Master 实体和参考程序 ID)Varchar 50NAM
Process ID进程识别编号Char 5NAM
Program CL ParametersProgram Command Line 参数Varchar 2000NAO

Process-Program-Schedule

每个单独程序都可以被调度为以预定义的顺序执行。这个实体促使程序关联到一个或多个调度,还能够定义和构造具有特定频率的重复 Process-Program 信息。(例如,某个程序可以以 5 分钟的间隔运行。)这个实体具有从 Process-Program 实体到 Process-Program-Schedule 实体的 “一对多” 基数性。

表 4. Process-Program-Schedule 实体结构
列描述数据类型和宽度默认值强制(M)或可选(O)
Process Program Schedule Surrogate Key包含这个实体的 Surrogate 键IntegerNAM
Process Program Surrogate Key包含 Process Program 的 Surrogate 键(Foreign Key)IntegerNAM
Schedule Year包含年度Varchar 4NAM
Schedule Month包含月份名称Varchar 20NAM
Schedule Day包含日期Varchar 2NAM
Schedule Hour包含小时Varchar 2NAM
Schedule Minute包含分钟Varchar 2NAM
Repeat Frequency这个字段包含频率信息(即,#5 表示这个程序将从开始时每 5 分钟执行一次)Varchar 2NAM
Skip Schedule程序是否按照其调度执行Char 1NAM
Trigger File Flag这个程序是否从另一个应用程序预期一个 “Trigger File”Char 1NO

进程日志

一个进程被发起后,系统就开始从 Process-Program-Schedule 搜索一个特殊程序,并在 Process Log 表中创建一个条目。系统根据进程状态控制进程的执行。在进程的每个执行步骤中,都有一个附加的特定状态码,系统在进程本身的执行状态的基础上更新这个状态码字段。一个特殊进程可以使用一些不同的状态码,如表 5 所示。

表 5. 进程执行状态 - 状态码示例
状态码状态描述注释
0由于已知的错误码而失败Error Code 可以从 Error Master 获取
1程序启动等待完成
2进程成功结束仅当进程结束、没有错误时
3处理了 0 条记录目标记录计数为 0
4源实体中的 0 记录源计数为 0
5进程链接错误进程不能被连接到它的父进程(附属进程情况)
6异常完成时间进程成功但时间异常
7进程进展错误进程启动但下一条记录读取没有发生
8进程重启进程重启代码
9失败的错误为 UNKNOWN 错误错误代码不能获取
*关联父进程的状态(仅当它的此前状态为 “2”)一旦一个子进程或附属进程启动以执行(仅当它的父进程已经成功完成且状态码位 “2” 时可能),系统将其父进程状态从 “2” 转换为 “*”
#处于执行状态的进程当附属进程系统执行时,系统将父进程状态从 “*” 转换为 “#”
$父进程成功一旦附属进程成功完成,系统将其父状态从 “#” 转换为 “$”。这意味着没有必要再次处理。

流程日志算法

  1. 启动一个进程。
  2. 搜索 Process-Program-Schedule 以确认关于调度的信息并获取程序名称。
    1. 获取 Process ID。
    2. 在 Process Log 实体中插入一条记录。
    3. Process Status Flag 应该从 “1” 开始。
    4. 使用程序的命令行参数执行程序。
  3. 提交
  4. 在进程成功完成时:
    1. 使用以下细节更新记录:
      "Process End Time" = (end timestamp)
      "Process Target Record Count" = (target table record count)
      "Process Status Flag" = "2" (if successful)
      "Process Execution Time" = (end time - start time)
      "Process Comments" = (comments with SQL ERROR code and description)
    2. 如果这是一个附属进程,将 “Parent Process” 状态标志从 “2” 转换为 “*”
    3. 根据列表更新这个父进程状态。这种机制确保进程可恢复性和连续性,而且还控制附属进程执行。
  5. 在成功完成之时:
    1. 更新相同记录。
    2. “Status Code” 应该不是 “2”。从列表选择适当的状态码。
  6. 提交
表 6. Process Log 实体结构
列描述数据类型和宽度默认值强制(M)或可选(O)
Process Log ID惟一地识别一条 Process Log 记录。这个 ID 可以插入到目标文件/表(基于每条记录插入一个单独的列中),以便控制下一个附属进程执行。下一个进程将只从表/文件访问那些记录,这个表/文件已经被处理,且正在等待进一步转换。IntegerNAM
Process ID正在处理的 Process IDChar 5NAM
Process Start Time流程的启动时间戳TimestampNAM
Process Log ID惟一地识别一条 Process Log 记录。这个 ID 可以插入到目标文件/表(基于每条记录插入一个单独的列中),以便控制下一个附属进程执行。下一个进程将只从表/文件访问那些记录,这个表/文件已经被处理,且正在等待进一步转换。IntegerNAM
Process End Time流程的结束时间戳TimestampNAM
Process Source File Name源的文件/表的名称Varchar 100NAO
Process Source Record Count源文件/表中的启动记录计数IntegerNAM
Process Target Record Count流程的结束记录计数IntegerNAM
Process Status Flag流程的状态(从状态列表获取)Varchar 2NAM
Process Start Module启动流程的模块Varchar 100NAO
Process End Module进程结束的模块Varchar 100NAO
Process Execution Time实际流程执行时间(可能不是从开始时间和结束时间之间的确切差)DecimalNAM
Process User Log ID启动流程的用户Varchar 50NAM
Process System StatusSystem (OS / Network) 相关信息Varchar 2000NAO

Process-Error

这个实体已经定义了流程相关的预定义错误代码和描述,用于流程执行步骤。当一个错误发生时,系统从这个表查找相关的错误代码,并根据 Process Log ID 从表更新 Process Log 表。

表 7. Process-Error 实体结构
列描述数据类型和宽度默认值强制(M)或可选(O)
Error Code包含错误码Char 5NAM
Error Description包含错误描述Varchar 100NAM
Error Type哪种错误类型:“SQL”、“SYSTEM”、“DATA”、“CODE”Varchar 10NAM
Critical Status5 = 最关键, 1= 最不关键Char 1NAO

伪代码

下面展示了一个样例伪代码,它在 Process Log 表中插入记录。

Main Procedure "Process Log Insert"
   Define 5 input parameters
   1st parameter is the input "Process ID" [by searching right process from Process-
	Program-Schedule"  Entity ]			
   2nd parameter is the "Start Time" 
   3rd parameter is the "Start Module" 
   4th parameter is the "Mode" [either "Insert" or "Update"]
   5th parameter is the "Process Log ID" (optional - for control the next process 
	execution)
				
   >>Insert a new record in the "Process Log" Entity with the input parameter 
	specified above, use DB2 INSERT statement to insert the record.			
					
   >> Update existing record in the "Process Log"  Entity, use DB2 UPDATE statement
	 to update the record.

注意事项

这个解决方案最重要的部分是使用适当的进程层级构建 Process Master 实体。成功创建 Process Master 后,需要根据进程的运行顺序和频率定义 Process Program Scheduler 数据。这两个活动是总体解决方案的先决条件。

结束语

现在,您应该能够跟踪整个应用程序的所有进程以及单独的、嵌套的、细粒度进程。这个解决方案是一个概念,可以使用任何 RDBMS(包括 DB2 和 Informix)构建,无需太多开发工作和资源利用。

要获取最优性能,您需要在 Process Log 表上的物理数据模型中创建适当的数据库索引。这个解决方案的另一个用途是进程可恢复性,当应用程序崩溃并需要重启时。这可以基于 Process Log 表中的那个特殊进程条目执行。为了重启进程,系统需要获取最新状态码和详细的进程信息。

这个解决方案没有提供任何界面来加载主数据或者为终端用户生成报告,用户需要单独构建它们。另外,自动可恢复性也需要单独设计。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=604233
ArticleTitle=数据库应用程序中的一种进程日志和调度机制
publish-date=12202010