How to get value of database session expire time?
I have session that I want to kill, but I don't have enough privileges to do it.
I can see the session in v$session:
SELECT * FROM v$session where osuser = 'osuser' and username='username';
As far as I understand session expire time is set in sqlnet.ora. (Obviously I don't have access to check.) Is there any select that I can execute to get the value of session expire time?
I'm using Oracle Database 10g.
Yes, indeed, SQLNET.EXPIRE_TIME is set in the sqlnet.ora configuration file.
Is there any select that I can execute to get the value of session
expire time?
Unfortunately no, there is no data dictionary view available that would allow you to display content of the sqlnet.ora. So, if you have no access to the file to view its content, and also has not been granted alter system privilege, you probably should ask your system administrator or DBA for help.
Related
I'm working on a website where a user is only allowed to have a single signed-in session. If a user attempts to authenticate to the website from more than one location the prior session is logged out.
The session information for a given user will be stored in Redis.
My current implementation uses two Redis databases. The first database stores session ID as the key and username as the value. The second database stores the username as the key and some other information including session ID as the value.
When a user logs in, the second Redis database is queried to find an existing session ID. If found, the old session is deleted, this would essentially force the user's old session to log out. After the old session is removed, we create another session in the first database and update the value of the session ID in the second database using the username as the key.
Here is a demonstration of this behavior using the "redis-cli":
redis-cli
select 2
get username
The website gets the session ID of the previous session and then generates a new session ID...
redis-cli
select 1
del old_session_id
set new_session_id username
select 2
set username new_session_id
This works, but I want to optimize it. In this solution, the website would query Redis twice because we have to get the old session id and delete it.
My question is: Can we combine the two queries?
My challenge is how to read the command get username result and automatically run del old_session_id against the Redis database.
Can anybody help me?
According to the SET documentation, you can add the GET option to write a key and get its old value. I would use this on database 2 first. If it returns an old session id, you can use RENAME to change the key name. If it doesn't return an old session id, you can just use another SET.
You should be able to get your setup to work with something like this:
redis-cli
select 2
set username new_session_id get
If that command returns a value, run this:
redis-cli
select 1
rename old_session_id new_session_id
If it does not return a value, run this:
redis-cli
select 1
set new_session_id username
thank for taking the time to try answer/understand this question.
I am using AWS Aurora Postgres (Engine version: 13.4) database.
I referred to this document for creating readwrite and readonly roles for 2 new rdsiam users -> "dev_ro" and "dev_rw". I have granted readwrite role to "dev_rw" and readonly to "dev_ro". The additional changes are:
myschema is "public" - which is my default schema
I add the same permissions as "myschema" to another schema called "graphile_worker" (from graphile/worker - which is a job queue).
With this in mind, here is what I have done:
I run my application which adds some repeating jobs (jobs schedule itself), implying that the jobs table can never be empty
Connect to RDS using the IAM user (doesn't matter dev_ro or dev_rw)
I run SELECT * FROM graphile_worker.jobs in my IDE (dbeaver - shouldn't matter, I think)
The table shows up empty
Disconnect and Re-connect to RDS using superuser credentials (which are created when server is created)
Run same query as above
See data in the table
I don't know why this is happening.
I double-checked, both "dev_ro/w" (through the roles) and superuser, have:
CONNECT to database (without doubt)
SELECT on all tables of graphile_worker schema
USAGE on the graphile_worker schema
Moreover, I can query graphile_worker.migrations and the migration records show up as expected (on both devro/w and superuser)!
Please let me know if there is any more information that I can provide to help debug this issue.
Removing Row-Level Security (RLS) solved this issue.
Thanks #Hambone for asking the right question.
RLS is removed by executing
ALTER ROLE <username> WITH BYPASSRLS
I have a group login which has the Server Role "dbcreator". Users of this login has been granted execute on "sp_delete_database_backuphistory" so that they can delete each others databases. The problem now is that it is possible for these users to delete databases created by other logins. Is there a solution for this? Can permissionĀ“s be set, so that these users ONLY can delete databases created with this login?
You can't do this directly, but you can wrap the system sp_delete_database_backuphistory into your own usp_delete_database_backuphistory
that can call sp_delete_database_backuphistory or return immediately depending on a result of the check you want to perform.
I cannot ask you in a comment what do you mean saying 'databases created by other users', first of all only login (not user) can create a database but this information (db creator) you cannot extract from any system metadata, all you can get is the current database owner and this can differ from database creator.
I mean, when you create a database you can explicitly assign other login to own the database, or you can do this later for certain purposes
In order to see all of the tables in our companies DB I have to go find the main sys account. Is there a way to default my connection so that it shows the other users tables?
Any table that your connecting account has at least SELECT privileges on will show up in the "Other Users" node of the navigation tree. If the table does not show up there then it is a database permissions issue, not a SQL Developer configuration issue.
Think you don't want to repeated type otheruser.tablename in all your queries. If that is the case you want to run this
alter session set current_schema = otheruser;
What do you mean by "see all of the tables"? Are you happy if you know they're there, or do you need to see their content. In the former case dba_tables should do. In the latter case it's a matter of the privileges assigned to you.
Change your connect to login as the main Sys user. Otherwise like dpbradley says you will have to go find them under the Other Users node.
If you connect to (e.g.) DB2 using JDBC driver, you can use this syntax:
jdbc:db2://localhost:50000/WESBDB:currentSchema=WESB;
Not only that the schema WESB will be your current schema, but it will be also the default schema in the tree on the Connections tab.
Note: It seems that it works for DB2 only.
As Ram, I also do it with
alter session set current_schema = otheruser;
It works if you want to access to the tables of a particular user
I am using Oracle Sql Developer
I have a huge script that creates tables, indexes, primary key constraints and such.
my DB name is: dbo_other
I logged into this dbo_other as sysdba.
If I run my script then tables do not show up on left panel under 'Tables'
However, if I append the script by adding 'dbo_other.' in front of every table name then the tables show up.
This is very tedious and time consuming.
Is there a way to avoid this? why wont they show up in dbo_other without adding dbo_other. in front of every table name?? When I run the query on the upper right corner the drop down has dbo_other selected!!
I can even do a select * from the table created (but dont see it in left sidebar) Furthermore, I can see the table in pl/sql developer.
Why does oracle sql developer want me to create it with dbo_other.??
Also, is there a way to avoid adding it for each table? maybe something can be done on top of the script so it takes effect on everything that follows?
Why are you logging in to your database using the SYSDBA account? This is very powerful, and it will allow you to do terrible damage to your database if you don't know what you're doing. In a development environment there's a limit to the harm you can do but it's best to get into good habits before doing things in Production.
The interesting thing about AS SYSDBA is that it overrides the username part of the login: if your OS user has the privileges, you're in. As SYS. Check it out:
SQL> conn apc
Enter password:
Connected.
SQL> show user
USER is "APC"
SQL> conn apc as sysdba
Enter password:
Connected.
SQL> show user
USER is "SYS"
SQL>
So, when you ran that script you created all those objects in the SYS schema. Which will prove to be a massive pain in the neck. I hope you have an equal and opposite reversion script.
To run the script properly, all you need to do is connect as DBO_OTHER (normal - i.e. without SYSDBA or SYSOPER which is the default after all). Your script will create tables in the current schema.
If you need to create objects in several schemas, you don't need to log out and in again. The schema is distinct from the user and it is possible to switch schema by executing alter session set current schema = WHOEVR;. This is quite a handy trick and I blogged it up some time back. Find out more.
Note that your user will not acquire any additional privileges by changing the current schema: they will only be able to do what they currently can do. So for something like creating objects in multiple schemas the executing user should be a power user, somebody with CREATE ANY privileges such as a DBA (but still not SYSDBA).
I just stumbled upon this little jem which lets you perform actions on a schema/user by default for which you are not logged in as. That is, by default your select statements, etc will operate on this new schema instead of your own.
alter session set current_schema =
Example:
Myself
+ table1
+ table2
SomeoneElse
+ SuperTable1
+ SuperTable2
log in as "Myself"
select * from SuperTable1
Error: ORA-00942: table or view does not exist
alter session set current_schema = SomeoneElse
select * from SuperTable1 <This will work.>
The "Tables" tree on the left-hand panel only includes tables the logged-in user owns in Oracle SQL Developer. If your script creates tables in another user's schema, you need to click the + next to "Other Users", find the appropriate user, and click the + on their tables.
As others have said, you shouldn't use SYSDBA unless you need to, and it sounds very much like your script should be executed as a normal user based on its rough description.