Gerir a Colocação na Cache de Consultas

O Oracle Analytics Cloud mantém uma cache local de conjuntos de resultados de consultas na cache de consultas.

Tópicos:

Acerca da Cache de Consultas

A cache de consultas permite ao Oracle Analytics Cloud satisfazer muitos pedidos de consulta subsequentes sem aceder a origens de dados de back-end, o que aumenta o desempenho da consulta. No entanto, as entradas da cache de consultas podem ficar obsoletas à medida que ocorrem atualizações nas origens de dados de back-end.

Vantagens da Colocação na Cache

A forma mais rápida de processar uma consulta é saltar a maior parte do processamento e utilizar uma resposta pré-calculada.

Com a colocação na cache de consultas, o Oracle Analytics Cloud armazena os resultados pré-calculados das consultas numa cache local. Se outra consulta puder utilizar esses resultados, todo o processamento da base de dados para essa consulta é eliminado. Isto pode resultar em acentuadas melhorias no tempo médio de resposta da consulta.

Além de melhorar o desempenho, a capacidade para responder a uma consulta a partir de uma cache local preserva os recursos da rede e o tempo de processamento no servidor da base de dados. Os recursos da rede são preservados porque não são devolvidos resultados intermédios ao Oracle Analytics Cloud. A não execução da consulta na base de dados liberta o servidor da base de dados para realizar outro trabalho. Se a base de dados utilizar um sistema de "charge back", a execução de menos consultas poderá também reduzir os custos no orçamento.

Outro benefício da utilização da cache para responder a uma consulta é a poupança no tempo de processamento no Oracle Analytics Cloud, especialmente se os resultados da consulta forem obtidos de várias bases de dados. Dependendo da consulta, poderá ocorrer um processamento considerável de junção e ordenação no servidor. Se a consulta já estiver calculada, este processamento é evitado, libertando recursos do servidor para outras tarefas.

Em resumo, a colocação na cache de consultas pode melhorar drasticamente o desempenho das consultas e reduzir o tráfego de rede, o processamento da base de dados e a sobrecarga de processamento.

Custos da Colocação na Cache

A colocação na cache de consultas tem muitos benefícios óbvios, mas também determinados custos.

Possibilidade de os resultados em cache serem obsoletos
Custos administrativos de gestão da cache

Com a gestão da cache, normalmente os benefícios ultrapassam em muito os custos.

Tarefas Administrativas Associadas à Colocação em Cache

Existem algumas tarefas administrativas associadas à colocação na cache. Deve definir adequadamente o tempo de persistência da cache para cada tabela física, sabendo com que frequência os dados dessa tabela são atualizados.

Se a frequência da atualização variar, deve controlar quando ocorrem as alterações e eliminar a cache manualmente quando for necessário.

Manter a Cache Atualizada

Se as entradas da cache não forem eliminadas quando os dados nas bases de dados subjacentes forem alterados, as consultas podem potencialmente devolver resultados desatualizados.

Deve avaliar se isto é aceitável. Poderá ser aceitável permitir que a cache contenha alguns dados obsoletos. Deve decidir que nível de dados obsoletos é admissível e depois configurar (e seguir) um conjunto de regras para refletir esses níveis.

Por exemplo, suponha que uma aplicação analisa os dados empresariais de um grande conglomerado e que está a efetuar resumos anuais das diferentes divisões da empresa. Os novos dados não afetam materialmente as consultas porque só afetam os resumos do ano seguinte. Neste caso, as contrapartidas para decidir se a cache deve ser eliminada podem favorecer a manutenção das entradas na cache.

Contudo, suponha que as bases de dados são atualizadas três vezes por dia e que está a efetuar consultas sobre as atividades do dia atual. Neste caso, deve eliminar a cache com muito mais frequência ou talvez considerar não utilizar a cache de todo.

Outro cenário é recriar o conjunto de dados desde o início a intervalos periódicos (por exemplo, uma vez por semana). Neste exemplo, pode eliminar toda a cache como parte do processo de recriação do conjunto de dados, garantindo que nunca tem dados obsoletos na cache.

Qualquer que seja a sua situação, deve avaliar o que é aceitável em termos de informações não atuais devolvidas aos utilizadores.

