Embora eu recomende fortemente contra isso (preferindo usar uma única sequência e apenas aceitar que haverá lacunas maiores do que o esperado), você pode construir sua própria tabela de pseudo-sequência
CREATE TABLE my_sequences (
sequence_name VARCHAR2(30) PRIMARY KEY,
sequence_val NUMBER
);
insira algumas linhas
INSERT INTO my_sequences( sequence_name, sequence_val )
VALUES( 'GroupA', 1 );
INSERT INTO my_sequences( sequence_name, sequence_val )
VALUES( 'GroupB', 1 );
e, em seguida, escreva uma função para obter o próximo valor de sequência
CREATE FUNCTION get_nextval( p_sequence_name IN VARCHAR2 )
RETURN NUMBER
IS
l_val NUMBER;
BEGIN
SELECT sequence_val
INTO l_val
FROM my_sequences
WHERE sequence_name = p_sequence_name
FOR UPDATE;
UPDATE my_sequences
SET sequence_val = sequence_val + 1
WHERE sequence_name = p_sequence_name;
RETURN l_val;
END;
Isso bloqueará a linha na tabela para a sequência específica até que a transação que recuperou a próxima linha seja confirmada ou revertida. Isso diminuirá radicalmente a escalabilidade do seu aplicativo em comparação com o uso de sequências Oracle, garantindo que apenas uma sessão possa inserir uma linha para um determinado
group_name de cada vez-- os outros bloquearão aguardando a sequência. Se você tiver um sistema com um número relativamente pequeno de usuários simultâneos (ou um número relativamente grande de group_name valores), que podem ser aceitáveis para você. Mas, em geral, é uma prática ruim. Dependendo da versão do Oracle, você pode usar transações autônomas para aumentar a simultaneidade, mas isso apenas adiciona mais um pouco de complexidade à solução. No ponto em que você está realmente preocupado com a escalabilidade, você realmente deseja retroceder em todo o design e usar apenas uma sequência Oracle. 
