Qu'entendez-vous exactement par "commandé" dans ce contexte ?
Par défaut, chaque nœud du cluster possède un cache distinct de numéros de séquence. Ainsi, le nœud 1 peut distribuer les valeurs 1-100 tandis que le nœud 2 distribue les valeurs 101-200. Les valeurs renvoyées par un seul nœud sont séquentielles, mais la session A sur le nœud 1 peut obtenir une valeur de 15 tandis que la session B sur le nœud 2 obtient une valeur de 107, de sorte que les valeurs renvoyées d'une session à l'autre apparaissent dans le désordre.
Si vous spécifiez que la séquence doit être ordonnée, vous allez à l'encontre de l'objectif du cache de séquence car Oracle doit désormais communiquer entre les nœuds chaque fois que vous demandez une nouvelle valeur de séquence. Cela a le potentiel de créer une quantité décente de surcharge de performance. Si vous utilisez la séquence comme une sorte d'horodatage, cette surcharge peut être nécessaire, mais elle n'est généralement pas souhaitable.
La différence de surcharge en termes pratiques dépendra fortement de l'application - elle sera incommensurable pour certaines applications et un problème important pour d'autres. Le nombre de nœuds RAC, la vitesse de l'interconnexion et la quantité de trafic d'interconnexion y contribueront également. Et comme il s'agit principalement d'un problème d'évolutivité, l'effet pratique va limiter la capacité d'évolution de votre application, ce qui est par nature non linéaire. Doubler le volume de transactions que votre application gère va bien plus que doubler les frais généraux.
Si vous spécifiez NOCACHE, le choix de ORDER ou NOORDER est fondamentalement hors de propos. Si vous spécifiez ORDER, le choix de CACHE ou NOCACHE est fondamentalement hors de propos. Donc CACHE NOORDER est de loin le plus efficace, les trois autres sont relativement interchangeables. Ils vont tous impliquer une coordination inter-nœuds et un trafic réseau chaque fois que vous demandez une valeur de séquence, ce qui est, évidemment, un goulot d'étranglement potentiel.
Il serait généralement préférable d'ajouter une colonne TIMESTAMP à la table pour stocker l'horodatage réel plutôt que de se fier à la séquence pour fournir un ordre d'horodatage.
