負荷テストデータ作成に関するTips — 指定率行の抽出・更新 —
JPOUG Advent Calendar 2019の13日目のエントリーです。 負荷テスト用データは件数が重要 最近、負荷テストの支援をすることが多いのですが、負荷テスト用のデータ準備にはいつも悩まされます。 経験から述べると、アプリケーション開発者にデータの準備をお願いすると大抵はうまく行かないことが多いです。 開発者はプログラムが仕様通り動くかどうかを確認する必要最小限のデータを準備することに関心はありますが、実際の業務を想定した量のデータを準備することはあまり考えていません。 また、本番環境の実データを使うにはセキュリティ上いろいろな制約があるため、機微な情報をマスク化する等の加工に時間がかかりただでさえ厳しいテスト工程を圧迫します。 結論から言うと、負荷テストでは値のリアルさよりも件数の妥当性の方が重要だと思います。 何年か前に参画したプロジェクトでは、アプリケーションの仕様を十
実行統計による実践的SQLチューニング（その２）
実行計画を実行順に表示させる 前回の投稿では、DBMS_XPLANパッケージのDISPLAY_CURSOR関数により実行統計を併記した実行計画の表示要領を紹介した。 しかし、実行計画ツリーからどのステップが起点となりどの順番で実行されるかを読み取るのはある程度の経験が必要であり、前回紹介した程度の行数であればともかく、数百ステップにもなる場合はベテランでも投げ出したくなる。 筆者は以前から実行計画ツリーを実行順に表示させることに関して試行錯誤を繰り返してきたが、この度方法を確立するに至ったので紹介したいと思う。 実行順表示スクリプト DBMS_XPLAN.DISPLAY_COURSORの入力ソースはV$SQL_PLAN_STATISTICS_ALLビューであるので、このビューを使って情報を取得する。 前回投稿の中で aplan.sql スクリプトから呼ばれていた aplans.sql の内
実行統計による実践的SQLチューニング（その１）
この投稿はJPOUG in 15 minutes #8で発表した内容に加筆・整理したものです。 実行統計とは？ 実行統計とは、DBMS_XPLANパッケージのDISPLAY_CURSOR関数における機能拡張で、SQL実行時に実行計画の各ステップ毎に出力行数や実行時間などの統計情報を取得し、実行後（正常終了および強制終了）に実行計画と共に統計情報を併記するものである。 ちなみに、本機能はOracle10g R2以降で使用可能となっている。 実行統計については以下の記事がよくまとまっている。 Oracle DatabaseでSQLの性能計測2(DBMS_XPLAN＆DBMS_SQLTUNE編)【Oracle Database or GoldenGate Advent Calendar 2018 Day 8】 Oracle® Database SQLチューニング・ガイド 12c リリース1 (1
Oracleでパーセンタイルを求める
JPOUG Advent Calendar 2017 13日目のエントリーです。 はじめに 今年の後半は「Oracle技術者から見た、SAP HANA」というDB Onlineの記事執筆で忙しかったこともあって、個人ブログの更新ができていませんでしたが、Advent Calendarといういいきっかけをいただいたので久しぶりの投稿です。（去年も同じようなことを言っていたような。。。） ちなみにSAP HANAの連載はまだまだ続きますので、ご興味のある方は是非見てください！ 今回のネタは「パーセンタイル」です。 パーセンタイルは、数学的な定義(Wikipedia)はとりあえず横に置きますが、われわれOracleエンジニアにとってレスポンスタイムの評価などでなじみがあると思います。 簡単に言うと100個の測定値を値の順に並べて、小さい方から90番目の値を「90パーセンタイル」あるいは「90%
Oracleバージョンによるヒント句の変遷〜最新版〜
オンプレミス版Oracle12c R2リリース！ OTNでOracle12c R2がダウンロード出来るようになったので早速手元環境にインストールしてみた。 SQL> select BANNER from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production PL/SQL Release 12.2.0.1.0 - Production CORE 12.2.0.1.0 Production TNS for Linux: Version 12.2.0.1.0 - Production NLSRTL Ve
IPアドレスの管理方法を考える①
ネットワーク・アドレスの格納を考える 構成管理データベースを考える時、ネットワーク管理情報を適切に格納することは重要である。Oracle以外のデータベースでは以下のように専用のデータ型や関数を提供している。 PostgreSQLの場合 PostgreSQLでは、IPv4アドレス、IPv6アドレス、MACアドレスを格納するデータ型を提供している。（8.9. ネットワークアドレス型） MySQLの場合 MySQLではIPv4 ネットワークアドレスのドット区切り表現を文字列から１０進数、あるいはその逆の変換を実行する関数を提供している。（IPv6 ネットワークアドレスの変換関数も用意されている。） inet_aton() inet_ntoa() Oracleでネットワークアドレス変換関数を作ってみる 翻って、Oracleでは悲しいくらいにネットワーク情報の格納手段が乏しい。ネットで検索したら以下
書籍紹介：『アポロ13』に学ぶITサービスマネジメント ~映画を観るだけでITILの実践方法がわかる! ~
アポロ１３号でなぜITILを学ぶのか？ アポロ１３号の事故は1970年、一方ITIL:Information Technology Infrastructure Libraryは1989年にイギリスで初版が公開された。 従ってこれらには直接の関連性はなく、それは本書の中でも再三繰り返されている。 しかし、ITILがアメリカの成功体験を分析することで策定されたという逸話もあるので、「成功した失敗」と呼ばれるアポロ１３号の教訓からITILの本質を学ぶという筆者の考えには共感できる。 目次 ■第1部 ITサービスマネジメントとアポロ13 ●第1章 ITサービスマネジメントとは -ITサービスの価値を高めるために- ●第2章 『アポロ13』でITSMを学ぶ意義 -アポロ計画とビジネスストラテジの共通点- ■第2部 サービスストラテジ ●第3章 「ニール・アームストロングが月に降り立ちました」 -ア
日本の古都はなぜ空襲を免れたか
古都鎌倉を戦火から救った恩人？ JR鎌倉駅西口にある「時計塔小公園」の中にうっかりすると見過ごしてしまう小さな碑がある。ラングドン・ウォーナーという米国人美術史家の碑である。写真をよく見ると１９８７年４月の建立とある。 この写真は２ヶ月ほど前に自転車でわざわざ撮りにいったものだが、今回はこの数奇な米国人を巡る戦後の歪んだプロパガンダについてまとめてみたいと思う。 文化は戦争に優先する Wikipediaの記述にもあるように、京都が米軍の空襲を受けなかったのは歴史的文化財の価値をよく理解していたラングドン・ウォーナーが上層部に進言したことによる、と今でも多くの日本人は思い込んでいる。（という私もそのように信じ込んでいた一人であるし、最近京都在住の叔母とこの件について話したがやはり同じような認識だった。） あれだけ圧倒的な軍事力を持ちながら京都を攻撃しなかったアメリカという国はなんと文化に対す
USE_INVISIBLE_INDEXESヒントについて（続編）
不可視索引のその後 先日、不可視索引はUSE_INVISIBLE_INDEXESヒントと共に使おうという記事を書いたのだが、以下の記述に関してどうやら違う挙動となるらしいことがわかった。 INDEXヒント＋USE_INVISIBLE_INDEXESヒント 基本的にUSE_INVISIBLE_INDEXESヒントを指定するだけでよいのだが、もし複数の不可視索引が定義されていたりする場合は、どのインデックスを使用するべきかをINDEXヒントで明確に指定することができる。 具体的には、複数の不可視索引が定義してある場合、INDEXヒントで明確に指定している不可視索引以外の不可視索引も使用されるようだ。 この部分を詳細に再検証してみたいと思う。 複数の不可視索引が存在する場合を検証する 検証環境 今回の検証で使用した環境は以下の通りである。 SQL> select * from v$version
インデックスとSQLの関係を調査する
前回の投稿他 前回の投稿ではsys.col_usage$表を使って、あるカラムに関するWHERE句（Predicate）の状況を分析する要領を紹介した。 一方、昨年「V$SQL_PLANでCRUD表モドキを作ってみる③」という記事を書いたのだが、応用編として インデックス – SQL V$SQL_PLANを使えば、テーブルとSQLの関係だけでなく、インデックスとSQLの関係を分析することもできます。 例えば、あるインデックスの定義を変更しようとする場合、１つのSQLだけに注目してしまうと他のSQLに影響があることに気づかず新たな問題を引き起こしてしまうかもしれません。 そのような場合、インデックスとSQLの相関表が役に立ちます。 ということを紹介しただけで終わっていた。 最近、実業務でインデックスとSQL(SQL_ID)の関係を一覧化する機会があったので、その要領を紹介しておこうと思う。
sys.col_usage$表でWHERE句を分析する
sys.col_usage$とは sys.col_usage$を理解するためにはまずヒストグラムを理解する必要がある。 ヒストグラムとはCBOが使用する列分布情報を保持するものであり、列データの分布が不均一な場合はヒストグラムの情報を使用してより良い実行計画を選択する。 ヒストグラムは列データの偏りが高い場合に有用なので、次のような状況では有用ではなく、つまりヒストグラムを作成する意味がない。 WHERE句内で指定しない列 絞り込み条件として使用しない列にヒストグラムを作っても無駄 均一な分布 データの偏りがない場合 一意な列を含む等価述語 OracleはDBMS_STATSパッケージよって統計情報を取得する際、ヒストグラムを取得すべき列を特定する情報を収集している。 この情報はSMONによって取得されsys.col_usage$表に保持される。 「CBOに関する統計情報は、バックグラウン
Flashback Dropの検証④（最終回）
Flashback Dropのまとめ Flashback Dropに関して、基本機能と容量管理について簡単な検証で確認をしたが最後におさらいをする。 Flashback DropはRECYCLEBIN初期化パラメータがON（デフォルト）の場合に有効な機能であり、OFFの場合はOracle9iまでと同じ動作となる。 テーブルをPURGEオプションなしでDropすると、テーブルは物理的に削除されずにリサイクルビンで管理される。これはリサイクルビン用の表領域に移動されるのではなく、同じ表領域のままデータ・ディクショナリから見えなくなるような仕組みで管理されることを意味する。 リサイクルビンで管理されているテーブルは「BIN$」で始まる名前にRenameされる。 テーブルに紐付くインデックスおよびPK制約もリサイクルビンで管理される対象であり、同様に「BIN$」で始まる名前にRenameされる。
実行計画を実行順に表示させてみる | サイクル＆オラクル
JPOUG Advent Calendar 2015 13日目のエントリーです。このイベントは初めての参加、かつブログ投稿自体久しぶりとなりましたのでよろしくお願いします。前日はTakahiro YAMADAさんでした。 Oracleの実行計画ツリーって分かりやすい。。。だけどたどりにくい？ 実行計画ツリー（マニュアルでは「行ソース・ツリー」）の解析は、OracleデータベースのSQLチューニング作業においては基本中の基本です。 実行計画ツリーは、OracleのSQL実行が階層的に逐次処理されていることを直感的に把握しやすく、どこにボトルネックが存在するかも分かりやすい表示だと思います。 実行計画ツリーの表示方法は以下のリンクになります。 12.4 PLAN_TABLE出力の表示 右から左、上から下へ 11gR2パフォーマンス・チューニング・ガイドの19.2.3 グローバル表のヒントの指定
STATSPACKデータをExcelでグラフ化する②〜DBバッファ編1〜
今週の名言 「自分が多数派の側にいると気付いたら、もう意見を変えてもいい頃だ。」 マーク・トウェイン 最近、マーク・トウェインの名言が多いですが、偶然です。 DBバッファの統計を調査する。 前回は、stats$snapshot表からスナップショット一覧を取得するSQL文を紹介しました。 今回から、応用編としてこの表とパフォーマンス・データが格納された表を結合して、１日の統計情報の推移を見てみます。 最初は取っ付き易いDBバッファについて調べてみましょう。 DBバッファヒット率の計算式 DBバッファの目的は、頻繁にアクセスされるDBブロックをなるべくメモリ（DBバッファ）に保持しておくことで、低速なディスクI/Oを回避することです。DBバッファ・ヒット率とは、要求されたDBブロックがバッファ内に存在していた割合を示すもので、以下の計算式によります。 DBバッファヒット率 ＝((CONSIST
STATSPACKデータをExcelでグラフ化する①
今週の名言 「成功の秘訣は、職業をレジャーとみなすことだ。」 マーク・トウェイン STATSPACKについて書かれた名著 私の手元に１０年以上前に買った素晴らしい本があります。ORACLE9i ハイパフォーマンスチューニング―STATSPACK編という本で、実に１３年近く前に出版されすでに絶版となっていますが、古本市場ではまだ入手できるようです。 私はこの本を自炊（スキャナで読み込んでPDF化）しiPadに入れているのですが、今でも時々読み返すことがあります。 Oracleは今や12cとなっていますが、個人的にはOracleの基本的なアーキテクチャは8iくらいで出来上がり、9iは各種管理機能の自動化が進み始めたバージョンという認識です。 まだ、ASMは登場しておらずRACもあまり洗練されたものではありませんでしたが、インスタンス単体レベルの基本機能は9iでかなり完成されているので、9i時代
インスタンスのリスナーへの登録（その２）
今週の名言 「今日できることを明日にまで延ばすな｡」 フィリップ・ チェスターフィールド 前回のおさらい（Oracle 11gR2） リスナーにインスタンスがサービスとして登録されて初めて、インスタンス（データベース）に対するネット接続が可能となります。 リスナーを後から起動すると、インスタンスが登録するまでにある程度の時間がかかります。（PMONが定期的にリスナーに登録しにいくので最長60秒程度かかる場合があります。） リスナーを先に起動しておくと、インスタンスは起動直後にリスナーに登録されます。 2.の場合でも「ALTER SYSTEM REGISTER」コマンドを実行すると、インスタンスを即時にリスナーへ登録することができます。 前回は、インスタンスのリスナーへの登録に関する挙動についてOracle11gR2で確認をしてみましたが、Oracle12cR1で同様の検証をしてみます。 サ
Oracleバージョンによるヒント句の変遷
今週の名言 「世間で頭角をあらわす人物は、自分の望む環境を自ら捜し求める人物であり、もしそれが見つからない時は自分で創り出す人物である。」 ジョージ・バーナード・ショー 今回もトリビアネタ Oracleエラーを数える回ではとんだ墓穴を掘ってしまいましたが、懲りずに今回はヒント句の種類、しかもOracleのバージョンが進化していく間にどんなヒント句が追加されてきたのかという変遷をたどってみます。 環境は12cR1 今回使用する環境はOracle12cR1です。 SQL> SELECT BANNER FROM V$VERSION; BANNER -------------------------------------------------------------------------------- Oracle Database 12c Enterprise Edition Releas
カレンダーで遊んでみる①
今週の名言 「知識に対する投資は常に一番の利益を生み出す」 － ベンジャミン・フランクリン － Oracleと暦法 以下はOracleデータベースがサポートする暦法（カレンダー）です。 Oracle® Databaseグローバリゼーション・サポート・ガイド 11gリリース2 (11.2) B56307-04 NLS_CALENDAR 参照 Arabic Hijrah(イスラム歴) English Hijrah(英語版イスラム歴) Gregorian(グレゴリオ暦) Japanese Imperial(日本の元号暦) Persian(ペルシャ暦) ROC Official(台湾暦) Thai Buddha(タイ仏教暦) Ethiopian(エチオピア歴、12c〜） こんなにも多くのカレンダーを使うことができるというのも驚きですが、我々日本人にとって元号歴がサポートされているというのは非常にあ
ORAエラーはいくつある？
今週の名言 「人にものを教えることはできない。できることは、相手のなかにすでにある力を見いだすこと、その手助けである。」 ガリレオ・ガリレイ 今回は小ネタで 前回に引き続き「Identity Column」のつもりでしたが、事情により今回は別のトリビア的なネタを紹介します。 アラートログ監視の難しさ Oracleの運用監視において、アラートログの中の「ORA-」で始まるメッセージを通知するということは当たり前に行われていると思いますが、エラー・メッセージ・マニュアルで「処置: 処置は必要ありません。」のように説明されているアラートが真夜中にエスカレーションされた経験はないでしょうか？ Oracleにある程度詳しい人であれば、経験から「これはとりあえず様子見でよいかな。」というような判断を下すことができるかもしれませんが、２４時間待機のオペレータにそこまでの判断を求めることは難しいのではない
12c新機能「Identity Column」の検証①
今週の名言 「自分がわずかなことしか知らないということを知るためには、多くのことを知る必要がある。」 モンテーニュ Oracle 12c新機能について 今週からOracle 12cの新機能を検証します。 実はOracle 12c 発表されたと思ったらリリース１(R1)はもうターミナル・リリースになるようです。（Database In-Memoryなど大幅に機能拡張：Oracle Database 12cR1の最新パッチセット12.1.0.2がリリースされました） 最近のOracle RDBMSは、R1のうちはイノベーター、アーリーアダプターまでが採用する傾向にあって、R2以降本格的にアーリーマジョリティ他に普及していくような都市伝説（？）があるように思います。 私が関わっている案件もほとんどが11gR2で、本番環境で12cに移行するというものをあまり聞いたことはありません。エンドユーザも状
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
