Сбой входа oracle не удается обработать запрос

Обновлено: 07.07.2024

Я пытаюсь подключиться к схеме на 11g (v11.2.0.1.0) от ПК с 9i (v9.2.0.1) клиент. Кажется, что он хорошо связан с некоторыми схемами, но не с этим - он возвращается с ORA-01017 Invalid Username/Password ошибка каждый раз.

имя пользователя и пароль определенно верны - может ли кто-нибудь придумать причину, почему это не сработает?

есть ли принципиальная несовместимость версии 9i и 11G?

пользователь и пароль тотже. Учетные данные Oracle 11g чувствительны к регистру.

попробуйте изменить системный набор SEC_CASE_SENSITIVE_LOGON = FALSE; и изменить пароль.

Если все остальное не удается, попробуйте сбросить пароль на то же самое. Я столкнулся с этой ошибкой и не смог обойти ее, но просто сброс пароля до того же значения решил проблему.

некоторое время назад у меня была аналогичная проблема. Вы должны быть осторожны с кавычками и двойными кавычками. Рекомендуется сбросить пароль пользователя, используя учетные данные администратора.

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

для oracle версии 12.2.X пользователи не могут войти в систему, используя пароли без учета регистра, даже если SEC_CASE_SENSITIVE_LOGON = FALSE, если PASSWORD_VERSIONS пользователя не 10g.

следующий sql должен показывать PASSWORD_VERSIONS для пользователя.

сделать PASSWORD_VERSIONS совместимым с 10g

добавить / изменить строку в sqlnet.ora базы данных, чтобы иметь SQLNET.ALLOWED_LOGON_VERSION_SERVER=8 перезапуска базы изменить / истечь пароль для существующего пользователя новый пользователь созданные также будут иметь те же настройки после вышеуказанных шагов PASSWORD_VERSIONS должно быть что-то вроде этого

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

еще несколько фактов моего env:

11.2
подключить как: sys as sysdba
операции . чтение all_tables , all_views и предоставлении выберите на них для другого пользователя

У меня была та же проблема, и я поставил двойные кавычки вокруг имени пользователя и пароля, и это сработало: создайте общедоступную ссылку базы данных "opps", идентифицированную "opps" с помощью "TEST";

Я не специалист. Если вы получаете ORA-01017 при попытке подключить схему HR от разработчика SQL в Oracle 11g Пожалуйста, попробуйте разблокировать HR следующим образом

alter user HR идентифицируется hr Пользователи табличного пространства по умолчанию временная температура табличного пространства разблокировка аккаунта;

вы можете подключиться к базе данных Oracle с помощью sqlplus:

затем создайте новых пользователей и назначьте привилегии.

моя ошибка заключалась в том, что мой пользователь был создан с кавычками (например, "rockerolf"), и мне также пришлось указать моего пользователя в connectionstring как User >

в конце концов я удалил пользователя с кавычками и создал новый без кавычек..

Я знаю, что этот пост был о 11g, но ошибка в клиенте 12c с тем, как он шифрует пароли, может быть виновата в этой ошибке, если вы решите использовать этот и вы:

нет регистра пароль вопрос (т. е. ты пробовал ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE и сброс пароля и все равно не работает),
поместите кавычки вокруг вашего пароля в строку подключения, и это все равно не поможет,
вы проверили все переменные среды ( ORACLE_HOME , PATH , TNS_ADMIN ), и TNS_ADMIN строковый реестре за HKLM\Software\Oracle\KEY_OraClient12Home на месте
вы проверили свою строку подключения и комбинацию имени пользователя / пароля в Net Manager, и
вы можете подключиться с помощью SQL * Plus, Oracle SQL Developer, используя те же учетные данные.

все основные проверки.

Fix: попробуйте установить HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled to 0 в реестре (regedit), чтобы отключить ФИПС.

недавно у меня была аналогичная проблема с Oracle 12c. Я создал нового пользователя с паролем нижнего регистра и смог войти в систему с сервера базы данных, но все клиенты потерпели неудачу с ORA-01017. Исправление оказалось простым в конце (сброс пароля в верхний регистр), но потребовалось много усилий, чтобы добраться туда.

ORA-01017: неверное имя пользователя / пароль; вход в систему запрещен. Ошибка базы данных Oracle.

ORA-01017:

неверное имя пользователя / пароль; ошибка входа запрещена (пользователи и пароли в программе не могут войти в систему, вход запрещен)
версия Oracle 11g

