Comments
Sort by recent activity
Hi, has there been any progress on the fixing of this bug?
It's still affecting the latest version of SQL Compare and is preventing us from upgrading.
Thanks
Chris / comments
Hi, has there been any progress on the fixing of this bug?
It's still affecting the latest version of SQL Compare and is preventing us from upgrading.
Thanks
Chris
I guess that this could be causing the problem.
You could use the following code to close all open XML documents - but note that you should first disable all processes that rely on open XML documents. You should use this at your own risk.
EXEC master.dbo.sqbmemory
GO
DECLARE @hdocument int
--Open a dummy document to get the next handle.
EXEC dbo.sp_xml_preparedocument @hdocument = @hdocument output
DECLARE @i INT
SET @i = @hdocument
WHILE @i >= 1
BEGIN
EXEC dbo.sp_xml_removedocument @i
--The handle always appears to be an odd-number on my test machine
--but you might want to experiment to see if this is true in your environment.
SET @i = @i - 2
END
GO
EXEC master.dbo.sqbmemory
GO
Chris / comments
I guess that this could be causing the problem.
You could use the following code to close all open XML documents - but note that you should first disable all processes that rely on open XML documen...
In my opinion everything you've said so far points to a problem with VAS pressure and not to anything 'external' to SQL Server, such as disk fragmentation, page files etc...
The reason I asked about CLR objects is that it seems that when the CLR initialises it consumes about 120-140MB of VAS, which is consistent with the out of memory error that you experienced when experimenting with CLR objects. @VERSION'?
If you haven't done so already it might be worth setting up a SQL Agent job to log the results of the 'sqbmemory' extended proc on a regular basis, I would suggest a frequency of one minute. This way you can track the 'total' and 'maximum' 'free' values over time and possibly correlate any drop-off with processes and/or jobs that are running on the server at that time. If you use Reporting Services then you could create a report to display the data against time.
Another thing that can cause VAS problems is heavy use of linked servers - do you use these at all? Other causes can be a large procedure cache, large numbers of SPIDs, larger numbers of cursor operations - it's impossible to quantify 'large' for your server, though, without an understanding of the workload.
Chris / comments
In my opinion everything you've said so far points to a problem with VAS pressure and not to anything 'external' to SQL Server, such as disk fragmentation, page files etc...
The reason I asked abou...
Everything seems to be in order there then.
Do you use any CLR objects (functions, stored procs or UDTs)?
Chris / comments
Everything seems to be in order there then.
Do you use any CLR objects (functions, stored procs or UDTs)?
Chris
Well at least you're now starting to eliminate things. [image]
You say that you have AWE enabled in SQL Server - do you have the /PAE and /3GB switches enabled in the boot.ini file?
We had server memory issues when migrating from SQL Server 2000 to 2005 and the problem was caused by the presence of the /3GB switch - only the /PAE switch is required for SQL Server 2005 to use AWE. One of the symptoms was that SQL Backup would fail with an 'insufficient storage to complete this command' error.
Chris / comments
Well at least you're now starting to eliminate things.
You say that you have AWE enabled in SQL Server - do you have the /PAE and /3GB switches enabled in the boot.ini file?
We had server memory i...
The sp_OA... issue was fixed in a pre-CU9 update so it's unlikely to be that (we applied CU9 and it resolved the problem that we were having).
I'd focus on your usage of the XML procs before looking elsewhere for the cause.
Chris / comments
The sp_OA... issue was fixed in a pre-CU9 update so it's unlikely to be that (we applied CU9 and it resolved the problem that we were having).
I'd focus on your usage of the XML procs before lookin...
Are you running SQL Server 2005 SP2, and do you regularly use (or use a 3rd-party app that regularly uses) the sp_OA... procedures? If so then you should look to apply the latest service pack of SQL Server as there is a known memory-leak issue relating to the use of the sp_OA... procs.
Have a look here for further info: http://support.microsoft.com/kb/937277
We recenly had a call open with Microsoft about this same problem and it turned out to be the use of these stored procs that caused the symptoms. Ironically it was the monitoring software that we were using to monitor the problem that was using the sp_OA... procs.
Another cause of memory (VAS) pressure can be the use of sp_xml_preparedocument without a corresponding sp_xml_removedocument.
Hope this helps.
Chris / comments
Are you running SQL Server 2005 SP2, and do you regularly use (or use a 3rd-party app that regularly uses) the sp_OA... procedures? If so then you should look to apply the latest service pack of SQ...
Actually, I've managed to sort this out myself by downloading a copy of SQLite Database Browser and removing the problematic entries from the Document and DocumentVersion table.
All is now well. / comments
Actually, I've managed to sort this out myself by downloading a copy of SQLite Database Browser and removing the problematic entries from the Document and DocumentVersion table.
All is now well.
Hi Steve
Thanks for your reply, however this isn't a feature request - I believe that it is a bug.
The point is that although the fulltext index definition differs there is no relevant sync statement included in the synchronisation script.
Chris / comments
Hi Steve
Thanks for your reply, however this isn't a feature request - I believe that it is a bug.
The point is that although the fulltext index definition differs there is no relevant sync stateme...
Hi Red-Gate
It's been four months since we initially reported the filter bug (for which you created SC-6165).
Are you able to confirm when this issue will be resolved?
Thanks
Chris / comments
Hi Red-Gate
It's been four months since we initially reported the filter bug (for which you created SC-6165).
Are you able to confirm when this issue will be resolved?
Thanks
Chris