I n earlier versions, a n Rdb(VMS database was con stra ined ro a single VMS fi l e . The bound vol ume ser capab il ity of the VMS system al lowed the fi l e to be striped across several d isks. Howeve r , data striping was not enough ro distribute the 1/0 operations over a large number of d isks. The result was performance bottlenecks (ca l led the 1/0 bottleneck) , since the database system performance was li m i ted by rhe 1/0 transfer rate of a single disk.
As noted earlier, one of the goals of the Rd b/VMS project was tO give t he DllA com plete control over the p lacement of data files on d isks. With this new version , a DllA can exploit the structuring capab i l i ties to e l i m inate the 1/0 bottleneck. This feature does, however , requ i re carefu l physical design and fi le p lacement at database design r i m e .
Storage Technology
COR PORATE DATABASE
Figure 5 Portition ing a Relation
A darabase can consist of several VMS fi les , cal led storage areas . Each storage area can be in depen dently assigned to a single disk. Srorage areas can be mapped to disks (or bound vol u me sets) at the phys ica l design stage . This mapping is referred to as the mu ltifile database capabi l ity.
A storage area ca n conta in database relat ions or ind ices or both. It is possible to store more than one re lation per srorage area . For this reason, t he Rdb/VMS software mai nta i ns space-management data struc tures, ca l led SPMv! pages, wh ich can be used to accel erate sequential scans on relations . SPAN! pages ma intain i n formation about free space in the storage area. In addition. SPAM pages can be used to deter m i ne whet her a certain page conta i ns records belongi ng to a speci fied relation . The proper design of S PAlvl pages and associated a lgorithms is critica I to ensure that these pages do not become a hot spot during periods of high update activity.
To fu rther al leviate the 1/0 bottleneck, RdbfYMS software a lso a l l ows partitioning of re lations and i nd ices over several storage areas as exp lai ned be low.
There are rwo options for part i tioning a re l ation.
Rclb/ViVIS software can u n i forml y spread the records of the relation over several storage areas by using a randomizing fu nction . This type of partitioning is use h.d when user transactions access s i ngle records in the re lation . Howeve r, Rdb/VMS does not a l l ow an i ndex ro be part i tioned in this manner.
The second way to partit ion t he relation is by specifyi ng a partition i n g pred icate. For example.
10 4
cons ider the Employees rehuion in Figure .:) Ass ume there are three storage areas over wh ich we wish to spread the Employees re lat ion . As i l l ustrated i n Figure '5 , w e can spec ify a part ition i ng predicate to i ndicate that e m p l oyee records with va l ues of EMP_ I D less t han LOOOO are pl aced i n the first stor age area; records ·with val ues between 1000 1 and '50000 a rc p laced in the second storage area: and records with values greater than '50000 are placed in t he t h i rd srorage area . The parti tion ing pred icate must specify disjoint panitions of data so that e\cry data record is a l lowed to exist in at most one parti tion . This type of part itioni ng is particu l a r l y usefu l in cases \\' here users ' access to the data records retlccrs the part itioni ng criteria . This tec hnique can also be used ro part ition i nd ices. The multifi l e and part ition ing capabil ities of Rdbf\'.'viS software guar antee that no sing le d isk can become an 1/0 bo ttle neck duri ng database activity .
The part ition i ng of relat ions over several storage areas a lso i ntroduces an add it ional l eve l of loc k i n g granu larity . I f a transaction J ocks only one part i t ion of the re lation , concu rrent access ro other part i t ions is possible. The opti m izer uses this property to allow a h igher leve l of concurrency for transactions t hat access d i fferent part itions.
The structu ri ng and parti t ioni ng of the re l at ions require carefu l �ment ion d u r i ng the ph\'sical data base design phase . Proper design can result in an order of magnitude i m prove me nt in execut ion per formance for a majority of queries . lt is a lso i m por-
rant ro nore that the multifile and partitioning fea rtJres are optional ; users who are satisfied with the performance of the earl ier versions can continue to use the new version of RdbjVMS software w ithout any performance degradation or DBA effort.