Insight SQL Testing 4

マニュアル

2024年10月31日(第3版)

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の評価までの基本的な手順のみを記載しています
  • 参照先は、以下のように示します。

    詳細については、インストールマニュアルを参照してください。
  • コマンドボックスは、コマンドライン上の入力または表示内容を示します。
    ex

    istctl upistcmon
    istctl startall
  • インラインブロックはInsight SQL TestingやLinuxのコマンドを示します。
    ex istctlに追加コマンドがあります。

  • 文中の 太字 はファイルやディレクトリを示します。
    ex ファイルは /mnt/piso-data/idt-data/sct 配下に出力されます。

  • < > は、使用する環境によって表記が異なることを示します。
    ex
    「 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へ実行し、実行結果を取得・分析することができます。

構成図
1つのターゲットDBでのみ行うアセスメント

また、ソースDBと同様のテスト環境をテスト用ソースDBとして別途用意して、テスト用ソースDBとターゲットDBの2つのデータベースに同じSQLを実行してSQL実行結果や時間、実行性能を比較することができます。

2DB構成図
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメント

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を蓄積、SQLを実行するマネージャーサーバーです。

評価SQLセット

ターゲットDBへ実行するフォーマットに変更したSQLのデータセットです。

アセスメント

評価SQLセットをターゲットDBへ実行すること。または実行結果のデータセットです。

修正SQLセット

評価SQLセットの一部のSQLに対し、修正を適用してアセスメントを実行するSQLのデータセットです。
アセスメントに対して修正保存したSQL、または評価SQLセットに対してツール連携で適用可能な、ZIPファイルまたはCSVファイルから作成できます。

PI Hash

SQLに付与する弊社独自のハッシュ値です。
SQLのリテラルやコメントを無視し、同じ構成のSQLに同じハッシュ値を付与します。
アセスメント時にSQLの重複を排除する際に使用します。

PISO

弊社が開発しているデータベースアクティビティモニタリングツールです。
アクセス情報を取得する機能があり、SQL Testingではそれを流用しています。

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 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.1.5. アンインストール手順について

仮想マシンの削除を行います。

VMwareのドキュメントを参照してください。

4.2. SQL Testing Managerの構築と設定(EC2の場合)

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

EC2上で構築した場合の一般的な構成図

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

IDT-Manager(BYOL)
「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取得の経路イメージです。

aws network

また、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セットの作成方法」項目を参照してください。

※5 詳細は、「登録してあるターゲットDBを使用する」を参照してください。

※6 詳細は、ターゲットDBの追加の「スナップショットからRDSインスタンス/Auroraクラスタを作成する」項目を参照してください。

4.2.1.1. エンドポイントの作成
  1. AWSマネジメントコンソール画面でVPCサービスを選択し、[エンドポイント]>[エンドポイントを作成]ボタンをクリックします。

  2. 名前を設定し、サービスカテゴリに[AWSのサービス]を選択します。

  3. サービスから接続先のAWSサービスを選択します。例えば、「rds」と検索して該当するものを選択してください。

  4. VPCからエンドポイントを作成するVPCを選択します。

  5. プライベートDNSを有効にします。[追加設定]から[DNS名を有効化]をオンにします。

    プライベートDNSを有効にしないと、デフォルトのDNSホスト名を使用してプライベートリンクを実行することができません。
    [DNSホスト名][DNS解決]を有効にすることで、プライベートDNSが有効化されます。
  6. サブネットからインターフェイスエンドポイントを使用するVPCのサブネットを選択します。

  7. セキュリティグループを選択します。アウトバウンドにHTTPS(443)が許可されたセキュリティグループを設定してください。

  8. ポリシーは[フルアクセス]を選択し、[エンドポイントを作成]ボタンをクリックしてください。

  • AWSマイグレーションでスナップショットからRDSインスタンス/Aurora DBクラスターを作成する場合は、手順3.で「sts」「ec2」で検索し、エンドポイントを追加で作成してください。
    登録済みのターゲットDBを使用する場合は手順3.で「sts」のみ追加で作成してください。

  • エンドポイント作成後、VPCの[詳細]タブから[DNSホスト名][DNS解決]が有効であれば、プライベートDNSが有効になっていることを確認できます。

4.2.1.2. ネットワークの接続確認
  • ネットワーク接続については、以下のcurl -vコマンドを実行してRDSやSTSなどへの応答を確認してください。

    icon ex RDSのデフォルトのホスト名の場合(東京リージョン)

    $ curl -v https://rds.ap-northeast-1.amazonaws.com

    icon ex STSのデフォルトのホスト名の場合(東京リージョン)

    $ curl -v https://sts.ap-northeast-1.amazonaws.com

4.2.2. EC2上でのSQL Testing Managerの起動

以下の手順に従い、EC2インスタンスを起動します。

  1. AWS MarketplaceからSQL Testing ManagerのAmazonマシンイメージ(AMI)を選択します。

  2. サブスクライブの利用規約を確認し、AMI、ソフトウェアバージョン、リージョンを選択します。

  3. インスタンス起動方法(アクション)に[Launch through EC2]を選択し、[Launch]をクリックします。
    EC2コンソールの「インスタンスを起動」画面に遷移します。

  4. インスタンスの名前とタグを入力します。

  5. インスタンスタイプは、vCPU 4以上、メモリ8GB以上(m5.xlarge推奨)を選択します。

  6. セキュリティグループは、SSH(22)に加え、HTTP(7777)を許可します。

    • PISO Targetは、PISO Managerのポート番号7777に対してデータを送信します(既定の動作)。

    • ポート番号7777は、SQL Testing Manager Webコンソールへのアクセスにも利用されます。

    • Apache HTTP Serverで使用するポート番号は、1023番以下には設定できません。

      ポート番号の変更については、PISO Managerインストールマニュアルの「ポート番号を変更する」を参照してください。
  7. ストレージ(データ領域)は、監視対象データベース1インスタンス(1か月)あたり50GB程度のストレージを必要としますが、利用状況により大きく異なります。
    ストレージで使用するEBSボリュームタイプはgp3を推奨します。
    データサイズについて不明な場合、EC2起動時にはデータ領域に50GB、バックアップ領域に10GB程度で設定し、利用状況に応じてストレージサイズの変更を検討してください。

    詳細はPISO Managerインストールマニュアルの「蓄積データ領域について」を参照してください。(/dev/sdb:データ領域、/dev/sdc:バックアップ領域、/dev/sdd:PostgreSQLのWALログ領域)
  8. 概要の設定項目を確認した上で、[インスタンスを起動]ボタンをクリックして起動します。

    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ロールを使う場合の手順
  1. 対象の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:::バケット名/*"
        ]
    }
  2. 設定後にSQL Testing Managerを終了します。

    istctl downidt
  3. SQL Testingの設定ファイル<IDT_HOME>/config/config.ymlに接続設定を加えます。

    data:
      /* 既存設定に以下を追加 */
      IDT_STORAGE_BUCKET: バケット名
      IDT_STORAGE_REGION: バケットリージョン
  4. SQL Testing Managerを開始します。

    istctl upidt
  5. 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)とのリソースの競合を解消することができます。

  • Amazon Aurora(PostgreSQL互換エディション)の利用料が発生します。

  • ネットワーク帯域が十分に確保されていない場合、パフォーマンスの低下やタイムアウトエラーなどが発生する可能性があります。

  • EC2インスタンス(SQL Testing Manager)と移行先のAmazon Aurora(PostgreSQL互換エディション)の通信には、双方のセキュリティグループに通信を許可するための設定が必要です。
    Amazon Auroraのユーザーガイドに従って、各セキュリティグループに下記の設定が含まれている必要があります。

    • Amazon Aurora(PostgreSQL互換エディション)に関連付けられたセキュリティグループに、EC2インスタンス(SQL Testing Manager)のVPCセキュリティグループをソースとするインバウンドルールが存在する。

    • EC2インスタンス(SQL Testing Manager)に関連付けられたセキュリティグループに、Amazon Aurora(PostgreSQL互換エディション)のVPCセキュリティグループをソースとするアウトバウンドルールが存在する。

  • アセスメント実行時に実行されるSQLのSELECT文によって取得されるデータの保存場所は、引き続きディスク上の/mnt/piso-data/idt-data(IDT_DATA_HOME)ディレクトリです。

  • ファイルアップロードを通じて評価SQLセットや修正SQLセットを作成する際には、アップロードされたファイルがディスク上の一時領域に保存されるため、処理中に一定量のストレージを消費します。この点も移行前後で変わりません。

  • 移行が完了するまでの間はSQL Testingを使用することはできません。

  • 移行後はSQL Testing Managerサーバーを起動する前にAmazon Aurora(PostgreSQL互換エディション)の起動が完了している必要があります。

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からのデータベースダンプ・移行先へリストア
  1. EC2インスタンス(SQL Testing Manager)にec2-userユーザーでログインします。

  2. OSのSQL Testing用ユーザー(通常、insight)へ変更します。

    sudo su - insight
  3. idt-appを停止します。

    podman stop idt-app
  4. 下記コマンドを実行し、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>"
  5. 移行が完了したらSQL Testing Managerを停止します。

    istctl downidt
  6. <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
  7. <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
  8. 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から、[今すぐ入手する]ボタンをクリックしてください。

Azure-marketplace

4.3.1. Azure VM上でのSQL Testing Managerの起動

以下の手順に従い、Azure VMを作成して起動します。

  1. Azure MarketplaceからSQL TestingのVMイメージを選択して起動します。

  2. VMサイズは、vCPU 4以上、メモリ8GB以上(D4s v4以上推奨)を選択します。

  3. ストレージは、監視対象データベース1インスタンス(1か月)あたり50GB程度のストレージを必要としますが、利用状況により大きく異なります。

    詳細はPISO Managerインストールマニュアルの「蓄積データ領域について」を参照してください。(/dev/sdb:データ領域、/dev/sdc:バックアップ領域、/dev/sdd:PostgreSQLのWALログ領域)
  4. ネットワークセキュリティグループは、SSH(22)に加え、HTTP(7777)を許可します。

    • PISO Targetは、PISO Managerのポート番号7777に対してデータを送信します(既定の動作)。

    • ポート番号7777は、SQL Testing Manager Webコンソールへのアクセスにも利用されます。

      ポート番号の変更については、PISO Managerインストールマニュアルの「ポート番号を変更する」を参照してください。
  5. [詳細]タブの[カスタムデータとcloud-init]のカスタムデータに以下を追加してください。

    #cloud-config
    swap:
      filename: /swapfile
      size: 4G
      maxsize: 4G
  6. Azure VMが起動したら、起動時に指定したユーザーにてSSHで接続することができます。

4.3.2. SQL Testing Managerの設定とインストール

Azure VMではインスタンス起動時にディスクサイズを変更することができないため、以下の手順に従います。

  1. インスタンス起動中の場合、Azure VMを終了します。

  2. Azure PortalのAzure VM画面にて、ディスクを選択し、対象のディスクのサイズを変更します。

  3. Azure VMを起動します。

  4. 以下のコマンドを実行しディスクサイズを拡張します。

    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本体のみのアップグレード)によって手順が異なります。

  • SQL Testing 4.0にアップグレードを行う場合、Insight DT 3.2以前に作成したアセスメントのSQL実行によるSELECT文などの取得結果は削除されるため、閲覧できません。

  • アップグレード時は、ディスクの空き容量に注意してください。ルート領域の空き容量を40GB以上確保することを推奨します。

  • SQL Testingを4.1以前からアップグレード、かつIAMロールにポリシーDを設定済みの場合、ポリシーを本マニュアルの記載に合わせてください。

4.4.1. 現在使用しているSQL Testingが3.0以前の場合

使用中のSQL Testingが3.0以前のバージョンの場合、モジュールの更新によるアップグレードはできません。
新規バージョンのSQL Testingを利用するには、以下の手順に従い実施してください。

  1. 使用中のSQL Testingで、評価SQLセットに使用したCSVファイルを、PISO Manager Webコンソールのマイニングサーチの画面からダウンロードします。

  2. 使用中のSQL Testingでの設定内容を記録して別途保存します。
    (作成済みユーザー情報、アセスメント設定、評価SQLセット設定、ターゲットDBの情報など)

  3. 使用中のSQL Testingを停止し、新規バージョンのSQL Testingを起動します。

  4. 使用中のSQL TestingでダウンロードしたCSVファイルは、新規バージョンのSQL Testingで評価SQLセット作成時にも引き続き使用可能です。

  5. 使用中の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で本体のみアップグレードする場合(ローカルで推論を行わない場合)

  1. 弊社サポートサイト(Service Portal)にログインし、SQL Testingのアップグレードインストール用パッケージ(SQL-Testing-Manager-XXXX-upgrade.tar.gz)を入手してください。

  2. パッケージを展開すると、以下のようなファイル構成になります。

    • sql_testing_vXXXX.tar.gz

    • upgrade.sh

  3. upgrade.shファイルとsql_testing_vXXXX.tar.gzファイルを仮想マシンのinsightユーザーのホームに配置します。

  4. 各仮想マシンのコンソールにログインし、OSのSQL Testing用ユーザー(通常、insight)でログインします。

  5. upgrade.shsql_testing_vXXXX.tar.gzファイルの所有者をinsightユーザーに変更します。

  6. upgrade.shファイルに実行権限を付与します。

    $ chmod +x upgrade.sh
  7. upgrade.shファイルを実行し、アップグレードを完了させます。

    $ ./upgrade.sh sql_testing_vXXXX.tar.gz 2>&1 | tee -a upgrade.log

4.4.4. SQL Testing 4.0以降で本体とLLMをアップグレードする場合(ローカルで推論を行う場合)

  1. 弊社サポートサイトにログインし、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

  2. これらのファイルを仮想マシンのInsightユーザーのホームディレクトリへ配置します。

  3. 各仮想マシンのコンソールにログインし、OSのSQL Testing用ユーザー(通常、insight)でログインします。

  4. upgrade.shsql_testing_vXXXX.tar.gzmodel_vxxxx.tar.gzファイルの所有者をinsightユーザーに変更します。

  5. upgrade.shファイルに実行権限を付与します。

    $ chmod +x upgrade.sh
  6. 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
  7. コンテナを再起動します。

    $ istctl downidt upidt
4.4.4.1. LLMのみ更新する場合
  1. 弊社サポートサイトにログインし、LLMのアップグレード用パッケージ(model-x.x.x.x-upgrade.tar.gz)を入手してください。
    パッケージを展開すると、以下のファイル構成になります。

    • upgrade.sh

    • model_vxxxx.tar.gz

  2. これらのファイルを仮想マシンのInsightユーザーのホームディレクトリへ配置します。

  3. 各仮想マシンのコンソールにログインし、OSのInsight DT用ユーザー(通常、insight)でログインします。

  4. ファイルの所有者をinsightユーザーに変更し、upgrade.shファイルに実行権限を付与します。

    $ chmod +x upgrade.sh
  5. 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

