I do MSSQL administration and recently got involved with Oracle. So my Oracle admin skills obviously is weak. I have a question regarding Oracle account and permissions. Say I have the following two schemas (users) created on an Oracle 12c instance – John and Dave. How do I grant “John” SELECT privilege to all the tables under the “Dave” schema? If possible, can you list the steps or better yet, the SQL commands.
Thank you
FOR x IN (SELECT table_name FROM all_tables where owner='DAVE')
LOOP
EXECUTE IMMEDIATE 'GRANT SELECT ON ' || x.table_name || ' TO JOHN';
END LOOP;
Related
I am a beginner to ireports.I want to create an ireport with oracle 11g using the default tables present in xe. I used EMP table from xe and it showed error ORA-00942 table or view does not exist when i run the query select * from EMP.
Please help!!!
Generally speaking, you should connect to user that contains tables you'd like to use in the report you're creating. So, if it is EMP table and it belongs to Scott, connect as Scott.
By default, its username/password combination is scott/tiger (all lower case). There's a chance that it (user) is locked. If so, connect to the database via SQL*Plus or SQL Developer or any other tool you use (as a privileged user, such as SYS or SYSTEM if there's no other you have - I presume you don't) and do the following:
alter user scott account unlock;
alter user scott identified by tiger;
After that, establish connection to Scott in iReport (providing previously mentioned credentials) and you should be able to query the EMP table.
I'm trying to import a DB dump {Oracle XE 11g (11.2.0.2.0)}, created by using the EXPDP command. Following is the command that I used to import.
impdp vnp/vnp directory=MY_DATA_PUMP_DIR dumpfile=EXPDP_DUMP_26_01_2018.DMP remap_schema=VNP_ADMIN:VNP remap_tablespace=SYSTEM:USERS,DATA:USERS;
When I run this command, I get a lot of errors containing the same reason
ORA-00959: tablespace 'USERS;' does not exist
However, when I run select tablespace_name from dba_tablespaces; I see that USERS tablespace is present.
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
USERS
After reading a few related questions, I saw that it could be related to privileges for the user VNP and I have provided privileges too.
SQL> alter user vnp quota unlimited on users;
User altered.
SQL> grant UNLIMITED TABLESPACE to vnp;
Grant succeeded.
Still I'm getting the same error when I try to import this DB dump. Can you please point me to a correct direction as to why this happens..? Thanks in advance.
How trivial!
ORA-00959: tablespace 'USERS;' does not exist
^
tablespace doesn't really have a semi-colon as a part of its name, eh?
IMPDP is ran at the operating system command prompt. As such, it doesn't require (and shouldn't have) a terminator (as opposed to SQL commands).
Additionally, if it still doesn't work once you remove the semi-colon, try to split REMAP_TABLESPACE in two:
remap_tablespace=SYSTEM:USERS remap_tablespace=DATA:USERS
How can I parameterise a SQL REVOKE command?
DECLARE #ViewName nvarchar = 'MyViewName'
DECLARE #UserRole nvarchar = 'MyRoleName'
REVOKE SELECT ON [#ViewName] TO [#UserRole]
Outputs the following error:
Cannot find the object '#ViewName', because it does not exist or you do not have permission.`
Do I need to use Dynamic SQL to solve this or is there another way?
My actual Use Case is in ASP.NET SqlDataClient and the code is being generated, so I have limited control over it. The code being sent to SQL (sniffed by SQL Profiler) is:
exec sp_executesql N'REVOKE SELECT ON [#ViewName] TO [#UserRole]',N'#ViewName nvarchar(24),#UserRole nvarchar(12)',#ViewName=N'MyViewName',#UserRole=N'MyUserRole'
Because GRANT and REVOKE require considerable permissions themselves, it's usually attractive to do this in a stored procedure that builds the dynamic SQL and can execute the commands under a different credential. That way you can selectively assign the right to REVOKE by controlling access to the stored procedure, add auditing if this ever becomes a requirement, and last but not least you can keep using parameters.
In this case:
CREATE PROCEDURE dbo.RevokeSelect(#ObjectName NVARCHAR(128), #RoleName NVARCHAR(128))
WITH EXECUTE AS OWNER AS BEGIN
SET NOCOUNT ON;
DECLARE #SQL NVARCHAR(MAX);
SELECT #SQL = REPLACE(REPLACE(
N'REVOKE SELECT ON #ObjectName TO #RoleName;',
'#ObjectName', QUOTENAME(#ObjectName)),
'#RoleName', QUOTENAME(#RoleName))
;
-- For debugging
--PRINT #SQL
EXEC (#SQL)
END;
GO
GRANT EXECUTE ON dbo.RevokeSelect TO [application_login];
Thanks to EXECUTE AS OWNER, the [application_login] account needs no additional permissions; it can REVOKE SELECT on any object in the database through the stored procedure. This can be exactly what you want, but if it's not, you should remove EXECUTE AS OWNER and grant individual CONTROL permission on the objects (but this, of course, allows lots of other operations as well).
Take care that a procedure that performs dynamic SQL needs careful review to ensure it's not susceptible to SQL injection, just like anything else that uses dynamic SQL. Obviously this is even more important if the procedure uses EXECUTE AS OWNER, since it could do anything. In this case, applying QUOTENAME to both parameters takes care of that.
Last but not least, while EXECUTE AS OWNER is simple and convenient, it will fail if the database owner is not an account but a group. In this case, if you want to delegate permissions, you'll have to create a proxy account for use in EXECUTE AS or sign the stored procedure with a certificate. You may want to do this anyway if developers can't be trusted with the power of EXECUTE AS OWNER. That goes beyond the scope of this answer, but Erland Sommerskog has an excellent writeup on this topic.
The past two times we have rebooted our sql server, our website has gone down. The reason appears to be because the tempdb is getting recreated and the ASPState user is losing permission to read/write to the tempdb (it is an ASP site and session data is stored in the sql server)
This was not a problem until about two weeks ago. Does anyone know how I can prevent the sql server from resetting tempdb permissions after a reboot? Or why this only started happening recently? We are using MS SQL Server 2005.
First off, you shouldn't assign permissions to the tempdb directly. For the obvious reasons that it gets recreated on every reboot.
Which actually raises a question: why do you need to have direct permissions to this database anyway?
You don't need any permissions beyond just being able to connect to sql server in order to create temp tables. However, if you are creating real tables in the tempdb, then I highly suggest you change this to use a dedicated database for this purpose.
UPDATE
Based on Martin's comment all I can say is wow. I would never even have considered that this would have been an option.
Okay, now that I've recovered from the shock.
Create a new job in sql server that executes on a schedule. The schedule should be set to "Start Automatically whenever SQL Server Agent Starts". The job should recreate your necessary tempdb permissions.
In a nutshell, when the server is rebooted the SQL Server Agent will be restarted (provided the service is set that way). When it restarts it will kick off this job that will then fix your permissions. I'd expect the site to remain down for only a few seconds more than it takes for SQL server to completely restart.
I know this is an old question but found some new information regarding the tempdb behaviour on restarting.
The tempdb is essentially recreated from the 'model' db and that is the reason why all changes to it are lost. If you make a change to persist your changes even after restart make the same changes to the 'model' db as you would to the 'tempdb'.
Have a look at the following: Does tempdb Get Recreated From model at Startup?
The Model database is used as a template for TempDB. Add users and permissions to model and the same usere and permissions will be used on TempDB. I do not say that this is the optimal solution for every case but it worked for me in a situation where an application needed speciffic TempDB access.
Create a startup script on sql Server as below:
use master
go
drop proc AddAppTempDBOwner
go
create proc AddAppTempDBOwner as
declare #sql varchar(200)
select #sql = 'use tempdb' + char(13)
+ 'exec sp_addrolemember ''db_owner'', ''app'''
exec (#sql)
go
exec sp_procoption 'AddAppTempDBOwner', 'startup', 'true'
go
Here's a script to create a startup stored procedure, which loops over Logins and creates Users in tempdb as db_owner. This script does not have harcoded logins.
As a result even after SQL machine restarts all SQL logins will have privileges to access tempdb.
USE [master]
GO
IF EXISTS ( SELECT *
FROM sysobjects
WHERE id = object_id(N'AddUsersToTempDb')
and OBJECTPROPERTY(id, N'IsProcedure') = 1 )
BEGIN
DROP PROCEDURE AddUsersToTempDb
END
GO
CREATE PROCEDURE AddUsersToTempDb
AS
DECLARE #loginname as NVARCHAR(100);
DECLARE Login_Cursor CURSOR FOR
SELECT loginname
FROM master..syslogins
OPEN Login_Cursor;
FETCH NEXT FROM Login_Cursor INTO #loginname;
WHILE ##FETCH_STATUS = 0
BEGIN
IF (#loginname <> 'sa' AND (NOT #loginname LIKE '##%') AND (NOT #loginname LIKE '%\%'))
BEGIN
PRINT #loginname
IF EXISTS(SELECT * FROM [tempdb].sys.database_principals WHERE type_desc = 'SQL_USER' AND name = #loginname)
PRINT ' - user already exists'
ELSE
BEGIN
PRINT ' - creating user'
DECLARE #Sql VARCHAR(MAX)
SET #Sql =
'USE Tempdb' + char(13) +
'CREATE USER ' + #loginname + ' FOR LOGIN ' + #loginname + char(13) +
'EXEC sp_addrolemember db_owner, ' + #loginname
EXEC (#Sql)
END
END
FETCH NEXT FROM Login_Cursor INTO #loginname;
END;
CLOSE Login_Cursor;
DEALLOCATE Login_Cursor;
GO
EXEC sp_procoption 'AddUsersToTempDb', 'startup', 'true'
GO
The tempdb database in SQL server is (from everything I've ever read, heard, or experienced) completely dropped and recreated every time the service is started up. Thus, anything stored within or written to that database, including roles, users, or other access right settings, will be wiped out. Barring some fussy code to set/reset them whenever the instance starts up, I don't think you can work around this. (I don't think anything set in the model database gets copied over to tempdb when it's created, but I've never even thought about that...)
Are any such settings being written to that databases? Are you sure that your system has not been recently changed or updated to do so? Possibly relevant, how often does the SQL instance get stopped and restarted? (It's not uncommon--if not wise--for SQL to run for months if not yers without a restart...)
We envision a Diagnostics-process in a ASP.NET WebForms application (.NET4, C#): we dispatch end-to-end a diagnostics signal from UI into the database to verify that all layers of our web-architecture are alive and well. Until now we supported Oracle and invoked
SELECT * FROM DUAL
ultimately. Going forward we will support MSSQL, we will invoke
SELECT GETDATE()
Does anyone know a universal SQL which would work on any Oracle and MSSQL instance out-of-the-box?
If all you are after is for a SQL statement to execute successfully, then you can use something benign like
SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES
See this link on INFORMATION_SCHEMA support
To use this query in Oracle, you will first have to create the schema and table, even if it only has 1 column with no data.. just to get count(*) working. In going that route, it may be even better to just create a dummy table and count from it rather than from INFORMATION_SCHEMA.TABLES