「システム基盤構築のプロフェッショナル」レック・テクノロジー・コンサルティングJapanese | English

レック・テクノロジー・コンサルティング株式会社

技術ブログ

HOME > 技術ブログ > 月別アーカイブ: M.K

月別アーカイブ: M.K

投票ディスク・OCRのおはなし

こんにちは。宮崎です。
今回のブログの内容は11g R2以降に準拠した内容になります。

まず、RACというテーマを踏まえて、
ASM(Automatic Storage Management)に関しての11gのR1とR2の違いを述べます。

11g R1までは、投票ディスクとOracle Cluster Registry(以下、OCR)という2つのOracle ClusterwareファイルをASMで管理できず、rawデバイスや共有ディスク内に配置していました。

ところが、11g R2では大きな変更がありました。
それは、11g R2ではこの2つのファイルをASM内で管理できるようになり、
ディスクの領域管理が楽になったのです。

・OCR

OCRとは、一言でいうと、RACの構成情報レポジトリ用ファイルのことです。
Oracle Clusterwareで制御するデータベース、サービス、リスナーなどのコンポーネントや各クラスタ・リソースのプロファイル情報やステータス情報など、Oracle Clusterware稼働に必要な情報が含まれているファイルです。

・投票ディスク

投票ディスクとは、Oracle Clusterwareがクラスタ内のノードの生死判断するのに用いるファイルです。クラスタ内の各ノードは、ハートビートと呼ばれるクラスタ同期サービス(以下、CSS)同士で生存確認を行います。その結果として、あるノードにサーバーダウンなどの異常が発生した場合、その異常が起きたノードを切り離し、クラスタを正常に保つスプリット・ブレインという機能に使用されます。
下の図は前回のブログでも出てきた、3ノードからなるクラスタ・データベースのイメージ図です。
asmpic1

インスタンス君①
 「おーい生きてるかー?」
インスタンス君②
 「こっちは無事だよー」
インスタンス君③
 「俺も大丈夫!」

各インスタンスはCSS社の糸電話で、こまめにお互いの無事を確かめ合っています。
asmpic2

しかし、ある日のこと、急にインスタンス③君が倒れてしまいました。

インスタンス君①
 「おーい生きてるかー?」
インスタンス君②
 「インスタンス君③から返事が帰ってこないの!」
インスタンス君①
 「何度呼びかけても応答してくれないな・・・」

asmpic3
意識を失っているので当然、糸電話で2人のインスタンス君たちと話すことはできません。
インスタンス君③がいない以上、このままでは今あるクラスタ・データベースを維持することができません。そこで残った2人のインスタンス君はある決断を下します。

インスタンス君①
 「インスタンス君③から応答があるまで、2人だけでクラスタを作りなおそうよ」
インスタンス君②
 「僕も同じ意見だよ。賛成票2票でインスタンス君③をクラスタから切り離そう」

こうして多数決によりインスタンス君③はクラスタから切り離され、インスタンス君①と②からなる新しいクラスタ・データベースができました。
asmpic4
それからしばらくしてインスタンス君③は何事もないかのように2人のもとに戻ってきました。

インスタンス君③
 「みんな、ただいま!」
インスタンス君①
 「おっ、やっと帰ってきたね。」
インスタンス君②
 「2人だけで大変だったんだよ!」
インスタンス君③
 「ごめんごめん!積もる話もあると思うけど、先にクラスタ作りなおそうぜ」
インスタンス君②
 「そうだね」
asmpic1
異常の発生したインスタンスが再び正常に起動すると、自動的にクラスタの再構成が始まります。

OCRと投票ディスクをASMで管理する利点としては、障害時にOracle Clusterwareを継続的に稼働したまま障害に対応し、その後の復旧まで自動的に行う点が挙げられます。その際、ディスクの冗長化設定を利用してデータ保護を行うとなおさらよいです。

