I wanted to create a view that looked something like the following but i keep getting an ORA-01031 - insufficient permission error
create view v_dbinfo as
Select INSTANCE_NAME,HOST_NAME from v$instance;
I can select from v$instance, and create a view from an existing table without any problems.
Any idea on why this is occurring and how i can go about fixing it?
Thanks
I would tend to wager that you have access to V$INSTANCE via a role rather than as a direct grant. If you want to create a view (or reference V$INSTANCE in a definer's rights stored procedure), you would need to have been granted access to the referenced objects via direct grants, not via a role.
In addition, if you intend on granting access to this new view to other users, you will need the access to V$INSTANCE to be granted using the WITH GRANT OPTION clause, i.e.
GRANT SELECT ON v$instance
TO your_user_name
WITH GRANT OPTION;
Related
Three days ago, I created another user, it's ok. Now I create another user, not working. I don't know what I missed.
This time I did:
CREATE USER TESTDB identified by N2dTlOBFRZ9x;
GRANT CONNECT, RESOURCE TO TESTDB;
GRANT CREATE SESSION TO TESTDB;
GRANT UNLIMITED TABLESPACE TO TESTDB;
GRANT CREATE TABLE to TESTDB;
GRANT CREATE VIEW to TESTDB;
I can create a view, named viewTest, save it.
TESTDB viewTest
select * from PRODDB.employee
Then open viewTest, it says insufficient privileges.
I have another user. let's call it PRODDB. This is online database
The user I created 3 days ago, is OKDB.
Today I created one another, TESTDB.
In OKDB, I created a view (viewTest) and I can open it.
select * from PRODDB.employee;
But in TESTDB, cannot open.
Thank you for the update! I believe this is a permissions issue.
In OKDB, I created a view and I can open it. select * from
PRODDB.employee;
But in TESTDB, cannot open.
So in this example, there are three users: 1. PRODDB, 2. OKDB, and 3. TESTDB.
The view is named Employee and was created under the PRODDB schema; PRODDB.EMPLOYEE.
If OKDB can query PRODDB.EMPLOYEE, one of two things have to be true. Either: 1. OKDB was granted privileges on PRODDB.EMPLOYEE directly (e.g. grant select on PRODDB.EMPLOYEE to OKDB;), or 2. OKDB has elevated privileges through a role that enables the user to query that view (e.g. grant DBA to OKDB, which will allow OKDB to query any table in the database.)
If TESTDB can't query the view, I would bet that the necessary privileges have not been granted to the user. To fix this, I would recommend checking the privileges and roles that have been granted to the OKDB user and then granting the same privilege(s) to TESTDB. If this is something work related, you may have to work with another DBA if you do not have permission to issue grants.
I want to create a view in SCHEMA_A using columns from a table LICENSE in SCHEMA_B.
create view SCHEMA_B.V_TEST as
SELECT LICENSE_NUMBER FROM SCHEMA_A.LICENSE L
then
select * from SCHEMA_B.V_TEST
This is giving me "ORA-01031: insufficient privileges" when I try to select from the view as the admin account. (Edit: admin account has SELECT ANY TABLE privileges.) What am I missing?
There is a similar question but the solution has to do with one user granting select to another. Since I'm admin I should have select privilege on both schemas already? However I have tried adding the line "GRANT SELECT ON SCHEMA_A.LICENSE TO admin_account WITH GRANT OPTION" and get the same error.
I think that the creation of the view fails, because schema_b doesn't have select privilege to schema_a.licence. Since you're creating an object in the schema_b, schema_b must have the necessary privilege.
Grant it:
as schema_a (or an DBA - "admin account")
grant select on schema_a.licence to schema_b
then you should be able to create the view and then select from it.
I have created a new user using the below in sql developer (Oracle 11g). I have only two tables titled FEED_DATA_A and FEED_DATA_B that I want this user to be able to select, update and insert into. Can someone help me understand the SQL to create the proper privileges to accomplish that? I'm currently logged in as the system user.
CREATE USER "USER_A" IDENTIFIED BY "test123";
If you want to grant the privileges directly to the user
GRANT select, update, insert
ON table_owner.feed_data_a
TO user_a;
GRANT select, update, insert
ON table_owner.feed_data_b
TO user_a;
More commonly, though, you would create a role, grant the role to the user, and grant the privileges to the role. That makes it easier in the future when there is a new user created that you want to have the same privileges as USER_A to just grant a couple of roles rather than figuring out all the privileges that potentially need to be granted. It also makes it easier as new tables are created and new privileges are granted to ensure that users that should have the same privileges continue to have the same privileges.
CREATE ROLE feed_data_role;
GRANT select, update, insert
ON table_owner.feed_data_a
TO feed_data_role;
GRANT select, update, insert
ON table_owner.feed_data_b
TO feed_data_role;
GRANT feed_data_role
TO user_a
Everytime I create a new view I have to change the permissions to all, and it's quite painfully to do a lot of times the same thing.
I also ask if is possible to change some default options in the database I create the view in order the permissions to be set to public.
Thanks
It sounds like you are using SQL naming. Use System naming instead, this will grant public authority according to the QCRTAUT system value. See Birgitta Hauser's article.
System naming has the added advantage of using the job's library list to resolve unqualified object references. By not hard-coding schema names, but allowing the system to find them according to the library list, enabling your code to work in different environments (ex. development, testing, training, production) without modifying the code, simply by running with a different library list. Therefore you can install code into production exactly the same code that was tested.
The following is from the V6R1 documentation:
Authorization
The privileges held by the authorization ID of the statement must
include at least one of the following:
The privilege to create in the schema. For more information, see
Privileges necessary to create in a schema.
Administrative authority
The privileges held by the authorization ID of the statement must
include at least one of the following:
The following system authorities: *USE to the Create Logical File
(CRTLF) CL command *CHANGE to the data dictionary if the library
into which the view is created is an SQL schema with a data dictionary
Administrative authority
The privileges held by the authorization ID of the statement must also
include at least one of the following:
For each table and view referenced directly through the fullselect,
or indirectly through views referenced in the fullselect: The SELECT
privilege on the table or view, and The system authority *EXECUTE on
the library containing the table or view Administrative authority
View ownership: If SQL names were specified:
If a user profile with the same name as the schema into which the
view is created exists, the owner of the view is that user profile.
Otherwise, the owner of the view is the user profile or group user
profile of the job executing the statement.
If system names were specified, the owner of the view is the user
profile or group user profile of the job executing the statement.
View authority:
If SQL names are used, views are created with the system authority of
*EXCLUDE on *PUBLIC. If system names are used, views are created with the authority to *PUBLIC as determined by the create authority
(CRTAUT) parameter of the schema.
If the owner of the view is a member of a group profile (GRPPRF
keyword) and group authority is specified (GRPAUT keyword), that group
profile will also have authority to the view.
The owner always acquires the SELECT privilege WITH GRANT OPTION on
the view and the authorization to drop the view.
The owner can also acquire the INSERT, UPDATE, and DELETE privileges
on the view. If the view is not read-only, then the same privileges
will be acquired on the new view as the owner has on the table or view
identified in the first FROM clause of the fullselect. These
privileges can be granted only if the privileges from which they are
derived can also be granted.
I am logging into oracle as a simple user.I want other user who are logged in to the same database as i am ,be able to see and manipulate tabels and stored procedure.
I used grant privilege to achieve this.
grant all on tablename to user;
but it is not working ie on querying the table it is showing no such table or view exists.
How should i achieve this.
The other user may have to use a schema name when accessing the table. eg. select * from user1.table1