Search found 3 matches

by pogib
Mon 30 May 2022 11:11
Forum: dotConnect for Oracle
Topic: RAC notification service connection timeout causes very slow connection opening
Replies: 1
Views: 11218

RAC notification service connection timeout causes very slow connection opening

I've noticed an issue which might be a bug or at least a possibility for improvement.
This can be reproduced with dotconnect for Oracle versions 9.14 and 9.16.

If you are connecting to an Oracle RAC and using Oracle Client with 12 or higher, when you create the connection devart tries to subscribe to the ONS notification synchronously, so if that service port is blocked (default is 6200), each connection initialization takes at least 10 seconds (until the subscription times out).

A workaround might be that you set the Min Pool Size to a number greater than 0.

For us it took quite some time to figure out what happens in the background, because the Oracle Client traces do not include useful information about this subscription timeout.

It looks like that the managed and unmanaged Oracle providers are doing this subscriptions asnychronously, so in that case the timeout appears in the console (in case of higher trace level) after you could already use their new connections.
I would assume that this might be also beneficial for dotconnect (of course in that case it is even more complicated to realize that there is a blocked port, but initializing a connection in 10s is really slow).

Probably Oracle should be writing some warning logs (I guess devart doesn't have the facility to notify the developer about this)

A bit unexpected that the following message was written to Console.Out - I guess by the Oracle unmanaged client:
ONS Error: ONS ERROR=26 subscriber 1 create failed: timedout (oracle client version 21)

or

subscriber 425700424 create failed (oracle client version 12)
by pogib
Mon 15 Jul 2013 12:47
Forum: dotConnect for Oracle
Topic: One query - many TCP packets
Replies: 3
Views: 1441

Re: One query - many TCP packets

Hi Shalex,

Thx for the reply!
Does it fetch all the records? It may display only first, for example, 100 records. The rest will be fetched step by step when you scroll the grid.
Additionally, SQL Developer has less overhead expenses comparing to retrieving data via any ORM.
I run the query with F5 in Sql Developer - in this case it fetches all results.
Please try using OCI connection (via Oracle client). Is there a significant difference between Direct Mode and OCI in your environment?
I've just tried - no significant differences. Execution of that query (5000 rows) is still around 5 minutes - in SQL Developer less than 10 seconds. Network analyzer shows the same activity (appr. 20 thousand TCP packets).
Usage of any ORM usually leads to performance losses. In case of Entity Framework, there are a number of ways for optimization: http://msdn.microsoft.com/en-us/library/cc853327.aspx.
I understand that difference, but 5 minutes vs. 10 seconds seems too much for me... Tracking is switched off and the query joins only two tables with 5-15 columns without any big binary or string data.

So I'm still curious: Is this number of TCP packets normal? Or any other hints?
by pogib
Fri 12 Jul 2013 09:56
Forum: dotConnect for Oracle
Topic: One query - many TCP packets
Replies: 3
Views: 1441

One query - many TCP packets

Hi,

I'm using EF4 with dotConnect for Oracle (7.7.267.0) and I experience low performance with queries resulting many objects.

If I debug my code the ToArray call on my query executes longer than 5 minutes when the result is around 5000 objects.
I've checked the db activity with dbMonitor and it shows that the query prepare and execute times are less than 1 sec (although this duration times don't look realistic).
When I run the same query in SQL developer (also from remote computer) it also execute in less than 10 seconds.

I've checked the network activity with a network analyzer and it shown that there are 2-3 times more TCP packets during this query execution than the number of resulting rows.

For me it looks like the cause of the low performance is the big network overhead of around 15000 network packets.

Is this normal? Can I change this behaviour somehow?
Any ideas in which direction should I proceed with the investigation?

Thx in advance!