Ik durf te wedden dat uw database RAC (Real Application Clusters) draait. Ervan uitgaande dat dat het geval is en dat u de reeks maakt met alle standaardinstellingen, is dat het verwachte gedrag.
De standaardinstelling is om 20 waarden in de cache op te slaan. Elk knooppunt in het RAC-cluster heeft standaard een aparte cache. Ervan uitgaande dat u een cluster heeft met twee knooppunten A en B, is de eerste keer een nextval wordt aangevraagd op A, zal A de waarden 1-20 in de cache plaatsen en een waarde van 1 retourneren. Als de volgende aanvraag voor een nextval is gemaakt op B, zal B de waarden 21-40 in de cache opslaan en een waarde van 21 retourneren. Van daaruit hangt de waarde die u krijgt af van het knooppunt waarop uw verbinding toevallig wordt uitgevoerd.
Over het algemeen zou dit geen probleem moeten zijn. Reeksen genereren unieke nummers. De nummers hoeven over het algemeen niet opeenvolgend te zijn. Als het echt nodig is dat waarden opeenvolgend worden geretourneerd omdat u iets doet zoals sorteren op de door de reeks gegenereerde waarde om de "eerste" of "laatste" rij te bepalen, kunt u de ORDER gebruiken clausule wanneer u de reeks maakt om te forceren dat waarden in volgorde worden geretourneerd. Dat heeft echter een negatieve invloed op de prestaties van een RAC-database, omdat het de hoeveelheid communicatie vergroot die tussen de knooppunten moet plaatsvinden om de geretourneerde waarden te synchroniseren. Als u de "eerste" of "laatste" rij moet bepalen, is het over het algemeen beter om een date toe te voegen of een timestamp kolom naar de tabel en sorteer daarnaar in plaats van aan te nemen dat de primaire sleutel opeenvolgend wordt gegenereerd.