Como conectar o Looker ao seu banco de dados usando o fluxo de trabalho aprimorado

Depois de proteger e configurar seu banco de dados, você poderá conectá-lo ao Looker. Se o recurso Nova configuração de conexão de banco de dados Labs estiver ativado, a página Adicionar/editar conexões terá uma UI atualizada, recursos aprimorados de validação e teste de conexão, documentação ampliada, incluindo recursos específicos da nuvem, e um resumo de configuração abrangente.

Você cria uma conexão de banco de dados no Looker na página Conectar seu banco de dados ao Looker. Há duas opções para abrir a página Conectar seu banco de dados ao Looker:

  • Selecione Conexões na seção Banco de dados do painel Administrador. Na página Conexões, clique no botão Adicionar conexão.
  • Clique no botão Criar no menu de navegação principal e selecione o item de menu Conexão.

Para mais informações sobre como aplicar atributos de usuário às configurações de conexão, consulte a seção Conexões da página de documentação Atributos do usuário.

Esta página descreve os campos comuns que o Looker exibe na página Conectar seu banco de dados ao Looker. Os campos exatos que aparecem na página dependem da sua configuração de dialeto.

Depois de inserir as configurações de conexão do banco de dados, teste a conexão para garantir que ela esteja configurada corretamente. Consulte a página de documentação Teste de conectividade do banco de dados para informações sobre solução de problemas. Se o Looker mostrar Can Connect, pressione Connect para criar a conexão. Sua conexão de banco de dados é adicionada à lista na página Conexões Administrador do Looker.

A configuração de conexão de banco de dados tem as seguintes quatro seções:

Configurações gerais

Nome

O nome da conexão que você quer usar. Você precisa desse nome de conexão do banco de dados para usar no parâmetro connection do modelo do LookML. O nome da conexão do banco de dados também é como a conexão é identificada na página Conexões Administrador do Looker. Não use o nome de nenhuma pasta para essa configuração. Esse valor não precisa corresponder a nada no seu banco de dados. Name é um rótulo que identifica essa conexão na interface do Looker.

Dialeto SQL

O dialeto SQL correspondente à sua conexão. É importante escolher o valor correto para receber as opções de conexão adequadas e para que o Looker possa converter o LookML corretamente em SQL.

Escopo do projeto

Selecione se a conexão pode ser usada com todos os projetos ou apenas com um:

  • Todos os projetos: todos os projetos do LookML na instância podem ter acesso à conexão. Portanto, o nome da conexão pode ser especificado no parâmetro connection dos arquivos de modelo nesse projeto.
  • Projeto selecionado: apenas um projeto do LookML na instância pode ter acesso à conexão. Quando você seleciona essa opção, a tela de conexão mostra um menu suspenso com os projetos na instância. Selecione o projeto que pode ter acesso a essa conexão.

Use essa opção com as seguintes permissões para delegar o gerenciamento de conexões e a configuração do modelo:

Detalhes do status

Abra a seção Status details para testar as configurações da conexão.

Configurações do banco de dados

Ativar o servidor SSH

A opção Servidor SSH só fica disponível se a instância for implantada na infraestrutura do Kubernetes e se a opção de adicionar informações de configuração do servidor SSH à sua instância do Looker estiver ativada. Se essa opção não estiver ativada na sua instância do Looker e você quiser ativar, entre em contato com um especialista de vendas do Google Cloud ou abra uma solicitação de suporte. Se você ativar a opção Ativar servidor SSH, o Looker vai mostrar os campos Servidor SSH e Túnel SSH.

Servidor SSH

O servidor SSH escolhe automaticamente a porta localhost para você, e não é possível especificar a porta localhost. Se você precisar criar uma conexão SSH que exija a especificação de uma porta localhost, abra uma solicitação de suporte.

Selecione uma configuração do servidor SSH na lista suspensa. Um servidor SSH é necessário para selecionar ou criar um túnel SSH adequado. É possível criar um novo servidor SSH na guia Servidores SSH do painel Conexões.

Túnel SSH

