Tag Info

New answers tagged

3

Yes, you can issue ROLLFORWARD after restoring an offline backup. The ROLLFORWARD command syntax remains the same, regardless of the type of restored backup image.


0

What Bob said. Couple of ways to get round this. Firstly, you could copy the files from the FTP server to your test server and then use xp_cmdshell and the DIR command to read in the contents of that folder (full, diff and log backups) and order them accordingly (you need the date/time in the filename to achieve this). Once you have this information, you ...


3

BCP is the tool you're looking for. Here's some links that should put you in the right direction: https://msdn.microsoft.com/en-us/library/ms162802.aspx https://www.simple-talk.com/sql/database-administration/working-with-the-bcp-command-line-utility/


4

why would the FirstLSN of the second differential backup (22000000041800004) be higher than the FirstLSN of the first differential backup (22000000039800037)? When dealing with Data (Full, file, etc) or differential version of said backups the FirstLSN and LastLSN actually mean something different than is being inferred. FirstLSN when dealing with ...


0

Given your situation and the information presented here, consider the following... If disk space allows for it, configure your custom log shipping to have 2 databases on the Secondary server that are both constantly restoring logs from the Primary. The purpose of database A would be for Disaster Recovery purposes and should be left alone so you never ...


0

(since this is longer than a comment .. so posting this as an answer) In sql server enterprise edition, you can leverage database snapshots. If I understand your question, you want to do some changes on a standy (not live) copy of your database and then discard those ? If that is true, then you can create a database snapshot of your main database using : ...


0

I'm a bit lost in your explanation, but there may not be much of a problem. You have a dump from December? But it is in the 'wrong' directory? The dump was taken using mysqldump? Reloading is nothing more than mysql -uroot -p


0

If you are running Developer or Enterprise edition, consider restoring from a database snapshot rather than a full backup (https://msdn.microsoft.com/en-s/library/ms189281.aspx). This can also be less resource-intensive than a full restore. The time needed to revert from a snapshot is largely proportional to the amount of changes made since the snapshot ...


-1

Instant file initialization doesn't apply to transaction log files. So, you may also help yourself by precreating and/or adjusting the destination database to at least the sizes from the database you are restoring from. Thus, SQL Server won't have to zero out any files during the restore.



Top 50 recent answers are included