本マニュアルに記載された情報は、予告なしに変更される場合があります。株式会社インサイトテクノロジーは、本マニュアルに関していかなる種類の保証（商用性および特定の目的への適合性の黙示の保証を含みますが、これに限定されません）もいたしません。
株式会社インサイトテクノロジーは、本マニュアルに含まれた誤謬に関しての責任や、本マニュアルの提供、履行および使用に関して偶発的または間接的に起こる損害に対して、責任を負わないものとします。

本マニュアルのいかなる部分も、株式会社インサイトテクノロジーからの文書による事前の許可なしには、形態または手段を問わず決して複製・配布してはなりません。
Insight SQL Testing、PISOは株式会社インサイトテクノロジーの商標または登録商標です。

その他の社名および製品名は、一般に各社の商標または登録商標です。なお、本文中には™、^®マークは明記しておりません。

Insight SQL Testing（以下、SQL Testingと表記）は、今までソースDB（移行元データベース）上で使用していたSQLを、ターゲットDB（移行先データベース）上で実際に使用できるかを検証します。
ソースDBでのSQLの取得は、株式会社インサイトテクノロジー独自のDMA機能を使うため、低負荷で網羅的に取得できます。取得したSQLは簡単にターゲットDBへ実行できます。
弊社製品PISOを使用しているお客様は、PISOで取得したSQLを使用できます。
ターゲットDBでのSQLの実行結果はビジュアライズされ、実行できないSQLの傾向や、性能が劣化したSQLが分かります。
また、SQL Testing上でSQLを書き換えて検証・保存することもできます。

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を使用しません。

すべてのSQL Testing Managerの基準値は以下の前提条件から算出されています。

上記ハードウェア基準値をもとに以下のSQL Testing Manager 1台ごとの稼働上限値を設けています。

SQL Testingで対応するデータベースの種類とSQL取得の対応と、バージョンについて説明します。

ソースDBのSQL取得方法は「PISO Managerの機能でSQLを取得」「SQL Testing Managerの機能でSQLを取得」があります。

^※詳細については、下の表を参照してください。

^※1 SQL Testing 4.1以降で対応しています。

^※2 本製品の動作確認は23cでのみ実施していますが、互換性のある23aiも同等にターゲットDBとして使用することができます。

^※3 互換製品を含みます。PostgreSQLの互換製品には、Amazon Aurora（PostgreSQL互換エディション）、EDB Postgres Advanced Server、FUJITSU Software Enterprise Postgresを含みます。

^※4 互換製品を含みます。SQL Serverの互換製品には、Azure SQL Database、Azure SQL Managed Instanceを含みます。

^※5 記載のないバージョンに関してもリリースノートに記載されているDriverバージョンで対応しているバージョンに関しては基本動作することを想定しています。ただし、何か問題が発生した場合はベストエフォートでの対応となります。

^※6 互換製品を含みます。MySQLの互換製品には、Amazon Aurora（MySQL互換エディション）、MariaDB 10.1以上を含みます。

^※7 SQL Testing 4.1以降で対応しています。
Snowflakeをターゲットにしたアセスメントにおいて、評価SQLセット作成元のDB種は不問です。

^※8 AWSマイグレーション機能を使用してアセスメントできます。

^※9 PISO Managerが対応するデータベースと同様です。
詳細は、弊社サポートサイト（Service Portal）から［Insight PISO］＞［製品ダウンロード］で製品検索し、表示される関連ファイル一覧から対応表を参照してください。

^※10 SQL Testing 4.4以降で対応しています。

ブラウザは、以下のものを使用してください。それ以外のブラウザでは、画面が正しく表示されない場合があります。

SQL Testing Managerが仮想マシン（VM）提供の場合、既定のインストールディレクトリは/home/insight/idt/（以下、<IDT_HOME>と表記）です。

製品サポートについては、契約しているサポート窓口までにお問い合わせください。

また、その他のサポートの提供に関する詳細、製品バージョンごとのサポートレベルについては、製品サポート、Insight SQL Testing 製品サポートレベルを確認してください。

