Par défaut, ORA_ROWSCN est stocké au niveau du bloc, pas au niveau de la ligne. Il n'est stocké au niveau de la ligne que si la table a été créée à l'origine avec ROWDEPENDENCIES activé. En supposant que vous puissiez tenir plusieurs lignes de votre tableau dans un seul bloc et que vous n'utilisez pas le APPEND Pour insérer les nouvelles données au-dessus de la limite supérieure existante de la table, vous insérez probablement de nouvelles données dans des blocs qui contiennent déjà des données existantes. Par défaut, cela va changer le ORA_ROWSCN de chaque ligne du bloc, ce qui fait que votre requête compte plus de lignes que celles réellement insérées.
Depuis ORA_ROWSCN est uniquement garanti d'être une limite supérieure la dernière fois qu'il y avait DML sur une ligne, il serait beaucoup plus courant de déterminer combien de lignes ont été insérées aujourd'hui en ajoutant un CREATE_DATE colonne à la table qui par défaut est SYSDATE ou de s'appuyer sur SQL%ROWCOUNT après votre INSERT run (en supposant, bien sûr, que vous utilisiez un seul INSERT pour insérer toutes les lignes).
Généralement, en utilisant le ORA_ROWSCN et le SCN_TO_TIMESTAMP la fonction va être un moyen problématique d'identifier quand une ligne a été insérée même si la table est construite avec ROWDEPENDENCIES . ORA_ROWSCN renvoie un SCN Oracle qui est un numéro de modification système. Il s'agit d'un identifiant unique pour un changement particulier (c'est-à-dire une transaction). En tant que tel, il n'y a pas de lien direct entre un SCN et une heure - ma base de données peut générer des SCN un million de fois plus rapidement que la vôtre et mon SCN 1 peut différer d'années de votre SCN 1. Le processus d'arrière-plan Oracle SMON maintient une table qui mappe les valeurs SCN à des horodatages approximatifs, mais elle ne conserve ces données que pendant une période de temps limitée - sinon, votre base de données se retrouverait avec une table de plusieurs milliards de lignes qui ne faisait que stocker des mappages SCN à horodatage. Si la ligne a été insérée il y a plus d'une semaine (et la limite exacte dépend de la base de données et de la version de la base de données), SCN_TO_TIMESTAMP ne pourra pas convertir le SCN en horodatage et renverra une erreur.
