Hola usuarios de JMP. Cuando usamos JMP Query Builder, tenemos una respuesta rápida para los servidores SQL que usan "ODBC Driver 11 para SQL Server", pero una respuesta lenta en algunos servidores Oracle que usan "Oracle en OraClient11g", en el orden de 2 a 3 minutos. Descubrimos por accidente que funciona bien usando el argumento SQL personalizado () en la función Nueva consulta SQL () del script, en lugar de usar el script generado desde el Generador de consultas JMP.
¿Alguien más ha visto una respuesta lenta de Oracle ODBC?
Como entiendo, parte del problema es que nuestra cuenta de inicio de sesión para esta base de datos de Oracle no permite ver algunas tablas en algunos esquemas en el servidor, por lo que el generador de consultas toma tiempo la primera vez que las carga para evitarlas. Es posible que no pueda replicar si el acceso a su base de datos incluye todos los esquemas y tablas. El envío directo de SQL personalizado omite esta exploración de esquemas y tablas?
En el siguiente ejemplo, utilizando el Generador de consultas, las columnas seleccionadas y un filtro. Tomó 147 segundos para correr por un millón de filas. Ahora desde Query Builder, seleccione el SQL en la pestaña SQL, o use el elemento de menú "Convertir a SQL personalizado" y copie el SQL personalizado (o ejecute la consulta desde la ventana del SQL personalizado), y péguelo como argumento para el Custom SQL (), y solo tomó de 7 a 8 segundos para un millón de filas.
// this is the JSL script generated by JMP Query Builder and saved to the datatable
// takes ~ 147 seconds to run
t1 = Tick Seconds();
New SQL Query(
Version( 130 ),
Connection(mycon),
QueryName( "Test1_147s" ),
Select(
Column( "X1", "t1" ),
Column( "X2", "t1" ),
Column( "X3", "t1" ),
Column( "X4", "t1" ),
Column(
"LAST_UPDATE_DATE",
"t1",
Numeric Format( "m/d/y h:m:s", "0", "NO", "" )
)
),
From( Table( "MY_DATABASE_TABLE", Schema( "SCHEMA" ), Alias( "t1" ) ) ),
Where(EQ(Column( "X2", "t1" ),"AAAA",UI( Comparison( Base( "Categorical" ) ) )))
) << Run foreground;
t2 = Tick Seconds();
t2-t1; // 147 seconds
// Now just copy the SQL code and put into the CustomSQL argument
// takes ~ 8 seconds to run
t1 = Tick Seconds();
New SQL Query(
Connection(mycon),
QueryName( "Test2_8s" ),
CustomSQL(
"SELECT t1.X1, t1.X2, t1.X3, t1.X4,
t1.LAST_UPDATE_DATE
FROM SCHEMA.MY_DATABASE_TABLE t1
WHERE ( ( ( t1.X2 = 'AAAA' ) ) )"
)
) << Run foreground;
t2 = Tick Seconds();
t2-t1; // 8 seconds
Para nuestras mejores prácticas de JMP Query Builder, ahora tendremos que mostrar cómo ejecutar y guardar la consulta y datos de la ventana de SQL personalizado para las bases de datos Oracle.
Gracias por los datos de rendimiento. Parece que tienes una solución.
Será interesante ver si JMP tiene algunas ideas o sugerencias para compartir.
Gracias por esos consejos! Hizo algunas pruebas más.
Veo el efecto de una segunda llamada a la base de datos Oracle, pero sigo viendo el orden de la diferencia de magnitud entre las dos técnicas JSL. Solo tengo que cerrar sesión en JMP14 para probar esto. Si ejecuto la prueba en el esquema lento, la primera vez que Custom SQL () toma 0.4 segundos. Si repito las ejecuciones del script Custom SQL () dentro de la sesión actual de JMP, se reduce a 0.06 segundos. Pero esto no ayuda para el código estándar de Query Builder, toma 120 segundos sin importar qué. Creo que el cambio de 0,4 a 0,06 entre la 1ª y la 2ª llamada a la base de datos de Oracle, si sucede para el esquema lento, está en el ruido de las pruebas de repetición siempre alrededor de 120 segundos.
También probé un esquema "rápido". La primera ejecución de SQL personalizada también es ~ 0.4s, luego se reduce a 0.06 segundos para las llamadas subsiguientes en la sesión activa. Para el código estándar de Query Builder, la primera llamada es de 1.2s, las llamadas subsiguientes en la sesión activa de JMP se reducen a 0.8s.
A partir de estas pruebas, se observa una reducción de ~ 0.3s para una llamada repetida a la base de datos de Oracle porque recuerda una última consulta sin importar el esquema para SQL personalizado (), pero no lo ve en el esquema "lento" usando el script Query Builder estilo.
Aquí no nos gusta el método Abrir base de datos / Cerrar base de datos (preocupado por colgar una base de datos abierta), preferimos usar el Generador de consultas, pero tendremos que usar el método SQL personalizado () y capturar el código SQL del Generador de consultas interfaz de usuario.
Esto es solo un par de comentarios de la experiencia:
- Oracle recuerda una última consulta, por lo que a menudo la segunda llamada es más rápida que la primera. Para probar esto, cierre su conexión y cierre la sesión en su sistema (para que tenga un nuevo ID de usuario del sistema), luego ejecute solamente Su segunda consulta y obtener el tiempo de rendimiento. Compruebe si está menos cerca de 8 segundos o mucho más grande o cerca de 147 segundos.
- Los expertos en JMP tendrán que verificar lo que realmente está sucediendo, pero parece que JMP podría haber construido la tabla y luego ejecutó las declaraciones de consulta en la primera Nueva Consulta SQL (). Y posiblemente la segunda nueva consulta de SQL (), JMP simplemente envía la declaración de SQL a la base de datos y devuelve los resultados.
- Cuando ejecuto la misma consulta o una similar en días diferentes, me gusta usar el Generador de consultas para generar y probar la consulta. Luego obtengo el SQL y escribo mi script para usar Open Database ("cadena de conexión", "cadena de consulta", "nombre de tabla");
¡Buena suerte!
