Comments
Sort by recent activity
The converted transaction log file restores properly with EM. / comments
The converted transaction log file restores properly with EM.
Brian,
Wanted to let you know that I unzipped and installed the SQL Backup update.
Unfortunately the problem doesn't seem to be corrected with this update.
Sam / comments
Brian,
Wanted to let you know that I unzipped and installed the SQL Backup update.
Unfortunately the problem doesn't seem to be corrected with this update.
Sam
I re-ran the restore again. It seems to fail on the same transaction log.
5/4/2005 8:18:22 AM: Restoring file: [image] \Program Files\Microsoft SQL Server\MSSQL\BACKUP\nimc\LOG_(local)_nimc_20050504 054500.sqb
There's no proprietary data in this transaction log. I can provide a zipped copy (5Kb) for your review. / comments
I re-ran the restore again. It seems to fail on the same transaction log.
5/4/2005 8:18:22 AM: Restoring file: \Program Files\Microsoft SQL Server\MSSQL\BACKUP\nimc\LOG_(local)_nimc_20050504 05450...
I don't know which log file failed to restore. That's part of the problem with the SQL Backup Log output:
----- SQL Server messages -----
Processed 2 pages for database 'nimc', file 'nimc_Log' on file 1.
RESTORE LOG successfully processed 2 pages in 0.002 seconds (7.168 MB/sec).
5/4/2005 8:18:22 AM: Restoring file: D:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\nimc\LOG_(local)_nimc_20050504 054500.sqb
5/4/2005 8:18:22 AM: Restore started ...
----- SQL Server messages -----
Msg 3242, Level 16, State 1, Server VAIO3, Line 1
The file on device 'SQLBACKUP_8510493' is not a valid Microsoft Tape Format backup set.
Msg 3013, Level 16, State 1, Server VAIO3, Line 1
RESTORE LOG is terminating abnormally.
There's no indication of which file was at fault.
I'll try to locate the file today by restoring the transaction logs individually. Assuming the logs are processed individually, it's number 16 out of 22 transaction logs. / comments
I don't know which log file failed to restore. That's part of the problem with the SQL Backup Log output:
----- SQL Server messages -----
Processed 2 pages for database 'nimc', file 'nimc_Log' on ...
I haven't seen this problem since my last post. I'm also running the most recent update.
Try: HELP, Check for Updates / comments
I haven't seen this problem since my last post. I'm also running the most recent update.
Try: HELP, Check for Updates
It's a schedule job from SQL Agent. / comments
It's a schedule job from SQL Agent.
I was using Windows Authentication in the GUI and an SQL account in QA.
Oddly, the problem has passed and the backups have been running since Tuesday of this week without the LOGTO option.
I'll keep an eye on things to see if this situation develops again.
Thanks,
Sam / comments
I was using Windows Authentication in the GUI and an SQL account in QA.
Oddly, the problem has passed and the backups have been running since Tuesday of this week without the LOGTO option.
I'll kee...
petey wrote:
Default log file location is <Documents and Settings folder>\All Users\Application Data\Red Gate\SQL Backup\Log.
<AUTO> does not work with the LOGTO option.
Right you are. Interesting finding there. The last log written was Friday, 1:45PM EST. The time my last backup ran successfully.
The log files appear again, with each test I ran using the GUI, then again when I added the LOGTO option.
I'm left having no idea what is the problem, but I'm glad it's running with the scotch tape applied.
I look forward to a more solid explanation and solution. / comments
petey wrote:
Default log file location is <Documents and Settings folder>\All Users\Application Data\Red Gate\SQL Backup\Log.
<AUTO> does not work with the LOGTO option.
Right you are. Interest...
As I said, the GUI works.
You want to see if the command line works. Here's the result: [image] \Program Files\Red Gate\SQL Backup>sqlbackupc -sql "BACKUP DATABASE pubs TO DI
SK = 'D:\pubs.sqb'"
SQL Backup 3.1.0, (c) Red Gate Software Ltd 2004 - 2005
Serial number: 010-001-020675-E71E
Backing up pubs (full database) to [image] \pubs.sqb ...
Backup data size : 1.938 MB
Compressed data size: 162.000 KB
Compression rate : 91.83%
Process completed successfully.
Processed 160 pages for database 'pubs', file 'pubs' on file 1.
Processed 1 pages for database 'pubs', file 'pubs_log' on file 1.
BACKUP DATABASE successfully processed 161 pages in 0.039 seconds (33.660 MB/sec
).
(1 row affected) / comments
As I said, the GUI works.
You want to see if the command line works. Here's the result:\Program Files\Red Gate\SQL Backup>sqlbackupc -sql "BACKUP DATABASE pubs TO DI
SK = 'D:\pubs.sqb'"
SQL Backup...
I've got some news...
Launched QA, ran the stored proc. Nothing, as in my earlier post.
Immediately after this failure, I added: , LOGTO = ''d:\sam.txt'' to the end of the list of the stored proc commands.
Pressed F5. It ran correctly. The backup of the full database worked.
Seems like there is some permission problem that developed (The GUI and the command line run with Windows Authentication), QA and scheduled jobs run under another User altogether.
I found no documentation on where the "default" LOGTO location might be. And I'll continue looking.
One more question: does <AUTO> work in LOGTO = ''d:\<AUTO>''
What is the solution and cause of this problem? These scripts ran correctly for almost a week. / comments
I've got some news...
Launched QA, ran the stored proc. Nothing, as in my earlier post.
Immediately after this failure, I added: , LOGTO = ''d:\sam.txt'' to the end of the list of the stored proc...