嵌入式实时数据库系统的事务处理特点

2　嵌入式实时数据库系统及其事务处理特点

嵌入式实时数据库系统具有与传统的嵌入式数据库系统和实时数据库系统不同的特点，不能直接引用传统的事务处理策略和方法，在对其事务处理的核心理论和关键技术问题进行研究之前，必须对系统本身的特点进行详细准确的分析，并由此探讨事务处理的特点，为后续的研究提供应用背景。

2.1　嵌入式实时数据库系统的特点

嵌入式实时数据库系统与其完全版本在某些方面相似，比如，可以是层次的、关系的、面向对象的甚至是对象/关系的模型。根据Patricia Seybold集团技术咨询公司高级分析员Anne Thomas Manes所说：嵌入式数据库在设备中完成基本的存储、组织、查询、应答和其他一些应用于台式机器的标准数据库所具备的功能。虽然嵌入式系统与台式和服务器版本的对应部分具有很多共性，但是，它有着独特的需求和局限性，主要体现在以下几个方面：

（1）小体积和功能局限性

通常而言，嵌入式数据库面临着完整数据库所没有的挑战，例如，它们必须集成到小的设备中，因而存储器和内存较小，要求无维护地运行或者维护量很小。所以，其大小一般为8～350KB，有些厂商已经生产出嵌入式数据库智能卡［1，2，3］，比如，Pervasive Software生产了智能卡嵌入式数据库SQL 2000，只有8KB。

为了取得必要的小体积，嵌入式数据库不能包含完整数据库所具备的所有功能。它们需要结构化查询语言包含丰富的命令集，具备管理和操纵数据的能力。但是，很多嵌入式数据库系统（如某些专用系统只应答特殊请求）对并发度的要求不高，处理的数据量也不大，有些系统不需要成熟的（完全的）错误恢复，甚至一些系统没有并发用户不需要事务处理，它们只需要一个高性能的数据存储能力。嵌入式实时数据库系统并不需要商业数据库完整版所有的功能，与特定应用相适应，开发者可以通过保留简单的SQL命令（比如，insert、select、update或delete）去掉高级功能（比如，算术、统计能力）来减少其体积。毕竟，PDA用户不需要这些高级功能。它们可能仅仅需要alphabetize、sort、group和search相关的表。PointBase数据库的体积与功能的配比关系如图2．1所示。

图2.1　数据库系统体积与功能的关系

（2）无管理的运行和可预报性

嵌入式实时数据库系统嵌入到设备中，常常在没有人工干预的情况下独立运行，或者它们的用户意识不到他们在与计算机打交道。此时，没有数据库管理员的管理。当出现异常情况时，系统应具备自我纠错的能力。为了达到这个目的，嵌入式系统的可预见性甚至比桌面应用系统更重要。

为了提高可预见性，需要给定一些约束，系统运行时必须时时检查返回值和应用中的其他错误指示，以便在无外部干预的情况下识别错误和恢复。例如，如果一个写操作因为没有足够的存储空间而失败，系统应该清除部分空间以便此写操作能成功完成；如果是网络链接失败，系统必须透明地指示客户机改道别的链接；由于数据库请求可能因为多种原因失败，设计可预见性并不容易。

资源贫乏是数据库操作失败的潜在原因，系统资源的不当管理是一个普遍的错误，特别是不能适当地占有和释放内存资源。由于嵌入式实时数据库系统可能长时间地运行，即使小小的内存漏洞就能最终耗尽所有的可用空间；可预见地运行和适当自主的管理显得尤为重要。

对于终端用户而言，可预见性意味着系统不需要人工管理而连续工作，意味着无备份、无恢复过程、无周期性地重整。如果该软件用一个日志记录变化的轨迹，该应用必须保证数据库周期性地宣告不再使用的日志记录，否则，过时的日志将大量占用宝贵的存储空间。如果数据库必须在系统崩溃后恢复，该应用程序必须明确何时恢复，并且必须采取对用户透明的合适的应对措施。

（3）时间性

作为数据处理的核心环节，嵌入式实时数据库系统被嵌入到设备或大型软件中，直接与环境接口和交互。由于嵌入式系统常常用于处理采集数据、过程控制和事故报警等方面，其事务和数据具有定时性、周期性或其他时间特性；事务必须在特定的时间内得到响应，否则其价值会降低。典型的如，飞机自动调度系统中，有些飞机必须正点起飞，否则它超时占用跑道就会影响空中飞机的降落，有些飞机必须及时降落，否则，其运送的货物可能变质，价值降低；有些飞机必须在适当的时刻调整航线，否则可能会机毁人亡。

（4）高可靠性

可靠性在嵌入式实时数据库中显得特别重要。根据Duncan的观点：某些数据库是基于ROM的，镶嵌在大型系统中，并且常常配置在远程或分布式站点，重启和升级不容易，系统必须很可靠。PointBase市场副总裁Art Monk说：使用被保护的、可重用的模块是提高可靠性的一个方法。

