I want to create the user and the database within that user. But when I tried to create database its giving the warning message as
ERROR at line 1:
ORA-01501: CREATE DATABASE failed
ORA-01100: database already mounted
Then I tried
STARTUP NOMOUNT;
Its giving the warning message for insufficient privileges even I have given all the permission to that particular user.
Can any one please help in finding the solution for this?
You don't create a database under a user in Oracle; I believe you're using terminology from another database poduct. The equivalent is a schema, which is a logical container for a group of objects. User and schema are essenentially synonymous in Oracle - when you create a user is automatically has its own schema.
You create the database once (which you already seem to have done, or had done for you), then create as many schemas/users as your application needs. You don't ever rerun the create database under normal circumstances - you certainly wouldn't as a normal user.
If you connect as that user you will be able to create tables, views, packages etc., assuming it has really been granted all the necessary privileges.
Related
I am trying to create a new user from Oracle SQL Developer. I made a connection with the user Sys and the password that I entered in the installation of Oracle Database XE 18c.
When creating the user I get the error ORA-65096, I have searched the internet and the solution I found is to write the following:
alter session set "_ORACLE_SCRIPT" = true;
However, I want to know if it is possible to create the new user without using any SQL statement or script and do it from the Oracle SQL Developer interface, do I have to login with a different user than Sys to create a new user? or what do I have to do? Could someone give me a detailed explanation please. I am learning how to use this database and I want to try to understand what I am doing.
oerr ora 65096
65096, 00000, "invalid common user or role name"
// *Cause: An attempt was made to create a common user or role with a name
// that was not valid for common users or roles. In addition to >the
// usual rules for user and role names, common user and role names
// must consist only of ASCII characters, and must contain the >prefix
// specified in common_user_prefix parameter.
// *Action: Specify a valid common user or role name.
This implies that you are connected to the root container instead of to a regular plug in database (pdb) where applications should be built. The solution for you is not to overrule setting to enable building an application in the root container but to connect to the pdb that has been made to host your application.
you can check the available pdb's by viewing v$pdbs. The special pdb cdb$root is as the name already tries to tell, the root container. show PDBS will give similar output.
Using alter session set container = [pdb_name]; can be used to switch to your container of choice where regular rules apply.
Even better is to directly connect to that pdb using sqlnet.
I am trying to create a read-only user for an Oracle 11g Database that will be used by SQLAlchemy to query the database.
I was using an existing DBA user with SQLAlchemy and wasn't having any problems, but now with the new user, I am unable to reflect database tables.
Could not reflect: requested table(s) not available in Engine
Note that I can SELECT the tables, just not reflect them.
I am wondering what kind of permissions I need to give to the new user for it to able to reflect through SQLALchemy.
I tried copying all roles from the existing DBA to the new user, but still get the same error
I even tried some advanced roles that weren't used before (I plan on deleting and adding the user correctly again later.
DBACONSULTA is the new user I am creating.
GRANT DBA TO DBACONSULTA
GRANT EXECUTE ANY EVALUATION CONTEXT TO DBACONSULTA
GRANT ANALYZE ANY TO DBACONSULTA
GRANT SELECT ANY TABLE TO DBACONSULTA
GRANT EXECUTE ANY PROGRAM TO DBACONSULTA
With Python I use the following code:
engine=create_engine('oracle+cx_oracle://...')
metadata = MetaData()
metadata.reflect(engine, only=['tablename'])
Get the error:
Could not reflect: requested table(s) not available in Engine
I want to be able to reflect tables, without using the Declarative form from SQLAlchemy
Thanks in advance.
I believe I have found the answers.
Two things that are important:
the table name had to be in lowercase (didn't work using uppercase)
the schema was not defined (turn out it was working because the user I was using was the owner of the schema of the tables)
So, when i declare the schema and use lowercase for the tablename the reflection works.
I want to import schema to my new host. First I had created new user account:
CREATE USER test IDENTIFIED BY test;
What kind of privileges I need to grant to have super role?
(create schema, tables, packages, triggers...etc)
It's one privilege to grant me access to all of them?
You should grant only those privileges that are required for a newly created user to work. One by one.
CREATE SESSION is the first one; without it, user can't even connect to the database.
CREATE TABLE is most probably also required, if user TEST is going to create his own tables.
That's enough to get it started. Once it appears that user needs to create a procedure, you'll grant CREATE PROCEDURE. And so forth.
There are/were roles named CONNECT and RESOURCE which contained the "most frequent" privileges one needed, but their use is - as far as I can tell & in my opinion - discouraged.
An application needs to access various Oracle database. Some databases have tables in Schemas, some don't - there's no control over this.
If a database has a schema in use, the applicable won't work unless the user enters a schema. I'd like it to be able determine via a SQL query if a schema is required to access the tables so the user can be alerted to this.
I'm aware of the question - How do I obtain a list of schemas that an Oracle user has access to - but that only tells me what schema's can be accessed, not if use of the schema is required to access tables.
Is there an SQL query to one of the system tables that can do this with that user's rights?
Note: The application only has login credentials and doesn't know any table details.
Hope that's clear. Thanks.
Question is confusing. For most part in Oracle, you can consider LOGIN == USER == SCHEMA. When you login into your database with your user, you are able to see and access all objects in that user's schema.
Objects in other schemas (on same database server) can be accesed by SCHEMA2.TABLE1 if connected user has privileges to acces table (there are different privileges...). As already stated in some comments, you do not need to prefix table if synonym exists. Your user can access even tables on some remote server if exists appropriate database link.
As security tightening exercise, I'm removing all system privileges from an oracle database user. Now this user ONLY has the following system privileges:
CREATE SESSION
UNLIMITED TABLESPACE
I was hoping that the user wont be able to do any DDL commands. But to my surprise, user can DROP TABLE in its own schema even though it can't create one.
Oracle documentation says prerequisite for DROP TABLE is "The table must be in your own schema or you must have the DROP ANY TABLE system privilege". Just that!!! I don't understand the security logic of Oracle but is there any way I can prevent Users from dropping their own tables?
The alternative would be creating another user to run the application and grant object access, which I'd rather like to avoid as there are potential issues.
A user will always have permissions to drop objects that they own. You can't prevent that by revoking privileges.
Since you're looking at tightening security, creating a new user and granting that user whatever privileges they need to manipulate the data is the right answer. The only people that ought to be logging in to a production database as a user that owns application objects are DBAs and then only when they are in the process of deploying changes to the schema. Everyone else should be logging in to the database as users other than the schema owner.
That being said, if the right solution is more work than you're prepared to undertake right now, a potential stopgap would be to create a DDL trigger on the database that throws an exception if a DROP is issued against an object in the specified schema. This is less secure than the proper solution. You may miss something when implementing the trigger, you or someone else may drop or disable the trigger and forget to re-enable it, etc. And it makes security reporting much more difficult because you've got a custom solution that isn't going to be obvious in the various security related data dictionary views which may create problems for auditors.