APRENDER. PRATICAR. EVOLUIR.Traduzir atualidade em requisitos de cada operação
Num portal fictício de fundos, a lista de processos pode tolerar alguns segundos de atraso, enquanto a confirmação de uma instrução tem de mostrar a escrita que acabou de terminar. São ambos SELECT, mas os contratos de serviço são diferentes. Antes de desenhar o encaminhamento, regista para cada operação o requisito de atualidade, a identidade autorizada, a reação a atraso e o comportamento em falha. True Cache pode fornecer um estado consistente confirmado que ainda não inclui a alteração mais recente do primary. A ausência temporária na cache não justifica repetir uma escrita financeira. O diagnóstico deve preservar a referência do pedido, confirmar o resultado da transação e usar uma rota de leitura adequada. Estes exemplos são fictícios e não representam procedimentos de uma instituição.
Verificar o modelo de ligação em uso
Com duas ligações físicas, a aplicação escolhe explicitamente o serviço do primary ou o da cache. O desenho com uma ligação lógica JDBC Thin requer suporte e configuração True Cache no cliente, além do modo read-only usado para selecionar leituras elegíveis. Não basta encontrar a palavra SELECT no código nem uma cache no inventário. O modelo de pool OCI de 26ai, disponível a partir do RU 23.26.0, tem opções distintas para pedir a cache ou preferi-la com fallback para o primary; aqui OCI significa Oracle Call Interface. O handover deve identificar a versão do cliente, propriedades aplicadas, serviço efetivo e modo de cada operação. Um teste deve observar a rota utilizada, incluindo a devolução de ligações ao pool. A configuração pretendida não é prova de que todas as ligações receberam o estado correto.
Escolher a instância e a métrica corretas
V$TRUE_CACHE mostra relações e estado da configuração: o primary pode apresentar uma linha por cache, enquanto a cache apresenta a relação com o seu primary. V$TRUE_CACHE_STAT deve ser consultada no True Cache; não devolver linhas no primary não significa atraso zero. Regista nome da métrica, unidade, instância, TIME_COMPUTED e DATA_TIME. Uma medição recalculada sobre dados cuja receção parou não demonstra sincronização atual. A documentação também distingue métricas que não são significativas neste contexto, como estimated startup time e apply finish time. Não as converte num SLA só porque aparecem na view. No relatório de incidente, separa ligação saudável, atraso de aplicação, latência de obtenção de blocos e latência percebida pela aplicação.
Preparar aquecimento, fallback e carga no primary
Depois de um arranque, as primeiras consultas podem exigir obtenção de blocos que ainda não residem na cache. Compara a mesma carga em condições frias e aquecidas, conservando o estado inicial e as medições. Uma cache com bons tempos depois de aquecer não demonstra o comportamento imediatamente após recuperação. Quando o cliente permite fallback, a indisponibilidade da cache pode concentrar leituras no primary que continua a processar escritas. Inclui essa combinação no ensaio de capacidade e define limites de admissão de carga. O plano deve identificar quem decide degradar uma consulta informativa e quem pode autorizar a passagem de tráfego. Não se atribui sucesso de recuperação apenas porque uma sessão voltou a ligar.
Distinguir escrita redirecionada e conflito de versão
DML redirection envia a alteração para o primary e a cache recebe depois a atualização correspondente. Esta opção não cria um primary de escrita independente; acrescenta um percurso cujo custo deve ser avaliado, sobretudo num serviço intensivo em escritas. Para um documento JSON protegido por ETAG, uma edição baseada numa versão antiga pode ser rejeitada no primary quando os dados já mudaram. A resposta adequada é reler e reconciliar a intenção de alteração, com as regras de negócio aplicáveis. Repetir cegamente o mesmo pedido ou retirar a validação de versão pode esconder o conflito. O gestor técnico deve incluir concorrência e resultado ambíguo no plano de testes, conservando identificadores de pedido e critérios claros para nova tentativa.
Exercício de desenho: oito decisões com evidência
O quadro abaixo é um exercício de mesa original, sem instância True Cache executada. Para cada linha, escolhe a rota ou investigação, a evidência que falta e uma condição que impede aceitação. A permite cache apenas dentro da tolerância acordada e com uma medição válida. B exige uma leitura que inclua a escrita confirmada; preserva a referência e não repete a escrita por omissão na cache. C é conflito ETAG e exige reconciliação. D pede a consulta de estatísticas na instância correta. E exige investigar a idade da telemetria antes de usar o valor. F pede avaliar a carga de fallback no primary. G exige comparar arranque frio e cache aquecida. H mantém a conclusão limitada à relação saudável; faltam critérios de serviço. Entrega uma matriz com owner, rota, observação e decisão. Uma solução é incompleta se usa HEALTHY como prova de todas as propriedades.
Exercício de mesa. Valores e contratos fictícios; não são telemetria real.
ID | Operação/sintoma | Condição conhecida
A | Lista de processos | Tolerância aprovada de 5 s; amostra recente de atraso de 2 s
B | Confirmação do pedido R-718 | Commit confirmado no primary; leitura da cache omite o pedido
C | Edição do documento D-22 | Outro utilizador alterou a versão; PUT com ETAG anterior rejeitado
D | Diagnóstico de atraso | V$TRUE_CACHE_STAT sem linhas; consulta feita no primary
E | Dashboard de lag | DATA_TIME parado às 11:12; TIME_COMPUTED avança até 11:20
F | Falha da cache | Cliente permite fallback; primary já processa o batch de fecho
G | Reinício da cache | Leituras iniciais lentas; sem comparação controlada fria/quente
H | Gate de entrega | V$TRUE_CACHE indica HEALTHY; não há medições da aplicação
Entregável: uma linha por caso com rota/investigação, owner, evidência e critério de bloqueio.HEALTHY não prova que a confirmação R-718 já está visível na cache.
Armadilhas comuns
Tratar SELECT como tolerância a atraso; confundir estado global com SLA; usar métricas da instância errada; repetir escritas após uma leitura desatualizada.
Tópicos relacionados: Pesquisa vetorial e migração de modelos · Visibilidade e fronteiras de transação · True Cache, reservas e evidência de auditoria
A decisão de usar cache depende do contrato da operação e de evidência atual da rota e do serviço.
Referência: Overview of Oracle True Cache · 1Z0-183 public objectives inspected 2026-09-30; revision date not published