Oracle ClusterwareとASMは、コンポーネントとしては独立しているものの、この2つが1つの機能として統合され、Grid Infrastructureと呼ばれるRACを支える重要なアーキテクチャとして提供されています。

ASMに関してはそれ自体もさることながら、ACFSも含めて色々と記事が書ける素材のため、
また折をみてお伝えしたいと思います。

投票ディスク・OCRのおはなし

Oracle Database Express 12c

こんにちは。エンジニアの宮崎です。

Oracle Database 12cでは、従来のバージョンでは使用可能だった
Enterprise Manager Database Controlを使用することができなくなりました。
その代わりとして、Oracle Database Expressというものが用意されています。

どういうものかというと、大雑把な説明として、
「DB管理機能を取り除いてDB監視機能だけになったEM Grid Control」
といえばイメージしやすいでしょうか。

今回はOracle Database Express(以下、ODE)で遭遇したトラブルについて紹介します。

Oracle Database Expressに接続できない!?

 
トラブルの内容は、ODEに接続できないということで相談を受けました。

話を伺うと、DBCAを使用してDBを作成されており、
スクリーンキャプチャが残っているということで確認してみました。

すると、インストール時に指定できる「Database Expressを構成する」というチェックボックスにチェックが入っていませんでした。もしここでチェックが入っていれば、DB構築と同時にDatabase Expressを自動で構成してくれます。

単なる設定漏れなので、手動で設定をしてあげればすぐに終わるなと考え、
マニュアルに記載されている内容に従い、ローカルリスナーの設定、ポートの設定、
dispatchersパラメータの設定を行いました。

だが、予想に反し、接続できない!

ローカルリスナーを設定後、再起動を行い、
リスナーは5500番ポートをリスニングしている。

DBMS_XDB_CONFIG.GETHTTPSPORT()の値が5500になっている。
そして他のプロセスが同ポートを使用していない。

dispatchersパラメータにSIDはしっかり書かれている。

でも、接続できない・・・

基本に立ち返り、ファイアウォール設定やネットワーク設定の再確認を行う。

だがおかしいところは見当たらない。

そこでふとDBパラメータの値を眺めてみる。

すると、shared_serversパラメータの値が0になっている。
ん?デフォルトだと確か1だったよな。

接続にディスパッチャを使用するということは、
この値が少なくとも1以上ないと問題があるのではないだろうか・・・

そこで、おもむろにalter system set 文でshared_serversパラメータの値を
デフォルトの1に戻し、データベースを再起動する。

データベース起動を確認後、
https://hostname:5500/em/
にアクセスすると、無事に接続できるように。

Oracle Database Express構成方法のまとめ

 
そんなこんなで、Oracle Database Express構成方法のまとめ。

[table id=34 /]

a. shared_serversパラメータの設定

ALTER SYSTEM SETコマンドで、
このパラメータの値を1以上の値に設定します(デフォルトの値は1)。

「専用サーバ接続にするし、この値は0でいっか」と考えて、
この値を0にすると、ODEに接続できなくなります。

この件はマニュアルには記載されていないと思います。

b. ポートの設定

SQL*Plus上で以下のコマンドを実行します。

SQL> SELECT DBMS_XDB_CONFIG.GETHTTPSPORT() FROM DUAL;

DBMS_XDB_CONFIG.GETHTTPSPORT()
------------------------------

ODEを構成しなかった場合は何も表示されないため、
使用するhttpsポートを指定してあげます(デフォルトの値は5500)

SQL> EXEC DBMS_XDB_CONFIG.SETHTTPSPORT(5500);

DBMS_XDB_CONFIG.GETHTTPSPORT()
------------------------------
5500

ちなみに、https接続だけじゃなく、http接続も可能で、

SQL> EXEC DBMS_XDB_CONFIG.SETHTTPPORT(8080)

で設定できます。
加えて、別のDBに別のODEを構成する場合、
既存のODEと同じポート番号は使用できないため、
DBCA実行前に、oracleユーザで以下のように環境変数を設定します。

