Oracle Database

Conceito

A tese do Oracle é completude e garantia contratual. Ele resolve o problema de uma instituição que precisa que o banco não pare, que a auditoria seja possível, que exista um fornecedor responsável em contrato — e que aceita pagar por isso. Bancos, telecom, seguradoras, governo e ERPs vivem nele por esse motivo, não por inércia.

Para quem chega do mundo open source, três choques culturais:

1. Muita lógica de negócio mora no banco. Packages PL/SQL, triggers, views materializadas, jobs. Não é má prática legada: é o modelo do produto, e mexer nisso é um projeto, não um refactor.
2. Recursos importantes são opções pagas. Particionamento, compressão avançada, Active Data Guard, RAC, In-Memory — cada um é uma linha de licença. "O Oracle tem esse recurso" e "você pode usar esse recurso" são perguntas diferentes.
3. Vocabulário próprio. Instance ≠ database, schema ≈ usuário, tablespace, SGA/PGA, redo/undo, SCN, AWR. Nada disso mapeia 1:1 no Postgres.

Arquitetura em uma tela

• Instance (memória SGA + processos de fundo) e database (os arquivos). Um database pode ser servido por várias instances — é o que o RAC faz.
• Multitenant (CDB/PDB): um contêiner (CDB) hospeda vários pluggable databases (PDB). Consolidação e plug/unplug de banco inteiro.
• RAC (Real Application Clusters): vários nós com disco compartilhado servindo o mesmo banco, ativo-ativo. É praticamente único no mercado — os concorrentes fazem shared nothing (Sharding) ou ativo-passivo (Fail-Over).
• Data Guard: réplica física com failover coordenado; Active Data Guard permite ler na réplica.
• Redo log + undo tablespace: redo para recuperação, undo para MVCC e rollback.
• Flashback: consultar (AS OF TIMESTAMP), reverter tabela ou o banco inteiro para um ponto no passado. Não há equivalente direto nos outros dois.
• AWR / ASH / SQL Plan Management: diagnóstico histórico de performance com granularidade que o mundo open source só alcança montando várias ferramentas.

Concorrência

• MVCC via undo, como o MySQL e diferente do Postgres: a versão antiga é reconstruída a partir do undo quando alguém precisa dela.
• Isolamento padrão: READ COMMITTED. Não existe dirty read — o Oracle simplesmente não implementa READ UNCOMMITTED. SERIALIZABLE existe; REPEATABLE READ não, mas SELECT ... FOR UPDATE e read-only transactions cobrem os casos.
• "Leitores não bloqueiam escritores, escritores não bloqueiam leitores" é slogan antigo da Oracle e é verdade — o custo aparece como ORA-01555 snapshot too old quando o undo necessário já foi reciclado.

Versões: 19c, 23ai e o 26ai

A nomenclatura mudou duas vezes em pouco tempo, e isso gera confusão real:

O 26ai trouxe AI Vector Search, replicação RAFT no globally distributed database, SQL Firewall no banco, criptografia resistente a quântica, True Cache, JSON Relational Duality (a mesma linha vista como tabela ou documento) e leitura de Apache Iceberg. Se você vê "23ai" numa vaga ou num plano de migração, o alvo correto hoje é 26ai.

Trade-offs

A licença é uma decisão de arquitetura. Licenciamento por core com fator de processador, opções pagas por recurso, regras próprias para virtualização e nuvem. A frase que resume: no Oracle, "vamos adicionar uma réplica de leitura" é uma conversa com o financeiro, não com o time de infra. É o que empurra migrações para Postgres.

Lock-in por PL/SQL. Um sistema com 200 mil linhas de PL/SQL não "troca de banco": ele é reescrito. Ferramentas de conversão (ora2pg) ajudam com schema e resolvem pouco de lógica.

Complexidade operacional exige especialista. RAC, ASM, Data Guard e tuning de SGA são conhecimento de DBA dedicado. Em compensação, quando existe esse especialista, o Oracle entrega diagnóstico e controle que os outros não têm.