Ошибки при первоначальной установке и использовании:

Решение 1. Создайте нового пользователя:

Открыть sqlplus
Войдите в систему как система:
Инструкции следующие

Создать нового пользователя:
Синтаксис: создать имя пользователя, идентифицированное паролем;

Разблокируйте синтаксис для только что созданного пользователя:
Синтаксис: изменить имя пользователя, разблокировать учетную запись;
Инструкция: изменение учетной записи root пользователя unlock; // разблокировка пользователя
Инструкция: изменить блокировку учетной записи root пользователя; // блокировка пользователя

Предоставьте разрешение на создание нового вошедшего в систему пользователя:
Синтаксис: разрешить создание сеанса имени пользователя;

Другие настройки разрешений:
Предоставьте вновь созданным пользователям права администратора базы данных:
Синтаксис: предоставить dba имени пользователя;
Инструкция: предоставить dba root;
Предоставьте другие разрешения пользователям:
Команда :

Переключитесь на вновь созданный синтаксис логина пользователя:

подключить логин / пароль;

Удалить синтаксис пользователя: удалить имя пользователя;

Если пользователь владеет таблицей данных, ее нельзя удалить напрямую. Используйте ключевое слово cascade:

Общие шаги:

Руководство по установке Oracle windows:

Разархивируйте по тому же пути:

Установка:

Настройте обновление для системы безопасности. На этом этапе вы можете указать свой адрес электронной почты (вы также можете оставить его пустым, но просто получите несколько бесполезных писем). Отмените «Я надеюсь получать обновления безопасности (W) через службу поддержки Oracle» ниже. Как показано:

Опция безопасности, непосредственно выберите создание и настройку базы данных по умолчанию (после установки программного обеспечения для управления базами данных система автоматически создаст экземпляр базы данных).

Системная категория, просто выберите категорию рабочего стола по умолчанию. Как показано

Типичная установка. Важные шаги Рекомендуется обновить только базовый каталог Oracle, а путь к каталогу не должен содержать китайские или другие специальные символы. Имя глобальной базы данных может быть именем по умолчанию, и пароль должен быть учтен. Когда вводится пароль, появляется предупреждение, и не имеет значения, не соответствует ли оно рекомендациям Oracel. (Поскольку правило пароля, предложенное Oracel, является более сложным, оно должно состоять из прописных букв, строчных букв и цифр и должно содержать более 8 цифр. Неисправность, вы можете ввести короткий пароль, к которому вы привыкли)

Если введенный пароль является коротким и простым, во время установки будет отображаться следующее приглашение. Просто подтвердите Y, чтобы продолжить установку. Как показано:

Предварительная проверка. Программа установки проверит, соответствует ли программное и аппаратное обеспечение минимальным требованиям для установки этой версии Oracle. Следующий шаг в порядке

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

После установки файлов программного обеспечения для управления базами данных и файлов dbms автоматически создается и устанавливается база данных с именем orcl перед базой данных экземпляра по умолчанию.

База данных экземпляра создана, система по умолчанию блокирует все учетные записи, недоступные (за исключением того, что доступны системные и системные учетные записи),Рекомендуется нажать кнопку управления паролем справа, Разблокируйте часто используемую учетную запись Scott и введите пароль

Разблокируйте учетную запись Скотта, снимите зеленую галочку напротив и введите пароль. Вы также можете вводить часто используемые короткие пароли, вам не нужно добавлять цифры в соответствии с прописными или строчными буквами 8 или более, как предложено Oracle.

Аналогичным образом, он будет запрашивать, если пароль не соответствует правилам. Не беспокойся об этом, просто продолжай с Y

Интеллектуальная рекомендация

совместный запрос mysql с тремя таблицами (таблица сотрудников, таблица отделов, таблица зарплат)

1. Краткое изложение проблемы: (внизу есть инструкция по созданию таблицы, копирование можно непосредственно практиковать с помощью (mysql)) Найдите отделы, в которых есть хотя бы один сотрудник. Отоб.

[Загрузчик классов обучения JVM] Третий день пользовательского контента, связанного с загрузчиком классов

IP, сеанс и cookie

При входе в базу данных Oracle может выдаваться ошибка ORA-01017: invalid username/password; logon denied, хотя пароль при вводе набирается правильный. Причин может быть несколько, но в данном посте будет рассмотрена одна из них – инициализационный параметр sec_case_sensitive_logon.

