we're comparing JTDS and Microsoft SQL Server for a Java EE application running on JBoss and we're finding that JTDS is from 30% to 50% faster, benchmarking the application in a high concurrence scenario and keeping exactly the same HW/SW but changing only the driver in the datasource configuration.
While we've seen a lot of favorable options towards JTDS and so we're thinking to go for it I'm still curious:
Why is the JTDS driver so much faster?
Why Microsoft never updated its driver to be fast as JTDS?
Comparison was made using the latest JDBC 3.0 version and the latest JTDS version and using a SQL Server 2008 running on a 16 core installation with dedicated SAN.
I've done similar performance comparisons, with similar results.
There are many potential reasons for performance differences. Some of them are visible in the T-SQL generated by the driver, which you can see with SQL Profiler. Other aspects are more subtle, such as connection management and how the underlying protocol (TDS) is implemented.
I can't say for sure why MS has never updated their driver, but I suspect that part of it is because Java is considered to be a competitive product/platform.
Related
I note that the full version of Windows 10 can be run on a RPI 3.
I wondered whether SQL Server Express (or any other edition) is available for the ARM version of Windows. I can’t see it anywhere so I suspect the answer is ‘no’ but want to check I have my missed a trick anywhere.
Effectively I am testing out working with a large SQL Server database. I don’t want my test code to touch the actual site, so my plan was to run a minimal example with some test records locally on my desk. I have an old Atom-based machine I can use - but the RPi is a much more convenient in terms of having a ‘portable’ demo server.
I am aware any such setup will perform awfully - performance not an issue for the demo.
There are two questions here :
Is there a SQL Server version that runs on ARM?
According to the Operating System requirements no. SQL Server is only available for Windows IoT Enterprise, essentially a Windows 10 Enterprise version with special licensing. It's the evolution of Windows Embedded and only meant for OEMs that produce 1000s of devices.
And the real question
I don’t want my test code to touch the actual site, so my plan was to run a minimal example
In that case you can use Windows 10 containers, a VM or a managed cloud version of SQL Server. SQL Server docker images are available for the Express and Developer edition.
No, in contrast with .net, powershell and other initiatives, up to this point there is no ARM version of SQL Server. And by knowing how existing version was ported, we hardly can expect that it will appear soon on this platform.
I have "inherited" a computer that has multiple ODBC driver's installed on it. Before I go removing anything, how do I tell which driver SQL Server is actually using? Does it just use the most updated one?
I am running SQL Server 2014, version 12.0.5207.0 (64 bit). I am also using SQL Server Management Studio 2017, version 17.5.
Additional question - I am planning to update the ODBC driver to 13.1, would I install the 64 bit since the server is 64 bit? When I look at the ODBC data sources the drivers are installed in both the 32-bit and 64-bit dialogues, so I am a bit confused. Total noob question, I realize, but I am very new to this.
That's not an easy answer. Let's break it into parts.
What driver is being used? The one the application requests. A driver is used by a client application to connect to the server, and the client application is the one that has the final say. You can look at the ODBC data sources configured in the machine to see the driver, but an application might not use an ODBC data source and instead embed the driver name into the application or some configuration file.
How can you tell? One way is to uninstall a driver and see what breaks. Usually not a good plan. Maybe you can use Process Monitor and check if any process load the drivers, but not Always feasible. If in doubt, leave the drivers alone. They are usually small and don't tend to cause trouble on their own.
As for SQL Server database engine and SQL Server Management Studio (SSMS), they normally don't use ODBC drivers. SSMS uses a .NET provider to connect to SQL Server. SQL Server database engine can use an ODBC driver if you have a linked server to another server.
If this is a database server and not an application server, chances are most drivers are rarelly used. If this is an application server, I'd leave the drivers alone. If it's a workstation, probably leave them alone too.
As for the new driver version, you need the 64-bit package to install, and it will install both 32 and 64-bit drivers. The reason is a 32-bit need a 32-bit driver, and a 64-bit application need a 64-bit driver. It's not the server bitness that matter in this case.
I'm trying to determine whether DNN 2.0.4 will be compatible with SQL Server 2005 SP4. My company is upgrading their server framework and they're trying to determine (without testing obviously...) if the SQL upgrade will blow up some of their older DNN sites.
I've trolled the boards, liberally dusted with Google magic and even skimmed through the super user manual. The nearest I've been able to get to an answer is that the latest version REQUIRES SQL Server 2005 but there's no indication that it will work with the older DNN.
Anybody out there have any concrete experience I can fall back on?
Because of the large installed base and wide variety of environments, the DNN core team has focused on using very standard SQL and I think if there was any problem, your searching would have turned something up.
Also, I'm not aware of any breaking changes or features in SQL Server 2000 that were removed in SQL Server 2005.
You should be fine. If you do run into a problem it's much more likely to be with a 3rd party module rather than the core. Some 3rd party modules were much quicker to begin to use the new capabilities of SQL Server 2005 and in general are less likely to follow standards or be tested as extensively in a wide variety of environments.
I am running 2.1.2 on SQL Server 2005 without issues. I think that the same would be true of 2.0.4.
I understand that some databases have native support in R (e.g. MySQL) but you can connect to other DBs like MS SQL Server using RODBC. How much speed improvement does one gain for reading/writing with the native drivers vs. RODBC? What other DBs have native drivers in R? Is reading faster or slower than writing generally?
If you're specifically interested in SQL Server, the reference below is a little bit out of date but I imagine it probably still holds.
Using ODBC with Microsoft SQL Server
Performance of ODBC as a Native API
One of the persistent rumors about ODBC is that it is inherently slower than a native DBMS API. This reasoning is based on the assumption that ODBC drivers must be implemented as an extra layer over a native DBMS API, translating the ODBC statements coming from the application into the native DBMS API functions and SQL syntax. This translation effort adds extra processing compared with having the application call directly to the native API. This assumption is true for some ODBC drivers implemented over a native DBMS API, but the Microsoft SQL Server ODBC driver is not implemented this way.
The Microsoft SQL Server ODBC driver is a functional replacement of DB-Library. The SQL Server ODBC driver works with the underlying Net-Libraries in exactly the same manner as the DB-Library DLL. The Microsoft SQL Server ODBC driver has no dependence on the DB-Library DLL, and the driver will function correctly if DB-Library is not even present on the client.
Microsoft's testing has shown that the performance of ODBC-based and DB-Library–based SQL Server applications is roughly equal.
It's an empirical question, so why don't measure it for the combination you are interested in?
Public code is not hidden, so why don't you count what other DB interfaces CRAN has? For DBI alone, we have SQLite, MySQL, Postgresql, Oracle; for custom db backends there are things like Vhayu.
Specialised forums exist, so why don't you ask on r-sig-db?
Lastly, as soon as there is an API and a need people tend to combine the two. I have written two different (at-work and hence unreleased) packages to two highly specialised and fast backends.
I have only just found out about DB2 Express. I had a quick look and was unable to find a load of information about it but would be interested in hearing how people have found it compared to SQL Server Express (particularly 2008) in terms of
Ease of deployment
Ease of use and development tools
Limitations such as size or CPU limits
Integration with .NET and other third party tools like nHibernate
DB2 Express is not free, DB2 Express-C (as Troels pointed out), is free to use. DB2 Express-C is cross-platform, and would probably be faster than PostgreSQL for mid-sized enterprise applications. DB2 is generally a little cheaper than Oracle as well, so if you needed to upgrade, DB2 might be a decent option.
I'd recommend DB2 Express-C if you need cross-platform enterprise scalable applications with solid enterprise grade management tools. That said, your question was how it compared against SQL Server Express ... so here are specific answers to those questions:
DB2 Express is easier to deploy than Oracle, more difficult than MS SQL.
For whatever reason, I've always dropped into SQL DDL statements (CREATE/ALTER TABLE, etc.) with DB2 and Oracle instead of using their Admin tools, while SQL Server Management Studio (even the free version) seem easy/fast enough to warrant using. This might just be me though
Currently DB2 Express-C has a 4 core (2 CPU), 2 GB limit, with no database size limit (more info). These limits are far better than MSSQL Express's (1 CPU, but no core limit, 1GB RAM, and 4GB database size)
Not surprisingly, SQL Server Express integrates much better with .NET applications (assuming you're using Visual Studio). However, DB2 generally works better with Java than SQL Server
I hope this helps!
I assume that you are talking about the Express-C edition of DB2 (which is not the samme as DB2 Express).
1,2: If you are generally working on a Windows platform (dev tools, backend+frontend, ...), you will find MSSQL easier to deploy and use. And in general, MSSQL is probably a bit easier to deploy than DB2.
3: Among the free offerings from the "big three" vendors, DB2 Express-C has the least restrictions.