1. 商標/免責事項
1.1. 免責事項
本マニュアルに記載された情報は、予告なしに変更される場合があります。株式会社インサイトテクノロジーは、本マニュアルに関していかなる種類の保証(商用性および特定の目的への適合性の黙示の保証を含みますが、これに限定されません)もいたしません。
株式会社インサイトテクノロジーは、本マニュアルに含まれた誤謬に関しての責任や、本マニュアルの提供、履行および使用に関して偶発的または間接的に起こる損害に対して、責任を負わないものとします。
1.2. 著作権と商標
本マニュアルのいかなる部分も、株式会社インサイトテクノロジーからの文書による事前の許可なしには、形態または手段を問わず決して複製・配布してはなりません。
Insight SQL Testing、PISOは株式会社インサイトテクノロジーの商標または登録商標です。
- 他社商標
-
-
Amazon Aurora、Amazon Bedrock、Amazon CloudWatch、Amazon EC2、Amazon RDS、Amazon S3、Amazon VPC、AWS、AWS Marketplaceは、米国および/またはその他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
-
Apacheは、Apache Software Foundationの米国およびその他の国における登録商標または商標です。
-
Azure、Microsoft Edge、SQL Serverは、米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
-
EDB Postgresは、EnterpriseDB Corporationの商標です。
-
Firefoxは、米国Mozilla Foundationの米国およびその他の国における商標です。
-
Google Chromeは、Google LLCの商標です。
-
Linuxは、Linus Torvalds氏の米国およびその他の国における登録商標または商標です。
-
MariaDBは、MariaDB Corporation Abおよびその子会社、関連会社のフィンランド、米国およびその他の国における登録商標です。
-
MySQL、Oracleは、Oracle Corporationおよびその子会社、関連会社の米国およびその他の国における登録商標です。
-
PostgreSQLは、カナダのPostgreSQLコミュニティ協会の登録商標です。
-
Snowflakeは、米国およびその他の国におけるSnowflake Inc.の登録商標または商標です。
-
VMware、VMware ESXiは、米国およびその他の地域におけるBroadcomの登録商標または商標です。
-
インテル®は、Intel Corporationまたはその子会社の商標です。
-
本製品には、OpenSSL Project(http://www.openssl.org)が開発したソフトウェアが含まれています(OpenSSL Toolkit で使用)。
-
その他の社名および製品名は、一般に各社の商標または登録商標です。なお、本文中には™、®マークは明記しておりません。
2. 本マニュアルの読み方
Insight Database Testing(Insight DT、またはIDT)は、2024年4月より製品名を「Insight SQL Testing」に変更しました。
一部の説明やパス等に旧製品名が含まれている場合があります。
- 表記について
-
本マニュアルでは、以下の表記方法を使用します。
-
注意事項は、以下のように示します。
本手順はSQLの評価までの基本的な手順のみを記載しています -
参照先は、以下のように示します。
詳細については、インストールマニュアルを参照してください。 -
コマンドボックスは、コマンドライン上の入力または表示内容を示します。
istctl upistcmon istctl startall
-
インラインブロック
はInsight SQL TestingやLinuxのコマンドを示します。
istctl
に追加コマンドがあります。 -
文中の 太字 はファイルやディレクトリを示します。
ファイルは /mnt/piso-data/idt-data/sct 配下に出力されます。 -
< > は、使用する環境によって表記が異なることを示します。
「 http://<インストールマシンのIPアドレス>:7777/idt/ 」の場合、インストールマシンのIPアドレスが「198.162.0.0」であるならば、「 http://198.162.0.0:7777/idt/ 」と読み替えてください。 -
PISO Manager/Insight SQL Testing Managerでは、以下のデータベースをまとめて指す場合「Amazon RDS」と表記します。
-
Amazon Aurora(PostgreSQL互換エディション)
-
Amazon Aurora(MySQL互換エディション)
-
Amazon RDS for Oracle
-
Amazon RDS for PostgreSQL
-
Amazon RDS for MySQL
-
Amazon RDS for MariaDB
-
-
3. はじめに
3.1. 製品の概要
Insight SQL Testing(以下、SQL Testingと表記)は、今までソースDB(移行元データベース)上で使用していたSQLを、ターゲットDB(移行先データベース)上で実際に使用できるかを検証します。
ソースDBでのSQLの取得は、株式会社インサイトテクノロジー独自のDMA機能を使うため、低負荷で網羅的に取得できます。取得したSQLは簡単にターゲットDBへ実行できます。
弊社製品PISOを使用しているお客様は、PISOで取得したSQLを使用できます。
ターゲットDBでのSQLの実行結果はビジュアライズされ、実行できないSQLの傾向や、性能が劣化したSQLが分かります。
また、SQL Testing上でSQLを書き換えて検証・保存することもできます。
3.2. 製品の構成
SQL TestingではソースDBで実行されているSQLを使用してアセスメントを実行します。SQLの取得と収集にはPISOを使用します。
すでに弊社製品PISOを導入しているお客様は、利用中のPISO TargetをSQLの取得に使用できます。
本製品は、ソースDBで実行するPISO Targetから取得したSQLを収集するPISO Manager部分と、ターゲットDBへSQLを実行するためのInsight SQL Testingマネージャー(以下、SQL Testing Managerと表記)部分とで構成されています。
ただし、ソースDBがAmazon RDS(Amazon RDS for SQL Serverを除く)の場合はPISO Targetは不要です。PISO ManagerまたはSQL Testing ManagerがAWS RDSのデータ(ログ)を取得して収集します。
ソースDBから収集したSQLを評価対象として、SQL Testing ManagerからターゲットDBへ実行し、実行結果を取得・分析することができます。
また、ソースDBと同様のテスト環境をテスト用ソースDBとして別途用意して、テスト用ソースDBとターゲットDBの2つのデータベースに同じSQLを実行してSQL実行結果や時間、実行性能を比較することができます。
AWSマイグレーションではデータベースのスナップショットからテスト用ソースDBとターゲットDBを作成して、2つのデータベースを指定したアセスメントを継続的に行うことができます。また、AWSマイグレーションではPISOを使用しません。
AWSマイグレーションの詳細は、「AWSマイグレーション」を参照してください。 |
3.3. SQL Testingのシステム要件
3.3.1. オンプレミスの場合
- ホストマシン
-
-
VMware ESXi 6.5以降
-
- インストールパッケージのファイル構成
-
弊社サポートサイト(Service Portal)にログインし、SQL Testingのインストールパッケージ(ZIPファイル)を入手してください。
インストールパッケージ(ZIPファイル)を展開すると、以下のようなファイル構成になります。-
SQL-Testing-ManagerXXXX.mf (バージョンによっては含まれない場合もあります。)
-
SQL-Testing-ManagerXXXX.ovf
-
SQL-Testing-ManagerXXXX-0.vmdk
-
SQL-Testing-ManagerXXXX-1.vmdk
-
SQL-Testing-ManagerXXXX-2.vmdk
-
SQL-Testing-ManagerXXXX-3.vmdk
-
- システム要件
-
ハードウェア 必要スペック vCPU
4以上
メモリ
8GB以上
ディスク
94GB以上 ※1
※1 一般的に、監視対象データベース1インスタンス(1か月)あたり50GB程度のディスク容量を必要としますが、利用状況により大きく異なります。94GBは、データ領域に50GB、バックアップ領域に10GBを設定した場合の例です。
詳細はPISO Managerインストールマニュアルの「蓄積データ領域について」を参照してください。(/dev/sdb:データ領域、/dev/sdc:バックアップ領域、/dev/sdd:PostgreSQLのWALログ領域) |
- ローカルで推論を行う場合のシステム要件
-
ローカル(SQL Testingと同一のマシン)で大規模言語モデル(以下、LLMと表記)による推論を行う場合、システム要件は以下のとおりです。
ハードウェア 必要スペック vCPU
4以上 ※ インテル AVX(Intel Advanced Vector Extensions)命令セットサポート必須
メモリ
16GB以上
ディスク
100GB以上
3.3.2. EC2の場合
Amazon EC2(以下、EC2と表記)でSQL Testingを使用することもできます。
AWS MarketplaceからSQL Testing ManagerのAmazonマシンイメージ(AMI)を入手してください。
|
3.3.3. Azure VMの場合
Azure Virtual Machines(以下、Azure VMと表記)でSQL Testingを使用することもできます。
Azure Marketplace: Insight SQL TestingからAzure VMイメージを入手してください。
Azure VM上でSQL Testingを構築する場合のシステム要件は、「Azure VM上でのSQL Testing Managerの起動」を参照してください。 |
3.3.4. PISO Managerの機能でSQLを取得時のディスク容量について
「PISO Managerを使用したSQL収集と出力」で(方法1)(方法2)のいずれの場合も必要なディスク容量の目安は、1評価セットで250GB/月です。
-
SQL Testingの監視対象データベース1インスタンスあたりが50GB/月。
-
PISO Managerのマイニングサーチを使用する場合、蓄積データ領域が通常の50GB/月の3倍必要になり150GB/月。
-
出力されるCSVファイルが50GB/月。
上記3つの使用量から、50+150+50=250GB/月としています。
ディスクは/mnt/piso-dataを、1日につき1評価SQLセットで9GB弱使用します。
(Azure VMにSQL Testing Managerを構築した場合は/data/piso-data)
PISO ManagerとSQL Testing Managerを接続して蓄積したSQLを転送する場合(方法2)は/mnt/piso-dataの他に、一時的にルートも使用します。
- 補足事項
-
-
必要となるディスクサイズは、評価SQLセットの期間や、SQLテキストのサイズにより変動します。
-
SQLテキストが大きい場合には、上記よりマージンを設けて容量を確保してください。
-
PISO ManagerのWAL領域(/mnt/pg-wal)が不足すると、PISO Managerが使用しているPostgreSQLの異常終了やWAL領域の使用率が高騰する等の事象が発生する場合があります。その場合はWAL領域を拡張してください。 詳細は、弊社サポートサイト(Service Portal)の[Insight PISO]>[ナレッジ]メニューの右部にある[Search…]から文書番号:000001943を参照してください。 |
3.4. 性能要件
すべてのSQL Testing Managerの基準値は以下の前提条件から算出されています。
- ハードウェア基準値
項目 | 基準値 |
---|---|
vCPU |
4 |
メモリ |
16GB |
ディスク |
130MB/secの転送性能 |
上記ハードウェア基準値をもとに以下のSQL Testing Manager 1台ごとの稼働上限値を設けています。
- SQL Testing Manager稼働基準値
項目 | 基準値 |
---|---|
SQLのサイズ |
1KB/1SQL |
1時間あたりの処理可能なアクセスログの件数 |
最大20.8万件 |
1日の合計件数 |
5000万件 |
3.5. 対応データベース
SQL Testingで対応するデータベースの種類とSQL取得の対応と、バージョンについて説明します。
ソースDBのSQL取得方法は「PISO Managerの機能でSQLを取得」「SQL Testing Managerの機能でSQLを取得」があります。
-
PISO Managerの機能でSQLを取得
SQL Testingに同梱されているPISO Managerのマイニングサーチ機能を利用して、ソースDBからSQLを取得する方法を指します。取得したSQLを使って評価SQLセットを作成する方法は次の2点です。-
CSVファイルを出力してSQL Testing Managerにアップロード・指定する方法
出力したCSVファイルは[CSVファイルから作成]からアップロード・指定します。 -
PISO Managerから直接評価SQLセットを作成する方法
-
-
SQL Testingの機能でSQLを取得
SQL Testing Managerの評価SQLセット機能([Amazon RDSから作成]および[Amazon CloudWatch Logsから作成])または、AWSマイグレーション機能を利用して、ソースDBからSQLを取得する方法を指します。
対応しているソースDB※は、一部のAmazon RDSにのみ対応しており、Amazon RDSで出力されたログからSQLを取得します。
※詳細については、下の表を参照してください。
評価対象のSQLは、SQL Testingのログ取得方法(評価SQLセット)によって異なります。詳細は、「評価対象のSQLについて」を参照してください。 |
データベース |
ソースDBのバージョン |
ターゲットDBのバージョン |
備考 |
|
---|---|---|---|---|
PISO Managerの機能でSQLを取得 |
SQL Testing Managerの機能でSQLを取得 |
|||
Oracle Database |
10g以上 |
× |
11gR2、12c、12cR2、18c、19c、23ai(旧名称:23c)※7、8 |
ソースDBにはPISO Targetをインストールする必要があります。 |
PostgreSQL |
9.3以上(互換製品を含む※1) |
× |
9.4以上(互換製品を含む※1) |
|
SQL Server |
2005以上 |
× |
2017、2019(互換製品を含む※2) |
|
MySQL |
5.5以上 |
× |
5.6、5.7、8.0(互換製品を含む※3) |
|
Snowflake※4 |
× |
× |
8.24以上 |
ソースDB(SnowflakeからSQLを収集)としては利用できません。 |
Amazon Aurora(PostgreSQL互換エディション)※5 |
※6 |
10~15、16※7 |
10~15、16※7 |
|
Amazon Aurora(MySQL互換エディション)※5 |
1~3 |
1~3 |
PISO Managerの機能でSQLを取得する場合、一般ログ(general log)を使用していないため行コメントを解釈できません。 |
|
Amazon RDS for Oracle |
× |
19c |
||
Amazon RDS for PostgreSQL※5 |
10~15、16※7 |
10~15、16※7 |
||
Amazon RDS for SQL Server |
× |
15.00.4073.23.v1 |
ソースDBにはPISO Target用のEC2インスタンスが必要です。 |
|
Amazon RDS for MySQL※5 |
5.7、8 |
5.7、8 |
PISO Managerの機能でSQLを取得する場合、一般ログ(general log)を使用していないため行コメントを解釈できません。 |
|
Amazon RDS for MariaDB |
× |
10.2~10.6 |
PISO Managerの機能でSQLを取得する場合、一般ログ(general log)を使用していないため行コメントを解釈できません。 |
|
AWS以外のマネージドデータベース |
× |
× |
△ |
通常のOracle Database、PostgreSQL、SQL Server、MySQLの要件に従います。 |
※1 PostgreSQLの互換製品には、Amazon Aurora(PostgreSQL互換エディション)、EDB Postgres Advanced Server、FUJITSU Software Enterprise Postgresを含みます。
※2 SQL Serverの互換製品には、Azure SQL Database、Azure SQL Managed Instanceを含みます。
※3 MySQLの互換製品には、Amazon Aurora(MySQL互換エディション)、MariaDB 10.1以上を含みます。
※4 SQL Testing 4.1以降で対応しています。
Snowflakeをターゲットにしたアセスメントにおいて、評価SQLセット作成元のDB種は不問です。
※5 AWSマイグレーション機能を使用してアセスメントできます。
※6 PISO Managerが対応するデータベースと同様です。
詳細は、弊社サポートサイト(Service Portal)から[Insight PISO]>[製品ダウンロード]で製品検索し、表示される関連ファイル一覧から対応表を参照してください。
※7 SQL Testing 4.1以降で対応しています。
※8 本製品の動作確認は23cでのみ実施していますが、互換性のある23aiも同等にターゲットDBとして使用することができます。
ソースDBがオンプレミス上のデータベースまたはRDS for SQL Serverの場合、PISO Targetの動作がサポートされている必要があります。 各種データベースに対するPISO Targetの対応状況は、弊社サポートサイト(Service Portal)の[Insight SQL Testing]>[製品ダウンロード]から製品検索・確認できます。 詳細は販売代理店または販売元にお問合せください。 |
3.6. 対応ブラウザ
ブラウザは、以下のものを使用してください。それ以外のブラウザでは、画面が正しく表示されない場合があります。
-
Google Chrome 91以降のバージョン
-
Microsoft Edge 92以降のバージョン
-
Mozilla Firefox 90.0以降のバージョン
3.7. SQL Testing Managerインストールディレクトリ
SQL Testing Managerが仮想マシン(VM)提供の場合、既定のインストールディレクトリは/home/insight/idt/(以下、<IDT_HOME>と表記)です。
3.8. 使用している用語について
用語 | 説明 |
---|---|
SQL Testing Manager |
SQL Testing マネージャー。 |
評価SQLセット |
ターゲットDBへ実行するフォーマットに変更したSQLのデータセットです。 |
アセスメント |
評価SQLセットをターゲットDBへ実行すること。または実行結果のデータセットです。 |
修正SQLセット |
評価SQLセットの一部のSQLに対し、修正を適用してアセスメントを実行するSQLのデータセットです。 |
PI Hash |
SQLに付与する弊社独自のハッシュ値です。 |
PISO |
弊社が開発しているデータベースアクティビティモニタリングツールです。 |
PISO Manager |
PISOにおいて、アクセス情報を蓄積・分析するためのマネージャーサーバーです。 |
PISO Target |
PISOにおいて、アクセス情報を取得するために監視対象サーバーにインストールするモジュールです。 |
マイニングサーチ |
PISOの蓄積データ抽出機能です。 |
3.9. 製品サポートについて
製品サポートについては、販売代理店または販売元にお問合せください。
また、その他のサポートの提供に関する詳細、製品バージョンごとのサポートレベルについては、製品サポート、Insight SQL Testing 製品サポートレベルを確認してください。
4. インストールと各種設定
SQL Testing ManagerはPISO Managerを同梱した形態で提供しています。
SQL Testing Managerをインストールすると、SQL Testing Manager WebコンソールとPISO Manager Webコンソールが設定され、接続できます。
-
オンプレミス環境にSQL Testing Managerをインストールする場合はVMwareイメージ(.ovf)を使用します。
「SQL Testing Managerの構築と設定(オンプレミスの場合)」を参照してください。 -
EC2でSQL Testing Managerを使用する場合は「SQL Testing Managerの構築と設定(EC2の場合)」を参照してください。
-
Azure VMでSQL Testing Managerを使用する場合は「SQL Testing Managerの構築と設定(Azure VMの場合)」を参照してください。
SQL Testing 4.0で同梱していたLLMのGPT4Allは、SQL Testing 4.1以降は同梱されません。 SQL Testing 4.1以降を新規インストールした環境でGPT4Allを用いてLLMによる推論を行う場合は、LLMのアップグレード用パッケージの別途インストールが必要です。 「LLMのみ更新する場合」の手順に従いインストールしてください。 Amazon Bedrockを使用する場合は、この手順は不要です。 |
構築作業は、通常30分以内で終了します。
ソースDBからSQL取得するためにPISO Targetを使用する場合には、弊社サポートサイト(Service Portal)にログインの上、PISO Target各インストールマニュアルを参照してください。 |
4.1. SQL Testing Managerの構築と設定(オンプレミスの場合)
4.1.1. 概要
SQL Testing Managerのインストールパッケージは、VMwareのイメージとして提供されるソフトウェアアプライアンスです。
仮想マシンイメージをインポートすることでアプリケーションを使用できます。
4.1.2. PISO Managerインストールマニュアルとの差異
仮想マシンイメージの操作はPISO Managerのインストールマニュアルに従います。
以下はSQL Testing Managerとしてマニュアルを読み替える箇所です。
-
仮想マシンのホスト名は「idt」です。
-
「OSのPISO用ユーザー」を「OSのSQL Testing用ユーザー」に読み替えてください。
-
ライセンスパスワードはSQL Testing Manager Webコンソールから設定します。
SQL Testing Managerおよび、同梱されているPISO Managerはあらかじめ自動起動設定されています。 -
istctl
の一部コマンドは使用しません。-
setlicense
-
id
-
showlicense
-
-
istctl
に追加コマンドがあります。-
upidt
-
downidt
-
SQL Testing Managerのインストールパッケージには、セットアップ済みのPISO Managerが同梱されています。PISO Managerのインストール作業を行う必要はありません。 |
4.1.3. インポート手順について
仮想マシンイメージのインポート(デプロイ)、ディスク設定およびネットワーク設定はPISO Managerインストールマニュアルの「オンプレミス環境でインストール」の章を参照してください。 ただし、「初期セットアップ」の手順は不要です。 |
4.1.4. Webコンソールへのアクセス
ブラウザからPISO ManagerとSQL Testing ManagerのWebコンソールに接続します。
- PISO Manager Webコンソール
-
PISO Manager Webコンソールでは、蓄積の設定・確認を行います。
以下のURLへアクセスし、既定のユーザーとパスワードを入力します。
-
http://<SQL Testing ManagerのIPアドレス>:7777/piso/
-
ユーザー名:administrator
-
パスワード:insight
-
- SQL Testing Manager Webコンソール
-
SQL Testing Manager Webコンソールでは、ターゲットDBへ接続しアセスメントを行います。
以下のURLへアクセスし、既定のユーザーとパスワードを入力します。
また、初回ログインの場合は、既定の管理者ユーザーでログインし、管理者画面から一般ユーザーを作成します。-
http://<SQL Testing ManagerのIPアドレス>:7777/idt/
-
ユーザー名:administrator
-
パスワード:insight
-
一般ユーザーの新規作成については、「一般ユーザーの新規作成」を参照してください。
-
ユーザーの初期パスワードは、変更することを推奨します。パスワードの変更方法については、「アカウント管理」を参照してください。
-
-
4.1.4.1. ポートの変更
PISO Managerインストールマニュアルの「ポート番号を変更する」を参照してください。 |
Apache HTTP Serverで使用するポート番号はPISO Managerと共通となります。
WebコンソールのURLは以下の形式ですので、ポート番号を変更した場合は合わせて変更してください。
http://<SQL Testing ManagerのIPアドレス>:<ポート番号>/<idtまたはpiso>/
4.1.4.2. 起動停止
SQL Testing Manager Webコンソール単独の起動・停止は以下のコマンドで実施します。
-
起動する場合
istctl upidt
-
停止する場合
istctl downidt
4.2. SQL Testing Managerの構築と設定(EC2の場合)
SQL TestingをEC2上に構築した場合のシステム構成図を示します。以下の構成図は、移行元データベースをオンプレミス上に構築した場合を想定しています。
なお、移行元データベースをAWS上にも構築することができます。
EC2上でSQL Testingを使用するには、AWS Marketplaceの中から利用形態に応じて製品を選択し、[Continue to Subscribe]ボタンをクリックしてください。
「AWS上で利用時の留意事項」を参照してください。 |
4.2.1. AWS上で利用時のネットワーク要件
SQL Testing ManagerをEC2に作成し、Amazon RDSからログを取得する場合は、SQL Testing ManagerとAmazon RDS API間の接続経路を確保する必要があります。
SQL Testing Managerがインターネットに接続できない閉ざされたサブネット(Private subnet)に所属している場合、RDSインスタンスが稼働しているサブネットへのネットワーク経路を確保しただけでは、ログの取得はできません。
SQL Testing ManagerはAmazon RDS APIを通してログを取得しますので、インターフェースVPCエンドポイント(AWS PrivateLink)を使用してAmazon RDS APIへの専用経路を作成してください。
以下は、SQL Testing ManagerのSQL取得の経路イメージです。
また、SQL Testing Managerが開かれたサブネットに所属する場合(インターネットに接続可能)、通常はAmazon RDS APIに接続できるため問題ありません。
SQL Testing Managerとデータベースが閉ざされたサブネットに所属している場合は、「エンドポイントの作成」を参照して作成してください。 |
- セキュリティグループについて
-
エンドポイントへアクセスする場合、使用するAWSのサービスのインスタンスに対してセキュリティグループのアウトバウンドにHTTPS(443)を許可する必要があります。
許可が必要なAWSのサービスは、以下のとおりです。操作 AWSのサービス PISO Managerの機能でAmazon RDSからログを取得する※1
-
自AWSアカウントの場合
RDS
-
IAMロールを使用しアクセスを委任する場合(別AWSアカウント)※2
RDS、STS
SQL Testingの機能で直接Amazon RDSのログを取得して評価SQLセットを作成する場合(自AWSアカウント)※3
RDS、STS
AWSマイグレーションを使用する(自AWSアカウントのみ)
-
テスト用ソースDBになるRDSインスタンス/AuroraクラスターをSQL Testingから作成する場合※4
RDS、EC2、STS
-
テスト用ソースDBになるRDSインスタンス/AuroraクラスターをSQL Testingから作成しない場合※5
RDS、STS
ターゲットDBになるRDSインスタンス/AuroraクラスターをSQL Testingから作成する場合※6
RDS、EC2、STS
※1 詳細は、「PISO Managerを使用したSQL収集と出力」を参照してください。
※2 詳細は、PISO Managerインストールマニュアルの「AWSアカウント間でIAMロールを使用しアクセスを委任した環境の場合」を参照してください。
※3 詳細は、「評価SQLセットの作成方法」項目を参照してください。
※4 詳細は、「スナップショットからRDSインスタンス/Auroraクラスタを作成する」を参照してください。
※5 詳細は、「登録してあるターゲットDBを使用する」を参照してください。
※6 詳細は、ターゲットDBの追加の「スナップショットからRDSインスタンス/Auroraクラスタを作成する」項目を参照してください。
-
4.2.1.1. エンドポイントの作成
-
AWSマネジメントコンソール画面でVPCサービスを選択し、[エンドポイント]>[エンドポイントを作成]ボタンをクリックします。
-
名前を設定し、サービスカテゴリに[AWSのサービス]を選択します。
-
サービスから接続先のAWSサービスを選択します。例えば、「rds」と検索して該当するものを選択してください。
-
VPCからエンドポイントを作成するVPCを選択します。
-
プライベートDNSを有効にします。[追加設定]から[DNS名を有効化]をオンにします。
プライベートDNSを有効にしないと、デフォルトのDNSホスト名を使用してプライベートリンクを実行することができません。
[DNSホスト名][DNS解決]を有効にすることで、プライベートDNSが有効化されます。 -
サブネットからインターフェイスエンドポイントを使用するVPCのサブネットを選択します。
-
セキュリティグループを選択します。アウトバウンドにHTTPS(443)が許可されたセキュリティグループを設定してください。
-
ポリシーは[フルアクセス]を選択し、[エンドポイントを作成]ボタンをクリックしてください。
|
4.2.1.2. ネットワークの接続確認
-
ネットワーク接続については、以下の
curl -v
コマンドを実行してRDSやSTSなどへの応答を確認してください。RDSのデフォルトのホスト名の場合(東京リージョン)
$ curl -v https://rds.ap-northeast-1.amazonaws.com
STSのデフォルトのホスト名の場合(東京リージョン)
$ curl -v https://sts.ap-northeast-1.amazonaws.com
4.2.2. EC2上でのSQL Testing Managerの起動
以下の手順に従い、EC2インスタンスを起動します。
-
AWS MarketplaceからSQL Testing ManagerのAmazonマシンイメージ(AMI)を選択します。
-
サブスクライブの利用規約を確認し、AMI、ソフトウェアバージョン、リージョンを選択します。
-
インスタンス起動方法(アクション)に[Launch through EC2]を選択し、[Launch]をクリックします。
EC2コンソールの「インスタンスを起動」画面に遷移します。 -
インスタンスの名前とタグを入力します。
-
インスタンスタイプは、vCPU 4以上、メモリ8GB以上(m5.xlarge推奨)を選択します。
-
セキュリティグループは、SSH(22)に加え、HTTP(7777)を許可します。
-
PISO Targetは、PISO Managerのポート番号7777に対してデータを送信します(既定の動作)。
-
ポート番号7777は、SQL Testing Manager Webコンソールへのアクセスにも利用されます。
-
Apache HTTP Serverで使用するポート番号は、1023番以下には設定できません。
ポート番号の変更については、PISO Managerインストールマニュアルの「ポート番号を変更する」を参照してください。
-
-
ストレージ(データ領域)は、監視対象データベース1インスタンス(1か月)あたり50GB程度のストレージを必要としますが、利用状況により大きく異なります。
ストレージで使用するEBSボリュームタイプはgp3を推奨します。
データサイズについて不明な場合、EC2起動時にはデータ領域に50GB、バックアップ領域に10GB程度で設定し、利用状況に応じてストレージサイズの変更を検討してください。詳細はPISO Managerインストールマニュアルの「蓄積データ領域について」を参照してください。(/dev/sdb:データ領域、/dev/sdc:バックアップ領域、/dev/sdd:PostgreSQLのWALログ領域) -
概要の設定項目を確認した上で、[インスタンスを起動]ボタンをクリックして起動します。
PISO Managerのインストールマニュアルも必要に応じて参照してください。その際は「PISO Managerインストールマニュアルとの差異」も確認してください。
4.2.3. SQL Testing Managerの設定(ストレージサイズの変更)
EC2起動時に指定したストレージサイズをOS側で認識させるには以下の手順で行います。
EC2起動時に、既定の1GBからボリュームサイズを変更している場合、EC2インスタンス起動後、ec2-userユーザーにてSSHで接続し、以下のコマンドでディスクサイズを拡張します。
sudo xfs_growfs -d /mnt/piso-data
sudo xfs_growfs -d /mnt/piso-backup
4.2.4. Webコンソールへのアクセス
ブラウザからPISO ManagerとSQL Testing ManagerのWebコンソールに接続します。
- PISO Manager Webコンソール
-
PISO Manager Webコンソールでは、蓄積の設定・確認を行います。
以下のURLへアクセスし、既定のユーザーとパスワードを入力します。
-
http://<SQL Testing ManagerのIPアドレス>:7777/piso/
-
ユーザー名:administrator
-
パスワード:起動したEC2のインスタンスID
-
- SQL Testing Manager Webコンソール
-
SQL Testing Manager Webコンソールでは、ターゲットDBへ接続しアセスメントを行います。
以下のURLへアクセスし、既定のユーザーとパスワードを入力します。
初回ログインの場合には、既定の管理者ユーザーでログインし、管理者画面から一般ユーザーを作成します。-
http://<SQL Testing ManagerのIPアドレス>:7777/idt/
-
ユーザー名:administrator
-
パスワード:起動したEC2のインスタンスID
-
一般ユーザーの新規作成については、「一般ユーザーの新規作成」を参照してください。
-
ユーザーの初期パスワードは、変更することを推奨します。パスワードの変更方法については、「アカウント管理」を参照してください。
-
-
4.2.5. Amazon S3互換のオブジェクトストレージへの転送
S3互換のオブジェクトストレージへ接続することで一定時間経過したシステムとジョブ実行のログを転送します。
この設定の使用は任意です。
- EC2環境でIAMロールを使う場合の手順
-
-
対象のS3バケットへのPutObject、GetObject、ListBucket、DeleteObjectをEC2にアタッチしたロールに付与します。
{ "Sid": "任意", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::バケット名", "arn:aws:s3:::バケット名/*" ] }
-
設定後にSQL Testing Managerを終了します。
istctl downidt
-
SQL Testingの設定ファイル<IDT_HOME>/config/config.ymlに接続設定を加えます。
data: /* 既存設定に以下を追加 */ IDT_STORAGE_BUCKET: バケット名 IDT_STORAGE_REGION: バケットリージョン
-
SQL Testing Managerを開始します。
istctl upidt
-
Web接続のエラーが発生した場合は、
idtctl logs
を実行して、objectStorage.jsの接続エラーを示すerror objectStorage.js
の行を確認してください。2022-03-03T10:09:09.963Z info objectStorage.js test connection 2022-03-03T10:09:10.087Z error objectStorage.js Bucket Not found. name=hoge
-
4.2.6. SQL TestingのデータベースをEC2からAmazon Auroraへ移行する方法
EC2上で稼働しているSQL Testingのデータベース(idt-middle-db)をAmazon Aurora(PostgreSQL互換エディション)に移行する方法について説明します。
SQL Testing 4.1から、内部のデータベース名が「idt-db」から「idt-middle-db」へ変更となりました。 SQL Testing 4.0以前からのアップグレード環境の場合、この変更の影響は受けずに「idt-db」のままになります。 「idt-middle-db」を「idt-db」に読み替えてください。 |
この移行により、SQL Testingのデータベースがデータの保存に使用していたデータディレクトリから離れます。
これによりSQL Testingのアプリケーション(idt-app)とのリソースの競合を解消することができます。
|
4.2.6.1. 移行手順
以下の手順は、SQL Testing Managerが起動している状態を想定しています。
- ステップ1 Auroraのインスタンス作成
-
移行先のAmazon Aurora(PostgreSQL互換エディション)インスタンスを作成します。
-
エンジンタイプは[Aurora (PostgreSQL Compatible)]を選択してください。
-
エンジンバージョンは[Aurora PostgreSQL (Compatible with PostgreSQL 13.x)]を選択してください。
-
データベースユーザーに「idt」を作成してください。
-
プライマリインスタンスはEC2インスタンス(SQL Testing Manager)と同じアベイラビリティゾーン(AZ)に配置してください。
-
以降、作成したAmazon Aurora(PostgreSQL互換エディション)インスタンスのホスト名を<host>、データベースユーザーのパスワードを<password>、ポートを<port>とします。
-
- ステップ2 EC2からのデータベースダンプ・移行先へリストア
-
-
EC2インスタンス(SQL Testing Manager)にec2-userユーザーでログインします。
-
OSのSQL Testing用ユーザー(通常、insight)へ変更します。
sudo su - insight
-
idt-appを停止します。
podman stop idt-app
-
下記コマンドを実行し、idt-middle-dbコンテナの中身を作成したAmazon Aurora(PostgreSQL互換エディション)インスタンスへ移行します。
podman exec idt-middle-db bash -c "pg_dump -U idt idt -p 5433 | PGPASSWORD=<password> psql -h <host> -U idt -d postgres -p <port>"
-
移行が完了したらSQL Testing Managerを停止します。
istctl downidt
-
<IDT_HOME>/bin/idt.ymlから PostgreSQLコンテナのセクションをコメントアウトします。
下記はSQL Testing 4.0におけるコメントアウト例です。# - image: docker.io/library/postgres:13 # name: db # env: # - name: POSTGRES_USER # value: idt # - name: POSTGRES_PASSWORD # value: idt # - name: POSTGRES_DB # value: idt # args: ["-c", "config_file=/etc/postgresql/postgresql.conf"] # volumeMounts: # - mountPath: /var/lib/postgresql/data:z # name: idt-postgres # - mountPath: /etc/postgresql/postgresql.conf:z # name: idt-postgresql-conf # - mountPath: /dev/shm # name: dshm (中略) # - name: idt-postgres # hostPath: # path: $IDT_POSTGRES_HOME # type: Directory # - name: idt-postgresql-conf # hostPath: # path: $IDT_HOME/config/postgresql.conf # type: File (中略) # - name: dshm # hostPath: # path: /dev/shm # type: Directory
-
<IDT_HOME>/config/config.ymlの「IDT_DATABASE_URL」をAuroraの接続情報に書き換えます。
apiVersion: v1 kind: ConfigMap metadata: name: idt-config data: IDT_LOG_LEVEL: INFO IDT_DATABASE_URL: postgres://idt:<password>@<host>:<port>/postgres IDT_REDIS_URL: redis://127.0.0.1:6379/0 IDT_MAX_REQUEST_SIZE: 100mb TZ: Asia/Tokyo
-
SQL Testing Managerを起動します。
istctl upidt
-
4.2.7. アンインストール手順について
SQL Testing ManagerのEC2インスタンスを選択し、[インスタンスを終了]をクリックしてください。
AWSのドキュメントを参照してください。 |
4.3. SQL Testing Managerの構築と設定(Azure VMの場合)
Azure VM上でSQL Testingを使用するには、Azure Marketplaceから、[今すぐ入手する]ボタンをクリックしてください。
4.3.1. Azure VM上でのSQL Testing Managerの起動
以下の手順に従い、Azure VMを作成して起動します。
-
Azure MarketplaceからSQL TestingのVMイメージを選択して起動します。
-
VMサイズは、vCPU 4以上、メモリ8GB以上(D4s v4以上推奨)を選択します。
-
ストレージは、監視対象データベース1インスタンス(1か月)あたり50GB程度のストレージを必要としますが、利用状況により大きく異なります。
詳細はPISO Managerインストールマニュアルの「蓄積データ領域について」を参照してください。(/dev/sdb:データ領域、/dev/sdc:バックアップ領域、/dev/sdd:PostgreSQLのWALログ領域) -
ネットワークセキュリティグループは、SSH(22)に加え、HTTP(7777)を許可します。
-
PISO Targetは、PISO Managerのポート番号7777に対してデータを送信します(既定の動作)。
-
ポート番号7777は、SQL Testing Manager Webコンソールへのアクセスにも利用されます。
ポート番号の変更については、PISO Managerインストールマニュアルの「ポート番号を変更する」を参照してください。
-
-
[詳細]タブの[カスタムデータとcloud-init]のカスタムデータに以下を追加してください。
#cloud-config swap: filename: /swapfile size: 4G maxsize: 4G
-
Azure VMが起動したら、起動時に指定したユーザーにてSSHで接続することができます。
4.3.2. SQL Testing Managerの設定とインストール
Azure VMではインスタンス起動時にディスクサイズを変更することができないため、以下の手順に従います。
-
インスタンス起動中の場合、Azure VMを終了します。
-
Azure PortalのAzure VM画面にて、ディスクを選択し、対象のディスクのサイズを変更します。
-
Azure VMを起動します。
-
以下のコマンドを実行しディスクサイズを拡張します。
sudo xfs_growfs -d /data/piso-data sudo xfs_growfs -d /data/piso-backup
4.3.3. Webコンソールへのアクセス
ブラウザからPISO ManagerとSQL Testing ManagerのWebコンソールに接続します。
- PISO Manager Webコンソール
-
PISO Manager Webコンソールでは、蓄積の設定・確認を行います。
以下のURLへアクセスし、既定のユーザーとパスワードを入力します。
-
http://<SQL Testing ManagerのIPアドレス>:7777/piso/
-
ユーザー名:administrator
-
パスワード:起動したAzure VMの名前
-
- SQL Testing Manager Webコンソール
-
SQL Testing Manager Webコンソールでは、ターゲットDBへ接続しアセスメントを行います。
以下のURLへアクセスし、既定のユーザーとパスワードを入力します。
初回ログインの場合には、既定の管理者ユーザーでログインし、管理者画面から一般ユーザーを作成します。-
http://<SQL Testing ManagerのIPアドレス>:7777/idt/
-
ユーザー名:administrator
-
パスワード:起動したAzure VMの名前
-
一般ユーザーの新規作成については、「一般ユーザーの新規作成」を参照してください。
-
ユーザーの初期パスワードは、変更することを推奨します。パスワードの変更方法については、「アカウント管理」を参照してください。
-
-
4.3.4. アンインストール手順について
SQL Testing ManagerのAzure VMを選択し、削除してください(通常、残しておく必要のあるリソースが他にない場合は、リソースグループごと削除します)。
Azureのドキュメントを参照してください。 |
4.4. アップグレード
SQL Testingのアップグレード手順は、現在使用しているバージョンによって異なります。
また、SQL Testing 4.0以降ではLLMによる推論を用いた機能追加があります。そのため、LLMによる推論をローカルで行うか、外部で行うか(SQL Testing本体のみのアップグレード)によって手順が異なります。
4.4.1. 現在使用しているSQL Testingが3.0以前の場合
使用中のSQL Testingが3.0以前のバージョンの場合、モジュールの更新によるアップグレードはできません。
新規バージョンのSQL Testingを利用するには、以下の手順に従い実施してください。
-
使用中のSQL Testingで、評価SQLセットに使用したCSVファイルを、PISO Manager Webコンソールのマイニングサーチの画面からダウンロードします。
-
使用中のSQL Testingでの設定内容を記録して別途保存します。
(作成済みユーザー情報、アセスメント設定、評価SQLセット設定、ターゲットDBの情報など) -
使用中のSQL Testingを停止し、新規バージョンのSQL Testingを起動します。
-
使用中のSQL TestingでダウンロードしたCSVファイルは、新規バージョンのSQL Testingで評価SQLセット作成時にも引き続き使用可能です。
-
使用中のSQL Testingでの設定内容を新規バージョンのSQL Testingに設定し、評価SQLセットの作成やアセスメントの実行を行います。
ターゲットDBの状態が変わっている場合は、同じ結果が再現されない場合もあります。
4.4.2. 現在使用しているSQL Testingが3.1~3.7の場合
使用中のSQL Testingが3.1~3.7の場合、モジュールの更新により最新バージョンにアップグレードできます。
SQL Testing 4.2以降にアップグレード、かつLLMによる推論を行う場合は、バージョンにより手順が異なるため、サポートまでお問い合わせください。 |
LLMによる推論を行わない場合は、SQL Testing 3.1~4.xで本体のみアップグレードする場合(ローカルで推論を行わない場合)の手順に従い実施してください。
アップグレードを実行する前に、実行中のアセスメントや作成処理中の評価SQLセットなどがないことを確認の上、仮想マシンのバックアップを事前に取得することを推奨します。
4.4.3. SQL Testing 3.1~4.xで本体のみアップグレードする場合(ローカルで推論を行わない場合)
-
弊社サポートサイト(Service Portal)にログインし、SQL Testingのアップグレードインストール用パッケージ(SQL-Testing-Manager-XXXX-upgrade.tar.gz)を入手してください。
-
パッケージを展開すると、以下のようなファイル構成になります。
-
sql_testing_vXXXX.tar.gz
-
upgrade.sh
-
-
upgrade.shファイルとsql_testing_vXXXX.tar.gzファイルを仮想マシンのinsightユーザーのホームに配置します。
-
各仮想マシンのコンソールにログインし、OSのSQL Testing用ユーザー(通常、insight)でログインします。
-
upgrade.sh、sql_testing_vXXXX.tar.gzファイルの所有者をinsightユーザーに変更します。
-
upgrade.shファイルに実行権限を付与します。
$ chmod +x upgrade.sh
-
upgrade.shファイルを実行し、アップグレードを完了させます。
$ ./upgrade.sh sql_testing_vXXXX.tar.gz 2>&1 | tee -a upgrade.log
4.4.4. SQL Testing 4.0以降で本体とLLMをアップグレードする場合(ローカルで推論を行う場合)
-
弊社サポートサイトにログインし、SQL Testingのアップグレードインストール用パッケージ(SQL-Testing-Manager-XXXX-upgrade.tar.gz)とLLMのアップグレード用パッケージ(model-x.x.x.x-upgrade.tar.gz)を入手してください。
記載のアップレグードパッケージはSQL Testing 4.2以降のパッケージ名です。
パッケージを展開すると、以下のファイル構成になります。-
sql_testing_vXXXX.tar.gz
-
upgrade.sh
-
model_vxxxx.tar.gz
-
-
これらのファイルを仮想マシンのInsightユーザーのホームディレクトリへ配置します。
-
各仮想マシンのコンソールにログインし、OSのSQL Testing用ユーザー(通常、insight)でログインします。
-
upgrade.sh、sql_testing_vXXXX.tar.gz、model_vxxxx.tar.gzファイルの所有者をinsightユーザーに変更します。
-
upgrade.shファイルに実行権限を付与します。
$ chmod +x upgrade.sh
-
upgrade.shファイルを実行し、アップグレードを完了させます。
$ ./upgrade.sh sql_testing_vXXXX.tar.gz model_vxxxx.tar.gz 2>&1 | tee -a upgrade.log
SQL Testing 4.0を新規インストールしてローカルで推論を行っていない環境の場合、$IDT_HOME/bin/idt.ymlの下記コメントアウトを外し、SQL testing managerを再起動してください。
# LLMコンテナはリソース消費を抑えるためにデフォルトでは起動しない # - image: localhost/idt-llm:latest # name: llm # envFrom: # - configMapRef: # name: llm-config
-
コンテナを再起動します。
$ istctl downidt upidt
4.4.4.1. LLMのみ更新する場合
-
弊社サポートサイトにログインし、LLMのアップグレード用パッケージ(model-x.x.x.x-upgrade.tar.gz)を入手してください。
パッケージを展開すると、以下のファイル構成になります。-
upgrade.sh
-
model_vxxxx.tar.gz
-
-
これらのファイルを仮想マシンのInsightユーザーのホームディレクトリへ配置します。
-
各仮想マシンのコンソールにログインし、OSのInsight DT用ユーザー(通常、insight)でログインします。
-
ファイルの所有者をinsightユーザーに変更し、upgrade.shファイルに実行権限を付与します。
$ chmod +x upgrade.sh
-
upgrade.shファイルを実行し、アップグレードを完了させます。
$ ./upgrade.sh --llm-only model_vxxxx.tar.gz 2>&1 | tee -a upgrade.log
4.4.5. アップグレード時に実施されるデータベースマイグレーションについて
SQL Testingのバージョンによっては、アップグレード時にデータベースマイグレーションを行います。
データベースマイグレーションの処理は、SQL Testing Manager自体のアップグレードとは別に実行されます。
そのため、upgrade.shファイルの実行後にアップグレード完了のメッセージ(launching SQL-Testing-Manager: finish)が表示された後も、裏ではデータベースマイグレーションの処理は続いている場合があります。
データベースマイグレーションの実施中にSQL Testing ManagerのWebコンソールを表示しようとするとProxy Errorの画面が表示されますが、データベースマイグレーションが完了後に正常に表示可能になります。
マイグレーションの実行状況を確認したい場合は、以下のコマンドにてマイグレーションのログを確認します。
$ podman logs idt-app
マイグレーションが発生する場合のログ
== 20230508034525-assessment-hook: migrating ======= == 20230508034525-assessment-hook: migrated (0.013s) == 20230525023108-fix-start-time-filter: migrating ======= == 20230525023108-fix-start-time-filter: migrated (0.009s) == 20230526020019-add-result-record-column-on-assessmentparameter: migrating ======= == 20230526020019-add-result-record-column-on-assessmentparameter: migrated (0.009s) == 20230626085508-add-db-and-session-fields-to-assessment-results: migrating ======= == 20230626085508-add-db-and-session-fields-to-assessment-results: migrated (0.008s)
-
==<タイムスタンプ>-<マイグレーション名>: migrating=======
この行はマイグレーションが実行中であることを示します。 -
==<タイムスタンプ>-<マイグレーション名>: migrated (<所要時間>s)
この行はマイグレーションが完了したことを示します。 -
すべてのマイグレーションが「migrated」と表示されるまでは、マイグレーションが未完了であるため、SQL Testing ManagerのWebコンソールを利用することはできません。
マイグレーションが発生しない場合、下記のようなログは記録されません。
==<タイムスタンプ>-<マイグレーション名>: migrated (<所要時間>s) ==<タイムスタンプ>-<マイグレーション名>: migrating=======
マイグレーションが発生しない場合のログ
[insight@idt ~]$ podman logs idt-app > idt@0.0.0 migrate > npx sequelize-cli db:migrate Sequelize CLI [Node: 20.11.0, CLI: 6.6.0, ORM: 6.32.0] Loaded configuration file "src/config/config.json". Using environment "production". No migrations were executed, database schema was already up to date. npm notice npm notice New minor version of npm available! 10.2.4 -> 10.5.0 npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.5.0> npm notice Run `npm install -g npm@10.5.0` to update! npm notice 2024-03-29T03:15:16.700Z info secret.js Initializing secret files. 2024-03-29T03:15:16.733Z info auth.js Initializing Auth Service 2024-03-29T03:15:16.739Z info license.js Initializing license service. 2024-03-29T03:15:16.750Z info objectStorage.js Initializing Storage Service 2024-03-29T03:15:16.751Z info objectStorage.js No options of IDT_STORAGE_* are not set. 2024-03-29T03:15:16.751Z info objectStorage.js Using the local file storage only. 2024-03-29T03:15:16.770Z info internal-socket-app.js domain socket launched. /tmp/idt_internal_app.sock 2024-03-29T03:15:16.893Z info app.js Server is online.
データベースマイグレーションの実施対象がデータ件数の多いテーブルである場合に、データベースマイグレーションの完了までに時間を要することがあります。 また、データベースマイグレーションの実施時に一時的に/mnt/piso-dataのディスクを使用しますが、この時使用されるディスクサイズは対象テーブルのデータ件数によって増加します。 そのためアップグレードは、/mnt/piso-dataのディスクサイズに余裕がある状態で実施してください。 |
4.4.6. 同梱のPISO Managerアップグレード
SQL Testingに同梱されているPISO Managerはアップグレードできません。
SQL Testingインストール時に同梱されているPISO Managerバージョンのまま使用する形になります。
不具合による問題が発生した場合は、サポート窓口へお問合せください。
5. 操作の流れ
SQL TestingにおけるSQLの取得と評価は、以下の一連の流れに従い実施します。
ここではSQL Testing 4.0の画面で操作の流れを説明します。
5.1. SQLの取得
PISO ManagerまたはSQL Testingの機能を使用して、ソースDB(SQL収集元)に蓄積したSQLを収集し、出力を行います。
5.1.1. PISO Managerの機能でSQLを取得する
5.1.1.1. 蓄積の設定
-
PISO Managerから、ソースDBのデータベースインスタンスに対して蓄積設定を行います。
蓄積設定は、PISO Manager Webコンソール(http://<SQL Testing ManagerのIPアドレス>:7777/piso/)から実行します。詳細は、PISO Manager設定マニュアルの「監視する内容を設定する」を参照してください。 -
PISO TargetがインストールされたデータベースでのSQL実行が蓄積されます。
5.1.1.2. 蓄積したSQLの出力
PISO ManagerとSQL Testing Managerを接続して蓄積したSQLを転送します。
PISO Managerで蓄積したSQLをCSVファイルに出力することもできます。詳細は、「PISO Managerで蓄積したSQLをCSVファイルに出力して受け渡す(方法1)」を参照してください。 |
-
PISO Manager Webコンソールの[設定管理]>[PISO Manager設定]>[外部サーバー接続]>[新規作成]ボタンをクリックします。
-
外部サーバー接続設定画面から以下のように設定して、接続情報を設定します。
設定項目 設定内容 外部サーバー接続識別子
任意の文字列を入力します。
接続タイプ
[SQL Testing連携]を選択します。
IPアドレスとポート番号
SQL Testing Managerとの同梱環境では「127.0.0.1」「7778」を設定します。
ユーザー名とパスワード
SQL Testing Managerの一般ユーザーアカウントを入力します。
HTTPS※
HTTPSを使って通信を行う場合には、チェックボックスにチェックを入れてください。
サーバー証明書検証※
サーバー証明書の検証が必要な場合は、チェックボックスにチェックを入れてください。
※ SQL Testing 4.2以降で対応しています。SQL Testing 4.1以前からアップグレードした場合、この機能は追加されません。
-
[保存]ボタンをクリックします。
-
[データ検索]>[マイニングサーチ]>[ジョブ実行条件指定]タブから、マイニングサーチのジョブ実行条件を設定します。
設定項目 設定内容 出力形式
[外部サーバー接続]を選択します。
外部サーバー接続識別子※1
外部サーバー接続設定画面で任意で設定した外部サーバー接続識別子を選択します。
外部サーバー転送先ディレクトリ名※1
「/」を入力します。
出力文字コード※1
SQL Testingと外部接続で連携する際は、以下の設定にしてください。
-
出力文字コード:UTF-8
-
圧縮形式:圧縮なし
圧縮形式※1
データベースの種類※2
評価SQLセットに登録するソースDBの種類を選択します。
SQL Testing 4.1以前の場合は「Oracle」になります。SQLの重複を削除する※2
重複を排除して評価SQLセットを作成します。
※1 SQL Testing 4.1以前の場合に表示されます。
※2 SQL Testing 4.2以降で対応しています。SQL Testing 4.1以前からアップグレードした場合、この機能は追加されません。 -
-
画面上部の[SUBMIT]ボタンをクリックします。
マイニングサーチジョブの実行が成功すると、SQL Testing Manager Webコンソールに評価SQLセットが自動作成されます。 -
続いて、評価SQLセットが作成されていることを確認します。「PISO Managerの機能でSQLを取得した場合」に進みます。
|
5.1.2. SQL Testingの機能でSQLを取得する
ソースDBが以下のAmazon RDSの場合のみ、SQL Testingの機能でSQLを取得できます。
-
Amazon Aurora(PostgreSQL互換エディション)
-
Amazon Aurora(MySQL互換エディション)
-
RDS for PostgreSQL
-
RDS for MySQL
AWSマネジメントコンソールから、以下の設定を行います。
-
AWS上のネットワーク要件を確認します。
SQL Testing Managerがインターネットに接続できない閉ざされたサブネット(Private subnet)に所属している場合、エンドポイントを作成する必要があります。 -
必要なIAMロールを設定します。
Amazon RDSからログを取得して評価SQLセットの作成を行う場合に必要なIAMポリシーを作成し、SQL Testingを構築したEC2にIAMロールを付与してください。
詳細は、必要なIAM設定についてを参照してください。 -
RDSインスタンスまたはAurora DBクラスターにログファイルの出力を設定します。
詳細は、以下を参照してください。 -
続いて、評価SQLセットの作成を行います。「SQL Testingの機能でSQLを取得する場合」に進みます。
5.2. SQLの評価(SQL Testing Manager Webコンソール)
以下の手順は、SQL Testing Manager Webコンソール(http://<SQL Testing ManagerのIPアドレス>:7777/idt/)から実行します。
本手順はSQLの評価までの基本的な手順を記載しています。
5.2.1. 評価SQLセットの作成
5.2.1.1. PISO Managerの機能でSQLを取得した場合
-
左のページメニューから[評価SQLセット]をクリックします。
-
「蓄積したSQLの出力」により、評価SQLセット一覧に以下の名前で評価SQLセットが自動作成されていることを確認します。
評価SQLセット名:<マイニングサーチ名>_<YYYY-MM-DD HH24:MI:SS> -
評価SQLセット名とデータベースは評価SQLセット画面から必要に応じて修正します。
-
続いて、ターゲットDBの設定を行います。
5.2.1.2. SQL Testingの機能でSQLを取得する場合
-
左のページメニューから[評価SQLセット]をクリックします。
-
[新規作成]ボタンをクリックし、[評価SQLセット作成方法]に[Amazon RDSから作成]を選択します。
-
ソースDBの情報を入力して、[新規作成]ボタンをクリックします。
設定項目 設定内容 評価SQLセット名
任意の評価SQLセットの名前を入力します。大文字、小文字を区別します。
使用するAWSプロファイル名
AWS認証に使用するAWSプロファイル名に「デフォルト」を選択します。
リージョン
東京リージョンの場合、ap-northeast-1と入力します。
インスタンスID/クラスターID
ソースDBのインスタンスID、またはクラスターIDを入力します。
データベース名
ソースDBのデータベース名を入力します。
-
作成した評価SQLセットが一覧に表示されます。ステータスが完了アイコン[]になると完了です。
-
続いて、ターゲットDBの設定を行います。
5.2.2. ターゲットDBの設定
-
左のページメニューから[ターゲットDB]をクリックします。
-
ターゲットDBの一覧画面から[新規作成]ボタンをクリックします。
-
[既存のDBを登録する]を選択します。
-
以下の必要項目を設定した後、[新規作成]ボタンをクリックします。
設定項目 設定内容 ターゲットDB名
任意のターゲットDBの名前を入力します。
データベース
対象のデータベースの種類を選択します。
バージョン
データベースのバージョン情報を入力します。
接続識別子
事前に指定した接続識別子を入力します(Oracleを選択した場合)。
DSN(データソース名)
DSNのIPアドレスを入力します(SQL Server、Snowflakeを選択した場合)。
ホスト名
IPアドレスを入力します(PostgreSQL、MySQLを選択した場合)。
ポート
ポート番号を入力します(PostgreSQL、MySQLを選択した場合)。
データベース名
データベース名を入力します(PostgreSQL、MySQLを選択した場合)。
テスト接続
データベースのユーザー名とパスワードを設定して接続を確認します。
-
ターゲットDBの種類によっては、事前に接続設定等が必要です。詳細は「事前準備」を参照してください。
-
Amazon RDSやAmazon AuroraをターゲットDBに設定する場合には、「ターゲットDBの追加」を参照してください。
-
5.2.3. アセスメントの実行(SQLの評価)
-
左のページメニューから[アセスメント]をクリックします。
-
アセスメントの一覧画面から[新規作成]ボタンをクリックします。
-
以下の必要項目を設定した後、[新規作成]ボタンをクリックします。
設定項目 設定内容 アセスメント名
評価結果として保存される任意の名前を入力します。
評価SQLセット名
作成した評価SQLセットを選択します。
実行タイプ
[実行]または[パース]を選択します。
バインド変数書式変換
必要に応じて「有効」に設定します。
DBへのデータ反映
「指定なし」を選択します。
タイムアウト設定
指定しません。データベースの設定でタイムアウト設定がされていればそれに従います。
同時セッション処理数
評価SQLセットをターゲットDBで実行する際に同時に処理するセッション数に「1」を設定します。
0秒の仮定値
0.2などの数値を設定します。
期間(セッション)
必要に応じて期間を設定します。
ターゲットDB
作成したターゲットDBを選択します。
DBユーザー設定
フィルタリングしたい実行DBユーザーをチェックし、パスワードを指定します。
ターゲットDBに接続できるかテストする場合、[テスト接続]ボタンをクリックします。
|
5.2.4. 結果の確認
-
左のページメニューから[アセスメント]をクリックします。
-
一覧からアセスメント名を選択すると結果のサマリーを確認できます。
-
実行結果の詳細は、左のページメニューの[SQL実行結果一覧]をクリックします。
-
SQL実行結果一覧画面左の連番(#)を選択して、SQLの詳細などを確認します。
6. 事前準備
6.1. ターゲットDB設定・接続設定
ソースDBから取得したSQLをターゲットDBへ実行する前に、ターゲットDBのデータベースの種類に応じて、以下の設定を行います。
SQLの取得については「PISO Managerを使用したSQL収集と出力」を参照してください。 |
6.1.1. Oracle Database
6.1.1.1. 接続識別子の指定
ターゲットDBがOracle Databaseの場合、SQL Testing Managerへ接続識別子の設定が必要になります。
接続識別子の指定方法は、2つの方法があります。
- SQL Testing Manager Webコンソールから指定する方法
-
SQL Testing Manager WebコンソールからOracle Databaseへ接続する際の接続識別子に、以下のいずれかの文字列を入力します。
事前にtnsnames.oraを編集する作業を省くことができます。-
簡易接続ネーミング・メソッド
ホスト:ポート/サービス名
db-host:1521/ORCL
-
Oracle Net Serviceのキーワード値ペア
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=ホスト) (PORT=ポート))(CONNECT_DATA=(SERVICE_NAME=サービス名)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=db-host) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCL)))
-
- tnsnames.oraを編集する方法
-
SQL Testing Managerのファイル<IDT_HOME>/etc/tnsnames.oraを編集して、接続識別子(net_service_name)を指定します。
SQL Testing Manager WebコンソールからOracle Databaseへ接続する際の接続識別子に、ファイルtnsnames.oraで指定した接続識別子を指定してください。基本的な書式net_service_name= (DESCRIPTION= (ADDRESS=(protocol_address_information)) (CONNECT_DATA= (SERVICE_NAME=service_name) ) )
詳細はOracle Databaseのドキュメントを参照してください。
6.1.1.2. Oracleユーザー権限設定
以下の場合は、Oracle DatabaseのSQL実行ユーザーに権限を付与します。
- 実行計画取得時にDBMS_XPLAN.DISPLAY_CURSORファンクションを使用する場合
-
-
必要なビューへのSELECT権限を付与します。
これは任意の設定であり、権限がない場合はexplain plan forを使用します。
GRANT SELECT ON SYS.V_$SESSION TO ユーザー GRANT SELECT ON SYS.V_$SQL TO ユーザー GRANT SELECT ON SYS.V_$SQL_PLAN_STATISTICS_ALL TO ユーザー
-
- アセスメントの中断処理で長時間応答の無いSQLの切断を可能にする場合
-
SQL Testing 4.1以降は中断処理の権限が不要になったため、この手順は必要ありません。
-
V$SESSIONのSELECTとセッション切断に必要な権限を付与します。 これは任意の設定あり、アセスメントのタイムアウト設定によって対処できます。
オンプレミスGRANT SELECT ON SYS.V_$SESSION TO ユーザー GRANT ALTER SYSTEM TO ユーザー
Amazon RDSGRANT SELECT ON SYS.V_$SESSION TO ユーザー GRANT EXECUTE ON RDSADMIN.RDSADMIN_UTIL TO ユーザー
-
|
6.1.2. MySQL
6.1.2.1. performance_schemaの有効化
ターゲットDBがMySQLおよびその互換製品の場合、データベース本体のperformance_schemaを有効にする必要があります。
performance_schemaとSQL Testing Managerで使用するイベントが有効であるかを確認します。
それぞれの項目で不足がある場合は有効化手順に従って設定を行います。
- 有効化確認
-
-
performance_schemaの確認
以下のクエリの結果がValue=Onならばperformance_schemaが有効です。> SHOW VARIABLES LIKE 'performance_schema'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | performance_schema | ON | +--------------------+-------+
-
setup_instrumentsの確認
以下の操作でstatement/com/Prepareとstatement/com/ExecuteのENABLEDとTIMED両方が「YES」であることを確認します。> use performance_schema; > select * from setup_instruments where name IN ('statement/com/Prepare', 'statement/com/Execute'); +-----------------------+---------+-------+ | NAME | ENABLED | TIMED | +-----------------------+---------+-------+ | statement/com/Prepare | YES | YES | | statement/com/Execute | YES | YES | +-----------------------+---------+-------+
-
setup_consumersの確認
以下の操作でevents_statements_currentとevents_statements_historyのENABLEDが「YES」であることを確認します。> use performance_schema; > select * from setup_consumers where name IN ('events_statements_current', 'events_statements_history'); +---------------------------+---------+ | NAME | ENABLED | +---------------------------+---------+ | events_statements_current | YES | | events_statements_history | YES | +---------------------------+---------+
-
setup_actorsの確認
評価対象のHOST、USER、ROLEに対してsetup_actorsのENABLEDとHISTORYの両方が「YES」であることを確認します。「%」はすべてが対象であることを示しています。
> use performance_schema; > select * from setup_actors; +------+------+------+---------+---------+ | HOST | USER | ROLE | ENABLED | HISTORY | +------+------+------+---------+---------+ | % | % | % | YES | YES | +------+------+------+---------+---------+
-
接続ユーザーの権限の確認
SQL Testingから接続するユーザーにperformance_schemaへのSELECT権限が付与されているかを確認します。
下記の「権限が適切に付与されている場合」のような結果であれば問題ありません。
SQL Testingから使用するDBアカウントで操作
> use performance_schema;
権限が適切に付与されている場合
> select count(*) from setup_instruments; +----------+ | count(*) | +----------+ | 1210 | +----------+
権限が不足している場合
> select count(*) from setup_instruments; ERROR 1142 (42000): SELECT command denied to user 'ユーザー名'@'localhost' for table 'setup_instruments'
-
- 有効化手順
-
-
performance_schemaとsetup_instruments、setup_consumersの有効化
オンプレミスの場合
my.cnf またはデータベースから読み込まれる設定ファイルのmysqldセクションに以下を追加してデータベースを再起動します。
[mysqld] performance_schema=ON performance-schema-instrument='statement/com/Prepare=ON' performance-schema-instrument='statement/com/Execute=ON' performance-schema-consumer-events_statements_current=ON performance-schema-consumer-events_statements_history=ON
クラウドサービスの場合
各サービスのドキュメントを参照してください。
-
setup_actorsの設定
setup_actorsに計測対象を加えます。> use performance_schema;
すべてを計測対象にする場合
> insert into setup_actors values ('%','%','%','YES');
特定のユーザーのみを対象にする場合
> insert into setup_actors values ('%','対象にするユーザー','%','YES');
-
接続ユーザー権限の設定
以下のクエリで接続ユーザーへperformance_schemaへのSELECT権限を与えます。
必要ユーザーすべてに対して実行してください。> GRANT SELECT ON 'performance_schema'.* TO 'ユーザー名'@'%';
-
6.1.3. SQL Server
6.1.3.1. データソース名の指定
ターゲットDBがSQL Serverおよびその互換製品の場合、SQL Testing ManagerへODBCデータソース名の設定が必要になります。設定方法は、2つの方法があります。
- SQL Testing Manager Webコンソールから指定する方法
-
SQL Testing Manager WebコンソールからSQL Serverへ接続する際のDSN(データソース名)に、以下の文字列を入力します。
事前にodbc.iniを編集する作業を省くことができます。-
ODBCデータソース文字列(Driver、UID、PWDは除く)
Server=ホスト,ポート;Database=データベース;
Server=db-host,1433;Database=master;
-
AutoTranslate=yes;も追加することを推奨します。
-
SQL Testing 4.1からは、セミコロンがあれば改行しても問題ありません。
-
-
- odbc.iniを編集する方法
-
SQL Testing Managerのファイル<IDT_HOME>/etc/odbc.iniを編集して、データソース名を指定します。
SQL Testing Manager WebコンソールからSQL Serverへ接続する際のDSNに、odbc.iniファイルで指定したデータソース名を指定してください。
Driverは「Driver=ODBC Driver 18 for SQL Server」を指定します。基本的な書式[SQL Server] Driver=ODBC Driver 18 for SQL Server Server=host,1433 Database=master
詳細はMicrosoftのドキュメントを参照してください。
6.1.4. Snowflake
SQL Testing 4.1以降で対応しています。
6.1.4.1. データソース名の指定
ターゲットDBがSnowflakeの場合、SQL Testing ManagerへODBCデータソース名の設定が必要になりま す。
設定方法は、2つの方法があります。
- SQL Testing Manager Webコンソールから指定する方法
-
SQL Testing Manager WebコンソールからSnowflakeへ接続する際のDSN(データソース名)に、以下の文字列を入力します。
事前にodbc.iniを編集する作業を省くことができます。-
ODBCデータソース文字列(Driver、UID、PWDは除く)
Server=アカウント識別子.snowflakecomputing.com;Database=データベース;Schema=スキーマ;Warehouse=ウェアハウス;
Server=myaccount.snowflakecomputing.com;Database=mydatabase;Schema=public;Warehouse=mywarehouse;
-
SQL Testing 4.1からは、セミコロンがあれば改行しても問題ありません。 |
- odbc.iniを編集する方法
-
SQL Testing Managerのファイル<IDT_HOME>/etc/odbc.iniを編集して、データソース名を指定します。
SQL Testing Manager WebコンソールからSnowflakeへ接続する際のDSNに、odbc.iniファイルで指定したデータソース名を指定してください。基本的な書式[Snowflake] Driver=SnowflakeDSIIDriver Server=myaccount.snowflakecomputing.com Database=mydatabase Schema=public Warehouse=mywarehouse
デフォルト設定されている項目は省略可能です。 |
詳細は、Snowflakeのドキュメントを参照してください。 |
6.2. Amazon RDS上でのログファイル出力設定
Amazon RDSをソースDBとして、ログ情報を取得して評価SQLセットを作成するためには、RDSインスタンスまたはAurora DBクラスターにてログファイル出力の設定が必要です。
SQL Testingで直接Amazon RDSのログを取得して評価SQLセットを作成する場合、AWSマイグレーション機能を使用する場合に設定してください。
PISO Managerの機能でAmazon RDSからログを取得する場合には、PISO Managerインストールマニュアルの「監視対象データベースがAmazon RDSの場合」を参照してください。 |
6.2.1. RDS for PostgreSQL、Amazon Aurora(PostgreSQL互換エディション)
RDS for PostgreSQL、Amazon Aurora(PostgreSQL互換エディション)の場合、出力するPostgreSQLログの形式を標準ログと監査ログ(pgAudit)から選択できます。
何も指定しない場合には、標準ログをデフォルトで出力します。
6.2.1.1. PostgreSQL標準ログの出力
PostgreSQL標準ログ形式を変換に使用する場合は、対象データベースのRDS for PostgreSQL、Amazon Aurora(PostgreSQL互換エディション)での標準ログの出力を有効にします。
-
RDSコンソールを開き、DBパラメータグループ(Aurora DBクラスターではDBクラスターパラメータグループ)に以下の設定を行います。
-
log_statementを
ALL
に設定します。 -
log_rotation_ageを
10
に設定します。 -
log_connectionsを
1
(on)に設定します。 -
log_disconnectionsを
1
(on)に設定します。 -
RDS for PostgreSQLの場合:
log_filenameをpostgresql.log.%Y-%m-%d-%H
に設定します。 -
Amazon Aurora(PostgreSQL互換エディション)の場合:
log_filenameをpostgresql.log.%Y-%m-%d-%H%M
に設定します。(通常は分単位(%M)を指定してください。)
-
6.2.1.2. PostgreSQL監査ログ(pgAudit)の出力
PostgreSQL監査ログ(pgAudit)形式をデフォルトで変換に使用するためには、以下のように設定を切り替えます。
-
SQL Testingにec2-userユーザーにてSSH接続してログインします。
-
SQL Testingの設定ファイル<IDT_HOME>/config/config.ymlにログ形式の設定を追加します。
data: /* 既存設定に以下を追加 */ IDT_POSTGRES_LOG_FORMAT: pgaudit
-
SQL Testingを再起動します。
続いて、対象データベースのRDS for PostgreSQL、Amazon Aurora(PostgreSQL互換エディション)での監査ログ(pgAudit)の出力を有効にします。
-
RDSコンソールを開き、DBパラメータグループ(Aurora DBクラスターではDBクラスターパラメータグループ)に以下の設定を行います。
-
pgaudit.logを
ALL
に設定します。 -
pgaudit.log_parameterを
1
(on)に設定します。 -
pgaudit.roleをrds_pgauditに設定します。
-
log_rotation_ageを
10
に設定します。 -
log_connectionsを
1
(on)に設定します。 -
log_disconnectionsを
1
(on)に設定します。 -
shared_preload_librariesに
pgaudit
を追加します。(元の設定値は削除しないでください。) -
RDS for PostgreSQLの場合:
log_filenameをpostgresql.log.%Y-%m-%d-%H
に設定します。 -
Amazon Aurora(PostgreSQL互換エディション)の場合:
log_filenameをpostgresql.log.%Y-%m-%d-%H%M
に設定します。(通常は分単位(%M)を指定してください。)
-
-
インスタンスを再起動します。
-
初めてインスタンスを起動する場合は、データベースにログインし、以下のSQLを実行します。
[PostgreSQL] CREATE ROLE rds_pgaudit; CREATE EXTENSION pgaudit;
|
6.2.2. RDS for MySQL、Amazon Aurora(MySQL互換エディション)
対象のデータベースが RDS for MySQL、Amazon Aurora(MySQL互換エディション)の場合、以下の手順で一般ログの出力とファイル出力を有効にします。
-
RDSコンソールを開き、DBパラメータグループ(Aurora DBクラスターではDBクラスターパラメータグループ)で以下を設定します。
-
general_logをon(
1
)に設定します。 -
log_outputを
FILE
に設定します。
-
|
6.3. 必要なIAM設定について
EC2に構築したSQL Testing Managerで以下の機能を利用する際には、EC2へのIAMロールの設定もしくは必要なIAMロールが付与されたIAMユーザーのアクセスキーが必要となります。
AWSマネジメントコンソール画面でIAMロールまたはIAMユーザーを作成し、アクセスに必要なポリシーを付与して、EC2へアタッチを行ってください。
ここでは、EC2とRDSが同じAWSアカウントを使用していると仮定し、IAMロールを利用した場合について説明します。
IAMユーザーを利用する場合でも付与するポリシー内容は同じです。
使用する機能により、必要なポリシーが異なります。
機能に合わせて以下の内容でIAMポリシーを作成してください。
IAMロールに該当するIAMポリシーを付与して、そのIAMロールをSQL Testing ManagerのEC2インスタンスへアタッチしてください。
使用する機能 | IAMロールに付与するポリシー | |
---|---|---|
PISO ManagerでAmazon RDSのログを取得 |
||
SQL Testing Managerで評価SQLセットをAmazon RDSから作成 |
||
SQL Testing Managerで評価SQLセットをAmazon CloudWatch Logsから作成 |
||
SQL Testing ManagerでスナップショットからRDSインスタンス/AuroraクラスターをターゲットDBとして新規作成 |
||
SQL Testing ManagerのAWSマイグレーション機能 |
||
SQL Testing ManagerのLLMでAmazon Bedrockを使用 |
※ xxxxxxxxxxxxはAWSアカウントID、ap-northeast-1はリージョンに置き換えてください。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "rds:DownloadDBLogFilePortion", "rds:DescribeDBInstances", "rds:DownloadCompleteDBLogFile", "rds:DescribeDBLogFiles", "rds:DescribeDBClusters" ], "Resource": [ "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:cluster:*", "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:db:*" ] } ] }
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "rds:DescribeDBEngineVersions", "rds:DescribeOrderableDBInstanceOptions", "ec2:DescribeSecurityGroups" ], "Resource": "*" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "rds:DownloadDBLogFilePortion", "rds:DescribeDBInstances", "rds:DownloadCompleteDBLogFile", "rds:DescribeDBLogFiles", "rds:DescribeDBClusters" ], "Resource": [ "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:cluster:*", "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:db:*" ] }, { "Sid": "VisualEditor2", "Effect": "Allow", "Action": [ "rds:StartDBCluster", "rds:StopDBCluster", "rds:StartDBInstance", "rds:StopDBInstance", "rds:CreateDBCluster", "rds:CreateDBInstance", "rds:ModifyDBInstance", "rds:ModifyDBCluster", "rds:AddTagsToResource", "rds:RestoreDBClusterFromSnapshot", "rds:RestoreDBInstanceFromDBSnapshot", "rds:DescribeDBClusterParameterGroups", "rds:DescribeDBParameterGroups", "rds:DescribeOptionGroups", "rds:DescribeDBSubnetGroups", "rds:DescribeDBSnapshots", "rds:DescribeDBClusterSnapshots", "rds:DescribeDBInstances", "rds:DescribeDBClusters", "rds:DeleteDBCluster", "rds:DeleteDBInstance" ], "Resource": [ "arn:aws:rds::xxxxxxxxxxxx:global-cluster:*", "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:db:sql-testing-*", "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:cluster:sql-testing-*", "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:pg:*", "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:cluster-pg:*", "arn:aws:rds:*:*:snapshot:*", "arn:aws:rds:*:*:cluster-snapshot:*", "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:subgrp:*", "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:secgrp:*", "arn:aws:rds:ap-northeast-1:xxxxxxxxxxxx:og:*" ] } ] }
{ "Version": "2012-10-17", "Statement": [ { "Sid": "CloudWatchLogsPermissions", "Effect": "Allow", "Action": [ "logs:FilterLogEvents", "logs:DescribeLogGroups" ], "Resource": "arn:aws:logs:*:xxxxxxxxxxxx:log-group:*" } ] }
{ "Version": "2012-10-17", "Statement": [ { "Sid": "BedrockPermissions", "Effect": "Allow", "Action": [ "bedrock:ListFoundationModels", "bedrock:InvokeModel" ], "Resource": "*" } ] }
SQL Testing ManagerをEC2インスタンスで構成していない場合は、上記IAMポリシーを付与したIAMユーザーを作成し、アクセスキーとシークレットアクセスキーを用意します。SQL Testing ManagerへSSHでアクセスの上、アクセスキーとシークレットアクセスキーを、/home/insight/.aws/credentialsファイルに以下の書式で記載します。また、PISOでRDSからログを取得する場合は、蓄積設定でアクセスキー情報を設定します。 [default] aws_access_key_id=AKIAIOSFODNN7EXAMPLE aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY 認証情報ファイルの詳細は、設定ファイルと認証情報ファイルの設定を参照してください。 |
EC2とRDSインスタンスが別々のAWSアカウントを使用している場合は、アクセスを委任する設定が必要です。 詳細は、以下を参照してください。 Insight Database TestingでAssumeRoleを使用して、他のAWSアカウントのAuroraから評価SQLセットを作成する |
6.4. PISO Managerを使用したSQL収集と出力
SQL TestingからソースDBの評価SQLセットを作成する前に、ソースDBからSQLを取得する必要があります。
ここでは、PISO Managerの機能でSQLを取得して、SQL Testing Managerに受け渡し、評価SQLセットを作成するまでの操作を説明します。
PISO Manager Webコンソールへアクセスして、以下のいずれかの方法でSQLを取得してください。
-
PISO Managerで蓄積したSQLをCSVファイルに出力して受け渡す(方法1)
PISO ManagerのWebコンソールからPISO Targetで取得したSQLを収集し、マイニングサーチ結果をCSVファイルに出力します。その後、SQL TestingのWebコンソールからCSVファイルをアップロードして評価SQLセットを作成します。 -
PISO ManagerとSQL Testing Managerを接続して蓄積したSQLを転送する(方法2)
PISO ManagerのWebコンソール上で、SQLの収集から評価SQLセットの作成までの一連の操作をすべて設定します。
|
6.4.1. PISO Managerで蓄積したSQLをCSVファイルに出力して受け渡す(方法1)
-
ブラウザからPISO Manager Webコンソールへ接続します。
-
[データ検索]>[マイニングサーチ]をクリックします。
-
[ジョブ実行条件指定]タブから以下のように設定して、蓄積したSQLをCSVファイルへ出力します。
設定項目 設定内容 ジョブ名
マイニングサーチのジョブ名を入力します。
最大実行時間
マイニングサーチが実行可能な最大時間幅(分)を入力します。
最大取得行数
マイニングサーチで取得する行数を入力します。
出力形式
[標準(MSテーブル)][CSV形式][外部サーバー接続]のうち、[CSV形式]を選択します。
[CSV形式]は、CSVファイルにマイニングサーチ結果を出力します。出力ディレクトリ
マイニングサーチ結果を指定したディレクトリに転送します。
SQL Testing Manager内に転送する場合は、以下のディレクトリを指定します。/mnt/piso-data/idt-data/src
(Azure VMにSQL Testing Managerを構築した場合/data/piso-data/idt-data/src)出力文字コード
SQL Testingと外部接続で連携する際は、以下の設定にしてください。
-
出力文字コード:UTF-8
-
圧縮形式:圧縮なし
圧縮形式
-
-
[SQL監視]タブを選択した状態にします。
条件オプションの詳細については、PISO Manager Webコンソール右上のアイコンからPISO Managerの設定マニュアルを開き、「[ジョブ実行条件指定]タブ」を参照してください。 -
画面上部の[SUBMIT]ボタンをクリックします。
-
マイニングサーチが実行され、[終了ジョブ一覧]にMS_JOB名.csvという名前でマイニングサーチ結果が作成されます。
-
出力したCSVファイルをアップロードして、SQL Testing Manager Webコンソールから評価SQLセットを作成してください。
詳細は、「評価SQLセットの作成」を参照してください。
6.4.2. PISO ManagerとSQL Testing Managerを接続して蓄積したSQLを転送する(方法2)
-
ブラウザからPISO Manager Webコンソールへ接続します。
-
[設定管理]>[PISO Manager設定]>[外部サーバー接続]>[新規作成]ボタンをクリックします。
-
外部サーバー接続設定画面から以下のように設定して、接続情報を設定します。
設定項目 設定内容 外部サーバー接続識別子
任意の文字列を入力します。
接続タイプ
接続する外部サーバーのタイプを選択します。
ここでは、[SQL Testing連携]を選択します。IPアドレス
ポート番号外部サーバー(SQL Testing Manager)が起動しているIPアドレスとポート番号を入力します。
SQL Testing Managerとの同梱環境では「127.0.0.1、7778」を設定します。ユーザー名
パスワード外部サーバーに転送を行うOSユーザー名とパスワードを入力します。
ここでは、SQL Testing Managerの一般ユーザーアカウントとパスワードを入力します。HTTPS ※
HTTPSを使って通信を行う場合には、チェックボックスにチェックを入れてください。
サーバー証明書検証 ※
サーバー証明書の検証が必要な場合は、チェックボックスにチェックを入れてください。
※ SQL Testing 4.2以降で対応しています。SQL Testing 4.1以前からアップグレードした場合、この機能は追加されません。
-
[保存]ボタンをクリックします。
-
[データ検索]>[マイニングサーチ]>[ジョブ実行条件指定]タブから、マイニングサーチのジョブ実行条件を設定します。
設定項目 設定内容 ジョブ名
マイニングサーチのジョブ名を入力します。
最大実行時間
マイニングサーチが実行可能な最大時間幅(分)を入力します。
最大取得行数
マイニングサーチで取得する行数を入力します。
出力形式
[標準(MSテーブル)][CSV形式][外部サーバー接続]のうち、[外部サーバー接続]を選択します。
[外部サーバー接続]は、事前に設定した外部サーバー接続識別子に対する外部サーバーに指定されたディレクトリにデータを転送します。 マイニングサーチ結果を外部サーバーに転送したい場合は、この形式を選択します。外部サーバー接続識別子 ※1
外部サーバー接続設定画面で任意で設定した外部サーバー接続識別子を選択します。
外部サーバー転送先ディレクトリ名 ※1
「/」を入力します。
出力文字コード ※1
SQL Testingと外部接続で連携する際は、以下の設定にしてください。
-
出力文字コード:UTF-8
-
圧縮形式:圧縮なし
圧縮形式 ※1
データベースの種類 ※2
評価SQLセットに登録するソースDBの種類を選択します。
SQL Testing 4.1以前の場合は「Oracle」になります。SQLの重複を排除する ※2
重複を排除して評価SQLセットを作成します。
※1 SQL Testing 4.1以前の場合に表示されます。
※2 SQL Testing 4.2以降で対応しています。SQL Testing 4.1以前からアップグレードした場合、この機能は追加されません。 -
-
画面上部の[SUBMIT]ボタンをクリックします。
-
ジョブ実行が成功すると、SQL Testing Manager Webコンソールの評価SQLセット一覧に以下の名前で評価SQLセットが作成されます。
評価SQLセット名:「<マイニングサーチ名>_<YYYY-MM-DD HH24:MI:SS>」) -
評価SQLセット名とデータベースは評価SQLセット画面から必要に応じて修正します。
詳細は、「評価SQLセットの編集」を参照してください。
|
7. SQL Testing Manager Webコンソール
7.1. SQL Testing Manager Webコンソールへログイン
-
ブラウザからSQL Testing Manager Webコンソールへ接続します。
以下のURLへアクセスしてください。http://<SQL Testing ManagerのIPアドレス>:7777/idt/
-
初回ログインの場合には、管理者ユーザーのユーザー名「administrator」と初期パスワードを入力し、[ログイン]をクリックします。
管理者ユーザーの初期パスワードは、オンプレミスの場合は「insight」、EC2の場合は、EC2インスタンスID、Azure VMの場合はVM名です。
すでに一般ユーザーを作成済みの場合は、一般ユーザーのユーザー名とパスワードを入力し、[ログイン]をクリックします。
|
7.2. ユーザーアカウント
SQL Testing Manager Webコンソールにログインするユーザーアカウントには、「管理者ユーザー」と「一般ユーザー」があります。
管理者ユーザーではユーザー管理とライセンス管理のみを行い、一般ユーザーではSQL Testing Managerの各設定と処理の実行および確認を行います。
管理者ユーザーでログインすると管理者画面が表示されます。
管理者画面では管理者ユーザーのパスワード変更と、一般ユーザーの作成、削除、パスワードのリセット、ライセンスパスワードの設定と確認を行うことができます。
一般ユーザーでログインするとSQL Testing Managerの操作画面が表示されます。
SQL Testing Managerの各設定(評価SQLセット、アセスメントetc)とユーザー自身のパスワード変更を行うことができます。
7.2.1. 管理者ユーザー
管理者ユーザーでログインすると、管理者画面の左メニューにユーザー管理とライセンス管理が表示されます。
7.2.1.1. ユーザー管理
一般ユーザーの新規作成、削除、パスワードのリセットを行います。
一般ユーザーの新規作成
-
SQL Testing Manager Webコンソールに管理者ユーザーでログインします。
ユーザー名は「administrator」、初期パスワードは、オンプレミスの場合は「insight」、EC2の場合は、EC2インスタンスID、Azure VMの場合はVM名です。
ユーザー一覧が表示されます。項目 説明 ユーザー名
管理者ユーザーと一般ユーザー名を表示します。
ロール
管理者ユーザーは「admin」、一般ユーザーは「normal」と表示します。
許可するAWSプロファイル名
一般ユーザーに許可するAWSプロファイル名を表示します。
操作
-
画面上部の[新規作成]ボタンをクリックします。
-
ユーザー名とパスワードを設定します。許可するAWSプロファイル名は、最低1件以上選択する必要があります。
[保存]ボタンをクリックします。ユーザー名は255文字以内、パスワードは6文字以上で設定してください。 -
ユーザー一覧に新規の一般ユーザーが追加されます。
一般ユーザーのパスワード変更については、「アカウント管理」を参照してください。 |
7.2.1.2. システムログのダウンロード
SQL Testing Managerのシステムのログをダウンロードできます。
SQL Testing Managerの動作について弊社で調査が必要な場合に、ログファイルの送付を依頼する場合があります。
その場合にログファイルをダウンロードし、サポート担当まで共有してください。
-
SQL Testing Manager Webコンソールに管理者ユーザーでログインします。
-
[ログ]の[ログをダウンロードする]ボタンをクリックします。
-
ダウンロードされたログファイル(ZIP)を指定された方法でサポート担当へ共有します。
7.2.1.3. ライセンス管理
SQL Testing Managerを使用するにはライセンスパスワードの設定が必要です(時間課金でAWS Marketplaceからサブスクライブした場合を除く)。
ライセンスパスワードの入手方法については販売代理店または販売元にお問合せください。
また、一般ユーザーでのログインは、ライセンスパスワードを設定してからログインできます。
-
SQL Testing Manager Webコンソールに管理者ユーザーでログインします。
-
[ライセンス管理]の[ライセンス更新]ボタンをクリックします。
-
入手したライセンスパスワードを入力して[保存]ボタンをクリックします。
-
ライセンス認証が正しく行われると、ライセンスが設定された旨のメッセージが表示され、ログイン画面に戻ります。
-
管理者ユーザーでログインし、[ライセンス管理]を選択すると、設定したライセンスパスワード情報を確認できます。
項目 説明 ライセンスパスワード
登録されているライセンスパスワード(16文字)の下4文字を表示します。
トライアル
登録されているライセンスパスワードが、正式版のときは「No」、トライアルのときは「Yes」を表示します。
ホスト
ライセンスパスワードが発行されたホストIDです。 無指定の場合は「NONE」を表示します。トライアルの場合は存在しません。
有効期限
ライセンスの有効期限(終了日)です。無期限の場合は「NEVER」を表示します。
プロダクト名
ライセンスされているプロダクト名です。
状態
パスワードが使用可能であれば「Valid」を表示します。
トライアルのライセンスパスワードを2回続けて設定することはできません。 |
7.2.1.4. 管理者ユーザーのパスワードのリセット
何らかの理由で管理者ユーザーとしてログインできなくなってしまった場合、管理者ユーザー「administrator」のパスワードをリセットすることが可能です。
-
OSのSQL Testing用ユーザー(通常はinsight)で仮想マシンにログインします。
-
XXXXXX
に設定したいパスワードを指定して、以下のコマンドを実行します。idtctl reset-admin-password XXXXXX
7.2.1.5. LLM
LLMを用いて推論を行うための設定をします。
設定したLLMを用いて、アセスメント実行後のSQL詳細画面で失敗したSQLの分析機能を使用することができます。
[利用可能モデルの設定変更]ボタンをクリックして使用するLLMを選択します。
使用可能なモデルは、[GPT4All]または[Amazon Bedrock]です。
[設定なし]の場合、失敗したSQLの分析機能は使えません。
Amazon Bedrockを使用する場合
SQL Testing 4.2以降では、Amazon Bedrockを使用する場合、複数のモデルの中から任意のモデルを選択できます(SQL Testing 4.1以前の場合は、Claude v2.1を使用)。
この機能を利用するためには、利用するモデルがアクセス可能な状態である必要があります。
モデルにアクセス可能な状態でない場合、以下の手順で利用可能な状態に設定してください。手順は、モデルがClaudeの場合を示します。
|
-
AWS マネジメントコンソールにログインし、Amazon Bedrockのコンソールを開きます。
-
左側のナビゲーションペインから[モデルアクセス]を選択します。
-
[モデルアクセスを管理]をクリックします。
-
[Anthropic]の[Claude]を選択し[モデルアクセスの要求]をクリックします。
-
モデルアクセスが承認されるまで数分かかる場合があります。
- (SQL Testing 4.1以前の場合)
-
「IDT_BEDROCK_REGION」を設定後、SQL Testing Managerを再起動してください。
SQL Testingの設定ファイル$IDT_HOME/config/config.ymlのdataセクションに下記を追加します。
IDT_BEDROCK_REGION: BEDROCKリージョン
7.2.2. 一般ユーザー
一般ユーザーでログインすると、SQL Testing Managerの操作画面が表示されます。
|
7.3. 画面説明
SQL Testing Webコンソールにログインして表示されるトップ画面について説明します。
以下、一般ユーザーでログインした場合を例に説明します。
番号 | 項目名 | 説明 |
---|---|---|
① |
ページメニュー |
全ページに共通して表示され、SQL Testingの主要な設定が表示されます。 |
② |
Language |
Webコンソール画面の言語を日本語または英語に切り替えます。 |
③ |
アカウント名 |
アカウントのパスワード変更、バージョン情報や各マニュアルの参照、ログアウトを行います。 |
④ |
各ページの設定ボタン |
各ページで行う設定がボタンで表示されます。 |
⑤ |
フィルタ |
各ページ画面を選択すると表示される一覧において絞り込み検索を行います。 |
7.3.1. 言語切り替え
SQL Testing Manager Webコンソールのメニューなどを表示する言語は、日本語と英語(English)に対応しています。
[Language]から表示したい言語に切り替えることができます。
言語の選択状態はブラウザに保存されます。
7.3.2. アカウント管理
SQL Testing Manager Webコンソールに接続するにあたってログイン用のパスワードが必要です。
ログインしているユーザーアカウントのパスワードを変更できます。
ユーザーの初期パスワードは、変更することを推奨します。 |
-
SQL Testing Manager Webコンソールのログイン画面から、パスワードを変更する一般ユーザーでログインします。
-
画面右上の[<一般ユーザー名>]のメニューから、[アカウント管理]をクリックします。
-
以下の項目を入力して、画面下部の[保存]ボタンをクリックします。
項目名 説明 現在のパスワード
現在のパスワードを入力します。
新しいパスワード
新しく設定するパスワードを入力します(6文字以上)。
パスワード(確認用)
確認用パスワードです。
上記パスワードと同じパスワードを入力します。 -
パスワード変更が成功した場合には、自動でログアウトしてログイン画面に変ります。
以上でパスワードの変更が完了しました。
次回SQL Testing Manager Webコンソールにログインする時から、今回設定したパスワードを使用します。
管理者ユーザーによるパスワードのリセットについては、ユーザー管理の「操作」項目を参照してください。 |
7.3.3. バージョン情報
使用しているSQL Testing Managerのバージョンを確認できます。
-
画面右上の[<一般ユーザー名>]のメニューから、[バージョン情報]をクリックします。
-
バージョンの情報が表示されます。
7.3.5. APIドキュメント
SQL Testingでは、REST API(Representational State Transfer API)を用意しています。
-
画面右上の[<一般ユーザー名>]のメニューから、[APIドキュメント]をクリックします。
APIドキュメントが表示されます。
7.3.6. 画面の更新
画面を最新の情報に更新します。
-
[▼]をクリックして、画面の更新間隔を選択します。
プルダウンメニューから任意の秒数を指定してください。
画面を自動で更新させたくないときは[停止]を選択してください。
7.3.7. フィルタ
ターゲットDB、修正SQLセット、評価SQLセット、アセスメント、AWSマイグレーションの一覧画面では、フィルタ機能を使用して一覧の絞り込み検索(フィルタリング)ができます。
フィルタに使用できる属性は以下のとおりです。
-
名前
-
メモ
-
更新日時
-
作成日時
検索文字(値)に使用できるフィルタ条件は以下のとおりです。
フィルタ条件 | 説明 |
---|---|
と一致 |
入力された値と属性の値が完全に一致するデータを絞り込みます。大文字小文字を区別します。 |
を含む |
属性の値が入力された値を部分的に含むデータを絞り込みます。大文字小文字は区別されません。 |
より前 |
入力された値よりも前の日時を持つデータを絞り込みます。 |
より後 |
入力された値と同じ、またはそれよりも後の日時を持つデータを絞り込みます。 |
-
フィルタ入力欄に文字を入力するとフィルタの候補が表示されます。
属性が検索文字「と一致」「を含む」「より前」「より後」の候補から選択します。 -
入力欄のカレンダーアイコンをクリックすると、入力フォームから日付時間を入力できます。
-
日付時間が入力された入力欄をクリックすると、フィルタの候補が表示されます。
-
更新日時、作成日時によるフィルタは、入力欄に以下の形式の文字列を入力することで表示されます。
YYYY-MM-DD HH:MM:SS形式 -
表示されたフィルタの候補を選択することでフィルタが適用されます。
-
適用中のフィルタは入力欄右にチップとして表示されます。
チップの[×]ボタンをクリックすると適用を解除できます。
チップ([×]ボタン以外)をクリックすると値が入力欄に戻り、適用されているフィルタは解除されます。
各属性に対して一度に適用できるフィルタは1つです。適用中のフィルタはフィルタの候補に表示されなくなります。
8. 評価SQLセット
評価SQLセットでは、取得したSQLをターゲットDBへ実行できるように専用の評価SQLセットを作成、または編集します。
評価SQLセットを作成する前に、ソースDBで蓄積したSQLを収集し出力させる必要があります。
8.1. 評価SQLセットの作成
評価するSQLの集まりである「評価SQLセット」を作成します。
以下はソースDBに対する評価SQLセット作成方法の対応表です。
ソースDB | CSVファイルから作成 | DBのログから作成 | Amazon RDSから作成 | Amazon CloudWatch Logsから作成 |
---|---|---|---|---|
Oracle Database / SQL Server |
〇 |
× |
× |
× |
MySQL / PostgreSQL |
〇 |
〇 |
× |
× |
RDS for Oracle / RDS for SQL Server / RDS for MariaDB |
〇 |
× |
× |
× |
RDS for MySQL / RDS for PostgreSQL / Aurora MySQL / Aurora PostgreSQL |
〇 |
〇 |
〇 |
〇 |
※Snowflake(SQL Testing 4.1以降で対応)はソースDBとして利用できないため、評価SQLセットの作成はできません。
- 評価SQLセット作成方法の補足
-
-
CSVファイルから作成
マイニングサーチ形式のCSVであればソースDBに関係なく評価SQLセットの作成が可能です。 -
DBのログから作成
Amazon RDS上でのログファイル出力設定に準拠しているログファイルが利用可能です。-
タイムスタンプのタイムゾーンはUTCになります。
-
タイムスタンプ精度は以下を想定しています。
DBエンジン タイムスタンプ精度 形式 PostgreSQL
秒
YYYY-MM-DD hh:mm:ss UTC
2024-01-01 12:00:00 UTCMySQL 5.6以前
ミリ秒
YYMMDD hh:mm:ss
240101 12:00:00MySQL 5.7以降
マイクロ秒
YYYY-MM-DDThh:mm:ss.uuuuuuZ
2024-01-01T12:00:00.000000Z
-
-
Amazon RDSから作成
RDS for MySQL / PostgreSQLおよびAurora MySQL / PostgreSQLに対応しています。Amazon RDS上でのログファイル出力設定が必要です。 -
Amazon CloudWatch Logsから作成
Amazon RDS上でのログファイル出力設定に準拠しているログがCloudWatch Logsにある場合に利用可能です。
-
-
SQL Testing Manager Webコンソールの左のページメニューから[評価SQLセット]をクリックします。
評価SQLセット一覧画面が表示されます。
-
評価SQLセット一覧画面で[新規作成]ボタンをクリックします。
-
評価SQLセット名を指定し、評価SQLセット作成方法を選択します。
必要な値を入力した後、画面下部の[新規作成]ボタンをクリックします。項目名 説明 評価SQLセット名
評価SQLセットの名前を入力します。
大文字、小文字を区別します。[CSVファイルから作成][DBのログから作成][Amazon RDSから作成][Amazon CloudWatch Logsから作成]のいずれかを選択します。
[Amazon RDSから作成]または[Amazon CloudWatch Logsから作成]を使用するには、適切なIAMの設定が必要となります。詳細は「必要なIAM設定について」を参照してください。 CSVファイルから作成
データ元ファイル
マイニングサーチ形式のCSVを使用します。
変換するデータ(CSVファイル、複数のCSVファイルを圧縮したZIPファイルやgzファイル)のファイルパスを指定します。
複数のCSVファイルを圧縮したZIPファイルやgzファイルを使用する場合、各CSVファイルのヘッダーが一致している必要があります。
gzファイルはSQL Testing 4.2以降で対応しています。ZIPファイルをWindowsで作成する場合の注意点
-
deflate64形式で圧縮されたファイルはデータ元ファイルとして使用できません。
-
ZIPファイルに含まれるファイル名がSJISの全角文字を含む場合でも評価SQLセットの作成は可能ですが、半角英数のみの使用を推奨します。
[CSVファイルをアップロードする]のトグルスイッチを「オン」にすると、CSVファイルをローカルPCからSQL Testing Managerにアップロードして評価SQLセットを作成します。
SQL Testing Manager内のファイルを指定する場合は、「オフ」にします。
SQL Testing Manager内の以下のディレクトリに配置したCSVファイルが表示されますので選択してください。/mnt/piso-data/idt-data/src
(Azure VMにSQL Testing Managerを構築した場合/data/piso-data/idt-data/src)データベース
SQLを収集するソースDBの種類をOracle、PostgreSQL、SQL Server、MySQLの中から選択します。
DBのログから作成
ログファイル
SQL収集元のデータベースから取得したログファイルのファイルパスを指定します。
アップロードするログファイルの形式は、Amazon RDS上でのログファイル出力設定と同等である必要があります。
ZIPファイルにまとめてアップロードも可能です。
ZIPファイル名とZIPに含まれるファイルの名前は、半角英数とファイル名として使用できる半角記号のみです。データベース名
SQL収集元データベースのデータベース名を指定します。
指定しない場合、すべてのデータベースを収集対象とします。ログファイル種別
ログファイルを取得したSQL収集元のデータベースの種類を、以下から選択してください。
-
PostgreSQL
-
MySQL
-
MySQL 5.7 互換 Aurora MySQL バージョン2
Amazon RDSから作成
使用するAWSプロファイル名
使用するAWSプロファイル名を選択します。「デフォルト」を選択した場合、共有AWS認証情報ファイルのdefault設定が存在すればそれを使用します。存在しない場合、IAMロールの設定で認証を試みます。
AWSプロファイル名を指定した場合、指定したAWSプロファイル名で認証を行います。無効なAWSプロファイル名の場合、エラーが発生します。リージョン
SQL収集元データベースのデータベースインスタンスまたはクラスターがあるリージョンを指定します。
インスタンスID/クラスターID
SQL収集元データベース(ソースDB)のインスタンスIDを指定します。
対象がAurora DBクラスターの場合にはクラスターIDを指定します。データベース名
SQL収集元データベースのデータベース名を指定します。
インスタンス内で複数のデータベースを運用していて、それらをテスト対象としたい場合は、AWSマイグレーションは別々に設定する必要があります。
指定しない場合、すべてのデータベースを収集対象とします。高度な取得設定
SQL取得開始日時/SQL取得終了日時SQL収集元データベースからSQLを収集する日時を指定します。
すでに出力されているような古いSQL情報をテスト対象としたくない場合に指定します。
指定しない場合は、取得できる最も古いデータまで遡ります。Amazon CloudWatch Logsから作成
使用するAWSプロファイル名
使用するAWSプロファイル名を選択します。「デフォルト」を選択した場合、共有AWS認証情報ファイルのdefault設定が存在すればそれを使用します。存在しない場合、IAMロールの設定で認証を試みます。
AWSプロファイル名を指定した場合、指定したAWSプロファイル名で認証を行います。無効なAWSプロファイル名の場合、エラーが発生します。リージョン
SQL収集元のAmazon CloudWatch Logsのリージョンを指定します。
データベース名
SQL収集元のAmazon CloudWatch Logsに記録されている収集対象のデータベース名を指定します。
指定しない場合、すべてのデータベースを収集対象とします。ログファイル種別
Amazon CloudWatch Logsに記録されているログの収集元データベースの種類を、以下から選択してください。
-
PostgreSQL
-
MySQL
-
MySQL 5.7 互換 Aurora MySQL バージョン2
ロググループ名
SQL収集元のCloudWatch Logsのロググループを指定します。
高度な取得設定
SQL取得開始日時/SQL取得終了日時SQL収集元データベースからSQLを収集する日時を指定します。
すでに出力されているような古いSQL情報をテスト対象としたくない場合に指定します。
指定しない場合は、取得できる最も古いデータまで遡ります。SQLの重複を排除する
トグルスイッチを「オン」にすると、重複するSQLを排除し、ユニークなSQLのみの評価SQLセットを作成します。
メモ
評価SQLセットについてのメモを入力します。
-
評価SQLセットの作成が開始されると、評価SQLセットの行頭のアイコンで進行状況を確認できます。
作成が完了すると、ステータスが完了アイコン[]になります。
SQL Testing 4.1以降は、完了時の状態によりステータスアイコンが変わります。
正常終了すると緑色[]、ログにwarningまたはerrorレベルの内容が出力されていると、オレンジ色[]になります。
評価SQLセットの作成はデータ量に応じて数分から数十分かかります。
8.2. 評価SQLセットのSQL詳細
評価SQLセットを作成した後、評価SQLセットの中のSQLの詳細を確認します。
評価SQLセットのSQLをターゲットDBへアセスメントする前に、作業量の確認等のために使用してください。
-
評価SQLセットの一覧画面から詳細情報を確認する評価SQLセット名を選択します。
-
サマリー画面が表示されます。
-
SQL詳細情報の一覧作成に成功した場合には、作成オプション、サマリー、SQL情報を表示します。
SQLテキストの下向き矢印をクリックすると、SQL全文を確認することができます。
-
SQL詳細情報の一覧作成に失敗した場合には、作成オプション、エラーメッセージを表示します。
-
項目の詳細については、「使用している項目名について」を参照してください。 |
8.3. 評価SQLセットの結合
複数の評価SQLセットを結合して1つの評価SQLセットを作成します。
-
評価SQLセットの一覧画面から結合する評価SQLセットにチェックを入れます。
-
画面上部の[結合]ボタンをクリックします。
-
新たに生成する評価SQLセット名を入力し、結合するSQLセットの順番をドラッグアンドドロップで並べ替えます。
画面下部にある[結合]をクリックします。項目名 説明 評価SQLセット名
新たに生成する評価SQLセットの名前を入力します。既存の評価SQLセット名と異なる名前にしてください。
大文字、小文字を区別します。メモ
修正SQLセットについてのメモを入力します。
評価SQLセットの一覧に情報が追加され、完了アイコン[]になると完了です。
評価SQLセットを作成中はアイコンが[]になります。完了まで時間がかかる場合があります。
評価SQLセットの一覧で、結合によって作成された評価SQLセットの[データソース]項目には結合元の評価SQLセット名が表示されます。 (通常、一覧の[データソース]には元となったCSVファイルやRDS、ログファイルの名称が表示されます。) |
8.4. 評価SQLセットの編集
-
評価SQLセットの一覧画面から編集する評価SQLセットにチェックを入れます。
-
画面上部の[編集]ボタンをクリックします。
-
必要な値を入力した後、画面下部にある[保存]ボタンをクリックします。
項目名 説明 評価SQLセット名
変更する評価SQLセット名を入力します。
データベース
変更するデータベースの種類を選択します。
CSVファイルを選択して評価SQLセットを作成した場合は、データベースを変更できます。
Amazon RDSからSQLを取得して評価SQLセットを作成した場合は、データベースを変更できません。メモ
評価SQLセットについてメモを入力します。
評価SQLセットの一覧の表示が変更になると、編集の完了です。
8.5. 評価SQLセットのコピー
-
評価SQLセットの一覧画面からコピーする評価SQLセットにチェックを入れます。
-
画面上部の[コピー]ボタンをクリックします。
-
必要な値を入力した後、画面下部にある[保存]ボタンをクリックします。
項目名 説明 コピー元評価SQLセット名
コピー元の評価SQLセットが表示されています。
新規評価SQLセット名
コピーして作成される評価SQLセットの名前を入力します。
大文字、小文字を区別します。メモ
コピーして作成される評価SQLセットについてメモを入力します。
SQLの絞り込み
SQLの重複を排除する
トグルスイッチを「オン」にすると、重複するSQLを排除し、ユニークなSQLのみの評価SQLセットのコピーを作成します。
除外したいSQLの正規表現
入力された正規表現にマッチするSQLを除外します。大文字と小文字を区別します。
「test_table」と「test_value」が含まれるSQLを除外したい場合には「test_table|test_value」と入力します。対象DBユーザー
DBユーザーでフィルタリングすることができます。
期間(SQL開始時刻)
SQL開始時刻でフィルタリングすることができます。
一覧に評価SQLセットのコピーが追加になり、ステータスが完了アイコン[]になるとコピーの完了です。
評価SQLセットのコピーはデータ量に応じて数分から数十分かかります。
8.6. 評価SQLセットのユーザー変更
評価SQLセットに格納されているDBユーザー名を変更します。
ソースDBとターゲットDBでDBユーザー名が異なる際に使用してください。
-
評価SQLセットの一覧画面からユーザー名を変更する評価SQLセットにチェックを入れます。
-
画面上部の[ユーザー変更]ボタンをクリックします。
-
既存ユーザー名が表示されます。
変更するDBユーザーの項目に、新たなDBユーザー名を入力し、画面下部にある[適用]ボタンをクリックします。
一覧のステータスが完了アイコン[]になると変更の完了です。
評価SQLセットの変更はデータ量に応じて数分から数十分かかります。
8.7. 評価SQLセットの外部連携
評価SQLに対して、修正したSQLをアップロードして適用します。
-
評価SQLセットの一覧画面から適用する評価SQLセットにチェックを入れます。
-
画面上部の[外部連携]ボタンをクリックします。
-
外部連携画面が表示されます。または入力欄をクリックし、ファイルを選択してください。
画面下部にある[適用]ボタンをクリックします。
8.8. 評価SQLセットのエクスポート
選択した評価SQLセットをPISO Managerのマイニングサーチ形式のCSVファイルでエクスポートします。
ZIP圧縮されたCSVファイルがダウンロードされます。
-
評価SQLセットの一覧画面からエクスポートする評価SQLセットにチェックを入れます。
-
画面上部の[エクスポート]ボタンをクリックします。
-
エクスポート画面が表示されます。メッセージを確認後、[エクスポート]ボタンをクリックします。
8.9. 評価SQLセットの削除
-
評価SQLセットの一覧画面から削除する評価SQLセットにチェックを入れます。
-
画面上部の[削除]ボタンをクリックします。
-
確認用画面が表示されます。削除する評価SQLセットを確認してください。
問題が無ければ、画面下部にある[削除]ボタンをクリックしてください。
一覧から、該当の評価SQLセット名がなくなると削除の完了です。
評価SQLセットの削除はデータ量に応じて数分かかる場合があります。
8.10. ログの確認
ログのアイコンをクリックすると、評価SQLセットを作成した際のログを確認することができます。
また、利用可能なログはダウンロードできます。
9. ターゲットDB
評価SQLセットを実行するターゲットDBを登録、または編集します。
-
SQL Testing Manager Webコンソールの左のページメニューから[ターゲットDB]をクリックします。
ターゲットDBの一覧画面が表示されます。
9.1. ターゲットDBの追加
-
ターゲットDBの一覧画面から[新規作成]ボタンをクリックします。
-
ターゲットDB名を指定し、[既存のDBを登録する][スナップショットからRDSインスタンス/Auroraクラスタを作成する]のいずれかを選択します。
[スナップショットからRDSインスタンス/Auroraクラスタを作成する]を設定するためには、AWSへの権限が必要です。詳細は、「必要なIAM設定について」を参照してください。 -
必要な値を入力した後、画面下部の[新規作成]ボタンをクリックします。
- [既存のDBを登録する]を選択する場合
-
項目名 説明 ターゲットDB名
任意のターゲットDBの名前を入力します。
大文字、小文字を区別します。メモ
ターゲットDBについてメモを入力します。
データベース
ターゲットDBの種類を選択します。
バージョン
ターゲットDBのバージョンを入力します。
接続識別子
接続識別子に簡易接続ネーミング・メソッドを使用した文字列、またはOracle Net Servicesのキーワード値ペアを入力します。または、事前に指定した接続識別子を入力します。
データベースにOracleを選択時に表示されます。接続識別子の指定方法については、「接続識別子の指定」を参照してください。 DSN
Driver、UID、PWDを除いたODBCデータソース文字列を入力します。または、事前に指定したDSN(データソース名)を入力します。
データベースにSQL Server、Snowflakeを選択時に表示されます。DSNの指定方法については、「データソース名の指定」を参照してください。 ホスト名
ホスト名を入力します。
データベースにPostgreSQL、MySQLを選択時に表示されます。Amazon Auroraの場合は、通常はクラスターエンドポイントを指定しますが、テスト目的に応じ、リーダーエンドポイントやインスタンスエンドポイントを指定します。 ポート
ポート番号を入力します。
データベースにPostgreSQL、MySQLを選択時に表示されます。データベース名
データベース名を入力します。
データベースにPostgreSQL、MySQLを選択時に表示されます。テスト接続
ターゲットDBの接続を確認することができます。
DBユーザーとパスワードを入力し、[テスト接続]ボタンをクリックしてください。
接続結果はボタン右のステータスアイコンに表示されます。ステータスアイコンをクリックすると結果をクリップボードにコピーできます。-
ユーザー:DBユーザー名を入力します。
接続確認で使用する、ターゲットDBの中にすでに存在しているユーザー名を入力します。 -
パスワード:DBユーザーのパスワードを入力します。
-
- [スナップショットからRDSインスタンス/Auroraクラスターを作成する]を選択する場合
-
項目 説明 使用するAWSプロファイル名
使用するAWSプロファイル名を選択します。「デフォルト」を選択した場合、共有AWS認証情報ファイルのdefault設定が存在すればそれを使用します。存在しない場合、IAMロールの設定で認証を試みます。
AWSプロファイル名を指定した場合、指定したAWSプロファイル名で認証を行います。無効なAWSプロファイル名の場合、エラーが発生します。スナップショットARN
ターゲットDBの作成の元となるスナップショットのARNを指定します。
インスタンスクラス
新規作成するターゲットDBのインスタンスクラスを指定します。
リージョン
新規作成するターゲットDBのリージョンを指定します。
インスタンス名(クラスター名)
新規作成するRDSのインスタンス名(Aurora DBクラスター名)を指定します。
セキュリティグループ
新規作成するターゲットDBのセキュリティグループのセキュリティグループIDを指定します。
複数入力する場合は、「,」で区切ります。サブネットグループ
データベースを作成するサブネットグループを指定します。
オプショングループ
新規作成するターゲットDBのオプショングループのオプショングループ名を指定します。
ターゲットDBの作成の元となるスナップショットにAurora DBクラスターを指定した場合は、指定できません。
指定しない場合はデフォルトのオプショングループが使用されます。パラメータグループ
新規作成するターゲットDBのパラメータグループのパラメータグループ名を指定します。
テスト対象がAurora DBクラスターの場合にはクラスターパラメータグループ名を指定します。
指定しない場合はデフォルトのパラメータグループまたはクラスターパラメータグループが使用されます。アップグレード後のエンジンバージョン
アップグレードしたターゲットDBを作成する場合、アップグレード後のエンジンバージョンを指定します。
スナップショットのデータベースバージョンから、1回でアップグレード(変更)可能なバージョンを指定してください。データベース名
スナップショットから作成したデータベースのデータベース名を入力します。
ターゲットDBの一覧に情報が追加されると完了です。
ターゲットDBが追加されるまで時間がかかる場合があります。
|
9.2. ターゲットDBの情報の変更と接続確認
すでに追加したターゲットDBの情報を変更します。また、ターゲットDBと接続確認もできます。
-
ターゲットDBの一覧画面から情報を変更するターゲットDBにチェックを入れます。
-
画面上部の[編集・テスト接続]ボタンをクリックします。
-
ターゲットDBの情報が表示されます。
-
ターゲットDBと接続確認をしたいときは、DBユーザーとパスワードを入力し、[テスト接続]ボタンをクリックします。
情報に変更が無ければ画面下部にある[キャンセル]ボタンをクリックしてください。 -
適切な値に変更した場合は、画面下部にある[保存]ボタンをクリックします。
項目の詳細については、「ターゲットDBの追加」を参照してください。
-
ターゲットDBの一覧に表示されている情報が変更されると完了です。
ターゲットDBの変更が完了するまで時間がかかる場合があります。
ターゲットDBの新規作成時に[スナップショットからRDSインスタンス/Auroraクラスターを作成する]から作成した場合、以下の項目は編集できません。
|
9.3. ターゲットDBの削除
ターゲットDBを削除します。
この操作はSQL Testing内の情報のみを削除します。接続先のデータベースに影響はありません。
-
ターゲットDBの一覧画面から削除するターゲットDBにチェックを入れます。
-
画面上部の[削除]ボタンをクリックします。
-
確認用画面が表示されます。削除するターゲットDBを確認してください。
問題が無ければ、画面下部にある[削除]ボタンをクリックしてください。
一覧から、該当のターゲットDBがなくなると削除の完了です。
ターゲットDBの削除は数分かかる場合があります。
AWSマイグレーションから作成されたターゲットDB(SQL Testingから作成されたRDSが紐づくターゲットDB)の場合、ターゲットDB削除時に削除可能なRDSインスタンス(Aurora DBクラスター)があれば同時に削除します。
10. アセスメント
評価SQLセットをターゲットDBへ実行します。
アセスメントには、1つのターゲットDBでのみ行うアセスメントと、テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの2種類が存在します。
アセスメントの種類については、「製品の構成」を参照してください。 |
|
-
SQL Testing Manager Webコンソールの左のページメニューから[アセスメント]をクリックします。
アセスメントの一覧画面が表示されます。
10.1. アセスメントの新規作成
|
-
アセスメント一覧画面から[新規作成]ボタンをクリックします。
-
必要な値を入力した後、画面下部にある[新規作成]ボタンをクリックします。
- 1つのターゲットDBでのみ行うアセスメント([2DBモード]が「オフ」)の場合
-
項目名 説明 アセスメント名
アセスメントの名前を入力します。
大文字、小文字を区別します。メモ
アセスメントについてメモを入力します。
2DBモード
テスト用ソースDBとターゲットDBの2つのデータベースを指定したアセスメントを実行します。
トグルを「オン」にすると、テスト用ソースDBを設定できます。トグルを「オン」にすると、SQLの開始時刻順にアセスメントを実行します。
評価SQLセットにトランザクション制御文を含めたSQLが、すべて含まれるようにしてください。直列実行有効時は、以下の値は固定となります。
-
実行タイプ:実行
-
DBへのデータ反映:指定なし
-
同時セッション処理数:1
2DBモードにおける直列実行の有効・無効によるSQLの実行順の違いについては、弊社サポートサイト(Service Portal)の[Insight SQL Testing]>[ナレッジ]メニューの右部にある[Search…]から文書番号:000001977を参照してください。 1つのターゲットDBでのみ行うアセスメントの直列実行は、SQL Testing 4.2以降で対応しています。
SQL Testing 4.1以前では[2DBモード]が「オン」かつ実行タイプが[実行]時に表示されます。エクスポート/
インポート-
エクスポート:アセスメントの新規作成画面の入力状態をJSONファイルとしてダウンロードします。
-
インポート:JSONファイルから入力値を読み取り、アセスメントの新規作成画面に反映します。
JSONファイルは一部要素のみ記述することで特定の項目のみ更新することができます。
エクスポートしたJSONファイルには、属性「"is2dbMode": false」(1DBモード)または「"is2dbMode": true」(2DBモード)があります。
インポートしたJSONファイルに属性「is2dbMode」が無い場合は、インポート時のアセスメントフォームの「2DBモード」のオンオフ状態を維持したままインポートします。評価SQLセット名
ターゲットDBへ実行する評価SQLセットを選択します。
事前に評価SQLセットを作成する必要があります。
をクリックすると、評価SQLセットの一覧画面に遷移します。詳細は「評価SQLセット」を参照してください。 実行タイプ
実行する方法を選択します。
-
実行:評価SQLセットをターゲットDBに対して実行します。
-
パース:パース実行を行います。実行時間は取得できないため、速度が遅くなったSQL等の判定ができません。バインド変数の値がなくてもテーブルの有無や構文のチェックができます。
パース実行の処理時間の参考値については、弊社サポートサイト(Service Portal)の[Insight SQL Testing]>[ナレッジ]から文書番号:000002063を参照してください。 バインド変数書式変換
SQLに含まれる名前付きバインド変数をターゲットDBで実行可能な書式に変換してSQLを実行します。
移行先が名前付き引数に対応していないDBMSでもデータベース接続ドライバー、またはデータベース接続プログラムによって対応される場合を再現して、アセスメント実行時にSQLを自動変換して実行します。バインド変数書式変換は、Oracle Database以外のデータベースからOracle Databaseへの変換をサポートしていません( 「$1」や「?」から「:1」への変換)。 DBへのデータ反映※
ターゲットDBへのデータ反映の設定を選択します。
ソースDBで実行された1セッションを1トランザクションとし、トランザクションをどの設定で実行するか選択できます。-
コミット:実行したSQLをコミットします。INSERT文やDELETE文などはターゲットDBに実行結果が反映されます。SQLが失敗すると、そのトランザクション内のSQLはすべてロールバックされます。
-
ロールバック:実行したSQLをセッション単位でロールバックします。ターゲットDBには何も反映されません。評価対象のSQLにトランザクション制御文が含まれている場合、ロールバックが正しく行われない場合があります。また、データベース種類に応じた暗黙的なコミットについてはロールバックできません。
-
指定なし:指定しません。ターゲットDBの設定に依存します。
セッション設定
SQL実行時のタイムアウトを設定します。
-
(指定しない):タイムアウトを明示的には指定しません。データベースの設定でタイムアウト設定がされていればそれに従います。
-
0:タイムアウトしません。データベースのタイムアウトの設定に関わらず、タイムアウトを無効にします。
-
1~:指定した時間(分)でタイムアウトします。SQLの実行時間が指定した時間を超えた場合、SQLの実行を強制終了し、失敗したSQLと判定します。
MySQLの場合、タイムアウト設定はSELECT文のみ有効です。 同時セッション処理数
評価SQLセットをターゲットDBで実行する際に同時に処理するセッション数を指定します(最大128)。
ターゲットDBとSQL Testing Managerのリソースに余裕がある場合に、アセスメント実行の速度向上が見込めます。
ターゲットDBのリソース制限や接続設定によって、実行がタイムアウトエラーとなる場合があります。同時セッション処理数を増やしても処理速度が向上しない場合は、弊社サポートサイト(Service Portal)の[Insight SQL Testing]>[ナレッジ]メニューの右部にある[Search…]から文書番号:000001971を参照してください。 取得結果の保存条件※
SQLを実行して取得した結果の保存条件を選択します。保存した取得結果は、アセスメントのSQL詳細画面で閲覧、ダウンロードできます(SQLの実行に失敗している場合や返り値のないSQLを除く)。
-
すべて保存:取得した結果に関わらず、すべての結果を保存します。
-
保存しない:取得した結果を保存しません。容量削減のため、この選択肢がデフォルトで設定されています。
アセスメント実行時に取得した実行計画の保存条件を選択します。
保存した実行計画は、アセスメントのSQL詳細画面から閲覧可能です。-
性能が劣化した場合に保存
ターゲットDBとテスト用ソースDBで性能が劣化した場合のみ、実行計画を保存します。
容量削減のため、この選択肢がデフォルトで設定されています。 -
すべて保存
性能比較結果に関わらず、すべての実行計画を保存します。 -
保存しない
実行計画を保存しません。
取得結果をディスクに置いて比較※
従来メモリ上で行う取得結果の比較処理をディスクを用いて行うことができます。
膨大な量の取得結果をすべて取得したいが、メモリ不足が懸念される場合に使用します。有効にした場合、通常よりアセスメントの実行に時間がかかります。 -
有効
取得結果の比較処理をディスクを用いて行います。通常よりアセスメントの実行に時間がかかります。
メモリの使用量を削減することができます。 -
無効
今までと同様に、メモリ上で比較処理を行います。
時間しきい値 [秒] ※
性能が劣化したSQLの判定をするための、時間しきい値を設定します。
ターゲットDBの処理時間がソースDB(2DBの時は、テスト用ソースDB)より時間しきい値 [秒]長かった場合、「性能が劣化」となります。
割合しきい値 [%]も設定した場合、両方のしきい値を超えたSQLが性能が劣化したSQLとして判定されます。
未指定の場合は0 [秒]を指定したものと同じです。割合しきい値 [%] ※
性能が劣化したSQLを判定するため、割合しきい値を設定します。
性能が劣化したSQLとは、ソースDB(2DBの時は、テスト用ソースDB)を基準に、ターゲットDBの処理時間比が割合しきい値 [%]より大きかったSQLです。
時間しきい値 [秒]も設定した場合、両方のしきい値を超えたSQLが性能が劣化したSQLとして判定されます。
未指定の場合は100 [%]を指定したものと同じです。保持比較行数制限※
アセスメント実行時に保持する行取得結果の上限値を指定します。
比較処理は上限値までの結果で評価します。
取得行数制限の値の方が小さい場合は、取得行数制限が優先されます。この機能はSQL Testing 4.1以前は「取得行数制限」の名称でしたが、4.2以降は「保持比較行数制限」に変わりました。
取得行数制限※
アセスメント実行時にデータベースからフェッチする上限値を指定します。
取得行数制限までの件数をデータベースからフェッチします。SQL Testing 4.1以前と4.2以降で機能に変更があり、記載内容は4.2以降の機能説明です。 4.1以前の機能は「保持比較行数制限」に名称が変わりました。
0秒の仮定値※
ソースDBでのSQL実行時間が0秒だった場合に、実行時間の仮定値として設定される値を入力します。
PISOのデフォルトのサンプリング間隔に基づき、デフォルトは0.2秒です。詳細は「0秒時の対応」を参照してください。 1つのターゲットDBでのみ行うアセスメント、かつ実行タイプで[実行]を選択時に表示されます。
期間(セッション)
セッションの期間でフィルタリングして実行することができます。
選択されていない期間のセッションのSQLは実行されません。
[期間(セッション)]をクリックし、適切な期間を設定してください。※ 実行タイプで[実行]を選択時に表示されます。
-
- テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメント([2DBモード]が「オン」)の場合
-
[2DBモード]が「オン」かつ実行タイプが[実行]時に表示される項目 項目名 説明 カラム名の比較
クエリ実行結果を比較する場合に、テーブルのヘッダーを比較対象とするかを指定します。
-
比較しない
カラム名の文字比較を行いません。 -
大文字・小文字を無視
カラム名の大文字・小文字を無視して比較します。 -
完全一致
カラム名を完全一致で比較します。
取得結果の行順序の一致レベルを指定します。
-
完全一致
行順序まで一致したものを成功したと判断します。再ソートによる評価はしません。 -
完全一致(再ソート試行)
行順序まで一致したものを成功したと判断します。再ソートによる評価も実施した結果も記録します。 -
自動
実行したSQL文にORDER BY句による順序指定がある場合は行順序を含む比較、指定がない場合は行順序を無視して評価します。 -
無視
行順序を無視して評価します。
比較対象外カラム
SQL Testing 4.1以降で対応しています。
指定したカラムは比較時に評価対象外となります。
[比較対象外カラム]で指定するカラム名は、クエリ実行結果のカラム名で指定してください。
対象外カラムは複数指定可能です。-
文字列に「%」を含む場合、その位置に応じて一致の評価が変わります。
-
前方に「%」がある場合: 後方一致
( 「%example」は「example」や「prefix_example」に一致) -
後方に「%」がある場合: 前方一致
( 「example%」は「example」や「example_suffix」に一致) -
前後に「%」がある場合: 部分一致
( 「%example%」は「example」や「prefix_example_suffix」に一致) -
「%」を含まない場合: 完全一致
( 「example」は「example」にのみ一致)
-
-
「%」を含むカラム名を指定することはできません。
-
大文字・小文字を区別します。
-
テスト用ソースDBとターゲットDBでクエリ実行結果のカラム名の大文字・小文字が異なる場合は、テスト用ソースDBのカラム名に合わせて入力してさい。
-
すべてのカラムが比較対象外となった場合、結果のステータスは「成功」もしくは「性能が劣化」になります。
取得結果の保存条件
SQLを実行して取得した結果の保存条件を選択します。保存した取得結果は、アセスメントのSQL詳細画面で閲覧、ダウンロードできます(SQLの実行に失敗している場合や返り値のないSQLを除く)。
-
結果が異なるもののみ保存:ターゲットDBとテスト用ソースDBで取得した結果が異なる場合のみ、結果を保存します。[2DBモード]を「オン」にした場合に表示されます。容量削減のため、この選択肢がデフォルトで設定されています。
-
すべて保存:取得した結果に関わらず、すべての結果を保存します。
-
保存しない:取得した結果を保存しません。
末尾の空白を削除して比較
取得結果が固定長文字列型の場合に末尾の空白を取り除いて比較します。
浮動小数点の誤差
取得結果が浮動小数点型の場合に許容する誤差を正の数で設定します。
未指定の場合は誤差を許容しません。期間(SQL開始時刻)
[2DBモード]が「オン」、実行タイプが[実行]、かつ[直列実行]が「オン」のときは、評価SQLセットのSQL開始時刻の期間でフィルタリングして実行することができます。
選択されていない範囲のSQLは実行されません。
[期間(SQL開始時刻)]をクリックし、適切な期間を設定してください。ターゲットDB 項目名 説明 ターゲットDB
評価SQLセットを実行するデータベース(ターゲットDB)を選択します。
事前にターゲットDBを登録する必要があります。
をクリックすると、ターゲットDBの一覧画面に遷移します。詳細は「ターゲットDB」を参照してください。 ターゲットDBに使用する修正SQLセット
ターゲットDBに使用する修正SQLセットを選択します。
修正SQLセットを用いる場合に設定します。修正SQLセットを使用しないときは[指定なし]を選択してください。テスト用ソースDBには元のSQL、ターゲットDBには修正SQLを適用する等、別々のSQLを適用することもできます。
フェッチ・サイズ値(ターゲットDB)
一度にデータベースサーバーから受け取る行数を指定することができます。
実行タイプで[実行]を選択時に表示されます。
[ターゲットDBと異なる設定をする]が「オン」の時は、ターゲットDBとテスト用ソースDBでそれぞれ設定できます。
「オフ」の時は、ターゲットDBに設定した値がテスト用ソースDBにも適用されます。データベースの種類により動作が異なります。
-
Oracle Databaseの場合:任意の値を指定できます。
-
PostgreSQL/MySQLの場合:0または1を指定した場合、1行ごとに取得します。
2以上を指定した場合、全件取得します。 -
SQL Serverの場合:値に関係なくドライバ依存の自動的に決定される取得件数になります。
テスト用ソースDB[2DBモード]が「オン」のときに表示します。
項目名 説明 テスト用ソースDB
評価SQLセットを実行するデータベース(テスト用ソースDB)を選択します。
事前にターゲットDBを登録する必要があります。
をクリックすると、ターゲットDBの一覧画面に遷移します。詳細は「ターゲットDB」を参照してください。 テスト用ソースDBに使用する修正SQLセット
テスト用ソースDBに使用する修正SQLセットを選択します。
テスト用ソースDBをアセスメントで使用し、かつ修正SQLセットを用いる場合に設定します。修正SQLセットを使用しないときは[指定なし]を選択してください。ターゲットDBと異なる設定をする
「オン」にすると、次の項目をテスト用ソースDBとターゲットDBで異なる設定にすることができます。
-
フェッチ・サイズ値
-
テスト接続のパスワードと読み替えユーザ
-
バインド変数補完
「オフ」の場合はターゲットDBの設定がテスト用ソースDBと同期されます。この時、テスト用ソースDBの上記項目は編集不可になります。
ターゲットDBの設定をコピーする
ボタンをクリックするとターゲットDBの下記項目がテスト用ソースDBにコピーされます。
-
フェッチ・サイズ値
-
テスト接続のパスワードと読み替えユーザ
-
バインド変数補完
[ターゲットDBと異なる設定をする]が「オフ」の時は無効になります。
フェッチ・サイズ値(テスト用ソースDB)
一度にデータベースサーバーから受け取る行数を指定することができます。
実行タイプで[実行]を選択時に表示されます。
[ターゲットDBと異なる設定をする]が「オン」の時は、ターゲットDBとテスト用ソースDBでそれぞれ設定できます。
「オフ」の時は、ターゲットDBで設定した値がテスト用ソースDBにも適用されます。データベースの種類により動作が異なります。
-
Oracle Databaseの場合:任意の値を指定できます。
-
PostgreSQL/MySQLの場合:0または1を指定した場合、1行ごとに取得します。
2以上を指定した場合、全件取得します。 -
SQL Serverの場合:値に関係なくドライバ依存の自動的に決定される取得件数になります。
DBユーザー設定 項目名 説明 DBユーザー/
パスワード実行するDBユーザーをフィルタリングできます。
チェックされているDBユーザーのSQLのみ実行されます。
実行するDBユーザーの対応するパスワードを入力してください。
チェックされていないDBユーザーのSQLは実行されません。表示されるDBユーザー名は、評価SQLセットに格納されています。フィルタするDBユーザー名を変更する場合には、「評価SQLセットのユーザー変更」を参照してください。 読み替えユーザー
DBユーザー名を異なるユーザー名に読み替えてアセスメントを実行します。
読み替えユーザーを指定しない場合は、表示されているDBユーザー名でSQLを実行します。テスト接続
ターゲットDB/テスト用ソースDBに対するテスト接続を行います。
パスワードに誤りがあると、ログインエラーになりアセスメントを正しく行うことができません。
パスワードを入力したら画面右下の[テスト接続]ボタンをクリックし、接続できるか確認してください。
接続結果はボタン右のステータスアイコンに表示されます。ステータスアイコンをクリックすると結果をクリップボードにコピーできます。バインド変数補完 項目名 説明 バインド変数補完(ターゲットDB)/
バインド変数補完(テスト用ソースDB)「バインド変数補完」を参照してください。 フック処理 項目名 説明 フック処理(ターゲットDB)/
フック処理(テスト用ソースDB)アセスメントの開始前と終了後に任意のSQLを実行します。
-
アセスメント前後それぞれに実行したいDBユーザーとSQLの組を複数指定できます。入力フォームには複数文の入力が可能です。
複数文を入力した際、正しく処理されない場合には1入力フォームに単一のSQL文を入力して回避してください。
-
フック処理で設定したSQLの実行失敗はログに出力しますが、アセスメント処理は継続します。
-
DBユーザーのパスワードはアセスメント実行の[DBユーザー設定]の値を使用します。
-
評価SQLセットに含まれていないDBユーザーを指定する場合には、[DBユーザー設定]から[+]ボタンでDBユーザーを追加します。
-
DBユーザー名で指定し、読み替えユーザーが設定されていれば実行時にそれを使用します。
セッション毎フック処理 項目名 説明 セッション毎フック処理(ターゲットDB)/
セッション毎フック処理(テスト用ソースDB)セッションの開始と終了時に任意のSQLを実行します。ユーザーを問わず実行されます。
入力フォームには複数文の入力が可能です。-
複数文を入力した際、正しく処理されない場合には1入力フォームに単一のSQL文を入力して回避してください。
-
アセスメントセッションフックで実行したSQLのエラーにより当該セッションのSQL実行に影響がある可能性に注意してください。
-
-
作成が完了すると、アセスメント一覧画面に完了アイコン[]が表示されます。
SQL Testing 4.1以降は、完了時の状態によりステータスアイコンが変わります。
正常終了すると緑色[]、ログにwarningまたはerrorレベルの内容が出力されていると、オレンジ色[]になります。
10.1.1. バインド変数補完
評価SQLセットに取得されていないバインド変数をアセスメント実行時に補完します。
データ型ごとに補完する値を設定します。
-
バインド変数に求められる型情報を移行先データベースから取得できなかった場合は、「デフォルト」で指定した値を使用します。
-
値にNULLを指定するときは、NULLにチェックを入れてください。
|
10.2. アセスメントを複製して新規作成
既存のアセスメント設定をもとに、新たなアセスメントを行います。
-
アセスメントの一覧画面から複製するアセスメントにチェックを入れます。
-
画面上部の[複製して新規作成]ボタンをクリックします。
-
変更したい項目を修正し、[複製して新規作成]ボタンをクリックします。
項目の詳細については、「アセスメントの新規作成」を参照してください。
10.3. アセスメントの編集
アセスメントの名前とメモを編集します。
-
アセスメントの一覧画面から編集するアセスメントにチェックを入れます。
-
画面上部の[編集]ボタンをクリックします。
-
アセスメント名やメモを変更し、[保存]ボタンをクリックします。
一覧から、該当のアセスメント名が編集されていたら編集の完了です。
10.4. アセスメントの中断
処理中のアセスメントを中断します。
-
アセスメントの一覧画面から中断するアセスメントにチェックを入れます。
-
画面上部の[中断]ボタンをクリックします。
-
確認用画面が表示されます。中断するアセスメントを確認してください。
問題が無ければ、画面下部にある[中断]ボタンをクリックしてください。
一覧で、処理中のアセスメントが終了状態になると中断の完了です。
終了したアセスメントとして、アセスメントサマリーなどを確認することができます。
10.5. アセスメントの削除
アセスメントを削除します。
-
アセスメントの一覧画面から削除するアセスメントにチェックを入れます。
-
画面上部の[削除]ボタンをクリックします。
-
確認用画面が表示されます。削除するアセスメントを確認してください。
問題が無ければ、画面下部にある[削除]ボタンをクリックしてください。
一覧から、該当のアセスメント名がなくなると削除の完了です。
アセスメントの削除はデータ量に応じて数分かかる場合があります。
10.6. アセスメント結果のダウンロード
アセスメント結果をダウンロードします。
複数を選択した場合は複数個別にダウンロードされます。
-
アセスメントの一覧画面からダウンロードするアセスメントにチェックを入れます。
-
画面上部の[ダウンロード]ボタンをクリックします。
-
ダウンロード画面が表示されます。ダウンロードするデータのリンク(ZIP)をクリックしてください。
項目 説明 フィルタ設定
1つのターゲットDBでのみ行うアセスメントの場合、実行結果のうち成功したSQLのみダウンロードする場合は[成功]のみにチェックを入れます。
失敗したSQLのみダウンロードする場合は[失敗]のみにチェックを入れます。
結果に関係なくすべてのSQLの実行結果を取得する場合は[成功][失敗][性能が劣化]にチェックを入れます。
[性能が劣化]はSQL Testing 4.2以降で対応しています。テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの場合、実行結果の[ターゲットDBでのみ失敗][両DBで失敗][結果が相違][性能が劣化][成功][テスト用ソースDBでのみ失敗]から選択します。
テスト用ソースDB
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでテスト用ソースDBの情報も取得する場合には、トグルスイッチを「オン」にします。
各データのダウンロードリンク
ダウンロードするデータ内容(実行結果、詳細情報、またはその両方)を選択します。
-
SQL毎の実行結果を出力します
-
SQL毎の詳細情報を出力します
-
実行結果と詳細情報を統合して出力します
ダウンロード開始間隔
アセスメント一覧画面で複数のアセスメントをチェックした場合に表示されます。ファイル毎のダウンロード開始間隔を調整します。
1ファイルのダウンロード完了まで長時間になることが予想される場合は、負荷分散のため間隔を長くとることを推奨します。すべてのファイルのダウンロードが開始されるまでブラウザ画面のリロードは行わないでください。 -
10.7. ログの確認
ログアイコンをクリックすると、アセスメントを実行した際のログを確認することができます。
また、利用可能なログはダウンロードできます。
10.8. アセスメント結果の確認
サマリーの画面から実行したSQLの実行結果を確認します。
SQL Testing 4.0以降では、Insight DT 3.2以前に作成されたアセスメントにおいて、アセスメント結果からSELECT文などの取得結果は閲覧できません。 |
-
アセスメントの一覧画面から確認するアセスメント名をクリックします。
-
サマリー画面が表示されます。
サマリー画面の詳細については、「サマリー」を参照してください。
10.9. サマリー
アセスメントの一覧からアセスメント名を選択することで、サマリーの画面へ遷移し、アセスメントのサマリーを閲覧します。
1つのターゲットDBでのみ行うアセスメントと、テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントとでサマリー画面の表示形式が異なります。
-
1つのターゲットDBでのみ行うアセスメントでのサマリー画面
ソースDBでSQLを取得した際のSQL実行時間情報を対象に、ターゲットDBでのSQL実行時間との比較を行います。
SQL Testing 4.2以降は結果ステータスに「性能が劣化」が追加されました。-
評価SQLセットに記録されているSQL実行時間と比較を行いたくない場合は、アセスメント設定の「時間しきい値」または「割合しきい値」へ大きい値を設定してください。
例えば、「時間しきい値」を100,000秒などの大きな秒数にすることで実現できます。
しきい値を超えると「性能が劣化」と判定されます。「時間しきい値」の場合、差が27時間以上ある場合に性能劣化となるため実質、性能劣化と判定されません。 -
SQL Testing 4.1以前で作成した1DB実行のアセスメントについては、実行結果の再計算および更新は行いません。
アセスメント一覧で「性能が劣化」カラムの数値は「0」になります。
-
-
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでのサマリー画面
テスト用ソースDBでSQLを実行した際のSQL実行時間情報を対象に、ターゲットDBでのSQL実行時間、SQL実行結果との比較を行います。
ステータス テスト用ソースDB ターゲットDB 備考 ターゲットDBでのみ失敗
成功
失敗
-
両DBで失敗
失敗
失敗
-
結果が相違
成功
成功
SELECT結果の比較/DMLの実行結果行数の比較で結果が異なる場合
性能が劣化
成功
成功
結果は同じだが、ターゲットDBでの処理が遅かった場合
成功
成功
成功
ターゲットDBでの処理時間がテスト用ソースDB以下の場合
テスト用ソースDBでのみ失敗
失敗
成功
テスト用ソースDBでの処理が失敗した場合
エラーメッセージ、エラーユーザー、エラープログラムの件数が10件を超える場合には、[全体表示]ボタンをクリックして他のエラー内容を確認します。
サマリー画面の左のページメニュー、または各ステータスや[エラーメッセージ][エラーユーザー]などでグルーピングされた一覧のリンクをクリックしてSQL実行結果一覧画面へ移動できます。
また、右のサイドバーを開くと、アセスメント実行時の設定情報を確認できます。
設定項目の詳細については、「アセスメント」を確認してください。 |
10.9.1. ターゲットDBでのみ失敗したSQL
実行できなかったSQL(左側)と実行できたSQL(右側)の割合が表示されます。
それぞれの件数と、すべてのSQLに対しての割合が表示されます。
評価に含まれていたSQLをすべて実行していますが、実行する際にDBユーザー、セッション等でフィルタリングを行った場合は、SQLが絞り込まれています。
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでは、ターゲットDBでの実行が失敗したSQL(ステータスが[ターゲットDBでのみ失敗][両DBで失敗])が表示対象になります。
実行できなかったSQLは3つの観点からグルーピングしています。
-
エラーメッセージ
-
エラーユーザー
-
エラープログラム
それぞれの件数を集計し、上位10件を表示します。
上位11件以降を参照する場合、[全体表示]をクリックするとページネーション表示()になり、残りを参照できます。
各項目のSQL情報を閲覧する場合は、対象の行を選択します。
10.9.2. 結果が異なるSQL
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントで、左側に結果が異なったSQL、右側に同じ結果になったSQLの割合と件数が表示されます。
結果は「取得結果」で確認できます。
サマリー画面で[SQLテキスト]をクリックすると、SQL詳細画面を表示します。
10.9.3. 性能が劣化したSQL
左側に遅くなったSQL、右側に遅くならなかったSQLの割合と件数が表示されます。
割合の分母は成功したSQLの件数です。
1つのターゲットDBでのみ行うアセスメントでは、ソースDBで取得した実行時間とターゲットDBで取得した実行時間を比較し、100%以上になるものを遅くなったSQLとして算出、上位10件を表示します。
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでは、アセスメント実行の際にテスト用ソースDBで取得した実行時間とターゲットDBで取得した実行時間を比較し、テスト用ソースDBでの実行時間に対してターゲットDBでの実行時間が100%以上になるものを遅くなったSQLとして算出、上位10件を表示します。
パースモードで実行した場合は、実行時間が取得できないため表示されません。
実行時間を取得する場合は、アセスメントの実行タイプを実行に指定してアセスメントしてください。
SQL情報を閲覧する場合は、対象の行を選択します。
[SQLテキスト]をクリックすると、SQL詳細画面を表示します。
-
取得したSQLの「実行計画」を確認できます。
-
1つのターゲットDBでのみ行うアセスメントでは、ソースDBのSQLの実行時間が0秒として取得されている場合があります。
詳細は「0秒時の対応」を参照してください。 |
10.9.4. テスト用ソースDBにて失敗したSQL
テスト用ソースDB、またはテスト用ソースDBとターゲットDBの両データベースでエラーになったSQLを、出現順序の早い順で表示します。
タイトルをクリックするとTOP10以降を確認できます。
SQLテキストをクリックすると該当SQLの詳細を表示します。
左側にテスト用ソースDBで失敗したSQLのパーセンテージと件数、右側にテスト用ソースDBで失敗しなかったSQLのパーセンテージと件数が表示されます。
パーセンテージの分母はエラーが出たSQLの件数です。
10.9.5. 移行情報
バインド変数変換や構文でエラーになるものを集計し、表示します。
-
バインド変数書式変換がある場合に変換したもの
-
取得できていないバインド変数に値を埋めたもの
-
バインド変数型の型変換で、エラーの可能性があるもの
-
非互換構文について取得したもの(Oracle Databaseのみ)
バインド変数については、以下を参照してください。 |
10.9.6. サマリーのダウンロード
アセスメント結果をCSVファイル形式でダウンロードします。
-
画面上部の[ダウンロード]ボタンをクリックします。
-
SQLのフィルタ条件(フィルタ設定)を選択します。
ダウンロードするデータのリンク(ZIP)をクリックします。1つのターゲットDBでのみ行うアセスメントの場合テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの場合項目 説明 フィルタ設定
1つのターゲットDBでのみ行うアセスメントの場合、実行結果のうち成功したSQLのみダウンロードする場合は[成功]のみにチェックを入れます。
失敗したSQLのみダウンロードする場合は[失敗]のみにチェックを入れます。
結果に関係なくすべてのSQLの実行結果を取得する場合は[成功][失敗][性能が劣化]にチェックを入れます。
[性能が劣化]はSQL Testing 4.2以降で対応しています。テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの場合、実行結果の[ターゲットDBでのみ失敗][両DBで失敗][結果が相違][性能が劣化][成功][テスト用ソースDBでのみ失敗]から選択します。
テスト用ソースDB
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでテスト用ソースDBの情報も取得する場合には、トグルスイッチを「オン」にします。
追加情報
実行結果加え、追加情報も取得する場合には、以下のトグルスイッチを「オン」にします。
-
SQL毎の詳細情報を取得します:実行結果に加え、SQL毎の詳細データも取得する場合にオンにします。
-
実行結果と詳細情報をマージして1つのCSVにします:実行結果CSVと詳細データCSVを1つのファイルにまとめたい場合にオンにします。
各データのダウンロードリンク
ダウンロードするデータ内容(実行結果、詳細情報、またはその両方)を選択します。
-
SQL毎の実行結果を出力します
-
SQL毎の詳細情報を出力します
-
実行結果と詳細情報を統合して出力します
-
-
ZIP圧縮されたCSVファイルのダウンロードが開始します。
CSVファイルの項目の詳細は「CSVファイルのカラムについて」を参照してください。 |
10.9.7. 修正を評価SQLセットに適用
修正したSQLを評価SQLセットにマージします。
-
SQL Testing 4.2以降の場合は、SQL修正一覧画面上部の[修正を評価SQLセットに適用]ボタンをクリックします。
SQL Testing 4.1以前の場合は、サマリー画面上部に修正完了率と[修正を評価SQLセットに適用]ボタンが表示されます。[修正を評価SQLセットに適用]ボタンをクリックします。 -
確認用の画面が表示されます。
[評価SQLセット]を選択し、画面下部の[修正を評価SQLセットに適用]ボタンをクリックします。画面はSQL Testing 4.2以降の場合です。選択した評価SQLセットへマージされます。
修正したSQLは評価SQLセットへ上書きされますので、必要に応じて評価SQLセットのコピーを作成してください。
10.9.8. SQLの抽出(ツール連携)
実行したアセスメントの結果から構文の重複を排除してSQLテキストを抽出します。
抽出したSQLは、失敗したSQLの自動変換など、外部ツールと連携して利用できます。
-
[SQLの抽出]ボタンをクリックすると、ダウンロードの確認画面が表示されます。
-
どの実行ステータスのSQLをダウンロードするかを選択し、画面下部の[ダウンロード]ボタンをクリックします。
ダウンロードが実行します。1つのターゲットDBでのみ行うアセスメントの場合テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでは、[ターゲットDBでのみ失敗][両DBで失敗][結果が相違][性能が劣化][成功][テスト用ソースDBでのみ失敗]から選択します。
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの場合
詳細は「失敗したSQLの抽出」を参照してください。 |
10.10. SQL実行結果一覧
サマリー画面の左のページメニューからSQL実行結果一覧へ遷移します。
または、サマリーの画面からSQLを絞り込むとSQL実行結果一覧画面へ遷移します。
サマリーの画面からのSQL絞り込みは、パイチャートのステータスやグルーピングされた一覧のリンクをクリックします。
クリックしたリンクによって、SQL実行結果一覧での初期のフィルタの状態が異なります。
-
SQL Testing 4.1以前では、SQL実行結果一覧画面の上部に修正完了率(バーチャート)を表示します。
左側に未修正のSQL、右側に修正済のSQLの割合と件数を表示します。初期表示は未修正のSQLが100%、修正済のSQLが0%です。 -
SQL Testing 4.2以降では、修正完了率(バーチャート)は「SQL修正一覧」に表示されます。
SQL実行結果一覧では、一番左に表示されるSQL実行の番号(#)をクリックすると、そのSQL詳細画面へ遷移します。
SQLのステータスが失敗アイコン[]の場合、SQLを修正、保存することで修正アイコン[]に変わります。
SQLの保存については、「SQLの保存」を参照してください。
保存していくことでSQLのステータスや修正完了率が変更されていきます。
10.10.1. 実行結果一覧
SQL実行結果、修正状態、フィルタリングから選択した項目で実行結果一覧の表示が切り替わります。
各項目の詳細は「使用している項目名について」を参照してください。 |
- SQL実行結果
-
- 1つのターゲットDBでのみ行うアセスメントの場合
項目名 説明 失敗
SQL実行が失敗したものを表示します。
成功
SQL実行が成功したものを表示します。
性能が劣化
SQL実行時間と比較して、遅かったものを表示します。
SQL Testing 4.2以降で対応しています。- テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの場合
-
項目名 説明 ターゲットDBでのみ失敗
ターゲットDBでのみSQL実行が失敗したものを表示します。
両DBで失敗
テスト用ソースDBとターゲットDBの両データベース上でSQL実行が失敗したものを表示します。
結果が相違
テスト用ソースDBとターゲットDBの両データベース上でSQL実行が成功したが、SQL実行結果が異なったものを表示します。
性能が劣化
テスト用ソースDBとターゲットDBの両データベース上でSQL実行が成功し、SQL実行結果は同じであったが、ターゲットDBでの実行時間がテスト用ソースDBよりも遅かったものを表示します。
成功
SQL実行が成功したものを表示します。
テスト用ソースDBでのみ失敗
テスト用ソースDBでのみSQL実行が失敗したものを表示します。
- 修正状態
-
項目名 説明 修正済
SQL詳細画面で修正が完了したSQLを表示します。
未対処
SQL詳細画面で未修正のSQLを表示します。
- フィルタリング
-
実行結果一覧の以下の項目の中から、特定の値(グレーボックスで囲まれたセル)をクリックすることで、表示されているSQLをフィルタリングします。
フィルタリングする項目は複数選択できます。フィルタリングできる項目は条件によって異なります。フィルタリングできる項目は以下のとおりです。
-
PI Hash
-
SQL ID
-
DBユーザー
-
プログラム
-
ターゲットDBエラーコード
-
ターゲットDBエラーメッセージ
- フィルタリングメニューからフィルタリング
-
項目名の隣のフィルタリングメニューをクリックして、フィルタリングもできます。
チェックを入れて[適用]をクリックすると、チェックした値でフィルタリングされます。
フィルタ後は表内のフィルタ処理は無効になります。-
1ページ当たり100件まで表示します。
-
検索はページ内でのみ有効です。
-
- 詳細フィルタを用いたフィルタリング
-
フィルタリングの右の[詳細フィルタ]をクリックすると、メニューが表示されます。
フィルタ条件にフィルタ対象、演算子、値を入力して[適用]をクリックします。
フィルタリング結果に詳細フィルタを適用することもできます。-
ステータス項目以外の項目をフィルタ条件に追加することができます。
-
適用中のフィルタはフィルタ対象にも表示され、編集できます。
-
中央の項は演算子を選択します。
-
演算子がNULL、NOT NULLの場合、値はグレー表示になり設定できません。
-
フィルタ対象の重複が許されるのは、一部演算子(<、≦、>、≧)のみです。
-
演算子「IN」を選択すると、値の右に[+]アイコンが表示され、OR条件を作成することができます。この時、フィルタ対象と演算子はグレー表示になり設定できません。
OR検索用の行は、各項目に不備がない状態でのみ行の追加ができます。演算子が「IN」のときのみ表示されます。-
比較条件が「LIKE」または「ILIKE」の場合に前方一致か部分一致かを選択できます。
LIKEとILIKEの違いは下記のとおりです。演算子 説明 LIKE
[値]に指定されたパターンに一致する文字列でフィルタします。大文字小文字を区別します。
ILIKE
[値]に指定されたパターンに一致する文字列でフィルタします。大文字小文字を無視します。
-
-
内部で処理できない値を入力すると、その旨のメッセージが表示されます。
-
-
- SQL実行結果一覧の表示項目とSQLのソート
-
アセスメントの実行タイプによって、SQL実行結果一覧の表示される項目が異なります。
また、項目名をマウスでホバリングすると項目名の前または後ろに矢印が表示されます。矢印をクリックすると、SQLを昇順と降順でソートします。ソートできる項目は条件によって異なり、ソートできる項目は以下のとおりです。
表中の「1DB」は1つのターゲットDBでのみ行うアセスメントを指します。
また、「2DB」はテスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントを指します。項目 1DB(パース) 1DB(実行) 2DB(パース) 2DB(実行) ソート #(連番)
〇
〇
〇
〇
可
SQLテキスト
〇
〇
〇
〇
可
修正済みSQL
〇
〇
〇
〇
不可
変換済みSQL(テスト用ソースDB)
✕
✕
〇
〇
可
変換済みSQL(ターゲットDB)
〇
〇
〇
〇
可
PI Hash
〇
〇
〇
〇
可
SQL ID
〇
〇
〇
〇
可
DBユーザー
〇
〇
〇
〇
可
バインド変数名
〇
〇
〇
〇
不可
変換済みバインド変数名(テスト用ソースDB)
✕
✕
〇
〇
不可
変換済みバインド変数名(ターゲットDB)
〇
〇
〇
〇
不可
SQL開始時刻
〇
〇
〇
〇
可
SQL終了時刻
〇
〇
〇
〇
可
プログラム
〇
〇
〇
〇
可
ログオン時刻
〇
〇
〇
〇
可
ログオフ時刻
〇
〇
〇
〇
可
テスト用ソースDBエラーコード
✕
✕
〇
〇
不可
テスト用ソースDBエラーメッセージ
✕
✕
〇
〇
不可
ターゲットDBエラーコード
〇
〇
〇
〇
可
ターゲットDBエラーメッセージ
〇
〇
〇
〇
可
ソースDB実行時間(秒)
〇
〇
〇
〇
可
テスト用ソースDB実行時間(秒)
✕
✕
✕
〇
可
ターゲットDB実行時間(秒)
✕
〇
✕
〇
可
遅くなった割合(%)
✕
〇
✕
〇
可
テスト用ソースDB取得完了時間(秒)
✕
✕
✕
〇
可
ターゲットDB取得完了時間(秒)
✕
〇
✕
〇
可
テスト用ソースDB取得行数
✕
✕
✕
〇
可
ターゲットDB取得行数
✕
✕
✕
〇
可
影響のあった行数(テスト用ソースDB)
✕
✕
✕
〇
可
影響のあった行数(ターゲットDB)
✕
✕
✕
〇
可
収集時処理行数
〇
〇
〇
〇
可
行比較結果
✕
✕
✕
〇
可
セッションID
〇
〇
〇
〇
可
オブジェクト
〇
〇
〇
〇
可
ORDER BY句指定※1
✕
✕
✕
〇
可
行取得中断
✕
✕
✕
〇
可
Action
〇
〇
〇
〇
可
Action Operation
〇
〇
〇
〇
可
Action Program
〇
〇
〇
〇
可
Client Information
〇
〇
〇
〇
可
Client Info IP
〇
〇
〇
〇
可
Client Info Host
〇
〇
〇
〇
可
Client Info User
〇
〇
〇
〇
可
〇:表示、✕:非表示、可:ソートできる、不可:ソートできない
※1 行順序の比較で[完全一致]を選択した時以外はNULLになります。 - 重複排除
-
SQL IDまたはPI Hashを用いて同じSQL文を持つ結果を排除します。PI Hashによる重複排除は意味的に同じSQL文を同一とみなします。
プルダウンメニューの[しない][PI Hash][SQL ID]から重複排除する項目を選択します。 - カラム表示設定
-
実行結果一覧画面に表示されるカラムをカスタマイズできます。
[カラム表示設定]ボタンをクリックすると、表示するカラム一覧が表示され、表示させたくないカラムのチェックを外すと非表示になります。
-
デフォルトではすべてのカラムを表示しています。
-
[#][ステータス][SQLテキスト]は常に表示されるカラムで、非表示にできません。
-
変更した表示設定は同一ブラウザにおいて保持されます。
-
10.10.2. SQL実行結果一覧のダウンロード
アセスメント結果をCSVファイル形式でダウンロードします。
アセスメント結果にフィルタリングを反映させた結果をダウンロートすることができます。
-
SQL実行結果一覧画面でフィルタリング設定を行った後、[ダウンロード]ボタンをクリックします。
-
現在設定されているフィルタリング結果をダウンロードする場合、[現在設定されているフィルタを使用]のトグルスイッチを「オン」にして、ダウンロードするリンクをクリックします。
または、現在設定されているフィルタリング結果は使用しない場合、[現在設定されているフィルタを使用]を「オフ」にします。フィルタリングしたいフィルタ設定の実行結果にチェックを入れて、ダウンロードするリンクをクリックします。項目 説明 フィルタ設定
[現在設定されているフィルタを使用]のトグルスイッチを「オン」にするとダウンロードする実行結果を現在設定されているフィルタで絞り込みを行うことができます。
[現在設定されているフィルタ]の対象は、SQL実行結果一覧画面の下記の項目の設定内容です。
-
[SQL実行結果]
-
[フィルタリング]
-
[重複排除]
[現在設定されているフィルタを使用]を「オフ」にすると、以下の実行結果から選択できます。
-
1つのターゲットDBでのみ行うアセスメントの場合は[成功][失敗][性能が劣化]から選択します。すべてのSQLの実行結果を取得する場合はすべてにチェックを入れます。
[性能が劣化]はSQL Testing 4.2以降で対応しています。 -
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの場合は[ターゲットDBでのみ失敗][両DBで失敗][結果が相違][性能が劣化][成功][テスト用ソースDBでのみ失敗]から選択します。すべてのSQLの実行結果を取得する場合はすべてにチェックを入れます。
テスト用ソースDB
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでテスト用ソースDBの情報も取得する場合には、トグルスイッチを「オン」にします。
各データのダウンロードリンク
ダウンロードするデータ内容(実行結果、詳細情報、またはその両方)を選択します。
-
SQL毎の実行結果を出力します
-
SQL毎の詳細情報を出力します
-
実行結果と詳細情報を統合して出力します
-
マイニングサーチ形式でダウンロード
[現在設定されているフィルタを使用]をオンにした場合、表示されます。フィルタリング後のSQLをマイニングサーチ形式で出力します。
-
-
ZIP圧縮されたCSVファイルのダウンロードが開始します。
10.11. SQL修正一覧
SQL Testing 4.2以降で対応しています。
アセスメント結果から修正して保存したSQL(SQL文・バインド変数)の一覧を確認することができます。
画面上部の修正完了率(バーチャート)では、左側に未修正のSQL、右側に修正済のSQLの割合と件数を表示します。
初期表示は未修正のSQLが100%、修正済のSQLが0%です。
表示された一覧の行をクリックするとpiHashとsqlIdのフィルタを適用した、実行結果一覧画面へ遷移できます。
10.12. SQLの詳細と実行
サマリーの画面からドリルダウンし、SQL実行結果一覧の画面左の連番(#)をクリックすると、SQL詳細画面に遷移します。
-
1つのターゲットDBでのみ行うアセスメントと、テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントとで表示内容が異なります。
-
修正SQLセットを適用して実行した場合は、適用されたSQLが表示されます。
10.12.1. SQLの修正
[SQLの修正]タブでは、SQLを修正しての実行確認などを行うことができます。
10.12.1.1. ステータス
画面上部にはステータスが表示されます。
実行できなかったSQLの場合は、エラーコードとエラーメッセージが表示されます。
実行できたSQLの場合は、ターゲットDBでのSQL実行時間が表示されます。
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでは、両データベースに対してSQLを実行して得られた情報が表示されます。
アセスメント設定の行順序の比較で一致レベルを指定した場合、ステータスに再ソートした結果であるかどうかを表示します。
-
順序を含めて完全一致
-
再ソート実行したが不一致
-
再ソート実行により一致
10.12.1.2. SQLの編集、実行計画取得、実行と保存
SQLを編集と実行計画取得、実行、保存します。
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでは、両データベースに対してそれぞれSQLを修正して、実行計画取得、実行を行います。
保存はターゲットDBに対して行ったSQLのみ保存対象となります。
10.12.1.3. SQLの整形
[SQLの修正]タブを選択して、画面左の[整形する]ボタンをクリックすると、現在表示されているSQLを整形します。
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでは、それぞれのSQLテキスト編集ペインで利用できます。
10.12.1.4. SQLの実行と実行先の設定
SQLの実行先を設定して、SQLを実行します。
-
画面左のSQLを、ターゲットDBへ実行させるSQLに書き換えます。
SQL実行時にセッションパラメーターを変更したい場合、下記のように複数文を入力して実行することができます。ALTER SESSION SET NLS_DATE_FORMAT = 'RRRR/MM/DD'; SELECT TO_CHAR(CURRENT_DATE) FROM DUAL;
-
画面右の[設定][バインド変数]タブにて、実行先のデータベースの設定を行います。
-
必要な値を入力します。
設定 項目名 説明 ターゲットDB
SQLの実行先のDBを選択します。
DBユーザー
DBユーザー名を入力します。
ターゲットDBに存在するユーザーを入力します。パスワード
DBユーザーのパスワードを入力します。
入力すると、グレーアウトした[SQLの実行]ボタンが有効になります。実行タイプ
実行する方法を選択します。
実行:実際にSQLを実行します。
パース:パース実行を行います。バインド変数の値がなくてもテーブルの有無や構文のチェックができます。パース実行の処理時間の参考値については、弊社サポートサイト(Service Portal)の[Insight SQL Testing]>[ナレッジ]から文書番号:000002063を参照してください。 フェッチ・サイズ値
一度にデータベースサーバーから受け取る行数を指定します。
SQL実行結果をコミットします
トグルスイッチをオンにすると、SQL実行をロールバックせずにコミットして、結果をターゲットDBに保持します。
バインド変数書式変換
トグルスイッチをオンにすると、SQLに含まれる名前付きバインド変数( :name)をターゲットDBで実行可能な書式に変換してSQLを実行します。
移行先が名前付き引数に対応していないDBMSでもデータベース接続ドライバー、またはデータベース接続プログラムによって対応される場合を再現してアセスメント実行時にSQLを自動変換します。バインド変数書式変換は、Oracle Database以外のデータベースからOracle Databaseへの変換をサポートしていません( 「$1」や「?」から「:1」への変換)。 SQL自動分割実行
トグルスイッチをオンにすると、複数文のSQL判別と分割実行をします。
バインド変数 項目名 説明 バインド変数
バインド変数とその値を入力します。
[]をクリックすると入力要素が表示されます。行の右にある[]をクリックすると当該の入力要素が削除されます。-
変数名、値、データ型を入力します。
-
値にNULLを指定するときは、NULLにチェックを入れてください。
-
データ型は、[文字列][固定長文字列][任意精度数値][整数][小数][時刻][日付][日付時刻][真偽値][バイナリ]から選択してください。
-
-
変数名の頭に「:」や「$」は必要ありません。
バインド変数については「ターゲットDB実行時の型指定と入力書式」を参照してください。 -
-
画面右の[SQL実行]をクリックすると、SQLが実行されます。
-
結果は、画面右上のインフォメーションに表示されます。
-
SQLがSELECTのときは取得結果を表示します(最大100行表示)。
-
DML(Update/Insert/Delete)のときは更新された行数の情報を表示します。
-
10.12.1.5. SQLの保存
SQLの修正をアセスメントに保存します。
ここで保存した修正は、サマリー画面での修正を評価SQLセットに適用する場合、または修正SQLセットを作成する際に使用できます。
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでは、ターゲットDBに対して実行したペインでのみSQL保存ができます。
SQLの保存の設定時にバインド変数の保存有無を選択したり、保存したSQLの修正を取り消すことができます。
-
SQLを修正した後、[SQLの保存]ボタンをクリックします。
項目名 説明 SQLの保存
修正したSQLを保存します。
SQLのみの保存となるため、バインド変数はNULLとして保存されます。
すでにバインド変数を保存している場合、NULLとして上書き保存されてしまう点に注意してください。バインド変数も含めて保存
修正したSQLとバインド変数の設定の両方を保存します。
[SQLの保存]ボタンの右横の下三角形のアイコンをプルダウンするとメニューが表示されます。バインド変数のみ保存
バインド変数の設定のみ保存します。
[SQLの保存]ボタンの右横の下三角形のアイコンをプルダウンするとメニューが表示されます。
バインド変数のみの保存となるため、SQLはNULLとして保存されます。
[SQLの保存]と同様、すでにSQLを保存している場合、NULLとして上書き保存されてしまう点に注意してください。 -
[修正の取り消し]ボタンをクリックすると、保存したSQL(バインド変数)を取り消します。
修正したSQLが保存されている場合に修正の取り消しが有効になります。
10.12.1.6. 実行計画取得
[実行計画取得]ボタンをクリックすると、詳細画面で表示されているSQLに対して実行計画を取得します。
実行計画取得後の表示形式は、対象データベースにより異なります。 |
10.12.2. 取得結果
[取得結果]タブでは、テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントで取得結果が異なったSQLに対して、アセスメント実行時に取得したSQLの実行結果を表示します。
-
SQLがSELECTのときに取得行数と取得結果を表示します。
-
取得結果が(最初に)異なる箇所をメッセージ、およびハイライトで表示します。
-
取得行数、カラム数が異なる場合は、画面上部にメッセージが表示されます。
-
上記以外のカラム名など異なる場合等は、メッセージと該当セルをハイライトで表示します。
-
-
取得行数が多い場合は、ページ番号、表示件数を指定して移動することができます。
-
すべてのページまたは現在表示しているページを選択してダウンロードできます(JSONまたはCSV形式)。
データが大きい場合(10MB)は、取得結果の一覧に表示されませんが、ダウンロードして確認することができます。 -
カラム名に値の型をツールチップで表示します。
10.12.3. 実行計画
[実行計画]タブでは、テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントで、アセスメント実行時に取得・保存した実行計画を表示します。 保存条件はアセスメント設定の[実行計画の保存条件]に従います。
10.12.4. ソースSQL
[ソースSQL]タブでは、ソースDBで実行されていたSQLを確認します。
[SQLの修正]タブでSQLを修正した場合、こちらの[ソースSQL]タブから編集前のSQLを確認できます。
また[SQLの修正]タブでバインド変数を修正した場合でも、[ソースSQL]タブから編集前のバインド変数を確認できます。
10.12.5. 詳細情報
[詳細情報]タブでは、SQL実行結果の詳細情報を確認します。
表示される項目は、SQL実行結果一覧と同様です。
項目の詳細は「使用している項目名について」を参照してください。 |
10.12.6. 失敗したSQLの分析機能
ターゲットDBで失敗したSQLについて、アセスメント結果を参考にエラーになった理由と修正案をLLMが推論して表示します。
-
アセスメント設定で[2DBモード]が「オン」、かつSQL実行結果のステータスが[ターゲットDBでのみ失敗]のSQLがある場合、本機能を使用することができます。
-
SQL Testing 4.2以降では、1つのターゲットDBでのみ行うアセスメントにも対応しました。
SQL実行結果のステータスが[失敗]のSQLがある場合、本機能を使用することができます。
管理者画面で使用するLLMを設定した場合、SQL詳細画面の[SQLの修正]タブの[エラー分析]ボタンが有効になります。
また、SQL Testing 4.2以降では、SQL詳細画面でSQLを実行した結果が失敗の時、その結果を使用して「エラー分析」ができます。
-
SQL詳細画面から[エラー分析]ボタンをクリックします。
-
エラー分析画面が開きます。[分析開始]ボタンをクリックすると推論が始まります。
項目名 説明 モデルの選択
Amazon Bedrockを使用する場合、利用可能なモデルが選択できます。
SQL Testing 4.2以降で対応しました。GPT4Allの場合は使用できません。分析開始
[分析開始]ボタンをクリックすると推論が始まります。
プロンプトの設定
プロンプトの設定を展開すると、推論時に使用するプロンプトの設定を行うことができます。
-
テンプレートプロンプト
-
デフォルトで用意されているプロンプトです。編集することはできません。
-
-
カスタムプロンプト
-
ユーザーが任意に作成したプロンプトです。
-
作成したカスタムプロンプトは[保存]ボタンをクリックすることで保存できます。保存したプロンプトは他のエラー分析で使用することができます。
-
-
プレースホルダーについて
プロンプト内で指定されたプレースホルダーは、推論時に各項目の値と置き換えられます。
使用できるプレースホルダーは以下のとおりです。-
{sourceDb}: テスト用ソースDB種別に置き換えられます。
-
{targetDb}: ターゲットDB種別に置き換えられます。
-
{sqlQuery}: SQLテキストに置き換えられます。
-
{errorMessage}: エラーメッセージに置き換えられます。
-
-
-
分析結果がLLMからの応答に表示されます。
LLMからの応答には誤りがある可能性があります。 |
使用するLLMの設定方法については、「LLM」を参照してください。 |
11. 修正SQLセット
修正SQLセットは、評価SQLセットの一部のSQLに対し、修正を適用してアセスメントを実行する機能です。
1回目のアセスメントで実行エラーとなったSQLを、外部ツールなどで更新して再度実行する場合に、修正した部分を追加適用してアセスメントを行います。
11.1. 修正SQLセットの作成
-
左のページメニューから[修正SQLセット]をクリックします。
-
修正SQLセットの一覧画面から[新規作成]ボタンをクリックします。
-
必要な値を入力した後、画面下部の[新規作成]ボタンをクリックします。
アセスメント結果にて保存してSQLから作成外部ツールで変換したSQL情報から作成項目名 説明 修正SQLセット名
任意の修正SQLセットの名前を入力します。
大文字、小文字を区別します。修正SQLセットのソース選択
修正SQLセットは、以下のいずれかの手段から作成できます。
-
アセスメント結果にて保存したSQLから作成
アセスメントに対して[SQLの修正]タブで修正保存したSQLを使用する場合に選択してください。 -
外部ツールで変換したSQL情報から作成
評価SQLセットに対してツール連携で適用可能な、ZIPファイルまたはCSVファイルをアップロードする場合に選択してください。
アセスメント結果にて保存したSQLから作成
アセスメント
▼をクリックし、修正SQLセットに使用するアセスメントを選択してください。
外部ツールで変換したSQL情報から作成
データ元ファイル
または入力欄をクリックし、修正SQLセットに使用するファイルを選択してください。
メモ
修正SQLセットについてのメモを入力します。
-
修正SQLセットの一覧に情報が追加されると完了です。
修正SQLセットが追加されるまで時間がかかる場合があります。
11.2. 修正SQLセットのSQL詳細
修正SQLセットを作成した後、修正SQLセットの中のSQLの詳細を確認します。
-
修正SQLセットの一覧画面から詳細情報を確認する修正SQLセット名を選択します。
-
SQLの一覧画面が表示されます。
11.3. 修正SQLセットの結合
複数の修正SQLセットを結合して1つの修正SQLセットを作成します。
-
修正SQLセットの一覧画面から結合する修正SQLセットにチェックを入れます。
ステータスが完了アイコン[]の修正SQLセットを選択してください。
ステータスが失敗アイコン[]の修正SQLセットは選択しても、内部フィルタで除外されます。 -
画面上部の[結合]ボタンをクリックします。
-
新たに生成する修正SQLセット名を入力し、結合するSQLセットの順番をドラッグアンドドロップで並べ替えます。
画面下部にある[結合]ボタンをクリックします。
※ステータスが失敗アイコン[]の修正SQLセットは表示されません。項目名 説明 修正SQLセット名
新たに生成する修正SQLセットの名前を入力します。既存の修正SQLセット名と異なる名前にしてください。
大文字、小文字を区別します。メモ
修正SQLセットについてのメモを入力します。
修正SQLセットの一覧に情報が追加され、完了アイコン[]になると完了です。
修正SQLセットを作成中はアイコンが[]になります。完了まで時間がかかる場合があります。
11.4. 修正SQLセットの編集
修正SQLセットの名前やメモを編集します。
-
修正SQLセットの一覧画面から編集する修正SQLセットにチェックを入れます。
-
画面上部の[編集]ボタンをクリックします。
-
必要な値を入力した後、画面下部にある[保存]ボタンをクリックします。
項目名 説明 修正SQLセット名
変更する修正SQLセット名を入力します。
メモ
修正SQLセットについてのメモを入力します。
修正SQLセットの一覧の表示が変更になると、編集の完了です。
11.5. 修正SQLセットの削除
-
修正SQLセットの一覧画面から削除する修正SQLセットにチェックを入れます。
-
画面上部の[削除]ボタンをクリックします。
-
確認用画面が表示されます。削除する修正SQLセットを確認してください。
問題が無ければ、画面下部にある[削除]ボタンをクリックしてください。
一覧から、該当の修正SQLセット名がなくなると削除の完了です。
修正SQLセットの削除はデータ量に応じて数分かかる場合があります。
12. AWSマイグレーション
AWSマイグレーションは、あらかじめスケジュールを設定した期間中に、定期的に評価SQLセットの作成とアセスメントの実行を繰り返すことができる機能です。
データベースのスナップショットから、テスト用ソースDBとターゲットDBを作成して、2つのデータベースを指定したアセスメントを行います。
|
12.1. AWSマイグレーションの一覧
-
グローバルメニューバーから[AWSマイグレーション]をクリックします。
-
設定されているAWSマイグレーションの一覧が表示されます。
一覧では、それぞれのAWSマイグレーションの状態が表示されます。
項目 説明 ステータス
最新のアセスメント実行のステータスをアイコンで示します。
スケジュール状態
現在スケジュール実行が有効かどうかを示します。
マイグレーション名
設定したマイグレーションの名前を表示します。
ログ
マイグレーションを作成した際のログの確認やダウンロードすることができます。
メモ
設定したメモ情報を表示します。
マイグレーション
テスト用ソースDB、ターゲットDBの情報を表示します。
スケジュール
設定したスケジュール情報を表示します。
SQL数
実行されたSQL数(件)を表示します。
失敗した割合
実行されたSQLのうち、失敗したSQLの割合(%)を表示します。
更新日時
最後に更新された日付を表示します。
作成日時
マイグレーションプロジェクトを作成した日時を表示します。
12.2. AWSマイグレーションの新規作成
-
AWSマイグレーションの一覧画面から[新規作成]をクリックします。
-
AWSマイグレーションの作成では以下の設定を行い、最後にバリデーションを実行してから新規作成します。
-
概要の設定
-
SQLログ取得設定
-
SQL実行先データベース設定
-
アセスメント設定
-
スケジュール設定
-
バリデーションに成功した場合でも、AWSアカウントの状態などにより、処理を開始できない場合があります。 |
新規作成されたAWSマイグレーションは一覧へ追加され、テスト用ソースDBが作成されたのち、実行待ち状態(スケジュールが有効な状態)となります。
設定された処理タイミングになると、ソースDBからのログ取得、評価SQLセットの作成、アセスメントが実行されます。
12.2.1. 概要の設定
AWSマイグレーションの概要情報を設定します。
概要情報は後から変更することができます。
項目 | 説明 |
---|---|
マイグレーション名 |
AWSマイグレーションの設定名を入力します。 |
メモ |
マイグレーションの概要を入力します。 |
12.2.2. SQLログ取得設定
ソースDB(SQL収集元)になるRDSのデータベース情報を設定します。
本番データベースや開発用データベースなど、アプリケーションからSQLが実行され、そのSQL実行がログとして記録されているデータベースを指定します。
項目 | 説明 |
---|---|
使用するAWSプロファイル名 |
使用するAWSプロファイル名を選択します。「デフォルト」を選択した場合、共有AWS認証情報ファイルのdefault設定が存在すればそれを使用します。存在しない場合、IAMロールの設定で認証を試みます。 |
リージョン |
SQL収集元データベースのデータベースインスタンスまたはクラスターがあるリージョンを指定します。 |
インスタンスID/クラスタID |
SQL収集元データベースのインスタンスIDを指定します。 |
データベース名 |
SQL収集元データベースのデータベース名を指定します。 |
SQL収集開始日 |
SQL収集元データベースからSQLを収集する日時を指定します。 |
12.2.3. SQL実行先データベース設定
テスト対象(SQL実行先)になるテスト用ソースDBとターゲットDBを設定します。
以下の2パターンで作成することができます。
12.2.3.1. スナップショットからRDSインスタンス/Auroraクラスタを作成する
あらかじめ手動で作成し用意したスナップショットからテスト用ソースDBやターゲットDBになるRDSインスタンスやAurora DBクラスターを作成するには、以下の設定を行います。
スナップショットからテスト用ソースDBやターゲットDBを作成する場合、AWSマイグレーションの作成直後に、最初にインスタンスの作成が実行されます。
項目 | 説明 |
---|---|
使用するAWSプロファイル名 |
使用するAWSプロファイル名を選択します。「デフォルト」を選択した場合、共有AWS認証情報ファイルのdefault設定が存在すればそれを使用します。存在しない場合、IAMロールの設定で認証を試みます。 |
スナップショットARN |
テスト用ソースDB/ターゲットDBの作成の元となるスナップショットのARNを指定します。 |
インスタンスクラス |
新規作成するテスト用ソースDB/ターゲットDBのインスタンスクラスを指定します。 |
リージョン |
新規作成するテスト用ソースDB/ターゲットDBのリージョンを指定します。 |
セキュリティグループ |
新規作成するテスト用ソースDB/ターゲットDBのセキュリティグループのセキュリティグループIDを指定します。 |
サブネットグループ |
データベースを作成するサブネットグループを指定します。 |
オプショングループ |
新規作成するテスト用ソースDB/ターゲットDBのオプショングループのオプショングループ名を指定します。 |
パラメータグループ |
新規作成するテスト用ソースDB/ターゲットDBのパラメータグループのパラメータグループ名を指定します。 |
アップグレード後のエンジンバージョン |
アップグレードしたターゲットDBを作成する場合、アップグレード後のエンジンバージョンを指定します。 |
アセスメント完了後の自動停止 |
トグルスイッチをオンにすると、アセスメントが完了したタイミングで作成したデータベースを停止します。 |
|
12.2.3.2. 登録してあるターゲットDBを使用する
SQL Testingからテスト用ソースDBを作成せずに、既存のターゲットDBを使用してAWSマイグレーションを行います。
項目 | 説明 |
---|---|
テスト用ソースDB |
テスト用ソースDBとして使用するデータベースを指定します。 |
ターゲットDB |
ターゲットDBとして使用するデータベースを指定します。 |
12.2.4. アセスメント設定
アセスメントを実行する際の設定を行います。
AWSマイグレーションには直列実行のオプションはありません。常に直列実行は「無効」で実行されます。
[行順序の比較][比較対象外カラム]は、SQL Testing 4.1以降で対応しています。
項目の詳細については、「アセスメント」を確認してください。 |
12.2.5. スケジュール設定
SQL情報を取得してアセスメント実行を繰り返し行うためにスケジュール、終了時期の設定を行います。
また、スケジュール設定を行わずに、直後に1回のみ実行することもできます。
項目 | 説明 |
---|---|
スケジュール設定 |
SQLの収集とアセスメント実行スケジュールを指定して定期的に実行する場合は、[スケジュールを設定する]を選択します。 |
マイグレーション実施期間 |
アセスメント実行の終了日を指定します。終了日の23:59までに開始されるスケジュールが実行対象となります。 |
評価SQLセット/アセスメントの実行頻度 |
評価SQLセット作成とアセスメント実行の頻度を[時間ごと]※1または[日ごと]に指定します。 |
※1 [時間ごと]では実行開始タイミングにかかわらず0時を基準としたタイミングで実行します。
また、指定した時間で24時間を割り切れない場合、最後の間隔が指定した時間とは異なります。
-
2時間おき:0,2,4,6, … , 22
-
3時間おき:0,3,6,9, … , 21
-
5時間おき:0,5,10, … , 20(最後の間隔は4時間になります)
12.2.6. 確認
設定内容を確認します。
[バリデーション]ボタンをクリックすると、入力した値が正しいかAWSに接続し確認します。
バリデーションに成功すると、[新規作成]ボタンをクリックできます。クリックすると続けてAWSマイグレーションを作成できます。
12.3. AWSマイグレーションを複製して新規作成
既存のAWSマイグレーション設定をもとに、新たなマイグレーション作成を行います。
既存のものと同様の設定で一部のみを変更してAWSマイグレーションの設定を行いたい場合に便利です。
-
AWSマイグレーションの一覧画面からもとにするAWSマイグレーションにチェックを入れます。
-
画面上部の[複製して新規作成]ボタンをクリックします。
-
マイグレーション情報画面に沿って、設定を変更します。最後の確認画面で[新規作成]ボタンをクリックします。
12.4. AWSマイグレーションの編集
AWSマイグレーションの名前やメモを変更します。
-
AWSマイグレーションの一覧画面から編集したいAWSマイグレーションにチェックを入れます。
-
画面上部の[編集]ボタンをクリックします。
-
必要な値を入力した後、画面下部にある[適用]ボタンをクリックします。
12.5. AWSマイグレーションのスケジュールの変更
AWSマイグレーションをスケジュール実行する場合、終了日付と実行頻度を設定、変更することができます。
[変更後にスケジュール実行を開始します]をオンにして[適用]ボタンをクリックすると、変更したスケジュールの日時でアセスメント実行を開始します。
[変更後にスケジュール実行を開始します]をオフにして[適用]ボタンをクリックすると、スケジュールの日時は変更されますがアセスメント実行はされません。
-
AWSマイグレーションの一覧画面からスケジュールを変更したいAWSマイグレーションにチェックを入れます。
-
画面上部の[スケジュールの変更]ボタンをクリックします。
-
日時を変更後、[変更後にスケジュール実行を開始します]をオンにします。
設定項目は、「スケジュール設定」を参照してください。 -
画面下部にある[適用]ボタンをクリックします。
12.6. AWSマイグレーションの再開
設定されている終了日付が過ぎていないマイグレーションのみ再開します。
-
AWSマイグレーションの一覧画面から再開したいAWSマイグレーションにチェックを入れます。
-
画面上部の[再開]ボタンをクリックします。
-
問題が無ければ、画面下部にある[再開]ボタンをクリックします。
12.7. AWSマイグレーションの中断
スケジュールが有効なAWSマイグレーションのスケジュール実行を無効化します。
中断したもののスケジュールを再度有効化することはできません。
-
AWSマイグレーションの一覧画面から中断したいAWSマイグレーションにチェックを入れます。
-
画面上部の[中断]ボタンをクリックします。
-
問題が無ければ、画面下部にある[中断]ボタンをクリックします。
12.8. AWSマイグレーションの削除
AWSマイグレーションの削除を行います。
対象のAWSマイグレーションから作成されたアセスメントや評価SQLセットを同時に削除しますが、ターゲットDBは削除されません。
[スナップショットからRDSインスタンス/AURORAクラスタを作成する]から作成した「ターゲットDBの削除」をする際、RDSインスタンスが削除可能な場合は削除します。
-
AWSマイグレーションの一覧画面から削除したいAWSマイグレーションにチェックを入れます。
-
画面上部の[削除]ボタンをクリックします。
-
問題が無ければ、画面下部にある[削除]ボタンをクリックします。
12.9. AWSマイグレーション結果の確認
-
スケジュールが実行中、またはスケジュールが終了したAWSマイグレーションに対してマイグレーション名を選択します。
-
マイグレーションの設定情報ならびに、実行済みのアセスメントの一覧が表示されます。
アセスメント結果をCSVファイル形式でダウンロードすることもできます。
サマリー画面右上の[ダウンロード]ボタンをクリックすると、ダウンロード画面を表示します。
取得したい情報を選択して[ダウンロード]ボタンをクリックすると、ZIP圧縮されたファイルのダウンロードを開始します。実行タイプに[実行]を選択した場合実行タイプに[パース]を選択した場合-
実行タイプの詳細については、「アセスメント」を参照してください。
-
ダウンロードの詳細については、「サマリーのダウンロード」を参照してください。
-
-
さらにアセスメント名を選択することで、アセスメントサマリーを表示することができます。
サマリー画面の詳細については、「サマリー」を参照してください。
12.10. AWSマイグレーション実行時のログファイル出力設定について
AWSマイグレーションでログ情報を取得するためには、RDSインスタンスまたはAurora DBクラスターにてログ出力の設定が必要です。
設定方法は、「Amazon RDS上でのログファイル出力設定」を参照してください。 |
13. その他
13.1. ツール連携
失敗したSQLをユニークな形でファイル抽出します。
SQLを自動変換するツールを使用する際などに使用してください。
抽出単位は1SQLにつき1ファイルです。
通常のSQL実行評価までの手順は、以下の5ステップになります。
ツール連携の場合は、続けて次の処理を行います。
-
[失敗したSQLの抽出]失敗したSQLをユニークにし、1SQLにつき1ファイルの単位で抽出する
-
抽出したものを別途ツールに読み込ませ、自動修正等処理を行う
-
修正したSQL1つにつき1つのファイルとして保存する
-
[修正を評価SQLセットに適用]修正したSQLを3で使用した評価SQLセットへマージする
-
再度ターゲットDBへ評価SQLセットを実行
-
実行結果を取得
-
修正したSQLがどれくらい修正できたか確認する
この手順を踏むことで、手動で修正するSQLの数を減らすことができます。
以下、ツール連携にあたりSQL Testingに用意されている機能の詳細です。
13.1.1. 失敗したSQLの抽出
実行したSQLの結果から、失敗したSQLをユニークな形で抽出します。
-
アセスメントのサマリー画面から[SQLの抽出]ボタンをクリックします。
-
「失敗」のステータスのみを選択して、実行に失敗したSQLファイルをダウンロードします。
ダウンロードしたZIPファイル内には、1SQLにつき1ファイルの単位でSQLが保存されています。
SQL自動変換ツールや、手動で修正など、任意の方法でSQLを修正してください。
13.1.2. 修正を評価SQLセットに適用
失敗したSQLの抽出で抽出したSQLを任意の方法で修正した後、評価SQLセットに修正したSQLを適用することで、修正したSQLにて再度アセスメントを実行します。
-
再度アセスメントを実行する評価SQLセットにチェックを入れます。
-
画面上部の[外部連携]ボタンをクリックします。
-
適用するファイルの[ファイルを選択]をクリックして、修正したSQLのCSVファイルを選択します。
-
[適用]ボタンをクリックします。
評価SQLセットの中身が更新されます。
13.2. ソースDB、ターゲットDBの型対応
ソースDBから取得可能なデータは以下のとおりです。
ソースDB | SQL | バインド変数値 | バインド変数型 |
---|---|---|---|
Oracle Database |
〇 |
△ |
△ |
PostgreSQL |
〇 |
〇 |
× |
SQL Server |
〇 |
× |
× |
MySQL |
〇 |
× |
× |
|
ターゲットDBへの実行時に使用可能なデータと機能は以下のとおりです。
ターゲットDB | SQL実行 | バインド変数型指定 | バインド変数型変換エラー推定※1 |
---|---|---|---|
Oracle Database |
〇 |
〇 |
× |
PostgreSQL |
〇 |
〇 |
〇 |
SQL Server |
〇 |
〇 |
〇 |
MySQL |
〇 |
〇 |
× |
Snowflake |
〇 |
〇 |
× |
※1 ターゲットDB実行時、SQL構文に問題が無い場合にバインド変数の暗黙の型変換でエラーになる箇所を推定する機能です。
13.3. ターゲットDB実行時の型指定と入力書式
ターゲットDBへのSQL実行時にSQL Testingのバインド変数型指定に応じてDBMS固有の型を設定します。
SQL Testing Manager Webコンソール上で設定した型の指定と値の入力は、アセスメント作成時のバインド変数補完、およびSQL詳細画面のSQL実行時に行います。
以下の表はターゲットDB実行時の型と入力書式の対応を示します。
型指定 | Oracle Database | PostgreSQL | MySQL | SQL Server | Snowflake※1 | 入力書式 |
---|---|---|---|---|---|---|
デフォルト※2 |
VARCHAR2 |
UNKNOWN |
LONGTEXT |
VARCHAR |
VARCHAR |
|
文字列 |
VARCHAR2 |
TEXTまたはVARCHAR※3 |
LONGTEXT |
VARCHAR |
VARCHAR |
|
固定長文字列 |
CHAR(n) |
CHAR(n) |
CHAR(n) |
CHAR(n) |
VARCHAR |
|
任意精度数値 |
NUMBER |
NUMERIC |
DECIMAL |
DECIMAL |
NUMERIC |
|
整数 |
NUMBER |
BIGINT |
BIGINT |
BIGINT |
NUMERIC |
|
小数 |
NUMBER |
DOUBLE PRECISION |
DOUBLE PRECISION |
FLOAT |
NUMERIC |
|
時刻 |
TIMESTAMP |
TIME |
TIME |
TIME |
VARCHAR |
YYYY/MM/DD HH24:MI:SS または YYYY/MM/DD HH24:MI:SS.FF の形式で、日付部分・時刻部分のみでも入力できます。 |
日付 |
TIMESTAMP |
DATE |
DATE |
DATE |
DATE |
YYYY/MM/DD HH24:MI:SS または YYYY/MM/DD HH24:MI:SS.FF の形式で、日付部分・時刻部分のみでも入力できます。 |
日付時刻 |
TIMESTAMP |
TIMESTAMP WITHOUT TIME ZONE |
DATETIME |
DATETIME2 |
VARCHAR |
YYYY/MM/DD HH24:MI:SS または YYYY/MM/DD HH24:MI:SS.FF の形式で、日付部分・時刻部分のみでも入力できます。 |
真偽値 |
VARCHAR2 |
BOOLEAN |
BOOLEAN |
BIT |
BOOLEAN |
TRUEの場合は「1」、FALSEの場合は「0」を入力します。 |
バイナリ |
RAW |
BYTEA |
LONGBLOB |
VARBINARY |
VARBINARY |
バイトデータを接頭辞(0x、0X)無しの16進数の文字列で入力します。 |
※1 SQL Testing 4.1以降で対応しています。
※2 型指定が無い場合はデフォルトの型指定を使用します。画面によっては「未指定」と表記しています。
※3 環境変数IDT_POSTGRES_TEXT_TYPEによって文字列の型を切り替えできます。デフォルトはVARCHARです。
13.4. 0秒時の対応
ソースDBのSQLの実行時間は、ソースDBの使用しているメモリを参照して取得しています。
そのため、タイミングによっては実行時間が0秒になることがあります。
0秒の場合、ターゲットDBの実行時間と比較することができず、遅くなったSQLのカテゴライズを正しく行うことができません。
遅くなったSQLを適切に算出するため、実行時間が0秒のSQLには、アセスメントを実行する際に入力した[0秒の仮定値]を代入して計算しています。
PISOのデフォルトのサンプリング間隔が0.2秒のため、0秒の仮定値はデフォルトで0.2秒になっています。
サンプリング間隔を変更した場合は、それによって0秒の仮定値を任意の値に変更してください。
13.5. ユニークSQLについて
SQLを一意にするためのハッシュ値(SQL IDもしくはSQLHASH)と、弊社独自で付与しているPI Hashを掛け合わせたものでユニークとしています。
PI Hashの詳細は「PI Hashについて」を参照してください。 |
13.6. PI Hashについて
弊社独自のSQLのハッシュ値を指します。
SQLのリテラルを無視し、同じ構成のSQLに同じハッシュ値を付与します。
13.7. 使用している項目名について
SQL実行結果一覧画面やSQL詳細画面で使用している項目名の詳細です。
項目名 | 説明 | ||
---|---|---|---|
ステータス |
SQLの実行結果のステータス情報を表します。
|
||
PI Hash |
SQLに付与する弊社独自のハッシュ値を表します。
|
||
SQL ID |
SQLを識別するIDを表します。 |
||
DBユーザー |
SQLを実行したDBユーザーを表します。 |
||
プログラム |
ソースDBで取得したSQLを発行したプログラム名を表します。 |
||
オブジェクト |
SQLに含まれるオブジェクト名を表します。 |
||
遅くなった割合(%) |
ソースDBと比較してターゲットDBではSQLの実行時間が何%になったかの値を表します。
|
||
SQLテキスト |
ソースDBから収集したSQLを表します。 |
||
バインド変数名 |
取得したSQL実行時に指定されたバインド変数の変数名を表します。 |
||
SQL開始時刻 |
ソースDBでSQLが実行された時刻を表します。 |
||
ログオン時刻 |
ソースDBでSQLが実行された際のセッションのログオン時刻を表します。 |
||
修正済みSQL |
[SQLの修正]タブで保存された修正後のSQLを表します。 |
||
テスト用ソースDB実行時間(秒) |
テスト用ソースDBへSQLの実行要求をしてから初回のレスポンスが返ってくるまでの時間を表します。 |
||
ターゲットDB実行時間(秒) |
ターゲットDBへSQLの実行要求をしてから初回のレスポンスが返ってくるまでの時間を表します。 |
||
ソースDB実行時間(秒) |
ソースDBのSQLの実行時間を表します。 |
||
テスト用ソースDBエラーコード |
テスト用ソースDBから出力されたエラーコードを表します。 |
||
テスト用ソースDBエラーメッセージ |
テスト用ソースDBから出力されたエラーメッセージを表します。 |
||
ターゲットDBエラーコード |
ターゲットDBから出力されたエラーコードを表します。 |
||
ターゲットDBエラーメッセージ |
ターゲットDBから出力されたエラーメッセージを表します。 |
||
変換済みSQL(テスト用ソースDB) |
アセスメントのオプションにより変換され、実際にテスト用ソースDBへ実行されたSQLを表します。 |
||
変換済みSQL(ターゲットDB) |
アセスメントのオプションにより変換され、実際にターゲットDBへ実行されたSQLを表します。 |
||
変換済みバインド変数名(テスト用ソースDB) |
アセスメントのオプションにより変換され、実際にテスト用ソースDBへ適用されたバインド変数を表します。 |
||
変換済みバインド変数名(ターゲットDB) |
アセスメントのオプションにより変換され、実際にターゲットDBへ適用されたバインド変数を表します。 |
||
テスト用ソースDB取得完了時間(秒) |
テスト用ソースDBへSQLの実行要求をしてからすべての結果をプログラムで取得するまでの時間を表します。 |
||
ターゲットDB取得完了時間(秒) |
ターゲットDBへSQLの実行要求をしてからすべての結果をプログラムで取得するまでの時間を表します。 |
||
テスト用ソースDB取得行数 |
テスト用ソースDBの取得行数を表します。 |
||
ターゲットDB取得行数 |
ターゲットDBの取得行数を表します。 |
||
影響のあった行数(テスト用ソースDB) |
テスト用ソースDBの影響のあった行数を表します。 |
||
影響のあった行数(ターゲットDB) |
ターゲットDBの影響のあった行数を表します。 |
||
セッションID |
ソースDBで取得したセッションIDを表します。 |
||
行比較結果 |
SELECT文の取得結果に対する行比較結果を表します。 |
||
ORDER BY句指定 |
クエリにORDER BY句による指定があるかどうかを表します。 |
||
収集時処理行数 |
PISO Targetで取得した時点のSQLの取得行数または処理行数を表します。 |
||
行取得中断 |
アセスメント実行時、行取得中断の有無を表します。 |
||
修正SQLセット適用(ターゲットDB) |
修正SQLセットが適用されている場合「有り」、適用されていない場合「無し」を表示します。 |
||
修正SQLセット適用(テスト用ソースDB) |
2DBモードで修正SQLセットが適用されている場合「有り」、適用されていない場合「無し」を表示します。 |
||
ログオフ時刻 |
SQLを実行したDBユーザーのログオフ時刻を表します。 |
||
SQL終了時刻 |
SQLの実行終了時刻を表します。 |
||
Action |
アプリケーション上のモジュール・アクション(DBMS_APPLICATION_INFO.SET_MODULE)の情報を表します。 |
||
Action Operation |
アプリケーション上のオペレーション名を表します。 |
||
Action Program |
アプリケーション上のプログラム名を表します。 |
||
Client Information |
アプリケーションサーバー経由のクライアント(DBMS_APPLICATION_INFO.SET_CLIENT_INFO)情報を表します。 |
||
Client Info IP |
アプリケーションサーバー経由のクライアントのIPアドレスを表します。 |
||
Client Info Host |
アプリケーションサーバー経由のクライアントのホスト名を表します。 |
||
Client Info User |
アプリケーションサーバー経由のユーザー名を表します。 |
13.8. CSVファイルのカラムについて
アセスメントの結果をCSVダウンロードした際に使用しているカラム名の詳細です。
項目名 | 説明 | ||
---|---|---|---|
id |
SQL実行結果に割り当てられる連番のIDです。 |
||
result |
ターゲットDBでSQL実行した結果を表します。 |
||
resultCode |
アセスメントによるSQL実行結果に割り当てたコードで、テスト対象SQLの成功・失敗を表します。
|
||
sqlId |
SQLを識別するIDを表します。 |
||
piHash |
SQLに付与する弊社独自のハッシュ値を表します。
|
||
sqlText |
ソースDBから収集したSQLです。 |
||
bind |
バインド変数情報の配列データを以下のようにJSON文字列形式で出力します。 [{"name": "バインド変数名", "type": "バインド変数型", "value": "値"},,,] |
||
errorCode |
データベースから出力されたエラーコードを表します。 |
||
errorMessage |
データベースから出力されたエラーメッセージを表します。 |
||
etimeFetch |
ターゲットDBへSQLの実行要求をしてからすべての結果をプログラムで取得するまでの時間を表します。 |
||
etimeCall |
ターゲットDBへSQLの実行要求をしてから最初に応答が返ってくるまでの時間を表します。 |
||
modifiedSqlText |
アセスメントのオプションにより変換され、実際にターゲットDBへ実行されたSQLを表します。 |
||
modifiedBind |
アセスメントのオプションにより変換され、実際にターゲットDBへ適用されたバインド変数を表します。 |
||
queryAffectedRows |
ターゲットDBの影響のあった行数を表します。 |
||
queryTotal |
ターゲットDBの取得行数を表します。 |
||
queryPlan |
ターゲットDBの実行計画を表します。 ※SQL Testing 4.1以降で対応しています。 |
||
fetchTruncated |
行取得中断の有無を表します。 |
||
patchApplied |
修正SQLセットの適用有無を「TRUE」「FALSE」で表します。 |
||
(source) patchApplied |
2DBモードでの修正SQLセットの適用有無を「TRUE」「FALSE」で表します。 |
||
elapsedTimeRatio |
ソースDBと比較してターゲットDBではSQLの実行時間が何%になったかの値を表します。
|
||
sessionIdentifier |
ソースDBで取得したセッションIDを表します。 |
||
user |
ターゲットDBへSQLを実行したDBユーザーを表します。 |
||
program |
ソースDBで取得したSQLを発行したプログラム名を表します。 |
||
db |
評価SQLセットに登録されているデータベース名を表します。 |
||
host |
評価SQLセットに登録されているホスト名を表します。 |
||
sessionStartTime |
ソースDBへ接続された日時を表します。 |
||
sessionEndTime |
SQLを実行したDBユーザーのログオフ時刻を表します。 |
||
sqlStartTime |
ソースDBで取得したSQLの開始時間を表します。 |
||
sqlStartTimeFraction |
ソースDBで取得したSQL開始時間のマイクロ秒部分を表します。 |
||
object |
SQLに含まれるオブジェクト名を表します。 |
||
rowsProcessed |
PISO Targetで取得した時点のSQLの取得行数または処理行数を表します。 |
||
elapsedTime |
ソースDBでのSQL実行時間を表します。 |
||
patchCreated |
SQLのステータス情報を以下の2種類で表します。 |
||
patchSqlText |
ユーザーが修正したSQLを表します。 |
||
sqlEndTime |
SQLの実行終了時刻を表します。 |
||
action |
アプリケーション上のモジュール・アクション(DBMS_APPLICATION_INFO.SET_MODULE)の情報を表します。 |
||
actionOperation |
アプリケーション上のオペレーション名を表します。 |
||
actionProgram |
アプリケーション上のプログラム名を表します。 |
||
clientInfo |
アプリケーションサーバー経由のクライアント(DBMS_APPLICATION_INFO.SET_CLIENT_INFO)情報を表します。 |
||
clientInfoIp |
アプリケーションサーバー経由のクライアントのIPアドレスを表します。 |
||
clientInfoHost |
アプリケーションサーバー経由のクライアントのホスト名を表します。 |
||
clientInfoUser |
アプリケーションサーバー経由のユーザー名を表します。 |
||
(source) errorCode※1 |
テスト用ソースDBから出力されたエラーコードを表します。 |
||
(source) errorMessage※1 |
テスト用ソースDBから出力されたエラーメッセージを表します。 |
||
(source) etimeFetch※1 |
テスト用ソースDBへSQLの実行要求をしてからすべての結果をプログラムで取得するまでの時間を表します。 |
||
(source) etimeCall※1 |
テスト用ソースDBへSQLの実行要求をしてから最初に応答が返ってくるまでの時間を表します。 |
||
(source) modifiedSqlText※1 |
アセスメントのオプションにより変換され、実際にテスト用ソースDBへ実行されたSQLを表します。 |
||
(source) modifiedBind※1 |
アセスメントのオプションにより変換され、実際にテスト用ソースDBへ適用されたバインド変数を表します。 |
||
(source) queryAffectedRows※1 |
テスト用ソースDBの影響のあった行数を表します。 |
||
(source) queryTotal※1 |
テスト用ソースDBの取得行数を表します。 |
||
(source)queryPlan |
テスト用ソースDBの実行計画を表します。 ※SQL Testing 4.1以降で対応しています。 |
||
rowsMatchedCode※1 |
SELECT文の取得結果に対する行比較結果を表します。 |
||
queryHasOrder※1 |
クエリにORDER BY句による指定があるかどうかを表します。 |
項目名 | 説明 |
---|---|
resultId |
実行結果CSVの「id」に対応する値を表します。 |
rank |
同一のresultIdのSQLに対して発見または適用された順番を表します。 |
applied |
SQLに対して変更を加えたかどうかを示します。 |
type |
分類を表します。 |
action |
typeに対応する詳細説明です。 |
severity |
深刻度を表します。 |
detail |
type、actionに関連する詳細データのJSON文字列を表します。 |
13.9. 評価対象のSQLについて
ソースDBから取得するSQLが評価対象のSQLとなり、評価SQLセットとして登録、アセスメントされます。
SQLの取得方法によって、評価対象となるSQLが異なります。
SQL取得方法 | 説明 |
---|---|
PISO Managerの機能でSQLを取得する |
|
SQL Testingの機能でSQLを取得する
|
|
※ ソースDBがオンプレミスのOracle Databaseである場合、取得できるバインド変数に制限事項があります。
詳細については、「バインド変数について」を参照してください。
13.10. 評価SQLセット生成元のデータファイルについて
13.10.1. マイニングサーチ出力CSV形式
SQL Testing Managerでは、PISO ISMやPISO Managerのマイニングサーチ結果(CSVファイル)を評価SQLセットとして取り込むことができます。また、同様のCSVファイルを用意することで、任意のSQLを評価SQLセットとして取り込みアセスメントを行うことが可能です。
出力されるCSVファイルのカラム名と値の定義は、弊社サポートサイト(Service Portal)の[Insight PISO]>[ナレッジ]から文書番号:000001818(旧文書番号-00369)の「カラム名(PISO 5.x以降)」一覧に従います。
ユニーク化の処理を除いて評価SQLセット格納時点では値を使用しません。
正当性をチェックしないので必要カラムが存在すれば評価SQLセットの作成は完了します。
属性 | 値 |
---|---|
文字コード |
BOM無しUTF-8 |
改行コード |
LFまたはCRLF |
カラム数 |
ヘッダとデータで一致すること |
カラム順 |
順不同 |
カラム名 | カラムの存在が必須 | 備考 | ||
---|---|---|---|---|
Host |
はい ※1 |
PISO Targetで指定したホスト名です。 |
||
Database |
はい※1 |
PISO Targetで指定したインスタンス名です。 |
||
SID |
はい※2、3 |
|||
Serial |
はい※2、3 |
|||
Logged In |
はい※3、4 |
SQLを実行したOracleユーザーのログイン時刻です。 |
||
Logged Out |
いいえ |
SQLを実行したOracleユーザーのログオフ時刻です。 |
||
DB User |
はい※3 |
Oracleユーザー名です。 |
||
SQL Start Time |
はい※4 |
SQLの実行開始時刻です。 |
||
SQL Start Time(Micro Sec) |
はい※4 |
SQLの実行開始時刻(マイクロ秒)です。 |
||
SQL End Time |
いいえ |
SQLの実行終了時刻です。 |
||
SQL Text |
はい |
SQL文です。 |
||
SQL Hash |
いいえ※5、6 |
SQL Textに対応するハッシュ値です。 |
||
PI Hash |
いいえ※5、6 |
SQL Textからリテラルを除いた構造に対応するハッシュ値です。 |
||
Bind Variables |
はい※7 |
バインド変数です。
|
||
Object |
はい |
アクションの対象オブジェクトです。 |
||
Rows Processed |
いいえ |
PISO Targetで取得した時点のSQLの取得行数または処理行数を表します。 |
||
Elapsed Time |
はい |
SQL実行にかかった時間(秒)の実数値です。 |
||
Program |
はい |
実行したプログラム名です。 |
||
Action |
いいえ |
アプリケーション上のモジュール・アクション(DBMS_APPLICATION_INFO.SET_MODULE)の情報です。 |
||
Action - Operation |
いいえ |
アプリケーション上のオペレーション名です。 |
||
Action - Program |
いいえ |
アプリケーション上のプログラム名です。 |
||
Client Information |
いいえ |
アプリケーションサーバー経由のクライアント(DBMS_APPLICATION_INFO.SET_CLIENT_INFO)情報です。 |
||
Client Information - IP Address |
いいえ |
アプリケーションサーバー経由のクライアントのIPアドレスです。 |
||
Client Information - Host |
いいえ |
アプリケーションサーバー経由のクライアントのホスト名です。 |
||
Client Information - User |
いいえ |
アプリケーションサーバー経由のユーザー名です。 |
※1 HostとDatabaseの値を結合して一意のデータベースインスタンスを識別します。
※2 内部的にSIDとSerialの値を結合して扱います。どちらかが空文字列であっても一意性を維持できる場合は処理可能です。
※3 Host、Database、SID、Serial、Logged In、DB Userの値を結合して一意のセッションを識別します。
※4 アセスメント実行はLogged Inの昇順でソートしたセッションごとに行います。
セッションごとにSQL Start Time、SQL Start Time(Micro Sec)の昇順でSQLを実行します。
※5 SQL HashとPI Hashの値を結合して一意のSQL文を認識します。
※6 カラムが存在しない場合は、SQL文のmd5値を使用します。
※7 バインド変数の型情報を付与する場合に必要です。
(3)と記載された場合、バインド変数値を文字列とみたときのバイト数を意味します。
(3,1)と記載された場合、バイト数とデータ型を意味します。
1個目のバインド変数を数値、2個目のバインド変数を文字列扱いとする場合
#1(3,2):123 #2(3,1):123
13.10.1.1. Bind Variablesの書式について
-
バインド変数型の出力が無効になっている場合:
#バインド位置(バイト数):バインド変数値 -
バインド変数型の出力が有効になっている場合:
#バインド位置(データ型,バイト数):バインド変数値
※ バイト数は、バインド変数値を文字列とみたときのバイト数を意味します。
データ型は、バインド変数のデータ型を意味します。
バインド変数値が取得できない場合、バイト数は「?」と表示されます。
NULL値がバインドされた場合、バイト数は「-」と表示されます。
空値がバインドされた場合、バイト数は「0」と表示されます。
バインド変数のデータ型の出力値は、Oracle Databaseでバインド変数型を表すコードとなります。
VARCHAR2, NVARCHAR2 : 1 CHAR, NCHAR : 96 -> SQL Testingでは、文字列として処理。 NUMBER : 2 -> SQL Testingでは、任意精度の数値として処理。 DATE : 12 TIMESTAMP : 180 -> SQL Testingでは、日付時刻として処理。 RAW : 23 -> SQL Testingでは、バイナリとして処理。値は16進数文字列で表す(先頭の0x無し)。
13.10.2. 評価SQLセット用CSVファイルについて
- SQLの評価順
-
-
SQLはセッション単位でまとめて評価されます。
-
セッションは、Host+Database+SID+Serial+Logged In+DB User単位で識別されます。
-
SQLは、セッションのLogged Inの昇順で、かつ、同セッション内のSQLのSQL Start Timeの昇順でソートされます。
そのため、すべてのSQLを順番に処理したい場合は、1SQLごとに、SIDとSerialに0001、0002、0003・・・と設定し、Logged Inも適当に昇順にします。また、SQL Start Timeも評価したい順に並べます。
同セッション内でSQL Start Timeが同じ値である場合は、CSVファイルで上にある方を先に実行します。
-
- 推奨サイズ
-
評価SQLセットに含むSQL本数は1000万件以内にすることを推奨します。
- アセスメント時のDBへのデータ反映
-
-
アセスメント設定時の[DBへのデータ反映]オプションは、セッション単位でコミット/ロールバックされます。
連続したSQLとして評価しても問題ないのであれば、同一セッションでSQLを処理した方が高速に処理できます。 -
1SQLごとにロールバックしたい場合は、すべてのSQLを別セッションにします。
セッション確立のオーバーヘッドがあるため、同一セッションでロールバックする場合に比べて処理が遅くなりますが、アセスメント設定時の[同時セッション処理数]オプションでの並列指定が有効に働きます。
-
- SQLの識別
-
-
SQLは、SQL Hash+PI Hash単位で識別されます。
実際のSQL Textが同じでも、この識別子が異なれば別SQLとして扱われます。 -
修正SQLセットとの紐づけもSQL HashとPI Hashを結合した値で行います。
-
SQL HashとPI Hash値自体は、任意の値を設定します。例えば、SQLごとに、SQL Hashに A、B、C…と設定して、PI Hashに 1、2、3…などと設定してください。
-
アセスメント順は、この値には影響されません。
-
13.11. テスト対象のDBユーザーの権限設定について
13.11.1. テスト対象のDBユーザーに必要な権限設定
2DBモード(テスト用ソースDBとターゲットDBの2つのデータベースを指定して行う)でアセスメントを直列実行で行う場合、MySQLのロック状態を取得するためには特定の権限をDBユーザーに設定する必要があります。
それぞれのバージョンに応じた設定方法は以下のとおりです。
- MariaDB/MySQL 5.7以下の場合
-
下記のSQLを使用し、必要な権限をユーザーに付与します。
GRANT PROCESS ON *.* TO 'ユーザー';
- MySQL 8.0の場合
-
下記のSQLを使用し、必要な権限をユーザーに付与します。
GRANT PROCESS ON *.* TO 'ユーザー'; GRANT SELECT ON sys.* TO 'ユーザー'@'%'; GRANT EXECUTE ON sys.* TO 'ユーザー'@'%'; GRANT SELECT ON performance_schema.* TO 'ユーザー'@'%';
13.11.2. アセスメント実行の前後での権限設定
権限は、データベースに直接設定することも、アセスメントの事前SQL実行で付与し、事後SQL実行でデフォルト値に戻すことも可能です。
13.11.3. SQL実行タイムアウト
ロック解放待ち中にSQLが終了される事象が発生した場合は、アセスメント設定で長いタイムアウト時間を設定することを推奨します。
13.12. システムの使用リソース高騰通知
13.12.1. 機能概要
SQL Testing 4.1から、システムリソースを監視し、特定の基準に達した際にメールで通知する機能が追加されました。
SQL Testing 4.1以降を新規インストールすると追加されます。 SQL Testing 4.0以前からアップグレードした場合、この機能は追加されません。 |
13.12.2. アラート基準
以下の条件に該当する場合にアラートが発生します。特に記載がない場合、1分間状態が継続した場合を指します。
-
ルートボリュームの空き容量が10GB以下
-
ルートボリュームの使用率が90%以上
-
piso-dataボリュームの空き容量が10GB以下
-
piso-dataボリュームの使用率が90%以上
-
RAMの使用量が75%以上の状態が10分間続いた場合
-
RAMの使用量が85%以上
-
node_exporter(メトリクス収集プログラム)が3分間停止した場合
13.12.3. アラート動作詳細
-
メトリクスの収集は15秒毎に行います。
-
同一アラートの再送間隔は1時間です。
-
状態の解消判定は5分間とします。
13.12.4. 通知方法
-
メール(SMTP)で通知を行います。
-
通知先は設定ファイル(/etc/prometheus/alertmanager.yml)で編集できます。
-
デフォルトで用意するSMTP送信先はWebで閲覧可能ですが、対象マシンで保持するとリスクがあるため、送信先の設定を推奨します。
13.12.5. SMTP未設定のメール閲覧方法
-
SSHポートフォワードを使用して、マシンの8025ポートを閲覧します。
-
コマンド :
ssh -L 8025:localhost:8025 {user}@{host}
-
-
Webコンソールのリッスンアドレスをlocalhostから変更し、ファイアウォールで8025ポートを開けることで閲覧可能ですが、認証がないため非推奨です。
13.12.6. SMTP設定方法
-
/etc以下のファイル編集とサービス操作はroot権限で行ってください。
-
/etc/prometheus/alertmanager.ymlを編集します。
- 初期設定例
-
global: smtp_smarthost: 'localhost:1025' # SMTPホスト:ポート smtp_require_tls: false # STARTTLS, SMTPSの場合はtrue smtp_from: 'SQLTesting <alertmanager@example.com>' # 送信元アドレスを記述 smtp_auth_username: 'username_here' # SMTPユーザー smtp_auth_password: 'password_here' # SMTPパスワード
- Amazon SESの設定例
-
global: smtp_smarthost: 'email-smtp.ap-northeast-1.amazonaws.com:587' smtp_require_tls: true smtp_from: 'SQLTesting <your-account@your-domain.example.com>' smtp_auth_username: 'AKIA1234567890ABCDEF' smtp_auth_password: 'ABCDEFGHIJKLMNOPQRSTU1234/ABCDEFGHIJK1234567'
- 受信者設定例
-
receivers: - name: 'email-notice' email_configs: - to: 'root@localhost' # 宛先に変える send_resolved: true headers: subject: '{{ template "__subject" . }}' html: '{{ template "email.html" . }}'
-
動作確認
systemctl stop node_exporter
を実行し、おおよそ3分後にアラートメールが届くことを確認してください。
確認後、必ずsystemctl start node_exporter
で復帰させてください。
14. 制限事項
14.1. バインド変数について
ソースDBによって、取得できるバインド変数には以下のような制限があります。
- オンプレミスのOracle Databaseの制限事項
-
-
WHERE句とHAVING句で使用されるバインド変数のみ取得できます。
-
同じSQLのバインド変数値が変化する場合、キャプチャリング直前のバインド変数値のみ取得できます(バインド変数値のキャプチャリングの間隔に起因しています)。
-
取得可能なバインド変数の数や値は3999バイトまでです。
-
- RDS for PostgreSQL、Aurora(PostgreSQL互換エディション)の制限事項
-
-
PISO Managerの機能でSQLを取得する場合、取得可能なバインド変数の数や値は4000バイトまでです。
-
バインド変数にNULLが指定されている場合、SQL TestingのSQL取得方法によってNULLと空文字の区別の可不可が異なります。
SQL取得方法 PostgreSQLのログ形式 バインド変数のNULLと空文字の区別 PISO Managerの機能でSQLを取得する
SELECTとDML(Insert/Update/Delete)のみが取得可能PostgreSQL監査ログ(pgAudit)
区別できない
SQL Testingの機能でSQLを取得する
評価SQLセットの新規作成でAmazon RDSからSQLを取得、または、AWSマイグレーション機能からSQLを取得PostgreSQL標準ログ(デフォルト)
区別できる
PostgreSQL監査ログ(pgAudit)
区別できない
-
- RDS for MySQL、Aurora(MySQL互換エディション)の制限事項
-
バインド変数は取得できません。
14.2. 1SQLのサイズ上限値
SQL Testing Managerで処理可能な1SQLの最大サイズは10Mバイトです。
それ以上のサイズでは、環境により処理できない可能性があります。
PISO Targetが取得する1SQLのデフォルトサイズは21674バイトです。
このデフォルトサイズは、以下のパラメーターで変更可能です。
-
PISO Target内の設定ファイル
$IST_HOME/usr/${HOSTNAME}/${ORACLE_SID}/etc/sgamond.prm -
パラメータ
MAX_SQLTEXT_LENGTH=21674
サイズの変更後、PISO TargetのSQL Collectorを再起動してください。
PISO Targetを使用せずにAmazon RDSからSQLを取得する場合、1SQLの最大サイズは10Mバイトです。
SQLを表示している画面において、以下のような制限があります。
|
14.3. AWSマイグレーション機能について
取得対象のソースDBに対するSQL実行のセッションがスケジュールの切り替わるタイミングをまたがっている場合、スケジュール切り替わり前から実行されていたセッションによるSQLを評価対象とすることができません。
14.4. Amazon RDSのログ制限
-
PISO Managerを用いない場合に、UTF-8以外の収集元データベースと発行SQLは対応していません。
サーバー側(RDS)の符号化方式をUTF-8以外(EUC-JP、Shift_JIS等)に設定している場合、RDSからログを取得して評価SQLセットを作成することはできません。 -
COPYコマンドの実行は対応していません。
COPY pg_class TO '/pg_class_file'; の場合、パース(構文チェック)は可能です。ただし実行(実際にテーブルをコピーしてファイルに出力)はできません。
評価SQLセットにCOPYコマンドが含まれている場合、アセスメント実行時はCOPYコマンドをスキップします。実行結果はエラーとして扱います。 -
ログ文中に複数のSQLが連結されている場合の実行は対応していません。
下記のようにRDSのログ文中にSQLが連結されている場合には対応していません。2022-12-06 08:36:25 UTC:IP address (Port):insight@insight:[31886]:LOG: statement: select 1; select 2; select 3; select sum_(1,2); select sum_(2,3), sum_(4,5); create TEMP table if not exists hoge (c1 double precision, c2 int); insert into hoge values (sum_(6.0, 7), sum_(8, 9.0::int));
14.5. MySQLから評価SQLセットを作成する場合の制限
- Connectログが存在しないセッションの取り扱い
-
MySQLから評価SQLセットを作成する際、ログファイル中にConnectログが存在するセッションのクエリログが読み取り対象となります。
Connectログが存在しないセッションは評価SQLセットに登録されないため、すべての必要なセッションがログファイルに正しく記録されていることを事前に確認してください。
Connectログは下記形式を想定しています。{timestamp}\t {connection_id} Connect\t{user}@{ip_address} on {database_name} using {protocol}
- Connect移植に関する注意点
-
Amazon RDSでは、複数のスキーマが含まれる1つのクエリログをスキーマ別に分割してSQL Testingに取り込む場合、分割したクエリログそれぞれにデータベースへの接続情報を含む元のconnectをコピー(移植)する必要がありますが、connectをタブを使用して改行している場合、移植したconnectからタブが抜けてしまう可能性があります。
移植したconnectにタブ(\t)が抜けていると、実行DBユーザーが認識されずクエリログが取り込まれません。そのため、connect移植した際にはタブが抜けていないか確認してください。
タブを使用して改行しているconnectのフォーマットは、以下の例を参考にしてください。{timestamp}\t {connection_id} Connect\t{user}@{ip_address} on {database_name} using {protocol}
スキーマ別にログファイルを分割する方法については、弊社サポートサイト(Service Portal)の[Insight SQL Testing]>[ナレッジ]から文書番号:000001995を参照してください。 |
14.6. アセスメントにおいてロック対象SQLの同時実行によるデッドロック
SQL Testingのテスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメント(2DBモード)において、以下の事象が原因で進行が停止する可能性があります。
-
同一のロック対象を持つSQLが異なるセッションとして評価SQLセットに登録されている場合、テスト用ソースDBとターゲットDB間で一方がロックを獲得し他方がロック獲得待ちとなることでデッドロック状態が発生
SQL Testing にはこのデッドロック状態を検知する機能はありません。アセスメントのタイムアウト設定を指定することで回避可能です。
14.7. Snowflakeの制限事項
SQL Testing 4.1以降で対応しています。
Snowflakeでは、直列実行時にロック状態を取得することはできません。
15. AWS上で利用時の留意事項
15.1. 導入作業について
製品の特性上、本製品の導入や利用時には、AWSの利用(IAM、VPC、EC2、EBS、RDSなど)に関する一般的な知識、Oracle Linux、データベース、SQLなどに関する一般的な知識があることを想定しています。
導入ではEC2インスタンスの起動を行います。AWS Marketplaceを通してAMIからEC2を起動可能な権限のあるユーザーで作業を実施してください。以下に導入ユーザーに必要となるIAMポリシー例を記載します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "aws-marketplace:ViewSubscriptions", "aws-marketplace:Subscribe", "aws-marketplace:Unsubscribe" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:Describe*", "ec2:GetConsole*", "ec2:CreateTags" ], "Resource": "*" }, { "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:network-interface/*", "arn:aws:ec2:*:*:instance/*", "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*::image/ami-*", "arn:aws:ec2:*:*:key-pair/*", "arn:aws:ec2:*:*:security-group/*" ] } ] }
また、ディスクの拡張が必要な場合、SSHで接続可能な環境から作業を実施してください。
導入作業をAWSアカウントのルートユーザーで行うことは推奨されていません。導入作業はIAMユーザーで行ってください。 ルートユーザーについては AWSアカウントのルートユーザーを参照してください。 |
|
15.2. 利用可能なリージョンについて
SQL Testing ManagerはAWS上のEC2で起動するため、EC2およびVPCなどが利用可能なリージョンを使用する必要があります。
また、ソースDBやテスト用ソースDBとしてRDSを使用する場合はRDSを利用可能なリージョンである必要があります。SQL Testing ManagerとRDSのリージョンは同じである必要はありません。
15.2.1. RDS / AuroraへのSSL接続について
-
RDS for MySQL / Aurora MySQL / RDS for PostgreSQL / Aurora PostgreSQLからSQLを取得する場合
-
RDS APIへのアクセスはhttps接続となり、通信は暗号化されています。
-
-
RDS for MySQL / Aurora MySQLをテスト用ソースDBとして使用する場合
-
DB(クラスター)へのSSL/TLS接続の要求が要求されている場合(require_secure_transportパラメータがONになっている場合)
SSL/TLSを使用したDBクラスターへの接続の暗号化 から証明書ファイルをダウンロードし、SQL Testing Managerの/home/insight/idt/etcにあるmy.cnfファイルに証明書のパスを以下のように記述します。
/home/insight/idt/etc/ap-northeast-1-bundle.pemというパスでファイルを置いた場合は「ssl-ca=/idt/etc/ap-northeast-1-bundle.pem」の行を追加します。
-
-
RDS for PostgreSQL / Aurora PostgreSQLをテスト用ソースDBとして使用する場合
-
DB(クラスター)へのSSL/TLS接続の要求が要求されている場合(rds.force_sslパラメータが1(オン)の場合)でも、SQL Testing Managerは評価可能です。
ただし、「sslmode=verify-ca」による証明書の検証はサポートしていません。
-
15.3. EC2内に保存されるデータについて
EC2上に構築したSQL Testing Managerは、EC2で使用するストレージ(EBS)上に蓄積されたデータベース内にSQL等のデータを保存しています。
EBSの暗号化については、ユーザーのセキュリティ要件に応じた暗号化などの対策を推奨します。
EBSの暗号化については Amazon EBS暗号化 を参照してください。 |
EBSの暗号化でKMS keyを使用する場合、 AWS KMS keys ローテーション の必要性も確認してください。
15.4. AWS Marketplaceでの提供形式について
SQL Testing Managerはインスタンスごとに課金される時間課金(年間課金)、また、契約期間中の利用にインスタンス数の制限のない月間課金、別途契約の取り決めを行う(BYOL)の複数のパターンで提供されています。
利用形態に応じたパターンを選択し、サブスクライブしてください。
詳細は、以下のAWS Marketplace上の弊社の製品リストを参照してください。BYOLの価格、ライセンス形態についてはサポート契約を締結している販売会社お問い合わせください。
15.5. アプリケーション稼働状況のモニタリングについて
起動したSQL Testing ManagerのEC2インスタンスは、AWSで提供されているEC2のモニタリング機能を利用することで稼働状態のモニタリングが可能です。
Amazon EC2 のモニタリングについては、 Amazon EC2 のモニタリング を参照してください。 |
アプリケーションが稼働しているかについては、SQL Testing Manager Webコンソールからログインを行いサービスにアクセス可能であることを確認してください。
SQL Testing Manager Webコンソールにアクセスできない場合、ec2-userユーザーにてSSHで接続し、以下のコマンドでサービスが正常起動していることを確認します。
[ec2-user@idt ~]$ sudo systemctl status piso-manager [ec2-user@idt ~]$ sudo -u insight sh -c 'XDG_RUNTIME_DIR=/run/user/$(id -u) systemctl --user status idt-manager'
定期的に稼働状況を確認する必要がある場合、SQL Testing ManagerへAPI経由でアクセスして動作を確認することが可能です。
APIの使用方法については、SQL Testing Manager WebコンソールからAPIマニュアルを参照してください。 |
15.6. AWSのサービスを利用したバックアップと復旧について
SQL Testing ManagerはEC2とEBSで動作しており、EBSボリュームと Amazon EC2インスタンスをバックアップすることにより、障害等に備えることが可能です。
事前にバックアップ処理とリストア処理が正しく動作することを確認したうえで本番運用設定を行ってください。
15.6.1. 自動バックアップの設定について
以下の手順で自動バックアップを設定します。
-
Amazon EC2コンソールから[Elastic Block Store]>[ライフサイクルマネージャー]>[ライフサイクルポリシーの作成]を選択します。
-
以下を設定して、ファイルサイクルポリシーを作成します。
-
ポリシータイプ:EBS-backed AMIポリシー
-
これらのタグを持つターゲット:Nameを選択し、EC2インスタンスの名前を選択します。
Nameタグを付与していない場合は、SQL Testing Managerのインスタンスへ名前を設定するなど、対象のインスタンスを識別しやすくすることを推奨します。 -
使用するIAMロールを選択します。通常はデフォルトのロールで問題ありませんが、別のロールを選択することも可能です。
-
ポリシースケジュール(実行頻度、開始時刻、保持数等)を設定します。
-
バックアップ作成の頻度については任意の期間を設定可能ですが、1日に1回程度、バックアップを取得することを推奨します。
-
頻度の設定により、何らかの障害が発生した際にどの程度最新の状態へ戻せるかが決まります。例えば、1日に1回バックアップを取得する場合は、最低でも1日前の状態まで戻すことが可能となります。
-
-
設定例
-
頻度:毎日
-
毎:24時間
-
開始時刻:18:00(UTC)
-
保持タイプ:カウント
-
カウント数:3など
-
-
-
インスタンスの再起動:再起動しない設定の場合、バックアップ取得処理はオンライン(起動状態)のまま実行されますが、SQL Testingが処理中などの状態がバックアップとして保存される場合があります。その場合、リストア後に一度再起動が必要となる場合があります。
-
その他のオプションを必要に応じて設定します。
自動バックアップ処理の設定については、 スナップショットのライフサイクルの自動化を参照してください。 -
ポリシーの作成を実行すると、定期的なバックアップの作成が有効となります。
-
バックアップは定期的な設定以外にも、手動で実行することも可能です。
大規模な変更などを行った場合には、手動でバックアップを行うことも検討してください。
15.6.2. バックアップからの復旧
ライフサイクルマネージャーでの設定により、EC2インスタンスはAMIとしてバックアップされます。
バックアップされたAMIには、インスタンスの起動に必要な情報と元のEC2インスタンスにアタッチされた各EBSボリュームのスナップショットが含まれています。
バックアップから復旧されるのに要する時間については、AMIからのEC2インスタンス起動の処理となるため、新規導入作業時に要する時間と同じです。
Amazonマシンイメージ(AMI)については、以下のAWSのドキュメントを確認してください。 Amazon マシンイメージ (AMI) |
-
Amazon EC2コンソールから[イメージ]>[AMI]を選択します。ライフサイクルマネージャーから作成されたAMIには、
dlm:managed
というタグが付与されています。 -
インスタンスタイプを選択します。
インスタンスタイプは、AWS Marketplaceから導入時に許可されているインスタンスタイプのみ選択することが可能です。許可されていないインスタンスタイプを選択するとエラーとなります。 -
以降のインスタンス起動の設定は、導入時のインスタンス起動手順と同じです。
|
15.7. AWSのサービスの障害からの復旧
15.7.1. AWSのサービスの障害時の影響について
SQL Testing ManagerはEC2とEBSで動作しています。また、内部のサービスはインスタンス起動時に自動起動されます。
何らかの理由でSQL Testing ManagerのEC2インスタンスが稼働していない場合、ソースDBから送られるSQL情報を収集・蓄積することができません。
一定期間ソースDB内で保持されていますが、あらかじめ設定された保持可能容量を超えた場合にはその間のログを収集することができなくなります。
SQL Testing ManagerでのSQL蓄積実行中に、AWSのサービス障害等でSQL Testing ManagerのEC2インスタンスが停止した場合には、以降の手順でSQL Testing Managerを復旧してください。
15.7.2. EC2インスタンスまたはアプリケーションの障害時の復旧
何らかの原因で、EC2インスタンスが終了してしまっている、もしくはアプリケーションの障害によりログインできない、などの場合はEC2インスタンスを再起動することでアプリケーションを再起動できます。
-
EC2インスタンスの一覧より対象のEC2インスタンスを選択し、右クリックで表示されるメニューから、[EC2インスタンスの開始]もしくは[EC2インスタンスの再起動]を選択してください。
-
EC2インスタンスが起動後、SQL Testing Manager Webコンソールへアクセスしてログイン可能であることを確認してください。
15.7.3. 現在のEC2をそのまま起動させることができない障害時の復旧
起動中のEC2が存在するAZに障害が発生するなど、現在のEC2インスタンスをそのまま起動させることができない障害が発生している場合、取得済みのバックアップから別AZでインスタンスを起動することでアプリケーションを稼働させることが可能です。
「バックアップからの復旧」 の手順に従い、正常なAZでバックアップ取得したAMIからEC2インスタンスを起動してください。