Параметр sec_case_sensitive_logon позволяет включать или выключать чувствительность к регистру паролей в базе данных Oracle (БД). Параметр принимает два значения – TRUE или FALSE, при TRUE – пароли пользователей чувствительны к регистру, а при FALSE, соответственно, нет. Значение параметра sec_case_sensitive_logon можно просмотреть командой show parameter sec_case_sensitive_logon. Запрос ниже показывает, что параметр имеет значение TRUE. Это означает, что чувствительность к регистру паролей в БД включена.

Изменить значение параметра sec_case_sensitive_logon можно командой alter system set sec_case_sensitive_logon = false или alter system set sec_case_sensitive_logon = true. Команда ниже отключает чувствительность к регистру паролей.

Начиная с версии Oracle Database 12.1.0.1, параметр sec_case_sensitive_logon считается устаревшим. Это значит, что Oracle не вносит в него дальнейших изменений, и пользователи не должны менять значение параметра. Значение по умолчанию TRUE. Если же значение будет изменено, то пользователь получит предупреждение при запуске БД:

Также, начиная с Oracle Database 12c release 2 (12.2), по умолчанию версией протокола аутентификации является 12 (известный как Exclusive Mode). Этот протокол для аутентификации требует чувствительные к регистру пароли. Например, для Oracle Database 12c release 2 (12.2) значение по умолчанию для параметра SQLNET.ALLOWED_LOGON_VERSION_SERVER в файле SQLNET.ORA равно 12. Файл SQLNET.ORA по умолчанию находится в следующей директории операционной системы:

Параметр SQLNET.ALLOWED_LOGON_VERSION_SERVER отображает протокол аутентификации, используемый для сервера. И по умолчанию, Oracle больше не поддерживает пароли, не чувствительные к регистру – разрешены только новые версии паролей (11G и 12C). В связи с этим при входе в БД с значением FALSE для параметра sec_case_sensitive_logon можно получить ошибку:

ORA-01017: invalid username/password.

Данная ситуация возникает из-за того, что параметр sec_case_sensitive_logon имеет значение FALSE и параметр SQLNET.ALLOWED_LOGON_VERSION_SERVER имеет значение 12 или 12a. Oracle Database не запрещает использование значения FALSE параметра sec_case_sensitive_logon, когда значение SQLNET.ALLOWED_LOGON_VERSION_SERVER равно 12 или 12a. Но при таких условиях, все учетные записи кроме имеющих роль sysdba становятся недоступными. И именно такие настройки вызывают ошибку ORA-01017: invalid username/password. Есть два способа выхода из этой ситуации.

Вторым способом является присвоение параметру SQLNET.ALLOWED_LOGON_VERSION_SERVER в файле SQLNET.ora значение, ниже 12, например, 11 версию протокола аутентификации. Но это решение подразумевает необходимость смены паролей для всех пользователей БД с ролью, отличной от sysdba. Ниже в примерах показывается возникновение ошибки и ее решение двумя вышеописанными способами.

Пример 1. Возникновение ошибки при изменении параметра sec_case_sensitive_logon. Выполняется подключение к подключаемой базой данных (Pluggable Database – PDB) XEPDB1 Oracle Database 18c Express Edition под пользователем sys:

Проверяется текущее значение параметра sec_case_sensitive_logon. Результат команды показывает, что параметр чувствительности к регистру пароля включен:

Назначается пароль пользователю hr и выполняется выход из БД:

Выполняется подключение к базе данных под пользователем hr.

Подключение успешно прошло под пользователем hr.

Далее, выполняется отключение от базы под пользователем hr и подключение к контейнерной базе данных (Container Database – CDB) Oracle Dabase 18c Express Edition под пользователем sys.

Изменяется значение параметра sec_case_sensitive_logon на FALSE.

Проверяется новое значение параметра sec_case_sensitive_logon.

Для информации: значение параметра sec_case_sensitive_logon в Oracle Database 18c Express Edition необходимо сменить в контейнерной базе данных, а не в подключаемой базе данных. В противном случае можно получить следующую ошибку:

ERROR at line 1: ORA-65040: operation not allowed from within a pluggable database

Далее, нужно подключиться к подключаемой базе данных под пользователем hr.

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

Проверяется, поможет ли возврат значения параметра успешно подключиться к базе данных. Подключение к БД происходит под пользователем hr еще раз.

