cancel
Showing results for 
Search instead for 
Did you mean: 

Statistics update and table sizes

Former Member
0 Kudos

Hi!

I'm a little confused about how MaxDB determines the sizes of tables. According to [ SAP help|http://help.sap.com/saphelp_nw70ehp2/helpdata/en/c2/36c5067754044db2b91b00ba60b36a/frameset.htm], by scheduling the update statistics job in DB13 will update the table sizes.

Now, we have the jobs " Mark tables for statistics update" and "Update statistics for marked tables" running every day and we also have the DETERMINE TABLE SIZES jobs (report RSADAT6M) jobs running every week.

My question is: is the DETERMINE TABLE SIZES job unnecessary then?

Thanks,

Peter

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Thanks for the answers!

lbreddemann
Active Contributor
0 Kudos

> I'm a little confused about how MaxDB determines the sizes of tables. According to [ SAP help|http://help.sap.com/saphelp_nw70ehp2/helpdata/en/c2/36c5067754044db2b91b00ba60b36a/frameset.htm], by scheduling the update statistics job in DB13 will update the table sizes.

> Now, we have the jobs " Mark tables for statistics update" and "Update statistics for marked tables" running every day and we also have the DETERMINE TABLE SIZES jobs (report RSADAT6M) jobs running every week.

> My question is: is the DETERMINE TABLE SIZES job unnecessary then?

This latter job is used to enable space usage history (table growth etc.). It's a CCMS thing - not a MaxDB one.

So better leave it enabled.

The statistics jobs are there to enable the join optimizer to do it's job - so you leave this job in place as well.

The only connection between these two jobs is that the table sizes report used to use the optimizer statistics

In the older days (before the filedirectory counters where implemented) figuring out how large a table is, was rather expensive.

To save time here, the developers decided to just use the data collected by the statistics run.

regards,

Lars

adrian_dorn
Active Participant
0 Kudos

My question is: is the DETERMINE TABLE SIZES job unnecessary then?

>

This latter job is used to enable space usage history (table growth etc.). It's a CCMS thing - not a MaxDB one. So better leave it enabled.

Just a short comment on that:

It is not strictly obligatory to keep it enabled. But if you disable it you would lose the nice feature in transaction DB59 and DBACOCKPIT of getting all kind of statistics on table sizes, e.g., comparing table sizes between two given dates or getting a hitlist of the biggest tables on a given date.