I am testing to see if a SQL Server server based program can also work on AWS Cloud Server with 2016 SQL Server on the Amazon server. In order for me to test it, I need to restore 2 databases.
The first one eventually restored fine once i figured it out...restoring the database from my S3 "bucket" BAK file.
So then I tried to restore the 2nd database, using the same restore stored proceudre, and get this message:
[2017-12-28 02:44:22.320] The file 'D:\rdsdbdata\DATA\smsystemdata.mdf' cannot be overwritten. It is being used by database 'amwsys'.
[2017-12-28 02:44:22.320] File 'sm_system_data' cannot be restored to 'D:\rdsdbdata\DATA\smsystemdata.mdf'. Use WITH MOVE to identify a valid location for the file.
I can't find where to use the WITH MOVE because it won't let me restore it interactively through the Management Studio restore menu; instead I have to give it a stored procedure command:
exec msdb.dbo.rds_restore_database
#restore_db_name='sample99',
#s3_arn_to_restore_from='arn:aws:s3:::lighthouse-chicago/sample999.bak';
And each time it tells me it can't restore it because it's going to overwrite the first database's files.
Much thanks
bill
I think you are stuck in RDS's restriction.
I had the similar problem as you. Multiple restore from one DB instance is impossible at RDS.
Here is RDS's restriction you may encounter.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.html
You can't restore a backup file to the same DB instance that was used
to create the backup file. Instead, restore the backup file to a new
DB instance. Renaming the database is not a workaround for this
limitation.
You can't restore the same backup file to a DB instance multiple
times. That is, you can't restore a backup file to a DB instance that
already contains the database that you are restoring. Renaming the
database is not a workaround for this limitation.
If you are in this case, you can't use .BAK file. To avoid it, you should create DB instance with DML and import table data.
Related
I am trying to restore a db with a backup, but it fails each time because of a file in use. The file is ftrow_FTC{xxxxxxx}.ndf
Does anyone know what this file is and what its for? Do I need it? If not, how can I get rid of it? Thank you.
I should add, this is SQL 2012 server on a Server 2008 R2.
the ftrow_FTC{xxxxxxx}.ndf if a Full-Text Catalog file. You're probably using SQL Server Management Studio wizard to restore that database. However, you can also use a t-sql command to do the restore.
In the latter case you could tell SQL Server to restore your full text catalog file under different name/path with the RESTORE ... WITH MOVE command:
RESTORE DATABASE DBNAME from disk = N'd:\path\to\your\backup.bak'
WITH MOVE 'ftrow_FTC{xxxxxxx}.ndf' TO 'd:\path\to\new\FT_location\ftrow_FTC{xxxxxxx}.ndf'
replace the DBNAME with your real DB name and the ftrow file name with real file name.
UPDATE: you can also easily restore your DB with full text catalog under different file name using SQL Server Management Studio dialog. During restore simply locate your ftrow file record in the DB files list and assign it to different path. That way you will not get conflict with the ftrow file used by your live DB.
HTH
I have a small (few hundred MB) SQL Server database running on RDS. I've spent several hours trying to get a copy of it onto my local SQL Server 2014 instance. All of the following fail. Any ideas what might work?
Task -> Backup fails because it doesn't give my admin account permission to backup to a local drive.
Copy Database fails during create package with While trying to find a folder on SQL an OLE DB error was encountered with error code 0x80040E4D
From SSMS, while connected to the RDS server, running BACKUP DATABASE. This fails with message BACKUP DATABASE permission denied in database 'MyDB'. Even after running EXEC sp_addrolemember 'db_backupoperator' for the connected user.
General scripts generates a 700MB .sql file. Running that with sqlcmd -i fails at some point after producing plausible .mdf and .ldf files that can't be mounted on the local server (probably because the sqlcmd failed to complete and unlock them).
AWS has finally provided a reasonably easy means of doing this: It requires an S3 bucket.
After creating a bucket called rds-bak I ran the following stored procedure in the RDS instance:
exec msdb.dbo.rds_backup_database
#source_db_name='MyDatabase',
#s3_arn_to_backup_to='arn:aws:s3:::rds-bak/MyDatabase.bak',
#overwrite_S3_backup_file=1;
The following stored procedure returns the status of the backup request:
exec msdb.dbo.rds_task_status #db_name='MyDatabase'
Once it finished I downloaded the .bak file from S3 and imported it into a local SQL Server instance using the SSMS Restore Database... wizard!
The SSIS Import Export Wizard can generate a package to duplicate a whole set of tables. (It's not the sort of Copy Database function that relies on files - it makes a package with data flow components for each table.)
It's somewhat brittle but can be made to work :-)
SSMS Generate Scripts feature can often fail with any large data set as the script for all the data is just to large/verbose. This method never scripts out the data.
Check this out: https://github.com/andrebonna/RDSDump
It is a C#.NET Console Application that search for the latest origin database Snapshot, restore it on a temporary RDS instance, generate a BACPAC file, upload it to S3 and delete the temporary RDS instance.
You can transform your RDS snapshot into a BACPAC file, that can be downloaded and imported onto your local SQL Server 2014 instance using the feature answered here (Azure SQL Database Bacpac Local Restore)
Redgate's SQL Compare and SQL Data Compare are invaluable for these types of things. They are not cheap (but worth every penny imo). But if this is a one-time thing, you could use the 14 day trial and see how it behaves for you.
http://www.red-gate.com/products/
I have a database in SQL Server 2014 on premises. For that database I have a backup to Azure storage configured using smart_admin.sp_set_db_backup procedure.
Recently I had to move the database files from one disk to another. I detached database, moved files, reattached it.
After that my backup stopped working. The function smart_admin.fn_backup_db_config shows that database backup record exists but database marked as is_dropped = 1
Any attempt to enable or disable backup for this database fails with error:
SQL Server Managed Backup to Windows Azure cannot configure the database, 'DATABASE_NAME', because it either does not exist or is offline.
Any way I can remove backup configuration information and create a new one? One of the ideas I found is rename the database, but I cannot do that in production.
Vad's answer is close, but there can be more than one record in autoadmin_managed_databases for a given db_name. You need to get the last record, which is the one with the max autoadmin_id. I picked the wrong one, and SQL Server repopulated the drop_date after I ran smart_admin.sp_set_db_backup or the 15 minute interval ran.
use msdb;
go
update [dbo].[autoadmin_managed_databases]
set drop_date = null
where [autoadmin_id]= (select max(autoadmin_id)
from [dbo].[autoadmin_managed_databases]
where db_name = '<DROPPPED_DATABASE_NAME>')
go
Managed Backups - is_dropped flag set to Yes after detaching database
and reattaching DB
Rename the database and set up managed backup again.
Reference
As I mentioned earlier I was not allowed to rename the database on the Production. So I found where it's marked as dropped and changed the value. That helped. Automated backups for the database started working again. IMO what happened looks like a bug in SQL Server 2014.
use msdb;
go
update [dbo].[autoadmin_managed_databases]
set drop_date = null
where [db_name] = '<DROPPED_DATABASE_NAME>'
go
I have a backup of a database from another SQL Server 2005 machine. I'm attempting to restore it to my SQL Server 2008 instance.
I have created a new database for the restore to go in to, but when attempting the restore with the following (generated by ssms):
RESTORE DATABASE [WendyUAT]
FROM DISK = N'D:\wanda20130503.bak'
WITH FILE = 1,
MOVE N'Wendy' TO N'D:\databases\\WendyUAT.mdf',
MOVE N'Wendy_log' TO N'D:\databases\\WendyUAT.ldf',
MOVE N'sysft_WendyFti' TO N'D:\databases\\WendyUAT.WendyFti',
NOUNLOAD, REPLACE, STATS = 10
I get the following error:
System.Data.SqlClient.SqlError: The operating system returned the error '32 (The process cannot access the file because it is being used by another process.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on 'D:\databases\WendyUAT.mdf'.
As far as I can tell (using Process Explorer etc) nothing else is using the file. I've disabled real-time protection in windows defender. I just cannot understand why SQL Server thinks the file is in use as windows explorer lets me delete it with no problems so Windows doesn't seem to think it's in use.
Any help would be gratefully received.
How are you connecting to your SQL Server in your application before running this backup? What database are you connecting to?
You cannot connect to the WendyUAT database and use it when you want to restore it - you'll have to explicitly use some other database, e.g. master, before running your SMO restore code
All my T-SQL restore scripts will always include:
USE [master]
GO
RESTORE DATABASE [WendyUAT] ......
So if you run this backup from your app, make sure you explicitly connect to e.g. master before running this T-SQL restore script
Update:
Is this something you did on purpose, or might it just be a typo??
MOVE N'Wendy' TO N'D:\databases\\WendyUAT.mdf',
* **
* *
* * two backslashes here -why???
* only one backslash here...
Does it work if you use single backslashes only??
RESTORE DATABASE [WendyUAT]
FROM DISK = N'D:\wanda20130503.bak'
WITH FILE = 1,
MOVE N'Wendy' TO N'D:\databases\WendyUAT.mdf',
MOVE N'Wendy_log' TO N'D:\databases\WendyUAT.ldf',
MOVE N'sysft_WendyFti' TO N'D:\databases\WendyUAT.WendyFti',
NOUNLOAD, REPLACE, STATS = 10
Try following script before restore
alter database DB_NAME set offline with rollback immediate;
and this script after restore to enable multi user
alter database DB_NAME set online with rollback immediate;
In my case I had installed two instances of SQL Server (2008 R2 and 2012). I had to stop one SQL Server service (2008 R2) from my two available SQL instances. This helped me to resolve this issue and I could restore my database.
I have the same issue.
What I did is that I just rename the Destination database to different name, then the restoration executed successfully. After the restoration, I just rename it to my desired database name.
I had to uninstall SQL Server 2005, because it was configured to be used only in windows authentication mode, and install it again in mixed mode. I had to take a backup of my only database there, and restore it again on installing the sql server back, though the backup was taken successfully but when am trying to restore it, it is giving me an error as
System.Data.SqlClient.SqlError: The media has 2 media families but only 1 are provided. All members must be provided. (Microsoft.SqlServer.Smo)
I am using SQL server management studio, and trying to restore the database by right clicking on the databases folder, selecting restore database option, and then providing a database name, in "destination for restore", and in "source for restore" am selecting from device option and then providing with the path of my .bak file(backup file of the database), but the thing is not working, saying that the restored has failed and giving the above mentioned description for the error.
I suggest that you do not use the SSMS GUI to perform your database RESTORE unless you are familiar with all of the various options and settings. Using the T-SQL RESTORE command you can define explicitly what you are looking to do.
I would suggest that you first verify your database backup file by using the RESTORE VERIFYONLY command.
See SQL Server Books online:
http://msdn.microsoft.com/en-us/library/ms188902.aspx
Is there any chance you backed up to two backup files (ie, striped backup), and you're only specifying one of them in the restore? The restore seems to be complaining that if can't find all the files it needs to start the restore.
if you haven't already tried this: crate a blank database with the exact same name as the data base you're restoring from, with the files at the exact same location. right click the blank database and restore from your backup.