AFKO without CBO statistics

[Ganimede-Dignan]

Hi,

in a ECC 6.0 with Oracle 10.2.04 on Solaris 10 SPARC box, AFKO table is without statistics. This system is just installed as hom-sys-copy, during Sapinst statistics was performed and all other tables have got statistics.

We have already try to calculate statistics with RSANAORA report with collect. also try delete and then collect without success. RSANAORA ends in few seconds with collect.

If we use BRTOOLS we have same results... but if we use:

ANALYZE TABLE AFKO COMPUTE STATISTICS;

AFKO have statistics

Have you got any idea?

Regards.

[former_member524429 · Accepted solution]

Hi,

Please refer the Following SAP Notes to get more information.

[Note 122718 - CBO: Tables with special treatment|https://service.sap.com/sap/support/notes/122718]

[Note 1020260 - Delivery of Oracle statistics|https://service.sap.com/sap/support/notes/1020260]

Regards,

Bhavik G. Shroff

[fidel_vales]

Hi,

even when the issue is already "solved" it is possible that the DBSTATC table in your system contains "wrong" information.

In Oracle 10g ALL tables are supposed to have statistics, the Oracle Rule base optimizer is not supported anymore. For that reason, the control table DBSTATC has to be initialized.

I assume that you have an entry in this table that causes BRCONNECT not to calculate statistics on this (and may be other) tables.

Please, review the table, there should not be any entry with the "active" field set to "N" or "R". If there are tables with such status someone should know the reason (or the upgrade to 10g has not been done following the SAP upgrade guide). You can initialize it as mentioned on the 10g upgrade guide with the script updDBSTATC10.sql from note 819830.

[Ganimede-Dignan]

Hi,

source system has DBSTATC in OK status, target system, that builded of a system copy based on export/import, hasen't DBSTATC in OK status. So, now it's hardly because we haven't source system abailable.

Regards.

[fidel_vales]

If DBSTATC is OK on the source and NOT OK on the target and you did a homogeneus system copy using backup/restore that means that someone has changed this table.

Find out who and why it was changed.

As mentioned, in 10g ALL tables must have statistics

[Ganimede-Dignan]

a system copy based on export/import and not on backup/restore.

Regards.

[fidel_vales]

>

> a system copy based on export/import and not on backup/restore.
> 
> Regards.

I'm not 100% sure if the exp/imp done with R3LOAD also transfer the content of this table or not (I use backup/restore)

In any case, you should review the table in all your 10g systems to avoid similar issues on other systems/other tables.