Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: How I save Cingular Wireless USD 30M

Re: How I save Cingular Wireless USD 30M

From: Jeremiah Wilton <>
Date: Sat, 25 Aug 2007 21:04:01 -0700
Message-ID: <>


You say that the 'orphaned segments' caused a performance problem. What was the database spending time doing to cause this performance problem?   If you had done nothing about the orphaned segments, what would have prevented someone from taking the same steps to manually update the data dictionary at the point that the database became so slow as to be unusable.

Your assertion that you saved Cingular $30MM seems to imply that had you not taken action that there would have been complete loss of data. Can you characterize how that data loss would have occurred?

This response actually is not very technical. My chief gripe is that it doesn't say how a person like myself with no apparent psychic abilities vis-a-vis Oracle databases might have detected and resolved the problem.

Most people on this list (hopefully) use wait events, preferably via ASH, to detect the root cause of performance problems. How was the time   being accounted for in the wait event interface? DD reads are accounted in that interface just as normal index and heap segment reads are. So you can see why some people here who approach problems in an empirical manner might have questions about the character of the problem.

My questions in no way are meant to invalidate the way that you solved the problem. After all, if you solved it, regardless of how you obtained the solution, wasn't the problem solved?


Jeremiah Wilton
ORA-600 Consulting

Tom Pall wrote:
> I did the traces, ran Staspack till I was blue in the face, set the
> events to trap deadlocks. I did all of the things a DBA would do but
> decided that there was something deeper than just two applications
> colliding, because as I worked the problem over a two week period, I
> noticed the database slowing down. Not waits slowing down, not I/O
> slowing down, just throughput slowing down. Slowing down in ways
> neither I nor Oracle Support could explain before my dream, research in
> Metalink and discovery of hcheck.sql in Metalink.
> Is this technical enough?

Received on Sat Aug 25 2007 - 23:04:01 CDT

Original text of this message