For a new system, an analyst estimates storage by multiplying the expected row count by average row size, arriving at 500 GB, and proposes provisioning exactly that amount. What should the DBA point out about this estimate?
Select an answer to reveal the explanation.
Short Explanation
Rows are only part of the luggage. Indexes, logs, tempspace and breathing room all need a seat on the plane too. If you size for the raw data alone, you'll run out of space long before you planned.
Full Explanation
Raw data volume, calculated from row count and average row size, is only the starting point for database storage sizing. Indexes frequently add a substantial fraction of the table size, and sometimes more than the data itself in heavily indexed OLTP schemas. Transaction logs need room to hold activity between backups or truncation points and to absorb large batch operations. Temporary space is used for sorts, hash joins and index builds, and pages are rarely full, so fill factors and free-space reserves add overhead. Backups, snapshots or replicas placed on the same storage add even more. Saying indexes and logs live on the application server is wrong by architecture: they are database structures stored by the database engine on the database server's storage. Halving the estimate assumes universal default compression, which is not a safe assumption across engines and editions; compression must be configured and measured before it is planned around. Claiming logs disappear at commit misunderstands logging, since records are retained until a checkpoint, backup or recovery requirement allows reuse of that space. Exam caveat: combine this with resource projection for growth. Operational check: load a representative sample, measure total data, index and log size, and scale from the measured ratio.