create or replace TRIGGER pdb_startup
AFTER STARTUP ON DATABASE
BEGIN
EXECUTE IMMEDIATE 'alter pluggable database all open';
END;
i try to made this trigger but i have insufficient privileges
To create a system trigger you must have the "ADMINISTER DATABASE TRIGGER" privilege.
While I don't work with PDB/CDB arrangements, what you are trying to do looks a bit strange. Normally we control database status through scripts external to the database, not in triggers. Are you sure this is the appropriate way to open your PDBs? I would also want to know whether this could deadlock on the library cache. At any rate, any DDL would require that a trigger be declared with the AUTONOMOUS_TRANSACTION pragma.
Related
I know this sounds weird but it's an old project that I'm trying to make work.
I have two schemas SchemaA and SchemaB each one with it's own user.
I'm writing a plsql script in a package in SchemaB, but in this script I need to delete records from a table in SchemaA. But there is a trigger that won't let the delete happen.
So to make it work I have to do this command:
EXECUTE IMMEDIATE 'ALTER TRIGGER SchemaA.TDA_K$TriggerA DISABLE';
But when I do that I get ORA-01031 which is logical since SchemaB cannot disable a trigger From SchemaA
My question is, how can I GRANT the permission on the trigger (or table utilizing that trigger), to SchemaB to be able to disable it.
As per Oracle documentation
" Prerequisites
The trigger must be in your own schema or you must have ALTER ANY TRIGGER system privilege.
In addition, to alter a trigger on DATABASE, you must have the ADMINISTER database events system privilege.
"
I would like to somehow protect databases on my SQL Server from being deleted without entering a password, even by someone with administrative access. There are times where a database has been deleted accidentally (for example, when two databases have similar names) and I'd like to prevent this from being an easy mistake to make.
I'm also open to any suggestions or alternative ideas on how to handle this. Thank you!
Create a Server Level Trigger that Rolls back any attempt to delete a database.
The Trigger will need to be disabled then re-enabled to perform any legitimate deletions.
USE [master]
GO
CREATE TRIGGER [Trig_Prevent_Drop_Database] ON ALL SERVER
FOR DROP_DATABASE
AS
RAISERROR('Dropping of databases has been disabled on this server.', 16,1);
ROLLBACK;
GO
DISABLE TRIGGER [Trig_Prevent_Drop_Database] ON ALL SERVER
GO
Or as a process:
Create a single-column, one row table in Master that will hold a database name.
Insert the name of the database in the Table.
Add an If statement to the trigger to check if the Database being dropped is identical to the Database in the table created in step 1. Otherwise Roll-back.
In this case you wouldn't need to disable the Trigger. But you're creating 2 points in the process where you define the database name.
Capturing the Database Name in a Server Level Trigger should be possible with:
SELECT CAST(eventdata().query('/EVENT_INSTANCE/DatabaseName[1]/text()') as NVarchar(128))
Our SQL Server database has a reporting feature that allows callers to read, but not write, any table, because the user (or, more precise, the connection opened by the web app that's operating on behalf of the user) has only datareader permissions on the database.
We'd like to be able to write a store procedure that is a special "cleanup report" that will scrub the DB of old cached data before running another report. We'd like the same read-only user above to be able to run this stored proc. The queries inside the stored proc will do DELETE operations, but we don't want to give the user the ability to delete anything other than by via calling this proc.
I know about Module Signing but was hoping to avoid the complexity of dealing with certificates.
Is there another solution? We're using SQL Standard Authentication if that matters.
CREATE PROCEDURE dbo.my_procedure
WITH EXECUTE AS OWNER
AS
BEGIN
-- do your stuff here
END
GO
GRANT EXEC ON dbo.my_procedure TO [your_datareader_member];
GO
The granted permission to execute the procedure will allow the delete to occur.
In fact this is a very relevant scenario, to limit ability to perform certain operations (such as delete). The user may not delete random rows from random tables but they can execute a specific targeted delete procedure.
I'm not sure how to even ask this question. We are running SQL Server 2008 R2. I'm not the admin, but a programmer. I need to write an application that updates some database stuff at night. I'm going to set a flag to disable logins to the database, but I want to make a particular database unavailable to anyone except me, even if someone is already logged in to the database. My program will run nightly, as a batch file, presumably with admin privileges.
I'm expecting to produce something like a script of SQL commands. I could take the database offline, except I need to make modifications to it myself. Not sure the best way to handle this.
You can basically just set the database to "single-user" mode and use it exclusively - this T-SQL will do this:
USE master;
GO
ALTER DATABASE AdventureWorks2012
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
(of course - replace AdventureWorks2012 with your own database name!)
This will make the database "single-user", e.g. only you have access to it, and it will boot off any users that's currently online, and will rollback all open transactions.
Read more about single user mode on MSDN!
This example sets the database to SINGLE_USER mode to obtain exclusive access. The termination option WITH ROLLBACK IMMEDIATE is specified in the first ALTER DATABASE statement. This will cause all incomplete transactions to be rolled back and any other connections to the AdventureWorks2012 database to be immediately disconnected.
Since you are using an administrative account to perform the updates, I'll assume the account is in one of these roles: db_owner, dbcreator, sysadmin. Use the ALTER DATABASE SET ... syntax to control database access during the DML operations.
The assumption is that database users you want to lock out aren't in the above mentioned roles.
USE master;
-- only allow members of db_owner, dbcreator, or sysadmin roles to access
-- database, allowing current transactions time to complete. if you want to
-- drop access immediately, add WITH ROLLBACK IMMEDIATE
ALTER DATABASE SET RESTRICTED_USER;
-- data load
-- return database to normal operating state
ALTER DATABASE SET MULTI_USER;
I have a sproc (call it client.UpdateClient) that is executed by a SQL User (call it MyWCFServicesUser.
MyWCFServicesUser has datareader and datawriter permissions on the database. It also has execute permissions on the sproc (but no other permissions).
The sproc will insert a row into client.Client with SET IDENITY_INSERT client.Client ON.
When I run this sproc (from SSMS) with integrated security (I am sa), everything works fine.
When I run it as MyWCFServicesUser (from SSMS) it fails with this error:
Msg 1088, Level 16, State 11, Procedure UpdateClient, Line 33
Cannot find the object "client.Client" because it does not exist or you do not have permissions.
I usually have all my sprocs and tables in the default (dbo) schema, but this time I am trying to not use dbo.
Is that why I don't have permissions? Do I need to elevate the sproc somehow? Or the user? Or somehow change the schema?
I am stumped...
Turns out that SET IDENTITY_INSERT requires alter permissions by the user.
The proper way to resolve privilege requirements in store procs is to use code signing. This way you grant the required privilege (ie. ALTER TABLE) to the procedure, not to the user, and you need only grant EXECUTE on the procedure (or schema) to the user. The advantage is that your low privilege user can only invoke the procedure and do whatever action requires the elevated privilege (ie. setting identity_insert on) as controlled by the procedure. Had you been grant the required privilege directly to the user he/she could use it for any operation permitted by said privilege (eg. add columns, drop constraints etc etc). The link has several examples.
That being said, I must call out that your question is about SET IDENTITY_INSERT, which is a special setting normally used for one-time data load. The fact that you are setting this from what seems like a routine CRUD UpdateClient procedure is a bit of a code smell.
what will matter is who is the owner of the objects you mentioned.
Any chance they were created by different users? Maybe sa is the owner of the table and MyWCFServicesUser owns the proc?
See this link about Ownership Chains http://msdn.microsoft.com/en-us/library/ms188676.aspx it may help you on your investigation