Zugriff aus Oracle via Proc SQL: Performanceprobleme

Transkript

1 News Artikel Foren Projekte Links Über Redscope Join List Random Previous Next Startseite Foren ETL & Base SAS Zugriff aus Oracle via Proc SQL: Performanceprobleme 27 October, :57 FrankRueckert Liebe Gemeinde, ich möchte auf eine Oracle-Datenbank zugreifen und erfahre dabei Performance-Probleme, die ich mir nicht erklären kann: - der Zugriff mittels PL/SQL Developer benötigt für eine (bestimmte) Abfrage "Sekunden" (ca. 10 Sekunde) - die gleich Abfrage dauert mit PROC SQL ca. 30 Minuten! Leider habe ich hierzu keinerlei Erfahrung. Um euch einen Ansatz der Hilfestellung zu geben, nachfolgend zwei unterschiedliche Abfragen, die (natürlich) zu zwei unterschiedlichen Ergebnissen in der Performance und der Ergebnisdaten führen. Dabei ist die erste Abfrage restriktiver, so daß diese Abfrage länger dauert und die Ergebnisdaten weniger Daten enthält. Unter welchen Umständen die Abfrage auf dem Server und wann auf dem Client läuft, weiß ich schon nicht: create table hihi as SELECT ITEM_TYPE, SUBSTAGE, DATE_TIME, MEASUREMENTID, VALUE FROM mydblib.pssd_all WHERE site_id = '05' AND SUBSTAGE ='ABC' AND (MEASUREMENTID='U1' OR MEASUREMENTID='U2c' OR MEASUREMENTID='U3c' OR MEASUREMENTID='U4a' OR MEASUREMENTID='U5a' OR MEASUREMENTID='VIB'); LOG File: NOTE: Table WORK.HIHI created, with 6480 rows and 5 columns. 32 real time 1:09:01.83 cpu time 0.83 seconds

2 create table hihi as SELECT ITEM_TYPE, SUBSTAGE, DATE_TIME, MEASUREMENTID, VALUE FROM mydblib.pssd_all WHERE site_id = '05' AND SUBSTAGE ='ABC'; LOG File: NOTE: Table WORK.HOHO created, with rows and 5 columns. 45 real time 31:39.77 cpu time seconds Foren: ETL & Base SAS in der zweiten Abfrage sollte hier natürlich "table hoho" stehe Habe bei copy & paste nicht aufgepaßt October, :59 FrankRueckert Diagnose stellen mit SASTRACE 27 October, :42 AndreasMangold Um zu sehen, welche Anweisungen tatsächlich in der Datenbank ausgeführt werden, kann man die SASTRACE-Option verwenden und folgende Anweisungen vor PROC SQL abschicken: OPTIONS sastrace=',,,d' sastraceloc=saslog; Es wäre interessant zu sehen, was sastrace zurückgibt. Ergebnis aus dem LOG-File 28 October, :26 FrankRueckert Ich habe den zweiten Aufruf mit der genannte OPTION noch einmal abgeschickt und folgenden LOG-Eintrag erhalten: DEBUG: Open Cursor - CDA= no_name 0 SQL DEBUG: PREPARE SQL statement: no_name 0 SQL SELECT * FROM PSSD_ALL no_name 0 SQL

3 DEBUG: PREPARE SQL statement: no_name 0 SQL SELECT "ITEM_TYPE", "SUBSTAGE", "DATE_TIME", "MEASUREMENTID", "VALUE", "SITE_ID", "SESSION_ID" FROM PSSD_ALL WHERE ( ("SITE_ID" = '05' ) AND ("SESSION_ID" LIKE '%XYZ%ABC%' ) AND ("ITEM_TYPE" = 'XYZ' ) ) no_name 0 SQL DEBUG: Close Cursor - CDA= no_name 0 SQL NOTE: Table WORK.HOHO created, with rows and 5 columns. 17 real time 27:40.58 cpu time seconds Anweisung wird komplett von der Oracle-Datenbank ausgeführt 28 October, :14 AndreasMangold Es wird hier sichtbar, dass die SQL-Anweisung weitgehend komplett in der Oracle-Datenbank ausgeführt wird, bis auf die Selektion auf Substage (was hat dieses Feld für einen Datentyp?). Also dauert die Abfrage schon innerhalb von Oracle so lange. Es könnte sein, dass es so aussieht, als sei die Abfrage in PL/SQL Developer schneller, weil dort bereits ein Ergebnis angezeigt wird, wenn die ersten paar Sätze selektiert wurden, wohingegen die CREATE-Anweisung von PROC SQL immer die komplette Abfrage ausführt. Vorschläge zur weiteren Diagnose: Die Feldnamen in der Select-Anweisung durch ein COUNT(*) ersetzen, und die so geänderte Anweisung sowohl unter SAS als auch unter PL/SQL Developer absetzen, damit sichergestellt ist, dass auch in der Oracle-Umgebung die komplette Abfrage abgearbeitet wird und nicht nur die ersten paar Sätze. Oder: In SAS mit der OBS-Option arbeiten, damit auch hier nur die ersten Datensätze der Abfrage selektiert werden. Warum nicht Pass-Through? 28 October, :02 StephanFrenzel Gibt es einen Grund, nicht die Pass-Through-Funktion von SAS zu verwenden, d.h. Oracle direkt die auszuführende SQL vorzugeben?... also etwa: create table hihi as select * from connection to oracle (SELECT ITEM_TYPE, SUBSTAGE, DATE_TIME, MEASUREMENTID, VALUE FROM &oraauser..&oratable WHERE site_id = '05' AND SUBSTAGE ='ABC' ); Es gibt eine Menge von Möglichkeiten, die es nur in der Oracle-SQL gibt, wenn 's um Performance

