User profile for marclallen

Brian, That is not true as far as I can tell. I can set some options, yes, but I can only control when updates are actually installed, not when they are checked for or how often. If you search Google on SVCHOST CPU 100 or similar, you'll find tons of threads about how the periodic Windows Update check can own a system for 10 minutes or more. It often happens on bootup and, for me, usually happens at least once in the afternoon, sometimes more often. I have found no documentation on when Windows Updates does its internal checks or what else it does besides simply updating. In these particular cases, both machines had uninstalled updates which I hadn't found time to perform, yet. I have no idea if that changes the equation or not. Finally, all I am doing is reporting what I have found. And that is, that at least one backup succeeded after several failures when I disabled Windows Update. I apologize if this seems rude, but when I am only able to receive a single communication from Red Gate each day, even though I often provide supplemental information early in your day, it irritates me that I receive unhelpful information. Even had I not known about a way to schedule Windows Update, and even if your suggestion had fixed it, it does not relieve Red Gate of the responsibility of identifying why that would be causing a problem if, in fact, it is. I am under the impression that Red Gate feels this is not an issue with SQL Backup but a series of external, uncontrollable influences. If so, explain why a standard SQL backup to the same share, which often takes two to three times longer, does not have any issues? I know this has been reported by other users, as I am in communication with one. As you don't appear to be actually working on it, perhaps you could take some time and answer some questions for me so that, maybe, I can troubleshoot it better: 1) If, as you say, the error may be due to a lack of contiguous memory, why doesn't the SQL Server Log indicate it? They have several warning messages for that sort of scenario. Also, why is it reported as a lack of disk space? 2) Who is actually reporting that error? Is SQL Server doing something, getting an error and passing it on to you? Or does the server grab a pile of data, pass it on to you, and then you error out and return the error back to SQL Server? 3) If the Red Gate virtual backup device is the one generating the error, why is there no retry logic? Or is there? Especially in the case where it's actually a buffer management problem? Some additional information: When still failing, I ran NETMON.EXE on the share machine. It did not show any sort of error, or network reset. It simply stopped in the middle of a long SMB write. Marc / comments

Brian, That is not true as far as I can tell. I can set some options, yes, but I can only control when updates are actually installed, not when they are checked for or how often. If you search Goo...

0 votes

Other information from MS support: http://support.microsoft.com/kb/843515 I'm not sure if it applies, but since I don't know who's actually issuing the 112 error, I don't know if perhaps it's reporting the wrong error. Marc / comments

Other information from MS support:http://support.microsoft.com/kb/843515 I'm not sure if it applies, but since I don't know who's actually issuing the 112 error, I don't know if perhaps it's report...

0 votes

Brian, Good thoughts. We are not running Symantec, althought NOD32 might have similar issues. I did shutdown the actual AV checking for a number of tests, with no luck; however, I know that it installs filters in the network stack that cannot be bypassed without deinstalling it. Personally, I don't think NOD32 is to blame, though. There have been a number of complaints against it, and, as far as I can tell, it turned out there was always a problem somewhere else. Still, if need be, I will remove it an try more. The affected servers are on a simple LAN, with the two source machines on static IPs and the destination on DHCP (why? I must've forgotten to give it one.) They connected through a single GB switch. So, no special network architecture here. Interestingly enough, my final attempt at one of the two databases did work after I disabled the Windows Update service. Unfortunately, the second host still failed after the same change. I will test more on that today. Petey, the log follows. I need to check, but it appears that the second host (which is not attached) reports a "share not available" in the log, but the event in the event log still indicates an error 112. I am thinking it's because it is trying with single threading. I have posted the SQL Log entries in an earlier thread. 6/15/2007 3:09:09 PM: Backing up OutsiteContent (full database) to: 6/15/2007 3:09:09 PM: \\Fileserver\HostBackups\Transaction1\FULL_(local)_OutsiteContent_20070615_150909.sqb 6/15/2007 3:09:09 PM: BACKUP DATABASE [OutsiteContent] TO DISK = '\\Fileserver\HostBackups\Transaction1\<AUTO>.sqb' WITH NAME = '<AUTO>', DESCRIPTION = '<AUTO>', INIT, ERASEFILES_ATSTART = 6h, MAILTO = 'mlallen@outsitenetworks.com', COMPRESSION = 1, THREADCOUNT = 3 6/15/2007 3:24:46 PM: Thread 0 error: Process terminated unexpectedly. Error code: -2139684860 Process terminated unexpectedly. Error code: -2139684860 6/15/2007 3:24:46 PM: Thread 1 error: Process terminated unexpectedly. Error code: -2139684860 6/15/2007 3:24:46 PM: Thread 2 error: Process terminated unexpectedly. Error code: -2139684860 6/15/2007 3:24:47 PM: Database size : 319.679 GB 6/15/2007 3:24:47 PM: Compressed data size: 19.148 GB 6/15/2007 3:24:47 PM: Compression rate : 94.01% SQL error 3013: SQL error 3013: BACKUP DATABASE is terminating abnormally. SQL error 3202: SQL error 3202: Write on 'SQLBACKUP_D8C9E2E5-ED1F-4DD2-AB9F-E2EE215B5A8D01' failed, status = 112. See the SQL Server error log for more details. Marc / comments

