2015年12月7日月曜日

Oracle Databaseで私がよく見るV$表

今回の記事は、弊社バルテックのアドベントカレンダーにエントリーしています。

Oracle Databaseには現在の状態を調べたいときに確認できるV$表(動的パフォーマンスビュー)というビューが存在しています。
※SQLServerでは同じようなビューとして「動的管理ビュー」が用意されていますね。
V$表の確認にはDBA権限が必要です。RAC環境ではGV$表で確認すると、RAC環境のすべてのインスタンスを取得することができます。

V$表は数百も用意されていますので、さすがにすべて紹介することはできません。今日は私が良く見るV$表を紹介します。


v$instance
現行インスタンスの状態を確認できます。
インスタンスとは、データベースシステムのまとまりのことを言います。
インスタンス名、ホスト名、起動状態などを確認できます。
様々な管理作業をする際、作業対象が想定したものであるかを確認する際に使用します。
https://docs.oracle.com/cd/E16338_01/server.112/b56311/dynviews_2002.htm

v$database
データベースの状態を確認できます。
データベース名、アーカイブログモード、データベースロールなどを確認できます。
https://docs.oracle.com/cd/E16338_01/server.112/b56311/dynviews_1097.htm

v$session
現在実行中のセッションの状態を確認できます。
SQLID、待機イベント、ログイン時間、待機時間などを確認できます。
SQLの長時間化を調査する際に、対象を絞り込むときに使っています。
https://docs.oracle.com/cd/E16338_01/server.112/b56311/dynviews_3016.htm
履歴はv$active_session_historyに記録されています。
https://docs.oracle.com/cd/E16338_01/server.112/b56311/dynviews_1007.htm

v$sql
共有SQL領域にあるSQLの実行回数、SQLテキスト、書き込み読み込みの累計時間、待機時間の累計時間などを確認できます。
SQLIDからSQLテキストを確認できるため、SQLの内容を確認する際に使っています。
https://docs.oracle.com/cd/E16338_01/server.112/b56311/dynviews_3043.htm

v$datafile
データベースに紐づいているデータファイルの状態を確認できます。
表領域名とデータファイルのフルパス、最終変更時間、サイズ、状態(オンライン、オフライン、リカバリ要など)を確認できます。
同じ筺体内に複数インスタンスのデータファイルが混在している場合などに、内容を確認するのに使っています。
https://docs.oracle.com/cd/E16338_01/server.112/b56311/dynviews_1100.htm

v$parameter
現在有効となっている初期化パラメータの値を確認できます。
spfileですとファイルの中身を見ても内容を確認できないので、ちょっと調べたい場合に便利です。
show parameterもありますけど。
http://docs.oracle.com/cd/E16338_01/server.112/b56311/dynviews_2087.htm


他にも様々なv$表がありますので、気になった方は調べてみてはいかがでしょうか。

2015年12月2日水曜日

Oracle DatabaseのASMディスクグループの空き容量を調べる

Oracle DatabaseのASMディスクグループの空き容量を調べる


JPOUG Advent Calendar 2015の2日目です。
前日は吉川 和宏さんでした。


Oracle DatabaseでRACを使用するには、ストレージにASM(Automatic Storage Management)を使用することが多いと思います。
ASMでは、データファイルの格納にディスクグループが使用されます。ディスクグループは複数のディスクをまとめたものです。
格納されたデータファイルはディスクグループ内に均等に分散されるため、ディスクのパフォーマンスは均一になります。

ASMでは、ディスク故障に備えた冗長性を備えています。
・高冗長性   HIGH   3重化
・標準冗長性 NORMAL  2重化
・外部冗長性 EXTERNAL 冗長化なし(ストレージコピーなど他の機能冗長性を保証)

さて、ASMのディスク使用量を調べるには、ASMCMDユーティリティでlsdgをする、もしくはv$asm_diskgroupビューを確認します。


lsdgにはいくつかの項目がありますが、ディスクの残量はどれを見ればよいのでしょう。
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB
MOUNTED  NORMAL  N         512   4096  4194304     12288     8835             1117            3859

容量の項目には以下のものがあります。マニュアルの説明を右に記載します。
Total_MB     : ディスク・グループのサイズ
Free_MB       : 冗長性を考慮しない場合のディスク・グループの空き領域(MB)
Req_mir_free_MB  : ディスク・グループで許容できる最悪の障害が発生した後、
             完全な冗長性をリストアするために
              ディスク・グループで使用可能にする必要のある領域の量
