Tnsnames ora где лежит windows 10

The TNSNAMES.ORA file is an important file when working with Oracle. Learn all about what it is, its location, and how to create and edit it in this article.

In this article, we’ll cover:

• What is TNSNAMES.ORA?
• Where is the TNSNAMES.ORA file?
• What order does Oracle check these locations
• TNSNAMES Location on Unix
• TNSNAMES Location on Windows
• What Is The Syntax?
• Modifying a TNSNAMES.ORA file
• Creating a TNSNAMES.ORA file
• TNSNAMES Example
• SQL Developer and TNSNAMES.ORA

What Is TNSNAMES.ORA?

TNSNAMES.ORA is a configuration file that the Oracle database uses. It allows users and applications to connect to Oracle databases by matching a connection name with all of the relevant details.

It’s written using a specific syntax, which I’ll cover later in this article. The good news is that it can be edited with any text editor.

The file and this article refer to a few different terms, such as service names and connect descriptors, which I’ll cover later in this article.

Where Is the TNSNAMES.ORA File Located?

The location of the TNSNAMES.ORA file is:

$ORACLE_HOMEnetworkadmin

What does this mean?

Well, $ORACLE_HOME is an environment variable. It works in the same way as a variable in a programming language, but it’s sits in your operating system.

In this case, $ORACLE_HOME is the location that the Oracle database is installed in. This environment variable, or path, works the same on Unix and Windows operating systems.

So, how do you find your $ORACLE_HOME value? I’ll show you how to do that in the next section.

There are some other locations that the TNSNAMES.ORA file can be stored in:

Client Machine

The ORACLE_HOMEnetworkadmin folder on your client machine. There is a file on both the server and the client.

TNS_ADMIN Environment Variable

There is another environment variable called TNS_ADMIN. The location of this folder could also have a TNSNAMES file.

To find the location of TNS_ADMIN, follow the same steps below to find ORACLE_HOME, but substitute the TNS_ADMIN value.

What Order Does Oracle Check These Locations In?

Because there are several locations for the TNSNAMES.ORA file, they are checked in a certain order:

1. If TNS_ADMIN is set, then this location is checked first. If the file is not found in this directory, it is assumed the file does not exist. You may need to create one.
2. In Windows, if the TNS_ADMIN environment variable is not set, then the registry is checked for the TNS_ADMIN parameter and checks that directory.
3. If the TNS_ADMIN variable is not set, then the ORACLE_HOMEnetworkadmin directory is checked.

How To Find ORACLE_HOME and the TNSNAMES.ORA Location in Unix

To find the location of ORACLE_HOME in Unix, you can run these commands:

env | grep ORACLE_HOME

Or, you can run the echo command

echo $ORACLE_HOME

How To Find ORACLE_HOME and the TNSNAMES.ORA Location in Windows

To find the ORACLE_HOME location in Windows, we can check a few places.

First, we’ll check the Environment Variables in the control panel. If it’s not there, we’ll check the registry.

To start, open the Control Panel.

Then, open System.

Click on Advanced System Settings, on the left.

Click on the Advanced tab (if it is not already selected) and click Environment Variables down the bottom.

Check the User Variables section and the System Variables section for a variable called ORACLE_HOME. If it is shown, then the Value will be your ORACLE_HOME location.

If it does not exist, it means you’ll need to check the registry. It isn’t showing in my Environment Variables, so I’ll check the registry.

Open the Run command box (on older versions of Windows), or if you’re on Windows 10, just open the Start menu.

Type regedit and press Enter.

On the left panel, navigate to this location by expanding the folders:

HKEY_LOCAL_MACHINESOFTWAREORACLE

Now, you’ll need to click on the item below Oracle on the left. This may be called KEY_XE (if you’re running Oracle Express like I am) or KEY_OraDb11g or something similar.

There will be an entry in this list on the left called ORACLE_HOME.

This is your ORACLE_HOME location. For example:

C:oraclexeapporacleproduct11.2.0server

To navigate to it, double-click on the line labelled ORACLE_HOME.

Copy the Value here, and paste it into Windows Explorer.

What Is The Syntax of the TNSNAMES.ORA File?

This file contains a series of entries, where each of them represents a connection string to the database.

An entry will look like this:

net_service_name =
  (DESCRIPTION=
    (ADDRESS = (PROTOCOL = TCP)(HOST = xxx.xxx.com)(PORT = 1521)
  )
  (CONNECT_DATA =
    (SERVICE_NAME=service_name)
  )
)

What does this mean?

• net_service_name: This is the name that you use for a connection string later. You can choose what this is. It’s like a name you give to this set of connection details.
• host: The IP address or server name where the database lives or that you want to connect to.
• port: The port that is required for the connection. In most cases the default port of 1521 will be fine.
• service_name: This is the name of the database you want to connect to.

What about the SID? The SID parameter was used in older versions of Oracle in this file (Oracle 8 and earlier). The service_name parameter should be used instead.

How Can I Modify the TNSNAMES.ORA File?

You can modify the file in a simple text editor. You can change an existing entry or create a new one.

To add an entry into the file, you can either copy the format from above, or copy and paste an existing entry from the file.

Then, make changes to it as needed.

Change the net_service_name, or the name you want to give to the connection. Change the host to the server name or IP address you want to connect to. Finally, change the service_name to the name of the database you want to connect to.

Save the file, and your changes will be saved.

How Can I Create a TNSNAMES.ORA File?

If you don’t have a TNSNAMES.ORA file in your ORACLE_HOME directory, you can create one. Or you can create one for any other reason.

To create the file, open a new text file in the editor of your choice (I use Notepad++).

Save the file with the name TNSNAMES.ORA (not a .txt file) and save it into your ORACLE_HOME location.

Now, add in a template for the entry you want to create:

net_service_name =
  (DESCRIPTION=
    (ADDRESS = (PROTOCOL = TCP)(HOST = xxx.xxx.com)(PORT = 1521)
  )
  (CONNECT_DATA =
    (SERVICE_NAME=service_name)
  )
)

Then, change the parameters to what you need to store for your database connection:

• net_service_name: the name you give to this connection, which will be used when you connect to it later.
• host: the server or IP address that the database runs on
• service_name: the name of the database you’re connecting to.

See below for an example of this.

TNSNAMES.ORA Entry Example

Here’s an example of an entry in this file:

ora_test =
  (DESCRIPTION=
    (ADDRESS = (PROTOCOL = TCP)(HOST = oracleserver.yourcompany.com)(PORT = 1521)
  )
  (CONNECT_DATA =
    (SERVICE_NAME=oratst)
  )
)

This means that the database runs on the server that’s called “oracle server.yourcompany.com”. The database name is orates, and when you connect to it, you’ll refer to this as ora_test.

Does SQL Developer Use TNSNAMES.ORA?

Yes, it does. In SQL Developer, you can set the location of your TNSNAMES.ORA file, which will give you additional options when creating connections to a database.

In SQL Developer, open Tools > Preferences.

