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.)
Related
I have created couple of DB links. Some are shared and some are not.
I created shared DB Link:
CREATE SHARED DATABASE LINK dblink_name CONNECT TO username IDENTIFIED BY password AUTHENTICATED BY schema_name IDENTIFIED BY password USING 'service_name';
I created Normal DBlink as:
create database link dblink_name connect to username identified by password using service_name;
Is there a way where i can identify if the dblink created is shared mode or not.
There's no simple way to check the data dictionary to determine if a link is shared or not. Below are two workarounds, using SYS.LINK$ and DBMS_METADATA, but they each have problems.
SYS.LINK$
The undocumented table SYS.LINK$ contains this information in a bitmap, as explained by Solomon Yakobson in this thread:
select name from sys.link$ where bitand(flag,1) = 1;
But that table contains password hashes and is only viewable by SYS. You could perhaps grant permission to that table, which could raise some security concerns. Or create a view on top of it and then grant that view, although you're typically not supposed to create objects in the SYS schema.
DBMS_METADATA
The package DBMS_METADATA recreates the link DDL and can be used to check for the "SHARED" keyword.
select owner, db_link
from dba_db_links
where lower(dbms_metadata.get_ddl('DB_LINK', db_link, owner)) like '%create shared%';
This solution can be slow, especially if the system has a large number of database links. And searching for text strings in source code may not be reliable. According to the syntax diagrams in the manual there are no other keywords that could come between CREATE and SHARED, but that may change or there may be undocumented features or behavior.
The given database contains a masterdata (MD) Schema and an application specific Schema (APP). In the APP Schema we have a view which provides the applications data from one table in the scheme joined with data from the MD Schema.
Example: Think of an address book application, which holds an address table, but cities and ZIP codes are joined from a masterdata table in another Schema which is maintained centrally.
CREATE VIEW view_adress AS
SELECT app.ID, app.Street, app.ZIP, zip.CITYNAME
FROM APP.adress app
LEFT OUTER JOIN MD.zipcodes zip
ON app.ZIP = zip.ZIP
This is very simplified. The actual view I use is a lot more complicated like that and therefore I implemented an INSTEAD OF INSERT, UPDATE Trigger to map INSERTs on the view to the correct base table in my APP Schema.
The application users (role) is granted SELECT,INSERT,UPDATE,DELETE on all tables inside this APP Schema. They are also granted SELECT on that zipcode table in the master data Schema.
When I insert on that view, I get an "ORA-01720: Grant Option Does Not Exist"... I don't know the exact cause of this error, but it can be assumed that the INSTEAD-OF Trigger never INSERTS on the ZIP Code Table, only on the address table.
I understand, that granting the application users INSERT privilege on the zipcode table would probably resolve this issue, but I am feeling uncomfortable granting INSERTs on tables to users which they never should edit in any way, because these are only lookups.
Is there another, possibly "the correct way" to solve this?
By "insufficient permissions error" do you mean this?
ORA-01720: grant option does not exist for 'MD.ZIPCODES'
*Cause: A grant was being performed on a view or a view was being replaced
and the grant option was not present for an underlying object.
*Action: Obtain the grant option on all underlying objects of the view or
revoke existing grants on the view.
If so, the solution is that you need to grant the relevant permissions to the schema owning the view - not to the roles that use the view:
grant insert on md.zipcodes to app with grant option;
It's true that you are still having to grant a permission that is logically not required, but you are not granting it to users, only the app schema.
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.
here's a tricky case on which 5 peoples including a DBA have been struggling on for days... I offer lifetime consideration to the one which will identify the root cause of the issue.
here it is:
Oracle Client: 10g
Oracle Server: 11g
We have 2 schemas and 1 user:
SCHEMA1
SCHEMA2
USER
We have 1 table 'TOTO' which is defined in SCHEMA1 (SCHEMA1.TOTO)
We have a private synonym of table 'TOTO', called 'TOTO' defined in SCHEMA2, created like this:
CREATE SYNONYM SCHEMA2.TOTO FOR SCHEMA1.TABLE1;
We have granted SELECT,UPDATE,DELETE,INSERT priviledges on "SCHEMA2.TOTO " (so on the synonym) to SCHEMA2 (so that any session ran from SCHEMA2 has access to the synonym table)
GRANT SELECT, UPDATE, DELETE, INSERT ON SCHEMA2.TOTO TO SCHEMA2;
Our application connects to the DB with USER, then directly switches to SCHEMA2:
ALTER SESSION SET CURRENT_SCHEMA=SCHEMA2;
Then after that, it tries to perform a select query on the synonym table WITHOUT prefixing the synonym name by SCHEMA1 (this is a constrain of the framework we use):
SELECT COL FROM TOTO;
Most of the times this query works successfully, which is what we expect since we have altered our session to SCHEMA2, by default that where the objects are looked.
But sometimes it fails, with an ORA-00942: table or view does not exist error.
I insist on the fact that between the time when it works and when it fails, nothing has changed, we've just restarted the application (which is of course re-connecting to the DB the same way at each startup).
We've been investigated with a DBA monitoring all the events on USER,SCHEMA1,SCHEMA2 hoping to find an external process modifying the GRANTS on one of thoses, between a success and a failure, but nothing changes. Yet, at some point, randomnly we get the ORA-00942 error, then we restart the application several times and it's back again...
Would someone have an idea or any suggestion/hint that could lead us to identify what we're missing here?
Many thanks for your help!
The grant should go to USER, not to SCHEMA2:
GRANT SELECT, UPDATE, DELETE, INSERT ON schema1.toto TO userxy;
This should solve the problem. If it doesn't, can you please post the result of
SELECT * FROM all_objects WHERE object_name='TOTO';
I have to import a stored procedure from Oracle database into Informatica.
But when I try to use the Stored Procedure Transformation I cannot view the respective stored procedure.
I am using the correct oracle driver since I don't have any trouble in importing target database tables.
I tried viewing the stored procedures in the oracle database using
select * from all_objects where object_type='FUNCTION' but could not find the
function I am looking for.
Please advise me on these:
Can we view the list and code of Stored procedure(s)/function(s) in Oracle
What am I missing in Informatica stored procedure transformation?
If you don't get any results from this..
select * from all_objects where object_type='FUNCTION'
It either means you don't have any functions or the current user does not have the privileges to execute any functions. Find out which user owns the function and grant the following.
example :
grant execute on <owner>.<function_name> to ETL_USER;
To avoid confusion, make sure the username in the informatica connection and the one you are using when connecting to the database are the same.
While importing object into Informatica, listed objects are always owned by the "connecting" user. If your object is owned by some other user, you wont see it. To see objects not owned by connecting user, you'd have to choose "All" in the schema text box, while connecting.
You should be looking for object_type='PROCEDURE' and not "FUNCTION". Therefore, your query should read as select * from all_objects where object_type='PROCEDURE'
If all this is done and you still dont see the object, check privileges on that object to your connecting user. For this, the best course is
a. ask your dba to grant execute privileges on that object to your connecting user. OR
b. connect to database as the owner of that object and run the following command
grant execute on <object_name> to <connecting_user>