ペンネーム：ぴっぐ
こんにちは！はじめまして！SREのぴっぐです。
弊社では先日、本番DBのメンテナンスを行いました。
今日は、そんなメンテナンス作業における経緯・準備・実施までの流れや実施内容について書いていこうと思います。
メンテナンス内容を要約すると以下のような感じです。
なぜDBメンテナンスをやったの？
会社の成長とともにデータ量が増えてきており、データ増加量の事を考えて、ディスク・グループの拡張が必要だと判断したためです。
DBメンテナンスって結局何をやったの？
ディスク・グループの拡張です。
ディスク・グループってなに？
ディスク・グループの前にOracleの自動ストレージ機能（ASM）について説明が必要ですが、今回は割愛します。
そんなASMがデータ（データファイル）を管理するのに、ディスク・グループが使用されます。
つまり簡単にいうと、データを保存するための領域です。
余談ですが、ディスク・グループには、データ領域、REDOログ領域、アーカイブログ領域として分けるのが一般的です。
今回はデータ領域用のディスク・グループについてです。
https://docs.oracle.com/cd/E16338_01/server.112/b61035/asmcon.htm/docs.oracle.com
拡張するのは難しい作業？
作業自体はコマンドを実行してステータスを監視する、というものなのでそんなに難しくはないです。
しかし、一番重要なデータ部分に関わる作業なだけあり、もし拡張中に何かあるとシステムに大きな影響を及ぼしかねない作業でした。
そのため、念入りに計画してテストを実施する必要がありました。
結局うまくいった？
完璧でした。
想定時間より少し長引きましたが、バッファをとって確保していたメンテナンス時間ぴったりに完了できました。
では実際に、DBメンテナンスを行なった経緯・準備・実施について書いていきます。
■経緯編
会社の成長とともにデータ量が増えてきており、今後のデータ増加量とディスク容量を考えた結果、繁忙期を向かえる前に、ディスクグループの拡張が必要だと判断しました。
弊社では11月、12月と繁忙期に入るため、それより前に行う必要があり10月に実施することを決めました。
■準備編
準備は以下のようなステップで行いました。
- 計画
- 手順書作成
- テスト
- チーム内MTG
- 業務観点のMTG
- リスク管理観点のMTG
それぞれについて簡単に書いていきます。
計画
計画では、スケジュール、影響範囲の洗い出し、作業後テスト項目作成、作業時間の確認などをしました。
スケジュール
こちらは10月中に完了させなければいけないという事を念頭に置き、10月2週目の土曜日夜間で決定しました。
何かあっても翌週できるように計画しました。
影響範囲の洗い出し
実は本作業を行う半年ぐらい前に、別の問題があり別領域（アーカイブログ領域）の拡張をしなければいけない状況がありました。
結局別観点からの解決で拡張作業はなくなったのですが、この時に影響範囲を洗い出していたため、基本流用の一部修正で済みました。
作業後テスト項目作成
テスト項目も同様に作成していたため、基本流用で済みました。
作業時間の確認
作業時間は、テスト環境でテストをしてから出すようにしました。
それでも念には念をということで目一杯バッファを積むようにと考えました。
手順書作成
私自身、過去に同様の作業をした経験があったので、手順は一通り作成しました。
事前事後の作業はありますが、当日実行した手順は下記です。
・ディスクグループにディスク追加 su - grid sqlplus / as sysasm ALTER DISKGROUP DATA1 ADD DISK '<DiskName>' NAME <DiskGroupName> REBALANCE POWER 1 NOWAIT; ・リバランス確認 select group_number, operation, state, est_minutes from V$ASM_OPERATION; ・ディスクグループの確認 select * from v$asm_disk; select * from v$asm_diskgroup;
こう見るとすごいシンプルですね。
テスト
問題なく突破！
（後になってつまずくことになるとはこの時はわかっておらず、安心していました・・・。）
チーム内MTG
こちらも特に問題なく突破！
テスト内容はおおよその作業時間、想定される本番作業時間を話しました。
業務観点のMTG
一部スケジュール感で指摘がありましたが、特に問題なく突破！
テストは完了していること、サポート体制が整っていることを話しました。
リスク管理観点のMTG
なんと、こちらも特に問題なく突破！
テストが完了していること、懸念点を潰せていることを話しました。
■実施編
いよいよ本番環境による実施です・・。
準備をしているとはいえど緊張でした。
本番環境による作業は、2回に分けて行いました。
それぞれについて話していきます。
- 失敗しても他に影響を出さないOS側の作業
- 失敗すると影響範囲が大きいDB側の作業
失敗しても他に影響を出さないOS側の作業
OS側の作業は、追加した物理ディスクを適切なサイズにパーティション切りし、Oracle（ASM）に認識させる作業です。
この作業で予期せぬ事態が起きて焦りました。
さて、では実際にやっていきます。
※弊社はRAC構成なため、１号機・２号機と書いていきます。
・パーティション作成 <１号機> # parted -l エラー: <DiskName>: ディスクラベルが認識できません。 モデル: Linux device-mapper (multipath) (dm) ディスク <DiskName>: 2067GB セクタサイズ (論理/物理): 512B/512B パーティションテーブル: unknown ディスクフラグ:
（ふむふむ、ちゃんとディスクはあるね）
# parted <DiskName> GNU Parted 3.1 <DiskName> を使用 GNU Parted へようこそ！ コマンド一覧を見るには 'help' と入力してください。 (parted) mklabel gpt (parted) unit MiB (parted) mkpart パーティションの名前? []? ファイルシステムの種類? [ext2]? ext4 開始? 0 終了? 1959328 警告: 0.00MiB から 1959328MiB (0 から 4012703743 セクタ)までのパーティションを指定されました。 可能な中で最も近いものは 0.02MiB から 1959328MiB (34 から 4012703743 セクタ)になります。 それでもかまいませんか？ はい(Y)/Yes/いいえ(N)/No? Y 警告: 操作の結果できるパーティションはアライメントが正しくないためにパフォーマンスがでません。 無視(I)/Ignore/取消(C)/Cancel? Ignore (parted) q 通知: 必要であれば /etc/fstab を更新するのを忘れないようにしてください。
（いい感じいい感じ）
# parted -l エラー: <DiskName>p1: ディスクラベルが認識できません。 モデル: Linux device-mapper (linear) (dm) ディスク <DiskName>p1: 2055GB セクタサイズ (論理/物理): 512B/512B パーティションテーブル: unknown ディスクフラグ: モデル: Linux device-mapper (multipath) (dm) ディスク <DiskName>: 2067GB セクタサイズ (論理/物理): 512B/512B パーティションテーブル: gpt ディスクフラグ: 番号 開始 終了 サイズ ファイルシステム 名前 フラグ 1 17.4kB 2055GB 2055GB
（お、いいじゃん、p1が出ているってことはちゃんと作成されたってこと！）
# ls -l /dev/dm-* brw-rw---- 1 grid asmadmin 253, 0 10月 10 18:51 /dev/dm-0 brw-rw---- 1 grid asmadmin 253, 1 10月 10 18:49 /dev/dm-1 brw-rw---- 1 grid asmadmin 253, 2 10月 10 18:52 /dev/dm-2 brw-rw---- 1 grid asmadmin 253, 3 10月 10 18:52 /dev/dm-3 brw-rw---- 1 grid asmadmin 253, 4 10月 10 18:52 /dev/dm-4 brw-rw---- 1 grid asmadmin 253, 5 10月 10 18:51 /dev/dm-5 brw-rw---- 1 grid asmadmin 253, 6 10月 10 18:51 /dev/dm-6 brw-rw---- 1 grid asmadmin 253, 7 10月 10 18:51 /dev/dm-7 brw-rw---- 1 grid asmadmin 253, 8 10月 10 18:51 /dev/dm-8 brw-rw---- 1 grid asmadmin 253, 9 10月 10 18:51 /dev/dm-9
（dm-9が今回作成されたやつだね！さて、２号機側もちゃんと作成されているかな）
＜２号機＞ # parted -l モデル: Linux device-mapper (multipath) (dm) ディスク /dev/mapper/360002ac0000000000000000500007ca2: 2067GB セクタサイズ (論理/物理): 512B/512B パーティションテーブル: gpt ディスクフラグ: 番号 開始 終了 サイズ ファイルシステム 名前 フラグ 1 17.4kB 2055GB 2055GB
（ん・・・？あれ、パーティション作成された形跡はあるけど、そのパーティションがない・・・？）
# ls -l /dev/dm-* brw-rw---- 1 grid asmadmin 253, 0 10月 10 18:54 /dev/dm-0 brw-rw---- 1 grid asmadmin 253, 1 10月 10 18:54 /dev/dm-1 brw-rw---- 1 grid asmadmin 253, 2 10月 10 18:54 /dev/dm-2 brw-rw---- 1 grid asmadmin 253, 3 10月 10 18:54 /dev/dm-3 brw-rw---- 1 grid asmadmin 253, 4 10月 1 14:20 /dev/dm-4 brw-rw---- 1 grid asmadmin 253, 5 10月 10 18:55 /dev/dm-5 brw-rw---- 1 grid asmadmin 253, 6 10月 10 18:55 /dev/dm-6 brw-rw---- 1 grid asmadmin 253, 7 10月 10 18:54 /dev/dm-7 brw-rw---- 1 grid asmadmin 253, 8 10月 10 18:54 /dev/dm-8
（あれ・・・、やっぱり作成されてない！！！なんで！！！）
少し焦りましたが日に余裕を持って作業を開始していたため、落ち着いて調査をしました。
そして答えを見つけました。
以下のサイトによると、
The kpartx command reads partition data from the disk and creates device-mapper linear maps corresponding to each discovered partition. This allows you to access the partitions on a device-mapper device as separate dm devices (e.g. you'd get devices with paths like '/dev/mapper/dm-0p1' or whatever depending on the -p switch given).
https://www.redhat.com/archives/dm-devel/2014-September/msg00077.htmlwww.redhat.com
なるほど、つまり「mapperデバイスには、kpartxコマンドを実行すると認識するよ！」（超絶自分よがりに訳してます...笑）ということです。
いざ！実行へ！
＜２号機＞ # kpartx -av <DiskName> add map <DiskName>p1 (253:9): 0 4012703710 linear <DiskName> 34
（お、いい感じっぽい？）
# ls -l /dev/mapper/360002ac0000000000000000500007ca2* lrwxrwxrwx 1 root root 7 10月 12 11:41 <DiskName> -> ../dm-2 lrwxrwxrwx 1 root root 7 10月 12 11:43 <DiskName>p1 -> ../dm-9
（おおおお！確認方法変えちゃったけど、dm-9ができてる！OK！）
今回の事象の原因は明らかなテスト不足。いや、テスト環境不足でした。
近しい環境は準備しましたが、OS周りも本番と同じ構成の環境でテストしていなかったのが痛い。
やっぱりテストする時は全く同じ環境でやるべきだなと改めて思いました。
さて、問題も解決したということで、ついにDB作業。
失敗すると影響範囲が大きいDB側の作業
DB側の作業は、上の方で書いた手順のとおり至ってシンプルです。
ECサイトをメンテナンス状態にし、パーティションしたディスクをディスク・グループに追加し、データをリバランス（均等に分散）させます。
基本１つコマンドを実行したあとは、定期的にステータスを確認しつつひたすら待ちです。
特に問題ないはずなので、いざ実行！
・ディスクグループにディスク追加 SQL> su - grid SQL> sqlplus / as sysasm SQL> ALTER DISKGROUP DATA1 ADD DISK '<DiskName>p1' NAME DATA1_0001 REBALANCE POWER 1 NOWAIT; Diskgroup altered.
（よし、問題なく適用された）
・リバランス確認 SQL> select group_number, operation, state, est_minutes from V$ASM_OPERATION; GROUP_NUMBER OPERATION STATE EST_MINUTES ------------ --------------- ------------ ----------- 2 REBAL RUN 97
（リバランス時間は約100分か。まぁ、少し長引くかな？）
完了まで時間がかかりそうなので、このリバランスについて軽く触れたいと思います。
リバランスとは、分かりやすい記事からの引用ですが、以下のように言っています。
リバランス処理は、ASMディスク間でデータを移動するリバランス・フェーズと、ASMディスク内でデータを移動するコンパクション・フェーズがあります。
https://www.oracle.com/technetwork/jp/database/articles/shibacho/index-2280867-ja.htmlwww.oracle.com
上記でリバランス確認として実行したコマンドは、ASMディスク間でデータを移動するリバランス・フェーズの進捗を確認するコマンドです。
リバランスはASMが提供していて、とても便利な機能です。
ディスクへのデータの偏りは大きなI/O負荷の原因になります。では、均等に再配置するにしても手動でやるには結構な工数がかかります。
そういった問題を解決してくれるのがリバランス機能です。リバランスによりディスクに対して均等分散配置されることで、I/O負荷の原因を少しでも減らすことができます。
そうこうしているうちにリバランス・フェーズが終わったようです。
03:14:59 SQL> / GROUP_NUMBER OPERATION STATE EST_MINUTES ------------ --------------- ------------ ----------- 2 REBAL RUN 0
（大体２時間ぐらいでリバランス自体は完了。ここからがコンパクション・フェーズ・・・。進捗もわからずただただ長い。早く終われ。）
これもまた長いので、コンパクション・フェーズにも簡単に触れます。
同じ記事からの引用です。
一方、既存ASMディスク側は新規ASMディスクへ移動したデータは削除していきますから、リバランス・フェーズが終わった段階では歯抜け状態になっているのが想像できるかと思います。
このデータの歯抜け状態を解消する為に、もう一つのフェーズであるコンパクション・フェーズの処理で、ASMディスク内に閉じて、データの移動が実行されるのですね。
まさにそのままです。
歯抜け状態だと、未使用領域も使われているように見えてしまい、断片化している状態になってしまいます。
そうならないために自動でコンパクションを行い綺麗な状態にしています。
さて、コンパクション・フェーズも終わったようです。
05:46:25 SQL> / no rows selected
（終わった・・・！！リミットが6時だったためヒヤヒヤした。想定より少し長くかかりましたが結果的にぴったりで完了！）
このあと、メンテナンス状態にしていたECサイトを定刻通り6時にオープンし、サービスの動作確認、関係者各位に完了メールを出して完了です！
作業時間は合計で約6時間半かかりました。
■内訳
事前作業：30分
DB側作業：5時間
事後作業：1時間
本番作業の緊張と深夜作業で非常に疲れましたが、何事もなく完了してよかったです！
■まとめ
今回の作業をする上で、以下のようなことを思いました。
テストは本当に大事
テストの重要性を再認識しました。今回はテスト環境の不備が目立ちましたが、テストを行うと、手順の確認、予想作業時間、考慮漏れなど色々なものが見えてきました。社内に頼れる人がたくさんいる
各分野で優れている先輩がたくさんいます。DB以外のところでつまずいても、相談することで早期解決に繋がることを改めて思いました。過去の経験が活かせてる
過去の経験を活かし、手順書の作成や作業による懸念点の洗い出しがスムーズにできたと思います。勉強になった
最近DBから少し離れていたところがあるため、このような機会があると本気で調べるので忘れかけていたことを思い出せました。
今回はこの辺りで終わりにしたいと思います。
スペシャリストになるため勉強を続けます！
楽しいOracle Lifeを！
