Ошибка oracle 28000

Вы не сталкивались с такой ошибкой? А я вот на днях столкнулся и хочу поделиться своей историей. Может быть эта информация поможет кому-то из вас быстрее разобраться в похожей ситуации.

Однажды, после окончания планового оффлайн бэкапа, система оказалась недоступна для работы. SAP GUI выдавал сообщение о том, что база данных системы недоступна. 

Первая мысль была: «Ну, наверное, по какой-то причине затянулся бэкап». Но переход на уровень операционной системы сервера показал, что база данных запущена, а процессов резервного копирования в операционной системе нет. Правда, со стороны Oracle работают только фоновые служебные процессы и нет ни одного shadow-процесса. 

Вы наверное знаете, что при оффлайн резервной копии базы данных (или как её ещё называют «холодный» бэкап) процессы ABAP инстанции не останавливаются, а остаются работать, потеряв коннект к базе данных. При этом рабочие процессы с настойчивостью и периодичностью пытаются открыть соединение к базе данных. Поэтому, как только база данных становится доступной для соединения, рабочие процессы открывают соединения, а Oracle запускает для каждого рабочего процесса SAP инстанции отдельный shadow-процесс. Подробнее о том, как рабочие процессы SAP системы подключаются к базе данных я описывал в статьях: «Как рабочие процессы SAP соединяются с базой данных Oracle — I» и «Как рабочие процессы SAP соединяются с базой данных Oracle — II». 

Так вот, shadow-процессов Oracle не наблюдалось. Я подключился к базе данных через SQLPlus, используя пользователя SYSTEM. Соединение установилось успешно. На всякий случай перестартовал базу данных. Проверил: shadow-процессов как не было, так и нет. При этом рабочие процессы SAP инстанции в списке процессов операционной системы висели.

Хорошо. Последний рестарт SAP системы был давно, вдруг что-то подглючило на уровне сервера приложений, подумал я. И решил перезапустить сервер приложений. Но скрипты запуска системы выдают: «База данных не запущена, будем запускать. Попытка запуска базы данных заканчивается ошибкой — «база данных недоступна». Стоит отметить, что скрипты запуска SAP системы для проверки доступности базы данных используют утилиту R3trans, входящую в состав SAP Kernel, запуская её с опцией «-d» (рис. 1 и 2).

Рис. 1. Пример успешной проверки соединения с базой данных.

Рис. 2. Пример безуспешной проверки соединения с базой данных.

Проверка переменных окружения пользователей, настроек Oracle client, процесса Listener ничего не дала. 

И только в третий раз просматривая журналы рабочих процессов SAP инстанции (файлы dev_w*), обратил внимание, что код ошибки при попытках коннекта к Oracle отличается от типичного. Когда база данных остановлена, выдаётся код ошибки 1034. 

Рис. 3. Пример кода ошибки соединения с остановленной базой данных.

А тут выдавался код 28000 (рис. 4). 

Рис. 4. Код ошибки при соединении с базой данных в текущем случае.

По коду ошибки удалось выяснить, что ошибка заключается не в недоступности Oracle, а в блокировке пользователя. Как вы уже знаете, из вышеупомянутых статей, что рабочие процессы SAP системы при подключении к Oracle используют пользователя владельца схемы в базе данных. В данном случае это пользователь SAPSR3. Так вот этот пользователь и оказался заблокированным. 

К блокировке пользователя привёл параметр базы данных Oracle — FAILED_LOGIN_ATTEMPTS. Начиная, с версий Oracle 10g значение данного параметра, по умолчанию, равно 10. В предыдущих версиях СУБД по умолчанию стоит значение UNLIMITED. Посмотреть значение в текущей базе данных можно запросом вида:

или

SQL> show parameter FAILED_LOGIN_ATTEMPTS;

Как вы помните из моего поста, при соединении с базой данных, до версии Oracle 11g в SAP системе использовался механизм хранения пароля пользователя владельца схемы в отдельной табличке OPS$<USER>.SAPUSER. Так как в момент оффлайн бэкапа база данных недоступна, то рабочий процесс не может получить к ней доступ и прочитать продуктивный пароль пользователя. И как видно из скриншота (рис. 3), каждый раз делается ещё и дополнительная попытка открыть соединение с дефолтным паролем, который зашит в коде ядра. Допускаю, что случилась такая ситуация, что в момент старта базы данных было сделано больше 10 попыток логина к базе данных со стороны SAP системы с этим стандартным паролем (который отличается от продуктивного пароля). В результате этого Oracle автоматически заблокировал пользователя (владельца схемы) и последующие попытки SAP системы присоединиться к базе данных проваливались уже по этой причине, вплоть до моего вмешательства. 

