CONVERT as a seperate utility?
Adam.Bean
Posts: 28
Does Red-Gate or any user have a utility that will CONVERT a Red-Gate SQL Backup to Native backup without having an install of SQL Backup?
This would be extremely handy in our environment to allow developers to convert our production backups into native for restores onto their own local machines without having SQL Backup installed.
Thanks
This would be extremely handy in our environment to allow developers to convert our production backups into native for restores onto their own local machines without having SQL Backup installed.
Thanks
Comments
(There's also a GUI for this utility which can be downloaded from the Red Gate Labs).
Alternatively you can use the CONVERT command with the SQL Backup -SQL parameter to convert SQL Backup files (.sqb) to native SQL Server format.
For example:
master..sqlbackup '-SQL "CONVERT 'C:\Backups\pubs.sqb' TO 'C:\Backups\pubs.bak' " '
SQL Backup Project Manager
Red Gate Software
When using that tool, why does it split the backup file in 14 smaller files when converting?
Therefore, in your case, you would have used THREADCOUNT = 14 during the backup; which results in 14 "threads" of data (and hence 14 native files).
Hope that helps,
Jason
While SQL Backup provides the ability to perform multi-threaded backups, SQL Server does not have the ability to handle multi-threaded restores. When you come to convert the backup to a native backup, the only way this can be done is to split the multiple threads out, so that one thread exists in one file. Unfortunately that is the only option.
Hope that helps,
Jason
So what is the performance increase by using multiple threads on backups? I'm wondering If I should just leave it single threaded then ...
As with any performance metrics, it will vary with every different system out there. However, given our own tests with multiprocessor systems, we have seen improvements of 50% or higher over a single thread - which will be quite common if the bottleneck was the CPU.
The one thing worth noting with the conversion is that the file names are entirely predictable... the files will each be appended with a _xx value, e.g. _01, _02 and so on. So if you know the number of threads beforehand, you will be able to compute the generated filenames afterwards.
Hope that helps,
Jason