拡張ワークフローを使用して Looker をデータベースに接続する

データベースの保護と構成が完了したら、データベースを Looker に接続する準備ができました。New Database Connection Setup Labs 機能が有効になっている場合、[接続の追加/編集] ページの UI が更新され、検証機能と接続テスト機能が強化され、クラウド固有のリソースを含むドキュメントが拡張され、包括的な構成の概要が表示されます。

Looker のデータベース接続は、[データベースを Looker に接続する] ページで作成します。[データベースを Looker に接続] ページを開くには、次の 2 つの方法があります。

  • [管理] パネルの [データベース] セクションで [接続] を選択します。[接続] ページで、[接続を追加] ボタンをクリックします。
  • メインのナビゲーション メニューで [作成] ボタンをクリックし、[接続] メニュー項目を選択します。

接続設定にユーザー属性を適用する方法の詳細については、ユーザー属性ドキュメント ページの接続セクションをご覧ください。

このページでは、Looker の [データベースを Looker に接続する] ページに表示される一般的なフィールドについて説明します。ページに表示される具体的なフィールドは、ダイアレクト設定によって異なります。

データベース接続設定を入力したら、接続をテストして正しく構成されていることを確認します。トラブルシューティング情報については、データベース接続のテストのドキュメント ページをご覧ください。Looker に [接続可能] と表示されたら、[接続] を押して接続を作成します。これで、データベース接続が Looker の [接続] 管理ページのリストに追加されます。

データベース接続の設定には、次の 4 つのセクションがあります。

全般設定

名前

接続に付ける名前です。 このデータベース接続名は、LookML モデルの connection パラメータで使用する必要があります。データベース接続名は、Looker の [接続管理] ページで接続が識別される仕組みでもあります。この設定にはフォルダの名前を使用しないでください。この値は、データベース内の値に一致する必要はありません。Name は、Looker UI 内でこの接続を識別するラベルです。

SQL 言語

接続に一致する SQL 言語。適切な接続オプションが表示され、LookMLがSQLに適切に変換されるよう、必ず正確な値を選択してください。

プロジェクトの範囲

接続をすべてのプロジェクトで使用できるか、1 つのプロジェクトのみで使用するかを選択します。

  • すべてのプロジェクト: インスタンス上のすべての LookML プロジェクトが接続にアクセスできるため、そのプロジェクトのモデルファイルの connection パラメータで接続名を指定できます。
  • 選択したプロジェクト: インスタンス上の 1 つの LookML プロジェクトのみが接続にアクセスできます。このオプションを選択すると、[接続] 画面にインスタンスのプロジェクトのプルダウン メニューが表示されます。この接続にアクセスできるプロジェクトを選択します。

次の権限とともにこのオプションを使用して、接続管理とモデル構成を委任します。

ステータスの詳細

[ステータスの詳細] セクションを開いて、接続の設定をテストします。

データベース設定

SSH サーバーを有効にする

[SSH Server] オプションは、インスタンスが Kubernetes インフラストラクチャにデプロイされており、さらに Looker インスタンスに SSH サーバー構成情報を追加する機能が有効になっている場合に限り利用できます。このオプションが Looker インスタンスで有効になっておらず、有効にしたい場合は、Google Cloud セールス スペシャリストにお問い合わせいただくか、サポート リクエストを開いてください。[SSH サーバーを有効にする] オプションをオンにすると、[SSH サーバー] フィールドと [SSH トンネル] フィールドが表示されます。

SSH サーバー

SSH サーバーは、自動で localhost ポートを選択します。localhost ポートを指定することはできません。localhost ポートを指定する必要がある SSH 接続を作成する必要がある場合は、サポート リクエストを作成します。

プルダウン リストから SSH サーバー構成を選択します。適切な SSH トンネルを選択または作成するには、SSH サーバーが必要です。新しい SSH サーバーは、[接続] パネルの [SSH サーバー] タブで作成できます。

SSH トンネル

