![](https://xn--w8j8bac3czf5bl7e.com/wp-content/uploads/blog/risu-e1567145532667.png)
目次
前回のおさらい
みなさん、こんにちは。
前回は、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は、想定した問題点をしっかり検知してくれましたね。
カラム単位で結果を確認できるため、
どのカラムに対して対処すべきかという判断がつきやすい点が非常に助かります。
スキャン操作も簡単で、検索や絞り込みができるので結果も見やすいですね🌸
次回は検出した問題点の解消をしていきたいと思います。
よろしくお願いいたします😆
投稿者プロフィール
![技術チーム](https://xn--w8j8bac3czf5bl7e.com/wp-content/uploads/blog/41007909421_6ae3fe3ef0_z-150x150.jpg)
Oracle Cloud2024年9月3日OCIとADアカウント連携してみました
インフラ2024年6月21日Zabbixエージェントをインストール・対象サーバを監視してみました!
Infrastructure(IaaS)2024年6月4日OCI ブート・ボリュームのバックアップ・リストア
Oracle Cloud2024年5月31日OCIのMySQLでリードレプリカを構成してみました!