Re: Database links

K Stahl <BlueSax_at_Unforgettable.com> writes:

> K Stahl wrote:
> > It has been a while since I've needed to work with a database link and
> > apparently there is some detail that I'm missing.
> > I've created a database link like this:
> > create public database link xyz_link
> > connect to myid identified by mypass using 'myserv'
> > myserv is a database alias in the tnsnames.ora on the server where I've
> > created the link:
> > Once it was created I could do like this:
> > connect myid/mypwd_at_myserv
> > and got a connection, so that told me that the tnsnames.ora entry was
> > correct and that the listener is running on the remote machine. But when I
> > tried this:
> > select * from mytable_at_xyz_link
> > I received the message:
> > ERROR at line 1:
> > ORA-12666: Message 12666 not found; product=RDBMS; facility=ORA
> > I tried using oerr to look up ora-12666, but there was no message. I then
> > tried TNS as a facility and got this:
> >
> > But I'm not sure whether this is relevant since the original error was
> > reported as ORA-12666 not TNS-12666.
>
> I don't understand what I did, but suddenly I seem to have gotten this
> working. The problem is I took a scientific-wild-assed-guess at something
> and now the blasted thing is working.
>
> I went to the sqlnet.ora file on the machine where the database exists in
> which I have created the database link. It had a line in it which read:
>
> sqlnet.authentication_services=(beq,none)
>
> I changed this to read:
>
> sqlnet.authentication_services=(tcp,none)
>
> and then went back into sqlnet and suddenly the link started working. What
> happend? What did this change? Why does it suddently work? I know what tcp
> means, of course, but what does the 'none' mean in this parameter?
"None" means that no network authentication (meaning the Advanced Security Option) is to be done.

This parameter is used to indicate the list of services that you have available for use in authenticating yourself to the other process. To get around an old bug, it used to be necessary to specify "beq, none" so connect internal would work with requiring a password. This bug has been fixed, BTW.

Your fix worked because "tcp" is not a valid authentication service and "none" means to use nothing. The end result was that ASO ignored the setting. When you attempted the DB link, no ASO authentication was done and everything worked. The same result can be obtained by commenting out or deleting the parameter setting.

However, ASO should not have used bequeath in the first place to attempt to authenticate the database link. That's why you saw the ORA-12666. I would still report it as a bug.

--

                                        Rick
                                        Rick Wessman
                                        Security and Directory Technologies
                                        Server Technologies
                                        Oracle Corporation
                                        rwessman_at_us.oracle.com

       The statements and opinions expressed here are my own and do not
             necessarily represent those of  Oracle Corporation.