プルダウン リストから既存の SSH トンネルを選択するか、ホスト名とポートまたはローカルポートを使用して新しい SSH トンネルを作成する場合は、[Create New Tunnel] アイコンをクリックします。

ホスト名

Looker がデータベース ホストに接続するために使用するデータベース ホスト名。

Looker アナリストと共同でデータベースへの SSH トンネルを構成した場合は、[ホスト] フィールドに「"localhost"」と入力します。ユーザー属性をホストフィールドには、ユーザー属性にユーザー アクセスレベルを編集可能に設定できません。データベースに接続するように SSH トンネルを構成した場合は、[Remote Host:Port] フィールドにユーザー属性を適用できません。

ポート

Looker がデータベース ホストに接続するために使用するデータベース ポート。

Looker アナリストと共同でデータベースへの SSH トンネルを構成した場合は、データベースにリダイレクトするポート番号を [ポート] フィールドに入力してください。このポート番号は担当の Looker アナリストから入手します。

ローカルポート

デフォルトでの Looker は、SSH トンネルに使用できるローカルポートを自動的に選択します。ローカルポートを手動で選択するには、[手動入力] を選択し、[Custom Local Port] フィールドにポート番号を入力します。インスタンスで、ローカルポートが使用できることを確認します。

課金プロジェクト ID（Google BigQuery のみ）

課金プロジェクト ID は Google Cloud プロジェクト ID です。詳細については、Google BigQuery のドキュメント ページをご覧ください。

ストレージ プロジェクト ID（Google BigQuery のみ）

コンピューティングとストレージを別々のプロジェクトに分割する場合の、ストレージ プロジェクト ID の名前。LookML デベロッパーが LookML のビュー、Explore、結合の sql_table_name パラメータに完全にスコープされたテーブル名を指定していれば、別の Google Cloud プロジェクトのデータセットをクエリできます。詳細については、Google BigQuery のドキュメント ページをご覧ください。

プライマリ データセット（Google BigQuery のみ）

データベースでクエリを実行するときに Looker がデフォルトにするデータセットの名前。詳細については、Google BigQuery のドキュメント ページをご覧ください。

データベース名

ホスト上のデータベースの名前。 たとえば、my-instance.us-east-1.redshift.amazonaws.com というホスト名に sales_info というデータベースがあるとします。このフィールドには sales_info を入力します。同じホスト上に複数のデータベースがある場合、それらを使用するには複数の接続を作成する必要があります（MySQLの場合は例外で、「データベース」という言葉は、ほとんどのSQLダイアレクトとは意味が少し異なります）。

デフォルトのスキーマ

スキーマが設定されない場合に使用されるデフォルトのスキーマです。 これは、SQL Runnerを使用しているとき、LookMLプロジェクトの生成中、およびテーブルをクエリするときに適用されます。

認証の設定

Google BigQuery、Snowflake、Trino、Databricks に接続する場合、Looker でデータベースへのアクセスに使用する認証の種類を選択します。

  • Google BigQuery 接続では、OAuth または Looker でデータベースに対する認証に使用するサービス アカウントを構成できます。
  • Snowflake、Trino、Databricks の接続では、Looker でデータベースに対する認証に使用する OAuth またはデータベース アカウントを構成できます。

OAuth を使用する場合、Looker からクエリを発行するには、ユーザーがデータベースにログインする必要があります。Looker への接続での OAuth の設定の詳細については、Google BigQuery、Snowflake、Trino、Databricks の接続手順をご覧ください。

ユーザー名

Looker でデータベースに接続するために使用できる、データベース上のユーザー アカウントのユーザー名。

パスワード

Looker でデータベースに接続するために使用できる、データベース上のユーザー アカウントのパスワード。

[ステータスの詳細] セクションを開いて、接続の設定をテストします。

オプションの設定

ノードごとの最大接続数