（5）协同性

嵌入式实时数据库系统开发者面临的最大挑战是协同性，不同设备之间、嵌入式数据库和大型企业数据库之间保持通讯需要彼此协同，另外，运行于不同操作系统上的嵌入式实时数据库系统也需要彼此协同。

（6）面向应用

由于嵌入式设备提供的服务范围较大，不同的嵌入式系统对它们

所使用的数据库系统有不同的要求。为了得到最佳的嵌入式实时数据库系统，首先确认嵌入式系统将提供什么样的服务，必须选择最适合你的特殊应用的产品，然后将它们与你的应用相结合。

（7）可裁剪

考虑到系统的通用性，很多嵌入式实时数据库系统是可配置（裁剪）的，允许开发者根据应用需求加入或减少服务——比如，前映像日志和两段锁。

（8）安全性较弱

安全性对于嵌入式实时数据库系统并不是必需的，因为它有可能不需要与外部通讯，比如，数据库镶嵌在嵌入式系统的ROM中，但是，对于有多用户访问或智能电话这类设备中的嵌入式数据库，安全性还是必需的，它的安全性通过加密、口令和限制用户存取权限来实现。

（9）广泛的硬件支持和开放的设备驱动程序

嵌入式实时数据库系统与硬件设备密切联系，事务处理（或数据处理）的直接后果可能就是驱动某些设备，比如，在水库监控系统中，水位升高到某个标准时需开闸放水，或闸门承受的压力到一定极限时需采取应急措施等。因此，系统需要广泛的硬件支持和开放的设备驱动程序。

（10）开放的用户接口

多数嵌入式实时数据库系统并不是像台式系统一样，用户必须通过键盘或鼠标发命令，在嵌入式实时数据库系统中，检测仪、探测器、扫描仪以及来自于其他程序的处理结果等都能驱动数据库运行，成为数据库系统与外部的接口。

基于以上分析，支持这类应用的嵌入式实时数据库系统应具有下列功能特性：

（1）事务的复杂性(www.xing528.com)

在嵌入式数据库系统中，事务的复杂性主要体现在以下几个方面：

①执行路径复杂性。事务有多条执行路径，当某一个路径不能成功执行时，只要时间许可，自动选择其他路径继续执行，这样，一方面事务重启时可以避开原来的障碍；另一方面，从语义上支持多方案选择的应用。

②活动复杂性。事务内部子事务之间以及事务之间存在复杂的互动关系，一个事务的执行可能触发另一个事务，一个事务的提交也有可能依赖于其他事务的执行结果。

③事务价值复杂性。事务的价值不仅依赖于事务执行的数据正确性，而且依赖于事务执行的时间和场合。

（2）事务的可补偿性

由于嵌入式实时数据库系统的事务操作结果常常是直接驱动外部设备，在事务提交之前，该事务可能已对外部环境产生了影响，这种影响不能通过事务的undo来消除，必须有另外的事务来补偿，因此事务应该具备补偿性。

（3）事务执行的并发性

虽然嵌入式系统并不要求很高的并发度，但依然要求提供事务彼此协调、并发执行的能力。

（4）事务正确性的判断

由于事务具有实时性，事务的价值与执行时间有关，有些事务在超过截止期的情况下不仅不能给系统带来收益，反而会带来灾难。比如，一列火车A晚点了3分钟，在此时刻站台属于另外一列火车B，如果A进站，则两列火车势必相撞。因此，事务的及时性比正确性更重要，有时宁愿及时地获得部分正确的信息，而不愿要完全正确但已过时（无效）的信息。

（5）访问外部数据库

在嵌入式实时数据库系统中，一方面系统在无人工干预下运行，事务要应对各种不测，需要知道用户数据以外的系统数据；另一方面，高效率和高可靠性要求事务能正确的选择执行路径，事务必须能了解有关调度的系统信息，由此，数据库的含义需要扩展，以便用户能够读取普通数据库以外的数据，如事务运行图、锁表等，以便事务能调整执行路径，提高系统的可预见能力。

（6）数据的时间性

由于嵌入式实时数据库往往无数据库管理员，在无人工干预下执行，而且，内存一般比较小，不断增长的数据不能无限期地存储在数据库中，因此，对于那些已经失效的数据，系统应能及时清除，系统只存取有效数据。故数据除具有值外，还具有时间属性，每个数据有一个与之相联的“有效”时区。

（7）强有力的预分析

为了实施实时调度，必须对事务进行预分析和处理，以便确认事务的可调度性、选择事务的执行路径，以最佳方式进行调度。这就要求采用内存数据库技术，避免I/O等不确定因素，使预分析事务的执行时间成为可能，同时提高执行速度，尽可能保证事务的截止期。由于事务的结构更加复杂，导致嵌入式实时数据库系统中的事务预分析有别于传统的事务预分析，典型的如，事务的最坏执行时间不是一个独立的数值，而是一个向量，该向量由事务所包含的各执行路径的最坏执行时间组成。

