To cut down a potentially laborious task of converting backup tasks in several maintenance plans to use SQL Backup we now have got a utility for doing it for you. It's not part of the install of SQL Backup, but it may be included in a future release. For now you can download it separately from http://labs.red-gate.com/index.php/Maintenance_Plan_Conversion_Wizard.

The conversion process involves identifying which plans you want to convert, then configuring the backup task to utilize SQL Backup functionality. This means you can set up compression and encryption while maintaining the common features of the native backup task.

This tool will convert maintenance plans on SQL Server 2000 and SQL Server 2005.

There's a working application available for download FREE which allows you to execute a script (or set of scripts) against multiple servers. That’s pretty much it!

It's called SQL Multi Script and you can download the alpha version here

it doesn’t require an install and you can get started in about 1 minute.

• Open a script or scripts or write your own on the fly
• Add the SQL Servers
• Execute on all the Servers in one go!

There are amazon vouchers available for good feedback.

Take a look and post a comment on the forum. It won't take you a moment and it could save you hours!

A little known application exists for converting your backup files created by SQL Backup (*.sqb) into MTF (Microsoft Tape Format) files. The command line version (sqb2mft.exe) is shipped with the product.

This utility makes it possible to restore backups created by SQL Backup using the restore command directly in SQL Server by converting them (and uncompressing the file) to a native SQL Server format.

The utility is freely distributed and doesn't require the full product installation. This means if you copy over this utility and the *.sqb file, it's pretty simple to move and then restore a backup file created with SQL Backup to a server that doesn't have SQL Backup installed.

SQL Backup to MTF Converter - the user interface

We have now got a user interface for this utility and it's on the Red Gate Labs as an unsupported application, free to download. It's not currently part of the SQL Backup application, however the idea is that by providing a user interface we have hopefully improved the conversion process. There are no license restrictions and there is no installation.

Comments about the user interface can be read on the forum. We're very keen to hear your feedback, so please post your ideas and thoughts about the utility on the forum. There are five goodie bags on offer to our top five forum entries!

One Monday lunchtime not so long ago we ran a bug hunt for SQL Backup 5. During the hour and a half session 12 participants (all willing Red Gate employees) paired up to try and break the application with the promise of wine and chocolates for the ‘most interesting bug found’. This was by far the most fun testing activity we have ran during the development of this next major release and took less then a day to organise. It also proved to be very useful with some ‘quirky’ issues being raised which would have gone unnoticed using the regression test scripts and the other formal test practices.

The idea of the bug hunt came from James A Whittaker’s book “How to break software”.

“Working in teams of two, one participant usually drives the application and the other sits back and thinks about the big picture. The driver is in charge or pressing keys and navigating the application, and the back-seat driver is in charge of paying attention to the application as a whole and making recommendations about what to try. Often the back-seat driver is the one who notices when a bug occurs.”

Although we adapted the process (we didn’t fancy giving the teams a bell to ring when they found a bug, we let them just holler) we took a lot of advice from James A Whittaker’s on how to run the event. The intention remained as described “The purpose of a hunt is not only to shake some good bugs out of a new build but also to foster teamwork and friendly, healthy competition among your testers”

We had 6 teams who spend approximately 45 mins to ‘play’ with the application and explore the features. For the next 45 mins we gave each pair a different feature in which to focus the testing, for example, Back Up dialog, Restore dialog, Reporting or the Log shipping dialog. Several teams came across known issues which we hadn’t had chance to fix yet, but this was useful to make sure we have the priority of the known bug correctly logged. Following the bug hunt I did find myself raising the priority of some known issues after seeing the context in which the bug hunters came across them. It’s a tough call though deciding when to run the bug hunt as if we left it until we’d fixed all the known issues we’d be close to release and then not in a position to make any potentially big design changes. We decided not to give a list of known issues as we didn’t want this to influence the testing.