Lookerがデータベースと確立できる最大接続数を設定できます。 ほとんどの場合、Lookerがデータベースに対して実行できる同時クエリ数を設定します。 また、クエリの強制終了用に、最大3つの接続を予約します。 接続プールが非常に小さい場合は、予約される接続数も少なくなります。

この値を設定するときには注意してください。 値が大きすぎると、データベースの負荷が高くなります。 値が低すぎると、複数のクエリがわずかな接続数を共用しなければなりません。 クエリは、前のクエリが返されるのを待たなければならないため、ユーザーには遅く感じることがあります。

一般に、まずデフォルト値（SQLダイアレクトによって異なる）を使用することをお勧めします。 ほとんどのデータベースには、受け入れる最大接続数について独自の設定もあります。 データベース構成が接続を制限する場合は、[ノードごとの最大接続数] の値がデータベースの上限以下になるようにしてください。

Connection Pool Timeout（接続プールタイムアウト）

ユーザーが [ノードごとの最大接続数] 設定よりも多くの接続をリクエストすると、リクエストは他のリクエストが完了するまで待機してから実行されます。要求が待つ最大時間はここで設定します。 デフォルト設定は 120 秒です。

この値は注意深く設定する必要があります。 値が低すぎると、他のユーザーのクエリが完了する十分な時間がないことから、ユーザーのクエリはキャンセルされる場合があります。値が高すぎると、多数のクエリが作成され、ユーザーは長い時間待たされる場合があります。一般に、まずデフォルト値を使用することをお勧めします。

その他の JDBC パラメータ

必要に応じて、クエリに Java Database Connectivity（JDBC）パラメータを追加することもできます。

JDBC パラメータでユーザー属性を参照するには、Liquid テンプレート構文_user_attributes['name_of_attribute']を使用します。次に例を示します。

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

メンテナンス スケジュール

Looker 再生ツールは、データグループと sql_trigger_value に基づいた永続テーブル（集約テーブルと永続的な派生テーブルの両方）を確認します。Looker リジェネレータは、これらのチェックに基づいて、データベースのスクラッチ スキーマから永続テーブルを再構築または削除します。

[メンテナンス スケジュール] の値は、Looker リジェネレータの cron 間隔を設定します。Looker リジェネレータは、リジェネレータ サイクルを開始して、cron 間隔でデータグループと永続テーブルを確認します。Looker リジェネレータ サイクルが次の cron 間隔で進行中の場合、Looker リジェネレータは進行中の再生成サイクルを完了し、次の cron 間隔まで待機してその次の再生成サイクルを開始します。

[メンテナンス スケジュール] 設定は、cron 式を受け入れます。デフォルト値は */5 * * * * です。つまり、前の再生成サイクルが完了している場合、Looker リジェネレータ サイクルは 5 分間隔でサイクルを開始します。前の再生成サイクルが完了していない場合、Looker リジェネレータはサイクルが完了した後、次の 5 分間隔を開けて開始されます。

デフォルトの 5 分は、[メンテナンス スケジュール] でサポートされている最も頻度の高い間隔です。Looker では、[メンテナンス スケジュール] に最大間隔が適用されません。つまり、cron 式で指定可能な限り、Looker リジェネレータ サイクルの間隔を延長できます。Looker リジェネレータ サイクルが長いと、キャッシュと永続テーブルのデータの鮮度に悪影響を及ぼす可能性があります。

Looker リジェネレータは、すべてのチェックと PDT の再ビルドをサイクルで完了すると、次の cron 間隔を待機し、その次のサイクルを開始します。長時間実行される PDT ビルドがある場合は、Looker の再生成サイクルの間隔が長い可能性があります。テーブルの再構築に必要な時間は、Looker の派生テーブルページの永続テーブルの導入に関する重要な考慮事項のセクションで説明するように、他の要素にも影響されることがあります。

データベースが24時間稼働していない場合は、稼働時にのみにチェックすることもできます。その他の cron 式は次のとおりです。

