Warum sollte ich konventionelle Ladepfade von SQL * Loader verwenden?

Question

Mein Verständnis des konventionellen Pfades von SQL * Loader ist, dass es einfach INSERT-Anweisungen erzeugt und diese an die Datenbank sendet. Gibt es irgendwelche Leistungsvorteile bei der Verwendung dieser Funktion, anstatt die SQL-Anweisungen programmgesteuert zu generieren und sie dann gegen die Datenbank auszuführen?

Answer 1

SQL * Loader erzeugt INSERT-Anweisungen, aber sehr kritisch verwendet er Bind-Variablen. Wenn Sie Tausende von Zeilen laden, ist der Aufbau von INSERT-Anweisungen, die String-Literale enthalten, um eine Größenordnung langsamer als die Verwendung von Bind-Variablen, zusätzlich zur Überschreitung des gemeinsamen Pools. Wenn Sie eine Reihe von INSERT-Anweisungen generieren, muss Oracle jede einzelne Anweisung analysieren, wodurch die meiste Zeit Ihres Ladeprozesses schnell verbraucht wird. Abhängig von der Größe Ihres gemeinsamen Pools, Ihrem CURSOR_SHARING Parameter und der Anzahl der Zeilen, die Sie laden, kann eine Datei mit INSERT-Anweisungen sehr leicht Druck auf den gemeinsam genutzten Pool ausüben, den der Ladeprozess (und/oder ein anderer nicht verwandter Prozess) passiert zufällig zur gleichen Zeit, die eine neue Abfrage parsen muss), wird ein Fehler auftreten, da nicht genug zusammenhängender Speicherplatz im gemeinsam genutzten Pool vorhanden ist.

Sie können sicherlich eine Anwendung schreiben, die sich so verhält wie SQL * Loader für eine konventionelle Pfadladung. Ihre Anwendung muss so etwas wie

Prepare the statement 
Loop 
    Read the next row of data 
    Split the next row of data into columns 
    Bind the data to the bind variables in the prepared statement 
    Execute the prepared statement 
End loop 

tun, die ganz anders sind als nur Tausende von separaten INSERT-Anweisungen für die Datenbank zu entfesseln.