10046 trace name context forever

従来からフルスキャン(通常 db file scattered read)をバッファーキャッシュを迂回するdirect path readに変更する手法としていくつか手段がありました。 * 今回は、Parallel Queryは除外 1. "_serial_direct_read"を設定する SQL> alter session set "_serial_direct_read"=true; 2. event 10355を設定 $ oerr ora 10355 10355, 00000, "turn on direct read path for scans" // *Cause: // *Action:  enable direct async read for scans 11gR2からは、フルスキャンでdb file scattered readを使うのか、direct path readを使うのか、Oracleが自動で決定しているようです。 勝手に選択されるのも、時と場合によっては問題になる可能性があるので、その仕組みを少し調査してみます。 以下の隠しパラメータが影響して、I/Oの制御を行っているようです。 "_small_table_threshold" lower threshold level of table size for direct reads "_very_large_object_threshold" upper threshold level of object size for direct reads セグメントサイズ > 5 * "_small_table_threshold" * blocksizeの場合にdirect path readを選択するようになります。 ただし、これは、event 10949で制御が可能です。 $ oerr ora 10949 10949, 00000, "Disable autotune direct path read for full table scan" // *Cause: // *A...

今回は、SQLパフォーマンスワークショップの話しを少しだけ。 第2回 SQLパフォーマンスワークショップ エンバカデロ・テクノロジーズさんとインサイトテクノロジー共同開催でワークショップを行うことになりました。 このワークショップで何を話そうかなと今まさに考えているのですが、まずはパフォーマンスチューニングのベーシックな 部分をきちんとお話ししようかなと思っています。 あと、ケーススタディを多めにして、参加者の方が考えながら参加できる内容にしたいと思っています。是非とも参加して みてください。 1. ディスクI/O系の話 データベースのボトルネックになりやすいのはディスクI/Oです。 データベースのディスクI/Oにはいくつかの種類が存在します。それらを上手く制御することがチューニングとなります。 では、ディスクI/Oを上手く制御できているのか? いないのか? はどうやって判断するのか? 2. コンテンション系の話 多くのデータベースは多数のユーザーが同時利用することを前提に設計されているので、1つのリソースを多数で共有する ための排他制御が様々な場所に実装されています。 排他制御はデータベース・カーネル側で制御しているラッチや内部ロックとユーザー自身で制御するロック(いわゆる行ロック)などがあります。 この排他制御を上手く行わないと、スループットが上がらないわけです。 3. コンフィギュレーション系の話 さらに、データベースの基本設定(パラメータや物理設計)の良し悪しでも、パフォーマンスに影響があります。 さすがに全部話していると時間がない気がしますが、出来る限りギュッとまとめて話したいと思います。

