Home » RDBMS Server » Server Administration » ORACLE DCN TCP Ports (11.2.0.4)
icon5.gif  ORACLE DCN TCP Ports [message #661490] Tue, 21 March 2017 05:26 Go to next message
gareththomas
Messages: 1
Registered: March 2017
Junior Member
Hi All.

I was wondering if someone can help me with a problem with oracle DCN - database change notification. I am not a DBA and our DBA's do not seem to have the knowledge. We have run a series of network tests with DCN on a new system - checking netstat -na and tcpdump on the machines to see exactly how the connections are opened. We see this

1. User logs into database on connection port - EG 1521. Connection is on 57100 local port - connectivity initiated Application -> Database
2. User subscribes to DCN for 2 tables
2.1 Subscription added to the database and port 47632 assigned (default DCN port is 47632, but we have seen up to 47638, depending on available ports)
2.2 No additional tcp connections are opened for the notifications
3. When table is updated and notification sent
3.1 Oracle Database initiates the tcp connection with the registered IP;PORT - connectivity Database -> Application
3.2 notification sent by Database and received by application
3.3 we now see new tcp connections on 47632 port

The issue we have is that because the database is hosted offsite our security rules prohibit connections being initiated from database to application.

Is there a way where we can get the Application to open the connection on subscription?

I know the application can specify the port but I cannot find anything to get the connection to be opened by the application before any notifications are sent.

Thanks
Gareth

Report message to a moderator

Re: ORACLE DCN TCP Ports [message #661549 is a reply to message #661490] Thu, 23 March 2017 11:00 Go to previous message
Caffeine+
Messages: 14
Registered: February 2017
Junior Member
Based on your description of events I assume that you are using JDBC style registrations. That style uses application-managed listener endpoints which is in conflict with your policies. PL/SQL style registrations are closer to what you need. Using a PL/SQL style registration will give you control over the interception and processing of the change notification message.

The DB will capture and stage the change like it does now but, instead of calling out to the app, it will call a stored procedure that you code. That new procedure could persist the message into a staging area reserved for your application. The application would then log into the DB and consume the notifications from that staging area. You can use Advanced Queues to persist the message or build your own solution using tables.

I can think of other ways to propagate change notifications but it would depend on the details of the restrictions: Security folks paranoid over opening firewalls ports from/to the DB besides 1521; Application team worried about en entry point into their stack; Etc. I can comment further is you provide more details.

HTH

Report message to a moderator

Previous Topic: Move to new Server
Next Topic: Sql Query
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Nov 28 16:47:43 CST 2024
.:: Forum Home :: Blogger Home :: Wiki Home :: Contact :: Privacy ::.