Free SQL Server Management Studio memory usage - ssms-2012

Is there a memory usage limitation for SQL Server Management Studio and is there a way to free SSMS memory without rebooting it? I am currently using SSMS 2012 and I always getting error message like below:
'An error occurred while executing batch. Error message is: Exception of type 'System.OutOfMemoryException' was thrown.'
My computer has 24GB RAM and the free memory is 17GB but I still get above message when executing some heavy queries. I store some xml data in tables so the query can bring huge data back. However this issue is not occurring all the time. usually it is after I run SSMS for a while that makes me think it is a memory usage limition. at this moment I have to reboot SSMS to get my query executed. Is there a way to free memory without rebooting SSMS?

Álvaro González is right. I installed a 64 bit SSMS and haven't seen same issue again so far.

Related

Internal OLE Automation errors

I've got a legacy project which runs some queries every minute to an Access database. All the queries work fine but after a certain amount of time (multiple weeks) and then all of a sudden Internal OLE Automation errors start appearing left and right. It first starts with one query giving an error and then slowly but surely all the queries will generate the error.
My gut feeling says this is a timeout issue but I don't have any clue where to start.
In advance: I know Access databases are horrible and that I shouldn't be using the JDBC-ODBC bridge in production environments but as I said this is a legacy project which we're still supporting.
Please do let me know if you need any additional information or code snippets.
Edited to add: The error is always java.sql.SQLException: [Microsoft][ODBC Microsoft Access Driver] Internal OLE Automation error For this specific server we use Java 6, Tomcat 6, Windows Server 2012 and the ms access driver native in Windows on version 6.03.9600.17415. They are all the 32 bit versions.

Making MySQL client program thread safe?

I'm running into an interesting threadding problem while running a D programming that uses the MySQL C API. I am getting error 2013 "Lost connection to MySQL server during query." The problem appears to occurs when enough threads flood the network interface buffer, but the server still has more to transfer. This is my best guess based on some research and running the program on two different computers. One computer has a 100Mb connection to the server and the other has a 1Gb connection. The computer with the 100Mb connection throws the error, while the 1Gb computer does not. I am wondering if I am running into what is described in the first paragraph of How to Write a Threaded Client in the MySQL documentation. If I am, what do I need to do with SIGPIPE and how do I do it?
For those who are interested, I am calling mysql_library_init before any library call and I am creating a new MYSQL* for each thread with mysql_init and mysql_real_connect. Also of note, the queries that I am executing are small SELECTs, only a few thousand records returned from each query and all queries are executed from the same table.
Please try this before mysql_real_connect:
my_bool myb = 1;
mysql_options(conn, mysql_option.MYSQL_OPT_RECONNECT, &myb);
Also please check this mysql troubleshooting page:
http://dev.mysql.com/doc/refman/5.5/en/gone-away.html

Memory Leak using msxml3.dll

Currently on Windows Server 2008 R2 Standard with 32GB memory.
Once the server hits a Memory usage of around 50% (18GB, 13GB of it is for SQL Server (2008)) some strange things are happening with the XMLHTTP requests. I have tried using "Microsoft.XMLHTTP and MSXML2.ServerXMLHTTP but i get the same result.
I am getting a 2 different errors all associated with the msxml3.dll file:
Error #: -2146697211
The system cannot locate the resource specified.
and
Error #: -2147024888
Not enough storage is available to process this command.
After i restart the server, everything seems to be working fine, for now at least, we'll see when the memory usage starts increasing.
I have searched a while for a solution, and have found that nothing seems to work except for restarting the server, haven't tried just restarting IIS, but I am wondering why this is happening all of a sudden.
If you mean to reserve only 13GB of memory for SQL Server, you need to tell someone. Right now you've told SQL Server to take over the server if it wants.
EXEC sp_configure 'show adv', 1;
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure 'max server memory', 13000;
RECONFIGURE WITH OVERRIDE;
GO
Now restart SQL Server. This won't guarantee that SQL Server won't use more than 13 GB, since this setting only controls certain aspects of its memory usage, but it will prevent SQL Server from taking over the box.
This is the setting I assumed you had already set what you said:
18GB, 13GB of it is for SQL Server (2008)

A transport-level error has occurred... (Existing connection closed by the server) Sql Server 2008

