"mcstock" <mcstockspamplug_at_spamdamenquery.com> wrote in message news:<2IadnQAB98PiCiyiRVn-vg_at_comcast.com>...
> little bit of a late post but...
>
> "they don't have time to make up test data" -- it takes less time than
> discussing why they need to use the production database for testing
>
> if all they need is realistic test data, just export the necessary tables
> from the production database, then import them into the 'test' database --
> the import can be rerun (after truncating the 'test' tables) anytime they
> need a predictable test environment
>
> "Van Messner" <vmessner_at_bestweb.net> wrote in message
> news:vr32jasq6tf0ba_at_corp.supernews.com...
> > You guys are all right. They obviously shouldn't be playing with
> production
> > this way. But I've seen a lot of Oracle at a lot of companies, and not
> > having test and/or devl and/or user acceptance is all too common. And not
> > having a proper backup schedule, and not practicing recovery, and having
> > business users with enough clout who always get their way, etc, etc.
> > The op didn't say what she could control and what she couldn't. BUT... if
> > all she's doing is selecting from a 50,000 to 1,000,000 table over a link
> 30
> > times a day, she probably won't get into too much trouble.
> >
> >
> > "FlameDance" <flamedance_at_gmx.de> wrote in message
> > news:bomh95$nt4$03$1_at_news.t-online.com...
> > > Rose wrote:
> > >
> > > > They requested
> > > > a database link to production so they can perform their research to
> > > > the production environment through this database link.
> > > > Their investigation consists of procedures that read files of any
> > > > number between 50,000 to 1,000,000 records and perform queries
> against
> > > > the production database - one by one. Since their customers make
> about
> > > > twenty to thirty different requests every day, they don't have time
> to
> > > > make up test data. Therefore they also wish to test their procedure
> > > > with production data using this same databalink link.
> > >
> > > I'd not do this. The risk of messing up the production database is too
> > > high should they do more than reading, and depending on the machines and
> > > the databases configuration you may run into serious performance
> > > problems with big queries - which both are a definite nono for the
> > > production database.
> > >
> > > What I'd do is the following: Set up another seperate machine and run a
> > > mirror database on it, either by doing a daily export/import from
> > > production to mirror or by linking the mirror database directly to the
> > > production database. (The latter has the additional advantage that,
> > > should the production machine fail, you can switch to the mirror machine
> > > quickly and call it the new production machine. It requires more
> > > administrative effort though to set up.) Then let them do their research
> > > on the mirror database, in an additional seperate tablespace and under
> > > an additional seperate user.
> > >
> > > Yours,
> > > Stephan
> > >
> >
> >
I am sorry if I was not clear. "The production tables average about 80
million records". They are reading about 50,000 to 1,000,000 rows of
data from flat files and doing queries on the production tables using
this data as search criteria.
Received on Sun Nov 16 2003 - 19:01:22 CST
