Opening (?) Port 1521 for Oracle Listener

[Robert Manning_2]

Hi,

I have an AlphaServer 4100 (OVMS 6.2-1H3) on which we host two Oracle 7.1.5 applications.

Following a reboot at the weekend, the listener for one of the apps didn't start, and it appears to me as if Port 1521 is not available. The other application uses Port 1522 for its listener, and that appears to be okay.

The attached file shows the results of the commands

UCX SHOW DEV/PORT=1521/FUL and
UCX SHOW DEV/PORT=1522/FUL

as well as the relevant LISTENER.ORA and TNSNAMES.ORA files.

The SID of the affected database is IMS.

If anyone knows how to get this port configured, I'd really appreciate it...

Thanks,

Bob

[Wim Van den Wyngaert · Accepted solution]

Was Oracle started before tcp was completely started ? No messages in log files and operator log file ?

Wim

[Marc Van den Broeck]

Bob,

can you please issue the command: lsnrctl status

In your listener file I see more instances than IMS, e.g. TANDT. Does this listener serve more than one instance?

Pls look in you listener.log file for any error messages.

Can you also post (as an attachment) the listener.ora and the tnsnames.ora file from the working listener?

Rgds
Marc

[Robert Manning_2]

Thanks for the replies...

Wim,

There's nothing in logs to indicate anything unusual, although the Listener.log shows (strangely) activity on a UCX print queue.

Marc,

There were formerly two databases activated on this disk, TANDT and IMS. TANDT closed and was migrated two years ago, and IMS remains in use.

The other existing instance, Postdraft, is configured and run independently of IMS - its Listener and TNSNames files are attached, as well as output from the lsnrctl command and Listener.log of IMS.

Rgds,

Bob

[Marc Van den Broeck]

Bob,

I see that PDRAFT_TCP (in tnsnames.ora you posted the second time) also refers to port 1521.
Can you therefor change from 1521 to 1523 in the listener.ora and the tnsnames.ora you posted first.
Then we are sure there will be no interferance with any other port.

Another question: why do you use STOP_LISTENER = YES in your listener.ora file?

Can you also check if the file DISK$AXPVMSSYS:[ORACLE.V7016.NETWORK.ADMIN]SRV_IMS.COM
still exists?

Rgds
Marc

[Robert Manning_2]

Hi,

Okay, it looks like we have a solution.

Following Wim's suggestion, and having seen the references to UCX_LPD in the LISTENER.LOG, I examined the file ownership and security of LISTENER.LOG and compared it with the security of the same file on the old system disk.

I found that, where the old file had been owned by the Oracle DBA account, the new one was owned by the UCX_LPD account, used to initialize and process print queues.

The protection on the file was such that the Oracle DBA account had no access to it, thus the listener process would be unable to write to the log.

By stopping and starting the Oracle application we were able to create a new LISTENER.LOG, and this time were successful in having the listener write to it. However we also had to create a new LISTENER.TRC file, as the pre-existing one was also owned by UCX_LPD.

Once both of thses files' ownerships had been fixed, the application ran normally.

Sorry about the lateness in posting this - I tried yesterday, but the forum page kept crashing and wouldn't reload...

Anyhow, thanks to everyone for your assistance and suggestions.

Cheers,

Bob

[Robert Manning_2]

See the 10-point suggestion - not as complex as we thought...

I meant to add in my update that as part of the solution we plan to add a wait staement to allow all layered products to properly start before we begin the application startups. Hopefully that'll prevent this from happening again...

Bob

[Wim Van den Wyngaert]

For future problems : enable security auditing and check it in case of problems (or do as we do : feed all security alarms to a monitoring tool).

Wim

[Robert Manning_2]

Sounds like a plan - will do...

[Wim Van den Wyngaert]

Do you have any idea how the lpd log got in the place of the listener log ?

Wim

[Robert Manning_2]

Wim,

No - and it was just that UCX_LPD took ownership of the listener log, not that it replaced it.

But I took your suggestion about whether Oracle had started before the UCX startup had finished and went from there and compared the ownerships of the listener files, and that's where I found the problem to be. I'll have a look through the audit logs and see if anything was recorded...

Bob