I created SQL database on Azure. I tried to clear cache from SQL Server Management
using:
DBCC FREEPROCCACHE, DBCC FREESYSTEMCACHE ('dbo')
Unfortunately I am not successfull.
I get the error
User 'dbo' does not have permission to run DBCC freesystemcache.
How is this possible, as dbo is the owner of a database?
Like #MJH stated in the previous answer, executing this requires ALTER SERVER STATE permissions. The article DBCC FREESYSTEMCACHE (Transact-SQL) also clearly shows it does not apply to Azure SQL Database.
Since Azure SQL is a managed service, this will be handled by the platform.
Extra: see ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)
Instead of DBCC FREEPROCCACHE please try the following statement:
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE
The ALTER DATABASE SCOPED CONFIGURATION statement requires ALTER ANY DATABASE SCOPE CONFIGURATION permission on the database. This permission can be granted by a user with CONTROL permission on a database.
Related
I have restored a SQL Server 2019 database from a .BAK file to a Google Cloud SQL instance.
I can connect to the instance using Visual Studio SQL Connection. I issue the following command to check the database owner, which should be: mydb_adm
USE master;
SELECT suser_sname(owner_sid) AS 'DB Owner' FROM sys.databases WHERE name = 'mydb';
DB Owner
--------
sqlserver
The above is expected, as the restore was done while using the sqlserver account which is the default user created when the SQL instance is provisioned by Google Cloud (according to the docs).
So, I need to change the DB owner; I execute the following command:
USE mydb
EXEC sp_changedbowner 'mydb_adm'
The system displays the following error message:
Msg 15151, Level 16, State 1, Line 1
Cannot find the principal 'mydb_adm', because it does not exist or you do not have permission.
The same message is displayed for:
ALTER AUTHORIZATION ON DATABASE::mydb TO mydb_adm;
However, the "mydb_adm" principal DOES exist, i.e.:
SELECT name, sid FROM sys.server_principals WHERE name = 'mydb_adm';
name sid
---- ---
mydb_adm 0xD81398C7DB0D724BB2738A2EC59BB554
.. so it must be a permission problem with the sqlserver account. When I query the DB, it appears the "sqlserver" user does NOT have ALTER permissions, i.e.:
UserName Permission Type Permission State
-------- --------------- ----------------
sqlserver ALTER DENY
... So how can I change the database owner or issue any ALTER commands using the "sqlserver" account? (There seems to be no way to grant the ALTER permission to the sqlserver user).
Any help / advice would be appreciated.
Thank-you to #DanGuzman for providing a "work-around", i.e.: while connected to the SQL instance using the "sqlserver" user, the following commands were used:
USE mydb;
CREATE USER mydb_adm;
ALTER ROLE db_owner ADD member mydb_adm;
After some additional digging, I also found the following in the Google Cloud docs at https://cloud.google.com/sql/docs/sqlserver/users, which states:
Cloud SQL for SQL Server is a managed service, so it restricts access
to certain system stored procedures and tables that require advanced
privileges. In Cloud SQL, you cannot create or have access to users
with superuser permissions.
Note: The sysadmin role is not supported. Therefore, you cannot run
system stored procedures that require the sysadmin role. As one of
the many examples, you cannot run the sp_OADestroy stored procedure
because it requires the sysadmin role.
As well as the following from the SQL Server docs at https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-authorization-transact-sql?view=sql-server-ver15#remarks, which state:
Requirements for the person executing the ALTER AUTHORIZATION
statement: If you are not a member of the sysadmin fixed server role,
you must have at least TAKE OWNERSHIP permission on the database, and
must have IMPERSONATE permission on the new owner login.
hence, commands such as EXEC sp_changedbowner ... or ALTER AUTHORIZATION ON DATABASE:: ... will raise the error (Msg 15151, ... you do not have permission.)
Hope that helps anyone else that may run into this type of issue.
I am the database owner on my Azure Database and I confirmed that using SELECT IS_MEMBER('db_owner') (returns 1)
When I try to run the command:
ALTER DATABASE [db] MODIFY (EDITION = 'standard', SERVICE_OBJECTIVE = 'S3');
it gives me the error as follows:
User does not have permission to alter database 'db', the database does not exist, or the database is not in a state that allows access checks.
So I tried to grant myself the alter permissions on the database:
GRANT ALTER ON DATABASE:: db TO [USER_NAME]
Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.
I dont know why I cant change the Azure Edition through script. I have done this through the Azure dashboard portal and it works just fine. But not through SSMS. Am I doing something wrong?
Go look at the documentation. Just because you are owner does not mean you can alter the database.
https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-database-azure-sql-database
I tried to migrate a SQL Server database by Export Data-tier Application (.bacpac file) from an Amazon RDS instance to other, but import didn't succeed. So now I want to delete the database (which is empty), when I try to:
DROP DATABASE mydatabase;
I get the error:
Cannot drop the database 'mydatabase', because it does not exist or
you do not have permission
Some context:
I've tried using SQL Server Management Studio, and choosing close connections: same error.
I'm logged as master user.
I can create and drop other databases, but not this one.
I just have these effective permissions on this database: CONNECT, SHOWPLAN, VIEW DATABASE STATE, VIEW DEFINITION (don't know why or how is this possible).
Any help is greatly appreciated!
I ran into this same issue. After trying to restore a database via SSMS using a .bacpac, it fails and leaves you with a database that you appear to not have permissions to drop.
A workaround, is to use the rdsadmin rename function to rename it to something else, which then seems to fix the permission issue and allows you to drop it.
EXEC rdsadmin.dbo.rds_modify_db_name N'<OldName>', N'<NewName>'
Then just drop the DB. Hope that helps someone else in the same predicament.
This is the answer for an old thread but who knows, it might help someone having the same issue.
I ran into the same problem, but in my case, my database was in an offline mode. If the database is in offline mode, it won't allow you to drop it with the drop command. first, you should bring the database back online by running this sp and then execute the drop table command.
EXEC rdsadmin.dbo.rds_set_database_online databasename
If your database is in a Multi-AZ deployment, then you need to run this command to drop those databases:
EXECUTE msdb.dbo.rds_drop_database N'DBName'
Sounds like your not a member of the correct role.
https://msdn.microsoft.com/en-us/library/ee240822.aspx
Permissions
A DAC can only be deleted by members of the sysadmin or serveradmin fixed server roles, or by the database owner. The built-in SQL Server system administrator account named sa can also launch the wizard.
https://msdn.microsoft.com/en-us/library/ms178613.aspx
Permissions
SQL Server - Requires the CONTROL permission on the database, or ALTER ANY DATABASE permission, or membership in the db_owner fixed database role.
Azure SQL Database - Only the server-level principal login (created by the provisioning process) or members of the dbmanager database role can drop a database.
Parallel Data Warehouse - Requires the CONTROL permission on the database, or ALTER ANY DATABASE permission, or membership in the db_owner fixed database role.
I'm experiencing a recurring problem whereby a user's CREATE SYNONYM permissions within TEMPDB are being lost. Is there a reason why these permissions do not seem to be permanently persistent?
The error I am getting:
> System.Data.SqlClient.SqlException (0x80131904): CREATE SYNONYM
> permission denied in database 'tempdb'
I left you the comment but what you can do is the following
create a proc in the master database, in that proc give the permissions for the tempdb (you can use USE tempdb in the proc if you use dynamic sql)
then mark the proc to run at startup
exec sp_procoption N'MyProcName', 'startup', 'on'
Now everytime sql server is restarted, this proc will run and give the permissions
See also here List all stored procedures that run at startup in SQL Server
tempdb is created as a copy of the model database every time the server is restarted. My guess is that there's a server restart happening between when you grant the permission to the user and when you get this error message. That said, you can either grant the permission in model and it will be in tempdb when the server restarts or you can do something like creating a startup stored procedure to grant the permission in tempdb.
My requirement is that user performing alter CANNOT be sysadmin (it can have all other rights but not sysadmin).
I am running a query from local server which should modify a remote one
EXEC ('ALTER DATABASE REMOTEDB MODIFY FILEGROUP ftfg_REMOTEDB NAME=ftfg_REMOTEDB') at [REMOTESERVER]
This query works once I add sysadmin right to the user but without the right, it give the following error:
The server principal "USERWITHOUTSYSADMIN" is not able to access the database "REMOTEDB" under the current security context.
I am on SQL Serve 2008.
Please Help!
After much research: This is not possible:(
Put the EXEC command in a stored procedure and grant execute on the procedure to the user. It won't STOP a sysadmin from executing it, but it will allow others to execute it as well. Be VERY, VERY careful with this!
Can you allow the user to impersonate someone with the appropriate permissions?
EXEC ('ALTER DATABASE REMOTEDB MODIFY FILEGROUP ftfg_REMOTEDB NAME=ftfg_REMOTEDB')
AS USER = 'UserWithAppropriatePermissions'
AT [REMOTESERVER]