Expand the Database section and click on Advanced.

In the Tnsnames Directory option at the bottom of the screen, add the location of the TNSNAMES.ORA file. This will be ORACLE_HOMEnetworkadmin as mentioned earlier.

Then, click OK.

Now, when you create a new connection, you can use this TNSNAMES data.

Click Create New Connection (the green + sign on the top left of SQL Developer).

In the Connection Type drop-down, select TNS.

Selecting TNS will allow you to select your connection details from the TNSNAMES file. This makes it easier to manage.

Jeff Smith has written more about how SQL Developer finds these files in this article.

Conclusion

The TNSNAMES.ORA file is used by Oracle to store and configure the connection details to different databases. It can be hard to find, but using this guide will make it easier. Making changes is easy, as it’s a simple text file with a specific format. It might not be something a database developer would need to use that often, but it’s still good to know.

Lastly, if you enjoy the information and career advice I’ve been providing, sign up to my newsletter below to stay up-to-date on my articles. You’ll also receive a fantastic bonus. Thanks!

В ранее приведенных примерах дескрипторов и идентификаторов подключений идентификатор подключения sales служил для подключения к службе sales. Идентификатор подключения может быть самим дескриптором подключения или более простым именем (наподобие sales), вместо которого затем подставляется дескриптор подключения. Обычно используемый простой идентификатор подключения называют именем сетевой службы. Таким образом, идентификатор подключения sales в ранее приведенных примерах является именем сетевой службы.

Поскольку указание полного дескриптора подключения при каждой установке подключения является довольно утомительной задачей, применение имен сетевых служб более целесообразно. Однако для этого потребуется поддерживать центральное хранилище всех соответствий между именами сетевых служб и информацией дескрипторов подключений, чтобы Oracle мог проверять актуальность имен сетевых служб. Таким образом, когда пользователь запускает процесс подключения, указывая имя сетевой службы sales, центральное хранилище ищет дескриптор подключения, соответствующий имени sales. Как только дескриптор подключения найден, Oracle Net инициирует подключение к базе данных на указанном сервере.

Oracle допускает использование нескольких типов хранилищ именования, и доступ к информации преобразования имен, хранящейся в этих хранилищах, можно получить одним из следующих методов именования.

• Метод локального именования. Этот метод для подключения к серверу базы данных использует файл tnsnames.ora, хранящийся на каждом клиенте.
• Метод именования простым подключением. Этот метод допускает подключения без какой-либо конфигурации имени службы.
• Метод внешнего именования. Этот метод использует независимую службу именования для преобразования имен служб.
• Метод каталожного именования. Этот метод использует LDAP-совместимый сервер для преобразования имен служб.

Независимо от применяемого метода именования процесс преобразования имен остается неизменным. Следующие действия понадобится выполнить при использовании любого из методов именования для разрешения дескриптора подключения именем сетевой службы.

1. Выберите метод именования — локальный, простое подключение, внешнее именование или именование с помощью службы каталогов.
2. Отобразите дескрипторы подключений на имена служб.
3. Сконфигурируйте клиенты, чтобы они использовали метод именования, выбранный на первом шаге.

Метод локального именования

Локальное именование — простейший и наиболее легкий способ установки подключения Oracle. При использовании этого метода имена служб и их дескрипторы подключения сохраняются в локальном файле конфигурации tnsnames.ora. По умолчанию этот файл всегда находится в каталоге $ORACLE_HOME/network/admin. Oracle предоставляет для использования образец файла tnsnames.ora, который можно найти в каталоге по умолчанию. ( Файл tnsnames.ora можно считать аналогичным файлу /etc/hosts, который содержит информацию по организации сети в системах UNIX/Linux.) Файл tnsnames.ora всегда присутствует на компьютере клиента. Если сервер базы данных применяется также для установки подключений клиентского типа, он будет содержать файл tnsnames.ora для других баз данных, к которым необходимо подключаться с этого сервера.

При инициализации подключения посредством интерфейса SQL*Plus либо других средств необходимо указать имя пользователя и пароль для той базы данных, к которой осуществляется подключение. Как только это будет сделано, службе Oracle Net придется выяснить, на каком сервере действует база данных, поэтому она обращается к файлу tnsnames.ora для определения сетевого адреса, протокола и порта сервера базы данных. Успешно справившись с этой задачей, она инициализирует соединение со слушателем на том компьютере, где расположен сервер базы данных. После того как слушатель передает подключение серверу базы данных, база данных выполняет аутентификацию имени пользователя и пароля.

После того как подключения сконфигурированы для применения метода локального именования, все подключения к базе данных, выполняются они непосредственно через интерфейс SQL*Plus или через страницу регистрации приложения, будут применять файл tnsnames.ora для преобразования имен служб.

При использовании метода локального именования клиентские компьютеры кроме файла tnsnames.ora используют еще один файл — sqlnet.ora. Этот файл хранится на каждом клиенте и содержит важные параметры сетевой конфигурации. (Естественно, если сервер служит и в качестве клиента, он также будет содержать файл sqlnet.ora.) Использование параметра SQLNET.AUTHENTICATION_SERVICES для конфигурирования аутентификации операционной системы будет описано мною в следующих заметках блога. Типичный файл sqlnet.ora имеет следующий вид: 

# SQLNET.ORA Network Configuration File:
/u01/app/oracle/product/10.1.0/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
NAMES.DEFAULT_DOMAIN = wowcompany.com
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES)

Обычно файлы конфигурации tnsnames.ora и sqlnet.ora располагаются в каталоге $ORACLE_HOME/network/admin в системах UNIX/Linux и в каталоге $ORACLE_HOMEnetworkadmin в системах Windows. Однако эти файлы можно размещать в любом удобном месте. Если они помещены в каталоге, отличном от заданного по умолчанию, потребуется в переменной среды TNS_ADMIN указать их местоположение. Oracle будет искать эти два файла в следующих местах и воспользуется первым из найденных экземпляров.

1. В каталоге, указанном в переменной среды TNS_ADMIN.
2. Поиск файла tnsnames.ora будет выполняться в глобальном каталоге конфигурации. Для систем UNIX/Linux это обычно каталог /var/opt/oracle.
3. В стандартных сетевых каталогах: $ORACLE_HOMEnetworkadmin в системах UNIX/Linux и в каталоге $ORACLE_HOMEnetworkadmin в системах Windows.

Изменение файла tnsnames.ora вручную

Чтобы сконфигурировать метод локального именования, нужно внести изменения в файл tnsnames.ora, предоставленный Oracle при создании базы данных. Для этого достаточно перейти в заданный по умолчанию каталог хранения файла tnsnames.ora, $ORACLE_HOME/network/admin, и отредактировать этот файл, чтобы отразить информацию об именах данной сети и базы данных. При добавлении новой базы данных в систему необходимо также физически добавить отображение имени службы новой базы данных в файл tnsnames.ora каждого пользователя или отправить всем пользователям новый обновленный файл tnsnames.ora, чтобы они заменили им старый файл. В листинге ниже показан типичный файл tnsnames.ora.

