1

This morning, I navigated to my website and saw it crashed with this message after any stored procedure:

Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

I noticed in the Event Viewer that there has been a brute force login attack by someone trying to use 'sa', so I disabled remote access.

Appart from that, I have no clue about what happened. Now, no ASP.Net page can be processed because SQL Server 2008 requests don't work and always return Timeout when trying to execute a stored procedures.

What could be the cause, and what should I check and fix?

[EDIT 3]

Resolved by changing the IP in the connection string to 127.0.0.1. An obscure firewall setting was still blocking external IP after I blocked then unblocked access to SQL port from external IPs.

[EDIT 2]

I made a query directly in SQL and the message shown is:

A transport-level error has occurred when sending the request to the server.

[EDIT]

Three possibilities are listed in a similar thread:

1 - There's a deadlock somewhere.

No, because:

  • All stored procedures now answer with this error
  • No code or procedure has been changed after the attack.

2 - The database's statistics and/or query plan cache are incorrect

I typed DBCC FREEPROCCACHE, it successfully deleted the cache with no errors.

I typed exec sp_updatestats, cache reset didn't change anything.

3 - The query is too complex and needs to be tuned

Same as 1. And stored procedures are very simple / basic.

Léon Pelletier
  • 2,701
  • 2
  • 40
  • 67
  • 1
    This question was once asked here http://stackoverflow.com/questions/8602395/timeout-expired-the-timeout-period-elapsed-prior-to-completion-of-the-operation – omoabobade Aug 16 '12 at 15:39

1 Answers1

0

Other answers for this question (I mean "in other threads", not "here") should also have focussed on the essential:

This error can also mean that it's impossible to communicate with SQL Server using the current connection string. Very basic.

In my case, my Windows firewall didn't (as usual) reflect how it was really acting. When was under brute force attack, I blocked access to SQL ports in the firewall and rebooted (and it changed nothing). Then after a while, even after I deleted this rule, it seems SQL began to refuse access to any IP address appart from lan IPs. But I wasn't thinking anymore about this rule in the firewall anymore. Anyway, I wanted to block external access and figured out after that there was a 'case' to check in SQL Manager to do this.

What I've done is to change my public IP address to 127.0.0.1 in the connection string.

Léon Pelletier
  • 2,701
  • 2
  • 40
  • 67