Re: import terminology

On Jan 30, 7:10 am, Fred Pierce <l..._at_avialantic.com> wrote:
> On Fri, 26 Jan 2007 15:30:15 -0500, Fred Pierce <l..._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.

I dunno, it seems like all the development projects I've been involved
in require modifying metadata (even if just adding a column, but usually
more), so refreshes always involve some way of dealing with that. My experience has skewed towards 3rd party packages that tend to have additional requirements between creating metadata and importing data, so that usually means refreshing the data is much easier by creating or recreating a schema from scratch. Or cloning production and then updating metadata and data as needed (common for the case of an application upgrade).

To me, it seems pretty fundamental that development metadata is going to be ahead of production metadata. Metadata may change in an abrupt manner, for example, a datatype may change or how a trigger is used may change, procedures may necessarily change. You also need test data that tests boundaries, so production data is insufficient for testing.

This context is quite different than, say, refreshing a DSS or DW.

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

And of course, with triggers, you have to deal differently with schema name changes.

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

:)

I treasure my "thanks for the grist" emails from scottadams.

jg

--
@home.com is bogus.
"I am strong
I am invincible
I'm a fella!" - Credibility Gap, IIRC