cron　式 定義
*/5 8-17 * * MON-FRI データグループとPDTを、月曜から金曜の営業時間に5分ごとにチェック
*/5 8-17 * * * データグループとPDTを、毎日、営業時間に5分ごとにチェック
0 8-17 * * MON-FRI データグループとPDTを、月曜から金曜の営業時間に1時間ごとにチェック
1 3 * * * データグループとPDTを、毎日午前3時01分にチェック

cron 式を作成する際は、次の点にご注意ください。

  • Looker は parse-cron v0.1.3 を使用しますが、これは cron 式の ? をサポートしていません。
  • cron 式は、Looker のアプリケーションのタイムゾーンを使用して、チェックのタイミングを決定します。
  • PDT が作成されない場合は、cron 文字列をデフォルトの */5 * * * * にリセットします。

以下に、cron 文字列の作成に役立つリソースを示します。

SSL

データが Looker とデータベース間で渡される際に、データを保護するために SSL 暗号化を使用するかどうかを選択します。SSL はデータの保護に使用できる唯一のオプションです。その他のセキュアなオプションについては、セキュアなデータベースアクセスを可能にするドキュメント ページをご覧ください。

SSL を確認

接続で使用される SSL 証明書の確認を求めるかどうかを選択します。確認が必要な場合は、SSL証明書に署名したSSL認証局（CA）が、クライアントの信頼できるソースのリストに含まれていなければなりません。CAが信頼できるソースではない場合、データベース接続は確立されません。

このボックスが選択されていない場合、接続でSSL暗号化は使用されますが、SSL接続の確認は要求されません。そのため、CAがクライアントの信頼できるソースのリストにない場合でも接続を確立できます。

テーブルと列を事前にキャッシュに保存

SQL Runnerでは、ユーザーが接続とスキーマを選択するとすぐに、テーブル情報が事前にロードされます これにより、SQL Runner ではテーブル名をクリックすると即座にテーブル列が表示されるようになります。ただし、多くのテーブルや大規模なテーブルが関係する接続とスキーマの場合は、SQL Runnerですべての情報を事前にロードしないようにすることをお勧めします。

テーブルが選択されている場合にのみテーブル情報を読み込むようにするには、[テーブルと列を事前にキャッシュに保存] オプションの選択を解除して、その接続における SQL Runner の事前読み込みを無効にします。

スキーマを取得してキャッシュに保存

一部の SQL 書き込み機能（集約テーブルの自動認識など）では、Looker はデータベースの情報スキーマを使用して SQL 書き込みを最適化します。情報スキーマがキャッシュに保存されていない場合、Looker は、情報スキーマを取得できるようにデータベースへの SQL 書き込みをブロックすることがあります。Hadoop Distributed File System（HDFS）を使用する原語の場合、情報スキーマの取得に時間がかかり、Looker クエリのパフォーマンスに大きな影響を与える可能性があります。情報スキーマに時間を要することが分かっている場合、接続の [スキーマを取得してキャッシュに保存] オプションを無効にできます。この機能を無効にすると、特定の機能に対する Looker の SQL 最適化の一部が妨げられるため、接続の情報スキーマが特に遅いことがわかっている場合を除き、[スキーマを取得してキャッシュに保存する] オプションを有効にする必要があります。

費用の見積もり

[費用の見積もり] の切り替えは、次のデータベース接続にのみ適用されます。

[費用の見積もり] 切り替えにより、接続で次の機能が有効になります。

詳細については、Looker でのデータの探索のドキュメント ページをご覧ください。

Database Connection Pooling

データベース接続プーリングをサポートする言語の場合、この機能により、Looker は JDBC ドライバを介して接続のプールを使用できます。データベース接続プールにより、クエリのパフォーマンスが向上します。新しいクエリでデータベース接続を新しく作成する必要はありません。接続プールにある既存の接続を使用できます。接続プール機能により、クエリの実行後に接続がクリーンアップされ、クエリの実行の終了後に接続が再利用できるようになります。 詳細については、データベース接続プーリングのドキュメント ページをご覧ください。

