サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
old.insight-tec.com
毎月大阪で第三木曜に行っている勉強会、「三木会」でお話した内容をまとめます。 今回のテーマは 「Oracleのdirect path read (diskからメモリにのせずreadし続ける) でTPCHを10GB/sが可能か?」になります。 Oracleからのdirect path readで読み出すということですが、まずDBで読み出す前に、ハードウェア的に10GB/sの性能を出す必要があるため、hardwareボトルネック中心のお話になります。 *** 検証の経緯 9月の検証では、oracleのdirect path readで1GB/secを計測しました。 500MB/secのSSDをRAID0でつなげていたので、当時の最大スループットがでていたということになります。 その時のマシン構成は以下の通りです。 (1GB/sec)デスクトップマシンの構成 CPU AND FX 8320 8c
2015/9/25に行われた、社内DBチューニングコンテストに優勝しました!! 今回はその時の話を書いていきます。 まず、競争条件について。 最初に聞いた条件は以下の通りでした。 【競争条件】 <測定ツール> - HammerDBを使用 <決勝> (1) TPC-H 4セッション(Scale Factor=10 ) <予選> (1) TPC-C 20セッション(1セッションごとに100万トランザクション) (2) TPC-H 4セッション(Scale Factor=1) 上記の合計24セッションが終わった時間で競う。(同時性は問わない) <パーツ条件> ・予算 10万円以内 ※ただし、超えた場合は自己負担も可 ・電源(中古品禁止) ※Bronze以上 ・マザーボード(中古品禁止) <禁止事項> ・作成されるデータはいじってはいけない ・DB起動時にデータをメモリ上に乗せてはいけない 予算1
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のディストリビューシ
<Oracle 11g リファレンス・パーティションに関する検証 その1> ペンネーム: パンダおやじ 今回から11gの新機能であるリファレンス(参照)パーティションについて 検証します。 リファレンス・パーティション(マニュアルでは参照パーティション)は、 親子の参照制約(外部キー制約)を使用して子表に親のパーティションの スキームを継承することができる機能です。 リファレンス・パーティションはどのように作成すればよいのか? リファレンス・パーティションを使うと性能はどうなるのか? 必ず速くなるのか、遅くなる場合は無いのかを検証していきます。 ▼ 想定する検索要件 全国の顧客分布を確認したい。 特定の都道府県の顧客数や売上データを確認したい。 製品種別毎の売上を確認したい。 製品・地域毎の売上を確認したい。 では、リファレンス・パーティションを使って下記表を作ってみましょう。 ER図はこ
DB監査製品シェアNo.1 <RACにAuditを実装する -Oracle新人奮闘記-> ペンネーム: world famous beagle みなさん、こんにちは。 印旛くんのRACインストールはお楽しみいただけたでしょうか? ようやくインストールを終えた印旛くんが次の課題に進みます。 よろしくお願いします。 ———————————————————————- 「印旛くん、ちょっと」 「はい、なんでしょう」 「君がインストールしたRACにauditを実装して欲しいんだけど」 「オウディットって、監査のauditですよね?」 「うん、じゃあよろしく。 過去のメルマガにauditの検証があるから参考にしてもいいよ」 「はい。わかりました」 *Audit Trailについての検証1~8 https://old.insight-tec.com/mailmagazine/ora3/vol163.ht
<マテリアライズドビュー検証 まて マテ マテビュー その2> ペンネーム:クリープ 前回の完全リフレッシュに続き、今回もリフレッシュについて検証していき ます。今回から、高速リフレッシュ。まずは、マテリアライズドビューログ を中心に見てみましょう。 ■■■■■今回のあらすじ■■■■■ 1)マテリアライズドビューログについて 2)MLOG$_XXX[元表] ■環境 Microsoft Windows XP Pro Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production 1)マテリアライズドビューログについて 高速リフレッシュは完全リフレッシュとは異なり、元表に変更があった箇所 のみをマテビューに反映する機能です。データを集計するような場合、 マテビューを再計算しているわけではなく、変更時の差分のみがマテビ
Oracle DataGuardについて、その基本構成、セットアップ方法、スイッチオーバー、Flashback、管理方法などを紹介する全4回の連載を1冊にまとめました。 Oracle DataGuardとは・・・1つ以上の Standby Database から構成されていてプライマリデータベース(稼動している方)から Standby Database へ REDO ログを転送し、同期をとることで、可用性を高めるものです。DataGuard には、Physical Standby Database と Logical Standby Database の 2つの構成を利用することができます。 *eBook版のダウンロードをご希望の方は、画像をクリック <DataGuard入門 その1> ペンネーム:りん おら!オラ!Oracleをご愛読の皆様 はじめまして。新米雑用係りんで
<Full Scanを速くしちゃう~Oracle Text編~その2> ペンネーム: グリーンぺぺ 前回は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検証 隠れた新機能検証 その3> ペンネーム: オレンジみかん 前回に引き続きOracle11gの隠れた新機能について検証を行います。 今回から2回にわたって仮想列について検証して行きたいと思います。 ■仮想列とは 仮想列とは、テーブルにあるカラムに対して直接計算式を定義し 表示専用のカラムとして表示させることが出来る機能です。 従来の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 に関する検証 ~その1~> ペンネーム ちょびひげ 過去の “Oracle 9i 関する検証” で 主にデータベース・バッファの構造を理 解するために X$BH 表を詳しく見ていった。今回は前回とは違った観点でX$BH に焦点を当てて検証を行って行きたいと思う。 最初に、単一インスタンスの環境でオブジェクトの検索時や更新時のデータベ ース・バッファ上のオブジェクトのステータス変化を見て行く。次にRACの場 合には、単一インスタンスと比較して、どのような変化をするのかを見て行 きたい。最後に10gの場合のSGA管理にも触れることが出来ればと思う。 それでは、まずX$BH表に関しておさらいしておきたい。 X$BH とは? Oracleの動的パフォーマンス・ビューの元表であり、SYSユーザでアクセスが 可能である。この表を見ることによって、データベース・バッファにどんな オブジェ
<待ちイベントに関する検証 その3> ペンネーム: ダーリン 【latch: shared pool/library cache】 シシです。イノシシです。猪突猛進の年が始まりました。 もう進むしかありません。前だけを見つめて心惑わすことなく Oracle の世界 に浸りましょう。今年は 11g もやってきそうだし。 さて、ちょっと長めのお休みをいただきましたので前回までを軽く振り返りま しょう。 今回のシリーズでは、待ちイベントにフォーカスして SQL の処理の流れを追 いかけてみることをテーマにしています。 1回目と、2回目は、DBへの入り口になるネットワーク関連の待ちイベントを探 ってみました。 通常 Idle イベントに分類されるものに関しては、監視しなくてもよいといわ れることがありますが、FETCH SIZE (SQL*Plus では ARRAY SIZE)をちょっと 変更する
<待ちイベントに関する検証 その1> ペンネーム: ダーリン 【SQL*Net message from/to client】 焼き芋が恋しい季節になりました。I can’t wait for YAKIIMO !! しかし、「いーしやーきいもー、焼き芋っ。」の声は聞こえても、こっちに来 てくれないことには、なかなか焼き芋にありつくことができません。待てば待 っただけのありがたみはあるのですが、それが Oracle データベースへの問い 合わせの結果となると、ありがたいどころかイライラするだけです。 このメルマガではこれまで Oracle の待ちイベントに絡んだ検証をたびたび 実施してきましたが、今回は少し視点を変えて SQL の処理を追いかける形で ポイントでの待ちイベントを追いかけてみたいと思います。 Oracle でパフォーマンスチューニングを実施するときは、いくつかアプロー チがあり
<Oracle10g Cost Base Optimizerにまつわる検証 その11> ~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って何? その4> ペンネーム: クリープ 先週は、統計情報を取得後にパフォーマンスが劣化するような状況を再現中 に、予想外の結果になったところで終わりました。 通常であれば、一意な値が格納された項目をSELECTすればインデックススキ ャンになるはずなのに何故フルスキャンになってしまったのでしょうか? 今週は、この疑問を解明していこうと思います。 ■■■■■概要■■■■■ 1)一意な値の参照でフルスキャンが選択された理由とは!? ■環境 RedHatLinux ES4 Update 5 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 – Production 1)一意な値の参照でフルスキャンが選択された理由とは!? 早速、フルスキャンが実行された原因を調査していくことにし
<Oracle 11g検証 第3弾 新機能:SPMって何? その1> ペンネーム: クリープ 先週に引き続き、今週も11gを検証していきます。 今週からは、11gの新機能にフォーカスして検証していきます。 今回、筆者が注目したのは、SPMという機能。 SPM?何それ?11gの新機能の中にそんな機能あったっけ? というぐらい地味な機能ですが、これが意外と。。。!? っと、詳細については検証で明らかにしていきますのでお楽しみに。 ■■■■■概要■■■■■ 1)SPMとは? 2)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
<待ちイベントに関する検証 その10> ペンネーム: ダーリン 【log file sync/log file parallel write】 さてさて、待ちイベントの検証も大詰めを迎えました。 前回は、更新処理が行われたときに発生する待ちイベントとして、 log buffer space が待ちイベントの最上位に来ていました。この待ちイベント は log buffer が足りないときに発生するので、これを回避するために初期化 パラメータの log_buffer を大きく設定してその効果を確認してみました。す ると、待ちイベントの発生回数が下がり、待ち時間も減少していることが確認 できましたね。 log buffer = 6120448 のときの待ちイベント: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ event wait_class total
<Oracle 9i 関する検証 その2> ペンネーム ちょびひげ — データベース・バッファとブロックサイズ -- ~ データベース・バッファのヒット率 ~ 今回はデータベース・バッファのヒット率について検証してみる。 一般的にデータベース・バッファのヒット率は最低でも90%を維持する必要が あると言われている。 ちなみに、ヒット率は以下の式で求めることが出来る。 1 – (physical reads / (db block gets + consistent gets)) 上記のphysical reads、db block gets、consistent getsの値は v$buffer_pool_statisticsやv$sysstatから取得できる。 9iの以下の環境で、検索条件を変えてヒット率を見ていこう。 尚、今回の検証はすべて、検索するデータをメモリ上に載せるために十分な
<待ちイベントに関する検証 その4> ペンネーム: ダーリン 【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検証 隠れた新機能検証 その1> ペンネーム: クリープ 今週から、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という単語を直訳すると「回転する」という意味で、何かを軸 としてものを動かす、と
<RAC One Node の検証 その1> ペンネーム : ダーリン さてさて、長らくの関西遠征から帰ってきました。 今回のテーマは RAC One Node 。 その名前の通り、RAC なんだけどアクティブノードはひとつだけと いうデータベースです。 ご存知の方も多いかもしれませんが、まずはどんな特徴があるかを 簡単に整理しておきます。まずは、RAC から。 RAC の特徴: - 単一のデータベースに対して、複数のインスタンスがある。 これらのインスタンスは同一のデータにアクセスできる。 - RAC を構成しているノードは通常すべてアクティブである。 - 万一特定のノードで障害が発生しても、影響はそのノードに接続 しているセッションのみに限定され、しかも通常は再接続するだ けで正常稼働しているノードに再接続されるため、ダウンタイム はごく短時間。 (他のノードはダウンしないためサービス
<Oracle10g Cost Base Optimizerにまつわる検証 その3> ~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の
<ASMLibに関する検証 その1> ペンネーム: ソラ 明けましておめでとうございます。 新年最初のメルマガは、筆者自身がOracleをインストールする際に気になっ ていた「ASMLib Kernel Driver(以下、ASMLib)に関する検証」を行っていき ます。 最近、Oracle Real Application Clusters(以下、RAC)構築にAutomatic Storage Management(以下、ASM)を使用することが多くなっています。 特にSE-RACではASMの使用が必須となっています。 ASMを使用する場合のインストールマニュアルに、以下のような一文がありま す。 「管理性を向上するため、プラットフォーム上で使用可能な場合にはASMLibを 使用する必要があります。」 一見使用したほうがよいように思えます。 しかし、一言で管理性を向上すると言っても、そ
~ロックに関する検証 その3~ ペンネーム ちゃむ 前回は、ロックが悪さをする場合について説明した。 今回は、トランザクションロックに関して検証を行う。 検証には、以下のテーブル 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
~ロックに関する検証 その2~ ペンネーム ちゃむ 前回は、ロックの重要性などを説明した。 今回は、ロックが悪さをする場合について説明しようと思う。 悪さというと少し語弊があるかもしれないが、例えば、以下のように行ロック待ちになるような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
~ロックに関する検証 その1~ ペンネーム ちゃむ 今回からロックに関する検証を行なう。 例えば、EMP表のデータをUPDATEしたときCOMMITするまで、そのUPDATEしたデー タが他のユーザーに変更されないように保証したり、表がDROPされないように保 証されているのはロックのおかげである。これらのことは「データに一貫性があ る」とか「データ構造の整合性がとれている」とかいわれることもある。さら に、ロックのおかげで、複数のユーザーがデータに同時実行アクセスできるよう になっている。 ロックには、表全体に対するロックである表ロックと、行データを保証するため の行ロックというものがある。これらを合わせてDMLロック(データロック)と いう。また、データ構造を保証するのは、DDLロック(データディクショナリー ロック)という。表のデータ構造は、データディクショナリ上に存在するので、 こ
<マテリアライズドビュー検証 まて マテ マテビュー その1> ペンネーム:クリープ 今回から、マテリアライズドビュー(以後マテビュー)について検証します。 マテビューについては、以前のメルマガ「Full Scanを速くしちゃう」で、 既に取り上げてますので、今回はさらに突っ込んだ形で、マテビューの機能 を検証していきます。題して! まて マテ マテビュー!! しばし、お付き合いを・・・ ※マテビューには、レプリケーション的な要素とデータウエアハウス的な 要素がありますが、今回はレプリケーションで使用されるような機能につ いては触れません。レプリケーションについての話を期待された方、あし からず。。。 ■■■■■今回のあらすじ■■■■■ 1)マテビューのおさらい 2)リフレッシュの機能検証 1)マテビューのおさらい それでは、おさらいも兼ねてマテビューについてさらっと確認。 マテビューとは
<共有プールに関する検証 その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 上記のカラムはいずれ
~ロールバック・セグメントに関する検証 その1 ~ ペンネーム ちゃむ 今回から、ロールバック・セグメントに関する検証を行なう。 <ロールバック・セグメントの役割> Oracleには、1つ以上のロールバック・セグメントが存在する。ロールバック・ セグメントには、トランザクション処理時の変更前の値が記録される。 この更新前の値を用いて、読取り一貫性、トランザクションのロールバック、 データベースのリカバリ(REDOをあてていくロールフォワードの後にロールバッ クを行なう)を実現している。 以下に、ロールバック・セグメントが更新前情報を格納しているイメージ図 を示す。 ロールバック・セグメントには、プライベート・ロールバック・セグメントと パブリック・ロールバック・セグメントがある。 <プライベート・ロールバック・セグメント> 単一のインスタンスでのみ使用可能。起動時に、初期化パラメータの r
次のページ
このページを最初にブックマークしてみませんか?
『old.insight-tec.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く