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.
"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.....
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.