Selecione um túnel SSH na lista suspensa ou clique no ícone Criar novo túnel se quiser criar um túnel SSH com um nome de host e Porta ou Porta local.

Nome do host

O nome do host do banco de dados que o Looker deve usar para estabelecer conexão.

Se você trabalhou com um analista do Looker para configurar um túnel SSH no seu banco de dados, insira "localhost" no campo Host. Se você aplicar um atributo de usuário ao campo Host, ele não poderá ter um nível de acesso do usuário definido como Editável. Se você configurou um túnel SSH para se conectar ao banco de dados, não é possível aplicar um atributo de usuário ao campo Host remoto:porta.

Porta

A porta do banco de dados que o Looker deve usar para se conectar ao host.

Se você trabalhou com um analista do Looker para configurar um túnel SSH no seu banco de dados, insira no campo Porta o número da porta que redireciona para o banco de dados, que o analista do Looker deve ter fornecido.

Porta local

Por padrão, o Looker seleciona automaticamente uma porta local disponível para o túnel SSH. Para escolher uma porta local manualmente, selecione Entrada manual e insira um número no campo Porta local personalizada. Verifique se a porta local está disponível na sua instância.

ID do projeto de faturamento (somente Google BigQuery)

O ID do projeto de faturamento é o ID do projeto Google Cloud . Para mais informações, consulte a página de documentação do Google BigQuery.

ID do projeto de armazenamento (somente Google BigQuery)

O nome do ID do projeto de armazenamento, se você separar computação e armazenamento em projetos diferentes. É possível consultar conjuntos de dados em um projeto diferente do Google Cloud se os desenvolvedores do LookML especificarem nomes de tabelas com escopo total no parâmetro sql_table_name das visualizações, análises ou junções do LookML. Para mais informações, consulte a página de documentação do Google BigQuery.

Conjunto de dados principal (somente Google BigQuery)

O nome do conjunto de dados que você quer que o Looker use como padrão ao consultar seu banco de dados. Para mais informações, consulte a página de documentação do Google BigQuery.

Nome do banco de dados

O nome do banco de dados no seu host. Por exemplo, você pode ter um nome de host my-instance.us-east-1.redshift.amazonaws.com com um banco de dados chamado sales_info. Você deve inserir sales_info neste campo. Se você tiver vários bancos de dados no mesmo host, talvez seja necessário criar várias conexões para usá-los (com exceção do MySQL, em que a palavra banco de dados significa algo um pouco diferente da maioria dos dialetos SQL).

Esquema padrão

O esquema padrão que o Looker usa quando um esquema não é especificado. Isso se aplica ao usar o SQL Runner, durante a geração de projetos do LookML e ao consultar tabelas.

Configurações de autenticação

Para as conexões Google BigQuery, Snowflake, Trino e Databricks, selecione o tipo de autenticação que você quer que o Looker use para acessar seu banco de dados:

  • Para conexões do Google BigQuery, você tem a opção de configurar o OAuth ou uma conta de serviço para que o Looker use para autenticação no seu banco de dados.
  • Para conexões do Snowflake, Trino e Databricks, você tem a opção de configurar o OAuth ou uma conta de banco de dados para que o Looker use para autenticação no seu banco de dados.

Quando você usa o OAuth, os usuários precisam fazer login no seu banco de dados para emitir consultas do Looker. Para mais informações sobre como configurar o OAuth em uma conexão com o Looker, consulte os procedimentos de conexão do Google BigQuery, Snowflake, Trino ou Databricks.

Nome de usuário

O nome de usuário de uma conta de usuário no banco de dados que o Looker pode usar para se conectar a ele.

Senha

A senha de uma conta de usuário no seu banco de dados que o Looker pode usar para se conectar a ele.

Abra a seção Status details para testar as configurações da conexão.

Configurações opcionais

Máximo de conexões por nó

