真の可用性を実現するために、12cのRACでやるべきこと

EnterpriseZine / 2014年3月28日 14時30分

コーディング: (image11.png)

 前回はOracle Database 12c(以下、12c)から実装されたAutomatic Data OptimizationとHeat MapによるILMの自動化について解説しました。今回は12cのReal Application Clusters(以下、RAC)関連の機能について検証結果を紹介します。

 

 ※RAC関連の新機能概要は「連載:徹底解説!Oracle Database 12cのすべて」の中で解説していますので、併せてご参照ください。

■Flex ASMで障害点を減らす

 ASM(自動ストレージ管理)はOracle Databaseのボリューム・マネージャ兼ファイル・システムとしてディスクを仮想化するための機能です。RACに不可欠な機能と言っても過言ではなく、Oracle Database 11g(以下、11g)以降のRACではおよそ9割がASMを使用しているとも言われています。ASM以外にもRAWデバイス、クラスタ・ファイル・システム、NFSといった選択肢がありますが、12cではRAWデバイスが非サポートになったため、これまで以上にASMの重要性が高まると考えられます。

 新機能を説明する前に、ASMの基本について復習しておきましょう。ASMにはストライピング、ミラーリング、リバランシングなど性能と可用性を両立させるための機能が搭載されており、データが格納されている位置をASMインスタンスで管理するという仕組みになっています。この位置情報はエクステント・マップと呼ばれ、データベース・インスタンス(以下、DBインスタンス)がディスクI/Oを行う際に参照されます。これがなければ目的のデータに辿りつけないため、ASMインスタンスは非常に重要な役割を担っていると言えます。

 誤解されやすいのですが、「ディスクI/Oが発生するたびにASMインスタンスに問い合わせる」という仕組みではないのでご注意ください。エクステント・マップはDBインスタンスのSGA内にキャッシュされているため、毎回ASMインスタンスに問い合わせる必要はありません。また、「ASMインスタンスを経由してデータにアクセスする」という仕組みでもありません。エクステント・マップさえあればASMインスタンスを経由せず直接ディスクI/Oを実行できるため、オーバーヘッドが出ないようになっています。

  • 前のページ
    • 1
    • 2
  • 次のページ
EnterpriseZine

トピックスRSS

ランキング