Co přesně v této souvislosti myslíte slovem "objednáno"?
Ve výchozím nastavení má každý uzel v clusteru samostatnou mezipaměť pořadových čísel. Takže uzel 1 může rozdávat hodnoty 1-100, zatímco uzel 2 rozdává hodnoty 101-200. Hodnoty vrácené z jednoho uzlu jsou sekvenční, ale relace A v uzlu 1 může získat hodnotu 15, zatímco relace B v uzlu 2 získá hodnotu 107, takže hodnoty vrácené napříč relacemi vypadají mimo pořadí.
Pokud určíte, že sekvence musí být seřazena, v podstatě zmaříte účel mezipaměti sekvencí, protože Oracle nyní musí komunikovat mezi uzly pokaždé, když požadujete novou hodnotu sekvence. To má potenciál vytvořit slušnou režii výkonu. Pokud sekvenci používáte jako určitý druh časového razítka, může být tato režie nezbytná, ale není obecně žádoucí.
Rozdíl v režii bude z praktického hlediska silně závislý na aplikaci – pro některé aplikace bude neměřitelně malý a pro jiné významný problém. Přispěje také počet uzlů RAC, rychlost propojení a objem propojovacího provozu. A protože se jedná především o problém škálovatelnosti, praktický efekt omezí, jak dobře se bude vaše aplikace škálovat, což je ze své podstaty nelineární. Zdvojnásobení objemu transakcí, které vaše aplikace zpracovává, znamená mnohem více než dvojnásobnou režii.
Pokud zadáte NOCACHE, výběr ORDER nebo NOORDER je v podstatě irelevantní. Pokud zadáte ORDER, výběr CACHE nebo NOCACHE je v podstatě irelevantní. CACHE NOORDER je tedy zdaleka nejúčinnější, ostatní tři jsou relativně zaměnitelné. Všechny budou zahrnovat koordinaci mezi uzly a síťový provoz pokaždé, když požadujete sekvenční hodnotu, což je samozřejmě potenciální úzké hrdlo.
Obecně by bylo vhodnější přidat do tabulky sloupec TIMESTAMP pro uložení skutečného časového razítka, než se spoléhat na pořadí, které zajistí pořadí časového razítka.