Aqui, você pode definir o número máximo de conexões que o Looker pode estabelecer com seu banco de dados. Na maioria das vezes, você está definindo o número de consultas simultâneas que o Looker pode executar no seu banco de dados. O Looker também reserva até três conexões para matar consultas. Se o pool de conexões for muito pequeno, o Looker vai reservar menos conexões.

Defina esse valor com cuidado. Se o valor for muito alto, seu banco de dados poderá ficar sobrecarregado. Se o valor for muito baixo, as consultas vão precisar compartilhar um número pequeno de conexões. Assim, muitas consultas podem parecer lentas para os usuários, porque precisam esperar o retorno de outras consultas anteriores.

O valor padrão (que varia de acordo com o dialeto SQL) geralmente é um ponto de partida razoável. A maioria dos bancos de dados também tem configurações próprias para o número máximo de conexões que aceitam. Se a configuração do banco de dados limitar as conexões, verifique se o valor de Conexões máximas por nó é igual ou menor que o limite do banco de dados.

Tempo limite do pool de conexões

Se os usuários solicitarem mais conexões do que a configuração Conexões máximas por nó, as solicitações vão esperar que as outras terminem antes de serem executadas. O tempo máximo de espera de uma solicitação é configurado aqui. A configuração padrão é de 120 segundos.

Defina esse valor com cuidado. Se ele for muito baixo, as consultas dos usuários podem ser canceladas porque não há tempo suficiente para que as consultas de outros usuários sejam concluídas. Se ele for muito alto, um grande número de consultas poderá se acumular, fazendo com que os usuários esperem por muito tempo. O valor padrão geralmente é um ponto de partida razoável.

Parâmetros JDBC adicionais

É possível incluir outros parâmetros de Java Database Connectivity (JDBC) para suas consultas aqui, se precisar.

Para referenciar um atributo do usuário em um parâmetro JDBC, use a sintaxe de modelagem de modelos Liquid: _user_attributes['name_of_attribute']. Exemplo:

my_jdbc_param={{ _user_attributes['name_of_attribute'] }}

Cronograma de manutenção

O regenerador do Looker verifica grupos de dados e tabelas persistidas (tabelas agregadas e tabelas derivadas persistentes) com base em sql_trigger_value. Com base nessas verificações, o regenerador do Looker recria ou exclui tabelas persistidas do esquema inicial do seu banco de dados.

O valor Programação de manutenção define o intervalo cron para o regenerador do Looker. O regenerador do Looker inicia um ciclo de regeneração para verificar grupos de dados e tabelas persistidas no intervalo cron. Se um ciclo de regeneração do Looker ainda estiver em andamento no próximo intervalo de cron, ele vai concluir o ciclo em andamento e aguardar o próximo intervalo de cron para iniciar o próximo ciclo de regeneração.

A configuração Programação de manutenção aceita uma expressão cron. O valor padrão é */5 * * * *, o que significa que o ciclo de regeneração do Looker vai iniciar um ciclo no intervalo de cinco minutos, se o ciclo de regeneração anterior tiver sido concluído. Se o ciclo anterior não tiver sido concluído, o regenerador do Looker será iniciado no próximo intervalo de cinco minutos após a conclusão do ciclo.

O padrão de cinco minutos também é o intervalo mais frequente com suporte para a Programação de manutenção. O Looker não impõe um intervalo máximo para a Programação de manutenção, o que significa que você pode estender o intervalo entre os ciclos de regeneração do Looker por um tempo que pode ser especificado por uma expressão cron. Ciclos mais longos do regenerador do Looker podem afetar negativamente a atualização dos dados no cache e nas tabelas persistidas.

Depois que o regenerador do Looker concluir todas as verificações e reconstruções de PDT em um ciclo, ele vai aguardar o próximo intervalo de cron para iniciar o próximo ciclo. Se você tiver builds de PDT de longa duração, poderá ter períodos longos entre os ciclos de regeneração do Looker. Outros fatores podem afetar o tempo necessário para recriar as tabelas, conforme descrito na seção Considerações importantes para implementar tabelas persistentes na página Tabelas derivadas no Looker.