Как можно убедиться, подключение прошло без ошибок после возвращения значения на TRUE.

Пример 2. Возвращается параметру sec_case_sensitive_logon значение FALSE, чтобы смоделировать ошибку и показать второй способ решения. Выполняется подключение к БД под пользователем sys и меняется значение параметра sec_case_sensitive_logon на FALSE.

Выполняется исправление ошибки другим способом. Осуществляется переход в папку $ORACLE_HOME/network/admin и проверяется ее содержимое.

На подключение к базе данных также влияет значение параметра SQLNET.ALLOWED_LOGON_VERSION_SERVER в файле sqlnet.ora. Как было сказано выше, по умолчанию для версий Oracle Database 12.2 и выше используется версия алгоритма пароля, равная 12. В Oracle Database 18с Express Edition, которая используется в данном примере, параметр SQLNET.ALLOWED_LOGON_VERSION_SERVER в файле sqlnet.ora отсутствует. Это значит, что БД использует версию алгоритма паролей равную 12 по умолчанию. Вручную, добавив строку SQLNET.ALLOWED_LOGON_VERSION_SERVER=11 задается значение параметра равное 11. После этого содержимое файла sqlnet.ora выглядит следующим образом:

Пароли пользователей кроме имеющих роль sysdba должны быть изменены после изменения значения параметра SQLNET.ALLOWED_LOGON_VERSION_SERVER на 11 версию. Иначе они получат ошибку при входе, как показано в примере ниже.

Выполняется подключение под пользователем sys и проверяется версия протоколов пароля пользователя hr:

Результат выполнения команды показывает, что у hr до сих пор применяются версии протоколов пароля 11g и 12c. Необходимо сменить ему пароль, чтобы в данном случае исключить ошибку при входе пользователя. Для этого, изменяется пароль пользователю hr и проверяется версия паролей пользователя hr.

После смены пароля выполняется подключение под пользователем hr. Ниже результат команды показывает, что подключение прошло успешно.

На этом завершается описание способов решения ошибки ORA-01017: invalid username/password; logon denied, связанной с параметром sec_case_sensitive_logon.

Windows Server 2003 R2 с установленным на нём Oracle Client 10.2.0.4.
При запуске sqlplus от имени пользователя с администраторскими полномочиями коннект осуществляется без проблем. Но при попытке подключиться к базе от имени пользователя без администраторских полномочий появляется ошибка:

Вызвано это невозможностью создать global object пользователем без администраторских полномочий. Я решил проблему так:

Создал группу ora_dba (имя группы, в данном случае, значения не имеет); Ввёл в эту группу всех пользователей, которым нужно работать с Oracle Client; Пуск, Администрирование, Локальная политика безопасности; В списке слева находим и разворачиваем "Локальные политики"; В списке справа находим "Создание глобальных объектов" и открываем его двойным щелчком мыши; Щёлкаем на "Добавить пользователя или группу…", затем на "Типы объектов…", ставим галочку против "Группы" и нажимаем "Ок"; В поле "Введите имена выбираемых объектов" вводим имя группы в нотации server\group_name ( srv1\ora_dba ). Можно нажать на кнопку "Проверить имена";

Результат - ошибок нет, пользователь счастлив и может работать.

ORA-28759: сбой при открытии файла

Суть проблемы в том, что Oracle Wallet Manager (OWM) при редактировании wallets меняет разрешения на доступ к файлу. В результате файл становится доступным только пользователю, от которого был запущен OWM.

Решение:
Измените разрешения на доступ к файлу так, чтобы пользователь, от которого работает Oracle DB, имел доступ хотя бы на чтение.

ORA-12154: TNS:could not resolve the connect identifier specified

PL/SQL Developer и Windows x64.

sqlplus

При попытке подключиться с помощью sqlplus, используя Easy Connect, тоже можно получить ошибку:

Для решения убедитесь, что " $ORACLE_HOME/network/admin/sqlnet.ora " или вообще не содержит параметра " NAMES.DIRECTORY_PATH ", или данный параметр имеет одним из значений (или единственным значением) " EZCONNECT ":

Ошибка компиляции при установке Oracle Client

Первоначально пробуем выполнить:

Для Ubuntu 14.04 вероятно придётся пересоздать symlink:

и создать новый:

и снова пробуем выполнить:

SQL Developer, Oracle XE и ORA-12705 в Linux

