Database Reference
In-Depth Information
Naming Transparency
While covering catalog management above, we dealt with the naming of database
objects in a distributed database system. As in a centralized database, database
objects in a distributed database must also have unique names. You have noted how
the names are made unique. You attach three different identifiers to the local name
of the object to make the name unique.
The DDBMS hides the complications of extending the local object names from
the users. User queries can refer to database objects by local names. DDBMS pro-
vides naming transparency through a method of using synonyms. Please refer back
to the subsection on catalog management.
Failure Transparency
You know that, in a centralized database system, a transaction must preserve its
atomicity and durability. That is, in the event of failures, either every operation of
a transaction is completed successfully or none of the operations of the transaction
is completed at all. Then atomicity of transactions is maintained. Furthermore, if a
transaction completes successfully and commits, no failure should be able undo any
database update performed by the committed transaction. The database changes
must be durable.
A distributed database environment is vulnerable to other types of failures
related to communication links. The DDBMS ensures that atomicity and durability
of a transaction will still be protected in the distributed environment as well. This
property is failure transparency.
DISTRIBUTED PROCESSING
The complexities of processing queries and transactions in a distributed database
environment far exceed those in a centralized database system. When a query is
submitted in a distributed database system, the DDBMS has to take into account a
number of factors to prepare an optimal query plan to execute the query. Do the
data elements needed by the query reside locally at that site? If not, are the data
elements stored elsewhere? Are the data elements parts of fragments? Is there any
replication scheme to be considered? If so, which is the optimal copy to be used?
Similar questions arise while processing transactions that perform insert, update,
and deletion operations.
Concurrency control gets more complicated in a distributed environment.
Where do you keep the locks? What types of locking protocols are effective?
How do you resolve deadlocks? Could transactions from multiple sites be in a dead-
lock situation? Recovery from failures poses greater challenges as well. What
happens when a site fails? Can the other sites keep operating while the failed site
is recovered?
We will consider the essential basics in this section. We will highlight the under-
lying complexities and present how distributed processing is generally performed.
We will present some recovery methods. However, more than cursory coverage of
Search WWH ::
Custom Search