Разрешение ситуации: разблокировка пользователя. Разблокировать пользователя можно в SQLPlus командой вида:

SQL> alter user SAPSR3 account unlock;

После этого рабочие процессы корректно подключаются к базе данных. Для предотвращения возникновения ситуации в будущем —  установка параметра в большее значение, вплоть до UNLIMITED. Сделать это можно SQL-командой вида:

P.S. Думаю, что описанная ситуация довольно таки редкая и возможна только в узком круге версий систем SAP и базы данных Oracle. Так как в современных версиях систем пароль хранится уже не в базе, а в файловой системе (подробнее) и попыток попасть в базу данных со стандартным (неверным) паролем не производится. Но в нашей жизни всё бывает и надо быть готовым ко всему.

Ошибка: ORA-28000: the account is locked
Описание: Скорее всего пользователь ввел неверный пароль максимальное количество раз, которое указано в профиле пользователя. Параметр FAILED_LOGIN_ATTEMPTS или пользователь был заблокирован DBA.
Решение: Ждем PASSWORD_LOCK_TIME или начинаем действовать, если конечно у вас есть права DBA. 


Источник: mirsovetov.net

1. Запускаем командную строку и пишем: sqlplus \sys as sysdba;
2. Вводим пароль (по умолчанию для логина sys пароль sys)
3. alter user [USER NAME] account unlock; где  [USER NAME] — Имя заблокированного пользователя
4. Пробуем подключится.

ORA-28000 means that the account that you tried to use is locked because some privileged user disabled the ability of connection, or attempt connections with wrong passwords exceeded the limit.

SQL> conn hr/hr
ERROR:
ORA-28000: The account is locked.

Please note that, schema objects and data of the user can still be used by others, even though the account is locked. In some cases, it could be a good tactic for sharing accounts which do not need logging.

Solution

You can revert the status by unlocking the account. First of all, logging as a privileged user.

SQL> conn / as sysdba
Connected.

And then we can check the status of the account.

SQL> column account_status forma a20;
SQL> select account_status, lock_date from dba_users where username = 'HR';

ACCOUNT_STATUS       LOCK_DATE
-------------------- ---------
LOCKED               23-DEC-19

There’re some ways to solve ORA-28000.

1. ALTER USER ACCOUNT UNLOCK
2. PASSWORD_LOCK_TIME
3. FAILED_LOGIN_ATTEMPTS

ALTER USER ACCOUNT UNLOCK

A simple unlocking can solve ORA-28000 by privileged users. If you can’t do it, please ask DBA to do that.

SQL> alter user hr account unlock;

User altered.

In reality, DBA may lock some inactive accounts for a period of time before actually dropping them. Therefore, if your account is locked, please inform your DBA as soon as possible.

PASSWORD_LOCK_TIME

PASSWORD_LOCK_TIME means that it is allowable to unlock the account automatically after a period of time, if the account lock was triggered by FAILED_LOGIN_ATTEMPTS.

In such situation, you may set a shorter PASSWORD_LOCK_TIME to release the account lock automatically, say 5 minutes.

SQL> alter profile default limit password_lock_time 5/1440;

Profile altered.

In this case, we set the lock time to a shorter period, 5 minutes.

By the way, a locked account which is waiting for automatic unlock has ASTATUS 4.

FAILED_LOGIN_ATTEMPTS

FAILED_LOGIN_ATTEMPTS means that how many times of failed login attempts are allowed before locking the account. Yes, the account will be locked if the number of consecutive failed attempts meets the value.

When ORA-28000 becomes too often, you may also consider to remove the restriction of FAILED_LOGIN_ATTEMPTS by setting it to UNLIMITED.

SQL> alter profile default limit failed_login_attempts unlimited;

Profile altered.

Please note that, some native accounts are initially locked by the database to protect them from unauthorized access. This is designed scheme.

For expired password of accounts, you shall see ORA-28001: the password has expired.

Вы не сталкивались с такой ошибкой? А я вот на днях столкнулся и хочу поделиться своей историей. Может быть эта информация поможет кому-то из вас быстрее разобраться в похожей ситуации.

