【再掲載】Database Migration Assistant for Unicode(DMU)ってなぁに？ 2/4

2023年5月2日 2023年5月2日「DBひとりでできるもん」運営チーム + 責任者_山本

「DBひとりでできるもん」運営チーム + 責任者_山本

前回のおさらい
キャラクタセット変更時における問題点の検知
さいごに

前回のおさらい

みなさん、こんにちは。
前回は、DMUとはどんなものか？ということをお伝えしました😊
いかがでしたでしょうか？是非、前回の記事も見て頂けると嬉しいです。

今回は、実際にDMUを使用し、キャラクタセット変更時における問題点の検知を行っていきます。

※今回使用した検証環境は以下の通りです。

DMU	2.1.1
DB	12.1 single
OS	RHEL 7.3

画像引用元：DMUダウンロードサイト

キャラクタセット変更時における問題点の検知

前回、キャラクタセット変更の大きな流れは以下のようになるとお伝えしました👀
1. 問題点の検知
2. 問題点の解消
3. キャラクタセットの変更

今回は、最初のプロセスである「キャラクタセット変更時における問題点の検知」を検証していきたいと思います。
※キャラクタセットを JA16SJISTILDE から AL32UTF8 に変更する前提で検証します。

DBのキャラクタセットおよび検証用のテーブルを確認

--現状のキャラクタセットを確認します💻

SQL> select * from nls_database_parameters where parameter=’NLS_CHARACTERSET’;
PARAMETER              VALUE
----------------   ------------------	
NLS_CHARACTERSET     JA16SJISTILDE

JA16SJISTILDE ですね。

--検証用のテーブル(testテーブル)を確認します💻

SQL> select * from test;
COL1          COL2
-----------  ------------
ひれ          りぶろーす
さーろいん     はらみ
　
SQL>Select TABLE_NAME,COLUMN_NAME,DATA_TYPE,DATA_LENGTH 
from user_tab_columns where TABLE_NAME='TEST';
 
TABLE_NAME 　COLUMN_NAME    DATA_TYPE      DATA_LENGTH
----------   -----------    -----------    ----------- 
TEST          COL1             VARCHAR2        10 
TEST          COL2             VARCHAR2        1000

testテーブルには、COL1とCOL2というカラムが存在し
COL1には最大バイト数と同バイト数の ”さーろいん” というデータが格納されています。

前回、JA16SJISTILDE と AL32UTF8 では、同じデータであっても、異なるバイト数で格納されることをお伝えしました。

そのため、キャラクタセットをこのまま AL32UTF8 に変更すると、testテーブルにおける
COL1のデータ ”さーろいん” は最大バイト数を超え、溢れてしまいます。

DMUはこの問題点を検知してくれるでしょうか？

DMU による問題点の検知

DMUを起動した後、DMUとDBの接続を確立します。

DBへの接続が完了した後、リポジトリのインストールを行います。
この手順の中で変更後のキャラクタセットを選択します。

ターゲットキャラクタセットに AL32UTF8 を選択します。

リポジトリのインストールが完了した後、キャラクタセット変更時における問題点の検知が可能になります。
DMUではこの操作を「スキャン」と呼びます。
「スキャン」はデータベース全体、スキーマ単位、テーブル単位で実行可能です。

スキャン結果は「スキャンレポート」からカラム単位で確認することができます。
TESTテーブルにおけるCOL1のOver Column Limitが1となっており、
データが溢れてしまうことを事前に検知しています。

スキャンレポートは、検索して結果を確認することも可能です。
例えば、一つ目の画像はデータが溢れてしまうカラムだけを検索、
二つ目の画像は問題が発生しているカラムだけを表示する検索方法を指定しています😊

また、スキャンレポートをHTML形式で出力することも可能です。

以下はHTML出力例です。

DMUによる問題点の検知の所要時間

参考程度ですが、スキャンにかかる時間も検証してみました。
※テーブル単位でスキャンしています。
平均すると1秒あたり約289MBスキャンしているようです。

＜テーブルサイズとスキャンの所要時間＞

件数（万件）	サイズ(MB)	所要時間（秒）	1秒あたり(MB)
100	2628	14	187.7143
200	5247	21	249.8571
300	7871	32	245.9688
400	10431	36	289.75
500	13055	32	407.9688
600	15679	52	301.5192
700	18303	59	310.2203
800	20863	74	281.9324
900	23487	79	297.3038
1000	26111	83	314.5904

さいごに

以上で、問題点の検知は終了です。

DMUは、想定した問題点をしっかり検知してくれましたね。
カラム単位で結果を確認できるため、
どのカラムに対して対処すべきかという判断がつきやすい点が非常に助かります。

スキャン操作も簡単で、検索や絞り込みができるので結果も見やすいですね🌸

次回は検出した問題点の解消をしていきたいと思います。
よろしくお願いいたします😆

投稿者プロフィール

「DBひとりでできるもん」運営チーム + 責任者_山本

「親しみやすさと技術力」をテーマに、技術情報・サービス・インフラ系資格取得に役立つ情報、社員等の情報をお届けします。
90名強の事業部員で鋭意、執筆中です。
少しでも当社を知って頂けるよう、愛情込めて頑張ります！
※facebook、X(旧twitter)、インスタグラムでは「DBひとりでできるもん」の更新情報を発信しています。