---

# TNSNAMES.ORA Network Configuration File:
/u01/app/oracle/product/10.1.0/db_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
finance =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = finance.world)
)
)
salesprod =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.11.150.1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = salesprod.world)
)
)
custprod =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = custprod)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = custprod.world)
)
)

---

В файле tnsnames.ora, приведенном в листинге выше, перечислены три базы данных, и каждая из них отличается собственными характеристиками. Первая запись — база данных finance, предназначенная для настольного компьютера NTL-ALAPATISAM. База данных salesprod расположена на сервере UNIX с IP-адресом 172.11.150.1, к которому служба Oracle Net может подключаться, используя порт 1521 и протокол TCP. Последняя база данных для обозначения сервера хоста вместо IP-адреса использует символьное имя custprod.

Если бы в этот файл tnsnames.ora нужно было добавить четвертую базу данных orderprod, расположенную на хосте с IP-адресом 172.16.11.151, в файл tnsnames.ora потребовалось бы добавить соответствующий идентификатор подключения, как показано в следующем примере: 

orderprod =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.11.151)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME =orderprod.world)
)

После того как имя сетевой службы сконфигурировано, а файл tnsnames.ora должным образом модифицирован, подключение к базе данных должно выполняться так, как описано ниже.

1. Распространите новую конфигурацию имени службы своим клиентам. Это можно выполнить, копируя файлы tnsnames.ora и sqlnet.ora на компьютеры клиентов, на которых должен присутствовать установленный Oracle Client. В качестве альтернативы, для конфигурирования имен сетевых служб на самом клиенте можно воспользоваться помощником Oracle Net8 Assistant или Net8 Configuration Assistant.
2. Удостоверьтесь, что слушатель запущен на том сервере, где действует база данных. Проверьте, что слушатель использует тот же протокол и адрес, которые были сконфигурированы для имени сетевой службы в файле tnsnames.ora. Убедитесь также, что слушатель использует протокол TCP/IP и прослушивает заданный по умолчанию порт 1521.
3. Удостоверьтесь, что целевая база данных, к которой вы пытаетесь подключиться, действует.
4. Протестируйте новое подключение с помощью следующей команды: 

CONNECT имя_пользователя/пароль@имя_сетевой_службы

Хотя локальное именование достаточно просто в реализации, применение этого метода оказывается обременительным при наличии большого количестве клиентских компьютеров, которым требуется непосредственный доступ к серверу баз данных, поскольку в этом случае приходится поддерживать локальные копии файла tnsnames.ora на всех локальных клиентах. Более того, при изменении хостов или добавлении баз данных в систему приходится обеспечивать внесение изменений во все клиентские файлы tnsnames.ora. Естественно, если база клиентов невелика, поддержание файлов tnsnames.ora не должно составлять проблему.

Изменение tnsnames.ora с помощью Net Configuration Assistant

Для добавления новой службы в свой файл tnsnames.ora можно отдать предпочтение помощнику Net Configuration Assistant (NCA) Oracle, а не делать все вручную. Подобно файлу listener.ora, файл tnsnames.ora является несколько сложным, учитывая все используемые в нем скобки, и при редактировании его вручную легко допустить ошибку. Создавать новые службы с помощью графического интерфейса пользователя очень просто. Помощник NCA запрашивает имя сервера, имя базы данных, сетевой адрес и тип протокола. По завершении конфигурирования подключения в заданном по умолчанию каталоге появится новый или обновленный файл tnsnames.ora, включающий в себя добавленные службы баз данных.

Чтобы можно было применять NCA, вначале на клиентском компьютере потребуется установить программное обеспечение Oracle Client c компакт-диска Oracle Client CD. NCA поставляется как с серверной, так и с клиентской версией ПО. Создание и тестирование подключения займет пару минут.

Чтобы использовать NCA для конфигурирования нового имени службы в файле tnsnames.ora, нужно выполнить следующие действия.

1. Запустите на сервере UNIX/Linux помощник Net Configuration Assistant с помощью команды netca, как показано в следующем примере: 

$ export DISPLAY=172.16.14.15:0.0
$ netca

---

На заметку! В системе Windows помощник NCA запускается выбором команды меню StartProgramsOracle-HOME_NAMEConfiguration and Migration Tools (ПускПрограммыИмя домашнего каталога OracleСредства конфигурирования и переноса).

---

1. Откроется страница Welcome (Приветствие). Выберите опцию Local Net Service Name Configuration (Локальная конфигурация имен сетевых служб) и щелкните на кнопке Next (Далее).
2. На странице Net Service Name Configuration (Конфигурация имен сетевых служб) выберите опцию Add (Добавить) и щелкните на кнопке Next.
3. На странице Service Name Configuration (Конфигурация имен служб) введите имя службы, которую необходимо сконфигурировать. В данном примере это база данных emrep.netbsa.org. Обратите внимание, что в общем случае имя службы совпадает с глобальным именем базы данных. Щелкните на кнопке Next.
4. На странице Select Protocol (Выберите протокол) выберите протокол TCP и щелкните на кнопке Next.
5. На странице TCP/IP Protocol (Протокол TCP/IP) введите имя хоста, на котором действует база данных. Выберите стандартный номер порта, 1521, и щелкните на кнопке Next.
6. На странице Test (Тестирование) щелкните на кнопке Yes, Perform a Test (Да, выполнить тестирование), а затем щелкните на кнопке Next.
7. NCA предпримет попытку подключения к базе данных с применением новой конфигурации и отобразит результаты. В случае неудачи подключения удостоверьтесь, что слушатель целевой базы данных запущен, а сочетание имени пользователя и пароля, по умолчанию используемое процессом тестирования (system/manager), изменено на действующее сочетание. Убедитесь также, что имена базы данных и домена указаны правильно.
8. Затем на странице Net Service Name (Имя сетевой службы) NCA попросит подтвердить имя сетевой службы. Щелкните на кнопке Next.
9. На странице Another Service Name (Имя другой службы) можно сконфигурировать дополнительные имена служб.
10. На странице Net Service Name Configuration Done (Конфигурация имени сетевой службы завершена) щелкните на кнопке Next. Когда снова откроется страница Welcome, щелкните на кнопке Finish (Готово).

---

На заметку! Имена сетевых служб можно конфигурировать и на странице Net Services Administration (Администрирование сетевых служб) в Oracle Enterprise Manager или в графическом интерфейсе пользователя Oracle Net Manager.

---

Метод именования простым подключением

Администраторы БД Oracle могут упростить конфигурирование клиентов, используя метод именования простым подключением. С помощью этого метода клиенты базы данных могут подключаться к ней без применения файла tnsnames.ora в средах TCP/IP. Все что им потребуется — это имя хоста, необязательный номер порта и имя службы базы данных. Таким образом, мы располагаем не требующей конфигурирования и доступной изначально возможностью подключения к любой базе данных в системе по протоколу TCP/IP.