Usable_file_MB  : ミラー化のために調整され、新しいファイルに使用可能な空き領域の量


Free_MBは、「冗長性を考慮しない」とあるので、冗長化をしたディスクの場合はこの値で空き容量を見積もることはできません。
※冗長性が「外部冗長性」の場合はこの値を空き容量とみなして良いです。

では、残りの値を見てみましょう。Req_mir_free_MBとは何でしょう?
この値は冗長性によって違います。
標準冗長性の場合は、1個の障害グループの値となります。
高冗長性の場合は、2個の障害グループの値となります。

障害グループがそれぞれの個数が壊れても大丈夫なように容量を確保する必要があるということのようです。
障害グループを明示的に指定していない場合でも、それぞれのディスクが障害グループとして扱われています。
これらの障害グループ1つまたは2つ分がReq_mir_free_MBとして計算されます。


Usable_file_MBは、新しいファイルに使用可能な空き容量ですので、こちらの値が残り使用できるディスク容量です。
Usable_file_MBは以下の式で産出されます。

(Free_MB - Req_mir_free_MB) / Redundancy*
*冗長性によって異なります。標準冗長性は2、高冗長性は3です


この計算の結果、Usable_file_MBがマイナス値になることもあります。
ただちに問題が発生とならない可能性もありますが、
ファイルが追加できなかったり、次に障害が発生した場合にファイルの冗長性が失われることがあります。


ASMディスクグループの使用量について、実際にファイルを追加しながら表示の変化を検証しているブログが、
以下にあります。
OakTableにも参加されているBreederodeさんのものです。興味のある方は見てみてはいかがでしょうか。
https://prutser.wordpress.com/2013/01/03/demystifying-asm-required_mirror_free_mb-and-usable_file_mb/



明日は kenken0807 さんです。楽しみですね。

2015年10月18日日曜日

JPOUG> SET EVENTS 20151017 でお話をさせて頂きました。

昨日、日本オラクルのセミナールームにて開催された「JPOUG> SET EVENTS 20151017」で1本セッションを担当させて頂きました。
「障害とオペミスに備える! Oracle Databaseのバックアップを考えよう」というタイトルでお話をさせて頂きました。

スライドは以下の場所に置いています。
http://www.slideshare.net/shinnosukeakita5/oracle-database-54077040


初めての機会でしたので、不慣れで分かりづらい点も多かったかと思いますが、
少しでもお役に立てたなら幸いです。
この度はセッションを担当させていただくというチャンスを頂きまして、JPOUGの皆さまには御礼申し上げます。また、私の拙いセッションを聞いてくださった皆様にも感謝申し上げます。
次も機会がありましたらチャレンジしたいと思います。


自分のセッションが終わった後は、「技」セッションを聞いていました。
最後に小田さんと林さんの「DBエンジニアのスキルの現実と伸ばし方」のディスカッションを聞きながら、今後どうスキルアップしていくべきか考えていかないとな、と思いました。

セッションの準備もあってブログも滞りがちでしたが、これからゆっくりとですが記事を書いていきたいと思いますので、たまに覗いていただければ幸いです。

2015年7月19日日曜日

Oracle Masterベータ試験を受けてきました。

先週からOracle Master Data Guardのベータ試験が出たので、受けてきました。
http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=5001&get_params=p_exam_id:1Z0-066

Oracle Master ベータ試験とは?
Oracle Masterの試験を正式にリリースする前に、試しに受けてもらうための試験です。
ベータ版ですので、通常よりも試験問題も多く、試験時間もかなり長いものとなります。
受験できるのはベータ試験期間内に1回だけのようで、合否もベータ試験終了後11週間以内に決定と、かなり遅いものとなります。

もちろん、ベータ版で合格しても正式な資格となります。
たくさん解いた問題の中から、正式の問題となったもののみを採点するらしいので、難易度は通常版と変わらないようです。

ベータ版を受ける利点として試験料は5400円と、通常のOracle Masterの試験の1/5程度で済みますので受験の金銭的ハードルは下がりますし、
正式に出る問題と同じような問題が体験できるので、お試し受験としても受けることができそうです。

受験した感想としては・・・難しかったです。
ただ、重箱の隅をつつくような問題ではなく、きちんとマニュアルを読み込んでおいて、
実機にもある程度触っていれば合格できそうです。
とはいえ、私は11gしか触ったことが無いので、12c関連の問題が出ると辛かったです。
詳しくは言えませんが、試験対象のバージョンを確認し、テスト内容チェックの項目を良く確認して勉強する必要があります。
あとは、英語版ですので英語に慣れておく必要はありますね。
DataGuard試験は出るかわかりませんが、ベータ版には日本語版もありますので、
ベータ試験がリリースされたらチャレンジするのも良いと思います。

