Re: here's a good one from dizwell on the recent product launch

On Thu, 26 Jul 2007 03:33:04 -0700, Noons <wizofoz2k_at_yahoo.com.au> wrote:

>On Jul 26, 2:04 pm, NetComrade <netcomradeNS..._at_bookexchange.net>
>wrote:
>
>> >Then after a while, inject a few of those updates,
>> >but this time on the table that is commonly named.
>> >Increase load on these and watch which table
>> >gets updated.
>>
>> >Happens since 9i, various Metalink SRs.
>> >Workaround? Turn off the pga_aggregate and the
>> >SGA auto memory management and go back to setting
>> >all the umpteen memory caches manually.
>> >No fix "until 11g".
>>
>> We hit this, we have many db's with almost identical schemas.. Is this
>> still not fixed? After we applied 10.2.0.3, I heard maybe one
>> complain. Lucky it was not a payroll database :)
>>
>
>You're not the only one. Anyone running the same
>table name in two schemas in same instance is exposed
>to this problem, since 9ir1. There are umpteen calls on
>this in Metalink since then, all answered and closed the
>same way: upgrade to 10.2.0.3 or 11 or turn off all the
>sga auto management switches. Oracle has done bleeding
>nothing to fix this until 10.2.0.3 and even then it's not
>reliable!
>

Actually, turning off sga management switches was not one of the suggestions for us, but we don't use pga_aggregate_target b/c of another extremely suckly oracle product called MTS (aka Shared Server) (I think you mentioned this one earlier as well)

We'll keep this in mind, thanks. I had only one unconfirmed report of this problem since 10.2.0.3 upgrade, but in 10.2.0.2 it was pretty obvious, data 'owned' by certain app users inserted in the wrong schema, which could be verified with timestamps only, didn't even have to dig with 'log miner' (which I wasn't really looking forward to do anyway)
.......
We run Oracle 9iR2,10gR1/2 on RH4/RH3 and Solaris 10 (Sparc) remove NSPAM to email Received on Thu Jul 26 2007 - 13:02:05 CDT