ref-sp-db-operationslisted

# Database Operations ## Purpose Keep a database trustworthy in production: correct under concurrency, fast enough for the real workload, recoverable after failure, and changeable without breaking. This skill owns **what happens to a schema once it exists**. It does not own the schema itself. Designing it is `ref-sp-db-schema-design`. ## When to use this skill - Planning transaction boundaries, isolation levels, or concurrency behavior. - Diagnosing lock contention, lost updates, inconsistent reads, or a slow query. - Choosing, justifying, or pruning indexes and storage layout. - Planning a schema migration, its rollback, and its behavior at production volume. - Reviewing whether backup and restore actually work, and how much work a failure may lose. - Separating transactional (OLTP) expectations from analytical (OLAP) reporting expectations. ## Scope boundaries - `ref-sp-db-schema-design` — entities, keys, constraints, normalization, and the physical design choices that flow from the model. Operations *tunes* what design *chose*. A fast query on a broken schema is still a bad design: fix it there, not here. - `ref-sp-db-nosql` — whether the workload belongs in a relational store at all. - `ref-sp-db-distributed` — fragmentation, replica placement, local vs global applications, and disconnected sync. Reach for it the moment topology becomes a first-class design concern rather than a deployment detail. - `ref-sp-db-security` — threat modeling, authorization, vie