Home » RDBMS Server » Networking and Gateways » Interoperating different releases of database and HS gateway (DB 12.2.x, 18.x)
Interoperating different releases of database and HS gateway [message #672896] Wed, 31 October 2018 12:11 Go to next message
John Watson
Messages: 8960
Registered: January 2010
Location: Global Village
Senior Member
I've configured the HS gateway before, but only on a small scale: Installing it into the same Oracle Home as the database, and configuring a connection to one remote non-Oracle database. However, a possibility has come up of needing to install gateways between several Oracle databases running off different homes and possibly of different releases with connections to several MySQL and SQL Server databases.
Is it feasible to install the gateways on one machine in one home, configuring all the ODBC connections there and running one listener to route all the connections? In effect, using the HS gateway machine as a hub that will be the target of several database links from several databases (possibly of different versions) and send them on to the appropriate third party database?

Thank you for any insight.

Report message to a moderator

Re: Interoperating different releases of database and HS gateway [message #672898 is a reply to message #672896] Wed, 31 October 2018 13:04 Go to previous messageGo to next message
EdStevens
Messages: 1376
Registered: September 2013
Senior Member
Not only is it feasible to install the gateway (singular "gateway", not pural "gateways") on one machine in home (gateway-only) home, that is the preferred configuration. I have multiple oracle databases, each with multiple links to different MSSQL databases residing on multiple host servers. I have a single gateway installation on one Windows server. It is not "in effect" using the gateway machine as a hub, it is using the gateway machine as a hub. The oracle side of the connection really doesn't know anything at all about the target database, just it's name. The request is sent to the listener with no knowledge at all about what happens after the listener gets it. And the listener itself really doesn't know or care either. It simply spawns a process that communicates with the ODBC driver, and THAT can then communicate with any db anywhere on the network.

Take a look at this article I wrote: https://edstevensdba.wordpress.com/2018/09/19/the-oracle-transparent-gateway/

Report message to a moderator

Re: Interoperating different releases of database and HS gateway [message #672907 is a reply to message #672898] Wed, 31 October 2018 15:50 Go to previous messageGo to next message
JPBoileau
Messages: 88
Registered: September 2017
Member
Precisely as Ed said. It's the right way to go.

The only thing you may want to watch out for is, if you're using this set-up on a WAN vs a LAN - WAN might incur higher operating costs, or saturate the WAN, all depends on your network configuration. Additionally, keep in mind that you may saturate the listener when having a single Gateway server. It's not common, but with very heavy use, it's a possibility.

JP

Report message to a moderator

Re: Interoperating different releases of database and HS gateway [message #672911 is a reply to message #672907] Wed, 31 October 2018 17:37 Go to previous messageGo to next message
EdStevens
Messages: 1376
Registered: September 2013
Senior Member
JPBoileau wrote on Wed, 31 October 2018 15:50
Precisely as Ed said. It's the right way to go.

Additionally, keep in mind that you may saturate the listener when having a single Gateway server. It's not common, but with very heavy use, it's a possibility.

JP
Maybe I've just never been in a really high-volume system, but I can't imagine the listener getting 'saturated'. Contrary to all-too-common misunderstanding, the listener is not involved in on-going communication between the client and the database. All it does is receive the connection request and spawn another server process, then tells the client what port to use to communicate with that process. Once a client is connected to a database, the listener can even be shut down, and existing connections will never know.

Report message to a moderator

Re: Interoperating different releases of database and HS gateway [message #672916 is a reply to message #672907] Wed, 31 October 2018 19:00 Go to previous messageGo to next message
BlackSwan
Messages: 26766
Registered: January 2009
Location: SoCal
Senior Member
JPBoileau wrote on Wed, 31 October 2018 13:50
Precisely as Ed said. It's the right way to go.

The only thing you may want to watch out for is, if you're using this set-up on a WAN vs a LAN - WAN might incur higher operating costs, or saturate the WAN, all depends on your network configuration. Additionally, keep in mind that you may saturate the listener when having a single Gateway server. It's not common, but with very heavy use, it's a possibility.

JP

Can you post a reproducible test case that conclusively shows any Oracle listener becoming "saturatued"?
Explain how you can even measure that a saturated listener exists.
The listener is a dedicated software process which runs at CPU speeds.
Since any & every Network Interface Card (NIC) is a SERIAL device, the listener can't services requests any faster than they arrive via the NIC.
I contend you are echoing an unsubstantiated Urban Legend.

Report message to a moderator

Re: Interoperating different releases of database and HS gateway [message #672983 is a reply to message #672911] Thu, 01 November 2018 09:25 Go to previous messageGo to next message
JPBoileau
Messages: 88
Registered: September 2017
Member
EdStevens wrote on Wed, 31 October 2018 17:37

Maybe I've just never been in a really high-volume system, but I can't imagine the listener getting 'saturated'. Contrary to all-too-common misunderstanding, the listener is not involved in on-going communication between the client and the database. All it does is receive the connection request and spawn another server process, then tells the client what port to use to communicate with that process. Once a client is connected to a database, the listener can even be shut down, and existing connections will never know.
I tried what you said above (shutdown listener after the connection is established), and I'm getting odd results. The listener sometimes refuses to stop or start if a connection to a gateway is still active. The scenario:

start gateway listener
start sqlplus session
select * from sometable@gateway (no problem)
stop gateway listener (no problem)
select * from sometable@gateway (no problem)

start gateway listener <-- this is where things hang.

select * from sometable@gateway (still no problem)
exit sqlplus session <-- this is when the listener restarts.

That being said, having a number of connections to SQL-Server from numerous databases is somewhat of a funnel.

One Oracle DB -> One Gateway -> One SQL-Server (repeat X times)

is less taxing than

X Oracle DB's -> One Gateway -> X SQL-Servers.

JP

Report message to a moderator

Re: Interoperating different releases of database and HS gateway [message #672985 is a reply to message #672896] Thu, 01 November 2018 10:17 Go to previous message
John Watson
Messages: 8960
Registered: January 2010
Location: Global Village
Senior Member
Thank you for all the advice. I'll plan on one installation of the gateway on its own machine, and if I use the latest 18.x version I would hope that it will be able to talk to all the Oracle and third party databases I am likely to need.

Now back to the bloody October RU. Hit a bizarre problem where some SQLs that were fine before now fail after applying it. I have TAR open that ain't going nowhere Sad

Report message to a moderator

Previous Topic: Unsuccessful of establishment of database link from oracle to sql server
Next Topic: ora-12224: tns:no hay ningun receptor
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Tue Dec 03 12:00:15 CST 2024
.:: Forum Home :: Blogger Home :: Wiki Home :: Contact :: Privacy ::.