永続的な派生テーブル（PDT）の設定

PDT が有効になっている場合は、次の設定が表示されます。

PDT を有効にする

永続的な派生テーブル（PDT）を有効にするには、[PDT を有効にする] 切り替えボタンをオンにします。PDT が有効になると、追加の PDT フィールドと [PDT オーバーライド] セクションが [接続] ウィンドウに表示されます。Looker では、データベース言語が PDT の使用をサポートしている場合にのみ、[PPDT を有効にする] 切り替えボタンが表示されます。

PDTについて、次の点に注意してください。

  • OAuth を使用する Snowflake 接続では PDT はサポートされていません。
  • 接続で PDT を無効にしても、PDT に関連付けられたデータグループは無効になりません。PDTを無効にしても、既存のデータグループは引き続きデータベースに対して sql_trigger クエリを実行します。データグループがデータベースに対して sql_trigger クエリを実行しないようにするには、LookML プロジェクトから datagroup パラメータを削除またはコメントアウトする必要があります。または、Looker による PDT およびデータグループのチェックの頻度が非常に低くなるようにするか、あるいはまったくチェックが行われないように、その接続の [データグループと PDT のメンテナンス スケジュール] 設定を更新することもできます。
  • Snowflake 接続の場合、Looker は AUTOCOMMIT パラメータの値を TRUE（Snowflake のデフォルト値）に設定します。Looker が PDT 登録システムを維持するために実行する SQL コマンドには、AUTOCOMMIT が必須です。

Temp Database

「一時データベース」に対して、データベース名またはスキーマ名を入力します（どちらを入力するかは、ご利用の SQL 言語によって異なります）。この名前は、Looker で永続的な派生テーブルを作成するために使用されます。このデータベースまたはスキーマには、適切な書き込み権限を前もって設定しておく必要があります。 データベース構成手順のドキュメント ページで、データベース言語を選択して、その言語の手順を表示します。

接続ごとに専用の一時データベースまたはスキーマが必要です。接続間で共有することはできません。

PDT ビルダーの最大接続数

PDT ビルダーの最大接続数の設定では、Looker リジェネレータがデータベース接続に対して同時に開始できるテーブルのビルド数を指定できます。[PDT ビルダーの最大接続数] 設定は、Looker リジェネレータが再ビルドを開始するテーブルのタイプにのみ適用されます。

  • トリガー永続テーブル（永続的な派生テーブルと datagroup_trigger または sql_trigger_value 永続化戦略を使用する集約テーブル）。
  • persist_for 戦略を使用する永続テーブル。ただし、persist_for テーブルが、datagroup_trigger または sql_trigger_value 永続戦略を使用するテーブルによって依存されている派生テーブルのカスケードの一部である場合に限る。この場合、Looker リジェネレータは persist_for テーブルを再構築します。これは、カスケード内の別のテーブルを再構築するために必要であるためです。それ以外の場合、リジェネレータは persist_for テーブルのビルドを開始しません。

[PDT ビルダーの最大接続数] 設定のデフォルトは 1 ですが、10 まで設定できます。ただし、この値を [ノードあたりの最大接続数] フィールドで設定された値や Looker の起動オプションで設定された per-user-query-limit より大きくすることはできません。

この値を設定するときには注意してください。 値が大きすぎると、データベースの負荷が高くなります。 値が小さいと、長期実行PDTまたは集計テーブルが原因で他の永続的なテーブルの作成が遅れるか、その接続の他のクエリが遅くなります。 マルチテナンシーに対応するデータベース（BigQuery、Snowflake、Redshift など）は、並列クエリビルドをより効率的に処理できます。

[PDT ビルダーの最大接続数] 設定の値を大きくする場合は、経験則として 1 ずつ増やします。予期しない動作が発生した場合は、デフォルトの 1 に戻します。または、クエリのパフォーマンスに影響がない場合は、設定を 1 ずつ増やし、増分ごとのパフォーマンスを確認してから、設定を増やします。

