Re: Tablespace export ???? how ???

On Mon, 26 Mar 2001 16:34:06 +0100, "Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote:

>Nuno's documentation is, or how well any site he has worked at keeps it. I

Aye, that's the problem. One does a big effort to put everything in place, documented, scripted, you name it. Then the first DBA that comes along "postures" for a while and does nothing to keep it actual. And ther's no way to enforce it other than hammering it in from the first day of training of DBAs. That way it might become Pavlovian rather than certified...

> I just have a philosophical difference about what
>types of advice is appropriate in a public forum for people of unknown skill
>and comprehension.
>

I don't really have the slightest problem with a diff in philosophy. Sorry for the long-winded reply, but I don't want any bad feelings between us.

Let me explain where I come from. Back in early 80's in the mainframe days of my life, I was a tech support A/P. As you are aware, that environment had its share of "hackers". A common occurrence was when one of them came up with a problem in their "code" and then tried to blame the maker (us) for it.

It was usually easy from the tone and content to weed them out. Keep in mind back then actual source code of the s/w was distributed to the client and it was up to them to re-compile/ re-link/ configure it before use. Yes boys and girls, the source was there for us to peek at! Fun, eh? Well, after patching a Codasyl chained-link in Assembler the fun quickly becomes "Yuch!"...

Dealing with these guys was no different from solving remotely what were sometimes very complex problems. Back then there was no modem or Net access to clients, we had to go by dump analysis. Still think it was fun? Don't.

This to come to the current situation with ORACLE. Their code is as closed as it gets and anyone messing there is open to prosecution. That weeds out most hackers straight away. There are a few, but they know darn well what they're doing, I can assure you!

That leaves the configuration. It's done in the case of ORACLE through very public scripts, run when instance initializes. ORACLE knows this and so does any user who has bothered to look. IMHO, this is a good thing. If someone wants to play around with it, it's there. It's also very enlightening.

I remember asking our regional suppmgr in my time at ORACLE if it was "kosher" to add indexes to sql.bsq and change catalog.sql. It was, I was told. "But you're on your own if you hit a problem. Don't bother international support if you muck up". Which I accepted not as a Darth Vader "thou shalt not do it" but as a welcome warning which makes a lot of obvious sense.

Coming back to this. I could mention here some techniques that could potentially "blow" an instance away if done out of context or without proper care. So can many others. That's truly dangerous. Zipped mouth from me.

Therefore, I stay close to what can be done without any resulting catastrophic production crash. In the case of sql.bsq, given it's used once at database creation time and never again, I can hardly see how it can blow an existing production instance. In the case of the dictionary views, I recommend very clearly any changes to those be done owned by a user OTHER than SYS or SYSTEM.

No consequence for normal operation. And of course these things aren't to be tried "cold turkey" in a production system. No more nor less than for example installing modified views to make third-party scripts work. Totally harmless. Yet, the recommendation is always there, implicit: do it first in an instance where it doesn't matter, learn, then apply. Anybody doing otherwise should be shot.

Now, if someone doesn't understand what's here, the solution is simple: ignore it. Those who do understand may take advantage, by the simple fact it was brought into the open. Which is the important part of this, IMHO. Being available as a "good to have", to be tried, used, whatever, when needed or when time is "long".

However, I agree with a more explicit warning that it's non-standard. As for unsupported, what isn't? According to the strict letter of the terms of use of ORACLE, anything you do with their s/w is on your own and if it causes you problems, ORACLE has nothing to do with it. Unsupported? Pah!

But I'll make sure in future "tricks" get appropriately flagged, as opposed to plain "install" advice.

No bad feelings whatsoever, captain. Glad we can still talk even when we don't agree. What a breath of fresh air!

Cheers
Nuno Souto
nsouto_at_bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html Received on Tue Mar 27 2001 - 05:10:07 CST