はじめに
2022年現在、Db2には多くの提供形態があります。
(参考：2022年6月のDb2製品ラインナップを整理してみる)
10年前まではオンプレミス環境での利用が圧倒的に多かったDb2も、IaaS環境での稼働はすっかり一般的になり、DBaaSであるDb2 on Cloud, Db2 Warehouse on Cloud（略称：Db2WoC）の利用検討も増えてきているようです。
DBaaSであるDb2 on Cloud , Db2WoC ではサービス利用を申し込めば、作成済のDBを提供されてすぐに利用開始することができます。
そして、OSログインは不要です。そもそもDb2が稼働するOSへログインすることはできません。
となると、どうやって運用管理を行うのでしょう？
DBaaSですから障害が起きたときのサービス復旧はベンダーであるIBMにおまかせで良さそうですが、DBサーバで日々行われる運用操作は多岐にわたります。
バックアップ、統計情報収集、再編成、モニタリングなど、一般的に行われるデータベース運用操作がDb2 on Cloud, Db2WoCではどうなるのか、何ができるかは知っておきたいところです。
そこで、オンプレミス環境、IaaS環境で稼働するDb2で通常行われる定常運用操作を、Db2 on Cloud , Db2WoCではどのように行えるのかを整理します。
目次
(1) バックアップ/リストア
(2) 統計情報収集/再編成 (この記事）
(3) モニタリング/監視
この記事では、「(2) 統計情報収集/再編成」について扱います。
統計情報収集/再編成 を行う目的
統計情報の収集 (→ データ・アクセスの最適化)：
SQLの実行にあたって、データに対しどのような操作/順序でアクセスを行うか(アクセスプラン)は、Db2のオプティマイザが決定します。
Db2のオプティマイザはコスト・ベース・オプティマイザであり、統計情報や構成パラメータ、バインドオプション等の情報に基づいてアクセスプランを作成します。
最適なSQLパフォーマンスを得るには、適切なアクセスプランが選択される必要があります。
適切なアクセスプランを選択するためには、まず正しい統計情報が必要となります。
Db2のRUNSTATSコマンドの実行により統計情報が最新化され、オプティマイザがより現状に即した、適切なプランを選択できるようになります。
参考情報：
Db2マニュアル「RUNSTATS コマンド」
再編成 (→ データのデフラグ)：
更新処理（UPDATE/DELETE/INSERT）が繰り返し行われフラグメンテーションが発生した結果、データページ内の配置が不連続になりI/O効率が悪化してしまうことがあります。また、実データ量以上にストレージの領域を占有してしまうこともあります。こういった場合に備えて(もしくは発生しないよう)、定期的に再編成を実行します。
Db2のREORGコマンドは、表、および索引を「再編成(re-organize)」することで、
ページの中に空き領域がない状態になるよう、レコードを詰め直します。
再編成により無駄な領域を開放して表や索引のサイズを縮小させ、I/O 効率を向上させる効果が得られます。
また、その表に再編成を行うことで、ディスクスペースの改善/性能向上の効果を得られる可能性があるかどうかを事前に確認できる「REORGCHK」コマンドも提供されています。
Db2における再編成には、オフライン再編成とオンライン再編成の大きく2種類があります。
| オフライン再編成 | オンライン再編成 | |
|---|---|---|
| 仕組み | データをきれいに並べ直した後、 元表を上書きして置き換える方式。 索引も再作成される。 |
表に割り当てられている 既存エクステント内の空きスペース を利用して少しずつデータの 詰め直しを行う方式。 他処理を優先させつつ バックエンドで、小さい範囲ごと の再編成を繰り返し行う。 |
| 処理中の表への アクセス |
照会処理が可能 | 更新・照会処理が可能 |
| パフォーマンス | 高速 | 低速 |
| 再編成完了時の 並び順 |
並び順は完璧 | 並び順は完璧ではない (更新アクセスを許可するモードの場合) |
| データ・スペース 所要量 |
再編成する表の約2倍程度必要 | 小さい |
| ログ・スペース 所要量 |
少ない | 非常に多い |
| 再編成処理の中断/ 再開可否 |
FORCEコマンドでの強制終了 | 中断/再開可能 |
| 索引の再作成 | 索引の再編成(再作成)も実行される | 索引の再編成は実行されないため、 REORG INDEXを実施した方がよい |
| LOB/LONG データ対応 |
〇 | × |
| すべての表の サポート |
〇 | × |
参考情報：
Db2マニュアル「REORG TABLE コマンド」
Db2マニュアル「REORG INDEX/INDEXES コマンド」
Db2マニュアル「表を再編成する方式の選択」
オンプレミス版Db2における 統計情報収集/再編成
オンプレミス版のDb2でRunstats / Reorgを行うには、
運用保守スクリプトを実装するか、Db2が提供する自動保守の仕組みを利用することができます。
1. スクリプトによる統計情報収集/再編成の実行
オンプレミス版のDb2では、Db2が提供するコマンドを任意のタイミング、任意のオプションで実行できることから、システム/アプリケーションの特性をふまえた柔軟な運用操作をユーザーが工夫しながら実施することができます。
統計情報収集/再編成 の一般的な運用フロー:
定期的に運用時間枠を取ることのできるOLTPシステムであれば、下の図に描かれるステップ1からステップ4までの作業をシェルスクリプトとして実装し、運用ジョブとして実行されることが一般的です。
2. Db2自動保守機能の活用
小規模なデータベースや、パッケージ製品同梱データベースなど、専用のDb2運用要員や運用ジョブを用意できない場合や、運用を簡略化したいなどの要件がある場合、Db2の自動保守機能を活用することができます。
Db2における自動保守アクティビティーとして、
- 自動統計収集(データ・アクセスの最適化) … デフォルトで有効
- 自動再編成(データのデフラグ) … デフォルトで無効
の機能が提供され、事前にポリシーファイル(xml)で定義しておいた保守時間枠の中で、保守アクティビティーが自動実行されます。
(※オンプレミス版Db2では自動再編成はデフォルト無効なので、デフォルトのまま運用開始した場合には自動統計収集のみが実行されます)
またこれらの他にも、自動保守アクティビティーの一つとして自動DBバックアップ機能がありますが、本稿では触れません。
補足：
自動再編成を有効にした場合も再編成は全ての表に行われるわけではなく、内部的に再編成の必要性をまず確認(REORGCHK)した上で、必要と判断されたユーザー表に対してオフライン再編成が実行される仕組みです。また、ポリシーファイルでスキーマ、表の名前などを指定しておくことで、再編成の対象とする表を絞り込むこともできます。
考慮点として、表の自動再編成はオフライン再編成のみとなるため、業務アプリケーションと重複するとロック待機が発生する可能性があります。
手動運用でオフライン再編成を実施する場合、その表を利用するアプリケーションはあらかじめ停止しておくことが一般的です。自動保守による表のオフライン再編成を利用する際にも同様に、業務/運用要件に照らし合わせた考慮が必要となります。
参考情報：
Db2マニュアル「自動保守」
[DB2 LUW] 自動保守のコマンドラインによる構成方法
Db2 on Cloud における統計情報収集/再編成
Db2 on Cloudでは、デフォルトでは、自動統計収集は実施され、表/索引の再編成は実施されない設定となっています。
統計情報収集
統計収集についてユーザーが明示的に保守操作を行う必要はありません。
もし業務要件上必要であれば、ユーザー自身でRUNSTATSコマンドを実行することも出来ます。
再編成
表や索引の再編成は、デフォルトでは自動実行されません。
Db2 on Cloudで表や索引の再編成を行いたい場合、下記いずれかの対応をとる必要があります。
- 1: 表に対する自動再編成が実施されるよう構成変更
- AUTOMAINT_SET_POLICY プロシージャーにて構成するか、サポート部門に依頼
- 表の自動再編成はオフライン再編成のみとなるため、業務/運用要件に照らし合わせた考慮が必要
- 2: 手動でREORGコマンドを実行
- Webコンソール、もしくはリモートカタログしたクライアントから実行可能
- オフライン再編成、オンライン再編成どちらも実行可能
参考情報：
Db2 on Cloud「RUNSTATS コマンド (ADMIN_CMD プロシージャーを使用)」
Db2 on Cloud「REORG INDEXES/TABLE コマンド (ADMIN_CMD プロシージャーを使用)」
Db2WoC における統計情報収集/再編成
Db2WoC では、デフォルトでは自動統計収集と索引の再編成が実行されます。
統計情報収集
統計収集についてユーザーが明示的に保守操作を行う必要はありません。
もし業務要件上必要であれば、ユーザー自身でRUNSTATSコマンドを実行することも出来ます。
再編成
Db2WoCでは自動再編成が行われ、索引がオンライン再編成の対象となります。
索引だけでなく表の再編成も行いたい場合、下記いずれかの対応をとる必要があります。
- 1: 表に対する自動再編成が実施されるよう構成変更
- AUTOMAINT_SET_POLICY プロシージャーにて構成するか、サポート部門に依頼
- 表の自動再編成はオフライン再編成のみとなるため、業務/運用要件に照らし合わせた考慮が必要
- 2: 手動でREORGコマンドを実行
- Webコンソール、もしくはリモートカタログしたクライアントから実行可能
- オフライン再編成、オンライン再編成どちらも実行可能
参考情報：
Db2 Warehouse on Cloud「RUNSTATS コマンド (ADMIN_CMD プロシージャーを使用)」
Db2 Warehouse on Cloud「REORG INDEXES/TABLE コマンド (ADMIN_CMD プロシージャーを使用)」