Re: null event causing concern

Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1064246222.280685_at_yasure>...
> John Ashton wrote:
>
> >Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1063984761.892697_at_yasure>...
> >
> >
> >>John Ashton wrote:
> >>
> >>
> >>
> >>>We seem to have a pl/sql procedure that can occionally take a very
> >>>long time to complete (> 13 hours). It is a big task but it would
> >>>normally complete within 2 hours.
> >>>
> >>>As I'm not a DBA and I have limited rights so I have only been able
> >>>get a partial view into what is happening (yes I have asked the
> >>>support company X's DBA to investigate but there are political reasons
> >>>why I feel I need to look at this too).
> >>>
> >>>The only thing I can see that bothers me is the following from
> >>>v$session_wait for the PL/SQL procedure session:
> >>>
> >>>EVENT P1 P2 P3 TIME SECONDS_IN_WAIT STATE
> >>>null event 301 87541 1 -1 26 WAITED KNOWN TIME
> >>>
> >>>Every time I see this null event, P1 is either 301 or 150 but I don't
> >>>know what this parameter refers to. I thought maybe it was file# but
> >>>there are no files above 160.
> >>>
> >>>Can anyone tell me what this event might be?
> >>>
> >>>Thanks
> >>>
> >>>
> >>>
> >>>
> >>I can't tell you whether the above has any relationship to your problem
> >>but I can tell you that you should
> >>get a copy of Tom Kyte's book "Expert one-on-one Oracle" or go to
> >>http://tahiti.oracle.com and learn
> >>how to use DBMS_PROFILER. It will point you to where the problem is ...
> >>though not the underlying cause.
> >>
> >>
> >
> >I realise that you think that most people who post to newsgroups are
> >idiots who don't bother to read manuals or understand the tools they
> >use but I did mention that I have limited rights to the live server
> >and cannot see much. This includes no read rights to any SQL_TRACE
> >files, no rights to execute DBMS_PROFILER, no login rights to
> >PERFSTAT. The politics of why this is I don't really want to get into.
> >
> >I cannot duplicate the problem on our local development server
> >(DBMS_PROFILER and STAT_PACK look fine) and it does not occur all the
> >time on the live server. I suspect it occurs when the process has to
> >deal with a certain amount of data which pushes it above a threshold
> >that causes the problem.
> >
> >Happily, Jonathon has given me some ideas which I will follow up and
> >try to replicate on our server.
> >
> >
> I will agree with you that I think most people don't read manuals. And
> you'd be hard pressed to find
> many that would disagree with that proposition. But your inability to do
> your job is not, as you state,
> a technical it is a political issue. So either management gives you
> access to the tools you need or you
> can't do your job. I don't see a lot of options there. Surely you don't
> hire a carpenter to build a house
> and then say ... 'sorry you can't use a hammer'.
>
> Rather than telling us what you can't do ... why don't you explain to
> management the list of tools you need
> to do your job. And if they won't support you either polish up your
> resume or resign yourself to doing an
> inadequate job, at best.
>
> --
> Daniel Morgan
> http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
> http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
> damorgan_at_x.washington.edu
> (replace 'x' with a 'u' to reply)
>
>
> --

You're right. It is a political issue. Our client is a division of a large company that would like to use all our skills and give us access to the tools we need. However, the overall company has an outsourcing arrangement for all infrastructure work. This arrangement will not change and has been 'pre-paid'. The division cannot say "we know you pay money for company X to do DBA work but they don't do the job well so pay again to get company Y to do the same job (but properly)".

So, we can advise but not control anything to do with DBA functions, UNIX or the hardware. That's why, for example, company X set up oracle on RAID 5, against our advice. At least we convinced them not to use a single tablespace and that range partitioning was a good thing (which wasn't easy).

If I were working for the client directly, I'd probably resign. However it is the consultancy I work for that is facing the problem. My company would like to be able to avoid difficult projects like this but then I'd say that would be "Goodbye small consultancy".

You may say that I "resign yourself to doing an inadequate job, at best". I prefer to think that I'm doing a more than adequate job but that the end result is inadequate due to 3rd party sabotage.

Time, now, to strike up the violins as I return to the realities of the small business world to do the best I can with what I have... Received on Wed Sep 24 2003 - 06:25:58 CDT