RE: FIRST_ROWS hints

[Sai Selvaganesan]

tried that too.infact i changed the db_file_multiblock_read_count to a very small value about 1/8 of the previous value. for it to move from SM to NL in only one case.

 

generally,it is using SJ only.and right i have started seeing a lot of full table scans.

 

apparently the general recommendation is to have a bigger block size on datawarehouse kind of systems. in those cases this could be a issue. so can i conclude that  though DW returns results in a longer time, this is acceptable and it is a attribute of DW.

sai


Scott Canaan <[EMAIL PROTECTED]> wrote:

Did you remember to cut the db_file_multiblock_read_count in half, since you doubled the blocksize?  I would assume that you also started seeing more full table scans, as well.

 

 

Scott Canaan ([EMAIL PROTECTED])

(585) 475-7886

"Life is like a sewer, what you get out of it depends on what you put into it." - Tom Lehrer.

 

-----Original Message-----
From: Sai Selvaganesan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 2:54 PM
To: Multiple recipients of list ORACLE-L
Subject: FIRST_ROWS hints

 

hi

 

i had a migration from 9.2.0.3 to 9.2.0.4 of a database and here are a couple of observations. please help me in understanding this.

 

i changed the db block size from 8k to 16k and all sql queires which were using nested loops earlier moved to sort merge joins. i ran 10053 and form whatever i could understand the 9204 db has fewer number of blocks compared to the existing 9203 (db size changed to 16k) and sort merge join turned out to be less costlier than nested loops (i couldnt understand the sort statistics). no  parameter other than db block size was changed.

 

after breaking my head i changed the optimizer mode from choose to first rows and the query is back to the old explain plans.

 

please clarify

1. whether this is a expected behaviour

2. what is first_rows hint and whether it is good move to go to first_rows to fix this problem.

 

thanks

sai