DataGuard資格の勉強も一段落したので、実機検証もやっていきたいと思います。

2015年6月16日火曜日

db tech showcase 2015東京に行ってきました

6/10~12にかけて、db tech showcase 2015 東京に行ってきました。
初めての3日間フル参加でした。今回特に注目なのはデータウェアハウスの父と言われるBill Inmon氏の来日でした。
構造定義されていないリレーショナルモデルにうまく適用できない大量の非構造化データを扱うことに価値があるということを話してくださいました。

3日間、様々なセッションを聴き、いろいろなデータベースについて聞きましたが、
Oracle関係で面白くてもっと勉強したいと特に思ったのがこの3本でした。

A12:oRCAle World: Root Cause Analysis
Daniel Morgan氏のこのセッションは、OSやネットワーク観点からのデータベースのトラブル例を語るものでした。
以下のサイトからプレゼンテーションが読めます。
http://www.morganslibrary.org/presentations.html

A35:The Best of Both Worlds: Leveraging In-Memory Column Store Features in Oracle Database 12.1.0.2
Oracle12.1.0.2より導入された新機能、インメモリカラムストアについて、
インメモリ圧縮の概要と通常のバッファキャッシュ折り返しとの処理速度の差について語っていました。
Exadata HCCと比較すると圧縮比率はそこまで高くありませんが、解凍して処理する時間は段違いに速いようです。
このセッションの前日にHistogram Enhancementsについて語っていて、ハイブリッド・ヒストグラムについて話をしていまして、
これらも含めて、大変勉強になりました。

E34:[JPOUG Presents] Oracle Database の隠されている様々な謎を解くセッション「なーんでだ?」再び
AWRやstatspackのレポートと事象を見ながらみんなで原因を考えるセッションです。
私は1問もわかりませんでした。。


様々な学びをくれたdb tech showcase 2015。また次回も時間を見つけて参加したいと思います。
懇親会では講師の方とお話をすることもでき、大変刺激になりました。

2015年4月29日水曜日

Exadata Smart Flash Loggingとは

OLTPでは、データベース・ログ書き込みの応答時間が短いことが重要です。
データベースには、更新後情報をREDOログに書き込みますが、パフォーマンスの低いディスクがREDOログへの書き込み待機時間のためにシステムのパフォーマンスに悪影響を及ぼすことがあります。
また、ディスク・ドライブ自体でも、パフォーマンスにおいてたびたび"一時的な停止"が発生することがあります。これらのパフォーマンスの悪化がデータベース・パフォーマンスに大きく影響する可能性があります。

Smart Flash Logは、OLTPワークロードに対応するためのExadataの独自機能です。
Smart Flash Loggingを使用するには、
 Storage Software 11.2.2.4以降
 Oracle Database  11.2.0.2以降
が必要になります。

Smart Flash Loggingは、Exadata Database Machineのフラッシュ・ハードウェアを利用します。
Smart Flash LoggingはREDOログをフラッシュ内に配置するだけではなく、二重化、ミラー化もします。
ただ、それだけですとパフォーマンスの低いディスクがREDOログへの書き込み待機のためのシステムのパフォーマンス悪影響は解決しません。
最大の利点は、ExadataはREDOログの書込み要求を受け取ると、ディスク上のREDOログとフラッシュ・ハードウェアパラレルに書込みを実行します。
これらの書込みのいずれかが完了したときに、データベースに対して即座に処理の完了を通知します。
ログをホストしているディスク・ドライブの応答時間が長い場合は、ExadataSmart Flash Cacheのログ書込みの応答時間がより短くなります。

デフォルトでは、512MBのExadataフラッシュがSmart Flash Loggingに割り当てられます。それぞれのExadata Cell Diskに1.6TBのフラッシュがあることと比較すると、小さな量で大きなパフォーマンス上の効果を得ることができます。

2015年4月6日月曜日

Data Guardの基礎知識(1)

ブログの期間がだいぶ空いてしまいました。
最近Data Guardを扱うことがあり、ここで一度きちんと勉強したいと思いましたので、
今日から何回かに分けて、Data Guardについて記事を書いていきます。お付き合い宜しくお願いします。

さて、Data Guardとは・・・
Oracle Databaseを使用する上で、障害時のデータ保護を補償するためにデータを遠隔地のサーバに同時転送する機能として使用されるのが、
Data Guardです。

