How can I execute 'conn / as sysdba' using jsp.
Using
PreparedStatement stmt = conn.prepareStatement(sql);
shows java.sql.SQLException: SQL string is not Query?
How can I do it using jsp?
conn is a SQL*Plus command, not a SQL statement. So it can only be used in SQL*Plus (or another client tool that happens to have some support for SQL*Plus commands). You can't use it via JDBC.
conn / as sysdba tells SQL*Plus to use operating system authentication to connect to the database as the user SYS with the SYSDBA role enabled. Operating system authentication in this case would require that SQL*Plus was being invoked on the server where the database is installed and that the user was logged in as the operating system user "oracle". It seems exceedingly unlikely that it would be appropriate and/or possible for a JSP page to use operating system authentication like this-- that would, at a minimum, require that the application server that is running your JSP code is installed on the same server that Oracle is installed on and that it is running as the same operating system user as the Oracle database. Neither of those are particularly likely. Connecting to the database as SYS with the SYSDBA role enabled would also be very odd for a JSP page-- it is exceedingly rare that you would want JSP code to be running with those sorts of privileges. Generally, Oracle databases do not allow connections as SYS from anything other than the machine that Oracle is running on because, in general, only a DBA would be logging in with that account and then only to perform a very small set of tasks that actually require that sort of elevated access.
It should be possible to configure Oracle to accept remote connections for the user SYS with the SYSDBA role. And it should be possible to configure the connection string in your JSP code to use the appropriate password for that account. But it would be so exceedingly rare to want to do both, and would open such a substantial security hole, that I would seriously question whether that's really what you want to do. Can you explain a bit more about the problem you're trying to solve?
Yes, sql is the Query, but you need resultQuery = stmt.executeQuery() to save the result.
Also, take a look to the driver connection, the name of the machine where the DB is and the user name and password.
Related
Environment:
Oracle XE 18 running on Windows 10 (my laptop!).
I run database commands using specific users and sys.
Problem:
The windows application event log has 1000's of verbose Oracle database logging, for example every SELECT statement, indeed every command I run!
Launch Windows Event Viewer, execute at command prompt: eventvwr
Questions:
How to configure Oracle so that only certain messages are written
the to the Windows Event Log. Ideally no commands that I execute are
logged.
Does Oracle XE also write to log files (not windows event logs) and if so how to configure the granularity?
(I'm fairly new to Oracle)
Additional Info:
Below is an example of a windows application event log
Looking at your screenshot, it seems you are using the SYS user to execute your SQL commands. By default, all operations executed by users using SYSASM, SYSBACKUP, SYSDBA, SYSDG, SYSKM, or SYSOPER privileges are audited and go to the event log. You can disable that behavior with the AUDIT_SYS_OPERATIONS initialization parameter.
See documentation here: https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/AUDIT_SYS_OPERATIONS.html#GUID-58176267-238C-40B5-B1F2-BB8BB9518950
When logged in as SYS, you can change the parameter setting with the following command:
alter system set audit_sys_operations=false scope=spfile;
Then restart the database.
That said, in general you should not be using SYS for day-to-day operations and preferably would leave the default auditing in place. Instead, use a user account with normal privileges (i.e. not SYS as SYSDBA) to do everything that doesn't require those elevated privileges. For the most part you wouldn't need that level of access except for startup/shutdown, backup operations, and installing patches.
create user myuser identified by mypassword;
grant dba to myuser;
alter user myuser default role all;
That should give you a user with plenty of elevated privileges that won't constantly trip the built-in auditing.
Read up on Oracle security here: https://docs.oracle.com/en/database/oracle/oracle-database/18/dbseg/introduction-to-oracle-database-security.html#GUID-41040F53-D7A6-48FA-A92A-0C23118BC8A0
When we connect to Oracle database for the first time from SQLPlus command line tool, why do we always connect like this
"sys as sysdba"
Can some one tell me the significance of this?
Why do not we do this in MYSQL?
I am new to Oracle, and this question might sound silly. I am learning using Oracle 11g XE.
SYS and SYSTEM are administrative users, they kind of "own" the database. Data dictionary is stored in SYS schema so - if you screw it up, you'll most probably destroy the database. Therefore, never mess up with it - use it only for necessary administrative tasks. Never touch any SYS owned tables (thinking "if I change this I'll make that happen). Even better, create your own user and grant it DBA privilege - it'll be able to do mostly everything you'd ever want.
SYSDBA is a privilege which is automatically granted to user SYS; it lets it perform high-level administrative tasks (such as backup and recovery or upgrade the database). SYSTEM doesn't have it; that's why you don't specify as sysdba when connecting as SYSTEM.
Furthermore, SYSDBA privilege lets you to connect to database instance although database isn't open yet - and lets you start it up.
Saying that you "always connect as sys as sysdba" - well, you don't have to do that "always". There are other predefined users (such as Scott or HR (Human Resources)) you can use. Default username/password combinations are "scott/tiger" and "hr/hr". Though, they are most probably locked so you can't establish connection. That's why you connect as SYS, unlock those accounts (or create new one(s), depending on what you want to do), and then connect as some other user.
More info here:
SYS and SYSTEM users
SYSDBA and SYSOPER system privileges
Why you don't have that in MySQL? Probably because MySQL isn't Oracle.
Finally, as you're new with Oracle, I'd suggest you to visit & bookmark this page: Oracle Database 10gR2 documentation. Yes, it is kind of "old" and you don't use that version, but it is the last one that separated "Getting Started" and "Most popular" books which makes it easy to find and read. I'd suggest you to read:
Concepts, to learn what Oracle is and how it works
Then, depending on what you'd want to do/be (developer or DBA), pick e.g.
2 day DBA
Administrator's guide
or
SQL reference
PL/SQL user's guide and reference
Application developer's guide - fundamentals
Certainly, you can find these books for database version you do use (11g), it is here: Oracle database online documentation 11g Release 2 (11.2) but - as I said - it is not as nicely presented as 10g.
Good luck with Oracle, enjoy!
I have a pluggable database in Oracle 12c named PDBORCL.
After a server restart something changed in how to connect to it.
I created a user in that pluggable DB, for the example the user is PETER and the password is also PETER. Before the restart I used to be able to open a Command Prompt, run sqlplus, which would in turn ask for my username and then its password, and it would sign in. Now this does not work, it says invalid username/password. When I log in with SYS and check:
SELECT * FROM dba_users WHERE username = 'PETER';
I get no results.
However, if I sign in using the following from a command prompt, it works:
sqlplus PETER/PETER#PDBORCL
So, the DB is up and running, but it seems to be connecting by default to the wrong pluggable DB. I need to change it to the way it was before the restart, so that it connects by default to that specific pluggable DB.
How can I achieve this?
I found the solution. Change or create the environment variable LOCAL (in Windows) to PDBORCL. I think I read in linux the variable is TWO_TASK. After changing it, the following works:
sqlplus PETER/PETER
Also, just calling sqlplus and waiting to be prompted for username and password works.
You have created a user in pluggableDB and this user is not visible beyond the pluggable DB hence the reason you dont see user PETER when running the above query as sys..
If you want to connect to your pluggable DB directly what you have done above is right else you to connect to sys and the use CONNECT command.
I want to:
select * from v$database#standby;
Problem:
standby is mounted so only a SYSDBA user can connect to query it
I can't find out how to use a database link using SYSDBA privilege
My goal is to display system information/stats from a standby Oracle database on a web page.
I'm using Oracle APEX. Pages are computed from mod_plsql which runs from an Oracle DB so it is easy to display the result of this kind of query.
Alternative:
How to select * from "shell script"?
I don't think you can do this, based on the few things I've seen via Google.
To sum up, connecting remotely as sysdba uses authentication via the password file. Database links do not attempt to authenticate this way, they are authenticated in the remote database and not externally.
Here's a link to a site that briefly touches upon the subject.
I think what you want is:
CREATE PUBLIC DATABASE LINK STANDBY
rather than CREATE DATABASE LINK STANDBY. I just tested this from sqlplus / as sysdba and was able to query.
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.