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:
- 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.
- 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.
- 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!
I installed both the 32 and 64-bit Oracle 11g drivers. I search my PC looking for files with the name “tnsnames.ora” and found 3 in the following locations:
1. C:Oracleproduct11203_32bitCLIENT_1NETWORKADMIN
2. C:Oracleproduct11203_64bitCLIENT_1NETWORKADMIN
3. C:WindowsTNS
The existence of the 3rd location of the tnsnames.ora file surprises me.
I have the following Oracle clients installed on my PC:
"C:Program Files (x86)Quest SoftwareToad for Oracle 11.6Toad.exe"
"C:Program FilesDevartdbForge Studio Express for Oracledbforgeoracle.exe"
Based on the location of each program (Program Files (x86) vs. c:Program Files), This suggests to me that the Toad, a 32 bit program, should use the 32 bit driver and dbForge should use the 64 bit driver.
dbForge seems to use either the tnsnames.ora file in either location #2 or #3. I know this by systematically renaming all but one of the tns files and then checking to see if the connection names read from the file are available when trying to create a new connection from with the app.
However, TOAD seems to only recognize the tnsnames.ora file in location #3 and it did not recognize the tnsnames.ora file in location 2 at all! (Being that it was a 32 bit program, I did not expect it to recognize the tns file in location 2 and that was the case). TO summarize the TOAD test for the sake of hopeful clarity, TOAD only recognized the tns file in location 3.
Other colleagues do not have a tns file in location 3 on their machines. I’m not sure why I do. When I run Toad, it shows the following 2 Home, with the 32 bit Home as being the active one.
OraClient11g_home1 (11.2.0.3)
ORACLE_HOME:C:appC39293product11.2.0client_1
ORACLE_HOME_NAME:OraClient11g_home1
ORACLE_HOME_KEY:HKEY_LOCAL_MACHINESOFTWAREORACLEKEY_OraClient11g_home1
ORACLE_SID:
NLS_LANG:AMERICAN_AMERICA.WE8MSWIN1252
SQLPATH:
LOCAL:
Client DLL:C:appC39293product11.2.0client_1oci.dll
TNSNames.ora:
SQLNet.ora:
LDAP.ora:
Login.sql:
GLogin.sql:
In system PATH:No
Home is valid:No
OraClient11g_home1_32bit (11.2.0.3)
ORACLE_HOME:c:oracleproduct11203_32bitCLIENT_1
ORACLE_HOME_NAME:OraClient11g_home1_32bit
ORACLE_HOME_KEY:HKEY_LOCAL_MACHINESOFTWAREORACLEKEY_OraClient11g_home1_32bit
ORACLE_SID:
NLS_LANG:AMERICAN_AMERICA.WE8MSWIN1252
SQLPATH:c:oracleproduct11203_32bitCLIENT_1dbs
LOCAL:
Client DLL:c:oracleproduct11203_32bitCLIENT_1binoci.dll
TNSNames.ora:
SQLNet.ora:
LDAP.ora:
Login.sql:
GLogin.sql:c:oracleproduct11203_32bitCLIENT_1sqlplusadminglogin.sql
In system PATH:Yes
Q1: Is OraClient11g_home1 my 64 bit home or do I have two Oracle clients installed?
Q2: Why doesn’t 32 bit TOAD use the tns in location #1 instead of only using the one in location #3?
Q3: If I leave on the tns file in location 3, both dbForge and TOAD work but I’d like to know why so I can accurately understand how to move tns info from one machine to another.
В ранее приведенных примерах дескрипторов и идентификаторов подключений идентификатор подключения sales служил для подключения к службе sales. Идентификатор подключения может быть самим дескриптором подключения или более простым именем (наподобие sales), вместо которого затем подставляется дескриптор подключения. Обычно используемый простой идентификатор подключения называют именем сетевой службы. Таким образом, идентификатор подключения sales в ранее приведенных примерах является именем сетевой службы.
Поскольку указание полного дескриптора подключения при каждой установке подключения является довольно утомительной задачей, применение имен сетевых служб более целесообразно. Однако для этого потребуется поддерживать центральное хранилище всех соответствий между именами сетевых служб и информацией дескрипторов подключений, чтобы Oracle мог проверять актуальность имен сетевых служб. Таким образом, когда пользователь запускает процесс подключения, указывая имя сетевой службы sales, центральное хранилище ищет дескриптор подключения, соответствующий имени sales. Как только дескриптор подключения найден, Oracle Net инициирует подключение к базе данных на указанном сервере.
Oracle допускает использование нескольких типов хранилищ именования, и доступ к информации преобразования имен, хранящейся в этих хранилищах, можно получить одним из следующих методов именования.
- Метод локального именования. Этот метод для подключения к серверу базы данных использует файл tnsnames.ora, хранящийся на каждом клиенте.
- Метод именования простым подключением. Этот метод допускает подключения без какой-либо конфигурации имени службы.
- Метод внешнего именования. Этот метод использует независимую службу именования для преобразования имен служб.
- Метод каталожного именования. Этот метод использует LDAP-совместимый сервер для преобразования имен служб.
Независимо от применяемого метода именования процесс преобразования имен остается неизменным. Следующие действия понадобится выполнить при использовании любого из методов именования для разрешения дескриптора подключения именем сетевой службы.
- Выберите метод именования — локальный, простое подключение, внешнее именование или именование с помощью службы каталогов.
- Отобразите дескрипторы подключений на имена служб.
- Сконфигурируйте клиенты, чтобы они использовали метод именования, выбранный на первом шаге.
Метод локального именования
Локальное именование — простейший и наиболее легкий способ установки подключения 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 будет искать эти два файла в следующих местах и воспользуется первым из найденных экземпляров.
- В каталоге, указанном в переменной среды TNS_ADMIN.
- Поиск файла tnsnames.ora будет выполняться в глобальном каталоге конфигурации. Для систем UNIX/Linux это обычно каталог /var/opt/oracle.
- В стандартных сетевых каталогах: $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 должным образом модифицирован, подключение к базе данных должно выполняться так, как описано ниже.
- Распространите новую конфигурацию имени службы своим клиентам. Это можно выполнить, копируя файлы tnsnames.ora и sqlnet.ora на компьютеры клиентов, на которых должен присутствовать установленный Oracle Client. В качестве альтернативы, для конфигурирования имен сетевых служб на самом клиенте можно воспользоваться помощником Oracle Net8 Assistant или Net8 Configuration Assistant.
- Удостоверьтесь, что слушатель запущен на том сервере, где действует база данных. Проверьте, что слушатель использует тот же протокол и адрес, которые были сконфигурированы для имени сетевой службы в файле tnsnames.ora. Убедитесь также, что слушатель использует протокол TCP/IP и прослушивает заданный по умолчанию порт 1521.
- Удостоверьтесь, что целевая база данных, к которой вы пытаетесь подключиться, действует.
- Протестируйте новое подключение с помощью следующей команды:
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, нужно выполнить следующие действия.
- Запустите на сервере UNIX/Linux помощник Net Configuration Assistant с помощью команды netca, как показано в следующем примере:
$ export DISPLAY=172.16.14.15:0.0 $ netca
На заметку! В системе Windows помощник NCA запускается выбором команды меню StartProgramsOracle-HOME_NAMEConfiguration and Migration Tools (ПускПрограммыИмя домашнего каталога OracleСредства конфигурирования и переноса).
- Откроется страница Welcome (Приветствие). Выберите опцию Local Net Service Name Configuration (Локальная конфигурация имен сетевых служб) и щелкните на кнопке Next (Далее).
- На странице Net Service Name Configuration (Конфигурация имен сетевых служб) выберите опцию Add (Добавить) и щелкните на кнопке Next.
- На странице Service Name Configuration (Конфигурация имен служб) введите имя службы, которую необходимо сконфигурировать. В данном примере это база данных emrep.netbsa.org. Обратите внимание, что в общем случае имя службы совпадает с глобальным именем базы данных. Щелкните на кнопке Next.
- На странице Select Protocol (Выберите протокол) выберите протокол TCP и щелкните на кнопке Next.
- На странице TCP/IP Protocol (Протокол TCP/IP) введите имя хоста, на котором действует база данных. Выберите стандартный номер порта, 1521, и щелкните на кнопке Next.
- На странице Test (Тестирование) щелкните на кнопке Yes, Perform a Test (Да, выполнить тестирование), а затем щелкните на кнопке Next.
- NCA предпримет попытку подключения к базе данных с применением новой конфигурации и отобразит результаты. В случае неудачи подключения удостоверьтесь, что слушатель целевой базы данных запущен, а сочетание имени пользователя и пароля, по умолчанию используемое процессом тестирования (system/manager), изменено на действующее сочетание. Убедитесь также, что имена базы данных и домена указаны правильно.
- Затем на странице Net Service Name (Имя сетевой службы) NCA попросит подтвердить имя сетевой службы. Щелкните на кнопке Next.
- На странице Another Service Name (Имя другой службы) можно сконфигурировать дополнительные имена служб.
- На странице 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 подключаются к базе данных следующим образом.
- Лицо, которое желает выполнить подключение, вводит на клиентском компьютере свое обычное сочетание имени пользователя/пароля и идентификатор соединения.
- Файл sqlnet.ora на компьютере клиента указывает, что он использует OID для преобразования имен, поэтому клиент Net Services передает свой запрос процессу слушателя/диспетчера OID.
- Слушатель/диспетчер OID передает запрос LDAP серверу каталогов Oracle.
- Сервер каталогов подключается к базе данных OID и преобразует идентификатор соединения в соответствующий дескриптор соединения, который содержит информацию о сети, сервере и протоколе. Затем он отправляет эту подробную информацию дескриптора соединения клиенту Net Services.
- Клиент отправляет полученный дескриптор соединения службе слушателя Oracle Net Listener (или диспетчеру, если используются разделяемые серверы).
- Служба слушателя принимает запрос на подключение и, после его проверки, пересылает базе данных.
Организация 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.
Вас заинтересует / Intresting for you:
Сеть это неотъемлемая часть клиент-серверной архитектуры, которая является фундаментальное составляющей всех современных баз данных. У БД Oracle была возможность для клиент-серверных вычислений с самого начала (версия 1, выпущенная в 1978 году использовала разделение между кодом Oracle и пользовательским кодом), но только в версии 4 в 1984 году Oracle представила разделение между компьютером пользователя и сервером. Настоящая поддержка клиент-серверной архитектуры наступила с версией 5 в 1986 году. В это главе мы рассмотрим сервис Oracle Net, который раньше назывался Sqlnet и некоторые DBA до сих пор используют это название.
По умолчанию Oracle Net настроена как выделенный сервер (dedicated server). В такой конфигурации каждому пользовательскому процессу, подключенному к БД, будет создаваться свой серверный процесс. Альтернативой этой конфигурации является конфигурация разделяемого сервера (shared server), где все пользовательские процессы используют фиксированный набор серверных процессов, разделяемых между пользовательскими сессиями. DBA неохотно используют shared server архитектуру, однако знание это конфигурации необходимо.
Oracle Net – это технология позволяющая использовать клиент-серверную архитектуру Oracle. Это механизм для установки сессии с экземпляром БД. Существует несколько программ, которые могут быть использованы для настройки и управления Oracle Net, хотя можно настроить всё используя только текстовый редактор. Каким бы инструментом вы не пользовались, результатом всё равно будет набор файлов, которые управляет процессом запуска сессий listener-ом при получении пользовательского запроса и определяет каким-образом пользовательскией процесс находит listener.
Содержание
- 1 Oracle Net и клиент-серверная парадигма
- 2 Установка соединения (создание сессии)
- 3 Подключение к локальному экземпляру
- 4 Определение имени (Name resolution)
- 5 Запуск серверного процесса
- 6 Создание listener-а
- 7 Регистрация БД
- 8 Статическая регистрация
- 9 Динамическая регистрация
- 10 Методы определения имени
- 11 Easy connect
- 12 Local Naming
- 13 Directory Naming и External Naming
- 14 Программа управления listener-ом
- 15 Настройка псевдонимов сервисов (alias)
- 16 Имена файлов и системная переменная TNSADMIN
- 17 Ссылки базы данных
Oracle Net и клиент-серверная парадигма
Пользователя и базу данных разделяет множество уровней. В окружении Oracle ни пользователи не имеют прямого доступа к базе данных, ни пользовательские процессы. Клиент-серверная архитектура гарантирует что любой доступ к БД контролируется сервером.
Пользователь взаимодействует с пользовательским процесс: это приложение которое запущено на локальной машине. Например Microsoft Acces и ODBC Driver, либо приложение написанное на C и использующее OCI библиотеки или SQL *Plus. Какое бы это ни были приложение, назначение пользовательского процесса одинаковое – позволить пользователю вводить информацию, которую приложение может использовать для генерации SQL запросов. В случае SQL *Plus пользовательский процесс будет просто ждать ввода запроса — более продвинутые инструменты могут отображать свойства объектов БД, генерировать и валидировать SQL команды, в любом случае будет сформирован SQL запрос, который передаётся серверному процессу.
Серверный процесс работает на сервере базы данных и выполняет запросы, полученные от пользовательского процесса. Это базовое клиент-серверное разделение: пользовательский процесс создаёт SQL, серверный процесс выполняет. Выполнение SQL запроса происходит в четыре этапа: разбор (parse), связывание (bind), выполнение (execute) и выборка(fetch). На этапе разбора сервер определяет валиден ли запрос, какие объекты используются и как выполнить запрос максимально быстро. Разбор использует shared pool: стурктуры памями используются для преобразования SQL в исполняемый код. На этапе связсывания – все переменные преобразуются в литералы. Этап выполнения будет использовать SGA и возможно саму базы данных. Во время выполнения данные в буфере кэша будет считываться или обновляться, изменения записываться в буфер логов, и если необходимых блоков нету в буфере серверный процесс считает их из файлов данных. Это единственный момент времени при выполнении запроса когда используется сама база данных. И, наконец, на этапе выборки серверный процесс отправит результирующий набор данных полученный в результате выполнения запроса назад пользовательскому процессу, и пользовательский процесс преобразует результат для отображения.
Oracle net предоставляет механизм для запуска серверного процесса, который будет выполнять код от имени пользовательского процесса. Этот механизм называют установкой сессии. Также Oracle Net используется для поддержки сессий: передачу SQL запросов от пользовательского процесса к серверному, и получение результатов выполнения запросов от сервеного процесса к пользовательскому.
На рисунке 4-1 отображены компоненты сессии. Пользователь взаимодействует с пользовательским процессом, пользовательский процесс в свою очередь взаимодействует с серверным процессом используя Oracle Net; серверный процесс работает с экземпляром БД и экземпляр при помощи фоновых процессов работает с базой данных. Клиен-серверное разделение осуществляется между пользовательским процессом создающим SQL запросы и серверным процессом выполняющим их. Это разделение обычно будет и физическим, так же как логическим: обычно серверные и клиентские машины соединены с помощью локальной сети, так же они могут соединяться с помощью сети интернет или вообще работать на одной физической машине. Oracle Net отвечает за установку соединения (создание сессии) и все взаимодействие между серверным и пользовательским процессом.
Установка соединения (создание сессии)
Когда пользователь хочет подключиться к БД используется команда вида
CONNECT STORE/ADMIN123@ORCL11G
Конечно если используется инструмент с графическим интерфейсом вы не будете писать такую команду, ваше приложение просто спросит все необходимые данные для подключения и команда будет сгенерирована пользовательским процессом. Разберём эту команду. Вначале идёт имя базы данных (STORE) и пароль (ADMIN123) разделённые символом “/”. Затем идёт символ “@” после которого строка подключения “ORCL11G”. Символ “@” является идентификатором для пользовательской сессии указывающим что сетевое подключение необходимо. Если пропустить этот символ и не указывать строку подключения, тогда пользовательский процесс преполагает что экземпляр к которому вы хотите подключиться запущен на локальной машине и он всегда доступен с помощью IPC протокола. Если символ “@” и строка подключения указаны, тогда пользовательский процесс будет использовать сетевое подключение для работы с удаленной машины – хотя фактически, сервер может быть той же локальной машиной и вы будете посылать запрос и принимать одной и той же сетевой картой локальной машины.
Подключение к локальному экземпляру
Даже когда вы подключаетесь к экземпляру работающему на локальной машине, вы всё равно используете Oracle Net. Все сессии используют сетевой протокол для разделения пользовательского когда от серверного, но для локального подключения этим протоколом будет IPC: это протокол предоставляемый операционной системой который пользоляет «общаться» процессам работающим на одной машине. Это единственный вид подключения который не требудет listener-а; более того, локальное подключение не требует никакой настройки. Единственная информация которая нужна пользовательскому процессу для подключения, это к какому экземпляру БД вы хотите подключиться. Нужно помнить что могут работать несколько экземпляров на одном компьютере. Эту инфомрацию процесс получает из системных переменных. На рисунке 4-3 показан пример подключения в системе Linux, а на рисунке 4-3 отображено как подключиться к локальной базе данных в Windows
Единственным отличием будет метод установки системных переменных.
Определение имени (Name resolution)
Когда происходит попытка подключения используя Oracle Net, первым делом необходимо определить куда конкретно вы хотите подключиться. Это процесс определения имени. Если команда CONNECT содержит строку подключения “@orcl11g”, Oracle Net необходимо понять что значит “orcl11g”. Строка должна быть преобразована в определённую информацию: протокол, который будет использоваться (предположим TCP), IP адресс на котором запущен listener, порт используемый listener-ом и имя экзкмпляра БД к которому вы хотите подключиться. Можно использовать разные строки подключения: к примеру вместо IP адреса в строке подключения может указываться имя хоста, которое затем определяется в IP адресс используя DNS сервер. Вместо указания имени экземпляра может быть указано имя сервиса, которое (в RAC архитектуре) может обслуживать несколько экземпляров. В single-instance архитектуре тоже могут использоваться сервисы – к примеру для отслеживания нагрузки на базу данных разными группами пользователей. Вы можете насторить разные механизмы выделения адреса сервера и имени экземпляра из строки подключения, но так или иначи процесс определения имени должен давать пользовательскому процессе достаточно информации для нахождения listener-а и создания запроса к экземпляру.
Запуск серверного процесса
Listener базы данных, работающий на сервере, использует один или несколько протоколов для мониторинга одного или нескольких портов на одном или нескольких сетевых интерфейсах в ожидании входящих запросов на подключение. Вы можете запустить несколько listener-ов на одном сервере, а также один listener может принимать запросы на подключение для нескольких экзмепляров. Когда listener получает запрос на подключение, вначале он должен проверить доступен ли запрашиваемый экземпляр. Если экземпляр доступен, listener запустит сервеный процесс для обслуживания пользовательского процесса. Таким образом, если к вашей базе данных подключено одновременно тысяча пользователей – на сервере будет работать тысяча серверных процессов. Такая конфигурация называется архитектура выделенного сервера (dedicated server architecture). Существует возможность использования другой конфигурации, когда пользовательские сессии обслуживаются выделенным процессом диспетчером (dispatcher process), но серверные процессы разделяются между пользовательскими сессиями. Эта архитектура называется общий сервер (shared server).
При использовании TCP протокола, каждому серверному процессу запущенному listener-ом присваивается уникальный номер TCP порта. Это значение устанавливается во время запуска процесса согласно алгоритму маппинга портов вашей операционной системы. Номер порта возващается пользовательской сессии и теперь пользоватеский процесс может работать напрямую с выделенным ему серверным процессом. На этом этапе listener заканчивает свою работу и ожидает других запросов на подключение. Таким образом если listener не запущен – то вы не сможете установить подключение, однако существующие подключения могут продолжать работу.
Создание listener-а
Listener определяется в файле listener.ora который по умолчанию находится в папке ORACLE_HOME/network/admin. Как минимум файл listener.ora должен содержать информацию об одном listener-e, включая имя listener-а, протокол и адресс. Вы можете настроить несколько listener-ов в одном файле, однако все они должны иметь уникальное имя и адресс.
Как идругие файлы для настройки Oracle Net, файл listener.ora очень привередливый к синтаксису. Важны регистр букв, количество пробелов и аббревиатуры. Поэтому многие DBA не любят редактировать файл самостоятельно (несмотря на то что ничего не мешает это делать вручную). Oracle предоставляет три программы для управления Oracle Net: это Enterprise Manager, Net Manager и Net Configuration Assistant. Оба последних написаны на Java. Функционал этих программ сильно пересекается, однако есть некоторые вещи, которые можно сделать в одной программе, но нельзя в другой и наоборот.
Ниже представлен пример файла listener.ora
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1)(PORT = 1521))
)
LIST2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1522))
(ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1.bplc.co.za)(PORT = 1522))
)
)
В первой секции описан listener с именем LISTENER, который использует локальное имя хоста на порту по умолчанию, 1521. Во второй секции определён второй listener с именем LIST2. Он мониторит порт 1522 также на локальном имене хоста и адресе замыкания (loopback/127.0.0.1).
Для создания listener-а всё что нужно сделать это добавить запись в файл listener.ora и запустить его выполнив команду lsnrctl. В ОС Windows listener будет работать как сервис, но нет нужды создавать его вручную. Он будет создан при первом запуске listener-а. Затем вы можете запускать и останавливать его как обычный сервис windows.
На рисунке 4-4 показана настройка listener-а LIST2 используя Net Manager, а на рисунке 4-5 тот же listener в окне Net Configuration Assistant.
В Net Manager вы можете настроить несколько адресов для мониторинга, а в Net Configuration Assistant нет: он работает только с локальным именем хоста.
Регистрация БД
Listener должен создать серверный процесс для экземпляра БД. Для этого listener должен знать какие экземпляры доступны на компьютере где он запущен. Listener находит информацию об экземплярах в процессе «регистрации». Используя single-instance архитектуру – listener и экземпляр должны быть запущены на одной машине. RAC пользоляет любому listener-у подключаться к любому instanсe в кластере.
Существует два метода регистрации экземпляров БД: статическая и динамическая регистрация. Для статической регистрации вы пишете список эезмепляров в файле listener.ora. Динамическая регистрация обозначает что экземпляр во время запуска, находит listener и регистрируется сам.
Статическая регистрация
Использование динамической регистрации предпочтительно, однако может возникнуть ситуация когда вам придёстя использовать статическую. Динамическая регистрация появилась с версии 8i, и если вам надо настроить listener для подключения к таким БД, то вам придётся регистрировать их статически. Также некоторые приложения требуют статическую регистрацию, в основном приложения для управления. Для статической регистрации экземпляра необходимо создать соответствующую запись в файле listener.ora.
В данном примере запись SID_LIST_LIST2 позволит listener-у с именем LIST2 принимать запросы на подключения к экземпляру с именем ocp11g. Это не значит что instance работает или даже существует. Значение ORACLE_HOME необходима только если listener запускается из домашней директории Oracle отличной от экземпляра. Этот путь используется для поиска исполняемого файла который выполняется для запуска серверного процесса. Обычно это используется при настройке listener-а дял разных версий Oracle, установленных в разные домашние директории.
Динамическая регистрация
Этот метод регистрации является предпочтительным, когда экземпляр регистрирует себя у listener-а. Инилизационный параметр local_listener указывает экземпляру на сетевой адресс который необходимо использовать для поиска и регистрации у listener-а. Во время запуска экземпляра, процесс PMON использует данный параметр для поиска listener-а и информирует его о имени экземпляра и сервисе(ах) которые запускает экземпляр. Имя экземпляра определено в параметре instance_name, а параметр service_names при остутствии значения составляется из параметров instance_name и db_domain (db_domain по умолчанию пустое значение). Возможно создавать и запускать дополнительные сервисы в любое время как изменяя значение параметра service_name (перечисляя через запятую) либо используя пакет DBMS_SERVICE.
Любые изменения должны быть зарегистрированы. Если этого не сделать то listener не будет знать что доступен новый сервис, и не сможет установить соединение. Процесс PMON регистрирует изменения автоматически один раз в минуты, но вы в любое время можете запустить процесс регистрации выполнив команду ALTER SYSTEM REGISTER;
Динамическая регистрации предпочтительнее, так как она позволяет быть увереным что только запущенные экземпляры и доступные сервис зарегистрированы у listener-а и нет ошибок в именах. Очень легко допустить ошибку если вы к примеру редактируете файл listener.ora вручную. Также когда экземпляр останавливается, он автоматически отменить регистрацию.
Начиная с версии 9i динамическая регистрация может не требовать конфигурации совсем, если ваш listener работает используя порт по умолчанию (1521). Все экезмпляры автоматически пытаются найти listener на локальной машине используя порт по умолчанию и в случае успеха – зарегистрироваться у этого listener-а. Если listener не доступен на локальной машине используя порт по умолчанию, вы должны установить где находится listener и перерегистрироваться. Например:
alster system set local_listener=list2;
alter system register;
В данном примере listener указывается используя имя. Это имя необходимо преобразовать в адресс и порт. Однако можно использовать сразу настройки в значении параметра. Например
alter system set local_listener='(address=(protocol=tcp)(host=127.0.0.1)(port=1522))’;
Использование такого значения допускается, однако лучше всё-таки использовать имя, которое настраивается в файле: так как появляется уровень абстракции между именем и физическим адресом. Если адресс listener-а изменится, вы должны сделать изменения в одном месте, а не менять параметры в каждом экземпляре использующим этот listener.
Методы определения имени
Вначале главы мы использовали строку подключения для установления сессии. Эта строка преобразуется в адресс машины где запущен listener и имя экземпляра или сервиса. При динамической регистрации логическое имя listener-а тоже преобразуется в сетевой адресс для регистрации. Доступно четыре метода для преобразования имени: easy connect, local naming, directory naming и external naming. Большинство установок использует local naming, но для сложной и большой системы предпочтительно использовать directory naming.
Easy connect
Метод easy connect был представлен в версии 10g. Его очень использовать – он не требует настройки. Но доступен при использовании только одного протокола: TCP. Остальные методы могут работать с любыми поддеживаемыми протоколами. Easy connect не может использовать дополнительные возможности Oracle Net, такие как балансировка нагрузки или поддержка сетевой маршрутизации. Этот метод часто используется DBA но для пользователей он не сильно удобен. Пример подключения
connect store/admin123@jwlnxl.bplc.co:1522/ocp11g
В этом примере пользовательский процесс использя TCP протокол подключится к порту 1522 по IP адрессу определённому из имени хоста. Если listener запущен на этом порту этого сервера – пользовательский процесс запроси listener создать серверный процесс на instance ocp11g. Можно ещё упростить эту команду
connect store/admin123@ jwlnxl.bplc.co
Такая команда сработает только если listener запущен на порту 1521 и имя сервиса совпадает с именем хоста jwlnxl.bplc.co
Local Naming
Используя эту технику пользователь использует псевдоним (Oracle Net service alias) в строке подключения, а псевдоним преобразуется в сетевой адресс, протокол, сервис или имя экземпляра с помощью локального файла. Этот файл и есть пресловутый tnsnames.ora, который доставил много горя DBA. Рассмотрим пример файла tnsnames.ora
ocp11g =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1.bplc.co.za)(PORT = 1522))
)
(CONNECT_DATA =
(service_name = ocp11g)
)
)
test =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = serv2.bplc.co.za)(PORT = 1521))
)
(CONNECT_DATA =
(sid = testdb)
)
)
Этот файл содержит два Oracle Net Service alias: ocp11g и test. Эти псевдоним и есть то, что будут использовать пользователи в строке подключения. Первый псевдоним ocp11g указывает на то, что если в строке подключения найдено «@ocp11g», то пользовательский процесс по протоколу TCP, порту 1522 подключится к машине jwlnx1.bplc.co.za и попросит listener создать сессию для экземпляра с названием сервиса ocp11g. Второй алиас test направит пользовательские процессы по другому адресу, порту и сессии будут создаваться для экземпляра testdb.
Метод local naming поддерживает все протоколы и возможность Oracle Net, но управление файлами tnsnames.ora на клиентских машинах может быть задачей, занимающей очень много времени. Также tnsnames.ora файл очень чувствителен к ошибкам синтаксиса. Использование графических программ поможет избегать этих ошибок.
Directory Naming и External Naming
Метод Directory Naming направляет пользовательскую сессию к серверу LDAP для определения псевдонима. LDAP – это широко распространённый стандарт, которого придерживается Oracle и другие производители ПО. Для использования directory naming метода, вначале вам нужно установить и настроить LDAP сервер на каком либо сервере в вашей сети. Oracle предоставляет LDAP сервер ( Oracle Internet Directory) как часть Oracle Application Server, но необязательно использовать именно его. Если у вас уже есть установленный и настроенный к примеру сервер с Microsoft Active Directory – вы можете использовать его.
Как и local naming, метод directory naming поддерживает все возможности Oracle Net – но вместо поддержки файлов tnsnames.ora разбросанных по всей сети, используется централизованное хранилище, что несомненно гораздо легче сопровождать.
External Naming отличается от directory naming только тем, что использует отдельный сервис вместо LDAP – Sun Network Information Services (NIS+) или Cell Directory Services (CDS).
Программа управления listener-ом
Можно запускать и останавливать listener через Database Control, но существует так же консольная программа lsnrctl (или lsnrctl.exe в Windows). Утилита lsnrctl может запускаться через командную строку ОС или через простой графический интерфейс. Для всех команд вы должны указать имя listener-а, если не используется имя по умолчанию LISTENER. На рисунках 4-6 и 4-7 показано как проверить статус listener-а, запустить и остановить его путём вызова команд из командной строки операционной системы или с помощью графического интерфейса.
Необходимо отметить что комнда status всегда отображает адрес по которому listener принимает запросы на подключение, а также имя и местонахождение файла listener.ora, в котором прописан listener и имя и местонахождение файлов логов listenera. На рисунках ниже также видно что listener LIST2 “supports no services”. Это отображается так как не было статически зарегистрировано сервисов и ни один экземпляр БД ещё не зарегистрировался динамически для этого listener-а. На рисунке 4-8 отображено состояние listener-а после динамической регистрации экземпляра БД.
На рисунке 4-8 результат выполнения команды status показывает нам, что listener с именем LISTENER поддерживает три сервиса, доступных для экземпляра БД orc11g:
- Сервис orcl11g.jwlnx1.bplc.co.za это обычный сервис БД. Listener может запустить выделенную серверную сессию для работы (ещё ни одной сессии не создано)
- Сервис orcl11gXDB.jwlnx1.bplc.co.za – это сервис для работы с БД основанный на XML. Данный сервис позволяет подключаться к БД используя протоколы отличные от Oracle Net, к примеру FTP и HTTP
- Сервис orcl11g_XPT.jwlnx1.bplc.co.za – это сервис для работы Dataguard.
По умолчанию экземпляры БД версии 11g регистрируют сервисы XDP и XDT, но они не могут использоваться без дополнительной настройки. Эти сервисы отображаются как “status ready” и это обозначает что они были автоматически зарегистрированы процессом PMON: listener знает что они доступны так как PMON при динамической регистрации указал это. Если бы сервисы были зарегистрированы статически, они бы отображались со статусом “status unknown”. Т.е. сервисы прописаны в файле listener.ora, но могут быть не запущены.
Для просмотра всех доступных команд программы lsnrctl используйте команду HELP
Назначение команд описано ниже
- START запуск listener-а
- STOP остановка listener-а
- STATUS просмотр состояния listener-а
- SERVICES отобразить сервисы доступны listener-у (более детальная информация чем в команде STATUS)
- VERSION отобразить версию listener-а
- RELOAD перечитать файл ora
- SAVE_CONFIG сохранить изменения в файл listener.ora
- TRACE разрешить трассировку деятельности listener-а
- CHANGE_PASSWORD установить пароль для администрирования listener-а
- QUIT выйти из программы без сохранения
- EXIT выйти из программы сохранив изменения
- SET установить значения параметров, таки как примеру время ожидания ответа
- SHOW отобразить значения установленных параметров
Настройка псевдонимов сервисов (alias)
Выбрав метод определения имени, следующей задачей становится настройка клиентских программ для использования этого метода. Вы можете использовать Database Control, но так как это серверный процесс – вы сможете настроить только программы, которые будут запускаться на том же сервере что и БД. Для настройки можно использовать Net Manager. Это отдельное приложение написанное на языке Java, поставляемое Oracle со всеми клиентскими программами.
Для запуска приложения в среде Unix запустите команду netmgr. В Windows вы можете найти эту программу в меню Пуск.
В дереве навигации доступны три ветки. Ветка Profile используется для установки параметров, которые могут применяться и на серверной и на клиентской стороне Oracle Net и которые могут влиять на поведение все сессий. Ветка Service naming используется для настройки определения имени на клиентской стороне, и ветка Listeners используется для настройки listener-ов БД.
Когда вы выбираете ветку Profile как показано на рисунке 4-9, фактически вы работаете с файлов sqlnet.ora. Этот файл создаётся по умолчанию в папке ORACLE_HOME/network/admin. Он не обязателен, так как для всех параметров доступны значения по умолчанию, но обычно вы будете использовать эту ветку для указания метода определения имени.
Выбрав ветку Profile, вы увидите доступные методы определения имени и три (TNSNAMES, EZCONNECT и HOSTNAME) выбраны по умолчанию: это и есть local naming, easy connect и host naming. External naming указаны как CDS и NIS. LDAP – это directory naming. Host naming это эквивалент Easy Connect и он существует только для обратной совместимости.
Затем вы должны настроить псевдонимы сервисов Oracle Net. Это можно сделать в ветке Service Naming, что фактически создает или изменяет файл tnsnames.ora (по умолчанию местонахождения файла ORACLE_HOME/network/admin). Если у вас настроен метод Directory Naming тогда вам не нужно редактировать ветку Service Naming – достаточно выбрать LDAP в ветке Profile. Пример записи в файле tnsnames.ora показан ниже
OCP11G =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = jwacer.bplc.co.za)(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE_NAME = ocp11g)
)
)
Если пользователь использует “ocp11g” в строке подключения то эта запись используется для отсылки запроса к listener-у по адресу jwacer.bplc.co.za на порт 1521 для создания сессии к экземпляру доступному через сервис ocp11g. Для подключения с помощью этого псведонима достаточно выполнить команду
sqlplus system/oracle@ocp11g
Используя Easy Connect команда выглядела бы
sqlplus system/manager@ jwacer.bplc.co.za:1521/ocp11g
Для проверки строки подключения можно использовать команду TNSPING. Эта программа принимает строку подключения как параметр, находит файлы Oracle Net, преобразует строку подключения и отправляет запрос к listener-у. Если listener запущен и запрашиваемый сервис зарегистрирован – программа отобразит упешный результат теста. Ниже показан пример работы программы TNSPING
Обратите внимание что результатом команды является имя использованного файла sqlnet.ora, имя метода определения имени и сведения о адресе и порте используемого для теста. Этот инструмент проверяет только listener, т.е. экземпляр может и не быть запущенным.
Имена файлов и системная переменная TNSADMIN
Используется три важных файла для настройки Oracle Net:
- listener.ora файл на стороне сервера, определяющий listener-ы БД. Влючает в себя сведения о протоколе, адресах и портах, используемых listener-ом для ожидания запросов на подключения. А также может содержать информацию о статических зарегистрированных экземплярах БД.
- tnsnames.ora – файл со стороны клиента используемый для определения имени. Используется пользовательским процессом для нахождения listener-ов БД.Также может быть использован самим экземпляром БД для нахождения listener-ов для динамической регистрации.
- sqlnet.ora – файл необязательный, может существовать (и даже с разными значениями) как на клиентской, так и на серверной стороне. Содержит настройки которые могут применяться ко всем сессиям к listener-ам, такие как настройки безопасности и шифрования.
Все три файла по умолчанию находятся в папке ORACLE_HOME/network/admin. Можно изменить путь к ним с помощью системной переменной: TNS_ADMIN. Эта переменная часто используется если сущуствует несколько домашних директорий Oracle. У обычного сервера Oracle будет как минимум три домашних директории Oracle: одна для Enterprise Manager Grid Control Agent, одна для запуска экземпляров и одна для запуска экземпляров ASM (Automatic Storage Management). На клиентских машинах также может быть несколько домашних директорий Oracle, например для клиентов Oracle 10g и Oracle 11g. Установка переменной TNS_ADMIN как указатель на папку одной из домашних директорий (или вообще внешнюю папку) означает, что вам, вместо того чтобы настраивать файлы в двух разных папках, можно будет настраивать файлы в одной папке. Чтобы установить эту переменную в Windows для какой-либо сессии вы можете выполнить команду
set NTS_ADMIN=C:oraclenet
Но лучше устанавливать значение этой переменной в регистре.
В Unix и Linux синтаксис может отличаться в зависимости от исползуемой оболочки, но обычно выглядит примерно так
set TNS_ADMIN=/u01/oracle/net; export TNS_ADMIN
Эту команду можно добавить в файл профила каждого пользователя, или в /etc/profile для всех пользователей.
На рисунке 4-10 показан процесс обработки пользовательского запроса. Пользователь инициирует создание подключения к серверу указывая имя пользователя, пароль и строку подключения. Если строка подключения отсутствует, клиент Oracle Net пробует использовать системную переменную ORACLE_SID как значение для строки подключения по умолчанию. Если это значение не установлено – обычно происходит ошибка. Если строка подключения указала, клиент Oracle Net пробует выяснить какой метод использовать дря преобразования строки подключения и для этого необходим файл sqlnet.ora, который может находиться в папке определённой в TNS_ADMIN переменной или ORACLE_HOME/network/admin. Если не установлены ни TNS_ADMIN ни ORACLE_HOME – возвращается ошибка.
Обычно в файле sqlnet.ora находится параметр NAMES.DIRECTORY_PATH, в которой перечислены в порядке предпочтения различные методы определения имени, такие как TNSNAMES, LDAP и EZCONNECT. Если TNSNAMES в списке указан первым, Oracle Net пробует найти файл tnsnames.ora опять же либо в директории указанной в переменной TNS_ADMIN либо в ORACLE_HOME/network/admin. Если файл найден, он используется для преобразования строки подключения в сетевой адрес обычно вида имя хоста:порт:sid или хоста:порт:имя сервиса.
Наконец клиент Oracle Net готов к установке соединения для пользовательского процесса который ициниировал запрос на подключение к БД. Если в строке подключения присутствует символ “@”, тогда происходит запрос к listener-у указанному в сетевом адресе для проверки доступа к экземпляру или сервису. Если listener работа – пользовательский процесс пробует установить соединение с сервером иначе повзращается ошибка. Если в строке подключения нет символа “@” — тогда происходит попытка создать локальное подключение используя протокол IPC и если экземпляр или сервис запущены на той же машине, что и клиентский пользовательский процесс соединение может быть успешно установлено.
Ссылки базы данных
Oracle Net используется для взаимодействия между пользователями и базой данных. Также Oracle Net может использоваться для взаимодействия БД между собой: пользовательская сессия подключенная к одной базе данных может выполнять SQL запросы к другой БД. Это осуществляется с помощью ссылок БД. Существует несколько вариантов для создания ссылок (все связаны с безопасностью), и простым примером является команда
create database link prodstore connect to store identified by admin123 using ‘prod’;
Эта команда создаёт ссылку из текущей БД к удалённой базе данных определяему строкой подключения PROD. Ссылка доступна и может быть использована только для схемы текущего пользователя. Когда будет выполнена команда
select * from orders@prodstore;
Пользовательская сессия попробует создать сессию к удалённой БД, используя имя пользователя STORE и выполнить запрос на удалённом сервере. Результат затем будет возвращён к текущей БД и затем пользователю.
Любые SQL запросы могут быть выполнены используя ссылки БД, если конечно есть соответствующие привилегии доступа. Например рассмотрим такой сценарий:
У вас есть рабочая БД определённая строкой подключения PROD, в которой находится схема STORE содержащая две таблицы: ORDERS и PRODUCTS. Создана ссылка к этой БД (командой описанной выше). Также есть база данных для разработки, определённая строкой подключения DEV, в которой также есть схема STORE. Вы подключены к третьей базе данных с именем TEST и вам нужно обновить схему базы данных для разработки данными из рабочей БД.
Для начала создадим ссылку на базу данных для разработки
create database link devstore connect to store identified by devpasswd using ‘dev’;
Затем обновим данные в БД для разработки используя рабочую базу
truncate table orders@devstore;
truncate table products@devstore;
insert into orders@devstore select * from orders@prodstore;
insert into products@devstore select * from products@prodstore;
commit;
В будущем если вам необходимо проверить были ли добавлены данные в рабочую базу данных и если были, то добавить эти данные в БЛ для разработки вы можете выполнить команду
insert into orders@devstore (select * from orders@prodstore minus select * from orders@devstore)
Если к примеру необходимо обновить имя покупателя вы можете сделать это в двух базах данных одновременно
update customers@prodstore set customer_name=’Coda’ where customer_id=10;
update customers@devstore set customer_name=’Coda’ where customer_id=10;
commit;
Когда необходимо Oracle выполнит дву-фазное подтверждение транзакции, чтобы убедиться что распределённая транзакция (distributed transaction – это транзакция затрагивающая данные в нескольких базах данных) обрабатывается как атомарная транзакция: изменения должны применяться либо ко всем базам данных либо ни к одной. Согласованность чтения данных также управляется во всём окружении.
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.
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.
tnsnames.ora in Windows
If there’s no tnsnames.ora, please copy one in sample folder for yourself.
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.
