HP 3000 Manuals

Scalability [ TurboIMAGE/XL Database Management System Reference Manual ] MPE/iX 5.5 Documentation


TurboIMAGE/XL Database Management System Reference Manual

Scalability 
[REV BEG] 

In versions prior to C.07.00, TurboIMAGE/XL serialized the execution of
DBPUT, DBDELETE, and DBUPDATE when critical item update (CIU) is enabled,
to protect the structural integrity of the database.  This serialization
is done via a semaphore known as PUTDELETE semaphore.  This translates
into processing only one DBPUT, DBDELETE, or DBUPDATE with CIU enabled at
a time for every database.  This is acceptable for the low-end machines
but not for the high-end and multi-processor machines.  It became
imperative that TurboIMAGE/XL scale to the performance of these high-end
and multi-processor machines.  That is, TurboIMAGE/XL must increase the
throughput of the intrinsics, DBPUT, DBDELETE, and DBUPDATE with CIU
enabled, which are collectively termed modify intrinsics.  In order to
achieve this, the approach taken is to increase the concurrency of the
modify intrinsics. 

Approach in Version C.07.00 

The enhanced approach in TurboIMAGE/XL version C.07.00 (and later) is
based strictly on the database design and is optional.  By default,
TurboIMAGE/XL continues to work the way it did in versions prior to
C.07.00.  For the revised approach, the database is internally grouped by
TurboIMAGE/XL into independent sub-databases based on physical
linkages/relationships or dependency of master and detail data sets.  In
addition, it uses multiple semaphores as well as a specific criteria to
lock the necessary semaphores for a sub-database.  The result is that the
modify intrinsics can execute concurrently for these independent
sub-databases.

In brief, the criteria pertaining to semaphores is as follows:

   1.  Assign ONE semaphore for each data set.

   2.  When modifying a master set, lock only the semaphore for this
       master.

   3.  When modifying a detail data set, lock the semaphore for the
       detail as well as all its related master sets, manual as well as
       automatic.  This can result in locking 1 (minimum, standalone
       detail) up to 17 (maximum, 1 + 16) semaphores.

To illustrate this, look at the following diagram:
___________________________________________________________________________________
|                                                                                 |
|          ------   ------        ------                  ------   ------  ------ |
|          \ M1 /   \ M2 /        \ M3 /                  \ M4 /   \ M5 /  \ M6 / |
|           \  /     \  /          \  /                    \  /     \  /    \  /  |
|            \/       \/            \/                      \/       \/      \/   |
|                     .             . .                     .        .       .    |
|                     .             .   .                   .       .  .     .    |
|                     .             .     .                 .      .     .   .    |
|                     .             .       .               .     .       .  .    |
|      --------     --------       --------  --------       --------      --------|
|      \  D1  /     \  D2  /       \  D3  /  \  D4  /       \  D5  /      \  D6  /|
|       \    /       \    /         \    /    \    /         \    /        \    / |
|        ----         ----           ----      ----           ----          ----  |
|                                                                                 |
|                                                                                 |
___________________________________________________________________________________

          Figure 10-5.  Independent Sub-Databases for Concurrency 

In the above diagram, the independent sub-databases are:

   1.  M1
   2.  D1
   3.  D2 and M2
   4.  D3 and M3
   5.  D4 and M3
   6.  D5, M4 and M5
   7.  D6, M5 and M6

There are several different scenarios when concurrent modifications can
be in progress.  For example:

M1            at all times as there is no dependency.

D1            at all times as there is no dependency.

Other         M2, M3, M4, M5, and M6 if the depending detail is not being
masters       modified.

Other         D2, D3 or D4, and D5 or D6.  This is if the dependent
details       master(s) are not being modified.  Note that both D3 and
              D4, or D5 and D6 cannot be concurrently modified.

Based on this approach, the throughput is dependent on the number of
sub-databases, the more, the better.  The worst case is a database which
can be sub-divided into only one sub-database.  For example, one detail
linked to 16 masters.  The best case is when there are several
stand-alone masters or details.

With this approach, some databases may benefit in throughput and some may
not.  Therefore, by default, TurboIMAGE/XL continues to work the way it
did in versions prior to C.07.00.

To use this enhancement, your database must be activated to use the
Dependency Semaphore.  To achieve this, use the option, DSEM, with the
ENABLE command of DBUTIL. The default for DSEM is DISABLED.

New syntax: 

EN[ABLE] database name[/maint word] FOR DSEM

DI[SABLE] database name[/maint word] FOR DSEM

After enabling your database for DSEM, if you feel that your database
cannot benefit by using this feature, you may DISABLE it.
[REV END]



MPE/iX 5.5 Documentation