Re: Building Slow Development Systems (On Purpose)
- From: Mathias Magnusson <mathias.magnusson@xxxxxxxxx>
- To: sfaroult@xxxxxxxxxxxx
- Date: Wed, 27 May 2009 22:43:27 +0200
Try creating a raid 5 where you stick all tables and indexes where it is
made up of different partitions from the same disk. That should make
it sufficiently slow.
But I do not see this as working at all. One place I know that has a similar
situation (not on purpose, but it is very slow) has a culture of "it doesn't
matter, we know it will be much faster in production". There is also a
general rule of not trying to create a system to outsmart developers because
they will outsmart the system.
I really don't think that approach works at all. If a developer is curious
to learn how to do it well, he/she may well also figure out that they have a
clueless DBA when it comes to supporting development to become productive.
Would it be good to remove OEM and such tools, take away SQL trace as well
as all Oracle tables and leave the DBA with nothing but the raw 10046 trace
(not allowed to format it) to make sure they learn how to tune with just
pure raw data? Most DBAs would just return top the time where god
performance was a result of black magic and a few lucky people would know a
little more and go from place to place with their magic wand.
I do not believe in slowing people down by giving them an environment that
does not perform like production. One side effect could be that things gets
developed that are heave on CPU, takes much longer than it should and wastes
a resource more precious than I/O.
Why not try something as novel as talking to the developers? If the benefit
of making something faster isn't enough, then maybe the ROI for the whole
organization just isn't there. Maybe making our lives easier isn't what is
in the best interest of the whole organization. Surely, having developers
that understands the database is much better than developers that thinks it
is just horribly slow and you should do what you can to not use it.
Mathias
On Wed, May 27, 2009 at 9:39 PM, Stephane Faroult <sfaroult@xxxxxxxxxxxx>wrote:
> Kerry,
>
> I think it's a great idea. I remember having read when I was a kid
> that the guy who won the gold medal for discus throwing at the very
> first Olympic Games had used for training a copy of the discus used by
> athletes in the antiquity - which was must heavier than its modern
> counterpart.
> A very small SDU in the tnsnames.ora file could also incite developers
> to perform fewer roundtrips. Putting redo log files on a very slow (or
> very busy) disc could calm down folks that commit every row they insert.
> The sad thing is that I don't see how to make PL/SQL cursor loops slower
> than they are ...
>
> HTH
>
> SF
>
>
> Kerry Osborne wrote:
> > Hey guys,
> >
> > I did a post yesterday about a conversation I had regarding
> > "encouraging" developers to write tighter code by intentionally
> > hampering development system capabilities. Specifically, using a very
> > small buffer cache which basically turns all the lio's into pio's,
> > thus (theoretically) encouraging developers to minimize lio's. There
> > have been some good comments already but I thought I would poll you guys.
> >
> > My initial reaction to the idea was that it was just plain crazy.
> > But for some reason, over the last several days, the idea keeps
> > popping up to the top of the stack in my brain. I fully expect to get
> > flamed a bit, but I'll try not to take it personal. I would request
> > that you give it an hour or two to roll around in your brain before
> > you respond. It is a bit counter intuitive and it is certainly counter
> > to what I've always thought of as the "ideal", which is DEV being an
> > exact duplicate of PROD in every respect (I'm still waiting to see my
> > first one of those by the way).
> >
> > Note that my conversation was about DEV environments, not QA
> > environments. QA environments should, IMHO, always be as close to PROD
> > as possible (same stats, etc...) But maybe there is an argument for
> > "encouraging" developers to minimize lio's.
> >
> > Feel free to flame away.
> >
> > Kerry Osborne
> > Enkitec
> > blog: kerryosborne.oracle-guy.com
> >
> >
> >
> >
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