[PDT ビルダーの最大接続数] 設定については、次の点に注意してください。

  • [PDT ビルダーの最大接続数] 設定は、テーブルの再構築に必要な接続にのみ適用され、トリガーのチェックに必要な接続には適用されません。トリガーチェックとは、テーブルの永続性戦略がトリガーされたかどうかを確認するためのクエリであり、これは常に順番に実行されるため、[PDT ビルダーの最大接続数] 設定は適用されません。
  • クラスタ化された Looker インスタンスでは、リジェネレータはメインノードでのみ実行されます。[PDT ビルダーの最大接続数] 設定はメインノードにのみ適用されるため、クラスタ全体の上限を設定します。
  • [PDT ビルダーの最大接続数] 設定は、次のタイプのテーブルには適用されません。以下のタイプのテーブルは順番に構築されます。
    • persist_for パラメータを介して永続化されたテーブル（テーブルが datagroup_trigger 戦略または sql_trigger_value 戦略を使用するテーブルに依存している場合を除く）。
    • 開発モードのテーブル。
    • テーブルが派生テーブルと実行を再ビルドするオプションで再構築されている。
    • 依存関係内の別のテーブルに依存するテーブル。 テーブルを依存するテーブルと同時に構築することはできません。 たとえば、table_B が table_A に依存している場合、table_B で再構築を開始できるようになる前に、table_A が再構築を完了する必要があります。

失敗した PDT ビルドを再試行する

[Retry failed PDT builds] 切り替えボタンは、Looker リジェネレータが前のリジェネレータ サイクルで失敗したトリガー永続テーブルの再作成方法を構成します。Looker リジェネレータは、メンテナンス スケジュール接続設定で構成された間隔に従って、トリガー永続テーブル（PDT と集計テーブル）を再構築するプロセスです。[Retry Failed PDT Builds] 切り替えボタンをオンにすると、Looker リジェネレータは、PDT のトリガー条件が満たされない場合でも、前のリジェネレータ サイクルで失敗した PDT の再構築を試みます。この設定が無効にされている場合、Lookerリジェネレーターは、PDTのトリガー条件が満たされた場合のみ、前に失敗したPDTの再ビルドを試みます。[Retry Failed PDT Builds] はデフォルトで無効になっています。

Looker リジェネレータの詳細については、Looker の派生テーブルのドキュメント ページをご覧ください。

PDT API 制御

[PDT API 制御] 切り替えボタンで、start_pdt_build、check_pdt_build、stop_pdt_build API 呼び出しをこの接続に使用できるかどうかを指定します。[PDT API 制御] 切り替えボタンが無効になっている場合、この接続で PDT を参照していると、API 呼び出しは失敗します。[PDT API 制御] 切り替えボタンは、デフォルトで無効になっています。

PDT オーバーライドを有効にする

データベースが永続的な派生テーブルをサポートしていて、接続設定の [永続的な派生テーブル] 切り替えボタンをオンにしている場合、Looker で [PDT オーバーライド] セクションが表示されます。[PDT オーバーライド] セクションには、PDT プロセスに固有の個々の JDBC パラメータ（ホスト、ポート、データベース、ユーザー名、パスワード、スキーマ、追加パラメータ、接続後のステートメント）を入力できます。これは次のような理由で非常に重要です。

  • PDT プロセス用に個別のデータベース ユーザーを作成することで、データベース認証情報にユーザー属性を割り当てる場合や、データベース接続に OAuth を使用する場合でも、Looker プロジェクトで PDT を使用できます。
  • PDTプロセスは、優先度の高い別のデータベースユーザーによって認証できます。 このようにして、データベースは重要度の低いユーザーのクエリよりも、PDTジョブを優先することができます。
  • 書き込みアクセス権限は標準的なLookerデータベース接続に対して無効にし、PDTプロセスが認証に使用する特別なユーザーにのみ付与することができます。 ほとんどの組織で、これはより安全なセキュリティ戦略です。
  • Snowflake のようなデータベースの場合、PDT プロセスは、残りの Looker ユーザーで共有されていない、より強力なハードウェアにルーティングできます。こうして、高コストなハードウェアをフルタイムで実行するコストを回避し、PDTをすばやく構築できます。