SQL TestingをEC2上に構築した場合のシステム構成図を示します。以下の構成図は、移行元データベースをオンプレミス上に構築した場合を想定しています。
なお、移行元データベースをAWS上にも構築することができます。

EC2上でSQL Testingを使用するには、AWS Marketplaceの中から利用形態に応じて製品を選択し、［Continue to Subscribe］ボタンをクリックしてください。

Azure VM上でSQL Testingを使用するには、Azure Marketplaceから、［今すぐ入手する］ボタンをクリックしてください。

SQL Testingのアップグレード手順は、現在使用しているバージョンによって異なります。
また、SQL Testing 4.0以降ではLLMによる推論を用いた機能追加があります。そのため、LLMによる推論をローカルで行うか、外部で行うか（SQL Testing本体のみのアップグレード）によって手順が異なります。

PISO ManagerまたはSQL Testingの機能を使用して、SQL収集元であるソースDBに蓄積したSQLを収集し、出力を行います。

以下の手順は、SQL Testing Manager Webコンソールhttp://<SQL Testing ManagerのIPアドレス>:7777/idt/から実行します。
本手順はSQLの評価までの基本的な手順を記載しています。

ソースDBから取得したSQLをターゲットDBへ実行する前に、ターゲットDBのデータベースの種類に応じて、以下の設定を行います。

Amazon RDSをソースDBとして、ログ情報を取得して評価SQLセットを作成するためには、RDSインスタンスまたはAurora DBクラスターにてログファイル出力の設定が必要です。

SQL Testingで直接Amazon RDSのログを取得して評価SQLセットを作成する場合、AWSマイグレーション機能を使用する場合に設定してください。

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インスタンスへアタッチしてください。

※ xxxxxxxxxxxxはAWSアカウントID、ap-northeast-1はリージョンに置き換えてください。

※Amazon Bedrockで用意されている推論プロファイルを使用する場合、ポリシーDのActionに"bedrock:ListInferenceProfiles"を追加してください。
※SQL Testing 4.4以降では、エラー分析機能で一部モデルを除き、ストリーミング対応するようになったため、ポリシーDのActionに"bedrock:InvokeModelWithResponseStream"の追加が必須になります。

SQL TestingからソースDBの評価SQLセットを作成する前に、ソースDBからSQLを取得する必要があります。
ここでは、PISO Managerの機能でSQLを取得して、SQL Testing Managerに受け渡し、評価SQLセットを作成するまでの操作を説明します。

PISO Manager Webコンソールへアクセスして、以下のいずれかの方法でSQLを取得してください。

SQL Testing Manager Webコンソールにログインするユーザーアカウントには、「管理者ユーザー」と「一般ユーザー」があります。

管理者ユーザーではユーザー管理とライセンス管理のみを行い、一般ユーザーではSQL Testing Managerの各設定と処理の実行および確認を行います。

管理者ユーザーでログインすると管理者画面が表示されます。
管理者画面では管理者ユーザーのパスワード変更と、一般ユーザーの作成、削除、パスワードのリセット等のユーザー設定の変更、ライセンスパスワードの設定と確認を行うことができます。

一般ユーザーでログインするとSQL Testing Managerの操作画面が表示されます。
評価SQLセット、アセスメントなどのSQL Testing Managerの各設定とユーザー自身のパスワード変更を行うことができます。

SQL Testing Webコンソールにログインして表示されるトップ画面について説明します。
以下、一般ユーザーでログインした場合を例に説明します。

評価するSQLの集まりである「評価SQLセット」を作成します。

以下はソースDBに対する評価SQLセット作成方法の対応表です。

※SQL Testing 4.1以降で対応したSnowflakeはソースDBとして利用できないため、評価SQLセットの作成はできません。

評価SQLセットの作成が開始されると、評価SQLセットの行頭のアイコンで進行状況を確認できます。
作成が完了すると、ステータスが完了アイコンになります。
SQL Testing 4.1以降は、完了時の状態によりステータスアイコンが変わります。
正常終了すると緑色［］、ログにwarningまたはerrorレベルの内容が出力されていると、オレンジ色［］になります。

