Alta disponibilidade com Oracle Standard Edition (à partir da versão 19c)

Durante o período de Janeiro de 2004 até Dezembro 2020 a Oracle comercializou, entre as versões 10g e 11g, uma família de produtos de banco de dados extremamente abrangente e capaz de atender empresas de todos os tamanhos e necessidades. Basicamente a edição do banco de dados Oracle era definida pela regra abaixo:

Com o crescimento da utilização das CPUs multicore em servidores de banco de dados e posteriormente os discos sólidos de alta velocidade, a utilização de quatro processadores em um cluster ativo/ativo permitia disponibilidade extrema em máquinas poderosas. O incremento do Oracle RAC na solução trazia alto retorno do investimento para as empresas pois aproveitavam totalmente o hardware do banco de dados, obtendo o melhor dos mundos – o núcleo do produto extremamente capaz de atender as fortes demandas de utilização concorrente, os sistemas operacionais 64 bit permitindo processamento praticamente ilimitado e o Real Application Cluster aproveitando integralmente os nós disponíveis em um cluster de disponibilidade.

No banco de dados Oracle versão 12c, a Oracle aposenta as edições Standard e Standard One e cria o novo Standard Two, utilizando uma política de limite máximo permitido de processamento, comum ao seu principal concorrente de banco de dados. Tecnicamente, as 16 threads de processamento total é mais do que suficiente para a maioria dos clientes Oracle Standard. Se um sistema possui necessidades acima desse limite nos servidores atuais de banco de dados, possivelmente valeria uma análise para uma possível migração para a edição Enterprise.

O que não agradou parte dos consumidores é que, antes o produto era limitado apenas pelo desempenho do hardware disponível, agora deveria ser migrado para uma outra edição da família caso ultrapassasse 16 threads de processamento.

Com o produto modificado, surge uma nova questão. Faria sentido dividir em dois nós ativos um produto que, por mais que existisse hardware para atender a demanda dos sistemas, iria limitar o processamento máximo em 16 threads?  Será que não seria mais adequado entregar todas as threads em apenas um nó, sem o custo extra de software para juntá-las como se fossem apenas um serviço, entregando o máximo desempenho que o hardware poderia processar? Nesse cenário a Oracle removeu o RAC mas não o cluster da infraestrutura do Standard 19c. Em outras palavras, ela readequou a alta-disponibilidade na edição standard, entregando uma tecnologia madura e tradicional embarcada no produto, ativa de um lado, passiva do outro, no clusterware 19 como parte da  inteligência e infraestrutura do Grid.

Importante salientar que, diferente do que alguns acreditam, existe SIM uma infraestrutura de cluster para bancos de dados Oracle Standard fornecida pela própria Oracle. Não há necessidade de aquisição ou instalação de produtos de terceiros para tal finalidade.