Noons wrote:
> On Jul 20, 2:16 am, DA Morgan <damor..._at_psoug.org> wrote:
>
>
> Before I forget:
>
>>> 1- A table gets updated in the WRONG schema.
>> So it is an issue for you: Send me a case I can test in 11g.
>
> Set SGA to auto memory management
> for everything and use a pga_aggregate
> as well.
> Create two schemas in the database,
> with differently named tables and one
> table with same name in both.
> Load the system with heavy updating,
> using vanilla UPDATE <tablename>
> statements in both schemas. Add a few
> heavy ORDER BY selects. Make sure
> you are not using UPDATE <owner.tablename>.
> Run them all under the username of one
> of the schemas.
> 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".
>
>>> 2- A CLOB can't be reliably used in an ASSM tablespace.
>> So it is an issue for you: Send me a case I can test in 11g.
>
> This one is easy: create tablespace with ASSM
> turned on. Slap a CLOB extension there.
> Insert a bucketload of rows in table with the CLOB,
> less than 4K CLOB size.
> Update those rows, set CLOB > 4K.
> Rinse and repeat with a couple of concurrent
> updaters.
> Once the ASSM tablespace starts growing, watch
> alert log for ORA600s. Fails with all
> 9i, all 10g.
>
> Workaround? Turn off ASSM for tablespaces
> with CLOB. No fix "until 11g".
>
>>> 3- A query returns WRONG number of rows or
>>> just plain WRONG result set, randomly.
>> So it is an issue for you: Send me a case I can test in 11g.
>
> This one is highly dependent on syntax
> and load conditions. Admittedly, I wouldn't write
> syntax like that. But others do. And it's legal
> syntax so it better work properly, no?
> I've got a variation with Peoplesoft tables,
> that blows in execution time if I do a
> INSERT SELECT, but runs OK if I
> do just the SELECT itself.
> Again, to do with FBIs: turn them into
> normal indexes and the problem goes away.
>
> Workaround? One cumulative patch to 10.2.0.2,
> another extra patch and three undocumented
> parameters set to FALSE. That's for 10.2.0.2.
> Check the cumulative patch I gave before for
> details on which releases are affected and which
> patches are available. Starts in 9i, goes to
> 10.2.0.3.
>
> Have fun. Or not...
Thanks. I will duplicate it Saturday.
Note to Mark: I sure hope I don't find it. <g>
--
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
Received on Fri Jul 20 2007 - 08:03:00 CDT