Единственным условием для применения метода именования простого подключения является наличие поддержки протокола TCP/IP как на стороне клиента, так и на стороне сервера. Однако при этом отпадает необходимость в настройке файла tnsnames.ora. Этот новый метод подключения можно рассматривать в качестве расширения метода именования хоста, предложенного в Oracle9i.

Синтаксис применения этого нового метода подключения выглядит следующим образом: 

$ CONNECT имя_пользователя/пароль@[//]хост[:порт][/имя_службы]

В этой синтаксической конструкции следует обратить внимание на четыре описанных ниже элемента.

• //. Этот элемент не обязателен.
• хост. Этот параметр обязателен. Можно указать либо символическое имя хоста, либо IP-адрес сервера, на котором расположена целевая база данных.
• порт. Этот параметр не обязателен. Если порт не указан, по умолчанию используется порт 1521.
• имя_службы. Этот параметр указывает имя службы базы данных (по умолчанию оно совпадает с именем хоста) и является необязательным. Если имя хоста и имя сервера базы данных идентичны, этот параметр можно опустить. Если же они не совпадают, понадобится указать допустимое имя службы для идентификации базы данных.

Следующий пример демонстрирует результат подключения к базе данных dev1, расположенной на сервере hp50. Подключение осуществляется непосредственно из приглашения операционной системы, поэтому вместо ключевого слова CONNECT используется SQLPLUS:

$ sqlplus system/Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.:1521/emrep.netbsa.org
–
SQL*Plus: Release 11.1.0.6.0 - Production on Thu Mar 20 09:38:15 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL>

Обратите внимание, что подключение также можно выполнить, не используя необязательный номер порта, как показано в следующем примере:

$ sqlplus system/Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript./emrep.netbsa.org

Обратите внимание, что основные параметры метода простого подключения совпадают с информацией подключения метода локального именования, которая требуется в файле tnsnames.ora. Приведенная в предыдущем примере информация в файле tnsnames.ora была бы сконфигурирована следующим образом: 

(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=ntl_alapatisam.netbsa.org)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=emrep.netbsa.org)))

При подключении из интерфейса SQL*Plus можно применять следующий синтаксис:

$ sqlplus /nolog
SQL*Plus: Release 11.1.0.6.0 - Production on Thu Mar 20 09:38:15 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
SQL> connect system/Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.:1521/emrep.netbsa.
org
Connected.
SQL> 

---

На заметку! Из четырех элементов, которые должны быть указаны при использовании в качестве метода именования простого подключения, обязательным является только имя хоста

---

Конфигурирование именования простым подключением

Как видно из его названия, метод именования простым подключением требует очень мало в плане конфигурирования. Для указания метода простого подключения в качестве значения переменной NAMES.DIRECTORY_PATH в файле sqlnet.ora применяется ключевое слово EZCONNECT. Рассмотрим следующий файл sqlnet.ora: 

# sqlnet.ora Network Configuration File:
/u01/app/oracle/10.1.0/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
NAMES.DEFAULT_DOMAIN = netbsa.org
SQLNET.AUTHENTICATION_SERVICES = (NTS)
NAMES.DIRECTORY_PATH = (TNSNAMES,EZCONNECT)

Последняя строка показывает методы подключения, которые служба Oracle Net будет использовать для преобразования идентификаторов подключений в дескрипторы подключений. Параметр NAMES.DIRECTORY_PATH задает порядок, в котором служба Oracle Net будет применять методы именования для преобразования идентификаторов подключений в дескрипторы подключений. В этом примере TNSNAMES является первой настройкой, поэтому Oracle Net будет использовать файл tnsnames.ora по умолчанию. Если ей не удастся подключиться с применением файла tnsnames.ora, она попытается подключиться методом EZCONNECT.

Если требуется, чтобы метод EZCONNECT применялся по умолчанию, можно вручную отредактировать файл sqlnet.ora, переместив значение EZCONNECT на первое место в параметре NAMES.DIRECTORY_PATH: 

NAMES.DIRECTORY_PATH = (EZCONNECT, TNSNAMES)

Ограничения метода именования простым подключением

Ниже перечислены ограничения в применении метода именования простым подключением.

• На стороне клиента должно быть установлено программное обеспечение Oracle Database 11g Net Services.
• Поддержка протокола TCP/IP должна быть обеспечена как на стороне клиента, так и на стороне сервера баз данных.
• Нельзя использовать какие-либо расширенные сетевые функциональные возможности Oracle, вроде поддержки пула соединений, вызовов внешних процедур или гетерогенных служб (Heterogeneous Services).

Резидентный пул соединений базы данных Oracle

Вплоть до появления версии Oracle Database 11g для подключения сеансов пользователя к базе данных можно было применять два способа: процесс выделенного сервера, который в каждый момент времени обрабатывает один процесс пользователя, и процесс разделяемого сервера, который обслуживает несколько процессов пользователей. В Oracle Database 11g появился третий способ подключения сеансов к базе данных, который является разновидностью подхода с использованием выделенного сервера и действует на основе концепции использования пула серверов при обслуживании запросов на подключение.

Как правило, веб-приложения устанавливают соединение, быстро его используют и быстро освобождают. Для этих приложений типичным является совместное или повторное использование сеансов. Обычно веб-приложения не поддерживают постоянного активного соединения с базой данных, а используют ее время от времени и, как правило, не сохраняют состояние при повторном подключении к БД. Применение пула соединений помогает обслуживать тысячи конечных пользователей с помощью небольшого количества сеансов, тем самым повышая масштабируемость базы данных. Технологии вроде PHP сами по себе не могут воспользоваться преимуществами пула соединений на сервере приложений, поскольку каждый процесс веб-сервера требует выделенного соединения с базой данных.

Совершенно новый метод подключения с помощью резидентного пула соединений базы данных ( database resident connection pooling — DRCP) использует пулы серверов для обслуживания большого количества сеансов пользователей. Применение DRCP снижает требования к памяти по сравнению с конфигурациями, использующими выделенные и разделяемые серверы.

DRCP разработан специально для поддержки таких архитектур, как PHP с сервером Apache, которые не в состоянии получить преимущества от пула соединений промежуточного слоя, поскольку они применяют мультипроцессные однопоточные серверы приложений. DRCP позволяет таким приложениям легко масштабировать серверных подключений вплоть до десятков тысяч. DRCP во многом аналогичен выделенному серверу в плане того, что работает подобно конфигурации с выделенным сервером, но при этом каждое подключение пользователя не должно сохранять связь с единственным выделенным сервером в течение времени своего существования. Каждое соединение с базой данных занимает сервер на краткий промежуток времени. Когда сеанс пользователя завершает свою работу, он освобождает соединение с сервером, делая его снова доступным для пула серверов.

Принцип работы DRCP

DRCP использует брокер соединений, который присваивает каждый новый сеанс клиента доступному серверу из пула. Как только запрос на подключение клиента обслужен базой данных, соединение освобождает сервер, возвращая его в пул серверов. Таким образом, сеансы используют память и другие ресурсы только в то время, когда база данных действительно выполняет задачи для обслуживания сеансов, и освобождают эти ресурсы, освобождая сервер и возвращая его в пул серверов.

