I work for Amazon Web Services. The opinions I share in this blog are my own. I'm *not* communicating as a spokesperson for Amazon.
In other words, I work at Amazon, but this is my own opinion.
Join 744 other subscribers
All content is © Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2015. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Kevin Closson and Kevin Closson's Blog: Platforms, Databases, and Storage with appropriate and specific direction to the original content.
Of course, the primary mission of a DBA is never to allow the situation in which an offline unloader must be used. Maybe a situation in which DUL was the only recourse left, would motivate the company management to hire a competent DBA?
I agree, a competent DBA should be able to minimize the risk of this occurence. Though, there are other things which can cause this, such as poor tape management, developer-written application data backup scripts, and intentional destruction; all of which are out of the DBAs control.
For the most part however, good processes will always minimize the risk of requiring DUL.
The existence of a tool can never hurt. Period.
I’ve seen tools that should not exist, as the simple handling of them hurts. Broken tools (real or virtual) are just one example.
Another way of putting it, the potential of abuse or misuse far exceeds the potential of use.
Remember “good viruses?”
Joel,
To your post, I can certainly attest to seeing several tools which have caused more harm than good. But, for the most part, I believe tools in and of themselves are generally harmless.
Per the DUL utilities, they all open Oracle’s data files in read-only mode, so they themselves aren’t going to cause any further corruption.
As to whether a tool is used correctly is a completely different story. Certainly, DUL utilities (as well as several others) can be used for bad, because they can extract data from a database without any database-level permission. Though, that security aspect is mitigated at operating system level.
I don’t think you were specifically talking about DUL utilities, just tools in general. And, I agree that before one uses any tool, they should understand something about it and what, if any potential issues may arise from its use.
Yes, I was just responding to Kevin’s generic statement. There could be a lot more said about that – there was a big ruckus once about a company distributing live virus samples, and need I bring up Oracle security…
However, check out a thread on cdos entitled “MYDUL avaialbe for recovery, another choise of DUL. Options”
There you will find some abuse of the fellow who wrote it, as well as some actual issues. The abuse arose from his previous tool which was not read-only. It may well be a good tool (I am basically an optimist about such things, since that’s what I would do given the time and motivation), but we don’t know that – and there have been people attempting to sell Oracle malware in that group. And I don’t know that you’ve checked the tool out from your blog posting (not that there’s anything wrong with that, I’ve certainly posted about many things I haven’t tried personally), and if he’s now an ACE, that in itself may lend credibility. On the other hand, the author is in a place that recently has shown a different definition of business ethics than the western world is used to. Check out the recall wall at your local Wal-Mart.
Hey, it’s the internet, people.
Yes, Joel, we are all deathly afraid of that screwdriver and hammer sitting over there on the workbench. Citing “live virus samples” in a discussion about tools is off topic.
The existence of a tool can never hurt.
Also, I just about censored your comment, Joel. The bit about the ethnicity of that Chinese guy schlepping his data unloader (DUL) over on c.d.o.s is not germane to this thread.
Err, ok, I’ll be more explicit. See the discussion entitled “Could This Good Virus Be Created? ” Sep 23 1996 in alt.comp.virus (and there are other examples, but that one is classic). It is on topic as part of the discussion is about whether a tool can hurt, and personally I think it shows the answer is “yes.” Of course, I had had my Amiga for 11 years at that point and still have all those joke viruses, my favorite is the one that melts the pixels down the screen.
As far as the ethnicity thing, I think I was fairly describing the current zeitgeist about Chinese products. That does not mean I endorse it. I hope you didn’t censor me because you understand that on some level. But it also doesn’t mean we should not speak of the issue because of Political Correctness. (And of course, it does mean we should be clear in our expositions, but that’s nearly impossible given the distorting lens people will always use interpreting these kinds of statements).
“Trust, but verify” may work for advice from gurus, but does not work for downloaded software (yes, even from Oracle, Jonathan Lewis has blogged good points about scripts on metalink, the docs and elsewhere – even his own). It should be “Distrust, understand and verify.”
[you can censor this next sarcastic one if you want:] And if you don’t think there is a problem, I know where you can get a GREAT deal on toothpaste!
Joel,
We are off topic now, but I need to point out that the portion of your earlier comment that I think was boarder line was:
“On the other hand, the author is in a place that recently has shown a different definition of business ethics than the western world is used to. Check out the recall wall at your local Wal-Mart.”
I read this as insinuation that since the author of that “tool” (a tool that has nothing to do with Jonah’s kit and list BTW) hails from China therefore there might be a propensity for…
There’s no room for Xenophobia here so let’s be careful.
where can i get tom pro*c utility