At present more and more industrial applications interacts in real time. Some of them are manipulating with large amounts of information. So they need in realtime databases and appropriate transaction handling. There is a wide area of industrial applications concerned with process control and SCADA systems which need in specialized real-time database servers. These systems have some distinctive features such as:
-lifecycle is divided into two parts -design-time and work time;
-database clients have limited subset of SQL query templates, and these templates are constant in worktime part; -sensor and system transactions have different static priorities which reflects subsequent transaction semantics;
-user transactions usually takes much longer time then sensor and system ones;
These features exert influence on transaction handling of Real-Time Database Management System (RT DBMS) used with SCADA system. Traditional works on RT DBMS scheduling policies considers transaction and data consistency taking into account only transaction deadlines and data deadlines. We propose new transaction handling policy which takes into account transaction flow irregularity represented by different static transactions priorities.
Another problem is that some critical (high-priority) sensor or system transactions fails due-to long user query transactions are executed on database server. We decided to use the mechanism of precompiled materialized views for remote database clients. Although influence of materialized views on system performance is not investigated in this paper materialized views management subsystem is the part of client system architecture.
In this paper we describe Soft Real-Time DBMS prototype architecture which implements model for investigating transaction handling policies. In performance evaluation distributed system is used to minimize influence clients (transaction generators) on database server performance.
There are a lot of works concerned with transaction handling policies so we will mention only papers which results have influenced on this work. Common transaction handling aspects in Real-Time DBMS were considered in [1,2,4]. Issues with Timing constraints were described in [3]. Works [5] and [6] are concerns with practical implementation of real-time transaction handling. Real-Time DBMS peculiarity is that research in this area tightly correlated with investigations in area of temporal and active database management systems. Survey on active databases represented in [7] while temporal DBMS is fully described in [8]. During developing query subsystem we investigated commonly used query optimization techniques (represented in [9]). Modern line of investigations in multi-query optimizations which used in materialized views support subsystem represented in [10].
Supported transaction model is based on composite transactions which can be divided into subset of microtransactions (atomic transactions such as add row, modify row, etc.). If atomic transaction fails all composite transaction is being revoked.
Transaction taxonomy represented in Figure 1 -dedicated server -RT DBMS server which handles clients requests -transaction generator -this application emulates clients activity and combines pure transaction generator with RT DBMS server to handle queries to materialized views (materialized views influence is not evaluated in this paper).
Both application types are based on common system architecture represented in illustration below (Figure 2). Main components are: Network Manager, Transaction Decomposer, Query Manager, Priority Manager, Transaction Scheduler, Transaction Pool and DBobjects Manager
Network Manager handles all communication between current server and over applications. Communication is based on own protocol, which supports control packets and transaction packets. This protocol is datagram protocol based upon UDP protocol. Network Manager stores its own settings (clients/servers map, datagram resend policy etc) in XML configuration file which can be loaded from the disk or sent throw the LAN by using special control packet.
Transaction decomposer receives waiting transaction from the Network Manager queue, decomposes transaction into atomic transactions and passes microtransactions subset either to Query Manager (for user queries) or to Transaction Scheduler queue.
Query manager handles composite correlated transactions which represents compiled SQL queries. The main purpose of query manager is to reconstruct logical query plan represented as DAG (Directed Acyclic Graph) and to transform it to appropriate physical DAG based on db-objects or materialized views.
Priority Manager is a class which implements all necessary methods for building dynamic transaction priority. By changing special tuning parameters it can handle priorities using one of scheduling policies.
Transaction scheduler is component which handles all atomic transactions sets and assigns them into unoccupied threads from transaction thread pool. Transaction Scheduler has special thread used for synchronization -all scheduling actions are performed within this thread to avoid resource management deadlocks.
All atomic transaction sets are waiting for their assignment in queue. In each scheduling step Transaction Scheduler checks this queue for failed transactions to return failed transaction back to the client.
When assigning transaction to the thread Transaction scheduler uses priority returned by Priority Manager in compliance with current transaction handling policy.
Transaction Pool is a set of threads capable of transaction executing. When transaction is assigned to the subsequent thread this thread locks object need for the first atomic transaction in the set. For locking Db object two-phase locking method used. First Lock is made by synchronization thread of Transaction Scheduler and second phase is performed by transaction executing thread. In execution step transaction is checked for data consistency and is aborted if deadline or data-deadline achieved. So all the transaction scheduling policies has data consistency check, but -DC suffix is omitted.
Objects Manager is the component which represents In-Memory database. It supports the following object types: tables; indexes (B-tree index); hashes; materialized views;
All objects represented in block-list (or paged) structure. Access to each object can be locked on pagelevel. Each object has a set of temporal attributes used in priority handling. Let X is object in RT DBMS then it has the following attributes:
LUT(X) -last update time of the X object -this time is calculated automatically by system; RVI(X) -relative validity interval -this value is set to each object at the design time. It represents time interval in which object keeps its validity; ) (X AVI -Absolute Validity Interval is the time interval which can be calculated as follows:
[ ]
All transaction handling (scheduling) policies are based on transaction model represented in (1), temporal object properties LUT(X), RVI(X), AVI(X) and a subset of dynamic transaction properties described below.
-transaction deadline is defined as follows:
) ), ( min( ) (
-data deadline depends on temporal object properties:
-estimated execution time is the function which depends on transaction type, transaction data and object statistics.
-execution transaction time is defined as follows::
where () now -special temporal function which returns current system time.
-slack factor is a parameter which takes into account estimated amount of time to transaction deadline. Slack factor is defined as follows:
(
) 6)
-proposed function which combines traditional priority handling policies (EDF, EDDF, LSF). We define this function as :
where ( )
(8) -priority handling function which combines EDF and EDDF policies is defined as:
)
Parameters α and µ are tuning parameters and used to handle which policy should be used at current moment.
To include semantic priority to this policy combining functions we introduce priority comparison function c PR defined as: ( )
As result we have a set of functions which can be used to combine different transaction handling policies at the same time by using tuning parameters Here α is defined as: , parameters α and µ , depends on secondary temporal policy. This policy could be used in systems which have a variety of transaction types with different semantic priorities.
Performance evaluation in this paper is devoted to comparison of proposed SPF policy with EDF and LSF policies. All policies are used with data consistency check, so we omit -DC suffix.
Experiment system has two PC connected through 100 Mbit Ethernet. One PC was used for dedicated server and another one for transaction generator. Dedicated server had test database with 20 tables (each table with 10000 rows, RVI(X)=100ms). Server had transaction pool with 10 threads. Transaction generator had 10 generation threads each generates 2 transactions (with static priority 100 and 500) per time. Generation period varies from 10 to 300 ms. Generated transactions are uniformly distributed within generation period. Relative validity interval for transaction data is rvi t =40ms. Each generated transaction contains 1000 atomic transactions of ModifyRow type.
For each generation period there was 10 test with 1000 transactions generated. After each test application was reloaded. For each test average miss ratio was calculated (miss ration = failed count / total count) and average miss ratio for high-priority (500) and lowpriority (100) transactions. Tables 1 and 2 contain performance evaluation results for each policy represented with total miss ratio (Table 1) and miss ratio for high-priority transactions (Table 2). Figure 3 contains appropriate diagram.
From the results we can see that total SPF miss ratio is higher then total miss ratio for EDF and LSF, but miss ratio for high-priority transactions is much better in comparison with EDF and LSF. So SPF policy can be used to minimize high-priority transactions missratio. To decrease low-priority transactions miss ratio in distributed environment client-side materialized views could be used. This approach was approved in SQL manager implementation (with earlier SPF policy version [12]) for SCADA KRUG-2000 DB Server [11]. Another direction of further experiments is investigating of materialized views using influence on common system performance. This work is concerned with tuning parameters and scheduling policy for clientside server, which handles materialized views. And as final part we propose the experiments on computational system which simulates real SCADA system with appropriate database structure and hosts configuration.