Problemas para obtener el controlador JTDS para aceptar sendStringParametersAsUnicode = false?

Question

He estado utilizando net.sourceforge.jtds.jdbc.Driver como mi controlador de MSSQL para todas mis aplicaciones. Tuve problemas con el rendimiento en una declaración preparada y me enteré de que sendStringParametersAsUnicode = false debería solucionar el problema. Desafortunadamente, parece que no consigo que el conductor acepte el valor. Yo puede conseguir la com.microsoft.sqlserver.jdbc.SQLServerDriver controlador de Microsoft para aceptar el parámetro muy bien:

jdbc:sqlserver://servername:1433;databaseName=dbname;sendStringParametersAsUnicode=false 

obras en un persistence.xml, y en mi ds.xml. Las declaraciones preparadas van rápidamente, 100 en 22 segundos.

Sin embargo, parece que no puedo obtener el mismo impulso de rendimiento de JTDS. Todavía cuelga alrededor de la declaración preparada, tomando varios segundos en cada iteración.

He intentado varias variaciones en la cadena, y veo el mismo retraso en mis pruebas (persistence.xml con Hibernate.connection.url) y Server con JTA y ds.xml.

jdbc:jtds:sqlserver://server:1433/dbname;sendStringParametersAsUnicode=false 

jdbc:jtds:sqlserver://server:1433;sendStringParametersAsUnicode=false;databaseName=dbname 

jdbc:jtds:sqlserver://server:1433;sendStringParametersAsUnicode=false;selectMethod=cursor;socketKeepAlive=true;databaseName=dbname 

Todo lo que he leído indica que el controlador de Microsoft es más lento y mi empresa tuvo problemas con él en el pasado. Realmente me gustaría utilizar JTDS si es posible, pero no puedo esperar a una declaración preparada durante 10 segundos.

¿Alguien tenía alguna idea?

Gracias

Answer 1

Los documentation para sendStringParametersAsUnicode estados:

determina si los parámetros de cadena son enviados a la base de datos de SQL Server en Unicode o en la codificación de caracteres por defecto de la base de datos. Esto afecta seriamente el rendimiento de SQL Server 2000 ya que no emite automáticamente los tipos (como 7.0 lo hace), lo que significa que si una columna de índice es Unicode y la cadena se envía usando la codificación de caracteres predeterminada (o viceversa) SQLServer realizará una exploración de índice en lugar de una búsqueda de índice. Para Sybase, determina si las cadenas que no se pueden codificar en el conjunto de caracteres del servidor se envían como cadenas de unicode. Hay un golpe de rendimiento para la lógica de codificación, por lo que establezca esta opción en falso si los tipos de datos unitexto o univarchar no están en uso o si el conjunto de caracteres es utf-8.

Así que si incluirla en su consulta es hacer que su rendimiento es peor , que sugiere que es no apropiados para su consulta, y que se está viendo exactamente los problemas de la documentación advierte acerca.

Si son viendo un aumento de rendimiento en el controlador de MS, es posible que sendStringParametersAsUnicode tiene un significado ligeramente diferente en jTDS que en el controlador de MS.

¿Cuál es el rendimiento de cada controlador con y sin la opción? ¿Qué versión de SQL Server estás usando? ¿Qué muestra su perfil de consultas para estas consultas? ¿Cuál es su consulta y cuáles son los tipos de campos involucrados?