Re: How I save Cingular Wireless USD 30M
- From: "Tom Pall" <oracle.list@xxxxxxxxx>
- To: "Niall Litchfield" <niall.litchfield@xxxxxxxxx>
- Date: Sat, 25 Aug 2007 20:47:03 -0500
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?
Tom
On 8/25/07, Niall Litchfield <niall.litchfield@xxxxxxxxx> wrote:
>
> I must say I find this a somewhat bizarre contribution to the list.
> Normally in a technical posting to this list it would be prudent to mention
> what the problem was, how you diagnosed it, and how you fixed it. In the
> case of a deadlock which can be traced, it would be normal to illustrate
> this process - or why it failed you. Dreams are well and good, the benzene
> ring structure springs to mind, but normally there's a follow up and a
> methodology to investigate the hypothesis. The details of this seem to be
> missing here - you say that you found a script on metalink for example, but
> don't mention the note number. It found some orphaned indexes (The word
> segment is redundant here) - I'm not sure what one of those would be - an
> intact index left when a table was dropped? I've never seen one of those. It
> would be a curious thing indeed, certainly worthy of describing in more
> detail. You also describe being able to give a database a life expectancy -
> I'd love more or indeed any detail on that. In short from a technical point
> of view you don't actually tell us anything.
>
> The alternative I suppose is that this is a disguised job search. The
> trouble with those of course is they tend not to work that well. I did take
> a look at your resume though. Stuff that I would look for would be a concise
> summary of your skills and abilities, your job history shows a number of
> diverse and in demand skills - but it doesn't really tell me what I'm
> getting. With the exception of the 30m saving - and believe me as a hiring
> manager I'd want more confirmation of that than a post to this list merits -
> your resume doesn't tell me how you will contribute to the business except
> as a techie. Incidentally since both the resume and this conversation will
> be indexed by google It would definitely be good to have the Oracle skill
> sets listed out in an easy to read format on the resume - my gut reaction is
> that the version 2 reference below is hyperbole given that that version was
> 12 years old when you started your career (and almost no-one bought it) but
> if your experience really does cover all of Oracle's history selling that in
> the resume would be helpful.
>
> So in summary - if this was intended as a technical post then perhaps a
> rethink about what you can and cannot say might produce a more helpful
> contribution, that is one production dbas can use. if intended as an advert
> - try not to make a habit of it and perhaps a resume rethink might help.
>
> best regards
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
Other related posts:
