WRT 3: (how to make update stats progress faster):
It depends of course on what resources are available to your database server. Update stats is both CPU intensive as well as Disk IO intensive. So, if you have many CPU's/engines/threads, and many disk devices/controllers , then it would be smart to use as many of those resources as possible (while leaving enough processing power for other needs during your update stats timeframe).
So, let's assume your table (mytable) has the following indexes:
create index index_one on mytable( a, b, c )
create index index_two on mytable( d, c )
create index index_three on mytable ( d, b, c, a )
If you have multiple engines/threads, it would be the most inefficient (and most time consuming) to use:
> update index statistics mytable
It would be better to start multiple connections each with it's own individual "part" of the above command.
But, It would also be a mistake to break it down like this:
(connection 1) > update table statistics mytable
(connection 2) > update index statistics mytable index_one
(connection 3) > update index statistics mytable index_two
(connection 4) > update index statistics mytable index_three
A mistake because statistics are gathered for column "c" three times,
columns "a","b","d" twice each. Worse was that in older (pre-15.0.2) versions of ASE,
non-leading columns for each "update index statistics" command were scanned
by the accessing the base table (data pages). For more recent versions the smallest index is used to gather stats.
The general command "update index statistics mytable" would be equivalent to a serial execution (using one engine/thread) of:
> update table statistics mytable
> update statistics mytable index_one
> update statistics mytable index_two
> update statistics mytable index_three
> update statistics mytable(b)
> update statistics mytable(c)
for the last two commands, the smallest index is used to scan all values of
"b", and "c" respectively.
If you have multiple engines (say 6 engines?), then you might be better
off separating this into 6 concurrent executions of each of the above
statements so that ASE keeps 6 engines busy working maximizing your
throughput and making update stats job run MUCH faster.
Better yet is if these indexes reside on separate storage devices so that device IO can be maximized.
My point is that you should experiment with various combinations of
concurrent "update statistics" jobs to see if you can accomplish more (and
faster) with multiple engines instead of executing a generic monolithic "update index statistics mytable" which only utilizes one engine/thread at a time.