icon ex マイグレーションが発生する場合のログ

== 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=======

icon ex マイグレーションが発生しない場合のログ

[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)」を参照してください。
  1. PISO Manager Webコンソールの[設定管理]>[PISO Manager設定]>[外部サーバー接続]>[新規作成]ボタンをクリックします。

  2. 外部サーバー接続設定画面から以下のように設定して、接続情報を設定します。

    PISO-MGR_外部サーバー接続
    設定項目 設定内容

    外部サーバー接続識別子

    任意の文字列を入力します。

    接続タイプ

    [SQL Testing連携]を選択します。

    IPアドレスとポート番号

    SQL Testing Managerとの同梱環境では「127.0.0.1」「7778」を設定します。

    ユーザー名とパスワード

    SQL Testing Managerの一般ユーザーアカウントを入力します。

    HTTPS

    HTTPSを使って通信を行う場合には、チェックボックスにチェックを入れてください。

    サーバー証明書検証

    サーバー証明書の検証が必要な場合は、チェックボックスにチェックを入れてください。

    SQL Testing 4.2以降で対応しています。SQL Testing 4.1以前からアップグレードした場合、この機能は追加されません。

  3. [保存]ボタンをクリックします。

  4. [データ検索]>[マイニングサーチ]>[ジョブ実行条件指定]タブから、マイニングサーチのジョブ実行条件を設定します。

    PISO-MGR_MSジョブ実行
    設定項目 設定内容

    出力形式

    [外部サーバー接続]を選択します。

    外部サーバー接続識別子※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以前からアップグレードした場合、この機能は追加されません。

  5. 画面上部の[SUBMIT]ボタンをクリックします。
    マイニングサーチジョブの実行が成功すると、SQL Testing Manager Webコンソールに評価SQLセットが自動作成されます。

  6. 続いて、評価SQLセットが作成されていることを確認します。「PISO Managerの機能でSQLを取得した場合」に進みます。

  • PISO Manager Webコンソール上ではジョブが終了していてもSQL Testing Manager Webコンソール上では処理中の場合があります。

  • マイニングサーチ結果のCSVファイルは、PISO Manager Webコンソールからダウンロードしてバックアップできます。

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マネジメントコンソールから、以下の設定を行います。

  1. AWS上のネットワーク要件を確認します。
    SQL Testing Managerがインターネットに接続できない閉ざされたサブネット(Private subnet)に所属している場合、エンドポイントを作成する必要があります。

  2. 必要なIAMロールを設定します。
    Amazon RDSからログを取得して評価SQLセットの作成を行う場合に必要なIAMポリシーを作成し、SQL Testingを構築したEC2にIAMロールを付与してください。
    詳細は、必要なIAM設定についてを参照してください。

  3. RDSインスタンスまたはAurora DBクラスターにログファイルの出力を設定します。
    詳細は、以下を参照してください。

  4. 続いて、評価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を取得した場合
  1. 左のページメニューから[評価SQLセット]をクリックします。

  2. 「蓄積したSQLの出力」により、評価SQLセット一覧に以下の名前で評価SQLセットが自動作成されていることを確認します。
    評価SQLセット名:<マイニングサーチ名>_<YYYY-MM-DD HH24:MI:SS>

  3. 評価SQLセット名とデータベースは評価SQLセット画面から必要に応じて修正します。

  4. 続いて、ターゲットDBの設定を行います。

5.2.1.2. SQL Testingの機能でSQLを取得する場合
  1. 左のページメニューから[評価SQLセット]をクリックします。

    評価SQLセット
  2. [新規作成]ボタンをクリックし、[評価SQLセット作成方法]に[Amazon RDSから作成]を選択します。

    評価SQLセット_新規作成_画面2
  3. ソースDBの情報を入力して、[新規作成]ボタンをクリックします。

    設定項目 設定内容

    評価SQLセット名

    任意の評価SQLセットの名前を入力します。大文字、小文字を区別します。

    使用するAWSプロファイル名

    AWS認証に使用するAWSプロファイル名に「デフォルト」を選択します。

    リージョン

    東京リージョンの場合、ap-northeast-1と入力します。

    インスタンスID/クラスターID

    ソースDBのインスタンスID、またはクラスターIDを入力します。

    データベース名

    ソースDBのデータベース名を入力します。

  4. 作成した評価SQLセットが一覧に表示されます。ステータスが完了アイコン[完了アイコン]になると完了です。

  5. 続いて、ターゲットDBの設定を行います。

5.2.2. ターゲットDBの設定

  1. 左のページメニューから[ターゲットDB]をクリックします。

  2. ターゲットDBの一覧画面から[新規作成]ボタンをクリックします。

  3. [既存のDBを登録する]を選択します。

  4. 以下の必要項目を設定した後、[新規作成]ボタンをクリックします。

    ターゲット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の評価)

  1. 左のページメニューから[アセスメント]をクリックします。

  2. アセスメントの一覧画面から[新規作成]ボタンをクリックします。

  3. 以下の必要項目を設定した後、[新規作成]ボタンをクリックします。

    アセスメント_新規作成_画面
    設定項目 設定内容

    アセスメント名

    評価結果として保存される任意の名前を入力します。

    評価SQLセット名

    作成した評価SQLセットを選択します。

    実行タイプ

    [実行]または[パース]を選択します。

    バインド変数書式変換

    必要に応じて「有効」に設定します。

    DBへのデータ反映

    「指定なし」を選択します。

    タイムアウト設定

    指定しません。データベースの設定でタイムアウト設定がされていればそれに従います。

    同時セッション処理数

    評価SQLセットをターゲットDBで実行する際に同時に処理するセッション数に「1」を設定します。

    0秒の仮定値

    0.2などの数値を設定します。

    期間(セッション)

    必要に応じて期間を設定します。

    ターゲットDB

    作成したターゲットDBを選択します。

    DBユーザー設定

    フィルタリングしたい実行DBユーザーをチェックし、パスワードを指定します。
    ターゲットDBに接続できるかテストする場合、[テスト接続]ボタンをクリックします。

  • アセスメント時に、SQL取得元環境に対するテスト環境を別途用意し、2つのデータベースに対してSQLを実行して比較するアセスメントを行うことができます。詳細は、「アセスメント」を参照してください。

  • Amazon RDSやAmazon Auroraを対象とした継続アセスメントを実行する場合には、「AWSマイグレーション」を参照してください。

5.2.4. 結果の確認

  1. 左のページメニューから[アセスメント]をクリックします。

  2. 一覧からアセスメント名を選択すると結果のサマリーを確認できます。

    サマリー
  3. 実行結果の詳細は、左のページメニューの[SQL実行結果一覧]をクリックします。

    SQL実行結果一覧
  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を編集する作業を省くことができます。

  • 簡易接続ネーミング・メソッド

    ホスト:ポート/サービス名

    icon ex db-host:1521/ORCL

  • Oracle Net Serviceのキーワード値ペア

    (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=ホスト) (PORT=ポート))(CONNECT_DATA=(SERVICE_NAME=サービス名)))

    icon ex

    (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ファンクションを使用する場合
  1. 必要なビューへの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以降は中断処理の権限が不要になったため、この手順は必要ありません。

  1. V$SESSIONのSELECTとセッション切断に必要な権限を付与します。 これは任意の設定あり、アセスメントのタイムアウト設定によって対処できます。

    オンプレミス
    GRANT SELECT ON SYS.V_$SESSION TO ユーザー
    GRANT ALTER SYSTEM TO ユーザー
    Amazon RDS
    GRANT 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で使用するイベントが有効であるかを確認します。
それぞれの項目で不足がある場合は有効化手順に従って設定を行います。

有効化確認
  1. performance_schemaの確認
    以下のクエリの結果がValue=Onならばperformance_schemaが有効です。

    > SHOW VARIABLES LIKE 'performance_schema';
    +--------------------+-------+
    | Variable_name      | Value |
    +--------------------+-------+
    | performance_schema | ON    |
    +--------------------+-------+
  2. 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   |
    +-----------------------+---------+-------+
  3. 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     |
    +---------------------------+---------+
  4. setup_actorsの確認
    評価対象のHOST、USER、ROLEに対してsetup_actorsのENABLEDとHISTORYの両方が「YES」であることを確認します。

    「%」はすべてが対象であることを示しています。

    > use performance_schema;
    > select * from setup_actors;
    +------+------+------+---------+---------+
    | HOST | USER | ROLE | ENABLED | HISTORY |
    +------+------+------+---------+---------+
    | %    | %    | %    | YES     | YES     |
    +------+------+------+---------+---------+
  5. 接続ユーザーの権限の確認

    SQL Testingから接続するユーザーにperformance_schemaへのSELECT権限が付与されているかを確認します。

    下記の「権限が適切に付与されている場合」のような結果であれば問題ありません。

    SQL Testingから使用するDBアカウントで操作

    > use performance_schema;

    ex 権限が適切に付与されている場合

    > select count(*) from setup_instruments;
    +----------+
    | count(*) |
    +----------+
    |     1210 |
    +----------+

    ex 権限が不足している場合

    > select count(*) from setup_instruments;
    ERROR 1142 (42000): SELECT command denied to user 'ユーザー名'@'localhost' for table 'setup_instruments'
有効化手順
  1. 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

    クラウドサービスの場合

    各サービスのドキュメントを参照してください。

  2. setup_actorsの設定
    setup_actorsに計測対象を加えます。

    > use performance_schema;

    すべてを計測対象にする場合

    > insert into setup_actors values ('%','%','%','YES');

    特定のユーザーのみを対象にする場合

    > insert into setup_actors values ('%','対象にするユーザー','%','YES');
  3. 接続ユーザー権限の設定
    以下のクエリで接続ユーザーへ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=データベース;

    icon ex 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=ウェアハウス;

    icon ex 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互換エディション)での標準ログの出力を有効にします。

  1. 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)形式をデフォルトで変換に使用するためには、以下のように設定を切り替えます。

  1. SQL Testingにec2-userユーザーにてSSH接続してログインします。

  2. SQL Testingの設定ファイル<IDT_HOME>/config/config.ymlにログ形式の設定を追加します。

    data:
      /* 既存設定に以下を追加 */
      IDT_POSTGRES_LOG_FORMAT: pgaudit
  3. SQL Testingを再起動します。

続いて、対象データベースのRDS for PostgreSQL、Amazon Aurora(PostgreSQL互換エディション)での監査ログ(pgAudit)の出力を有効にします。

  1. 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)を指定してください。)

  2. インスタンスを再起動します。

  3. 初めてインスタンスを起動する場合は、データベースにログインし、以下のSQLを実行します。

    [PostgreSQL]
    CREATE ROLE rds_pgaudit;
    CREATE EXTENSION pgaudit;

6.2.2. RDS for MySQL、Amazon Aurora(MySQL互換エディション)

対象のデータベースが RDS for MySQL、Amazon Aurora(MySQL互換エディション)の場合、以下の手順で一般ログの出力とファイル出力を有効にします。

  1. RDSコンソールを開き、DBパラメータグループ(Aurora DBクラスターではDBクラスターパラメータグループ)で以下を設定します。

    • general_logをon(1)に設定します。

    • log_outputをFILEに設定します。

  • ログ出力を有効にすると、高スループットのデータベースでパフォーマンスに影響する可能性があります。
    実際のパフォーマンスへの影響は、対象データベースで実行されているワークロードの特性や量に大きく依存するため、事前に影響を確認してください。

  • RDS for MySQLとAmazon Aurora(MySQL互換エディション)の一般ログファイルは、以下の保持期間を過ぎると削除されます。

    RDS for MySQL

    2週間後、またはストレージ領域の2%を超えたら、古いログからログファイルを削除します。

    Amazon Aurora(MySQL互換エディション)

    24時間後、またはストレージ領域の15%を超えたら、古いログからログファイルを削除します。

    AWSマイグレーションによるログファイルの取得が実施される前にログファイルが削除された場合、SQL Testingによるアセスメント処理が行われません。
    そのため、ログファイルがすぐに削除されない設定となっていることを確認し、AWSマイグレーションを実施してください。

  • 詳細は以下を参照してください。

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マイグレーション機能

登録してあるターゲットDBを使用

SQL Testing ManagerのLLMでAmazon Bedrockを使用

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

