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

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... Received on Fri Jul 20 2007 - 02:19:26 CDT