Partilha da Cache Entre Utilizadores

Se a entrada em sessão partilhada estiver ativada para um determinado pool de ligações, a cache pode ser partilhada entre utilizadores e não necessita de ser criada para cada utilizador.

Se a entrada em sessão partilhada não estiver ativada e for utilizada uma entrada em sessão na base de dados específica do utilizador, cada utilizador gera a sua própria entrada da cache.

Ativar ou Desativar a Colocação na Cache de Consultas

No Oracle Analytics Cloud, a cache de consultas está ativada por omissão. Pode ativar ou desativar a colocação na cache de consultas na página Definições do Sistema.

Clique em Consola.
Clique em Definições do Sistema.
Clique em Desempenho e Compatibilidade.
Defina Ativação da Cache como ativado ou desativado.
- Ativado — A colocação na cache de consultas de dados está ativada.
- Desativado — A colocação na cache está desativada.
Clique em Aplicar.
Aguarde alguns momentos para que as alterações sejam renovadas no sistema.

Monitorizar e Gerir a Cache

Para gerir as alterações nas bases de dados subjacentes e para monitorizar as entradas da cache, deverá desenvolver uma estratégia de gestão da cache.

É necessário um processo para invalidar as entradas da cache quando os dados nas tabelas subjacentes que compõem a entrada da cache são alterados, assim como um processo para monitorizar, identificar e retirar as entradas da cache indesejáveis.

Este capítulo contém os seguintes tópicos:

Escolher uma Estratégia de Gestão da Cache

A escolha de uma estratégia de gestão da cache depende da volatilidade dos dados nas bases de dados subjacentes e da previsibilidade das alterações que causam esta volatilidade.

Depende também do número e dos tipos de consultas que compõem a sua cache e da utilização dada a essas consultas. Esta secção fornece uma perspetiva geral das várias abordagens à gestão da cache.

Desativar a Colocação na Cache para o Sistema

Pode desativar a colocação na cache para todo o sistema, de modo a impedir todas as novas entradas da cache e impedir que as novas consultas utilizem a cache existente. A desativação da colocação na cache permite-lhe ativá-la mais tarde, sem perder as entradas armazenadas na cache.

A desativação temporária da colocação na cache é uma estratégia útil se suspeitar que poderá ter entradas da cache obsoletas, mas quer verificar se são realmente obsoletas antes de eliminar essas entradas ou toda a cache. Se verificar que os dados armazenados na cache ainda são relevantes, ou após ter eliminado de forma segura as entradas com problemas, poderá ativar a cache com segurança. Se for necessário, elimine toda a cache ou a cache que está associada a um determinado modelo de negócio antes de voltar a ativar a cache.

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

Pode definir um atributo passível de colocação na cache para cada tabela física, o que lhe permite especificar se as consultas para essa tabela são acrescentadas à cache para responder a consultas futuras.

Se ativar a colocação na cache para uma tabela, qualquer consulta que envolva a tabela é acrescentada à cache. Todas as tabelas são passíveis de colocação na cache por omissão, mas algumas podem não ser adequadas para inclusão na cache, a menos que configure definições de persistência da cache apropriadas. Por exemplo, suponha que tem uma tabela que armazena dados de cotações da bolsa que são atualizados a cada minuto. Pode especificar que pretende eliminar as entradas dessa tabela a cada 59 segundos.

Também pode utilizar as definições de persistência da cache para especificar quanto tempo as entradas desta tabela ficam armazenadas na cache de consultas. Isto é útil para as origens de dados que são atualizadas frequentemente.

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

Se utiliza o Modelador Semântico, consulte Quais São as Propriedades Gerais de uma Tabela Física?.
Na caixa de diálogo de propriedades da Tabela Física, no separador Geral, efetue uma das seguintes seleções:
- Para ativar a colocação na cache, selecione Passível de Colocação na Cache.
- Para impedir que uma tabela seja colocada na cache, anule a seleção de Passível de Colocação na Cache.
Para definir um tempo de expiração da cache, especifique um Tempo de persistência da cache e especifique uma unidade de medida (dias, horas, minutos ou segundos). Se não quiser que as entradas da cache expirem automaticamente, selecione A cache nunca expira.
Clique em OK.

