Re: Databases and Instances

On Wed, 05 Apr 2000 14:01:08 GMT, nsouto_at_nsw.bigpond.net.au.nospam (Nuno Souto) wrote:
>:-) Relax, I'm not THAT grumpy. Just pisses me off to see crap like
>Sybase and sql server being used to reinforce a point about DB2. as
>you noted somewhere else, DB2 and ORACLE are so far ahead of those in
>their implementations, I see no need whatsoever to use them as
>"reinforcement": it's just not applicable. I'd like to think DB2 can
>stand on its own without using those two thingies as props...

You're right ... I was a bit random with my choice of comparison.

>OK, let's look into it now. Warning, this is a long one. I was
>trying to draw you out to see what the real problem was. As I
>suspected, just a minor semantics misunderstanding. Who knows, maybe
>even the MS-oid marketing lurkers, who came here to learn what real
>databases do, will learn a bit?
>
>>
>>You miss the point. I mean being able to have two objects with
>>IDENTICAL fully qualified names in two separate areas ... including
>>SCHEMA name! See below.
>
>Why on Earth would anyone want to do that in ORACLE? See below too.
>
>>Nope, I can't have two schema's with identical names in one instance,
>>because Oracle forces them into its one and only DB, and prevents it
>>happening.
>
>True. Thank God for that. Or else the entire edifice of relational
>database theory would crumble. Keep on reading, there's more.
>
>> With the other RDBMSs mentioned, identical schemas can be
>>housed in different databases within the instance.
>
>Not with sql server or Sybase.

True :-)

