Hallo JMP-Benutzer. Bei Verwendung des JMP Query Builder haben wir eine schnelle Antwort für SQL-Server, die „ODBC-Treiber 11 für SQL Server“ verwenden, aber eine langsame Antwort auf einigen Oracle-Servern, die „Oracle in OraClient11g“ verwenden, in der Größenordnung von 2 bis 3 Minuten.Wir haben durch Zufall festgestellt, dass es mit dem benutzerdefinierten SQL()-Argument in der New SQL Query()-Funktion im Skript problemlos funktioniert, anstatt das generierte Skript von JMP Query Builder zu verwenden.
Hat jemand anderes eine langsame Antwort von Oracle ODBC gesehen?
Ein Teil des Problems, wie ich es verstehe, ist, dass unser Anmeldekonto für diese Oracle-Datenbank das Anzeigen einiger Tabellen in einigen Schemas auf dem Server nicht zulässt, sodass der Abfragegenerator beim ersten Laden Zeit braucht, um sie zu umgehen. Sie können möglicherweise nicht replizieren, wenn Ihr Datenbankzugriff alle Schemata und Tabellen umfasst. Das Senden von direktem benutzerdefiniertem SQL umgeht dieses Scannen der Schemas und Tabellen?
Im folgenden Beispiel werden mithilfe des Abfragegenerators ausgewählte Spalten und ein Filter verwendet. Es dauerte 147 Sekunden, um eine Million Zeilen zu durchlaufen. Wählen Sie nun im Abfrage-Generator das SQL auf der Registerkarte „SQL“ aus oder verwenden Sie das Menüelement „In benutzerdefiniertes SQL konvertieren“ und kopieren Sie das benutzerdefinierte SQL (oder führen Sie die Abfrage im Fenster „Benutzerdefiniertes SQL“ aus) und fügen Sie es als Argument für „Benutzerdefiniert“ ein SQL(), und es dauerte nur 7 bis 8 Sekunden für eine Million Zeilen.
// 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
Für unsere Best Practices für den JMP-Abfragegenerator müssen Sie nun zeigen, wie Sie die Abfrage und die Datentabelle aus dem Fenster „Benutzerdefiniertes SQL“ für Oracle-Datenbanken ausführen und speichern.
Danke für die Leistungsdaten. Es scheint, Sie haben eine Lösung.
Es wird interessant sein zu sehen, ob JMP ein paar Erkenntnisse oder Vorschläge zu teilen hat.
Danke für diese Tipps! Habe noch ein paar Tests gemacht.
Ich sehe die Wirkung eines zweiten Aufrufs der Oracle-Datenbank, sehe aber immer noch den Größenordnungsunterschied zwischen den beiden JSL-Techniken. Ich muss mich nur von JMP14 abmelden, um dies zu testen. Wenn ich den Test auf dem langsamen Schema ausführe, dauert Custom SQL() beim ersten Mal 0,4 Sekunden. Wenn ich das Custom SQL()-Skript innerhalb der aktuellen Sitzung von JMP wiederhole, wird es auf 0,06 Sekunden reduziert.Dies hilft jedoch nicht für den Standardcode des Abfragegenerators, es dauert 120 Sekunden, egal was passiert. Ich glaube, die Änderung von 0,4 auf 0,06 zwischen dem 1. und 2. Aufruf der Oracle-Datenbank, wenn sie für das langsame Schema auftritt, liegt im Rauschen der Wiederholungstests immer bei etwa 120 Sekunden.
Ich habe auch ein "schnelles" Schema getestet. Die erste Ausführung von benutzerdefiniertem SQL dauert ebenfalls ~0,4 Sekunden und wird dann für nachfolgende Aufrufe in einer aktiven Sitzung auf 0,06 Sekunden reduziert. Bei standardmäßigem Query Builder-Code beträgt der erste Aufruf 1,2 s, nachfolgende Aufrufe in einer aktiven JMP-Sitzung werden auf 0,8 s reduziert.
Aus diesen Tests ergibt sich eine Reduzierung von ~0,3 Sekunden für einen wiederholten Aufruf an die Oracle-Datenbank, da sie eine letzte Abfrage unabhängig vom Schema für Custom SQL() zurückruft, sie jedoch nicht im "langsamen" Schema mit dem Query Builder-Skript sieht Stil.
Hier mögen wir die Open Database/Close Database-Methode nicht (besorgt darüber, dass eine Datenbank offen bleibt), wir bevorzugen die Verwendung des Query Builder, aber wir müssen die Custom SQL()-Methode verwenden und den SQL-Code aus dem Query Builder erfassen Benutzeroberfläche.
Hier nur ein paar Erfahrungsberichte:
- Oracle erinnert sich an eine letzte Abfrage, daher ist der zweite Aufruf oft schneller als der erste. Um dies zu testen, schließen Sie Ihre Verbindung und melden Sie sich von Ihrem System ab (damit Sie eine neue Systembenutzer-ID haben) und führen Sie es dann aus nur Ihre zweite Abfrage und erhalten Sie die Leistungszeit. Überprüfen Sie, ob es weniger, näher an 8 Sekunden oder viel größer oder nahe 147 Sekunden ist.
- JMP-Experten müssen überprüfen, was wirklich vor sich geht, aber es hört sich so an, als hätte JMP die Tabelle erstellt und dann die Abfrageanweisungen in der ersten neuen SQL-Abfrage() ausgeführt. Und möglicherweise die zweite New SQL Query(), JMP sendet einfach die SQL-Anweisung an die Datenbank und gibt die Ergebnisse zurück.
- Wenn ich dieselbe oder eine ähnliche Abfrage an verschiedenen Tagen ausführe, verwende ich gerne den Abfragegenerator, um die Abfrage zu erstellen und zu testen.Dann bekomme ich das SQL und schreibe mein Skript, um Open Database ( "Verbindungszeichenfolge", "Abfragezeichenfolge", "Tabellenname");
Viel Glück!
