Gerenciar Cache de Consulta

O Oracle Analytics Cloud mantém um cache local dos conjuntos de resultados de consulta no cache de consulta.

Tópicos:

Sobre o Cache de Consulta

O cache de consulta permite que o Oracle Analytics Cloud atenda a muitas solicitações de consultas subsequentes sem acessar as origens de dados de back-end e isso aumenta o desempenho da consulta. No entanto, as entradas no cache de consulta podem se tornar obsoletas à medida que ocorrem atualizações nas origens de dados de back-end.

Vantagens do Armazenamento no Cache

A maneira mais rápida de processar uma consulta é ignorar o volume do processamento e usar uma resposta pré-calculada.

Com o cache de consulta, o Oracle Analytics Cloud armazena os resultados pré-calculados das consultas em um cache local. Se outra consulta puder usar esses resultados, todo o processamento do banco de dados para essa consulta será eliminado. Isso pode resultar em grandes melhorias no tempo médio de resposta da consulta.

Além de melhorar o desempenho, poder responder a uma consulta de um cache local economiza recursos de rede e tempo de processamento no servidor de banco de dados. Economiza-se recursos de rede porque resultados intermediários não são retornados ao Oracle Analytics Cloud. A não execução da consulta no banco de dados libera o servidor de banco de dados para outros trabalhos. Se o banco de dados usar um sistema de chargeback, a execução de menos consultas poderá também cortar custos no orçamento.

Outro benefício de usar o cache para responder a uma consulta é a economia de tempo de processamento no Oracle Analytics Cloud, especialmente se os resultados da consulta são recuperados de vários bancos de dados. Dependendo da consulta, poderá haver um considerável processamento de junção e classificação no servidor. Se a consulta já estiver calculada, esse processamento será evitado, liberando recursos do servidor para outras tarefas.

Para resumir, o cache de consulta pode melhorar muito o desempenho de consulta e reduzir o tráfego da rede, o processamento do banco de dados e a sobrecarga de processamento.

Custos do Armazenamento no Cache

O cache de consulta tem muitos benefícios óbvios, mas também certos custos.

Possibilidade de que os resultados no cache se tornem obsoletos
Custos administrativos de gerenciamento do cache

Com o gerenciamento do cache, os benefícios superam em muito os custos.

Tarefas Administrativas Associadas ao Armazenamento no Cache

Algumas tarefas administrativas são associadas ao armazenamento no cache. Defina de forma correta o tempo de persistência no cache para cada tabela física, sabendo com que frequência os dados dessa tabela são atualizados.

Quando a frequência da atualização variar, rastreie o momento em que as alterações ocorrem e expurgue o cache manualmente quando necessário.

Manter o Cache Atualizado

Se as entradas no cache não forem expurgadas quando os dados dos bancos de dados subjacentes forem alterados, as consultas possivelmente retornarão resultados desatualizados.

Avalie se isso é aceitável. Pode ser aceitável permitir que o cache contenha alguns dados obsoletos. Decida que nível de dados obsoletos é aceitável e depois configure (e siga) um conjunto de regras para refletir esses níveis.

Por exemplo, suponha que um aplicativo analise dados corporativos de um grande conglomerado e que você esteja fazendo resumos anuais das diferentes divisões da empresa. Os novos dados não afetam materialmente as consultas porque só afetam os resumos do próximo ano. Nesse caso, as compensações para decidir se o cache deve ser expurgado poderão ser favoráveis a deixar as entradas no cache.

Suponha, entretanto, que os bancos de dados sejam atualizados três vezes por dia e você esteja fazendo consultas nas atividades do dia atual. Nesse caso, você deverá expurgar o cache com muito mais frequência ou talvez considerar não usar cache de forma alguma.

Outro cenário seria você reconstruir o conjunto de dados do início em intervalos periódicos (por exemplo, uma vez por semana). Nesse exemplo, você pode expurgar o cache inteiro como parte do processo de reconstrução do conjunto de dados, assegurando que nunca tenha dados obsoletos no cache.

Qualquer que seja a situação, avalie o que é aceitável para informações não atuais retornadas aos usuários.

Compartilhamento de Cache entre Usuários