>>This is absolutely critical for proper application testing ...
>>something often missed by the "Just use different schema" mantra of
>>some Oracle afficianados.
>
>Let me see: the thousands of sites out there who use ORACLE are all
>complete morons who do NOT know a single thing about the "critical"
>needs of "proper application testing"?
>
>Has it EVER occured to you that maybe such a BASIC item of
>functionality might actually be provided for in ORACLE?
>Since the year dot, BTW?
>And maybe, (just maybe mind you!) it does NOT have to be in exactly
>the same fashion DB2 does it?
>
>But I digress. Forgive me, let's go on.
>
>OK, here lies the problem: you probably dealt with a DBA that didn't
>know what he was doing (or couldn't be bothered). It happens in the
>best families.
>
>When you code your application, you do NOT write the FULLY qualified
>table names into your code. I could point you to a few reference
>texts on this subject, but why bother? I KNOW you know this, you're
>just conveniently forgetting it.

Yes, I was simplifying things. And you go on to hit the nail on the head ... what happens when you (me, you, poor DBA's in general) get off-the-shelf software with said hard-coded names. I was probably being a little rough on Oracle ... but I'm sure Larry can handle it.

>What you do is write the name of the table. Period. No more, no
>less. What that maps to is completely dependent on how the DBA sets up
>your runtime environment.
>
>If the DBA could have been bothered, he would have given you two
>usernames to run your application. Each of these would have the table
>names mapping to the fully qualified REAL table names living in
>differently named schemas, same instance or different ones is
>immaterial here.
>
>You want to use the development schema? Connect to the database with
>one of the usernames.
>
>You want the test schema? Use the other username to connect to the
>same database.
>
>Guess what? Don't you have to do EXACTLY that to use same name schemas
>in same instance in DB2? Connect as two different users? So what is
>the problem?
>
>How to do this in ORACLE? So easy it doesn't even rate a mention.

And thankfully it can be done the same way in DB2.

>Now, you mentioned the REAL problem:
>
>>>Yes. Start more than one instance with the same shared code. I
>>>believe exactly what happens to DB2 too. Not the slightest problem.
>>
>>No, not quite. For example, each DB2 database can have independently
>>configured things like buffer pools (analogous to shared pool in
>>Oracle) that aren't tied to the instance config - each database has
>>it's own (in fact, you can even tie them to individual tablespaces
>>with the database!).
>
>Er, I thought we were talking about UNIX? Or else you wouldn't have
>brought the other two thingies into this. BTW, ORACLE can indeed run
>on mainframes. None of the thingies can.

"Thingies"? That's a good one. I bet the M$ people reading this thread are turning red right now. :-)

>I know it's possible to do all that with DB2 for mainframes. Unlike
>most people in ORACLE, my background is mainframes. I still remember
>a few things about them. They have capabilities UNIX still hasn't
>"invented"! But that's another story.

You mean you're not looking forward to running 58000000000 Win2000 machines in some god-awful cluster to try and come close to what big iron was doing ten years ago? (yeah, that was a joke.)

>Last I looked, it wasn't possible in the UNIX version of DB2. Even if
>IBM manages to make it work (no doubts there), I can tell you it won't
>stick: UNIX just doesn't have the fine control of virtual memory
>needed to do this in a manner that will make it efficient. MVS does.
>Not UNIX. Not yet, anyway.

Mmm ... don't know enough myself about this, though it is there in version 5, 6 (and soon to be 7) of DB2 on UNIX and NT.

>While I'm here: what is the point of having two sets of everything in
>the same instance? Isn't that exactly the same as using two shared
>code instances linking to the SAME two sets of everything? Or am I
>missing something? (warning: this is a "loaded" question. Just
>testing...)

My initial gripe was "loaded" too - I was alluding to the out-of-our-control stuff (like off the sheld packages) that gets foisted on you, with hard-coded schemas, crazy synonym use, etc. OK, this isn't really a problem with the Oracle way of doing things per se, but the db/instance/schema limitations it has do make it more complicated to do things like upgrades, testing, etc. when you can't change things at the schema level.

>>You hit the nail on the head when saying Oracle
>>needs separate instances for this.
>>
>
>Absolutely. I know its limitations only too well. The buffer
>partitioning issue has always been a problem. And it's got nothing to
>do with "proper application testing".

OK, OK, I'll get off my testing soap-box.

> It's been a long asked for item
>in many a user group meeting. Impossible to do properly in UNIX as it
>stands. And there are other things to do too, like independent
>recovery logs and such. You need all of those to make it work
>properly.
>
>>>>Gee, let me see. Nope, Oracle flunks ALL OF THOSE!!!!!
>>>Nope. Go back to 101, buddy.
>>Bzzzt. Graduated long ago ... but there's a place there for you.
>
>Maybe with DB2 and mainframes. I can assure you that is not the case
>for ORACLE. Or UNIX. Or NT.

I'm not sure how they're getting around it, but the DB2 instances I run on NT and UNIX (Solaris, Linux) do provide for this. It may be some fancy footwork within the instance itself, to take one logical block of virtual memory, and the add another "virtual partitioning" over the top of it to give the illusion of what we see ... or something far more sophisticated ... can't say I've really bothered with how it does it, I just smile knowing that it does.

>As I said, ORACLE doesn't "flunk all of those". Maybe one of them.
>In mainframes. Far ahead from the thingies anyway, who can't even run
>there let alone do it.
>
>>And Informix (bet that puts a smile on your face.)
 

>:-) Yes it does. It's my sentimental favorite, although it will never get
>anywhere.

You think they've got no chance of coming back? (I happen to agree, but they do seem to be refusing to die, unlike Sybase, which seems to be disappearing faster than free beer.)

>>Not quite. You're right, there may be no need to change ... I was
>>making the point that it would be bloody difficult for them to try it
>>if they wanted to.
>
>No argument from me there. I don't think ORACLE is terribly
>interested in competing with DB2 in mainframes. It's just not their
>market, although they are the only database maker other than IBM who
>can run there too.
>
>However, rest assured: if IBM manages to include proper virtual memory
>management into the UNIX standard and make it stick, it won't take
>ORACLE a second to make this work. The structure is already there, in
>8.1 it's already partly functioning. Give them the proper OS
>functionality and they'll do it. It's really not that hard. Just
>another level of abstraction in their "onion" architecture. They have
>done it before many times.
>
>Now, where were we? Oh yes, fire your ORACLE DBA. Or put the fear of
>God on him/her!

Alas, it was a programmer acting as a DBA about 5 years ago that started the whole problem ... I'm the one trying to clean up the mess :-) (And the first thing to go is bloody hard coded schema's!!!!)

(I can hear you laughing from here!)

Ciao
Fuzzy
:-) Received on Wed Apr 05 2000 - 00:00:00 CDT