До тех пор пока количество серверов в пуле базы данных не достигло максимального значения, брокер соединений будет создавать сервер в пуле для назначения его новому клиентскому соединению, если не сможет найти свободный сервер в пуле. По достижении максимального количества серверов пула брокер не сможет создавать новые серверы. В этом случае он будет отправлять клиентские подключения в очередь ожидания на освобождение серверов пула. В отличие от подхода с применением выделенного сервера, где используемый объем памяти (PGA) пропорционален количеству сеансов пользователей, при использовании DRCP объем памяти пропорционален числу активных серверов из пула. Следующий пример демонстрирует, как значительно сэкономить память, перейдя от конфигурации с применением выделенного сервера к конфигурации с DRCP.

В этом примере предполагается, что существует 5000 клиентских соединений, и что каждый клиентский сеанс требует 200 Кбайт, а каждый процесс сервера — 5 Мбайт памяти. Кроме того, будем считать, то максимальное количество необходимых серверных соединений равно 200. Общий объем памяти, требуемый для конфигураций с применением выделенного сервера и с применением DRCP можно вычислить следующим образом:

Выделенный сервер
Общий необходимый объем памяти = 5000 × (200 Кбайт + 5 Мбайт) = 260 Гбайт
Резидентный пул соединений базы данных
Общий необходимый объем = 200 (200 Кбайт + 5 Мбайт) = 502 Мбайт
Разделяемый сервер
500 × 200 Кбайт + 200 × 5 Мбайт = 11 Гбайт

Как видите, в то время как конфигурация с выделенным сервером требует 260 Гбайт, для конфигурации с применением DRCP необходимо лишь не многим больше 0,5 Гбайт

Активизация и отключение DRCP

По умолчанию база данных изначально конфигурируется с используемым по умолчанию пулом соединений SYS_DEFAULT_CONNECTION_POOL. Однако чтобы воспользоваться преимуществами, предоставляемыми DRCP, потребуется запустить заданный по умолчанию пул соединений. Его запускают с помощью процедуры START_POOL из пакета DBMS_CONNECTION_POOL, как показано в следующем примере: 

SQL> connect sys/sammyy1 as sysdba
SQL> exec dbms_connection_pool.start_pool();
PL/SQL procedure successfully completed.
SQL>

Состояние пула соединений можно проверить с помощью следующего запроса:

SQL> select connection_pool, status, maxsize from dba_cpool_info;
CONNECTION_POOL              STATUS  MAXSIZE
---------------------------  ------  --------
SYS_DEFAULT_CONNECTION_POOL  ACTIVE  80
SQL> 

После запуска пула соединений он останется открытым даже при остановке базы данных и ее повторном запуске. Пул соединений можно остановить, выполняя процедуру STOP_POOL:

SQL> exec dbms_connection_pool.stop_pool();
PL/SQL procedure successfully completed.
SQL>

Пулом соединений управляет фоновый процесс CMON (Connection Monitor — Монитор соединений). Приложения передают процессы выделенного сервера процессу CMON, который возвращает процесс пулу соединений. DRCP-подключение можно указать следующим образом.

При использовании строки EZ Connect укажите в ней ключевое слово POOLED: 

myhost.comany.com:1521/mydb.company.com:POOLED

При использовании файла tnsnames.ora укажите параметр SERVER=POOLED в строке подключения TNS:

mydb = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=myhost.company.com)
(SERVER=POOLED)))

Конфигурирование DRCP

Для конфигурирования DRCP в базе данных используют следующие параметры. Пул соединений можно конфигурировать в зависимости от требований к применению БД.

Основные параметры конфигурации DRCP перечислены ниже.

• INACTIVITY TIMEOUT. Максимальное время бездействия, разрешенного помещенного в пул серверу, прежде чем он будет остановлен.
• MAX_LIFETIME_PER_SESSION. Длительность времени жизни (time to live — TTL) для сеанса, помещенного в пул.
• MAX_USES_PER_SESSION. Максимальное число раз предоставления помещенного в пул сервера пулу соединений.
• MAX_SIZE и MIN_SIZE. Максимальное и минимальное количество помещенных в пул серверов в пуле соединений.
• MAX_THINK_TIME. Максимальное время, в течение которого клиент может оставаться неактивным после получения сервера из пула соединений.

Для одновременной настройки нескольких параметров конфигурации пула соединений можно выполнить процедуру CONFIGURE_POOL из пакета DBMS_CONNECTION_POOL. Чтобы определить значение одного параметра конфигурации пула соединений, можно запустить процедуру ALTER_PARAM из пакета DBMS_CONNECTION_POOL, как показано в следующем примере: 

SQL> exec dbms_connection_pool.alter_param(' ','INACTIVITY_TIMEOUT','2400')

Приведенный пример демонстрирует, как можно определить значение параметра INACTIVITY_TIMEOUT. В соответствии со значением параметра INACTIVITY_TIMEOUT, равным 2400, база данных разрешает помещенному в пул серверу оставаться бездействующим на протяжении периода длительностью до одного часа, прежде чем соединение будет разорвано.

Значения параметров конфигурации пула соединений, заданные по умолчанию, можно восстановить, выполняя процедуру RESTORE_DEFAULTS, как показано в следующем примере: 

SQL> exec dbms_connection_pool.restore_defaults()

Процедура RESTORE_DEFAULTS помогает восстановить заданные по умолчанию значения для всех параметров конфигурации пула соединений.

Мониторинг DRCP

Для отслеживания работы DRCP используются следующие представления.

• DB_CPOOL_INFO. Отображает имя пула соединений, его состояние, максимальное и минимальное количества соединений и тайм-аут для бездействующих сеансов
• V$CPOOL_STAT. Отображает статистические сведения, такие как количество запросов сеансов и время ожидания запросов сеансов.
• V$CPOOL_CC_STATS. Отображает подробные статистические сведения о соединении на уровне класса.

Метод внешнего именования

Для преобразования имен сетевых служб внешний метод именования использует внешние службы именования наподобие Network Information Service (Сетевая информационная служба) (NIS), которая первоначально была разработана компанией Sun Microsystems. Системы NIS содержат центральную базу данных имен хостов и используют двумерное пространство имен, основанное на главном сервере.

Чтобы использовать метод внешнего именования для преобразования имен, потребуется выполнить следующие действия.

1. Попросите своего системного администратора сконфигурировать NIS, если это еще не было сделано.

2. Создайте файл tnsnames.ora, как это было бы сделано при использовании метода локального именования.

3. Преобразуйте файл tnsnames.ora в карту tnsnames, которая впоследствии понадобится для сервера NIS. Для извлечения карты tnsnames из файла tnsnames.ora системный администратор должен использовать команду tns2nis, как показано в этом примере: 

# tns2nis tnsnames.ora

4. Скопируйте файл карты связей tnsnames на сервер, на котором действует служба NIS.