Como as Alterações ao Modelo Semântico Afetam a Cache de Consultas

Quando modifica modelos semânticos utilizando o Modelador Semântico ou o Model Administration Tool, as alterações podem ter implicações para as entradas armazenadas na cache. Por exemplo, se alterar a definição de um objeto físico ou de uma variável de modelo semântico dinâmica, as entradas da cache que fazem referência a esse objeto ou essa variável poderão deixar de ser válidas. Estas alterações podem resultar na necessidade de eliminar a cache. Existem dois cenários a ter em conta: quando modifica o seu modelo semântico existente e quando cria (ou carrega) um novo modelo semântico.

Alterações ao Modelo Semântico

Quando modifica um modelo semântico ou carrega um ficheiro .rpd diferente, as alterações efetuadas que afetam entradas da cache resultam automaticamente numa eliminação de todas as entradas da cache que fazem referência aos objetos alterados. A eliminação ocorre ao carregar as alterações. Por exemplo, se apagar uma tabela física de um modelo semântico, todas as entradas da cache que fazem referência a essa tabela são eliminadas na altura do registo de entrada. Quaisquer alterações efetuadas num modelo semântico na camada Lógica irão eliminar todas as entradas da cache desse modelo semântico.

Alterações às Variáveis do Modelo Semântico Globais

Os valores das variáveis do modelo semântico globais são renovados pelos dados que são devolvidos das consultas. Quando define uma variável de modelo semântico global, cria um bloco de inicialização ou utiliza um preexistente que contenha uma consulta de SQL. Também configura uma agenda para executar a consulta e renovar periodicamente o valor da variável.

Se o valor de uma variável de modelo semântico global for alterado, qualquer entrada da cache que utilize esta variável numa coluna torna-se obsoleta e é gerada uma nova entrada da cache quando os dados nessa entrada são novamente necessários. A entrada da cache antiga não é retirada imediatamente, permanecendo até ser limpa através do mecanismo de colocação na cache habitual.

Estratégias para Utilizar a Cache

Uma das principais vantagens da colocação na cache de consultas é melhorar o desempenho aparente das consultas.

A colocação na cache de consultas pode ser valiosa para criar a cache fora do horário de expediente, executando as consultas e colocando na cache os respetivos resultados. Uma boa estratégia de criação requer que saiba quando ocorrem os sucessos da cache.

Se pretender criar a cache para todos os utilizadores, poderá criar a cache com a seguinte consulta:

SELECT User, SRs

Após criar a cache utilizando SELECT User, SRs, as seguintes consultas são sucessos da cache:

SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER1)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER2)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER3)

Este capítulo contém os seguintes tópicos:

Acerca dos Sucessos da Cache

Quando a colocação na cache está ativada, cada consulta é avaliada para determinar se se qualifica para um sucesso da cache.

Um sucesso da cache significa que o Oracle Analytics Cloud conseguiu utilizar a cache para responder à consulta sem ter de recorrer à base de dados. O Oracle Analytics Cloud pode utilizar a cache de consultas para responder a consultas ao mesmo nível ou a um nível superior de agregação.

Muitos fatores determinam o sucesso da cache. A tabela abaixo descreve estes fatores.