Data Guardの構成には、1つのプライマリデータベースと1つ以上のスタンバイデータベースが必要となります。

プライマリデータベース : 本番データベース
スタンバイデータベース : コピーデータベース

スタンバイデータベースはプライマリデータベースの一貫性のあるコピーです。
プライマリデータベースからスタンバイデータベースにREDOデータを転送して、スタンバイデータベースでREDOデータを適用することで
スタンバイデータベースにコピーしていきます。

スタンバイデータベースには、フィジカルスタンバイデータベースとロジカルスタンバイデータベースがあります。
フィジカルスタンバイデータベースは、REDOデータをそのまま適用し、ロジカルスタンバイデータベースはREDOデータをSQL文に変換して適用します。


さて、これら2種類のスタンバイデータベースはどのように選択すべきでしょうか?
フィジカルスタンバイデータベースは、REDOデータをそのまま適用するので、物理的に全く同一になります。物理バックアップとして使用することができます。
一方、ロジカルデータベースはSQL文で適用されるため、必ずしも同一にはなりません。
しかしながら、プライマリデータベースには無いテーブルを追加することができるというメリットがあります。


さて、次からはプライマリデータベースからスタンバイデータベースを作成する手順について、
書いていこうと思います。

2015年2月11日水曜日

Neo4jユーザーグループの勉強会に行ってきました。

2月10日にNeo4jの勉強会に行ってきました。
http://jp-neo4j-usersgroup.connpass.com/event/11305/

Neo4jとはグラフDBの一種で、物と繋がりで表現するデータベースです。
たとえば、電車の路線図でいうところの、駅と路線をイメージしてもらえれば、想像しやすいかもしれません。

ここらへんのサイトがわかりやすそうです。
http://www.omotenashi-mind.com/index.php/Neo4j%E3%81%A7%E5%AD%A6%E3%81%B6Graph_DB%E5%85%A5%E9%96%80


イベントではDavid Montag氏のプレゼンテーションを通訳してもらう形で進みました。
RDBMSでスキーマ設計をすると複雑になってしまう、もしくは変更時に大幅な変更が出てしまうようなケースにおいての
グラフDBの優位性、他のNoSQLと比較した優位性について話をされていました。
高い同時実行性を持ちながら、ACID特性を保持しており、粒度が細かいため(物と繋がり単位でのロック?)ロック待ちも少ないとのことでした。
どうやってデータを探していくのかといったところが気になりましたが、それは次回以降に期待したいと思います。

次回はNeo4jを作っているNeoTechnology社のCOOが登壇されるようなので、また行ってみようと思います。
今後が楽しみなデータベースでした。

2015年1月25日日曜日

ORA-01795: リストに指定できる式の最大数は1000です

先日、自社に帰社したら、別の現場の方から
「OracleではIN句が1000個までしか指定できないので、回避策は無いか」
といった相談を受けました。

たとえば、こんなSQLで考えてみました。
select bonus from salary
 where empno in (select empno from employee where prefecture = 'CHIBA');

このとき、千葉県の社員が1000人を超えるとORA-01795が発生します。


さて、どうやってSQLを書き変えましょうか。
IN句を書かずにこう書いてみます。

select bonus from salary,employee
 where employee.prefecture = 'CHIBA' and salary.empno = employee.empno;

EXIST句で書く方法もあります。

select bonus from salary
 where exists
 ( select empno from employee
   where prefecture = 'CHIBA'
   and salary.empno = employee.empno);

AccessでSQL実行してみましたが、問題無く動きました。
IN句とEXIST句の書き換えが難なくできるようになりたいものです。

2015年1月10日土曜日

ORA-01111 : name for data file XX is unknown

新年あけましておめでとうございます。今年も宜しくお願い致します。

さて、年初よりDataGuardと格闘をしております。
先日、訳あってスタンバイデータベースをリカバリしていたら、こんなエラーが出てしまい、ハマってしまいました。

ORA-01111: name for data file 47 is unknown ? rename to correct file
ORA-01110: data file 47: ‘/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00047′
ORA-01157: cannot identify/lock data file 47 ? see DBWR trace file

プライマリ側でデータファイルが追加になったのですが、スタンバイデータベースに表領域作成がされないため、
データベースが困っている状態のようです。

こんなときは、表領域を作成する必要があります。

alter database create datafile '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00047'
as '+DATA/sakedb/aquavit.dbf';

データファイルが作成できたら、あとはrecover standby databaseでスタンバイデータベースを復旧できます。