I'm running SQL Server 2016 (13.0.5850.14) with a linked server connection to Google BigQuery using the Simba BigQuery driver v2.4.1.1009 (64 bit). I have multiple queries that I'm using to bring data back to our premise operational data store. The solution works fine for small record sets but there seems to be a point where larger record sets kill the SQL Service.
One of my queries returns a record set within a few seconds when limited to 40,000 records but kills the service when returning the full record set of approx 47,000 records.
SQL traces don't show any errors, neither does the event log. The SQL log does say:
Message
SQL Server is terminating because of fatal exception 40000015. This error may be caused by an unhandled Win32 or C++ exception, or by an access violation encountered during exception handling. Check the SQL error log for any related stack dumps or messages. This exception forces SQL Server to shutdown. To recover from this error, restart the server (unless SQLAgent is configured to auto restart).
I've already extended the timeout on the connections but that doesn't seem to have made any difference and I suspect its more some sort of memory issue with the driver but I really don't know what more I can do? Appreciate any suggestions
Related
I got the following message while querying a database to pull data to retrain a model. I do not have sysadmin access or anything like that, I am merely a user of a larger database shared by our whole organization. I'm trying to understand what this message means; is our SQL server doing a shutdown or have I potentially done something to cause this? All I have done before seeing this error message is import libraries and run the query.
('42000', '[42000] [Microsoft][ODBC SQL Server Driver][SQL Server]SHUTDOWN is in progress. (6005) (SQLExecDirectW)')
unable to rollback
Assuming you are set up correctly, you would never be able to shut down a SQL Server instance as a user.
Based on what you've said, importing libraries would not cause a SQL Server shutdown. This would be done purposely by an administrator of the database.
I would suggest informing your IT team. Hopefully this was for some planned maintenance.
We have a clojure code that runs on Databricks, and fetches some large amount of data from Azure SQL Database.
Recently, we are getting frequent connection timeout errors.
I am new to Clojure, so I don't understand why this error occurs. Sometimes the code runs perfectly while sometimes it fails.
We have tried different connection parameters like "connectionretry" and "logintimeout" but it didn't work.
com.microsoft.sqlserver.jdbc.SQLServerException: Connection timed out (Read failed)
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:234)
at com.microsoft.sqlserver.jdbc.SimpleInputStream.getBytes(SimpleInputStream.java:352)
at com.microsoft.sqlserver.jdbc.DDC.convertStreamToObject(DDC.java:796)
at com.microsoft.sqlserver.jdbc.ServerDTVImpl.getValue(dtv.java:3777)
at com.microsoft.sqlserver.jdbc.DTV.getValue(dtv.java:247)
at com.microsoft.sqlserver.jdbc.Column.getValue(Column.java:190)
at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getValue(SQLServerResultSet.java:2054)
at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getValue(SQLServerResultSet.java:2040)
at com.microsoft.sqlserver.jdbc.SQLServerResultSet.getObject(SQLServerResultSet.java:2372)
at clojure.java.jdbc$dft_read_columns$fn__226.invoke(jdbc.clj:457)
at clojure.core$mapv$fn__6953.invoke(core.clj:6627)
at clojure.lang.LongRange.reduce(LongRange.java:233)
at clojure.core$reduce.invokeStatic(core.clj:6544)
at clojure.core$mapv.invokeStatic(core.clj:6618)
at clojure.core$mapv.invoke(core.clj:6618)
at clojure.java.jdbc$dft_read_columns.invokeStatic(jdbc.clj:457)
at clojure.java.jdbc$dft_read_columns.invoke(jdbc.clj:453)
at clojure.java.jdbc$result_set_seq$row_values__233.invoke(jdbc.clj:483)
at clojure.java.jdbc$result_set_seq$thisfn__235.invoke(jdbc.clj:493)
at clojure.java.jdbc$result_set_seq$thisfn__235$fn__236.invoke(jdbc.clj:493)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:521)
at clojure.core$seq__4357.invokeStatic(core.clj:137)
at clojure.core$map$fn__4785.invoke(core.clj:2637)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.Cons.next(Cons.java:39)
at clojure.lang.RT.next(RT.java:688)
at clojure.core$next__4341.invokeStatic(core.clj:64)
at clojure.core$dorun.invokeStatic(core.clj:3033)
at clojure.core$doall.invokeStatic(core.clj:3039)
at clojure.core$doall.invoke(core.clj:3039)
at clojure.java.jdbc$query$fn__340$fn__341.invoke(jdbc.clj:1007)
at clojure.java.jdbc$query$fn__340.invoke(jdbc.clj:1006)
The issue isn't related to Azure SQL Database JDBC driver but the way you are establishing the connection and running queries.
Make sure you are closing the connection properly after every commit. Additionally, you have a sufficient sleep time between connections.
Also, make sure that the large data you are fetching must have required bandwidth and properly queried.
You can refer these official documentation for troubleshooting:
Troubleshooting connectivity issues and other errors with Azure SQL Database and Azure SQL Managed Instance
Resolving connectivity errors to SQL Server
Currently, I have two separate SQL Server instances that I am querying using pass-through SQL queries via a form in Microsoft Access.
The queries to SERVER1 work every time without fail. I'd say about 80% of the time the queries to SERVER2 don't work after Access has been closed and re-opened until I go in and "modify" the OBDC connection string and save the query. I have quotes around modify because if I edit one character in the string and re-add it and then save, it usually starts to work again (but not always), even though the string hasn't changed. And once it works it will continue to work until once again Access is closed.
It's usually one of three errors, here are two of them and the third error which I get less frequently is that the login is incorrect:
The OBDC connection string is as follows (for what it's worth I also tried ODBC Driver 17 for SQL Server and got the same results):
ODBC;Description=SERVER2 PASSTHROUGH;DRIVER=ODBC Driver 11 for SQL Server;SERVER=SERVER2;UID=Test;PWD=Password;DATABASE=MyDB;LANGUAGE=us_english;ApplicationIntent=READONLY;
How do I go about solving this problem? Also, I am willing to provide any clarifying information.
Thanks!
Thanks to Alex for the reply.
Alex recommended going to SQLCMD Unable to complete login process due to delay in opening server connection. I should have been more scientific but I used a shotgun approach... I set my shared memory to disabled, as well as increased the connection timeout and command timeouts.
This then produced a new error for me similar to the one here No process is on the other end of the pipe (SQL Server 2012).
As many of the comments suggested, my SQL server was set to SQL Server and Windows Authentication mode, I changed it to Windows Authentication mode, and then back to SQL Server and Windows Authentication mode, and restarted my SQL server.
And for now, my problem has not shown up through multiple MS Access restarts and a few PC restarts as well for good measure. Fingers crossed.
My users are receiving the query timeout error when they try to insert data to SQL server 2008 through an Access 2010 form. The error msg specifically occurs when users move off the record having keyed in all data fields.
When I look into Activity Monitor in SQL Server I can see many blocked SPIDs throughout the day but they do soon clear up. I don't know why this happens and the only solution seems to be restarting the SSMS Services. I don't think its a memory issue as the server has got 8GB which is plenty. The SQL DB is only 400 MB, but there are many transactions taking place across 2 sites.
I do notice that the SSMS memory consumption is around 3.5GB at the time of this error. After the restart this goes down of course.
Where do I start looking? is it network related or is it a blocked process due to local VBA code which could be moved to SQL Server? or is it cache related?
I'm no DBA so not sure of how to go about the search.
Thanks
I have been getting these intermittent ColdFusion Database connection reset errors and was wondering if anyone had experience with this and had a particular solution that worked?
Here is the error:
Error Executing Database Query.[Macromedia][SQLServer JDBC Driver]A problem occurred when attempting to contact the server (Server returned: Connection reset). Please ensure that the server parameters passed to the driver are correct and that the server is running. Also ensure that the maximum number of connections have not been exceeded for this server.
This doesn't happen with any particular query, the code breaks in different queries every time, returning a SQLState error 08s01. These query's logic are fine, no logic errors etc. I checked the network logs and there were no database server connection refusals at the time of the error. Once the first error occurs, it keeps happening for no more than a minute or so at random times of the day, every few days. I've googled this thing and so far anyone that has had this issue was only on CF6 or 7, which the fixes coldFusion put out are only for CF6 or 7.
Server configuration wise:
The ColdFusion server is version 8
The database server is SQL Server
2005 Standard
The database connections allowed
setting is set to unlimited on both
SQL Server and ColdFusion
Any help would be greatly appreciated, Thanks!
I'd personally try to update JDBC driver ( http://sourceforge.net/projects/jtds/ ) and add Validation Query if not already existing. I used once tool which was constantly checking TCP connections between servers, detecting even milisecond gap, check this tool http://www.colasoft.com/ping_tool/ .
Have you already resolved the issue?
I'm having the same problem on CF8 VPS, and after doing some research online I found this post:
http://www.mail-archive.com/cf-talk#houseoffusion.com/msg302264.html
It says it's related to some features on the network card and something on the SP2 for Win2k3 that messes it up. Don't know if that applies to you but just in case.