$ export DBEXPRESS_HTTPS_PORT=5501

c. dispatchersパラメータの設定

dispachesパラメータの設定を行います。
これはOEM構成をしたかどうかに関わらず、
初期化パラメータを触っていなければ最初から設定されています。

ORACLE_SIDがORCL12Cという環境の場合、以下のように設定されます。

SQL> SHOW PARAMETERS dispatchers

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dispatchers string (PROTOCOL=TCP) (SERVICE=ORCL12CXDB)

もし設定されていない場合は、
ALTER SYSTEM SETコマンドで設定する必要があります。

d. local_listenerパラメータの設定

local_listenerパラメータの設定を行います。
これも初期化パラメータを触っていなければ、最初から設定されています。

設定を行う場合、値を直接書き込んでも、
tnsnames.oraを使用しても、どちらでも構いません。

e. リスナーの再起動

最後にリスナーの再起動が必要です。
リスナー再起動後、ポート5500をリッスンするようになります。

$ lsnrctl status

(中略)
リスニング・エンドポイントのサマリー...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostname)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=hostname)(PORT=5500))(Security=(my_wallet_directory=/opt/app/oracle/product/12.1.0/dbhome_1/admin/ORCL12C0/xdb_wallet))(Presentation=HTTP)(Session=RAW))

この件もマニュアルには明確に記載されていないと思います。
 
今回のように、現場ではマニュアルの通りに設定してもうまく動かないといったトラブルに多々遭遇します。一度経験すれば次からは躓きませんが、初めて遭遇した方にとっては有効な情報だと思いますので、今後もこうした情報があれば発信していきます。


以上です。

Oracle Database Express 12c

キャッシュフュージョン(Cache Fusion)のおはなし

こんにちは、Re:Qの宮崎です。

今日はキャッシュフュージョン(Cache Fusion)のお話です。
第1回で言葉だけ出てきましたが、皆さん覚えてますか?

覚えてない方はリンクからざっと1話目を復習して頂くとして、ではここから本題に入りましょう。

キャッシュフュージョン(Cache Fusion)とは

 
各インスタンス君は、頭のなかにシステムグローバル領域(SGA)というメモリ領域を持っています。
そのメモリ領域の中に、データの内容を保持するデータベース・バッファ・キャッシュというものがありましたね。

キャッシュフュージョンとは、各インスタンス君のもつバッファキャッシュを、あたかも一つの大きなキャッシュであるかのように扱う機能のことです。

もちろん、このときキャッシュの一貫性はきちんと保たれており、それに伴ってデータブロックの一貫性も保たれます。 一貫性を保つ秘訣は、インスタンス君たちが持っているグローバル・リソース・ディレクトリ(GRD)というものです。このGRDは、どのデータブロックがどのインスタンスで利用されているかを管理するものです。

3ノードRACをイメージして図に表すと、下図のようになります。
各インスタンスはそれぞれGRDを持っており、データを分割して管理しています。

では、GRDで管理して、キャッシュフュージョンを用いることでどんないいことがあるのでしょうか?

インスタンス君たちの会話を聞いてみましょう。
1話目でもでてきましたが、やはり糸電話をつかっているようですね。

インスタンス君①「データブロック☆を読み込みたいんだけど、誰か持ってない?」
インスタンス君②「俺が管理しているやつだ!確か誰もまだ持ってないから直接読み込んでよ」
インスタンス君①「仕方ないな。面倒だけど読みこもうか...」


インスタンス君①「ふう、ようやく読み終わった。読書なんて嫌いだよ」
インスタンス君③「データブロック☆内のデータAをデータA'に更新するんだって!
         字読むの面倒くさいなー。誰か持ってたらplz!」
インスタンス君②「また俺が管理しているやつか。はいはい。
         データブロック☆は、インスタンス君①が持っているよ。
         ①君、そのデータブロック☆を③に渡してあげてよ。」
