gathering stats is equivalent to running a series of full table scans on your tables. In terms of CPU, if you run it serially, then it will only use a single core on your server. In terms of I/O, it depends on what bandwidth your storage can support.

Obviously we recommend running it during as quiet a period as possible to minimise impact, but assuming your using the defaults, it will only gather stats on those objects that need it (ie, are stale or missing statistics).

And don't forget, you generally don't need to get over obsessive with statistics. A table going from 100 million rows to 150 million rows is still just "a big table", so optimizer plans are typically unlikely to change much. Often it is the changes in *smaller* tables (from 10 rows to 1000 rows) that have a bigger impact on plans, and these are very cheap to gather stats on .

Other options include if you have a standby database, you can gather stats on that database and import them into your production database. But if gathering stats is going to push you "over the edge" in terms of server resources, it strikes me that you are running very very close to the limit anyway?