При попытке настроить Jasper Reports Integration столкнулся с этой же ошибкой при настройке соединения Tomcat. Решается путём создания " $CATALINA_BASE/bin/setenv.sh " с добавлением в него следующих параметров запуска Java:

У меня содержимое файла выглядит так:

Проблемы с external job (sjsec 6a)

В какой-то момент стал получать ошибку:

Это происходило в Oracle, установленном на сервер под управлением Windows.
Решение — убедитесь и при необходимости запустите сервис OracleJobScheduler<SID>.
Где SID — SID вашего экземпляра БД.

ORA-01075 you are currently logged on

Нашёл решение здесь, но решил у себя продублировать. Итак, если при подключении к БД получаем что-то типа:

нужно выполнить следующие шаги:

подключаемся к системе под именем пользователя, от которого запущен Oracle;

SQLDeveloper из Oracle 11g (64 bit) на Windows (64 bit)

Как ни парадоксально, но это решается установкой java 32-bit и добавлением в файл " %ORACLE_HOME%\sqldeveloper\sqldeveloper\bin\sqldeveloper.conf " строки, в которой с помощью SetJavaHome задан JAVA_HOME (путь к java), например так:

ORA-00845: MEMORY_TARGET not supported on this system

На Windows я с такой ошибкой пока не встречался, а на linux решение простое:

правим (или добавляем при остутствии) в " /etc/fstab " строку

Где:
size — размер больше или равен объёму выделяемой для всех экземпляров Oracle памяти. В нашем случае он равен 12Gb (size=12g).

должны получить что-то похожее на следующее:

ORA-12034: materialized view log on "SCHEMA"."MVIEW" younger than last refresh

Можно смотреть ноту 204127.1 на Metlink.
В некоторых случаях помогает:

Проблемы при повторной конфигурации Oracle XE.

Один из вариантов повторной конфигурации Oracle XE заключается в удалении " /etc/sysconfig/oracle-xe " (для Red Hat) и выполнении " /etc/init.d/oracle-xe configure ". Однако, если у вас имеется созданное вами табличное пространство в указанном вами файле данных, выполните обязательно бэкап этого табличного пространства. Указанный скрипт выполнит пересоздание DBID для известных ему файлов данных, но не тронет те, что вы создали. Таким образом, после старта системы вы не сможете ни получить доступ к вашим файлам, ни подключить их к БД, т.к. в них прописаны старые DBID. Будьте внимательнее.

ORA-01704: string literal too long

При работе с Oracle через JDBC, столкнулся с проблемой в виде ошибки "ORA-01704: string literal too long". Оказывается, в некоторых случаях (JDBC — один из них) нельзя просто взять и вставить строку длиной больше 4000 символов в поле таблицы. Даже если это поле типа CLOB. Т.е. не прокатывает строка вида:

Пересоздание сессии в удалённой БД (dblink)

Разработчики стали жаловаться, что, при обращении к объекту, размещённому в удалённой БД, через database link, появляется следующая ошибка:

создаем database link с тем же именем, но с подключением к любому другому серверу (про другую схему того же сервера сказать ничего не могу — не проверял); выполняем любой запрос к удалённой БД через созданный линк; создаём заново линк, но уже с нужными параметрами подключения.

В результате, на требуемом нам сервере будет создана новая сессия. Проблема была решена. Такой вот lifehack.

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

Certificate of the remote server does not match the target address.

Эта заметка относится к Oracle Database 12.2.
В wallet-файле есть необходимый сертификат, но при обращении к ресурсу получаем ошибку:

Ещё один широко известный в узких кругах ресурс:

ORA-27369: job of type EXECUTABLE failed with exit code: 274662

ORA-00392: log 1 of thread 1 is being cleared, operation not allowed

При открытии БД с resetlogs получаем ошибку:

Вероятно, первая команда " alter database open resetlogs " завершилась неудачно и в control-файле redo остались в статусе CLEARING/CLEARING_CURRENT:

Можно попробовать использовать следующие команды:

а затем уже повторить:

На metalink есть документ (Doc ID 1352133.1)

ORA-31640: unable to open dump file "FILENAME" for read

При выполнении импорта средствами Oracle DataPump столкнулся с этой ошибкой (видна в лог-файле). Дамп-файлы были размещены на NFS-разделе, который был смонтирован не совсем корректно. Подсмотрел здесь параметры, которые помогли решить проблему:

Читайте также: