2017年4月25日火曜日

ログマイナーを試してみる

Oracle LogMinerは、Oracle DatabaseのREDOログファイル(オンライン・アーカイブともに)の内容ををSQLで問い合わせることができるものです。
REDOログファイルの内容を見ることができるようになることで、データベースの履歴情報が確認できます。

LogMinerを使用するためには、REDOログファイルに対して追加の列を用意し、記録をする必要があります。追加の列に記録することを「サプリメンタル・ロギング」といいます。
デフォルトでは、Oracle Databaseはサプリメンタル・ロギングは有効になっていません。そのため、LogMinerを使用したい場合はサプリメンタルロギングを有効にする必要があります。

まずは、現在のデータベースの設定を確認し、サプリメンタル・ロギングが有効か確認します。

SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;
SUPPLEME
--------
NO


NOはサプリメンタル・ロギングが設定されていないことを示しています。

さて、それではサプリメンタル・ロギングを有効にしましょう。

SQL> alter database add supplemental log data;
Database altered.
SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;
SUPPLEME
--------
YES


有効になりました。

さて、LogMinerによるデータの取得をしてみましょう。

1.LogMinerディクショナリの指定
ディクショナリの指定を行うことができますが、今回はLogMiner起動時に指定したので、
特になにもしませんでした。

2.REDOログファイルの指定
LogMinerのデータを取得したいREDOログファイルを指定します。
まずは、今使われているのオンラインREDOログファイルを確認します。


SQL> select member from v$logfile;
MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/balloon/redo03.log
/u01/app/oracle/oradata/balloon/redo02.log
/u01/app/oracle/oradata/balloon/redo01.log
SQL> select * from v$log;
    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE  MEMBERS ARC
---------- ---------- ---------- ---------- ---------- ---------- ---
STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------------- ------------- --------- ------------ ---------
1    1       1   52428800   512 1 YES
INACTIVE       1127233 13-NOV-16      1147535 09-APR-17
2    1       2   52428800   512 1 NO
CURRENT       1147535 09-APR-17   2.8147E+14
3    1       0   52428800   512 1 YES
UNUSED     0    0

現在はredo02.logを使用されているため、今回はredo02.logを確認したいと思います。

SQL> execute dbms_logmnr.add_logfile(logfilename => '/u01/app/oracle/oradata/balloon/redo02.log', options=> dbms_logmnr.new);
PL/SQL procedure successfully completed.

指定が完了しました。

3.LogMinerを起動
LogMinerを起動します。ここではディクショナリの指定にオンラインカタログを使用します。
オンラインカタログはオンラインREDOログ、アーカイブREDOログの分析に使用できます。

SQL> execute dbms_logmnr.start_logmnr( options => dbms_logmnr.dict_from_online_catalog);
PL/SQL procedure successfully completed.

★ここで、REDOログに記録するSQLを発行します。
今回は、qb.keiyakuテーブルに新たに行を追加したのち、削除後ロールバックした場合と削除後コミットした場合のログを見てみます。

SQL> select * from qb.keiyaku;
NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10

SQL>  insert into qb.keiyaku values('oriko',to_date('2011/03/20','yyyy/mm/dd'));
1 row created.
SQL> commit;
Commit complete.

SQL> select * from qb.keiyaku;
NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10
oriko     20-MAR-11 ★
6 rows selected.

SQL> delete from qb.keiyaku where name = 'oriko';
1 row deleted.
SQL> rollback;
Rollback complete.

SQL> select * from qb.keiyaku;
NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10
oriko     20-MAR-11 ★
6 rows selected.

SQL> delete from qb.keiyaku where name = 'oriko';
1 row deleted.
SQL> commit;
Commit complete.

SQL> select * from qb.keiyaku;
NAME     KEIYAKUBI
-------------------- ---------
madoka     03-OCT-10
homura     01-AUG-09
mami     01-AUG-10
sayaka     15-OCT-10
kyoko     01-MAY-10

4.REDOログの内容を確認
REDOログの内容を確認します。
確認するには、SQLにてv$logmnr_contentsビューを確認することで可能となります。

set line 6000
select SCN,TIMESTAMP,TABLE_NAME,OPERATION,SQL_REDO from v$logmnr_contents where operation!='INTERNAL';
       SCN TIMESTAMP TABLE_NAME      OPERATION       SQL_REDO
(略)
   1152964 15-APR-17 KEIYAKU      INSERT       insert into "QB"."KEIYAKU"("NAME","KEIYAKUBI") values ('oriko',TO_DATE('20-MAR-11', 'DD-MON-RR'));
(略)
   1153175 15-APR-17 KEIYAKU      DELETE       delete from "QB"."KEIYAKU" where "NAME" = 'oriko' and "KEIYAKUBI" = TO_DATE('20-MAR-11', 'DD-MON-RR') and ROWID = 'AAASAfAAEAAAAEPAAB';
   1153180 15-APR-17 KEIYAKU      INSERT       insert into "QB"."KEIYAKU"("NAME","KEIYAKUBI") values ('oriko',TO_DATE('20-MAR-11', 'DD-MON-RR'));
   1153181 15-APR-17      ROLLBACK       rollback;
(略)
   1153193 15-APR-17 KEIYAKU      DELETE       delete from "QB"."KEIYAKU" where "NAME" = 'oriko' and "KEIYAKUBI" = TO_DATE('20-MAR-11', 'DD-MON-RR') and ROWID = 'AAASAfAAEAAAAEPAAB';
   1153194 15-APR-17      COMMIT       commit;

略としてある場所には、裏で発行SQL文をv$sqlに格納するなど、システム側の動きがありました。

5.LogMinerを停止
最後にLogMinerを停止します。

SQL> EXECUTE DBMS_LOGMNR.END_LOGMNR;
PL/SQL procedure successfully completed.

以上のような手順でログマイナーを使用できます。
オペミスなどのときにも確認に使えそうですね。

ただ、気になるのはシステムへの負荷。
今回試してみたのは「最小サプリメンタル・ロギング」でしたが、最小サプリメンタル・ロギングでは、マニュアルで読む限り、さほど負荷は大きくならないとなっています。もちろん、導入の際にはしっかり事前検証が必要でしょう。
行の内容までを記録できる「認識キー・ロギング」もありますが、こちらは最小サプリメンタル・ロギングと比べると負荷が大きくなるようです。

2017年2月26日日曜日

海外カンファレンスに行く(8):渡航を終えて

これまで6回に分けてブログに書いてきました、5泊7日の海外カンファレンス参加を終えました。
本場アメリカでのカンファレンス参加は刺激的なもので、遠く日本からの参加者への物珍しさもあり、親切にもしてもらえましたし、楽しませてもらいました。

特に、Welcome Receptionで技術の話を1対1で話すイベントは、英語力の無さがあって聞けなかったものがあったものの、アメリカのExpert達が語るデータベースへの思いだとか悩みだとかが聞けました。
日ごろ携わっている仕事でぶち当たる課題が、地球の裏側でも起きていて、同じように(もしくはもっと画期的な方法で)取り組まれているのだと思うと、不思議な思いがしました。
OracleOpenWorldなど、もっと大きな規模のカンファレンスもありますが、手作り感があり話し手と近いRMOUG Training Daysに参加できたことはとてもよかったです。

またお金をためて、私はデンバーに訪れることでしょう。
長々とした連載となりましたが、最後まで見てくださりありがとうございました。

2017年2月24日金曜日

海外カンファレンスに行く(7):RMOUG Training Days 2017参加3日目その2

前回のエントリの続きです。

[Session9: From 10046 to Real-Time Monitoring/ASH/Modern Techniques for Diagnostics]
10046トレース、ASHからリアルタイム監視をするセッションです。
スライドの文字が小さく、話す言葉も速くてついていけませんでした…。

[Session10: Bulletproof Your Data Guard Environment]
DataGuard環境を守れ! ということで、DataGuardのセッションです。
・Oracle7.3のホットスタンバイから始まったDataGuardは、11gでActive Data Guard、12cでFar Syncが採用された。
・Far Syncインスタンスは、プライマリDBとそれほど離れていない場所に作成する必要がある。
・DataGuardは12.2からブロック比較(Block Comparison)ツールがDGMGRLにできる。
・Active DataGuardでインメモリが使用できる。
・Active DataGuardでAWRが使用できる(今まではstatspackしか使えなかった)。
・DataGuardのよくある失敗として、スタンバイ適用前にデータファイルを削除したり、ASMディスク領域がExhaustion(疲労)したりといったことがある。
・リスナーの設定にSEND_BUF_SIZEとRECV_BUF_SIZEの設定をしてあげよう。
・ブロックチェンジトラッキングファイルをEnableにしてあげよう。
等など、書ききれないほどの注意点を教えてもらいました。

セッション後に質問して、通常、DataGuard環境を最大保護モードとすると、スタンバイDBがダウンするとプライマリDBもダウンすることになるが、Far Syncを最大保護モードに設定した場合、Far Syncインスタンスがダウンすると同様にプライマリもダウンするのか聞きましたが、この場合はダウンすることは無いようです。

[Session11: Virtualization 101 and Q&A]
・仮想化の適用は年々増加している。移行のプランにも物理より仮想化が増えてきている。
・新しいスキルへの適用をしていきましょう。DBAにとってはパーティショニングの考え方に似ているかもしれない。
スナップショット、コピーデータ管理、テストデータ管理などを図で説明頂きました。

これですべてのセッションが終わりました。この日はコンビニで夕飯を買って、最後の夜を過ごしました。

2017年2月23日木曜日

海外カンファレンスに行く(6):RMOUG Training Days 2017参加3日目その1

だいぶ長くなってしまいましたが、開催3日目の報告です。

<DAY5>
この日も朝からカンファレンスです。朝食会で声をかけてくれる人もちらほらいらっしゃり、心細さも無くなっていきました。
[Session6: Stabilizing Performance After Oracle 12c Upgrade]
・プラン・スタビリティのお話
・12cへのアップグレードの方法として、
 アップグレードするか、マイグレーションか
 マルチテナントを使用するか
 DBUAを使うか、コマンドラインでアップグレードするか
といった項目がある。
・テストを行う方法として、RAT(Real Application Testing)の活用、SQLパフォーマンスアナライザの使用のほか、テストしたSQLで性能悪化したものをASHやAWRで解析するなど考えられる。
・SPMを使用する方法も考えられます。SPMの実行に当たっては、ドキュメントやバグ、パッチの情報を見ておく必要がある。
・11gCBOはバグがあっていくつかは12cで直っているが、12cで全部実行計画が良くなるわけではない。

[Session7: Holistic Approach to Database Security]
・攻撃により、怪しいデータになったり、データロストしたり、パスワードが盗まれたりというリスクが考えられる。
・パスワードのフレーズもグーグルで検索できてしまうため、暗号化したから大丈夫とも言えなくなっている。
・DBを信頼できる状態にするために、Real Application SecurityやPL/SQLによる方法がある。
・SQLインジェンクション対策として、デリケートなデータとそうでないものを分けて、デリケートなものは権限をつけてDBへ見に行かせるようにする工夫が必要。
・どんなデータを扱っているかわかってしまうので、PL/SQLのコードに必要以上にコメントをつけない。
・参考としてSQLインジェクションのホワイトペーパーを見てみるとよい。

[Session8: Big Data Solution Architecture: Kafka, Spark, Cassandra, and Oracle Technology Integration]
Kafka、Spark、Cassandraをどう使うべきかというセッションでした。
・Kafkaはメッセージングシステムで、ソースのデータからクエリを使ってデータを引っ張っていく処理を行う。増分で引っ張るか、すべて引っ張るかを選択可能。
・Sparkは、Scala、JavaまたはPythonで書かれている。SparkのストリーミングをKafkaがひっぱって、Casandraのテーブルに入れるという動きになる。
・ETLとは、SparkSQLであり、SQLのデータを変形、フレームを変形させたりするときに使用する。
・Cassandraとは、NOSQLのデータベースである。CQLSH(Casandraのクエリ言語)というジョインがないSQLを使用する。
・Kafka、Cassandra、Sparkをなぜ使うか?
 - ライセンス費がかからない
 - 可用性・拡張性がある
 - マシンラーニングを使用できる
 - リアルタイムに分析、検索できる
 - 利用可能でない情報をひっぱることができる(この特性については、良い点と悪い点がある)

[Expert Lunch]
初日にRACのサービスについてのセッションをしてくださった、Bjoern Rost氏と食事をしました。某秋葉原のカンファレンスのTシャツを着ていたので、その話を少ししました。しかしながら昨日同様に話は長く続けられませんでした…。


長くなったので、次のエントリに分けます。

2017年2月22日水曜日

海外カンファレンスに行く(5):RMOUG Training Days 2017参加2日目その2

前回のエントリの続きです。

[Session4: Putting HCC Compression to Good Use]
ExadataのHCC圧縮に関するセッション。
・5000万件の行のログを保存する。インデックスを貼っている。書き込むが長く、コンテンション(ロックなど)が多いというシチュエーションでの話
・インデックスが原因だろうか。インデックスはなぜ必要か。ただデータを保存するだけであればインデックスは保存したいデータそのものではないから不要ではないか。
・Exadataから別マシンに移動する、データベースリンクで移動する、移動に3時間以上かかってしまうという状態。
・Exadataであれば、HCCでフルスキャンは速くなるため、インデックスを削減するという選択肢がありうる。
・今あるテーブルに対してHCC圧縮を行いたい場合は、パーティション交換をする必要がある。圧縮用テーブルを作成し、データを移動することで行う。パーティション交換はメタデータの変更のみである。

[Session5: Index and Redo Internals]
Oracle 12c R2 Solaris 11での検証結果によるもの。ドキュメントにないものもある。
・インデックスは木構造となっている。ルートブロックとブランチ(枝)、リーフ(葉)の3種類あるが、Tracedumpではブランチとリーフを確認できる。
・ルートブロックはブロックダンプにより確認ができる。
詳細は行の変更、ビットマップインデックス、インデックスのスプリットが発生した場合のパターンなどをスライドで図示してくださいましたが、ここで書いてよいものか判断に迷うものもあるため、詳細は渇愛とさせてください。

[Welcome Reception]
セッションの後はWelcome Receptionとして、軽食とお酒が用意しての歓談が行われました。
とはいえ、英語がそれほど話せない私としては、どうしよかなと思っていたのですが、このなかでNetwork Eventとして、技術的テーマにそって1対1で話すというイベントがありまして、拙いながらも話したり、相手のストーリーを聞くことができました。
DBAになりたいと語る大学生、Oracle ACEでありながらそのなかでトップ技術者に憧れ近づきたいと語るエキスパートの方など、その熱に圧倒されました。

[ODTUG Meetup]
このイベントの後、近くのカフェCraveでODTUGのMeetupがありました。参加していいのか聞いておどおどしていると、隣に座りなよと声をかけてくれる人がいて、スピーカーなのかとかこのカンファレンスの為だけに日本から来たのか等聞かれました。
あまり話についてはいけませんでしたが、ビールを飲みながらUser Groupの話ができ、楽しいひと時でした。
そのあともう1件店に連れて行ってもらいましたが、アメリカのエンジニアと触れあえる貴重なひと時でした。

21時30分ごろ解散。タクシーでホテルに帰りました。

2017年2月21日火曜日

海外カンファレンスに行く(4):RMOUG Training Days 2017参加2日目その1

カンファレンスの続きです。
この日からは全日カンファレンスです。朝食会が7:30からということで、朝早く来ました。

<DAY4>
[Session1: Exadata Maintenance tasks 101]
Exadataのメンテナンスに関するセッション
*まずはExadataの紹介。
・X4-2、X4-8の-2、-8はCPUソケットの数。
・ExadataにはOLTPやInmemory用のXF(Extreme Flash)とWareHouse用のHC(High Capacity)がある。
・DBサーバとセルサーバをInfiniBandで接続。セル側はcellcliを使用して操作する。
・Exadataのライセンスはストレージサーバのライセンス+DB&オプションのライセンス
・Exadataの機能(スマートフラッシュキャッシュ、HCC、IORMなどを簡単に紹介)
・リモートモニタリング、個別パッチ作成などのサポートを受けられる
*メンテナンスについて
・メンテナンスはあらかじめ予定して行うばかりでなく、冗長性のパートではあらかじめ予定していなくても対応可能
・Exadata X2は3年以内にリプレイスすべき「Battery」というステータスになっている。
・Griddiskをメンテする場合、リバランスディスクを必要とする。GridDiskをオフにしてパッチ適用をして、GridDiskをオンにし、リバランスされることを確認する。
・冗長化の状態によりメンテ中のシステムダウンの可能性がある。
・パッチの種類として、Quarter Full Stack Download Patch(QFSDP)と、Quarter DB Patch / Bundle Patchがある。
・パッチにはノードのファームウェア、PS、GIとRDBMSのバイナリ、インフィニスイッチなどを含む。セルサーバのパッチはDBノードよりdcliを使用して行う
・Exadataディスク交換はSRを投げて確認、フィールドエンジニアと連携して作業をするという流れで行う

[Key note]
Ask Tomの運営を行っているConnor McDonald氏による講演。Ask Tomを始めた頃のお話を語ってくださいました。

[Session2: Upgrade to Oracle Database 12c Release 2 (12.2) Live and Uncensored!]
*アップグレードについて
・Oracle 12.2はエンジニアドシステムとリリース日付が分けられることとなった。
・9i及び10g R1は一旦11.2.0.4にしてからアップグレードする必要がある
・10g R2及び11g R1は一旦12.1.0.2にしてからアップグレードする必要がある。
・11g R2以降は直接アップグレードが可能。
・Pre-Upgradeスクリプトが用意されており、アップグレード可能か確認できる。
・パラレルアップグレードがあり、アップグレードによるダウンタイムを減らせる。
このあと、デモンストレーションでpreupgradeを実行し、その結果に従ってcompatibleなど変更を行って、その後DBを落としてからupgradeモードで起動する。
*マイグレート(移行)について
・Transportable Tablespaceを活用する方法がある。データファイルはDBMS_FILE_TRANSFERで転送したり、RMANのCONVERTコマンド使用する方法がある。
・Transportable Tablespaceにより、初期移行後、増分バックアップ+TTSを行うケースや、Full Transportable Tablespaceを使用する方法がある。

[Expert Lunch]
Oracle内部構造に詳しいOracle Ace DirectorのRiyaj Shamsudeen氏のテーブルで食事しました。英語がもっと話せたらいろいろ話したかったのですが、少ししか話せませんでした…。

[Session3: Best Practices for Migrating Your Legacy RDBMS to MySQL and the Cloud]
ベンダさんのセッションで、RDBMSからMySQLやクラウドへの移行の話
・Foglight for Databasesという製品でデータベースのモニタリングを行える
・Spotlight Developerによるクラウドへのオフロードを行うことができる

長くなったので、2つに分割します。

2017年2月20日月曜日

海外カンファレンスに行く(3):RMOUG Training Days 2017参加1日目

今回も海外カンファレンス参加の続きです。

<DAY 3>
いよいよ、この日からカンファレンス参加です。
初日は午後からカンファレンスが始まります。位置づけとしてはサービストラックということで、30分のTip Sessionと2時間のDeep Diveが並列で行われていました。
私は以下のセッションに参加しました。



[Horsepower: The Sizing and Scaling of Hyperion to OBIEE Conversion]
・HyperionはOracleが買収した業務管理ソフト。異種のデータソースの統合ができる。
・OBIEE(Oracle Business Intelligence Enterprise Edition)はBIの機能があり、DBが理解できるレベルのクエリを作成
ということでしたが、普段触らない内容なので、あまり理解はできませんでした。

[DOP: How Much is “Enough”?]
DOPとは、Degree of Pararelismのことです。
・Oracle7より導入。Enterprise Editionのみで利用可能。
・DOPは、同時実行可能な並列処理を指定する。
・パラレル指定はデフォルトではDDLとQueryのみで、DMLはできない。
・DOPの実行を考える際は、キーの文字列などどうやって分割させるか考え、セッション数を考える。DOPの値を大きくしすぎるとページスワップ発生、CPU・I/Oが高くなってしまう。
・SLAとETLを考慮しながら、実行時にパラレル指定をしていく必要がある。
・自動DOPは11gから導入。parallel_degree_policy初期化パラメータによって指定される。11gではI/Oのみ考慮したが、12cからはCPUとI/Oを考慮してコスト計算される。

[Make Services Work for You: Stop Missing Out]
・Serviceを作成することにより、セッションのグルーピングやフィルタが可能。
・tnsnames.oraにサービス名を指定してあげると、DNSを移動できるため、RACを運用する上では有効
・ローリングによるパッチ当てが可能となる。サービスを別ノードに切り替えて、古いセッションが終わったらインスタンスをシャットダウンするといったやり方ができる。

[Exadata for Developers: Stop Driving Your Ferrari in the Parking Lot!]
Exadataを速くするための機能を紹介。
・ストレージインデックスを使用したquely offloadが可能
・DWHやHCCを使う場合は、インデックスは最低限使用もしくは完全に無くすことを検討してよい。どのくらい減らすかは一概に言えないが、必要になったら足せばよい。
・HCCによる容量削減が可能。
・ストレージにはセルフラッシュキャッシュがある。DBバッファに乗せたいデータはセルフラッシュもKEEP設定とすべき。
・Exadataでは実行計画上、「STORAGE FULL」などSTORAGEという名前が入る。
・ASHのメトリックで、quely offloadが効いたかどうかなどが確認できる。

[Only the Gorillas are Naked]
高い技術を持つエンジニアとなる為の心構えについてのお話を頂いた。
抽象的な話であり、英語があまりできないことから、内容はあまり理解できなかった。

英語力不足により、理解できないことも多かったのですが、それでも本場のセッションを楽しめました。英語をもっと勉強しなければと思います。

この日は夕飯用のサンドイッチを買って、ホテルでの食事でした。