Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Listener doesn't start & points to nonexistent error 1

Status
Not open for further replies.

neuralnode

Technical User
Sep 12, 2007
59
PL

Hi all,

I've been experiencing a strange problem. I need to have two databases running, called ICM1 & ICM2, but only the listener for one of them (ICM2) starts. The other returns the following error:

$ lsnrctl start ICM1

TNS-01151: Missing listener name, ICM1, in LISTENER.ORA
Listener failed to start. See the error message(s) above...


Please mind the listener.ora file is correct, there are no typos etc. - has been checked & compared with other servers thoroughly. All information about both databases is there, syntax is OK (otherwise ICM2 wouldn't have started).

Also, in one of the log files I find:

TNS-01155: Incorrectly specified SID_LIST_LISTENER_ICM1 parameter in LISTENER.ORA
NL-00303: syntax error in NV string


The OS is Solaris 10.

Anyone familiar with this issue?

Thanx in advance.


 
Looks like a malformed entry in listener.ora to me. Are you sure there isn't a 'hidden' typo in there, perhaps a Ctrl-key combination? Have you tried deleting the entry completely and then re-instating it?

I want to be good, is that not enough?
 

Try without the db name:

lsnrctl start
[3eyes]


----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb
 


Thanx for your comments!
The problem is now solved. :)

Actually, KenCunningham, I think you were right. What I did was:
1. cat listener.ora > tempfile
2. rm listener.ora
3. touch listener.ora
4. cat tempfile > listener.ora
6. chmod & chown accordingly the listener.ora file

Both listeners started fine then. I guess some special character secretly found its way into the original file and caused the entire sabotage... :)
Anyway, if that's the case, it would mean that all my cat + touch procedure somehow got rid of the special character(s), which I never knew was possible. I would think that the cat command and stream redirection (">") duplicate EVERY character, special or not. Apparently it is not so.

Anyone knows how these operations handle the "non-printable" characters?

But anyway, consider the case closed & solved. Thanx for your input!

 
Thanks for the star. Like you, I have never seen (or at least noticed, two different things!) this behaviour with cat and >, but I suppose it's not beyond the bounds of possibility. If anyone knows exactly what's going on, I'd be interested to hear.

I want to be good, is that not enough?
 
A method to isolate the behavior of "cat" and ">" would be to generate a text file of all ASCII combinations, then do a "cat" and a ">" to files to see what those invocations produce in the new files.

Here is code that will create all 255 ASCII combinations:
Code:
set serveroutput on format wrap
spool strikeup.txt
Begin
	dbms_output.enable(1000000);
	for i in 1..255 loop
		dbms_output.put_line(i||' = "<'||chr(i)||'>"');
	end loop;
end;
/
set echo on
spool off
prompt
prompt Wrote file "strikeup.txt"
prompt
I would try it myself, but I haven't access to a *nix server presently.

Let us know your findings.

[santa]Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
“Beware of those that seek to protect you from harm or risk. The cost will be your freedoms and your liberty.”
 
Thanks Dave. I ran the above and catted it to a new file via >. A diff between the old and the new reveals no differences between them. This was on a Solaris 8 server, but I would probably expect similar behaviour in other *nixes.

I want to be good, is that not enough?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top