Præcis hvad mener du med "bestilt" i denne sammenhæng?
Som standard har hver node i klyngen en separat cache med sekvensnumre. Så node 1 uddeler muligvis værdierne 1-100, mens node 2 uddeler værdierne 101-200. Værdierne, der returneres fra en enkelt node, er sekventielle, men session A på node 1 kan få en værdi på 15, mens session B på node 2 får en værdi på 107, så de værdier, der returneres på tværs af sessioner, vises ude af rækkefølge.
Hvis du angiver, at sekvensen skal bestilles, besejrer du grundlæggende formålet med sekvenscachen, fordi Oracle nu skal kommunikere mellem noder, hver gang du anmoder om en ny sekvensværdi. Det har potentialet til at skabe en anstændig mængde præstationsomkostninger. Hvis du bruger sekvensen som en slags tidsstempel, kan det overhead være nødvendigt, men det er generelt ikke ønskeligt.
Overheadforskellen i praktiske termer vil være meget applikationsafhængig - den vil være umådelig lille for nogle applikationer og et betydeligt problem for andre. Antallet af RAC-noder, hastigheden af sammenkoblingen, og hvor meget sammenkoblingstrafik der er, vil også bidrage. Og da dette primært er et skalerbarhedsproblem, vil den praktiske effekt begrænse, hvor godt din applikation skalerer op, hvilket i sagens natur er ikke-lineært. En fordobling af transaktionsvolumen, som din applikation håndterer, vil være langt mere end fordoblet overhead.
Hvis du angiver NOCACHE, er valget af ORDER eller NOORDER dybest set irrelevant. Hvis du angiver ORDER, er valget af CACHE eller NOCACHE dybest set irrelevant. Så CACHE NOORDER er langt den mest effektive, de tre andre er relativt udskiftelige. De vil alle involvere inter-node-koordinering og netværkstrafik, hver gang du anmoder om en sekvensværdi, som naturligvis er en potentiel flaskehals.
Det ville generelt være at foretrække at tilføje en TIMESTAMP-kolonne til tabellen for at gemme det faktiske tidsstempel i stedet for at stole på sekvensen for at give en tidsstempelrækkefølge.