Однажды, после окончания планового оффлайн бэкапа, система оказалась недоступна для работы. SAP GUI выдавал сообщение о том, что база данных системы недоступна. 

Первая мысль была: «Ну, наверное, по какой-то причине затянулся бэкап». Но переход на уровень операционной системы сервера показал, что база данных запущена, а процессов резервного копирования в операционной системе нет. Правда, со стороны Oracle работают только фоновые служебные процессы и нет ни одного shadow-процесса. 

Вы наверное знаете, что при оффлайн резервной копии базы данных (или как её ещё называют «холодный» бэкап) процессы ABAP инстанции не останавливаются, а остаются работать, потеряв коннект к базе данных. При этом рабочие процессы с настойчивостью и периодичностью пытаются открыть соединение к базе данных. Поэтому, как только база данных становится доступной для соединения, рабочие процессы открывают соединения, а Oracle запускает для каждого рабочего процесса SAP инстанции отдельный shadow-процесс. Подробнее о том, как рабочие процессы SAP системы подключаются к базе данных я описывал в статьях: «Как рабочие процессы SAP соединяются с базой данных Oracle — I» и «Как рабочие процессы SAP соединяются с базой данных Oracle — II». 

Так вот, shadow-процессов Oracle не наблюдалось. Я подключился к базе данных через SQLPlus, используя пользователя SYSTEM. Соединение установилось успешно. На всякий случай перестартовал базу данных. Проверил: shadow-процессов как не было, так и нет. При этом рабочие процессы SAP инстанции в списке процессов операционной системы висели.

Хорошо. Последний рестарт SAP системы был давно, вдруг что-то подглючило на уровне сервера приложений, подумал я. И решил перезапустить сервер приложений. Но скрипты запуска системы выдают: «База данных не запущена, будем запускать. Попытка запуска базы данных заканчивается ошибкой — «база данных недоступна». Стоит отметить, что скрипты запуска SAP системы для проверки доступности базы данных используют утилиту R3trans, входящую в состав SAP Kernel, запуская её с опцией «-d» (рис. 1 и 2).

Рис. 1. Пример успешной проверки соединения с базой данных.

Рис. 2. Пример безуспешной проверки соединения с базой данных.

Проверка переменных окружения пользователей, настроек Oracle client, процесса Listener ничего не дала. 

И только в третий раз просматривая журналы рабочих процессов SAP инстанции (файлы dev_w*), обратил внимание, что код ошибки при попытках коннекта к Oracle отличается от типичного. Когда база данных остановлена, выдаётся код ошибки 1034. 

Рис. 3. Пример кода ошибки соединения с остановленной базой данных.

А тут выдавался код 28000 (рис. 4). 

Рис. 4. Код ошибки при соединении с базой данных в текущем случае.

По коду ошибки удалось выяснить, что ошибка заключается не в недоступности Oracle, а в блокировке пользователя. Как вы уже знаете, из вышеупомянутых статей, что рабочие процессы SAP системы при подключении к Oracle используют пользователя владельца схемы в базе данных. В данном случае это пользователь SAPSR3. Так вот этот пользователь и оказался заблокированным. 

К блокировке пользователя привёл параметр базы данных Oracle — FAILED_LOGIN_ATTEMPTS. Начиная, с версий Oracle 10g значение данного параметра, по умолчанию, равно 10. В предыдущих версиях СУБД по умолчанию стоит значение UNLIMITED. Посмотреть значение в текущей базе данных можно запросом вида:

или

SQL> show parameter FAILED_LOGIN_ATTEMPTS;

Как вы помните из моего поста, при соединении с базой данных, до версии Oracle 11g в SAP системе использовался механизм хранения пароля пользователя владельца схемы в отдельной табличке OPS$<USER>.SAPUSER. Так как в момент оффлайн бэкапа база данных недоступна, то рабочий процесс не может получить к ней доступ и прочитать продуктивный пароль пользователя. И как видно из скриншота (рис. 3), каждый раз делается ещё и дополнительная попытка открыть соединение с дефолтным паролем, который зашит в коде ядра. Допускаю, что случилась такая ситуация, что в момент старта базы данных было сделано больше 10 попыток логина к базе данных со стороны SAP системы с этим стандартным паролем (который отличается от продуктивного пароля). В результате этого Oracle автоматически заблокировал пользователя (владельца схемы) и последующие попытки SAP системы присоединиться к базе данных проваливались уже по этой причине, вплоть до моего вмешательства. 

Разрешение ситуации: разблокировка пользователя. Разблокировать пользователя можно в SQLPlus командой вида:

SQL> alter user SAPSR3 account unlock;

После этого рабочие процессы корректно подключаются к базе данных. Для предотвращения возникновения ситуации в будущем —  установка параметра в большее значение, вплоть до UNLIMITED. Сделать это можно SQL-командой вида:

P.S. Думаю, что описанная ситуация довольно таки редкая и возможна только в узком круге версий систем SAP и базы данных Oracle. Так как в современных версиях систем пароль хранится уже не в базе, а в файловой системе (подробнее) и попыток попасть в базу данных со стандартным (неверным) паролем не производится. Но в нашей жизни всё бывает и надо быть готовым ко всему.

Account status in dba_users show open but connection on Standby fails as ‘ORA-28000: the account is locked’ (Doc ID 2440122.1)

Last updated on OCTOBER 10, 2022

Applies to:

Symptoms

Account status in dba_users show open but connection fails as ‘account locked’.

When connecting to the user via sqldevelope or sqlplus, we are getting user account is locked. This is for standby ADG database
SQL> select username,account_status from dba_users where username=’USER1′;

SQL> SQL> conn USER1
Enter password:
ERROR:
ORA-28000: the account is locked

SQL> select open_mode,controlfile_type from v$database;

OPEN_MODE CONTROL
——————— ——-
READ ONLY WITH APPLY STANDBY

Cause

To view full details, sign in with your My Oracle Support account.

Don’t have a My Oracle Support account? Click to get started!

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.

Oracle offers a comprehensive and fully integrated stack of cloud applications and platform services. For more information about Oracle (NYSE:ORCL), visit oracle.com. пїЅ Oracle | Contact and Chat | Support | Communities | Connect with us | | | | Legal Notices | Terms of Use

Источник

sidadm

записки SAP Basis консультанта

Полезное

24 сентября 2020 г.

Ошибка ORA-28000: the account is locked

Рис. 1. Пример успешной проверки соединения с базой данных.

Рис. 2. Пример безуспешной проверки соединения с базой данных.

Рис. 3. Пример кода ошибки соединения с остановленной базой данных.

Рис. 4. Код ошибки при соединении с базой данных в текущем случае.

SQL> select LIMIT from DBA_PROFILES where PROFILE=’DEFAULT’ AND RESOURCE_NAME=’FAILED_LOGIN_ATTEMPTS’;

SQL> alter user SAPSR3 account unlock;

SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS 50;

4 комментария:

Спасибо за статью! Очень полезно.
Скажите, пожалуйста, у меня после миграции системы с Оracle10 на oracle12 получилась такая ситуация, что через полгода истек пароль на пользователя подключения к базе
ERROR: Connect to SAP failed (20200817003713, ORA-28001: the password has expired).
Похожая ошибка, что и описаная в статье, но тут expired.
Не сталкивались ли вы с таким? Есть какой-то способ этой ошибки избежать? Спасибо!

Ruslan, добрый день. Я не сталкивался. Но судя по быстрому поиску за это отвечает параметр PASSWORD_LIFE_TIME, который с Oracle 11 стал иметь значение по умолчанию = 180 дней. Варианта решения я вижу два: поменять значение параметра, а пользователя разблокировать командой, приведённой в статье. Посмотрите вот тут — https://www.stechies.com/error-ora28001-password-expired-during-system-startup/
SQL-команда отключения периода действия пароля примерно такая:
alter profile default limit password_life_time unlimited;
На сколько установка такого значения корректна со стороны рекомендаций SAP, я сходу не нашёл.
Либо второе решение — запланировать периодическую смену пароля владельца схемы. Через BRTools. Такое решение отвечает требованиям безопасности.

Спасибо большое! Все действительно оказалось довольно просто. Всего две команды
SELECT resource_name,limit FROM dba_profiles WHERE profile=’DEFAULT’ AND resource_name=’PASSWORD_LIFE_TIME’; смотрим
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED; меняем
Спасибо!

Источник

IT World

RDBMS, Unix and many more…

Who is locking your accounts (ORA-01017 and ORA-28000 errors) ?

Table of contents

Preamble

I have decided to write this blog post after second time I received question on how to know from where are coming connections that are locking an account in an Oracle database…

Do not smile, I have seen at least two situations where, after a password change, a batch job was initiating plenty of connection (with previous wrong password) and no one was able to know from where this batch job was running (!!).

As a reminder, with default profile in Oracle 11g, accounts are automatically locked 1 day (PASSWORD_LOCK_TIME) after 10 failed login attempt (FAILED_LOGIN_ATTEMPTS):

SQL> set lines 200 SQL> set pages 200 SQL> select * from dba_profiles where profile=’DEFAULT’ order by resource_name; PROFILE RESOURCE_NAME RESOURCE LIMIT —————————— ——————————— ——— —————————————- DEFAULT COMPOSITE_LIMIT KERNEL UNLIMITED DEFAULT CONNECT_TIME KERNEL UNLIMITED DEFAULT CPU_PER_CALL KERNEL UNLIMITED DEFAULT CPU_PER_SESSION KERNEL UNLIMITED DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10 DEFAULT IDLE_TIME KERNEL UNLIMITED DEFAULT LOGICAL_READS_PER_CALL KERNEL UNLIMITED DEFAULT LOGICAL_READS_PER_SESSION KERNEL UNLIMITED DEFAULT PASSWORD_GRACE_TIME PASSWORD 7 DEFAULT PASSWORD_LIFE_TIME PASSWORD 180 DEFAULT PASSWORD_LOCK_TIME PASSWORD 1 DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD NULL DEFAULT PRIVATE_SGA KERNEL UNLIMITED DEFAULT SESSIONS_PER_USER KERNEL UNLIMITED 16 rows selected.

Oracle client session will received 10 times ORA-01017: invalid username/password; logon denied error message and then ORA-28000: the account is locked error message (for one day and then back to ORA-01017 error message).

The final question is how to identify from where (client IP address/name) are coming those tentative connections… I have done my testing using Oracle 11.2.0.3 running on Oracle Linux Server release 6.3.

ORA-01017/ORA-28000 with AUDIT_TRAIL

The first and preferred solution is with Oracle standard auditing feature. Start by setting initialization parameter AUDIT_TRAIL to db and restart your Oracle database as it is static parameter.

Then activate network auditing with (as SYS):

SQL> audit network by access; Audit succeeded.

With below query you get everything needed:

select * from dba_audit_session order by sessionid desc;

Returncode column contains Oracle error code and so different of 0 if logon/logoff issue. The invalid password is the error we are chasing:

]$ oerr ora 1017 01017, 00000, «invalid username/password; logon denied» // *Cause: // *Action:

So if you find 1017 values in this column then we have found what we were looking for. For example with my test case where I intentionally specify a wrong password for my account:

SQL> select username,userhost,returncode from dba_audit_session where username=’YJAQUIER’ order by sessionid desc; USERNAME USERHOST RETURNCODE —————————— ——————— ———- YJAQUIER server1 1017 YJAQUIER GVADT30596 0 YJAQUIER server1 0 YJAQUIER server1 0 . . .

And if you insist, as explained, you get:

SQL> select username, account_status,lock_date, profile from dba_users where username=’YJAQUIER’; USERNAME ACCOUNT_STATUS LOCK_DATE PROFILE —————————— ——————————— ——————— —————————— YJAQUIER LOCKED(TIMED) 23-nov-2012 10:30:37 DEFAULT

If you set AUDIT_TRAIL to db behave the size of SYS.AUD$ table as a small list of audits are already implemented by default:

SQL> set lines 200 SQL> set pages 200 SQL> select * from DBA_STMT_AUDIT_OPTS; USER_NAME PROXY_NAME AUDIT_OPTION SUCCESS FAILURE —————————— —————————— —————————————- ———- ———- ALTER SYSTEM BY ACCESS BY ACCESS SYSTEM AUDIT BY ACCESS BY ACCESS CREATE SESSION BY ACCESS BY ACCESS CREATE USER BY ACCESS BY ACCESS ALTER USER BY ACCESS BY ACCESS DROP USER BY ACCESS BY ACCESS PUBLIC SYNONYM BY ACCESS BY ACCESS DATABASE LINK BY ACCESS BY ACCESS ROLE BY ACCESS BY ACCESS PROFILE BY ACCESS BY ACCESS CREATE ANY TABLE BY ACCESS BY ACCESS ALTER ANY TABLE BY ACCESS BY ACCESS DROP ANY TABLE BY ACCESS BY ACCESS CREATE PUBLIC DATABASE LINK BY ACCESS BY ACCESS GRANT ANY ROLE BY ACCESS BY ACCESS SYSTEM GRANT BY ACCESS BY ACCESS ALTER DATABASE BY ACCESS BY ACCESS CREATE ANY PROCEDURE BY ACCESS BY ACCESS ALTER ANY PROCEDURE BY ACCESS BY ACCESS DROP ANY PROCEDURE BY ACCESS BY ACCESS ALTER PROFILE BY ACCESS BY ACCESS DROP PROFILE BY ACCESS BY ACCESS GRANT ANY PRIVILEGE BY ACCESS BY ACCESS CREATE ANY LIBRARY BY ACCESS BY ACCESS EXEMPT ACCESS POLICY BY ACCESS BY ACCESS GRANT ANY OBJECT PRIVILEGE BY ACCESS BY ACCESS CREATE ANY JOB BY ACCESS BY ACCESS CREATE EXTERNAL JOB BY ACCESS BY ACCESS

So you must put in place a purging policy for this table.

ORA-01017/ORA-28000 without AUDIT_TRAIL

The only drawback of the previous solution is that you have to restart the database. And maybe two times because after problem solved you would like to deactivate auditing. This is most probably not reliable solution on a production database so I have been looking for a better solution with no database reboot.

I initially thought of the AFTER LOGON trigger but you need to be logged-in and the BEFORE LOGON does not exits. Then at same documentation place I found the AFTER SERVERERROR trigger and decided to give it a try.

First I created a dummy table to log server error (columns inherited from dba_audit_session dictionary table):

create table sys.logon_trigger ( USERNAME VARCHAR2(30), USERHOST VARCHAR2(128), TIMESTAMP DATE );

Second I created below trigger:

CREATE OR REPLACE TRIGGER sys.logon_trigger AFTER SERVERERROR ON DATABASE BEGIN IF (IS_SERVERERROR(1017)) THEN insert into logon_trigger values(SYS_CONTEXT(‘USERENV’, ‘AUTHENTICATED_IDENTITY’), SYS_CONTEXT(‘USERENV’, ‘HOST’), sysdate); commit; END IF; END; /

Then third simulated a wrong password access with my account and issued:

Источник

Разблокировка и доступ к пользователю HR в Oracle Database 18c Express Edition

В посте рассматривается способ разблокировки и доступа к учебному и тестовому пользователю (схемы) HR в базе данных Oracle Database 18c Express Edition. Рассмотрены следующие вопросы:

• Краткий обзор Multitenant архитектуры
• Разблокировка пользователя HR

Краткий обзор Multitenant архитектуры На сегодняшний день последней актуальной версией бесплатной редакции Oracle Database является Oracle Database 18c Express Edition. Данная версия выпущена в 2018 году. Предыдущая версия бесплатной редакции была Oracle Database 11g Express Edition. В Oracle Database 18c Express Edition включены многие важные опции наиболее функциональной редакции Oracle Database – Oracle Database Enterprise Edition. Ниже приведены некоторые основные опции, которые доступны также в Oracle Database 18c Express Edition:

• Multitenant
• Flashback Table
• Flashback Database
• Oracle Partitioning
• In-Memory Column Store и Aggregation
• Advanced Analytics и Security
• Online Index Rebuild
• Online Table Redefinition
• Query Results Cache и PL/SQL Function Result Cache
• Oracle Advanced Compression
• Materialized View Query Rewrite
• Oracle Spatial and Graph
• Bitmap Indexes

Для подключения к схеме HR в Oracle Database 18c Express Edition необходимо понимать принцип работы новой опции Multitenant. Начиная с Oracle Database 12с поддерживается новая архитектура – Multitenant, которая предоставляет возможность использовать множество баз данных для консолидации их в составе единой и главной базы данных. Такая консолидация упрощает задачи администрирования баз данных. Единая и главная база данных используется в качестве платформы и называется контейнерная база данных (Container Database – CDB), а база данных из множества работающих в составе контейнерной базы данных называется подключаемой базой данных (Pluggable Database – PDB). Архитектура Multitenat позволяет создать в Oracle Database 18с Express Edition одну CDB базу и до трех PDB баз. Архитектура Oracle Database 11g Express Edition предоставляет возможность создать одну и единственную базу. В Oracle Database 18с Express Edition учебная и тестовая схема (пользователь) HR, которая содержит взаимосвязанные таблицы и данные, располагается в составе PDB. В связи с этим, чтобы подключиться к базе данных под этой учетной записью, необходимо войти в PDB, разблокировать пользователя HR и назначить ему пароль. Ниже пошагово описываются шаги подключения к CDB, PDB и манипуляция настроек пользователя с помощью SQLPlus и SQLDeveloper.

Разблокировка пользователя (схемы) HR

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

Вариант разблокировки с помощью SQL*Plus.

Шаг 1. Подключение к CDB

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

Подключение успешно прошло к CDB. Далее проверяется имя и идентификатор CDB.

Результат запроса показывает, что CDB имеет имя XE и ее уникальный идентификатор = 0. По умолчанию, после установки Oracle Database 18c Express Edition есть одна PDB с именем XEPDB1. Следующий запрос покажет существующие PDB.

Активная PDB имеет имя XEPDB1 с идентификатором 3 и ее режим работы определен как READ WRITE. OPEN MODE – READ WRITE означает, что база данных (БД) открыта и готова работать в режиме чтения и записи. PDB$SEED используется CDB как шаблон для создания новых PDB баз.

Проверяется наличие пользователя HR в CDB.

Запрос не вернул данные. Это означает, что пользователя HR нет в CDB. Далее необходимо подключиться к PDB и найти там HR.

Шаг 2. Подключение к PDB

Есть два способа подключиться к PDB с использованием SQL*Plus.

Способ 1. Находясь в CDB, подключиться к PDB используя команду alter session. В примере ниже происходит переключение из сеанса CDB к PDB с именем XEPDB1:

Переключение прошло успешно. Для того, чтобы удостовериться в корректности подключения, проверяется имя и идентификатор PDB базы:

Запросы показывают характеристики существующей PDB (Шаг 1.).

Способ 2. Можно подключиться к PDB с консоли операционной системы, указав параметры подключения.

Ниже выполняется подключение к PDB под пользователем sys с указанием IP адреса сервера БД, порта и имени PDB (по умолчанию для созданной PDB (XEPDB1) используется порт 1539):

Подключение прошло успешно.

Для информации: Администраторы баз данных временами выполняют подключение к БД используя аутентификацию на уровне операционной системы с помощью команды sqlplus / as sysdba и без указания пароля. При запуске этой команды в среде с Multitenant архитектурой будет осуществлено подключение к CDB. Для того, чтобы напрямую подключиться к PDB минуя CDB, используется sqlplus / as sysdba и без указания пароля, также необходимо в переменную среду операционной системы добавить новый системный параметр ORACLE_PDB_SID и в его значении указать название PDB. Этот параметр для подключения к PDB без указания пароля могут осуществлять только пользователи sys и system. Остальные пользователи будут автоматически подключены к CDB, если не укажут параметры подключения к PDB. Ниже описываются шаги подключения к PDB для пользователя sys с применением параметра ORACLE_PDB_SID в переменной среде операционной системы. Это очень удобный способ для администраторов баз данных:

Подключение к PDB прошло успешно напрямую из операционной системы без указания пароля и параметров подключения PDB. Далее проверяется имя и идентификатор PDB.

После успешного подключения к PDB c использованием одного из двух способов определяется наличие пользователя HR, а также его статус.

Запускается запрос поиска пользователя HR среди всех существующих пользователей в XEPDB1:

Получен результат, подтверждающий наличие пользователя HR в PDB.

При помощи запроса определяется имя, статус и дата блокировки пользователя HR:

Результат запроса показывает, что статус пользователя «заблокирован» и пароль просрочен (необходимо задать новый пароль) – EXPIRED & LOCKED. Первоначальная дата блокировки равна дате установки Oracle Database 18c Express Edition.

Шаг 3. Разблокировка пользователя HR

После установки Oracle Database 18c Express Edition учетная запись HR заблокирована и пароль у нее просрочен (необходимо задать новый пароль) (см. предыдущий шаг – Шаг 2.). В этом случае, система позволяет сделать запросы к объектам HR (таблицам, представлениям, функциям и т.п.) от имени других пользователей при наличии соответствующих привилегий. Например, при выполнении запроса на определение количества строк в таблице EMPLOYEES пользователя HR под пользователем SYS система успешно выдаст следующий результат:

Для пользователя HR назначается новый пароль:

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

Необходимо заново подключиться к PDB под пользователем sys:

и разблокировать пользователя HR следующей командой:

Операции назначения пароля и разблокировки пользователя HR прошли успешно. Проверяется статус пользователя:

