I'm surprised I haven't been able to find this question on the site already. Apologies if it turns out to be a duplicate!
In Oracle (10 upwards) is it possible for USER_A to deploy objects in USER_B's schema?
For example, assuming I am logged in as USER_B:
CREATE OR REPLACE PACKAGE user_a.my_example_pkg IS
PROCEDURE Make_Log;
PROCEDURE Init;
END user_a.my_example_pkg;
I get an ORA-1031: insufficient privileges response when I deploy.
I know that it is possible to log in as USER_A to deploy the package, and yes I can do that. But the point is that on my database, someone appears to have modified a package "across the schema" in this way. And I need to figure out how they did it!!
I'm fairly sure that the privilege exists, but I can't find what it is. Moreover, if there are many privileges which allow this to be done, it would be a bonus to get an exhaustive list of what those privileges are.
You'd want to look for the ANY privileges
CREATE PROCEDURE lets you create procedures in your schema. CREATE ANY PROCEDURE lets you create procedures in any schema.
CREATE TABLE lets you create tables in your schema. CREATE ANY TABLE lets you create tables in any schema.
CREATE VIEW lets you create views in your schema. CREATE ANY VIEW lets you create views in any schema.
For any of the CREATE privileges, there is a corresponding CREATE ANY privilege. Those ANY privileges are extremely powerful and really shouldn't be given to anyone other than a DBA since it would allow you to do things like create procedures owned by highly privileged users that can do anything a DBA could do.
I would simply like to allow a colleague to view and edit the Database I've created.
I've tried:
GRANT ALL on FISHTABLE to CDEMARES;
and it returned Grant succeeded but nothing changed for him and he still wasn't able to view my table.
I also tried
GRANT SELECT smahala.fishtable to cdemares#sole.nefsc.noaa.gov;
but that failed with SQL Error: ORA_00990: missing or invalid privilege.
Is my issue that I don't have the administrative authority to allow someone else to view my Oracle table? Any advice is appreciated, thanks.
Your colleague needs to prefix your table with your schema name, otherwise Oracle doesn't know where to look for it, e.g.:
select * from smahala.fishtable
If they don't do that, and simply try to use:
select * from fishtable
then Oracle will look for the table in their own schema, and then look for a view, or a private synonym, or a public synonym. Your colleague could create a synonym if they'll be accessing this table a lot (and they don't have their own table with the same name). It's also possible to change their session's current schema, but that will make it harder to see their own objects.
You can read more about object naming and how to refer to objects in the documentation.
SQL Developer allows you to browse objects in other schemas. If your colleague was connected when you granted the permissions, they can refresh the object list, or disconnect and reconnect. Either way they should then be abke to see your table under your schema.
(Your second grant statement is missing an on, and you can't grant permissions across a database link, if that's what you're trying to do.)
I am new to PL/SQL Developer, and I used the File->New->Table option to create a new table. After using the GUI to set up my table descriptions, when I click "apply" I get the error "no privileges on table space".
I tried googling a solution and I read that I need to give the owner of the schema privileges to modify this table. How do I determine who the owner of a schema is so that I can give them privileges?
Is there another solution to this issue that I do not know of?
You have created the table, so it belongs to you, there is no need to grant something on schema level.
A different story altogether is the tablespace in which the table is created. There, you need a quota. With a privileged user, you can give the quote like so:
alter user <your-username>
quota unlimited on <tablespace-name>;
You need someone with sysdba privileges on the database your schema belongs to (typically a DBA) to grant your schema the necessary privileges to create objects (tables, procedures etc), along with a quota on the tablespace in question.
I have tables in Schema A. I created views in Schema B using the tables in schema A.
I want to grant permissions to a user to select the data from view in Schema B.
For this to work i know we have to enable the grant option on tables in Schema A to user B.
But I want to do it in a single script (This script has to be in schema B). Is there a way to do this using the user name/password of schema A.
It's not unusual to want to have a single script to deploy a change. The thing is, such a script needs to be run by a power user, because it needs to have system privileges at the ANY level. This usually means a DBA account, preferably an application account but otherwise SYSTEM or SYS.
So the script you want would look like this:
grant select on user_a.t23 to user_b
/
grant select on user_a.t42 to user_b
/
create view user_b.v_69 as
select t23.col1, t42.col2
from user_a.t42
join user_a.t23
on (t42.id = t23.id)
/
grant select on user_b.v_69 to user_c
/
A common scenario is that we have a suite of individual scripts which have been written to be run by different users but which we now need to bundle up into a single deployment. The original scripts don't contain the schema names, and there are many good reasons why we wouldn't want to hardcode them in the scripts.
One way to build that master script is to use change the CURRENT_SCHEMA syntax:
alter session set current_schema=USER_A
/
#run_grants_to_userb.sql
alter session set current_schema=USER_B
/
#create_view69.sql
#run_grants_to_userc.sql
We still need a DBA user to run the master script. One advantage of switching the current schema is that it allows us to deploy objects like database links, which through a quirk of syntax cannot have the schema name in their declaration. One gotcha is that the user doesn't change, so a script which employs the USER pseudo-column may produce unwanted results.
Simply Run the query
GRANT INSERT, SELECT, UPDATE, DELETE ON TABLE1 TO SCHEMA2;
Only by connecting as user A at some point. You can still do it in one script if you really want to:
connect userA/passwordA
grant select on my_table to userB;
connect userB/passwordB
create view my_view as select * from userA.my_table;
Of course now you have a script lying around which exposes two sets of user credentials to anyone who can read it. So something to think hard about before doing in production, for example.
If you want other users to be able to select from the view, you don't need to grant explicit permissions on userA.my_table to them; as long as the view owner can see the underlying table, other users just need to be able to see the view. Which is often kinda the point (or one of them) as you can restrict the view to only expose selected data from the underlying table to the rest of the world. I assume you have a reason for not creating the view in schema A.
I'm not sure if you're really asking about granting select to user B with admin option so that user B can then grant select on user A's table to other people. If that's possible, it doesn't sound like a good idea, and isn't necessary for the view to work.
Let user A grant select on his tables to B and include the 'grant option'.
As user A:
GRANT select ON table TO user_b WITH GRANT OPTION;
Let user B grant select on his views to user A and include the 'grant option'.
As user B:
GRANT select ON view TO user_a WITH GRANT OPTION;
As user A:
GRANT select on user_b.view TO user_c;
This allows user A to pass this grant on to other users.
What is the difference between a user and a schema in Oracle?
From Ask Tom
You should consider a schema to be the user account and collection of all objects therein
as a schema for all intents and purposes.
SCOTT is a schema that includes the EMP, DEPT and BONUS tables with various grants, and
other stuff.
SYS is a schema that includes tons of tables, views, grants, etc etc etc.
SYSTEM is a schema.....
Technically -- A schema is the set of metadata (data dictionary) used by the database,
typically generated using DDL. A schema defines attributes of the database, such as
tables, columns, and properties. A database schema is a description of the data in a
database.
I believe the problem is that Oracle uses the term schema slightly differently from what it generally means.
Oracle's schema (as explained in Nebakanezer's answer): basically the set of all tables and other objects owned by a user account, so roughly equivalent to a user account
Schema in general: The set of all tables, sprocs etc. that make up the database for a given system / application (as in "Developers should discuss with the DBAs about the schema for our new application.")
Schema in sense 2. is similar, but not the same as schema in sense 1. E.g. for an application that uses several DB accounts, a schema in sense 2 might consist of several Oracle schemas :-).
Plus schema can also mean a bunch of other, fairly unrelated things in other contexts (e.g. in mathematics).
Oracle should just have used a term like "userarea" or "accountobjects", instead of overloadin "schema"...
From WikiAnswers:
A schema is collection of database objects, including logical structures such as tables, views, sequences, stored procedures, synonyms, indexes, clusters, and database links.
A user owns a schema.
A user and a schema have the same name.
The CREATE USER command creates a user. It also automatically creates a schema for that user.
The CREATE SCHEMA command does not create a "schema" as it implies, it just allows you to create multiple tables and views and perform multiple grants in your own schema in a single transaction.
For all intents and purposes you can consider a user to be a schema and a schema to be a user.
Furthermore, a user can access objects in schemas other than their own, if they have permission to do so.
Think of a user as you normally do (username/password with access to log in and access some objects in the system) and a schema as the database version of a user's home directory. User "foo" generally creates things under schema "foo" for example, if user "foo" creates or refers to table "bar" then Oracle will assume that the user means "foo.bar".
This answer does not define the difference between an owner and schema but I think it adds to the discussion.
In my little world of thinking:
I have struggled with the idea that I create N number of users where I want each of these users to "consume" (aka, use) a single schema.
Tim at oracle-base.com shows how to do this (have N number of users and each of these users will be "redirected" to a single schema.
He has a second "synonym" approach (not listed here). I am only quoting the CURRENT_SCHEMA version (one of his approaches) here:
CURRENT_SCHEMA Approach
This method uses the CURRENT_SCHEMA session attribute to automatically
point application users to the correct schema.
First, we create the schema owner and an application user.
CONN sys/password AS SYSDBA
-- Remove existing users and roles with the same names.
DROP USER schema_owner CASCADE;
DROP USER app_user CASCADE;
DROP ROLE schema_rw_role;
DROP ROLE schema_ro_role;
-- Schema owner.
CREATE USER schema_owner IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO schema_owner;
-- Application user.
CREATE USER app_user IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
GRANT CONNECT TO app_user;
Notice that the application user can connect, but does not have any
tablespace quotas or privileges to create objects.
Next, we create some roles to allow read-write and read-only access.
CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;
We want to give our application user read-write access to the schema
objects, so we grant the relevant role.
GRANT schema_rw_role TO app_user;
We need to make sure the application user has its default schema
pointing to the schema owner, so we create an AFTER LOGON trigger to
do this for us.
CREATE OR REPLACE TRIGGER app_user.after_logon_trg
AFTER LOGON ON app_user.SCHEMA
BEGIN
DBMS_APPLICATION_INFO.set_module(USER, 'Initialized');
EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER';
END;
/
Now we are ready to create an object in the schema owner.
CONN schema_owner/password
CREATE TABLE test_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT test_tab_pk PRIMARY KEY (id)
);
GRANT SELECT ON test_tab TO schema_ro_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON test_tab TO schema_rw_role;
Notice how the privileges are granted to the relevant roles. Without
this, the objects would not be visible to the application user. We now
have a functioning schema owner and application user.
SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
Name Null? Type
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
DESCRIPTION VARCHAR2(50)
SQL>
This method is ideal where the application user is simply an
alternative entry point to the main schema, requiring no objects of
its own.
It's very simple.
If USER has OBJECTS
then call it SCHEMA
else
call it USER
end if;
A user may be given access to schema objects owned by different Users.
Schema is an encapsulation of DB.objects about an idea/domain of intrest, and owned by ONE user. It then will be shared by other users/applications with suppressed roles. So users need not own a schema, but a schema needs to have an owner.
--USER and SCHEMA
The both words user and schema are interchangeble,thats why most people get confusion on this words below i explained the difference between them
--User User is a account to connect database(Server). we can create user by using CREATE USER user_name IDENTIFIED BY password .
--Schema
Actually Oracle Database contain logical and physical strucutre to process the data.The Schema Also Logical Structure to process the data in Database(Memory Component). Its Created automatically by oracle when user created.It Contains All Objects created by the user associated to that schema.For Example if i created a user with name santhosh then oracle createts a schema called santhosh,oracle stores all objects created by user santhosh in santhosh schema.
We can create schema by CREATE SCHEMA statement ,but Oracle Automatically create a user for that schema.
We can Drop the schema by using DROP SCHEMA schama_name RESTRICT statement but it can not delete scehema contains objects,so to drop schema it must be empty.here the restrict word forcely specify that schema with out objects.
If we try to drop a user contain objects in his schema we must specify CASCADE word because oracle does not allow you to delete user contain objects.
DROP USER user_name CASCADE
so oracle deletes the objects in schema and then it drops the user automatically,Objects refered to this schema objects from other schema like views and private synonyms goes to invalid state.
I hope now you got the difference between them,if you have any doubts on this topic,please feel free to ask.
Thank you.
A user account is like relatives who holds a key to your home, but does not own anything i.e. a user account does not own any database object...no data dictionary...
Whereas a schema is an encapsulation of database objects. It's like the owner of the house who owns everything in your house and a user account will be able to access the goods at the home only when the owner i.e. schema gives needed grants to it.
A schema and database users are same but if schema has owned database objects and they can do anything their object but user just access the objects, They can't DO any DDL operations until schema user give you the proper privileges.
Based on my little knowledge of Oracle... a USER and a SCHEMA are somewhat similar. But there is also a major difference. A USER can be called a SCHEMA if the "USER" owns any object, otherwise ... it will only remain a "USER". Once the USER owns at least one object then by virtue of all of your definitions above.... the USER can now be called a SCHEMA.
User: Access to resource of the database. Like a key to enter a house.
Schema: Collection of information about database objects. Like Index in your book which contains the short information about the chapter.
Look here for details
For most of the people who are more familiar with MariaDB or MySQL this seems little confusing because in MariaDB or MySQL they have different schemas (which includes different tables, view , PLSQL blocks and DB objects etc) and USERS are the accounts which can access those schema. Therefore no specific user can belong to any particular schema. The permission has be to given to that Schema then the user can access it. The Users and Schema is separated in databases like MySQL and MariaDB.
In Oracle schema and users are almost treated as same. To work with that schema you need to have the permission which is where you will feel that the schema name is nothing but user name. Permissions can be given across schemas to access different database objects from different schema. In oracle we can say that a user owns a schema because when you create a user you create DB objects for it and vice a versa.
Schema is a container of objects.
It is owned by a user.
Well, I read somewhere that if your database user has the DDL privileges then it's a schema, else it's a user.