User profile for aarons44

I still can't get the command line MAILTO option to work. I'm calling the restore query from VB. It gets stored in a variable, and then later I call SQLBackupC with the variable as the parameter. Here's the line of code: query10 = "-SQL ""RESTORE DATABASE " & myString6 & " FROM DISK = 'G:\myFiles\CompressedBackups" & myFile6 & "' WITH MOVE '" & myString6 & "' TO 'G:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data" & myString6 & ".mdf', MOVE '" & myString6 & "_LOG' TO 'G:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data" & myString6 & ".ldf' WITH MAILTO='myemail@mydomain.com'"" -I sql -U user -P password THREADPRIORITY=6" The problem must be with where the mailto option is placed, because the restore works. Here I get a syntax error. I've also tried putting it right before the -I and I don't get an error, but I don't get the mail either. Test emails from the GUI work fine. The mail server doesn't require authentication, so credentials shouldn't be an issue. petey wrote: The command line interface uses the settings you specified using the GUI, thus you do not need to provide the mail server settings. One difference when using the command line interface is that all the work will be performed using the credentials of the logged-on user. When using the extended stored procedure, all work is performed using the credentials of the SQL Backup service startup user. / comments

I still can't get the command line MAILTO option to work. I'm calling the restore query from VB. It gets stored in a variable, and then later I call SQLBackupC with the variable as the parameter. H...

0 votes

It's been happening with both the local drive and the SAN - there are two separate backups. The first backup is supposed to run from 12:00AM - 2:00AM, and writes to a SCSI attached storage device. The second backup is supposed to run from 2:15AM - 4:00AM, and writes to a fibre channel attached SAN. The server is running and backing up 800 databases. We rebooted the server, and the SCSI attached storage backup worked fine the next day, backing up in 3 hours, but the SAN backup was slow. Every day after that both were slow, with the SCSI attached storage backup taking 8 hours. We eliminated everything else as the issue, by switching back to the SQL Server Maintenence Plans. SQL Server was able to backup the same databases in 3 hours consistently. Looking at the SQL Backup logs, it appears that deleting the backups is what is taking so long. On the "fast" day, it took 6 seconds to delete a 4.438MB database. On the "slow" day, it took 2 minutes and 52 seconds. We have three large databases ( > 15GB), and they are also slower, but the small databases show the highest percentage of change in delete time. The small databases are taking anywhere from 10 seconds to 3 minutes or more longer to delete. I think that what is occuring is that the first backup after a reboot works fine, and then every backup after that is slow, regardless of destination. The first SCSI backup was normal, but then the SAN backup that occurs right after it was slow, and then after that they were both slow. I've set perfmon counters for processors, memory, disk queue length, and they show no difference between a fast day and a slow day. So, just to summarize and recap, we're running Windows 2003 x64 SP2, SQL Server 2005 x64 SP2, 32 GB of RAM, SQL Backup 5. The first backup after a reboot appears to be fast, with every backup after that becoming slow on the deletes. Perfmon counters show no difference between a fast backup and a slow backup in terms of CPU, memory or disk queue length. We're running / backing up 800 databases. Brian Donahue wrote: I can't think of a reason for this, but then again it may simply be a change in the environment, for instance, if you're backing up to a network share, can you find any issues that would cause packet loss, such as a flaky router? You may also want to examine your logs in %allusersprofile%\application data\red gate\sql backup\instance\logs. In the past there have been issues with Backup's peripheral activities such as copyto, backup history update, and the like. The logs will tell you how much time is being spent doing peripheral and housekeeping tasks like this as part of the backup. To be honest, I don't see anything different in the new version that would cause this. The backup engine has only had some minor changes done. But if you do have any more useful information about the environment, maybe I can offer some better suggestions. / comments

It's been happening with both the local drive and the SAN - there are two separate backups. The first backup is supposed to run from 12:00AM - 2:00AM, and writes to a SCSI attached storage device. ...

0 votes

Fred, email me and I can send you a script that might be similar to the one you are looking for. I have a script that queries a folder to get a list of database backups, stores the list in a recordset, and loops through the recordset, using SQLBackupC to restore the databases. It also runs scripts to change some tables because the databases are being restored on a different server, and uses the "With Move" option for that same reason. I'd post it here, but it is long. Aaron / comments

Fred, email me and I can send you a script that might be similar to the one you are looking for. I have a script that queries a folder to get a list of database backups, stores the list in a record...

0 votes

Ok. Let me just change some database names and I'll send it in. Daniel Handley wrote: If you send the script in to support(at)red-gate.com i can always post it on our ftp site for retrieval. It would also be useful for us to have to give out to other cutomers. Thanks Dan / comments

Ok. Let me just change some database names and I'll send it in. Daniel Handley wrote: If you send the script in to support(at)red-gate.com i can always post it on our ftp site for retrieval. It wo...

0 votes

Great, thanks! petey wrote: I'll add it to the feature request list for future consideration. Thanks for letting us know. / comments

Great, thanks! petey wrote: I'll add it to the feature request list for future consideration. Thanks for letting us know.

0 votes

Thanks, you answered it for me. Basically, I have a script that uses SQLCMD to restore databases, and then uses SQLCMD to call .SQL files that make updates to the databases. The .SQL files aren't just simple SQL commands, they're complex scripts that are about 100 lines of code each. That's why they're stored in .SQL files rather than just executing the commands directly with SQLCMD - there is a lot of processing that goes on in the scripts as well. I was easily able to replace the restore part with SQLBackupC. I was hoping to call the .SQL files with SQLBackupC as well, so I would only have to use one program. It's not a big deal though. SQLBackupC does the restore and SQLCMD calls the scripts. eddie davis wrote: Hi Sorry I am a little confused with your question. Red Gate SQL Backup provides a comand line utility so you can perform back and restore operations in any SQL Script or batch files that you create. The SQL Backup command line executable is call SQLBackupC. It is located in the folder in which you installed the SQL Backup Server Components, by default this is C:\Program Files\Red Gate\SQL Backup\<instance name>. The SQL Backup command line interface uses a subset of the T-SQL Backup and Restore statements. Further advice on using the SQL Backup Command Line Interface can be found in the SQL Backup Help file. If I have understood your post correctly, the answer is no you cannot use the SQL Backup Command Line Interface to call other .SQL Scripts. However you can include SQL Backup Command Line Interface into any .SQL Scripts that you create. Eddie Davis Red Gate Software Ltd Technical Support Engineer / comments

Thanks, you answered it for me. Basically, I have a script that uses SQLCMD to restore databases, and then uses SQLCMD to call .SQL files that make updates to the databases. The .SQL files aren't j...

0 votes

How can we help you today?

aarons44

Comments