Se o log-on compartilhado estiver ativado para um determinado pool de conexões, o cache poderá ser compartilhado entre os usuários e não precisará ser pré-implantado para cada usuário.

Se o log-on compartilhado não estiver ativado e um log-in no banco de dados específico do usuário for utilizado, cada usuário vai gerar sua própria entrada no cache.

Ativar ou Desativar o Cache de Consulta

No Oracle Analytics Cloud, o cache de consulta é ativado por padrão. Você pode ativar ou desativar o armazenamento em cache de consulta na página Definições Avançadas do Sistema.

Clique em Console.
Clique em Definições Avançadas do Sistema.
Clique em Desempenho e Compatibilidade.
Defina Ativação do Cache como on ou off.
- On — O cache de consulta de dados está ativado.
- Off — O cache está desativado.
Clique em Aplicar.
Dê um tempo para que o sistema atualize as alterações.

Monitorar e Gerenciar o Cache

Para gerenciar as alterações nos bancos de dados subjacentes e monitorar as entradas no cache, desenvolva uma estratégia de gerenciamento de cache.

Você precisa de um processo para invalidar as entradas no cache quando os dados das tabelas subjacentes que compõem a entrada forem alterados, além de um processo para monitorar, identificar e remover qualquer entrada indesejável.

Essa seção contém os seguintes tópicos:

Escolher uma Estratégia de Gerenciamento de Cache

A escolha de uma estratégia de gerenciamento de cache depende da volatilidade dos dados nos bancos de dados subjacentes e da capacidade de prever as mudanças que causam essa volatilidade.

Depende também do número e dos tipos de consultas que abrangem o cache e o uso que essas consultas recebem. Esta seção fornece uma visão geral das várias abordagens ao gerenciamento de cache.

Desativar o Armazenamento no Cache do Sistema

Você pode desativar o armazenamento no cache do sistema inteiro para interromper todas as novas entradas no cache e fazer com que as novas consultas parem de usar o cache existente. A desativação do armazenamento no cache permite ativá-lo posteriormente sem perder qualquer entrada armazenada.

A desativação temporária do armazenamento no cache é uma estratégia útil nas situações em que você talvez suspeite de entradas obsoletas, mas queira verificar se de fato são obsoletas antes de expurgar essas entradas ou o cache inteiro. Se você achar que os dados armazenados no cache ainda são importantes, ou depois de ter expurgado com segurança as entradas com problemas, poderá ativar o cache sem medo. Caso seja necessário, expurgue todo o cache ou o que está associado a um determinado modelo de negócios antes de ativá-lo novamente.

Cache e Tempo de Persistência no Cache para Tabelas Físicas Especificadas

Você pode definir um atributo que possa ser armazenado no cache para cada tabela física, permitindo que especifique se as consultas nessa tabela são adicionadas ao cache para responder às futuras consultas

Se você ativar o armazenamento no cache para uma tabela, toda consulta que envolver a tabela será adicionada ao cache. Todas as tabelas podem ser armazenadas no cache por padrão, mas algumas talvez não sejam candidatas ideais a serem incluídas no cache, a menos que você defina configurações de persistência de cache adequadas. Por exemplo, suponha que você tenha uma tabela que armazene dados de registro de ações que são atualizados a cada minuto. Você pode especificar que deseja limpar as entradas dessa tabela a cada 59 segundos.

Você também pode usar as definições de persistência de cache para especificar por quanto tempo as entradas dessa tabela são armazenadas no cache de consulta. Isso é útil para origens de dados atualizadas frequentemente.

No Model Administration Tool, na camada Física, clique duas vezes na tabela física.

Se você usar o Semantic Modeler, consulte Quais são as Propriedades Gerais de uma Tabela Física?.
Na caixa de diálogo de propriedades Tabela Física, na guia Geral, faça uma das seguintes seleções:
- Para ativar o armazenamento no cache, selecione Armazenável no Cache.
- Para evitar que a tabela seja armazenada no cache, desmarque a opção Armazenável no Cache.
Para definir um tempo de expiração do cache, especifique um Tempo de persistência no cache e defina uma unidade de medida (dias, horas, minutos ou segundos). Para que as entradas no cache não expirem automaticamente, selecione O cache nunca expira.
Clique em OK.

