バージョン: 4.x

JDBC カタログ

JDBC Catalogは、標準のJDBCインターフェースを通じてJDBCプロトコルと互換性のあるデータベースへの接続をサポートします。

このドキュメントでは、JDBC Catalogの一般的な設定と使用方法を紹介します。異なるJDBCソースについては、それぞれのドキュメントを参照してください。

Note

DorisのJDBC Catalog機能は、データの読み取りと処理にJavaレイヤーに依存しており、全体的なパフォーマンスはJDKバージョンの影響を受ける可能性があります。古いバージョンのJDK（JDK 8など）の一部の内部ライブラリは効率が低く、リソース消費が高くなる可能性があります。より高いパフォーマンスが必要な場合は、デフォルトでJDK 17でコンパイルされ、より優れた全体的なパフォーマンスを提供するDoris 3.0の使用を推奨します。

適用シナリオ

JDBC Catalogは、データソースから少量のデータをDorisにインポートしたり、JDBCデータソース内の小さなテーブルでjoinクエリを実行したりするなど、データ統合にのみ適しています。JDBC Catalogは、データソース上のクエリを高速化したり、大量のデータに一度にアクセスしたりすることはできません。

サポートされているデータベース

Doris JDBC Catalogは以下のデータベースへの接続をサポートします：

サポートされているデータソース
MySQL
PostgreSQL
Oracle
SQL Server
IBM DB2
ClickHouse
SAP HANA
Oceanbase

Developer Guideを参照して、新しい、サポートされていないJDBCデータソースのサポートを開発できます。

Catalogの設定

構文

CREATE CATALOG [IF NOT EXISTS] catalog_name PROPERTIES (
    'type' =='jdbc', -- required
    {JdbcProperties},
    {CommonProperties}
);

{JdbcProperties}

必須プロパティ

パラメータ名	説明	例
`user`	データソースのユーザー名
`password`	データソースのパスワード
`jdbc_url`	データソース接続URL	`jdbc:mysql://host:3306`
`driver_url`	JDBCドライバファイルへのパス。ドライバパッケージのセキュリティについては、付録を参照してください。	3つの方法をサポート、下記参照。
`driver_class`	JDBCドライバのクラス名

driver_urlは以下の3つの指定方法をサポートします：

ファイル名。例：mysql-connector-j-8.3.0.jar。JarファイルはFEおよびBEデプロイディレクトリ下のjdbc_drivers/ディレクトリに事前配置する必要があります。システムは自動的にこのディレクトリ内を検索します。この場所はfe.confおよびbe.confのjdbc_drivers_dir設定により変更することも可能です。
ローカル絶対パス。例：file:///path/to/mysql-connector-j-8.3.0.jar。JarファイルはすべてのFE/BEノードの指定パスに事前配置する必要があります。
HTTP URL。例：http://repo1.maven.org/maven2/com/mysql/mysql-connector-j/8.3.0/mysql-connector-j-8.3.0.jar 。システムはこのHTTPアドレスからドライバファイルをダウンロードします。認証なしのHTTPサービスのみサポートします。

オプションプロパティ

パラメータ名	デフォルト値	説明
`lower_case_meta_names`	false	外部データソースからデータベース、テーブル、カラム名を小文字で同期するかどうか
`meta_names_mapping`		外部データソースで`MY_TABLE`や`my_table`など大文字小文字のみが異なる名前がある場合、DorisはCatalogをクエリする際に曖昧性によりエラーを報告します。競合を解決するために`meta_names_mapping`パラメータを設定する必要があります。
`only_specified_database`	false	`jdbc_url`で指定されたデータベースのみを同期するかどうか（このDatabaseはDorisのDatabaseレベルにマップされます）
`connection_pool_min_size`	1	接続プール内の最小接続数を定義し、プールの初期化とキープアライブが有効な場合に少なくともこの数のアクティブ接続を確保するために使用されます。
`connection_pool_max_size`	30	接続プール内の最大接続数を定義します。各Catalogに対応する各FEまたはBEノードは最大でこの数の接続を保持できます。
`connection_pool_max_wait_time`	5000	プールで利用可能な接続がない場合にクライアントが接続を待機する最大時間をミリ秒で定義します。
`connection_pool_max_life_time`	1800000	プール内の接続の最大アクティブ期間（ミリ秒）を設定します。この時間を超えた接続はリサイクルされます。さらに、この値の半分がプールの最小退避アイドル時間として使用され、この時間に達した接続は退避の対象となります。
`connection_pool_keep_alive`	false	BEノードでのみ有効で、最小退避アイドル時間に達したが最大ライフタイムには達していない接続をアクティブに保つかどうかを決定します。不要なリソース使用を削減するため、デフォルトで無効になっています。

