I have a third party .Net web application (Sitecore) which connects to an Oracle database on a server in my DMZ (separated from my LAN with a firewall). Connectivity between the application and the database is slow. It does not fail, the process (called Publishing) just takes a long time in comparison to the same process occurring between the application (Sitecore) and an Oracle database inside our LAN (a few milliseconds versus 20 minutes). Interestingly I get the same behaviour when I use Toad for Oracle to query the database in the DMZ versus querying a copy of the database inside my LAN.
I have replicated the setup inside our LAN and the problem goes away. If I use an MSSQL database the problem also goes away. If we don’t use Sitecore or Toad and instead run simple queries in Oracle’s sqlPlus application the problem doesn’t occur.
This indicates to me that the problem is specific to applications that use the Oracle Data Provider for .Net, and that are running inside our LAN and are trying to query an Oracle database outside our LAN.
OS is Windows 2008R2 64bit (Oracle DB server), Windows 2008 32bit (Sitecore), Win7 64bit (Toad and SqlPlus clients). Not sure what the firewall is but I think it is on some kind of a virtual switch/router thing (yeah, I’m not a network guy, how’d you guess?). Oracle is 10g. Clients are using Oracle.DataAccess 2.102.4.0 or 2.102.5.0 for 64 and 32 bit. Toad is 10.6. Sitecore is 6.2.0 rev 091012
I have run various monitors like Wireshark, Procmon, and the Win7 Resource Monitor but I’m not really sure what I’m looking for. All I can see is that there are large gaps of time between sends and receives but I can’t determine where these gaps are being created. To me this is all really spooky. In my experience network connectivity either works or it doesn’t, and if some traffic is slow, then all traffic is slow.
Any ideas as to what might cause this behaviour? Specifically, what network/router/firewall settings might cause connectivity (over TNS & TCP protocols according to Wireshark) to go slowly but not fail completely, for a particular implementation of an Oracle data provider?
Confused and mildly spooked,
James.
So the answer is the firewall we are using is causing the issue. It is trying to do deep packet inspection on the Oracle traffic (which has been processed by the ODP.net provider), which slows the network traffic down considerably, without actually stopping it. A firewall that works with a different method should fix the problem. The guys are Quest (Toad Support) were very good and came up with the answer. Oracle support were less helpful. Quest have some documentation on the problem but it is behind there support portal.