Le partage de curseur est (ou était) un gros avantage sur la concurrence. Fondamentalement, le même plan de requête est utilisé pour les requêtes correspondantes. Une application aura un ensemble standard de requêtes qu'elle émet (par exemple, obtenir les commandes pour cet identifiant client). Le moyen simple est de traiter chaque requête individuellement, donc si vous voyez 'SELECT * FROM ORDERS WHERE CUSTOMER_ID =: b1', vous regardez si table ORDERS a un index sur CUSTOMER_ID etc. Vous pouvez donc passer autant de temps à chercher des métadonnées pour obtenir un plan de requête en tant que récupération des données. Avec des recherches simples par clé, un plan de requête est facile. Les requêtes complexes avec plusieurs tables jointes sur des colonnes asymétriques sont plus difficiles.
Oracle a un cache de plans de requête, et les anciens/moins utilisés sont obsolètes car de nouveaux plans sont requis.
Si vous ne mettez pas en cache les plans de requête, vous ne pouvez pas faire en sorte que votre optimiseur soit intelligent car plus vous générez de codes intelligents, plus vous avez d'impact sur chaque requête traitée. Les requêtes de mise en cache signifient que vous ne subissez cette surcharge que la première fois que vous voyez la requête. L'inconvénient est que pour que le partage du curseur soit efficace, vous devez utiliser des variables de liaison. Certains programmeurs ne s'en rendent pas compte et écrivent du code qui n'est pas partagé, puis se plaignent qu'Oracle n'est pas aussi rapide que mySQL.
Un autre avantage d'Oracle est le journal UNDO. À mesure qu'une modification est effectuée, l'ancienne version des données est écrite dans un journal d'annulation. D'autres bases de données conservent les anciennes versions de l'enregistrement au même endroit que l'enregistrement. Cela nécessite des opérations de nettoyage de style VACUUM ou vous rencontrez des problèmes d'espace et d'organisation. Ceci est particulièrement pertinent dans les bases de données avec une activité de mise à jour ou de suppression élevée.
Oracle n'a pas non plus de registre de verrouillage central. Un bit de verrouillage est stocké sur chaque enregistrement de données individuel. SELECT ne prend pas de verrou. Dans les bases de données où SELECT se verrouille, plusieurs utilisateurs peuvent lire des données, se verrouiller les uns les autres ou empêcher les mises à jour, en introduisant des limites d'évolutivité. D'autres bases de données verrouillent un enregistrement lorsqu'un SELECT a été effectué pour s'assurer que personne d'autre ne peut modifier cet élément de données (il serait donc cohérent si la même requête ou transaction examinait à nouveau la table).Oracle utilise UNDO pour son modèle de cohérence de lecture (c.-à-d. Rechercher les données telles qu'elles apparaissent à un moment précis).