Hey doug even though i agree that statement is wrong look at the last update date for that website .
someone might have decided they liked exports at that time.
This page last changed on 26-Aug-2004 19:32:37 CEST by Danpb.

1) Date I worked out that an export file is not a backup? I can't remember but it was in the very early 90s! I didn't need someone to tell me, I worked it out when I worked out what would be required for recovery. In fact, the fairly recent publication date makes me slightly less sympathetic because this is not new knowledge.

2) A web page could be removed if the author decided he or she doesn't 'like' exports any more.

3) Normally I'm not so aggressive against any attempt to contribute. I'm aware that an export serves a useful purpose of it's own, but I'm so *tired* of this 'export as backup' nonsense that I struggle to find any sympathy even for those who just don't understand. As Noons pointed out, look at that 'recovery' method! It's dangerous.

4) That web page is *riddled* with scary advice! I actually picked one of the more harmless items which happens to be close to my heart.

5) But, in fairness, I can see some positive intention, like Niall. For example, consistent=y is used, along with system (as opposed to sysdba). However, the page is full of such dangerous, casual advice that my mouth dropped open.

I'd like to think I'm sensitive to other's efforts, but that page is rubbish, masquerading as advice. However, I would accept that it looks like it was intended for a limited audience. However, whether it's bad advice for 6 people or 6,000? It's still bad advice.

That's why I mentioned Alex's BAAG site. It's very important, but the day to day reality I've come across is so much worse than whether we're disciplined about our approach to performance problems or not. We can't even get the basics right!

I totally agree on all your comments .
but having experienced this first hand in 1998 the company i used to work with .
the only backup strategy they had was *cough *cough exports and filesystem backups . i lobbied hard against it but they just would not understand my reasoning.
I do agree with you that content needs to be updated and anyone hitting a webpage like that should always double check the facts.
who knows the guy who posted this is even there or not.
There are alot of orphan webpages on the internet.

Oh, I still see it at sites today. It's quite common and I suppose as long as those who use this approach understand the implications fully, I'm quite relaxed about it. The problem I have with is the bald statement 'backup my database'.

who knows the guy who posted this is even there or not.

Good point. Perhaps they aren't and that's one of the dangers of the internet. All the more reason to argue against it, though.

An export CAN be a valid backup IF it fits the recoverability requirements and recovery is exercised regularly. I agree that majority of Oracle databases have higher recoverability requirements but there are places that can live just fine with exports.

But I digress so back to the first sentence. That guy *GUESSED* that everyone's requirements are just like his. You did the same and assumed (read guessed) that the requirements must be much higher. Even though you are close to the truth - you are BOTH generallt still wrong.

Get the requirements and start from there. Export can be, in certain cases, an acceptable backup implementation but, as you stated, it's quite an old solution and most of the times nowadays is not up to the job.

An export CAN be a valid backup IF it fits the recoverability requirements and recovery is exercised regularly.

You mean, like this statement here?

"I suppose as long as those who use this approach understand the implications fully, I'm quite relaxed about it. "

So I think you're telling me something I already said

You did the same and assumed (read guessed) that the requirements must be much higher.

No I didn't actually, you 'guessed' what I meant. It might just have been a joke, it might have been a serious point, but you don't really have enough information to go on, and yet you guess what I mean?

That's the problem with deciding what is and isn't a guess, I think it might be trickier than you think. But then, I'm just guessing about what you might think, as you were guessing what I might think (but then it could start to get a little ridiculous from here!).

In the end, even if an export is a way of getting data back ...

- so is a flat file
- so is storing it in an Access database somewhere
- so is someone sitting there and typing it all in again
- so are bits of paper

So any backup method is acceptable but, as an Oracle DBA (which is what I am) I'm sick of hearing this 'export as backup' business and I don't think any of the afore-mentioned methods is very sensible.

Maybe that's why I'll never be a true 'scientist', because even if something is logically correct and interesting, if it doesn't make practical sense to me, I find it hard to justify it.

You know, Noons hit on the real point here. It's about the recovery path and, if people are happy recreating databases then that's fine, but I'm not.

Get the requirements and start from there.

(deep sarcasm) You know, I hadn't thought of that, but I will in future - thanks for your help!

About other backup methods you proposed. Well, I assume they could be used but cost, maintenance and reliability would probably be less favorable whereas export is a standard low-maintenance technology.

While not disagreeing with your comments in general, it's only fair to point out that the web page you point to (BylineonOracle) is specifically for using Oracle database for Byline (http://byline.objectweb.org/) which appears to be a content management system.
Their advice may be quite appropriate for that particular application.

