La limite imposée par Oracle découle d'un calcul très simple avec un seuil ancré dans le temps il y a 24 ans. Prenez le nombre de secondes depuis le 01/01/1988 à 00:00:00 et multipliez ce chiffre par 16 384. Si la valeur actuelle du SNC est inférieure à cela, alors tout va bien et le traitement continue normalement. Pour mettre cela en termes simples, le calcul suppose qu'avec une base de données fonctionnant en permanence depuis le 01/01/1988, il est impossible dans la réalité d'arriver à 16 384 transactions par seconde.
Mais il est toujours possible de modifier les conditions de cette réalité pour repousser la limite du SNC.

Le bug de sauvegarde

Un exemple récent vient sous la forme d'un bug de la base de données Oracle avec la fonction qui assure les sauvegardes live. Elle permet à un administrateur d'exécuter une commande afin de faciliter la sauvegarde d'une base de données en direct. C'est une fonction très pratique qui peut être exécutée facilement : «ALTER DATABASE BEGIN BACKUP » est la commande dont vous avez besoin. Vous pouvez ensuite sauvegarder la base jusqu'à ce que vous saisissiez la commande « ALTER DATABASE END BACKUP» qui switche sur le mode de fonctionnement normal. Un moyen très simple pour un administrateur de faire des sauvegardes de ses bases de données en production.

Le problème est que, en raison d'un codage défaillant, la commande «BEGIN BACKUP » entraine un bond spectaculaire du SCN qui continuera d'augmenter à un rythme effréné même après la saisie de la commande « END BACKUP » . Ainsi, effectuer une sauvegarde à chaud peut augmenter de plusieurs millions ou mêmes milliards la  valeur du SCN. Dans la plupart des cas, les limites du SCN sont si éloignées que ce saut occasionnel n'est pas une cause de préoccupation majeure. Il est même certain que bien peu d'administrateurs ont remarqué le problème.

L'interconnection des bases multiplie l'effet du bug SCN

Mais quand vous mélangez le bug de sauvegarde live avec un grand nombre de bases de données interconnectées dans une mise en oeuvre massive de la plate-forme d'Oracle, la combinaison peut entraîner une élévation énorme du SCN. Certains grands clients d'Oracle ont des centaines de serveurs exécutant des centaines d'instances Database interconnectées dans toute l'infrastructure. Chacun peut être chargé avec un service de base et quelques fonctions moins importantes - mais presque tous sont reliés entre eux, à travers un, deux, quatre ou plus de serveurs intermédiaires.

Avec tous ces serveurs interconnectés, les SCN se synchronisent à un moment ou un autre. Collectivement, ils pourraient dépasser les 16 384 transactions par seconde, mais certainement pas depuis le 01/01/1988, donc la limite SCN n'est pas dépassée. Mais que faire si une DBA sur une partie de ce réseau Oracle gère la sauvegarde live et déclenche le précédent bug ? Soudain, le SCN fait un bond de, disons 700 millions, et ce nombre devient bientôt la référence pour tous les SCN interconnectés sur le réseau. Quelque temps plus tard, une autre commande de sauvegarde live est enclenchée par un DBA de l'autre côté de l'entreprise. Le SCN pousse jusqu'à quelques centaines de millions cette fois-ci, également synchronisé sur toutes les instances reliées au fil du temps.

Avec l'émission de quelques commandes de sauvegarde, le SCN d'un groupe de bases de données Oracle peut augmenter de plusieurs centaines de millions, voire de centaines de milliards dans une courte période. Même les SGBD qui se relient occasionnellement, par semaine ou par mois, pourraient voir leur nombre SCN bondir de plusieurs milliards.
Dans un tel scénario, ce n'est qu'une question de temps pour que les commandes de sauvegarde dépassent la limite du SCN et entrainent des problèmes très sérieux, blocage des requêtes provenant d'autres serveurs, ou plantages tout simplement.