Se o banco de dados não estiver disponível 24 horas por dia, limite as verificações aos horários em que ele estiver disponível. Confira outras expressões cron:

Expressão cron Definição
*/5 8-17 * * MON-FRI Verifique os grupos de dados e os PDTs a cada 5 minutos durante o horário comercial, de segunda a sexta-feira
*/5 8-17 * * * Verifique os grupos de dados e os PDTs a cada cinco minutos durante o horário comercial, todos os dias
0 8-17 * * MON-FRI Verifique os grupos de dados e os PDTs a cada hora durante o horário comercial, de segunda a sexta-feira
1 3 * * * Verificar grupos de dados e TDPs todos os dias às 3h01

Algumas observações ao criar uma expressão cron:

  • O Looker usa o parse-cron v0.1.3, que não oferece suporte a ? em expressões cron.
  • A expressão cron usa o fuso horário do aplicativo do Looker para determinar quando as verificações são feitas.
  • Se as TDPs não estiverem sendo criadas, redefina a string de cron para o padrão */5 * * * *.

Confira alguns recursos para ajudar na criação de strings cron:

SSL

Escolha se você quer usar a criptografia SSL para proteger os dados que passam entre o Looker e seu banco de dados. O SSL é apenas uma opção que pode ser usada para proteger seus dados. Outras opções seguras são descritas na página de documentação Ativar o acesso seguro ao banco de dados.

Verificar SSL

Escolha se você quer exigir a verificação do certificado SSL usado pela conexão. Se a verificação for necessária, a autoridade certificadora (AC) SSL que assinou o certificado SSL precisa vir da lista de fontes confiáveis do cliente. Se a AC não for uma fonte confiável, a conexão do banco de dados não será estabelecida.

Se a caixa não estiver selecionada, a criptografia SSL ainda será usada na conexão, mas a verificação da conexão SSL não será necessária. Portanto, uma conexão poderá ser estabelecida quando a AC não estiver na lista de origens confiáveis do cliente.

Pré-cache de tabelas e colunas

No SQL Runner, todas as informações da tabela são pré-carregadas assim que você seleciona uma conexão e um esquema. Isso permite que o SQL Runner mostre rapidamente as colunas da tabela assim que você clica no nome dela. No entanto, para conexões e esquemas com muitas tabelas ou com tabelas muito grandes, talvez você não queira que o SQL Runner pré-carregue todas as informações.

Se você preferir que o SQL Runner carregue as informações da tabela somente quando uma tabela for selecionada, desmarque a opção Pré-carregar tabelas e colunas para desativar o pré-carregamento do SQL Runner para a conexão.

O esquema para buscar e armazenar em cache

Para alguns recursos de programação SQL, como awareness agregado, o Looker usa o esquema de informações do seu banco de dados para otimizar a programação SQL. Se o esquema de informações não estiver armazenado em cache, o Looker poderá bloquear ocasionalmente a gravação de SQL no banco de dados para buscar o esquema de informações. Para dialetos que usam o Hadoop Distributed File System (HDFS), a busca do esquema de informações pode levar tempo suficiente para afetar significativamente o desempenho das consultas do Looker. Se você souber que o esquema de informações é lento, desative a opção Buscar e armazenar em cache o esquema para a conexão. A desativação desse recurso impede parte da otimização do SQL do Looker para determinados recursos. Portanto, ative a opção Buscar e armazenar em cache o esquema, a menos que você saiba que o esquema de informações da conexão é particularmente lento.

Custo estimado

A opção Estimativa de custo se aplica apenas às seguintes conexões de banco de dados:

O botão Estimativa de custo ativa os seguintes recursos na conexão:

Consulte a página de documentação Analisar dados no Looker para mais informações.

Pool de conexão de banco de dados

Para dialetos compatíveis com o pooling de conexões de banco de dados, esse recurso permite que o Looker use pools de conexões pelo driver JDBC. O pooling de conexões de banco de dados permite uma performance de consulta mais rápida. Uma nova consulta não precisa criar uma nova conexão de banco de dados, mas pode usar uma conexão existente do pool de conexões. O recurso de agrupamento de conexões garante que uma conexão seja limpa após a execução de uma consulta e fique disponível para reutilização após o término da execução. Consulte a página de documentação Agrupamento de conexões de banco de dados para mais informações.

