1 / 51

DISTRIBUTED DATABASES

DISTRIBUTED DATABASES. Dr. Awad Khalil Computer Science Department AUC. Content. DBMS Architectures Functions of DDBMS Generic DDBMS Architecture Data Fragmentation Data Allocation Data Replication Query Processing Concurrency Control and Recovery. Distributed Computing Systems.

gayle
Télécharger la présentation

DISTRIBUTED DATABASES

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DISTRIBUTEDDATABASES Dr. Awad Khalil Computer Science Department AUC Distributed Databases, by Dr. Khalil

  2. Content • DBMS Architectures • Functions of DDBMS • Generic DDBMS Architecture • Data Fragmentation • Data Allocation • Data Replication • Query Processing • Concurrency Control and Recovery Distributed Databases, by Dr. Khalil

  3. Distributed Computing Systems • Distributed databases bring the advantage of distributed computing to the database management domain. • A Distributed Computing System consists of a number of processing elements, not necessarily homogeneous, that are connected by a communications network and that are cooperate in performing certain assigned tasks. • A Distributed Database is a collection of multiple logically interrelated databases distributed over a computer network. • A Distributed Database management System (DDBMS) is the software system that manages a distributed database while making the distribution transparent to the user. Distributed Databases, by Dr. Khalil

  4. Parallel Versus Distributed Technology • There are two main types of multiprocessor system architecture that are commonplace: • Shared memory (tightly coupled) architecture: Multiple processors share disk storage and also share main memory. • Shared disk (loosely coupled) architecture: Multiple processors share disk storage but each has their own main memory. • DBMSs developed using the above types of architectures are termed Parallel DBMSs rather than DDBMS, since they utilize parallel processor technology. • In shared nothing architecture, every processor has its own main and secondary (disk) memory, and the processors communicate over a high-speed interconnection network (bus or switch). Distributed Databases, by Dr. Khalil

  5. DBMS Architectures • Centralized DatabaseThe database is stored at a single computer site. A centralized DBMS can support multiple users, but the DBMS and the database themselves reside totally at a single computer site. • All system component are accessed remotely via terminals to it but all processing is done centrally. Distributed Databases, by Dr. Khalil

  6. DBMS Architectures • Shared Nothing Architecture Every processor has its own main and secondary (disk) memory, and the processors communicate over a high-speed interconnection network (bus or switch). Distributed Databases, by Dr. Khalil

  7. DBMS Architectures • LAN-based File Server Networked small computers (PCs) share data (and other resources). Each has its own software (such as DBMS). One PC is designated as the file server where the shared database is stored. Distributed Databases, by Dr. Khalil

  8. DBMS Architectures • Truly Distributed Database Architecture The actual database and DBMS software are distributed over many sites, connected by a communications network. Distributed Databases, by Dr. Khalil

  9. System Architectures • Traditional two-tier Client-Server Architecture • Three-tier architecture Distributed Databases, by Dr. Khalil

  10. Traditional two-tier Client-Server Architecture • Data-intensive business applications consist of four major components: • the database, • the transaction logic, • the application logic, and • the user interface. • The traditional two-tier client-server architecture provides a basic separation of tasks. • The client (tier 1) is primarily responsible for the presentation of data to the user, • The server (tier 2) is primarily responsible for supplying data services to the client. Distributed Databases, by Dr. Khalil

  11. Traditional two-tier Client-Server ArchitectureProblems !! • The need for enterprise scalability challenged the traditional two-tier client-server model. In the mid-1990s, as applications became more complex and potentially could be deployed to hundreds or thousands of end-users, the client side presented two problems that prevented true scalability: • A “fat” client, requiring considerable resources on the client’s computer to run effectively. This includes disk space, RAM, and CPU power. • A significant client-side administration overhead. Distributed Databases, by Dr. Khalil

  12. Three-tier Architecture • By 1995, a new variation of the traditional two-tier client-server model appeared to solve the problem of enterprise scalability. This new architecture proposed three layers, each potentially running on a different platform: • The user interface layer, which runs on the end-user’s computer (the client). • The business logic and data processing layer. This middle tier runs on a server and is often called the application server. • A DBMS, which stores the data required by the middle tier. This tier may run on separate server called the database server. Distributed Databases, by Dr. Khalil

  13. Three-tier Architecture – Advantages !! • The “thin” client, which requires less expensive hardware. • By centralizing the business logic for many end-users into a single application server, application maintenance is centralized. This eliminates the concerns of software distribution that are problematic in the traditional two-tier client-server model. • The added modularity makes it easier to modify or replace one tier without affecting the other tiers. • Separating the core business logic from the database functions makes it easier to implement load balancing. • The three-tier architecture maps quite naturally to the Web environment, with a Web browser acting as the “thin” client, and a Web server acting as the application server. Distributed Databases, by Dr. Khalil

  14. Distributed Databases - Definition • A distributed database: is a collection of data that belongs logically to the same system but is physically spread over the sites of a computer network. Distributed Databases, by Dr. Khalil

  15. Distributed Databases - Functions • Location Transparency: A user can submit a query that accesses distributed objects without having to know where objects are. • Performance Transparency: A query can be submitted from any node in a distributed DBMS and it will run with comparable performance. • Copy Transparency: The system supports the optional existence of multiple copies of database objects. • Transaction Transparency: A user can run an arbitrary transaction that updates data at any number of sites, and the transaction behaves exactly like a local transaction and atomicity is maintained. • Fragmentation Transparency: A relation (class) can be divided into multiple sites according to specified distribution criteria. • Schema Change Transparency: A user who adds or deletes a database object from a distributed database need make the change only once and does not need to change the catalog at all sites. • Local DBMS Transparency: The distributed database system provides services without regard for what local systems are actually managing local data. Distributed Databases, by Dr. Khalil

  16. An Example Distributed Databases, by Dr. Khalil

  17. Additional required Functions • The ability to access remote sites and transmits queries and data among the various sites via a communication network. • The ability to keep track of the data distribution and replication in the DDBMS. • The ability to devise execution strategies for queries and transactions that access data from more than one site. • The ability to decide on which copy of a replicated data item to access. • The ability to maintain the consistency of copies of a replicated data item. • The ability to recover from individual site crashes and from new types of failures such as the failure of a communication link. Distributed Databases, by Dr. Khalil

  18. Potential Advantages • Distributed nature of some database applications. • Increase reliability and availability. • Reliability: is broadly defined as the probability that a system is running (not down) at a certain time point. • Availability: is the probability that a system is continuously available during a time interval. • Allowing data sharing while maintaining some measure of local control. • Improved performance. • Modular growth. • Lower communication costs Distributed Databases, by Dr. Khalil

  19. Cost • Software cost and complexity. • Processing overhead. • Data integrity. • Slow response. Distributed Databases, by Dr. Khalil

  20. Generic DDBMS Architecture • A DDBMS is required to perform the following functions: • Determine the location(s) from which to retrieve requested data. • If necessary, translate the request at one node using a local DBMS into proper request to another node using a different DBMS and data model. • Provide data management functions such as security, concurrency and deadlock control, query optimization, and failure recovery. Distributed Databases, by Dr. Khalil

  21. Generic DDBMS Architecture • In a DDBMS environment each site has a local DBMS that manages the database stored at that site. • Also, each site has a copy of the distributed DBMS and the associated distributed data dictionary/directory (DD/D). • The distributed DD/D contains the location of all data in the network, as well as data definitions. • Requests for data by users or application programs are first processed by the distributed DBMS, which determines whether the transaction is local or global. • A local transaction is one in which the required data are stored entirely at the local site. • A global transaction requires reference to data at one or more non-local sites to satisfy the request. For local transactions, the DDBMS passes the request to the local DBMS; for global transactions, the DDBMS routes the request to other sites as necessary. • The DDBMSs at the participating sites exchange messages as needed to co-ordinate the processing of the transaction until it is completed (or aborted if necessary). This process may be quit complex. Distributed Databases, by Dr. Khalil

  22. Generic DDBMS Architecture • The generic DDBS architecture is based on the following components: • DDBS Global Language: Most DDBS have a global language for communication between nodes, this includes; message protocols; languages and formats for specifying queries; responses; and errors. Nodes need to translate to this language. Global language consists of: Data Definition Language – defines the description of objects, and Data Manipulation Language – manipulates queries. One global language therefore only one kind of translator. Without this global language would need a translator to and from every other language in the system. • DDBS Nucleus: is responsible for co-ordination and control. The nucleus has to verify the initiator of the query is authorized to access the distributed database, or part of it, and check for bugs. It also has to perform query decomposition, as a logical unit (relation) may be distributed over several nodes using a distributed data dictionary to produce the sub-queries. Query optimization is also performed by the nucleus. The DDBS nucleus also has a message distribution module that is responsible for creating a DDBS message for each sub-query, and creating message log information for control purposes when sub-responses (responses to sub-queries) are received back. When all responses have been received or a time limit has been reached then the appropriate information will be passed onto the response composition module. Response composition module produces a single global response. The nucleus may be completely centralized (global node). Alternatively, the functions of the global node are distributed amongst all the query nodes. Distributed Databases, by Dr. Khalil

  23. Generic DDBMS Architecture • DDBS Interface: is responsible for the mapping and translation software. The interfaces between the local DBMS and the global DBMS are: • Query Interface: It is the interface at the user/application end. Users express the query in external query language (SQL) which may be the language of the local DBMS or a special DDBS query language. This is translated by the external/global query translation module to the global language. • Data Interface: Translates from global to local language (may be SQL). The query is processed in the normal way by DBMS and a local response will be the result. Distributed Databases, by Dr. Khalil

  24. Data Fragmentation Techniques • In a DDBS, decision must be made regarding which site should be used to store which portions of the database. The simplest logical units of a database that can be distributed are the relations themselves. There are several fragmentation techniques: • Horizontal Fragmentation: A horizontal fragment of a relation is a subset of the tuples in that relation. The tuples that belong to the horizontal fragment are specified by a condition on one or more attributes of the relation. A set of horizontal fragments whose conditions C1, C2, ..., Cn include all the tuples in R - which is, every tuple in R satisfies (C1 OR C2, OR ... OR Cn) - is called a complete horizontal fragmentation. In many cases a complete horizontal fragmentation is also disjoint; that is, no tuple in R satisfies (Ci And Cj) for any i <> j. To reconstruct the relation R from a complete horizontal fragmentation, we need to apply the UNION operation to the fragments. Distributed Databases, by Dr. Khalil

  25. Data Fragmentation Techniques • Vertical Fragmentation: A vertical fragment of a relation keeps only certain attributes of the relation. A set of vertical fragments whose projection lists L1, L2, ..., Ln include all the attributes in R but share only the primary key attribute of R is called a complete vertical fragmentation of R. In this case the projection lists satisfy the following two conditions: • L1  L2  ... Ln = ATTRS(R). • Li  Lj = PK(R) for any i <> j, where ATTRS(R) is the set of attributes of R and PK(R) is the primary key of R. • To reconstruct the relation R from a complete vertical fragmentation, we apply the OUTER UNION operation to the fragments. We could also apply the FULL OUTER JOIN operation and get the same result for a complete vertical fragmentation. Distributed Databases, by Dr. Khalil

  26. Data Fragmentation Techniques • Mixed Fragmentation: The horizontal and vertical fragmentations can be intermixed to yield a mixed fragmentation. In this case the original relation can be reconstructed by applying UNION and OUTER UNION (or OUTER JOIN) operations in the appropriate order. Distributed Databases, by Dr. Khalil

  27. Data Fragmentation Techniques • In general, a fragment of relation R can be specified by a SELECT-PROJECT combination of operations L(C(R)). • If C = True and L <> ATTRS(R), we get a vertical fragment. • If C <> True and L = ATTRS(R), we get a horizontal fragment. • If C <> True and L <> ATTRS(R), we get a mixed fragment. • A relation can itself be considered a fragment with C=True and L= ATTRS(R). Distributed Databases, by Dr. Khalil

  28. Fragmentation & Allocation Schemas • A fragmentation schema of a database is a definition of a set of fragments that includes all attributes and tuples in the database and satisfies the condition that whole database can be reconstructed from the fragments by applying some sequence of OUTER UNION (or OUTER JOIN) and UNION operations. • An allocation schema describes the allocation of fragments to sites of the DDBS; hence, it is the mapping that specifies for each fragment the site(s) at which it is stored. If a fragment is stored at more than one site, it is said to be replicated. Distributed Databases, by Dr. Khalil

  29. Data Replication & Allocation Why replication ? • Replication is useful in improving the availability of data. Distributed Databases, by Dr. Khalil

  30. Replication Levels • Fully Replication: The most extreme case is replication of the whole database at every site in the distributed system, thus creating a fully replicated distributed database. This can improve availability remarkably because the system can continue to operate as long as at least one site is up. It also improves performance of retrieval for global queries, because the result of such a query can be obtained locally from any one site. The disadvantage of full replication is that it can slow down update operations drastically, since a single logical update must be performed on every copy of the database to keep the copies consistent. • No Replication: Each fragment is stored at exactly one site. In this case all fragments must be disjoint, except for the repetition of primary keys among vertical (or mixed) fragments. • Partial Replication:Some fragments ofthe database may be replicated whereas others are not. The number of copies of each fragment can range from one up tothe total number of sites in the distributedsystem.A description of the replication of fragments is called areplication schema. Distributed Databases, by Dr. Khalil

  31. An Example Assumptions: • The company has three computer sites - one for each current department. • Site 1 is used by the company headquarters and accesses all employees and project information regularly, in addition to keeping track of DEPENDENT information for insurance purposes. • Sites 2 and 3 are for departments 5 and 4, respectively. At each of these sites we expect frequent access to the EMPLOYEE and PROJECT information for the employees who work in the department and the projects controlled by that department. Further, we assume that these sites mainly access the NAME, SSN, SALARY, and SUPERSSN attributes of EMPLOYEE. Distributed Databases, by Dr. Khalil

  32. Fragmentation Schema • The whole database can be stored at site 1. • To determine the fragments to be replicated at sites 2 and 3, we can first horizontally fragment the EMPLOYEE, PROJECT, DEPARTMENT, and DEPT-LOCATIONS relations by department number. We can then vertically fragment the resulting EMPLOYEE fragments to include only the attributes {NAME, SSN, SALARY, SUPERSSN, DNO}. The resulting mixed fragments are referred to as EMPD5 and EMPD4, which include the EMPLOYEE tuples satisfying the conditions DNO = 5 and DNO = 4, respectively. The horizontal fragments of PROJECTS, DEPARTMENT, and DEPT_LOCATIONS are similarly fragmented by department number. All these fragments - stored at sites 2 and 3 - are replicated because they are also stored at the headquarters site 1. • We must now fragment the WORKS_ON relation and decide which fragments of WORKS_ON to store at sites 2 and 3. The problem is that no attribute of WORKS_ON directly indicates the department to which each tuple belongs. In fact, each tuple in WORKS_ON relates an employee e to a project p. We could fragment WORKS_ON based on the department d in which e works or based on the department d that controls p. Distributed Databases, by Dr. Khalil

  33. Fragmentation Schema • Complete and disjoint fragments of the WORKS_ON relation. • (a) Fragments of WORKS_ON for employees working in department 5 (C=ESSN IN (SELECT SSN FROM EMPLOYEE WHERE DNO=5)). • (b) Fragments of WORKS_ON for employees working in department 4 (C=ESSN IN (SELECT SSN FROM EMPLOYEE WHERE DNO=4)). • (c) Fragments of WORKS_ON for employees working in department 1 (C=ESSN IN (SELECT SSN FROM EMPLOYEE WHERE DNO=1)). • The union of fragments G1, G2, and G3 gives all WORKS_ON tuples for employees who work for department 5. • The union of fragments G4, G5, and G6 gives all WORKS_ON tuples for employees who work for department 4. • The union of fragments G1, G4, and G7 gives all WORKS_ON tuples for projects controlled by department 5. • The union of fragments G2, G5, and G8 gives all WORKS_ON tuples for projects controlled by department 4. Distributed Databases, by Dr. Khalil

  34. Allocation Schema Site 2 We choose to include all fragments that can be joined to either an EMPLOYEE tuple or a PROJECT tuple at sites 2 and 3. Hence, we place the union of fragments G1, G2, G3, G4, and G7 at site 2. Distributed Databases, by Dr. Khalil

  35. Allocation Schema Site 3 • We choose the union of fragments G4, G5, G6, G2, and G8 at site 3 (G2 and G4 are replicated at both sites). Distributed Databases, by Dr. Khalil

  36. Degree of Homogeneity Homogeneous DDBMS: all servers (or individual local DBMSs) use identical software and all clients use identical software. Heterogeneous DDBMS: Servers and clients use different software. In a heterogeneous multidatabase system, one server may be a relational DBMS, another a network DBMS, and a third a hierarchical DBMS; in such a case it is necessary to have a canonical system language and to include language translators in the client to translate subqueries from the canonical language to the language of each server. Degree of Local Autonomy No Local Autonomy: all access to the DDBMS must be gained through a client. A DDBMS looks like a centralized DBMS to the user. A single conceptual schema exists, and all access to the system is obtained through a client. Local Autonomy: direct access by local transactions to a server is permitted. Such type of DDBMS is called federated DDBMS (or a multidatabase system). In such a system, each server is an independent and autonomous centralized DBMS that has its own local users, local transactions, and DBA and hence has a very high degree of local autonomy. Each server can authorize access to particular portions of its database by specifying an export schema, which specifies the part of the database that may be accessed by a certain class of nonlocal users. A federated system is a hybrid between distributed and centralized systems; it is a centralized system for local autonomous users and a distributed system for global users. Types of Distributed Database Systems Distributed Databases, by Dr. Khalil

  37. Degree of Distribution Transparency High Degree of Distribution Transparency: the user sees a single integrated schema without any information concerning fragmentation, replication, or distribution. No Distribution Transparency: the user sees all fragmentation, allocation, and replication. The user must refer to specific fragment copies at specific sites when formulating a query, by appending the site name before a relation or fragment name. This is a part of a complex problem of naming in distributed systems. Types of Distributed Database Systems Distributed Databases, by Dr. Khalil

  38. Query Processing in Distributed Databases Data Transfer Costs • In a distributed system, the transfer of data over the network is considered an important factor affecting the processing and optimization of a query. • This data includes intermediate files that are transferred to other sites for further processing, as well as final result files that may have to be transferred to the site where the query result is needed. • DDBMS query optimization algorithms consider the goal of reducing the amount of data transfer as an optimization criterion in choosing a distributed query execution strategy. Distributed Databases, by Dr. Khalil

  39. Example • Suppose that the EMPLOYEE and DEPARTMENT relations are stored in site 1 and site 2, respectively and neither relation is fragmented. The size of the EMPLOYEE relation is 100 * 10,000 = 1,000,000 bytes, and the size of the DEPARTMENT relation is 35 * 100 = 3500 bytes. Distributed Databases, by Dr. Khalil

  40. Q1 Consider that the query is submitted at a distinct site 3: “For each employee, retrieve the employee name and the name of the department for which the employee works.” The result of this query will include 10,000 records, assuming that every employee is related to a department. Suppose that each record in the query results in 40 bytes long. If minimizing the amount of data transfer is our optimization criterion, we should choose strategy 3. Transfer both the EMPLOYEE and the DEPARTMENT relations to the result site, and perform the join at site 3. In this case we need to transfer a total of 1,000,000 + 3500 = 1,003,500 bytes.  Transfer the EMPLOYEE relation to site 2, execute the join at site 2, and send the result to site 3. The size of the query result is 40 * 10,000 = 400,000 bytes, so we must transfer 400,000 + 1,000,000 = 1,400,000 bytes.  Transfer the DEPARTMENT relation to site 1, execute the join at site 1, and send the result to site 3. In this case we have to transfer 400,000 + 3500 = 403,500 bytes. Example Distributed Databases, by Dr. Khalil

  41. Q2 Consider that another query is submitted at site 3: “For each department, retrieve the department name and the name of the department manager.” There are three simple strategies for executing this distributed query. Again, we would choose strategy 3. Transfer both the EMPLOYEE and the DEPARTMENT relations to the result site, and perform the join at site 3. In this case we need to transfer a total of 1,000,000 + 3500 = 1,003,500 bytes.  Transfer the EMPLOYEE relation to site 2, execute the join at site 2, and send the result to site 3. The size of the query result is 40 * 100 = 4000 bytes, so we must transfer 4000 + 1,000,000 = 1,004,000 bytes.  Transfer the DEPARTMENT relation to site 1, execute the join at site 1, and send the result to site 3. In this case we have to transfer 4000 + 3500 = 7500 bytes. Example Distributed Databases, by Dr. Khalil

  42. Q3 Consider that the result site is site 2; then we have two simple strategies. Transfer the EMPLOYEE relation to site 2, execute the query, and present the result to the user at site 2. Here, we need to transfer the same number of bytes (1,000,000) for both Q1 and Q2.  Transfer the DEPARTMENT relation to site 1, execute the query at site 1, and send the result back to site 2. In this case we must transfer 400,000 + 3500 = 403,500 bytes for Q1 and 4000 + 3500 = 7500 bytes for Q2. Example Distributed Databases, by Dr. Khalil

  43. Distributed Query Processing Using SemiJoin • The idea behind distributed query processing using the semijoin operation is to reduce the number of tuples in a relation before transferring it to another site. • Intuitively, the idea is to send the joining column of one relation R to the site where the other relation S is located; this column is then joined with S. • Following that, the join attributes, along with the attributes required in the result, are projected out and shipped back to the original site and joined with R. • This can be quite an efficient solution to minimizing data transfer. Distributed Databases, by Dr. Khalil

  44. Example Q1 and Q2 Processing Using semijoin: • Project the join attributes of DEPARTMENT at site 2, and transfer them to site 1. For Q1, we transfer F = DNUMBER(DEPARTMENT), whose size is 4 * 100 = 400 bytes, whereas for Q2, we transfer F’ = MGRSSN(DEPARTMENT), whose size is 9 * 100 = 900 bytes. • Join the transferred file with the EMPLOYEE relation at site 1, and transfer the required attributes from the resulting file to site 2. For Q1, we transfer R = <DNO, FNAME, LNAME> (F  DNUMBER=DNO EMPLOYEE) whose size is 34 * 10,000 = 340,000 bytes, whereas for Q2, we transfer R’ = <MGRSSN, FNAME, LNAME>(F’  MGRSSN=SSN EMPLOYEE), whose size is 39 * 100 = 3900 bytes. • Execute the query by joining the transferred file R or R’ with DEPARTMENT, and present the result to the user at site 2. Distributed Databases, by Dr. Khalil

  45. Concurrency Control and Recovery in Distributed Databases • Dealing with multiple copies of the data items. • Failure of individual sites. • Failure of communication links. • Distributed commit. • Distributed deadlock. Distributed Databases, by Dr. Khalil

  46. Distributed Concurrency Control Based on a Distinguished Copy of a Data Item • The idea is to designate a particular copy of each data item as a distinguished copy. • The locks for this data item are associated with the distinguished copy, and all locking and unlocking requests are sent to the site that contains that copy. • A number of different techniques are based on this idea. Distributed Databases, by Dr. Khalil

  47. Primary Site Techniques. In this method, all distinguished copies are kept at one site, called the primary site. The primary site is designated to be the coordinator site for all database items. Hence, all locks are kept at that site, and all requests for locking or unlocking are sent to that site. Advantage: It is a simple extension of the centralized approach. Disadvantages: All locking requests are sent to a single site, possibly overloading that site and causing a system bottleneck. Failure of the primary site paralyzes the system, since all locking information is kept at that site. This can limit system reliability and availability. Primary Site with Backup Site. This approach addresses the second disadvantage of the primary site method by designating a second site to be a backup site. All locking information is maintained at both the primary and the backup sites. In case of failure of the primary site, the backup site can take over as primary site, and a new back site can be chosen. Advantage: This approach simplifies the process of recovery from failure of the primary site, since the backup site takes over and processing can resume after a new backup site is chosen and the lock status information is copied to that site. Disadvantage: It slows down the process of acquiring locks, because all lock requests and granting of locks must be recorded at both the primary and the backup sites before a response is sent to the requesting transaction. Techniques Distributed Databases, by Dr. Khalil

  48. Primary Copy Technique. This method attempts to distribute the load of lock coordination among various sites by having the distinguished copies of different data items stored at different sites. Failure of one site affects any transactions that are accessing locks on items whose primary copies reside at that sit, but other transactions are not affected. This method can also use backup sites to enhance reliability and availability. Choosing a New Coordinator Site in Case of Failure. Whenever a coordinator site fails in any of the preceding techniques, the sites that are still running must choose a new coordinator. In the case of the primary site approach with no backup site, all executing transactions must be aborted and restarted, and the recovery process is quite tedious. For methods that use backup sites, transaction processing is suspended while the backup site is designated as the new primary site and a new backup site is chosen and is sent copies of all the locking information from the new primary site. Techniques Distributed Databases, by Dr. Khalil

  49. Distributed Concurrency Control Based on Voting • In the voting method, there is no distinguished copy; rather, a lock request is sent to all sites that include a copy of the data item. Each copy maintains its own lock and grant or deny the request for it. If a transaction that requests a lock is granted that lock by a majority of the copies, it holds the lock and informs all copies that it has been granted the lock. If a transaction does not receive a majority of votes granting it a lock within a certain time-out period, it cancels its request and informs all sites of the cancellation. • The voting method is considered a truly distributed concurrency control method, since the responsibility for a decision resides with all the sites involved. Simulation studies have shown that voting has higher message traffic among sites than do the distinguished copy methods. If the algorithm takes into account possible site failures during the voting process, it becomes extremely complex. Distributed Databases, by Dr. Khalil

  50. Distributed Recovery • The recovery process in distributed databases is quite involved. In some cases it is quite difficult even to determine whether a site is down without exchanging numerous messages with other sites. For example, suppose that site X sends a message to site Y and expects a response from Y but does not receive it. There are several possible explanations: • The message was not delivered to Y because of communication failure. • Site Y is down and could not respond. • Site Y is running and sent a response, but the response was not delivered. • Another problem with distributed recovery is distributed commit. When a transaction is updating data at several sites, it cannot commit until it is sure that the effect of the transaction on every site cannot be lost. This means that every site must first have recorded the local effects of the transactions permanently in the local site log on disk. The two-phase commit protocol is often used to ensure the correctness of distributed commit. Distributed Databases, by Dr. Khalil

More Related