Skip to content

Diagnostic Key DS6-043–056

DS6-043 — C · Sharding

Sharding isolates chunks that can be updated independently. Replication copies; federation presents autonomous databases together; archive moves old data.
Source: p. 188 · Confusion: sharding vs replication.

DS6-044 — D · Evaluate strategic DBMS by total fit

Evaluate technical fit plus organizational/vendor factors: architecture, volume/velocity, workload, functions, platform, tools, performance, scale, resiliency, risk appetite, skills, TCO, support, reputation, references. Feature count, license-only decisions, and one-DBMS-for-all are weaker.
Source: pp. 189–190 · Confusion: technical fit vs vendor/TCO factors.

DS6-045 — A · Complete storage estimate

Include indexes, logs, redundant images/mirrors, and future growth—not only table data. Training/support costs are relevant elsewhere but do not complete capacity sizing.
Source: p. 191 · Confusion: complete vs incomplete capacity estimate.

DS6-046 — B · Time-based usage pattern

Month-end peaks and weekend valleys are predictable workload timing patterns useful for resource controls/scheduling. Federation, schema-on-read, and audit do not explain the symptom.
Source: p. 191 · Confusion: usage pattern vs capacity/access.

DS6-047 — C · Business criticality

Recovery order follows business criticality—essential operational databases first, less critical later, and some copies may not need restoration. Size, name, and DBMS age do not determine business priority.
Source: p. 192 · Confusion: critical vs non-critical recovery.

DS6-048 — D · Recoverability not proven

Backup job success proves copy creation, not restoration. Test recovery on suitable non-production/failover infrastructure. Cold backup and federation do not solve the proof gap.
Source: pp. 192–193 · Confusion: backup vs tested recovery.

DS6-049 — A · Physical vs functional configuration audit

Physical audit asks whether installed configuration matches detailed design; functional audit asks whether required functional/performance attributes are achieved. B reverses them; licensing/retention are different concerns.
Source: pp. 194–195 · Confusion: physical vs functional audit.

DS6-050 — B · Implement Physical Data Models

Adding DBMS-specific indexes, constraints, partitions, capacity, and storage allocation is physical-model implementation. Technology evaluation happens earlier; Test Data and asset tracking are separate.
Source: pp. 195–196 · Confusion: implement PDM vs technology evaluation.

DS6-051 — C · Performance = availability + speed

A database must be available before its response time has business value; Chapter 6 treats both as interdependent facets. Availability alone is not the only metric.
Source: p. 196 · Confusion: availability vs speed.

DS6-052 — D · Stale/inaccurate statistics after volatility

Heavy insert/delete activity can make statistics inaccurate and lead the optimizer to poor plans. Federation, retention, and schema ownership do not match the clue.
Source: pp. 199–200 · Confusion: stale statistics vs other performance causes.

DS6-053 — A · Protected test-data approach

Use appropriate sample/generated data and mask protected Production-derived fields when restrictions require it. Non-production does not automatically remove security/privacy obligations.
Source: pp. 201–202 · Confusion: test data vs protected Production data.

DS6-054 — B · Data migration

Migration transfers data between storage types, formats, or systems with as little conceptual change as possible. Semantic combination = integration; simultaneous copies = replication; irreversible deletion = purge.
Source: p. 202 · Confusion: migration vs integration / replication.

DS6-055 — C · Controlled upgrade path

Assess data-loss and technology-readiness risk, test in lower environments, use controlled scripts/processes, and promote Production last. Vendor support does not replace readiness; direct/manual Production change is riskier.
Source: pp. 203–205 · Confusion: lower-environment testing / scripts / readiness.

DS6-056 — D · Service metric + Data Audit

Average issue-resolution time belongs to Service metrics; contractual storage compliance calls for a Data Audit. Validation is quality/usability acceptance; Performance and Operational metrics answer different questions.
Source: pp. 206–208 · Confusion: Service metrics vs audit vs validation.

← Answers 029–042 · Coverage →