In spite of unlocking several times, my account on oracle database is getting locked each time I try to connect to another user.
I type the following command while I am on root account:
sql> connect hr/hr
And then, I get the following error.
ERROR: ORA-28000: the account is locked
WARNING: You are no longer connected to ORACLE
You are attempting to connect to a locked account:this is not permitted. However, issuing a connect logs you out of your root account (whatever means in an Oracle context).
In order to connect to hr you need to unlock that account. This needs DBA privileges:
alter user hr account unlock;
You can change PASSWORD_LIFE_TIME parameter by using below command.
alter profile default limit PASSWORD_LIFE_TIME unlimited;
Related
Recently, the user has become very often locked. I suspect this is due to the erroneous input of the username and password, but I don’t know how to find out from which computer this happens. Is it possible to get any information about this (for example, IP or username) due to which the user was blocked?
Oracle Database 10g Release 10.2.0.3.0 - Production
It may not be that the user has blocked themselves. This question gives several reasons including:
An appropriately privileged user could issue the command:
ALTER USER user_name ACCOUNT LOCK;
An appropriately privileged user could issue the command:
REVOKE CONNECT FROM user_name;
If could be that the PASSWORD_LIFE_TIME is exceeded, or both that and PASSWORD_GRACE_TIME is exceeded.
User exceeds FAILED_LOGIN_ATTEMPTS
Only 1 of those 4 reasons would have been initiated by the (now) locked user.
The accepted answer to that question states:
Provided audit trail is turned on, then I prefer to use the following to help track down login failures (which is usually the cause of locked accounts):
select * from dba_audit_trail where returncode in (1017, 28000) order by timestamp desc;
returncode is the ORA- error that would be returned from the database: 1017 is "invalid usercode or password" and 28000 is "account is locked".
And then goes on to give more details of how to activate the audit trail if it is not already turned on.
I want to create a new profile in SQL plus.
I started off by creating a user, this worked:
create user myuser
identified by password;
Then I tried to create a profile, this didn't work:
create profile myuserprofile limit
sessions_per_user 2
connect_time 120
idle_time 30
failed_login_attempts 3
password_life_time 365;
This is the errors i received:
ORA-65048: error encountered when processing the current DDL statement in pluggable database XEPDB1
ORA-01435: user does not exist
I tried it on my laptop, the same result.
the next step would be to alter the user to have the profile.
Edit:
I connected as the system and was able to get rid of both the errors:
ORA-65048: error encountered when processing the current DDL statement in pluggable database XEPDB1
ORA-01435: user does not exist
However, the error still arises when I try and create the profile on my user
Edit2:
FIXED
I realised i did not have DBA privileges on my user.
GRANT DBA TO XYZ;
Thanks
Is there a way for a user to terminate one's own session/connections, given an Oracle SID, without DBA rights?
Specifically, I can run this in my DB without admin rights:
SELECT SID, "SERIAL#", STATUS, USERNAME
FROM V$SESSION
WHERE
(USERNAME = 'LastF')
AND
(STATUS = 'INACTIVE');
But when I go to kill my orphaned session (from another session to which I still have access),
ALTER SYSTEM KILL SESSION "12, 123"
I get the following:
JDBC ERROR: ORA-01031: insufficient privileges
Note: I am connecting with JDBC through R/Rstudio using the RJDBC package.
Motivation:
It doesn't appear too difficult to kill sessions in Oracle SQL:
https://docs.oracle.com/cd/B28359_01/server.111/b28310/manproc008.htm#ADMIN11192
How can I kill all sessions connecting to my oracle database?
However, for non-DBA users who have orphaned connections (i.e. internet outage, 3rd party client that manages connections errors out, etc), it can be really frustrating to get:
ORA-02391 exceeded simultaneous SESSIONS_PER_USER limit
and have to wait for timeout.
To successfully run an ALTER SYSTEM command, you don't need to be the DBA, but you do need the ALTER SYSTEM privilege to be granted to you (or to the "user" owning the application through which you connect to the database - which may be different from "you" as the "user" of RStudio).
You have a few options:
ask the DBA to kill the session
ask to be granted the ALTER SYSTEM privilege (which is a very poor practice)
have a "supervisor" (however defined - responsible specifically for these situations) be granted the ALTER SYSTEM privilege, who will be in charge of killing such sessions
(perhaps the best option) create a packaged
procedure whose only task is to kill orphaned sessions. Grant ALTER SYSTEM to the package owner, and grant execute privilege on that
package to individual users (as needed). The procedure should be
written to only kill specific kinds of sessions.
You can use the below to cancel whatever is running in the session
DECLARE
l_status v$session.status%TYPE;
BEGIN
dbms_system.set_ev( &sid, &serial, 10237, 1, '');
LOOP
SELECT status INTO l_status FROM v$session
WHERE sid = &sid and serial# = &serial;
EXIT WHEN l_status='INACTIVE';
END LOOP;
dbms_system.set_ev( &sid, &serial, 10237, 0, '');
END;
you will have to create a direct select grant on sys.v_$session
grant select on v_$session to
Where is the schema that owns the above procedure. This has to be a direct grant and not through a role.
Check the link for more details and given by Donald Burleson
we can kill the oracle session with pid ,
if you are unable to identify the operating system process identifier (spid) from the query , you can issue the following query to help identify the correct session:
SELECT s.sid, s.serial#, p.spid
FROM v$process p, v$session s
WHERE p.addr = s.paddr
AND s.username = '<username>';
At the operating system prompt, issue the kill command and supply the operating system process identifier (spid):
kill <spid>
I am very new to postgres. One of my project is using an RDS postgres instance, the application team created a user and use that user to create the database.
I am trying to grant default privilege to the default postgres user to this application database by running the command below but I am getting an error message.
ALTER DEFAULT PRIVILEGES
FOR USER postgres
IN SCHEMA public
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO postgres;
Error message
ERROR: must be member of role "postgres"
SQL state: 42501
Please advise how I can grant default privilege to postgres user for the database.
You must connect as a superuser to run this command.
I misunderstood my case earlier. Apparently, postgres user was the owner of the database not the app user. So I logged in as postgres and executed the command and it works.
If you did a pgdump to export the database, and then were getting this error on trying to import it. Use -O when creating the pgdump - https://www.postgresql.org/docs/current/app-pgdump.html
I am trying to set up a user in my Oracle 11g database as such
create user BARRY6 IDENTIFIED by password123;
grant connect to BARRY6;
grant create session to BARRY6;
grant UNLIMITED TABLESPACE to BARRY6;
commit;
This should create the user and provides them with the basic permissions.
All commands executes successfully, However i can not connect with this user.
I get an error
An error was encountered performing the requested operation:
ORA-01031: insufficient privileges
01031. 00000 - "insufficient privileges"
*Cause: An attempt was made to perform a database operation without
the necessary privileges.
*Action: Ask your database administrator or designated security
administrator to grant you the necessary privileges
Vendor code 1031
When i view the USER_ROLE_PRIVS table , there is no permissions in that table for my user
This was happening because the role i was trying to login in as was sysdba. While it should be default.
I know, stupid, but it posting the solution in case other people are creating a user and they make this simple mistake. It was caused by loading the sys connection and just changing the password and not changing the role