- Discuss the following with respect to Distributed Database Systems.
- Problem Area of Distributed Database.
- Transaction Processing Framework.
- Models of Failure.
a) Problems Area of Distributed Database:-When a problem occurs within a distributed relational database, it is necessary to first identify where the problem originates. The problem may be on the application server or application requester. When the database problem is located properly in the network, you may further isolate the problem as a user problem, a problem with an application program, or communications problem in order to correct the error. Problem analysis needs to be managed in a distributed database environment. Problem analysis involves both identifying and resolving problems for applications that are processed across a network of systems. Consider the following:-
- Distributed database processing problems manifest themselves in various ways. For example, an error return code may be passed to a distributed database application by the system that detects the problem. In addition, responses may be slow, wrong, or nonexistent.
- Tools are available to diagnose distributed database processing problems. For example, each distributed relational database product provides trace functions that can assist in diagnosing distributed data processing problems.
When a problem occurs accessing a distributed relational database, it is the job of the administrator to:-
- Determine the nature of the problem, and
- Determine if it is a problem with the application or a problem with the local or remote system.
A problem you encounter when running a distributed relational database application can exhibit two general symptoms:
- The user receives incorrect output
- The application does not complete in the expected time
Investigating a problem usually begins with the user. Users may not be getting the results they expect when running a program or they may get a message indicating a problem. Sometimes the best way to diagnose and solve a problem is to step through the procedure with a user. The copy screen function allows you to do this either in real time with the erver or application requester. When the database problem is located properly in the network, the IT department may further isolate the problem as a user problem, a problem with an application program, or communications problem in order to correct the error.
b) Transaction Processing Framework:-Ever-increasing demands for high transaction rates, limitations of high-end processors, high availability and modular growth considerations are all driving forces towards distributed architectures for transaction processing. A key prerequisite to take advantage of the capacity of a distributed transaction processing system, however, is an effective strategy for workload allocation. The distribution of the workload should not only achieve load balancing, but also support an efficient transaction processing with a minimum of inter-system communication. To this end, adaptive schemes for transaction routing have to be employed which are highly responsive to workload fluctuations and configuration changes. Adaptive allocation schemes are also important for simplifying system administration which is a major problem in distributed transaction processing systems.
We develop a taxonomical framework for workload allocation, in particular transaction routing, in distributed transaction processing systems. This framework considers the influence of the underlying system architecture (e.g. shared nothing, shared disk) and transaction execution model as well as the major dependencies between workload, program and data allocation. The main part of the framework covers structural (or architectural) and implementational alternatives for transaction routing to help identify key factors and basic tradeoffs in the design of appropriate allocation schemes. Finally, we show how existing schemes fit under our taxonomy. The framework substantially facilitates a comparison of the different schemes and can guide the development of new, more effective protocols.
c) Models of Failure:- The vitality of resource and information availability
in distributed systems is well-appreciated by the user communities, resource and information sharing being the fundamental motivation for the construction of distributed
systems. As accepted by a broad spectrum of research and user groups, the performance of a distributed system should, if at all, degrade only gracefully in presence of
failures. But, unfortunately, most existing systems are highly failure-prone and do not have satisfactory tools to handle the failures. In spite of this, research efforts to handle the wide variety of failures have shown momentum only recently. Different classes of failures are possible in a distributed system due to the failure of sites and/or links. Two classes
of failures are considered in the literature for sites-various degrees of malicious behavior and fail-stop. A fail-stop processor simply stops when it detects any- failure of the other type. The most common failure of links is also fail-stop where all messages transmitted on a link are lost permanently. A cumulative effect of fail-stop processor and link failures could lead to a global failure known as network partitioning. We study two classes of failures-
Manuscript received October 31, 1983; revised May 31, 1985. This work was supported in part by the National Science and Engineering Research,Council of Canada under Grant A4319,F. Y. Chin is with the Center for Computer Studies and Applications,University of Hong Kong, Hong Kong,K. V. S. Ramarao is with the Department of Computer Science, University of Pittsburgh, Pittsburgh, PA 15260.fail-stop processors and network partitioning, in this paper. Availability and consistency have been recognized as the two fundamental requirements of databases. Atomic transactions are convenient abstractions for valid programs accessing a database: database consistency is invariant under a transaction. Since concurrency control
mechanisms deal with the serialization of concurrent operations by different transactions, we only need to consider whether a given transaction is successfully completed or not. Thus, throughout our discussion, we consider the execution of a single transaction and study how the implementation of its atomicity gets effected by failures. Naturally, atomic implementation of all distributed transactions even in presence of faults is a necessary condition to ensure the consistency of distributed databases at all times. Maximization of the availability of databases at the operational sites when there is a failure is a natural goal any designer would like to achieve. Study of these two and certain related aspects is the prime intention of this paper.There is a variety of models available for the execution of a distributed transaction, such as central, tree, and nested. It is easy to understand them with the following abstraction, which will be made formal in the next section: the execution of a transaction proceeds in three (ordered) stages in the general case: 1) initiation during which the transaction is decomposed into a number of sub transactions and sent to the appropriate sites; 2) decision-making during which a decision is made on the fate of the transaction-whether it can be completed successfully or not, and 3) completion during which the decision
made in the previous stage is implemented. A transaction completed successfully is said to be committed while it is said to be aborted otherwise. A variety of ways is possible for the implementation of each of these stages, depending on who controls the process during that stage. Most common are 1) centralized where a single predesignated site supervises the function by communicating with all other sites (other sites do not usually communicate among themselves in this case unless the designated site fails), 2) hierarchical where the interaction among the sites is tree-structured, and 3) decentralized where each site in dependently interacts with all other sites. Implementation of the decision-making stage further depends on who makes the decision.
