はてなブックマーク

9/25(金)に社内Oracleのチューニングコンテスト決勝戦が開催されました。 チューニングコンテストのルールは予算10万円でマシンを構築し、予選でTPC-Cのnumber of warehouses=1,sessio=20を規定時間以内に終了させれば決勝進出という内容で、決勝戦はTPC-Hのscale factor=10,session=4の実行終了までの時間を競いました。 細かなチューニングをせずに勝負に挑み2位という結果でした。 その要因の1つがマシンスペックの差によるものです。 これはCPU,メモリ,マザーボードをオーバークロック向きの構成でまとめたことが大きかったように思います。 そしてもう1つの要因となったのがOSでした。 OSを選択する上でこだわったのはシンプルであるということです。 いろいろ検討する中で見つけたのはがArch LinuxというLinuxのディストリビューシ

DB監査製品シェアNo.1 ＜RACにAuditを実装する -Oracle新人奮闘記-＞ ペンネーム： world famous beagle みなさん、こんにちは。 印旛くんのRACインストールはお楽しみいただけたでしょうか？ ようやくインストールを終えた印旛くんが次の課題に進みます。 よろしくお願いします。 ———————————————————————- 「印旛くん、ちょっと」 「はい、なんでしょう」 「君がインストールしたRACにauditを実装して欲しいんだけど」 「オウディットって、監査のauditですよね？」 「うん、じゃあよろしく。 過去のメルマガにauditの検証があるから参考にしてもいいよ」 「はい。わかりました」 ＊Audit Trailについての検証１～８ https://old.insight-tec.com/mailmagazine/ora3/vol163.ht

＜マテリアライズドビュー検証 まて マテ マテビュー　その２＞ ペンネーム：クリープ 前回の完全リフレッシュに続き、今回もリフレッシュについて検証していき ます。今回から、高速リフレッシュ。まずは、マテリアライズドビューログ を中心に見てみましょう。 ■■■■■今回のあらすじ■■■■■ １）マテリアライズドビューログについて ２）MLOG$_XXX[元表] ■環境 Microsoft Windows XP Pro Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production １）マテリアライズドビューログについて 高速リフレッシュは完全リフレッシュとは異なり、元表に変更があった箇所 のみをマテビューに反映する機能です。データを集計するような場合、 マテビューを再計算しているわけではなく、変更時の差分のみがマテビ

Oracle DataGuardについて、その基本構成、セットアップ方法、スイッチオーバー、Flashback、管理方法などを紹介する全4回の連載を1冊にまとめました。 Oracle DataGuardとは・・・1つ以上の Standby Database から構成されていてプライマリデータベース(稼動している方)から Standby Database へ REDO ログを転送し、同期をとることで、可用性を高めるものです。DataGuard には、Physical Standby Database と Logical Standby Database の 2つの構成を利用することができます。 *eBook版のダウンロードをご希望の方は、画像をクリック ＜DataGuard入門　その１＞ ペンネーム：りん おら！オラ！Oracleをご愛読の皆様 はじめまして。新米雑用係りんで

＜Full Scanを速くしちゃう～Oracle Text編～その２＞ ペンネーム： グリーンぺぺ 前回はOracle Textを使用することにより中間一致検索を秒殺する テクニックを紹介した。どうしてOracle Textは速いのか? 今回解説する。全文検索について知ってるよという方は 今回は読み飛ばして下さい。 ■Oracle Textの使い方手ほどき編 前回Oracle Textを何の前触れもなく使ってみたので少し解説を交え ながら、Oracle Textエンジンを利用した検索を行ってみる。 □手順1:プリファレンスの作成 SQL> exec ctx_ddl.create_preference('my_lexer','JAPANESE_LEXER'); プリファレンスとはOracle Textによる索引の作成方法に影響するオプションの パラメータのことを指す。作成するプリファレンス名

＜Oracle 11g検証 隠れた新機能検証　その３＞ ペンネーム： オレンジみかん 前回に引き続きOracle11gの隠れた新機能について検証を行います。 今回から２回にわたって仮想列について検証して行きたいと思います。 ■仮想列とは 仮想列とは、テーブルにあるカラムに対して直接計算式を定義し 表示専用のカラムとして表示させることが出来る機能です。 従来のVIEWを利用しても計算式を定義して計算することができましたが 仮想列を利用することで幾つかのメリットが得られます。 今回の検証では仮想列とVIEWの違いを明らかにし、仮想列の基本的な特徴を 見て行きたいと思います。 ■検証環境 Red Hat Enterprise Linux Server release 5.3 Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 – 6