Configurações de tabelas derivadas persistentes (TDPs)

As configurações a seguir aparecem se as TDPs estiverem ativadas.

Ativar TDPs

Ative a opção Ativar TDPs para ativar as TDPs persistentes. Quando as TDPs estão ativadas, a janela Conexão mostra outros campos de TDP e a seção Substituições de TDP. O Looker mostra a opção Ativar TDPs somente se o dialeto do banco de dados for compatível com o uso de TDPs.

Observe o seguinte sobre as PDTs:

  • Os TDPs não são compatíveis com conexões do Snowflake que usam o OAuth.
  • Desabilitar PDTs em uma conexão não desativa os datagroups associados a elas. Mesmo que você desative as PDTs, os grupos de dados atuais ainda vão executar as consultas sql_trigger no banco de dados. Se você quiser impedir que um grupo de dados execute a consulta sql_trigger no banco de dados, exclua ou comente o parâmetro datagroup do seu projeto do LookML. Também é possível atualizar a configuração Datagroup and PDT Maintenance Schedule da conexão para que o Looker verifique as PDTs e os grupos de dados com pouca frequência ou nunca.
  • Para conexões do Snowflake, o Looker define o valor do parâmetro AUTOCOMMIT como TRUE (valor padrão do Snowflake). AUTOCOMMIT é necessário para comandos SQL que o Looker executa para manter o sistema de registro de PDT.

Banco de dados temporário

Embora seja chamado de Banco de dados temporário, você digita o nome do banco de dados ou do esquema apropriado para seu dialeto SQL que o Looker usa na criação de tabelas derivadas persistentes. Configure esse banco de dados ou esquema com antecedência, com as permissões de gravação adequadas. Na página de documentação Instruções de configuração do banco de dados, selecione o dialeto do banco de dados para ver as instruções dele.

Cada conexão precisa ter o próprio banco de dados temporário ou esquema. Eles não podem ser compartilhados entre conexões distintas.

O número máximo de conexões do builder da TDP

Com a configuração Número máximo de conexões do builder da TDP, é possível especificar quantas versões simultâneas de tabelas o regenerador do Looker pode iniciar em uma conexão de banco de dados. A configuração Número máximo de conexões do builder da TDP se aplica apenas aos tipos de tabelas para os quais o regenerador do Looker inicia a reconstrução:

  • Tabelas com gatilho permanente (tabelas derivadas persistentes e tabelas agregadas que usam a estratégia de persistência datagroup_trigger ou sql_trigger_value).
  • Tabelas persistidas que usam a estratégia persist_for, mas somente quando a tabela persist_for faz parte de uma cascata de tabelas derivadas em que ela depende de uma tabela que usa a estratégia de persistência datagroup_trigger ou sql_trigger_value. Nesse caso, o regenerador do Looker vai recriar uma tabela persist_for, já que ela é necessária para recriar outra tabela na cascata. Caso contrário, o gerador não inicia builds para tabelas persist_for.

A configuração Número máximo de conexões do builder da TDP tem o valor padrão 1, mas pode ser definido até 10. No entanto, o valor não pode ser maior do que o definido no campo Conexões máximas por nó ou no per-user-query-limit definido nas opções de inicialização do Looker.

Defina esse valor com cuidado. Se o valor for muito alto, seu banco de dados poderá ficar sobrecarregado. Se o valor for baixo, as PDTs de execução longa ou as tabelas agregadas podem atrasar a criação de outras tabelas persistentes ou diminuir a velocidade de outras consultas na conexão. Os bancos de dados que oferecem suporte à multitenência, como BigQuery, Snowflake e Redshift, podem ter melhor desempenho no processamento de builds de consulta paralela.

