Is this just me, or is it a wider issue. -- Turns out it is just me.
In SQL Server 2017 with CU15 (14.0.3162.1) you can restore a database over an existing database without the REPLACE option being used. The 'Overwrite the existing database (WITH REPLACE)' option is now irreverent and is ignored.
Confirmed with SSMS 17.8.1 & 17.9.1, both via the GUI and New Query window.
The backups being restored were from SQL Server 2014 (12.0.6024.0) and local backups (SQL Server 2017) exhibit the same behaviour.
So
RESTORE DATABASE [TMP1] FROM DISK = N'F:\tmp\TMP1.bak' WITH FILE = 1, NOUNLOAD, STATS = 5
Is the same as
RESTORE DATABASE [TMP1] FROM DISK = N'F:\tmp\TMP1.bak' WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 5
The REPLACE option overrides several important safety checks that
restore normally performs.
https://learn.microsoft.com/en-us/sql/t-sql/statements/restore-statements-transact-sql?view=sql-server-2017
When doing a RESTORE, SQL Server checks for certain conditions that may lead to problems. As long as none of those conditions are applicable, it will perform the backup, even if that means overwriting an existing database. If any of the safety checks fail, it will give an error message. By adding the REPLACE option, you are telling SQL Server that it's okay to overwrite the files regardless of the safety checks.
------------ EDIT: ---------------
How does SQL Server determine whether the database being restored is the same as the database being overwritten? I did not know the answer when I started writing this, so I've done some research. For this purpose SQL Server uses the FamilyGUID. Every time you create a new database it is tattooed with a FamilyGUID. When a database is backed up, the FamilyGUID is carried along. When it comes time to restore, SQL Server compares the FamilyGUID of the backup to the database being overwritten. If they are the same, then there is no problem. If they are different, you need to use REPLACE.
Perhaps in your case, the FamilyGUIDs are the same.
To find the FamilyGUID of the backup, use:
RESTORE headeronly FROM DISK = N'Q:\MyBackup.bak'
To find the FamilyGUID of the database being overwritten, you can use:
SELECT DB_NAME(database_id) as DatabaseName, database_guid, family_guid
FROM master.sys.database_recovery_status
Are they the same?
Related
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.
A database server crashed. I was able to get the mdf and the log file and I am trying to mount it on another server. I don't have backup as it was a development database.
When I try to attach the mdf and ldf files, Sql Server Management Studio give me this error:
TITLE: Microsoft SQL Server Management Studio
------------------------------
Attach database failed for Server
------------------------------
Could not redo log record (457:14202:19), for transaction ID (0:478674), on page (1:519205), database 'WSS_Content_5555' (database ID 15). Page: LSN = (370:463:113), type = 1. Log: OpCode = 2, context 2, PrevPageLSN: (298:40524:64).
Restore from a backup of the database, or repair the database.
During redoing of a logged operation in database 'WSS_Content_5555', an error occurred at log record ID (457:14202:19).
Typically, the specific failure is previously logged as an error in the Windows Event Log service.
Restore the database from a full backup, or repair the database.
Could not open new database 'WSS_Content_5555'.
CREATE DATABASE is aborted. (Microsoft SQL Server, Error: 3456)
I don't know how to repair the database. Does it need to be attached before beeing repaired? In that case, how can I attach it?
You can try a workaround. In short:
Create a dummy DB with the same name (may need to remove the real DB first, save the original files or rename then).
Take the dummy off line (detach and (set offline or stop the SQL service)).
Delete dummy files, replace then with the real DB files.
Try to re-attach de DB
Edit
As by OP comment note you also can need to rebuild the log (if you lost transactions)
ALTER DATABASE [MyDatabase ] REBUILD LOG ON (NAME=’MyDatabaseLog’,FILENAME=’D:\Microsoft SQL Server\YourDataPath\Data\Logfile.ldf’)
and put the DB in multiple users log (taking the DB off can require you to put it in single use mode)
ALTER DATABASE [nomdb] SET MULTI_USER
For all the gore details you can refer to the Paul Randal Article
(Note in this article the author uses EMERGENCY MODE to (attempt) repair the transaction log)
I already used it with success but depending on the extent of the damage or others details it can be a impossible task. Consider restoring a backup.
Note this stunts are fine in a development server but you really need to plan (and drill) for disaster recovery in a prodution server.
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 database server with two SQL instances on:
SQLExpress
SQLWebEdition
I have a backup script that is executed via a batch file and schedule to back up the databases. Normally this works fine, but I have one particular server I'm setting the scripts up on that has two instances of SQL. I'm able to do this for the SQLExpress instance, but cannot back up the WebEdition ones.
I think the script can only see the one instance and not the other instance.
Is there something I can put in the script so that the SQL script can see a named SQL instance?
eg
This sees one instance of the SQL on the server
BACKUP DATABASE [database] TO DISK = #backupfile WITH NOFORMAT, INIT, SKIP, STATS = 10, COMPRESSION
Where #backupfile is a variable holding the path disk.
the pseudo code of what I need to achieve (or similar)
BACKUP DATABASE the_server_instance \ [database] TO DISK = #backupfile WITH NOFORMAT, INIT, SKIP, STATS = 10, COMPRESSION
Not at all. That is not possible. You can validate that in - cough - the documentation explaining the BACKUP DATABASE command - which you can find at http://msdn.microsoft.com/en-us/library/ms186865.aspx
As you can clearly see there, there is no way to enter a server name. It also makes sense - backup database backs up the database of the active connection.
What you need is 2 scripts, sending each one to the separate database instance. The plus of multiple scripts is that - hey, they can run in parallel.
But if you can explain why you retain the Express edition - there is no reason to have 2 instances like that. Obviously outside of "waste memory and make things less efficient".
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.