I am aware of "SQL Server Profiler", But is there any tools or methods available to monitor the issued sql queries from the client machine?
Some of the things currently in my mind are:
1) The SysInternals ProcMon can log and tell when the executable process on client machine connects to sql server. Any similar but more advanced tools available to tell more data?
2) Any debug version or instrumented version of client libraries and APIs available for client machine to allow such operation?
You can enable ODBC Tracing from the ODBC Data Source Administrator (odbcad32.exe). The log file it generates is rather cryptic but it will provide you with the SQL statements run by the logged in user on that machine. There is also a checkbox labeled "Machine-Wide tracing for all user identities" for logging all SQL statements run by any user - including services - on that machine.
Logging may not start until you disconnect and reconnect to the SQL server. So, it is a good idea to restart whatever programs/services connect to your SQL Server. This is especially important if you have connection pooling enabled, which will keep connections open even if the program, in question, has disconnected.
Also, there are two versions of the ODBC Data Source Administrator on Windows 64bit, one for 32bit and the other for 64bit. So, you will need to enable logging for the appropriate bitness of the program you are tracing.
How To Generate an ODBC Trace with ODBC Data Source Administrator
Setting Tracing Options
Why my 32 bit applications cannot see the ODBC DSNs that I created on my 64 bit machine ?
ODBC Administrator tool displays both the 32-bit and the 64-bit user DSNs in a 64-bit version of Windows
Update: Another option for you would be to use a tool like Wireshark. Since it has the ability to sit at the network driver level, it can intercept all your network traffic - including but not limited to SQL. These are known as TDS packets - a standard that is used by Sybase SQL Server (ASE), Microsoft SQL Server and FreeTDS ( w/ UnixODBC).
RPR NA03: Analysing SQL Server performance using Wireshark and Excel
How do I filter SQL Server traffic between app and DB servers using Wireshark?
How can I decode SQL Server traffic with wireshark?
What does my SQL Server data look like over the wire?
Google Search for "Wireshark+SQL"
Related
I've scoured the internet and apparently in the Linux version of SQL Server 2019 linked servers are only allowed between 1 SQL Server to another SQL Server. I need to create a linked server from linux SQL Server 2019 to postgresql 4.17 so I can query tables that are in PostgreSQL from SQL Server.
I have ODBC drivers installed on my Windows machine that can connect and I have the odbc drivers installed on my ubuntu server that hosts SQL Server 2019. I can also connect and pull data and run queries from SSIS. OPENQUERY, OPENDATASOURCE and OPENROWSET do not work either.
I can't believe this is not possible. Any suggestions or ideas on how to do this or the closest best possible solution would be greatly appreciated.
Edit
Linux version of SQL Server 2019 only supports linked server connections to other SQL Servers.
https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-editions-and-components-2019?view=sql-server-linux-2017
I suggest looking at other ways for importing data, like BCP and SSIS, unfortunately.
End of edit
Your statement: "apparently in the Linux version of SQL Server 2019 linked servers are only allowed between 1 SQL Server to another SQL Server." Could you perhaps link to where that is stated in the Microsoft documents?
In the release notes for SQL Server 2019 on Linux I see mention of linked servers (with no statement that you can only connect to other SQL Servers).
Is there an error message you are receiving, or could you give us some more information on what steps you have taken and troubleshooting you've done? There are some configurations needed to insure communication on linux, according to the docs:
Features that involve outbound TCP connections from the sqlservr
process, such as linked servers or Availability Groups, might not work
if both the following conditions are met:
The target server is specified as a hostname and not an IP address.
The source instance has IPv6 disabled in the kernel. To verify if your
system has IPv6 enabled in the kernel, all the following tests must
pass:
cat /proc/cmdline will print the boot cmdline of the current kernel.
The output must not contain ipv6.disable=1.
The /proc/sys/net/ipv6/ directory must exist.
A C program that calls socket(AF_INET6,
SOCK_STREAM, IPPROTO_IP) should succeed - the syscall must return an
fd != -1 and not fail with EAFNOSUPPORT. The exact error depends on
the feature. For linked servers, this manifests as a login timeout
error. For Availability Groups, the ALTER AVAILABILITY GROUP JOIN DDL
on the secondary will fail after 5 minutes with a download
configuration timeout error.
To work around this issue, do one of the following:
Use IPs instead of hostnames to specify the target of the TCP
connection.
Enable IPv6 in the kernel by removing ipv6.disable=1 from the boot
cmdline. The way to do this depends on the Linux distribution and the
bootloader, such as grub. If you do want IPv6 to be disabled, you can
still disable it by setting net.ipv6.conf.all.disable_ipv6 = 1 in the
sysctl configuration (for example, /etc/sysctl.conf). This will still
prevent the system's network adapter from getting an IPv6 address, but
allow the sqlservr features to work.
I am trying to create / modify a system data source for my application which needs to connect to our Microsoft SQL Express 2014 database through an ODBC data source.
The connection used to work before we enabled the SSL encryption flow but,
now that we have an encrypted link, the connection does not work anymore.
Here are some details:
We run Microsoft SQL Server express 2014 SP1 with the latest cumulative update (CU #3) (which was necessary so that we could deactivate SSL 3.0 and TLS 1.0 and run only with TLS 1.1 and TLS 1.2)
The database instance is a named instance, configured to run with a TCP/IP connection and a fixed port.
We enabled the "Force Encryption" option and configured the certificate through the "Sql Server Configuration Manager"
We can successfully establish a connection to the database either using Management Studio or the SQL command line utility
We disabled all usage of SSL/TLS prior to version TLS 1.1 done through Microsoft Schannel. This required us to update SQL Express 2014 SP1 to the latest cumulative update (CU #3)
The ODBC data source we try to configure (through ODBC data source Administrator) is a "System DSN" and uses the "SQL server" driver and target the exact same server name as the one working in management studio (and whose server name corresponds to the machine FQDN which is reflected in the certificate CN value)
The Version indicated for the SQL Server ODBC driver is "Microsoft SQL Server ODBC Driver Version 06.03.9600"
I am testing the connection directly through the ODBC data source Administrator tool.
The first test I runs are run on the exact same machine as the one hosting the database server.
We get two consecutive error message in the Microsoft SQL Server Login:
Connection failed:
SQLState : '01000'
SQL Server Error: 771
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]ConnectionOpen(SECDoClientHandshake()).
Connection failed:
SQLState : '08001'
SQL Server Error: 18
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SSL Security error.
I went through all the literature I could find but cannot find a solution.
EDIT 27/01/2016 16:30
Following erg suggestion, I tried to use the last MS SQL Server Native Client version (11.00.2100 on my system), but it still does not resolve the issue. I experience another issue though (whether or not I force the strong encryption on the client side results in the same error):
Running connectivity tests...
Attempting connection
[Microsoft][SQL Server Native Client 11.0]TCP Provider: An existing connection was forcibly closed by the remote host.
[Microsoft][SQL Server Native Client 11.0]Client unable to establish connection
TESTS FAILED!
So, I finally got it working after struggling a little bit more.
First of all, it appears that there is another CU available (CU4) for SQL Server Express 2014 SP1.
I did download it and install it, but it did not resolve my problem: as soon as I deactivated TLS 1.0 and below version ODBC did not work.
Strangely, though the CU3 and installation of .NET 4.6 allowed me to successfully log in in Management Studio, when I tried to execute
the xp_readerrorlog query, it actually failed.
What I did to solve my issue was to follow malthus's answer on another related stack overflow question
https://dba.stackexchange.com/questions/93127/sql-server-service-won-t-start-after-disabling-tls-1-0-and-ssl-3-0 (3rd answer from the top).
I therefore activated the local security policy on my computer and managed to get the links to my SQL db working.
Now, I got IIS working along my own service and client working.
BTW, if somebody needs a more user friendly way of activating SSL/TLS version(s) and cryptographic algorithms on Windows, I stumbled uppon a nice GUI application which does not required to use regedit for it:
https://www.nartac.com/Products/IISCrypto. It's free and I am not a a Nartac Software employee, manager or shareholder.
I hope this will help!
EDIT Feb 25, 2016
It looks like the latest cumulative update (CU5 available at
https://support.microsoft.com/en-us/kb/3130926) removes the need to
activate the FIPS option for the System Cryptography.
I discovered this since I had to deactivate FIPS to enable another required
functionnality while still relying on a TLS 1.2 connection. Indeed, it
appears that activating the FIPS option for the System Cryptography prevents
.NET Framework to successfuly make use of some system algorithms (such as
SHA256Managed).
In addition, according to some discussions seen around the web (i.e.
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recommending-fips-mode-anymore.aspx)
it is not recommended to activate FIPS (except to strictly comply with
some governmental recommendations) since it breaks applications
relying on non-FIPS validated implementations of cryptographic
algorithms, which, however are provided in Microsoft system libraries.
I am experiencing extremely slow connections to a local DB2 (v9.7 Express-C) database through ODBC on a Windows 7 system (x64). I wrote several test programs, each connecting to a local database for 100 times in a row (without querying) and measuring the time. Results are:
C++ x86 DB2/ODBC: 32bit C++ application, connecting to a local DB2 database via CDatabase
C++ x86 DB2/ODBC: same as above, but x64 application
PHP DB2/ODBC: Connecting to a local DB2 database via odbc_connect.
PHP MySQL/ODBC: Connecting to a local MySQL database via odbc_connect.
JDBC DB2: Java application, connecting to a local DB2 database using the DB2 JDBC driver.
JDBC MySQL: Java application, connecting to a local MySQL database using the MySQL JDBC driver.
My first thought was that something's wrong with my ODBC configuration, but as you can see connecting to a MySQL database through ODBC works like charm. On the other hand, connecting to DB2 with the JDBC driver instead of ODBC works fine too (although it's still a lot slower than MySQL).
I found this related question, but it does not apply to me.
Any hints on what might be causing this and how to resolve would be great!
Supplementary question: What are common connection times when connecting to a DB2 database through ODBC? Is it normal for the DB2 ODBC driver to be so slow?!
One thing that you should look at is the database activation. DB2 activates the database upon the first connection and deactivates it when the last connection is closed. During activation DB2 allocates transaction log files, memory pools, and performs a number of other tasks that take time.
This behaviour does not depend on the type of connection (ODBC or JDBC); the difference you observe might be explained by an extra connection that keeps the database active during your JDBC tests.
Try issuing ACTIVATE DB <YOURDB> before your tests, which will keep the database active even in the absence of connections. There is no way to activate databases by default, apart from issuing this command upon the system startup, e.g. from a batch file.
We've been experiencing a strange issue with SQL 2008 R2 (10.50.1600) installed as a named instance. In order for any external clients to connect, we have a certain procedure we have to follow, but should not have to. Now I did in fact open the TCP/IP and Named Pipes protocols on the SQL server and restarted it, this isn't the problem. We're on an Active Directory Domain (running from Server 2003). The problem exists no matter what OS the server or client is (XP, 2003, 2008, Vista, 7, 64bit, 32bit, etc.). The problem also persists from anything which can connect, for example, SQL Management Studio, ADO (from our applications), etc.
The problem is that before any client can connect to this server, each client machine must first connect to this server through ODBC (and we don't use ODBC). Any attempt to connect to a 10.5 SQL server before doing this results in "Server does not exist or access denied". But once we can connect in the ODBC (through Named Pipes), then everything else starts to work. The same issue occurs both when using the Computer Name and IP Address. In fact, if we want to connect with computer name \ instance name, then we have to do so first in the ODBC, and then if we want to connect via the IP address \ instance name, then we have to do the same also for that.
We've been having to do this on every single client computer. Again, once the ODBC is able to connect to this SQL server through Named Pipes, then all future attempts from that client work.
What could be causing this to occur? How to avoid it? I should not have to do this "ODBC Trick" as we've been calling it. I've never had this issue on any other version of SQL.
The issue might be related to the SQL Browser service. Each sql instance will have a different port number - try connecting from the client as IP Address,Port (e.g. 123.123.123.1,1433) - this will exclude DNS and Browser from the equation
Edit: now knowing that it is browser related, try see why clients can't access SQL Browser (usually Port 1434). Service not started? Possibly firewall blocking?
Microsoft have tied down everything security wise now by default, so any new configuration now generally requires quite a bit of detailed security planning, policy configuration, permissions etc. Welcome to the age of non-trust ;)
You could easily test your connection by creating a simple file. Follow the steps here at "How to test an SQL Server connection": http://teusje.wordpress.com/2012/02/21/how-to-test-an-sql-server-connection/
Our MS Access application with linked tables to SQL Server 2005 is slow when using Windows Authentication from Windows XP clients.
We've been running it successfully using SQL Server authentication, but now we want to move to Windows Authentication for better security control.
Setup:
Database server: Windows 2003 Server, SQL Server 2005 SP2
Client: Windows XP SP3, SQL Server ODBC driver v2000.85.1132.00
MS Access application: MS Access 2003
Connection string:
DRIVER=SQL Server;SERVER=[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
Only the TCP/IP network protocol is enabled on the server.
The slowness does not happen in these situations:
App on DB server, SQL Server Authentication
App on DB server, Windows Authentication
App on Windows XP client, SQL Server Authentication
SQL Server Management Studio on client, Windows Authentication - I did a small test with running 15 queries in SQL MS. This went fast and did not cause any logon/logoff events in the Security event log on the server.
I've analyzed the slowness using SQL Server Profiler and the event log on the server and it seems to come down to this:
The application runs a query
A new connection to SQL Server is opened (visible in SQL Server Profiler)
The identity of the user is verified (visible in the Security event log on the server, a logon/logoff event happens). This takes several hundreds of milliseconds.
The query runs on SQL Server
Results are returned to Access
This happens for every query. Some of the forms run +- 10 queries when showing a new record (updating sub forms, loading values for combo's etc). This results in very slow performance.
Of course setting up a new connection to SQL Server for every query isn't necessary, and reusing connections might solve the issue. I've been looking around for information on how to make sure Access/ODBC does proper connection pooling. I found these MS KB articles:
Frequently Asked Questions About ODBC Connection Pooling
How to Enable Connection Pooling in an ODBC Application
I've tried calling the SQLSetEnvAttr function from the main form of the Access application, but this didn't improve results.
Any help is greatly appreciated.
The first question I have is: are you running a domain controller? This may sound like a crazy question, but I just want to make sure. Although is less and less common, I've seen organizations run Windows networks with workgroups and "pass-through" authentication. The symptoms you describe are the same as would be observed on a network that is set up in this fashion.
Assuming you do have a proper domain set up, you must have a problem somewhere in the Named Pipes network stack. Named Pipes is the default protocol if you're using Windows authentication. It's not a bad idea to get to the bottom of this if you have the time, but if you just want to fix your performance problem, then I would force the TCP/IP protocol in your connection string:
DRIVER=SQL Server;SERVER=tcp:[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
Note the addition of the tcp: prefix. I got this syntax from Jon Galloway's blog. TCP/IP is the default protocol for SQL Server Authentication. You can also make the protocol switch by disabling Named Pipes support on the server, but this is more of a hassle and could cause other unanticipated problems.
Check Microsoft SQL Server Native Client
at http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc&displaylang=en