Most of my earnings come from my role as SQL Server Performance Tuning and Optimization consultant. Every single day I work with few customers so that I can maintain the quality of my work with each of them. As you can imagine, I face new challenges and learn new ways to tune SQL Server. In this blog post, we will discuss an error XML document could not be created because server memory is low. Use sp_xml_removedocument to release XML documents.
System.Web.HttpUnhandledException (0x80004005): Exception of type ‘System.Web.HttpUnhandledException’ was thrown. —> HRMS.Runtime.Remoting.RemoteServerException: The remote server generated an exception.
<Description>XML document could not be created because server memory is low. Use sp_xml_removedocument to release XML documents.</Description>
Above message is error number 6624 in SQL Server.
Now here is the interesting part, a server had around 300 GB of RAM and most of it was free when SQL raised the error. It looks like there is some memory limit somewhere. My further search on the internet shows: “A parsed document is stored in the internal cache of SQL Server. The MSXML parser (Msxmlsql.dll) uses one-eighth the total memory available for SQL Server.” When I looked further, I also found that it can’t take more than 4 GB of RAM irrespective of total RAM on the server.
When we looked at the pattern of the issue, it was clear that they are having an increase in the data getting processed. OpenXML is not able to scale because with the data processing. It worked fine when data was less but now it is hitting 4 GB limit and that’s why we are getting out of memory error, even though the message says “server” memory.
As a long terms solution, I helped them in changing the code to XQuery methods (value, query, nodes) for XML processing instead of OpenXML. As per documentation, XQuery uses different parser then OpenXml, and have much better memory management since it’s implemented in the engine itself. XQuery Language Reference (SQL Server)
So if you need to choose between OpenQuery and XQuery, then go with XQuery for scalability reasons.
Reference: Pinal Dave (https://blog.sqlauthority.com)