（8）主动性

嵌入式实时数据库系统往往要求监视数据库状态，在特定的状态或状态变迁出现时，自动进行条件评价，当条件满足时自动触发某一外部或内部活动。比如，通过传感器关闭一个闸门，这就要求系统具备主动性。主动性在保障系统可预见能力方面非常重要，比如，当发生资源阻塞时，事务自动从另外一条路径执行。

（9）时间与空间的取舍

如上所述，嵌入式实时数据库系统的体积较小，内存容量也小，事务处理和数据组织的方式应以节约空间为主，为此需要付出时间代价。但是，嵌入式实时数据库系统常常处理实时事务，特别是为了避免灾难，需要不惜牺牲空间来节约处理时间，时间与空间的矛盾在嵌入式实时数据库系统中显得特别突出。

（10）简略的恢复机制

有些系统不需要恢复，其恢复几乎就是数据库重装；有些系统不会花费宝贵的内存空间保留日志，而采用相应的改进方法或基于影子的恢复策略。

综上所述，嵌入式实时数据库应用要求嵌入、主动、实时、内存数据库的完善集成，尤其是在事务模型、特征、正确性标准、事务处理及系统的存储体系结构等方面需要做出深入的探讨。

2.2　基于替代/补偿的实时事务及其处理

嵌入式实时数据库系统应具有较高的可预见能力和应变能力，以及较高的成功率。为实现这个目标，其事务具有比普通实时事务更复杂的结构，本书提出了一个基于功能替代性的实时事务模型FATM（Function Alternative Transaction Model），它定义实时事务为若干任务（事务步）的集合，每个任务又由若干功能等价的子事务组成，在每个任务中取一个子事务就组成该事务的一个替代，这样，替代就成为事务调度和并发控制的基本单位。只要有一个替代成功执行，则该事务可提交，但是，一个替代夭折并不代表该事务夭折，只有当事务所有的替代都失败（或必定会超过截止期）时，该事务才夭折。功能替代性使事务的执行具有多条路径，提高了事务的适应能力和应变能力，从而提高了事务的成功率。但是，并不是每个实时事务都是可替代的，当实时事务的替代数为1时，它就退化为普通的实时事务。

事务的可替代性使事务的执行具有多条路径，提高了事务的成功率，但是，如果事务的所有替代都不能（或时间不允许）成功执行，则该事务依然要夭折。为了避免因此而引起的系统灾难，我们扩充模型FATM，使之支持补偿性，即事务由主任务和补偿任务组成，当主任务不能成功执行时由其补偿任务使之安全结束，当然，并非每个事务都是可补偿的。

事务的替代性和补偿性是互相兼容的，一个事务可能既可替代又可补偿，替代可提高事务的成功率，而补偿是在事务失败时的处理措施。

同一事务的替代虽然在功能上是等价的，但在性能上存在差异，因此，调度不同的替代投入运行，其效果是不同的，此特点导致事务的调度具有二重性：分为内部调度和外部调度。内部调度根据替代之间的性能差异，对该事务的所有可调度替代进行调度，当其结果为空时该实时事务不可调度；外部调度类似于传统的实时事务调度，其处理对象就是内部调度的结果，当事务执行失败时，不能立即夭折，必须重新转入内部调度。停止此调度活动的原因有：事务的截止期到；由特殊操作强迫停止；该事务的所有替代都失败；有一个替代成功执行。

在并发控制方面，与二重调度相匹配的是二重并发控制策略，即替代级控制和事务级控制。在替代级控制中，两个具有代表性的策略是FHC和CCCP，FHC允许一个事务的多个替代并发执行，它们是彼此相容的，主要针对于硬实时事务；CCCP在一个时刻只允许事务中的一个可调度性较强的替代执行。它们的目的都是提高实时事务的成功率，本书给出了实现方法。

所有这些调度和并发控制策略的实现依赖于正确的事务预分析，针对新的事务特点，本书明确指出事务动态执行时间和静态执行时间的区别。动态执行时间才是对实时调度更为有意义的，并结合灰色系统理论建立了估算事务动态执行时间的模型；同时，在研究替代生成、替代资源需求的基础上，分析替代的可调度性，为实时调度和实时并发控制的实施提供依据。

由于超载将导致过度的资源竞争并提高系统的控制复杂度、降低事务成功率，因此，保证系统效率和可靠性的另一个关键环节是有效的接纳控制机制。本书就此进行了深入的研究，提出了一套接纳协议和相应的策略。在抢占处理上，传统的方法是高优先级事务抢占低优先级事务，它可能抢占了一大批优先级低的事务，当这些低优先级事务的总价值更大时，系统总体收益降低。因此，我们的接纳控制机制综合考虑事务的优先级和价值。