Re: using ifile in the tnsnames.ora file

  • From: "Stefan Knecht" <knecht.stefan@xxxxxxxxx>
  • To: Thomas.Mercadante@xxxxxxxxxxxxxxxxx
  • Date: Fri, 9 Feb 2007 14:47:17 +0100

Well, that depends.

A former employer of mine - an outsourcer - wanted to use a central grid
control repository to manage all the clients' databases. In addition to
that, we wanted to provide isql*plus to some of the team. And to do that
you'd need a central tnsnames.ora - which quickly gets confusing with 100's
of instances in there. Names wasn't an option - due to security constraints.


using IFILE (i.e. one file for each client) allowed quick and efficient
management of the aliases. (If only it would've worked right :)

Stefan

On 2/9/07, Mercadante, Thomas F (LABOR) <Thomas.Mercadante@xxxxxxxxxxxxxxxxx>
wrote:

   Cques,



I always thought that the whole "ifile" business was bad practice.  Maybe
I'm lazy, but when I want to look at the init.ora file, or the
tnsnames.ora file, I don't want to have to go searching other files to see
what I'm looking for.



I like things simple and clear, and the ifile thing is neither.


This is, of course, simply my opinion.



Tom


     ------------------------------

This transmission may contain confidential, proprietary, or privileged
information which is intended solely for use by the individual or entity to
whom it is addressed.  If you are not the intended recipient, you are
hereby notified that any disclosure, dissemination, copying or distribution
of this transmission or its attachments is strictly prohibited.  In
addition, unauthorized access to this transmission may violate federal or
State law, including the Electronic Communications Privacy Act of 1985.  If
you have received this transmission in error, please notify the sender
immediately by return e-mail and delete the transmission and its
attachments.

   ------------------------------

 *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Jacques Kilchoer
*Sent:* Thursday, February 08, 2007 4:38 PM
*To:* oracle-l
*Subject:* RE: using ifile in the tnsnames.ora file



Sorry, I should do better proof-reading. I corrected a sentence below.



Recently however, when creating database links, I noticed that the
database link FAILED WHEN using an alias that is coming from an "ifile" in
the tnsnames.ora  (unable to resolve service name)


 ------------------------------

*De la part de* Jacques Kilchoer
*Objet :* using ifile in the tnsnames.ora file

Do you use an IFILE parameter in a network configuration file (
tnsnames.ora, sqlnet.ora, other) to consolidate entries  in a central
location? I guess it's an obsolete practice and I should stop.

I've been using IFILE parametes in the tnsnames.ora file for as long as
I've been using Oracle. Recently however, when creating database links, I
noticed that the database link  failed when using an alias that is coming
from an "ifile" in the tnsnames.ora  (unable to resolve service name),
even though SQL*Plus on the server could use that entry. I've never had
problems using an IFILE in the tnsnames.ora except the one I recently
encountered with database links.

Imagine my surprise when I saw this on Tom Kyte's website:


http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:489021635775

Quoter: "IFILE is not supported for tnsnames/listener/sqlnet/protocol.ora
files."


I checked the network administration / reference manuals for 8.0.6, 8.1.7,
9.0, 9.2, 10.1, the "ifile" parameter is never mentioned for the network
configuration files (sqlnet.ora, tnsnames.ora, listener.ora, cman.ora,
names.ora, ldap.ora) - but it is mentioned in the server reference manual
as a valid parameter for the init.ora file.

Is this a new limitation? For example I quickly found Metalink note
1017689.102 that tells me I can use ifile in the tnsnames.ora and
listener.ora files with an Oracle 8.0 listener.

I found a couple of recent notes that mentioned a tnsnames.ora containing
an ifile (Notes 397684.1 and 397567.1) but both of these notes had the
comment  "This document is being delivered to you via Oracle Support's Rapid
Visibility (RaV) process, and therefore has not been subject to an
independent technical review."


Other related posts: