When encountering this error, we generally think that the database user is locked, and we only need to execute the user unlock to recover, but the reason why it is written here is because of a strange problem.
Yesterday afternoon, I received a colleague's information, saying that a user's connection report was locked. After communication, I found that it was actually connected to an ADG standby database as a read-only user to query data. So I logged in and checked the relevant database server information provided by him, and found that the account was not locked. , but it does report ORA-28000: the account is locked when trying to log in through its account and password.
1. Error phenomenon
SQL> conn dbuser/dbuser; ERROR: ORA-28000: the account is locked
Second, the reason for the error
The user logs in with an incorrect password, which exceeds the failed login limit, resulting in the user being locked.
3. Processing process
1. Log in to the standby database and view the database user dictionary
The account is in the open state, why is the user locked? Log in to the main database to check that the account is still normal, but the information that is not locked by logging in with the username and password
This is strange, the user is not locked, the main database can log in, why does the standby database show that it is locked? Could it be that multiple login failures of the standby database cause the user to be locked, because the data dictionary cannot record the locking information because the standby database is read-only?
After testing, it is found that logging in with the wrong user password in the standby database will cause the account of the standby database to be locked, but the account lock information will not be recorded in the dictionary, and the main database can log in normally.
Login Statistics
select name,LCOUNT from user$ where name='DBUSER';
2. Unlock the standby database user
alter user dbuser account unlock;
Log in again and you can log in. But try again after a few minutes, still prompted to be locked.
3. Try restarting database recovery
After restarting, the user returned to normal, but after a while, the user was prompted to be locked.
4. Zoom in, change the user profile, and make the login failure unlimited
View the password and login restrictions of the user's corresponding profile
set line 200;
set pagesize 2000;
col resource_name for a30;
col profile for a18;
col limit for a15;
select a.username,a.profile,b.resource_name,b.limit from dba_users a,dba_profiles b where a.profile=b.profile and b.resource_name='FAILED_LOGIN_ATTEMPTS' and a.username='APP_BG';
Change User Login Restrictions
SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS UNLIMITED; Profile altered.
5. Issue tracking
Which IP has been trying to log into the database with an incorrect password? We can traceroute in several ways. We can log in to audit (because it is a standby database, so we need to enable system-level auditing), and we can analyze the information connected to the database through tcpdump packet capture. What is done here is to complete the problem tracking in the way of database auditing. The specific methods are as follows:
1) Determine the user status
select username, ACCOUNT_STATUS ,LOCK_DATE ,expiry_date from dba_users order by lock_date desc ;
2) View audit information
show parameter audit;
audit_sys_operations boolean FALSE
audit_syslog_level string
audit_trail string NONE
found that auditing is not turned on
Enable database auditing
alter system set audit_sys_operations = TRUE scope = spfile; --Audit management account, generally set false alter system set audit_trail = os,extended scope = spfile; restart the database
3) Track audit logs
show parameter audit_file_dest
4) Analyze the user, IP address, etc. connected to the audit log
If you are using DB-level auditing, you can view the login audit information through the following statement
SELECT username,TIMESTAMP,os_username,userhost, OS_PROCESS,RETURNCODE FROM sys.dba_audit_session WHERE returncode != 0 AND TIMESTAMP>='2015-12-09 13:25:00' ;
4. Appendix
1. Reference documents
There is an article saying that an article on mos said that this problem is due to the main library (after testing, it is found that there is a problem with this description, please ignore it)
ORA - 28000 On Active Data Guard (Doc ID 1922621.1 ) In this Document Symptoms Cause Solution References APPLIES TO: Oracle Database - Enterprise Edition - Version 11.2.0.1 and later Information in this document applies to any platform. SYMPTOMS Noticed one user account was locked in primary and its Active Data Guard instances. It was fine Primary Database after unlocking the User, but at the Active Data Guard Standby Database, it was showing ORA-28000 that the account is still locked. Followed Note 1600401.1: ORA-28000 "the account is locked" in the standby database, even after the account was unlocked in the primary but it is still unlocked and user can not connect to standby database. Here is log:
2. Database Audit
Audit_trail：
None: is the default value, no auditing;
DB: record the audit trail in the audit-related table of the database, such as aud$, the audit result only has connection information;
DB, Extended: In this way, in addition to the connection information, the audit result also contains the specific statement executed at that time;
OS: Record the audit trail in the operating system file, the file name is specified by the audit_file_dest parameter;
xml: Added in 10g.
Note: These two parameters are static parameters and need to restart the database to take effect.
When the audit function is turned on, the database can be audited at three levels: Statement (statement), PRivilege (authority), and object (object).
( 1 ) Statement audit AUDIT SELECT TABLE BY username ; AUDIT SESSION BY jeff, lori; ( 2 ) Authority audit AUDIT DELETE ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL; AUDIT DELETE ANY TABLE; AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE BY ACCESS WHENEVER NOT SUCCESSFUL; ( 3 ) Object Audit AUDIT DELETE ON jeff.emp; AUDIT SELECT, INSERT, DELETE ON jward.dept BY ACCESS WHENEVER SUCCESSFUL; ( 4 ) Cancel the audit NOAUDIT session; NOAUDIT session BY jeff, lori; NOAUDIT DELETE ANY TABLE; NOAUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE,EXECUTE PROCEDURE; NOAUDIT ALL ; -- Cancel all statement audits NOAUDIT ALL PRIVILEGES ; -- Cancel all privilege audits NOAUDIT ALL ON DEFAULT ; -- Cancel all object audits ( 5 ) Clear audits DELETE FROM SYS.AUD$; DELETE FROM SYS.AUD$ WHERE obj $name = ' EMP ' ; ( 6 ) Audit View USER_AUDIT_STATEMENT -- statement audit USER_AUDIT_SESSION -- session audit USER_AUDIT_OBJECT -- audit object list USER_AUDIT_TRAIL -- audit record ( 7 ) Move the audit result table from the system table space to another table space In fact, the sys.aud$ table contains two lob fields, not a simple move table. The following is the specific process: alter table sys.aud$ move tablespace users; alter table sys.aud$ move lob(sqlbind) store as( tablespace USERS); alter table sys.aud$ move lob(SQLTEXT) store as( tablespace USERS); alter index sys.I_AUD1 rebuild tablespace u ;