Question 1

Transactional concurrency control: If two transactions run at the same time and the combined result is the same as if they had executed one after the other in some order, are those transactions considered serializable?

Accepted Answer

Introduction / Context:Serializable isolation is the gold standard for correctness in concurrent transaction processing. It ensures that interleaved execution of transactions yields a final database state equivalent to some serial (one-after-another) execution. This question checks whether that equivalence property is precisely what “serializable” means.Given Data / Assumptions:Two or more transactions may overlap in time (concurrent execution).We compare the outcome of the concurrent schedule to the outcome of a serial schedule.No requirement to match a particular serial order—only that some serial order exists.Concept / Approach:A schedule is serializable if it is conflict-serializable or view-serializable, meaning there exists a serial ordering of the same transactions that produces the same effect on the database. Concurrency control mechanisms (e.g., two-phase locking or optimistic schemes) strive to allow parallelism while preserving this serializability property.Step-by-Step Solution:Define serial schedule: T1 then T2 (or T2 then T1) with no overlap.Define serializable schedule: an interleaving whose effect matches some serial order.Conclude: if the concurrent result equals the result of one serial order, the transactions are serializable.Verification / Alternative check:Use precedence (conflict) graphs: if the graph is acyclic, the schedule is conflict-serializable, guaranteeing equivalence to a serial order.Why Other Options Are Wrong:“Incorrect” contradicts the formal definition.“Only under read uncommitted isolation” is wrong; serializability is stronger than read uncommitted.“Only when no locks are used” is wrong; locking (2PL) is a common way to enforce serializability.Common Pitfalls:Confusing serial execution (no overlap) with serializable execution (may overlap but is equivalent to a serial order). Also, assuming there must be a specific serial order match—any serial order that yields the same result suffices.Final Answer:Correct

Question 2

Database recovery terminology: Is a synchronization point between the database and its transaction log commonly called a “stop point”, or is there a standard term?

Accepted Answer

Introduction / Context:In database recovery, the system periodically flushes dirty pages and writes log records to establish a known consistent state to speed up crash recovery. This question asks whether such a synchronization point is called a “stop point.”Given Data / Assumptions:We are discussing the standard ARIES-style (or similar) logging and recovery concepts.Terminology matters for exam and practical communication.The operation establishes a known point in the log from which REDO/UNDO begins.Concept / Approach:The widely accepted and vendor-agnostic term is checkpoint. A checkpoint records that all transactions up to a certain log sequence number (with some nuances) have their necessary log records on stable storage, and certain pages may be flushed. This reduces recovery time after a crash by limiting how far back the system must scan the log.Step-by-Step Solution:Identify the intended operation: synchronize database state with log.Recall standard name: checkpoint.Conclude: calling it a “stop point” is nonstandard; the correct term is checkpoint.Verification / Alternative check:Review documentation of major DBMS (e.g., PostgreSQL, SQL Server, Oracle); all use the term checkpoint for this concept.Why Other Options Are Wrong:“Correct: stop point” uses a nonstandard label and may mislead learners.Limiting correctness to specific architectures (distributed or in-memory) does not change the established term.Common Pitfalls:Confusing checkpoints with savepoints. Savepoints are intra-transaction markers for partial rollbacks, whereas checkpoints concern system-wide recovery state.Final Answer:Incorrect: the standard term is checkpoint

Question 3

Isolation anomalies: Does a phantom read mean that, on reread, a transaction finds that previously read rows were modified or deleted by a committed transaction?

Accepted Answer

