We have different user in our environment(Greenplum/ Version 4.2.x)
(1. dbauser - User having DBA rights, can create objects and grant accss to other users
etluser - User having DML access and perform DMLs through Informatica
analyticsuser - having readonly access
bouser - user having readonly access and configured at BO reports to report on DB)
We are facing a problem for the last 3-4 days. Any of the user is not able to login to database through pgadmin except dbauser; when other users (etluser,analyticsuser,bouser) try to login the pgAdmin hanged and no response.
you can check the log in greenplum and most of the time you will the reason there.
Login to the server where your master is installed and go the directory of your master configured. Here is one example
/data1/data/master/gpseg-1/pg_log
can you check the resource queue limit and also priority of your user . some time DB exhaust with many connections
Please check the resource queue limit for the respective user and also find the limited number of connections for that queue.
Related
If the DB is locked ora-28000, will it impact ongoing executions
Please find the below scenario
A user has logged in and executing a SQL/PLSQL
B user has entered incorrect password, due to which DB user is locked
Will the existing executing queries continue to run until the user logs off
User A (Rahul) established connection and is allowed to work
User B (Littlefoot) tried to connect to the same database schema and provided wrong password too many times which caused the account to be locked
that affects future connections; the ones that were previously established work normally until their session is over, which means that
if user A (Rahul) disconnects and tries to connect again, although providing correct password, won't be able to connect because account is locked and DBA should unlock it
I just downloaded the Oracle Database 11g and I can't select,create,update or do anything. Every command that I entered and run only results to "ORA-01435: user does not exist"
What are the things that i need to do in order to enable creating and running some commands?
Here is a picture of ORA-01435: user does not exist
Please look at right upper corner SCHEMA:XS$NULL:
From Securing Oracle Database User Accounts
XS$NULL
An internal account that represents the absence of a user in a session. Because XS$NULL is not a user, this account can only be accessed by the Oracle Database instance. XS$NULL has no privileges and no one can authenticate as XS$NULL, nor can authentication credentials ever be assigned to XS$NULL.
Expired and locked
You need to change it to some specific schema.
I want to connect Oracle DB with same user several time at the same time on java app.
Is there any limitations?
I want to connect db and read bulk data from same user.
In general there are not unless there is a limit specifically configured through the user profile, which can limit sessions_per_user.
http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_6010.htm
The number of sessions is limited by the "sessions" configuration parameter of the database instance. According to the Oracle documentation the default value is (1.5 * PROCESSES) + 22.
See also
http://docs.oracle.com/cd/E11882_01/server.112/e25513/initparams232.htm#REFRN10197
Other related parameters are "processes" and "transactions".
In general it's not a problem to open several connection in an application to the same database user/schema at the same time. This is what application servers like JBoss are doing all the time.
We want to allow DB access (Oracle) to our users only through our own application - let's call it "ourTool.exe", installed locally on the users computers. Currently, the users must provide username/password whenever they start "ourTool". The provided password password gets decrypted and we use username/decrypted-password to finally log in to the Oracle DB. This approach prevents the users from directly accessing our DB using third party tools (SQLplus, Excel, Access, ...) and everything in the DB is guaranteed to have been entered/edited using "ourTool".
Now, one of our clients wants to allow its users "single sign-on" (with SmartCards/Oracle PKI). With this, the user will be able connect to our DB without providing any password every time they start "ourTool". But the same will be true for the potentially dangerous tools like SQLplus, Excel, Access, etc.
Is there a way to prevent this? How can we make sure that every record in our DB is only created/edited/deleted using "ourTool" in this scenario?
Since it's your application and you have control of the source, you can use either password protected database roles or Secure Application Roles that are enabled from ourTool.exe. (see http://www.oracle.com/technology/obe/obe10gdb/security/approles/approles.htm ).
For example, with a password-protected database role, the initial connection would be with only the CREATE SESSION privilege, and then ourTool.exe would issue the SET ROLE with password known only to you. Any other application doesn't have the information to set the role. Obviously, the privileges are granted only to the role and not directly to the user in this configuration.
By default, OCI transmits the calling application EXE name and you can access it by querying v$session:
SELECT program
FROM V$SESSION
, which you can do in an AFTER LOGON trigger.
But this can be easily overriden and should not be relied upon.
I renamed my sqlplus.exe to myTool.exe and after making a connection with myTool.exe
SELECT program
FROM V$SESSION
where username = 'SYSTEM';
Returns:
myTool.exe
So be aware, as Quassnoi said: although usable in some circumstances it's certainly not bullit proof.
I have a database in oracle, my task is to create/update a user in Microsoft Active directory running on different server, when a user detail is entered / updated in Oracle table.
If its not possible then what is the best way to achieve this.
Currently we are doing it by running a code written in C# which reads from oracle and does job in AD, it triggers from user creation package but some times triggering fails and whole process fails. User details are updated in DB but not in AD.
Oracle is running at different server. User details are entered in DB through a different package.