＜共有プールに関する検証　その10＞　ペンネーム　ダーリン –　続・共有プールのフラグメンテーション　-－ 前回は共有プールの断片化の様子をおってみた。 今回はその中でも”free memory”について、断片化の様子をみてみることにしよう。 前回X$KSMSP表から以下のような断片化の様子を見ることが出来た。 ********************************************************************* KSMCHCOM CHUNK RECR FREEABL SUM ---------------- ---------- ---------- ---------- ---------- （※1） free memory 98 32525012 （※2） free memory 16015 13904108 ※1：インスタンス起動直後 ※2：処理

＜続 X$BH に関する検証　～その１～＞ ペンネーム　ちょびひげ 過去の “Oracle 9i 関する検証” で 主にデータベース・バッファの構造を理 解するために X$BH 表を詳しく見ていった。今回は前回とは違った観点でX$BH に焦点を当てて検証を行って行きたいと思う。 最初に、単一インスタンスの環境でオブジェクトの検索時や更新時のデータベ ース・バッファ上のオブジェクトのステータス変化を見て行く。次にRACの場 合には、単一インスタンスと比較して、どのような変化をするのかを見て行 きたい。最後に10gの場合のSGA管理にも触れることが出来ればと思う。 それでは、まずX$BH表に関しておさらいしておきたい。 X$BH とは？ Oracleの動的パフォーマンス・ビューの元表であり、SYSユーザでアクセスが 可能である。この表を見ることによって、データベース・バッファにどんな オブジェ

＜待ちイベントに関する検証　その３＞ ペンネーム： ダーリン 【latch: shared pool/library cache】 シシです。イノシシです。猪突猛進の年が始まりました。 もう進むしかありません。前だけを見つめて心惑わすことなく Oracle の世界 に浸りましょう。今年は 11g もやってきそうだし。 さて、ちょっと長めのお休みをいただきましたので前回までを軽く振り返りま しょう。 今回のシリーズでは、待ちイベントにフォーカスして SQL の処理の流れを追 いかけてみることをテーマにしています。 1回目と、2回目は、DBへの入り口になるネットワーク関連の待ちイベントを探 ってみました。 通常 Idle イベントに分類されるものに関しては、監視しなくてもよいといわ れることがありますが、FETCH SIZE (SQL*Plus では ARRAY SIZE)をちょっと 変更する

＜待ちイベントに関する検証　その１＞ ペンネーム： ダーリン 【SQL*Net message from/to client】 焼き芋が恋しい季節になりました。I can’t wait for YAKIIMO !! しかし、「いーしやーきいもー、焼き芋っ。」の声は聞こえても、こっちに来 てくれないことには、なかなか焼き芋にありつくことができません。待てば待 っただけのありがたみはあるのですが、それが Oracle データベースへの問い 合わせの結果となると、ありがたいどころかイライラするだけです。 このメルマガではこれまで Oracle の待ちイベントに絡んだ検証をたびたび 実施してきましたが、今回は少し視点を変えて SQL の処理を追いかける形で ポイントでの待ちイベントを追いかけてみたいと思います。 Oracle でパフォーマンスチューニングを実施するときは、いくつかアプロー チがあり

