2016年6月18日土曜日

EM 13c - EM Cloud Control 12cからのアップグレード方法

原文:EM 13c - How to Upgrade from EM Cloud Control 12c

私はCloud Controlの専門家ではありませんが時々このツールは使うことがありますし、お客様のほとんどのお客様はヘビーユーザーで、大きなお客様ですと特にそうです。
もしOracle Enterprise Manager Cloud Control 12c (12.1.0.3, 12.1.0.4, 12.1.0.5のいずれか) をお使いで、Oracle Enterprise Manager Cloud Control 13cへのアップグレードという選択肢を評価してみたい方は、下記のとても有用なドキュメントを参照してみてください:

もしソフトウェアをお探しでしたら、ここから入手できます

--Mike

2016年6月12日日曜日

Enterprise Managerでいろいろな期間のCPUグラフを表示させる方法

原文:Displaying CPU Graphs For Different Time Ranges in Enterprise Manager

このご質問は、ツイッター上で @matvarsh30 さんから寄せられたものです。いわく、「いろいろな期間のCPU使用状況をEnterprise Managerで表示させたいのですが、どうすればできますか?」
皆さん、トップアクティビティの画面はお気に入りですよね。でもこの機能は、ビューのカスタマイズ性ということになると限られていて、このユーザーもそこで行き詰まっていました。このデータを表示する方法はいくつもありますが、ここでは私のお気に入りの一つである機能、トップアクティビティ画面の代替として作られたASH分析に焦点を当てたいと思います。

ASH分析用にAWRデータを保持する


注:この手順によるCPUグラフの表示は、EM12cとEM13cで使用できます。ターゲットメニューの位置が違うこと以外は大きく変わっていません
(ASH分析の)デフォルトの表示期間は1時間です。ASH分析はAWRデータに依存していますから、過去8日間分の詳細な情報を得るのは難しくありませんが、管理対象データベース側の保存期間期間を適切に変更し、8日間ぶん以上のAWRを見たり分析したりできるようにしておくことは大切です。私の信条としては、もしDiagnostics PackとTuning Packを持っているのであれば、その価値を最大限引き出せるように保存期間をデフォルト値から伸ばすために次のコマンドをSQL*Plusから実行します(適切な権限を持ったユーザーで):
BEGIN
  DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
    retention => 86400,        -- 単位は分, 86400は60日
    interval  => 30);          -- 単位は分, 負荷テストなどをするときなどにデフォルト値60から変更します。(通常は)60分間隔で問題ありません
END;
/
これで、EMメトリックデータ(ロールアップあり)だけでなく、ASH分析に必要なAWRでもディープな分析やレポーティングができるようになります。
これを前提として、この質問にこたえるグラフを作ってみましょう。「データベースのCPU使用を1週間以上とか、10日、30日、60日といった形で表示するには?」

パワーユーザー向けのビューに切り替える

いずれかのデータベースに(EMから)ログインすると、「パフォーマンス」ドロップダウンメニューからASH分析にアクセスすることができます。11gかそれ以下のデータベースの場合、パッケージをインストールしてEMCC用のビューを作らないといけないかもしれません。でもこれはEnterprise Managerのパワフルな機能を活用するために必要なことです。ASH分析はデータベースのバージョンが10.2.0.4以上の場合に動作します。

ASH分析のページにはいると、1時間分のインスタンスのデータが表示されますが、これを1週間のビューに変えるには、「Week(週)」をクリックしてからビューを動かし、画面下部のグラフに1週間分のデータが表示されるようにするだけです:
ashan1

2016年6月8日水曜日

Enterprise Manager 13cとAWS

原文:Enterprise Manager 13c and AWS

この投稿では、Enterprise Manager Cloud Control 13c (EM13c) と Amazon Web Services (AWS) とを使うときに何がサポートされるのか、明らかにしてみたいと思います。この疑問は社内のセールスコンサルタントの何人かから寄せられたもので、EM13c と AWSを使うにあたって何がサポートされるのかについて混乱した情報に遭遇していました。そこで、私はサポートの人たちにこの件について回答するサポートノートを書いてもらうよう依頼しました。それが書かれるまでの間、私としてはこの簡易的なブログ投稿を通じて、この件について説明してみます