Se você quiser aumentar a configuração Número máximo de conexões do builder da TDP, uma boa regra é aumentar em incrementos de 1. Se ocorrer algum comportamento inesperado, defina o valor padrão 1. Caso contrário, se a performance da consulta não for afetada, continue aumentando a configuração de 1 em 1 e verificando a performance em cada incremento antes de aumentar a configuração.

Observe o seguinte sobre a configuração Número máximo de conexões do builder da TDP:

  • A configuração Número máximo de conexões do builder da TDP se aplica apenas às conexões necessárias para a reconstrução de tabelas, não às conexões necessárias para as verificações de acionamento. Uma verificação de acionador é uma consulta que verifica se a estratégia de persistência da tabela foi acionada. Como essas consultas de verificação de acionador são sempre executadas sequencialmente, a configuração Número máximo de conexões do builder da TDP não se aplica.
  • Em uma instância de cluster do Looker, o regenerador é executado apenas no nó principal. A configuração Número máximo de conexões do builder da TDP se aplica apenas ao nó principal e, portanto, define o limite para todo o cluster.
  • A configuração Número máximo de conexões do builder da TDP não se aplica aos seguintes tipos de tabelas. Estes tipos de tabelas são criados de forma consecutiva:
    • Tabelas persistidas pelo parâmetro persist_for (a menos que a tabela dependa de tabelas que usam as estratégias datagroup_trigger ou sql_trigger_value).
    • Tabelas no modo de desenvolvimento.
    • Tabelas recriadas com a opção Recriar tabelas derivadas e executar.
    • Tabelas em que uma depende da outra em uma cascata de dependência. Uma tabela não pode ser criada ao mesmo tempo que uma tabela de dependência. Por exemplo, se table_B depender de table_A, table_A precisará terminar a recriação antes que table_B possa começar.

Repetir builds de TDP com falha

O botão Repetir builds de TDP com falha configura como o regenerador do Looker tenta recriar as tabelas com gatilhos que falharam no ciclo anterior do regenerador. O regenerador do Looker é o processo que recria tabelas persistidas por gatilho (PDTs e tabelas agregadas) de acordo com o intervalo configurado na configuração de conexão Programação de manutenção. Quando a opção Repetir builds de TDP com falha está ativada, o regenerador do Looker tenta recriar uma TDP que falhou no ciclo anterior, mesmo que a condição de acionamento da TDP não tenha sido atendida. Quando essa configuração está desativada, o regenerador do Looker tenta recriar uma TDP com falha anterior apenas quando a condição de acionamento da TDP é atendida. A opção Repetir builds de TDP com falha fica desativada por padrão.

Consulte a página de documentação Tabelas derivadas no Looker para mais informações sobre o regenerador do Looker.

Controle da API de TDPs

O botão Controle da API de TDP determina se as chamadas de API start_pdt_build, check_pdt_build e stop_pdt_build podem ser usadas para essa conexão. Quando o botão Controle de API de TDP estiver desativado, essas chamadas de API vão falhar quando referenciarem TDPs nessa conexão. A opção Controle da API de TDPs fica desativada por padrão.

Ativar substituições de TDP

Se o banco de dados oferecer suporte a tabelas derivadas persistentes e você tiver ativado a opção Ativar PDTs nas configurações de conexão, o Looker vai mostrar a seção Substituições de PDTs. Na seção Substituições de TDP, é possível inserir parâmetros JDBC separados (host, porta, banco de dados, nome de usuário, senha, esquema, parâmetros adicionais e instruções pós-conexão) específicos para processos de TDP. Isso pode ser útil por vários motivos:

  • Ao criar um usuário de banco de dados separado para processos de TDP, você pode usar TDPs no seu projeto do Looker mesmo que atribua atributos de usuário às credenciais de login do banco de dados ou use OAuth para a conexão do banco de dados.
  • Os processos de PDT podem ser autenticados por um usuário de banco de dados separado que tem prioridade mais alta. Dessa forma, o banco de dados pode priorizar os jobs de PDT em vez de consultas de usuários menos importantes.
  • O acesso de gravação pode ser revogado para a conexão padrão do banco de dados do Looker e concedido apenas a um usuário especial que os processos de PDT vão usar para autenticação. Essa é uma estratégia de segurança melhor para a maioria das organizações.
  • Para bancos de dados como o Snowflake, os processos de PDT podem ser roteados para hardwares mais poderosos que não são compartilhados com os demais usuários do Looker. Dessa forma, os PDTs podem ser criados rapidamente sem incorrer no custo de executar hardwares caros o tempo todo.