評価SQLセットの作成はデータ量に応じて数分から数十分かかります。

評価SQLセットを作成した後、評価SQLセットの中のSQLの詳細を確認します。
評価SQLセットのSQLをターゲットDBへアセスメントする前に、作業量の確認等のために使用してください。

複数の評価SQLセットを結合して1つの評価SQLセットを作成します。

評価SQLセットの一覧に情報が追加され、完了アイコンになると完了です。
評価SQLセットを作成中は作成中アイコンになります。完了まで時間がかかる場合があります。

評価SQLセットの一覧の表示が変更になると、編集の完了です。

一覧に評価SQLセットのコピーが追加になり、ステータスが完了アイコンになるとコピーの完了です。
評価SQLセットのコピーはデータ量に応じて数分から数十分かかります。

評価SQLセットに格納されているDBユーザー名を変更します。
ソースDBとターゲットDBでDBユーザー名が異なる際に使用してください。

一覧のステータスが完了アイコンになると変更の完了です。
評価SQLセットの変更はデータ量に応じて数分から数十分かかります。

評価SQLに対して、修正したSQLをアップロードして適用します。

選択した評価SQLセットをPISO Managerのマイニングサーチ形式のCSVファイル（ZIP圧縮）でエクスポートします。

一覧から、該当の評価SQLセット名がなくなると削除の完了です。
評価SQLセットの削除はデータ量に応じて数分かかる場合があります。

ログのアイコンをクリックすると、評価SQLセットを作成した際のログを確認することができます。
また、利用可能なログはダウンロードできます。

ターゲットDBの一覧に情報が追加されると完了です。
ターゲットDBが追加されるまで時間がかかる場合があります。

すでに追加したターゲットDBの情報を変更します。また、ターゲットDBと接続確認もできます。

ターゲットDBの一覧に表示されている情報が変更されると完了です。
ターゲットDBの変更が完了するまで時間がかかる場合があります。

ターゲットDBを削除します。
この操作はSQL Testing内の情報のみを削除します。接続先のデータベースに影響はありません。

一覧から、該当のターゲットDBがなくなると削除の完了です。
ターゲットDBの削除は数分かかる場合があります。 AWSマイグレーションから作成されたターゲットDB（SQL Testingから作成されたRDSが紐づくターゲットDB）の場合、ターゲットDB削除時に削除可能なRDSインスタンス（Aurora DBクラスター）があれば同時に削除します。

既存のアセスメント設定をもとに、新たなアセスメントを行います。

アセスメントの名前とメモを編集します。

一覧から、該当のアセスメント名が編集されていたら編集の完了です。

処理中のアセスメントを中断します。

一覧で、処理中のアセスメントが終了状態になると中断の完了です。
終了したアセスメントとして、アセスメントサマリーなどを確認することができます。

アセスメントを削除します。

一覧から、該当のアセスメント名がなくなると削除の完了です。
アセスメントの削除はデータ量に応じて数分かかる場合があります。

アセスメント結果をエクスポートします。
複数を選択した場合は複数個別にエクスポートされます。

ログアイコンをクリックすると、アセスメントを実行した際のログを確認することができます。
また、利用可能なログはダウンロードできます。

サマリーの画面から実行したSQLの実行結果を確認します。

アセスメントの一覧からアセスメント名を選択することで、サマリーの画面へ遷移し、アセスメントのサマリーを閲覧します。
1つのターゲットDBでのみ行うアセスメントと、テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントとでサマリー画面の表示形式が異なります。

エラーメッセージ、エラーユーザー、エラープログラムの件数が10件を超える場合には、［全体表示］ボタンをクリックして他のエラー内容を確認します。

サマリー画面の左のページメニュー、または各ステータスや［エラーメッセージ］［エラーユーザー］などでグルーピングされた一覧のリンクをクリックしてSQL実行結果一覧画面へ移動できます。
また、右のサイドバーを開くと、アセスメント実行時の設定情報を確認できます。