トラブル時の応急処置を伝授！安定と先進のいいとこ取りを目指す、Oracle Database活用術
2021.11.11
|
|---|
＜執筆者＞ 徳原 茂之 Tokuhara Shigeyuki
ビジネスインフラ技術本部
データベース技術統括部 部長
1996年に入社以来、Oracle、PostgreSQL、Verticaなどデータベース分野を中心に担当。3年間の東京勤務を経て2016年に帰阪した以降は、西日本のお客様に対するデータベースの提案／構築支援の責任者に従事。
週2回はジムに通い、自身の筋肉との対話を欠かさない。
Oracle Databaseにおける自動化/自律化
こんにちは。技術部長の徳原茂之です。
昨今、ビジネスの世界では様々なものが「自動化」されるようになってきました。
データベース分野も例外ではなく、Oracle Databaseでは、性能面や障害対応において自動化/自律化の機能を取り入れ始めています。
しかし、自動化/自律化されることによって「なぜそうなったのか」の根拠が明らかにならないケースがあります。
こちらは、Oracle Databaseに関する弊社サポートセンターへの問い合わせ傾向です。
Oracle Databaseに関するサポートセンターへの問い合わせ傾向
|
|
エラーやパフォーマンス、ロック/ハングといった、いわゆるトラブルの問い合わせが約4割となっています。
これらは、
Oracle Databaseの自動化/自律化の機能が原因
となっている場合も多いです。
そこで、Oracle Databaseの自動化/自律化に関するトラブルが発生した時に、オススメの応急処置を2つご紹介したいと思います。
バージョンアップ後の応急処置に！「OPTIMIZER_FEATURES_ENABLE」
12c以降のOracle Databaseでは、バージョン毎に多くの「自動化・自律化機能」が追加されています。
ほとんどの場面で機能は有効に動作するのですが、まれに適切ではない挙動をして性能影響を与える場合があります。
そんな時に使えるのが、Oracle Databaseの
初期化パラメータの一つ「OPTIMIZER_FEATURES_ENABLE」
です。
このパラメータは、値にバージョン番号を指定し、オプティマイザと呼ばれる内部動作を制御します。
通常は現行のバージョン番号を指定しますが、バージョンアップ後に性能劣化した場合は「バージョンアップ前の番号を指定する」ことで、以前の振る舞いに戻すことができます。
「OPTIMIZER_FEATURES_ENABLE」パラメータの変更
適用範囲は、DBインスタンス全体、セッション単位、SQL単位から選べます。
まずはセッション単位で指定し、動作確認を行うことを推奨します。
セッション単位で適用
初期化パラメータで「11.2.0.4」に設定
SQL> ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE='11.2.0.4';
SQL単位で適用
ヒント句で「11.2.0.4」に設定
SQL> SELECT /*+ OPTIMIZER_FEATURES_ENABLE('11.2.0.4') */ empno,ename, …;
バージョンアップ直後に性能劣化した際は、「OPTIMIZER_FEATURES_ENABLE」パラメータを変更して動作確認をし、問題なければそのまま運用すると良いでしょう。
安心してバージョンアップするための「事前チェック」
先進的な機能を利用したり、不具合の修正モジュールを適用するには、バージョンを最新に保つ必要があります。
ただ、前述の通り、バージョンアップはリスクを伴います。
応急処置でどうにかなる可能性があるとはいえ、問題が起こってから対応するのではなく、事前に確認しておくことも重要です。
しかし、追加/拡張される機能は多岐に渡るため、それらが有益かどうかを判断するのは、なかなか難しいものです。
そこで、アシストでは30年以上培ってきたOracle Databaseの知識を活用し、
『Oracle Database移行支援』
や
『Oracle Real Application Testing SQL非互換チェック支援』という支援を行っています。
特に『Oracle Real Application Testing SQL非互換チェック支援』は、
バージョン変更に伴うアプリケーション（SQL）の挙動の変化を事前に確認
できますので、アプリケーション改修コストの見積もりや、バージョンアップの実施判断にも有効です。
バージョンアップをお考えの際は、お気軽にご相談ください。
Oracle Database移行支援
バージョンアップやシステム・リプレースに伴う
データベースのデータ移行計画策定、データ移行作業を実施します。
流れ ：事前確認 → 移行 → ドキュメント作成 → 報告会
訪問回数 ：10回程度
主な納品物：支援報告書、移行計画書/結果報告書
Oracle Real Application Testing SQL非互換チェック支援
データベースのバージョン変更によるSQLの互換性を確認します。
現行環境でSQL Tuning Set（DBEEの機能）を利用してSQLのキャプチャを取得し、
再現環境でSQL Performance Analyzer（RATの機能）を利用してSQLを実行します。
流れ ：事前確認 → 現行環境の情報収集 → 診断/分析 → 報告会
訪問回数 ：4回程度
主な納品物：支援報告書
運用中の応急処置に！「統計情報のリストア」
Oracle Databaseは、日々「オプティマイザ統計」と呼ばれる統計情報を収集しています。
これは、表の行数/ブロック数、列内のNULL数、データの偏りや索引のブロック数などの情報で、データの更新などが発生したタイミングで自動的に収集されます。
この統計情報を使用し、最も効率的な実行計画（データアクセス方法）を選択しています。
これらの動作はバージョンを重ねるごとに改善/改良されており、最新の統計情報を維持していれば、適切な実行計画が選択されやすくなっています。
ただ、適切ではない実行計画が選択される可能性も0ではなく、統計情報が更新されたタイミングで実行計画が変更され、パフォーマンスが落ちる場合があります。
そんな時には、
「過去の統計情報にリストアする」
ことで改善されるか確認してみましょう。
統計情報は、初期設定で31日前まで履歴が保持されていますので、戻したい日時を指定します。
過去の統計情報にリストアする方法
適用範囲は、DBインスタンス全体、スキーマ単位、オブジェクト単位から選べます。
統計情報の履歴を確認
SQL> SELECT OWNER, TABLE_NAME, STATS_UPDATE_TIME
FROM DBA_TAB_STATS_HISTORY WHERE TABLE_NAME='テーブル名';
特定テーブルの統計情報をリストア
SQL> exec DBMS_STATS.RESTORE_TABLE_STATS(-
ownname=>'スキーマ名',tabname=>'テーブル名',as_of_timestamp=>'日時');
運用中に性能劣化した際は、「過去の統計情報にリストアする」ことで動作確認をし、問題なければそのまま運用すると良いでしょう。
データベースのパワーを最大限に引き出す「データベース診断」
たとえ最新のハードウェアやデータベースのバージョンを利用していても、設定が適切でなければ性能を最大限に引き出すことはできません。
また、前述のように、運用中に突然性能が劣化する事象も多く、パフォーマンスは永遠の課題です。
そこで、アシストでは
『Oracle Database診断』
というサービスをご用意しています。
性能劣化時にボトルネックを特定したり、定期健診のようにデータベースの状態を継続的にチェックすることができます。
データベースのパフォーマンスに懸念がある方は、お気軽にご相談ください。
Oracle Database診断
お客様のシステム特性をお聞きしながら、データベースを診断します。
潜在的な問題を浮き彫りにして、改善ポイントを明らかにします。
流れ ：事前確認 → 現行環境の情報収集 → 診断/分析 → 報告会
訪問回数 ：4回程度
主な納品物：DB診断報告書
さいごに
最近では、Oracle CloudやAWSへの移行/構築もどんどん増えてきています。
クラウドへのリフト/シフトに関するご相談も絶賛受付中です。
本コラムに関することだけでなく、データベースに関するご質問やご相談などあれば、最下部の「お問い合わせフォーム」よりご連絡ください。
ますます進化を続けるOracle Database。
今後もOracle Databaseをとことん「使いこなす」ため、アシストをうまく「使いこなして」もらえればと思います。
関連情報
データベースに関する最新の技術トピックは、ブログで発信しています。ぜひご覧ください。
＼ 人気コンテンツ！ ／
アシスト現場ブログ ～Database & Cloud～
|
|
本ページの内容やアシスト西日本について何かございましたら、お気軽にお問い合わせください。
