バージョン: 3.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データソースの小さなテーブルでの結合クエリなど、データ統合にのみ適しています。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 Overviewセクションを参照してください。

クエリ操作

基本クエリ

-- 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外部テーブルクエリにおける述語プッシュダウンを以下のパラメータ変数を通じて制限・制御しています：

注意：現在、DorisはMySQL、Clickhouse、Oracleデータソースの述語プッシュダウンのみをサポートしています。将来的にはより多くのデータソースがサポートされる予定です。

enable_jdbc_oracle_null_predicate_push_down

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

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

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

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

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

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

データソース	ブラックリスト	ホワイトリスト	説明
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`

Function書き換えルール

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

データソース Doris関数ターゲット関数
MySQL nvl ifnull
MySQL to_date date
Clickhouse from_unixtime FROM_UNIXTIME
Clickhouse unix_timestamp toUnixTimestamp
Oracle ifnull nvl
カスタムfunction pushdownと書き換えルール

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

データソース	Doris関数	ターゲット関数
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 と連携して動作する追加のCatalogプロパティ lower_case_meta_names を使用します。

設定	説明
`lower_case_meta_names`	Catalog作成時に `properties` で指定され、そのCatalogにのみ適用されます。デフォルト値は `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 が適切に区別できない場合、Catalog に 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 packageパスが許可されます。
データディレクトリを作成する際、checksumパラメータを使用してdriver packageのチェックサムを指定できます。driver packageの読み込み後、Dorisはチェックサムを検証し、検証に失敗した場合は作成が拒否されます。

Connection Pool Cleanup

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

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

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

Credential Update

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

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

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

考えられるアカウントロックアウトには以下があります：

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​

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