Oracle EEのオプションで最も使うと思われるものがPartitioning Optionではないかと個人的に思っています。小幡さんのブログ( Storage Serverフィルタリング考察 )にてPartition Viewという懐かしいモノが紹介されていました。7.2で鳴り物入りと書かれていましたが、すぐにPartitioning Tableがリリースされて陽の目を見なかったですね。。。 しかし、Partition ViewにはPartitioning Tableにない素晴らしい点があります。それは、EEじゃなくても使える。頑張って作りこめばPartitioning Optionみたいに使える(これは利点なのか...?)ことです。 というわけで、一回、Partition Viewをまとめてみます。 * 個人的には、昔、この機能を使いこなそうとかなり苦労しました。 まず、大前提です。 基本的には、Partitioning Tableのように論理的に一つのテーブルとして扱えません(あくまでも1つのビューです) なので、グローバルインデックスや、カラムの追加/削除、パーティションの追加/削除といったことは透過的に実行できません。 さらに、DMLもビューに対して実行できません(union all viewなので) もう一度書きますが、あくまでもビューです。 では、普通のビューとどう違うのか? それは、たった1つなのですが、現在のPartitioning TableのようにPartition ViewへのQueryの実行計画をPartitionを考慮して立ててくれること。です。 事前に準備すべき事は以下となります。 各テーブルのPartition Keyとなるカラムにはチェック制約が必要 初期化パラメータ(partition_view_enabled)がTRUE(ただし、大昔から、このパラメータは無くなり_partition_view_enabledがデフォルトTRUEとなっていますので、余り気にしない) 1のチェック制約を見て、ナルホドと思いますね。単純というか何と言うか... では、一応、やってみます。 -- 通常のビュー用 -- 2010 Q1 create table t2010q1 (term ...

以前、Unbreakable Enterprise KernelのI/O schedulerがdeadlineに変更されたと ブログ に書きました。 また、SSDであればnoopの方が合っているかもしれないとコメントに書きました。 実際のところ、どうなのでしょうか? 検証してみます。 まずは、I/O schedulerを変更してみます。変更するには3通りあるのですが、 1. bootパラメータ(elevator)を変更する 2. /sys/block/<device>/queue/schedulerを直接変更する 3. udevのルールを変更する 今回は、検証なので、2の直接書き換え方式を使っていますが、通常はは、SSDのみをnoopとしたい、かつ、リブートで元に戻って欲しくない等になるので、3のudevルールで対応すると思います。 以下のudevのルールを/etc/udev/rule.dに作成します。 SUBSYSTEM=="block", SYSFS{queue/rotational}=="0", RUN+="/bin/sh -c 'echo noop > /sys$devpath/queue/scheduler'" * queue/rotationalは磁気ディスクであれば1が設定され、SSDであれば0が設定されますが、USBのような安価なフラッシュ   ディスクの場合は1が設定される場合があるようです 今回は、15セッションでTPC-Cのベンチマークを実施してみました。 1. deadline $ su - root -c "echo deadline > /sys/block/sdc/queue/scheduler" $ su - root -c "echo 3 > /proc/sys/vm/drop_caches" Unbreakable Enterprise KernelではデフォルトとなっているdeadlineI/Oスケジューラのパフォーマンスをチェックしておきます。 今回のテストの結果では、平均のレスポンスタイムが22msとなってい...

前回( filesystemio_optionsと非同期I/O )でfilesystemio_options=asynchの動作が非同期I/Oになっていないのではないか?と書きましたが、もう少し、状況証拠をとるためにTPCのベンチマークを取得しました。 filesystemio_options=noneの場合とasynchの場合でほぼ同一の結果となっており、ますます、filesystemio_options=asynchの動作の怪しさが増しています。 - filesystemio_options=none swingbenchの結果 ASH Viewerの結果 commitクラスの待機イベント - filesystemio_options=asynch swingbenchの結果 ASH Viewerの結果 commitクラスの待機イベント - filesystemio_options=setall swingbenchの結果 ASH Viewerの結果 基本的に全てのケースでUser I/Oの待機イベントで待機しているのは変わりません。しかし、特徴的な待機イベントとしてCommitクラス(内容はlog file sync)があります。none と asynchの場合にのみ発生しています。 LGRWが log bufferからREDOログへ書き込んでいるのを待機しているわけですが、 OLTP系の処理であれば、commitはそれなりに頻繁に発行される + それなりに多くのセッションが同様の処理をする。という特徴を考えると、LGWRのアクティビティは高くなります。LGWRが同期I/Oをしている場合、commit I/Oの衝突により各セッションが待機するであろうことは想像に難くありません。 それが、none の場合(同期I/O)の場合とasynch(非同期I/Oのつもり)で、ほぼ同一のレスポンス時間、同一TPMかつ、待機イベントの傾向である。また、setall(DIRECTかつ非同期I/O)の場合で、レスポンス時間およびTPMが改善され、待機イベントにlog file syncが無いこと。 上記を考えると、やはり、filesystemi...

先日、 filesystemio_options=asynchの場合のopenモードが不思議 と書いたのですが、一応、サンプルソースを使って試してみました。 サンプルソースはLinux Foundationにある aiocp を拝借してテストしました。 [oracle@kshinkub aio]$ wget http://devresources.linuxfoundation.org/daniel/AIO/aiocp.c --2010-10-02 21:45:34-- http://devresources.linuxfoundation.org/daniel/AIO/aiocp.c devresources.linuxfoundation.org をDNSに問いあわせています... 140.211.169.81 devresources.linuxfoundation.org|140.211.169.81|:80 に接続しています... 接続しました。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 11896 (12K) [text/x-csrc] `aiocp.c' に保存中 100%[==================================================================>] 11,896 37.3K/s 時間 0.3s 2010-10-02 18:45:35 (37.3 KB/s) - `aiocp.c' へ保存完了 [11896/11896] [oracle@kshinkub aio]$ gcc -laio -o aiocp aiocp.c 処理内容はざっと以下の通りです。 1. コピー元ファイルのopen 2. コピー先ファイルのopen 3. 1に対してreadを非同期I/Oで要求し、その完了をコールバック関数で待ち受ける 4. 3のread要求が完了した場合、コールバック関数が呼ばれ、さらに2に対して非同期でwrite要求が発行される 5. write要求も完了時にはコールバック関数が呼ばれる 6. 全てのread/writeの要求が発行された場合、その完了を待って終了 つまり、処理の重いwrit...