Introduction / Context:Understanding isolation anomalies is critical for choosing the appropriate transaction isolation level. Common anomalies include dirty reads, non-repeatable reads, and phantoms. This question distinguishes between non-repeatable reads and phantom reads.Given Data / Assumptions:A transaction reads some data, then later rereads.Between reads, another committed transaction changes the database.We must identify which anomaly matches “modifications or deletions of previously read rows.”Concept / Approach:Non-repeatable read occurs when a transaction rereads the same row and finds it changed or removed by another committed transaction. Phantom read occurs when a transaction rereads a set of rows defined by a predicate and finds new additional rows appear (or disappear) that match the predicate, even if previously read rows are unchanged. Phantoms are prevented by serializable isolation with predicate locking or by techniques like index-range locking.Step-by-Step Solution:Identify the symptom in the stem: prior rows are modified or deleted.Map to anomaly: that is a non-repeatable read, not a phantom.Conclude the statement is incorrect as phrased.Verification / Alternative check:Compare definitions across textbooks: “phantom” refers to new tuples matching a predicate, while “non-repeatable” refers to changes to previously read tuples.Why Other Options Are Wrong:Calling it a phantom confuses two distinct phenomena.References to serializable isolation or predicate locks do not make the given description a phantom.Common Pitfalls:Equating any second read difference with “phantom.” Always ask: did the set definition change (phantom) or did the same row’s values change (non-repeatable)?Final Answer:Incorrect: that describes a non-repeatable read

Question 4

Transaction semantics: Is a transaction a series of database actions that must all succeed together, or else none take effect (all-or-nothing)?

Accepted Answer

Introduction / Context:Transactions provide a clean unit of work in database systems. The key property highlighted here is atomicity: a transaction’s changes are applied entirely or not at all. This property underpins reliable application behavior in the face of errors or crashes.Given Data / Assumptions:A transaction encloses multiple reads and writes.Commit makes changes durable; rollback undoes them.System may crash, but recovery respects atomicity.Concept / Approach:ACID stands for Atomicity, Consistency, Isolation, Durability. Atomicity is the “all-or-nothing” guarantee. Consistency requires that transactions move the database from one valid state to another, Isolation controls interference among concurrent transactions, and Durability guarantees that committed changes persist.Step-by-Step Solution:Group operations into a transaction (BEGIN/START TRANSACTION).On success, COMMIT to make changes permanent.On failure, ROLLBACK to cancel all effects.Verification / Alternative check:Crash recovery replays/undoes logged operations to ensure either the full transaction is applied or not applied, never a partial state.Why Other Options Are Wrong:“Incorrect” contradicts the definition of atomicity.Transaction semantics do not apply “only for read-only” or depend solely on autocommit; even with autocommit, each statement is a transaction.Common Pitfalls:Mistaking batch execution for transactional grouping. Without explicit transaction control, some drivers autocommit per statement; still, each statement is atomic.Final Answer:Correct

Question 5

Role clarity: Is the primary responsibility of the Database Administrator (DBA) to enable, support, and facilitate effective development and use of the organization’s databases?

Accepted Answer

Introduction / Context:DBA responsibilities span availability, security, performance, recoverability, and governance. This question assesses the high-level mission: enabling development teams and business users to build and use reliable, performant databases safely.Given Data / Assumptions:DBAs manage operational and sometimes architectural aspects of databases.They collaborate with developers, SRE/ops, and security teams.They balance performance, cost, and compliance.Concept / Approach:While day-to-day tasks include backups, patching, monitoring, capacity planning, and tuning, the overarching responsibility is to facilitate effective use and evolution of database systems—ensuring data is safe, accessible, and performant for applications and analytics.Step-by-Step Solution:Identify stakeholder needs: uptime, data integrity, performance.Map DBA functions: backup/restore, security, schema change processes, tuning, incident response.Conclude the overall responsibility is enablement and stewardship of the database environment.Verification / Alternative check:Job descriptions and ITSM practices emphasize service enablement and governance, not just single tasks.Why Other Options Are Wrong:Limiting the role to backups or tuning is too narrow.“Incorrect” ignores the holistic mission of the DBA function.Common Pitfalls:Viewing DBAs as gatekeepers only. Modern DBAs partner with teams to automate, standardize, and accelerate delivery while maintaining safety and compliance.Final Answer:Correct

Question 6

Concurrency basics: When two transactions are processed at the same time against the database, are they called concurrent transactions?

Accepted Answer

