Re: LOB columns and migrated rows

Multiple blocksizes are heavily used in TPC-C tests as well. They could help getting the last bit of performance out of your system.

LOBs can also be a special case, when having fairly large LOBs, it could be useful to store those in large blocksize tablespaces. Both for less storage overhead reasons and that way Oracle is able to address longer LOB intems without help of LOB index in some cases.

But for chained rows - what is the block size for original poster? If your row size is less than your block size minus couple hundred bytes of overhead then going to larger block size won't help to reduce chaining. You can reduce row migration by appropriately measuring initial row size when it's inserted and final row size when the row is mature and calculate appropriate PCTFREE for your table from there.

But otherwise, there's no need to bother about chained/migrated rows unless your query response time is too low due excessive LIOs *and* you see that large % of the IOs are caused by fetching chained/migrated row pieces (can be seen from "table fetch continued row" statistic).

Tanel.

• Original Message ----- From: Joseph Amalraj To: oracle-l_at_freelists.org Sent: Friday, February 03, 2006 9:53 AM Subject: Re: LOB columns and migrated rows

  Mladen Gogala <gogala_at_sbcglobal.net> wrote:

  Multiple block sizes are normally used to plug in tablespaces from another database,   typically from an OLTP to DW. It's much faster then export and import. Multiple   block sizes are practically useless for anything else.   --
  Mladen Gogala
  http://www.mgogala.com

  Had heard that using larger block sizes for index, will improve performance as per   http://searchoracle.techtarget.com/tip/1,289483,sid41_gci1008028,00.html

  Is having a larger block size set up for indexes only worthwhile.

  Thanks

  Joseph Amalraj

  --
  http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l