Brief background info
We´re moving a database from Windows Server 2012 to 2016 in a critical production environment and are experiencing problems where the database on the new server gets set to Restricted user after the restore is done.
This is the order things are done:
2012 db is manually set to restricted user
Backup is made from 2012 db
2016 db is restored using backup in step 2
2016 db is unwillingly set to restricted user
The reason that we set the 2012 db in restricted user in the first place is to force logged in users to a stand-by environment while the 2016 db is being set-up.
The team that is doing this backup and restore claims that the database state is included in the backup as well and that that's the reason the new database get's set into restricted user as soon as the restore is done.
The new database being set to restricted user is not a huge problem since it's possible to manually change it back to multi user, but since this environment is of such critical nature, we don't want to risk having our users on the backup system any longer then necessary
So here's the actuall question:
When restoring a database from a backup, is the database state included in the backup and brought to the newly restored database? And if so, is it possible to exclude this?
Thanks in advance! :)
The RESTORE documentation states:
During a restore, most of the database options that are settable using
ALTER DATABASE are reset to the values in force at the time of the end
of backup.
So if the source database is in RESTRICTED_USER, the database will be set to that mode during the restore. You can, however, specify the WITH RESTRICTED_USER option during the restore to set the restored database to RESTRICTED_USER if the source database was backed up with a different option.
But there is no RESTORE option to specify WITH MULTI_USER so you'll need to execute ALTER DATABASE after the RESTORE to change the option.
Is there a way to backup and restore a database without the data. I just want the tables, scheme, stored procedures, etc. without the data.
How to backup the database?
How to restore it in SSMS?
If I'm not mistaken you can do this:
Right click the database
Select Script Database As
Select Create to
Select file
This gives you a script that you can run on a different server to set up the db.
Update:
You probably need to follow the steps here
I'm trying to backup a live database to my computer and I can't find the option to do it. I'm connecting to it using Microsoft SQL Server Management Studio 2008 R2. I'm a MySQL monkey, so I'm used to being able to backup to .sql files and move them around.
Anyone have any idea how I can create a file backup of the database? I've found the backup option which only backs up on the server, or the export, which seems to only allow a single table, or code an SQL query, which I'm not too sure on, short of putting in something like SHOW TABLES;
Anyone have any ideas? I'm limited to readonly access for various reasons, nothing bad, promise!
You will only be able to backup the database to a location the service account for SQL has access to. If you have access to a central share on the server/network that you can access and the service can, you might backup to that location and then browse from your computer to pull it down.
If you are just wanting the database structure you could script the database out to a file. This would let you save it locally. If you also want the data though doing a full backup is the quickest way I know of.
EDIT
I would use the T-SQL BACKUP comand and include WITH COPY_ONLY to backup the database, since you stated this is a "live" database. If a scheduled job is performing backups against the database and you break in to do an additional one you will effect the backup recovery chain of the database. Using the COPY_ONLY will allow you to get a backup of the database without requiring it in the event of a recovery need.
You can also create sql dumps with Management Studio.
Right-click the database and select Tasks - Generate Scripts. This will open a wizard that allows you to select what the dump should include (e.g. tables, indices, views, ...).
Make sure you set "Script Data" to true if you want your dump to include inserts.
You can enter a valid UNC path in the Backup option.
Dumb question - what's the best way to copy instances in an environment where I want to refresh a development server with instances from a production server?
I've done backup-restore, but I've heard detach-copy-attach and one guy even told me he would just copy the datafiles between the filesystems....
Are these the three (or two, the last one sounds kind of suspect) accepted methods?
My understanding is that the second method is faster but requires downtime on the source because of the detach aspect.
Also, in this situation (wanting an exact copy of production on a dev server) what's the accepted practice for transferring logins,etc.? Should I just backup and restore the user databases + master + msdb?
Easiest way is actually a script.
Run this on production:
USE MASTER;
BACKUP DATABASE [MyDatabase]
TO DISK = 'C:\temp\MyDatabase1.bak' -- some writeable folder.
WITH COPY_ONLY
This one command makes a complete backup copy of the database onto a single file, without interfering with production availability or backup schedule, etc.
To restore, just run this on your dev or test SQL Server:
USE MASTER;
RESTORE DATABASE [MyDatabase]
FROM DISK = 'C:\temp\MyDatabase1.bak'
WITH
MOVE 'MyDatabase' TO 'C:\Sql\MyDatabase.mdf', -- or wherever these live on target
MOVE 'MyDatabase_log' TO 'C:\Sql\MyDatabase_log.ldf',
REPLACE, RECOVERY
Then save these scripts on each server. One-click convenience.
Edit:
if you get an error when restoring that the logical names don't match, you can get them like this:
RESTORE FILELISTONLY
FROM disk = 'C:\temp\MyDatabaseName1.bak'
If you use SQL Server logins (not windows authentication) you can run this after restoring each time (on the dev/test machine):
use MyDatabaseName;
sp_change_users_login 'Auto_Fix', 'userloginname', null, 'userpassword';
The fastest way to copy a database is to detach-copy-attach method, but the production users will not have database access while the prod db is detached. You can do something like this if your production DB is for example a Point of Sale system that nobody uses during the night.
If you cannot detach the production db you should use backup and restore.
You will have to create the logins if they are not in the new instance. I do not recommend you to copy the system databases.
You can use the SQL Server Management Studio to create the scripts that create the logins you need. Right click on the login you need to create and select Script Login As / Create.
This will lists the orphaned users:
EXEC sp_change_users_login 'Report'
If you already have a login id and password for this user, fix it by doing:
EXEC sp_change_users_login 'Auto_Fix', 'user'
If you want to create a new login id and password for this user, fix it by doing:
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
UPDATE:
My advice below tells you how to script a DB using SQL Server Management Studio, but the default settings in SSMS miss out all sorts of crucial parts of a database (like indexes and triggers!) for some reason. So, I created my own program to properly script a database including just about every type of DB object you may have added. I recommend using this instead. It's called SQL Server Scripter and it can be found here:
https://bitbucket.org/jez9999/sqlserverscripter
I'm surprised no-one has mentioned this, because it's really useful: you can dump out a database (its schema and data) to a script, using SQL Server Management Studio.
Right-click the database, choose "Tasks | Generate Scripts...", and then select to script specific database objects. Select the ones you want to copy over to the new DB (you probably want to select at least the Tables and Schemas). Then, for the "Set Scripting Options" screen, click "Advanced", scroll down to "Types of data to script" and select "Schema and data". Click OK, and finish generating the script. You'll see that this has now generated a long script for you that creates the database's tables and inserts the data into them! You can then create a new database, and change the USE [DbName] statement at the top of the script to reflect the name of the new database you want to copy the old one to. Run the script and the old database's schema and data will be copied to the new one!
This allows you to do the whole thing from within SQL Server Management studio, and there's no need to touch the file system.
Below is what I do to copy a database from production env to my local env:
Create an empty database in your local sql server
Right click on the new database -> tasks -> import data
In the SQL Server Import and Export Wizard, select product env's servername as data source. And select your new database as the destination data.
Its hard to detach your production dB or other running dB's and deal with that downtime, so I almost always use a Backup / restore method.
If you also want to make sure to keep your login's in sync check out the MS KB article on using the stored proc sp_help_revlogin to do this.
The detach/copy/attach method will take down the database. That's not something you'd want in production.
The backup/restore will only work if you have write permissions to the production server. I work with Amazon RDS and I don't.
The import/export method doesn't really work because of foreign keys - unless you do tables one by one in the order they reference one another. You can do an import/export to a new database. That will copy all the tables and data, but not the foreign keys.
This sounds like a common operation one needs to do with database. Why isn't SQL Server handling this properly? Every time I had to do this it was frustrating.
That being said, the only painless solution I've encountered was Sql Azure Migration Tool which is maintained by the community. It works with SQL Server too.
I run an SP to DROP the table(s) and then use a DTS package to import the most recent production table(s) onto my development box.
Then I go home and come back the following morning. It's not elegant; but it works for me.
If you want to take a copy of a live database, do the Backup/Restore method.
[In SQLS2000, not sure about 2008:] Just keep in mind that if you are using SQL Server accounts in this database, as opposed to Windows accounts, if the master DB is different or out of sync on the development server, the user accounts will not translate when you do the restore. I've heard about an SP to remap them, but I can't remember which one it was.
I've got a backup made using the regular SQL Server 2005 backup command. Is there a way to restore just a single table, not the whole DB?
Restore the whole database to another machine (or temporary database), then copy the table seems like the easiest to me.
This is not natively supported in SSMS but it’s possible using third party tools.
Apart from Red Gate (great tools btw) you can try SQL Diff (restore object) and SQL Data Diff (restore data) from ApexSQL.
Disclaimer: I’m not affiliated with ApexSQL but we are their customers and use their tools
The unit of backup and recovery in SQL Server is the database (it is the outer boundary of referential integrity).
Red Gate has some pretty good tools for row-level restore (SQL Data Compare and SQL Backup), but they come at a price.
Detach the current database then restore the database with the date of the tbl you need to a new location (make a sub folder) to put it in keep it separate from your production databases, then restore the database to that sub folder, when completed find the tbl you need and script it to a create script file save to a file, your done with the database delete it then reattached the original one, now scroll down to the tbl you want to restore and script it to a create file (this is a backup only) now delete the tbl, make sure your database is selected and the active one next load the the scripted file you just created with the other database in the query analyzer and run it, it should report successful now check to see if your tbl has been replaced. your done