I am having a real big headache with slow SQL query. I have two connection string which are as follows :
ConnectString1 = "Driver={SQL Server};Server=MSSQLSERVER5;Database=SchoolMain;Uid=Admin;Pwd=admin101;"
and
ConnectString2 = "Provider=SQLOLEDB.1;Persist Security Info=False;User ID=Admin;Password=admin101;Initial Catalog=SchoolMain;Data Source=192.168.1.2,1433"
Both are connecting to a SQL Server database instance on the same system. The first connects using the database instance name, while second connects using IP address (over the internet to the system) and port number.
The query with ConnectString1 is very first, takes less than 2 seconds to execute while query using ConnectString2 is extremely very slow and most times comes back with timeout expired error.
I have searched everywhere on the internet and still cannot find where the issue is. I read about turning off the LLMNR protocol and adding entries in the hosts file to tackle Reverse DNS, followed the steps but it's still the same as query with ConnectString2 is still very slow.
Though when I changed the IP address in ConnectString2 from 192.168.1.2 to 127.0.0.1, the query works very fast, just exactly as it is with ConnectString1.
Is there a way to route all IP address to 127.0.0.1 on the machine?
I need ConnectString2 to work query will be pushed over the IP address from other systems outside the LAN.
Note: I am using SQL Server 2008
Please help.
The main reason this may happen is reverse DNS, meaning the sql needs to translate the IP to a physical address and it takes time.
To fix this problem use your host file to add the address to your machine and than use the name given at the host file instead of the IP.
If you do not want to temper with the host file try to look at the alternate solution to enable the TCP/IP which is disabled by default.
Related
I configured my sql server to listen on ip:192.168.1.2 but since my machine get IP from DHCP may my last IP be differ from previous one on next start up.
in this situation when sql service wants to start, it cant find previous IP and cant start.
I would like to know ,is there a solution as SQL update itself IPs automatically?or I have to update IPs manually on every start up?
as I saw, when I changed my IPs and restart machine or SQL service it doesn't Modify Ip.
Thanks
Perhaps you may try Named Pipe?
http://devproconnections.com/database-development/sql-server-performance-tip-favoring-tcpip-over-named-pipes
Are your system hard-coded the IP address and not allowed to be change?
I have a local SQL Server DB on my domain-attached machine to which I'm trying to connect via a WPF app. The original connstring was:
Server=MyMachine.MyDomain.local;Database=MyDomain;Trusted_Connection=True
That resulted in a failed connection (could connect via SSMS just fine), access is denied. When I changed the connstring to:
Server=MyMachine;Database=MyDomain;Trusted_Connection=True
everything connected properly. Any thoughts as to why? It's not a big deal, as it's a test db, but I'd like to understand.
It's a guess, but I'd bet that name resolution is failing. Somehow the dns lookup is failing, but the short name works because it tries a netbios lookup instead of a dns lookup. It likely also works if you put in the server IP address.
I finally found the problem: protocol TCP/IP was disabled, so it appears that calling it via MyMachine.MyDomain.local was trying to use the TCP/IP protocol, even though it was on my local machine.
Say I have SQL Server installed on a server with an IP of 10.1.2.3. If I have a process running on that server that wishes to connect to the db it can use either:
10.1.2.3,1433
localhost,1433
machinename,1433
The third option will incur slightly more overhead because it needs to lookup DNS each time correct? But what of the other two options? For all intents and purposes are they identical?
Obviously IPs can change, but localhost is always localhost so that is a benefit for that option, but on the other hand IP can be used from any machine within the network, localhost only on the server itself so that's a benefit for using IP. But I'm solely concerned with speed/performance/reliability/overhead, etc
For speed, your best bet is an IP, since it avoid a name lookup. There may be a reverse lookup on the server side of the connection, though. When using 'localhost', you are (likely) actually going to 127.0.0.1, not the external IP (or you should be, anyway, and if you're not something's not right). The advantage there is that you can change the external IP of the machine without having to change your connection string and things should still work.
I need to have an Access front end and SQL 2005 back end for a client. I would like to require them to have a static IP and I'll open a port for that IP. But they also want to be mobile, so their IP will change when they aren't in their office.
Is there another way to secure the connection?
Thanks.
I much don't see any problem or issue with this question. As a note, one could keep in mind with your requested setup the IP address of the mobile devices does not and should not matter.
What matters for the most part is that device can connect to the IP address of the SQL server in question (and that address is not likely to change – or at least not change often).
so their IP will change when they aren't in their office.
This question makes more sense. The internal IP address you use to connect to SQL server can be an unc path name to the server (with SQL on it). However, often just using the IP address of the server on your local network also works. So a typical address would be 192.168.1.100.
So, your Access front end can thus link to the above IP address (I assume you have some SQL re-link code on startup).
When you step outside of the office and that local network, then of course you have several choices.
You could as you suggest open up a port on the SQL serving to allow incoming connections. This is likely not such a great idea. It likely better to setup some type of VPN from that device back to your office network. Once you have that VPN connection setup, then the front end that linked to the fixed internal ip address should continue to work (and you can use the SAME internal address).
However, without a VPN, then you can certainly have the Access front end "re-link" to the external exposed IP address of your office network. This would require that you open a port and forward a port on your router to the machine running SQL server. And you would have to open the default port for sql server. The default is 1433 – but as noted, it is NOT such a great idea to open up your SQL server to the wild internet. Last time I did this, within a FEW minutes there was automated "bots" on the internet already attempting to logon (and the robot was testing all of the most common sql logons + most common passwords). So, this is high risk adventure to open up sql server ports this way.
So, the best approach here is some type of SSL tunnel, or a VPN to your office network, and the bonus part is you likely NOT have to re-link the front end to a different IP address since once that "tunnel" is setup to your office, then the result of the network setup, including the use of printers etc. from your laptop should thus work with any place you connect to the internet.
Suppose the following:
I have a database set up on database.mywebsite.com, which resolves to IP 111.111.1.1, running from a local DNS server on our network.
I have countless ASP, ASP.NET and WinForms applications that use a connection string utilising database.mywebsite.com as the server name, all running from the internal network.
Then the box running the database dies, and I switch over to a new box with an IP of 222.222.2.2.
So, I update the DNS for database.mywebsite.com to point to 222.222.2.2.
Will all the applications and computers running them have cached the old resolved IP address?
I'm assuming they will have.
Any suggestions along the lines of "don't have your IP change each time you switch box" are not too welcome as I cannot control this aspect of the situation, unfortunately. We are currently using the machine name of the box, which changes every time it dies and all apps etc. have to be updated with the new machine name. It hurts.
Even if the DNS is not cached local to the machine, it will likely be cached somewhere along the DNS chain between the machine and the name servers, at least for a short while. My understanding is this situation would usually be handled with IP takeover where you just make the new machine 111.111.1.1.
Probably a question for serverfault.
You're looking for DNS TTL (Time To Live) I guess.. In my opinion applications may cache the IP for at most the value of the TTL. I'm afraid however that some applications/technologies might actually cache it longer (agian in my opinion completely wrong)
Each machine will cache the ip address.
The length of time it is cached is the TTL (Time To Live). This is a setting on your DNS server, if you set it very low say 5 mins, then you show be up and running fairly quikly. A bit of a hack but it should work.
Yes, the other comments are correct in that what controls this is the DNS TTL set for the hostname database.mywebsite.com.
You'll have to decide what the maximum amount of time you're willing to wait for if you have a failure on your primary address (111.111.1.1) after you make the switch to the secondary address. Lower settings will give you a quicker recovery time, but will also increase the load and bandwidth to your DNS server because clients will have to re-query it to refresh their cache more often.
You can use nslookup using the -d option from your cmd prompt to see what your default TTL times and remaining TTL times are for the DNS server you are querying.
%> nslookup -d google.com
You should assume that they are cashed for two reasons not clearly mentioned before:
1- Many "modern" versions of OS families do DNS caching.
2- Many applications do DNS caching or have poor error/failure detection on live connections and/or opening new connections. This would possibly include your database client.
Also, this is probably not well documented. I did some googling, and found this for MySQL:
http://dev.mysql.com/doc/refman/5.0/en/connector-net-programming-connecting-connection-string.html#connector-net-programming-connecting-errors
It does not clearly explain its behavior in this regard.
I had a similar issue with a web site that disables the application pool recycling features and runs for weeks on end. Sometimes, a clustered SQL Server box would restart and for some reason, my SqlConnection's were not reconnecting. I was getting the error:
A network-related or instance-specific
error occurred while establishing a
connection to SQL Server. The server
was not found or was not accessible.
Verify that the instance name is
correct and that SQL Server is
configured to allow remote
connections. (provider: Named Pipes
Provider, error: 40 - Could not open a
connection to SQL Server)
The server was there - and running - in fact, if I just recycled the app pool, the app would work fine - but I don't like recycling app pools!
The connections that were being held in the connection pool were somehow using old connection information, and that could have been old IP addresses. This is what seems so similar to the poster's question, that it appears to be cached DNS information, because as soon as some sort of a cache is cleared, the app works fine.
This is how I solved it - by forcing all of the connections in the pool to be re-created:
Try
' Example: SqlDependency, but this could also be any SqlConnection.Open call
Dim result As Boolean = SqlClient.SqlDependency.Start(ConnStr)
Catch sqlex As SqlClient.SqlException
SqlClient.SqlConnection.ClearAllPools()
End Try
The code sample is just the boiled-down basics - it should be tweaked for your situation!
The DNS gets cached, but for any server that resolves to the wrong ip address, you can update the HOSTS file of the server and the ip should be updated immediately. This could be a solution if you have a limited amount of servers accessing your database server.