Database Migration Assistant for Unicode(DMU)ってなぁに？ 2/4

2020年4月16日 Oracle Database 管理

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

前回のおさらい

みなさん、こんにちは。
前回は、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