You should know the sizes of your tables and indexes to understanding query and system behavior. At several stages of tuning work, you need size data to:
Understand statistics io reports for a specific query plan.
Chapter 35, “Using the set statistics Commands,” describes how to use statistics io to examine the I/O performed.
Understand the optimizer’s choice of query plan. Adaptive Server’s cost-based optimizer estimates the physical and logical I/O required for each possible access method and chooses the cheapest method. If you think a particular query plan is unusual, you can used dbcc traceon(302) to determine why the optimizer made the decision. This output includes page number estimates.
Determine object placement, based on the sizes of database objects and the expected I/O patterns on the objects. You can improve performance by distributing database objects across physical devices so that reads and writes to disk are evenly distributed.
Object placement is described in Chapter 5, “Controlling Physical Data Placement.”
Understand changes in performance. If objects grow, their performance characteristics can change. One example is a table that is heavily used and is usually 100 percent cached. If that table grows too large for its cache, queries that access the table can suddenly suffer poor performance. This is particularly true for joins requiring multiple scans.
Do capacity planning. Whether you are designing a new system or planning for growth of an existing system, you need to know the space requirements to plan for physical disks and memory needs.
Understand output from Adaptive Server Monitor and from sp_sysmon reports on physical I/O.
See the Adaptive Server System Administration Guide for more information on sizing.
