-
As long as an object has proper storage attributes defined and its row fits within a block, there shouldn't be any issues.
Here, we are not talking about row migration or row chaining, but the effect of having more than 255 columns in a table.
What I am saying is Oracle cannot read more than 255 columns in a single IO even when all 1000 columns of a row stored in a single block.
Tamil
-
Yes, I do agree with you there........
"table fetch continued row" wait events do start appearing due to mutiple fetches (physical or logical IO) when a table has more than 255 columns and 256 columns within the table column list has atleast 1 byte of data in them.....
http://www.dbaxchange.com
-
Thank you so much for everybody's answers. TamilSelvan, thanks for your exact answer for my question...
-
Tamil,
In you answer, you are saying, "row is fetched via index look up".
What does it mean?.
Originally Posted by tamilselvan
It is not chained. The data of the columns whose number is > 255 is still stored in the same block provided the block has space.
The real problem is "table fetch continued row " event appears in the statspack report.
Oracle has to do 2 IOs (logical) for the data appears after the 255th column even when all the columns data are stored in one block and the row is fetched via index look up.
However, full table scan will not suffer from 2 IOs.
You can have 1000 columns in a table. In my opinion, restrict the number of columns less than 255 and the performance will be good.
Tamil
Tamil
-
In you answer, you are saying, "row is fetched via index look up".
What does it mean?.
It means fetching a row data from the table's block using an index lookup.
OR
Oracle reads the index leaf block based on the index key submitted to get the rowid, and then using the rowid it goes and gets the row data from the table's block.
Tamil
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|