Hey Everyone - support case id - 03631460
Im so sure the behaviour of SQL explorer has changed in v4a - does anyone use Veeam for point in time table restores? Or does everyone use another product?
We want to be protected if someone accidentally corrupts a table (say a update condition with no where clause) - we have a 900GB SQL database and have veeam handling the log backups
If we want to restore a table from the last full backup, I can pop it out in 5mins but if I want to do a restore in time to say 5mins ago - it will take 3 hours to just get that one table, because it copies the database files to a new location on a staging server and then applies the logs to the copy
Ive tried merging the staging server with the backup proxy (which has the sql backup files) and install the console, so it didnt have to copy over the network but it still does a file copy
Im sure when I tested the point in time restore previously, it would mount and then apply the logs to the mounted database (so no file copying), Im sure of this because we dont have another 900gb lying around on main sql server when I did the tests. But now when I run the restore its saying "not enough space"
If you can test it in your own environments and let me know, that would be great!
-
- Influencer
- Posts: 11
- Liked: 2 times
- Joined: Nov 06, 2018 12:21 am
- Contact:
-
- Influencer
- Posts: 11
- Liked: 2 times
- Joined: Nov 06, 2018 12:21 am
- Contact:
Re: Sql Explorer - Speed of table restores
Can anyone try a SQL table restore in their labs? Need to know on a point in time restore - does it copy another copy of the database to apply the logs too?
-
- Product Manager
- Posts: 20415
- Liked: 2302 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Sql Explorer - Speed of table restores
Can you tell what versions are comparing? As far as I remember, the behaviour you've mentioned was implemented not in U4a, but in 9.5 U3 or even 9.5 GA.
This change was done to improve performance (we've stopped using cache, which worked rather slow). And you seem to be the first one to complain about it.
Anyway, to speed up db restore you can try to publish the db first and the export required table from it manually - should be faster.
Thanks!
This change was done to improve performance (we've stopped using cache, which worked rather slow). And you seem to be the first one to complain about it.
Anyway, to speed up db restore you can try to publish the db first and the export required table from it manually - should be faster.
Thanks!
Who is online
Users browsing this forum: Semrush [Bot] and 60 guests