Por exemplo, em uma conexão em que os campos de nome de usuário e senha são definidos como atributos do usuário, a seção Substituições de PDT pode criar um usuário separado (pdt_user) com a própria senha. Com essa configuração, o seguinte vai ocorrer:

  • Cada usuário pode acessar o banco de dados usando as credenciais individuais atribuídas pelos atributos do usuário.
  • A conta pdt_user será usada para todos os processos de TDP, com níveis de acesso adequados para a criação e atualização de TDPs.
  • O tráfego de consulta do usuário e o tráfego do processo de PDT podem ser diferenciados rapidamente para fins como monitoramento com a Atividade do sistema.

fuso horário do banco de dados

O fuso horário em que o banco de dados armazena informações baseadas em tempo. O Looker precisa saber disso para converter os valores de tempo para os usuários, facilitando a compreensão e o uso de dados baseados em tempo. Consulte a página de documentação Como usar as configurações de fuso horário para mais informações.

fuso horário de consultas

A opção Fuso horário da consulta só fica visível se você desativou os Fusos horários específicos do usuário.

Quando os Fusos horários específicos do usuário estão desativados, o Fuso horário da consulta é o fuso horário que aparece para os usuários quando eles consultam dados baseados no tempo, e o fuso horário em que o Looker vai converter dados baseados no tempo do Fuso horário do banco de dados.

Consulte a página de documentação Como usar as configurações de fuso horário para mais informações.

Abra a seção Status details para testar as configurações da conexão.

Revisão

É possível testar as configurações de conexão em alguns lugares na interface do Looker:

  • Selecione o botão Testar na parte de baixo da página Configurações de conexões.
  • Selecione o botão Testar ao lado da lista de conexões na página Administrador de conexões, conforme descrito na página de documentação Conexões.
  • Selecione o botão Revisar na parte de baixo de cada etapa da configuração da conexão. Revise e modifique os detalhes de conexão que você inseriu nas seções anteriores na seção Revisão. Abra a seção Detalhes do status para testar as configurações da conexão. Clique no ícone de edição ao lado de cada seção para voltar a ela e mudar as configurações.

Se a conexão não passar em um ou mais testes, confira estas opções de solução de problemas:

  • Siga algumas das etapas de solução de problemas na página de documentação Teste de conectividade do banco de dados.
  • Se você estiver executando a versão 3.6 ou anterior do Mongo no Atlas e receber uma falha de link de comunicação, consulte a página de documentação do Conector do Mongo.
  • Para receber mensagens de conexão bem-sucedidas sobre o esquema temporário e os PDTs, você precisa permitir essa funcionalidade ao configurar o banco de dados do Looker. As instruções para fazer isso estão na página de documentação Instruções de configuração do banco de dados.

As conexões de banco de dados que usam OAuth, como o Snowflake e o Google BigQuery, exigem que o usuário faça login. Se você não estiver conectado à sua conta de usuário OAuth ao testar uma dessas conexões, o Looker vai mostrar um aviso com um link Fazer login. Clique no link para inserir suas credenciais do OAuth ou permitir que o Looker acesse as informações da sua conta OAuth.

Se você ainda tiver problemas, entre em contato com o suporte do Looker.

Se você definiu um ou mais valores de parâmetro de conexão para um atributo do usuário, a opção Testar como usuário vai aparecer. Selecione um usuário e clique em Testar para verificar se o banco de dados pode se conectar e executar consultas como esse usuário.

Próximas etapas

Depois de conectar seu banco de dados ao Looker, você pode configurar as opções de login para seus usuários.