Hot answers tagged

4

You have to start over and restore full and diffs with no recovery and then the tlogs with stand by option. This will allow you to restore tlogs later as well. You can configure logshipping with option of stand by, so you can read from the secondary database. There will be a .tuf (transaction undo file) file created when you restore tlogs with standby ...


3

You should use WITH STATS = 10 so that SSMS can show your the progress. Also, if you restored an older version of backup to a newer version of sql server, sql server will undergo an upgrade process .. something along the lines database 'your db name' running the upgrade step from version 661 to version 668 ..


3

When I see messages of that nature, I usually blame the redo logs. This is where is LSN is written. The problem may stem from not preparing the incremental backup. What seems to be missing is the use of the --prepare option. What this essentially does is create the backup rolled forward to a specific point in time. This is particularly true if there were ...


2

From the symptoms, it seems that you are using InnoDB engine for your tables. If so, it is normal not to have accurate number of rows shown by clients (Like HeidiSQL or PHPMyAdmin). It is also worth it to mention that SHOW TABLE STATUS LIKE 'table_name' does not provide accurate row count for InnoDB tables. InnoDB estimates the number of rows in the ...


1

There is an API called db2ReadLog() that you can use to read transaction logs and collect information about deleted records. IBM also sells a product called Recovery Expert that will help you do this and generate undo SQL statements.


1

Database or tablespace recovery is the only* way to go back in time and find deleted records if you haven't planned for this. To minimize the impact on the production environment you can always perform a restore on a different machine, export the records and import them in production. That does not require any downtime. HADR with delayed replay, possibly in ...


1

EDIT: I've finally managed to get the database restored. It took only 124 minutes, when we changed some settings on the server. I found the settings here: https://support.microsoft.com/da-dk/kb/2160002 and here https://technet.microsoft.com/en-us/library/cc778996.aspx


1

You are trying to restore a 45GB database with 32GB memory on the server. What you can do is bump up the memory (RAM) on the server and play with Stripe your backup to multiple LUNs or disk. Use BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE backup parameters along with INIT & COMPRESSION (you are using it as I see from your output) to tune your backup. ...



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