Comments
Sort by recent activity
It's now happending on another server that was upgraded and there is no bugreport.txt file. Looks like I will have to look at all the servers I upgraded and if no bugreport.txt file exists run sqbutility 9997 and see if I get anything the next time this happens.
Chris / comments
It's now happending on another server that was upgraded and there is no bugreport.txt file. Looks like I will have to look at all the servers I upgraded and if no bugreport.txt file exists run sqbu...
Petey,
I don't have the bugreport.txt file so it looks like I will need to run exec master..sqbutility 9997 on the server if I see this again?
I think that I had mentioned that this has happened on teo occasions since we upgraded from what I have seen.
Thanks
Chris / comments
Petey,
I don't have the bugreport.txt file so it looks like I will need to run exec master..sqbutility 9997 on the server if I see this again?
I think that I had mentioned that this has happened on...
Jamie,
What version of SQLBackup are you running?
if it is 6.0 or above I believe that the GUI will have a show log entry for each job that tries to run. If the messages don't show enough then the error number can be looked up on this site or in the help contents of the GUI.
HTH
Chris / comments
Jamie,
What version of SQLBackup are you running?
if it is 6.0 or above I believe that the GUI will have a show log entry for each job that tries to run. If the messages don't show enough then the ...
Its more the max free size part that is important. I know that SQLBackup needs 6Mb contigous to run a backup. You might have over 100Mb available but if it gets fragmented and the max free is less than 6Mb it will either not run or push something out of the VAS. If you use CLR this is something else that goes into the VAS.
Chris / comments
Its more the max free size part that is important. I know that SQLBackup needs 6Mb contigous to run a backup. You might have over 100Mb available but if it gets fragmented and the max free is less ...
What version of SQL are you running?
if its 2005 or higher try running this when you are running SQLBackup
Begin
With VASummary(Size,Reserved,Free) AS
(SELECT
Size = VaDump.Size,
Reserved = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
WHEN 0 THEN 0 ELSE 1 END),
Free = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
WHEN 0 THEN 1 ELSE 0 END)
FROM
(
SELECT CONVERT(VARBINARY, SUM(region_size_in_bytes))
AS Size, region_allocation_base_address AS Base
FROM sys.dm_os_virtual_address_dump
WHERE region_allocation_base_address <> 0x0
GROUP BY region_allocation_base_address
UNION
SELECT CONVERT(VARBINARY, region_size_in_bytes), region_allocation_base_address
FROM sys.dm_os_virtual_address_dump
WHERE region_allocation_base_address = 0x0
)
AS VaDump
GROUP BY Size)
SELECT SUM(CONVERT(BIGINT,Size)*Free)/1024 AS [VAS Total avail mem, KB] ,CAST(MAX(Size) AS BIGINT)/1024 AS [Max free size, KB]
FROM VASummary
WHERE Free <> 0
end
It will tell you how much VAS is available and the biggest chunk.
Chris / comments
What version of SQL are you running?
if its 2005 or higher try running this when you are running SQLBackup
Begin
With VASummary(Size,Reserved,Free) AS
(SELECT
Size = VaDump.Size,
Reserved = SUM(CA...
You can add the -g startup parameter to increase your VAS memory.
As Petey said SQLBackup needs contigous VAS memory. This can get fragmented easily so you may need to expand this.
Chris / comments
You can add the -g startup parameter to increase your VAS memory.
As Petey said SQLBackup needs contigous VAS memory. This can get fragmented easily so you may need to expand this.
Chris
We have a similar situation that has been partially fixed in 6.5
We run a number of backups at the same time all writting to the same drive letter. If one fails because the disk space is full, we delete old backups after a successfull one, then the job will fail just like yours. 6.5 added a fix to delete the partial backup if the job fails because of sparse disk space. I then have to remove data from that drive before the backup will run successfully.
HTH
Chris / comments
We have a similar situation that has been partially fixed in 6.5
We run a number of backups at the same time all writting to the same drive letter. If one fails because the disk space is full, we d...
We run many SQLBackup backup jobs at the same time as they get scheduled into SQL Agent. Remember each job needs 6Mb of contiguous VAS memory. Also get the latest 6.5.1.9 from the download page as it has a needed fix for large database restores.
Chris / comments
We run many SQLBackup backup jobs at the same time as they get scheduled into SQL Agent. Remember each job needs 6Mb of contiguous VAS memory. Also get the latest 6.5.1.9 from the download page as ...
I think that it was 6.5.2.9 that introduced VERIFYINTERVAL. I am sure that a Red Gate support analyst will confirm. It delays the time at which the verify process begins so that data in cache can be written to disk if I rememebr correctly. I also think that there is a later version 6.5.2.18 that may have other improvements for the verify process.
You might also be able to try V 7 that came out earlier this week.
Chris / comments
I think that it was 6.5.2.9 that introduced VERIFYINTERVAL. I am sure that a Red Gate support analyst will confirm. It delays the time at which the verify process begins so that data in cache can b...
hitsgdba,
Yous don't mention what version you are running other than the possible subject line.
We are running 6.5.2.9 and have this happen every so often. We even added a VERIFYINTERVAL parameter as we had been told it might help with this issue.
Chris / comments
hitsgdba,
Yous don't mention what version you are running other than the possible subject line.
We are running 6.5.2.9 and have this happen every so often. We even added a VERIFYINTERVAL parameter ...