Troubleshooting Oracle Client Connections

A couple of the most common problems you might encounter when configuring the Oracle client include opening the default port in the Windows Firewall and using the correct Oracle login information. Here’s how you can work around each of these issues.

Open Port 1521 on the Windows Firewall. The Oracle client can’t connect when the Oracle listen port isn’t available—particularly on new Oracle server installations. To create an exception in the Windows Firewall, go to the Oracle server and open up the Control Panel, select Windows Firewall, and select the Allow a program through the Windows Firewall link. Doing so will display the Windows Firewall Settings dialog box. Next click Add Port to open the Add Port dialog box that you can see in Figure A.

Now, enter a descriptive name for the port. In Figure A you can see that I’ve used the name Oracle. Enter 1521 for the port number, make sure TCP/IP is the protocol that’s selected, and then click OK. You should need to do this only on the Windows server that’s running Oracle. On the client, the Windows Firewall is dynamically opened by outgoing requests.

Verify your login information. To connect to the Oracle server you need to provide a valid login to the Oracle system. For testing you might try to connect using the Oracle sample Scott/tiger user ID and password. Note that recent Oracle releases are shipped with this login locked. To unlock it, open a SQLPlus connection to the Oracle server and enter the following PL/SQL command

From the Blogs

The quest for the Golden Record to achieve a single, accurate and complete version of a customer record is worth the pursuit to attain survivorship. Record matching and consolidation are only the beginning. Melissa Data takes a new approach. Learn how to apply intelligent rules based on reference data to make smarter and better decisions for data cleansing....More

On SQL Servers where Availability Groups (or Mirroring) isn’t in play, I typically recommend keeping a combination of on-box backups along with copying said backups off-box as well. Obviously, keeping databases AND backups on the SAME server is the metaphorical equivalent of putting all of your eggs in one basket – and therefore something you should avoid like the plague....More

One of the biggest strengths of AlwaysOn Availability Groups is that they allow DBAs to address both high availability and disaster recovery concerns from a single set of tooling or interfaces. But, this doesn’t mean that you won’t still need backups....More