I want to extract a subset of a database and copy to another server/database. Is it possible to copy/backup a single filegroup from one database and attach/restore to another?
You cannot restore a filegroup into a different database. Any restore operation must go through the recovery phase when the log is replayed against the restored data files and a new database would have a log that does not match the restored filgroup, so the engine will reject the backup.
You cannot detach/attach filegroups either, detach and attach are not working at filegroup level, only at database level.
Nor can you cannot do a file copy/overwrite, when the database comes online the recovery process will detect the mismatch and declare the database corrupt.
Use the faithful "SELECT * FROM old_db.old_tbl INTO new_db.new_tbl" for each table.
Related
I have a SQL server database with 5 filegroups i want to backup 2 filegroups(one contains filestream)only and restore them to different existing database.
What you are asking about is Piecemeal Restores (SQL Server)
You can restore primary + all readwrite fg + any of readonly filegroups in you are in simple recovery model or you can restore primary + any other filegroup(s) if you are in full recovery model.
As the first filegroup to restore is always primary filegroup, it will replace your "different existing database" primary data file and log (in your restore command you should use with move that points to your existing mdf + log files) and every subsequent restore will overwrite other files, there will remain nothing from your "existing" database, so there is no sense to restore to a "different existing database": you will be able to bring online only the filegroups you are restored and the database will know nothing about remaining files of "existing database". So it's just the same as to restore to just another(non existing) database.
Here is the restore sequence example for primary + readonly fg in simple recovery model Example: Piecemeal Restore of Only Some Filegroups (Simple Recovery Model)
And here is the example for full recovery model Example: Piecemeal Restore of Only Some Filegroups (Full Recovery Model)
We have a large database in MS SQL in which one of the tables is partitioned by a date column. The Primary key index is also partitioned using the same partition function. The database is kept in Simple Recovery model, since data is added to it in batches every 3 months.
DBCC checkfilegroup found consistency errors, so we needed to bring back just one filegroup from a complete backup.
Restore did not allow me to run a restore of a filegroup in Simple Mode, so I changed to full recovery mode, then ran the following, with no errors.
restore database aricases filegroup='2003'
from disk=N'backupfile-name.bak'
with recovery
I expected the "with recovery" clause to bring this back to working order, but the process ended with a note saying
The roll forward start point is now at log sequence number (LSN) 511972000001350200037. Additional roll forward past LSN 549061000001370900001 is required to complete the restore sequence.
When I query the database table that includes this filegroup I get a message saying that the primary key cannot be accessed because one of the partitions for the table cannot be access because it is offline, restoring, or defunct.
Why didn't "with recovery" clause leave this filegroup fully restored. Now what?
The entire database is very large (1.5TB). I can't backup the log file, because I'd first need to create a backup in full model mode. The filegroup itself is only 300gb.
I can do the restore again-- but would like to know the correct way of performing this.
Is there a way of staying in complete recovery mode and performing a piecemeal filegroup backup from a complete database backup?
I found the answer. Bottom line is that Simple Recovery Model is very limited. You must restore ALL read/write filegroups together from the same backup. Individual read/only filegroups CAN be restored separately, as long as they became read/only (no more changes) BEFORE the last backup of the read/write filegroups.
Bottom line-- only Full or Bulk-Logged models let you restore single read/write filegroups.
Bulk-Logged model is what a datawarehouse with batch loading should be using, not Simple Model. My error in design.
see from Microsoft
http://msdn.microsoft.com/en-us/library/ms191253.aspx
then look at piecemeal restores for Simple Model
http://msdn.microsoft.com/en-us/library/ms190984%28v=sql.100%29.aspx
very limited
I'm managing a reasonably large SQL Server database. Some tables contain data that are business-critical and must be backed up offsite daily. But we also have other (read-write) tables that take up about half the size of the database that aren't business-critical. What I would like to do is something like this:
Primary filegroup: Tables A, B, C --> daily backup
Secondary filegroup: Tables D, E, F --> monthly (or occasional manual) backup
When I tried to test this, I got errors while trying to restore the filegroups. It looks like I can't restore a single filegroup alone or different file groups from different points in time. Ideally, I'd like to be able to just restore the primary filegroup (the most important one) first, and then restore the secondary one. I'm willing to accept some data loss on the secondary filegroup.
Can this be done?
In order to succeed with a partial or piecemeal restore strategy, you first need to adopt a Filegroup backup strategy. You can still backup your whole database at one time if you wish, but the backup needs to be at the filegroup level.
Details of how to perform filegroup backups can be found at the following link: http://msdn.microsoft.com/en-us/library/ms179401(v=sql.105).aspx
Details of how to perform a piecemeal restore can be found here http://msdn.microsoft.com/en-us/library/ms177425(v=sql.100).aspx
I accidentally deleted a row in a table and want to restore it. I've found a solution here: How to recover deleted records in MS SQL server
I've tried to restore database from backup taken after delete. But I can't restore database with STOPAT option:
RESTORE LOG database FROM DISK = N'X:\database.BAK' WITH
STOPAT = N'2011-02-12T00:00:00', RECOVERY
I have following error:
Msg 3117, Level 16, State 4, Line 1
The log or differential backup cannot be restored because no files are
ready to rollforward.
Msg 3013, Level 16, State 1, Line 1
RESTORE LOG is terminating abnormally.
I've tried to restore database from
backup taken after delete.
You cannot recover deleted records from a backup taken after the delete. You need:
the latest full backup taken before the delete
all the log backups taken between the last full backup until the first log backup taken one after the delete
the database must be in full recovery mode
You may have an differential backup thrown in to reduce the log backup chain length, but this is optional.
Only if all the conditions above are satisfied, then you can go ahead and follow the procedure. If you are missing any of the above, then that record is lost. As a rule of thumb, don't follow blog articles or forum answers, including this one, follow instead the product documentation: How to: Restore to a Point in Time (Transact-SQL)
If your database was in full recovery mode then you can try to read transaction log and recover data from there using commercial tool such as ApexSQL Log or sql server commands such as DBCC LOG or fn_log.
Also you can try looking at these posts for more details:
How to undo a delete operation in SQL Server 2005?
How to view transaction logs in SQL Server 2008
Taken from this link -
A differential backup, though only containing changed data pages since the last full database backup, can only be restored in conjuntion with a full backup similar to using log backups. You don't have the ability to restore only single tables or objects, but you can restore at the database, filegroup, file, and page level. You can also restore up to a particular point in time from any of the backups (assuming you've restored the required preceding full, diff, logs).
Possibly the best solution for you in this case would be to restore the database using a different database name, then moving only the data you want into your existing database? Not sure if that's exactly what you're trying to achieve though.
Yes, it's possible to recover deleted records from SQL Server database using various methods, which, on the other hand, requires different prerequisites. Some of them involve native SQL Server features, others 3rd party tools.
Anyway, in some cases the deleted data is not lost even your database is not using the Full recovery model. For more information, check the Recover deleted SQL data from a backup or from online database files online article.
Disclaimer: I work as a Product Support Engineer at ApexSQL
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