[CommonProperties]

CommonPropertiesセクションは共通プロパティの設定に使用されます。共通プロパティについてはCatalog概要セクションを参照してください。

クエリ操作

基本クエリ

-- 1. switch to catalog, use database and query
SWITCH mysql_ctl;
USE mysql_db;
SELECT * FROM mysql_tbl LIMIT 10;

-- 2. use mysql database directly
USE mysql_ctl.mysql_db;
SELECT * FROM mysql_tbl LIMIT 10;

-- 3. use full qualified name to query
SELECT * FROM mysql_ctl.mysql_db.mysql_tbl LIMIT 10;

クエリ最適化

述語プッシュダウン

JDBC Catalogがデータソースにアクセスする際、基本的にBEノードを選択し、JDBC Clientを使用して生成されたSQLクエリをソースに送信し、データを取得します。そのため、パフォーマンスは生成されたSQLがソース側でどれだけ効率的に実行されるかにのみ依存します。Dorisは述語条件をプッシュダウンし、生成されたSQLに組み込もうとします。EXPLAIN SQL文を使用して生成されたSQLを確認できます。

EXPLAIN SELECT smallint_u, sum(int_u)
FROM all_types WHERE smallint_u > 10 GROUP BY smallint_u;

...
|   0:VJdbcScanNode(206)                                                                             |
|      TABLE: `doris_test`.`all_types`                                                               |
|      QUERY: SELECT `smallint_u`, `int_u` FROM `doris_test`.`all_types` WHERE ((`smallint_u` > 10)) |
|      PREDICATES: (smallint_u[#1] > 10)                                                             |
|      final projections: smallint_u[#1], int_u[#3]                                                  |
|      final project output tuple id: 1   
...                                                           |

Function Pushdown

述語条件において、Dorisと外部データソースでセマンティクスや動作が一致しない場合があります。そのため、DorisはJDBC外部テーブルクエリにおける述語pushdownを以下のパラメータ変数で制限および制御します：

注意：現在、Dorisは MySQL、Clickhouse、Oracle データソースの述語pushdownのみをサポートしています。今後、より多くのデータソースがサポートされる予定です。

enable_jdbc_oracle_null_predicate_push_down

セッション変数。デフォルトはfalseです。つまり、述語条件にNULL値が含まれる場合、述語はOracleデータソースにpush downされません。これは、Oracle version 21以前では、OracleがNULLを演算子としてサポートしていないためです。

このパラメータは2.1.7および3.0.3以降でサポートされています。
enable_jdbc_cast_predicate_push_down

セッション変数。デフォルトはfalseです。つまり、述語条件に明示的または暗黙的なCASTがある場合、述語はJDBCデータソースにpush downされません。異なるデータベース間でCASTの動作が一致しないため、正確性を確保するため、デフォルトではCASTはpush downされません。ただし、ユーザーはCASTの動作が一致するかどうかを手動で確認できます。一致する場合は、このパラメータをtrueに設定することで、より多くの述語をpush downしてパフォーマンスを向上させることができます。

このパラメータは2.1.7および3.0.3以降でサポートされています。

Function pushdownブラックリストとホワイトリスト

同じシグネチャを持つ関数でも、Dorisと外部データソースでセマンティクスが一致しない場合があります。Dorisには関数pushdown用の事前定義されたブラックリストとホワイトリストがあります：

Data Source	Blacklist	Whitelist	Description
MySQL	- `DATE_TRUNC` - `MONEY_FORMAT` - `NEGTIVE`		MySQLはFE設定項目`jdbc_mysql_unsupported_pushdown_functions`を通じて追加のブラックリスト項目を設定することも可能です。例：`jdbc_mysql_unsupported_pushdown_functions==func1,func2`
Clickhouse		- `FROM_UNIXTIME` - `UNIX_TIMESTAMP`
Oracle		- `NVL` - `IFNULL`

関数書き換えルール

Dorisと外部データソースには動作は一致しているが名前が異なる関数があります。Dorisは関数pushdown時にこれらの関数を書き換えることをサポートしています。現在、以下の書き換えルールが組み込まれています：

Data Source Doris Function Target Function
MySQL nvl ifnull
MySQL to_date date
Clickhouse from_unixtime FROM_UNIXTIME
Clickhouse unix_timestamp toUnixTimestamp
Oracle ifnull nvl
カスタム関数pushdownと書き換えルール

3.0.7以降のバージョンでは、Dorisはより柔軟な関数pushdownと書き換えルールをサポートしています。ユーザーはCatalogプロパティで特定のCatalogに対する関数pushdownと書き換えルールを設定できます：
```
create catalog jdbc properties (
...
'function_rules' = '{"pushdown" : {"supported": ["to_date"], "unsupported" : ["abs"]}, "rewrite" : {"to_date" : "date2"}}'
)
```

Data Source	Doris Function	Target Function
MySQL	nvl	ifnull
MySQL	to_date	date
Clickhouse	from_unixtime	FROM_UNIXTIME
Clickhouse	unix_timestamp	toUnixTimestamp
Oracle	ifnull	nvl

function_rules を通じて、以下のルールを指定することができます：

- `pushdown`

    ファンクションプッシュダウンルールを指定します。`supported` と `unsupported` の配列は、それぞれプッシュダウン可能な関数名とプッシュダウンできない関数名を指定します。ある関数が両方の配列に存在する場合は、`supported` が優先されます。

    Doris はまずシステムの事前定義されたブラックリストとホワイトリストを適用し、その後ユーザー指定のブラックリストとホワイトリストを適用します。

- `rewrite`

    ファンクションリライトルールを定義します。上記の例のように、関数名 `to_date` は `date2` として書き換えられ、プッシュダウンされます。

    注意：プッシュダウンが許可されている関数のみがリライトされます。

行数制限

クエリに LIMIT キーワードが含まれている場合、Doris はデータ転送量を削減するために LIMIT 句をデータソースにプッシュダウンします。生成された SQL に LIMIT 句が含まれているかどうかを確認するには、EXPLAIN ステートメントを使用できます。

書き込み操作

Doris は JDBC プロトコルを介して、対応するデータソースへのデータの書き戻しをサポートしています。

INSERT INTO mysql_table SELECT * FROM internal.doris_db.doris_tbl;

Statement Passthrough

適用シナリオ

Dorisは、statement passthroughを通じてJDBCデータソース内で対応するDDL、DML、およびクエリステートメントを直接実行することをサポートしています。この機能は以下のシナリオで適用可能です：

複雑なクエリのパフォーマンス向上

デフォルトでは、Dorisクエリオプティマイザーは元のSQLを解析し、特定のルールに基づいてデータソースに送信するSQLを生成します。この生成されたSQLは通常、シンプルな単一テーブルクエリであり、集約やjoinクエリなどの演算子を含めることはできません。例えば、以下のクエリを考えてみてください：
```
SELECT smallint_u, sum(int_u)
FROM all_types WHERE smallint_u > 10 GROUP BY smallint_u;
```

最終的に生成されるSQLは以下のようになります：

SELECT smallint_u, int_u 
FROM all_types
WHERE smallint_u > 10;

この場合、集約操作はDoris内で実行されます。そのため、一部のシナリオでは、ネットワーク経由でソースから大量のデータを読み取る必要があり、クエリ効率が低下する可能性があります。statement passthroughを使用することで、元のSQLを直接データソースに渡すことができ、データソース自体の計算能力を活用してSQLを実行し、クエリパフォーマンスを向上させることができます。

統合管理

クエリSQL に加えて、statement passthrough機能はDDLおよびDMLステートメントも渡すことができます。これにより、ユーザーはDorisを通じてソースデータに対して直接データベースやテーブル操作を実行できます。例えば、テーブルの作成、削除、またはテーブル構造の変更などです。

Passthrough SQL

SELECT * FROM
QUERY(
  'catalog' = 'mysql_catalog', 
  'query' = 'SELECT smallint_u, sum(int_u) FROM db.all_types WHERE smallint_u > 10 GROUP BY smallint_u;'
);

QUERYテーブル関数は2つのパラメータを取ります：

catalog：カタログの名前。カタログの名前と一致する必要があります。
query：実行するクエリ文。対応するデータソースの構文を直接使用して記述します。

パススルーDDLおよびDML

CALL EXECUTE_STMT("jdbc_catalog", "insert into db1.tbl1 values(1,2), (3, 4)");

CALL EXECUTE_STMT("jdbc_catalog", "delete from db1.tbl1 where k1 = 2");

CALL EXECUTE_STMT("jdbc_catalog", "create table dbl1.tbl2 (k1 int)");

EXECUTE_STMT() 関数は2つのパラメータを取ります：

第1パラメータ：カタログの名前。現在、JDBC タイプのカタログのみがサポートされています。
第2パラメータ：実行する SQL 文。現在、DDL および DML 文のみがサポートされており、対応するデータソースの構文を使用して記述する必要があります。

使用制限

CALL EXECUTE_STMT() コマンドを使用する場合、Doris はユーザーが記述した SQL 文を、カタログに関連付けられた JDBC データソースに直接送信して実行します。そのため、この操作には以下の制限があります：

SQL 文は対応するデータソースの構文に従う必要があります。Doris は構文や意味的チェックを実行しません。
SQL 文で参照されるテーブル名は、db.tbl のような完全修飾名を使用することが推奨されます。データベースが指定されていない場合、JDBC カタログの JDBC URL 内のデータベース名が使用されます。
SQL 文は JDBC データソース外のデータベースやテーブルを参照することはできませんし、Doris のデータベースやテーブルを参照することもできません。ただし、Doris JDBC カタログと同期されていない JDBC データソース内のテーブルを参照することは可能です。
DML 文を実行する場合、挿入、更新、または削除された行数は取得できません；コマンドの成功または失敗のみを判断できます。
カタログに対する LOAD 権限を持つユーザーのみが CALL EXECUTE_STMT() コマンドを実行できます。
カタログに対する SELECT 権限を持つユーザーのみが query() テーブル関数を実行できます。
カタログ作成時に指定された JDBC ユーザーは、対応する文を実行するためにソース上で必要な権限を持っている必要があります。
query() テーブル関数によって読み取られる結果のデータ型は、クエリされたカタログタイプでサポートされるデータ型と一致します。

付録

大文字小文字の区別設定

デフォルトでは、Doris のデータベース名とテーブル名は大文字小文字を区別し、カラム名は大文字小文字を区別しません。この動作は設定パラメータによって変更できます。さらに、一部の JDBC データソースにおけるデータベース名、テーブル名、カラム名の大文字小文字の区別ルールは、Doris のものと異なる場合があります。この違いにより、JDBC Catalog を介した名前マッピング時に命名の競合が発生する可能性があります。以下のセクションでは、このような問題を解決する方法について説明します。

表示名とクエリ名

Doris では、オブジェクト名（ここではテーブル名を例として使用）を 表示名 と クエリ名 に分けることができます。例えば、テーブル名の場合、表示名 は SHOW TABLES の結果に表示される名前を指し、クエリ名 は SELECT 文で使用できる名前を指します。

例えば、テーブルの実際の名前が MyTable の場合、Frontend（FE）パラメータ lower_case_table_names の設定に応じて、このテーブルの 表示名 と クエリ名 が異なる場合があります：

設定	説明	実際の名前	表示名	クエリ名
`lower_case_table_names=0`	デフォルト設定。元の名前が保存・表示され、クエリでは大文字小文字を区別します。	`MyTable`	`MyTable`	クエリで大文字小文字を区別、以下を使用する必要があります：`MyTable`
`lower_case_table_names=1`	名前は小文字で保存・表示され、クエリでは大文字小文字を区別しません。	`MyTable`	`mytable`	クエリで大文字小文字を区別しません。例：`MyTable` または `mytable` を使用できます。
`lower_case_table_names=2`	元の名前が保存・表示されますが、クエリでは大文字小文字を区別しません。	`MyTable`	`MyTable`	クエリで大文字小文字を区別しません。例：`MyTable` または `mytable` を使用できます。

JDBC Catalog 名の大文字小文字区別ルール

Doris 自体では テーブル名 の大文字小文字区別ルールの設定のみが可能です。しかし、JDBC Catalog では データベース名 と カラム名 に対する追加の処理が必要です。そのため、lower_case_table_names と組み合わせて動作する追加のカタログプロパティ lower_case_meta_names を使用します。

設定	説明
`lower_case_meta_names`	カタログ作成時に `properties` で指定され、そのカタログにのみ適用されます。デフォルト値は `false` です。`true` に設定すると、Doris はすべてのデータベース名、テーブル名、カラム名を小文字に変換して保存・表示します。Doris でのクエリでは小文字の名前を使用する必要があります。
`lower_case_table_names`	Frontend（FE）設定項目で、`fe.conf` で設定され、クラスタ全体に適用されます。デフォルト値は `0` です。

注意：lower_case_meta_names = true の場合、lower_case_table_names 設定は無視され、すべてのデータベース名、テーブル名、カラム名が小文字に変換されます。

lower_case_meta_names（true/false）と lower_case_table_names（0/1/2）の組み合わせに基づいて、保存および クエリ 時のデータベース名、テーブル名、カラム名の動作を以下の表に示します（「元のまま」は外部データソースからの大文字小文字をそのまま保持することを意味し、「小文字」は自動的に小文字に変換することを意味し、「任意の大文字小文字」はクエリで任意の大文字小文字を使用できることを意味します）：

`lower_case_table_names` & `lower_case_meta_names`	データベース表示名	テーブル表示名	カラム表示名	データベースクエリ名	テーブルクエリ名	カラムクエリ名
`0 & false`	元のまま	元のまま	元のまま	元のまま	元のまま	任意の大文字小文字
`0 & true`	小文字	小文字	小文字	小文字	小文字	任意の大文字小文字
`1 & false`	元のまま	小文字	元のまま	元のまま	任意の大文字小文字	任意の大文字小文字
`1 & true`	小文字	小文字	小文字	小文字	任意の大文字小文字	任意の大文字小文字
`2 & false`	元のまま	元のまま	元のまま	元のまま	任意の大文字小文字	任意の大文字小文字
`2 & true`	小文字	小文字	小文字	小文字	任意の大文字小文字	任意の大文字小文字

大文字小文字競合チェック

JDBC Catalog を通じて名前マッピングを実行する際、命名の競合が発生する可能性があります。例えば、ソースのカラム名が大文字小文字を区別し、ID と id の2つのカラムがある場合、lower_case_meta_names = true を設定すると、これら2つのカラムは小文字に変換された後に競合します。Doris は以下のルールに従って競合チェックを実行します：

すべてのシナリオにおいて、Doris は カラム名 の大文字小文字競合をチェックします（例：id と ID が同時に存在するかどうか）。
lower_case_meta_names = true の場合、Doris はデータベース名、テーブル名、カラム名の大文字小文字競合をチェックします（例：DORIS と doris が同時に存在するかどうか）。
lower_case_meta_names = false かつ lower_case_table_names が 1 または 2 に設定されている場合、Doris は テーブル名 の競合をチェックします（例：orders と ORDERS が同時に存在するかどうか）。
lower_case_table_names = 0 の場合、データベース名とテーブル名は大文字小文字を区別し、追加の変換は不要です。

大文字小文字競合の解決方法

競合が発生した場合、Doris はエラーを出力し、以下のアプローチを使用して競合を解決する必要があります。

大文字小文字のみが異なるデータベース、テーブル、またはカラム（例：DORIS と doris）により Doris が適切に区別できない場合、カタログに meta_names_mapping を設定して手動マッピングを指定することで競合を解決できます。

例

{
  "databases": [
    {
      "remoteDatabase": "DORIS",
      "mapping": "doris_1"
    },
    {
      "remoteDatabase": "doris",
      "mapping": "doris_2"
    }
  ],
  "tables": [
    {
      "remoteDatabase": "DORIS",
      "remoteTable": "DORIS",
      "mapping": "doris_1"
    },
    {
      "remoteDatabase": "DORIS",
      "remoteTable": "doris",
      "mapping": "doris_2"
    }
  ],
  "columns": [
    {
      "remoteDatabase": "DORIS",
      "remoteTable": "DORIS",
      "remoteColumn": "DORIS",
      "mapping": "doris_1"
    },
    {
      "remoteDatabase": "DORIS",
      "remoteTable": "DORIS",
      "remoteColumn": "doris",
      "mapping": "doris_2"
    }
  ]
}

Driver Package Security

Driver packageはユーザーによってDorisクラスターにアップロードされ、一定のセキュリティリスクをもたらします。ユーザーは以下の対策を通じてセキュリティを向上させることができます：

Dorisはjdbc_drivers_dirディレクトリ内のすべてのdriver packageを安全なものとみなし、それらに対してパスチェックを実行しません。管理者は、このディレクトリ内のファイルを自分で管理し、その安全性を確保する必要があります。
driver packageがローカルパスまたはHTTPパスを使用して指定された場合、Dorisは以下のチェックを実行します：
- 許可されたdriver packageパスは、FE設定項目jdbc_driver_secure_pathによって制御されます。この設定には複数のパスを含めることができ、セミコロンで区切られます。この設定が行われた場合、Dorisはdriver_urlパスプレフィックスがjdbc_driver_secure_pathに含まれているかどうかをチェックします。含まれていない場合、作成は拒否されます。
  
  例：
  
  jdbc_driver_secure_path = "file:///path/to/jdbc_drivers;http://path/to/jdbc_drivers" が設定されている場合、file:///path/to/jdbc_driversまたはhttp://path/to/jdbc_drivers で始まるdriver packageパスのみが許可されます。
- このパラメータはデフォルトで*です。空または*に設定されている場合、すべてのJarパッケージパスが許可されます。
データディレクトリを作成する際、checksumパラメータを使用してdriver packageのチェックサムを指定できます。driver packageのロード後、Dorisはチェックサムを検証し、検証に失敗した場合、作成は拒否されます。

Connection Pool Cleanup

Dorisでは、各FEおよびBEノードがconnection poolを維持し、個々のデータソース接続の頻繁な開閉を回避します。プール内の各接続は、データソースとの接続を確立し、クエリを実行するために使用できます。タスク完了後、これらの接続は再利用のためプールに返され、これによりパフォーマンスが向上するだけでなく、接続確立のシステムオーバーヘッドも削減され、データソースの接続制限に達することを防ぐのに役立ちます。

connection poolのサイズは、実際のニーズに応じて調整でき、異なるワークロードにより適切に対応できます。通常、プール内の最小接続数は1に設定すべきで、keep-aliveメカニズムが有効な場合に少なくとも一つの接続がアクティブな状態を維持することを保証します。最大接続数は、過度なリソース消費を回避するため、適切な値に設定すべきです。

BEでの未使用connection poolキャッシュの蓄積を防ぐため、BEでjdbc_connection_pool_cache_clear_time_secパラメータを設定してキャッシュクリーンアップ間隔を指定できます。デフォルト値は28,800秒（8時間）で、この時間後、BEはこの時間内に使用されなかったすべてのconnection poolキャッシュを強制的にクリアします。

Credential Update

JDBC Catalogを使用して外部データソースに接続する際は、データベース認証情報を慎重に更新することが重要です。

Dorisは、クエリに迅速に応答するためconnection poolを通じてアクティブな接続を維持しています。しかし、認証情報を変更した後、connection poolは古い認証情報を使用して新しい接続を試行し続け、失敗する可能性があります。システムは一定数のアクティブな接続を維持しようとするため、これらの誤った試行は繰り返され、一部のデータベースシステムでは、頻繁な失敗がアカウントロックアウトにつながる可能性があります。

認証情報を変更する必要がある場合は、Doris JDBC Catalogの設定を同期して更新し、Dorisクラスターを再起動してすべてのノードが最新の認証情報を使用することを保証し、接続失敗と潜在的なアカウントロックアウトを防ぐことが推奨されます。

可能なアカウントロックアウトには以下が含まれます：

MySQL: account is locked

Oracle: ORA-28000: the account is locked

SQL Server: Login is locked out

コネクションプールトラブルシューティング

HikariPool接続タイムアウトエラー: Connection is not available, request timed out after 5000ms
- 考えられる原因
  - 原因1: ネットワークの問題（例：サーバーに到達できない）
  - 原因2: 認証の問題（無効なユーザー名やパスワードなど）
  - 原因3: ネットワーク遅延が高く、接続作成が5秒のタイムアウトを超える
  - 原因4: 並行クエリが多すぎて、プールで設定された最大接続数を超えている
- 解決策
  - エラー Connection is not available, request timed out after 5000ms のみが発生する場合は、原因3と4を確認してください：
    - ネットワーク遅延の増加またはリソース枯渇を確認する。
    - プールの最大接続数を増やす：
      ALTER CATALOG catalog_name SET PROPERTIES ('connection_pool_max_size' = '100');

接続タイムアウトを増加する:

     ```sql
     ALTER CATALOG catalog_name SET PROPERTIES ('connection_pool_max_wait_time' = '10000');
     ```

Connection is not available, request timed out after 5000ms 以外に追加のエラーメッセージがある場合は、これらの追加エラーを確認してください：

 * ネットワークの問題（例：サーバーにアクセスできない）により接続に失敗する場合があります。ネットワーク接続が安定していることを確認してください。

 * 認証の問題（例：無効なユーザー名またはパスワード）も接続失敗の原因となる場合があります。設定内のデータベース認証情報を確認し、ユーザー名とパスワードが正しいことを確認してください。

 * 根本原因を特定するために、具体的なエラーメッセージに基づいてネットワーク、データベース、または認証に関する問題を調査してください。

適用シナリオ​

サポートされているデータベース​

Catalogの設定​

構文​

クエリ操作​

基本クエリ​

クエリ最適化​

述語プッシュダウン​

Function Pushdown​

行数制限​

書き込み操作​

Statement Passthrough​

適用シナリオ​

Passthrough SQL​

パススルーDDLおよびDML​

使用制限​

付録​

大文字小文字の区別設定​

表示名とクエリ名​

JDBC Catalog 名の大文字小文字区別ルール​

大文字小文字競合チェック​

大文字小文字競合の解決方法​

Driver Package Security​

Connection Pool Cleanup​

Credential Update​

コネクションプール トラブルシューティング​

適用シナリオ

サポートされているデータベース

Catalogの設定

構文

クエリ操作

基本クエリ

クエリ最適化

述語プッシュダウン

Function Pushdown

行数制限

書き込み操作

Statement Passthrough

適用シナリオ

Passthrough SQL

パススルーDDLおよびDML

使用制限

付録

大文字小文字の区別設定

表示名とクエリ名

JDBC Catalog 名の大文字小文字区別ルール

大文字小文字競合チェック

大文字小文字競合の解決方法

Driver Package Security

Connection Pool Cleanup

Credential Update

コネクションプールトラブルシューティング