Como Alterações no Modelo Semântico Afetam o Cache de Consulta

Quando você modifica modelos semânticos usando o Semantic Modeler ou o Model Administration Tool, as alterações podem ter implicações nas entradas armazenadas no cache. Por exemplo, se você alterar a definição de um objeto físico ou uma variável de modelo semântico dinâmica, as entradas no cache que mencionam o objeto ou a variável podem não ser mais válidas. Essas alterações podem resultar na necessidade de expurgar o cache. Há dois cenários que devem ser considerados: quando você modifica seu modelo semântico existente e quando cria (ou faz upload) de um novo modelo semântico.

Alterações no Modelo Semântico

Quando você modifica um modelo semântico ou faz upload de um arquivo .rpd distinto, todas as alterações feitas que afetam as entradas no cache automaticamente resultam em uma expurgação de todas as entradas que mencionam os objetos alterados. A expurgação ocorre quando você faz upload das alterações. Por exemplo, se você excluir uma tabela física de um modelo semântico, todas as entradas no cache que mencionarem essa tabela serão expurgadas no check-in. Qualquer alteração feita em um modelo semântico na camada Lógica expurga todas as entradas do cache para esse modelo semântico.

Alterações nas Variáveis de Modelo Semântico Globais

Os valores de variáveis de modelo semântico globais são atualizados pelos dados retornados das consultas. Ao definir uma variável de modelo semântico global, você cria um bloco de inicialização ou usa um preexistente que contém uma consulta SQL. Você também configura uma programação para executar a consulta e atualizar periodicamente o valor da variável.

Se o valor de uma variável de modelo semântico global for alterado, toda entrada no cache que usar essa variável em uma coluna se tornará obsoleta e uma nova entrada no cache será gerada quando os dados dessa entrada forem novamente necessários. A antiga entrada no cache não é removida imediatamente, permanecendo até que seja limpa pelo mecanismo comum de armazenamento no cache.

Estratégias para Usar o Cache

Uma das principais vantagens do cache de consulta é melhorar o aparente desempenho da consulta.

O cache de consulta pode ser valioso para pré-implantação fora do horário de pico, executando consultas e armazenando seus resultados no cache. Uma boa estratégia de pré-implantação exige que você saiba quando há ocorrências no cache

Se você quiser pré-implantar o cache para todos os usuários, poderá fazer isso com a seguinte consulta:

SELECT User, SRs

Após a pré-implantação do cache usando SELECT User, SRs, as seguintes consultas são ocorrências no cache:

SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (e o usuário era USER1)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (e o usuário era USER2)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (e o usuário era USER3)

Essa seção contém os seguintes tópicos:

Sobre Ocorrências no Cache

Quando o armazenamento no cache está ativado, cada consulta é avaliada para determinar se ela se qualifica para uma ocorrência no cache.

Uma ocorrência no cache significa que o Oracle Analytics Cloud conseguiu usar o cache para responder à consulta e não acessou o banco de dados. O Oracle Analytics Cloud pode usar o cache de consulta para responder às consultas no mesmo nível de agregação ou mais alto.

Muitos fatores determinam se houve ocorrência no cache. A tabela a seguir descreve esses fatores.