さて、いくつかのシナリオを見ていきましょう:
オンプレミスのEnterprise Managerで、アマゾンのVirtual Private Cloud (VPC) を使用せずにパブリッククラウドのリソースを管理する:Enterprise Manager 12c R5以降で使用可能なハイブリッドクラウド管理機能は、SSHトンネリングを使用し、VPCを使用せずにOracle Cloudのリソースを監視します。この機能群は、Oracle Cloudに対してのみサポートされています。実はコード上、ゲートウェイエージェントはサードパーティーのクラウドに対しては設定できないようになっています。
注:このシナリオでは、既存のEC2用EMプラグインでAmazonターゲットタイプを作成し、REST経由でいくつかのcloudwatchメトリックを監視できますが、ベーシックな項目のみです。
アマゾン上にインストールしたEnterprise Managerを使用してアマゾン上のリソースを監視する:このシナリオではOMSとターゲットを全てアマゾン上に配置します。このケースでは、オラクルはこのシナリオに対して明示的に動作確認はしておらず、関連するEnterprise Managerのインストール要件や、その他のオラクルのポリシーをすべて満たしている限りにおいて、(通常の)データセンター配置と同様に扱います。
VPCを使用する:もしVPCを使用してネートワークレベルで自社のデータセンターとアマゾンをつなげており、OMSとエージェントの間でhttp(s)アクセスが可能な場合、Enterprise ManagerをVPC内のどこかにインストールしてVPC内のリソースを監視することができます。
まとめると、最初のシナリオはOracle Cloud以外には使うことができず、残りの2つは動作確認はされていないものの明確に禁止されてもいません。この2つは、Enterprise Managerのインストール要件(OSバージョン、パッケージ、ネットワーク設定など)やオラクルのポリシーを満たしている限り、(通常の)データセンター配置と同様にみなされ、(アマゾン上であるかどうかを)特に問わない(agnostic)、ということになります。

みなさんの疑問が解消するとよいのですが!

2016年5月24日火曜日

Oracle Database 12cで押さえておきたいパラメーター - パート2

原文:Parameter Recommendations for Oracle Database 12c - Part II 

Oracle Database 12.1.0.2のお薦めパラメーターについて再び書いていきます。この投稿では、とてもよく知られているパラメーター興味深い動作をするものにフォーカスをあてます。ここには挙動が変わったものや、我々として指摘しおきたいものが含まれます。また、まだOracle Database 11gをお使いの方にとっても、以下の推奨のいくつかは当てはまる可能性があります。

はじめに

繰り返しとなりますが、以下のことに注意してください。以下のパラメーターリストの大部分は、個人的な経験のみに基づくものです。いくつかはオラクル社によって公式に推奨されてもいます。必ず適切なテスト手法を用いるようにしてください。
我々としては Real Application Testing を強くお勧めします。特に SQL Performance Analyzer ですが、 Database Replay と合わせて、これらのパラメーターの変更による影響を検証してください。.

よく知られたパラメーターで興味深い動作をするもの

  • parallel_min_servers
    • これは何?
      • マニュアルをご覧ください。 - パラレルクエリ用スレーブプロセスの最小起動数
    • デフォルト値:
      • CPU_COUNT * PARALLEL_THREADS_PER_CPU * 2
    • 挙動の変化:
      • この値をデフォルトより小さい値にしても、データベースはこれを無視します
      • Oracle Database 11gではデフォルト値は0でした
      • 11.2.0.4 と 12.1.0.2 とを同じサーバー上で比べてみます:
        • 11g:
          SQL> show parameter parallel_min_servers
          NAME                  TYPE     VALUE
          --------------------- -------- ------
          parallel_min_servers  integer  0
        • 12c:
          SQL> show parameter parallel_min_servers
          NAME                  TYPE     VALUE
          --------------------- -------- ------
          parallel_min_servers  integer  8
    • 解説:

