What is in a pipe?
Geoff May
I'm trying to work out how many messages are queued in a pipe and how
long said messages are. Anyone got any ideas?
So far, the best I can come up with is something silly like receiving
DBMS_PIPE messages, unpacking them, counting and adding lengths and then
repacking and requeuing the messages.
What I would like is something like this:
select * from DBA_ALL_ABOUT_PIPES;
And DBA_ALL_ABOUT_PIPES has the name, type of pipe (public or private),
size, number of queued messages and length of messages.
Anyone have any ideas?
Cheers
Geoff
K Gopalakrishnan
How about checking V$db_pipes?
It does have the pipe_name and type (public/private).
-Gopal
ddf
But it basically stops there, and does not provide the information the
OP requested. It's likely the OP will need to 'roll his own' utility
or methodology by creating a table to contain the desired data then
populating that table with each call to dbms_pipe.pack_message. This,
then, creates a possible maintenance nightmare as every call to
dbms_pipe.unpack_message would require a delete from this same table
for the record matching the unpacked pipe messge. Absent that
consideration the OP could then query his home-grown table to find, at
any moment, the expected contents of the desired pipe (given, of
course, that all of the inserts succeeded and none of the deletes
failed).
David Fitzjarrell
Ed Prochak
There is not a general way to do this, even in the UNIX world where
pipes are used extensively.
One reason for this is about the time you get an answer, the
information is likely wrong.
So why would you want this?
ddf
>
> - Show quoted text -
Maybe he's checking for leaks ... :D
David Fitzjarrell
joel garry
Or invasive root... :-D
jg
--
@home.com is bogus.
I once rehabbed a house that had been vacant a while. The sewer
worked fine for a couple of weeks. Sewer guy told me old dried sludge
had taken that long to absorb water and expand.
Geoff May
> On Jan 29, 8:11 am, ddf <orat...@msn.com> wrote:
>
>>On Jan 29, 9:49 am, Ed Prochak <edproc...@gmail.com> wrote:
>>
>>
>>>So why would you want this?
>>
>>
>>David Fitzjarrell
>
> Or invasive root... :-D
<snigger> :-)
Basically, the current application requires information from remote
servers. It takes a while to get this information and we use the pipes
to advise the application that the data has been fetched. The problem we
are experiencing is that we know the pipes are getting overloaded but we
don't know why. That's why I want to know how many messages and how big
said messages are.
Gopal pointed to the view but, as David said, there isn't enough
information in there for me. One of the lads at work found something
called OraPiper (I think I got that right) but, judging by the
documentation, it does what I don't want to do (receive the message,
unpack, repack and send the message back into the pipe).
Anyways, thanks to all for the help and if anyone does think of
something, I would be most appreciative.
Cheers
Geoff.
hpuxrac
snip
> Basically, the current application requires information from remote
> servers. It takes a while to get this information and we use the pipes
> to advise the application that the data has been fetched. The problem we
> are experiencing is that we know the pipes are getting overloaded but we
> don't know why. That's why I want to know how many messages and how big
> said messages are.
>
> Gopal pointed to the view but, as David said, there isn't enough
> information in there for me. One of the lads at work found something
> called OraPiper (I think I got that right) but, judging by the
> documentation, it does what I don't want to do (receive the message,
> unpack, repack and send the message back into the pipe).
>
> Anyways, thanks to all for the help and if anyone does think of
> something, I would be most appreciative.
Use AQ instead of pipes?
Jonathan Lewis
"Geoff May" <Do...@Spam.Me> wrote in message
news:6ubvu7F...@mid.individual.net...
This might help:
http://jonathanlewis.wordpress.com/all-postings/
--
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
joel garry
wrote:
> "Geoff May" <Do...@Spam.Me> wrote in message
>
> news:6ubvu7F...@mid.individual.net...
>
>
>
>
>
> > Hi all,
>
> > I'm trying to work out how many messages are queued in a pipe and how
> > long said messages are. Anyone got any ideas?
>
> > So far, the best I can come up with is something silly like receiving
> > DBMS_PIPE messages, unpacking them, counting and adding lengths and then
> > repacking and requeuing the messages.
>
> > What I would like is something like this:
>
> > select * from DBA_ALL_ABOUT_PIPES;
>
> > And DBA_ALL_ABOUT_PIPES has the name, type of pipe (public or private),
> > size, number of queued messages and length of messages.
>
> > Anyone have any ideas?
>
> > Cheers
>
> > Geoff
>
> This might help:
>
> http://jonathanlewis.wordpress.com/all-postings/
That one is just awesome.
It does beg Ed's point about timeliness. I only say anything because
of Geoff's emphasis on packing/repacking implies a high level of
consistency, while the cool script would be sampling inconsistently,
if I understand this right. But the requirement of figuring out what
is overloading the pipes and why may be satisfied. This depends on
refining the requirement. If it's just going to be used by a couple
of guys, ok, but if it's being put on top of a product or starts
blindly propagating through the universe it's likely to lose the blog
context...
jg
--
@home.com is bogus.
28 year old single mom living in 2 bedroom apartment with her mother
has fertility treatments, octuplets. Last year they lost everything
in bankruptcy, now Grandpa is going back to Iraq...
Jonathan Lewis
Thanks, I was quite pleased with it.
> It does beg Ed's point about timeliness. I only say anything because
> of Geoff's emphasis on packing/repacking implies a high level of
> consistency, while the cool script would be sampling inconsistently,
> if I understand this right. But the requirement of figuring out what
> is overloading the pipes and why may be satisfied. This depends on
> refining the requirement. If it's just going to be used by a couple
> of guys, ok, but if it's being put on top of a product or starts
> blindly propagating through the universe it's likely to lose the blog
> context...
The way I read the requirement, it was for a rapid, low-cost,
diagnostic, just like any other snapshot of the dynamic performance
views.
I think the references to unpacking and repacking were making the
point that that wasn't a feasible option. In fact, if you unpack and
repack, then you'll miss some stuff that comes in as you're getting
stuff out, and some new stuff will come in and spoil the ordering
as you put the old stuff back ! So I don't think you can do anything
with consistent checking of pipes unless you stop the feed to do so.
I realised from your post that I put the wrong URL up for the
article, so I've given the right one below.
http://jonathanlewis.wordpress.com/2009/01/30/pipes/
Geoff May
> On Jan 29, 3:49 pm, Geoff May <Do...@Spam.Me> wrote:
>
>
> Use AQ instead of pipes?
We are working towards that but these are all legacy applications so we
have to rewrite a lot of code. Still, we are getting there.
Cheers
Geoff
Geoff May
> "Geoff May" <Do...@Spam.Me> wrote in message
> news:6ubvu7F...@mid.individual.net...
>
Hi Jonathan,
As Joel said, this is awesome. Once again, thanks very much. It is
exactly what I need.
Cheers
Geoff