AWS RDS SQL Server Backup Restore Issue - sql-server

I have setup the RDS instance for SQL Server 2019 SE. Option group also created with major version=15. SQL Server backup and restore option is added along with S3 settings and IAM role. The option group is also attached with instance.
I executed the command;
exec msdb.dbo.rds_restore_database #restore_db_name='MyDatabaseOnRDS_Staging',
#s3_arn_to_restore_from='arn:aws:s3:::MyBucketName/MyDatabaseOnRDS_Staging.bak';
The above statement created the task which is visible in;
exec msdb.dbo.rds_task_status;
The % complete goes to 100%. But then it shows ERROR in 'lifecycle' column. When I check the details in task_info column, it shows the error at the end;
The proposed new database owner is already a user or aliased in the database. Changed database context to 'master'.
What am I doing wrong?


Ok, the issue was sa user. It was added as a db user. It was in disabled state, but for some reason AWS RDS was not allowing rdsa to be the DB owner of the DB in restore as sa was the part of db users.
I did to following steps;
Changed the sa schema owner to dbo
Removed sa user (just user and not the sa schema) from the DB Users.
Took the backup, copied the backup to S3 and restored it.


You're attempting to restore the database from within a connection to that database. Change the context you're executing the restore operation from to the master database, as the error suggested.

Related

SQL Server - new user has access to master database

I created a new SQL server with a database in Azure and after logging in with the admin account I added a new user that I wanted to only have access to one database.
In SSMS I right clicked on mynewdatabase database and selected New Query.
I executed
CREATE USER mynewuser WITH PASSWORD ='good password here';
ALTER ROLE db_owner ADD MEMBER mynewuser ;
Now after logging in as mynewuser I can still see the master database.
The question is how do I restrict mynewuser to only access mynewdatabase?
I'm sure this is something basic.

In SQL Server, including Azure SQL DB, all users can can see all system databases in sys.databases. This is not the same as being able to connect to them or run queries in them. This does not disclose any sensitive information as these are system databases and whether you saw them listed or not you would know they were there. See https://msdn.microsoft.com/en-us/library/ms178534.aspx#Anchor_0.
Based on the steps you describe, you have created a contained user that should not be able to connect to the master database or run queries in Azure SQL DB.

user: dbo unable to drop database

I have a SQL agent job whereby we do a restore of a full backup of production data on a nightly basis. We are setting up a new server and when I attempt to run the job on the new server I receive an error on the job of
3701 - Cannot drop database because it does not exist or you do not have permission.
This is confounding me because we are using the dbo user to accomplish this step and the database is listed in sys.databases catalog view. I have tried altering the database to put it into single_user to no avail.
The first step of the job kills all connections and that passes. I am not sure where this error is coming from because everything looks in accord to me. We can also drop the database manually through logging in as the sa.

Sql Server Agent job failing to execute stored procedure

I have a stored procedure that I can execute in SSMS with a non domain SQL Server user.
This stored procedure selects data from tables in one database (DB1) truncates and selects into a table in DB2.
The user has datareader,datawriter and dbowner for both databases.
Problem:
When I execute the stored procedure via SS Agent with execute as the user I get the following error
The server principal [user] is not able to access the database [DB1]
under the current security context.
Actions taken So far:
I have tried to resolve this so far by:
Turning on db chaining for both databases
Deleted the user from DB1 and added again
Checked using EXEC sp_change_users_login #Action=’Report’ to see if user orphaned. As this is a database that is a restore of a live one. However I added the user after the restore. The user was not listed as orphaned

A possible workaround if you don't want to have the owner be sa is to have the user be a member of msdb and grant the the SQLAgentOperatorRole in msdb. See if that works.
But to be honest, either use sa or a dedicated service account with enough permissions. It's better if the job runs under that context.

AWS RDS SQL Server unable to drop 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.

SQL Server 2008 -- User not able to access restored Database

I'm trying to move a database from one SQL Server database running on one machine to a another machine that is the test server and copy of the original.
On the main machine, I took a backup of database myDB.
On the test machine, I deleted the existing older database myDB.
On the test machine, I restored the new database myDB.
The data seems to have come across successfully.
But I have a problem accessing the database.
The owner of all tables is 'user1' and user1 exists with the same login on both DB's.
After trying to access the restored database on the test machine though as user1 there are problems.
First it says that the password for user1 isn't correct.
After resetting the password, it says the user1 doesn't have a default database set. But it is set already to myDB. It is the same name as the restored db -- myDB.
What have I done wrong in restoring the DB?
Do I need to have deleted in addition to the DB the user user1 before attempting to restore the backup? I tried that. How do I handle updating a restore and maintaining user access?

after doing the restore do a
ALTER USER user1 WITH LOGIN = user1
inside the restored DB, that will fix the mismapped SID
See also Do you still use sp_change_users_login instead of ALTER USER UserName WITH LOGIN = UserName

To avoid this issue add your user ( the user who is taking backup) as a user of the Backup database, and your user should have (login) access in the new instance.

Resources