インスタンス君①「あいよ」
インスタンス君③「㌧!じゃ、さっそく更新するけど大丈夫だよね?」
インスタンス君①「ただ読んでいるだけで、何もいじってないから大丈夫だよ」
インスタンス君③「②さん、データブロック☆を更新したんでよろしくね」


インスタンス君②「え?データブロック☆内のデータBをデータB'に更新...だと...?
         じゃぁ、③君、君の持ってるのが最新版だから、それをこっちに送って」
インスタンス君③「ほいほい」

一般的にインスタンス君たちは、糸電話で会話するのと比較して、ディスクから文字を読み込むのが遅いです。また、文字を書き込むのも遅いという特徴があります。

そのためデータ競合時に、あるインスタンスが更新したデータを一旦ディスクに書き込み、別のインスタンスがそのデータを読み込むことで間接的にデータを受け渡しするよりも、上の例のように、ディスクの読み書きを経由せずに直接データキャッシュをやり取りするほうが、圧倒的に早くお仕事をすることができます。

具体的にどのくらい処理が速くなるのかというと、もちろん環境によって変わってくるのでしょうが、従来の処理時間が10ミリ秒だとすると、キャッシュフュージョンの使用によりマイクロ秒レベルまで短縮されることもあります。

今回はここまで。

キャッシュフュージョン(Cache Fusion)のおはなし

クラスタ・データベースのおはなし

 
こんにちは。Re:Qの宮崎です。
今回は、RAC(Real Application Clusters)を説明する際に非常に重要な概念であるクラスタ・データベースについてお話しします。

まず普通のデータベース(シングルインスタンス)を見てみましょう。


インスタンス君は非常に仕事熱心で、24時間休まずに働き続けます。
しかし、そんな彼でも急に熱が出て倒れてしまうことがあります。 

そうなってしまうと困るのはユーザです。インスタンス君が倒れている間は誰もデータベースに読み書きすることができないため、システムダウンに陥り業務に支障をきたします。

この問題を解決するために、「インスタンス君が二人以上いれば、一人が倒れても残った人が頑張ればデータベースは動き続けるよね」という発想が出てきます。これがクラスタ・データベースの概念です。

クラスタ・データベースは、複数の独立したサーバを相互に接続し、ひとつのクラスタを構成することで、あるノードが停止しても別のノードが動いている限り、全体のシステムが停止することなく稼働し続けることを可能にします。

言い換えると、高可用性を実現しているわけです。

 

 

クラスタ・データベースと一口に言っても、一般的に複数の構成方法があります。
代表的なものは、共有ディスク構成非共有ディスク構成HA構成の三種類です。

OracleのRACは、共有ディスク構成をとっています。

一般的な共有ディスク構成とは次のようなものです。
すべてのノードから等しく到達できる共有ディスクに、データベースのデータを配置します。データベースの透過性が実現されており、ユーザやアプリケーションサーバがデータベースを利用する際、各ノードによって違うデータが見えたり、操作方法が変わったりのような現象が起こらないようになっています。また、クラスタを構成するノードは、並列構成かつすべてアクティブとなっており、すべてのノードでユーザやアプリケーションサーバなどからの依頼を処理することで、全体で負荷を分散しシステム停止を防止します。

これを図解したものが前回出てきたこの図です。

一方、共有ディスク構成の欠点として、ディスクI/Oが原因で、1から2、2から3へとノードを追加した時に、必ずしも追加数に見合った性能になるとは限らない点があります。また、共有ディスクが、その部分に障害がおこったとき、システム全体が停止してしまう単一障害点になってしまうこともあげられます。

なお、先程OracleのRACは共有ディスク構成と言いましたが、一般的な共有ディスク構成と同じかというと、そういう訳ではありません。OracleのRACは独自の技術をもって、先に挙げた2点の短所を克服しています。(続く…)

クラスタ・データベースのおはなし
資料請求・お問い合わせはこちら

▲ ページトップに戻る

技術ブログ

2022年6月
« 5月  
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
採用に関するお問い合わせはこちら