Number range query causes repeated scan by index

I have a query that seems to repeatedly call an index scan on a table for reasons I'm not sure about. Anyone know why it would be doing the index scan on totaldwellingarea in the dimensions table (DIMEN_PID_TDWELLAREA) repeatedly? This only seems to happen when I put on the range clause d.totaldwellingarea between scr.lowvalue and scr.highvalue.
I am using Oracle version 9.2.0.3.
select d.propertyid,d.totaldwellingarea, e.size_, scr.size_
from eqid e, dimensions d, brt_eval.size_code_ranges scr
where e.style not in ('1','A','G','L') and e.size_ = '0'
and d.propertyid = e.propertyid and e.style = scr.style and d.totaldwellingarea between scr.lowvalue and scr.highvalue;
CREATE
TABLE "BRT_ADMIN"."EQID"
    "PROPERTYID"   VARCHAR2(20 BYTE) NOT NULL ENABLE,
    "EQID"         CHAR(10 BYTE),
    "ZONE_"        CHAR(1 BYTE),
    "AREA"         CHAR(1 BYTE),
    "GROUP_"       CHAR(1 BYTE),
    "GMA"          CHAR(1 BYTE),
    "STYLE"        CHAR(1 BYTE),
    "FLOORPLAN"    CHAR(1 BYTE),
    "BLDGCODEABBR" CHAR(1 BYTE),
    "SIZE_"        CHAR(1 BYTE),
    "CONDITION"    CHAR(1 BYTE),
    "SUBGROUP"     CHAR(1 BYTE),
    "UPDATED_BY"   VARCHAR2(10 BYTE),
    CONSTRAINT "EQID_PK" PRIMARY KEY ("PROPERTYID") USING INDEX
    CONSTRAINT "EQID_PROPERTIES_FK1" FOREIGN KEY ("PROPERTYID") REFERENCES
    "BRT_ADMIN"."PROPERTIES" ("PROPERTYID") DISABLE
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('3734003158','E241RJR440','E','2','4','1','R','J','R','4','4','0','274892');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('5428001913','H113TMH330','H','1','1','3','T','M','H','3','3','0','263579');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('8798001037','J423DX0440','J','4','2','3','D','X','0','4','4','0','SYSTEM');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('6924000909','L423LR0000','L','4','2','3','L','R','0','0','0','0','275251');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('81640006040000304','P142223240','P','1','4','2','2','2','3','2','4','0','SYSTEM');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('6828004705','M812IW3340','M','8','1','2','I','W','3','3','4','0','275281');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('3622002125','K212RJO340','K','2','1','2','R','J','O','3','4','0','TEMP001');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('7492002946','H513RJO250','H','5','1','3','R','J','O','2','5','0','276022');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('2561002635','A221MOW340','A','2','2','1','M','O','W','3','4','0','275464');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('7380002035','P612MRU530','P','6','1','2','M','R','U','5','3','0','TEMP002');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('8396000929','J211RJO340','J','2','1','1','R','J','O','3','4','0','SYSTEM');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('8902001921','B123RJO340','B','1','2','3','R','J','O','3','4','0','272144');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('5094000612','L142RJR340','L','1','4','2','R','J','R','3','4','0','225293');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('8803005315','L312TMH440','L','3','1','2','T','M','H','4','4','0','225293');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('5378004026','D121MNU140','D','1','2','1','M','N','U','1','4','0','134965');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('5414005625','L311RJR340','L','3','1','1','R','J','R','3','4','0','275251');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('6286005917','E323RJR240','E','3','2','3','R','J','R','2','4','0','274951');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('7824000540','E314SE0140','E','3','1','4','S','E','0','1','4','0','274951');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('3200001829','H525LR0000','H','5','2','5','L','R','0','0','0','0','248930');
Insert into EXPORT_TABLE (PROPERTYID,EQID,ZONE_,AREA,GROUP_,GMA,STYLE,FLOORPLAN,BLDGCODEABBR,SIZE_,CONDITION,SUBGROUP,UPDATED_BY) values ('1102002714','G314MPW240','G','3','1','4','M','P','W','2','4','0','250794');
CREATE
TABLE "BRT_ADMIN"."DIMENSIONS"
    "PROPERTYID" VARCHAR2(20 BYTE),
    "DIMENSIONID" NUMBER(38,0),
    "LANDDATE" DATE,
    "BLDGDATE" DATE,
    "PROCESSDATE" DATE,
    "INPUTUSER"         VARCHAR2(100 BYTE),
    "PLOTFRONT"         NUMBER(38,3),
    "PLOTDEPTH"         NUMBER(38,3),
    "PLOTSQFT"          NUMBER(38,3),
    "TOTALDWELLINGAREA" NUMBER(38,3),
    "TOTALFLOOR"        NUMBER(38,3),
    "SHAPE"             CHAR(1 BYTE),
    "GARAGE"            VARCHAR2(2 BYTE),
    CONSTRAINT "DIMENSIONS_PK" PRIMARY KEY ("DIMENSIONID") USING INDEX