Fator ou Regra	Descrição
Um subconjunto de colunas na lista `SELECT` deve corresponder.	Todas as colunas na lista `SELECT` de uma nova consulta devem existir na consulta armazenada no cache para qualificação a uma ocorrência no cache ou devem poder ser calculadas com base nas colunas da consulta. Essa regra descreve o requisito mínimo para ocorrência no cache, mas o cumprimento dessa regra não garante uma ocorrência. As outras regras listadas nessa tabela também se aplicam.
As colunas na lista `SELECT` podem ser compostas por expressões nas colunas das consultas armazenadas no cache.	O Oracle Analytics Cloud pode calcular expressões nos resultados armazenados no cache para responder à nova consulta, mas todas as colunas devem estar no resultado armazenado no cache. Por exemplo, a consulta: SELECT product, month, averageprice FROM sales WHERE year = 2000 atinge o cache na consulta: SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000 porque `averageprice` pode ser calculado em `dollars` e `unitsales` (`averageprice = dollars/unitsales`).
A cláusula `WHERE` deve ser semanticamente a mesma ou um subconjunto lógico	Para que a consulta se qualifique como ocorrência no cache, as restrições da cláusula `WHERE` devem ser equivalentes aos resultados armazenados no cache ou um subconjunto desses resultados. Uma cláusula `WHERE` que é um subconjunto lógico de uma consulta armazenada no cache se qualificará para uma ocorrência no cache se o subconjunto atender a um dos seguintes critérios: Um subconjunto de valores de lista `IN`. As consultas que solicitam menos elementos de uma consulta de lista `IN` armazenada no cache se qualificam para uma ocorrência no cache. Por exemplo, a seguinte consulta: SELECT employeename, region FROM employee, geography WHERE region in ('EAST', 'WEST') se qualifica como ocorrência na seguinte consulta armazenada no cache: SELECT employeename, region FROM employee, geography WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST') Ela contém menos (mas idênticas) restrições `OR` do que o resultado armazenado no cache. Ela contém um subconjunto lógico de uma comparação literal. Por exemplo, o seguinte predicado: WHERE revenue < 1000 se qualifica como ocorrência no cache em uma consulta comparável com o predicado: WHERE revenue < 5000 Não há cláusula `WHERE`. Se uma consulta sem cláusula `WHERE` for armazenada no cache, as consultas que satisfizerem todas as outras regras de ocorrência no cache se qualificarão como ocorrências no cache, independentemente de suas cláusulas `WHERE`. Além disso, as colunas usadas na cláusula `WHERE` devem estar na lista de projeção. Por exemplo, a seguinte consulta: SELECT employeename FROM employee, geography WHERE region in ('EAST', 'WEST') Não resulta em uma ocorrência no cache para a consulta de pré-implantação na lista anterior porque REGION não está na lista de projeção.
As consultas somente dimensão devem ser uma correspondência exata	Se uma consulta for somente dimensão, significando que nenhum fato ou medida está incluído nela, somente uma correspondência exata das colunas de projeção da consulta armazenada no cache atingirão o cache. Esse comportamento evita falsos positivos quando há várias origens lógicas para uma tabela de dimensão.
As consultas com funções especiais devem ser uma correspondência exata	Outras consultas contendo funções especiais, como série de tempo (`AGO`, `TODATE` e `PERIODROLLING`), funções de limite e deslocamento (`OFFSET` e `FETCH`), funções de relacionamento (`ISANCESTOR`, `ISLEAF`, `ISROOT` e `ISSIBLING`), funções de agregação externa e geralmente métricas de filtro também devem ser uma correspondência exata com as colunas de projeção na consulta armazenada no cache. Nesses casos, o filtro também deve ser uma correspondência exata. Para métricas de filtro, se for possível regravar a métrica como cláusula `WHERE`, o cache de subconjunto poderá ser utilizado.
O conjunto de tabelas lógicas deve corresponder	Para que se qualifiquem como ocorrência no cache, todas as consultas de entrada devem ter o mesmo conjunto de tabelas lógicas que a entrada no cache. Essa regra evita falsas ocorrências no cache. Por exemplo, `SELECT * FROM product` não corresponde a `SELECT * FROM product, sales`.
Os valores de variável de sessão devem corresponder, inclusive variáveis de sessão de segurança	Se a instrução SQL lógica ou física se referir a qualquer variável de sessão, os valores das variáveis deverão corresponder. Caso contrário, o cache não será atingido. Além disso, o valor das variáveis de sessão sensíveis à segurança devem corresponder aos valores de variável de sessão de segurança definidos no modelo semântico, mesmo que a própria instrução SQL lógica não mencione variáveis de sessão. Consulte Assegurar Resultados Corretos do Cache ao Usar a Segurança do Banco de Dados no Nível de Linha.
Condições de junção equivalentes	A tabela lógica resultante unida de uma nova solicitação de consulta deve ser a mesma (ou um subconjunto) dos resultados armazenados no cache para se qualificar a uma ocorrência no cache.
O atributo `DISTINCT` deve ser o mesmo	Se uma consulta armazenada no cache eliminar registros duplicados com processamento `DISTINCT` (por exemplo, `SELECT DISTINCT`...), as solicitações para as colunas armazenadas no cache também deverão incluir o processamento `DISTINCT`; uma solicitação para a mesma coluna sem o processamento `DISTINCT` é uma ausência no cache.
As consultas devem conter níveis de agregação compatíveis	As consultas que solicitam um nível agregado de informações podem usar resultados armazenados no cache em um nível mais baixo de agregação. Por exemplo, a seguinte consulta solicita a quantidade vendida no nível de fornecedor, região e cidade: SELECT supplier, region, city, qtysold FROM suppliercity A seguinte consulta solicita a quantidade vendida no nível de cidade: SELECT city, qtysold FROM suppliercity A segunda consulta resulta em uma ocorrência no cache na primeira consulta.
Agregação adicional limitada	Por exemplo, se uma consulta com a coluna `qtysold` for armazenada no cache, uma solicitação para `RANK(qtysold)` resultará em uma ausência no cache. Além disso, uma consulta que solicita `qtysold` no nível de país pode obter uma ocorrência no cache de uma consulta que solicita `qtysold` no nível de país, região.
A cláusula `ORDER BY` deve ser composta por colunas na lista de seleção	As consultas ordenadas por colunas que não estão contidas na lista de seleção resultam em ausências no cache.
Diagnosticando o comportamento de ocorrência no cache	Para avaliar melhor o comportamento de ocorrência no cache, defina a variável de sessão ENABLE_CACHE_DIAGNOSTICS como 4, conforme mostrado no seguinte exemplo: ENABLE_CACHE_DIAGNOSTICS=4