＜Oracle10g Cost Base Optimizerにまつわる検証　その１１＞ ～DBMS_STATSの変（？）～ ペンネーム：りん ■おさらい 先週は、コストの計算をしていましたが、I/Oしかフォーカスしていませんで した。つまり、I/Oのコストが算出されただけでした。 GATHER_SYSTEM_STATSを取得して、CPUのコストも… なんて書いていたわりに、CPUが入っていないのはおかしな話です。 では、GATHER_SYSTEM_STATSで取得したCPUSPEEDはどう使われるのでしょうか ■環境 Redhat Linux Advanced Server 2.1 Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 ■検証 先週書いた計算式をまとめると ((Single Block Read x SREADT

＜Oracle 11g検証 第3弾 新機能：SPMって何？　その４＞ ペンネーム： クリープ 先週は、統計情報を取得後にパフォーマンスが劣化するような状況を再現中 に、予想外の結果になったところで終わりました。 通常であれば、一意な値が格納された項目をSELECTすればインデックススキ ャンになるはずなのに何故フルスキャンになってしまったのでしょうか？ 今週は、この疑問を解明していこうと思います。 ■■■■■概要■■■■■ １）一意な値の参照でフルスキャンが選択された理由とは！？ ■環境 RedHatLinux ES4 Update 5 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 – Production １）一意な値の参照でフルスキャンが選択された理由とは！？ 早速、フルスキャンが実行された原因を調査していくことにし

＜Oracle 11g検証 第3弾 新機能：SPMって何？　その１＞ ペンネーム： クリープ 先週に引き続き、今週も11gを検証していきます。 今週からは、11gの新機能にフォーカスして検証していきます。 今回、筆者が注目したのは、SPMという機能。 SPM？何それ？11gの新機能の中にそんな機能あったっけ？ というぐらい地味な機能ですが、これが意外と。。。！？ っと、詳細については検証で明らかにしていきますのでお楽しみに。 ■■■■■概要■■■■■ １）SPMとは？ ２）SPMを使ってみよう！ ■環境 RedHatLinux ES4 Update 5 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 – Production ■テストテーブル作成 SQL> create table test_spm(seq_no numb

＜Oracle 9i 関する検証　その２＞ ペンネーム ちょびひげ — データベース・バッファとブロックサイズ -－ ～ データベース・バッファのヒット率 ～ 今回はデータベース・バッファのヒット率について検証してみる。 一般的にデータベース・バッファのヒット率は最低でも90%を維持する必要が あると言われている。 ちなみに、ヒット率は以下の式で求めることが出来る。 1 – (physical reads / (db block gets + consistent gets)） 上記のphysical reads、db block gets、consistent getsの値は v$buffer_pool_statisticsやv$sysstatから取得できる。 9iの以下の環境で、検索条件を変えてヒット率を見ていこう。 尚、今回の検証はすべて、検索するデータをメモリ上に載せるために十分な

＜待ちイベントに関する検証　その４＞ ペンネーム： ダーリン 【latch: shared pool/library cache】 さて、先週は結局 library cache の待ちが発生 “する” のか “しない” のか よくわからない解説で終了してしまいました。 今週はもう少し解説を続けます。 まず、実際に待ちが発生しているときの統計情報をもう一度見てみましょう。 今回は、v$latch の情報も同時に取得してみました。 前回と同様、同時 20 Session での検索処理です。 [ V$SYSTEM_EVENT の情報 ] event wait_class total_wait time_waited ---------------------------- ------------ ---------- ------------ latch: cache buffers chai

＜Oracle 11g検証 隠れた新機能検証　その１＞ ペンネーム： クリープ 今週から、Oracle11gで新たに追加された機能の中でも、大々的に取り上げられ てないけど開発者や管理者にとって使えそうな機能をピックアップして、検証 してみようと思います。 まず第1回は、PIVOT関数についてです。 ■環境 Red Hat Enterprise Linux ES Update 5 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 – Production ■PIVOTとは？ Oracle11gから追加された関数の中にPIVOT関数があります。 エクセルのピボットテーブル（PIVOT TABLE）などクロス集計機能でおなじみで すね。このPIVOTという単語を直訳すると「回転する」という意味で、何かを軸 としてものを動かす、と

＜Oracle10g Cost Base Optimizerにまつわる検証　その３＞ ～Monitoring属性の変～ ペンネーム：グリーンペペ 先回はMonitoring属性の表の監視情報がdba_tab_modificationsビューで参照 可能であることを確認しました。 また、表の監視情報は統計情報を取得すると消えることを確認しました。 ではdba_tab_modificationsビューにて参照可能な監視情報とCost Base Optimizer はどのような関係があるのでしょうか？ 表の監視情報をしばらくながめていると、どうも1日経つと消えてしまう場合 があるようです。 ■環境 Miracle Linux Standard Edition V2.1 Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 ■EMP2の

～ロックに関する検証　その３～ ペンネーム　ちゃむ 前回は、ロックが悪さをする場合について説明した。 今回は、トランザクションロックに関して検証を行う。 検証には、以下のテーブル a を使用する。 SQL> create table a maxtrans 1 as select * from emp; maxtransというものは、あまり指定してテーブルを作成しない場合が多いであ ろう。これは、データブロック中のトランザクションエントリのMAX値を決める ものである。以前、ロールバック・セグメントの検証のときに、以下のような テーブルのブロックダンプを紹介したと思う。その時は、Xidがトランザクショ ン表のスロットの場所を示すことなどの説明をした。 Itl Xid Uba Flag Lck Scn/Fsc 0x01 xid: 0x0009.003.00000076 uba: 0x04000

～ロックに関する検証　その２～ ペンネーム　ちゃむ 前回は、ロックの重要性などを説明した。 今回は、ロックが悪さをする場合について説明しようと思う。 悪さというと少し語弊があるかもしれないが、例えば、以下のように行ロック待ちになるようなSQL文を発行してみる。 セッションA SQL> UPDATE A SET ENAME = 'OSMAU'; 12行が更新されました。 セッションB SQL> UPDATE A SET ENAME = 'OSMAU'; 「待たされているよ～～～～～～～～～～」 この時の、V$LOCKの様子は以下の通りである。 SQL> SELECT SID,TYPE,ID1,ID2,LMODE,REQUEST,CTIME,BLOCK FROM V$LOCK WHERE TYPE IN ('TM','TX') ; SID TY ID1 ID2 LMODE REQUEST CT

～ロックに関する検証　その１～ ペンネーム　ちゃむ 今回からロックに関する検証を行なう。 例えば、EMP表のデータをUPDATEしたときCOMMITするまで、そのUPDATEしたデー タが他のユーザーに変更されないように保証したり、表がDROPされないように保 証されているのはロックのおかげである。これらのことは「データに一貫性があ る」とか「データ構造の整合性がとれている」とかいわれることもある。さら に、ロックのおかげで、複数のユーザーがデータに同時実行アクセスできるよう になっている。 ロックには、表全体に対するロックである表ロックと、行データを保証するため の行ロックというものがある。これらを合わせてDMLロック（データロック）と いう。また、データ構造を保証するのは、DDLロック（データディクショナリー ロック）という。表のデータ構造は、データディクショナリ上に存在するので、 こ

＜マテリアライズドビュー検証 まて マテ マテビュー　その１＞ ペンネーム：クリープ 今回から、マテリアライズドビュー(以後マテビュー)について検証します。 マテビューについては、以前のメルマガ「Full Scanを速くしちゃう」で、 既に取り上げてますので、今回はさらに突っ込んだ形で、マテビューの機能 を検証していきます。題して！　まて　マテ　マテビュー！！ しばし、お付き合いを・・・ ※マテビューには、レプリケーション的な要素とデータウエアハウス的な 要素がありますが、今回はレプリケーションで使用されるような機能につ いては触れません。レプリケーションについての話を期待された方、あし からず。。。 ■■■■■今回のあらすじ■■■■■ １）マテビューのおさらい ２）リフレッシュの機能検証 １）マテビューのおさらい それでは、おさらいも兼ねてマテビューについてさらっと確認。 マテビューとは

＜共有プールに関する検証　その2＞　ペンネーム　ダーリン –　V$SQLAREA　と　負荷の高いSQL　-－ 今週も、先週に続いて共有プールを覗いていこう。 先週は、動的パフォーマンスビューのV$SQLAREA表を使って類似SQL文を見つけ る方法と、CURSOR_SHARINGを設定して、バインド変数の利用と同等の効果を実 現する方法を紹介した。 さて、今回はそのV$SQLAREA表から負荷の高いSQLを見つけてみよう。 V$SQLAREA表には、SQLの負荷を見極めるために有効な情報として以下のような 統計データがある。 ===　　=== SHARABLE_MEM EXECUTIONS LOADS FIRST_LOAD_TIME PARSE_CALLS DISK_READS BUFFER_GETS ROWS_PROCESSED ADDRESS HASH_VALUE 上記のカラムはいずれ