Dev local é atrito. Não se sobe um Oracle como docker run postgres. Há XE (edição gratuita, com limites) e imagens oficiais em contêiner, mas o ciclo é mais pesado — o que na prática significa menos testes contra o banco real e mais surpresa no ambiente integrado.

O trade-off central: Oracle troca custo e liberdade por capacidade e responsabilidade contratual. Para um sistema onde uma hora parada custa mais que a licença anual, é barato. Para um SaaS que precisa multiplicar réplicas por demanda, é o pior modelo econômico dos três.

Exemplo prático

O que mais quebra código vindo de Postgres/MySQL — a semântica de string vazia:

-- Oracle: '' É NULL para VARCHAR2. Não é "quase", é literalmente.
SELECT CASE WHEN '' IS NULL THEN 'é null' ELSE 'não é' END FROM dual; -- 'é null'

-- consequência 1: NOT NULL não impede "vazio", porque vazio = ausente
INSERT INTO clientes (nome) VALUES ('');   -- ORA-01400: cannot insert NULL

-- consequência 2: comparação silenciosa
SELECT * FROM clientes WHERE nome = '';    -- SEMPRE zero linhas (NULL = NULL é unknown)

-- consequência 3: concatenação ignora NULL (diferente de Postgres!)
SELECT 'a' || NULL || 'b' FROM dual;       -- 'ab'  (no Postgres: NULL)

Uma aplicação que grava "" para "campo não preenchido" e um relatório que filtra WHERE campo = '' conviveram por anos no Postgres e passam a devolver zero linhas no Oracle — sem erro, sem aviso. É o tipo de diferença que 2. Dialetos SQL na Prática cataloga.

E o padrão que define performance no Oracle, bind variables:

-- ❌ SQL montado por concatenação: cada valor gera um hard parse novo
SELECT * FROM pedidos WHERE cliente_id = 4711;

-- ✅ com bind: um plano no cache, reutilizado por todos
SELECT * FROM pedidos WHERE cliente_id = :id;

O Oracle guarda planos de execução no shared pool, indexados pelo texto da query. SQL concatenado gera um texto diferente por chamada → hard parse a cada execução → contenção de latch na library cache → ORA-04031 quando o pool esgota. Em Go, usar ?/:1 no database/sql já resolve — que é o mesmo motivo pelo qual você evita SQL concatenado por segurança. Ver 5. Go em Produção.

Como isso falha em produção

Aprofundamento aplicado

Identificar o contexto antes de interpretar um erro

Em ambiente multitenant, conexão, serviço e container determinam onde o SQL é executado. Dois usuários com o mesmo nome em contextos diferentes não implicam acesso às mesmas tabelas. Uma investigação deve registrar serviço, schema e PDB, além da instrução que falhou.

Cenário: a aplicação migra um schema em um serviço e executa consultas por outro. O erro de objeto inexistente pode vir do contexto de conexão, sem que a migração tenha falhado. Sinônimos e privilégios também participam da resolução e do acesso.

Separar recursos do produto e requisitos da aplicação

Antes de depender de um recurso específico, relacione-o à edição, configuração e ambiente efetivamente implantados. Ter SQL compatível não demonstra que um mecanismo de disponibilidade ou diagnóstico está habilitado.

Exercício: documente o caminho cliente → serviço → container → schema de uma aplicação fictícia. Resultado esperado: explique onde uma tabela é criada, quem a acessa e como outra aplicação evita conectar ao contexto errado.

Referência: conceitos de arquitetura Oracle.

Relacionado

• 1. PostgreSQL
• 1. MySQL
• 1. PostgreSQL vs MySQL vs Oracle
• 2. Dialetos SQL na Prática
• 3. MVCC e Isolamento na Prática
• RDS
• Serviços de Migração

---

Parte de MOC Oracle · docs.oracle.com/database · GA do 26ai on-premises