Combined Bank Assistant Maintenance Engineer Exam 8 May 2026 — Question Solution | সমন্বিত ব্যাংক (ব্যাংকার্স সিলেকশন কমিটি) সহকারী রক্ষণাবেক্ষণ প্রকৌশলী নিয়োগ পরীক্ষা ২০২৬ — প্রশ্ন সমাধান

Answer: usable capacity = (n − 1) × drive size = (5 − 1) × 4 TB = 16 TB. It is not 20 TB because RAID 5 spends one drive's worth of space (4 TB) on parity, and that parity is spread across all five drives.

What RAID 5 is

RAID 5 is block-level striping with distributed parity. Data is split into blocks and written across the drives in stripes. In every stripe, one block is a parity block calculated from the other blocks. The parity block moves to a different drive in each stripe, so no single drive becomes a parity bottleneck (a dedicated parity drive is RAID 4, not RAID 5). RAID 5 needs at least 3 drives and survives the failure of any one drive.

Stripe layout with five drives (P = parity)

Stripe	Drive 1	Drive 2	Drive 3	Drive 4	Drive 5
1	A1	A2	A3	A4	Ap
2	B1	B2	B3	Bp	B4
3	C1	C2	Cp	C3	C4
4	D1	Dp	D2	D3	D4
5	Ep	E1	E2	E3	E4

In every stripe, 4 of the 5 blocks hold data and 1 holds parity. Over the whole array, therefore, 1/5 of the raw space is parity.

Calculation

Item	Value
Raw capacity	5 × 4 TB = 20 TB
Space used by parity	1 drive's worth = 4 TB (1/5 of raw)
Usable capacity	20 − 4 = 16 TB
Storage efficiency	(n − 1) ÷ n = 4 ÷ 5 = 80%
Drive failures tolerated	1
Shown by the operating system	16 × 10¹² bytes ÷ 2⁴⁰ ≈ 14.55 TiB (drive makers use decimal TB)

How parity protects the data (XOR)

Parity is the bitwise XOR of the data blocks in a stripe. Example with one byte from each data drive:

Block	Value
A1	10110010
A2	01101100
A3	11100001
A4	00011111
Ap = A1 ⊕ A2 ⊕ A3 ⊕ A4	00100000

If Drive 3 fails, its block is rebuilt from the survivors: A1 ⊕ A2 ⊕ A4 ⊕ Ap = 11100001 = A3 ✓. That rebuild ability is exactly what the "missing" 4 TB pays for.

flowchart LR
  D["Data blocks A1 to A4"] --> X["XOR"]
  X --> P["Parity block Ap"]
  F["Drive 3 fails"] --> RB["Rebuild: A1 ⊕ A2 ⊕ A4 ⊕ Ap"]
  P --> RB
  RB --> A3["A3 restored"]

Practical points for the maintenance engineer

• Write penalty: each small write needs 4 I/Os (read old data, read old parity, write new data, write new parity), so RAID 5 is slower for write-heavy loads.
• Degraded mode and rebuild risk: after one failure the array works without protection. Rebuilding a 4 TB drive takes hours; a second failure or an unreadable sector during the rebuild can lose the array. For critical data, use RAID 6 (two parity blocks: (5 − 2) × 4 = 12 TB, survives 2 failures) or keep a hot spare.
• RAID is not a backup: it does not protect against deletion, ransomware or corruption, so regular backups are still required.

Level (5 × 4 TB)	Usable	Failures tolerated
RAID 0	20 TB	0
RAID 5	16 TB	1
RAID 6	12 TB	2

Exam tip: RAID 5 usable = (n − 1) × smallest drive; one drive's capacity goes to distributed parity, which is why 20 TB raw gives 16 TB usable.

(a) What Consistency guarantees

Consistency (the C in ACID) guarantees that a transaction takes the database from one valid state to another valid state. Every integrity rule — constraints (CHECK, NOT NULL, UNIQUE, FOREIGN KEY), triggers and business rules — holds before and after the transaction. If any statement would break a rule, the DBMS rejects it and the transaction is rolled back, so an invalid state is never committed.

In a fund transfer of Tk 3,000 from account SA-1001 to SA-1002:

State	SA-1001	SA-1002	Total
Before	5,000	1,000	6,000
After commit	2,000	4,000	6,000

Consistency guarantees that:

• Money is neither created nor lost: the debit equals the credit, so the total stays 6,000.
• No rule is broken: no balance goes negative, both account numbers exist (foreign keys), and the amount is positive.
• No half state survives: if the transfer cannot finish validly, both updates are undone (consistency works together with atomicity).

Consistency is a joint duty: the DBMS enforces the declared constraints, and the application must code the business logic correctly (for example, debiting and crediting the same amount).

(b) SQL constraint so current_balance never drops below zero

The required clause is a CHECK constraint:

CONSTRAINT chk_current_balance_nonneg CHECK (current_balance >= 0)

In the table definition:

CREATE TABLE Savings_Accounts (
    account_no       VARCHAR(20)    PRIMARY KEY,
    holder_name      VARCHAR(100)   NOT NULL,
    current_balance  DECIMAL(15,2)  NOT NULL DEFAULT 0,
    CONSTRAINT chk_current_balance_nonneg CHECK (current_balance >= 0)
);

For a table that already exists:

ALTER TABLE Savings_Accounts
    ADD CONSTRAINT chk_current_balance_nonneg CHECK (current_balance >= 0);

• >= 0 (not > 0) is used because a zero balance is allowed; only a negative balance is forbidden.
• NOT NULL is needed as well: a CHECK condition that evaluates to UNKNOWN (because the value is NULL) is treated as satisfied.
• DECIMAL (not FLOAT) keeps money exact.

What happens on an overdraw (SA-1001 now holds 2,000; a 7,000 transfer is attempted). The transfer code runs COMMIT only if both updates succeed; on any error it runs ROLLBACK:

BEGIN TRANSACTION;
UPDATE Savings_Accounts SET current_balance = current_balance - 7000
 WHERE account_no = 'SA-1001';   -- would become -5000: CHECK fails
-- error raised here, so the code skips the credit and runs:
ROLLBACK;
-- (on success it would run the credit to SA-1002 and then COMMIT)

Result:

Error: CHECK constraint failed: chk_current_balance_nonneg
-> ROLLBACK
SA-1001 = 2000.00, SA-1002 = 4000.00 (both unchanged)

Why the explicit ROLLBACK matters: a constraint error does not always cancel the whole transaction by itself. PostgreSQL marks the whole transaction as failed, so a later COMMIT only rolls back. Oracle, MySQL, SQLite and SQL Server (by default) undo only the failing statement and keep the transaction open: if a script carried on, the 7,000 credit to SA-1002 would still be applied and committed, creating money. So the transfer must stop at the first error and roll back (for example, a TRY…CATCH block, or SET XACT_ABORT ON in SQL Server).

flowchart LR
  S["Valid state: total 6,000"] --> T["Transfer transaction"]
  T --> C{"All constraints hold?"}
  C -->|"Yes"| OK["COMMIT: new valid state, total 6,000"]
  C -->|"No: balance < 0"| RB["ROLLBACK: old valid state kept"]

Note: PostgreSQL, Oracle and SQL Server enforce CHECK constraints; MySQL enforces them from version 8.0.16 (older versions parsed but ignored them).

Exam tip: Consistency = valid state → valid state, enforced by constraints; the exact clause is CHECK (current_balance >= 0).