Yes I noticed that and I'm sure anyone who visited the link would. However ...

Their advice may be quite appropriate for that particular application.

I don't see how it's relevant. If it had said - "recreate the database using standard Oracle methods and then run our patented content loading utility", then I might see your point. But it doesn't. It says

Backup :-

exp system/manager file=$FILE consistent=y full=y compress=n

Restore from a backup :-

imp system/manager file=[filename] full=y

If you can explain to me how that's going to help them recover from a corrupt or deleted data file, I'm all ears!

As far as I'm concerned it's terrible advice. I don't care what application they're using the backup and recovery advice for the underlying database is deeply flawed.

Bear in mind I said

It's quite common and I suppose as long as those who use this approach understand the implications fully, I'm quite relaxed about it.

in an earlier comment. I know people use exports as backups, but let's be clear that it will require database recreation which is way more difficult than the import part. So is it that people always seem to neglect mentioning that part? Is it because they haven't thought it through properly?

I guess the problem is the use of the words "backup" and "recovery" in the context of exp/imp. Or vicky-the-versa.

I know: we have all seen the odd site here and there that uses exp/imp only and are happy with it. Heck, I used to be a remote dba in a site that did just this! No matter how much I explained that was not a backup/recovery strategy, they insisted it was enough for their purposes.

All they did run was a mickey-mouse size Peoplesoft HR installation with a few GB db. They never ran nightly jobs and it only took half an hour or so to do a exp consistent=y at midnight. And the db was on a huge SAN: not exactly the easiest way to lose data. Although it can happen, of course.

It was right for them, I suppose. I was never convinced and never managed to convince them to change. Their new inhouse dba has now got them using archivelog recovery. They still do the exp/imp for "logical recovery" of the odd table here and there. Whatever that means, if it keeps them happy...

But the thing that strikes me as downright scary is the imp advice in this web site. I can't see one single instance where that would work as "recovery":

1- lost part of db? Well, you just created duplicates for what's left, buddy!

2- lost the entire db? Well, how can you run imp against a non-existent db, in the first place? It needs the exp/imp dict views to run!...

Then again, you folks should see the instructions we got the other day to move a SQL Server: suffice to say we couldn't even login as admin after we finished! This from a company with a HUGE name in the accounting industry.

I don't disagree it is explictly a bad backup strategy. The rants are appropriate.

But I have to point out, they don't say "recover," they say "restore."

I think in the backup docs near the beginning somewhere it is explicit about what backup means for that doc, which of course is different then the usage in the general computing world, and we forget that. People even maintain that exports are not backups, which they are according to the docs - logical, not physical.

But it isn't a restore either, at least it's missing the rather large part where you create a new database first with the appropriate tablespaces of the right sizes that you just lost. Rather a key step.

Until I got really happy with the flashback stuff I used always to run a backup and an export for the logical corruption problems (PITR). But the export was never a backup.

Of course you are right, the tablespace creation sizes or placement in the export could be way off, though you don't necessarily have to create a new db, that depends on the circumstances - refreshing a test db on a different platform is but one obvious case. But the imp won't work without uncompressing the file anyways! (Note the gzip in the export

First of all - Orablogs isn't, and never has been sponsored or endorsed or in any way controlled by Oracle.

Secondly, I have no connection whatsoever to Oracle marketing (perish the thought). I'm a software engineer on the JDeveloper team, and I set up and maintain Orablogs primarily to give something back to the Oracle community.

I've spent hundreds of dollars of my own money maintaining the servers, and I've resisted numerous requests to put advertising and other revenue generators on the site in order to maintain its neutrality. At times I've been within a hair's width of pulling the whole site down. It's frustrating and surprisingly unrewarding running a site like this.

But others both within and outside Oracle have always convinced me that it's a valuable resource that was instrumental in fostering the early Oracle blogging community several years ago and that it should keep running.

I fundamentally believe in free speech. Every Oracle related blog (regardless of how "right" or "wrong" I or others believe it is) that someone sends to me for inclusion is considered with equal weight.

Disclaimer

For the avoidance of any doubt, all views expressed here are my own and not those of past or current employers, clients, friends, Oracle Corporation, my Mum or, indeed, Flatcat. If you want to sue someone, I suggest you pick on Tigger, but I hope you have a good lawyer. Frankly, I doubt any of the former agree with my views or would want to be associated with them in any way.