たとえば、ユーザー名フィールドとパスワード フィールドがユーザー属性に設定されている接続では、[PDT オーバーライド] セクションで独自のパスワードを持つ個別のユーザー（pdt_user）を作成できます。この構成では、次のように処理されます。

  • 各ユーザーは、ユーザー属性で割り当てられた個別の認証情報を使用してデータベースにアクセスできます。
  • pdt_user アカウントは、PDT の作成と更新に適切なアクセスレベルを使用して、すべての PDT ‏プロセスに使用されます。
  • ユーザーのクエリ トラフィックと PDT プロセス トラフィックは、システム アクティビティによるモニタリングなどの目的で簡単に区別できます。

データベースのタイムゾーン

時間に基づく情報をデータベースで保管するときのタイムゾーンです。 Lookerは、ユーザーのために時間の値を変換するため、この値が必要です。これにより、時間ベースのデータをユーザーが理解して使用しやすくなります。 詳しくは、タイムゾーン設定の使用のドキュメント ページをご覧ください。

クエリのタイムゾーン

[クエリのタイムゾーン] オプションは、[ユーザー固有のタイムゾーン] を無効にしている場合にのみ表示されます。

ユーザー固有のタイムゾーンが無効になっている場合、クエリのタイムゾーンは、ユーザーが時間ベースのデータをクエリするときに表示されるタイムゾーンであり、Looker はこのタイムゾーンに、データベースのタイムゾーンから時間ベースのデータを変換します。

詳しくは、タイムゾーン設定の使用のドキュメント ページをご覧ください。

[ステータスの詳細] セクションを開いて、接続の設定をテストします。

確認

接続設定は、Looker UI の次の場所でテストできます。

  • [接続設定] ページの下部にある [テスト] ボタンを選択します。
  • 接続のドキュメント ページの説明に従って、[接続管理] ページの接続リストの横にある [テスト] ボタンを選択します。
  • 接続設定の各ステップの下部にある [確認] ボタンを選択します。[確認] セクションで、前のセクションで入力した接続の詳細を確認して変更します。[ステータスの詳細] セクションを開いて、接続の設定をテストします。各セクションの横にある編集アイコンをクリックすると、そのセクションに戻って設定を変更できます。

接続が 1 つ以上のテストに合格しない場合は、次のトラブルシューティング オプションをお試しください。

  • データベース接続のテストに関するドキュメント ページに記載されているトラブルシューティングの手順をお試しください。
  • Atlas で Mongo バージョン 3.6 以前を実行していて、通信リンク障害が発生した場合は、Mongo コネクタのドキュメント ページをご覧ください。
  • 一時スキーマとPDTに関する正常接続のメッセージを受け取るには、Lookerデータベースをセットアップする際にその機能を有効にする必要があります。 設定方法については、データベースの設定に関するインストラクションのドキュメント ページをご覧ください。

OAuth を使用するデータベース接続（Snowflake や Google BigQuery など）には、ユーザーのログインが必要です。これらの接続のいずれかをテストするときに OAuth ユーザー アカウントにログインしていない場合、Looker には [ログイン] リンクとともに警告が表示されます。このリンクをクリックして、OAuth資格情報を入力するか、またはLookerによるOAuthアカウント情報へのアクセスを許可します。

それでも障害が続く場合は、Lookerサポートに連絡してください。

1 つ以上の接続パラメータの値をユーザー属性に設定している場合、[ユーザーとしてテスト] オプションが表示されます。ユーザーを選択して [テスト] をクリックし、データベースに接続でき、このユーザーとしてクエリを実行できることを確認します。

次のステップ

データベースを Looker に接続したら、ユーザーのサインイン オプションを構成できます。