New table without statistics returns invalid number of rows

Question

Hi,
I've been searching for a while now for an explanation for the following "problem"
We have an Oracle 11.1.0.7 database on AIX5.3
In this database we have two tables, called KRT_PRODUCTS_INFO and KRT_STRUCTURES_INFO ( the table name don't really matter ).
The scenario is as following:
If we recreate these tables like:
CREATE TABLE KRT_PRODUCT_INFO_BUP AS SELECT * FROM KRT_PRODUCT_INFO;
DROP TABLE KRT_PRODUCT_INFO CASCADE CONSTRAINTS;
CREATE TABLE KRT_PRODUCT_INFO (...) TABLESPACE PIM_DATA NOLOGGING NOCOMPRESS NOCACHE NOPARALLEL MONITORING;
CREATE INDEX KRT_PRODUCT_INFO_X1 ON KRT_PRODUCT_INFO (PRODUCT_NUMBER) NOLOGGING TABLESPACE PIM_DATA NOPARALLEL;
CREATE INDEX KRT_PRODUCT_INFO_X2 ON KRT_PRODUCT_INFO (PIM_ARTICLEREVISIONID) NOLOGGING TABLESPACE PIM_DATA NOPARALLEL;
INSERT INTO KRT_PRODUCT_INFO (SELECT * FROM KRT_PRODUCT_INFO_BUP);
COMMIT;
CREATE TABLE KRT_STRUCTURE_INFO_BUP AS SELECT * FROM KRT_STRUCTURE_INFO;
DROP TABLE KRT_STRUCTURE_INFO CASCADE CONSTRAINTS;
CREATE TABLE KRT_STRUCTURE_INFO (...) TABLESPACE PIM_DATA NOLOGGING NOCOMPRESS NOCACHE NOPARALLEL MONITORING;
CREATE INDEX KRT_STRUCTURES_X1 ON KRT_STRUCTURE_INFO (STRUCTURE_GRP_REV_ID) NOLOGGING TABLESPACE PIM_DATA NOPARALLEL;
CREATE INDEX KRT_STRUCTURES_X2 ON KRT_STRUCTURE_INFO (STRUCTURE_GRP_IDENTIFIER) NOLOGGING TABLESPACE PIM_DATA NOPARALLEL;
CREATE INDEX KRT_STRUCTURES_X3 ON KRT_STRUCTURE_INFO (STRUCTURE_GRP_ID) NOLOGGING TABLESPACE PIM_DATA NOPARALLEL;
INSERT INTO KRT_STRUCTURE_INFO (SELECT * FROM KRT_STRUCTURE_INFO_BUP);
COMMIT;
and we run a complex query with these two tables, this query only return a couple of rows ( exactly 24 !!! )
If we however generate statistics on these tables after creation, the correct number of rows is returned, being 1.167.991 rows
The statistics are gathered using:
BEGIN
SYS.DBMS_STATS.GATHER_TABLE_STATS (
OwnName => 'PIM_KRG'
,TabName => 'KRT_PRODUCT_INFO'
,Estimate_Percent => NULL
,Method_Opt => 'FOR ALL COLUMNS SIZE REPEAT '
,Degree => NULL
,Cascade => TRUE
,No_Invalidate => FALSE);
END;
BEGIN
SYS.DBMS_STATS.GATHER_TABLE_STATS (
OwnName => 'PIM_KRG'
,TabName => 'KRT_STRUCTURE_INFO'
,Estimate_Percent => NULL
,Method_Opt => 'FOR ALL COLUMNS SIZE REPEAT '
,Degree => NULL
,Cascade => TRUE
,No_Invalidate => FALSE);
END;
/I can imagine that the 'plan' for the query used is wrong because of missing statistics.
But I can't imagine that it would actually return an incorrect number of rows.
I tested this behaviour in Toad and sqlplus ( first thought it was Toad ), and both behave the same.
Another fact is, that the "problem" is NOT reproducable on our TEST environment, that runs on Oracle 11.1.0.7 on Windows2008
Just to be sure this is the "complex" query used. It is not developed by me, and I think it looks somewhat strange but that shouldn't matter:
SELECT sr."Identifier" STRUCTURE_IDENTIFIER
, ar_i."Identifier" ITEM_NUMBER
, SUM (REPLACE (NVL (s.HIDE_LE10, 0) + NVL (p.HIDE_LE10, 0), 2, 1))
hide_le10
, SUM (REPLACE (NVL (s.HIDE_LE30, 0) + NVL (p.HIDE_LE30, 0), 2, 1))
hide_le30
, SUM (REPLACE (NVL (s.HIDE_LE40, 0) + NVL (p.HIDE_LE40, 0), 2, 1))
hide_le40
, SUM (REPLACE (NVL (s.HIDE_LE50, 0) + NVL (p.HIDE_LE50, 0), 2, 1))
hide_le50
, SUM (REPLACE (NVL (s.HIDE_LE55, 0) + NVL (p.HIDE_LE55, 0), 2, 1))
hide_le55
, SUM (REPLACE (NVL (s.HIDE_LE60, 0) + NVL (p.HIDE_LE60, 0), 2, 1))
hide_le60
, SUM (REPLACE (NVL (s.HIDE_LE70, 0) + NVL (p.HIDE_LE70, 0), 2, 1))
hide_le70
, SUM (REPLACE (NVL (s.HIDE_LE75, 0) + NVL (p.HIDE_LE75, 0), 2, 1))
hide_le75
, SUM (REPLACE (NVL (s.HIDE_LE58, 0) + NVL (p.HIDE_LE58, 0), 2, 1))
hide_le58
, SUM (REPLACE (NVL (s.HIDE_LE80, 0) + NVL (p.HIDE_LE80, 0), 2, 1))
hide_le80
, SUM (REPLACE (NVL (s.HIDE_LE90, 0) + NVL (p.HIDE_LE90, 0), 2, 1))
hide_le90
, SUM (REPLACE (NVL (s.HIDE_LE92, 0) + NVL (p.HIDE_LE92, 0), 2, 1))
hide_le92
, SUM (REPLACE (NVL (s.HIDE_LE94, 0) + NVL (p.HIDE_LE94, 0), 2, 1))
hide_le94
, SUM (REPLACE (NVL (s.HIDE_LE96, 0) + NVL (p.HIDE_LE96, 0), 2, 1))
hide_le96
, COUNT (*) cnt
FROM KRAMP_HPM_MAIN."StructureRevision" sr
, KRAMP_HPM_MAIN."StructureGroupRevision" sgr
, KRAMP_HPM_MASTER."ArticleStructureMap" asm
, KRAMP_HPM_MASTER."ArticleRevision" ar_p
, KRAMP_HPM_MASTER."ArticleDetail" ad_p
, KRAMP_HPM_MASTER."ArticleRevision" ar_i
, KRAMP_HPM_MASTER."ArticleDetail" ad_i
, KRAMP_HPM_MASTER."ArticleReference" ar
, KRT_STRUCTURE_INFO s
, KRT_PRODUCT_INFO p
WHERE sr."StructureID" = sgr."StructureID"
AND sgr."StructureGroupID" = asm."StructureGroupID"
AND ar_p."ID" = asm."ArticleRevisionID"
AND ar_p."ID" = ad_p."ArticleRevisionID"
AND ad_p."Res_Text100_02" = 'PRODUCT'
AND ar_i."ID" = ad_i."ArticleRevisionID"
AND ad_i."Res_Text100_02" = 'ARTICLE'
AND ar."ArticleRevisionID" = ar_p."ID"
AND ar."ReferencedSupplierAID" = ar_i."Identifier"
AND s.STRUCTURE_GRP_REV_ID = sgr."ID"
AND p.PIM_ARTICLEREVISIONID = ar_p."ID"
GROUP BY sr."Identifier", ar_i."Identifier";Any ideas are welcome..
Thanks
FJFranken

Answer 1

Hemant K Chitale wrote:
These two tables are in the PIM_KRG schema while the other tables in the query are distributed across two other schemas "KRAMP_HPM_MAIN" and "KRAMP_HPM_MASTER" ?
Do you happen to have the same table names occurring in multiple schemas - the query is then referencing the data in the wrong schema ?
Hemant K ChitaleHi,
This is not the case. The KRAMP_HPM schema's are application dedicated schema's
And this also then does not explain why the results are correct after generating statistics.
Anyway thanks for the tip.
FJFranken