Question 1

In distributed databases, maintaining a full copy of the database at two or more sites (replication) is commonly used both for data distribution and for fault tolerance. Is this statement accurate?

Accepted Answer

Introduction / Context: This question checks understanding of why organizations keep complete copies of a database at multiple sites. The practice is known as replication and it supports both geographic distribution (placing data close to users) and fault tolerance (surviving node or site failures). Given Data / Assumptions: Two or more independent sites (nodes) exist. Each site stores a full copy of the database (not just a partition). A replication mechanism keeps copies reasonably consistent. Concept / Approach: Replication provides redundancy and local read access. When a site fails, clients can redirect to another site that holds a complete copy. When demand is global, placing replicas near users reduces latency. Consistency is managed via synchronous or asynchronous techniques depending on requirements. Step-by-Step Solution: Identify that multiple complete copies across sites = replication.Relate replication to distribution: users can read from the nearest replica.Relate replication to fault tolerance: if one site fails, another replica serves requests.Conclude the statement is accurate. Verification / Alternative check: High-availability architectures (active–active or active–standby) rely on multi-site replication for low RTO/RPO targets. Why Other Options Are Wrong: Claiming replication is rare or only for special topologies ignores mainstream HA/DR patterns. Shared storage is not required; replicas often use independent storage for failure isolation. Common Pitfalls: Confusing sharding (partitioning) with replication (copying). Assuming replication guarantees zero data loss without considering sync mode and commit policies. Final Answer: Applies — replication at multiple sites is a common strategy for both goals

Question 2

Distributed DBMS: Does asynchronous replication usually slow transactions because the system spends time ensuring updates are fully propagated before commit?

Accepted Answer

Introduction / Context: Replication strategies affect commit latency. This item differentiates between synchronous and asynchronous replication in a distributed DBMS. Given Data / Assumptions: Synchronous replication confirms remote updates before commit returns. Asynchronous replication ships changes after commit (eventual consistency). Network checks and coordination add latency when performed in the critical path. Concept / Approach: If a system waits to “accurately and completely propagate” an update across the network before acknowledging success, it is operating synchronously. Asynchronous replication decouples propagation from the user transaction to improve perceived response time at the cost of temporary inconsistency and additional conflict handling. Step-by-Step Solution: Identify the behavior described: waiting for network-wide propagation during commit.Map this to synchronous replication semantics.Recognize that asynchronous replication does not wait, so response time is typically better, not worse.Conclude that the statement is incorrect for asynchronous replication. Verification / Alternative check: HA/DR guides show synchronous modes increasing commit latency and asynchronous modes prioritizing throughput and local responsiveness. Why Other Options Are Wrong: Asserting “always blocks” or “needs 2PC at every site” is incorrect for asynchronous methods. LAN/WAN scope does not change the sync/async semantic. Common Pitfalls: Assuming asynchronous means “fast and exact” or “no ordering issues.” It improves latency but requires reconciliation and careful conflict resolution policies. Final Answer: Does not apply — the description matches synchronous replication, not asynchronous

Question 3

Distributed query processing: In a semijoin, is only the join attribute sent to the remote site, after which only the matching rows are returned?

Accepted Answer

Introduction / Context: Semijoins are classic techniques in distributed query optimization to reduce data shipped over the network for join processing. Given Data / Assumptions: Relations reside at different sites. Joins can be expensive if full tables are transmitted. Join keys can be projected and used to filter remote rows. Concept / Approach: In a semijoin, site A sends the projection of its join attribute(s) to site B. Site B uses those values to select only matching rows and returns just those rows (or just their keys). This avoids transferring irrelevant tuples. Step-by-Step Solution: Project join attributes from the initiating site.Transmit the compact set of keys to the remote site.Filter remote tuples and return only matches.Complete the join locally with greatly reduced data movement. Verification / Alternative check: Cost models consistently favor semijoins when selectivity is high and key sets are small relative to full tables. Why Other Options Are Wrong: Saying semijoin “ships full tables” negates its purpose. Synchronization mode or partitioning does not define semijoin behavior. Common Pitfalls: Using semijoin when join selectivity is low (little reduction) can add overhead without benefit. Final Answer: Applies — projecting join keys first reduces network traffic

Question 4

Failure transparency in distributed transactions: does it guarantee all-or-nothing outcomes (either all actions commit or none do)?

Accepted Answer

