We are looking at migrating one of our databases from SQL Server 2008 Express to SQL Server 2012. The guy that has been taking care of the database says he always does a detach, copy the files to the new server and attach. This takes the database offline of course.
Is there a benefit in doing that vs. right click backup, copy backup files and right click restore on the new server?
Taking a backup should pull everything without taking the DB offline correct?
Is there a recommended best practice for this?
(New to the MS database world)
You could Backup and Restore
You will still have to "un-orphan" sql-users to db-users.
BACKUP DATABASE MyDB TO DISK = 'c:\backups\MyDB.bak' WITH FORMAT
RESTORE DATABASE MyDB FROM DISK = 'c:\backups\MyDB.bak' WITH REPLACE,
MOVE 'MyDB' TO 'd:\sqlfiles\mydb.mdf',
MOVE 'MyDB_Log' TO 'd:\sqlfiles\mydb_log.ldf'
Change the paths however you want.
I'm not sure about best practice, but I have done this more times than I can remember and never had an issue by backing up the DB, taking the old DB offline, and restoring the backup to the new server.
I guess on really high traffic systems you may want to take the DB offline first to ensure nothing changes during your backing up (new records added etc. which would be lost). If you take the DB offline first then you can't back up the DB, so I guess that's when attaching the individual files to the new server becomes necessary as opposed to just restoring the backup.
Related
I am backing up a SQL Server 2008 R2 database with the intention of restoring it elsewhere. When I back it up using the backup wizard (right click tasks, backup ) the size of the resulting backup is much larger than I know the database should be (c45Gb when there is only about 5Gb of data)
How can I get a reasonably sized backup created to transfer and restore elsewhere?
Thanks,
Dan
Full backups contain all pages in use plus the part of the log that covers the time span that the backup ran for (approximately). It would surprise me if you generated 40GB of log during a backup of 5GB. At this point I'd check if you really backed up the right database. Or, maybe the destination file already contained other backups.
You say:
I created a smaller backup by going to the options tab on the backup
and set the compression to 'compress backup', I also chose Overwrite
all existing backup sets and Backed up to a new media set name.
Apparently, the existing file already contained data. It is unlikely that compression is responsible for the bulk of the savings.
I created a smaller backup by going to the options tab on the backup and set the compression to 'compress backup', I also chose Overwrite all existing backup sets and Backed up to a new media set name.
The transaction log file for the ReportServerTempDB database (database installed with Reporting Services) is has grown to over 100GB. And I'm not sure why.
Here are the file sizes:
D:\SQLDatabases\ReportServer.mdf - 0.7GB
G:\SQLDatabases\ReportServer.ldf - 1.8GB
E:\SQLDatabases\ReportServerTempDB.mdf - 5GB
G:\SQLDatabases\ReportServerTempDB.ldf - 107.6GB
Recovery mode for all these database is SIMPLE.
We are using SQL Server 2008 R2 Standard Edition.
EDIT: Something that is unique to the reporting services databases:
The collation for these databases is Latin1_General_CI_AS_KS_WS. But for all other database it is Latin1_General_CI_AS.
I don't want to just shink the log files and carry on, because they might just grow again. And I can't see why they should be so large.
Does anyone know what could cause the log file (and the data file) for the ReportServerTempDB database to grow so much
And what I should do about it?
Could this indicate a problem with our Report Server?
You are sure that your temp DB is on recovery model - simple as well?
At least you can shrink the database so you get your disk space back using SHRINK DBCC, check this link for more details: http://msdn.microsoft.com/en-us//library/ms190488.aspx
We had renamed SSRS, but the cleanup / archive procs were still trying to cleanup the old database names. When we changed that, out problem stopped.
I have sql backups copied from server A to server B on a nightly basis.
We want to move the sql server from server A to server B without much downtime, but the files are very large.
I assumed that performing a differential backup and restore would solve the problem with the databases.
Copy full backup from server A to copy to server B (10+gb)
Open SQL Server Managment Studio on server B
Right mouse on databases
Restore Database
Type in the new DB-name
Choose "From Device" and browse to the backup file
Click Okay. This is now resorting the original "full" backup.
Test new db with dev application - everything works :)
On original database rightmouse on DB > Tasks > Backup...
Backup Type = Differential, Backup to disk, add a new file, and remove the old one (it needs to be a small file to transfer for the smallest amount of outage)
Copy the diff backup onto the new db
Right mouse on DB > Tasks > Restore > Database
This is where I get stuck. If I add both the new differential file, and the original backup to the restore process I get an error
The media loaded on "M:\path\to\backup\full.bak" is formatted to support 1 media families, but 2 media families are expected according to the backup device specification.
RESTORE HEADERONLY is terminating abnormally.
But if I try to restore using just the differential file I get
System.Data.SqlClient.SqlError: The log or differential backup cannot be restored because no files are ready to rollforward. (Microsoft.SqlServer.Smo)
Any idea how to do it? Is there a better way of restoring backups with limited downtime?
See 2008 Books Online Performing a Complete Database Restore for details and code.
Perhaps the error is caused by both full and differential backups trying to be restored at once by the backup device specification (may need to be changed).
Do them one at a time (basic idea):
Create tail_log backup.
Restore full first, with NORECOVERY.
Restore differential, with NORECOVERY.
Restore log, with NORECOVERY.
Restore tail_log, with NORECOVERY.
Then, when all done, Restore with RECOVERY.
I have one database which contains the most recent data, and I want to replicate the database content into some other servers. Due to non-technical reasons, I can not directly use replicate function or sync function to sync to other SQL Server instances.
Now, I have two solutions, and I want to learn the pros and cons for each solution. Thanks!
Solution 1: detach the source database which contains the most recent data, then copy to the destination servers which need the most recent data, and attach database at the destination servers;
Solution 2: make a full backup of source server for the whole database, then copy data to destination servers and take a full recovery at the destination server side.
thanks in advance,
George
The Detach / Attach option is often quicker than performing a backup as it doesn't have to create a new file. Therefore, the time from Server A to Server B is almost purely the file copy time.
The Backup / Restore option allows you to perform a full backup, restore that, then perform a differential backup which means your down time can be reduced between the two.
If it's data replication you're after, does that mean you want the database functional in both locations? In that case, you probably want the backup / restore option as that will leave the current database fully functional.
EDIT: Just to clarify a few points. By downtime I mean that if you're migrating a database from one server to another, you generally will be stopping people using it whilst it's in transit. Therefore, from the "stop" point on Server A up to the "start" point on Server B this could be considered downtime. Otherwise, any actions performed on the database on server A during transit will not be replicated onto server B.
In regards to the "create a new file". If you detach a database you can copy the MDF file immediately. It's already there ready to be copied. However, if you perform a backup, you have to wait for the .BAK file to be created and then move it to it's new location for a restore. Again this all comes down to is this a snapshot copy or a migration.
Backing up and restoring makes much more sense, even if you might eek out a few extra minutes from a detach attach option instead. You have to take the original database offline (disconnect everyone) prior to a detach, and then the db is unavailable until you reattach. You also have to keep track of all of the files, whereas with a backup all of the files are grouped. And with the most recent versions of SQL Server the backups are compressed.
And just to correct something: DB backups and differential backups do not truncate the log, and do not break the log chain.
In addition, the COPY_ONLY functionality only matters for the differential base, not for the LOG. All log backups can be applied in sequence from any backup assuming there was no break in the log chain. There is a slight difference with the archive point, but I can't see where that matters.
Solution 2 would be my choice... Primarily becuase it won't create any downtime on the source database. The only disadvatage i can see is that depending on the database recovery model, the transaction log will be truncated meaning if you wanted to restore any data from the transaction log you'd be stuffed, you'd have to use your backup file.
EDIT: Found a nice link; http://sql-server-performance.com/Community/forums/p/5838/35573.aspx
Anyone using MozyPro to backup SQL Server databases?
I'm concerned about the way it does the backup. It just copies data files the way they are. Not using the backup database command.
Is it safe?
MozyPro uses the Volume Shadow Service (VSS) to create backups for SQL Server. SQL Server 2005 has been engineered so that VSS backups are consistent. So this is definitely a valid way to back up SQL Server databases.
Here is a white paper on how the SQL Server 2005 SQL Writer works with VSS.
Microsoft® SQL Server™ 2005 provides
support for creating snapshots from
SQL Server data using Volume Shadow
Copy Service (VSS). This is
accomplished by providing a VSS
compliant writer (the SQL writer) so
that a third-party backup application
can use the VSS framework to back up
database files. This paper describes
the SQL writer component and its role
in the VSS snapshot creation and
restore process for SQL Server
databases. It also captures details on
how to configure and use the SQL
writer to work with backup
applications in the context of the VSS
framework.
Here is the MozyPro manual (PDF), which describes how to restore SQL Server backups that were made using VSS.
That being said, if you don't trust this method, there is nothing stopping you from setting up a backup job and just having Mozy backup your *.bak files.
Judging by the hell I am currently going through with Mozy.. NO NO NO!
The backups work, in theory, just not the restore part. Mozy's extreme incremental backup system results in restores that can take weeks. Apparently. I'm still waiting despite talking their top level tech support, over 10 days have passed.
https://github.com/candera/hobocopy
WHY DOES HOBCOPY USE THE VOLUME SHADOW SERVICE?
Because HoboCopy copies from a VSS snapshot, it is able copy even
files that are in locked by some other program. Further, certain
programs (such as SQL Server 2005) are VSS-aware, and will write their
state to disk in a consistent state before the snapshot is taken,
allowing a sort of "live backup". Files locked by VSS-unaware programs
will still be copied in a "crash consistent" state (i.e. whatever
happens to be on the disk). This is generally a lot better than not
being able to copy the file at all.