Brian, Good thoughts. We are not running Symantec, althought NOD32 might have similar issues. I did shutdown the actual AV checking for a number of tests, with no luck; however, I know that it in...

0 votes

Brian, If this NETBIOS reset is something that MS widely added to their OS for security purposes, then don't you think that a simple retry would take care of it? I mean, file copies and such don't seem to have problems. Would it beneficial for SQL Backup to simply retry three or four times? Or is there a problem with not knowing if a write was committed or not? Marc / comments

Brian, If this NETBIOS reset is something that MS widely added to their OS for security purposes, then don't you think that a simple retry would take care of it? I mean, file copies and such don't ...

0 votes

Brian, I am currently running 5GB, using /PAE and /3GB, and SQL Server 2000 Enterprise. AWE is enabled, and I have only a single instance running 1 user database plus the 6 or so system databases. I have not set the -g switch, but the max server memory is set to 4GB. According to BOL, SQL Server Setup assigned the rights to lock pages in memory to the MSSQL server application by default. I assume I ndo not need to do anything else. I did check and that service runs under 'Administrator' who has permissions to lock pages. I do not know how to interpret the output of sqbmemory, but here is the idle (no backup running) output of it: Type Minimum Maximum Average Blk count Total ---------------- -------------------- -------------------- -------------------- -------------------- -------------------- Commit 4096 39514112 20582 28044 577212416 Reserve 8192 3944448 86979 27068 2354364416 Free 4096 187760640 609648 475 289583104 Private 4096 39514112 52827 54382 2872881152 Mapped 4096 1060864 53835 314 16904192 Image 4096 7581696 100460 416 41791488 If you can show me where I can identify low contiguous memory, I would appreciate it. Finally, as I noted earlier, all documentation for SQL Server indicates that the log should show something if a buffer allocation fails due to insufficient contiguous memory. I will retry my backups again at 64K MAXTRANSFERSIZE and let you know how it works. Thanks, Marc / comments

Brian, I am currently running 5GB, using /PAE and /3GB, and SQL Server 2000 Enterprise. AWE is enabled, and I have only a single instance running 1 user database plus the 6 or so system databases....

0 votes

I discovered the following: Here are the times my backups failed. Note the minute and seconds for each failure. They are practically the same every time!SQLBackup@TOTALIZER1 ERROR - full backup &...

0 votes

Egad! Dropping my MAXTRANSFERSIZE to 64KB makes the backups take FOREVER. I don't think that it will be acceptable, even if it works. Even 256K is just too slow. Can you provide any insight into how I can show, for certain, that the issue is contiguous memory? Marc / comments

Egad! Dropping my MAXTRANSFERSIZE to 64KB makes the backups take FOREVER. I don't think that it will be acceptable, even if it works. Even 256K is just too slow. Can you provide any insight int...

0 votes

Brian, Thanks for the response. If you read back a number of posts, you will see that I have already reduced the transfer size to 1MB. Are you suggesting I make it even smaller? Also, in some other posts, I saw reference to a program that tested buffer sizes. That program runs fine with no errors on my system. I do not believe it is a buffer issue, or at least not as simple as you make it out to be. Marc / comments

Brian, Thanks for the response. If you read back a number of posts, you will see that I have already reduced the transfer size to 1MB. Are you suggesting I make it even smaller? Also, in some oth...

0 votes

Dropping both MaxTransferSize and MaxDataBlock (or whatever they are called) to 512K failed. So, if it's an SQL Buffer allocation error, the error is occurring on the machine being backed up, correct? So, there should be a SQL performance counter that would be in play. Any idea on which one it would be? Also, I should note that this machine is running with both the PAE and the 3GB switch on boot. Marc / comments

Dropping both MaxTransferSize and MaxDataBlock (or whatever they are called) to 512K failed. So, if it's an SQL Buffer allocation error, the error is occurring on the machine being backed up, corre...

0 votes

Some probably useless SQL Log entries I've gotten. These are from the last failure: Internal I/O request 0x4986DE78: Op: Write, pBuffer: 0x12620000, Size: 131072, Position: 53128658944, UMS: Internal: 0x0, InternalHigh: 0x20000, Offset: 0xAD800000, OffsetHigh: 0x2A, m_buf: 0x12620000, m_len: 131072, m_actualBytes: 0, m_errcode: 112, BackupFile: SQLBACKUP_39817ADE-5343-4C13-A25E-B066011B344401 BackupMedium::ReportIoError: write failure on backup device 'SQLBACKUP_39817ADE-5343-4C13-A25E-B066011B3444'. Operating system error 112(There is not enough space on the disk.). There are more, but they're all pretty much like the above. It looks like I got both of these for each thread involved. As I understand it, if there is a problem obtaining enough contiguous memory for a buffer, the log would indicate that as a contiguous memory problem. So, I'm not sure that is it. Marc / comments

Some probably useless SQL Log entries I've gotten. These are from the last failure: Internal I/O request 0x4986DE78: Op: Write, pBuffer: 0x12620000, Size: 131072, Position: 53128658944, UMS: Inter...

0 votes

How can we help you today?

marclallen

Comments