Re: diff bewteen 8i and 9i?

"Nuno Souto" <nsouto_at_nsw.bigpond.net.au.nospam> wrote in message news:3b161fc0.860355_at_news-server...
> On Thu, 31 May 2001 19:12:28 +1000, "Howard J. Rogers"
> <howardjr_at_www.com> wrote:
>
> >>
> >
> >I'll confirm that there's a section in the course notes stating that
 Server
> >Manager is defunct, and 'connect internal' now produces an error message.
> >
>
> David's prezzie actually contains a nice little slide with an error
> being returned when calling svrmgrl! :-)
>
> >
> >The course notes agree that keep/recycle and default only relate to the
> >'standard block size' (ie, the one you pick when you create the
 database).
> >All other block sizes chosen when you create a tablespace must have a
 home
> >to go to in the buffer cache -but those 2, 4 8, 16 or 32K non-standard
> >caches are flat caches with no internal divisions.
>
> I'd settle for one buffer cache per tablespace, tuneable.

Nope. If you have three tablespaces of 16K, you have one 16K buffer cache to deal with all of them. Nice try, but no banana.

>Don't
> really need one buffer cache per block size, that doesn't help much.
> Oh well, we'll see how it develops. But it's beginning to look like a
> wasted opportunity of catching up with DB2's vastly superior buffer
> cache. Once again... <sigh>
>

You can email me on this one, but what's so good about the DB2 buffer cache?

> >
> >Incidentally, Nuno was correct when he complained that the *total* SGA
 size
> >is fixed, since you can add or remove bits from the SGA (in units called
> >'granules') only upto the limit specified by an over-riding SGA size
> >parameter. Still, strikes me Nuno wants blood from a stone!! 'Sgot to
 be
> >better than a kick in the teeth!
>
> Me? Nah, I don't care about the SGA upper limit provided I can
> re-shuffle things within it. Happy as a bird with that one. Not
> happy at all with the buffer cache, though. Not one bit. Sincerely
> hope I misunderstood it.
>

Pining for the DB2 fjords, eh?

> >
> >Difficult to say -the US will get it first, of course. Trainers in OZ
 are
> >meeting the product for the first time in June. I imagine we won't be
> >training it until at least Octoberish. Mileage will vary. I don't rate
> >your chances if you live in Timbucctoo of seeing it before 2002 (and no,
 it
> >wasn't intended to rhyme).
>
>
> Make sure you ping me for the first "diffs" course, deal?
>

You're on.

>
> >Incidentally, I forgot to mention: ORA-1555s are a thing of the past,
 since
> >you can now protect rollback required for read-consisitent image
 preparation
> >for any given length of time (the default appears to be 30 seconds).
 Must
> >be worth an upgrade for that fact alone, I'd say.
>
>
> Hehehe! Not so fast, bro Rogers! It's still possible, we just can
> delay it for quite a while. Or so my reading of David's prezzie lead
> me to believe.
>

If you look at Steve Adams' scripts for this, they essentially work by raising a dummy (ie, blocking) transaction for a given period of time -and his scripts allow you to have variable timings. Basically, the new 9i stuff does exactly the same thing in exactly the same way. Yes, you need to know for how long rollback is needed. Anyone who answers "All week" gets sent to the back of the class. I think you're supposed to be able to know things with slightly greater precision than that!

> Not sure exactly how that's gonna work. How the heck are we supposed
> to know what's a sufficient delay? Suck it and see?
>

Yup. As far as I can tell, the requirement for the DBA to know his, her or its (I like to be inclusive) application doesn't entirely disappear. So you suck it and see, and tune accordingly.

> Nevertheless, I'd kill to have 9i right now. For many a number of
> reasons.
>

Me too. Do you think I can get my mits on even a beta version?????? Huh!! Get back in line. Grrrrr.

HJR
>
> Cheers
> Nuno Souto
> nsouto_at_bigpond.net.au.nospam
> http://www.users.bigpond.net.au/the_Den/index.html
Received on Sat Jul 21 2001 - 16:47:19 CDT