Fator ou Regra	Descrição
Um subconjunto de colunas na lista `SELECT` deve corresponder	Todas as colunas da lista `SELECT` de uma nova consulta têm de existir na consulta em cache para se qualificarem para um sucesso da cache ou é necessário que possam ser calculadas a partir das colunas na consulta. Esta regra descreve o requisito mínimo para o sucesso da cache, mas o cumprimento desta regra não garante um sucesso da cache. As outras regras listadas nesta tabela também se aplicam.
As colunas na lista `SELECT` podem ser compostas por expressões nas colunas das consultas em cache	O Oracle Analytics Cloud pode calcular expressões nos resultados em cache para responder à nova consulta, mas todas as colunas devem estar no resultado em cache. Por exemplo, a consulta: SELECT product, month, averageprice FROM sales WHERE year = 2000 obtém um sucesso da cache na consulta: SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000 porque `averageprice` pode ser calculado a partir de `dollars` e `unitsales` (`averageprice = dollars/unitsales`).
A cláusula `WHERE` deve ser semanticamente idêntica ou um subconjunto lógico	Para que a consulta se qualifique como um sucesso da cache, as restrições da cláusula `WHERE` devem ser equivalentes aos resultados em cache ou um subconjunto dos resultados em cache. Uma cláusula `WHERE` que seja um subconjunto lógico de uma consulta em cache qualifica-se para um sucesso da cache se o subconjunto cumprir um dos seguintes critérios: Um subconjunto de valores da lista `IN`. As consultas que pedem menos elementos de uma consulta em cache da lista `IN` qualificam-se para um sucesso da cache. Por exemplo, a consulta seguinte: SELECT employeename, region FROM employee, geography WHERE region in ('EAST', 'WEST') qualifica-se como um sucesso na consulta em cache seguinte: SELECT employeename, region FROM employee, geography WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST') Contém menos restrições `OR` (mas idênticas) do que o resultado em cache. Contém um subconjunto lógico de uma comparação literal. Por exemplo, o predicado seguinte: WHERE revenue < 1000 qualifica-se como um sucesso da cache numa consulta comparável com o predicado: WHERE revenue < 5000 Não existe nenhuma cláusula `WHERE`. Se existir uma consulta sem uma cláusula `WHERE` colocada na cache, as consultas que satisfizerem todas as outras regras de sucesso da cache qualificam-se como sucessos da cache independentemente da respetiva cláusula `WHERE`. Além disso, as colunas que são utilizadas na cláusula `WHERE` devem existir na lista de projeções. Por exemplo, a consulta seguinte: SELECT employeename FROM employee, geography WHERE region in ('EAST', 'WEST') Não resulta num sucesso da cache para a consulta de criação na lista anterior porque REGION não está na lista de projeções.
As consultas só de dimensão devem ser uma correspondência exata	Se uma consulta for só de dimensão, o que significa que nenhum facto ou medida está incluído na consulta, apenas uma correspondência exata das colunas de projeção da consulta em cache será um sucesso da cache. Este comportamento impede falsos positivos quando existem várias origens lógicas para uma tabela de dimensões.
As consultas com funções especiais devem ser uma correspondência exata	As outras consultas que contêm funções especiais, como funções de série de tempo (`AGO`, `TODATE` e `PERIODROLLING`), funções de limite e diferencial (`OFFSET` e `FETCH`), funções de relação (`ISANCESTOR`, `ISLEAF`, `ISROOT` e `ISSIBLING`), funções de agregação externa e, em geral, as métricas do filtro também devem ser uma correspondência exata com as colunas de projeção na consulta em cache. Nestes casos, o filtro também deve ser uma correspondência exata. Para as métricas do filtro, se for possível reescrever a métrica do filtro como uma cláusula `WHERE`, poderá tirar partido da cache do subconjunto.
O conjunto de tabelas lógicas deve corresponder	Para se qualificarem como um sucesso da cache, todas as consultas recebidas devem ter o mesmo conjunto de tabelas lógicas que a entrada da cache. Esta regra evita sucessos da cache falsos. Por exemplo, `SELECT * FROM product` não corresponde a `SELECT * FROM product, sales`.
Os valores das variáveis da sessão devem corresponder, incluindo as variáveis da sessão de segurança	Se a instrução de SQL lógico ou SQL físico fizer referência a qualquer variável da sessão, os valores das variáveis da sessão devem corresponder. Caso contrário, não ocorre um sucesso da cache. Além disso, o valor das variáveis da sessão que são sensíveis à segurança deve corresponder aos valores das variáveis da sessão de segurança definidos no modelo semântico, mesmo que a própria instrução de SQL lógico não faça referência às variáveis da sessão. Consulte Assegurar Resultados da Cache Corretos ao Utilizar a Segurança da Base de Dados ao Nível da Linha.
Condições de junção equivalentes	A tabela lógica com junção resultante de um novo pedido de consulta tem de ser idêntica (ou um subconjunto de) aos resultados em cache para se qualificar para um sucesso da cache.
O atributo `DISTINCT` deve ser o mesmo	Se uma consulta em cache eliminar registos duplicados com o processamento `DISTINCT` (por exemplo, `SELECT DISTINCT`...), os pedidos para as colunas em cache também devem incluir o processamento `DISTINCT`; um pedido para a mesma coluna sem o processamento `DISTINCT` é uma falha da cache.
As consultas devem conter níveis de agregação compatíveis	As consultas que pedem um nível agregado de informações podem utilizar os resultados em cache a um nível de agregação inferior. Por exemplo, a consulta seguinte pede a quantidade vendida ao nível do fornecedor, da região e da localidade: SELECT supplier, region, city, qtysold FROM suppliercity A consulta seguinte pede a quantidade vendida ao nível da localidade: SELECT city, qtysold FROM suppliercity A segunda consulta resulta num sucesso da cache na primeira consulta.
Agregação adicional limitada	Por exemplo, se uma consulta com a coluna `qtysold` estiver em cache, um pedido de `RANK(qtysold)` resulta numa falha da cache. Adicionalmente, uma consulta que peça `qtysold` ao nível do país pode obter um sucesso da cache a partir de uma consulta que peça `qtysold` ao nível do país e da região.
A cláusula `ORDER BY` deve ser composta por colunas na lista Select	As consultas que ordenam por colunas que não estão contidas na lista Select resultam em falhas da cache.
Diagnosticar o comportamento de sucesso da cache	Para avaliar melhor o comportamento de sucesso da cache, defina a variável da sessão ENABLE_CACHE_DIAGNOSTICS como 4, como mostrado no exemplo seguinte: ENABLE_CACHE_DIAGNOSTICS=4