2016年3月28日月曜日

エージェントについて

原文:All About That Agent…

Enterprise Managerではエージェントは大きな役割を持っています。ターゲットから全ての情報を集めてくるほか、管理作業やジョブを実行します。ジョブを実行するにはエージェントはヘルシーな状態でないといけません。この投稿では、エージェントとターゲットがきちんと監視されて情報を送っていることを確かめるためのチェックポイントをいくつか見ていきます。

エージェントページ

エージェントのページで何を見ることができるのでしょうか。個人的には、EM管理者は毎日このページをチェックすべきだと思います。どのターゲットでアップロードが停止しているか、どのエージェントが停止していたり長期間ブラックアウト状態になっているか、把握しておくべきです。「設定」→「Cloud Controlの管理」→「エージェント」から次の画面に行くことができます:

まず、ステータスでフィルタリングすることができます。すべて、起動中、停止中、ブラックアウト中、使用不可、のビューがあります。また、ブロックされているものや校正ミスがあるものも見ることができます。

エージェントはデフォルトでインストール中にセキュア化されます。ですから「セキュア・アップロード」が「いいえ」である場合は再度セキュア化する必要があります。

2016年3月22日火曜日

Oracle Database 12cでおさえておきたいパラメーター - パート1

原文:Parameter Recommendations for Oracle Database 12c - Part I 

数週間前に、パラメーター設定(隠しパラメーターを含む)に関する記事を書いたのですが、社内の議論に基づき(ちなみにまだ議論は続いています)その記事は削除し、内容を分けて書くことにしました。内容の一部についてはオプティマイザチームで担当し、記事が投稿され次第私のほうでもアップデートを投稿していきます


はじめに

まずご注意いただきたいのは、下記のパラメーターのリストは基本的に私の個人的な経験に基づくものです。いくつかはオラクルのサポートによって公式に推奨されてもいます。必ず適切な手法でテストを行うようにしてください
我々としてはSQL Performance Analyzerを使ってこれらのパラメーターの変更による影響をテストすることを強くおすすめします。


この投稿内容をどう読むべきか?

「誰かが行った」とか「誰かがブログ(このブログも含みます!)で書いていた」とか「わが国には世界的にも優秀なチューニングエキスパートがいるから」などといった理由で、盲目的にこれらの隠しパラメーター(アンダースコアパラメーター)をセットしては絶対にいけません。信頼すべきは、オラクルのサポート(MOS Noteに書かれている内容)や、オラクルの公式ホワイトペーパーや、皆さんの環境を良く知っていて長く一緒に仕事をしているサポートエンジニアやコンサルタントがいる場合はそういった人々です。
.

重要なパラメーター設定
    • _kks_obsolete_dump_threshold
      • これは何?
        • カーソルシェアリングの診断を改善するためにOracle 12.1.0.2で導入された改良で、親カーソルがN回無効になった際に無効な親カーソルとその子カーソルの情報をダンプするというものです

    2016年3月20日日曜日

    AWRウェアハウスに関するジョブ in EM13c

    原文:AWR Warehouse Jobs in EM13c

    AWRウェアハウス機能をいろいろと試しているうちに、いくつか注意したほうがよさそうな変更点に気付きました。ご存知の通り、AWRウェアハウスはEMのジョブ機能を多用しており、EM13cではさらにその度合いが増しています。EMのジョブシステムは(EM13c)で大きくオーバーホールされました。そこで、この変更によってAWRウェアハウスにデータベースを追加していくときにどういう影響があるのか見ていきましょう。

    検出

    EM13cでAWRウェアハウスにデータベースを追加して数分すると、コンソール上では「スナップショットがアップロードされていない」と表示されることに気づくでしょう。この画面を使っている人がこれを見るとちょっと警戒するかもしれません。