Skip to Main Content

SQL & PL/SQL

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

REGEXP question

469875Jun 17 2007 — edited Jul 10 2007
HI ALL,

how do i extract from 'A1B2C3-AZ123' the characters A-Z after the '-' ?

i tried to use:
select regexp_substr('A1A1A1-AZ11', '-[A-Z]+') from dual
but this still returns '-AZ' including the '-' :(

i may want to omit the '-' and capture 'AZ' only.

i tried another substr to omit the '-', but can we do this as a single regexp? :)

help on this one pls :)

THANKS!
BROKEN

Comments

sjensen
Answer
MAXQUEUES is used to specifying the maximum number of Queues - Not number of messages on (each) queue.

To solve your blocking problem, you could consider adding more servers (to speed up the responsetimes).
Another option could be making synchronous calls if that would make sense to whatever application you are designing.
Marked as Answer by 652398 · Sep 27 2020
Todd Little-Oracle
Hi Bill,

From the documentation:
1380
	
ERROR: Message queue blocking prevented delivery, Qaddr = qaddress

Description

The BRIDGE process could not deliver a message it received from the network due to UNIX message queue blocking.

The process(es) associated with the full queue may be identified by looking up qaddress in output of tmadmin 's printserver command (verbose mode).

Another method of examining message queue status is the ipcs -aq command. 
So you need to determine what queues/processes are causing the BRIDGE to be unable to deliver an IPC message. If you check out the documentation, you'll find a list of suggestion on how to cure this problem. See error number 1380 on this page: http://download.oracle.com/docs/cd/E15261_01/tuxedo/docs11gr1/messages/cdtux/cdtux013.html

If you need more help figuring out which action to take, ask here.

Regards,
Todd Little
Oracle Tuxedo Chief Architect
652398
"making synchronous calls" I cannot understand it well. So could u explain it further? Thanks
652398
Yes, I will try adding more servers.
652398
I have another question. Besides mentioned errors in ULOG, the process time of this application in product environment is very slow, nearly more than 1 seconds. However in testing environment, the same process time of application only needs 200 mill-seconds. Whether the process time has related with more requests in queue?
Ed Heeren-Oracle
Bill,

A synchronous call is a call that waits for a reply. tpacall() operates synchronously and tpacall() operates asynchronously().

There can be many reasons why an application might be slower in production than in a test envirionment. The workload might be heavier in production, the hardware might not be identical, or the operating system might be configured differently. One good area to investigate is message queue configuration. When Tuxedo sends a message that would take up more than 75% of the total space on a message queue or when there is no space left on the message queue for a new message Tuxedo uses file transfer. File transfer writes the message to a temporary file and writes a short message to the queue containing the location of the temporary file. This is substantially slower than writing the entire message directly to the queue. Tuxedo writes a LIBTUX_CAT:942 userlog message when tpreturn uses file transfer situation but does not write a userlog message when a client uses file transfer.
On most versions of Unix, the maximum allowable number of bytes on a message queue can be found in the QBYTES column of the output of "ipcs -q -b" . On SuSE Linux the equivalent command is "ipcs -l" . On Windows the message queue limits can be configured within Tuxedo itself. Your Unix or Linux system administrator can help you if message queue size limits need to be increased.

Regards,

Ed
Todd Little-Oracle
Hi Bill,

As Ed points out, load can make a huge difference on application performance. If you are running into queues being full, then you probably have a lot of messages queued. If normal single stream performance of you services gives you 200 millisecond response time, with 4 entries in the queue, your response time will increase to 1 second. 800 milliseconds to process the entries ahead of the request, and 200 to process the request. If there are available system resources, usually CPU although it could be database or other resources that limit the performance of your service, adding additional servers will allow better concurrency, higher throughput, and lower response times. However, if there are resources causing bottlenecks, increasing the number of servers may hurt response time as additional contention will be encountered.

Regards,
Todd Little
Oracle Tuxedo Chief Architect
652398
“If normal single stream performance of you services gives you 200 millisecond response time, with 4 entries in the queue, your response time will increase to 1 second. 800 milliseconds to process the entries ahead of the request, and 200 to process the request.”