5. Установите файл карты tnsnames на сервер NIS, используя NIS-программу makedbm:

# makedbm tnsnames /var/yp/'domainname'/tnsnames 

6. Протестируйте установку карты связей tnsnames в службе NIS с помощью следующей команды:

# ypmatch net_service_name tnsnames 

Вы должны получить подтверждение в следующей форме:

description=(address=(protocol=tcp)
(host=имя_хоста)(port=номер_порта)))
(connect_data=(service_name=имя_службы))) 

7. Отредактируйте файл sqlnet.ora, как показано ниже:

NAMES_DIRECTORY_PATH=(nis, hostname, tnsnames) 

Метод nis должен быть указан первым в скобках, т.к. служба Oracle Net будет пытаться преобразовать имя службы, вначале используя службу NIS. Порядок следования остальных элементов в скобках значения не имеет.

Именование с помощью службы каталогов

По установившейся традиции сетевая информация хранилась на нескольких серверах, часто в различных форматах, но современные Интернет-приложения подвергают многие организации огромному риску в плане безопасности. Децентрализованные системы служат постоянным источником беспокойства для большинства специалистов в области безопасности. Централизованные службы каталогов, предназначенные для аутентификации пользователей и реализации политик безопасности, повышают возможности организаций по защите своих сетевых ресурсов.

Службы каталогов — это огромные централизованные хранилища, которые содержат все метаданные, связанные с базами данных, сетями, пользователями, политиками безопасности и т.п. Каталог, поддерживающий работу этих служб, может замещать множество локализованных файлов, таких как tnsnames.ora, и предоставлять единственное место выполнения преобразования имен и аутентификации. Эти каталоги представляют собой сравнительно редко обновляемые базы данных, по отношению к которым выполняется значительное количество операций чтения. Скорость получения информации — основной фактор успешности работы службы каталогов.

Вот несколько примеров видов данных, которыми такие каталоги могут эффективно управлять:

• имена пользователей и пароли;
• профили пользователей;
• политики предоставления полномочий;
• конфигурация сети и информация сетевых служб.

Существует много видов доступных коммерческих служб каталогов, в том числе Active Directory от Microsoft и Oracle Internet Directory (OID), и их можно арендовать для выполнения функций хоста для организации.

Метод именования с помощью службы каталогов хранит информацию о соединениях базы данных на сервере каталогов, совместимом с протоколом LDAP (Lightweight Directory Access Protocol — Облегченный протокол доступа к каталогам). Идентификаторы соединений сохраняются в контексте Oracle, который содержит записи, предназначенные для использования с OID.

Хотя вначале централизованная настройка может показаться пугающе сложной, в действительности она достаточно проста. Первоначальные затраты могут оказаться выше, но впоследствии затраты на управление информацией минимальны. Кроме облегчения клиентам подключения к центральным сетям и базам данных, такие каталоги, как OID, чрезвычайно ценны с точки зрения обеспечения безопасности в пределах всей организации.

Oracle Internet Directory

OID — это LDAP-совместимая служба каталогов, которая, помимо прочего, хранит также идентификаторы соединений. LDAP — популярный протокол доступа к сетевым службам, и он является Интернет-стандартом хранения данных и доступа к каталогам. Служба OID чрезвычайно масштабируема, поскольку она реализована на основе в высшей степени масштабируемой базы данных Oracle. Это позволяет хранить огромный объем информации о каталогах и легко получать к ней доступ. Данные защищены, поскольку они хранятся в базе, а OID является в высшей степени доступной службой, как и база данных Oracle. Спецификация LDAP привлекательна также минимально необходимым объемом клиентского программного обеспечения.

OID можно использовать для многих приложений, таких как адресные книги, хранилища сертификатов безопасности и корпоративные службы каталогов. Компания Oracle настоятельно рекомендует переходить к применению OID в качестве способа конфигурирования соединений баз данных. Путем отхода от Oracle Names (Имена Oracle) — метода подключения, предоставляемого в прошлом — компания Oracle позиционирует OID в качестве основной альтернативы традиционного метода локального именования, который требует использования файла конфигурации сети tnsnames.ora. База данных Oracle может применять OID для хранения имен пользователей и паролей и для хранения верификатора пароля вместе с записью каждого пользователя. Другие компоненты Oracle используют OID в различных целях.

• Oracle Application Server Single Sign-On (Единый интерфейс входа в сервер приложений Oracle). Применяет OID для хранения записей пользователей.
• Oracle Collaboration Suite (Пакет для обеспечения сотрудничества Oracle). Использует OID для осуществления централизованного управления информацией о пользователях и группах.
• Oracle Net Services (Сетевые службы Oracle). Пользуется OID для хранения и преобразования имен служб базы данных и сетевых служб.
• Oracle Advanced Security (Расширенная служба безопасности Oracle). Использует OID для централизованного управления аутентификационными мандатами пользователей, авторизацией, преобразованиями в схему совместного использования, аутентификацией посредством единственного пароля, безопасностью пользователей предприятия и центральным хранилищем мандатов инфраструктуры PKI (Public Key Infrastructure — инфраструктура открытых ключей).

OID включает в себя следующие элементы.

• Oracle directory server (Сервер каталогов Oracle). Предоставляет имена служб и другую информацию, используя при этом многоуровневую архитектуру поверх стека протоколов TCP/IP.
• Oracle directory replication server (Сервер репликации каталогов Oracle). Реплицирует данные LDAP между серверами каталогов Oracle.
• Средства администрирования каталогов, в том числе:
• Oracle Directory Manager (Диспетчер каталогов Oracle), графический интерфейс пользователя, который облегчает администрирование OID, и другие утилиты администрирования на основе командной строки;
• средства управления сервером каталогов, входящие в состав консоли Application Server Control (Управление сервером приложений) Oracle Enterprise Manager 10g, которые позволяют отслеживать события реального времени из веб-браузера.

Основная идея применения OID проста. Пользователи подключаются к OID, который является приложением, действующим в базе данных Oracle. Пользователи предоставляют OID идентификатор службы Oracle (имя базы данных). Каталог возвращает полную информацию о соединении — имя хоста, протокол подключения, номер порта и имя экземпляра базы данных — клиенту, который затем подключается к серверу базы данных. Идентификаторы соединений хранятся в контексте Oracle, который содержит такие записи, как имена баз данных и служб, предназначенные для использования с программным обеспечением Oracle, подобным OID.

Функция Advanced Security Oracle использует OID для централизованного управления информацией, связанной с пользователями. При использовании технологии реплицированной базы данных каталог Oracle OID будет весьма полезным в плане преодоления сложностей, связанных с использованием нескольких серверов и сетевых протоколов.

Хотя компания Oracle предпочла бы, чтобы все сетевые конфигурации были преобразованы в OID, это совершенно не означает, что предоставляемые этой службой преимущества окупают дополнительные накладные расходы для большинства небольших или средних предприятий. Помните, что OID не является продуктом, предназначенным исключительно для конфигурирования сети. Сетевые соединения базы данных — лишь небольшая часть возможностей OID. Подход локального именования (или новый метод именования простым подключением) благодаря своей простоте по-прежнему остается удобным для большинства организаций.

