| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.misc -> Re: import terminology
On Fri, 26 Jan 2007 15:30:15 -0500, Fred Pierce <lists_at_avialantic.com>
wrote:
>Would some of you be so kind as to comment on the veracity or lack
>thereof of the following definition for a "data only" import?
>
>"a data-only import would be a refreshment of tables - and
>consequentally their indexes, views and triggers. Packages,
>procedures and functions aren't supposed to be modified."
>
>Oh - and the definition quoted also apparently includes dropping the
>tables, though it's not stated.
>
>I'm intentionally leaving out any background or context since I just
>want your reaction to the statement as it stands.
>
>Thanks,
>
>Fred Pierce ("this is not my quote" Well, that is, but not the one I'm
>asking to be evaluated. By "that", I mean the "this is not my quote"
>part. By "part" I am referring to this message. )
>I really hope I won't be misunderstood.
>
>-------------------------------------------
>Fred Pierce - DNRC - avialantic.com
>
>
Thanks to all for the feedback thus far. There seems to be a concensus that the statements hold up. The reason for the post is that I'm trying to figure out a communications problem, i.e. how far is it necessary to go in defining an instruction (what does "is" mean?) and how responsibility for clarification is apportioned, i.e. sender and receiver.
The reason I posted the question was to test whether my basic assumption of the meaning of "import data only" was universal. Apparently not, so it looks like I will have to put down the bludgeon. I will, however, now add some context (and my interpretation of the phrase) to see if your evaluation of the statement changes.
In all the projects with which I've been associated, "data only" refreshment meant just that - the contents of the tables were replaced. DDL structures remain intact except for disabling constraints & triggers to allow the refresh to take place. Add context - replacing test data with the latest production, and it would seem clear that any change to the database objects, i.e. dropping the next-generation test tables, over-writing triggers with the production versions would cause havoc with the test environment I also wonder by what definition are triggers "data," etc.? Another way of looking at it would be that "refreshing data" is DML. The only DDL involved would be that necessary to allow the import which can certainly be done with either import or datapump without dropping or overwriting any objects.
Further in regard to dropping the tables or any other objects, this was *never* done without ensuring that it was acceptable by the requestor. "Common knowledge" in the project. Define "common knowledge."
The perp - er - DBA carrying out the "refresh" has been with the project for over two years and assured all that "data only" was understood. It should be noted though, that this person *always* asserted that they understood the task and seldom asked questions. The effect of the action would have been less if anyone had known that the more than the data had been "refreshed." Lots of head scratching and "how did this happen?" before realizition dawned.
This is just one incident in a comedy of errors that I am trying to remedy with training, documentation, beatings and whatever other means I can find (not true - beatings, torture, dismissals etc. are generally not acceptable). Most of it has to do with the difficulty of communication among people with different skills, levels of knowlege, incentive, etc. DBA's, developers, and of course, managers.
I've begun weekly training sessions based on the problems I've observed over the past couple of years and even though I should know better, have been surprised at how much knowledge I take for granted, definitions and methods I "just know" etc. Since (in this working environment) employees are given the benefit of the doubt in anything they do wrong, silk-purse making is a big part of the job, and I appreciate your allowing me to bounce these thoughts off of the group.
Although I haven't been able to contribute much, reading the c.d.o groups over the years have helped me keep my perspective, since for the most part I'm the only DBA etc. around except for whatever conferences I can get to.
Thanks,
fdp
P.S. Joel - I've been including the DNRC in my sigs off and since it was formed, and you're about the 5th person to comment. We are few, but strong!
 |
 |