In my work as a developer I often restore backups from a fileshare to my local sql server.
The latest backup is posted at irregular intervals on the fileshare. The new backup has the same name as the old one. I copy the backup file to my computer and restore it.
I would like to know if it is possible to quickly compare my local backup file to the one on the fileshare, do they have some embedded checksum or such?, so I know if it is worth to copy the file or not?
You could use an MD5 to do this. It's a checksum for any file.
Microsoft have a utility for making these, and you can run it from the command line. Here's an article including a link to download:
https://support.microsoft.com/en-us/kb/841290
I ended up using the creation date to compare sql backups. Since I use the comparison while doing development exact comparison of files are not necessary, and creating a MD5 just takes extra time.
The solution that I have use for my keeping my local sql development server up to date is using a script. I run this script once in a while to get a fresh database, or whenever I need a "clean" database backup.
The script will check for a new backup file. If a new file exist it will copy the new file to the local machine. After copy, the script will set the creation date of the copied file will to the date of the source backup file. After the check and copy step the script will run a RESTORE command. The restore is run even if no new file is copied. After the restore the script calls RoundhousE (https://github.com/chucknorris/roundhouse) to execute any change scripts that I have in my GIT folder that have not been applied to the database. (RoundhousE has added tables that keep track of scripts that have been run, to the database).
That way I keep my sql development server up to date.
Related
I wanted to know the script for full database backup to multiple files depending on the size of the backup file. meaning split the backup file to multiple small backup files. please assist.
I have a database in SQL Server 2008 (not R2)
A third party has the job of replacing the database regularly by restoring the data in the live environment from a .bak file made in the development environment. This leads to the destruction of any user generated data in that database. I am restricted in the live environment and cannot have two databases there.
One solution I am thinking about is to write a stored procedure that could save somehow the user generated data to some kind of local file and then once the development .bak is restored a second stored procedure could write this data back from the local file.
I'm familiar with using generate scripts that will generate a .sql file so maybe something similar to this, but it needs to be generated from a sql query that contains only the user generated data (these are specific rows of certain tables that are joined together - not the best design but it's what I have to work with).
Is it possible to generate a SQL script from a SQL query? Or is there some other kind of local file storage I could use. Something like a CSV file would be ok but I'm not aware of an easy way to automate restoring this. It will need to be restored with some very specific sql queries.
I have a database in SQL server management studio named wardobsliveisle. I want to create another database in SQL server management studio that is the exact same copy of wardobsliveisle but I want to call it demosql. How do I do this?
You have database wardobsliveisle in SSMS and now you want to create an other database demosql from wardobsliveisle. The process given below creates a copy of wardobsliveisle with new name demosql. This new database has now separate .ldf and .mdf files and it is absolutely a separate copy of your original database.
Follow the steps
Right click on Databases in your Object Explorer in SSMS.
Select Restore Files and Filegroups..., a wizard opens
Type a new database name demosql in To Database box and select source
database (Not a backup file) from From Database dropdown.
Click OK button
It will take a few minutes or less.
Taken from MSDN:
General Steps for Using Backup and Restore to Copy a Database
When you use backup and restore to copy a database to another instance of SQL Server, the source and destination computers can be any platform on which SQL Server runs.
The general steps are:
Back up the source database, which can reside on an instance of SQL Server 2005 or later. The computer on which this instance of SQL Server is running is the source computer.
On the computer to which you want to copy the database (the destination computer), connect to the instance of SQL Server on which you plan to restore the database. If needed, on the destination server instance, create the same backup devices as used to the backup of the source databases.
Restore the backup of the source database on the destination computer. Restoring the database automatically creates all of the database files.
The following topics address additional considerations that may affect this process.
Before You Restore Database Files
Restoring a database automatically creates the database files that are needed by the restoring database. By default, the files that are created by SQL Server during the restoration process use the same names and paths as the backup files from the original database on the source computer.
Optionally, when restoring the database, you can specify the device mapping, file names, or path for the restoring database. This might be necessary in the following situations:
The directory structure or drive mapping used by the database on the original computer not exist on the other computer. For example, perhaps the backup contains a file that would be restored to drive E by default, but the destination computer lacks a drive E.
The target location might have insufficient space.
You are reusing a database name that exists on the restore destination and any of its files is named the same as a database file in the backup set, one of the following occurs:
If the existing database file can be overwritten, it will be overwritten (this would not affect a file that belongs to a different database name).
If the existing file cannot be overwritten, a restore error would occur.
To avoid errors and unintended consequences, before the restore operation, you can use the backupfile history table to find out the database and log files in the backup you plan to restore.
Moving the Database Files
If the files within the database backup cannot be restored onto the destination computer because of the reasons mentioned earlier, it is necessary to move the files to a new location while they are being restored. For example:
You want to restore a database from backups created in the default location of the earlier version.
It may be necessary to restore some of the database files in the backup to a different drive because of capacity considerations. This is likely to be a common occurrence because most computers within an organization do not have the same number and size of disk drives or identical software configurations.
It may be necessary to create a copy of an existing database on the same computer for testing purposes. In this case, the database files for the original database already exist, so different file names need to be specified when the database copy is created during the restore operation.
For more information, see "To restore files and filegroups to a new location," later in this topic.
Changing the Database Name
The name of the database can be changed as it is restored to the destination computer, without having to restore the database first and then change the name manually. For example, it may be necessary to change the database name from Sales to SalesCopy to indicate that this is a copy of a database.
The database name that is explicitly supplied when you restore a database is used automatically as the new database name. Because the database name does not already exist, a new one is created by using the files in the backup.
I want to backup some specific data of SQL database by using vb.net code. In fact i want to save this file as .BAK file and then i want to restore it.
I couldn't find anything. all the solutions in the web was about full backup of database and there was not any method to backup some tables via code.
SQL Server does not permit backing up a single table. Full stop. No provision is made for this whatsoever.
It does permit restoring a single table from a complete backup, but this does not seem to be what you want.
I have a database in SQL Server 2008, which I want to copy to another computer.
How do I make such a copy?
Once this is done, what should I do at the other computer to build the database once again from my copy?
Using SQL Server Management Studio, here are the steps:
1.Right-click the database and select Tasks | Backup
2.Make sure that the Backup type is Full
3.Click Add and specify the location and backup name
4.Copy the created backup file to another computer
5.In SQL Server Management Studio on another computer, right-click the SQL Server instance and select Restore Database
6.Select Device and click the elipsis button to navigate to the copied backup file
Simple Answer: Back it up, then restore it on the other computer.
Have a look here: http://technet.microsoft.com/en-us/library/cc966495.aspx
There's a lot of stuff there, but essentially, right click on the database, Tasks > Backup. Fill in the options to perform a full backup to somewhere.
Once it has created the backup (one big file, by convention with a BAK extension), on the second computer, right click the Databases folder, Restore Database and follow the prompts.
You can do it as well in SQL if you wish:
Backup: http://msdn.microsoft.com/en-us/library/ms186865.aspx
Restore: http://msdn.microsoft.com/en-us/library/ms186858.aspx
There might be times when it's better to detach and move, but this approach always feels a bit safer!
This will copy both structure and the data in the database.
Use TSQL backup and restore. This should help http://www.sqlmag.com/article/tsql3/use-t-sql-to-back-up-and-restore-sql-server-user-databases
One of the easiest ways to do this is back up and restore.
http://msdn.microsoft.com/en-us/library/ms187048.aspx
Another option you have is detaching your database from SQL Server, copying the MDF and LDF files to the target machine, and re-attaching there. Note, if you want to keep a copy of the database on the original server, you will also need to attach there too.
http://msdn.microsoft.com/en-us/library/ms190794.aspx
You can dump the content of your database and restore it on another machine. The same mechanism can be used also for backup purposes. Check the backup&restore functionality of MS SQL.