Administration and Autonomy In A Replication-Transparent Distributed DBMS

Transcription

1 Administration and Autonomy In A Repication-Transparent Distributed DBMS Kenneth R. Abbott, Dennis R. McCarthy Computer Corporation of America Four Cambridge Center, Cambridge, MA Abstract Administrative issues are of vita importance to organizations adopting distributed database technoogy. Most research systems and emerging commercia DDBMSs have assumed site autonomy as a guiding principe. This paper presents some genera probems associated with autonomy and administration in a DDBMS, and discusses the incompatibiity between repication transparency and site autonomy. In a DDBMS which supports repication transparency, the degree of site autonomy in a system shoud propery be a poicy decision made by system administrators. Parameterization of the degree of site autonomy in a DDBMS invoves carefu design of a mechanism invoving storage structures, operations, and authorization. A mechanism which extends the ANSI SQL authorization mode is described, and exampes of how users can use the mechanism to impement both centraized and decentraized administration poicies are presented. 1. Introduction As distributed DBMS technoogy becomes more widey avaiabe in commercia systems, issues reated to administration, configuration, and operation of distributed systems are becoming increasingy important. Pragmaticay, administrative issues wi probaby be the hardest probems faced by organizations attempting to adopt distributed database technoogy. Research in distributed DBMS has focused on the probem of access to distributed data (the probem of transating and decomposing a database update or query into oca updates or retrievas at a set of communicating sites), but has not paid much attention to administration of distributed data. A few papers have discussed genera organizationa probems of administering a distributed system [] [2], but itte attention has been paid to the technica aspects of Permission to copy without fee a or pt Of this rmtaia is granted provided that the copies are not made or diiwed for direct commercia advantage, the VLDB cowright rotice cud the tite of the pubication and its date apear, md notice ir given that copying is by permission of the Very Large Data Base Endowment. To copy othexwise. or to repubish, requites a fee and/or specia permission from the Endowment. DBMS functionaity that are usefu for impementing distributed administration poicies [33. Lack of work in the area may refect a bias that administrative and operationa probems are not technicay interesting, and may aso be a consequence of the fact that the probems are not evident or important in an R&D environment where most work on distributed systems has occurred. Singe-site DBMS soutions to administrative probems have evoved but they do not readiy scae up to the distributed case for severa reasons:. Administration is compicated by fragmentation. repication, and aocation of data to sites. Cear hierarchica ines of contro at a singe site do not exist in a distributed system.. In the distributed case, operations such as resource aocation and backup/recovery decompose into distinct goba and oca components that are not distinguished in the singe-site case. As was recognized eary on in the R* project, the issue of site autonomy [4] is a semina issue for the designer of a distributed DBMS. The degree of site autonomy has a profound effect on both the data access and administrative aspects of the DBMS. R* and emerging commercia systems (Ingres/Star and Orace*) adopt site autonomy as a basic design principe. Whie the assumption of site autonomy makes sense as a basis for migrating existing centraized databases into a confederated distributed system, it affects the abiity of the system to hide distribution and repication. Furthermore, the strong identification of autonomy with sites obscures a usefu distinction between the ogica concept of autonomy and the physica concept of site. In fact, considerations of repication transparency force a distinction between ogica and physica concepts of autonomy and administration. Logica eve administrative operations such as naming, backup, and reorganization of tabes necessariy invove cooperation (and hence oss of autonomy) of sites which store repicated data. Loca, physica-eve administrative operations (such as resource aocation at a site) may be performed autonomousy even in the presence of repicated data. Proceedings of the 14th VLDB Conference Los Angees, Caifornia

2 During the design of Adapex [5], a homogeneous, repication transparent DBMS, repication transparency 1 and site autonomy were found to be antagonistic goas. The goa of fuy transparent distribution and repication of data strongy affects administrative DBMS functions as we as data access functions2. Our work on Adapex differs from other systems because we began with the assumption of repication transparency and investigated the impications of this assumption on administration and autonomy. Our approach was to parameterize the degree of autonomy in the distributed system and aow database administrators to trade-off between autonomy and repication transparency on a per-instaation basis. The key components of our pammeterized approach are:. introduction of the database storage structure (the ogica and administrative unit of autonomy) which may be mapped to physica sites in various ways, depending on the degree of site autonomy or repication transparency desired, definition of intermediate storage structures and operations which support a cear deineation between ogica eve (site-independent) administration and physica eve (site-specific) administration;. extension of the ANSI SQL authorization mecha- For the purposes of this paper, we adopt the definitions of distribution and repication transparency appied in [5]:. Users see a ogicay centraized view of the cataog (data dictionary) and the database. Names of objects share a goba namespace, and site names do not appear in object names. Users are not associated with sites. Users may og in to the DBMS and access data without regard for their ocation (ogin site) or the ocation of data.. When a user accesses a fragmented tabe, the DBMS automaticay decomposes the query into accesses to fragments of the tabe. For retrievas, the DBMS merges the resuts so that the user sees a singe, ogicay integrated tabe.. When a user accesses repicated data, the DBMS automaticay transforms the access into an access to a particuar copy of the data item at some site. On updates, the DBMS automaticay propagates and merges updates to a copies so as to maintain onecopy seriaizabiity. *It is interesting to note in this context that R* researchers originay intended to support repicated data, but eventuay abandoned the effort 161. nism to encompass these storage structures and operations Even with this fexibe approach, it is necessary to make a base assumption about the trustworthiness of the DBMS: with fu, paranoid site autonomy, the DBMS at one site never trusts the DBMS at another site. However, many agorithms and protocos for impementing transparent repication must impicity trust DBMS software at mutipe sites. Therefore, the parameterized mechanisms described here cannot achieve paranoid site autonomy (because users must trust DBMS software at remote sites) but the mechanisms can achieve functiona site autonomy (users can issue commands and perform operations just as they woud in a fuy autonomous system). In section 2, we wi motivate and enumerate some of the major technica issues in distributed database administration. In section 3, the roe of operations, storage structures, and authorization in database administration are discussed in genera terms. Section 4 describes the design of the Adapex storage structures and authorization mechanism, and section 5 gives exampes of how the Adapex mechanism can be used to impement a variety of administrative poicies. 2. Issues in Distributed Administration Techniques for administering a singe-site DBMS have become we estabished as DBMS has become an essentia eement of data processing. A key eement in administration is identification of various administrative roes and the association of various capabiities with them: DBMS operators can perform DBMS operations that reguar users can t; system administrators can do things that operators can t; etc. A common feature of singe-site administration schemes is that there is an impicit or expicit hierarchy of roes - there is usuay one roe - that subsumes a others. However, in a distributed system, roes that are bunded in the singe-site case become unraveed. Responsibiity for the ogica structure and integrity of the distributed database is a system-wide roe, whie responsibiity for detaied administration tends to be distributed to ocaized roes at individua sites [2]. What was a hierarchy in the singe-site case is better understood as a baance of powers between spheres of contro [7] scattered throughout the distributed system. Notice that a distributed system can be administered in either a centraized or decentraized fashion. However, singe-site administration techniques are not directy appicabe even in a centray administered distributed system. The foowing paragraphs summarize some of the major administrative issues which come into pay in a distributed system. 196

3 Repication Transparency vs Site Autonomy In a distributed system, it is desirabe to consider distribution and repication as physica detais of an object s representation. In the query anguage, ogica objects (e.g. tabes) are manipuated without regard for their physica representation. Repication transparency means that the user is unaware that a ogica object may be represented by mutipe physica copies. Some administrative impications of repication transparency confict with site autonomy:... Access contro - with site autonomy, sites can contro a user s abiity to access individua copies of data. This vioates transparency because a user may be abe to access some, but not a, copies of a data item, and the behavior of a query may vary depending on the copy seected. Furthermore, the DBMS cannot guarantee mutua consistency of repicated data if it cannot update a copies in an identica fashion. Operation - autonomous operation of sites can cause inconsistencies between copies of a data item. For exampe, individua copies of a data item cannot be restored from tape, because the restored copy wi be out synch with other copies. Possibe soutions (prohibiting uncoordinated restores, or forcing a sites to restore simutaneousy) vioate site autonomy. Resource aocation - physica resources such as disks are controed by individua sites. In genera, the resources at a site wi be used in a variety of appications; the distributed DBMS wi be merey one activity among many being performed at a site. The need to contro aocation of site resources to the DBMS must be baanced against the DBMS need to maintain identica copies of data at different sites. Loca View vs The Big Picture In the distributed case, there is no a-seeing, a-powerfu person with tota authority over a detais of distributed system operation. In genera, designing, impementing, and using a distributed database invoves the interaction of severa peope in different roes. For exampe, the designer of a distributed database may have the big picture** in terms of the overa ogica design (e.g. goba access paths for distributed queries, system-wide requirements for avaiabiity and recovery, etc) but cannot be expected to have the detaied knowedge of particuar sites (e.g. names of disk units, fienames, etc) necessary to impement the design. Top Down vs Bottom Up Database Design Top-down design and impementation requires centraization of authority in the database designer. The designer is responsibe for defining the ogica structure of the database and aocating and repicating data at sites. Individua sites are treated as anonymous resources to be used as the goba design dictates. Bottom-up design and impementation is done in a decentraized fashion: individua pieces of the database are independenty created at various sites, and the system administrator is responsibe for passivey reacting to decisions made ocay at sites. Bottom-up design mode is compatibe with fu site autonomy. 3. Overview of Distributed Database Administration Athough the query anguage is often considered the ony important interface to a DBMS, most vita administrative DBMS functions are not accessibe from the query anguage. Consider the case of the SQL [81 anguage, which is purey a query anguage in the sense that it deas ony with the ogica objects presented by a DBMS: tabes, indexes, authorization ids, etc. It does not address the way in which a particuar DBMS maps these abstract reationa concepts to structures or faciities provided outside the DBMS, nor does it address issues pertaining to operating the DBMS in a faiure-prone environment (viz, the rea word). Commercia DBMS s based on SQL (e.g., DB2, Orace) have extended SQL to address these administrative aspects of database management. In fact, for most commercia DBMSs, more inear feet of documentation are dedicated to administrative functions than to data access functions. From the standpoint of an organization using a DBMS, easy and reiabe administration of the DBMS may be as important as accessibiity of data in the DBMS. In this paper, we wi focus on on the foowing aspects of DBMS administration:. Resource Aocation and Utiization - The issue of resource aocation refects the need to share physica resources such as disks, tapes, processors, etc between various functions, one of which is data management. There is a need to be abe to convenienty aocate needed resources to a DBMS and to be assured that the DBMS wi not exceed its aocation. The issue of resource utiization refects a reated need to exercise fine-grained contro over how the DBMS uses particuar resources. The pacement of data on disk, in particuar, can be an extremey important factor in DBMS performance. DBMS Operation - Administering a database invoves performing many operations. Some of these 197

4 operations invove interaction with both the DBMS and the host system. Many of these operations do not directy invove ogica data objects such as tabes. Some major categories of DBMS operations are: instaation, system and site contro, routine maintenance, and recovery. 3.1 The Roe Of Storage Structures in Administration To support administrative DBMS functions, most commercia DBMSs introduce intermediate storage structures into their storage architecture (e.g. DB2 has databases, tabe spaces, and storage groups [9]; Orace has partitions, spaces, and custers,[o etc.). Administrative operations work on intermediate storage structures rather than ogica objects. In effect, intermediate structures are the objects of administrative design of the database, just as physica structure are objects of physica design. In a distributed DBMS, the issues reated to intermediate storage structures are quite compex. The mapping from ogica objects to physica storage has an additiona ayer of compexity introduced by the need to ocate data at sites. Aso, the physica representation of an object may span site boundaries. Support of fuy transparent distribution and repication of data further compicates the roe of intermediate storage structures. There are needs both for distributed intermediate structures (to faciitate administration of ogica objects - e.g. groups of reated tabes) and for ocaized structures (to faciitate pacement of data on disk at a particuar site.) 3.2 Authorization And Administration To taior the configuration of a DBMS to conform to a particuar organization s needs, an authorization mechanism is providedthis mechanism aows administrators to seectivey contro a user s abiity to access data and/or to perform administrative operations. SQL defines an authorization mechanism based on the granting and revoking of privieges on objects which is derived from the System R authorization mechanism [ 111. The SQL authorization mechanism supports access contro to data in tabes and indexes. When administrative functions are factored into a DBMS, there is a parae need to contro access to and operations on objects which are not visibe in the query anguage. To serve these needs, the basic SQL authorization mechanism must be extended [ 121. In extending the SQL mechanism, the DBMS designer must make design choices aong severa dimensions :. How are users and data identified and named for purposes of authorization [3] [ 13]? What intermediate storage structures does the DBMS provide and what primitive operations are aowed on them?. How are are various administrative roes represented for purposes of authorization? There are innumerabe subteties in design choices aong any dimension, and there are often unexpected connections between superficiay unreated design choices3 To achieve the goa of designing a fexibe mechanism that works we in many different situations, it is necessary to make compromises aong a dimensions. The measure of success is not in making the mechanism optima for any particuar appication, but in making it cose to optima for a spectrum of anticipated appications. 4. The Adapex Administrative Concepts and Mechanisms The Adapex authorization mode and mechanisms were designed to aow impementation of poicies with the foowing requirements: Aow a database designer the abiity to specify a ogica and physica design without requiring detaied knowedge of sites that may eventuay store data. Aow a naive user to perform simpe operations (e.g. CREATE TABLE without fancy options) without intervention of site or database administrators. Aow an indifferent site administrator to permit the system to pace data at the site by issuing simpe commands, without requiring knowedge of the overa database design. Aow a concerned site administrator to have fmegrained fexibiity and contro over physica pacement of data at the site, but deny him the abiity to override ogica or physica design decisions made by a database designer. Notice that it is a poicy decision (at each instaation) to aow or deny the capabiities impied by these requirements. 3 An exampe of an unexpected connection between design decisions was the discovery that impementation of protection views in R* was significanty compicated by considerations of site autonomy [14] [15]. F rotection views are objects of authorization which can be used to provide users with a restricted view of tabes which they woud not otherwise be authorized to access. 198

5 The remainder of this section is organized as foows. First we introduce a generaization of the notion of site autonomy. Then we discuss administrative roes. Finay, we describe the authorization mechanism used to impement these roes. 4.1 Storage Structures In Adapex, a database the unit of administrative autonomy. It is a sef-contained subset of the distributed DBMS with a unique system-wide name. A database encapsuates a namespace which contains tabes, users, indexes, etc. A database contains both user data and the cataogs which describe the data. Cataogs for a database are physicay repicated at every site which stores any data stored in the database. There is no hard-wired association between sites and databases: a site may store data from zero, one, or many databases. However, it is usefu the think of a database as the ogica anaog of a site, in the foowing senses: Each database contains a disjoint namespace. References from one database to another must be quaified by database name. Users are vaidated reative to a database (i.e. a user is named object within a database s name space).. Databases are decouped from each other - activity in one database cannot affect data or users in another databas. Thus the database abstracts the various ogica notions of autonomy (e.g., independent operation, separate namespace) without impications about physica representation. Using databases, users have considerabe fexibiity in configuring a distributed DBMS. If a data is paced in a singe database, then the system acts ike a ogicay centraized DBMS with a singe namespace and gobay repicated metadata. If each site is associated with exacty one database, then the system acts ike a oose federation of autonomous sites, where each site maintains its own namespace, users, and data. It is aso possibe to define intermediate configurations where mutipe databases are stored at mutipe cooperating sites. A tabe exists within a database and can be fragmented and repicated (within the containing database) as described in [5]. A copy of a fragment of a tabe is stored at a site in a pagespace, which is the Adapex intermediate storage structure that represents actua physica storage at a site. The foowing tabe summarizes the intermediate structures used to represent and store tabe and index data: The configuration of a distributed DBMS is determined by contro over pagespaces as we as by the use of databases. Sites can maintain a degree of autonomy by retaining contro over their pagespaces. To centraize database administration, sites must give up contro of pagespaces. Adapex provides fexibe contro over pagespaces through its authorization mechanism. Storage Structure Database Fragment Fragment Group Description A sef-contained environment (virtua DBMS) in which users, tabes, etc. are defmed. A database can exist at one or more sites, and a site may store one or more databases. A horizonta partition or sice of a tabe. A fragment is defined by a predicate defined on coumns within a singe tabe. A set of ogicay reated fragments which am distributed, repicated, and recovered as a unit. A set of disk pages at a site used to store fragments with simiar characteristics. A pagespace is defined in terms of host system fies, which may have been created outside of Adapex. Figure 1. A&pex Storage Structures 199

6 4.2 Administrative Roes In a centraized DBMS, the roes payed by various casses of DBMS users and operators are fairy we understood and estabished. In DB2, there is a hierarchy of roes, with the system administrator being a-seeing and a-powerfu. In a distributed DBMS, the roes are more differentiated and are no onger hierarchica. In particuar, the centraized system administrator roe bifurcates into two roes: a goba administration roe and a site administration roe [2]. The foowing ist summarizes administrative roes iden t&d for Adapex:. Goba - This roe is responsibe for managing a distributed Adapex system. The roe has compete contro over a ogica objects in the system, but does not directy contro aocation of resources at a particuar site. Responsibiities incude system-wide instaation and configuration.. Database - This roe is responsibe for a singe database. The roe has contro over a objects in the database. Responsibiities incude database design, maintenance of tabes and indexes, and fragmentation and repication of data.. Site - This roe is responsibe for managing a singe site. The roe has compete contro over physica resources at the site, but may have imited contro over the mapping of ogica structures to physica structures. Responsibiities incude site-specific instaation and configuration, creation and maintenance of oca storage structures, and oca operations. The impementor of an authorization poicy has the option of assigning mutipe administrative roes to a singe user or may choose to assign different administrative roes to different users. In the atter case, administration of the DBMS requires active cooperation among the various administrators. The authorization mechanism makes it possibe for non-cooperating administrators to effectivey veto operations that might impinge on his or her sphere of contro. For exampe, data may not be stored at a site unti the proper physica structures have been initiaized at the site. If the authorization poicy separates the site and database administration roes, then a site administrator may bock the storage of data at his site by refusing to create the requisite structures. However, if the site administrator does create the structures, the site administrator sti does not have any contro over the stored data since contro over the ogica data remains vested in the database administrator. 4.3 Authorization Mechanism The Adapex authorization mechanism is based on the ANSI GRANT/REVOKE mode [81, and is strongy infu- enced by (but not identica to) the DB2 mechanism [12]. In the simpest form of this mechanism, users perform operations on objects. A priviege is a ternary reation between a user, an operation, and an object which represents that the user is authorized to perform the operation on the object. There are numerous extensions to this basic mode, some of which have been impemented in DB2 (e.g. aggregate privieges), and some of which have been proposed (e.g. casses or groups of users [16]). Adapex provides aggregate privieges to support the administrative roes described above. Wims and Lindsay [16] briefy discusses the issue of authorization in a distributed, site autonomous system. The approach taken by Adapex differs from that approach because authorization is aso site transparent. The basic user/priviege/object mechanism has the drawback that a privieges must be attached to DBMS objects. This eads to bootstrapping probems: instaing or configuring the DBMS requires authorization, but the DBMS may not be functiona or may contain no objects. DB2 soves this probem by imprinting itsef with the host operating system id of the superuser who initiay configured the DBMS, and recognizing that id as a specia one. This technique is very awkward in the distributed case, because the same user can access the DBMS from many different sites with different host system ids. To generaize this notion, the concept of an authority was introduced. The appropriate priviege or authority is required to perform an operation. Authorities are authenticated using passwords, without reference to a database. They are hardwired into the DBMS, and cannot be granted or revoked. Adapex recognizes two authorities: system and site. System Authority corresponds to goba administrator roe. It contros addition and deetion of sites, creation and repication of databases. Site Authority corresponds to the site administrator roe. It contros oca storage structures and operations at a site. A user may gain site authority over his ogin site if he knows the password for the site. (The password for the site is stored at the site during the instaation procedure.) Notice that Adapex wi ony grant site authority to users actuay ogged in at the site. Using the site authority, privieges to perform operations on pagespaces can be granted to users in databases. In this manner, contro over oca resources can be transferred from the site administrator to a database administrator. 5. Impementing Administrative Poicies In designing the authorization mechanism, it became cear that there is an unavoidabe confict between the administrative roes described above. Site administrators want 200

7 tota contro over resources at their site; goba and database administrators want to be abe to commandeer resources from sites as dictated by the goba needs of the system. We attempt to resove this confict by division of abor and authority between administrative roes. In genera, configuring a site as part of a distributed Adapex system wi require the execution of some operations requiring authority at a site, some commands requiring authority on specific objects, and some commands requiring authority on both simutaneousy. 5.1 Site Administration When a copy of a fragment group is stored at a site, each fragment in the fragment group must be assigned to a pagespace at the site. Before the fragment group is stored, the pagespaces must be created, and the user pacing the fragments in the pagespaces must be granted privieges to use the pagespaces. A site administrator has contro over the creation and use of pagespaces at a site. Initiay, site authority is required to create a pagespace or to store a fragment in a pagespace. To retain oca contro, the site administrator creates pagespace (using site authority) and grants database administrators the priviege to store fragments in the pagespace. In this case, storing a copy of a fragment group at a site is a two stage process, with responsibiity divided between the site administrator and the database administrator. First the site administrator must create the pagespaces and grant privieges to use them. Then the database administrator stores a copy of the fragment group at the site in the pagespaces. The site administrator can veto the pacement of a fragment group at a site by refusing to set up the pagespaces. Loca contro of a site is desirabe from the standpoint of site autonomy, but is undesirabe because it requires frequent cose coaboration between database administrators and site administrators. Aternativey, the site administrator can grant privieges on the site to users in a database (that is repicated at the site). For exampe, granting the priviege to create pagespaces on the site makes it possibe for users to create pagespaces (in a singe database) at the site without expicit intervention by the site administrator. A ogicay centraized DBMS can be configured by granting privieges for site operations on a repication sites of a database to the database administrator. The database administrator then has contro over the ogica data as we as its physica pacement. 5.2 Distributed Database Design and Impementation A distributed database can be designed, impemented, and used in either a centraized fashion or a decentraized fashion. The activities of design, impementation, and use are independent in the sense that it is possibe (for exampe) to design a database centray, impement it in a decentraized manner, and use it in a centraized fashion. Since a DBMS does not usuay directy support database design (independent of impementation), in this section we focus on database impementation and usage, and describe schematicay how the authorization mechanism can accommodate both centraized and decentraized styes of administration. To iustrate how the authorization mechanism is used, we distinguish two usage modes and two resource contro modes for a distributed database. The usage modes are: 1. Interactive mode: In this mode, users can create and drop tabes and views. There is no singe database designer who has the universa view of a objects in the database. This mode of usage might occur within a department where the DBMS is used as a decision support too and ad hoc queries are common. 2. Production mode: In this mode, the schema for a database is designed and impemented specificay to support an appication. There is a database administrator for each database who has a universa view of database contents and who is responsibe for monitoring and impementing a changes to the database. This mode of usage might occur in a arge company deveoping MIS appications for in-house cients. Orthogona to the usage modes described above are resource contro modes for processors and disks in the distributed system: 1. Cooperative mode: Resources are used cooperativey and are aocated on an as-needed basis. A the resources in the distributed system are controed by the same organization, and can be used interchangeaby. This mode might correspond to a DBMS running on a sma LAN where a processors are controed by the same department in a company. 2. Autonomous mode: Resources are stricty aocated aong site boundaries and each site has strong contro over its own resources. This mode might correspond to a DBMS running a geographicay distributed network, where each site is controed by a different corporate organization. 201

8 Roe Database Site SQL User Action Create user profies in the database for a interactive users. Grant privieges to a users which aow them to create tabes, indexes, and fragment groups. At each site where data wi be stored, create defaut pagespaces and grant interactive users the privieges to pace fragment groups in the pagespaces. As desired, define new tabes and indexes. Use defaut fragmentation and repication parameters so that data is automaticay paced in &faut pagespaces created by site administrators. Figure 2. Interactive Usage/Cooperative Resource Contro Scenario The foowing scenarios are constructed by considering combinations of usage modes and resource contro modes. In a of them, it is assumed that the goba administrator has aready created a database and repicated it at a of the sites where data is to be stored. Figure 2 describes the combination of interactive and cooperative modes. In this scenario, mtive interactive use is accommodated by heavy use of defaut vaues. Database and site administrators coaborate in setting up author-ization and storage structures so that defaut mechanisms work transparenty. Figure 3 describes the combination of interactive and autonomous modes. In this scenario, interactive usage is accommodated by iberay granting privieges on ogica objects (tabes) but imiting privieges to create pagespaces to site administrators. By NOT creating defaut pagespaces, site administrators force users to be expicit in specifying physica storage. If a user wants to store data at a site, the user must get the site administrator at the site to create pagespaces and/or grant privieges on pagespaces at that site. Roe Database Site SQL User Action Create user profies in the database for a interactive users. Grant privieges to a users which aow them to create tabes, indexes, and fragment groups. When a user wants to store data at a site, the user negotiates with the site administrator, who creates a pagespace at the site and grants the priviege to pace data in the pagespace to the user (and no other user). Create tabes and expicity specifies fragmentation, repication, and creation of fragment groups. For each fragment group, repicate it at sites by expicity pacing it in the pagespace created by the site administrator. Figure 3. Interactive Usage/Autonomous Resource Contro Scenario 202

9 Roe Site Action At each site which wi store data, grant the priviege on the site to aow the database administrator to act as site administrator. Database Design the ogica schema, and determine fragmentation, fragment grouping, and pacement of fragment groups at sites. Create pagespaces at sites as needed. Create tabes, fragments, and fragment groups, and expicity pace fragment groups in previousy defined pagespaces. Grant ordinary users privieges to access the ogica objects (tabes) but not the underying pagespaces. Figure 4. Production Usage/Cooperative Resource Scenario Figure 4 describes the combination of production and cooperative modes. In this scenario, a contro over resources is centraized by granting the site administrator priviege on each site to the database administrator. By NOT granting privieges on pagespaces to users, users are prevented from creating new tabes without coaboration with the databaseadministrator. Figure 5 describes the combination of production and autonomous modes. In this scenario, the database administrator and site administrators share responsibiity for designing and impementing the database. Coaboration is forced by NOT granting privieges on sites to the database administrator. 5.3 Operationa Exampe: Backup and Recovery Even routine DBMS operations (e.g. backup, software instaation, og maintenance, etc) can be compicated by distribution, autonomy, and repication. To iustrate this point, this section uses backup and recovery operations as exampes of a basic DBMS operations that are affected by these considerations. Backup and recovery must work on fragmented, distributed, repicated, and geographicay dispersed data. The obvious impementation (mount a tape and put a the data you want on it) is unwiedy for two reasons: I Roe Databuse Site Database Action Design the ogica schema, and determine fragmentation, fragment grouping, and pacement of fragment groups at sites. In cooperation with site adminstrators, determine pagespaces required to hod fragment groups at each site. At each site, create the pagespaces agreed on with the database administrator. Grant the priviege to pace fragment groups in each pagespace to the database administrator. Create tabes, fragments, and fragment groups, and expicity pace tiagment groups in previousy defined pagespaces. Grant ordinary users privieges to access the ogica objects (tabes) but not the underying pagespaces. Figure 5. Production Usage/Autonomous Resource Contro Scenario * 203

10 . To obtain a consistent snapshot of a tabe (for exampe) may require retrieving data from fragments at remote sites. Transmission of the arge voumes of data required for backups over the network woud swamp the network and woud cause backups to take a ong time (and hence be ess ikey to compete successfuy).. If recovery is required, then the backup tape may be at a different site from the recovery site. This not ony impies the data transmission probems mentioned above, but has the operationa probem of getting the correct tape mounted at the correct time at a remote site (which may be anywhere ese in the word!). Individua sites cannot be aowed to autonomousy backup oca data, because there is no way to ensure that backups taken independenty at different sites contain a consistent snapshot of the system. This is a probem when data at one site may refer to or depend on data at another site (even in the absence of repication). Therefore, even if backup operations ony put oca data on tape, there needs to be a goba synchronization of backup operations. Simiary, recover operations must be synchronized when there are inter-site data dependencies. Furthermore, recovery of repicated data must synchronize a copies of the data, not just the copy being recovered. Adapex impements distributed backups using the readony transaction mechanism [17]. The backup operation is performed in two phases: in the goba phase, a database administrator decares a backup and gives it a name; in the oca phase, individua site administrators attach to the backup and make tapes containing oca data which is consistent with data put on tape at other sites. Internay, Adapex starts a distributed read-ony transaction when the backup is decared. This transaction reserves a consistent snapshot of the database at a sites which wi participate in the backup. When individua sites attach to the backup, data is retrieved using the read-ony transaction and put on tape. Since the database snapshot is automaticay reserved unti transaction termination, there is no need for rea-time synchronization of oca backup operations. The distributed recovery operation has a simiar two phased structure. The recover operation is first decared, and then individua sites perform oca recover operations. To guarantee mutua consistency, Adapex wi not make the ogica object being recovered accessibe unti a oca operations have successfuy competed. 6. Concusions and Areas For Future Work Before distributed DBMS technoogy can be adopted, adequate soutions must be provided for the probems of administering a distributed DBMS. Existing soutions for singe-site DBMS s do not address the compications introduced by distribution. Database administrators must dea with fragmentation and repication; there are operations that span sites and must produce consistent resuts; the hierarchy of administrative roes in a singe-site DBMS breaks down in the distributed case. Site autonomy has been proposed as a guiding principa in distributed DBMS administration, but it is incompatibe with repication transparency. We propose a generaization of site autonomy in which the database is the unit of autonomous administration. Autonomy is raised to the ogica eve; sites are treated as physica resources. This aows a range of configurations for a distributed DBMS. At one extreme, functiona site autonomy can be achieved by imposing a one-to-one correspondence between sites and databases. At the other extreme, a system can be configured to behave ike a ogicay centraized DBMS by storing a data in a singe database which is present at a sites. Intermediate configurations are possibe with varying usage modes and resource contro modes. We describe intermediate storage structures and an authorization mechanism that provide fexibiity in configuring a distributed DBMS. Areas for future work incude: i E.. Distributed Resource Contro - this paper has routine DBMS administration. It is not cear how this techniques wi work in exceptiona cases. For exampe, suppose a disk at one site overfows when appying updates to a copy of a repicated data item. There are many possibe actions the system coud take: abort a update transactions unti the condition is fixed, take the copy offine, make the ogica data item unavaiabe, etc. It is not cear what toos are needed to diagnose such probems in a distributed system, nor is it cear who is responsibe for recognizing and fixing such probems. Distributed Security - the probems of providing security in a distributed system are we known. In the absence of reiaby secure networks and trusted security kernes, it is not cear to what extent sites in a distributed system can trust each other. References J. M. Gross, P. E. Jackson, J. Joyce, and F. A. McGuire, Distributed Database Design and Administration, Distributed Databases: An Advanced Course, Draffan and Pooe, eds., Cambridge University Press, H. Waker, Administering A Distributed Database Management System, ACM-SIGMOD Record, 12~

11 r31 [41 S. Ceri and G. Peagatti, Distributed Databases: Principes and Systems, McGraw-Hi, B. Lindsay and P. Seinger, Site Autonomy Issues in R*: A Distributed Database Management System, IBM Research Report RJ2927, IBM, San Jose, CA. U WI P. Seinger and B. W. Wade, An Authorization Mechanism For a Reationa Database System, ACM-TODS, 1:3, IBM Corp., IBM Database 2 System Panning and Administration Guide, SC , IBM Corp E E A. Chart, et a, Overview of An ADA Compatibe Distributed Database Manager*, ACM-SIGMOD Proceedings, San Jose, CA, B. Lindsay, A Retrospective of R*: A Distributed Database Management System*, Proceedings of the IEEE 75.5, Bray, IRM In A Decentraized/Distributed Environment, Database Engineering, 9:2,1986. ANSI, ANSI X Database Language SQL, American Nationa Standards Institute, WI B. G. Lindsay, Object Naming and Cataog Management For A Distributed Database Manager, Proceedings 2nd Internationa Conference On Distributed Computing Systems, Paris, D. Danies, et a, An Introduction To Distributed Query Compiation in R*, Proceedings of The 2nd internationa Symposium On Distributed Databases, Berin, E. Bertino. L. M. Haas, and B. G. Lindsay, View Management in Distributed Data Base Systems, IBM Research Report RJ3851, IBM Corp., San Jose, r91 DOI IBM Corp., IBM Database 2 Data Base Panning and Administration Guide, SC , IBM Carp, Orace Corp, Orace Database s Guide, 3601-V5.0, Orace Corp., Bemont, CA, m [17 P. F. Wims and B. G. Lindsay, A Database Authorization Mechanism Supporting Individua and Group Authorization, IBM Research Report RJ3137 (38514), IBM Research, San Jose, CA, A. Chan and R. Gray, Impementing Distributed Read-Ony Transactions, IEEE Transactions on Software Engineering, SE- 1:2, February,