Hot answers tagged

10

No, you need to have taken transaction logs that cover the time frame you want to use with STOPAT. You can't do this from a full database backup only - that is just a one-time copy, and that is why we have different types of backups (full, log, diff). If you have taken transaction log backups in between your full backups, please update the question with ...


6

Recently I have faced with the same issue. I have googled for a while and found that this is a problem in the Microsoft products. I wrote the article according to this error message, so you can find more information there. So, to solve this issue and restore your database to point-in-time use T-SQL commands: Restore your last full backup RESTORE DATABASE ...


4

According to the error message, your database contains Enterprise Edition features in the table Country. First of all, check the following on the original (old) server: SELECT SERVERPROPERTY('Edition'); That should tell you if you're running on Standard, Enterprise or Developer Edition. Developer Edition supports all of the Enterprise features (with ...


3

Disclaimer, the following solution where for a development box. Use with caution. For a production like scenario, open a PMR. It turned out that during a previous restore the file system got full and therefore not all files necessary got created. I cataloged the database: db2 catalog db XXXX DB20000I The CATALOG DATABASE command completed successfully. ...


3

The errors have nothing to do with the fact that the database is restored (in fact they aren't even errors, just intellisense being flaky). As you can see in the dropdown top left and the status bar (in yellow) you are executing your query against the master database. Either change your database in the dropdown or execute a USE mydatabasename;. As noted ...


3

Seeing as we take regular full db backups at midnight, would it be safe for me to temporarily put the database into Simple Recovery Mode (after one of these backups has run), shrink the log file to reclaim (virtually all of) the space and then put it back in to Full Recovery with the backup strategy mentioned above? Yes, it would be safe ...


3

Just an F.Y.I that the transaction log for that database contains all transactions since the last transaction log backup, or the last time it was switched from simple recovery mode. Execute the following to get the definitive reason as to why SQL Server can not truncate the log and subsequently why the log is growing. SELECT d.Name ...


2

So you've got two zones. Let's say zone one floods or burns... it's completely gone. All the hardware is destroyed, and the old site isn't even usable. It could be weeks putting it back together. Thankfully, you're still online thanks to zone two. Of course, you might try something like short-term leasing servers to get redundancy back while you put ...


2

You are setting the restore to not recover your database. $res.NoRecovery = $TRUE Remove this line or set this value to $FALSE and the database will restore as you expect. This setting is useful when restoring log backups. This includes when you restore the tail of the log. Books Online has more info here As for the duration of a RESTORE it depends on ...


2

OPTIMIZE is probably better because what it does is CREATE TABLE ... Copy all the existing rows over RENAME ... (Some time during or after step 2, the indexes are rebuilt.) Dump and reload: Read the entire table, write to disk DROP TABLE or TRUNCATE TABLE and CREATE TABLE ... Read the dump, inserting into the table This is slower because of the ...


2

This restriction of 'instant file initialization' (aka. SetFileValidData) is documented: Note The file cannot be a network file, or be compressed, sparse, or transacted.


2

Which SP of SQL Server 2012 did you use? This is a known issue with SQL Server 2012 SP2. The information for "Restore to:" is empty, which was supposed to show the timelines. To work around this issue: Use SQL 2014 SSMS Use T-SQL


1

Its a blunder to restore a BIG database on SQL Server with no instant file initialization enabled. The amount of time taken to restore with no IFI is MUCH larger than amount of time taken to restore with IFI enabled. When IFI is enabled what it does is this permission keeps SQL Server from "zeroing out" new space when you create or expand a data file. This ...


1

I supposed you haven't taken any LOG backup since your last FULL backup and this FULL backup was the last backup of any type taken. You need to take a Tail LOG Backup first: BACKUP LOG [MyDB] TO DISK = N'I:\MSSQL\DATA\MyDB_LogBackup_2016-01-27_17-40-41.bak' WITH NAME = N'MyDB_LogBackup_2016-01-27_17-40-41' , NOFORMAT, NOINIT, NOSKIP, ...



Only top voted, non community-wiki answers of a minimum length are eligible