トップ > DBA中級 > 11章
11章 データベースのメンテナンス
では今回はデータベースのメンテナンスについてご紹介していきます。

データベースの運用とは


データベースのメンテナンスとはどのようなものがあるのでしょうか。

・サーバのCPU使用率やメモリ使用率が高くなっていないか
・表は断片化していないか
・SQLの処理速度が遅くなっていないか
・表領域の使用率が高くなっていないか
・エラーが発生していないか

など、日々運用しているとデータベースが徐々にパフォーマンスが低下していくことがあります。データベースを定期的に監視することで、データベースの致命的な問題を未然に防ぐことができます。

ではずっとサーバのCPU使用率や表領域の使用率を監視し続けることは出来るでしょうか。またCPU使用率が高くなっていたとしても問題ないときもあります。
例えば、お昼はアクセスが多く、その時間帯は負荷が集中してしまうのがシステム特性としてある場合、その時間帯のCPU使用率が通常どのくらいであるかを知っておかなければ、CPUの異常値に気づくことが難しいです。

上記は一例ですが、監視というのはシステム特性を正確に把握し、その特性を踏まえたうえで、データベースの異常に気付かなくてはならない為、監視は難易度が高いです。

データベースの監視ツール


ではデータベースの監視はそう簡単ではないことがわかりました。
それではどのようにすれば監視がするのが最適なのでしょうか。
まずは定期的にデータベースの性能情報を取得しておくことです。
人がモニターを見て、ずっと監視し続けるのは難しいですね。

万が一、見ていなかったとしても、性能情報を取得しておけば、その時間帯に何が起こっていたのか確認することが可能です。

データベースの性能情報を取得できるツールはSTATSPACK,AWRがあります。

STATSPACKや自動ワークロードリポジトリ(AWR)は定期的にデータベースの性能情報を取得し、その性能情報をDB上に保持します。その情報をもとに性能レポートを作成することができます。

またAWRの場合、自動データベース診断モニター(ADDM)を利用することで、データベースの性能は自動的に診断されます。この機能はオプションです。
STATSPACKもAWRと同様の機能を提供しますが、STATSPACKは手動で取得する必要があります。AWRは自動的に性能情報を取得します。

自動ワークロードリポジトリ(AWR)


AWRはDBの診断用パフォーマンス情報を定期的に収集する機能です。この情報を使用して、データベースのパフォーマンスが劣化していないかを確認することが出来ます。

AWR
取得した性能情報ををスナップショットと呼びます。
スナップショットはMMONプロセスが60分に1度取得します。
そのAWRスナップショットはSYSAUX表領域に格納されています。
スナップショットはデフォルト8日間保持します。

またAWRの機能を使用するためにはSTATISTICS_LEVELパラメータをTYPICAL(デフォルト)以上にしておく必要があります。


AWRの設定確認


それではSTATISTICS_LEVELパラメータ確認してみましょう。

  SQL> show parameter statistics_level

  NAME                        TYPE        VALUE
  --------------------------- ----------- ------------------
  statistics_level            string      TYPICAL
  

デフォルトはTYPICALなので、よほどのことが無い限り、変更する必要はありません。
次にAWRの設定の確認方法です。

  SQL> select * from dba_hist_wr_control;

  DBID       SNAP_INTERVAL        RETENTION            TOPNSQL    CON_ID
  ---------- -------------------- -------------------- ---------- -------
  397531058  +00000 01:00:00.0    +00008 00:00:00.0    DEFAULT          1
  

SNAP_INTERVALが取得間隔です。1時間(60分)に設定されています。
RETENTIONは保持期間です。8日間となっていることが分かります。

これらのパラメータを変更したい場合は、以下の方法で変更が可能です。
たとえば、保持期間を14日(20160分)、取得間隔を30分にしてみます。

  SQL> BEGIN
    2  DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( interval  => 30,
    3                                                     retention => 20160);
    4  END;
    5  /

  PL/SQL procedure successfully completed.


  SQL> select * from dba_hist_wr_control;

        DBID SNAP_INTERVAL        RETENTION            TOPNSQL        CON_ID
  ---------- -------------------- -------------------- ---------- ----------
   397531058 +00000 00:30:00.0    +00014 00:00:00.0    DEFAULT             1
   


AWRの取得およびレポート作成


次にAWRスナップショットの手動取得とレポートの作成を行ってみます。
スナップショットは60分間隔で取得されていますが、手動の取得も可能です。

  SQL> EXECUTE DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

  PL/SQL procedure successfully completed.
  

上記コマンドでAWRスナップショットを取得することができます。
では取得したAWRスナップショットからAWRレポートを作成してみましょう。
AWRレポートはawrrpt.sqlを使用します。

  SQL> @?/rdbms/admin/awrrpt.sql

  Current Instance
  ~~~~~~~~~~~~~~~~
     DB Id    DB Name      Inst Num Instance
  ----------- ------------ -------- ------------
   1443685173 ORCL                1 orcl

  Specify the Report Type
  ~~~~~~~~~~~~~~~~~~~~~~~
  AWR reports can be generated in the following formats.  Please enter the
  name of the format at the prompt.  Default value is 'html'.

  'html'          HTML format (default)
  'text'          Text format
  'active-html'   Includes Performance Hub active report

  → レポートをHTMLかTEXTかを選択します。


     DB Id     Inst Num DB Name      Instance     Host
  ------------ -------- ------------ ------------ ------------
  * 1443685173        1 ORCL         orcl         linux01

  Using  1443685173 for database Id
  Using           1 for instance number

  Specify the number of days of snapshots to choose from
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Entering the number of days (n) will result in the most recent
  (n) days of snapshots being listed.  Pressing  without
  specifying a number lists all completed snapshots.

  Enter value for num_days: 1

  → 表示するスナップショットの期間を指定します。
     1を指定した場合1日分のレポートを取得します。
