Re: Databases and Instances

On Wed, 05 Apr 2000 03:55:21 GMT,
granta_at_nospam.student.canberra.edu.au (Fuzzy) wrote:

OK, warning: this is gonna be a long one.

Why did I know this was yet another tired old case of a different "database language" being used to explain a "missing" feature in ORACLE? :-) 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...

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.

>
>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.

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.

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.

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.

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.

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...)

>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". 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.

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.

Thanks for pointing out a reinforcement of my argument, BTW. As I said, you can't say "all those databases" when you mean DB2 in mainframes. That is just not correct.

>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!

:-)

Cheers
Nuno Souto
nsouto_at_nsw.bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html Received on Wed Apr 05 2000 - 00:00:00 CDT