4 geht z.b. die s.g. Hints. SAS SQL Performance 31 October, :55 Thomas Degenhardt Hallo, ich kann von ähnlichen Beobachtungen berichten. Wir haben bei AOL ein SAND Datawarehouse im Einsatz. Da es für die Datenbank keine native Schnittstelle im SAS System gibt läuft die Verbindung über eine "normale" ODBC Verbindung. Diese ist jedoch nicht das Problem. Der Nachteil liegt darin, das die SAS Proc-SQL Statements nicht 1:1 von der Datenbank verstanden werden. Dies führt zu dem Effekt, das SAS sich erstmal alle Zeilen, die zur Select Anweisung gehören, zieht und die Where Bedingung auf diesen Daten durchführt. Angenommen die Tabelle im Warehouse umfasst 10Mio. Zeilen und 50 Spalten, das SQL zielt auf 1000 Zeilen und eine Spalte, dann wird diese Spalte ersteinmal mit allen 10Mio. Zeilen ins SAS System transferiert. Auf diesen Daten wird dann die Where Bedingung ausgeführt. Das dauert natürlich sehr lange. Beim Pass Through umgeht man das Problem, da das Statement direkt auf der Datenbank ausgeführt wird und nur noch das Endergebnis ins SAS System gespielt wird. Nachteile die ich kenne sind folgende: 1. Im SQL muss auf SAS typische Funktionen, die der Datenbank unbekannt sind verzichtet werden. 2. Ein Join auf SAS Tabellen ist im SQL Statement nicht möglich. Wenn hier jemand gute Lösungen kennt wäre ich über Anregungen dankbar. Ich denke man muss abwägen ob die Investition in die Schnittstelle zu Oracle lohnt, oder nicht. Für SAND bietet SAS eine solche Lösung leider nicht an. Das ist eine komplexe Aufgabe für SAS 1 November, :47 AndreasMangold Die SAS/ACCESS-Libname-Engine ist darauf ausgerichtet, Abfragen auch über Datenbankgrenzen hinweg zu optimieren und die SQL aufzuteilen. Wenn man beispielsweise im Extremfall eine DB2-Tabelle mit einer SAS-Tabelle und einer Excel-Tabelle verknüpft, dann wird die SQL aufgeteilt und an die verschiedenen Systeme geschickt und die Ergebnisse wieder zusammengesetzt. Die SAS/ACCESS-Libname-Engine ist von den frühen 8er-Version bis zur aktuellen Version da immer besser geworden, die SQL zu optimieren. Der von Ihnen geschilderte Fall (alle Datensätze werden zunächst nach SAS geladen) sollte nur unter ungünstigen Bedingungen vorkommen, z.b. wenn man eine SAS-Funktion in der WHERE-Klausel verwendet und diese keine weiteren Einschränkungen enthält. In der Dokumentation zu SAS/ACCESS (SAS9) kann man unter anderem nachlesen, welche SAS-Funktionen in Datenbankfunktionen umgesetzt werden können und damit zu optimierten Abfragen führen. Schritte zur Optimierung hängen sehr vom Einzelfall ab. Die in diesem Forumsbeitrag genannte Option SASTRACE ist sehr hilfreich, um zu bestimmen, wie eine Abfrage genau ausgeführt wird.

5 SAS / Access Hallo Herr Mangold, 1 November, :46 Thomas Degenhardt vielen Dank für die Antwort. In meinem Fall scheint die Engine starke Probleme mit der SAND Datenbank zu haben. Obwohl die Verbindung über ODBC läuft. Ein Einsatz von Pass Through SQL statt Proc-SQL brachte auch bei einfachsten Select Anweisungen mit "normalen" Where Bedingungen enorme Geschwindigkeitsvorteile. Viele Grüße, Thomas Degenhardt Was gibt SAS an ODBC weiter? 1 November, :56 AndreasMangold Hallo Herr Degenhardt, können Sie an der SASTRACE-Ausgabe bei sich sehen, was SAS/ACCESS an ODBC weitergibt? Vermutlich nicht dasselbe wie Passthrough, sonst wäre die Laufzeit ja die gleiche. Die SAS-Version und der Hotfix-Stand machen hier einen großen Unterschied. Viele Grüße Andreas Mangold SAS Trace Hallo Herr Mangold, 3 November, :30 Thomas Degenhardt ich werde die SASTRACE Option testen. Bin gespannt was ich erkennen kann. Viele Grüße, Thomas Degenhardt