Introduction / Context:Concurrency allows better throughput and resource utilization by overlapping transaction execution. The question asks for a basic definition: transactions executing during overlapping time intervals are concurrent.Given Data / Assumptions:Two or more transactions overlap in time (start/end times intersect).They may or may not touch the same rows or tables.Database uses a concurrency control method to preserve correctness.Concept / Approach:Transactions are concurrent if their operations interleave. Even if they touch different data items, they are still concurrent. Concurrency control mechanisms (locks, MVCC, OCC) ensure correctness properties such as serializability or snapshot isolation.Step-by-Step Solution:Identify time overlap: execution windows intersect.Label as concurrent regardless of data overlap.Conclude that the statement matches the standard definition.Verification / Alternative check:Schedulers interleave reads/writes from concurrent transactions into a single schedule; serial schedules have no interleaving.Why Other Options Are Wrong:Requiring same table access is unnecessary; concurrency is about time, not object overlap.Isolation level differences are irrelevant to whether execution is concurrent.Common Pitfalls:Conflating contention (which needs same data) with concurrency (which needs just overlap). You can be concurrent without contention.Final Answer:Correct

Question 7

Locking terminology: Is the “lock granularity” the size or scope of the lock (for example, row-level vs. page-level vs. table-level)?

Accepted Answer

Introduction / Context:Locking granularity affects concurrency and overhead. Finer granularity (row) increases concurrency but may require more locks; coarser granularity (table) reduces overhead but can block more operations. This question checks the definition of “lock granularity.”Given Data / Assumptions:Various resources can be locked: rows, keys, pages/blocks, partitions, or entire tables.Lock types (shared, exclusive, intent) are orthogonal to granularity.Granularity influences contention and performance.Concept / Approach:“Granularity” literally describes the size or scope of a lockable unit. Databases often support hierarchical locking with intent locks to combine coarse and fine-grained locks safely. Tuning granularity is a trade-off between throughput and overhead.Step-by-Step Solution:Recognize possible lock scopes: row, page, table.Relate “granularity” to these scopes.Conclude that lock granularity is the size/scope of the locked resource.Verification / Alternative check:Examine DBMS documentation for lock modes and levels; they explicitly refer to lock levels as granularity choices.Why Other Options Are Wrong:Granularity is not limited to shared or exclusive locks; it applies to both.“Incorrect” conflicts with standard terminology.Common Pitfalls:Assuming finer granularity is always better. More locks mean more overhead and potential deadlock complexity.Final Answer:Correct

Question 8

ACID properties: Does an ACID transaction stand for atomic, consistent, isolated, and durable (the four fundamental guarantees)?

Accepted Answer

Introduction / Context:ACID summarizes the essential guarantees of reliable transaction processing. This question checks recognition of the four ACID properties and their meanings in practice.Given Data / Assumptions:Atomic: all-or-nothing.Consistent: preserves database invariants.Isolated: concurrent execution does not cause interference beyond the chosen isolation level.Durable: committed effects persist despite failures.Concept / Approach:ACID is independent of specific storage engines or architectures. Whether centralized or distributed (with 2PC/3PC, Paxos/Raft-backed logs), ACID describes the transactional contract offered to applications, though implementations may differ in strictness and performance.Step-by-Step Solution:Map the acronym to its four properties.Check that each property’s definition matches standard usage.Conclude the statement is correct.Verification / Alternative check:Consult any DBMS fundamentals text; the acronym expansion is uniform across vendors and academia.Why Other Options Are Wrong:Limiting ACID to distributed systems or NoSQL is incorrect. Many NoSQL systems are non-ACID by default; many RDBMS are ACID.“Incorrect” conflicts with the accepted definition.Common Pitfalls:Confusing “consistency” in ACID with “consistency” in CAP; they are different concepts.Final Answer:Correct

Question 9

Durability property: In a durable transaction, are all changes that were committed guaranteed to be permanent?

Accepted Answer

