Oracle Data Platform Foundations Associate (1Z0-1195-25): o portfólio de dados Oracle na prática
Das três certificações Foundations, essa é a mais densa de todas. A Oracle construiu um portfólio de dados que cobre praticamente todo cenário possível: banco relacional, JSON, grafo, espacial, NoSQL, analytics, lakehouse. A prova cobre tudo isso. Quem se prepara para ela sai com um mapa completo de um ecossistema que, sem nenhum guia, levaria meses para entender.
Para quem vem do AWS ou Azure, vale o aviso: o Autonomous Database e a Converged Database são os pontos onde a Oracle mais difere das outras nuvens. Não tem equivalente direto. Entender o que esses dois fazem vai mudar a forma como você pensa arquitetura de dados, e com certeza terá reflexo prático no seu próximo projeto.
Dados da prova:
- Código: 1Z0-1195-25
- Questões: 55, múltipla escolha
- Duração: 90 minutos
- Aprovação: 68%
- Custo: gratuito
- Aposentadoria da versão 2025: 29 de maio de 2026
Parte 1 - O que é a área e o que a prova cobre
A plataforma de dados Oracle cobre todo o ciclo: armazenamento, processamento, analytics, desenvolvimento de aplicação sobre o banco, resiliência e migração. A prova não chega no detalhes técnicos de cada um, mas espera que você saiba o que cada produto faz e em que situação faz sentido escolhê-lo.
Os domínios oficiais e seus pesos:
Domínio Peso
Autonomous Database e ferramentas 16%
Data Lake, Data Warehouse e Machine Learning 15%
Desenvolvimento em Oracle Database 13%
Introdução à gestão de dados 11%
Exadata e DBCS 11%
Resiliência 9%
MySQL e NoSQL 10%
Converged Database 7%
Upgrades e migrações 8%
Analisando essa distribuição, os três primeiros domínios somam 44% da prova. Quem chega bem preparado em Autonomous Database, na arquitetura de Lakehouse Oracle e nos fundamentos de desenvolvimento (ORDS, APEX) já chega cpm vantagem.
Parte 2 - Os serviços Oracle na prática
Autonomous Database
O Autonomous Database é o protagonista da prova. E o "Autonomous" no nome não é à toa: a Oracle assume o trabalho de patching, backup, tunning de query, scaling de compute e storage e detecção de anomalias de segurança. Tudo automatizado. A diferença para o Base Database Service é simples: aqui você não pega SSH, não decide quando aplicar patch, não mexe no sistema operacional. Para muita gente isso é alívio, para outros é perda de controle. Depende do caso.
Quatro variantes, cada uma com seu cenário:
ATP (Autonomous Transaction Processing) - para OLTP. Workload transacional com muita concorrência, milhares de conexões abertas, transações curtas de escrita e leitura. Sistema de e-commerce, ERP, CRM.
ADW (Autonomous Data Warehouse) - para analytics. Query analítica pesada sobre volume grande de dados histórico. Columnstore por padrão, paralelismo automático. Performance bem melhor que o ATP em query agregada, justamente porque o armazenamento é orientado a coluna.
AJD (Autonomous JSON Database) - banco de documentos JSON com API SODA, e compatível com a API do MongoDB. Quem tem aplicação MongoDB e quer migrar pode apontar o driver para o AJD sem reescrever código.
Autonomous Database for APEX - banco dedicado para desenvolvimento low-code com Oracle APEX. Custa menos que as outras variantes porque é otimizado especificamente para esse perfil de uso.
Um trecho de SQL para dar contexto do que dá para fazer dentro do banco:
[SQL]
-- Criar schema para aplicação
CREATE USER vendas_app IDENTIFIED BY "Senha#2026!";
GRANT CONNECT, RESOURCE TO vendas_app;
-- Tabela de pedidos com performance para OLTP
CREATE TABLE vendas_app.pedidos (
id NUMBER GENERATED ALWAYS AS IDENTITY,
cliente_id NUMBER NOT NULL,
produto_id NUMBER NOT NULL,
quantidade NUMBER NOT NULL,
valor_total NUMBER(10,2) NOT NULL,
status VARCHAR2(20) DEFAULT 'PENDENTE',
criado_em TIMESTAMP DEFAULT SYSTIMESTAMP,
CONSTRAINT pk_pedidos PRIMARY KEY (id),
CONSTRAINT ck_status CHECK (status IN ('PENDENTE','PROCESSANDO','ENVIADO','ENTREGUE','CANCELADO'))
);
-- Índice para queries por cliente (frequente em OLTP)
CREATE INDEX idxpedidoscliente ON vendasapp.pedidos (clienteid, criado_em DESC);
-- Query analítica que o ADW vai paralelizar automaticamente
SELECT
produto_id,
TRUNC(criado_em, 'MM') AS mes,
COUNT(*) AS total_pedidos,
SUM(valor_total) AS receita,
AVG(valortotal) AS ticketmedio
FROM vendas_app.pedidos
WHERE criadoem >= ADDMONTHS(SYSDATE, -12)
AND status = 'ENTREGUE'
GROUP BY produtoid, TRUNC(criadoem, 'MM')
ORDER BY mes DESC, receita DESC;
Pela CLI fica assim:
[BASH]
Criar ATP via CLI
oci db autonomous-database create \
--compartment-id <compartment-ocid> \
--db-name "VENDAS01" \
--display-name "banco-vendas-producao" \
--db-workload "OLTP" \
--cpu-core-count 4 \
--data-storage-size-in-tbs 2 \
--admin-password "Admin#2026!" \
--is-auto-scaling-enabled true \
--is-free-tier false
Escalar CPU sem downtime
oci db autonomous-database update \
--autonomous-database-id <adb-ocid> \
--cpu-core-count 8
Criar backup manual
oci db autonomous-database-backup create \
--autonomous-database-id <adb-ocid> \
--display-name "backup-pre-atualizacao" \
--type "FULL"
Baixar wallet para conexão segura
oci db autonomous-database generate-wallet \
--autonomous-database-id <adb-ocid> \
--password "WalletPwd#2026" \
--file wallet.zip
Vale destacar o auto-scaling. Se ativado, o banco usa até três vezes o número base de CPUs em momento de pico, e volta ao baseline quando o tráfego cai. Você paga pelas CPUs adicionais por hora efetivamente usada, não pelo tempo provisionado. Para workload com tráfego irregular, isso elimina aquele cálculo chato de dimensionar para o pior caso e pagar caro o ano inteiro.
Exadata e Base Database Service
O Exadata é o hardware proprietário Oracle, desenhado para Oracle Database de alta performance. A ideia técnica é simples de explicar mas pesada na prática: hardware e software co-projetados, com otimizações que servidor genérico não tem. Smart Scan executa filtro diretamente na camada de storage antes de mandar dado para a camada de banco. Smart Flash Cache mantém bloco quente em NVMe flash com acesso direto. O resultado é throughput de I/O em outro patamar.
No OCI, o Exadata aparece em três formatos:
- Exadata Cloud Service: infraestrutura dedicada que você provisiona, Oracle gerencia hardware e software Exadata
- Autonomous Database on Exadata: Autonomous rodando sobre Exadata, gerenciamento máximo
- Exadata Cloud@Customer (ExaCC): Exadata instalada no seu data center, gerenciada via OCI
O Base Database Service (DBCS) é o Oracle Database tradicional rodando em VM no OCI. Você tem SSH, controla configuração do banco, e pode instalar software adicional. A Oracle ainda oferece ferramenta para automatizar backup e patching, mas quem decide quando e como é você. Mais controle, mais trabalho operacional.
Quando o DBCS faz mais sentido que o Autonomous? Em três casos comuns: versão específica do Oracle Database que o Autonomous ainda não suporta, workload com dependência de SO (extensão compilada, script de sistema), e licenciamento BYOL com Enterprise Edition mais opções específicas.
[BASH]
Criar Base Database Service
oci db system launch \
--compartment-id <compartment-ocid> \
--availability-domain "GrCH:SA-SAOPAULO-1-AD-1" \
--subnet-id <subnet-ocid> \
--db-home-display-name "DbHome01" \
--db-version "19.0.0.0" \
--display-name "dbcs-producao" \
--hostname "dbcs-prod-01" \
--shape "VM.Standard.E4.Flex" \
--ssh-public-keys '["<ssh-public-key>"]' \
--cpu-core-count 4 \
--database-edition "ENTERPRISE_EDITION" \
--db-name "PRODDB" \
--admin-password "Admin#2026!" \
--db-workload "OLTP"
Converged Database: JSON, Grafo e Spatial no mesmo engine
A Converged Database é o conceito que mais diferencia a Oracle das outras nuvens em banco de dados. Em vez de usar um banco de documento separado para JSON, um banco de grafo para relação complexa, um banco espacial para geolocalização, você usa Oracle Database para todos. O modelo relacional é a base, e cada modelo adicional vive como capacidade nativa do mesmo engine.
JSON nativo - o Oracle Database trata JSON como tipo de primeira classe. Coluna JSON, índice em campo específico do documento, query com SQL padrão ou via API SODA. Sem parser externo, sem driver paralelo.
[SQL]
-- Armazenamento e consulta de JSON no Oracle Database
CREATE TABLE produtos (
id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
dados JSON
);
INSERT INTO produtos (dados) VALUES (
JSON('{"nome": "Notebook Pro",
"preco": 5999.00,
"specs": {"ram": "16GB", "storage": "512GB SSD"},
"tags": ["eletronico", "computador", "premium"]}')
);
-- Consultar usando dot notation
SELECT p.dados.nome AS nome,
p.dados.preco AS preco,
p.dados.specs.ram AS ram
FROM produtos p
WHERE p.dados.preco < 7000;
-- Verificar se contém uma tag específica
SELECT p.dados.nome
FROM produtos p
WHERE JSON_EXISTS(p.dados, '$.tags[*]?(@ == "premium")');
-- Criar índice em campo JSON para performance
CREATE INDEX idxprodutopreco
ON produtos (JSON_VALUE(dados, '$.preco' RETURNING NUMBER));
Oracle Graph - permite consulta em dado modelado como grafo (nó e aresta) usando PGQL (Property Graph Query Language) ou SQL/PGQ. Os casos de uso clássicos: detecção de fraude por padrão de transação, análise de rede social, sistema de recomendação, supply chain.
[SQL]
-- Criar grafo de relacionamentos de clientes
CREATE PROPERTY GRAPH rede_social
VERTEX TABLES (clientes LABEL CLIENTE PROPERTIES (id, nome, cidade))
EDGE TABLES (
seguimentos
SOURCE KEY (seguidor_id) REFERENCES clientes(id)
DESTINATION KEY (seguido_id) REFERENCES clientes(id)
LABEL SEGUE
);
-- Buscar amigos de amigos (distância 2 no grafo)
SELECT *
FROM GRAPHTABLE (redesocial
MATCH (c1 IS CLIENTE) -[IS SEGUE]-> (c2 IS CLIENTE) -[IS SEGUE]-> (c3 IS CLIENTE)
WHERE c1.nome = 'Ana Souza'
AND c3.nome != 'Ana Souza'
COLUMNS (c1.nome AS origem, c3.nome AS amigodeamigo)
);
-- Detectar ciclos (possível indicador de fraude em redes de transações)
SELECT *
FROM GRAPHTABLE (redefinanceira
MATCH (a) -[IS TRANSFERE]-> (b) -[IS TRANSFERE]-> (a)
COLUMNS (a.contaid AS contaa, b.contaid AS contab)
);
Spatial - dado geográfico via tipo SDO_GEOMETRY e função de análise espacial. Encontrar ponto dentro de raio, calcular distância entre coordenada, verificar se ponto está dentro de polígono. Tudo via SQL.
[SQL]
-- Criar tabela com dados espaciais
CREATE TABLE lojas (
id NUMBER PRIMARY KEY,
nome VARCHAR2(200),
cidade VARCHAR2(100),
localizacao SDO_GEOMETRY
);
-- Inserir loja em São Paulo (longitude, latitude)
INSERT INTO lojas VALUES (
1,
'Loja Centro',
'São Paulo',
SDOGEOMETRY(2001, 4326, SDOPOINT_TYPE(-46.6333, -23.5505, NULL), NULL, NULL)
);
-- Criar índice espacial
CREATE INDEX idxlojasspatial ON lojas (localizacao) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
-- Encontrar todas as lojas em raio de 5km de uma coordenada
SELECT nome, cidade,
SDOGEOM.SDODISTANCE(localizacao,
SDOGEOMETRY(2001, 4326, SDOPOINT_TYPE(-46.6388, -23.5489, NULL), NULL, NULL),
0.05, 'unit=KM') AS distancia_km
FROM lojas
WHERE SDOWITHINDISTANCE(localizacao,
SDOGEOMETRY(2001, 4326, SDOPOINT_TYPE(-46.6388, -23.5489, NULL), NULL, NULL),
'distance=5 unit=KM') = 'TRUE'
ORDER BY distancia_km;
O que você precisa saber para a prova? Por que usar um engine que suporta vários modelos em vez de bancos especializados separados? A resposta envolve simplicidade operacional - apenas uma stack para administrar, menor latência (sem rede entre engines), transação ACID em diversos modelos (mantendo consistência), e segurança unificada.
MySQL HeatWave
O MySQL HeatWave é a versão Oracle do MySQL com um acelerador analítico in-memory acoplado. A proposta é juntar OLTP e analytics no mesmo sistema, sem pipeline ETL para data warehouse separado e sem latência de replicação.
Funciona assim: o HeatWave é um cluster de nós especializados em memória ligado ao MySQL. Você marca quais tabelas devem entrar, e a partir daí as queries analíticas nessas tabelas são roteadas automaticamente para o HeatWave. O MySQL continua respondendo a transações OLTP normalmente.
[SQL]
-- Carregar tabela de vendas no HeatWave para acelerar analytics
ALTER TABLE vendas SECONDARY_ENGINE=RAPID;
ALTER TABLE vendas SECONDARY_LOAD;
-- Verificar status do carregamento
SELECT TABLENAME, LOADSTATUS
FROM performanceschema.rpdtables
WHERE TABLESCHEMA = 'dbvendas';
-- Query analítica (será automaticamente roteada para HeatWave)
EXPLAIN SELECT
DATEFORMAT(datavenda, '%Y-%m') AS mes,
produto_categoria,
SUM(valor) AS total,
COUNT(*) AS transacoes
FROM vendas
WHERE datavenda >= DATESUB(NOW(), INTERVAL 12 MONTH)
GROUP BY mes, produto_categoria
ORDER BY mes DESC, total DESC;
-- Com USESECONDARYENGINE=FORCED no explain, confirma uso do HeatWave
-- Usar o recurso ML do HeatWave (treino direto no MySQL)
CALL sys.MLTRAIN('dbvendas.historico_clientes',
'churn_score',
JSON_OBJECT('task', 'classification'),
'modelochurnv1');
CALL sys.MLPREDICTROW(
JSONOBJECT('idade', 35, 'valormediomensal', 150.0, 'mesesinativo', 3),
'modelochurnv1',
NULL
);
E tem mais: o HeatWave traz ML integrado. Você treina modelo diretamente no MySQL, sem exportar dados para outra plataforma. Para várias empresas que tem MySQL em produção e quer começar a explorar ML sobre os dados do próprio negócio, isso elimina o trabalho de montar uma infraestrutura paralela.
OCI NoSQL Database
O OCI NoSQL é um banco de chave-valor e documento para workload que precisa de latência previsível em escala horizontal. Latência em milissegundo de um dígito, throughput que escala adicionando capacidade, modelo serverless sem cluster para gerenciar.
Funciona muito bem em catálogos de produtos, perfis de usuários, sessões de aplicações, catálogo de produto com leitura intensa, perfil de usuário, sessão de aplicação e dados de IoT com alta taxa de ingestão. Onde não funciona? Relações complexax entre entidades, transações ACID em múltiplas linhas e query analítica.
[PYTHON]
import borneo
from borneo import NoSQLHandle, NoSQLHandleConfig
from borneo.iam import SignatureProvider
from borneo.nosql import TableLimits, TableRequest, PutRequest, GetRequest, QueryRequest
Conectar ao OCI NoSQL
provider = SignatureProvider()
config = NoSQLHandleConfig("sa-saopaulo-1").setauthorizationprovider(provider)
handle = NoSQLHandle(config)
Criar tabela
table_request = TableRequest()
tablerequest.setstatement("""
CREATE TABLE IF NOT EXISTS sessoes_usuario (
usuario_id STRING,
sessao_id STRING,
dados JSON,
expira_em LONG,
PRIMARY KEY (SHARD(usuarioid), sessaoid)
)
""")
tablerequest.settable_limits(TableLimits(50, 50, 1)) # reads/s, writes/s, GB
handle.tablerequest(tablerequest).waitforcompletion(handle, 30000, 1000)
Inserir sessão
put_request = PutRequest()
putrequest.settablename("sessoesusuario")
putrequest.setvalue({
"usuarioid": "user12345",
"sessaoid": "sessabc_20260415",
"dados": {"carrinho": [{"produto_id": 42, "qty": 2}], "origem": "mobile"},
"expira_em": 1766000000000
})
handle.put(put_request)
Buscar sessão por chave primária (latência ~1ms)
get_request = GetRequest()
getrequest.settablename("sessoesusuario")
getrequest.setkey({"usuarioid": "user12345", "sessaoid": "sessabc_20260415"})
result = handle.get(get_request)
print(result.get_value())
Query SQL-compatible
query_request = QueryRequest()
queryrequest.setstatement(
"SELECT * FROM sessoesusuario WHERE usuarioid = 'user_12345'"
)
results = handle.query(query_request)
ORDS e Oracle APEX: desenvolvimento sobre o banco
O Oracle REST Data Services (ORDS) expõe tabela e procedure do Oracle Database como API REST automaticamente. Aplicação moderna que não quer driver JDBC na stack consome dado Oracle via HTTP. É bem útil quando você tem time front-end ou mobile que precisa falar com o banco e você quer evitar criar uma camada de API só para isso.
[SQL]
-- Habilitar ORDS para um schema
BEGIN
ORDS.ENABLE_SCHEMA(
p_enabled => TRUE,
pschema => 'VENDASAPP',
purlmappingtype => 'BASEPATH',
purlmapping_pattern => 'vendas',
pautorest_auth => FALSE
);
COMMIT;
END;
/
-- Expor uma tabela como endpoint REST automaticamente
BEGIN
ORDS.ENABLE_OBJECT(
p_enabled => TRUE,
pschema => 'VENDASAPP',
p_object => 'PEDIDOS',
pobjecttype => 'TABLE',
pautorest_auth => FALSE
);
COMMIT;
END;
/
-- Agora: GET /ords/vendas/pedidos/ retorna os pedidos
-- GET /ords/vendas/pedidos/:id retorna um pedido específico
-- POST /ords/vendas/pedidos/ insere novo pedido
-- Criar endpoint customizado com lógica de negócio
BEGIN
ORDS.DEFINE_SERVICE(
pmodulename => 'relatorios',
pbasepath => '/relatorios/',
p_pattern => 'vendas-mensais/',
p_method => 'GET',
psourcetype => ORDS.sourcetypequery,
psource => 'SELECT produtoid,
SUM(valor_total) AS total,
COUNT(*) AS qtd
FROM pedidos
WHERE TRUNC(criado_em, ''MM'') = TRUNC(SYSDATE, ''MM'')
AND status = ''ENTREGUE''
GROUP BY produto_id
ORDER BY total DESC'
);
COMMIT;
END;
/
O Oracle APEX (Application Express) é o framework de desenvolvimento low-code que roda dentro do banco Oracle. Você monta aplicação web inteira (formulário, relatório, dashboard, fluxo de workflow) pelo browser, sem servidor de aplicação separado. O banco é o runtime. Para muito uso interno de empresa, o APEX entrega aplicação funcional em horas, não semanas.
[SQL]
-- Criar página de relatório APEX programaticamente via API
DECLARE
lappid NUMBER := 100;
lpageid NUMBER;
BEGIN
-- Criar nova página no aplicativo
APEXAPPLICATIONPAGE.CREATE_PAGE(
papplicationid => lappid,
ppagealias => 'relatorio-pedidos',
ppagename => 'Relatório de Pedidos',
ppageid => lpageid
);
-- Adicionar região de relatório interativo
APEXAPPLICATIONPAGEREGIONS.CREATEREGION(
papplicationid => lappid,
ppageid => lpageid,
pregionname => 'Pedidos',
psource => 'SELECT id, clienteid, valortotal, status, criadoem
FROM pedidos
ORDER BY criado_em DESC',
pregiontype => 'NATIVE_IR' -- Interactive Report
);
END;
Data Lakehouse: Object Storage + Autonomous Database + Analytics
A arquitetura de Lakehouse da Oracle junta armazenamento barato (Object Storage) com poder analítico (Autonomous Database). O dado bruto fica no Object Storage, e o Autonomous Database lê externamente via External Table ou via Data Catalog, sem precisar mover tudo para dentro do banco. Você consulta arquivo CSV ou Parquet com SQL puro, como se fosse tabela do banco.
[SQL]
-- Criar tabela externa que lê dados CSV direto do Object Storage
CREATE TABLE vendashistoricoext (
data_venda DATE,
produto_id NUMBER,
quantidade NUMBER,
valor NUMBER,
regiao VARCHAR2(50)
)
ORGANIZATION EXTERNAL (
TYPE ORACLE_LOADER
DEFAULT DIRECTORY DATAPUMPDIR
ACCESS PARAMETERS (
RECORDS DELIMITED BY NEWLINE
SKIP 1
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
(
data_venda DATE "YYYY-MM-DD",
produto_id INTEGER EXTERNAL,
quantidade INTEGER EXTERNAL,
valor DECIMAL EXTERNAL,
regiao CHAR(50)
)
)
LOCATION ('https://objectstorage.sa-saopaulo-1.oraclecloud.com/n/<namespace>/b/datalake/o/vendas/')
)
REJECT LIMIT UNLIMITED;
-- Consultar dados do Object Storage diretamente com SQL
SELECT regiao,
SUM(quantidade) AS total_itens,
SUM(valor) AS receita_total
FROM vendashistoricoext
WHERE data_venda >= DATE '2025-01-01'
GROUP BY regiao
ORDER BY receita_total DESC;
O OCI Data Flow é o Spark serverless do OCI. Você escreve PySpark ou Scala, deixa o código no Object Storage, e submete o job. Sem cluster para subir, sem cluster para descer. Paga pelo tempo de execução.
[PYTHON]
Submeter job Spark no OCI Data Flow via CLI
import subprocess
import json
job_config = {
"compartmentId": "<compartment-ocid>",
"displayName": "processamento-logs-abril",
"applicationId": "<data-flow-app-ocid>",
"arguments": ["--data-date", "2026-04-01"],
"configuration": {
"spark.executor.memory": "4g",
"spark.executor.cores": "2"
}
}
result = subprocess.run([
"oci", "data-flow", "run", "submit",
"--from-json", json.dumps(job_config)
], capture_output=True, text=True)
E para fechar o ciclo de BI, o Oracle Analytics Cloud (OAC) é a plataforma de business intelligence gerenciada. Conecta no Autonomous Database, em outras fontes e no Object Storage. Entrega dashboard, relatório, análise aumentada com ML, e integra com os OCI AI Services.
Maximum Availability Architecture e resiliência
A Oracle tem um framework chamado MAA (Maximum Availability Architecture) que organiza estratégia de alta disponibilidade em quatro níveis: Bronze, Silver, Gold e Platinum. Cada nível habilita um conjunto de capacidades. Quanto mais alto, menor o RPO (perda potencial de dado) e o RTO (tempo até voltar).
Data Guard replica o banco para uma instância standby. Pode ser síncrono (zero perda, latência maior) ou assíncrono (perda potencial de segundo, melhor performance). Em caso de falha, o failover promove o standby para primário.
[SQL]
-- Verificar status do Data Guard
SELECT DATABASEROLE, PROTECTIONMODE, PROTECTION_LEVEL,
SWITCHOVERSTATUS, DATAGUARDBROKER
FROM V$DATABASE;
-- No Autonomous Database, configurar Autonomous Data Guard via console ou CLI
oci db autonomous-database update \
--autonomous-database-id <adb-ocid> \
--is-data-guard-enabled true \
--standby-whitelisted-ips '["0.0.0.0/0"]'
-- Verificar lag de replicação
SELECT APPLYLAG, TRANSPORTLAG
FROM V$DATAGUARD_STATS
WHERE NAME IN ('apply lag', 'transport lag');
O RAC (Real Application Clusters) permite que várias instâncias do banco acessem o mesmo storage ao mesmo tempo, provendo alta disponibilidade ativa-ativa. Se um nó morre, as sessões migram para os outros sem o usuário perceber.
Migrações: Database Migration Service e AutoUpgrade
O Database Migration Service (DMS) migra banco externo para o OCI: Oracle on-premises indo para Autonomous Database ou DBCS, PostgreSQL indo para DBCS, MySQL indo para MySQL HeatWave. O processo usa Oracle GoldenGate para replicação contínua, o que mantém o downtime baixo na hora do corte final.
[BASH]
Criar migration job no DMS via CLI
oci database-migration migration create \
--compartment-id <compartment-ocid> \
--display-name "migracao-oracle-atp" \
--type "ONLINE" \
--source-database-connection-id <source-conn-ocid> \
--target-database-connection-id <target-atp-ocid>
Validar a migration antes de executar
oci database-migration migration validate \
--migration-id <migration-ocid>
Iniciar a migration
oci database-migration migration start \
--migration-id <migration-ocid>
Monitorar progresso
oci database-migration work-request get \
--work-request-id <work-request-ocid>
O AutoUpgrade é a ferramenta para upgrade de versão do Oracle Database (de 19c para 23ai, por exemplo). Ele automatiza análises, execuções e rollback. Pode rodar upgrade em paralelo em vários bancos, o que ajuda quando você tem dezenas de instâncias para atualizar.
Parte 3 - O curso online e o ritmo de estudos
O learning path oficial no MyLearn tem cerca de 6 horas de vídeo, divididas nos domínios da prova. Os módulos de Autonomous Database, Converged Database e APEX têm boa profundidade. Migração e resiliência ficam mais por cima, o que reflete o peso menor desses domínios na prova.
O Material complementar é ótimo. Os canais da Oracle no YouTube (Oracle Learning, Oracle Database Development) têm conteúdo mais atualizado para tópico específico como JSON nativo e Graph, principalmente quando recursos novos saem.
Para laboratório, o ambiente Always Free do OCI já entrega um Autonomous Database com 1 OCPU e 20 GB, gratuito para sempre. Dá para fazer praticamente todos os labs da certificação ali mesmo - criar tabela, explorar o Database Actions, testar API SODA, configurar ORDS e brincar com query analítica. Sem precisar de cartão de crédito.
Ritmo sugerido:
Para quem tem base de banco de dados relacional e SQL, três semanas dão conta. Os conceitos fundamentais você já tem. O tempo extra vai para aprender o que é específico Oracle: Autonomous Database, Converged, APEX, ORDS, HeatWave.
Para quem está chegando em banco de dados agora, é preciso de quatro a cinco semanas. A primeira semana inteira é fundação relacional antes de entrar nos produtos.
Prazo importante: a versão 2025 se aposenta em 29 de maio de 2026, mesma data da AI Foundations. Quem quer tirar as três versões 2025, atenção nesse calendário, porque o tempo é apertado.
Parte 4 - Plano de estudos
Semana 1 - Fundamentos e Autonomous Database
Dias 1 e 2: Módulo de Introdução à gestão de dados no MyLearn. Conceito de data management strategy da Oracle, os objetivos da plataforma (simplificar, convergir, automatizar, inovar), modelos de deployment (cloud, on-premises, multicloud). Não é o domínio mais pesado, mas contextualiza tudo que vem depois.
Dias 3 e 4: Autonomous Database completo. Cubra as quatro variantes (ATP, ADW, AJD, APEX), o que "autonomous" significa na prática operacional, scaling sem downtime, backup automático, e o Database Actions como ferramenta de gerenciamento. Suba um Autonomous Database no Always Free e explore o Database Actions direto no browser.
Dia 5: Ferramentas que vivem dentro do Autonomous Database: Data Studio para carregamento e transformação, Performance Hub para análise de performance, APEX para low-code. Não é para decorar, é para entender qual ferramenta resolve o que.
Semana 2 - Compute de Dados e Desenvolvimento
Dias 1 e 2: Exadata e DBCS. Modelos de deployment do Exadata (Exadata Cloud Service, Autonomous on Exadata, ExaCC), componentes técnicos (Smart Scan, Smart Flash Cache, RDMA), e quando cada opção bate Autonomous Database como melhor escolha.
Dias 3 e 4: ORDS e Oracle APEX. Como o ORDS expõe Oracle Database como REST API, AutoREST para objeto e handler customizado. APEX como framework low-code dentro do banco. Esse domínio pesa 13% da prova e é menos familiar para quem vem de outras plataformas, então vale dedicar algum tempo.
Dia 5: Converged Database. JSON nativo com JSONVALUE, JSONEXISTS, JSONTABLE. Oracle Graph com PGQL e SQL/PGQ. Spatial com SDOGEOMETRY. Aqui você deve responder uma pergunta: por que usar um engine multi-modelo em vez de bancos especializados? Você precisa ter essa resposta na ponta da língua.
Semana 3 - Dados em Escala, Resiliência e Migração
Dias 1 e 2: MySQL HeatWave e OCI NoSQL. HeatWave: arquitetura, roteamento automático de query, ML integrado. NoSQL: modelo de dado, latência e escalabilidade, quando usar em vez de banco relacional.
Dias 3 e 4: Data Lakehouse. Object Storage como camada bruta, External Table no Autonomous Database, OCI Data Flow para processamento Spark, Oracle Analytics Cloud para BI. A distinção entre data lake, data warehouse e lakehouse cai na prova mais de uma vez.
Dia 5: Resiliência e Migrações. Data Guard (síncrono e assíncrono), MAA (Bronze a Platinum), Database Migration Service, AutoUpgrade. Peso menor na prova, mas sempre está lá.
Semana 4 - Revisão e simulados
Dias 1 e 2: Revisão focada nos pontos fracos identificados durante o estudo. Autonomous Database (16%), Data Lake/DW/ML (15%) e Desenvolvimento (13%) somam 44%. Priorize esses na revisão.
Dias 3 e 4: Dois simulados completos de 55 questões em 90 minutos. O MyLearn tem practice exam. Anote em quais domínios você errou mais.
Dia 5: Revisão final só dos erros dos simulados. Não tente revisar a prova inteira, esse não é o momento.
Parte 5 - Por que essa certificação importa
O portfólio de dados da Oracle é deliberadamente amplo. Autonomous Database com várias variantes, Converged Database com suporte nativo a JSON, grafo e espacial, MySQL com HeatWave acoplado, NoSQL gerenciado, APEX para low-code, ORDS para REST, Lakehouse com Data Flow rodando Spark. É bastante coisa.
A maioria das pessoas que trabalha com Oracle Cloud usa apenas parte desse portfólio. Muitas vezes porque descobriu o que precisava na hora em que precisou, e não mudou muito depois disso. O Autonomous Database resolve a maioria dos problemas de banco, então muita gente não vai além.
Essa certificação te força a criar um inventário de tudo que existe em dados. Você sai apresender que o Oracle Graph permite consultas de caminho em dado relacional sem stack separada, que o HeatWave elimina a necessidade de data warehouse paralelo para analytics em MySQL, que o ORDS expõe procedure Oracle como REST em minutos ou que o AI Vector Search no 23ai permite RAG sem manter um vector store à parte.
Para quem está desenhando soluções de dados em sistemas Oracle, esse mapa vale ouro. Para quem está chegando no Oracle Cloud vindo do AWS ou Azure, essa é a certificação que melhor cobre o terreno onde a Oracle difere das outras nuvens. E justamente por isso, as melhores soluções não são óbvias para quem está acostumado com outro vocabulário.
O prazo da versão atual é 29 de maio de 2026, mesma data da AI Foundations. Quem quer pegar as duas antes do prazo precisa planejar bem o tempo de estudo.
