しばちょう先生の試して納得！DBAへの道 indexページ▶▶
みなさん、こんにちは。先日、Japan Oracle User GroupのJPOUG Tech Talk Night #5にてお話する機会を頂き、沢山の方から本連載を読んで頂いているというフィードバックを頂戴致しました。非常に嬉しく、本当に光栄であり、引き続き頑張って執筆し続けていこうと改めて決意しました、”しばちょう”こと柴田長（しばた つかさ）です。
今回も引き続き、Oracle Automatic Storage Management（略して、ASM）の世界をお届けします。前回はASMに実際に触れて頂き、ASMディスクやASMディスク・グループの実体や関係性を中心としてデータの冗長性（二重化、三重化）を理解して頂きましたが、今回はASMの真骨頂でもある「リバランス」を通して、ストライピングの状況やASMディスクを追加することによるI/O性能の向上を体験して頂きたいと考えています。既に利用されたことのある方はご同意頂けると思いますが、このリバランス機能はRAWデバイス上にデータファイルを配置してデータベースを運用されていたDBAの方にとって、圧倒的な衝撃を感じて頂ける機能だと思います。
DBAにとって必要なスキルは何でしょう？SQLチューニングはもちろん必要なスキルですが、I/O性能を最大限に引き出すことができることもまた同じぐらい重要なスキルだと私は考えています。例えば、RAWデバイスを使用していたケースでは全表のアクセスタイプやアクセス量を分析予想し、初期データ量と成長率を考慮した結果、最適なRAWデバイスの配置場所を決定しますが、この作業には1ヶ月～3ヶ月と非常に時間を要していた経験をお持ちだと思います。さらに、データベースが稼働し始めた後は、アプリケーションの改修や新機能が追加されることで当初の想定からは大きくI/Oパターンやデータ量が異なってきて、結果的に特定のRAWデバイスのI/Oがボトルネックとなり、データベース全体の性能劣化が起きることも珍しくはないでしょう。そして、これをチューニングするスキルを身につけるには長年の経験と非常に高いスキルが必要とされていたと思います。
前置きが長くなりましたが、ASMを使用すればそのような作業や心配を大幅に削減することが可能となりますよーという部分を今回の演習において体験して頂きたいと思っています。今回は是非ともこの機会にASMを自分のものにしてしまいましょう。
なお、今回の演習は前回同様に、仮想化ソフトウェアであるOracle VM VirtualBoxで作成した仮想環境で検証を進めさせて頂きます。Oracle Technology Networkで公開されているOracle Database 11g(11.2.0.4) on VirtualBox構築ガイド内の「Oracle VM VirtualBox を用いた Oracle Real Application Clusters(RAC)11g Release 2 環境の構築」を参考にして検証環境を作成してみてください。
こちらは2ノードRAC環境の構築ガイドとなっていますが、手順「6. 仮想マシンのクローンとクローン後の設定」をスキップして、続く手順「7. Oracle Grid Infrastructure インストールおよび構成」の「5. インストール・オプションの選択」画面において『スタンドアロン・サーバー用のOracle Grid Infrastructureの構成』を選択することで、Oracle Restart環境（ASMを使用したシングル・データベース環境）を作成することが可能です。もちろん、手順通り実施して2ノードRAC環境を構成して頂いても、以降の演習には影響はございません。
※以降の演習問題及び解答例は、前回の演習1を実施済みである前提で記述させて頂いておりますのでご注意ください。
1. 前回使用したOracle VM VirtualBoxのOracle Database 11g Release 2環境において、新規に1GBの仮想ハードディスク・ドライブを1つ追加して、ASMインスタンスにおいてASMディスクとして認識可能な状態として下さい。 ただし、今回の検証結果の効果を見易くする目的として、可能であれば、その仮想ハードディスク・ドライブの実体（.vmdkファイル）は、前回使用した既存の4つとは異なる記憶媒体（デバイス）上に保存して下さい。
[root@vm11204]# fdisk /dev/sdn <-- 環境に合わせて、新規に追加されたデバイス名を指定して下さい。 Command (m for help): p <ENTER> Disk /dev/sdj: 1073 MB, 1073741824 bytes 255 heads, 63 sectors/track, 130 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x6eba0f6f Device Boot Start End Blocks Id System Command (m for help): n <ENTER> Command action e extended p primary partition (1-4) p <ENTER> Partition number (1-4): 1 <ENTER> First cylinder (1-130, default 1): 1 <ENTER> Last cylinder, +cylinders or +size{K,M,G} (1-130, default 130): <ENTER> Using default value 130 Command (m for help): w <ENTER> # 新規に切り出したパーティションのオーナーとパーミッションを変更 [root@vm11204]# chown grid:asmadmin /dev/sdn1 [root@vm11204]# chmod 660 /dev/sdn1 [root@vm11204 dev]# ls -lrt /dev/sdn1 brw-rw----. 1 grid asmadmin 8, 145 Jun 2 21:06 sdn1 # 必要に応じて、udevの設定を見直しておく [root@vm11204]# cat /etc/udev/rules.d/99-oracle.rules KERNEL=="sd[b-z]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="0660" [grid@vm11204]$ sqlplus / as sysasm SQL> drop diskgroup DG_HIGH ; SQL> set linesize 150 pages 500 col NAME for a12 col HEADER_STATUS for a14 col PATH for a20 select GROUP_NUMBER, DISK_NUMBER, NAME, HEADER_STATUS, PATH from V$ASM_DISK where GROUP_NUMBER = 0 order by PATH ; GROUP_NUMBER DISK_NUMBER NAME HEADER_STATUS PATH ------------ ----------- ------------ -------------- -------------------- 0 1 CANDIDATE /dev/sdn1
こちらのオペレーションは前回の演習1,2とほぼ同じですので問題は無いかと思います。上記の手順は前述したガイド「Oracle VM VirtualBox を用いた Oracle Real Application Clusters(RAC)11g Release 2 環境の構築」の「5.11 記憶域の確認と準備」においても解説されている内容ですので、ここでの説明は割愛させて頂きます。
ここでは、演習問題に書かせて頂いた条件「ただし、今回の検証結果の効果を見易くする目的として・・・」について補足しておきます。既存の仮想ハードディスク・ドライブ用の.vmdkファイルは恐らく同一のデバイス上に配置されているかと予想しておりますが、今回新たに追加した.vmdkファイルはそれらとは別のデバイス上に配置して頂くことで、ASMのストライピング及びリバランスの効果を体験して頂くことが可能となります。もしも、全て同じデバイス上に配置された場合には、ストライピングの状態を見ることは出来ますが、その効果を体感することが難しいかもしれません。ちなみに、私の検証環境では、既存の4つの.vmdkファイルはノートPCに搭載されているSSD上に配置していたので、新規分についてはRAMディスク上に配置しています。RAMディスクでなくとも、外付けのHDD/SSD、USBメモリでも代用することが出来ますので、可能な限り、別デバイス上に配置してみてくださいね。
以降の演習と解説で使用する用語の認識を合わせておきたいと思います。
- 既存デバイス: /dev/sdj1, /dev/sdk1, /dev/sdl1, /dev/sdm1
- 新規デバイス: /dev/sdn1
2. 既存デバイスで構成されているASMディスク・グループを削除し、3本の既存デバイスで構成される標準冗長なASMディスク・グループ「DG_NORMAL」を新規作成して下さい。
[oracle@vm11204]$ sqlplus / as sysdba
SQL> drop tablespace TBS30 including contents and datafiles ;
[grid@vm11204]$ sqlplus / as sysasm
SQL> drop diskgroup DG_HIGH ;
SQL>
set linesize 150 pages 500
col NAME for a12
col HEADER_STATUS for a14
col PATH for a20
select GROUP_NUMBER, DISK_NUMBER, NAME, HEADER_STATUS, PATH
from V$ASM_DISK
where GROUP_NUMBER = 0
order by PATH ;
GROUP_NUMBER DISK_NUMBER NAME HEADER_STATUS PATH
------------ ----------- ------------ -------------- --------------------
0 4 FORMER /dev/sdj1
0 0 FORMER /dev/sdk1
0 2 FORMER /dev/sdl1
0 3 FORMER /dev/sdm1
0 1 CANDIDATE /dev/sdn1
SQL>
create diskgroup DG_NORMAL
normal redundancy
disk '/dev/sdj1', '/dev/sdk1', '/dev/sdl1'
attribute
'COMPATIBLE.ASM' = '11.2.0.2',
'COMPATIBLE.RDBMS' = '11.2' ;
こちらも前回の復習となりますね。注意点は、ASMディスク・グループ「DG_HIGH」を削除する前にその上に作成していた表領域をまずは消しておく必要がありましたよね。
ASMディスク・グループを削除後、そのASM ディスク・グループに所属していたASMディスクのHEADER_STATUSを確認してみると、「FORMER」と表示されていることに気付いたと思います。一方で、演習1で新規追加したASMディスク「/dev/sdn1」に関しては「CANDIDATE」と表示されています。このステータスの違いは気になる所ですよね。と言う事で、マニュアル「Oracle Databaseリファレンス」で「V$ASM_DISK」ビューを確認してみましょう。すると全部で8つのステータスの種類があることが分かりますね。ここでは「FORMER」と「CANDIDATE」についてだけ抜粋しておきます。
FORMER – ディスクは以前、ディスク・グループのメンバーであったが、グループから完全に削除されている。これは、ALTER DISKGROUP文を使用して新しいディスク・グループに追加できる。
CANDIDATE -ディスクはディスク・グループのメンバーではなく、ALTER DISKGROUP文を使用してディスク・グループに追加できる。
つまり、・・・どちらのステータスであっても、どのASMディスク・グループにも属していないので、好き勝手に使用することが出来る状態と言う事が理解出来たかと思います。と言う事で、3本の既存デバイスを含めた標準冗長性「NORMAL REDUNDANCY」なASMディスク・グループをサクッと作成出来ましたよね。これも前回の復習ですよー。
3. 演習2で作成したASMディスク・グループ「DG_NORMAL」に属する各ASMディスクの空き容量を確認して下さい。
[grid@vm11204 ~]$ sqlplus / as sysasm
SQL>
set lines 110 pages 500
col NAME for a10
col STATE for a10
col TYPE for a8
col COMPATIBILITY for a15
col DATABASE_COMPATIBILITY for a15
select GROUP_NUMBER,
NAME,
TYPE,
TOTAL_MB,
FREE_MB,
HOT_USED_MB + COLD_USED_MB "USED_MB",
REQUIRED_MIRROR_FREE_MB,
USABLE_FILE_MB
from V$ASM_DISKGROUP
where NAME = 'DG_NORMAL' ;
GROUP_NUMBER NAME TYPE TOTAL_MB FREE_MB USED_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
------------ ---------- ------ -------- ------- ------- ----------------------- --------------
3 DG_NORMAL NORMAL 3057 2898 159 1019 939
SQL>
col NAME for a15
col HEADER_STATUS for a14
col PATH for a12
col FAILGROUP for a16
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, PATH, NAME, TOTAL_MB, FREE_MB
from V$ASM_DISK
where GROUP_NUMBER = 3
order by 2 ;
GROUP_NUMBER DISK_NUMBER HEADER_STATUS PATH NAME TOTAL_MB FREE_MB
------------ ----------- -------------- ------------ --------------- ---------- ----------
3 0 MEMBER /dev/sdj1 DG_NORMAL_0000 1019 966
3 1 MEMBER /dev/sdk1 DG_NORMAL_0001 1019 966
3 2 MEMBER /dev/sdl1 DG_NORMAL_0002 1019 966
こちらも前回の復習となりますので、簡単に捌けたかと思います。V$ASM_DISKGROUPビューから対象のASMディスク・グループのGROUP_NUMBER=3を導き、その情報を使用してV$ASM_DISKビューへ問い合わせることで目的の各ASMディスクの空き容量（V$ASM_DISK.FREE_MB）を確認することが可能ですね。この値は冗長性を考慮してはいない点も思い出しておいてください。つまり、合計で2898MBの空き容量がありますが、標準冗長性（2重化）であるこのASMディスク・グループにおいては実際に作成可能な表領域のサイズはその半分以下になりましたよね。
V$ASM_DISKGROUPビューにおいてはその値の意味が捉えづらい列もありますが、ASMディスク・グループの耐障害性を説明してからの方がスムーズに解説できると思いますので、この点については今後の連載に期待しておいてください。
4. ASMディスク・グループ「DG_NORMAL」上に1200MBのビッグファイル表領域「TBS31」を作成することで、各ASMディスクの空き容量がそれぞれどのように変化するのかを確認して下さい。
[oracle@vm11204]$ sqlplus / as sysdba
SQL>
create bigfile tablespace TBS31
datafile '+DG_NORMAL(DATAFILE)' size 1200M
extent management local
uniform size 4m
segment space management auto;
select TABLESPACE_NAME,
EXTENT_MANAGEMENT,
ALLOCATION_TYPE,
SEGMENT_SPACE_MANAGEMENT,
BIGFILE
from DBA_TABLESPACES
where TABLESPACE_NAME = 'TBS31' ;
TABLESPACE_NAME EXTENT_MAN ALLOCATIO SEGMEN BIG
------------------------------ ---------- --------- ------ ---
TBS31 LOCAL UNIFORM AUTO YES
[grid@vm11204 ~]$ sqlplus / as sysasm
SQL>
set lines 110 pages 500
col NAME for a15
col HEADER_STATUS for a14
col PATH for a12
col FAILGROUP for a16
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, PATH, NAME, TOTAL_MB, FREE_MB
from V$ASM_DISK
where GROUP_NUMBER = 3
order by 2 ;
GROUP_NUMBER DISK_NUMBER HEADER_STATUS PATH NAME TOTAL_MB FREE_MB
------------ ----------- -------------- ------------ --------------- ---------- ----------
3 0 MEMBER /dev/sdj1 DG_NORMAL_0000 1019 157
3 1 MEMBER /dev/sdk1 DG_NORMAL_0001 1019 158
3 2 MEMBER /dev/sdl1 DG_NORMAL_0002 1019 157
久しぶりのビッグファイル表領域の作成でしたが、問題無く実行出来ましたよね？この演習でも新しいことは何も実行していませんが、改めてコメントしておきたい事があります。
表領域を作成後の各ASMディスクの空き容量（FREE_MB）をじっくり見てください。いかがでしょう? 3つのASMディスクの空き容量が均等に減少している事が一目瞭然ですよね。「こんなの当たり前じゃん」なのですが、今一度噛みしめてみてください。均等に減少したと言う事は、均等に使用されたと言う事です。つまり、3つのASMディスクに表領域のデータファイルが均等分散されていることが簡単にイメージすることが出来ると思います。これがASMのストライピングの特徴となります。ASMのストライピングはデータファイル毎に、全ASMディスクへ均等分散するという特徴を覚えておいてくださいね。
また、もう一つ噛みしめて頂きたいのは、皆さんは表領域を作成しただけですよね。と言う点です。実際にはまだレコードをINSERTしたわけでもなく、表セグメントさえも作成していない状態ですが、ASMディスク・グループ上には既に領域が割り当てられていると言う事も改めて見直してみると「あ、そうだ！」と、気付いて頂けたのであれば幸いです。この気付きと言うのはかなり深く記憶に残ると思います。なので、シミジミと実機を使用した体験と言うのは大切だと思うのです。
5. 演習4で作成した表領域「TBS31」上に、約1GBの表「TAB31」を作成して下さい。TAB31表の第一カラムはNUMBER型、第二、第三カラムはCHAR(1000)型と
[oracle@vm11204]$ sqlplus / as sysdba
SQL>
create user TRY identified by TRY default tablespace TBS31 ;
grant CONNECT, RESOURCE to TRY ;
connect TRY/TRY
create table TAB31 (COL1 number, COL2 char(1000), COL3 char(1000)) tablespace TBS31 ;
create sequence SEQ1 start with 10000001 increment by 1;
insert /*+append */ into TAB31
select SEQ1.nextval, 'a', 'b'
from (select 0 from all_catalog where rownum <= 1024),
(select 0 from all_catalog where rownum <= 3*128);
commit ;
col SEGMENT_NAME for a16
select SEGMENT_NAME, BYTES/1024/1024, BLOCKS from USER_SEGMENTS ;
SEGMENT_NAME BYTES/1024/1024 BLOCKS
---------------- --------------- ----------
TAB31 1032 132096
はい、こちらも問題無いでしょう。これまで何度となく体験してきて頂いていますからね。私はいつもと少しだけ変えて、直積を使用したレコード生成を書いてみましたよ。
さて、いよいよ後半戦に突入です。ここまでで既に原稿9枚目に入っていること気付いた私だったりしますが・・・頑張りましょう。
6. 演習5で作成した表「TAB31」に対して全表検索が実行されるSELECT文を3回実行して下さい。
[oracle@vm11204]$ sqlplus /nolog
SQL>
-- 今回の計測においてDYNAMIC SAMPLINGを発生させたくない為、統計情報を取得しておく
connect TRY/TRY
exec dbms_stats.gather_table_stats(ownname=>'TRY', TABNAME=>'TAB31') ;
-- Buffer Cache上のデータブロックをクリア
connect / as sysdba
alter system flush buffer_cache ;
-- 全データをHDDから読み取る際の性能を測定
connect TRY/TRY
set timing on
select count(*) from TAB31 ;
COUNT(*)
----------
393216
Elapsed: 00:00:09.31
Elapsed: 00:00:09.11
Elapsed: 00:00:09.14
* あくまで演習の理解を深める目的で性能値を掲載させて頂いております。実行環境によって前後する値となりますので、全ての環境においてこの性能を保証するものではございません。
いかがですか？おおよそ9.1～9.3秒程度で検索できたのではないでしょうか。TAB31表には索引を作成していないので、単純にCOUNT(*)すれば全表検索になります。ただし、実行時間がブレてしまう可能性を排除する目的として、測定前の準備としてオプティマイザ統計情報を取得しておくこと（動的サンプリング（DYNAMIC SAMPLING）機能が有効にならないようにする為）、さらには、バッファ・キャッシュ上のデータをフラッシュすること（必ず、ASMディスク上からデータを読み込むようにする為）は忘れないでくださいね。
私の検証環境の3本のASMディスク（既存デバイス）で構成されているASMディスク・グループにおいては、約9.1のレスポンス・タイムだったと言う事です。この値がどのように変化していくのかに注目して、以降の演習に取り組んでみてください。
7. 新規デバイス（/dev/sdn1）のASMディスクを、ASMディスク・グループ「DG_NORMAL」へ追加して下さい。ただし、リバランスは実行しないでください。また、追加後の各ASMディスクの空き容量も確認して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
alter diskgroup DG_NORMAL add disk '/dev/sdn1' rebalance power 0 ;
Diskgroup altered.
SQL>
col NAME for a15
col HEADER_STATUS for a14
col PATH for a12
col FAILGROUP for a16
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, PATH, NAME, TOTAL_MB, FREE_MB
from V$ASM_DISK
where GROUP_NUMBER = 3
order by 2 ;
GROUP_NUMBER DISK_NUMBER HEADER_STATUS PATH NAME TOTAL_MB FREE_MB
------------ ----------- -------------- ------------ --------------- ---------- ----------
3 0 MEMBER /dev/sdj1 DG_NORMAL_0000 1019 157
3 1 MEMBER /dev/sdk1 DG_NORMAL_0001 1019 158
3 2 MEMBER /dev/sdl1 DG_NORMAL_0002 1019 157
3 3 MEMBER /dev/sdn1 DG_NORMAL_0003 1019 1017
意外にもあっけなく、ASMディスクは追加出来たのではないでしょうか？追加するSQLコマンドが不明な場合は、「ASMディスク・グループに対する変更」と言う事から「ALTER DISKGROUP」文になるだろうと予想出来れば、マニュアル「SQL言語リファレンス」へアクセスして探し出すことが出来るでしょう。
ところでASMディスクを追加する目的ってなんでしょう？私は二つの目的があると思っています。一つ目はASMディスク・グループの容量不足への対応。空のASMディスクを追加することで空き表量を増やすことが直感的に分かると思います。もう一つが重要ですよ。そうです。I/O性能の改善ですね。I/O性能がボトルネックとなっている場合の対処として、より多くのASMディスクにデータファイルを分散配置すれば、それだけ多くのデバイスが同時に稼働することになり、同時に読み込めるデータ量が増加してSQLの実行時間の改善が期待出来ますよね。
さて、回答例の解説をしておきます。とは言え、リバランス自体の説明をしていませんが、それはこの後を読み進めて頂ければ、納得頂けると思います。また、今回の連載ではリバランスの効果について体験して頂くことを目的としているので、リバランスの詳細動作についてはまたの機会に解説させて頂く予定ですが、ここでは「リバランスを実行しない」という事を簡単にご紹介しておきます。
ALTER DISKGROUP ADD DISK文でASMディスクを追加することが出来ますが、その際に「REBALANCE POWER」句でリバランスの強度を指定することが可能です。ちなみに、この句を省略した場合には初期化パラメータ「POWER_LIMIT」の値が自動的に引き継がれることになります。でもって、今回の演習問題では「リバランスは実行しない」と制限があるので、「REBALANCE POEWR 0」を指定することになります。
と言う事で、ASMディスクを追加しました。リバランスしていません。そのような状態の時に、このASMディスク・グループに所属している各ASMディスクの空き容量はどうなっていたでしょうか？予想通りでしたか？予想を裏切られましたか？
元々含まれていた3つのASMディスク（DG_NORMAL_0000~0002）の空き容量は、表領域TBS31を作成した演習4で確認した時から変化していませんよね。一方、追加したASMディスク（DG_NORMAL_0003）に関しては全く使用されておらず、ほぼ1GBの容量が空いている事が理解出来ます。演習4の解説でも述べましたが、ASMのストライピングはデータファイル単位で全ASMディスクへ均等分散するはずですが、物凄く不均等な状態と言って良いでしょう。私であれば「気持ち悪い」という表現を使いますね。
お気付きの方もいらっしゃると思いますが、この気持ち悪い状態はASMディスクを追加した際にリバランスをしていないからです。本来はリバランスをしておくべきなのです。 「では早速、リバランスしましょう。」とはならないのが私の演習です（笑） 「気持ち悪い」と言うのは感情だけなので、現実的に何が発生してしまうのかを体験しておこうじゃありませんか！と言う事で、次の演習をチャレンジしてみてください。
8. 演習6で実行したSELECT文を再度3回実行して下さい。
[oracle@vm11204]$ sqlplus /nolog
SQL>
-- Buffer Cache上のデータブロックをクリア
connect / as sysdba
alter system flush buffer_cache ;
-- 全データをHDDから読み取る際の性能を測定
connect TRY/TRY
set timing on
select count(*) from TAB31 ;
COUNT(*)
----------
393216
Elapsed: 00:00:09.27
Elapsed: 00:00:09.17
Elapsed: 00:00:09.19
そりゃそうですよね。という結果が出ましたね。ASMディスクを追加する前後で全く性能は変化していない事を確認出来たかと思います。TAB31表はTBS31表領域上に存在していて、そのTBS31表領域のデータファイルは既存の3本のASMディスク上にしか配置されていないことは演習7で確認した通りです。なので、新規に追加したASMディスク上に配置されているレコードは一件も存在しないわけですから、このSELECT文の実行時間が変化するはずが無いのです。
と言う事は、演習7の解説部分で述べたASMディスクを追加する2つの目的のうちの2つ目は、リバランスをしていない状態では全く実現できていないことが理解出来たかと思います。じゃあ、1つ目で述べた空き容量だけは実現できているのね？と思いがちですが、実はそれも実現できていないのです。と言う具体例を次に挙げておきます。
[oracle@vm11204]$ sqlplus /nolog SQL> connect / as sysdba alter tablespace TBS31 resize 1800m ; ORA-01237: cannot extend datafile 5 ORA-01110: data file 5: '+DG_NORMAL/orcl/datafile/tbs31.256.851805999' ORA-17505: ksfdrsz:1 Failed to resize file to size 230400 blocks ORA-15041: diskgroup "DG_NORMAL" space exhausted
えー！今回の連載で一番驚いてもらいたい箇所です。と言うのは嘘ですけど（二番目ぐらい？）、表領域のサイズを1200MBから1800MBへ600MB分の拡張を試行してみましたがORAエラーが沢山出ていて結果的には拡張に失敗していることが理解出来ますよね。ASMディスク・グループDG_NORMALは標準冗長性のASMディスク・グループですから、実際には新たに1200MBの容量を消費することになるわけですけど・・・。ここで、演習7の解答例でV$ASM_DISKビューを確認していた結果を見直して頂きたいのですが、4つのASMディスクのFREE_MBを集計すると、確実に1200MB分の空き容量はあるのにー！！と言う相談を受けたことがありますので、皆さん注意して下さいね。
繰り返しになりますが、ASMのストライピングは、データファイル単位で全ASMディスクへ均等分散すると説明させて頂きました。それを再び噛みしめてください。今回の拡張では実質1200MBの新たな領域をASMディスク・グループ上に書き込もうとしています。これを4本のASMディスクで均等分散することになるのですから、1本のASMディスクあたり300MBを書き込もうとするのですよ。でもって、各ASMディスクに300MBの空き容量があるかと言えば「No」ですよね。新規に追加したASMディスクは約1GBの空き容量があるので問題なさそうですが、既存の3本のASMディスクはいずれも空き容量が約150MB程度しか存在していませんから。なので、ASMディスクを追加して空き領域が増加したつもりになっていても、リバランスを実行しない限り、実質的には増えていないと言う事になるのです。
さて、困った困った。ASMディスクを追加する際にリバランスをしなかったけど、後からリバランスすることは出来るのかしら？と調査したい気持ちが自然と湧き出してきたらラッキーです。一気に調べてしまいましょう。と言うことで次の演習です。
9. ALTER DISKGROUP文でリバランスを実行し、各ASMディスクの空き容量が均等化されることを確認して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
alter diskgroup DG_NORMAL rebalance power 1 wait ;
Diskgroup altered.
SQL>
set lines 110 pages 500
col NAME for a10
col STATE for a10
col TYPE for a8
col COMPATIBILITY for a15
col DATABASE_COMPATIBILITY for a15
select GROUP_NUMBER,
NAME,
TYPE,
TOTAL_MB,
FREE_MB,
HOT_USED_MB + COLD_USED_MB "USED_MB",
REQUIRED_MIRROR_FREE_MB,
USABLE_FILE_MB
from V$ASM_DISKGROUP
where NAME = 'DG_NORMAL' ;
GROUP_NUMBER NAME TYPE TOTAL_MB FREE_MB USED_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
------------ ---------- ------ -------- ------- ------- ----------------------- --------------
3 DG_NORMAL NORMAL 4076 1489 2587 1019 235
SQL>
col NAME for a15
col HEADER_STATUS for a14
col PATH for a12
col FAILGROUP for a16
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, PATH, NAME, TOTAL_MB, FREE_MB
from V$ASM_DISK
where GROUP_NUMBER = 3
order by 2 ;
GROUP_NUMBER DISK_NUMBER HEADER_STATUS PATH NAME TOTAL_MB FREE_MB
------------ ----------- -------------- ------------ --------------- ---------- ----------
3 0 MEMBER /dev/sdj1 DG_NORMAL_0000 1019 370
3 1 MEMBER /dev/sdk1 DG_NORMAL_0001 1019 371
3 2 MEMBER /dev/sdl1 DG_NORMAL_0002 1019 371
3 3 MEMBER /dev/sdn1 DG_NORMAL_0003 1019 377
リバランスはALTER DISKGROUP文を使用することでいつでも実行することが出来ますので安心しましたよね。このコマンドもマニュアル「SQL言語リファレンス」へアクセスして探し出すことが出来たことでしょう。そして、リバランス後にV$ASM_DISKビューへ問い合わせることで、4本全てのASMディスクの空き容量が均等化されている事も確認出来ましたよね。つまりは、表領域TBS31のデータファイルが均等配置されたということ、さらにはその表領域上に作成した表TAB31内のレコードも均等配置されたことを意味しています。
さてさて、これでASMディスクを追加する二つの目的である、I/O性能の改善と空き容量の増加が実現しているのかを最後2つの演習で体験してみましょう。
10. 演習6で実行したSELECT文を再度3回実行して下さい。
[oracle@vm11204]$ sqlplus /nolog
SQL>
-- Buffer Cache上のデータブロックをクリア
connect / as sysdba
alter system flush buffer_cache ;
-- 全データをHDDから読み取る際の性能を測定
connect TRY/TRY
set timing on
select count(*) from TAB31 ;
COUNT(*)
----------
393216
Elapsed: 00:00:06.85
Elapsed: 00:00:06.70
Elapsed: 00:00:06.71
じゃーん、ですね。これがリバランスの真骨頂です！見事にSELECT文のレスポンス・タイムが約6.8秒まで短縮していることが確認できたかと思います。ASMディスクを追加する前は約9.1秒でしたから、これを100%に換算した場合、ASMディスクを追加することで75%まで改善したことになります。
このロジックを理解するのは簡単です。「時間=距離÷速度」の公式と全く同じですから。距離はASMディスク・グループから読み込むデータ量（表サイズ）に相当しますので、これはASMディスクの追加前後で変化はありません。速度はASMディスクの本数に相当します。速度3本だったものがASMディスクを追加することで速度4本になったと考えられるでしょう。よって、時間は単純に3/4=0.75=75%に短縮すると考えることが出来ます。もう少し算数っぽく演算すると、次のようになりますよね。
式1) ASMディスク追加前の時間A = 表サイズ ÷ 速度3本 → 表サイズ = ASMディスク追加前の時間A ×速度3本
式2）ASMディスク追加後の時間 B= 表サイズ ÷ 速度4本
ASMディスク追加後の時間 B = (ASMディスク追加前の時間A ×速度3本) ÷速度4本 = ASMディスク追加前の時間A × 0.75
ちなみに、演習1で用意して頂いた新規追加するASMディスクを切り出す仮想ハードディスク・ドライブを既存分とは別のデバイス上に配置してい頂いたのであれば、この結果が得られる可能性が高まります。もし、既存分と新規分が同一のデバイス上に存在していた場合は、速度を3本から4本に早くなると言うように扱ってはいけません。デバイスの性能を100とした場合、ASMディスクを追加する前は、既存の3本の各ASMの性能は100/3=33になるでしょう。この3本が同時に動いても100しか仕事が出来ません。さらに同じデバイス上に作成したASMディスクを追加した場合は、デバイスの性能100を4分割することになるだけです。なので、各ASMディスクの性能は25になるでしょう。この4本が同時に動いても100しか仕事は出来ませんよね。これは図を書けばもう少しうまく説明出来ると思うのですが、ちょいと体力と時間の都合上、省略させて下さい。ごめんなさーい。
11. 表領域TBS31が1800MBへ拡張し、各ASMディスクの空き容量が均等であることを確認して下さい。
SQL>
connect / as sysdba
alter tablespace TBS31 resize 1800m ;
Tablespace altered.
[grid@vm11204]$ sqlplus / as sysasm
SQL>
col NAME for a15
col HEADER_STATUS for a14
col PATH for a12
col FAILGROUP for a16
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, PATH, NAME, TOTAL_MB, FREE_MB
from V$ASM_DISK
where GROUP_NUMBER = 3
order by 2 ;
GROUP_NUMBER DISK_NUMBER HEADER_STATUS PATH NAME TOTAL_MB FREE_MB
------------ ----------- -------------- ------------ --------------- ---------- ----------
3 0 MEMBER /dev/sdj1 DG_NORMAL_0000 1019 71
3 1 MEMBER /dev/sdk1 DG_NORMAL_0001 1019 69
3 2 MEMBER /dev/sdl1 DG_NORMAL_0002 1019 71
3 3 MEMBER /dev/sdn1 DG_NORMAL_0003 1019 78
これまた、じゃーん。ですね。ASMディスクを追加するもう一つの目的も、リバランスを実行することで実現出来ましたね。
さて、ASMのストライピングとリバランスを一挙に体験して頂きましたが、いかがでしたでしょうか？
私は本当にASMが大好きです。だって、RAWデバイス環境で容量が足りなくなったらどうします？I/O性能が不足したらどうします？様々なチューニング方法があると思いますが、どれも今回体験して頂いたASMディスクの追加とリバランスの容易性には遠く及ばないはずです。例えば、RAWデバイスの時に必要になってくるのは、表データをExportしてから表領域をDROPして、RAWデバイスを構成し直してから、再度表領域作成と表データをImportしなければなりません。そのような複雑な作業をするという事はミスも発生しますし、明らかに業務を停止しなければなりません。しかしながら、今回の体験して頂いたASMにおいては、何か業務を止めるような作業をしましたでしょうか？していませんよね。全てオンラインで実行可能なオペレーションだったはずです。（新規デバイスをOSへ見せる作業は、環境依存でOS再起動が必要にな るケースもありそうですね）と言う点もASMのメリットとして強く印象に残って頂けたのであれば幸いです。
ASMのリバランスの内部挙動、障害発生時の挙動等を公開可能な限りご紹介していく予定ですので、是非とも体験に参加して頂けると嬉しいです。今回も最後まで体験して頂きましてありがとうございました。次回以降もどうぞよろしくお願い致します。