Lesson 1 — Operating Spine, Continuity, and Guiding Principles
What Chapter 6 manages
Data Storage and Operations is the design, implementation, and support of stored data so its value is maximized throughout the lifecycle. The chapter separates two responsibilities that often sit in the same DBA organization but answer different questions.
Database Technology Support
Think the engine/platform. What DBMS technology fits? How will it be installed, configured, patched, upgraded, monitored, supported, licensed, and kept technically viable?
Database Operations Support
Think the stored-data service. How will data be loaded, changed, backed up, recovered, retained, archived, purged, replicated, tuned, tested, migrated, and kept available?
Deciding clue: selecting/configuring the DBMS → Technology Support. Backup/recovery/performance/environments/data lifecycle → Operations Support.
Primary driver and three goals
The primary business driver is business continuity. If stored data is unavailable or corrupted, business operations can stop.
The operating target has three parts:
- Availability — data can be used when needed across its lifecycle.
- Integrity — data remains correct and trustworthy through transactions and operational change.
- Transaction performance — work completes within acceptable service expectations.
A database can fail the service even if only one leg is weak: fast but corrupt is bad; correct but unavailable is bad; available but unusably slow is bad.
Guiding principles
- Automate where useful. Repeated manual provisioning, deployment, monitoring, and database changes invite delay and error.
- Build with reuse in mind. Common interfaces, views, services, procedures, or other abstractions can reduce unnecessary application coupling to physical database details.
- Apply best practices appropriately. Standards are defaults, not blind project blockers. A justified exception can be acceptable if consequences and ownership are explicit.
- Connect standards to support requirements. SLAs and support agreements should state what the DBA function will and will not support when teams deviate from standards.
- Set DBA expectations early. Bring database/support concerns into project definition—not after release is almost ready.
Changed-fact drill
A team is choosing among DBMS products based on transaction support, scale, vendor support, and cost → Technology Support.
Now change one fact: the DBMS is already installed and the question concerns backup schedules and recovery tests → Operations Support.
Source: pp. 166–169.