前回のおさらい
みなさん、こんにちは😊
前回は、DMUを使用してキャラクタセット変更時の問題点を検知しました。
いかがでしたでしょうか？
今回は、検知した問題点の解消をしていきたいと思います。
宜しくお願い致します。
※今回使用した検証環境は以下の通りです。
| DMU | 2.1.1 |
|---|---|
| DB | 12.1 single |
| OS | RHEL 7.3 |
画像引用元：DMUダウンロードサイト
バックナンバー
●1回目 DUMとはどんなものか？
●2回目 キャラクタセット 変更時における問題点の検知
こちらも是非見てくださいね🌸
キャラクタセット変更時の問題点の解消
初回に、キャラクタセット変更の大きな流れは以下のようになるとお伝えしました😆
1. 問題点の検知
2. 問題点の解消
3. キャラクタセットの変更
今回は2つ目のプロセス、「問題点の解消」を検証していきたいと思います。
※キャラクタセットを JA16SJISTILDE から AL32UTF8 に変更する前提で検証します。
DMUによる問題点の解消
以下は前回もお見せした、スキャンの結果です。
このままキャラクタセットの変更をすると、TESTテーブルのCOL1のデータが溢れてしまうという問題があります。
問題を解消する前に対象のカラムの現状を確認してみましょう👀
–問題解消前にカラムの最大バイト数を確認
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
ではこの問題を解消していきましょう❗
対象のテーブル名を右クリックし、Cleansing Editorを選択します。
すると、問題の原因となるデータが色付けされた状態で表示されます。
次に対象のデータを右クリックし、Modify Columnを選択します。
今回はカラムの最大バイト数を10バイトから15バイトに拡張したいと思います。
–変更後にカラムの最大バイト数を確認。無事変更されています！
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 15
TEST COL2 VARCHAR2 1000
補足ですが、カラムの最大バイト数は以下のSQLでも変更可能です。
SQL> alter table test modify(col1 varchar2(15));
どちらの方法でも問題ありませんが、DMUは問題のあるデータを色付けして表示してくれるので
視覚的に分かり易いですね❗
問題点が解消されたので、再度スキャンを実行し、スキャンレポートを見てみます。
Over Column Limitが0になり、スキャンレポートからも問題点が解消されていることを確認できました🍒
さいごに
以上で、問題点の検知は終了です。
しっかり問題点を解消してくれていましたね🌸
いかがでしたでしょうか？
次回はついに、 キャラクタセット の変更を検証していきたいと思います。
よろしくお願いいたします😆
バックナンバー
●1回目 DUMとはどんなものか？
●2回目 （ キャラクタセット 変更時における問題点の検知）
投稿者プロフィール