CREATE
    INDEX "BRT_ADMIN"."DIMEN_PID_TDWELLAREA" ON "BRT_ADMIN"."DIMENSIONS"
      "PROPERTYID",
      "TOTALDWELLINGAREA"
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('8318000324',506808,null,to_date('01-JUN-2001 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('19-JUN-2001 12:00 AM','DD-MON-YYYY HH:MI AM'),'DOMENIC J. DEMURO',15.5,56,868,1200,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('8814000708',336134,null,to_date('01-JUL-1999 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('30-JUL-1999 12:00 AM','DD-MON-YYYY HH:MI AM'),'margaret jimenez',16,69.29,1108.64,2265,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('8791002638',231697,null,null,to_date('29-OCT-2004 12:00 AM','DD-
MON-YYYY HH:MI AM'),'DMEB020',15,65.38,980.7,0,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('6138000961',409453,to_date('01-AUG-2004 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('01-AUG-2002 12:00 AM','DD-MON-YYYY HH:MI AM'),to_date('18-AUG-2004 12:00 AM','DD-MON-YYYY HH:MI AM'),'DMEB017',14.75,78.5,1157.87,1357,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('8576002721',154908,null,null,to_date('29-OCT-2004 12:00 AM','DD-
MON-YYYY HH:MI AM'),'DMEB020',12,72.99,875.88,0,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('3851000509',441426,to_date('01-AUG-2004 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('01-NOV-2003 12:00 AM','DD-MON-YYYY HH:MI AM'),to_date('18-AUG-2004 12:00 AM','DD-MON-YYYY HH:MI AM'),'DMEB017',63.94,97.96,6264,2358,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('2889011105',498582,null,to_date('01-AUG-2000 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('14-AUG-2000 12:00 AM','DD-MON-YYYY HH:MI AM'),'ANTHONY CELLO',19.92,102.16,2035.02,1400,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('6960000520',535448,to_date('30-DEC-2011 12:00 AM','DD-MON-YYYY
HH:MI AM'),null,to_date('30-DEC-2011 12:00 AM','DD-MON-YYYY HH:MI AM'),'Donna Dirscherl',50,209.33,10342,0,0,'A','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('8902000005',398306,null,to_date('01-JUL-2001 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('11-JUL-2001 12:00 AM','DD-MON-YYYY HH:MI AM'),'BERNICE murphy',40,98,3920,7040,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('4624001130',341318,null,to_date('01-FEB-2001 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('27-FEB-2001 12:00 AM','DD-MON-YYYY HH:MI AM'),'JANINE TRAVALINA',15.96,66,1053.36,960,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('2798005812',459363,null,to_date('01-JAN-2001 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('19-JAN-2001 12:00 AM','DD-MON-YYYY HH:MI AM'),'ANTHONY D ELETTO',15.5,60,930,1112,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('1940000212000008A',500949,null,to_date('01-NOV-2010 12:00 AM','DD-
MON-YYYY HH:MI AM'),to_date('02-NOV-2010 12:00 AM','DD-MON-YYYY HH:MI AM'),'GERALDINE WHITE',0,0,0,1068,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('1132006225',544051,to_date('01-AUG-2004 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('01-MAY-2002 12:00 AM','DD-MON-YYYY HH:MI AM'),to_date('18-AUG-2004 12:00 AM','DD-MON-YYYY HH:MI AM'),'DMEB017',16,63.5,1016,1088,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('6588004904',258106,to_date('01-NOV-2007 12:00 AM','DD-MON-YYYY
HH:MI AM'),null,to_date('08-NOV-2007 12:00 AM','DD-MON-YYYY HH:MI AM'),'DMEB025',15.5,109.88,1703.14,1660,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('3504001628',166760,null,to_date('01-JAN-2001 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('10-JAN-2001 12:00 AM','DD-MON-YYYY HH:MI AM'),'BERNICE murphy',14.83,63.5,941.7,938,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('8817006645',285652,null,to_date('01-JUN-1999 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('22-JUN-1999 12:00 AM','DD-MON-YYYY HH:MI AM'),'ANTONETTE M. LAFAUCI',15.8,72.5,1145.5,1210,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('6450003427',115405,null,null,to_date('29-OCT-2004 12:00 AM','DD-
MON-YYYY HH:MI AM'),'DMEB020',14,50,700,0,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('5284002600',416035,null,to_date('01-JAN-1999 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('11-JAN-1999 12:00 AM','DD-MON-YYYY HH:MI AM'),'rose cappo',15,40,600,750,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('8801003637',415464,null,to_date('01-OCT-2000 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('30-OCT-2000 12:00 AM','DD-MON-YYYY HH:MI AM'),'CARLA DOWNS',15.5,80,1240,1632,0,'E','0');
Insert into EXPORT_TABLE (PROPERTYID,DIMENSIONID,LANDDATE,BLDGDATE,PROCESSDATE,INPUTUSER,PLOTFRONT,PLOTDEPTH,PLOTSQFT,TOTALDWELLINGAREA,TOTALFLOOR,SHAPE,GARAGE) values ('8878000860',163537,null,to_date('01-MAR-1999 12:00 AM','DD-MON-YYYY
HH:MI AM'),to_date('30-MAR-1999 12:00 AM','DD-MON-YYYY HH:MI AM'),'VIVIAN REESE',15,60.5,907.5,1140,0,'E','0');
CREATE
TABLE "BRT_EVAL"."SIZE_CODE_RANGES"
    "STYLE"       CHAR(1 BYTE),
    "SIZE_"       CHAR(1 BYTE),
    "LOWVALUE"    NUMBER(38,0),
    "HIGHVALUE"   NUMBER(38,0),
    "DESCRIPTION" VARCHAR2(25 BYTE),
    CONSTRAINT "SIZE_CODE_RANGES_PK" PRIMARY KEY ("STYLE", "SIZE_") USING INDEX
Insert into BRT_EVAL.SIZE_CODE_RANGES (STYLE,SIZE_,LOWVALUE,HIGHVALUE,DESCRIPTION) values ('2','2',400,1399,'400 sqft - 1399 sqft');
Insert into BRT_EVAL.SIZE_CODE_RANGES (STYLE,SIZE_,LOWVALUE,HIGHVALUE,DESCRIPTION) values ('2','4',2600,3599,'2600 sqft - 3599 sqft');
Insert into BRT_EVAL.SIZE_CODE_RANGES (STYLE,SIZE_,LOWVALUE,HIGHVALUE,DESCRIPTION) values ('P','3',1300,1601,'1300 sqft - 1601 sqft');
Explain Plan:
OPERATION     OPTIONS     OBJECT_NODE     OBJECT_OWNER     OBJECT_NAME     OBJECT_INSTANCE     OBJECT_TYPE     OPTIMIZER     SEARCH_COLUMNS     ID     PARENT_ID     POSITION     COST     CARDINALITY     BYTES     OTHER_TAG
PARTITION_START     PARTITION_STOP     PARTITION_ID     OTHER     DISTRIBUTION     CPU_COST     IO_COST     TEMP_SPACE
SELECT STATEMENT                                   CHOOSE          0          14     14     1     63                                        14
TABLE ACCESS     BY INDEX ROWID          BRT_ADMIN     EQID     1          ANALYZED          1     0     1     2     1     16                                        2
NESTED LOOPS                                             2     1     1     14     1     63                                        14
NESTED LOOPS                                             3     2     1     6     4     188                                        6
TABLE ACCESS     FULL          BRT_EVAL     SIZE_CODE_RANGES     3                    4     3     1     2     1     32                                        2
INDEX     FAST FULL SCAN          BRT_ADMIN     DIMEN_PID_TDWELLAREA          NON-UNIQUE               5     3     2     4     1427     21405                                        4
INDEX     RANGE SCAN          BRT_ADMIN     EQID_PROPERTYID_IDX          NON-UNIQUE     ANALYZED     1     6     2     2     1     10                                             1     Edited by: ReubenC on Oct 16, 2012 9:50 AM

I tried removing the index to see if that would have any effect. That appears to work OK. I would like to leave the index in place, however.
Looks like NO_INDEX Hint works. First time using hints... I don't suppose there's anyway to tell it to use the index for one part of the where clause but not a different part?
select /*+ NO_INDEX(d DIMEN_PID_TDWELLAREA) */ d.propertyid,d.totaldwellingarea, e.size_, scr.size_
from eqid e, dimensions d, brt_eval.size_code_ranges scr
where e.style not in ('1','A','G','L') and e.size_ = '0' and totaldwellingarea <> 0
and d.propertyid = e.propertyid and e.style = scr.style and totaldwellingarea >= scr.lowvalue and totaldwellingarea <= scr.highvalue;
select /*+ NO_INDEX(d DIMEN_PID_TDWELLAREA) */ count(*)
from eqid e, dimensions d, brt_eval.size_code_ranges scr
where e.style not in ('1','A','G','L') and e.size_ = '0' and totaldwellingarea <> 0
and d.propertyid = e.propertyid and e.style = scr.style and totaldwellingarea >= scr.lowvalue and totaldwellingarea <= scr.highvalue;Edited by: ReubenC on Oct 16, 2012 3:15 PM
Edited by: ReubenC on Oct 16, 2012 3:22 PM
OK figured all that out.

Similar Messages

Number ranges query

dear gurus,
               i am having some queries regarding number ranges,.
        in number ranges of production orders i am finding..
number range group with check box under that i find the order types.Say(1234 -to9999)
pp01
pp04
zx01
.My requirement is I want to (detach) remove order type pp04.and I want to assign order type pp04 to different number range group.
please guide me>it is very urgent in client side.
                please help me
                                  guna         -

In co82,
Group -->maintain
inside the screen
keep coursor on PP04 and follow the menu path
Edit -->select element
Select the check box of group to which you want to assign and follow the menu path
Edit --> assign element group
then save.
come back if required

Material Document Number Range query

Hi all,
How can I create Materila Doc Number Range Groups and elements . Pls note I want to create it new one and DO NOT WANT TO USE STANDARD .
Also how can I assign or relate or link this groups to Company code or Plant
Regards
Bhushan

1. go to MMNR Transaction
2. click GROUP - change mode
3. go to menu: GROUP -> INSERT (F6)
4. maintain new group data and material number intervals
5. save
6. assign proper material types to new group.
If you want to control material number you can use enhacement:
Source: IMG help:
"enhacement MGA00002 (for industry) or enhancement MGW00002 (for retail) for this.
For more information, see the documentation for the following components assigned to these enhancements:
Industry
EXIT_SAPLMG02_001
EXIT_SAPLMG02_002
Retail
EXIT_SAPLMG72_001
With the exception of the transfer structure, this function is identical to customer enhancement MGA00002 for material number assignment for the material master for industry. Please see customer enhancement MGA00002 for more information and for sample coding.
EXIT_SAPLMG72_002
With the exception of the transfer structure, this function is identical to customer enhancement MGA00002 for material number assignment for the material master for industry. Please see customer enhancement MGA00002 for more information and for sample coding.
EXIT_SAPLMGNK_003"
Hope it helps.
Regards,
wojciech

Number Range Query

Hi,
I have a requirement that number range for sales order and delivery to be same but it is not possible in SAP. Request if anyone can guide for solution like maybe prefix etc.
The requirement is that when we look at delivery number we should know the sales order number but without any document flow or report but by just viewing the delivery number the sales order number to be guessed correctly.
kindly help.

Firstly the idea of suffix like "S" for Sales Order, "D" for Delivery seems good...
But practically speaking it would be very hard, infact impossible to continue with same numbers for Sales Orders & Deliveries.
The main reason behind this Sales Orders may be blocked, cancelled, deleted. Similarly, Deliveries may be reversed or blocked & so on...
So over a period of time Sales Order & Delivery number ranges may not run in same sequence, no matter how hard you try... This is my practical experience.
The client can anytime see the Document flow & know the preceeding / suceeding number document numbers.
Hope this helps...
Thanks,
Jignesh Mehta

Number Ranges inBI

Hi,
Can anyone please tell me what are number ranges and what is there use in BI, how we create it, What are there benefits.
Thanks

The SAP BW system uses number ranges when loading master data or transactional data into BW. The system uses a unique master data number ID for each loaded record. Each new record reads the number range table NRIV to determine the next number in sequence. This ensures that there are no duplicate numbers. Not using unique number range values could compromise the datas integrity.
Number ranges can cause significant overhead when loading large volumes of data as the system repeatedly accesses the number range table NRIV to establish a unique number range. If a large volume of data is waiting for these values, then the data loading process becomes slow.
One way to alleviate this bottleneck is for the system to take a packet of number range values from the table and place them into memory. This way, the system can read many of the new records from memory rather than repeatedly accessing and reading table NRIV. This speeds the data load.

Query occasionally causes table scans (db file sequential read)

Dear all,
we periodically issue a query on a huge table via an oracle job.
Whenever I invoke the query manually, the response time is good. When I start the periodic job, initially the response times are good as well. After some days, however, the query suddenly takes almost forever.
My vague guess is that for some reason the query suddenly changes the execution plan from using the primary key index to a full table scan (or huge index range scan). Maybe because of some problems with the primary key index (fragmentation? Other?).
- Could it be the case that the execution plan for a query changes (automatically) like this? For what reasons?
- Do you have any hints where to look for further information for analysis? (logs, special event types, ...)?
- Of course, the query was designed having involved indexes in mind. Also, I studied the execution plan and did not find hints for problematic table/range scans.
- It is not a lock contention problem
- When the query "takes forever", there is a "db file sequential read" event in v$session_event for the query with an ever increasing wait time. That's why I guess a (unreasonable) table scan is happening.
Some charachteristics of the table in question:
- ~ 30 Mio rows
- There are only insertions to the table, as well as updates on a single, indexed field. No deletes.
- There is an integer primary key field with an B-tree index.
Charachteristics of the query:
The main structure of the query is very simple and as follows: I select a range of about 100 rows via primary key "id", like:
Select * from TheTable where id>11222300 and id <= 11222400
There are several joins with rather small tables, which make the overall query more complicated.
However, the few (100) rows of the huge table in question should always be fetched using the primary key index, shouldn't it?
Please let me know if some relevant information about the problem is missing.
Thanks!
Best regards,
Nang.

user2560749 wrote:
Dear all,
we periodically issue a query on a huge table via an oracle job.
Whenever I invoke the query manually, the response time is good. When I start the periodic job, initially the response times are good as well. After some days, however, the query suddenly takes almost forever.
My vague guess is that for some reason the query suddenly changes the execution plan from using the primary key index to a full table scan (or huge index range scan). Maybe because of some problems with the primary key index (fragmentation? Other?).
- Could it be the case that the execution plan for a query changes (automatically) like this? For what reasons?Yes possible, One reason is stats of the table has been changed i.e somebody issued dbms_stats. If you are worried about execution plan getting changed then two option 1) Lock the stats 2) Use hint in the query.
- Do you have any hints where to look for further information for analysis? (logs, special event types, ...)?Have a Ora-10053 trace enabled whenever query plan changes and analysis it.
- Of course, the query was designed having involved indexes in mind. Also, I studied the execution plan and did not find hints for problematic table/range scans.
- It is not a lock contention problem
- When the query "takes forever", there is a "db file sequential read" event in v$session_event for the query with an ever increasing wait time. That's why I guess a (unreasonable) table scan is happening.
If it db file sequential read then i see two things 1) It is doing index range scan(Not table full scan) or 2) It is scanning undo tablespaces.
Some charachteristics of the table in question:
- ~ 30 Mio rows
- There are only insertions to the table, as well as updates on a single, indexed field. No deletes.
- There is an integer primary key field with an B-tree index.
Charachteristics of the query:
The main structure of the query is very simple and as follows: I select a range of about 100 rows via primary key "id", like:
Select * from TheTable where id>11222300 and id <= 11222400
There are several joins with rather small tables, which make the overall query more complicated.
However, the few (100) rows of the huge table in question should always be fetched using the primary key index, shouldn't it?
Yes theoreitically it should practically we can only say by looking at run time explain plan(through 10053,10046 trace).
Please let me know if some relevant information about the problem is missing.
Thanks!
Best regards,
Nang.I am still not sure in which direction you are looking for solution.
Is your query performing bad once in a fortnight and next day it is all same again.
I suggest to
1) Check if the data is scanning undo tablespace. I see you mentioned there is lot of inserts, could be that Oracle would be scanning undo tablespace because of delayed clean out.
2) Check if that particular day the number of records are high compared to other day.
Or once it starts performing bad then for next couple of days there is no change in response time.
1) Check if explain plan has been changed?
And what action you take to bring back the response time to normal?
Regards
Anurag

Finding the Text of SQL Query causing Full Table Scans

Hi,
does anyone have a sql script, that shows the complete sql text of queries that have caused a full table scan?
Please also let me know as to how soon this script needs to be run, in the sense does it work only while the query is running or would it work once it completes (if so is there a valid duration, such as until next restart, etc.)
Your help is appreciated.
Thx,
Mayuran

Finding the Text of SQL Query Causing Full Table Scan

SD Revenue recognition-Query on Number range for Rev Rec

Hi Experts ,
I see that in VF45-Rev Rec overview transaction, the deferred value are captured as required.But when I try posting them into Revenue G/L account, Iam facing the below errors.
Error Log
1)Accounting document for collective processing 1000002092 was not created
2)For object RF_BELEG 0417, number range interval 88 does not exist FBN1
3)0148000018 000010 Non-processed revenue line: 0003010501 2009003 000 - successor: 000000 - bal. sheet accts: 0002035000
4)0148000018 000010 Non-processed revenue line: VPRS 2009003 000 - successor: 000000 - bal. sheet accts:
Can you suggest me the right config i need to do to over come this issue??
Also can any one explain the significance of this new number range in the FI config??
Appreciate your earliest support
Thanks in Advance
Banu

Hi Banu
For your First query , as the accounting document is not generated that is the reason it has given error also of maintaining number range in FBN1
For your second query , Maintain number range interval 88 in FBN1 with the from and To number range.
Just configure then your third problem should also get solved. If it is not solved let us know or else close the thread if your problem is solved
Regards
Srinath

Query of batch number range

Hi experts
I found that I can assign a external batch number to a material manually,but in background I have not assigned an external number range for batch, who can tell me that's why?
thank you!

Hi,
It is not relevant with No. Range of Batch
Go to SPRO > Logistics - General > Batch Management > Creation of New Batches > Define Initial Creation of Data for Batch Master Transactions > Here for Material Type select option as "C" (Automatic / No Manual)
Also check in SPRO > Logistics - General > Batch Management > Creation of New Batches > Define Batch Creation for Goods Movements > Here for Movement Type select option as "C" (Automatic / No Manual)

Query on number ranges?

hi friends
if PR is created automatically using MD01 i.e through MRP do we need to manually maintain number ranges and document type for PR or if any purchasing document is created automatically then do we need to manually maintain number ranges and document type
Thanks
regards
krishna

IF PR is created via MRP than system will pick up the number range and document type as per config.
In the PO creation system defualt NB doc type and number range automatically from config.
For number rabnge config you can use tcode SNRO
enter your object and maintain or go through SPRO

Range query and case

I am testing on Oracle 10g R2, trying to work on a range query.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/sql_1016.htm#i28528
I have used CASE as follows;
test@>explain plan for
2 select count(*) from rm_supplies
3 where item_no < 40000;
Explained.
test@>SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
Plan hash value: 1332725657
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 5 | 8748 (7)| 00:01:45 | | |
| 1 | SORT AGGREGATE | | 1 | 5 | | | | |
| 2 | PARTITION RANGE ITERATOR| | 5542K| 26M| 8748 (7)| 00:01:45 | 1 | 2 |
| 3 | INDEX FAST FULL SCAN | RM_SUPPLIES_IDX1 | 5542K| 26M| 8748 (7)| 00:01:45 | 1 | 2 |
10 rows selected.
test@>explain plan for
2 select count(*) from rm_supplies
3 where item_no between 40000 and 60000;
Explained.
test@>SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
Plan hash value: 1332725657
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 5 | 8818 (8)| 00:01:46 | | |
| 1 | SORT AGGREGATE | | 1 | 5 | | | | |
| 2 | PARTITION RANGE ITERATOR| | 4028K| 19M| 8818 (8)| 00:01:46 | 3 | 5 |
|* 3 | INDEX FAST FULL SCAN | RM_SUPPLIES_IDX1 | 4028K| 19M| 8818 (8)| 00:01:46 | 3 | 5 |
Predicate Information (identified by operation id):
 3 - filter("ITEM_NO"<=60000)
15 rows selected.
test@>explain plan for
2 select count(*) from rm_supplies
3 where item_no > 60000;
Explained.
test@>SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
Plan hash value: 2956645916
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 5 | 2037 (3)| 00:00:25 | | |
| 1 | SORT AGGREGATE | | 1 | 5 | | | | |
| 2 | PARTITION RANGE ITERATOR| | 845K| 4126K| 2037 (3)| 00:00:25 | 5 | 7 |
|* 3 | TABLE ACCESS FULL | RM_SUPPLIES | 845K| 4126K| 2037 (3)| 00:00:25 | 5 | 7 |
Predicate Information (identified by operation id):
 3 - filter("ITEM_NO">60000)
15 rows selected.
test@>ed
Wrote file afiedt.buf
1 explain plan
2 for
3 select count(case when item_no < 40000
4 then 1 ELSE null END) count1,
5 COUNT (CASE WHEN item_no BETWEEN 40000 and 60000
6 then 1 ELSE null END) count2,
7 COUNT (CASE WHEN item_no > 60000
8 THEN 1 ELSE null END) count3
9* from rm_supplies
10 /
Explained.
test@>SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
Plan hash value: 3589921989
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 5 | 8597 (5)| 00:01:44 | | |
| 1 | SORT AGGREGATE | | 1 | 5 | | | | |
| 2 | PARTITION RANGE ALL | | 10M| 49M| 8597 (5)| 00:01:44 | 1 | 7 |
| 3 | INDEX FAST FULL SCAN| RM_SUPPLIES_IDX1 | 10M| 49M| 8597 (5)| 00:01:44 | 1 | 7 |
10 rows selected.Can there be any other way that I could recreate the range query?
Thank you,
Adith

Thank you for the reply. I was hoping for a similar answer as you have stated;
index fast full scan could be the best way to get the needed information. So then there is no need to recreate or change the query.
Thank you once again.
Adith

SD Number Ranges Archiving

Hi Guru,
Is it possible reuse the number range of documents considering the range is almost over
Regards,
Sachin Vispute
Edited by: Sachin Vispute on Apr 9, 2011 6:45 AM

Hello Sachin,
Before reusing a document number range, please read oss note 781802. It is usually not recommended to do this as it can cause problems with inconsistent results when trying to view archived data. The conclusion of this oss note states:
OSS NOTE 781802
Avoid reusing document numbers, and only do so if you are certain that the date identification will not be lost in the system. You will experience loss of functions when you access old data. While, you can implement technical access using the structure of appropriate indexes in most cases without any major problems, you can no longer determine the document links in the DRB correctly. The standard programs for a business view display on archived data will also not work.
We therefore recommend that you allow a sufficiently large number supply when restarting the numbering procedure. In addition, check that not too many unused numbers were lost due to the selection of the number range buffering.
You should only consider reusing document numbers if the effort of implementing a numbering procedure that avoids reusing document numbers, exceeds the effort of avoiding the problems given in this note, and if it is sufficient for the full functional capacity of the data display and object links to only be available for data in the database.
Hope this helps.
Best Regards,
Karin Tillotson

"Number range for trans./event type WV in year 2014 does not exist"

while doing PGI i am getting error as "Number range for trans./event type WV in year 2014 does not exist"
Thanks,
Rohit

Welcome to the forum. As a new member, I would like to inform you that there are certain rules and regulations applicable to this
forum which you can find to your right screen where it has also been indicated that posting basic / repeated query is not allowed. Please search in this forum or Google it with the same text, so that you will find many threads discussed on the same topic. Take the inputs from there and update still if you are not able to resolve. Meanwhile, this thread would be locked.
G. Lakshmipathi

Number range for trans./event type WA in year 2014 does not exist

Dear,
Member As I am unable to post goods receipt through MB1C.
Error coming-Number range for trans./event type WA in year 2014 does not exist Message no. M7562.
I have gone through below thread, but still not resolving.
In OMBT initial screen, clicked on Group button with pencil figure.
There, selected Material documents for goods movements and inventory diffs.
WA WH WI WL WQ WR WS WZ.
There, I have put 2014 and simply copy the number range 4900000000 - 4999999999 with current number as 0.
I have gone through the previous thread but not yet got solution.
Thanks & regards,
Supriyo

Welcome to the forum. As a new member, I would like to inform you that there are certain rules and regulations applicable to this
forum which you can find to your right screen where it has also been indicated that posting basic / repeated query is not allowed. Please search in this forum or Google it with the same text, so that you will find many threads discussed on the same topic. Take the inputs from there and update still if you are not able to resolve. Meanwhile, this thread would be locked.
G. Lakshmipathi

CRM ISA R/3 Edition on AP 7.0 Pricing Routine Number range error

Hi Experts,
For our R/3 ISA Secenerio I have developed a Pricing Prepare Routine (PRP). I have uploaded this routine into AP 7.0 ( which runs my IPC 5.0). Now when I try to register my PRP routine I'm not able to do so because of Number range not defined for Application V Scenerio A and Routine Type PRP.
My question are:
1) For a PRP type Routine( Multiple Implementation) is it important to assign a
routine number? ***( according to pricinguserexit manual dummy routine no
has to be assigned)******
2) If yes then how can i assign Number range for this combination.
NOTE: AP 7.0 has SP 7 ( So it fullfills requirment for Special scenerio)
I have never recieved a reply for my query from this forum... hope someone helps this time. :)
Regards,
Dipender Singh

go to http://www.configuration-workgroup.com/ and find technical doc about IPC 5.0 that i presented at Marco Island in 2006.

Number range query causes repeated scan by index

Similar Messages

Maybe you are looking for