Assegurar Resultados da Cache Corretos ao Utilizar a Segurança da Base de Dados ao Nível da Linha

Quando utiliza uma estratégia de segurança da base de dados ao nível da linha, como uma Base de Dados Privada Virtual (VPD), os resultados dos dados devolvidos estão dependentes das credenciais de autorização do utilizador.

Por este motivo, o Oracle Analytics Cloud deve saber se uma origem de dados está a utilizar a segurança da base de dados ao nível da linha e quais as variáveis relevantes para a segurança.

Para garantir que os sucessos da cache só ocorrem nas entradas da cache que incluem e correspondem a todas as variáveis sensíveis à segurança, deve configurar corretamente o objeto da base de dados e os objetos da variável da sessão no Model Administration Tool, conforme se segue:

Objeto da Base de Dados. Na camada Física, no separador Geral da caixa de diálogo Base de Dados, selecione Base de Dados Privada Virtual para especificar que a origem de dados está a utilizar a segurança da base de dados ao nível da linha.

Se estiver a utilizar a segurança da base de dados ao nível da linha com colocação na cache partilhada, deve selecionar esta opção para impedir a partilha de entradas da cache cujas variáveis sensíveis à segurança não correspondem.
Objeto da Variável da Sessão. Para variáveis relacionadas com a segurança, na caixa de diálogo Variável da Sessão, selecione Sensível à Segurança para as identificar como sensíveis à segurança ao utilizar uma estratégia de segurança da base de dados ao nível da linha. Esta opção assegura que as entradas da cache são marcadas com as variáveis sensíveis à segurança, permitindo a correspondência de variáveis sensíveis à segurança em todas as consultas recebidas.

Executar um Conjunto de Consultas para Preencher a Cache

Para maximizar os potenciais sucessos da cache, uma estratégia consiste em executar um conjunto de consultas para preencher a cache.

Seguem-se algumas recomendações para os tipos de consultas a utilizar na criação de um conjunto de consultas com as quais irá criar a cache.

Consultas pré-criadas comuns. As consultas executadas frequentemente, em particular aquelas cujo processamento é dispendioso, são excelentes consultas de criação da cache. As consultas cujos resultados estão incorporados em dashboards são bons exemplos de consultas comuns.
Listas SELECT sem expressões. A eliminação de expressões em colunas de listas SELECT expande a possibilidade de sucessos da cache. Uma coluna em cache com uma expressão só pode responder a uma nova consulta com a mesma expressão; uma coluna em cache sem expressões pode responder a um pedido para essa coluna com qualquer expressão. Por exemplo, um pedido em cache como:
```
SELECT QUANTITY, REVENUE...
```
pode responder a uma nova consulta como:
```
SELECT QUANTITY/REVENUE... 
```
mas não o inverso.
Nenhuma cláusula WHERE. Se não existir nenhuma cláusula WHERE num resultado em cache, este pode ser utilizado para responder a consultas que satisfaçam as regras de sucesso da cache para a lista Select com qualquer cláusula WHERE que inclua colunas na lista de projeções.

