RE: [kdsgrp1] error RAC on TABLE segment with chained rows

From: <>
Date: Fri, 18 Jan 2013 07:34:04 -0600
Message-ID: <>

Thanks Jonathan. That's really the way I was leaning since the process finishes normally when the system is not as busy. It would be nice if I could recreate the issue on demand but haven't been able to.



-----Original Message-----
From: Jonathan Lewis [] Sent: Friday, January 18, 2013 2:28 AM
To: Taylor Christopher - Nashville; Subject: Re: [kdsgrp1] error RAC on TABLE segment with chained rows

The rowid 09b7df57.ffffffff is suspect because the row portion can't exceed 4095, but since we don't know what steps Oracle takes to create (or dissolve) a chained row we can't be sure that there isn't a moment at which ffffffff is used as a place holder. Given the row chaining involves some type of recursive transaction we could imagine some scenarios that allow one instance to "know" that a row is in the process of being chained or unchained while another instance has insufficient information to follow the chain properly. Since blocks pass between instances very rapidly in normal circumstances, it wouldn't be too surprising to find that this type of race condition will only happen when the system is very busy and some time delays can occur between a request for a block being sent to the resource master and the block being dispatched from the current holder to the requestor. I would suspect that this is more likely to happen on a 3 (or more) node system than on a 2-node - in fact I wouldn't really expect it to be possible on two nodes.


Jonathan Lewis

Author: Oracle Core (Apress 2011)

  • Original Message ----- From: <> To: <> Sent: Wednesday, January 16, 2013 9:37 PM Subject: [kdsgrp1] error RAC on TABLE segment with chained rows

| Env: 3-node RAC RH Linux 64-bit
| Ok guys and gals,
| I'm a bit stumped here.
| Here's what I have and I'm hoping someone can offer some thoughts on
chained rows perhaps.
| *** 2013-01-16 00:51:51.891
| *** ACTION NAME:(wq_rules.run_rules) 2013-01-16 00:51:51.891
| *** MODULE NAME:(JDBC Thin Client) 2013-01-16 00:51:51.891
| *** SERVICE NAME:(CCMNASP1) 2013-01-16 00:51:51.891
| *** SESSION ID:(5304.26095) 2013-01-16 00:51:51.891
| row 09b7df57.ffffffff continuation at
| file# 38 block# 3661655 slot 0 not found
| File 38, block# 3661655 matches to MON_ACCOUNT_ACTIVITY table.

Received on Fri Jan 18 2013 - 14:34:04 CET

Original text of this message