ORACLE RAC環境構築 Oracle Grid Infrastructure11gR2インストール時、RHEL(x86) × AMDの環境でroot.shの実行に失敗する。
RHEL5.9(x86)で、Oracle Grid Infrastructure11gR2インストール時に、root.shの実行に失敗する
OLRの作成に失敗し、「signal 11」のエラーが返却される。：Setting ocr location +CRS
：Creating or upgrading Oracle Local Registry (OLR)
：Failure with signal 11 from command: {$GRID_HOME}/bin/ocrconfig -local -upgrade grid oinstall
：{$GRID_HOME}/grid/bin/ocrconfig -local -upgrade failed with error: 11
：Failed to create or upgrade OLR
原因
AMDとOracle Grid Infrastructure11gR2の相性が悪いらしくバグが発生するらしい。64ビットのアドバンスト·マイクロ·デバイス（AMD）のAthlonのハードウェア上でLinux 32ビットオペレーティングシステムを実行している場合、CPUタイプが正しく識別されない。またDBCAやNETCAも起動しない。
【バグ番号：8670579】
http://docs.oracle.com/cd/E11882_01/readmes.112/e11015/toc.htm
When running the Linux 32-bit operating system on 64-bit Advanced Micro Devices (AMD) Athlon hardware, there is a bug in third party code where the CPU type is not correctly identified. This may result in an application crash when using DBCA or NETCA startup.
対策
Oracle Clusterwareの構成解除
root.shを一度実行してしまった場合、構成解除してから、再度root.shを実行する必要がある。以下を参考ORACLE RAC環境構築 root.shの実行に失敗した場合の対処 - へっぽこSEブログ
ORACLE RAC環境構築 root.shの実行に失敗した場合の対処
root.shの実行ログの場所
root.sh 実行中に問題が発生した場合には、- クラスタ用 Grid Infrastructure の場合
/cfgtoollogs/crsconfig/rootcrs_ .log
- スタンドアロン・サーバ用のGrid Infrastructure の場合
/cfgtoollogs/crsconfig/roothas.log
ソフトウェアを削除せずに行うOracle Clusterwareの構成解除
root.sh 実行中に問題が発生した場合は、Oracle Clusterwareの構成解除が必要な場合がある。 フラグ-deconfig -forceを指定してrootcrs.plコマンドを実行すると、インストールしたソフトウェアを削除しなくても、1つ以上のノードでOracle Clusterwareの構成を解除できます。
この機能は、共有記憶域を誤って構成した場合など、インストール中に1つ以上のクラスタ・ノードでエラーが発生した場合に役に立ちます。エラーの原因を修正してから、再度rootcrs.plを実行できます。
- 1つのノードの構成解除
cd/crs/install
perl rootcrs.pl -deconfig -force
- クラスタ内のすべてのノードの構成を解除。(最後のノードで次のコマンドを入力します)
cd/crs/install
perl rootcrs.pl -deconfig -force -lastnode
修正が終わったら、再度root.shを実行する。
ORACLE RAC環境構築時のSSH設定
ORACLE RAC環境構築時のSSH設定
各クラスタ・ノードに、sshパスワードログイン無しの設定し、SSHユーザー等価関係の有効化をする必要がある。- 各クラスタ・ノードのsshd_configの設定
- 各クラスタ・ノードの公開鍵と秘密鍵の作成
- 各クラスタ・ノードの公開鍵を含んだauthorized_keysの作成
- SSHユーザー等価関係の有効化の確認
各クラスタ・ノードのsshd_configの設定
vi /etc/ssh/sshd_config〜 省略 〜
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeyFile .ssh/authorized_key
〜 省略 〜
- サーバ再起動
/etc/rc.d/init.d/sshd restart
各クラスタ・ノードの公開鍵と秘密鍵の作成
mkdir /home/grid/.ssh
chmod 700 /home/grid/.ssh
/usr/bin/ssh-keygen -t rsa※コマンド実行後、公開鍵「~/.ssh/id_rsa.pub」、秘密鍵「~/.ssh/id_rsa」が作成されていることを確認。
各クラスタ・ノードの公開鍵を含んだauthorized_keysの作成
ここでは、node1とnode2がクラスタ・ノードとする。- node1でauthorized_keysを作成
[grid@node1 ~]$cat id_rsa.pub >> authorized_keys
- node1で作成したauthorized_keysをnode2にSCPで送る。（鍵を受け入れるように求められる場合、Yesと入力する。コピー先のノードがknown_hostsファイルに追加される。）
[grid@node1 ~]scp authorized_keys node2:/home/grid/.ssh/
- SCPで送られてきたauthorized_keysにnode2の公開鍵を追加（node1とnode2を鍵情報を含んだauthorized_keysが作成されます。）
[grid@node2 ~]cat id_rsa.pub >> authorized_keys※ノードが3個以上ある場合は、上記手順で authorized_keysに各クラスタノードの情報を追加していく。
- クラスタ・ノードの公開鍵の情報を含んだauthorized_keysを全てのノードにコピーし、権限を600に設定する。
chmod 600 /home/grid/authorized_keys
SSHユーザー等価関係の有効化の確認
各クラスタ・ノードから全てのノードに対して、以下のコマンドを打ち、パスワードが聞かれないことを確認。（known_hostsに追加されていない場合、鍵を受け入れるように求められるので、Yesと入力する。）[grid@node1 ~]$ ssh node2 date
Mon Feb 27 23:34:42 UTC 2013
[grid@node1 ~]$ ssh node1 date
Mon Feb 27 23:34:48 UTC 2013
設定がうまくいかない場合
ORACLE RAC環境構築 GNSへのドメイン委任のためのDNS構築
GNSへのドメイン委任のためのDNS構築
備忘録として残す。Oracle Grid Infrastructureのインストール時に、GNSを使用する場合、サブドメイン(クラスタ・メンバー・ノード)に対する名前解決要求がGNSへ委任されるように、DNSを構成する。
- DNSでGNS仮想IPアドレスのエントリを作成。(ドメイン名がexample.comで、IPアドレスが192.168.11.200の場合)
クラスタ名.example.com A 192.168.11.200
xxxxxx.example.com NS クラスタ名.example.com※ xxxxxx.example.comは委任するサブドメイン
- 各クラスタ内のノードのresolv.confの編集
vi /etc/resolv.conf
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
search xxxxxx.example.com example.com
nameserver xxx.xxx.xxx.xx(有効なDNSサーバ)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
GNSを使用した時の、ネットワーク例
クラスタノードがnode1,node2の二つだった場合| ID | 種類 | アドレスの割当て元 | 解決方法 |
|---|---|---|---|
| GNS VIP | 仮想IP | ネットワーク管理者が固定 | DNS |
| ノード1パブリック | パブリックIP | 固定 | GNS |
| ノード1 VIP | 仮想IP | DHCP | GNS |
| ノード1プライベート | プライベートIP | 固定またはDHCP | GNS |
| ノード2パブリック | パブリックIP | 固定 | GNS |
| ノード2 VIP | 仮想IP | DHCP | GNS |
| ノード2プライベート | プライベートIP | 固定またはDHCP | GNS |
| SCAN VIP 1 | 仮想IP | DHCP | GNS |
| SCAN VIP 2 | 仮想IP | DHCP | GNS |
| SCAN VIP 3 | 仮想IP | DHCP | GNS |
ORA-00374 ブロックサイズ32KB指定時のエラーについて。
ORA-00374 ブロックサイズ32KB指定時のエラーについて
Oracle 11gリリース2 (11.2) for Windows（x64）で、DB_BLOCK_SIZEに32KBを指定したら、以下のようなエラーメッセージが表示された。結果から先にいうと、Windowsでは2KB〜16KBしか指定できないよ。ってことらしい。
ORACLEでは、ブロック毎にI/Oが発生する。そのためチューニングする上で、DB_BLOCK_SIZEの値を変更する必要があった。
ORACLE@DATABASEリファレンスからDB_BLOCK_SIZEの有効値を調べたところ「ただし、オペレーティング・システムによっては、さらに範囲が狭い場合がある。」と記載されていた。
また「64ビットのオペレーティング・システムがサポートするDB_BLOCK_SIZEの最大値は32768です。」と記載されてあった。また、自分の持ってるORACLEの本にも同様の記述が書かれていた。
この記述をみてしまうと、Windows(x64)の制限値がわかりずらい。一見、32KBを指定できそう。
調べたら、Windows（x64）には制限2KB〜16KBがあることがわかった。 Windows版のプラットフォームガイドを参照
16KBを指定したら、問題なくDBを作成することができた。マニュアルが多すぎて、ソースにたどり着くまで時間がかかった。また検索しても、プラットフォーム毎の制限を書いてある記事がすくなかった。よって、記事を書くことにした。
DB_BLOCK_SIZEがOSによって異なることで発生する問題
例えば、DB_BLOCK_SIZEが32KBで指定してあったUnixのOSから、Windows版に移行する。などがあった場合には、制限値による問題が起こる。その場合は、事前に、DB_BLOCK_SIZEの変更が可能か確認する必要があると思う。また、OSによって設定値の制限が異なるため、移行時はOS毎のマニュアルを参照する必要がある。他OSのDB_BLOCK_SIZE
OracleDatabase管理者リファレンス11gリリース2 (11.2) for Linux and UNIX-Based Operating Systemsを参照したところ、「DB_BLOCK_SIZEに設定できる最大値は、Linux x86の場合16KBです。その他のプラットフォームの場合、32KBです。」と記載されている。よって、以下のようになると思う。
※ Unix（AIX,Solaris,HP-UX）によっても制限がある可能性があるため念のため確認したほうが良い。
| Windows(x86、x64) | 16KB |
| Linux or Unix(x86) | 16KB |
| Linux or Unix(x64) | 32KB |
参考：DB_BLOCK_SIZE指定の判断基準
DB_BLOCK_SIZEの正しい設定値は、データベースの処理特性や格納されるデータによって異なる。ランダムアクセス主体のOLTPやWebシステムでは索引検索による単一ブロックI/Oが主体になるため多ければいいってものじゃない。シーケンシャルが主体のDWHシステムの場合は、大きいほうが良い場合もあるでしょう。以下のサイトがわかりやすく書いてあった。
OTN Japan - Oracle9i 物理設計：第1部 DB全体の設計
2012年での出来事を振り返って
エンジニアが一人前になるために必要な時間「10000時間」
会社の先輩が言っていたことで印象に残っています。ITエンジニアが一人前になるために必要な時間の目安として「10000時間」というラインがあるそうです。仕事の稼働時間 ＋ 個人勉強時間 ＝10000時間
転職したのが去年の1月。IT業界に入ってちょうど2年なので、いまどれくらい時間を費やしているか計算してみた。
個人勉強期間はわからなかったので、仕事の稼働時間の1割にしてみた。このペースだとあと二年はかかるみたいです。うちの会社は3年で一人前になれという方針がありますが、今の自分の状況だと3年で一人前は厳しいですね。
初めてのプロジェクトリーダー
とあるパッケージ製品のテストフェーズで、プロジェクトリーダーをやりました。初めてで要領悪かったのが大きいのですが、一番苦労した点は、以下の三つです。- お金をかけるべきところとかけなくていいところ
- 体制や仕組み作り、コミュニケーション計画
- マルチタスク
1. お金をかけるべきところとかけなくていいところ
パッケージ製品は、1障害に対してのインパクトがでかいです。例えば以下の左図ようにテスト全体にかけるお金が500万だったとしても、右図のように障害の事象によっては1障害がでたときの対応する総金額が500万以上になる場合があります。
とはいってもコスト/リソースは有限であり、いくら工数をかけても100%障害がでないってことはありえない。なので「工数をかけるべきところとかけないところ」の判断をしていかなければなりません。コストやリソースが足りない場合、「レビュー」や「調査」「テスト」の部分など、優先度を決めて低いのを削っていかねばなりません。特にプロジェクトは進行中は、さまざまなイベントが発生するので、それに対して優先度を臨機応変に判断するのが難しかった。
マイルストーン毎に、定期的に再考慮する時間を作っておいたほうが良いと痛感しました。
2. 体制や仕組み作り、コミュニケーション計画
管理をする際、要員やコストなど様々な理由から、自分に作業ベースのタスクを多く積んでしまい稼働的な意味で失敗した。さきほども書きましたが、プロジェクトは進行中さまざまなイベントが発生するので、課題に対応する時間などを作れないと後に苦しいです。ある程度バッファ見込んでたのですが、計画よりも多くかかる傾向がありました。また、コミュニケーションの疎通がとれているつもりで取れてなかったことが後からわかったりと、うまく回る体制や仕組み作り、課題対応への計画が余ったようです。
プロジェクトにもよるかもしれませんが、初めて管理をする場合は、あまり自分へ作業ベースのタスクを振らないほうがいいかもしれません。周りに吸収してもらうような仕組み作りや体制に力を入れたほうが、後に予期せぬイベントが発生した場合にうまく回る場合があるということを学びました。
3. マルチタスク
同時期に複数のプロジェクトの管理をやりました。タスクが増えてくると、1タスクに対しての生産性が100%の力でだせない。計画段階では一人分の生産性100%で見込んでしまっているため、見込み工数とずれていく。
プロジェクトはイベントが多発するので、今実施しているタスクよりも優先度の高いタスクが発生した場合、そちらに着手することになり、現在のタスクが後回しになったりとなって、結果あれやったりこれやったりと臨機応変に対応していると、1タスクに集中できないため、本来3hで終わる作業が、4h以上かかったりと見込んだ工数とずれてしまいます。
マルチタスクのときは、少しバッファもたないとだめだと痛感した。
やってみて振り返ると
苦しかったところもあったけど、この経験は財産になりました。チャンスをくれた関係者に感謝。周りの関係者に恵まれたのか、やりやすい環境で出来て成長も実感できた。最後のプロジェクトでは、もう一回やってほしいと何人かに言われ、やってよかったと思ったし、自信にもなった。まだまだ課題がありますが。
初めての見積作業とRFP作成
今年は、見積をたくさんやりました。特に「RFPの作成」「RFPを元に見積書を作ること」の両方経験できたことは貴重でした。両方の立場のタスクを経験したことで、「RFPにははどんな情報が書かれていると、相手は見積作成しやすいか、QA頻度が下がるか」「見積書を書くときにどんな点に注意しなければならないか（スコープや納品物、瑕疵担保など）」というのがかなり実感でき:ました。
詳しくは今後のブログに書きたいと思います。
ここからは、今年の1月に2012年の目標を立てたのでそれを元に振り返る
2012-01-11 - へっぽこSEブログ
スキルでの評価ついて
去年は意識とか取り組みによって評価されたので、今年は技術スキル等で頼られたい。という目標を立てました。今年は自社他社からいろいろチャンスをもらえたので、そのことからある程度は、スキル面でも認められたのかなと思っています。ただ、いまだに自分のスキルや技術がどのレベルにいるかよくわからないです。同じキャリアの人と比較して、技術スキルは向上できているのだろうかとか、不安が常にぬぐえないです。隣の芝生は輝いてみえるのです・・。まあ不安がモチべになったりもするのですが。
アプリの公開について
これははっきりいうと達成できませんでした。APIが公開されているサービスのWebClientを作った程度でした。さぼっちゃいましたブログの更新について
あきらかにさぼりました。来年頑張る。去年：50回 / 139日
今年：21回 / 365日
歯医者について
これは達成できました。虫歯なくなった！去年のおみくじから今年の実績を比較して
確かに物事の達成が困難だったことが多かった。長い川を渡って、渡り方がへたくそだったから。
おみくじすごい
今年全体を通して
今年は色々新しいことをやって成長は実感できたし、充実できた一年でした。関係者の皆さん今年ありがとうございました。来年もよろしくお願いいたします。
大容量データの分析に向いているデータベース「infiniDB」
「infiniDB」は、大容量データベースの分析に向いているMySQLのストレージエンジンです。特徴を調べてみた。
I/Oをできるだけ減らすように特化したアーキテクチャ
◆列指向型データベースのアーキテクチャ
一般的なリレーショナルデータベースでは、データを行単位で扱います。あるデータを参照したい場合には、目的のデータがある行を探して、その行を読み込むことで参照します。一方、列指向型データベースは列方向にデータをまとめて扱っています。行の場合は、すべてのカラムを読み込まなくてはいけませんが、列指向データベースの場合は、「必要な列にだけアクセスする」という考え方。カラムが20列あったとしても、アクセス対象が3列しかない場合、3列分しかアクセスしない。必然的にI/Oが減る。
- 行指向型と列指向型データベースの違い
◆エクステントの単位が8MB
MySQLの代表的なストレージエンジンのInnoDBと同じで、データをエクステントという単位で持ってる。InnoDBの場合は、エクステントのサイズが16KBなのに対して、InfiniDBは列ごとに8MBの領域を用意。エクステント毎にI/Oが発生するため、BIシステムのように一回にアクセスするデータが多い場合は、必然的にI/Oが減る。そのかわり一回のI/O単位が大きいため、主キー検索を大量に発行するような用途には向かない。以下は、データ概念。
低メンテナンス
◆自動垂直および水平パーティショニング
自動パーティション化されます。DBAが前もってパーティションに名前を付けたり、定義する必要はない。エクステントという単位で縦だけでなく横方向にもパーティショニングを行っている。
◆インデックス作成の必要はない
infiniDBはデータを列ごとにエクステントという単位で持っている。エクステント・マップと呼ばれる機能で、エクステント同士が論理的に結びついている。どのエクステントにどのデータが記録されているかは、Mapとして記録される。列ごとに「エクステント」を数MBごとに領域を持ち、各エクステントの最小値と最大値をMapで管理している。このMapがインデックスの機能を果たしている。
◆圧縮
列ごとの圧縮が可能。列内のデータは似た値が多いので圧縮効率が良い。
◆分散型のシェアード・ナッシング・データ・キャッシュ
infiniDBV3から対応。共有ディスクが不要となるため、拡張の際にもコストを抑えやすい。大量データ処理の際に最大のボトルネックとなるディスクへの物理I/Oを分散、抑制できるので、データ処理性能の大幅な向上が期待できる。
◆クラッシュ・リカバリー
システムクラッシュが発生した場合は、自動的にデータの整合性を維持し、システムの再起動時の操作フォワードとロールバックをサポートしている。oracleのインスタンスリカバリのようなものかな？
