A pergunta provavelmente atrairá respostas baseadas em opinião. Este é um deles.
O balanceamento de carga não está facilmente disponível se você executar o processo do Oracle DB como um serviço em um cluster da Red Hat. O melhor que você pode fazer quando se trata de cluster seria ativo-standby ou seja. haveria processos do Oracle DB sendo executados em apenas um dos nós em seu cluster em qualquer momento específico e os processos passariam para outro nó quando um deles falhasse. Mesmo isso pode se tornar muito difícil de realizar.
O motivo pelo qual o cenário de balanceamento de carga não é viável dessa maneira é porque ter mais de um processo do Oracle DB acessando partições de dados sem que eles estejam cientes um do outro pode corromper seus dados. Atualmente, a maneira de tornar os nós cientes um do outro no nível do Oracle DB é comprar o RAC, e é por isso que eles o vendem.
Dito isso, uma configuração de espera ativa pode ser algo assim: vincule os processos do Oracle DB a um endereço IP extra que, em seguida, viaja de um nó para outro com o serviço, isto é. Ambos os endereços IP do serviço, os processos do Oracle DB e as partições de dados são serviços em um cluster da Red Hat, passando de nó a nó em caso de falha. O IP de serviço oferece um benefício: assim, seus clientes podem se reconectar quando um nó falha e outro toma o seu lugar. No entanto, todas as conexões existentes serão desativadas durante a alternância no cenário de espera ativa.
Além das desvantagens listadas acima, existem outros problemas, por exemplo, será muito difícil obter suporte da Oracle quando algo der errado, pois o cenário que você está pensando não é exatamente o recomendado pela Oracle.
Para resumir, pode ser uma boa idéia reconsiderar e se você realmente precisa de balanceamento de carga no nível do Oracle DB e tal, provavelmente é melhor comprar o RAC do que tentar preparar sua própria solução simulando alguns dos recursos RAC ofertas.