Em geral, as melhores consultas para a criação da cache são as consultas que consomem muito recursos de processamento da base de dados e com grande probabilidade de serem reemitidas. Tenha cuidado para não criar a cache com consultas simples que devolvam muitas linhas. Estas consultas (por exemplo, SELECT * FROM PRODUCTS, em que PRODUCTS efetua correspondência diretamente com uma única tabela da base de dados) requerem muito pouco processamento da base de dados. Estas consultas representam custos em termos de sobrecarga da rede e do disco, que são fatores que a colocação na cache não atenua.

Quando o Oracle Analytics Cloud renova as variáveis do modelo semântico, examina os modelos de negócio para determinar se referenciam essas variáveis do modelo semântico. Se o fizerem, o Oracle Analytics Cloud elimina toda a cache para esses modelos de negócio. Consulte Como as Alterações ao Modelo Semântico Afetam a Cache de Consultas.

Utilizar Agentes para Criar a Cache de Consultas

Pode configurar agentes para criar a cache de consultas do Oracle Analytics Cloud.

A criação da cache pode melhorar os tempos de resposta para os utilizadores quando estes executam análises ou visualizam análises que estão incorporadas nos respetivos dashboards. É possível fazê-lo agendando agentes para executar pedidos que renovam estes dados.

No Oracle Analytics Cloud, abra a Página Principal Clássica e selecione Agente (secção Criar).
No separador Geral, selecione Destinatário para a opção Executar como. A criação da cache personalizada utiliza a visibilidade dos dados de cada destinatário para customizar o conteúdo da entrega do agente para cada destinatário.
No separador Agendar, especifique quando pretende que a cache seja criada.
Opcional: Selecione Condição e crie ou selecione um pedido condicional. Por exemplo, poderá ter um modelo de negócio que determina quando o processo ETL está concluído. Poderá utilizar um relatório baseado neste modelo de negócio de forma a ser o trigger condicional para iniciar a criação da cache.
No separador Conteúdo da Entrega, selecione um pedido individual ou uma página do dashboard completa para a qual pretende criar a cache. A seleção de uma página do dashboard pode poupar tempo.
No separador Destinatários, selecione utilizadores individuais ou grupos para serem os destinatários.
No separador Destinos, limpe todos os destinos dos utilizadores e selecione Cache do Oracle Analytics Server.
Grave o agente selecionando o botão Gravar no canto superior direito.

A única diferença entre os agentes de criação da cache e os outros agentes é o facto de limparem a cache anterior automaticamente e não aparecerem no dashboard como alertas.

Nota:

Os agentes de criação da cache só eliminam as consultas de correspondência exata, pelo que ainda podem existir dados obsoletos. Certifique-se de que a estratégia de colocação na cache inclui sempre a eliminação da cache, porque as consultas de agentes não tratam de consultas ad hoc ou definições do nível de detalhe.

Utilizar o Model Administration Tool para Eliminar Automaticamente a Cache para Tabelas Específicas

Eliminar a cache apaga entradas da cache de consultas e mantém o seu conteúdo atualizado. Pode eliminar automaticamente entradas da cache para tabelas específicas, definindo o campo Tempo de Persistência da Cache para cada tabela no Model Administration Tool.

Nota:

Se utiliza o Modelador Semântico, consulte Quais São as Propriedades Gerais de uma Tabela Física?

Isto é útil para as origens de dados que são atualizadas frequentemente. Por exemplo, se tiver uma tabela que armazena dados de cotações da bolsa que são atualizados a cada minuto, pode utilizar a definição Tempo de Persistência da Cache para eliminar as entradas dessa tabela a cada 59 segundos. Consulte Cache e Tempo de Persistência da Cache para Tabelas Físicas Especificadas.