Как OID осуществляет подключения к базам данных

При использовании OID для преобразования имен следует помнить, что клиент не располагает файлом, таким как tnsnames.ora, содержащим информацию о преобразовании. При использовании именования с помощью службы каталогов клиенты Net Services подключаются к базе данных следующим образом.

1. Лицо, которое желает выполнить подключение, вводит на клиентском компьютере свое обычное сочетание имени пользователя/пароля и идентификатор соединения.
2. Файл sqlnet.ora на компьютере клиента указывает, что он использует OID для преобразования имен, поэтому клиент Net Services передает свой запрос процессу слушателя/диспетчера OID.
3. Слушатель/диспетчер OID передает запрос LDAP серверу каталогов Oracle.
4. Сервер каталогов подключается к базе данных OID и преобразует идентификатор соединения в соответствующий дескриптор соединения, который содержит информацию о сети, сервере и протоколе. Затем он отправляет эту подробную информацию дескриптора соединения клиенту Net Services.
5. Клиент отправляет полученный дескриптор соединения службе слушателя Oracle Net Listener (или диспетчеру, если используются разделяемые серверы).
6. Служба слушателя принимает запрос на подключение и, после его проверки, пересылает базе данных.

Организация OID

Каталог содержит набор сведений о различных объектах, таких как имена и адреса сотрудников или информацию об именах служб баз данных . Информация в каталоге организована в виде иерархической структуры, получившей название DIT (Directory Information Tree — Дерево информации каталога). Каждая запись каталога образуется из различных объектных классов и атрибутов следующим образом:

• каталоги образуются из объектных классов;
• объектные классы — это группы атрибутов;
• атрибуты представляют собой контейнеры, содержащие данные.

Каталог состоит из записей, которые представляют собой коллекции информации об объекте. Для однозначной идентификации записи требуется какое-либо средство для указания ее местоположения в структуре каталога. Этим однозначным локатором адреса является отличительное имя (distinguished name — DN) записи. DN подобно адресу, который точно указывает местоположение записи в каталоге — оно предоставляет полный путь от вершины иерархии до местоположения записи.

Ниже приведен пример DN: 

cn=nina
ou=finance
c=us
o=wowcompany 

Это DN записи nina содержит следующие узлы:

• cn — общее имя (common name);
• ou — организационная единица (organizational unit);
• c — страна (country);
• o — организация (organization).

Таким образом, DN-имя nina.finance.us.wowcompany уникальным образом определяет лицо с именем Nina, которое работает в финансовом отделе (finance) филиала в США (US) компании Wowcompany. Обратите внимание, что каждый из отдельных узлов называют относительными отличительными именами (relative distinguished names — RDN), поэтому, по сути, DN — это всего лишь строка имен RDN.

Контекст именования — это смежное поддерево на одном сервере каталогов. Контекст Oracle содержит соответствующие записи, предназначенные для использования с такими функциями Oracle, как именование с помощью службы каталогов

Oracle Net Service и безопасность пользователя предприятия. Один сервер каталогов может содержать несколько контекстов Oracle. OID создаст заданный по умолчанию контекст Oracle в корне дерева информации каталога. В дереве DIT контекст Oracle RDN (cn=OracleContext) является местоположением по умолчанию, которое клиенты применяют для поиска в каталоге соответствующих дескрипторов соединений для указанных идентификаторов соединений.

Контекст Oracle в дереве каталогов должен содержать все имена служб, включая полную информацию о сетевых подключениях и подключениях к серверам. В дополнительных подзаписях, поддерживающих именование с помощью службы каталогов, контекст Oracle содержит записи, поддерживающие функции безопасности предприятия. Поэтому при попытке подключения к базе данных на сервере серверу OID не нужно просматривать все дерево каталогов от корневой записи до последнего узла. Нужно просто снабдить его частичным именем DN с указанием пути от корневого узла до контекста Oracle. Контекст Oracle будет содержать имена сетевых служб, а те, в свою очередь, будут содержать подробную информацию о подключении.

Административный контекст, называемый также контекстом именования с помощью каталогов, — это запись каталога, которая содержит контекст Oracle. Следующий простой пример демонстрирует эти несколько запутанные понятия.

Полное имя DN для базы данных orcl выглядит так: 

dc=com,dc=wowcompany
cn=orcl,
cn=description,
cn=address,
cn=port,
cn=service_name

В записи DN dc означает domain component (компонент домена) и обычно используется для описания элементов доменов в каталоге.

Важно отметить, что поскольку вся информация дескриптора соединения хранится в контексте Oracle RDN, полное имя DN не обязательно указывать при каждом поиске информации о подключении к базе данных. Приведенное достаточно длинное имя DN можно заменить следующим имеющим обобщенный вид именем DN:

dc=com,dc=wowcompany,cn=OracleContext

Обратите внимание, что dc определяет компонент домена, а cn означает общее имя (common name). В этом примере и com, и wowcompany — компоненты домена, поэтому они расположены в верхней части дерева каталога.

Инсталляция OID

OID можно установить с применением программного обеспечения сервера приложений Oracle Application Server 10g Release 2 (10.1.2.0.0). При использовании универсального инсталлятора Oracle в окне Select a Product to Install (Выберите продукт для установки) потребуется выбрать опцию Oracle AS Infrastructure 10g (Инфраструктура сервера приложений Oracle 10g). Эта опция позволяет установить новую службу OID на сервер. На следующей странице универсального инсталлятора Oracle — Select Installation Type (Выберите тип установки) — выберите опцию Identify Management and Metadata Repository (Управление идентификацией и хранилище метаданных). Она создает хранилище метаданных Metadata Repository, существование которого обязательно для инсталляции OID.

Рассмотрение установки и управления OID выходит за рамки настоящей книги. За более подробной информацией обращайтесь к документации Oracle Application Server Release 2 на веб-сайте http://technet.oracle.com.

Как только служба OID будет сконфигурирована, можно приступать к вводу в этот каталог имен сетевых служб. Для этого применяется несколько методов. Проще всего добавлять имена служб в Oracle Net Manager, если записи добавляются индивидуально, или же импортировать в OID весь файл tnsnames.ora, используя Oracle Enterprise Manager.

Suppose you have known the usage of TNSNAMES, now let’s see where we can find it in this post.

In fact, the location of tnsnames.ora depends on what platform you use. Here we introduce two major platforms: Windows and Linux.

1. tnsnames.ora in Windows OS

For Windows OS, the location of tnsnames.ora file is usually at:

%TNS_ADMIN%tnsnames.ora

Problem is, there’s no TNS_ADMIN environment variable in most database systems by default. However, you can use ORACLE_HOME to derive it.

%TNS_ADMIN% = %ORACLE_HOME%networkadmin

Therefore, the location of tnsnames.ora is usually at:

