Ma compréhension du chemin conventionnel de SQL * Loader est qu'il génère simplement des instructions INSERT et les envoie à la base de données. Y a-t-il des avantages de performance à utiliser ceci plutôt que de simplement générer les instructions SQL par programme et de les exécuter par rapport à la base de données?Pourquoi utiliser les chemins de chargement conventionnels SQL * Loader?
SQL * Loader génère des instructions INSERT, mais très critique, il utilise des variables de liaison. Si vous chargez des milliers de lignes, la création d'instructions INSERT incluant des littéraux de chaîne sera d'un ordre de grandeur plus lent que l'utilisation de variables de liaison en plus de l'écrasement du pool partagé. Si vous générez un tas d'instructions INSERT, Oracle doit analyser chaque instruction, ce qui consomme rapidement la grande majorité du temps de votre processus de chargement. Selon la taille de votre pool partagé, votre paramètre CURSOR_SHARING et le nombre de lignes que vous chargez, un fichier d'instructions d'insertion peut très facilement mettre suffisamment de pression sur le pool partagé que le processus de chargement (et/ou tout autre processus non lié est en cours d'exécution en même temps que nécessaire pour analyser une nouvelle requête) va générer une erreur car il n'y a pas assez d'espace contigu dans le pool partagé.
Vous pouvez certainement écrire une application qui se comporte aussi bien que SQL * Loader pour un chargement de chemin conventionnel. Votre demande aurait besoin de faire quelque chose comme
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
C'est très différent de celui que des milliers déchaînant des requêtes INSERT distinctes contre la base de données.
+1 Bonne réponse. –