Re: Database Performance Problem between 3:00PM and 4:00PM

On Oct 23, 3:11 am, gazzag <gar..._at_jamms.org> wrote:
> On 22 Oct, 18:46, joel garry <joel-ga..._at_home.com> wrote:
>
>
>
>
>
> > I agree, and the first thing I would look for is some performance
> > monitoring tool!
>
> > When I was taking networking (circa 1982) in school, my professor was
> > the fellow who had done the arconet, which connected AM/PM minimarts
> > with a 9600 multidrop line. It had just been shutdown due to
> > insufficient performance. Anyhow, he told a story which totally
> > cracked me up. I've posted it before, but can't remember where, so
> > apologies to those who've heard this before. Imagine a thick
> > Hungarian accent...
>
> > As I recall the story went, a particular subnet would shut down every
> > night at 9PM. They tried a number of tools (in those days, one wrote
> > ones own), and could only find that some noise started at that time.
> > Finally he went to one of the stores involved and waited until 9, and
> > sure enough it went down. He plugged in a phone (in those days, it
> > was analog), and heard "THIS IS THE VOICE OF GOD!"
>
> > Turns out, a large AM transmitter was nearby, and would start
> > broadcasting a Christian radio show at 9PM every night, overwhelming
> > the data signal via induction.
>
> > I've also worked in a couple of industrial areas where the place next
> > door would turn on large machines at particular times, affecting
> > hardware that was not isolated enough. Even my current customer
> > recently got affected by some transient packet storm that overwhelmed
> > one of an hp-ux machine's network interfaces, killing telnetd and the
> > console. It's a dirty, dirty world.
>
> > jg
> > --
> > @home.com is bogus.
> > At least one web page is still up: http://www.sdcountyemergency.com/-Hide quoted text -
>
> Great story :-)
>
> I used to work for the Ministry of Defence here in the UK. We had an
> issue once where the database server on an army site, for no apparent
> reason, would reboot at random intervals. Needless to say , it was a
> high-profile system and the army top-brass were making one heck of a
> racket to get it sorted. We even had the local electricty company in
> as, initially, I suspected power surges from the mains. None of the
> data we accumulated corrolated with anything; the problem seemed
> genuinely random. We had memory changed, CPU's changed, even the
> whole damn motherboard went through a few incarnations, yet still the
> problem persisted. The army started blaming the hardware supplier and
> there was even talk of contracts being terminated and a new system
> being sourced.
>
> Then, one day, while sitting in the server room, mulling over and over
> all the different things we'd tried, and all the things that had
> failed, a slow rumble of realisation began to form in my mind. But
> then the rumble got louder and louder and louder. I started to
> realise that the rumble that I thought I was imagining was real when
> the floor began to shake. I jumped up and ran to the window to see
> what the heck was going on. Then I saw the likely cause of our
> problem as 60-something tonnes of Challenger tank (http://
> en.wikipedia.org/wiki/Challenger_1_tank) hoved into view and made a
> right turn past the server room.
>
> It wasn't power surges or network glitches; merely disks and disk-
> heads being almost rattled out of their casings :-)

LOL! Love IS war stories, especially when they involve tanks :-)

One place had network problems, every time the Assistant Director rolled his chair across the thinnet. Also had problems whenever he turned his PC on, which was rare because he was a technophobe, but his IP was the same as something else. Duhhhhhhhh...

zigzag, please show the top waits from the statspack? Also the plans as Robert suggested, this has all the earmarks of something outside the server, and you need to show your people exactly why Oracle thinks the disk or network is slow, if that is what it is.

Going off into lala land here, but I'm wondering if this is one of those odd cases where there are a number of things Oracle is waiting on, and you are looking at the top 5, but it is the 8th thing that is the problem for the specific db accesses that people are noticing.

jg

--
@home.com is bogus.
http://www.google.com/search?hl=en&q=%22Unibus+timeout+fatal+trap+program+lost+sorry%22+&btnG=Google+Search