I'm using MSI Project with InstallShield 2010.
I have a .bak file, a backup of a SQL database (I am using SQL Server 2008 R2). How can I restore it using InstallShield?
I was looking in SQL Scripts tab and I didn't find anything about restoring backups.
Thanks for your time!
Technically you could use a SQL script to restore the .BAK file but this isn't really the best practice. What you are supposed to do is "script out" the database into one or many SQL files and execute those files to create your database during the install.
say suppose you have xyz.bak as a bakup and you want to restore it on to your sqlserver 2008r2 try running following query in ssms
Restore database DatabaseName from disk='path of your bak file'
this will restore your database.
In hopes of getting an answer to this thread's original question, let's say that building up the database via the "script out" approach would take way too long to perform at install-time.
Scripted out, the database I am working with takes ~90 min to get built up. Restoring a 1.6 GB compressed .bak takes ~90 sec.
I am interested in restoring a .bak as part of my IS2010 msi project. Currently CAs are used but a more elegant solution (especially one that can provide progress back to the user) would be more ideal.
Related
Surprisingly, I did not find a concise way on Stackoverflow or elsewhere, so please allow me to ask.
I want transport a complete SQL Server database from one environment to another using the Microsoft SQL Server Management Studio (SSMS).
I guess I need a complete database dump (of model and data) e.g. from the production environment, which I then restore e.g. on the pre-production environment.
I am more the MongoDB guy, and it is straight forward there. But how do I quickly backup, transfer and restore a complete T-SQL database (context) using SSMS? The issue is that I should explain somebody else what to do since I do not have the rights to try it myself.
The official documentation on backup and restore is rather lengthy, but I get the concept, I hope. Except for the copy only backup, maybe. The definition reads:
Copy-only full backups (all recovery models)
A copy-only backup cannot serve as a differential base or differential backup and does not affect the differential base. Restoring a copy-only full backup is the same as restoring any other full backup.
Do I need a copy-only backup for my purpose? If so, why?
Recipe Draft
Within SSMS on the source server, open the Object Explorer (F8), right click on the DB you want to transport (e.g.myDB) and choose Tasks > Backup...
In the pop-up window, choose Backup Type: Full. Under Destination, choose Back up to: Disk and add a folder.
Navigate to the folder where the .bak file is stored, e.g. C:\Program Files\Microsoft SQL Server\MSSQL 14.MSSQLSERVER\MSSQL\Backups\, transfer it to the destination server onto a similar location.
On the destination server, open the Object Explorer (F8). Make sure you have no database context called myDB, then right click on another context, choose Task > Restore > Database... and then what?
I would also need help with the last step, please. The popup window shows on top No backup set selected to be restored. and keeps freezing if I want to choose the myDB.bak file.
References
SQL Server Management Studio: Backup and restore database without data
Import / Export database with SQL Server Server Management Studio - loads of hits, but rather old and not quite fool-proof recipes
Copy database from SQL server management to another instance Directely
Microsoft SQL DB to MySQL DB
restore sql backup with microsoft management studio
You should use COPY_ONLY if you don't want to mess with the potentially existing backup set. For example, if you have some backup solution that takes differential backups (log backups) in between full backups. You need to use COPY_ONLY if you're manually going to take a FULL backup, otherwise you will make the differential backups useless until the next FULL backup is performed by your backup solution (or you have to use that FULL backup of yours together with the diff backups in case of a point-in-time restore, but you risk having issues using that with your normal backup solution).
I want to migrate a database completely or partially. Right now, I will do a complete database. Partial will be posted as a separate question.
Strategies I am considering:
copy database wizard
convert 2005 database to script. Run script on 2008
simple SQL query
My question - I want to use method 2. Is it even possible to do this? If yes, how to do it? Any limitations/risks ?
NOTE - The source server is a SQL Server 2005 database with one IP. Destination is a SQL Server 2008 instance with another IP.
I don't know if you need to be sysadmin to do this. I am not even sure if I am sysadmin. If yes, then how to check if I am a sysadmin ?
Just RESTORE it on the SQL2008 server and it will be automatically upgraded. And you can check if you're a sysadmin using IS_SRVROLEMEMBER.
My question - I want to use method (2). Is it even possible to do this ? (...) any limitations/risks ?
Option 2 could be a problem if database is too large. Worked for me with up to 2 GB databases.
any limitations/risks ?
You may need to increase SQL's buffer and/or run the script through command line, since a large script in SQL Manager eats up plenty of memory.
If yes, how to do it ?
To generate the script, simply right click and choose generate script. Select both data and model for whole database, and choose appropriate options for others.
As Pondlife said, Just backup the database at SQL 2005, restore as a new database at SQL 2008. You change the compatible mode to SQL 2005 which is version 9, or you can leave it to 2008 which is version 10 or 10.5. I think you want to keep the database as is, so you could set the compatible more to 9.0.xxxx and you all be done.
As usual grant access to users, create them as new if you have to, or migrate them from SQL 2005.
Generating script from 2005 and running on 2008 is a long route. There may be some possibilities for errors and TSQL compatibility.
Hope it helps !!
Most simple way to do this is to restore backup or copy MDF and LDF files to new server. If your servers are in the same network you can do this by creating shared folders on the second server and copying files there.
If that is not an option for any reason then you can zip the backup (make sure to add strong password) upload it to some online storage and then download it from second server.
Final option is to use third party comparison and synchronization tools from RedGage or ApexSQL (there are a lot of these on the market and they all have fully functional trials)
One of the tasks in a project that I'm working on is to migrate an existing database on SQL Server 2000, to a new server which runs SQL Server 2008. This database is extremely huge, with 23 million rows and a 78GB mdf file.
What is the best way to migrate a database of this size?
My current approach would be to:
allow for application downtime so that the application doesn't write records to the database
perform a full backup on SQL Server 2000.
move backup file over to new server across the network.
restore full backup on SQL Server 2008.
configure the application to refer to the database on the new server
restart application.
decommission the database on SQL Server 2000.
However, I'm not sure how much application downtime that would involve.
Are there any easier approaches, or an approach that involves very little downtime? Can a backup be taken while the application is running? Obviously I would need to stop the application when the backup file is transferred and the restore is completed. Interested to hear your approaches to a task like this.
If you're open to downtime:
Detach the database
Copy data file(s) and log file(s) to the new server
Attach the database on the new server instance
Detaching closes the database and finalizes the files so they safely can be moved (or backed up via filesystem backup). It will no longer be accessible on the server instance until you reattach it.
Don't cut and paste / move the data and log files, just in case something bombs during the copy.
There are several other things to keep in mind when migrating to a new server instance, like making sure logins exist on the new instance, features in use that might be deprecated, etc.
Here's the reference for detach/attach.
I have two SQL Servers and I want to do a backup on one of them and then restore that on the other server. The catch is that the database already exists on the server I'm restoring to, and I want to keep the security settings the way they are on the server I'm restoring to.
The other catch is that I want to do all of this from PowerShell, so no GUI operations.
Or is this maybe the wrong solution to the problem. Is there maybe another way to move the data without doing a backup/restore and keeping the security settings?
In my environment we use Powershell scripts with Red Gate Compare Professional to restore databases and persist security plus database object differences. The process is fairly simple
Create a Red Gate snapshot of the destination database. Using the Red Gate command-line tool. The file it generates is very small and only contain users, permissions, and objects--basically everything except for the data.
Restore the source database over the destination database using T-SQL
Use the command-line Red Gate tools to compare and synchronize snapshot created in step to the nearly restored database. Any security or object changes are restored.
This solution does require purchasing the Professional edition of SQL Compare and installing the tool on the development server from which the script can be executed. All of this can easily be put into SQL Agent job. The use of Powershell is really kind of basic since we're just executing sqlcompare.exe
There is an article here explaining how to script SQL Server permissions through SMO via PowerShell. Your scenario would then be to script permissions from your initial DB before restoring the backup, then execute the generated script after backup has been restored.
Let us start with...yes I am new to SQL and really only a lightweight programmer. So I am assuming that I am doing something horribly wrong. I have spent days on the MS forums looking for an answer to no avail. So I am going to give as much info as possible.
Application language is VBExpress 2010 and using SQLExpress 2008. The Database contain basic tables, no stored procs, no views, no diagrams. The Application has configured diagrams where one of the tables has inner joins... Tables origninally built in SSMS, but have been altered in VBE.
Anytime I run the application, even after exiting the application, if I then go to SSMS I can see the database name but I cannot open it up (no + beside it). If I try I get an error that says:
One or more files do not match the primary file of the database. If you are attempting to attach a database retry the operation with the correct files. If this is an existing database the file may be corrupted and should be restored from a backup."
When I look at the files, I see two log files, one with _1 appended on to it. If I delete the logfiles before opening SSMS, everything opens fine. If I had already opened SSMS then I have to delete the files, reboot my computer and then I can access the database through SSMS...
I recently found that if I go into SSMS, take the database offline and then bring it back online I can get access back.
Anytime I open SSMS, I have to completely reboot my computer before VBE will reconnect the database.
The bottom line is that I cannot back up the database without either deleting the log files or doing an offline/online cycle in SSMS....
This is driving me nuts. I cannot possilby deploy the application if I cannot achieve a normal backup procedure. And I cannot seem to get any kind of answer about why this is happening.
What am I doing so WRONG?
If you are using SQL Server 2008 then, reattach the database files and it will must be stored in C:\Program Files\Microsoft SQL Server\MSSQL 10.MSSQLSERVER\MSSQL\DATA.
And recheck the database on that folder and it will take backup and restore point of Primary files of Database. Don't modify/delete the database files. If the location of log files are changed the it will shows the error. Please give your mail id I'll send a program to restore and backup of database files in winrar.
Thank you
Regards,
Naresh.