I have a web application which is currently running on Windows XP operating system with SQL Server 2005 database and IIS 6.0.
Now, we are trying to upgrade it to IIS 7.0 on Windows Server 2008 and SQL server 2008 database.
When I run the application then it is throwing "A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)" randomly at different database calls.
I have verified using "sp_who" that only one connection which I am using is opened.
Can anyone tell me, what could be the cause of this issue?
This blog post by Michael Aspengren explains the error message "A transport-level error has occurred when sending the request to the server."
Maybe the database is set to auto-close? This used to be the default for databases created on the older MSDE/Express edition.
ALTER DATABASE YourDatabaseName SET AUTO_CLOSE OFF;
More:
The SQL Server 2005 Express Edition Overview states:
Features like Auto-Close and the ability to copy databases as files are enabled by default in SQL Server Express ...
I can't remember which service pack changed the default, but the New Database UI in the SP3 version of Management Studio Express defaults the Auto Close setting to false.
This is an error that occurrs when connecting to database due to a lower layer network-related error that you cannot handle from Sql Server.
It would be great that the API used to conenct handled this error but AFAIK it is not. The only way to solve this is to retry connecting to the database when this error occurrs.
You should try to reconnect at least a couple of times more to get sure that the error is not persistent and if it is the case then throw the exception. My experience tells me that trying to reconnect, the 99.9% of times you will succed.
Often, it's the database being offline/closed or the SQL Instance being restarted/offline
In my case. We have DELL R720, NICs are on board and PCI Broadcom NetXtreme Gigabit Ethernet cards. We run into two issues.
Network speed is very slow for HyperV VMs. The solution is to disable the "Virtual Machine queues" of the HyperV host Broadcom nic property windows. It is in the Advanced tab.
SQL client having this transport level issue. It only happened once in every 10-15 min. At the same time the RDP service kick out client from time to time also. The solution is to disable the "Large Send Offload V2" of the HyperV host Broadcom nic property windows. It is in the Advanced tab.
Check if you have MultipleActiveResultSets=true; set in your connection string.
Transport level errors are often linked to the connection to sql server being broken ... usually network.
Timeout Expired is usually thrown when a sql query takes too long to run. Is this the scenario in your case? Like stored proc taking too much time to execute or are there are batch jobs that are executed?
Use clearpool(urSQLconnection), along with dispose. This will clear the dirty connection. and you can open new connection.
Got this trying to execute commands from multiple threads on one connection object in .net, that was a stupid mistake. Locking it or using a separate connection per thread fixes that.
In my case it was McAffee that was pre-installed. Can tell if it was conflict with other solutions or not. The connection was on VPN, on WiFI. Maybe this will help someone in future.

SSIS package execute - Out-of-memory issue!

While executing SSIS package, I got following errors,
The buffer manager failed a memory allocation call for 10484608 bytes, but was unable to swap out any buffers to relieve memory pressure. 20 buffers were considered and 20 were locked. Either not enough memory is available to the pipeline because not enough are installed, other processes were using it, or too many buffers are locked.
[DTS.Pipeline] Error: Thread "SourceThread0" has exited with error code 0xC0047038.
[DTS.Pipeline] Error: The Data Flow task failed to create a buffer to call PrimeOutput for output "XML Source 1" (91) on component "GeneralCongfigurations" (98). This error usually occurs due to an out-of-memory condition.
It happen when trying insert data to SQL table from an XML file with 'Script Component'.
How to solve it?
The message tells you SSIS is using 20 buffers, 10Mb each - about 200Mb together.
It is not very big amount of memory, even on 1Gb machine you would not run out of memory.
It is likely other processes consume the rest of the memory - check the task manager. Often it is SQL Server who consumes all the memory - if you run SQL and SSIS on same machine, restrict the amount of memory SQL is allowed to consume (in SQL Server properties), leaving some memory for SSIS - I would recommend leaving at least 0.5Gb.
You should also look at all of the log messages. In particular, Lookup transforms can log a lot of information about how much memory they're using. You can get some very detailed logs about memory allocation.
I faced the same issue. My XML source is of around 2MB. when I start the package it started throwing this OutOfMomory warning. My server has around 8GB RAM. So it was not memory issues . Current machine SQL server service was taking close to 6GB space. I could check this from Task Manager. As my SSIS package destination was connecting to difference database I did not want the current server SQL service to be running. So the moment I stopped this SQL SERVER service, my SSIS package executed successfully.
#Chris Pickford
You want to use PerfMon Counters:
Memory\
Availabe Bytes/MBytes
Committed Byrtes
SQLServer:SSIS Pipeline\
Buffer Memory
Buffers in Use
Buffers Spooled
Also, if you've got logging on your package, look at event User:BufferSizeTuning