Snap Snap Instance DB Name Snap Id Snap Started Level ------------ ------------ --------- ------------------ ----- orcl ORCL 194 17 Mar 2017 01:21 1 195 17 Mar 2017 01:28 1 Specify the Begin and End Snapshot Ids ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Enter value for begin_snap:194 → 使用したいスナップショットの1つ目のSnap Idを指定します。 Enter value for end_snap: 195 → 使用したいスナップショットの2つ目のSnap Idを指定します。 Specify the Report Name ~~~~~~~~~~~~~~~~~~~~~~~ The default report file name is awrrpt_1_194_195.txt. To use this name, press return to continue, otherwise enter an alternative. Enter value for report_name: → AWRレポートのファイル名を指定します。 省略した場合、デフォルトの名前で作成されます。 … Miscellaneous Information ------------------------- There was no significant database activity to run the ADDM. End of Report Report written to awrrpt_1_194_195.txt

作成したAWRレポートは、カレントディレクトリに作成されます。
簡単に確認してみましょう。

  WORKLOAD REPOSITORY report for

  DB Name     DB Id    Instance     Inst Num Startup Time    Release     RAC
  -------- ----------- ------------ -------- --------------- ----------- ---
  ORCL      1443685173 orcl                1 17-Mar-17 01:10 12.1.0.2.0  NO

  Host Name        Platform             CPUs Cores Sockets Memory(GB)
  ---------------- -------------------- ---- ----- ------- ----------
  linux01          Linux x86 64-bit        1     1       1       1.96

                Snap Id      Snap Time      Sessions Curs/Sess
              --------- ------------------- -------- ---------
  Begin Snap:       194 17-Mar-17 01:21:48        35       1.1
    End Snap:       195 17-Mar-17 01:28:27        36       1.0
     Elapsed:                6.65 (mins)
     DB Time:                0.02 (mins)
     
  → 取得したサーバ名やスナップショットのレポート化した期間の情報


  Load Profile                Per Second   Per Transaction  Per Exec  Per Call
  ~~~~~~~~~~~~~~~           ------------   --------------- --------- ---------
               DB Time(s):           0.0               0.3      0.00      0.00
                DB CPU(s):           0.0               0.2      0.00      0.00
        Background CPU(s):           0.0               1.1      0.00      0.00
        Redo size (bytes):       6,922.2         690,397.0
    Logical read (blocks):         347.1          34,615.8
            Block changes:          25.9           2,587.3
   Physical read (blocks):           3.7             364.5
  Physical write (blocks):           1.5             147.3
         Read IO requests:           3.7             364.5
  …

  → データベース全体の物理読み込みやCPU使用量の情報
 
  Instance Efficiency Percentages (Target 100%)
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              Buffer Nowait %:  100.00       Redo NoWait %:  100.00
              Buffer  Hit   %:   98.95    In-memory Sort %:  100.00
              Library Hit   %:   86.01        Soft Parse %:   77.65
           Execute to Parse %:   72.69         Latch Hit %:  100.00
  Parse CPU to Parse Elapsd %:   90.80     % Non-Parse CPU: -141.27
            Flash Cache Hit %:    0.00

  → キャッシュヒット率の情報。90%以上が理想。

  Top 10 Foreground Events by Total Wait Time
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                        Total Wait       Wait   % DB Wait
  Event                           Waits Time (sec)    Avg(ms)   time Class
  ----------------------------- ------- ---------- ---------- ------ --------
  DB CPU                                        .9              70.5
  cursor: pin S wait on X            18         .3      14.28   19.3 Concurre
  db file sequential read            47         .1       2.61    9.2 User I/O
  PX Deq: Slave Session Stats        66         .1       1.16    5.7 Other
  latch: call allocation              5          0       0.38     .1 Other
  log file sync                       1          0       0.17     .0 Commit

  → この期間帯で多かった待機イベントのトップ10の情報

  …以下、省略


以上がAWRについての内容となります。
上記AWRの取得を行うことでAWRレポートを作成し、定期的にDB診断を行います。Diagnosticsオプションを購入すれば、自動診断モニター(ADDM)を利用し、自動的に性能を診断します。


サーバ生成アラートについて


先ほどAWRスナップショットの取得、レポート作成を行い、このレポートを
定期的に監視することで、DBの問題を事前に把握できるということをお話しました。しかし、実際どうでしょうか。
日々、業務をこなし、毎日、AWRレポートをチェックする。
またシステムとしてはDBが複数あることも珍しくありません。
そのDB分のAWRレポートをチェックする。このようなことができるでしょうか。
可能であれば問題が発生したときだけ、レポートをチェックするようにしたいですね。

サーバ生成アラートはそのような要望に対応できる機能です。
たとえば、表領域の使用率が80%を超えたときや、CPU使用率が50%を超過した時にアラート通知します。
アラート機能を使用すれば、DB性能情報を常に確認する必要がなくなります。

しかし、こちらの機能は12c以降は、有償であるEnterprise Manager Could Controlを使用する必要があるようです。
以前は、標準のEnterprise Managerで設定が出来たのですが。。

このような便利な機能を使用する場合はDatabase製品とは別に有償オプションを購入する必要があります。
補足すると、AWRもDiagno Stics Packの有償オプションが必要となるのでご注意を。

今回の内容はパフォーマンスが低下しないよう事前調査についてご紹介してきました。
これは事前チューニングとも呼ばれる作業となっています。
次章では性能劣化が発生した場合の事後チューニングについてご紹介していきます。