ポリシーA
{
    "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:*"
            ]
        }
    ]
}
ポリシーB
{
    "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:*"
            ]
        }
    ]
}
ポリシーC
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CloudWatchLogsPermissions",
            "Effect": "Allow",
            "Action": [
                "logs:FilterLogEvents",
                "logs:DescribeLogGroups"
            ],
            "Resource": "arn:aws:logs:*:xxxxxxxxxxxx:log-group:*"
        }
    ]
}
ポリシーD
{
    "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を取得してください。

6.4.1. PISO Managerで蓄積したSQLをCSVファイルに出力して受け渡す(方法1)

  1. ブラウザからPISO Manager Webコンソールへ接続します。

  2. [データ検索]>[マイニングサーチ]をクリックします。

  3. [ジョブ実行条件指定]タブから以下のように設定して、蓄積したSQLをCSVファイルへ出力します。

    ja piso manager ms setting
    設定項目 設定内容

    ジョブ名

    マイニングサーチのジョブ名を入力します。

    最大実行時間

    マイニングサーチが実行可能な最大時間幅(分)を入力します。

    最大取得行数

    マイニングサーチで取得する行数を入力します。

    出力形式

    [標準(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

    • 圧縮形式:圧縮なし

    圧縮形式

  4. [SQL監視]タブを選択した状態にします。

    条件オプションの詳細については、PISO Manager Webコンソール右上のhelp btnアイコンからPISO Managerの設定マニュアルを開き、「[ジョブ実行条件指定]タブ」を参照してください。
  5. 画面上部の[SUBMIT]ボタンをクリックします。

  6. マイニングサーチが実行され、[終了ジョブ一覧]にMS_JOB名.csvという名前でマイニングサーチ結果が作成されます。

    ja piso manager ms completed
  7. 出力したCSVファイルをアップロードして、SQL Testing Manager Webコンソールから評価SQLセットを作成してください。

    詳細は、「評価SQLセットの作成」を参照してください。

6.4.2. PISO ManagerとSQL Testing Managerを接続して蓄積したSQLを転送する(方法2)

  1. ブラウザからPISO Manager Webコンソールへ接続します。

  2. [設定管理]>[PISO Manager設定]>[外部サーバー接続]>[新規作成]ボタンをクリックします。

  3. 外部サーバー接続設定画面から以下のように設定して、接続情報を設定します。

    PISO-MGR_外部サーバー接続
    設定項目 設定内容

    外部サーバー接続識別子

    任意の文字列を入力します。

    接続タイプ

    接続する外部サーバーのタイプを選択します。
    ここでは、[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以前からアップグレードした場合、この機能は追加されません。

  4. [保存]ボタンをクリックします。

  5. [データ検索]>[マイニングサーチ]>[ジョブ実行条件指定]タブから、マイニングサーチのジョブ実行条件を設定します。

    PISO-MGR_MSジョブ実行
    設定項目 設定内容

    ジョブ名

    マイニングサーチのジョブ名を入力します。

    最大実行時間

    マイニングサーチが実行可能な最大時間幅(分)を入力します。

    最大取得行数

    マイニングサーチで取得する行数を入力します。

    出力形式

    [標準(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以前からアップグレードした場合、この機能は追加されません。

  6. 画面上部の[SUBMIT]ボタンをクリックします。

  7. ジョブ実行が成功すると、SQL Testing Manager Webコンソールの評価SQLセット一覧に以下の名前で評価SQLセットが作成されます。
    評価SQLセット名:「<マイニングサーチ名>_<YYYY-MM-DD HH24:MI:SS>」)

    評価SQLセット_結果
  8. 評価SQLセット名とデータベースは評価SQLセット画面から必要に応じて修正します。

    詳細は、「評価SQLセットの編集」を参照してください。
  • PISO Manager Webコンソール上ではジョブが終了していてもSQL Testing Manager Webコンソール上では処理中の場合があります。

  • マイニングサーチ結果のCSVファイルは、PISO Manager Webコンソールからダウンロードしてバックアップできます。

7. SQL Testing Manager Webコンソール

7.1. SQL Testing Manager Webコンソールへログイン

  1. ブラウザからSQL Testing Manager Webコンソールへ接続します。
    以下のURLへアクセスしてください。

    http://<SQL Testing ManagerのIPアドレス>:7777/idt/

  2. 初回ログインの場合には、管理者ユーザーのユーザー名「administrator」と初期パスワードを入力し、[ログイン]をクリックします。
    管理者ユーザーの初期パスワードは、オンプレミスの場合は「insight」、EC2の場合は、EC2インスタンスID、Azure VMの場合はVM名です。
    すでに一般ユーザーを作成済みの場合は、一般ユーザーのユーザー名とパスワードを入力し、[ログイン]をクリックします。

    ログイン画面
  • ライセンスパスワードを設定しないと一般ユーザーでログインすることはできません(時間課金でAWS Marketplaceからサブスクライブした場合を除く)。ライセンスパスワード設定については、「ライセンス管理」を参照してください。

  • 一般ユーザーの作成方法については、「一般ユーザーの新規作成」を参照してください。

  • パスワード変更については、「アカウント管理」を参照してください。

7.2. ユーザーアカウント

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

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

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

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

7.2.1. 管理者ユーザー

管理者ユーザーでログインすると、管理者画面の左メニューにユーザー管理とライセンス管理が表示されます。

7.2.1.1. ユーザー管理

一般ユーザーの新規作成、削除、パスワードのリセットを行います。

一般ユーザーの新規作成
  1. SQL Testing Manager Webコンソールに管理者ユーザーでログインします。
    ユーザー名は「administrator」、初期パスワードは、オンプレミスの場合は「insight」、EC2の場合は、EC2インスタンスID、Azure VMの場合はVM名です。
    ユーザー一覧が表示されます。

    一般ユーザー
    項目 説明

    ユーザー名

    管理者ユーザーと一般ユーザー名を表示します。

    ロール

    管理者ユーザーは「admin」、一般ユーザーは「normal」と表示します。

    許可するAWSプロファイル名

    一般ユーザーに許可するAWSプロファイル名を表示します。

    操作

    • リセットアイコンicon pass resetをクリックすると、ユーザーの既存のパスワードをリセットし、ランダムな文字列でパスワードを自動生成します。

    • ごみ箱アイコンicon binをクリックすると、該当するユーザーを削除します。

    • 雲+鍵アイコンicon cloudkeyをクリックすると、許可するAWSプロファイル名を更新できます。

      aws profile name

  2. 画面上部の[新規作成]ボタンをクリックします。

  3. ユーザー名とパスワードを設定します。許可するAWSプロファイル名は、最低1件以上選択する必要があります。
    [保存]ボタンをクリックします。

    ユーザー名は255文字以内、パスワードは6文字以上で設定してください。
    管理者_一般ユーザー作成
  4. ユーザー一覧に新規の一般ユーザーが追加されます。

一般ユーザーのパスワード変更については、「アカウント管理」を参照してください。
7.2.1.2. システムログのダウンロード

SQL Testing Managerのシステムのログをダウンロードできます。
SQL Testing Managerの動作について弊社で調査が必要な場合に、ログファイルの送付を依頼する場合があります。
その場合にログファイルをダウンロードし、サポート担当まで共有してください。

  1. SQL Testing Manager Webコンソールに管理者ユーザーでログインします。

  2. [ログ]の[ログをダウンロードする]ボタンをクリックします。

    ログ
  3. ダウンロードされたログファイル(ZIP)を指定された方法でサポート担当へ共有します。

7.2.1.3. ライセンス管理

SQL Testing Managerを使用するにはライセンスパスワードの設定が必要です(時間課金でAWS Marketplaceからサブスクライブした場合を除く)。
ライセンスパスワードの入手方法については販売代理店または販売元にお問合せください。
また、一般ユーザーでのログインは、ライセンスパスワードを設定してからログインできます。

  1. SQL Testing Manager Webコンソールに管理者ユーザーでログインします。

  2. [ライセンス管理]の[ライセンス更新]ボタンをクリックします。

    管理者_ライセンス管理
  3. 入手したライセンスパスワードを入力して[保存]ボタンをクリックします。

    管理者_ライセンス更新
  4. ライセンス認証が正しく行われると、ライセンスが設定された旨のメッセージが表示され、ログイン画面に戻ります。

  5. 管理者ユーザーでログインし、[ライセンス管理]を選択すると、設定したライセンスパスワード情報を確認できます。

    管理者_ライセンス確認
    項目 説明

    ライセンスパスワード

    登録されているライセンスパスワード(16文字)の下4文字を表示します。

    トライアル

    登録されているライセンスパスワードが、正式版のときは「No」、トライアルのときは「Yes」を表示します。

    ホスト

    ライセンスパスワードが発行されたホストIDです。 無指定の場合は「NONE」を表示します。トライアルの場合は存在しません。

    有効期限

    ライセンスの有効期限(終了日)です。無期限の場合は「NEVER」を表示します。

    プロダクト名

    ライセンスされているプロダクト名です。

    状態

    パスワードが使用可能であれば「Valid」を表示します。

トライアルのライセンスパスワードを2回続けて設定することはできません。
7.2.1.4. 管理者ユーザーのパスワードのリセット

何らかの理由で管理者ユーザーとしてログインできなくなってしまった場合、管理者ユーザー「administrator」のパスワードをリセットすることが可能です。

  1. OSのSQL Testing用ユーザー(通常はinsight)で仮想マシンにログインします。

  2. XXXXXXに設定したいパスワードを指定して、以下のコマンドを実行します。

    idtctl reset-admin-password XXXXXX
7.2.1.5. LLM

LLMを用いて推論を行うための設定をします。
設定したLLMを用いて、アセスメント実行後のSQL詳細画面で失敗したSQLの分析機能を使用することができます。

llm1

[利用可能モデルの設定変更]ボタンをクリックして使用するLLMを選択します。
使用可能なモデルは、[GPT4All]または[Amazon Bedrock]です。
[設定なし]の場合、失敗したSQLの分析機能は使えません。

llm2
Amazon Bedrockを使用する場合

SQL Testing 4.2以降では、Amazon Bedrockを使用する場合、複数のモデルの中から任意のモデルを選択できます(SQL Testing 4.1以前の場合は、Claude v2.1を使用)。
この機能を利用するためには、利用するモデルがアクセス可能な状態である必要があります。

モデルにアクセス可能な状態でない場合、以下の手順で利用可能な状態に設定してください。手順は、モデルがClaudeの場合を示します。

  • Amazon Bedrockを使用する場合、オンデマンドによる課金が発生します。

  • 本マニュアルに記載されている手順は、公開時点でのAWSマネジメントコンソールおよびAmazon Bedrockの操作方法に基づいています。AWSマネジメントコンソールは継続的に改善されているため、この手順の文言やUI/レイアウトが実際の画面と異なる可能性があります。最新のマネジメントコンソールの案内に従ってください。

  1. AWS マネジメントコンソールにログインし、Amazon Bedrockのコンソールを開きます。

  2. 左側のナビゲーションペインから[モデルアクセス]を選択します。

  3. [モデルアクセスを管理]をクリックします。

  4. [Anthropic]の[Claude]を選択し[モデルアクセスの要求]をクリックします。

  5. モデルアクセスが承認されるまで数分かかる場合があります。

(SQL Testing 4.1以前の場合)

「IDT_BEDROCK_REGION」を設定後、SQL Testing Managerを再起動してください。
SQL Testingの設定ファイル$IDT_HOME/config/config.ymlのdataセクションに下記を追加します。

IDT_BEDROCK_REGION: BEDROCKリージョン
(SQL Testing 4.2以降の場合)Amazon Bedrockの利用可能なモデルを変更する

$IDT_HOME/config/config.llm.yml のAWS_DEFAULT_REGIONに任意のリージョンを記述することで、別リージョンのAmazon Bedrockを使用することができます。
デフォルトはap-northeast-1です。
指定したリージョンにおいて、使用するAWSアカウントで利用可能なモデルがエラー分析画面の選択欄に表示されます。

7.2.2. 一般ユーザー

一般ユーザーでログインすると、SQL Testing Managerの操作画面が表示されます。

user top page

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コンソールに接続するにあたってログイン用のパスワードが必要です。
ログインしているユーザーアカウントのパスワードを変更できます。

ユーザーの初期パスワードは、変更することを推奨します。
  1. SQL Testing Manager Webコンソールのログイン画面から、パスワードを変更する一般ユーザーでログインします。

  2. 画面右上の[<一般ユーザー名>]のメニューから、[アカウント管理]をクリックします。

    アカウント管理
  3. 以下の項目を入力して、画面下部の[保存]ボタンをクリックします。

    アカウント管理_保存
    項目名 説明

    現在のパスワード

    現在のパスワードを入力します。

    新しいパスワード

    新しく設定するパスワードを入力します(6文字以上)。

    パスワード(確認用)

    確認用パスワードです。
    上記パスワードと同じパスワードを入力します。

  4. パスワード変更が成功した場合には、自動でログアウトしてログイン画面に変ります。

以上でパスワードの変更が完了しました。
次回SQL Testing Manager Webコンソールにログインする時から、今回設定したパスワードを使用します。

管理者ユーザーによるパスワードのリセットについては、ユーザー管理の「操作」項目を参照してください。

7.3.3. バージョン情報

使用しているSQL Testing Managerのバージョンを確認できます。

  1. 画面右上の[<一般ユーザー名>]のメニューから、[バージョン情報]をクリックします。

  2. バージョンの情報が表示されます。

    バージョン情報_表示

7.3.4. マニュアル

本マニュアルを表示します。

  1. 画面右上の[<一般ユーザー名>]のメニューから、[マニュアル]をクリックします。

7.3.5. APIドキュメント

SQL Testingでは、REST API(Representational State Transfer API)を用意しています。

  1. 画面右上の[<一般ユーザー名>]のメニューから、[APIドキュメント]をクリックします。
    APIドキュメントが表示されます。

7.3.6. 画面の更新

画面を最新の情報に更新します。

  1. [▼]をクリックして、画面の更新間隔を選択します。
    プルダウンメニューから任意の秒数を指定してください。
    画面を自動で更新させたくないときは[停止]を選択してください。

    画面の更新

7.3.7. フィルタ

ターゲットDB、修正SQLセット、評価SQLセット、アセスメント、AWSマイグレーションの一覧画面では、フィルタ機能を使用して一覧の絞り込み検索(フィルタリング)ができます。

フィルタに使用できる属性は以下のとおりです。

  • 名前

  • メモ

  • 更新日時

  • 作成日時

検索文字(値)に使用できるフィルタ条件は以下のとおりです。

フィルタ条件 説明

と一致

入力された値と属性の値が完全に一致するデータを絞り込みます。大文字小文字を区別します。
この条件は「名前」「メモ」属性に適用されます。
例えば、「名前が『sample』と一致」というフィルタは、名前が「sample」と一致するデータのみを表示します。

を含む

属性の値が入力された値を部分的に含むデータを絞り込みます。大文字小文字は区別されません。
この条件は「名前」「メモ」属性に適用されます。
例えば、「メモが『test』を含む」というフィルタは、メモの中に「test」が部分文字列として存在するすべてのデータを表示します。

より前

入力された値よりも前の日時を持つデータを絞り込みます。
この条件は「更新日時」「作成日時」属性に適用されます。指定された日時は含まれません。
例えば、『更新日時が『2023-07-11 17:46:00』より前』というフィルタは、更新日時が「2023-07-11 17:46:00」よりも前のすべてのデータを表示します。

より後

入力された値と同じ、またはそれよりも後の日時を持つデータを絞り込みます。
この条件は「更新日時」と「作成日時」属性に適用されます。
例えば、「作成日時が『2023-07-11 17:46:00』より後」というフィルタは、作成日時が「2023-07-11 17:46:00」と同じ、またはそれよりも後のすべてのデータを表示します。

  1. フィルタ入力欄に文字を入力するとフィルタの候補が表示されます。
    属性が検索文字「と一致」「を含む」「より前」「より後」の候補から選択します。

    navi filter2
  2. 入力欄のカレンダーアイコンicon calendarをクリックすると、入力フォームから日付時間を入力できます。

    navi filter3
  3. 日付時間が入力された入力欄をクリックすると、フィルタの候補が表示されます。

    navi filter4
  4. 更新日時、作成日時によるフィルタは、入力欄に以下の形式の文字列を入力することで表示されます。
    YYYY-MM-DD HH:MM:SS形式

  5. 表示されたフィルタの候補を選択することでフィルタが適用されます。

  6. 適用中のフィルタは入力欄右にチップとして表示されます。
    チップの[×]ボタンをクリックすると適用を解除できます。
    チップ([×]ボタン以外)をクリックすると値が入力欄に戻り、適用されているフィルタは解除されます。
    各属性に対して一度に適用できるフィルタは1つです。適用中のフィルタはフィルタの候補に表示されなくなります。

    navi filter

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
      icon ex 2024-01-01 12:00:00 UTC

      MySQL 5.6以前

      ミリ秒

      YYMMDD hh:mm:ss
      icon ex 240101 12:00:00

      MySQL 5.7以降

      マイクロ秒

      YYYY-MM-DDThh:mm:ss.uuuuuuZ
      icon ex 2024-01-01T12:00:00.000000Z

  • Amazon RDSから作成
    RDS for MySQL / PostgreSQLおよびAurora MySQL / PostgreSQLに対応しています。Amazon RDS上でのログファイル出力設定が必要です。

  • Amazon CloudWatch Logsから作成
    Amazon RDS上でのログファイル出力設定に準拠しているログがCloudWatch Logsにある場合に利用可能です。

  1. SQL Testing Manager Webコンソールの左のページメニューから[評価SQLセット]をクリックします。

    評価SQLセット一覧画面が表示されます。

    評価SQLセット
  2. 評価SQLセット一覧画面で[新規作成]ボタンをクリックします。

  3. 評価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セットの作成はデータ量に応じて数分から数十分かかります。

ope tds results

8.2. 評価SQLセットのSQL詳細

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

  1. 評価SQLセットの一覧画面から詳細情報を確認する評価SQLセット名を選択します。

    評価SQLセット_選択
  2. サマリー画面が表示されます。

    • SQL詳細情報の一覧作成に成功した場合には、作成オプション、サマリー、SQL情報を表示します。

      評価SQLセット_詳細_成功

      SQLテキストの下向き矢印icon arrowをクリックすると、SQL全文を確認することができます。

      評価SQLセット_詳細_成功
    • SQL詳細情報の一覧作成に失敗した場合には、作成オプション、エラーメッセージを表示します。

      評価SQLセット_詳細_失敗
項目の詳細については、「使用している項目名について」を参照してください。

8.3. 評価SQLセットの結合

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

  1. 評価SQLセットの一覧画面から結合する評価SQLセットにチェックを入れます。

    評価SQLセットの結合
  2. 画面上部の[結合]ボタンをクリックします。

  3. 新たに生成する評価SQLセット名を入力し、結合するSQLセットの順番をドラッグアンドドロップで並べ替えます。
    画面下部にある[結合]をクリックします。

    結合の名前
    項目名 説明

    評価SQLセット名

    新たに生成する評価SQLセットの名前を入力します。既存の評価SQLセット名と異なる名前にしてください。
    大文字、小文字を区別します。

    メモ

    修正SQLセットについてのメモを入力します。

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

評価SQLセットの一覧で、結合によって作成された評価SQLセットの[データソース]項目には結合元の評価SQLセット名が表示されます。
(通常、一覧の[データソース]には元となったCSVファイルやRDS、ログファイルの名称が表示されます。)

8.4. 評価SQLセットの編集

  1. 評価SQLセットの一覧画面から編集する評価SQLセットにチェックを入れます。

  2. 画面上部の[編集]ボタンをクリックします。

    評価SQLセット_チェック
  3. 必要な値を入力した後、画面下部にある[保存]ボタンをクリックします。

    評価SQLセット_編集_画面
    項目名 説明

    評価SQLセット名

    変更する評価SQLセット名を入力します。

    データベース

    変更するデータベースの種類を選択します。
    CSVファイルを選択して評価SQLセットを作成した場合は、データベースを変更できます。
    Amazon RDSからSQLを取得して評価SQLセットを作成した場合は、データベースを変更できません。

    メモ

    評価SQLセットについてメモを入力します。

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

8.5. 評価SQLセットのコピー

  1. 評価SQLセットの一覧画面からコピーする評価SQLセットにチェックを入れます。

  2. 画面上部の[コピー]ボタンをクリックします。

  3. 必要な値を入力した後、画面下部にある[保存]ボタンをクリックします。

    評価SQLセット_コピー_画面
    項目名 説明

    コピー元評価SQLセット名

    コピー元の評価SQLセットが表示されています。

    新規評価SQLセット名

    コピーして作成される評価SQLセットの名前を入力します。
    大文字、小文字を区別します。

    メモ

    コピーして作成される評価SQLセットについてメモを入力します。

    SQLの絞り込み

    SQLの重複を排除する

    トグルスイッチを「オン」にすると、重複するSQLを排除し、ユニークなSQLのみの評価SQLセットのコピーを作成します。

    除外したいSQLの正規表現

    入力された正規表現にマッチするSQLを除外します。大文字と小文字を区別します。
    icon ex 「test_table」と「test_value」が含まれるSQLを除外したい場合には「test_table|test_value」と入力します。

    対象DBユーザー

    DBユーザーでフィルタリングすることができます。

    期間(SQL開始時刻)

    SQL開始時刻でフィルタリングすることができます。

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

8.6. 評価SQLセットのユーザー変更

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

  1. 評価SQLセットの一覧画面からユーザー名を変更する評価SQLセットにチェックを入れます。

  2. 画面上部の[ユーザー変更]ボタンをクリックします。

  3. 既存ユーザー名が表示されます。
    変更するDBユーザーの項目に、新たなDBユーザー名を入力し、画面下部にある[適用]ボタンをクリックします。

    評価SQLセット_ユーザー変更_画面

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

8.7. 評価SQLセットの外部連携

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

  1. 評価SQLセットの一覧画面から適用する評価SQLセットにチェックを入れます。

  2. 画面上部の[外部連携]ボタンをクリックします。

  3. 外部連携画面が表示されます。icon ope clipまたは入力欄をクリックし、ファイルを選択してください。
    画面下部にある[適用]ボタンをクリックします。

    評価SQLセット_外部連携

8.8. 評価SQLセットのエクスポート

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

  1. 評価SQLセットの一覧画面からエクスポートする評価SQLセットにチェックを入れます。

  2. 画面上部の[エクスポート]ボタンをクリックします。

  3. エクスポート画面が表示されます。メッセージを確認後、[エクスポート]ボタンをクリックします。

    評価SQLセット_エクスポート

8.9. 評価SQLセットの削除

  1. 評価SQLセットの一覧画面から削除する評価SQLセットにチェックを入れます。

  2. 画面上部の[削除]ボタンをクリックします。

  3. 確認用画面が表示されます。削除する評価SQLセットを確認してください。
    問題が無ければ、画面下部にある[削除]ボタンをクリックしてください。

    評価SQLセット_削除_確認

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

8.10. ログの確認

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

9. ターゲットDB

評価SQLセットを実行するターゲットDBを登録、または編集します。

  1. SQL Testing Manager Webコンソールの左のページメニューから[ターゲットDB]をクリックします。

    ターゲットDBの一覧画面が表示されます。

    ターゲットDB

9.1. ターゲットDBの追加

  1. ターゲットDBの一覧画面から[新規作成]ボタンをクリックします。

  2. ターゲットDB名を指定し、[既存のDBを登録する][スナップショットからRDSインスタンス/Auroraクラスタを作成する]のいずれかを選択します。

    [スナップショットからRDSインスタンス/Auroraクラスタを作成する]を設定するためには、AWSへの権限が必要です。詳細は、「必要なIAM設定について」を参照してください。
  3. 必要な値を入力した後、画面下部の[新規作成]ボタンをクリックします。

    [既存のDBを登録する]を選択する場合
    ターゲット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クラスターを作成する]を選択する場合
    ターゲットDB_新規作成_スナップショットから
    項目 説明

    使用する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が追加されるまで時間がかかる場合があります。

  • スナップショットからアップグレードしたターゲットDBを作成する際、AWS側にスナップショットが自動で作成されます。
    作成されたスナップショットが不要な場合は削除してください。

    AWSのデータベースのバックアップ保持期間が「0」の場合は、スナップショットは作成されません。

  • RDSインスタンス、およびAurora DBクラスターは、作成後AWS上で課金対象となり、停止していても7日間利用が無ければ再起動される仕様となっています。
    SQL Testingでは、再起動した後のRDSインスタンス、またはAurora DBクラスターの再停止処理は行いません。
    RDSインスタンス、およびAurora DBクラスターの管理は、お客様側で行ってください。

9.2. ターゲットDBの情報の変更と接続確認

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

  1. ターゲットDBの一覧画面から情報を変更するターゲットDBにチェックを入れます。

  2. 画面上部の[編集・テスト接続]ボタンをクリックします。

  3. ターゲットDBの情報が表示されます。

    • ターゲットDBと接続確認をしたいときは、DBユーザーとパスワードを入力し、[テスト接続]ボタンをクリックします。
      情報に変更が無ければ画面下部にある[キャンセル]ボタンをクリックしてください。

    • 適切な値に変更した場合は、画面下部にある[保存]ボタンをクリックします。

      ターゲットDB_編集_画面
      項目の詳細については、「ターゲットDBの追加」を参照してください。

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

ターゲットDBの新規作成時に[スナップショットからRDSインスタンス/Auroraクラスターを作成する]から作成した場合、以下の項目は編集できません。

  • スナップショットARN

  • インスタンスクラス

  • リージョン

  • インスタンス名(クラスター名)

  • セキュリティグループ

  • サブネットグループ

  • オプショングループ

  • パラメータグループ

  • アップグレード後のエンジンバージョン

9.3. ターゲットDBの削除

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

  1. ターゲットDBの一覧画面から削除するターゲットDBにチェックを入れます。

  2. 画面上部の[削除]ボタンをクリックします。

  3. 確認用画面が表示されます。削除するターゲットDBを確認してください。
    問題が無ければ、画面下部にある[削除]ボタンをクリックしてください。

    ターゲットDB_削除_確認

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

10. アセスメント

評価SQLセットをターゲットDBへ実行します。

アセスメントには、1つのターゲットDBでのみ行うアセスメントと、テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの2種類が存在します。

アセスメントの種類については、「製品の構成」を参照してください。
  • 事前に評価SQLセットを作成する必要があります。
    詳細は「評価SQLセット」を参照してください。

  • 事前にターゲットDBを登録する必要があります。
    詳細は「ターゲットDB」を参照してください。

  1. SQL Testing Manager Webコンソールの左のページメニューから[アセスメント]をクリックします。

    アセスメントの一覧画面が表示されます。

    アセスメント

10.1. アセスメントの新規作成

  • SQL Testing 4.1から、システム停止を防ぐため、システムメモリが枯渇する前にメモリを多く消費するアセスメントプロセスを終了させる機能が追加されました。
    本機能ではメモリとスワップの使用状況を監視し、メモリの利用可能量が少なくなり、かつスワップ領域の空き容量が十分でないと判断された場合、メモリを多く消費するプロセスを終了させます。
    この機能で終了となるアセスメントは結果保存を試みますが、改善が見られなかった場合は異常終了となります。

  • SQL Testing 4.1以降を新規インストールすると追加されます。
    SQL Testing 4.0以前からアップグレードした場合、この機能は追加されません。

  1. アセスメント一覧画面から[新規作成]ボタンをクリックします。

  2. 必要な値を入力した後、画面下部にある[新規作成]ボタンをクリックします。

    1つのターゲットDBでのみ行うアセスメント([2DBモード]が「オフ」)の場合
    アセスメント_新規作成_画面1DB実行タイプ
    項目名 説明

    アセスメント名

    アセスメントの名前を入力します。
    大文字、小文字を区別します。

    メモ

    アセスメントについてメモを入力します。

    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セットを作成する必要があります。
    icon moveをクリックすると、評価SQLセットの一覧画面に遷移します。

    詳細は「評価SQLセット」を参照してください。

    実行タイプ

    実行する方法を選択します。

    • 実行:評価SQLセットをターゲットDBに対して実行します。

    • パース:パース実行を行います。実行時間は取得できないため、速度が遅くなったSQL等の判定ができません。バインド変数の値がなくてもテーブルの有無や構文のチェックができます。

    パース実行の処理時間の参考値については、弊社サポートサイト(Service Portal)の[Insight SQL Testing]>[ナレッジ]から文書番号:000002063を参照してください。

    バインド変数書式変換

    SQLに含まれる名前付きバインド変数をターゲットDBで実行可能な書式に変換してSQLを実行します。
    移行先が名前付き引数に対応していないDBMSでもデータベース接続ドライバー、またはデータベース接続プログラムによって対応される場合を再現して、アセスメント実行時にSQLを自動変換して実行します。

    バインド変数書式変換は、Oracle Database以外のデータベースからOracle Databaseへの変換をサポートしていません(icon ex 「$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実行タイプ
    [2DBモード]が「オン」かつ実行タイプが[実行]時に表示される項目
    項目名 説明

    カラム名の比較

    クエリ実行結果を比較する場合に、テーブルのヘッダーを比較対象とするかを指定します。

    • 比較しない
      カラム名の文字比較を行いません。

    • 大文字・小文字を無視
      カラム名の大文字・小文字を無視して比較します。

    • 完全一致
      カラム名を完全一致で比較します。

    行順序の比較

    取得結果の行順序の一致レベルを指定します。

    • 完全一致
      行順序まで一致したものを成功したと判断します。再ソートによる評価はしません。

    • 完全一致(再ソート試行)
      行順序まで一致したものを成功したと判断します。再ソートによる評価も実施した結果も記録します。

    • 自動
      実行したSQL文にORDER BY句による順序指定がある場合は行順序を含む比較、指定がない場合は行順序を無視して評価します。

    • 無視
      行順序を無視して評価します。

    比較対象外カラム

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

    指定したカラムは比較時に評価対象外となります。
    [比較対象外カラム]で指定するカラム名は、クエリ実行結果のカラム名で指定してください。
    対象外カラムは複数指定可能です。

    • 文字列に「%」を含む場合、その位置に応じて一致の評価が変わります。

      • 前方に「%」がある場合: 後方一致
        icon ex 「%example」は「example」や「prefix_example」に一致)

      • 後方に「%」がある場合: 前方一致
        icon ex 「example%」は「example」や「example_suffix」に一致)

      • 前後に「%」がある場合: 部分一致
        icon ex 「%example%」は「example」や「prefix_example_suffix」に一致)

      • 「%」を含まない場合: 完全一致
        icon ex 「example」は「example」にのみ一致)

    • 「%」を含むカラム名を指定することはできません。

    • 大文字・小文字を区別します。

    • テスト用ソースDBとターゲットDBでクエリ実行結果のカラム名の大文字・小文字が異なる場合は、テスト用ソースDBのカラム名に合わせて入力してさい。

    • すべてのカラムが比較対象外となった場合、結果のステータスは「成功」もしくは「性能が劣化」になります。

    取得結果の保存条件

    SQLを実行して取得した結果の保存条件を選択します。保存した取得結果は、アセスメントのSQL詳細画面で閲覧、ダウンロードできます(SQLの実行に失敗している場合や返り値のないSQLを除く)。

    • 結果が異なるもののみ保存:ターゲットDBとテスト用ソースDBで取得した結果が異なる場合のみ、結果を保存します。[2DBモード]を「オン」にした場合に表示されます。容量削減のため、この選択肢がデフォルトで設定されています。

    • すべて保存:取得した結果に関わらず、すべての結果を保存します。

    • 保存しない:取得した結果を保存しません。

    末尾の空白を削除して比較

    取得結果が固定長文字列型の場合に末尾の空白を取り除いて比較します。

    浮動小数点の誤差

    取得結果が浮動小数点型の場合に許容する誤差を正の数で設定します。
    未指定の場合は誤差を許容しません。

    期間(SQL開始時刻)

    [2DBモード]が「オン」、実行タイプが[実行]、かつ[直列実行]が「オン」のときは、評価SQLセットのSQL開始時刻の期間でフィルタリングして実行することができます。
    選択されていない範囲のSQLは実行されません。
    [期間(SQL開始時刻)]をクリックし、適切な期間を設定してください。

    ターゲットDB
    項目名 説明

    ターゲットDB

    評価SQLセットを実行するデータベース(ターゲットDB)を選択します。
    事前にターゲットDBを登録する必要があります。
    icon moveをクリックすると、ターゲットDBの一覧画面に遷移します。

    詳細は「ターゲットDB」を参照してください。

    ターゲットDBに使用する修正SQLセット

    ターゲットDBに使用する修正SQLセットを選択します。
    修正SQLセットを用いる場合に設定します。修正SQLセットを使用しないときは[指定なし]を選択してください。

    テスト用ソースDBには元のSQL、ターゲットDBには修正SQLを適用する等、別々のSQLを適用することもできます。

    修正SQL適用

    フェッチ・サイズ値(ターゲットDB)

    一度にデータベースサーバーから受け取る行数を指定することができます。

    実行タイプで[実行]を選択時に表示されます。
    [ターゲットDBと異なる設定をする]が「オン」の時は、ターゲットDBとテスト用ソースDBでそれぞれ設定できます。
    「オフ」の時は、ターゲットDBに設定した値がテスト用ソースDBにも適用されます。

    データベースの種類により動作が異なります。

    • Oracle Databaseの場合:任意の値を指定できます。

    • PostgreSQL/MySQLの場合:0または1を指定した場合、1行ごとに取得します。
      2以上を指定した場合、全件取得します。

    • SQL Serverの場合:値に関係なくドライバ依存の自動的に決定される取得件数になります。

    テスト用ソースDB

    [2DBモード]が「オン」のときに表示します。

    項目名 説明

    テスト用ソースDB

    評価SQLセットを実行するデータベース(テスト用ソースDB)を選択します。
    事前にターゲットDBを登録する必要があります。
    icon moveをクリックすると、ターゲット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実行に影響がある可能性に注意してください。

    セッション毎フック処理

  3. 作成が完了すると、アセスメント一覧画面に完了アイコン[完了アイコン]が表示されます。
    SQL Testing 4.1以降は、完了時の状態によりステータスアイコンが変わります。
    正常終了すると緑色[完了アイコン]、ログにwarningまたはerrorレベルの内容が出力されていると、オレンジ色[ワーニングアイコン]になります。

    ope assessments ico

10.1.1. バインド変数補完

評価SQLセットに取得されていないバインド変数をアセスメント実行時に補完します。
データ型ごとに補完する値を設定します。

  • バインド変数に求められる型情報を移行先データベースから取得できなかった場合は、「デフォルト」で指定した値を使用します。

  • 値にNULLを指定するときは、NULLにチェックを入れてください。

アセスメント_バインド変数補完

10.2. アセスメントを複製して新規作成

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

  1. アセスメントの一覧画面から複製するアセスメントにチェックを入れます。

  2. 画面上部の[複製して新規作成]ボタンをクリックします。

    複製して新規作成
  3. 変更したい項目を修正し、[複製して新規作成]ボタンをクリックします。

    項目の詳細については、「アセスメントの新規作成」を参照してください。

10.3. アセスメントの編集

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

  1. アセスメントの一覧画面から編集するアセスメントにチェックを入れます。

  2. 画面上部の[編集]ボタンをクリックします。

  3. アセスメント名やメモを変更し、[保存]ボタンをクリックします。

    アセスメント_編集_確認

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

10.4. アセスメントの中断

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

  1. アセスメントの一覧画面から中断するアセスメントにチェックを入れます。

  2. 画面上部の[中断]ボタンをクリックします。

  3. 確認用画面が表示されます。中断するアセスメントを確認してください。
    問題が無ければ、画面下部にある[中断]ボタンをクリックしてください。

    アセスメント_中断‗確認

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

10.5. アセスメントの削除

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

  1. アセスメントの一覧画面から削除するアセスメントにチェックを入れます。

  2. 画面上部の[削除]ボタンをクリックします。

  3. 確認用画面が表示されます。削除するアセスメントを確認してください。
    問題が無ければ、画面下部にある[削除]ボタンをクリックしてください。

    アセスメント_削除_確認

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

10.6. アセスメント結果のダウンロード

アセスメント結果をダウンロードします。
複数を選択した場合は複数個別にダウンロードされます。

  1. アセスメントの一覧画面からダウンロードするアセスメントにチェックを入れます。

  2. 画面上部の[ダウンロード]ボタンをクリックします。

  3. ダウンロード画面が表示されます。ダウンロードするデータのリンク(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. ログの確認

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

10.8. アセスメント結果の確認

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

SQL Testing 4.0以降では、Insight DT 3.2以前に作成されたアセスメントにおいて、アセスメント結果からSELECT文などの取得結果は閲覧できません。
  1. アセスメントの一覧画面から確認するアセスメント名をクリックします。

    アセスメント_選択
  2. サマリー画面が表示されます。

    サマリー画面の詳細については、「サマリー」を参照してください。

10.9. サマリー

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

  • 1つのターゲットDBでのみ行うアセスメントでのサマリー画面

    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とターゲット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件以降を参照する場合、[全体表示]をクリックするとページネーション表示(icon pagenation)になり、残りを参照できます。
各項目のSQL情報を閲覧する場合は、対象の行を選択します。

10.9.2. 結果が異なるSQL

テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントで、左側に結果が異なったSQL、右側に同じ結果になったSQLの割合と件数が表示されます。
結果は「取得結果」で確認できます。

結果が異なるSQL

サマリー画面で[SQLテキスト]をクリックすると、SQL詳細画面を表示します。

結果が異なるSQL_2DB
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの場合

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詳細画面を表示します。

サマリー_遅くなったSQL_2DB
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの場合
  • 取得したSQLの「実行計画」を確認できます。

  • 1つのターゲットDBでのみ行うアセスメントでは、ソースDBのSQLの実行時間が0秒として取得されている場合があります。

詳細は「0秒時の対応」を参照してください。

10.9.4. テスト用ソースDBにて失敗したSQL

テスト用ソースDB、またはテスト用ソースDBとターゲットDBの両データベースでエラーになったSQLを、出現順序の早い順で表示します。
タイトルをクリックするとTOP10以降を確認できます。
SQLテキストをクリックすると該当SQLの詳細を表示します。

左側にテスト用ソースDBで失敗したSQLのパーセンテージと件数、右側にテスト用ソースDBで失敗しなかったSQLのパーセンテージと件数が表示されます。
パーセンテージの分母はエラーが出たSQLの件数です。

テスト用ソースDBにて失敗したSQL

10.9.5. 移行情報

バインド変数変換や構文でエラーになるものを集計し、表示します。

  • バインド変数書式変換がある場合に変換したもの

  • 取得できていないバインド変数に値を埋めたもの

  • バインド変数型の型変換で、エラーの可能性があるもの

  • 非互換構文について取得したもの(Oracle Databaseのみ)

バインド変数については、以下を参照してください。

サマリー_移行情報

10.9.6. サマリーのダウンロード

アセスメント結果をCSVファイル形式でダウンロードします。

  1. 画面上部の[ダウンロード]ボタンをクリックします。

    サマリー_ダウンロード
  2. SQLのフィルタ条件(フィルタ設定)を選択します。
    ダウンロードするデータのリンク(ZIP)をクリックします。

    サマリー_ダウンロード_画面
    1つのターゲットDBでのみ行うアセスメントの場合
    2dbダウンロード
    テスト用ソース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毎の詳細情報を出力します

    • 実行結果と詳細情報を統合して出力します

  3. ZIP圧縮されたCSVファイルのダウンロードが開始します。

CSVファイルの項目の詳細は「CSVファイルのカラムについて」を参照してください。

10.9.7. 修正を評価SQLセットに適用

修正したSQLを評価SQLセットにマージします。

  1. SQL Testing 4.2以降の場合は、SQL修正一覧画面上部の[修正を評価SQLセットに適用]ボタンをクリックします。
    SQL Testing 4.1以前の場合は、サマリー画面上部に修正完了率と[修正を評価SQLセットに適用]ボタンが表示されます。[修正を評価SQLセットに適用]ボタンをクリックします。

    SQL Testing 4.2以降_修正を評価SQLセットに適用
  2. 確認用の画面が表示されます。
    [評価SQLセット]を選択し、画面下部の[修正を評価SQLセットに適用]ボタンをクリックします。画面はSQL Testing 4.2以降の場合です。

    サマリー_修正を評価SQLセットに適用_適用

    選択した評価SQLセットへマージされます。
    修正したSQLは評価SQLセットへ上書きされますので、必要に応じて評価SQLセットのコピーを作成してください。

10.9.8. SQLの抽出(ツール連携)

実行したアセスメントの結果から構文の重複を排除してSQLテキストを抽出します。
抽出したSQLは、失敗したSQLの自動変換など、外部ツールと連携して利用できます。

  1. [SQLの抽出]ボタンをクリックすると、ダウンロードの確認画面が表示されます。

    SQLの抽出
  2. どの実行ステータスのSQLをダウンロードするかを選択し、画面下部の[ダウンロード]ボタンをクリックします。
    ダウンロードが実行します。

    失敗したSQLの抽出
    1つのターゲットDBでのみ行うアセスメントの場合

    テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでは、[ターゲットDBでのみ失敗][両DBで失敗][結果が相違][性能が劣化][成功][テスト用ソースDBでのみ失敗]から選択します。

    失敗したSQLの抽出
    テスト用ソース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のステータスや修正完了率が変更されていきます。

実行結果一覧_2DB

10.10.1. 実行結果一覧

SQL実行結果、修正状態、フィルタリングから選択した項目で実行結果一覧の表示が切り替わります。

各項目の詳細は「使用している項目名について」を参照してください。
SQL実行結果
1つのターゲットDBでのみ行うアセスメントの場合
実行結果一覧_1DB
項目名 説明

失敗

SQL実行が失敗したものを表示します。

成功

SQL実行が成功したものを表示します。

性能が劣化

SQL実行時間と比較して、遅かったものを表示します。
SQL Testing 4.2以降で対応しています。

テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの場合
実行結果一覧_2DB
項目名 説明

ターゲット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エラーメッセージ

フィルタリングメニューからフィルタリング

項目名の隣のフィルタリングメニューをクリックして、フィルタリングもできます。
チェックを入れて[適用]をクリックすると、チェックした値でフィルタリングされます。
フィルタ後は表内のフィルタ処理は無効になります。

SQL一覧_カラムフィルタリング
  • 1ページ当たり100件まで表示します。

  • 検索はページ内でのみ有効です。

詳細フィルタを用いたフィルタリング

フィルタリングの右の[詳細フィルタ]をクリックすると、メニューが表示されます。
フィルタ条件にフィルタ対象、演算子、値を入力して[適用]をクリックします。
フィルタリング結果に詳細フィルタを適用することもできます。

SQL一覧_詳細フィルタ
  • ステータス項目以外の項目をフィルタ条件に追加することができます。

  • 適用中のフィルタはフィルタ対象にも表示され、編集できます。

  • 中央の項は演算子を選択します。

  • 演算子がNULL、NOT NULLの場合、値はグレー表示になり設定できません。

  • フィルタ対象の重複が許されるのは、一部演算子(<、≦、>、≧)のみです。

  • 演算子「IN」を選択すると、値の右に[+]アイコンが表示され、OR条件を作成することができます。この時、フィルタ対象と演算子はグレー表示になり設定できません。
    OR検索用の行は、各項目に不備がない状態でのみ行の追加ができます。演算子が「IN」のときのみ表示されます。

    • 比較条件が「LIKE」または「ILIKE」の場合に前方一致か部分一致かを選択できます。
      LIKEとILIKEの違いは下記のとおりです。

      詳細フィルタLIKE
      演算子 説明

      LIKE

      [値]に指定されたパターンに一致する文字列でフィルタします。大文字小文字を区別します。

      ILIKE

      [値]に指定されたパターンに一致する文字列でフィルタします。大文字小文字を無視します。

  • 内部で処理できない値を入力すると、その旨のメッセージが表示されます。

SQL実行結果一覧の表示項目と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一覧_重複排除
カラム表示設定

実行結果一覧画面に表示されるカラムをカスタマイズできます。

カラム表示設定

[カラム表示設定]ボタンをクリックすると、表示するカラム一覧が表示され、表示させたくないカラムのチェックを外すと非表示になります。

  • デフォルトではすべてのカラムを表示しています。

  • [#][ステータス][SQLテキスト]は常に表示されるカラムで、非表示にできません。

  • 変更した表示設定は同一ブラウザにおいて保持されます。

    カラム表示設定

10.10.2. SQL実行結果一覧のダウンロード

アセスメント結果をCSVファイル形式でダウンロードします。
アセスメント結果にフィルタリングを反映させた結果をダウンロートすることができます。

  1. SQL実行結果一覧画面でフィルタリング設定を行った後、[ダウンロード]ボタンをクリックします。

    SQL実行結果一覧ダウンロード
  2. 現在設定されているフィルタリング結果をダウンロードする場合、[現在設定されているフィルタを使用]のトグルスイッチを「オン」にして、ダウンロードするリンクをクリックします。
    または、現在設定されているフィルタリング結果は使用しない場合、[現在設定されているフィルタを使用]を「オフ」にします。フィルタリングしたいフィルタ設定の実行結果にチェックを入れて、ダウンロードするリンクをクリックします。

    ope sqllist download modal
    項目 説明

    フィルタ設定

    [現在設定されているフィルタを使用]のトグルスイッチを「オン」にするとダウンロードする実行結果を現在設定されているフィルタで絞り込みを行うことができます。

    [現在設定されているフィルタ]の対象は、SQL実行結果一覧画面の下記の項目の設定内容です。

    • [SQL実行結果]

    • [フィルタリング]

    • [重複排除]

    [現在設定されているフィルタを使用]を「オフ」にすると、以下の実行結果から選択できます。

    • 1つのターゲットDBでのみ行うアセスメントの場合は[成功][失敗][性能が劣化]から選択します。すべてのSQLの実行結果を取得する場合はすべてにチェックを入れます。
      [性能が劣化]はSQL Testing 4.2以降で対応しています。

    • テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントの場合は[ターゲットDBでのみ失敗][両DBで失敗][結果が相違][性能が劣化][成功][テスト用ソースDBでのみ失敗]から選択します。すべてのSQLの実行結果を取得する場合はすべてにチェックを入れます。

    テスト用ソースDB

    テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでテスト用ソースDBの情報も取得する場合には、トグルスイッチを「オン」にします。

    各データのダウンロードリンク

    ダウンロードするデータ内容(実行結果、詳細情報、またはその両方)を選択します。

    • SQL毎の実行結果を出力します

    • SQL毎の詳細情報を出力します

    • 実行結果と詳細情報を統合して出力します

    • マイニングサーチ形式でダウンロード
      [現在設定されているフィルタを使用]をオンにした場合、表示されます。フィルタリング後のSQLをマイニングサーチ形式で出力します。

  3. ZIP圧縮されたCSVファイルのダウンロードが開始します。

10.11. SQL修正一覧

SQL Testing 4.2以降で対応しています。

アセスメント結果から修正して保存したSQL(SQL文・バインド変数)の一覧を確認することができます。
画面上部の修正完了率(バーチャート)では、左側に未修正のSQL、右側に修正済のSQLの割合と件数を表示します。
初期表示は未修正のSQLが100%、修正済のSQLが0%です。

SQL修正一覧

表示された一覧の行をクリックするとpiHashとsqlIdのフィルタを適用した、実行結果一覧画面へ遷移できます。

SQL修正一覧

10.12. SQLの詳細と実行

サマリーの画面からドリルダウンし、SQL実行結果一覧の画面左の連番(#)をクリックすると、SQL詳細画面に遷移します。

  • 1つのターゲットDBでのみ行うアセスメントと、テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントとで表示内容が異なります。

  • 修正SQLセットを適用して実行した場合は、適用されたSQLが表示されます。

SQL詳細
1つのターゲットDBでのみ行うアセスメント
SQL詳細_2db
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメント

10.12.1. SQLの修正

[SQLの修正]タブでは、SQLを修正しての実行確認などを行うことができます。

10.12.1.1. ステータス

画面上部にはステータスが表示されます。
実行できなかったSQLの場合は、エラーコードとエラーメッセージが表示されます。
実行できたSQLの場合は、ターゲットDBでのSQL実行時間が表示されます。

テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでは、両データベースに対してSQLを実行して得られた情報が表示されます。
アセスメント設定の行順序の比較で一致レベルを指定した場合、ステータスに再ソートした結果であるかどうかを表示します。

  • 順序を含めて完全一致

  • 再ソート実行したが不一致

  • 再ソート実行により一致

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を実行します。

  1. 画面左のSQLを、ターゲットDBへ実行させるSQLに書き換えます。
    SQL実行時にセッションパラメーターを変更したい場合、下記のように複数文を入力して実行することができます。

    ALTER SESSION SET NLS_DATE_FORMAT = 'RRRR/MM/DD'; SELECT TO_CHAR(CURRENT_DATE) FROM DUAL;
  2. 画面右の[設定][バインド変数]タブにて、実行先のデータベースの設定を行います。

  3. 必要な値を入力します。

    SQL詳細_設定_保存
    設定
    項目名 説明

    ターゲットDB

    SQLの実行先のDBを選択します。

    DBユーザー

    DBユーザー名を入力します。
    ターゲットDBに存在するユーザーを入力します。

    パスワード

    DBユーザーのパスワードを入力します。
    入力すると、グレーアウトした[SQLの実行]ボタンが有効になります。

    実行タイプ

    実行する方法を選択します。
    実行:実際にSQLを実行します。
    パース:パース実行を行います。バインド変数の値がなくてもテーブルの有無や構文のチェックができます。

    パース実行の処理時間の参考値については、弊社サポートサイト(Service Portal)の[Insight SQL Testing]>[ナレッジ]から文書番号:000002063を参照してください。

    フェッチ・サイズ値

    一度にデータベースサーバーから受け取る行数を指定します。

    SQL実行結果をコミットします

    トグルスイッチをオンにすると、SQL実行をロールバックせずにコミットして、結果をターゲットDBに保持します。

    バインド変数書式変換

    トグルスイッチをオンにすると、SQLに含まれる名前付きバインド変数(ex :name)をターゲットDBで実行可能な書式に変換してSQLを実行します。
    移行先が名前付き引数に対応していないDBMSでもデータベース接続ドライバー、またはデータベース接続プログラムによって対応される場合を再現してアセスメント実行時にSQLを自動変換します。

    バインド変数書式変換は、Oracle Database以外のデータベースからOracle Databaseへの変換をサポートしていません(icon ex 「$1」や「?」から「:1」への変換)。

    SQL自動分割実行

    トグルスイッチをオンにすると、複数文のSQL判別と分割実行をします。

    SQL詳細_バインド変数
    バインド変数
    項目名 説明

    バインド変数

    バインド変数とその値を入力します。
    icon plus]をクリックすると入力要素が表示されます。行の右にある[icon x]をクリックすると当該の入力要素が削除されます。

    • 変数名、値、データ型を入力します。

      • 値にNULLを指定するときは、NULLにチェックを入れてください。

      • データ型は、[文字列][固定長文字列][任意精度数値][整数][小数][時刻][日付][日付時刻][真偽値][バイナリ]から選択してください。

    • 変数名の頭に「:」や「$」は必要ありません。

    バインド変数については「ターゲットDB実行時の型指定と入力書式」を参照してください。
  4. 画面右の[SQL実行]をクリックすると、SQLが実行されます。

  5. 結果は、画面右上のインフォメーションに表示されます。

    SQL詳細_SQLの実行_結果
    • SQLがSELECTのときは取得結果を表示します(最大100行表示)。

      取得結果
    • DML(Update/Insert/Delete)のときは更新された行数の情報を表示します。

      取得結果
10.12.1.5. SQLの保存

SQLの修正をアセスメントに保存します。
ここで保存した修正は、サマリー画面での修正を評価SQLセットに適用する場合、または修正SQLセットを作成する際に使用できます。
テスト用ソースDBとターゲットDBの2つのデータベースを指定して行うアセスメントでは、ターゲットDBに対して実行したペインでのみSQL保存ができます。
SQLの保存の設定時にバインド変数の保存有無を選択したり、保存したSQLの修正を取り消すことができます。

  1. SQLを修正した後、[SQLの保存]ボタンをクリックします。

    SQL詳細_保存
    項目名 説明

    SQLの保存

    修正したSQLを保存します。
    SQLのみの保存となるため、バインド変数はNULLとして保存されます。
    すでにバインド変数を保存している場合、NULLとして上書き保存されてしまう点に注意してください。

    バインド変数も含めて保存

    修正したSQLとバインド変数の設定の両方を保存します。
    [SQLの保存]ボタンの右横の下三角形のアイコンをプルダウンするとメニューが表示されます。

    バインド変数のみ保存

    バインド変数の設定のみ保存します。
    [SQLの保存]ボタンの右横の下三角形のアイコンをプルダウンするとメニューが表示されます。
    バインド変数のみの保存となるため、SQLはNULLとして保存されます。
    [SQLの保存]と同様、すでにSQLを保存している場合、NULLとして上書き保存されてしまう点に注意してください。

  2. [修正の取り消し]ボタンをクリックすると、保存したSQL(バインド変数)を取り消します。
    修正した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つのデータベースを指定して行うアセスメントで、アセスメント実行時に取得・保存した実行計画を表示します。 保存条件はアセスメント設定の[実行計画の保存条件]に従います。

実行計画_2DB

10.12.4. ソースSQL

[ソースSQL]タブでは、ソースDBで実行されていたSQLを確認します。
[SQLの修正]タブでSQLを修正した場合、こちらの[ソースSQL]タブから編集前のSQLを確認できます。
また[SQLの修正]タブでバインド変数を修正した場合でも、[ソースSQL]タブから編集前のバインド変数を確認できます。

SQL詳細_ソースSQL_バインド変数

10.12.5. 詳細情報

[詳細情報]タブでは、SQL実行結果の詳細情報を確認します。
表示される項目は、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を実行した結果が失敗の時、その結果を使用して「エラー分析」ができます。

  1. SQL詳細画面から[エラー分析]ボタンをクリックします。

    llm3
  2. エラー分析画面が開きます。[分析開始]ボタンをクリックすると推論が始まります。

    llm4
    項目名 説明

    モデルの選択

    Amazon Bedrockを使用する場合、利用可能なモデルが選択できます。
    SQL Testing 4.2以降で対応しました。GPT4Allの場合は使用できません。

    分析開始

    [分析開始]ボタンをクリックすると推論が始まります。

    プロンプトの設定

    プロンプトの設定を展開すると、推論時に使用するプロンプトの設定を行うことができます。

    • テンプレートプロンプト

      • デフォルトで用意されているプロンプトです。編集することはできません。

    • カスタムプロンプト

      • ユーザーが任意に作成したプロンプトです。

      • 作成したカスタムプロンプトは[保存]ボタンをクリックすることで保存できます。保存したプロンプトは他のエラー分析で使用することができます。

    • プレースホルダーについて
      プロンプト内で指定されたプレースホルダーは、推論時に各項目の値と置き換えられます。
      使用できるプレースホルダーは以下のとおりです。

      • {sourceDb}: テスト用ソースDB種別に置き換えられます。

      • {targetDb}: ターゲットDB種別に置き換えられます。

      • {sqlQuery}: SQLテキストに置き換えられます。

      • {errorMessage}: エラーメッセージに置き換えられます。

  3. 分析結果がLLMからの応答に表示されます。

    llm5
LLMからの応答には誤りがある可能性があります。
使用するLLMの設定方法については、「LLM」を参照してください。

11. 修正SQLセット

修正SQLセットは、評価SQLセットの一部のSQLに対し、修正を適用してアセスメントを実行する機能です。

1回目のアセスメントで実行エラーとなったSQLを、外部ツールなどで更新して再度実行する場合に、修正した部分を追加適用してアセスメントを行います。

11.1. 修正SQLセットの作成

  1. 左のページメニューから[修正SQLセット]をクリックします。

  2. 修正SQLセットの一覧画面から[新規作成]ボタンをクリックします。

    修正SQLセット
  3. 必要な値を入力した後、画面下部の[新規作成]ボタンをクリックします。

    修正SQLセットの新規作成1
    アセスメント結果にて保存してSQLから作成
    修正SQLセットの新規作成2_外部
    外部ツールで変換したSQL情報から作成
    項目名 説明

    修正SQLセット名

    任意の修正SQLセットの名前を入力します。
    大文字、小文字を区別します。

    修正SQLセットのソース選択

    修正SQLセットは、以下のいずれかの手段から作成できます。

    • アセスメント結果にて保存したSQLから作成
      アセスメントに対して[SQLの修正]タブで修正保存したSQLを使用する場合に選択してください。

    • 外部ツールで変換したSQL情報から作成
      評価SQLセットに対してツール連携で適用可能な、ZIPファイルまたはCSVファイルをアップロードする場合に選択してください。

    アセスメント結果にて保存したSQLから作成

    アセスメント

    ▼をクリックし、修正SQLセットに使用するアセスメントを選択してください。

    外部ツールで変換したSQL情報から作成

    データ元ファイル

    icon ope clipまたは入力欄をクリックし、修正SQLセットに使用するファイルを選択してください。

    メモ

    修正SQLセットについてのメモを入力します。

修正SQLセットの一覧に情報が追加されると完了です。
修正SQLセットが追加されるまで時間がかかる場合があります。

11.2. 修正SQLセットのSQL詳細

修正SQLセットを作成した後、修正SQLセットの中のSQLの詳細を確認します。

  1. 修正SQLセットの一覧画面から詳細情報を確認する修正SQLセット名を選択します。

  2. SQLの一覧画面が表示されます。

    修正SQLセットのSQL詳細

11.3. 修正SQLセットの結合

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

  1. 修正SQLセットの一覧画面から結合する修正SQLセットにチェックを入れます。
    ステータスが完了アイコン[ope status success]の修正SQLセットを選択してください。
    ステータスが失敗アイコン[ope status failed]の修正SQLセットは選択しても、内部フィルタで除外されます。

    修正SQLセットの結合
  2. 画面上部の[結合]ボタンをクリックします。

  3. 新たに生成する修正SQLセット名を入力し、結合するSQLセットの順番をドラッグアンドドロップで並べ替えます。
    画面下部にある[結合]ボタンをクリックします。
    ※ステータスが失敗アイコン[ope status failed]の修正SQLセットは表示されません。

    修正SQLセットのセット名
    項目名 説明

    修正SQLセット名

    新たに生成する修正SQLセットの名前を入力します。既存の修正SQLセット名と異なる名前にしてください。
    大文字、小文字を区別します。

    メモ

    修正SQLセットについてのメモを入力します。

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

11.4. 修正SQLセットの編集

修正SQLセットの名前やメモを編集します。

  1. 修正SQLセットの一覧画面から編集する修正SQLセットにチェックを入れます。

  2. 画面上部の[編集]ボタンをクリックします。

  3. 必要な値を入力した後、画面下部にある[保存]ボタンをクリックします。

    評価SQLセット_編集_画面
    項目名 説明

    修正SQLセット名

    変更する修正SQLセット名を入力します。

    メモ

    修正SQLセットについてのメモを入力します。

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

11.5. 修正SQLセットの削除

  1. 修正SQLセットの一覧画面から削除する修正SQLセットにチェックを入れます。

  2. 画面上部の[削除]ボタンをクリックします。

  3. 確認用画面が表示されます。削除する修正SQLセットを確認してください。
    問題が無ければ、画面下部にある[削除]ボタンをクリックしてください。

    修正SQLセット_削除_確認

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

12. AWSマイグレーション

AWSマイグレーションは、あらかじめスケジュールを設定した期間中に、定期的に評価SQLセットの作成とアセスメントの実行を繰り返すことができる機能です。
データベースのスナップショットから、テスト用ソースDBとターゲットDBを作成して、2つのデータベースを指定したアセスメントを行います。

12.1. AWSマイグレーションの一覧

  1. グローバルメニューバーから[AWSマイグレーション]をクリックします。

  2. 設定されているAWSマイグレーションの一覧が表示されます。

    AWSマイグレーションの一覧

    一覧では、それぞれのAWSマイグレーションの状態が表示されます。

    項目 説明

    ステータス

    最新のアセスメント実行のステータスをアイコンで示します。

    execution ico スケジュール状態

    現在スケジュール実行が有効かどうかを示します。

    マイグレーション名

    設定したマイグレーションの名前を表示します。

    ログ

    マイグレーションを作成した際のログの確認やダウンロードすることができます。

    メモ

    設定したメモ情報を表示します。

    マイグレーション

    テスト用ソースDB、ターゲットDBの情報を表示します。

    スケジュール

    設定したスケジュール情報を表示します。

    SQL数

    実行されたSQL数(件)を表示します。

    失敗した割合

    実行されたSQLのうち、失敗したSQLの割合(%)を表示します。

    更新日時

    最後に更新された日付を表示します。

    作成日時

    マイグレーションプロジェクトを作成した日時を表示します。

12.2. AWSマイグレーションの新規作成

  1. AWSマイグレーションの一覧画面から[新規作成]をクリックします。

  2. AWSマイグレーションの作成では以下の設定を行い、最後にバリデーションを実行してから新規作成します。

    • 概要の設定

    • SQLログ取得設定

    • SQL実行先データベース設定

    • アセスメント設定

    • スケジュール設定

バリデーションに成功した場合でも、AWSアカウントの状態などにより、処理を開始できない場合があります。

新規作成されたAWSマイグレーションは一覧へ追加され、テスト用ソースDBが作成されたのち、実行待ち状態(スケジュールが有効な状態)となります。
設定された処理タイミングになると、ソースDBからのログ取得、評価SQLセットの作成、アセスメントが実行されます。

12.2.1. 概要の設定

AWSマイグレーションの概要情報を設定します。
概要情報は後から変更することができます。

概要の設定
項目 説明

マイグレーション名

AWSマイグレーションの設定名を入力します。
大文字、小文字を区別します。半角英数字のみ使用できます。

メモ

マイグレーションの概要を入力します。

12.2.2. SQLログ取得設定

ソースDB(SQL収集元)になるRDSのデータベース情報を設定します。
本番データベースや開発用データベースなど、アプリケーションからSQLが実行され、そのSQL実行がログとして記録されているデータベースを指定します。

SQLログ取得設定
項目 説明

使用するAWSプロファイル名

使用するAWSプロファイル名を選択します。「デフォルト」を選択した場合、共有AWS認証情報ファイルのdefault設定が存在すればそれを使用します。存在しない場合、IAMロールの設定で認証を試みます。
AWSプロファイル名を指定した場合、指定したAWSプロファイル名で認証を行います。無効なAWSプロファイル名の場合、エラーが発生します。

リージョン

SQL収集元データベースのデータベースインスタンスまたはクラスターがあるリージョンを指定します。

インスタンスID/クラスタID

SQL収集元データベースのインスタンスIDを指定します。
対象がAurora DBクラスターの場合にはクラスターIDを指定します。

データベース名

SQL収集元データベースのデータベース名を指定します。
インスタンス内で複数のデータベースを運用していて、それらをテスト対象としたい場合は、AWSマイグレーションは別々に設定する必要があります。

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マイグレーションの作成直後に、最初にインスタンスの作成が実行されます。

スナップショットからRDSインスタンス/Auroraクラスタを作成する
項目 説明

使用するAWSプロファイル名

使用するAWSプロファイル名を選択します。「デフォルト」を選択した場合、共有AWS認証情報ファイルのdefault設定が存在すればそれを使用します。存在しない場合、IAMロールの設定で認証を試みます。
AWSプロファイル名を指定した場合、指定したAWSプロファイル名で認証を行います。無効なAWSプロファイル名の場合、エラーが発生します。

スナップショットARN

テスト用ソースDB/ターゲットDBの作成の元となるスナップショットのARNを指定します。

インスタンスクラス

新規作成するテスト用ソースDB/ターゲットDBのインスタンスクラスを指定します。

リージョン

新規作成するテスト用ソースDB/ターゲットDBのリージョンを指定します。

セキュリティグループ

新規作成するテスト用ソースDB/ターゲットDBのセキュリティグループのセキュリティグループIDを指定します。
複数入力する場合は、「,」で区切ります。

サブネットグループ

データベースを作成するサブネットグループを指定します。

オプショングループ

新規作成するテスト用ソースDB/ターゲットDBのオプショングループのオプショングループ名を指定します。
テスト用ソースDB/ターゲットDBの作成の元となるスナップショットにAurora DBクラスターを指定した場合は、指定できません。
指定しない場合はデフォルトのオプショングループが使用されます。

パラメータグループ

新規作成するテスト用ソースDB/ターゲットDBのパラメータグループのパラメータグループ名を指定します。
テスト対象がAurora DBクラスターの場合にはクラスターパラメータグループ名を指定します。
指定しない場合はデフォルトのパラメータグループまたはクラスターパラメータグループが使用されます。

アップグレード後のエンジンバージョン

アップグレードしたターゲットDBを作成する場合、アップグレード後のエンジンバージョンを指定します。
スナップショットのデータベースバージョンから、1回でアップグレード(変更)可能なバージョンを指定してください。

アセスメント完了後の自動停止

トグルスイッチをオンにすると、アセスメントが完了したタイミングで作成したデータベースを停止します。

  • AWSマイグレーションからアップグレードしたデータベースを作成する際、AWS側にスナップショットが自動で作成されます。
    作成されたスナップショットが不要な場合は削除してください。

  • [アセスメント完了後の自動停止]を選択していても、次の処理開始までの時刻が30分以内の場合には停止はされません。

  • RDSインスタンス、およびAurora DBクラスターは、作成後AWS上で課金対象となり、停止していても7日間利用が無ければ再起動される仕様となっています。
    SQL Testingでは、再起動した後のRDSインスタンス、またはAurora DBクラスターの再停止処理は行いません。
    RDSインスタンス、およびAurora DBクラスターの管理は、お客様側で行ってください。

12.2.3.2. 登録してあるターゲットDBを使用する

SQL Testingからテスト用ソースDBを作成せずに、既存のターゲットDBを使用してAWSマイグレーションを行います。

登録してあるターゲットDBを指定
項目 説明

テスト用ソースDB

テスト用ソースDBとして使用するデータベースを指定します。

ターゲットDB

ターゲットDBとして使用するデータベースを指定します。

12.2.4. アセスメント設定

アセスメントを実行する際の設定を行います。
AWSマイグレーションには直列実行のオプションはありません。常に直列実行は「無効」で実行されます。

アセスメント設定

[行順序の比較][比較対象外カラム]は、SQL Testing 4.1以降で対応しています。

項目の詳細については、「アセスメント」を確認してください。

12.2.5. スケジュール設定

SQL情報を取得してアセスメント実行を繰り返し行うためにスケジュール、終了時期の設定を行います。
また、スケジュール設定を行わずに、直後に1回のみ実行することもできます。

スケジュール設定
項目 説明

スケジュール設定

SQLの収集とアセスメント実行スケジュールを指定して定期的に実行する場合は、[スケジュールを設定する]を選択します。
今収集している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マイグレーションの設定を行いたい場合に便利です。

  1. AWSマイグレーションの一覧画面からもとにするAWSマイグレーションにチェックを入れます。

  2. 画面上部の[複製して新規作成]ボタンをクリックします。

    複製して新規作成
  3. マイグレーション情報画面に沿って、設定を変更します。最後の確認画面で[新規作成]ボタンをクリックします。

    複製して新規作成:設定

12.4. AWSマイグレーションの編集

AWSマイグレーションの名前やメモを変更します。

  1. AWSマイグレーションの一覧画面から編集したいAWSマイグレーションにチェックを入れます。

  2. 画面上部の[編集]ボタンをクリックします。

  3. 必要な値を入力した後、画面下部にある[適用]ボタンをクリックします。

    AWSマイグレーションの編集画面

12.5. AWSマイグレーションのスケジュールの変更

AWSマイグレーションをスケジュール実行する場合、終了日付と実行頻度を設定、変更することができます。
[変更後にスケジュール実行を開始します]をオンにして[適用]ボタンをクリックすると、変更したスケジュールの日時でアセスメント実行を開始します。
[変更後にスケジュール実行を開始します]をオフにして[適用]ボタンをクリックすると、スケジュールの日時は変更されますがアセスメント実行はされません。

  1. AWSマイグレーションの一覧画面からスケジュールを変更したいAWSマイグレーションにチェックを入れます。

  2. 画面上部の[スケジュールの変更]ボタンをクリックします。

  3. 日時を変更後、[変更後にスケジュール実行を開始します]をオンにします。

    設定項目は、「スケジュール設定」を参照してください。
  4. 画面下部にある[適用]ボタンをクリックします。

    AWSマイグレーションのスケジュールの変更

12.6. AWSマイグレーションの再開

設定されている終了日付が過ぎていないマイグレーションのみ再開します。

  1. AWSマイグレーションの一覧画面から再開したいAWSマイグレーションにチェックを入れます。

  2. 画面上部の[再開]ボタンをクリックします。

  3. 問題が無ければ、画面下部にある[再開]ボタンをクリックします。

    AWSマイグレーションの再開

12.7. AWSマイグレーションの中断

スケジュールが有効なAWSマイグレーションのスケジュール実行を無効化します。
中断したもののスケジュールを再度有効化することはできません。

  1. AWSマイグレーションの一覧画面から中断したいAWSマイグレーションにチェックを入れます。

  2. 画面上部の[中断]ボタンをクリックします。

  3. 問題が無ければ、画面下部にある[中断]ボタンをクリックします。

    AWSマイグレーションの中断画面

12.8. AWSマイグレーションの削除

AWSマイグレーションの削除を行います。
対象のAWSマイグレーションから作成されたアセスメントや評価SQLセットを同時に削除しますが、ターゲットDBは削除されません。
[スナップショットからRDSインスタンス/AURORAクラスタを作成する]から作成した「ターゲットDBの削除」をする際、RDSインスタンスが削除可能な場合は削除します。

  1. AWSマイグレーションの一覧画面から削除したいAWSマイグレーションにチェックを入れます。

  2. 画面上部の[削除]ボタンをクリックします。

  3. 問題が無ければ、画面下部にある[削除]ボタンをクリックします。

    AWSマイグレーションの削除画面

12.9. AWSマイグレーション結果の確認

  1. スケジュールが実行中、またはスケジュールが終了したAWSマイグレーションに対してマイグレーション名を選択します。

    AWSマイグレーションの選択
  2. マイグレーションの設定情報ならびに、実行済みのアセスメントの一覧が表示されます。

    AWSマイグレーションの結果確認

    アセスメント結果をCSVファイル形式でダウンロードすることもできます。
    サマリー画面右上の[ダウンロード]ボタンをクリックすると、ダウンロード画面を表示します。
    取得したい情報を選択して[ダウンロード]ボタンをクリックすると、ZIP圧縮されたファイルのダウンロードを開始します。

    AWSマイグレーションの結果ダウンロード:実行時
    実行タイプに[実行]を選択した場合
    AWSマイグレーションの結果ダウンロード:パース
    実行タイプに[パース]を選択した場合
  3. さらにアセスメント名を選択することで、アセスメントサマリーを表示することができます。

    サマリー画面の詳細については、「サマリー」を参照してください。

12.10. AWSマイグレーション実行時のログファイル出力設定について

AWSマイグレーションでログ情報を取得するためには、RDSインスタンスまたはAurora DBクラスターにてログ出力の設定が必要です。

設定方法は、「Amazon RDS上でのログファイル出力設定」を参照してください。

12.11. AWSマイグレーション実行時に必要なIAM設定について

AWSマイグレーションを実施するためにはIAMロールの設定が必要です。

詳細は「必要なIAM設定について」を参照してください。

13. その他

13.1. ツール連携

失敗したSQLをユニークな形でファイル抽出します。
SQLを自動変換するツールを使用する際などに使用してください。
抽出単位は1SQLにつき1ファイルです。

通常のSQL実行評価までの手順は、以下の5ステップになります。

  1. ソースDBからSQL Testing Managerへ網羅的にSQLを蓄積

  2. SQL Testing Managerから評価SQLセットを作成

  3. ターゲットDBへ評価SQLセットを実行

  4. 実行結果を取得

  5. 実行結果の参照

ツール連携の場合は、続けて次の処理を行います。

  1. [失敗したSQLの抽出]失敗したSQLをユニークにし、1SQLにつき1ファイルの単位で抽出する

  2. 抽出したものを別途ツールに読み込ませ、自動修正等処理を行う

  3. 修正したSQL1つにつき1つのファイルとして保存する

  4. [修正を評価SQLセットに適用]修正したSQLを3で使用した評価SQLセットへマージする

  5. 再度ターゲットDBへ評価SQLセットを実行

  6. 実行結果を取得

  7. 修正したSQLがどれくらい修正できたか確認する

この手順を踏むことで、手動で修正するSQLの数を減らすことができます。

ツール連携の利便性について

以下、ツール連携にあたりSQL Testingに用意されている機能の詳細です。

13.1.1. 失敗したSQLの抽出

実行したSQLの結果から、失敗したSQLをユニークな形で抽出します。

  1. アセスメントのサマリー画面から[SQLの抽出]ボタンをクリックします。

  2. 「失敗」のステータスのみを選択して、実行に失敗したSQLファイルをダウンロードします。

ダウンロードしたZIPファイル内には、1SQLにつき1ファイルの単位でSQLが保存されています。
SQL自動変換ツールや、手動で修正など、任意の方法でSQLを修正してください。

13.1.2. 修正を評価SQLセットに適用

失敗したSQLの抽出で抽出したSQLを任意の方法で修正した後、評価SQLセットに修正したSQLを適用することで、修正したSQLにて再度アセスメントを実行します。

  1. 再度アセスメントを実行する評価SQLセットにチェックを入れます。

  2. 画面上部の[外部連携]ボタンをクリックします。

  3. 適用するファイルの[ファイルを選択]をクリックして、修正したSQLのCSVファイルを選択します。

  4. [適用]ボタンをクリックします。
    評価SQLセットの中身が更新されます。

13.2. ソースDB、ターゲットDBの型対応

ソースDBから取得可能なデータは以下のとおりです。

ソースDB SQL バインド変数値 バインド変数型

Oracle Database

PostgreSQL

×

SQL Server

×

×

MySQL

×

×

  • Oracle Databaseからデータを取得するPISO Target for Oracleは、デフォルトではバインド変数を取得しません。
    バインド変数を取得するには PISO Target for Oracleのマニュアルを参照し設定してください。

  • Amazon RDS for Oracleのバインド変数の取得については、PISO Managerインストールマニュアルの「監視対象がRDS for Oracleの機能と制限事項」を参照してください。

  • PISO Target for PostgreSQLは、デフォルトではバインド変数を取得しません。
    バインド変数を取得するにはPISO Target for PostgreSQLのマニュアルの「SQL実行時のパラメータの取得について」を参照し、設定してください。

  • バインド変数の取得には制限があります。「バインド変数について」を参照してください。

ターゲット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実行結果

SQLの実行結果のステータス情報を表します。

  • ope status success:成功

  • ope status failed:失敗、または、ターゲットDBでのみ失敗

  • icon status both failed:両DBで失敗

  • icon status different return:結果が相違

  • icon status performance degradation:性能が劣化

  • icon status failed only in test src db:テスト用ソースDBでのみ失敗

  • icon status corrected:修正済。修正が完了したSQLを表します。

  • icon status not corrected:未対処。未修正のSQLを表します。

PI Hash

SQLに付与する弊社独自のハッシュ値を表します。

詳細は「PI Hashについて」を参照してください。

SQL ID

SQLを識別するIDを表します。

DBユーザー

SQLを実行したDBユーザーを表します。

プログラム

ソースDBで取得したSQLを発行したプログラム名を表します。

オブジェクト

SQLに含まれるオブジェクト名を表します。

遅くなった割合(%)

ソースDBと比較してターゲットDBではSQLの実行時間が何%になったかの値を表します。
ソースDBでの実行時間が0秒の場合は計算することができません。

詳細は「0秒時の対応」を参照してください。

SQLテキスト

ソースDBから収集したSQLを表します。

バインド変数名

取得したSQL実行時に指定されたバインド変数の変数名を表します。

SQL開始時刻

ソースDBでSQLが実行された時刻を表します。

ログオン時刻

ソースDBでSQLが実行された際のセッションのログオン時刻を表します。

修正済みSQL

[SQLの修正]タブで保存された修正後のSQLを表します。

テスト用ソースDB実行時間(秒)

テスト用ソースDBへSQLの実行要求をしてから初回のレスポンスが返ってくるまでの時間を表します。
ネットワークを経由した時間が含まれます。

ターゲットDB実行時間(秒)

ターゲットDBへSQLの実行要求をしてから初回のレスポンスが返ってくるまでの時間を表します。
ネットワークを経由した時間が含まれます。

ソースDB実行時間(秒)

ソースDBのSQLの実行時間を表します。
PISOのSQLサンプリング間隔設定により、実行時間が0秒になる場合があります。

テスト用ソース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句による指定があるかどうかを表します。
行順序の比較で[完全一致]を選択した時以外はNULLになります。

収集時処理行数

PISO Targetで取得した時点のSQLの取得行数または処理行数を表します。
SQLがSELECTのときは取得行数、UPDATE、INSERT、DELETEの場合は処理行数を表します。

行取得中断

アセスメント実行時、行取得中断の有無を表します。

修正SQLセット適用(ターゲットDB)

修正SQLセットが適用されている場合「有り」、適用されていない場合「無し」を表示します。
SQL Testing 4.2以降で対応しています。

修正SQLセット適用(テスト用ソースDB)

2DBモードで修正SQLセットが適用されている場合「有り」、適用されていない場合「無し」を表示します。
SQL Testing 4.2以降で対応しています。

ログオフ時刻

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ダウンロードした際に使用しているカラム名の詳細です。

実行結果CSVファイルのカラム
項目名 説明

id

SQL実行結果に割り当てられる連番のIDです。

result

ターゲットDBでSQL実行した結果を表します。
success:SQLが成功した場合
failed:失敗した場合

resultCode

アセスメントによるSQL実行結果に割り当てたコードで、テスト対象SQLの成功・失敗を表します。

詳細は「APIドキュメント」の[アセスメント]>[resultCodeについて]を参照してください。

sqlId

SQLを識別するIDを表します。

piHash

SQLに付与する弊社独自のハッシュ値を表します。

詳細は「PI Hashについて」を参照してください。

sqlText

ソースDBから収集したSQLです。

bind

バインド変数情報の配列データを以下のようにJSON文字列形式で出力します。

ex [{"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」で表します。
SQL Testing 4.2以降で対応しています。

(source) patchApplied

2DBモードでの修正SQLセットの適用有無を「TRUE」「FALSE」で表します。
SQL Testing 4.2以降で対応しています。

elapsedTimeRatio

ソースDBと比較してターゲットDBではSQLの実行時間が何%になったかの値を表します。
ソースDBでの実行時間(elapsedTime)が0秒の場合は、アセスメント実行時に指定した[0秒の仮定値]をもとに計算されます。

詳細は「0秒時の対応」を参照してください。

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の取得行数または処理行数を表します。
SQLがSELECTのときは取得行数、UPDATE、INSERT、DELETEの場合は処理行数を表します。

elapsedTime

ソースDBでのSQL実行時間を表します。
SQLのサンプリング間隔により、実行時間が0秒になることがあります。

patchCreated

SQLのステータス情報を以下の2種類で表します。
0:未修正のSQL
1:修正済みのSQL

patchSqlText

ユーザーが修正したSQLを表します。
未修正の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文の取得結果に対する行比較結果を表します。
0:取得結果が順序を含めて完全に一致する
1:一致しない
2:取得結果を再ソートして一致する

queryHasOrder※1

クエリにORDER BY句による指定があるかどうかを表します。
TRUE:実行するSQLにORDER BY句による指定がある
NULL:上記以外の場合
行順序の比較で[完全一致]を選択した時以外はNULLになります。

※1 この項目は、ダウンロード画面で[テスト用ソースDBの情報も取得します]をオンにすると取得できます。

追加情報CSVファイルのカラム
項目名 説明

resultId

実行結果CSVの「id」に対応する値を表します。

rank

同一のresultIdのSQLに対して発見または適用された順番を表します。

applied

SQLに対して変更を加えたかどうかを示します。
変更を加えた場合は「1」、加えてない場合には「0」と表します。

type

分類を表します。

action

typeに対応する詳細説明です。

severity

深刻度を表します。

detail

type、actionに関連する詳細データのJSON文字列を表します。

13.9. 評価対象のSQLについて

ソースDBから取得するSQLが評価対象のSQLとなり、評価SQLセットとして登録、アセスメントされます。
SQLの取得方法によって、評価対象となるSQLが異なります。

評価対象のSQLについて
SQL取得方法 説明

PISO Managerの機能でSQLを取得する
PISOで蓄積したSQLに対してマイニングサーチを実行して評価SQLセットを作成する

  • SELECTとDML(Insert/Update/Delete)のみが評価対象となります。

  • RDS for MySQL、RDS for MariaDB、Amazon Aurora(MySQL互換エディション)に対して、PISOで蓄積したSQLを評価対象とする場合、行コメントのあるSQLを正しく評価することができません。

  • バインド変数のNULLと空文字の区別ができません(アセスメント時は双方とも空文字として扱われます)。

  • 依存オブジェクトが存在しないSQLは評価対象になりません。例えば、「select 1;」「select version();」は取得しません。

SQL Testingの機能でSQLを取得する

  • 評価SQLセットの新規作成でAmazon RDSからSQLを取得

  • 評価SQLセットの新規作成でAmazon CloudWatch LogsからSQLを取得

  • AWSマイグレーション機能からSQLを取得して評価SQLセットを作成

  • Amazon RDSのログファイルに出力されたものを評価対象とします。

    • 結果の反映(トランザクション)オプションは、評価対象のSQLに「COMMIT」や「ROLLBACK」などのトランザクション制御文が含まれている場合に、アセスメント自体の「元に戻すオプション」は正しく動作しません。

    • RDS for PostgreSQL、Amazon Aurora(PostgreSQL互換エディション)では標準ログと監査ログ(pgAudit)での出力を対象とします。

      監査ログ(pgAudit)の場合、以下の制限があります。
      • バインド変数のNULLと空文字の区別ができません(アセスメント時は双方とも空文字として扱われます)。

      • PL/pgSQL内のSQL実行がpgAuditログに出力されているものについては、評価対象とはしません。

      標準ログの場合、以下が取得できます。

      標準ログ、かつ「application_name」が設定されている場合は「プログラム」が取得できます。

    • RDS for MySQL、Amazon Aurora(MySQL互換エディション)では一般ログ(general log)での出力を対象とします。

ソース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セットの作成は完了します。

CSVファイルの属性
属性

文字コード

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ユーザーのログイン時刻です。
書式:YYYYMMDDHHmmss
icon ex 20210630152047

Logged Out

いいえ

SQLを実行したOracleユーザーのログオフ時刻です。

DB User

はい※3

Oracleユーザー名です。

SQL Start Time

はい※4

SQLの実行開始時刻です。
書式:YYYYMMDDHHmmss
icon ex 20210630152047

SQL Start Time(Micro Sec)

はい※4

SQLの実行開始時刻(マイクロ秒)です。
書式:6桁までの正の整数値

SQL End Time

いいえ

SQLの実行終了時刻です。

SQL Text

はい

SQL文です。

SQL Hash

いいえ※5、6

SQL Textに対応するハッシュ値です。

PI Hash

いいえ※5、6

SQL Textからリテラルを除いた構造に対応するハッシュ値です。

Bind Variables

はい※7

バインド変数です。
空文字列でも実行可能です。
書式:#1(3):abc #2(1):5 …​、または
#1(3,1):abc #2(1,1):1 …​

詳しい書式は、「Bind Variablesの書式について」を参照してください。

Object

はい

アクションの対象オブジェクトです。
空文字列でも実行可能です。
ソース環境情報です。

Rows Processed

いいえ

PISO Targetで取得した時点のSQLの取得行数または処理行数を表します。

Elapsed Time

はい

SQL実行にかかった時間(秒)の実数値です。
値が無ければ0.0になります。

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)と記載された場合、バイト数とデータ型を意味します。
 icon ex 1個目のバインド変数を数値、2個目のバインド変数を文字列扱いとする場合
  #1(3,2):123 #2(3,1):123

13.10.1.1. Bind Variablesの書式について
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ポートを閲覧します。

    • コマンドicon ex : ssh -L 8025:localhost:8025 {user}@{host}

  • Webコンソールのリッスンアドレスをlocalhostから変更し、ファイアウォールで8025ポートを開けることで閲覧可能ですが、認証がないため非推奨です。

13.12.6. SMTP設定方法

  1. /etc以下のファイル編集とサービス操作はroot権限で行ってください。

  2. /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" . }}'
  3. 動作確認
    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を表示している画面において、以下のような制限があります。

  • アセスメントサマリーおよびアセスメントのSQL一覧では、画面サイズに応じて内容を表示します。

  • 評価SQLセットおよび修正SQLセットのSQL一覧では、最大10000文字までのSQLを表示します。

  • SQL詳細画面では、利用環境の利用可能メモリ量などの状況により、表示できない場合があります。

14.3. AWSマイグレーション機能について

取得対象のソースDBに対するSQL実行のセッションがスケジュールの切り替わるタイミングをまたがっている場合、スケジュール切り替わり前から実行されていたセッションによるSQLを評価対象とすることができません。

14.4. Amazon RDSのログ制限

  • PISO Managerを用いない場合に、UTF-8以外の収集元データベースと発行SQLは対応していません。
    icon ex サーバー側(RDS)の符号化方式をUTF-8以外(EUC-JP、Shift_JIS等)に設定している場合、RDSからログを取得して評価SQLセットを作成することはできません。

  • COPYコマンドの実行は対応していません。
    icon ex COPY pg_class TO '/pg_class_file'; の場合、パース(構文チェック)は可能です。ただし実行(実際にテーブルをコピーしてファイルに出力)はできません。
    評価SQLセットにCOPYコマンドが含まれている場合、アセスメント実行時はCOPYコマンドをスキップします。実行結果はエラーとして扱います。

  • ログ文中に複数のSQLが連結されている場合の実行は対応していません。
    icon ex 下記のように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ログは下記形式を想定しています。

icon ex
{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のフォーマットは、以下の例を参考にしてください。

icon ex
{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アカウントのルートユーザーを参照してください。
  • 権限の設定については、 IAMでのセキュリティのベストプラクティス を参照してください。

  • 導入手順については 「SQL Testing Managerの構築と設定(EC2の場合)」を参照してください。

  • SQL Testing ManagerはシングルAZ構成のみをサポートしています。マルチAZ構成/マルチリージョン構成はサポートしていません。

  • SSHを使用してインスタンスに接続する場合は、EC2起動時にキーペアを指定する必要があります。キーペアの指定については Amazon EC2のキーペアとAmazon EC2インスタンス を参照してください。

  • バックアップ時に生成されるEBSのスナップショットや、EBS暗号化においてKMSのカスタマー管理型のキーを使う場合など、利用するサービス・設定により、サービス利用にかかる費用が別途発生します。

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ファイルに証明書のパスを以下のように記述します。
      icon ex /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. 自動バックアップの設定について

以下の手順で自動バックアップを設定します。

  1. Amazon EC2コンソールから[Elastic Block Store]>[ライフサイクルマネージャー]>[ライフサイクルポリシーの作成]を選択します。

    lifecyclemanager
  2. 以下を設定して、ファイルサイクルポリシーを作成します。

    • ポリシータイプ: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)
  1. Amazon EC2コンソールから[イメージ]>[AMI]を選択します。ライフサイクルマネージャーから作成されたAMIには、dlm:managed というタグが付与されています。

    dlm-ami
  2. インスタンスタイプを選択します。

    インスタンスタイプは、AWS Marketplaceから導入時に許可されているインスタンスタイプのみ選択することが可能です。許可されていないインスタンスタイプを選択するとエラーとなります。
  3. 以降のインスタンス起動の設定は、導入時のインスタンス起動手順と同じです。

  • バックアップ実行時の状態により、バックアップから復旧したEC2インスタンスでWebコンソールにアクセスできない場合があります。その場合、一度、EC2インスタンスを再起動し、再度アクセス可能か確認してください。

  • SQL Testing Managerでのadministratorなどのユーザーのパスワードは、バックアップ元のEC2インスタンスの環境の情報が引き継がれます。
    既定のadministratorのパスワードは、EC2のインスタンスIDですが、このインスタンスIDは、バックアップ元の環境のインスタンスIDであることに注意してください。

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インスタンスを再起動することでアプリケーションを再起動できます。

  1. EC2インスタンスの一覧より対象のEC2インスタンスを選択し、右クリックで表示されるメニューから、[EC2インスタンスの開始]もしくは[EC2インスタンスの再起動]を選択してください。

  2. EC2インスタンスが起動後、SQL Testing Manager Webコンソールへアクセスしてログイン可能であることを確認してください。

15.7.3. 現在のEC2をそのまま起動させることができない障害時の復旧

起動中のEC2が存在するAZに障害が発生するなど、現在のEC2インスタンスをそのまま起動させることができない障害が発生している場合、取得済みのバックアップから別AZでインスタンスを起動することでアプリケーションを稼働させることが可能です。
「バックアップからの復旧」 の手順に従い、正常なAZでバックアップ取得したAMIからEC2インスタンスを起動してください。