Изменение размера шрифта в Парус-8
Инструкция
Точка входа в процедуру не найдена
Решение
Обновление версии Парус-8
Вопросы с сетью, например при запуске виснет на проверке лицензии, хотя при этом связь есть.
Решение
В данной ситуации ошибка связана с тем, что сеть (канал связи) между вами и МИАЦ не настроена должным образом и в процессе передачи данных либо бьются пакеты передаваемые с сервера, либо дефрагментируются, а на конечных машинах не могут собраться. Решение проблемы скорее всего кроется в настройке параметров сети MTU и MSS. По поводу настройки сети вам нужно звонить в организацию, которая вам ее предоставляет, как правило это РОСИНТЕГРАЦИЯ, либо МИАЦ.
Ошибка соединения с сервером базы данных. ORA-12170: TNS:Connect timeout occurred
Решение
Необходимо убедиться доступен ли сервер с базой данных, чтобы это сделать нужно зайти в командную строку и выполнить команду — ping:
ping 10.0.9.60
1. По результату команды – ping можно сделать выводы о причине выше указанной ошибки, если пакеты теряются либо вообще не приходят с сервера, то причина в канале связи либо в настройке сети, в данном случае вам нужно обращаться к той организации которая предоставляет вам сеть как правило это РОСИНТЕНРАЦИЯ либо МИАЦ.
2. Если по результату команды – ping потери пакетов нету, то необходимо проверить чтобы порт 1521 был открыт на входящие и исходящие подключения.
3. Если по результату команды – ping потери пакетов нету, и порт 1521 открыт то в данной ситуации ошибка связана с тем, что сеть (канал связи) между вами и МИАЦ не настроена должным образом и в процессе передачи данных либо бьются пакеты передаваемые с сервера, либо дефрагментируются, а на конечных машинах не могут собраться. Решение проблемы скорее всего кроется в настройке параметров сети MTU и MSS. По поводу настройки сети вам нужно звонить в организацию которая вам ее предоставляет, как правило это РОСИНТЕГРАЦИЯ либо МИАЦ.
Ошибка ORA-12154: TNS: could not resolve service name
Решение
Рекомендуется перезагрузить компьютер и сетевое оборудование, и попробовать снова войти в программу. Если после этого ошибка не пропала, то причина её кроется в настройке сети, сетевого оборудования обеспечивающего связь с сервером.
Ошибка соединения с сервером базы данных. ORA-12518: TNS:listener could not hand off client connection
Решение
Рекомендуется перезагрузить компьютер и сетевое оборудование, и попробовать снова войти в программу. Если после этого ошибка не пропала, то причина её кроется в настройке сети, сетевого оборудования обеспечивающего связь с сервером.
Ошибка ORA-03113 иногда ошибка ORA-03135
Решение
Проблема в сети, об этом собственно говорит ошибка. По данным вопросам нужно обращаться в Росинтеграцию, для правильной настройки VipNet координатора.
В окне ввода имени пароля название организации и название модулей пишется «Вопросительными» знаками.
Решение
После установки Парус 8 в окне «Начать сеанс» в полях «Организация» и «Приложение» знаки вопроса «???????» вместо корректных значений. Попробуйте перезагрузить компьютер, после снова попробовать зайти в Парус 8, после чего должна опять появиться подобная ошибка, со второй попытки входа ошибка должна исчезнуть. Если после выше указанных действий ошибка не исчезает, то нужно проверить прописалась ли переменная NLS_LANG (шаг 3) в переменные среды окружения ОС. Нужно зайти в: Компьютер-Свойства-Дополнительные параметры системы-Переменные среды- Системные переменные (нижнее окошко) и убедится что переменная NLS_LANG со значением AMERICAN_AMERICA.CL8MSWIN1251 присутствует в списке переменных, если ее нет то ее необходимо добавить в ручную и попробовать Войти в Парус 8 (если необходимо перезагрузить компьютер).
Ошибка ORA-12560
Решение
1. Проверить чтобы директория установки Паруса была отличная от Program Files (x86), в противном случае перенести парус в другую директорию.
2. Если п.1 не помог, и парус был установлен по инструкции, то решение проблемы заключается в правильной настройке сети, VIPnet координатора, если он есть, настройке файрвола, проверке пинга до сервера БД.
При попытке открыть отчет из Центра учета, появляется вот такая ошибка: «Произошла ошибка внешнего программного объекта. В случае повторения ошибки необходимо сообщить о ней разработчикам» Exception EOleSysError in module p8561vcl.bpl at 0005F9C0.
Решение
Проверьте, что бы:
- Версия MS Office была 32х битная.
- MS Office, была не пробная(trial).
- MS Office были установлены все патчи.
Если все условия соблюдены необходимо переустановить на компьютер пользователя MS Office, предварительно удалив ветки реестра:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice
HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoftOffice
Ошибка ORA-12546: TNS:permission denied
Решение
Проблема заключается в недостатке системных привилегий у пользователя ОС на объекты ORACLE, нужно их назначить. При наличии криптографического ПО (например VIPNET), требуется также настройка прав доступа для пользователя ОС.
Ошибка ORA-12569: TNS:packet checksum failure
Решение
Проблема заключается в том что пакеты приходящие с сервера на клиент oracle повреждены, причина этого заключается в локальной сети, либо сетевом оборудовании, которое работает не должным образом. Нужно попробовать переподключить все соединения, перезагрузить сетевое оборудование. Также проблема может крыться в наличии криптографических программ, которые шифруют трафик, в этом случае требуется более детальная их настройка. Либо стоит связаться с провайдером вашей локальной/глобальной сети.
Ошибка Error loading MIDAS.DLL
Решение
Исправление ошибки при вызове отработанного времени midas.docx
Я пытался подключиться к базе данных здесь, в моем ноутбуке, используя Oracle Toad, но я продолжал иметь эту ошибку:
ORA-12170: TNS: время ожидания подключения
каковы возможные причины, я продолжал иметь эту ошибку?
вчера я получил доступ к той же базе данных и смог получить к ней доступ.
7 ответов
[сбор ответов в комментариях]
проблема в том, что Служба Oracle работает по IP-адресу, а хост настроен с другим IP-адресом.
чтобы увидеть IP-адрес Службы Oracle, введите lsnrctl status
команда и проверка указанного адреса (в данном случае это 127.0.0.1, localhost):
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1521)))
чтобы увидеть IP-адрес хоста, введите ipconfig
(под windows) или ifconfig
(под linux) команда.
Howewer, в моей установке, служба Oracle не работает если установлен на localhost адрес, я должен установить реальный IP-адрес хоста (например 192.168.10.X).
чтобы избежать этой проблемы в будущем, не используйте DHCP для назначения IP-адреса хоста, а используйте статический.
это из-за конфликтующего SID. Например, в Oracle12cBaseappproduct12.1.0dbhome_1NETWORKADMINtnsnames.описание файла-ora, соединение для ORCL это:
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
)
)
и вы пытаетесь подключиться с помощью строки подключения, используя тот же SID, но другой IP, имя пользователя/пароль, например:
sqlplus username/password@192.168.130.52:1521/orcl
чтобы решить эту проблему, внесите изменения в файл tnsnames.Ора файл:
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.130.52)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
)
)
Проверьте брандмауэр, чтобы разрешить подключение на сервере от вашего клиента.
Разрешив доменную сеть или создав правило.
проблема, потому что установление соединения или связь с клиентом не удалось завершить в течение отведенного интервала времени. Это может быть результатом сетевых или системных задержек.
я получал ту же ошибку при подключении моего пользователя «hr» ORCLPDB, который является подключаемой базой данных.
во-первых, получить имя хоста и номер порта, введите команду lsnrctl status
в командной строке Windows. В моем случае, это был 127.0.0.1 и номер порта, как 1521
во-вторых, введите команду ниже с именем хоста и номером порта:
sqlplus username/password@HostName:Port Number/PluggableDatabaseName.
например:
sqlplus hr/hr@127.0.0.1:1521/ORCLPDB.
ШАГИ ПО УСТРАНЕНИЮ НЕПОЛАДОК (Doc ID 730066.1)
ошибки тайм-аута соединения ORA-3135 и ORA-3136
Ошибка тайм-аута соединения может быть выдана, если попытка подключения к базе данных не завершает фазы подключения и проверки подлинности в течение периода времени, разрешенного следующими параметрами:
заменить sqlnet.INBOUND_CONNECT_TIMEOUT и/или INBOUND_CONNECT_TIMEOUT_ серверные параметры.
начиная с Oracle 10.2, по умолчанию для этих параметров 60 секунд, где в предыдущих выпусках это было 0, что означает отсутствие тайм-аута.
в тайм-аут клиентская программа получит ошибку ORA-3135 (или, возможно, TNS-3135):
ORA-3135 соединение потерял контакт
и база данных зарегистрирует ошибку ORA-3136 в своем предупреждении.log:
… Сб 10 Мая 02: 21: 38 2008
Предупреждение: время ожидания входящего соединения (ORA-3136) …
- аутентификация SQL
когда сеанс базы данных находится на этапе проверки подлинности, он выдаст последовательность операторов SQL. Аутентификация не завершена, пока все они не будут проанализированы, выполнены, извлечены полностью. Некоторые из операторов SQL в этом списке, например, на 10.2:
select value$ from props$ where name = 'GLOBAL_DB_NAME'
select privilege#,level from sysauth$ connect by grantee#=prior privilege#
and privilege#>0 start with grantee#=:1 and privilege#>0
select SYS_CONTEXT('USERENV', 'SERVER_HOST'), SYS_CONTEXT('USERENV', 'DB_UNIQUE_NAME'),
SYS_CONTEXT('USERENV', 'INSTANCE_NAME'), SYS_CONTEXT('USERENV', 'SERVICE_NAME'),
INSTANCE_NUMBER, STARTUP_TIME, SYS_CONTEXT('USERENV', 'DB_DOMAIN')
from v$instance where INSTANCE_NAME=SYS_CONTEXT('USERENV', 'INSTANCE_NAME')
select privilege# from sysauth$ where (grantee#=:1 or grantee#=1) and privilege#>0
ALTER SESSION SET NLS_LANGUAGE= 'AMERICAN' NLS_TERRITORY= 'AMERICA' NLS_CURRENCY= '$'
NLS_ISO_CURRENCY= 'AMERICA' NLS_NUMERIC_CHARACTERS= '.,' NLS_CALENDAR= 'GREGORIAN'
NLS_DATE_FORMAT= 'DD-MON-RR' NLS_DATE_LANGUAGE= 'AMERICAN' NLS_SORT= 'BINARY' TIME_ZONE= '+02:00'
NLS_COMP= 'BINARY' NLS_DUAL_CURRENCY= '$' NLS_TIME_FORMAT= 'HH.MI.SSXFF AM' NLS_TIMESTAMP_FORMAT=
'DD-MON-RR HH.MI.SSXFF AM' NLS_TIME_TZ_FORMAT= 'HH.MI.SSXFF AM TZR' NLS_TIMESTAMP_TZ_FORMAT=
'DD-MON-RR HH.MI.SSXFF AM TZR'
Примечание: список SQL выше не является полным и не представляет собой порядок проверки подлинности SQL . Могут также существовать различия от выпуска к выпуску.
- зависает во время проверки подлинности
вышеуказанные операторы SQL должны быть проанализированы, выполнены и извлечены, как это происходит для всех SQL внутри базы данных Oracle. Из этого следует, что любая проблема, возникшая на этих этапах, которая выглядит как зависание или серьезная низкая производительность, может привести к таймауту.
симптомы таких зависаний будут видны сеансом аутентификации как ожидания для:
* курсор: pin s ждать на X
* защелка: объекты кэша строк
* блокировка кэша строк
Возможны другие типы событий ожидания; этот список может быть неполным.
проблема здесь в том, что сеанс аутентификации заблокирован, ожидая получения общего ресурса, который удерживается другим сеансом внутри базы данных. Этот сеанс блокатора сам занят длительным действием (или его собственным зависанием), которое не позволяет ему освободить общий ресурс, необходимый сеансу аутентификации в своевременная мода. В результате время ожидания в итоге сообщили аутентификации сессии.
- Устранение неполадок аутентификации зависает
в таких ситуациях нам нужно выяснить процесс блокатора, содержащий общий ресурс, необходимый сеансу аутентификации, чтобы увидеть, что с ним происходит.
типичные диагностики используемые в таких случаях следующие:
- три раза подряд systemstate сбрасывает на уровне 266 во время блокировки одного или нескольких сеансов проверки подлинности. Вполне вероятно, что сеанс блокировки приведет к тайм-аутам более чем одной попытки подключения. Следовательно, дампы systemstate могут быть полезны, даже если время, необходимое для их создания, превышает период одного таймаута, например 60 сек:
$ sqlplus -prelim '/ as sysdba' oradebug setmypid oradebug unlimit oradebug dump systemstate 266 ...wait 90 seconds oradebug dump systemstate 266 ...wait 90 seconds oradebug dump systemstate 266 quit
- отчеты ASH, охватывающие, например, 10-15 минут периода времени, в течение которого несколько ошибок тайм-аута были замечены.
- если возможно, два последовательных запроса на V$LATCHHOLDER view для случая, когда ожидаемый общий ресурс является защелкой.
выбрать * из V$latchholder;
Дампы systemstate должны помочь в идентификации сеанса блокатора.
Уровень 266 покажет нам, в каком коде он выполняется, что может помочь в поиске любой существующей ошибки в качестве основной причины.
примеры проблем, которые могут привести к зависанию аутентификации
- неопубликованные Ошибка 6879763 shared pool simulator ошибка исправлена патчем
для неопубликованной ошибки 6966286 см. Примечание 563149.1 -
неопубликованная ошибка 7039896 обходной параметр
_enable_shared_pool_durations=false см. Примечание 7039896.8 -
другие подходы, чтобы избежать проблем
в некоторых случаях можно избежать проблем с аутентификацией SQL, закрепив такие операторы в общем пуле вскоре после экземпляра запускается и они свежеиспеченные. Вы можете использовать следующие статья для:
Документ 726780.1 как закрепить Курсор в общем пуле с помощью DBMS_SHARED_POOL.KEEP
закрепление предотвратит их вымывание из-за бездействия и старения и, следовательно, предотвратит их необходимость перезагрузки в будущем, т. е. необходимость повторного ремонта и подверженности проблемам с аутентификацией.
-1
автор: Mohammad AL-Omari
TROUBLESHOOTING STEPS (Doc ID 730066.1)
Connection Timeout errors ORA-3135 and ORA-3136
A connection timeout error can be issued when an attempt to connect to the database does not complete its connection and authentication phases within the time period allowed by the following:
SQLNET.INBOUND_CONNECT_TIMEOUT and/or INBOUND_CONNECT_TIMEOUT_ server-side parameters.
Starting with Oracle 10.2, the default for these parameters is 60 seconds where in previous releases it was 0, meaning no timeout.
On a timeout, the client program will receive the ORA-3135 (or possibly TNS-3135) error:
ORA-3135 connection lost contact
and the database will log the ORA-3136 error in its alert.log:
… Sat May 10 02:21:38 2008
WARNING: inbound connection timed out (ORA-3136) …
- Authentication SQL
When a database session is in the authentication phase, it will issue a sequence of SQL statements. The authentication is not complete until all these are parsed, executed, fetched completely. Some of the SQL statements in this list e.g. on 10.2 are:
select value$ from props$ where name = 'GLOBAL_DB_NAME'
select privilege#,level from sysauth$ connect by grantee#=prior privilege#
and privilege#>0 start with grantee#=:1 and privilege#>0
select SYS_CONTEXT('USERENV', 'SERVER_HOST'), SYS_CONTEXT('USERENV', 'DB_UNIQUE_NAME'),
SYS_CONTEXT('USERENV', 'INSTANCE_NAME'), SYS_CONTEXT('USERENV', 'SERVICE_NAME'),
INSTANCE_NUMBER, STARTUP_TIME, SYS_CONTEXT('USERENV', 'DB_DOMAIN')
from v$instance where INSTANCE_NAME=SYS_CONTEXT('USERENV', 'INSTANCE_NAME')
select privilege# from sysauth$ where (grantee#=:1 or grantee#=1) and privilege#>0
ALTER SESSION SET NLS_LANGUAGE= 'AMERICAN' NLS_TERRITORY= 'AMERICA' NLS_CURRENCY= '$'
NLS_ISO_CURRENCY= 'AMERICA' NLS_NUMERIC_CHARACTERS= '.,' NLS_CALENDAR= 'GREGORIAN'
NLS_DATE_FORMAT= 'DD-MON-RR' NLS_DATE_LANGUAGE= 'AMERICAN' NLS_SORT= 'BINARY' TIME_ZONE= '+02:00'
NLS_COMP= 'BINARY' NLS_DUAL_CURRENCY= '$' NLS_TIME_FORMAT= 'HH.MI.SSXFF AM' NLS_TIMESTAMP_FORMAT=
'DD-MON-RR HH.MI.SSXFF AM' NLS_TIME_TZ_FORMAT= 'HH.MI.SSXFF AM TZR' NLS_TIMESTAMP_TZ_FORMAT=
'DD-MON-RR HH.MI.SSXFF AM TZR'
NOTE: The list of SQL above is not complete and does not represent the ordering of the authentication SQL . Differences may also exist from release to release.
- Hangs during Authentication
The above SQL statements need to be Parsed, Executed and Fetched as happens for all SQL inside an Oracle Database. It follows that any problem encountered during these phases which appears as a hang or severe slow performance may result in a timeout.
Symptoms of such hangs will be seen by the authenticating session as waits for:
• cursor: pin S wait on X
• latch: row cache objects
• row cache lock
Other types of wait events are possible; this list may not be complete.
The issue here is that the authenticating session is blocked waiting to get a shared resource which is held by another session inside the database. That blocker session is itself occupied in a long-running activity (or its own hang) which prevents it from releasing the shared resource needed by the authenticating session in a timely fashion. This results in the timeout being eventually reported to the authenticating session.
- Troubleshooting of Authentication hangs
In such situations, we need to find out the blocker process holding the shared resource needed by the authenticating session in order to see what is happening to it.
Typical diagnostics used in such cases are the following:
- Three consecutive systemstate dumps at level 266 during the time that one or more authenticating sessions are blocked. It is likely that the blocking session will have caused timeouts to more than one connection attempt. Hence, systemstate dumps can be useful even when the time needed to generate them exceeds the period of a single timeout e.g. 60 sec:
$ sqlplus -prelim '/ as sysdba' oradebug setmypid oradebug unlimit oradebug dump systemstate 266 ...wait 90 seconds oradebug dump systemstate 266 ...wait 90 seconds oradebug dump systemstate 266 quit
- ASH reports covering e.g. 10-15 minutes of a time period during which several timeout errors were seen.
- If possible, Two consecutive queries on V$LATCHHOLDER view for the case where the shared resource being waited for is a latch.
select * from v$latchholder;
The systemstate dumps should help in identifying the blocker session.
Level 266 will show us in what code it is executing which may help in locating any existing bug as the root cause.
Examples of issues which can result in Authentication hangs
- Unpublished Bug 6879763 shared pool simulator bug fixed by patch
for unpublished Bug 6966286 see Note 563149.1 -
Unpublished Bug 7039896 workaround parameter
_enable_shared_pool_durations=false see Note 7039896.8 -
Other approaches to avoid the problem
In some cases, it may be possible to avoid problems with Authentication SQL by pinning such statements in the Shared Pool soon after the instance is started and they are freshly loaded. You can use the following artcile to advise on this:
Document 726780.1 How to Pin a Cursor in the Shared Pool using DBMS_SHARED_POOL.KEEP
Pinning will prevent them from being flushed out due to inactivity and aging and will therefore prevent them for needing to be reloaded in the future i.e. needing to be reparsed and becoming susceptible to Authentication hang issues.
Oracle databases are widely used around the world, and like any other software, they can run into issues. One such issue is the ORA-12170 error, which occurs when a client is unable to establish a connection to the Oracle database server within the specified time period. In this guide, we will provide a comprehensive explanation and step-by-step solution to resolve the ORA-12170 error.
Table of Contents
- Understanding the ORA-12170 Error
- Common Causes of ORA-12170 Error
- Step-by-Step Solution to Fix ORA-12170 Error
- Step 1: Verify the Basic Network Connectivity
- Step 2: Check the Listener Configuration
- Step 3: Validate the SQL*Net Configuration
- Step 4: Test the Connection with TNSPING
- Step 5: Adjust the Connection Timeout
- FAQ
Understanding the ORA-12170 Error
The ORA-12170 error occurs when a client fails to establish a connection to the Oracle database server within the specified time period. The error message looks like this:
ORA-12170: TNS: Connect timeout occurred
This error can be caused by several factors, such as network issues, incorrect listener configuration, or an overly restrictive firewall.
Common Causes of ORA-12170 Error
Some of the common causes of the ORA-12170 error include:
- Network connectivity issues between the client and the database server
- An incorrect or missing listener configuration
- Invalid SQL*Net configuration in the client’s
tnsnames.ora
file - Insufficient connection timeout value
- Firewall restrictions between the client and the database server
Step-by-Step Solution to Fix ORA-12170 Error
Follow these steps to resolve the ORA-12170 error:
Step 1: Verify the Basic Network Connectivity
First, ensure that the client can connect to the database server over the network. You can use the ping
command to test the basic network connectivity.
ping <database_server_hostname/IP>
If the ping
command fails, check your network configuration and ensure that the client and the database server can communicate with each other.
Step 2: Check the Listener Configuration
Ensure that the Oracle listener is running on the database server and is configured correctly. You can use the lsnrctl status
command on the server to check the listener’s status.
lsnrctl status
If the listener is not running, start it using the lsnrctl start
command.
lsnrctl start
If the listener is running but is not configured correctly, edit the listener.ora
file on the server and update the configuration as needed.
Step 3: Validate the SQL*Net Configuration
On the client side, check the tnsnames.ora
file for the correct SQL*Net configuration. Ensure that the hostname, port, and service name in the configuration match the listener configuration on the database server.
Here’s a sample tnsnames.ora
configuration:
MYDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <database_server_hostname/IP>)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = mydb)
)
)
Step 4: Test the Connection with TNSPING
Use the tnsping
utility on the client to test the connection to the Oracle database server.
tnsping MYDB
If the tnsping
test fails, review the previous steps to ensure that the network connectivity, listener configuration, and SQL*Net configuration are correct.
Step 5: Adjust the Connection Timeout
If the tnsping
test is successful but you still encounter the ORA-12170 error, consider increasing the connection timeout value. You can do this by adding the TIMEOUT
parameter to the CONNECT_DATA
section of the tnsnames.ora
file.
MYDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = <database_server_hostname/IP>)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = mydb)
(TIMEOUT = 5000)
)
)
In the example above, the connection timeout is set to 5000 milliseconds (5 seconds).
FAQ
What is the default connection timeout value for Oracle databases?
By default, the connection timeout value for Oracle databases is set to 60 seconds.
How can I check the current connection timeout value?
You can check the current connection timeout value in the tnsnames.ora
file on the client side. Look for the TIMEOUT
parameter in the CONNECT_DATA
section.
Can firewall restrictions cause the ORA-12170 error?
Yes, firewall restrictions between the client and the database server can cause the ORA-12170 error. Ensure that the necessary ports (usually 1521 for Oracle databases) are open on the firewall.
Can I change the connection timeout value on the server side?
Yes, you can change the connection timeout value on the server side by editing the listener.ora
file and adding the INBOUND_CONNECT_TIMEOUT
parameter in the SID_DESC
section.
How can I troubleshoot network issues between the client and the database server?
You can use various network troubleshooting tools, such as ping
, traceroute
, or telnet
, to identify network connectivity issues between the client and the database server.
Learn more about Oracle Listener
Oracle SQL*Net Configuration
Oracle TNSPING Utility
После успешной установки ORACLE 11g в Red Hat Enterprise Linux Server версии 6.7, после настройки TNS на клиенте, проверьте, может ли он подключиться к серверу блока данных, результатом будет ошибка: ORA-12170: TNS: время ожидания соединения
1: Сначала проверьте, можно ли пинговать сеть, как показано ниже, сеть разблокирована.
2: Проверьте конфигурацию TNS (с конфигурацией TNS проблем нет)
GSP =
(DESCRIPTION =
(ADDRESS =(PROTOCOL = TCP)(HOST = 192.168.1.81)(PORT = 1521))
(CONNECT_DATA=
(SERVER = DEDICATED)
(SERVICE_NAME = esbdb)
)
)
3: Проверьте, запущена ли служба мониторинга сервера
[[email protected] ~]$ lsnrctl status
LSNRCTL for Linux: Version 10.2.0.1.0 — Production on 14-DEC-2012 15:51:13
Copyright (c) 1991, 2005, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
STATUS of the LISTENER
————————
Alias LISTENER
Version TNSLSNR for Linux: Version 10.2.0.1.0 — Production
Start Date 14-DEC-2012 13:15:28
Uptime 0 days 2 hr. 35 min. 45 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /database/oracle/product/dbhome/network/admin/listener.ora
Listener Log File /database/oracle/product/dbhome/network/log/listener.log
Listening Endpoints Summary…
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=wgods)(PORT=1521)))
Services Summary…
Service «PLSExtProc» has 1 instance(s).
Instance «PLSExtProc», status UNKNOWN, has 1 handler(s) for this service…
Service «gsp» has 2 instance(s).
Instance «gsp», status UNKNOWN, has 1 handler(s) for this service…
Instance «gsp», status READY, has 1 handler(s) for this service…
Service «gspXDB» has 1 instance(s).
Instance «gsp», status READY, has 1 handler(s) for this service…
Service «gsp_XPT» has 1 instance(s).
Instance «gsp», status READY, has 1 handler(s) for this service…
The command completed successfully
4: Используйте команду tnsping, чтобы проверить и сообщить TNS-12535: TNS: Превышено время ожидания операции. На данный момент мы можем быть уверены, что это проблема межсетевого экрана.
C:Userskerry>tnsping 192.168.1.81
Утилита TNS Ping для 32-битной Windows: версия 11.2.0.1.0-Production от 14-декабря-2012 15:47:15
Copyright (c) 1997, 2010, Oracle. All rights reserved.
Файл используемых параметров:
E:appkerryproduct11.2.0dbhome_1networkadminsqlnet.ora
Адаптер EZCONNECT был использован для разрешения псевдонимов
Попробуйте подключиться (DESCRIPTION = (CONNECT_DATA = (SERVICE_NAME =)) (ADDRESS = (PROTOCOL = TCP) (HOST = 172.20.32.79) (PORT = 1521)))
TNS-12535: TNS: Превышено время ожидания операции
Для проблемы брандмауэра у нас может быть два решения:
1: Отключите брандмауэр (это решение не очень хорошее, отключение брандмауэра принесет много угроз безопасности)
[[email protected] ~]# service iptables stop
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
2: изменить iptables, открыть порт 1521 и разрешить подключение к порту 1521
2.1 Отредактируйте файл iptables и добавьте запись -A RH-Firewall-1-INPUT -p tcp -m state —state NEW -m tcp —dport 1521 -j ACCEPT.
[[email protected] sysconfig]# vi iptables
# Generated by iptables-save v1.3.5 on Fri Dec 14 17:03:58 2012
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1749:243629]
:RH-Firewall-1-INPUT — [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp —icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp —dport 5353 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp —dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp —dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state —state NEW -m tcp —dport 21 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state —state NEW -m tcp —dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state —state NEW -m tcp —dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state —state NEW -m tcp —dport 23 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state —state NEW -m tcp —dport 1521 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT —reject-with icmp-host-prohibited
COMMIT
# Completed on Fri Dec 14 17:03:58 2012
~
~
~
~
~
«iptables» 24L, 1212C written
2.2 Перезапустите сервис iptables
[[email protected] sysconfig]# service iptables restart
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
Applying iptables firewall rules: [ OK ]
Loading additional iptables modules: ip_conntrack_netbios_ns ip_conntrack_ftp [ OK ]
2.3 Сохраните новые правила, чтобы правила конфигурации не стали недействительными после перезапуска компьютера в следующий раз.
[[email protected] sysconfig]# service iptables save
Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
2.4 Проверьте, открыт ли порт 1521 и разрешите соединение (см. Красную часть)
[[email protected] sysconfig]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all — 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all — 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all — 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp — 0.0.0.0/0 0.0.0.0/0 icmp type 255
ACCEPT esp — 0.0.0.0/0 0.0.0.0/0
ACCEPT ah — 0.0.0.0/0 0.0.0.0/0
ACCEPT udp — 0.0.0.0/0 224.0.0.251 udp dpt:5353
ACCEPT udp — 0.0.0.0/0 0.0.0.0/0 udp dpt:631
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:631
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:23
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:1521
REJECT all — 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
[[email protected] sysconfig]#
Используйте PL / SQL Developer для подключения к базе данных от клиента и решения проблемы.