Distributed DBMS: Overview & Concurrency Control

Goal: a small-scale (dozens of sites) distributed DBMS

1. Location transparency: users don’t know where the data is
2. Performance transparency: performance independent of submission site
3. Copy transparency: objects can be copied, and copies are maintained automatically. Critical for availability
4. Transaction transparency: looks like single-site xacts
5. Fragment "transparency": tables can be fragmented to different sites
6. Schema change transparency: schema updates at a single site affect global schema
7. Local DBMS transparency: shouldn’t matter what DBMS is running at each site (ha!)

Nobody provides all of this (#7 & #3 are still major research field)

IBM Almaden’s R* was the most "real" DDBMS prototype.

• VTAM/CICS provided communication
• Good optimizer, concurrency control

Others:

• SDD-1: done at CCA, never really ran. PDP-10’s on Arpanet. Strange design decisions based on unreasonably slow network.
• Distributed INGRES: UCB, also never ran. Lack of UNIX networking software (pre TCP/IP!).
• Commercial vendors beginning to provide this functionality

The R* Distributed DBMS

Goals

• location transparency
• local privacy & control
• local performance on local queries
• no central dependencies: site autonomy
• no central catalogs
• no central scheduler
• no central deadlock detector

Tables can be

• dispersed
• replicated
• partitioned:
• horizontal partitioning (by predicate)
• vertical partitioning (but a key at each partition)
• snapshots

Table names: user_name@user_site.object_name@birth_site

Catalogs store info on local objects, and objects born locally (along with pointers to current sites)

Remote catalog info is cached as hints:

• invalid cache entries are detected easily and updated
• catalog entries have version numbers

a catalog entry for a table:

• System-Wide Name
• type info
• access paths
• view definition (if it’s a view)
• optimizer stats

To find a catalog entry:

1. check local catalog & cache
2. check birth site
3. check the place the birth site points to

An overview of Distributed CC:

Every transaction gets an xactno: site_name.time (or SN)

deadlocks: shoot the youngest, largest-numbered xact

Commit Protocol – you can’t just decide to commit:

• some site may not be able to
• you can’t distingush inability from slowness!

Two Phase Commit (2PC):

1. coordinator says to participants: want to commit? (N-1 messages)
2. Participants all vote yea/nay (N-1 messages)
3. coordinator tells everyone to commit/abort (N-1 messages)
4. participants acknowledge message (N-1 messages)

This does the right thing, but it’s pretty costly. Next paper improves this.

Distributed Deadlock Detection:

• find and resolve local deadlocks
• pass your waits-for graph around to detect global deadlocks
• next paper does this more efficiently