This query
select distinct owner from dba_objects
is throwing this error
ORA-00942: table or view does not exist
Does that make any sense at all?
You have to use an administrative user (such as sys or system). If you do not have access to such a user, you could use the all_objects view instead of dba_obejcts. Any user can query it, and will get results only for the objects it has privileges to.
It does if you don't have select privs on the DBA_OBJECTS view or if you don't have a local or global synonym to the SYS.DBA_OBJECTS view. You could try selecting from SYS.DBA_OBJECTS instead.
As others state, this is a privileges issue.
However, if a user needs access to the more privileged DBA data dictionary objects you should grant them the SELECT_CATALOG_ROLE role. Connecting with SYS or SYSTEM, or even as a DBA, should be discouraged for normal operations.
Related
I have administrative problem on my database.
I need to give permission to other schema to my View. My View have data from one table and view. This Second view is using private database link.
How can i grant select on that View, to other schema and in the same time grant view that is using database link?
While trying making simple
grant select on myView to otherSchema;
i have error ORA-02021: DDL operations are not allowed on a remote database
DDL operations of any kind, such as grants, are not allowed to be executed through a database link. You need to connect to the remote database where the source objects are located, and grant select on them to the user/schema who connects by dblink. As you don't provide any code, consider the option that you might need to use grant select on xxxx with grant option.
When I try to create a view by using different tables(from different users), getting grant option does not exist for (dependent table) even though Privileges(WITH GRANT OPTION) exists on dependent tables to respective user but when I execute same dependent Select query of creating view it's running successfully.
create or replace view ein.eswar
as
select * from ron.anil t ,msd.ram v where t.id=v.id;
grant option does not exist for ron.anil;
After dropping view and recreating it successfully without any issues. Please explain.
You need to have privilege SELECT WITH GRANT option;
GRANT SELECT ON ron.anil TO EIN WITH GRANT OPTION.
When you are creating view on different schema then table_owner, privilege with grant option are necessary.
There is a table which when I use to execute a query it gets normally executed but when I compile it in a package it is giving an error for that table saying
insufficient privileges
Any idea what I can do about it ?
The user you are using got the privilege to access the table through a role.
Privileges obtained through roles are not in effect inside a PL/SQL program. You need to grant the select (insert,update,delete) privilege directly to the user in question.
I want to get the number of sessions in Oracle using the SQL query:
SELECT value FROM v$parameter WHERE name = 'sessions'
But I get this error:
Error starting at line 1 in command:
SELECT value FROM v$parameter WHERE name = 'sessions'
Error at Command Line:1 Column:18
Error report:
SQL Error: ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
Maybe the Oracle user that I use is not privileged?
Generally the better approach is to use a procedure and grant the necessary privileges to this procedure. However if you want use SQL directly, you can grant SELECT_CATALOG_ROLE or SELECT ANY DICTIONARY to the user.
Probably. To grant the rights, you need to use the table name as V_$PARAMETER. It comes from some restriction when granting rights on dynamic views.
If you want to use SQL directly (referring to the second option in the accepted answer)
As of Feb 2023, using Oracle version 19, this works...
Connect as SYSTEM and run
grant SELECT ANY DICTIONARY to <user>;
But SELECT_CATALOG_ROLE didn't work for me...
grant SELECT_CATALOG_ROLE to ...;
There are documented differences between the two here:
http://www.petefinnigan.com/weblog/archives/00001461.htm
This is where the author gives the following info and warning:
Well, SELECT_CATALOG_ROLE allows access to some things Oracle deemed not allowed by SELECT ANY DICTIONARY so we need to be careful of granting this role on these grounds. BUT, the overwhelming issue for me is that SELECT_CATALOG_ROLE gives access to 4539 objects and SELECT ANY DICTIONARY gives access to 6228 objects (both numbers in 18c XE)
I am not sure why Oracle do not publish the full list of exclusions in SELECT ANY DICTIONARY but they do publish all of the main tables. We can easily find out anyway. For me, i want to know what does SELECT ANY DICTIONARY really mean. I want to know what i am actually granting if I give out that privilege; well it means access to 6228 tables and views in 18cXE
Both of these rights should not be used; they are a sledgehammer to crack a peanut. If someone needs access to V$SESSION or V$DATABASE and there is a legitimate reason to have that access then grant access on the individual views not SELECT ANY DICTIONARY or SELECT_CATALOG_ROLE.
using the privileges: - select any table, alter any table when running the grant as SYS with SYSDBA in Oracle 12c solved the issue for me.
Suppose I'm logged in as USERA, I want to access all the user_* views of the USERB schema, such as user_tables, user_tab_columns. How can I do this? Thanks
All the USER_* tables have analogues with the ALL_* and DBA_* prefix. USER_TABLES has information about all the tables you own. ALL_TABLES has information about all the tables you have access to. DBA_TABLES has information about all the tables in your database.
If you want to see information about UserB's tables
SELECT *
FROM all_tables
WHERE owner = 'USERB';
or
SELECT *
FROM dba_tables
WHERE owner = 'USERB';
The former will work if you have SELECT access on User B's tables. The latter will work if your DBA has given you access to the DBA_TABLES view. That is normally done by granting the SELECT ANY DICTIONARY privilege (or the SELECT_CATALOG_ROLE in prior version) though the DBA can grant access to individual DBA_* views.
USER_% views give what you own, that is what's inside your schema.
ALL_% views give what you have access to.
So what you really should use is ALL_TABLES/etc, and grant appropriate access to USERB objects.
Assuming you have permissions, you could try:
ALTER SESSION SET CURRENT_SCHEMA=USERB;