Assegurar Resultados Corretos do Cache ao Usar a Segurança do Banco de Dados no Nível de Linha

Ao usar uma estratégia de segurança de banco de dados de nível de linha, como um Banco de Dados Privado Virtual (VPD), os resultados dos dados retornados são contingentes nas credenciais de autorização do usuário.

Por causa disso, o Oracle Analytics Cloud deve saber se uma origem de dados está usando a segurança de banco de dados de nível de linha e quais variáveis são pertinentes à segurança.

Para garantir que as ocorrências de cache ocorram apenas em entradas de cache que incluam e correspondam a todas as variáveis sensíveis à segurança, você deve configurar corretamente o objeto de banco de dados e os objetos de variável de sessão no Oracle Analytics Developer Client Tool, da seguinte forma:

Objeto de banco de dados. Na camada Física, na guia Geral da caixa de diálogo Banco de Dados, selecione Banco de Dados Privado Virtual para especificar que a origem de dados está usando a segurança de banco de dados de nível de linha.

Se você estiver usando a segurança de banco de dados de nível de linha com armazenamento em cache compartilhado, você deverá selecionar essa opção para evitar o compartilhamento de entradas no cache cujas variáveis sensíveis à segurança não sejam correspondentes.
Objeto de Variável de Sessão. Para variáveis relacionadas à segurança, na caixa de diálogo Variável de Sessão, selecione Sensível à Segurança para identificá-las como sensíveis à segurança ao usar uma estratégia de segurança de banco de dados de nível de linha. Essa opção assegura que as entradas no cache sejam marcadas com as variáveis sensíveis à segurança, ativando a correspondência de variável sensível à segurança em todas as consultas de entrada.

Executar uma Suíte de Consultas para Preencher o Cache

Para maximizar possíveis ocorrências no cache, uma estratégia seria executar uma suíte de consultas para preencher o cache.

Seguem algumas recomendações para os tipos de consultas a serem usadas na criação de uma suíte de consultas com a qual pré-implantar o cache.

Consultas pré-construídas comuns. As consultas comumente executadas, especialmente aquelas cujo processamento é dispendioso, são excelentes consultas de pré-implantação do cache. As consultas cujos resultados são integrados em painéis de controle são bons exemplos de consultas comuns.
Listas SELECT sem expressões. A eliminação de expressões nas colunas de listas SELECT expande a possibilidade de ocorrências no cache. Uma coluna no cache com uma expressão só pode responder a uma nova consulta com a mesma expressão, enquanto uma sem expressões pode responder a uma solicitação dessa coluna com qualquer expressão. Por exemplo, uma solicitação no cache como:
```
SELECT QUANTITY, REVENUE...
```
pode responder a uma nova consulta como:
```
SELECT QUANTITY/REVENUE... 
```
mas não o contrário.
Nenhuma cláusula WHERE. Se não houver cláusula WHERE em um resultado armazenado no cache, ele poderá ser usado para responder consultas que atendam às regras de ocorrência no cache para a lista de seleção com qualquer cláusula WHERE que inclua colunas na lista de projeção.