Introduction / Context: Distributed systems aim to hide failures from applications. In the database world, failure transparency ties closely to atomic commit: either all participants commit or all abort. Given Data / Assumptions: Distributed transactions may involve multiple resource managers. Two-phase commit (2PC) or a similar protocol coordinates commit. Sites and networks can fail independently. Concept / Approach: Failure transparency means applications should not observe partial effects of a transaction. Atomicity across sites is ensured via commit protocols and logging. If any participant cannot commit, the coordinator orders a rollback everywhere, preserving the all-or-nothing property. Step-by-Step Solution: A client initiates a distributed transaction.Participants enter prepare phase and promise to commit or abort atomically.On success, the coordinator issues commit to all; on failure, issues abort to all.Clients observe either complete success or complete rollback. Verification / Alternative check: Textbook ACID semantics define atomicity explicitly; distributed commit protocols extend this across sites. Why Other Options Are Wrong: Partial commits violate atomicity; limiting to one site or read-only cases misunderstands the concept. Common Pitfalls: Ignoring heuristic outcomes in rare failure modes; not accounting for blocking issues in 2PC during coordinator failures. Final Answer: Applies — failure transparency masks faults so a transaction is atomic across sites

Question 5

When are replicated databases preferred? Are they favored for workloads that are mostly read-only with relatively static data?

Accepted Answer

Introduction / Context: Replication trades off write complexity and consistency coordination for improved read availability and locality. The suitability depends on workload characteristics. Given Data / Assumptions: Workload is dominated by reads; writes are less frequent. Data changes are relatively infrequent (static compared to read volume). Replica freshness requirements are compatible with the chosen sync mode. Concept / Approach: Read-mostly systems gain by serving queries from many replicas close to users while batching or asynchronously applying updates. Highly write-intensive, hot-spot workloads face overhead from propagating each change to all replicas, risking conflicts and lag. Step-by-Step Solution: Assess read/write ratio and update frequency.Match replication mode (sync/async) to staleness tolerance.Place replicas near consumers to reduce latency.Confirm the approach improves availability and performance. Verification / Alternative check: Many CDNs and global services replicate state that changes slowly (catalogs, profiles, reference data) for scalability. Why Other Options Are Wrong: Write-heavy workloads magnify replication cost; hardware uniformity and semijoins are unrelated requirements. Common Pitfalls: Underestimating conflict resolution in multi-writer topologies; ignoring replication lag for read-your-write scenarios. Final Answer: Applies — read-mostly and slow-changing data suit replication well

Question 6

Does asynchronous replication immediately apply every update to all other copies (or abort) across the network?

Accepted Answer

Introduction / Context: This question contrasts asynchronous with synchronous replication timing guarantees. Given Data / Assumptions: Asynchronous replication ships changes after local commit. Synchronous replication waits for remote acknowledgment before commit success. Network conditions may delay propagation under asynchronous modes. Concept / Approach: The statement describes the synchronous guarantee (all-or-abort across all copies before commit returns). Asynchronous replication improves availability and latency by decoupling propagation, accepting temporary divergence among replicas. Step-by-Step Solution: Identify “immediately applied everywhere” as a sync property.Recall async behavior: commit locally first; ship and apply later.Conclude the given behavior is not asynchronous. Verification / Alternative check: System docs for popular databases detail synchronous commit semantics versus eventual consistency of asynchronous modes. Why Other Options Are Wrong: LAN speed, semijoins, or shared logs do not redefine asynchronous semantics. Common Pitfalls: Expecting read-your-write consistency across sites immediately after a local commit in async setups. Final Answer: Does not apply — immediate, all-site updates describe synchronous behavior

Question 7

Does the semijoin strategy reduce network traffic in distributed join processing?

Accepted Answer

Introduction / Context: Network bandwidth is a scarce resource in distributed databases. The semijoin technique is a classic optimization to reduce transferred data during joins. Given Data / Assumptions: Relations to be joined reside on different sites. Join selectivity allows filtering large fractions of non-matching rows. Join keys can be exchanged at low cost compared to full rows. Concept / Approach: A semijoin sends projected join keys first, enabling the remote site to eliminate non-matching rows, and then returns only necessary tuples, reducing bytes on the wire. Step-by-Step Solution: Project join attribute(s) at the initiating site.Send keys to the remote site.Filter and return only matching tuples.Complete the final join locally with reduced data volume. Verification / Alternative check: Cost-based optimizers consider semijoins when the key set is much smaller than the base relation sizes. Why Other Options Are Wrong: Semijoins do not require replication, outer joins, or specific schemas; they address transmission cost broadly. Common Pitfalls: Using semijoins when the key set is large can negate benefits due to extra passes. Final Answer: Applies — semijoins are used specifically to cut data shipping

Question 8

Replication choices: Can database replication be implemented with either synchronous or asynchronous techniques, with asynchronous being more common in practice?

Accepted Answer

Introduction / Context: Choosing replication mode is a key architectural decision that balances latency, consistency, and durability. Given Data / Assumptions: Synchronous replication adds commit latency but strong consistency. Asynchronous replication lowers latency but allows temporary divergence. Many production systems prioritize throughput and availability, making async prevalent. Concept / Approach: Both modes are widely supported. Asynchronous replication is often favored for geo-distribution and large-scale read-heavy services because it reduces user-visible latency and tolerates WAN variability. Step-by-Step Solution: Define synchronous vs. asynchronous semantics.Map them to operational trade-offs (latency vs. consistency).Recognize industry practice: async is common for DR and global read replicas.Conclude the statement is valid. Verification / Alternative check: Vendor documentation typically offers both modes with tuning for durability and lag monitoring. Why Other Options Are Wrong: Limiting to a single mode or architecture is incorrect; 2PC is related to distributed commit, not required for all replication styles. Common Pitfalls: Assuming async guarantees no data loss in catastrophic failures; SLA design must specify RPO/RTO. Final Answer: Applies — both modes exist and async is commonly deployed

Question 9

Materialized views / snapshots: Does the refresh cost depend on whether the snapshot is simple or complex?

Accepted Answer

Introduction / Context: In many DBMSs, “snapshots” or materialized views can be refreshed incrementally or fully, and their definition influences refresh cost. Given Data / Assumptions: Simple views (single-table or certain join/aggregation patterns) can track changes efficiently. Complex views (arbitrary joins, non-deterministic functions) may not qualify for incremental refresh. Systems may require logs or MV logs to support fast refresh. Concept / Approach: Fast (incremental) refresh uses change data to update only affected rows, reducing cost. Complex definitions may force complete refresh, reading base tables and recomputing results, which is more expensive. Step-by-Step Solution: Classify the snapshot as simple or complex based on DBMS rules.Check availability of change tracking (logs).Choose fast or complete refresh accordingly.Estimate cost: incremental is typically cheaper than full recompute. Verification / Alternative check: DBMS documentation lists allowable constructs for fast refresh and their performance implications. Why Other Options Are Wrong: Replication mode, OLTP/OLAP labels, or index type do not dictate refresh complexity alone. Common Pitfalls: Assuming all materialized views can fast-refresh; overlooking required logging or constraints. Final Answer: Applies — simple snapshots may fast-refresh; complex often require more work

Question 10

Failures in distributed vs. centralized databases: Is each node in a distributed system subject to the same failure types as a centralized system (plus additional inter-site risks)?

Accepted Answer

Introduction / Context: Understanding failure modes is essential for resilient database design. Distributed systems inherit all single-node risks and add new ones from distribution. Given Data / Assumptions: Centralized failures include hardware faults, OS crashes, power loss, and data corruption. Distributed systems also experience network partitions, inter-site latency spikes, and split-brain scenarios. Each node is still a computer subject to ordinary failures. Concept / Approach: A distributed system is a collection of nodes; each node has the same baseline failure profile as a standalone server. Distribution introduces additional failure classes rather than removing existing ones. Hence, per-node risks mirror centralized systems. Step-by-Step Solution: List local failure types (disk, CPU, memory, OS, process).Add distributed-specific risks (network partition, consensus failure, clock skew).Recognize that node-level failure equivalence holds; distribution adds complexity.Conclude the statement is accurate. Verification / Alternative check: Fault models (fail-stop, Byzantine) and CAP discussions highlight additional risks, not fewer. Why Other Options Are Wrong: Distribution does not immunize nodes from common failures; it complicates recovery and coordination. Common Pitfalls: Neglecting network partition testing and cross-site failover procedures; assuming RAID or replication prevents all data loss. Final Answer: Applies — nodes face similar local failures; distribution adds network/site risks

Distributed Databases Questions