Sorry, I cannot understand it well. "Entry" there means every request to the service? If so, in my mind, there maybe 4*200 milliseconds to process 4 entries in the request queue. What's wrong with my thought? Thanks again.
Todd Little-Oracle
Hi Bill,

Sorry if my response wasn't clear. What I was trying to explain was the effect on response times if there are already requests in the queue. If there are 4 requests already in the server's queue, and it takes the server 200 milliseconds to process a request, then it will be 800 milliseconds before a new request placed on the queue would get processed.

The whole point of my post was that if response time when only running one client request at a time differs greatly than when the system is under load, you will need to look for the resource bottleneck and try to alleviate it. The bottleneck could be:

1)Number of servers - If you have inadequate servers configured, then servers become a bottleneck and prevent optimal usage of the other resources in the system.

2) CPU - You may have enough servers to utilize all the CPU resources, so adding more processors or another machine is likely your only option.

3) Database - Databases like any other resource have finite bandwidth and can only process so many requests in a given time period. If you reached that limit, you may need to increase the resources available to the database.

4) IPC Queue Size - As others mentioned, if the kernel configured System V IPC resources are inadequately sized, then you may end up with very poor Tuxedo performance as requests and/or replies may get written to disk temporarily. Using the ipcs command, you should be able to determine whether the IPC queues are getting close to 50% full, either in terms of number of entries or number of bytes queued, and if so, you may wish to change the system IPC limits.

Although there are other possible resource limitations such as memory, disk I/O, etc., the ones above tend to be the ones that most often affect Tuxedo application performance.

Regards,
Todd Little
Oracle Tuxedo Chief Architect
652398
Thanks for your explaination in details.

"it takes the server 200 milliseconds to process a request, then it will be 800 milliseconds before a new request placed on the queue would get processed."

In my mind, the 5th request will wait for 4 requests completed, maybe 800 milliseconds. But when the 5th request is processed, its time will also be 200 millseconds? You mean that because of load queue, the header of the 5th request is written to a local file for Tuxedo searching this request, so it takes much time to process it using file transfer. Is that right?
Todd Little-Oracle
Hi Bill,

You said: "In my mind, the 5th request will wait for 4 requests completed, maybe 800 milliseconds." That is correct. But the response time for that request will 1 second. 800 milliseconds the request waited in the queue, and 200 milliseconds for the server to process the request once it began executing.

Without knowing your IPC configuration, your Tuxedo configuration, the load on the system, etc., it's hard for me to tell if you are getting into file transfer mode. File transfer mode occurs if a message written to an IPC queue would cause the number of bytes on the queue to exceed 75% of the queues capacity.

Have you tried the ipcs command and see how full your queues are when you get these error messages? If you wanted, you could even use the Tuxedo event broker to execute the ipcs command automatically when the error is logged.

Regards,
Todd Little
Oracle Tuxedo Chief Architect
652398
In ULOG, I saw:
211522.v490g-tux!BRIDGE.7488.1.0: CMDTUX_CAT:1380: ERROR: Message queue blocking prevented delivery, Qaddr = 179427
211523.v490g-tux!GWOSITP.23356.1.0: LIBTUX_CAT:1285: WARN: tpreturn message send blocked, will try file transfer

I guess that the application processing every request very long causes the full queue, further turn to use file transfer. I have modified the application that will use less time to process every request. Later, I will put it on production environment and have a try.

A little question, you said that "File transfer mode occurs if a message written to an IPC queue would cause the number of bytes on the queue to exceed 75% of the queues capacity."

1. There is a limit for the number of bytes on the queue? How to get this value?
2. How does file transfer mode process? The header of the message or the content of the message will be written to the file and IPC queue will search this file to transfer it to the application? Where does the file store?

Thanks for your continuous help.
Todd Little-Oracle
Hi Bill,

It would save a lot of time if you could post the output of the ipcs command, especially when you are getting the error message.

The limit on the number of messages in a queue and the maximum number of bytes in a queue are determine by operating system settings on all platforms except Windows. On Windows there is a control panel applet provided by Tuxedo that allows setting these values. On other operating systems they are generally set by some kernel parameters. Please check your operating system's documentation on how to set and tune the System V IPC parameters. For Unix based systems, look for parameters named msgmni, msgmax, msgmnb, etc. to see how to set those. The value for msgmnb determines that maximum number of bytes that can be stored on a single IPC queue.

File transfer works by writing a small bit of information to the IPC queue and writing the message to a temporary file stored in the temporary file system, usually /tmp on Unix. When the small bit of information is read from the IPC queue, Tuxedo then uses that information to locate the temporary file and read in the entire message.

Regards,
Todd Little
Oracle Tuxedo Chief Architect
652398
The following is the result of ipcs.

$ ipcs
IPC status from <running system> as of Wed Dec 29 13:23:24 CST 2010
T ID KEY MODE OWNER GROUP
Message Queues:
q 30720 0xabb02 -Rrw-rw-rw- tuxdcs1 tux
q 220161 0 -Rrw-rw-rw- tuxdcs1 tux
q 51202 0 -Rrw-rw-rw- tuxdcs1 tux
q 25603 0 --rw-rw-rw- tuxdcs1 tux
q 87044 0 -Rrw-rw-rw- tuxdcs1 tux
q 61445 0 -Rrw-rw-rw- tuxdcs1 tux
q 61446 0 -Rrw-rw-rw- tuxdcs1 tux
q 112647 0 -Rrw-rw-rw- tuxdcs1 tux
q 102408 0 --rw-rw-rw- tuxdcs1 tux
q 92169 0 --rw-rw-rw- tuxdcs1 tux
q 92170 0 --rw-rw-rw- tuxdcs1 tux
q 92171 0 --rw-rw-rw- tuxdcs1 tux
q 92172 0 --rw-rw-rw- tuxdcs1 tux
q 92173 0 --rw-rw-rw- tuxdcs1 tux
q 92174 0 --rw-rw-rw- tuxdcs1 tux
q 92175 0 --rw-rw-rw- tuxdcs1 tux
q 92176 0 --rw-rw-rw- tuxdcs1 tux
q 92177 0 --rw-rw-rw- tuxdcs1 tux
q 92178 0 --rw-rw-rw- tuxdcs1 tux
q 92179 0 --rw-rw-rw- tuxdcs1 tux
q 92180 0 --rw-rw-rw- tuxdcs1 tux
q 92181 0 --rw-rw-rw- tuxdcs1 tux
q 92182 0 --rw-rw-rw- tuxdcs1 tux
q 92183 0 --rw-rw-rw- tuxdcs1 tux
q 92184 0 --rw-rw-rw- tuxdcs1 tux
q 92185 0 --rw-rw-rw- tuxdcs1 tux
q 92186 0 --rw-rw-rw- tuxdcs1 tux
q 92187 0 --rw-rw-rw- tuxdcs1 tux
q 92188 0 --rw-rw-rw- tuxdcs1 tux
q 92189 0 --rw-rw-rw- tuxdcs1 tux
q 92190 0 --rw-rw-rw- tuxdcs1 tux
q 92191 0 --rw-rw-rw- tuxdcs1 tux
q 92192 0 --rw-rw-rw- tuxdcs1 tux
q 92193 0 --rw-rw-rw- tuxdcs1 tux
q 92194 0 --rw-rw-rw- tuxdcs1 tux
q 92195 0 --rw-rw-rw- tuxdcs1 tux
q 92196 0 --rw-rw-rw- tuxdcs1 tux
q 92197 0 --rw-rw-rw- tuxdcs1 tux
q 92198 0 --rw-rw-rw- tuxdcs1 tux
q 92199 0 --rw-rw-rw- tuxdcs1 tux
q 92200 0 --rw-rw-rw- tuxdcs1 tux
q 92201 0 --rw-rw-rw- tuxdcs1 tux
q 92202 0 --rw-rw-rw- tuxdcs1 tux
q 92203 0 --rw-rw-rw- tuxdcs1 tux
q 92204 0 --rw-rw-rw- tuxdcs1 tux
q 92205 0 --rw-rw-rw- tuxdcs1 tux
q 92206 0 --rw-rw-rw- tuxdcs1 tux
q 92207 0 --rw-rw-rw- tuxdcs1 tux
q 92208 0 --rw-rw-rw- tuxdcs1 tux
q 92209 0 --rw-rw-rw- tuxdcs1 tux
q 92210 0 --rw-rw-rw- tuxdcs1 tux
q 92211 0 --rw-rw-rw- tuxdcs1 tux
q 92212 0 --rw-rw-rw- tuxdcs1 tux
q 92213 0 --rw-rw-rw- tuxdcs1 tux
q 92214 0 --rw-rw-rw- tuxdcs1 tux
q 92215 0 --rw-rw-rw- tuxdcs1 tux
q 92216 0 --rw-rw-rw- tuxdcs1 tux
q 92217 0 --rw-rw-rw- tuxdcs1 tux
q 92218 0 --rw-rw-rw- tuxdcs1 tux
q 81979 0 -Rrw-rw-rw- tuxdcs1 tux
q 81980 0 --rw-rw-rw- tuxdcs1 tux
q 81981 0 --rw-rw-rw- tuxdcs1 tux
q 81982 0 --rw-rw-rw- tuxdcs1 tux
q 81983 0 --rw-rw-rw- tuxdcs1 tux
q 81984 0 --rw-rw-rw- tuxdcs1 tux
q 81985 0 --rw-rw-rw- tuxdcs1 tux
q 81986 0 -Rrw-rw-rw- tuxdcs1 tux
q 81987 0 --rw-rw-rw- tuxdcs1 tux
q 81988 0 --rw-rw-rw- tuxdcs1 tux
q 81989 0 --rw-rw-rw- tuxdcs1 tux
q 81990 0 --rw-rw-rw- tuxdcs1 tux
q 81991 0 --rw-rw-rw- tuxdcs1 tux
q 81992 0 --rw-rw-rw- tuxdcs1 tux
q 81993 0 -Rrw-rw-rw- tuxdcs1 tux
q 81994 0 --rw-rw-rw- tuxdcs1 tux
q 81995 0 --rw-rw-rw- tuxdcs1 tux
q 81996 0 --rw-rw-rw- tuxdcs1 tux
q 81997 0 --rw-rw-rw- tuxdcs1 tux
q 81998 0 --rw-rw-rw- tuxdcs1 tux
q 81999 0 --rw-rw-rw- tuxdcs1 tux
q 82000 0 -Rrw-rw-rw- tuxdcs1 tux
q 82001 0 --rw-rw-rw- tuxdcs1 tux
q 82002 0 --rw-rw-rw- tuxdcs1 tux
q 82003 0 --rw-rw-rw- tuxdcs1 tux
q 82004 0 --rw-rw-rw- tuxdcs1 tux
q 82005 0 --rw-rw-rw- tuxdcs1 tux
q 82006 0 --rw-rw-rw- tuxdcs1 tux
q 82007 0 -Rrw-rw-rw- tuxdcs1 tux
q 82008 0 --rw-rw-rw- tuxdcs1 tux
q 82009 0 --rw-rw-rw- tuxdcs1 tux
q 82010 0 --rw-rw-rw- tuxdcs1 tux
q 82011 0 --rw-rw-rw- tuxdcs1 tux
q 82012 0 --rw-rw-rw- tuxdcs1 tux
q 82013 0 --rw-rw-rw- tuxdcs1 tux
q 82014 0 -Rrw-rw-rw- tuxdcs1 tux
q 82015 0 --rw-rw-rw- tuxdcs1 tux
q 82016 0 --rw-rw-rw- tuxdcs1 tux
q 82017 0 --rw-rw-rw- tuxdcs1 tux
q 82018 0 --rw-rw-rw- tuxdcs1 tux
q 82019 0 --rw-rw-rw- tuxdcs1 tux
q 82020 0 --rw-rw-rw- tuxdcs1 tux
q 855141 0 -Rrw-rw-rw- tuxdcs1 tux
q 138342 0 -Rrw-rw-rw- tuxdcs1 tux
q 6999143 0 -Rrw-rw-rw- tuxdcs1 tux
q 8458344 0 -Rrw-rw-rw- tuxdcs1 tux
q 860265 0 -Rrw-rw-rw- tuxdcs1 tux
q 240746 0 -Rrw-rw-rw- tuxdcs1 tux
q 20690027 0 -Rrw-rw-rw- tuxdcs1 tux
q 7598188 0 -Rrw-rw-rw- tuxdcs1 tux
q 1300589 0 -Rrw-rw-rw- tuxdcs1 tux
q 276590 0 --rw-rw-rw- tuxdcs1 tux
q 56431 0 -Rrw-rw-rw- tuxdcs1 tux
q 56432 0 --rw-rw-rw- tuxdcs1 tux
q 56433 0 -Rrw-rw-rw- tuxdcs1 tux
q 56434 0 -Rrw-rw-rw- tuxdcs1 tux
q 56435 0 --rw-rw-rw- tuxdcs1 tux
q 71796 0 -Rrw-rw-rw- tuxdcs1 tux
q 71797 0 --rw-rw-rw- tuxdcs1 tux
q 66678 0 -Rrw-rw-rw- tuxdcs1 tux
q 66679 0 --rw-rw-rw- tuxdcs1 tux
q 61560 0 -Rrw-rw-rw- tuxdcs1 tux
q 61561 0 -Rrw-rw-rw- tuxdcs1 tux
q 61562 0 -Rrw-rw-rw- tuxdcs1 tux
q 61563 0 -Rrw-rw-rw- tuxdcs1 tux
q 56444 0 -Rrw-rw-rw- tuxdcs1 tux
q 66685 0 -Rrw-rw-rw- tuxdcs1 tux
q 56446 0 -Rrw-rw-rw- tuxdcs1 tux
q 61567 0 -Rrw-rw-rw- tuxdcs1 tux
q 71808 0 -Rrw-rw-rw- tuxdcs1 tux
q 66689 0 -Rrw-rw-rw- tuxdcs1 tux
q 56450 0 -Rrw-rw-rw- tuxdcs1 tux
q 66691 0 -Rrw-rw-rw- tuxdcs1 tux
q 66692 0 -Rrw-rw-rw- tuxdcs1 tux
q 82053 0 -Rrw-rw-rw- tuxdcs1 tux
q 76934 0 --rw-rw-rw- tuxdcs1 tux
q 11448455 0 -Rrw-rw-rw- tuxdcs1 tux
q 61576 0 --rw-rw-rw- tuxdcs1 tux
q 102537 0 -Rrw-rw-rw- tuxdcs1 tux
q 97418 0 -Rrw-rw-rw- tuxdcs1 tux
q 66699 0 -Rrw-rw-rw- tuxdcs1 tux
q 61580 0 --rw-rw-rw- tuxdcs1 tux
q 56461 0 -Rrw-rw-rw- tuxdcs1 tux
q 56462 0 --rw-rw-rw- tuxdcs1 tux
q 56463 0 -Rrw-rw-rw- tuxdcs1 tux
q 56464 0 --rw-rw-rw- tuxdcs1 tux
q 56465 0 -Rrw-rw-rw- tuxdcs1 tux
q 56466 0 --rw-rw-rw- tuxdcs1 tux
q 56467 0 -Rrw-rw-rw- tuxdcs1 tux
q 56468 0 --rw-rw-rw- tuxdcs1 tux
q 56469 0 -Rrw-rw-rw- tuxdcs1 tux
q 82070 0 --rw-rw-rw- tuxdcs1 tux
q 76951 0 -Rrw-rw-rw- tuxdcs1 tux
q 56472 0 -Rrw-rw-rw- tuxdcs1 tux
q 56473 0 --rw-rw-rw- tuxdcs1 tux
q 56474 0 -Rrw-rw-rw- tuxdcs1 tux
q 56475 0 --rw-rw-rw- tuxdcs1 tux
q 220316 0 -Rrw-rw-rw- tuxdcs1 tux
q 256157 0 --rw-rw-rw- tuxdcs1 tux
q 215198 0 -Rrw-rw-rw- tuxdcs1 tux
q 128159 0 --rw-rw-rw- tuxdcs1 tux
q 56480 0 -Rrw-rw-rw- tuxdcs1 tux
q 56481 0 -Rrw-rw-rw- tuxdcs1 tux
q 56482 0 -Rrw-rw-rw- tuxdcs1 tux
q 56483 0 -Rrw-rw-rw- tuxdcs1 tux
q 56484 0 --rw-rw-rw- tuxdcs1 tux
q 56485 0 --rw-rw-rw- tuxdcs1 tux
q 61606 0 --rw-rw-rw- tuxdcs1 tux
q 61607 0 -Rrw-rw-rw- tuxdcs1 tux
q 56488 0 --rw-rw-rw- tuxdcs1 tux
q 56489 0 -Rrw-rw-rw- tuxdcs1 tux
q 56490 0 --rw-rw-rw- tuxdcs1 tux
q 56491 0 -Rrw-rw-rw- tuxdcs1 tux
q 56492 0 --rw-rw-rw- tuxdcs1 tux
q 56493 0 -Rrw-rw-rw- tuxdcs1 tux
q 56494 0 --rw-rw-rw- tuxdcs1 tux
q 56495 0 -Rrw-rw-rw- tuxdcs1 tux
q 56496 0 -Rrw-rw-rw- tuxdcs1 tux
q 82097 0 -Rrw-rw-rw- tuxdcs1 tux
q 56498 0 -Rrw-rw-rw- tuxdcs1 tux
q 189619 0 -Rrw-rw-rw- tuxdcs1 tux
q 87220 0 --rw-rw-rw- tuxdcs1 tux
q 56501 0 -Rrw-rw-rw- tuxdcs1 tux
q 56502 0 -Rrw-rw-rw- tuxdcs1 tux
q 56503 0 --rw-rw-rw- tuxdcs1 tux
q 66744 0 --rw-rw-rw- tuxdcs1 tux
q 61625 0 --rw-rw-rw- tuxdcs1 tux
q 61626 0 --rw-rw-rw- tuxdcs1 tux
q 56507 0 -Rrw-rw-rw- tuxdcs1 tux
q 56508 0 --rw-rw-rw- tuxdcs1 tux
q 56509 0 -Rrw-rw-rw- tuxdcs1 tux
q 76990 0 -Rrw-rw-rw- tuxdcs1 tux
q 71871 0 -Rrw-rw-rw- tuxdcs1 tux
q 92352 0 -Rrw-rw-rw- tuxdcs1 tux
q 66753 0 -Rrw-rw-rw- tuxdcs1 tux
q 76994 0 -Rrw-rw-rw- tuxdcs1 tux
q 61635 0 -Rrw-rw-rw- tuxdcs1 tux
q 6082756 0 -Rrw-rw-rw- tuxdcs1 tux
q 4746437 0 -Rrw-rw-rw- tuxdcs1 tux
q 204998 0 -Rrw-rw-rw- tuxdcs1 tux
q 76999 0 -Rrw-rw-rw- tuxdcs1 tux
q 123080 0 -Rrw-rw-rw- tuxdcs1 tux
q 56521 0 -Rrw-rw-rw- tuxdcs1 tux
q 56522 0 -Rrw-rw-rw- tuxdcs1 tux
q 56523 0 -Rrw-rw-rw- tuxdcs1 tux
q 138444 0 -Rrw-rw-rw- tuxdcs1 tux
q 66765 0 -Rrw-rw-rw- tuxdcs1 tux
q 51406 0 -Rrw-rw-rw- tuxdcs1 tux
q 51407 0 -Rrw-rw-rw- tuxdcs1 tux
q 51408 0 -Rrw-rw-rw- tuxdcs1 tux
q 51409 0 -Rrw-rw-rw- tuxdcs1 tux
q 51410 0 -Rrw-rw-rw- tuxdcs1 tux
q 51411 0 -Rrw-rw-rw- tuxdcs1 tux
q 51412 0 -Rrw-rw-rw- tuxdcs1 tux
q 51413 0 -Rrw-rw-rw- tuxdcs1 tux
q 51414 0 -Rrw-rw-rw- tuxdcs1 tux
q 61655 0 -Rrw-rw-rw- tuxdcs1 tux
q 51416 0 -Rrw-rw-rw- tuxdcs1 tux
q 33520857 0 -Rrw-rw-rw- tuxdcs1 tux
q 51418 0 -Rrw-rw-rw- tuxdcs1 tux
q 51419 0 -Rrw-rw-rw- tuxdcs1 tux
q 107740 0 -Rrw-rw-rw- tuxdcs1 tux
q 51421 0 -Rrw-rw-rw- tuxdcs1 tux
q 51422 0 -Rrw-rw-rw- tuxdcs1 tux
q 51423 0 -Rrw-rw-rw- tuxdcs1 tux
q 51424 0 -Rrw-rw-rw- tuxdcs1 tux
q 522465 0 -Rrw-rw-rw- tuxdcs1 tux
q 61666 0 -Rrw-rw-rw- tuxdcs1 tux
q 706787 0 -Rrw-rw-rw- tuxdcs1 tux
q 51428 0 -Rrw-rw-rw- tuxdcs1 tux
q 51429 0 -Rrw-rw-rw- tuxdcs1 tux
q 51430 0 -Rrw-rw-rw- tuxdcs1 tux
q 61671 0 -Rrw-rw-rw- tuxdcs1 tux
q 61672 0 -Rrw-rw-rw- tuxdcs1 tux
q 61673 0 --rw-rw-rw- tuxdcs1 tux
q 51434 0 -Rrw-rw-rw- tuxdcs1 tux
q 2406635 0 --rw-rw-rw- tuxdcs1 tux
q 51436 0 -Rrw-rw-rw- tuxdcs1 tux
q 77037 0 --rw-rw-rw- tuxdcs1 tux
q 51438 0 -Rrw-rw-rw- tuxdcs1 tux
q 82159 0 -Rrw-rw-rw- tuxdcs1 tux
q 56560 0 -Rrw-rw-rw- tuxdcs1 tux
q 107761 0 -Rrw-rw-rw- tuxdcs1 tux
q 66802 0 -Rrw-rw-rw- tuxdcs1 tux
q 56563 0 -Rrw-rw-rw- tuxdcs1 tux
q 97524 0 -Rrw-rw-rw- tuxdcs1 tux
q 77045 0 --rw-rw-rw- tuxdcs1 tux
q 25564421 0 --rw-rw-rw- tuxdcs1 tux
Shared Memory:
m 0 0 rw----- root root
m 4097 0xabb02 --rw-rw-rw- tuxdcs1 tux
m 4098 0 --rw-rw-rw- tuxdcs1 tux
m 4099 0 --rw-rw-rw- tuxdcs1 tux
m 4100 0 --rw-rw-rw- tuxdcs1 tux
m 8709 0 rw----- tuxdcs1 tux
m 8710 0 rw----- tuxdcs1 tux
m 8711 0 rw----- tuxdcs1 tux
m 8712 0 rw----- tuxdcs1 tux
m 8713 0x8029 rw----- tuxdcs1 tux
m 6154 0 rw----- tuxdcs1 tux
m 11 0x400c4824 --rw-rw-rw- mqm mqm
Semaphores:
s 524288 0xabb02 --ra-ra-ra- tuxdcs1 tux
s 1114113 0 --ra-ra-ra- tuxdcs1 tux
s 524290 0 --ra-ra-ra- tuxdcs1 tux
s 524291 0 --ra-ra-ra- tuxdcs1 tux
s 2293764 0 --ra-ra-ra- tuxdcs1 tux
s 1638405 0 --ra-ra-ra- tuxdcs1 tux
s 6 0xc4824 --ra-ra-ra- mqm mqm
Todd Little-Oracle
Hi Bill,

I'm not sure what platform you are using, but you'll likely need to add the -a or -l switch to the ipcs command. We need to see how full the queues are and the system you are on apparently doesn't provide that information with just the ipcs command. So please check the man page on your system for the ipcs command and use the appropriate switch to see queue utilization. It should show you the number of bytes and messages in each queue, and the maximum number of bytes and messages allowed in each queue. Do you have a Unix system administrator who could help you with this?

Regards,
Todd Little
Oracle Tuxedo Chief Architect
652398
Thanks Todd.

My OS is Solaris. I use ipcs -b to see that the QBYTES(maximum bytes in each queue) is 655360. Because the error of occurring file transfer doesn't happen at regular time, I will check it when it appears. Thanks again.
1 - 16
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Aug 7 2007
Added on Jun 17 2007
11 comments
1,441 views