| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Perfomrance Issue When using BEQ protocol
Tnsping only verifies contact with the Listener, which validates the service
name is being resolved properly and Net8 is working correctly. The Bequeath
protocol, however, actually bypasses the Net8 Listener and creates the
server process for you, directly, on the local host.
If you run your batch process on the same host as the database your
assumption regarding the BEQ protocol should be correct. In contrast, using
TCP/IP is going to cause significant SQL*Net latencies from the client and
server processes having to communicate via the network card on the same host
(on a STATSPACK report it would show as SQL*Net message from client &
SQL*Net more data from client).
I would use Oracle tracing or STATSPACK (take snapshot immediately before/after) and run a subset of the actual batch process. This should provide a true test of the relative performance. In particular, I would check for any SQL*Net waits (normally considered idle waits) when using TCP/IP. Regardless, your assumption regarding BEQ protocol should prove to be valid.
Ellis
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Mark W. Farnham
Sent: Thursday, July 08, 2004 5:05 AM
To: oracle-l_at_freelists.org
Subject: RE: Perfomrance Issue When using BEQ protocol
Are you trying to measure the time to connect or the time to suck matching amounts of data through the straw?
I think what you are actually measuring is how long it takes TNSPING to parse your arguments and determine whether a straw that can be used exists.
>From your data it appears you might be better off with TCP if you are chronically connecting, grabbing a very small amount of data, and disconnecting (since the difference in elapsed time of the connection location might be a significant component of the overall task.) To really tell, though, you would need to make a connection, since there is significant overhead in an actual connection beyond verifying that contact is possible. Most of that overhead is probably the same for both methods, since it is largely internal to the database engine.
Now if that really is your job profile, you're probably a candidate for some sort of connection pooling or multiple threading.
If, on the other hand, you're trying to measure which straw has bigger capacity, I think you want a test that draws a lot of data through the straw per connection. To make the test fair for your apparent purpose, you'll want to check that you've done everything you can to advise the Oracle software and the OS that your connection is actually local (short of specifying BEQ) for the TCP connection.
Interesting thought pattern to consider TNSPING in the context of PING to check the data movement capacity. I wonder if Oracle could add data packet shoving with PING-like specifications to TNSPING without creating a security hole or destabilizing an "always works" diagnostic tool. I don't think they had the capacity testing aspect of PING in mind when they named the tool.
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Ahmed Abdel Fattah
Sent: Thursday, July 08, 2004 3:10 AM
To: oracle-l_at_freelists.org
Subject: Perfomrance Issue When using BEQ protocol
Dear All,
I have an environment that has two databases, OFSA & ODS.
Database ODS has a database link to the OFSA database. This
database link uses a connect string called OFSA, which is defined
as follows:
OFSA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = CI-DW-PRD)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME =OFSA)
)
)
There is a batch job that run on the server and that uses the above
database link to retrieve some data from the OFSA database.
Due to performance issues on the above batch job, I suggested to implement
the BEQ protocol in the connect string that is used by the above databse
link
as long as the two databases are on the same server, and because I read some
documents that BEQ is faster than TCP/IP. So, I created another connect
string
as follows:
PROD =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = BEQ)(PROGRAM = oracle)(ARGV0 = oracleOFSA)(ARGS =
'(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=BEQ)))')(ENVS =
'ORACLE_SID=OFSA,ORACLE_HOME=/apps/oracle/product/8.1.7'))
)
The I test connection using the two connect strings, using the tnsping
utility
over a period of time, and I found that using the BEQ connect string is much
slower than using the TCP/IP connect string. Following are sample test
results:
Thanks & Best Regards
Ahmed
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Thu Jul 08 2004 - 08:13:46 CDT
 |
 |