Storage Structures, Tablespaces, and Schema Objects
This domain tests how physical storage structures and logical schema objects interact, and how NDB maps them onto Nutanix storage constructs such as vDisks, volume groups, and storage policies.
Storage layers
- Engine files include datafiles, redo/transaction logs, control files, and archive logs. Oracle adds tablespaces (SYSTEM, SYSAUX, UNDO, TEMP, USERS); SQL Server uses filegroups and files; PostgreSQL uses tablespaces and relation files.
- Within a tablespace, a segment is composed of extents, which are composed of blocks. Extent sizing affects allocation and fragmentation.
- Schema objects include tables, indexes, views, sequences, synonyms, and constraints. Their placement determines I/O isolation and recoverability.
- NDB can present storage as VM vDisks or Nutanix Volumes-backed volume groups; snapshots are coordinated at the storage layer.
Worked example
A high-write OLTP table and its indexes generate random I/O, while archive logs are sequential. Place data and indexes in a tablespace backed by a storage policy suited to random I/O, and keep redo/archive logs on separate vDisks or volume groups. Reasoning: separating sequential log writes from random data reads reduces contention and makes log shipping or backup streams independent of datafile scans. If the table grows by range partitions, give each partition its own tablespace so old partitions can be archived without touching current data.
Traps
- Placing TEMP, UNDO, and redo on the same busy datastore.
- Assuming thin provisioning always reclaims space after a large delete.
- Creating many small datafiles instead of correctly sized ones.
- Forgetting that indexes consume the same tablespace quota as tables.