Пользователь HR разблокирован и новый пароль активен. Это означает, что теперь можно подключиться к PDB с именем XEPDB1 под учебным тестовым пользователем HR и начать работу.

Шаг 4. Подключение к PDB с учетной записью HR.

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

На этом завершается определение наличия пользователя, назначение ему пароля и разблокировка HR в PDB Oracle Database 18c Express Edition, а также выполнение запроса к его объекту с помощью SQL*Plus.

Вариант разблокировки с помощью SQL Developer.

Шаг 1. Подключение к CDB

Для этого создается новое подключение в SQL Developer и указываются необходимые параметры подключения к CDB, такие как:

Name: XE_18c
Указывается имя соединения, которое позволяет однозначно идентифицировать CDB при подключении.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XE
SID или имя CDB.

Username: sys
Указывается имя пользователя для подключения к БД.

Role: SYSDBA
Подключение к БД осуществляется пользователем sys. Данный пользователь может подключиться только с ролью SYSDBA.

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

После нажатия Connect произойдет успешное подключение к CDB с именем XE. Далее проверяется имя, идентификатор и версия CDB, а также выводятся существующие PDB.

Как и ожидалось, выведенные выше данные идентичны полученным с помощью SQL*Plus.

Далее проверяется наличие пользователя HR в CDB.

Запрос не вернул данные, это означает, что пользователя HR нет в CDB. Теперь необходимо подключиться к PDB и проверить наличие HR в PDB.

Шаг 2. Подключение к PDB

Создается новое подключение в SQL Developer и указываются необходимые параметры подключения к подключаемой базе данных XEPDB1, такие как:

Name: XEPDB1_18c
Указывается имя соединения, которое позволяет однозначно идентифицировать PDB при подключении.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XEPDB1
SID или имя PDB.

Username: sys
Указывается имя пользователя для подключения к БД.

Role: SYSDBA
Подключение к БД осуществляется пользователем sys. Данный пользователь может подключиться только с ролью SYSDBA.

Password:
Пароль пользователя sys, который был назначен во время установки базы данных. Пользователи sys и system могут подключиться с одним и тем же паролем и к CDB и к PDB.

После нажатия Connect произойдет успешное подключение к подключаемой БД XEPDB1. Далее проверяется имя и идентификатор.

Результаты показывают, что было подключение к PDB с именем XEPDB1 и идентификатором 3. Определяется наличие пользователя HR в этой PDB. В иерархии дерева надо выбрать «Other Users» в соединении с именем XEPDB1_18c как показано на скриншоте:

В списке пользователей необходимо найти пользователя HR и нажать на правую кнопку. Из контекстного меню выбрать «Edit User». Откроется новое модальное окно «Edit User» как показано на скриншоте. Как видно на скриншоте учетная запись HR заблокирована (Account is Locked) и пароль у нее просрочен (Password Expired):

Шаг 3. Разблокировка пользователя HR:

В продолжение предыдущего шага необходимо:

1. Задать идентичный пароль в полях New Password (новый пароль) и Confirm Password (подтвердить пароль).
2. Снять галочку из пункта Password Expired (user must change next login).
3. Снять галочку из пункта Account is Locked для разблокировки пользователя.
4. Нажать Apply.

Пользователь HR разблокирован и ему назначен пароль. Это означает, что теперь можно подключиться к PDB с именем XEPDB1 под учебным тестовым пользователем HR и начать работу.

Шаг 4. Подключение к PDB с учетной записью HR.

Создается новое подключение в SQL Developer и указываются необходимые параметры подключения к подключаемой базе данных XEPDB1 с пользователем HR, такие как:

Name: XEPDB1_18c_hr
Указывается имя соединения, которое позволяет однозначно идентифицировать PDB при подключении с пользователем HR.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XEPDB1
SID или имя PDB.

Username: HR
Указывается имя пользователя для подключения к БД.

Role: default
Подключение к БД осуществляется пользователем HR. Данный пользователь не может использовать роль SYSDBA.

Password:
Пароль, который был назначен пользователю HR на третьем шаге, то есть hr.

После нажатия Connect произойдет успешное подключение к PDB с именем XEPDB1 под пользователем HR. Выполняется запрос для определения количества строк в таблице EMPLOYEES:

На этом завершается определение наличия пользователя, назначение ему пароля и разблокировка HR в PDB Oracle Database 18c Express Edition, а также выполнение запроса к его объекту с помощью SQL Developer.

Источник