Introduction / Context:Durability is the “D” in ACID. It ensures that once a transaction commits, its effects survive power loss, crashes, or restarts. This question checks that understanding directly.Given Data / Assumptions:The system uses write-ahead logging (or equivalent) and stable storage.Commit protocol ensures log records and relevant data are persisted.Recovery procedures reapply or undo as needed after a crash.Concept / Approach:On commit, the DBMS forces necessary log records to durable storage (fsync/flush). After a crash, REDO ensures committed updates reappear; UNDO removes effects of uncommitted transactions. Thus, committed changes are permanent from the application’s perspective.Step-by-Step Solution:Transaction commits → log forced to stable storage.Crash occurs → recovery scans logs.Recovery redoes committed work, undoing uncommitted, preserving permanence.Verification / Alternative check:Examine DBMS guarantees for synchronous commit vs. relaxed (asynchronous) modes; durability can be configured, but the contract of durability assumes synchronous commit.Why Other Options Are Wrong:“Only until the next checkpoint” is wrong: checkpoints optimize recovery; they do not limit durability.“Only if the server does not crash” contradicts durability’s purpose.Common Pitfalls:Confusing user-configured non-durable modes (e.g., delayed fsync) with the definition of durability itself.Final Answer:Correct

Question 10

Exclusive lock semantics: Does an exclusive (X) lock allow others to read but block changes, or does it block both readers and writers?

Accepted Answer

Introduction / Context:Lock modes control what concurrent operations can proceed. Understanding how exclusive locks interact with shared locks is essential for reasoning about isolation and blocking behavior.Given Data / Assumptions:An exclusive (X) lock is held by one transaction on a resource (e.g., row/table).Other transactions may attempt shared (S) or exclusive (X) locks on the same resource.We consider classical two-phase locking semantics.Concept / Approach:A shared (S) lock allows concurrent readers but not writers. An exclusive (X) lock allows a single writer and conflicts with both S and X requests from others—blocking both reads and writes. Some MVCC systems let others read old versions without acquiring S locks, but under a locking-based model, an X lock prevents other transactions from reading the locked item because they cannot acquire a compatible S lock.Step-by-Step Solution:Recall lock compatibility matrix: S with S = compatible; S with X = incompatible; X with X = incompatible.Therefore, if one transaction holds X, others cannot obtain S or X.Conclude: X blocks both writers and readers (in lock-based isolation).Verification / Alternative check:Check DBMS documentation for lock compatibility charts; exclusive locks conflict with both shared and exclusive requests.Why Other Options Are Wrong:Claiming “X allows reads” misstates compatibility; readers need S which conflicts with X.Snapshot/MVCC exceptions present different mechanisms (versioned reads), not the semantics of the X lock itself.Common Pitfalls:Confusing MVCC’s non-blocking reads with lock compatibility. MVCC reads avoid S locks but that is due to versioning, not because X permits reads.Final Answer:Incorrect: X lock blocks both reads and writes by others

Question 11

Database administration (DBA) refers to a technical function within the database environment. Does it necessarily apply to the entire organization?

Accepted Answer

Introduction / Context:Many learners confuse “data administration” (enterprise-wide governance) with “database administration” (DBA), which is a technical role focused on specific database systems. This question tests whether you can distinguish the scope of DBA work from broader, organization-wide data governance functions.Given Data / Assumptions:DBA tasks include installation, configuration, backup/restore, performance tuning, security configuration, and availability for particular databases.Organization-wide concerns such as data policies, stewardship, and enterprise data standards fall under data administration or data governance.Large organizations may have multiple DBAs aligned to different platforms or business units, not necessarily a single enterprise-spanning DBA scope.Concept / Approach:The statement claims DBA “applies to the entire organization.” This wording better fits the role known as data administration or data governance. DBA is typically narrower: it applies to the managed database environments. While DBAs support enterprise applications, their function is defined by the databases they administer, not by all organizational information assets.Step-by-Step Solution:Identify the role boundaries: DBA focuses on DBMS operations and security inside the database tier.Contrast with data administration: organization-wide policies, data quality, and ownership.Evaluate the claim “applies to the entire organization”: that generalizes beyond normal DBA scope.Therefore, the statement is not accurate as written.Verification / Alternative check:Review job descriptions: DBAs manage instances and clusters; Chief Data Officers and data governance councils handle enterprise-wide information strategy.Why Other Options Are Wrong:“Valid statement” conflates DBA with enterprise governance. “Centralized IT only” is organizational structure, not a definition. “Vendor dependent” and “not applicable” are irrelevant.Common Pitfalls:Assuming “database” equals “all data” and expanding DBA scope to enterprise policy; overlooking the separation between governance and operations.Final Answer:Invalid statement

Question 12

Locking basics: if a lock is placed by an explicit command, is it considered an implicit lock?

Accepted Answer

Introduction / Context:Database systems use locks to coordinate concurrent access. Two common terms are “implicit” (locks the DBMS sets automatically) and “explicit” (locks issued directly by a user or application command). This question checks whether you can correctly classify locks set by commands.Given Data / Assumptions:DBMS often acquires locks implicitly to enforce isolation during DML.Users/applications can request locks with explicit statements (e.g., LOCK TABLE, SELECT … FOR UPDATE).Terminology is standard across many SQL platforms.Concept / Approach:Locks placed by command are, by definition, explicit. Implicit locks are created automatically by the DBMS as part of transaction processing without a specific LOCK statement from the user.Step-by-Step Solution:Classify the action: a user or app issues a lock statement → explicit lock.Contrast with implicit: DBMS sets locks as needed when executing DML under isolation.Evaluate the claim: calling explicit commands “implicit locks” is incorrect.Therefore, the statement is invalid.Verification / Alternative check:Check DBMS manuals: explicit examples include LOCK TABLE, sp_getapplock, or SELECT FOR UPDATE; implicit examples occur during INSERT/UPDATE/DELETE under isolation.Why Other Options Are Wrong:Isolation level, row scope, or concurrency model does not change the definition of explicit vs. implicit.Common Pitfalls:Assuming all locks are implicit; overlooking that explicit locks can override defaults and escalate scope.Final Answer:Invalid statement

Question 13

Lock granularity terminology: is the “size of a lock” correctly called lock sizing?

Accepted Answer

Introduction / Context:The level at which a lock is applied (row, page, table, database) is an important performance and concurrency concept. The standard term is “lock granularity.” This question checks if “lock sizing” is the correct phrase.Given Data / Assumptions:Granularity affects contention and overhead: fine-grained (row) yields higher concurrency; coarse-grained (table) reduces overhead but may block more.Vendors may support lock escalation between granularities.Terminology matters for exams and documentation.Concept / Approach:“Lock granularity” is the recognized term for the scope/size of locks. “Lock sizing” is not standard; using it may confuse readers and is not used in mainstream database literature.Step-by-Step Solution:Identify the concept: size/scope of lock → granularity.Check the label used in texts and manuals.Conclude that “lock sizing” is incorrect terminologically.Verification / Alternative check:Look up topics like “lock granularity and escalation” in DBMS documentation; the phrase “lock sizing” rarely appears, if ever.Why Other Options Are Wrong:Suggesting NoSQL or key-range exceptions does not change the accepted terminology.Common Pitfalls:Using nonstandard vocabulary in audits/designs can lead to miscommunication.Final Answer:Invalid statement

Question 14

Database security objective: is the goal to ensure only authorized users perform authorized activities at authorized times?

Accepted Answer

Introduction / Context:Security in database systems aims to protect confidentiality, integrity, and availability (CIA). The statement summarizes access control: who can do what, and when. This question checks whether that phrasing aligns with core security principles.Given Data / Assumptions:Authorization covers operations (SELECT, INSERT, UPDATE, DELETE, EXECUTE), objects (tables, views, procedures), and context (time, location, application).Authentication verifies identity; authorization grants privileges; auditing records activity.Additional controls include encryption, row-level security, masking, and policies.Concept / Approach:The phrase “authorized users, authorized activities, authorized times” reflects least privilege and policy-based access control. Time-based or context-based constraints (e.g., business hours) are part of advanced authorization policies.Step-by-Step Solution:Map the statement to CIA: stopping unauthorized actions preserves confidentiality and integrity; timing constraints can support availability and compliance.Recognize this is a concise articulation of access control objectives.Therefore, the statement is valid.Verification / Alternative check:Review DBMS features such as GRANT/REVOKE, row filters, and policy-based access (e.g., session context) that implement “who/what/when.”Why Other Options Are Wrong:Limiting to roles or read-only misses the breadth of security; encryption is orthogonal to authorization.Common Pitfalls:Confusing authentication with authorization; over-granting privileges; ignoring temporal restrictions where required by policy.Final Answer:Valid statement

Question 15

Resource locking purpose: does it prevent multiple applications from taking simultaneous write copies of the same record that is about to be changed?

Accepted Answer

Introduction / Context:Locking is a classic mechanism to preserve consistency under concurrent access. This question asks whether locking exists to prevent conflicting, simultaneous modifications of the same data.Given Data / Assumptions:Concurrent transactions may target the same row/page/table.Without coordination, “lost updates” and inconsistent reads can occur.DBMSs use locks (or MVCC with conflict detection) to serialize or validate writes.Concept / Approach:Yes—locking (especially pessimistic locking) prevents multiple writers from updating the same record at once. Even in MVCC systems, write-write conflicts are prevented or detected, and one transaction typically must wait or be rolled back to avoid corruption.Step-by-Step Solution:Identify conflict: two sessions intend to change the same row.Apply locking rule: acquire a write-intent lock; others block or validate later.Result: only one change is committed; the other is serialized or rejected.Verification / Alternative check:Simulate two concurrent UPDATEs under READ COMMITTED with row locks; the second updater waits until the first commits/rolls back.Why Other Options Are Wrong:Calling the statement invalid ignores the fundamental purpose of locking; restricting to table-level or certain engines is unnecessary.Common Pitfalls:Confusing read locks with write locks; assuming MVCC “removes” locking—it still coordinates writers.Final Answer:Valid statement

Question 16

Optimistic locking assumption: does it assume conflicts will occur frequently?

Accepted Answer

Introduction / Context:Two broad concurrency strategies exist: pessimistic locking (assume conflicts, lock early) and optimistic concurrency control (assume conflicts are rare, validate at commit). This question probes whether you know the core assumption behind optimistic locking.Given Data / Assumptions:Optimistic control uses version numbers, timestamps, or hashes to detect concurrent updates at commit time.Pessimistic locking places locks ahead of time to prevent conflicts.High-read, low-write workloads benefit from optimistic approaches.Concept / Approach:Optimistic locking assumes conflicts are unlikely; therefore, it avoids blocking locks during the transaction. At commit, it verifies that the record was not modified by another transaction since it was read. If changed, the update fails and must be retried.Step-by-Step Solution:Evaluate the statement: it claims optimistic locking assumes conflicts will occur.This actually describes pessimistic locking rationale.Thus, the statement is false.Verification / Alternative check:Check common implementations (ROWVERSION in SQL Server, xmin in PostgreSQL, ORMs with @Version): they perform a check at UPDATE/DELETE to detect rather than preempt conflicts.Why Other Options Are Wrong:Isolation level does not change the basic assumption; optimistic control is not limited to distributed systems.Common Pitfalls:Using optimistic control on hot rows with frequent writes can cause many retries; conversely, using pessimistic locking everywhere can cause contention and deadlocks.Final Answer:Invalid statement

Question 17

Transaction anomalies: reading uncommitted changes is called a “dirty read,” not a “filthy read.” Is the given statement correct?

Accepted Answer

Introduction / Context:ACID-compliant systems classify anomalies such as dirty reads, nonrepeatable reads, and phantom reads. Accurate terminology is crucial. The statement uses “filthy read” instead of the standard term “dirty read.”Given Data / Assumptions:A dirty read occurs when one transaction reads data modified by another transaction that has not yet committed.Dirty reads are typically possible only at the lowest isolation (READ UNCOMMITTED) or with special hints.The standard label across literature is “dirty read.”Concept / Approach:Although the definition in the sentence matches the phenomenon, the incorrect term makes the statement invalid in a correctness/terminology sense. Precision matters for exams and professional communication.Step-by-Step Solution:Identify the anomaly described: read of uncommitted data.Recall the standard name: “dirty read.”Compare with the given term: “filthy read” is nonstandard and incorrect.Therefore, the statement is invalid.Verification / Alternative check:Consult isolation level definitions: only “dirty read” appears alongside “nonrepeatable” and “phantom” in documentation and textbooks.Why Other Options Are Wrong:Vendor differences do not rename the anomaly; phantom reads are a different phenomenon (new rows matching a predicate appear between reads).Common Pitfalls:Mixing up dirty vs. nonrepeatable reads; assuming READ COMMITTED allows dirty reads (it does not).Final Answer:Invalid statement

