Depois de proteger e configurar seu banco de dados, você poderá conectá-lo ao Looker.
Crie 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 no painel Administrador. Na página Conexões, clique no botão Adicionar conexão.
- Clique no botão Criar no painel de navegação esquerdo e selecione o item de menu Conexão.
Para obter 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.
Nesta página, descrevemos campos comuns que o Looker mostra na página Conectar seu banco de dados ao Looker. Os campos exatos que a página exibe dependem da sua configuração de dialeto.
Clique aqui para conferir os links para instruções específicas de dialeto na documentação do Looker.
- Avalanche ativo
- AlloyDB para PostgreSQL
- PostgreSQL do Amazon Aurora
- Amazon Athena (em inglês)
- Amazon Aurora MySQL
- Amazon RDS para MySQL
- Amazon RDS para PostgreSQL
- Amazon Redshift
- Apache Druid (em inglês)
- Apache Hive 2.3+ e 3.1.2+
- Apache Spark 3 ou mais recente
- ClickHouse
- Cloudera Impala 3.1 ou mais recente
- Databricks
- DataVirtuality
- Denodo
- Dremio
- Exasol
- Firebolt (link em inglês)
- SQL legado do Google BigQuery
- SQL padrão do Google BigQuery
- Google Cloud SQL para MySQL
- Google Cloud SQL para PostgreSQL
- Google Spanner (em inglês)
- Greenplum
- IBM DB2 no AS400
- IBM DB2 no LUW
- MariaDB
- Microsoft Azure Synapse Analytics
- Banco de dados SQL do Microsoft Azure
- Microsoft Azure PostgreSQL
- Microsoft SQL Server (MSSQL)
- Conector do MongoDB para BI
- MySQL
- Oracle
- Oracle ADWC (link em inglês)
- PostgreSQL
- PrestoDB
- SAP HANA
- SingleStore (antigo MemSQL)
- Snowflake
- Teradata
- Trino
- Vetor
- Vertica
Depois de inserir as configurações de conexão do banco de dados, selecione o botão Testar na página Conectar seu banco de dados ao Looker para testar a conexão e verificar se está definida corretamente. Clique em Testar para verificar se a conexão foi estabelecida. Consulte a página de documentação Como testar a conectividade do banco de dados para informações sobre solução de problemas. Se o Looker exibir Pode conectar, pressione Conectar para criar a conexão. Sua conexão de banco de dados é adicionada à lista na página do administrador Conexões do Looker.
Configurações gerais
Nome
O nome da conexão como você quer se referir a ela. Você precisa desse nome de conexão de banco de dados para usar no parâmetro connection
do seu modelo do LookML. O nome da conexão do banco de dados também é identificada na página Administrador de conexões do Looker. Não use o nome de nenhuma pasta para essa configuração. Esse valor não precisa corresponder a nada no banco de dados. Name
é um rótulo que identifica essa conexão na interface do Looker.
Escopo da conexão
Selecione se a conexão deve ser usada com todos os projetos ou apenas com um projeto.
Use esta opção com as seguintes permissões para delegar o gerenciamento de conexões e a configuração do modelo:
Dialeto
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.
ID do projeto de faturamento
Apenas para conexões do Google BigQuery, o ID do projeto de faturamento é o ID do projeto do Google Cloud.
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 na configuração de um túnel SSH para seu banco de dados, digite "localhost"
no campo Host.
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, no campo Porta, digite o número da porta que redireciona para o banco de dados, que o analista do Looker deve ter fornecido.
Banco de dados
O nome do banco de dados no seu host. Por exemplo, é possível ter o nome do host my-instance.us-east-1.redshift.amazonaws.com
em que há um banco de dados chamado sales_info
. Insira sales_info
nesse campo. Se você tem vários bancos de dados no mesmo host, pode ser necessário criar várias conexões para usá-los (exceto o MySQL, em que a palavra banco de dados significa algo um pouco diferente do que na maioria dos dialetos SQL).
Esquema
O esquema padrão que o Looker usa quando um esquema não é especificado. Isso se aplica quando você está usando o SQL Runner, durante a geração de projetos do LookML e quando está consultando tabelas.
Autenticação
Para conexões do 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:
- Nas conexões do Google BigQuery, você tem a opção de configurar o OAuth ou uma conta de serviço para o Looker se autenticar 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 o Looker usar para autenticar seu banco de dados.
Quando você usa o OAuth, os usuários precisam fazer login no banco de dados para fazer consultas pelo 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 no seu banco de dados que o Looker pode usar para se conectar ao seu banco de dados.
Senha
A senha de uma conta de usuário no seu banco de dados que o Looker pode usar para se conectar ao seu banco de dados.
Configurações opcionais
Servidor SSH
A opção Servidor SSH só vai estar disponível se a instância estiver implantada na infraestrutura do Kubernetes e somente se a capacidade de adicionar informações de configuração do servidor SSH à instância do Looker estiver ativada. Se essa opção não estiver ativada na sua instância do Looker e você quiser ativá-la, entre em contato com um especialista em vendas do Google Cloud ou abra uma solicitação de suporte.
O servidor SSH escolhe automaticamente a porta localhost para você, e não é possível especificar essa porta. Se precisar criar uma conexão SSH que exija a especificação de uma porta localhost, abra uma solicitação de suporte.
Para se conectar ao banco de dados usando um túnel SSH, ative a opção e selecione uma configuração de servidor SSH na lista suspensa.
Porta local
Por padrão, o Looker seleciona automaticamente uma porta local disponível para o túnel SSH. Para escolher manualmente uma porta local, selecione Entrada manual e insira o número da porta no campo Porta local personalizada. Certifique-se de que a porta local esteja disponível na instância.
Tabelas derivadas persistentes (TDPs)
Ativar TDPs
Ative o botão Ativar TDPs para ativar as tabelas derivadas persistentes. Quando as TDPs são ativadas, a janela Conexão revela campos adicionais de TDP e a seção Substituições de TDP. O Looker vai mostrar 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 TDPs:
- As TDPs não são compatíveis com conexões Snowflake que usam OAuth.
- Desativar as TDPs em uma conexão não desativa os grupos de dados associados a elas. Mesmo que você desative as PDTs, os grupos de dados ainda vão executar as consultas
sql_trigger
no banco de dados. Se você quiser impedir que um grupo de dados execute a consultasql_trigger
no seu banco de dados, exclua ou comente o parâmetrodatagroup
do projeto do LookML ou atualize a configuração Programação de manutenção de PDT e grupo de dados 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
comoTRUE
(valor padrão do Snowflake). OAUTOCOMMIT
é necessário para comandos SQL executados pelo Looker para manter o sistema de registro de TDP.
Banco de dados temporário
Ainda que o rótulo seja Banco de dados temporário, é preciso inserir o nome do banco de dados ou do esquema, conforme apropriado para seu dialeto SQL, que o Looker deve usar para criar tabelas derivadas persistentes. Você precisa configurar esse banco de dados ou esquema com antecedência, com as permissões de gravação apropriadas. 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 um banco de dados temporário ou esquema próprio. elas não podem ser compartilhadas entre conexões.
Número máximo de conexões do criador de TDP
A configuração Número máximo de conexões do builder de TDP permite especificar quantos builds de tabela simultâneos o regenerador do Looker pode iniciar na conexão do banco de dados. A configuração Número máximo de conexões do builder de PDT se aplica apenas aos tipos de tabelas em que o regenerador do Looker inicia recriações:
- Tabelas mantidas pelo gatilho (tabelas derivadas persistentes e tabelas de agregação que usam a estratégia de persistência
datagroup_trigger
ousql_trigger_value
). - tabelas persistentes que usam a estratégia
persist_for
, mas somente quando a tabelapersist_for
faz parte de uma cascata de tabelas derivadas em que ela depende de uma tabela que usa a estratégia de persistênciadatagroup_trigger
ousql_trigger_value
; Nesse caso, o regenerador do Looker vai recriar uma tabelapersist_for
, já que ela é necessária para recriar outra na cascata. Caso contrário, o regerador não iniciará builds para tabelaspersist_for
.
A configuração Número máximo de conexões do criador de PDT é definida por padrão como 1, mas pode ser definida como 10. No entanto, o valor não pode ser maior que o definido no campo Máximo de conexões 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, o banco de dados poderá ficar sobrecarregado. Se o valor for baixo, PDTs ou tabelas agregadas de longa duração poderão atrasar a criação de outras tabelas persistentes ou retardar outras consultas na conexão. Bancos de dados com suporte a multilocação, como BigQuery, Snowflake e Redshift, podem ter melhor desempenho no processamento de builds de consultas paralelas.
Se você quiser aumentar a configuração Número máximo de conexões do builder de PDT, uma boa regra prática é aumentá-la em um incremento de 1. Se ocorrer um comportamento inesperado, defina novamente o padrão como 1. Caso contrário, se o desempenho da consulta não for afetado, continue aumentá-la incrementalmente em 1 e verificar o desempenho a cada incremento antes de aumentar ainda mais a configuração.
Observe o seguinte sobre a configuração Número máximo de conexões do criador de TDP:
- A configuração Número máximo de conexões do criador de PDT se aplica apenas às conexões necessárias para a recriação de tabelas, não às conexões necessárias para verificações de acionadores. Uma verificação de gatilho é uma consulta que confere se a estratégia de persistência da tabela foi acionada. Como essas consultas de verificação de acionador são sempre executadas em sequência, a configuração Número máximo de conexões do criador de PDT não se aplica.
- Em uma instância do Looker em cluster, o regenerador é executado apenas no nó principal. A configuração Número máximo de conexões do builder de PDT 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 criador de TDP não se aplica aos tipos de tabela a seguir. Os seguintes tipos de tabelas são criados consecutivamente:
- tabelas mantidas por meio do parâmetro
persist_for
(a menos que elas dependam de tabelas que usam as estratégiasdatagroup_trigger
ousql_trigger_value
). - Tabelas no Modo de Desenvolvimento.
- Tabelas reconstruídas com a função Reconstruir tabelas derivadas e Run.
- Tabelas em que um depende do outro em uma cascata de dependência. Uma tabela não pode ser criada ao mesmo tempo que uma tabela da qual depende. Por exemplo, se
table_B
depende detable_A
,table_A
precisa concluir a recriação antes quetable_B
possa iniciar a recriação.
- tabelas mantidas por meio do parâmetro
Programação de manutenção de TDP e grupo de dados
O regenerador do Looker verifica grupos de dados e tabelas mantidas (tabelas de agregação e tabelas derivadas persistentes) baseadas em sql_trigger_value
. Com base nessas verificações, o regenerador do Looker recria ou descarta tabelas persistentes do esquema inicial do banco de dados.
O valor de Programação de manutenção de PDT e grupo de dados define o intervalo cron
para o regenerador do Looker. O regenerador do Looker inicia um ciclo para verificar grupos de dados e tabelas persistentes no intervalo cron
. Se um ciclo de regenerador do Looker ainda estiver em andamento no próximo intervalo de cron
, ele vai concluir o ciclo que está em andamento e aguardar o intervalo cron
subsequente para iniciar o próximo ciclo.
A configuração Programação de manutenção de PDT e grupo de dados aceita uma expressão cron
. O valor padrão é */5 * * * *
, o que significa que o ciclo do regenerador do Looker vai iniciar um ciclo no intervalo de cinco minutos se o ciclo anterior tiver sido concluído. Se o ciclo anterior não tiver sido concluído, o Looker será iniciado no intervalo de cinco minutos seguinte após a conclusão do ciclo.
O padrão de cinco minutos também é o intervalo mais frequente compatível com a Programação de manutenção de PDT e grupo de dados. O Looker não impõe um intervalo máximo para a programação de manutenção de PDT e grupo de dados. Isso significa que é possível estender o intervalo entre os ciclos de regenerador do Looker pelo tempo que puder 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 persistentes.
Depois que o regenerador do Looker concluir todas as verificações e recriar a PDT em um ciclo, ele vai aguardar o próximo intervalo cron
para iniciar o próximo ciclo. Se você tiver builds de PDT de longa duração, talvez tenha longos períodos entre os ciclos de regenerador do Looker. Outros fatores podem afetar o tempo necessário para recriar as tabelas, conforme descrito na seção Considerações importantes para a implementação de tabelas persistentes na página Tabelas derivadas no Looker.
Se seu banco de dados não estiver ativo 24 horas por dia, 7 dias por semana, convém limitar as verificações aos horários em que ele está ativo. Estas são algumas outras expressões cron
:
Expressão cron |
Definição |
---|---|
*/5 8-17 * * MON-FRI |
Verifique os grupos de dados e PDTs a cada cinco minutos durante o horário comercial, de segunda a sexta-feira |
*/5 8-17 * * * |
Verificar grupos de dados e PDTs a cada cinco minutos durante o horário comercial, todos os dias |
0 8-17 * * MON-FRI |
Verifique os grupos de dados e PDTs a cada hora durante o horário comercial, de segunda a sexta-feira |
1 3 * * * |
Verificar grupos de dados e PDTs todos os dias às 3h01 |
Algumas observações ao criar uma expressão cron
:
- O Looker usa parse-cron v0.1.3, que não oferece suporte a
?
em expressõescron
. - 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 cron para o padrão
*/5 * * * *
.
Confira abaixo alguns recursos para ajudar na criação de strings cron
:
- https://crontab.guru: ajuda para editar e testar strings
cron
. - http://www.crontab-generator.org: selecione as configurações de horário, e o gerador criará a string
cron
correspondente.
Repetir builds de TDP com falha
O botão Tentar novamente builds de TDP com falha configura como o regenerador do Looker tenta recriar tabelas com gatilhos que falharam no ciclo anterior. O regenerador do Looker é o processo que recria tabelas mantidas por gatilhos (PDTs e tabelas de agregação) de acordo com o intervalo definido na configuração de conexão Programação de manutenção de PDT e grupos de dados. 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 PDT não seja atendida. Quando essa configuração está desativada, o regenerador do Looker tenta recriar uma PDT que falhou anteriormente apenas quando a condição de acionamento da PDT for atendida. A opção Repetir builds de TDP com falha está 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 de alternância Controle da API PDT 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 de alternância Controle da API de TDP estiver desativado, essas chamadas de API vão falhar quando fizerem referência a TDPs nessa conexão. O botão de alternância Controle da API de TDP fica desativado por padrão.
Substituições de TDP
Se o banco de dados for compatível com tabelas derivadas persistentes e você tiver ativado a opção Ativar TDPs nas configurações de conexão, o Looker exibirá a seção Substituição de TDP. Na seção Substituições de TDP, insira 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 os processos de TDP. Isso pode ser valioso por vários motivos:
- Ao criar um usuário de banco de dados separado para os processos de TDP, é possível usá-las no seu projeto do Looker mesmo que você atribua atributos de usuário às credenciais de login do banco de dados ou use o OAuth para a conexão com o banco de dados.
- Os processos de TDP podem ser autenticados com um usuário do banco de dados separado que tenha uma prioridade mais alta. Dessa forma, o banco de dados pode priorizar os jobs de TDP em vez de consultas de usuários menos críticas.
- 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 TDP usarão 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 um hardware mais potente que não é compartilhado com o restante dos usuários do Looker. Dessa forma, as TDPs podem ser criadas rapidamente sem incorrer no custo de executar hardware caro em tempo integral.
Por exemplo, a configuração a seguir mostra uma conexão em que os campos de nome de usuário e senha são definidos como atributos de usuário. Dessa forma, cada usuário pode acessar o banco de dados usando suas credenciais individuais. A seção Substituições de TDP cria um usuário separado (pdt_user
) com uma senha própria. A conta pdt_user
será usada para todos os processos de TDP, com níveis de acesso adequados para criação e atualização de TDP.
Fuso horário
fuso horário do banco de dados
O fuso horário em que seu banco de dados armazena informações baseadas em tempo. O Looker precisa saber disso para converter valores de tempo para os usuários, facilitando a compreensão e o uso de dados baseados em tempo. Para mais informações, consulte a página de documentação Como usar configurações de fuso horário.
fuso horário de consultas
A opção Fuso horário da consulta só ficará visível se você tiver desativado 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 mostrado aos usuários quando eles consultam dados baseados em tempo, e o fuso em que o Looker vai converter os dados com base no horário do fuso horário do banco de dados.
Para mais informações, consulte a página de documentação Como usar configurações de fuso horário.
Mais configurações
Parâmetros JDBC adicionais
É possível incluir outros parâmetros de Java Database Connectivity (JDBC) para suas consultas aqui, se precisar.
Para fazer referência a um atributo de usuário em um parâmetro JDBC, use a sintaxe de modelos líquidos: _user_attributes['name_of_attribute']
. Exemplo:
my_jdbc_param={{ _user_attributes['name_of_attribute'] }}
Máximo de conexões por nó
Aqui é possível definir o número máximo de conexões que o Looker pode estabelecer com seu banco de dados. Em sua maioria, 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 eliminar 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 precisam compartilhar um pequeno número de conexões. Assim, muitas consultas podem parecer lentas para os usuários, pois elas precisam aguardar o retorno de outras consultas anteriores.
O valor padrão (que varia de acordo com seu dialeto SQL) é normalmente um ponto de partida razoável. A maioria dos bancos de dados também tem as próprias configurações para o número máximo de conexões aceitas. Se a configuração do banco de dados limitar as conexões, verifique se o valor em Máximo de conexões por nó é igual ou menor que o limite do banco de dados.
Tempo limite do pool de conexão
Se os usuários solicitarem mais conexões do que a configuração Máximo de conexões por nó, as solicitações esperarão que os outros sejam concluídos antes de serem executadas. O período máximo de espera de uma solicitação é configurado aqui. A configuração padrão é de 120 segundos.
Defina esse valor com cuidado. Se o valor for muito baixo, as consultas dos usuários podem ser canceladas porque não há tempo suficiente para consultas sejam concluídas. Se ele for muito alto, um grande número de consultas poderá se acumular, fazendo com que os usuários aguardem muito tempo. O valor padrão costuma ser um ponto de partida razoável.
SSL
Escolha se você quer ou não usar a criptografia SSL para proteger os dados transmitidos entre o Looker e seu banco de dados. 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 Como 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 de certificação (CA, na sigla em inglês) que assinou o certificado SSL precisará estar na 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 essa caixa não for selecionada, a criptografia SSL ainda será usada na conexão, mas a verificação da conexão SSL não será necessária. Dessa forma, uma conexão poderá ser estabelecida quando a CA não estiver na lista de fontes confiáveis do cliente.
Pré-cache do SQL Runner
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 exiba rapidamente as colunas da tabela assim que você clicar no nome de uma tabela. No entanto, para conexões e esquemas com muitas tabelas ou tabelas muito grandes, talvez você não queira que o SQL Runner pré-carregue todas as informações.
Se preferir que o SQL Runner carregue informações somente quando uma tabela for selecionada, desmarque a opção Pré-cache do SQL Runner para desativar o pré-carregamento do SQL Runner para a conexão.
Buscar esquema de informações para gravação em SQL
Para alguns recursos de gravação em SQL, como reconhecimento agregado, o Looker usa o esquema de informações do seu banco de dados para otimizar a escrita SQL. Se o esquema de informações não for armazenado em cache, o Looker poderá ter que bloquear 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 esquema de informações para gravação SQL na conexão. Desativar esse recurso vai impedir a otimização de alguns recursos do SQL do Looker. Por isso, ative a opção Buscar esquema de informações para gravação de SQL, a menos que você saiba que o esquema de informações da sua conexão é particularmente lento.
Custo estimado
O botão de alternância Estimativa de custo se aplica apenas às seguintes conexões de banco de dados:
- Snowflake
- Amazon Redshift
- Amazon Aurora (em inglês)
- PostgreSQL, Google Cloud SQL para PostgreSQL e Microsoft Azure PostgreSQL
O botão Estimativa de custo ativa os seguintes recursos na conexão:
- Estimativas de custo para consultas da Análise
- Estimativas de custo para consultas do SQL Runner
- Estimativas de economia de computação para consultas de reconhecimento agregadas
Consulte a página de documentação Como analisar dados no Looker para mais informações.
Pool de conexão de banco de dados
Para dialetos compatíveis com pool de conexões de banco de dados, esse recurso permite que o Looker use pools de conexões pelo driver JDBC. O pool de conexões de banco de dados permite um desempenho de consulta mais rápido. Uma nova consulta não precisa criar uma nova conexão de banco de dados, mas pode usar uma do pool de conexões. O recurso de pool de conexões garante que uma conexão seja limpa após a execução de uma consulta e esteja disponível para reutilização após o término da execução da consulta. Para mais informações, consulte a página de documentação Pool de conexões de banco de dados.
Testando as configurações de conexão
É possível testar suas 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 na listagem da conexão na página do administrador Conexões, conforme descrito na página de documentação Conexões.
Depois de definir as configurações de conexão, clique em Testar para verificar se as informações estão corretas e se o banco de dados pode se conectar.
Se sua conexão não passar em um ou mais testes, veja algumas opções de solução de problemas:
- Siga algumas das etapas de solução de problemas na página de documentação Como testar a conectividade do banco de dados.
- Se você estiver executando o Mongo versão 3.6 ou anterior no Atlas e ocorrer uma falha no link de comunicação, consulte a página de documentação do Mongo Connector.
- Para receber mensagens de conexão bem-sucedidas relacionadas ao esquema temporário e às PDTs, permita essa funcionalidade ao configurar seu banco de dados do Looker. As instruções para isso podem ser encontradas na página de documentação Instruções de configuração do banco de dados.
Se ainda estiver com problemas, entre em contato com o suporte do Looker para receber ajuda.
Testar como usuário
Se você tiver definido um ou mais valores de parâmetro de conexão para um atributo de usuário, a opção Testar como usuário será exibida. Selecione um usuário e clique em Testar para verificar se o banco de dados consegue se conectar e executar consultas como esse usuário.
Próximas etapas
Depois de conectar seu banco de dados ao Looker, você poderá configurar as opções de login para os usuários.