Em geral, as melhores consultas com as quais pré-implantar o cache são aquelas com alto consumo de recursos de processamento do banco de dados e que provavelmente serão emitidas novamente. Tenha cuidado para não pré-implantar o cache com consultas simples que retornam muitas linhas. Essas consultas (por exemplo, SELECT * FROM PRODUCTS, em que PRODUCTS é mapeado diretamente para uma única tabela de banco de dados) exigem muito pouco processamento do banco de dados. Seu custo é a sobrecarga de rede e disco, que são fatores que o armazenamento no cache não reduz.

Quando o Oracle Analytics Cloud atualiza variáveis de modelo semântico, ele examina os modelos de negócios para determinar se eles mencionam essas variáveis de modelo semântico. Se a resposta for sim, o Oracle Analytics Cloud expurgará todo o cache desses modelos de negócios. Consulte Como Alterações no Modelo Semântico Afetam o Cache de Consulta.

Usar Agentes para Pré-implantar o Cache de Consulta

Você pode configurar agentes para pré-implantar o cache de consulta do Oracle Analytics Cloud.

A pré-implantação do cache pode melhorar os tempos de resposta para os usuários quando eles executam ou exibem análises integradas em seus painéis de controle. Você pode fazer isso programando os agentes para executarem solicitações que atualizem esses dados.

No Oracle Analytics Cloud, abra a Home page Clássica e selecione Agente (seção Criar).
Na guia Geral, selecione Destinatário para a opção Executar como. A pré-implantação personalizada do cache usa a visibilidade de dados de cada destinatário para personalizar o conteúdo de entrega do agente para cada destinatário.
Na guia Programação, especifique quando deseja que o cache seja pré-implantado.
Opcional: Selecione Condição e crie ou selecione uma solicitação condicional. Por exemplo, você poderá ter um modelo de negócios que determine quando o processo ETL é concluído. Você poderá usar um relatório com base nesse modelo de negócios que deverá ser o trigger condicional para que a pré-implantação do cache comece.
Na guia Conteúdo de Entrega, selecione uma solicitação individual ou uma página de painel de controle inteira cujo cache você deseja pré-implantar. A seleção de uma página do painel de controle pode economizar tempo.
Na guia Destinatários, selecione usuários individuais ou grupos que deverão ser os destinatários.
Na guia Destinos, limpe todos os destinos do usuário e selecione Cache do Oracle Analytics Server.
Salve o agente selecionando o botão Salvar no canto superior direito.

A única diferença entre os agentes de pré-implantação do cache e outros agentes é que eles limpam o cache anterior automaticamente e não aparecem no painel de controle como alertas.

Nota:

Os agentes de pré-implantação do cache só expurgam as consultas de correspondência exata, por isso ainda poderão existir dados desatualizados. Assegure-se de que a estratégia de armazenamento no cache sempre inclua expurgação do cache, porque as consultas do agente não tratam consultas ou drills ad-hoc.

Usar o Model Administration Tool para Expurgar Automaticamente o Cache de Tabelas Específicas

A expurgação do cache exclui as entradas do cache de consulta e mantém o conteúdo atual. Você pode expurgar automaticamente as entradas no cache para tabelas específicas, definindo o campo Tempo de Persistência no Cache para cada tabela no Model Administration Tool.

Nota:

Se você usar o Semantic Modeler, consulte Quais são as Propriedades Gerais de uma Tabela Física?

Isso é útil para origens de dados atualizadas frequentemente. Por exemplo, se você tiver uma tabela que armazene dados de registro de ações atualizados por minuto, poderá usar a definição Tempo de Persistência no Cache para expurgar as entradas dessa tabela a cada 59 segundos. Consulte Cache e Tempo de Persistência no Cache para Tabelas Físicas Especificadas.