I was pretty nervous, watching and listening to colleagues from different departments (developers, support engineers, sales and marketing) use an application which I have been closely involved with. It’s been my (working) life for a number of months now and it was a matter of pride that it didn’t fall over at the first sign of being ‘stressed’. It is amazingly revealing watching people first hand learn how to navigate around, and hearing their comments when they are stuck. Terminology we had taken for granted as being crystal clear was actually sometimes ambiguous. There were lots of field validation tests occurring with thousands of characters being pasted into text boxes and plenty of attention on how many clicks it takes to perform a task. With such attention to detail it didn’t take long for the feedback forms to be filled out. All extremely valuable information (assuming you can read the hand writing).

Given that the whole event took less than a day to organise and the only cost was the wine and chocolates (other than the time spent by the participants), the list of ideas for new features and the new bugs found made it a rewarding way to improve the quality and check the application is still on track for release. The bug hunters all got chance to get up to speed with the product too, so it also served as the first round of product training. I’d recommend it as part of any software development project and like to hear any useful tips from anyone who’s run a bug hunt before.

Compared to using native SQL Server to perform database backups, third party tools can create fast backups which are compressed and encrypted. This is the main premise for SQL Backup, performance. How quickly are your backups created and how much space do they take up? There are also other factors involved when reviewing the other products on the market, not to mention how much it will cost or ease-of-use, but fundamentally the performance has to be up there as a deciding factor.

There are 3 compression levels to choose from in SQL Backup. It’s a trade-off between optimising for speed or compression, so compression level 1 offers will compress the backup at high speed, while compression level 3 will take the longest (still quicker than native backups) but will result in the smallest backup file. In the middle, compression level 2 will provide a fast backup which is well compressed if both factors are equally important. It’s an easy 3-way decision for users to make, is it speed, compression or both which takes priority?

As part of the testing during development of new versions of SQL Backup, we regularly run tests on our test databases to monitor SQL Backup performance, recording speed and compression at all 3 compression levels. After boasting about the recent performance enhancements to the current released version of SQL Backup the idea was hatched to get an independent test carried out to compare performance with the other tools in the SQL Server Backup market.

The Tolly group have produced a report comparing the performance of Red Gate’s SQL Backup with Litespeed from Quest and Idera’s backup tool. The highlights of the independent test showed SQL Backup delivered throughput of up to 176 MB/sec (compared with 153 MB/sec from the nearest competitor) whilst still managing to achieve the best level of compression of all 3 applications.

The full results can be viewed from http://www.red-gate.com/products/SQL_Backup/performance_evaluation.htm. They used a public data source, (the data from wikipedia) so that the tests can be reproduced by anyone on their own servers. The tests were required to conform to the fair test charter.

Thankfully for the development team the results they came back with justified the boasting since with or without encryption SQL Backup out performed both competitors on both compression and speed. No eating of hats required.

If you want to be one of the privileged few people who will get chance to influence the development of the next version of SQL Backup then please email me (helen.joyce@red-gate.com) for more details.

There's a major upgrade of SQL Backup planned and while we are keeping a number of the big features under out hats, we do like to get usability feedback during the development process from a wide cross section of the target audience. There's no preparation required on your part and we're not testing the candidates in any way. Running usability programs is an essential part of the design process for SQL Backup and therefore feedback from SQL Server DBA's and developers is extremely valuable to us. Those who are willing to take part will be rewarded for their time. It’s also a great opportunity to have some bearing on how the next major version evolves.

I recently wrote an article for the simple talk website about software testing. I should have put a link from my blog straightaway but must have got side tracked with SQL Backup and test team duties!

The article can be found at:

 http://www.simple-talk.com/opinion/opinion-pieces/driving-up-software-quality---the-role-of-the-tester/

Take a look to see my views on what it's like to be a tester and what we actually do at work. Any feedback is most welcome in particular from other software testers.

Here's a snippet:

In reality testing can be an extremely creative activity. You still get to develop complicated software, only the objective is different. Where developers have to stick to a fairly rigid brief on what they are coding, testers have more freedom about what and how to build applications that increase productivity or verify quality. It's also extremely satisfying to break a developer friend's code!