Comments on: I Wish

By: Jonathan Lewis

Jonathan Lewis — Sat, 31 Mar 2012 07:03:04 +0000

Raova,
I repeated your experiment using an 8KB block size (just in case it was an anomaly due to the 16KB block size) and I get the same result – however the behaviour was dependent on the the structure of the table.

It looks as if you rebuilt the table before reporting this test – is that the case ? Your row-piece ordering is something I could reproduce only through ‘alter table XXX move’

By: raova

raova — Fri, 23 Mar 2012 17:20:39 +0000

I have a table with 978 columns and 1 row in it. as expected it has stored the row as 4 row pieces (as there are trailing not null columns). here is the block dump of the block.

block_row_dump:
tab 0, row 0, @0x3e1b
tl: 357 fb: --H-F--- lb: 0x0  cc: 255
nrid:  0x1e0174e4.1
tab 0, row 1, @0x3c18
tl: 515 fb: -------- lb: 0x0  cc: 255
nrid:  0x1e0174e4.2
tab 0, row 2, @0x3ab4
tl: 356 fb: -------- lb: 0x0  cc: 255
nrid:  0x1e0174e4.3
tab 0, row 3, @0x2fe9
tl: 2763 fb: -----L-- lb: 0x0  cc: 213
end_of_block_dump

But when I acces this table it says it has visited 2 blocks and 8 row pieces. Not sure why it is vising 2 blocks when it got all 4 row pieces in 1 block and 8 row pices when it has only 4.

table scan blocks gotten                                                     2
table scan rows gotten                                                       8
table scans (short tables)                                                   1

By: Jonathan Lewis

Jonathan Lewis — Mon, 19 Dec 2011 12:23:07 +0000

Mark,

Every time I start to think about the options I start to worry about how easy it would be to do it wrong; there are so many considerations of timing and overheads, effects of migrating backwards or migrating to a third location – not to mention thoughts of data that ought to be well-clustered ending up badly scattered because of migration. I think I’d rather see a little more education of how to anticipate data growth, rather than an undercover mechanism that tries to work around the problems. (Think cursor_sharing!)

By: Mark W. Farnham

Mark W. Farnham — Sat, 17 Dec 2011 00:38:53 +0000

This is an interesting topic. I wonder if Oracle might start storing the migrated to address for single piece rows in indexes. I wonder if Oracle might start storing (perhaps at user index definition and/or the system figuring out when it made sense) up to some n block addresses in the index for multipiece rows. The behavior of fetching “the rest of the columns” when adaptive direct read kicks in is interesting. Monitoring column usage and possibly allowing physical reordering of columns so the most used columns are in the first piece might be useful. I think these things tend to get lower priority because there is a tendency to think people who use more than 254 columns in a table or allow much row migration to take place should be glad it works at all.

I’m certainly glad you brought this all up. In the era of big data, it is the sort of remediation the database engine could do in response to defects in how something to rebuild has accreted. Scratchpad has scratched the surface of this topic in a very important way. It could become a whole industry area of research and expertise.