Question 18

Transaction log contents: are after-change copies called “before images”?

Accepted Answer

Introduction / Context:Recovery systems use logs to reconstruct database state. Log records may include “before images” (state prior to change) and “after images” (state after change). This question checks whether you can distinguish the terminology.Given Data / Assumptions:Before image: the original value(s) prior to an operation; used for UNDO.After image: the resulting value(s) after the operation; used for REDO.Different DBMSs implement logical, physiological, or physical logging, but the naming is consistent.Concept / Approach:The statement calls after-change copies “before images,” which reverses the meaning. In logging strategies (e.g., ARIES), both before and after images can be present depending on the operation and logging mode.Step-by-Step Solution:Identify the claim: post-change copies are labeled “before images.”Recall definition: “before” is pre-change; “after” is post-change.Therefore, the statement is incorrect.Verification / Alternative check:Review REDO/UNDO logic: before image enables rollback; after image enables roll-forward after a crash.Why Other Options Are Wrong:Logging style (physical vs. logical) does not swap the names; page-level vs. row-level scope is unrelated to terminology.Common Pitfalls:Assuming every log always stores both images; some systems optimize and log only what is needed for recovery guarantees.Final Answer:Invalid statement

Question 19

Lost update problem definition: is it when User A reads data that come from a partial (uncommitted) transaction of User B?

Accepted Answer

Introduction / Context:Classic anomalies include dirty read, nonrepeatable read, phantom read, and lost update. Each has a precise definition. This question verifies whether you can accurately state what “lost update” means.Given Data / Assumptions:Dirty read: reading uncommitted data.Nonrepeatable read: seeing a row change between two reads in the same transaction.Lost update: two transactions update the same data; one overwrites the other without awareness.Concept / Approach:The statement provided describes a dirty or inconsistent read rather than a lost update. A lost update requires conflicting writes where one transaction’s update is effectively undone or overwritten by another committed update.Step-by-Step Solution:Compare definitions: “reads uncommitted” → dirty read; “overwritten writes” → lost update.The statement talks about User A reading data processed by part of User B’s transaction → that is dirty/inconsistent read.Therefore, this is not the lost update definition and the statement is invalid.Verification / Alternative check:Simulate two UPDATEs without proper isolation; observe last writer wins and one change is lost—this is the lost update scenario, not merely a read of uncommitted data.Why Other Options Are Wrong:Snapshot isolation actually prevents lost updates via write-write checks; equating with nonrepeatable read is incorrect.Common Pitfalls:Mixing up anomaly names; thinking any anomaly with two users is “lost update.”Final Answer:Invalid statement

Question 20

Who places “explicit” locks — the user or the DBMS? Are DBMS-placed locks called explicit?

Accepted Answer

Introduction / Context:Lock classification helps clarify who requested a lock. Explicit locks are requested directly by user/application commands; implicit locks are acquired automatically by the DBMS while enforcing isolation for DML. This question checks whether you can properly attribute the term “explicit.”Given Data / Assumptions:Examples of explicit locks: LOCK TABLE, SELECT … FOR UPDATE, application-level advisory locks.Examples of implicit locks: row/page/table locks acquired automatically during UPDATE/DELETE/INSERT.Terminology is consistent across most relational systems.Concept / Approach:Locks placed by the DBMS automatically are implicit, not explicit. The statement that “locks placed by the DBMS are explicit” is therefore incorrect.Step-by-Step Solution:Identify who issues the request: user command → explicit; system automatic → implicit.Apply to the statement: DBMS-placed locks are implicit.Thus, the statement is invalid.Verification / Alternative check:Trace locks during a simple UPDATE under READ COMMITTED; the DBMS acquires and releases locks implicitly without a user lock command.Why Other Options Are Wrong:Scope (row/table) and isolation level do not change explicit vs. implicit classification.Common Pitfalls:Assuming all locks you see in monitoring were explicitly requested; many are system-driven.Final Answer:Invalid statement

Managing Multiuser Databases Questions

Questions

Practice smarter