%ORACLE_HOME%networkadmintnsnames.ora

But first of all, you have to know where ORACLE_HOME is in Windows OS before finding the file.

Let’s see an example.

If there’s no tnsnames.ora, please copy one in sample folder for yourself.

2. tnsnames.ora in Linux and Unix-liked OS

For Linux and Unix-like OS, the location of tnsnames.ora file is at:

$ORACLE_HOME/network/admin/tnsnames.ora

Again, you have to know where ORACLE_HOME is in Linux before finding the file.

How the Oracle Client finds TNSNames.ora

Most Oracle Client installs use a TNSNames.ora file. This allows users to enter a database alias in client programs
to connect to an Oracle database. A common problem is when the Oracle Client either can’t find the TNSNames.ora
file or is using a different one than was intended.

Default location

The default location of the TNSNames.ora file is «ORACLE_HOMEnetworkadmintnsnames.ora», where ORACLE_HOME is the
directory which contains your primary Oracle Home installation. This could be something like
«C:Oracle12networkadmintnsnames.ora».

Forcing the Oracle Client to use a particular TNSNames.ora file

If you use TNSNames.ora it is recommended to use either an environment variable or a registry setting to force the
location of the file. This setting is called TNS_ADMIN and is set to the directory/path of the tnsnames.ora
file (but should not contain the filename, just the path to it.)

TNS_ADMIN can be set in a number of different ways, but Oracle will use the following precedence:

1. Local session environment variable.
2. Global environment variable.
3. User registry setting under HKey_Current_UserSoftwareOracle (or individual Oracle home registry entry.)
4. System registry setting under HKey_Local_MachineSoftwareOracle (or individual Oracle Home registry entry.)

Possible Problems

One possible problem (and this comes up surprisingly often!) is that the Oracle Client will first check if the current
application directory contains tnsnames.ora. The current application directory can be initially set in the startup icon
options for a program, or programs often keep track of the last used document directory. It is a good idea to not keep
copies of tnsnames.ora in default program directories or document directories so as not to have the Oracle Client
accidentally use it instead of the intended tnsnames.ora file.

Home » Articles » Misc » Here

In its most basic form, Oracle uses three files (listener.ora, tnsnames.ora & sqlnet.ora) for network configuration. This article gives an example of each file as a starting point for simple network configuration.

• Assumptions
• listener.ora
• tnsnames.ora
• sqlnet.ora
• Testing
• Common Problems

Assumptions

The example files below are relevant for an Oracle installation and instance with the following values.

• HOST : myserver.example.com
• ORACLE_HOME : /u01/app/oracle/product/11.2.0.4/db_1
• ORACLE_SID : orcl
• Service : orcl
• DOMAIN : example.com

listener.ora

The «listerner.ora» file contains server side network configuration parameters. It can be found in the «$ORACLE_HOME/network/admin»
directory on the server. Here is an example of a basic «listener.ora» file from Linux. We can see the listener has the default name of «LISTENER» and is listening for TCP connections on port 1521. Notice the reference to the hostname «myserver.example.com». If this is incorrect, the listener will not function correctly.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1)) 
      (ADDRESS = (PROTOCOL = TCP)(HOST = myserver.example.com)(PORT = 1521))
    )
  )

After the «listener.ora» file is amended the listener should be restarted or reloaded to allow the new configuration to take effect.

$ # Restart
$ lsnrctl stop
$ lsnrctl start

$ # Or Reload.
$ lsnrctl reload

The listener defined above doesn’t have any services defined. These are created when database instances auto-register with it. In some cases you may want to manually configure services, so they are still visible even when the database instance is down. If this is the case, you may use a «listener.ora» file like the following.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1)) 
      (ADDRESS = (PROTOCOL = TCP)(HOST = myserver.example.com)(PORT = 1521))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = orcl.example.com)
      (ORACLE_HOME = /u01/app/oracle/product/11.2.0.4/db_1)
      (SID_NAME = orcl)
    )
  )

If there are multiple database instances on the server, you can added multiple SID_DESC entries inside the SID_LIST section.

tnsnames.ora

The «tnsnames.ora» file contains client side network configuration parameters. It can be found in the «$ORACLE_HOME/network/admin» directory on the client. This file will also be present on the server if client style connections are used
on the server itself. Here is an example of a «tnsnames.ora» file.

LISTENER = (ADDRESS = (PROTOCOL = TCP)(HOST = myserver.example.com)(PORT = 1521))

orcl.example.com =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = myserver.example.com)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = orcl)
    )
  )

The alias used at the start of the entry can be whatever you want. It doesn’t have to match the name of the instance or service. Notice the PROTOCOL, HOST and PORT match that of the listener. The SERVICE_NAME can be any valid service presented by the listener. You can check the available services by issuing the lsnrctl status or lsnrctl service commands on the database server. Typically there is at least one service matching the ORACLE_SID of the instance, but you can create more.

sqlnet.ora

The «sqlnet.ora» file contains client side network configuration parameters. It can be found in the «$ORACLE_HOME/network/admin» directory on the client. This file will also be present on the server if client style connections are used on the server itself, or if some additional server connection configuration is required. Here is an example of an «sqlnet.ora» file.

NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)
NAMES.DEFAULT_DOMAIN = example.com

# The following entry is necessary on Windows if OS authentication is required.
SQLNET.AUTHENTICATION_SERVICES= (NTS)

There are lots of parameters that can be added to control tracing, encryption, wallet locations etc. These are out of the scope of this article.

Testing

Once the files are present in the correct location and amended as necessary the configuration can be tested using SQL*Plus
by attempting to connect to the database using the appropriate username (SCOTT), password (TIGER) and service (orcl.example.com).

$ sqlplus scott/tiger@orcl.example.com

Common Problems

The OS hostname command must return the correct hostname of your database server. If not, fix it so it does.

$ hostname
myserver.example.com
$

The server must have a correct entry in the «/etc/hosts» file matching the hostname and IP address of the server, as well as the loopback entry for localhost. For example in this case the values are as follows.

127.0.0.1      localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.0.123  myserver.example.com  myserver

If these are provided by DNS, that is fine also.

If you are using the ORACLE_HOSTNAME environment variable, possibly set in your «/home/oracle/.bash_profile», it must be set to the correct value.

export ORACLE_HOSTNAME=myserver.example.com

The HOST entry in the «listener.ora» file must point to an active network adapter, either real or loopback. If not, the listener will fail to start.

If the HOST entry in the «listener.ora» file is set to «localhost», the listener will start and accept connections from the local server, but not from other clients. You would typically expect this to be set to the hostname of the database server, although some people use the IP address instead.

For the client to make a connection via the listener, there must be a clear route through the network between the two machines. If you are struggling to connect, check network firewalls and the local firewall (iptables, firewalld, Windows Firewall) on the database server.

For more information see:

• Oracle Database Net Services Administrator’s Guide
  11g Release 2 (11.2)

Hope this helps. Regards Tim…

Back to the Top.