やむをえずOracle10g上でテーブルを全件取得せざるをえない案件が

やむをえずOracle10g上でテーブルを全件取得せざるをえない案件があります。

ま、時間がかかるのは承知の上なのですが、少しでも短くするため
1.DB本体はSSD上にのせる
2.GigabitLANでサーバーとクライアントをつなぐ
をしております。

上記以外に、ハードウェア的に対処できる方法ってありますでしょうか？

No.2 ベストアンサー 回答者： whiteline507 回答日時： 2010/07/11 10:42

#1です。

cacheが効かないことは無いと思いますよ。
SSDのプチフリ対策のRAMDISK関連の記述とかにも良く載っていますが
SSDが速いといっても所詮数百MB/secレベルです。
それに対してcache（メモリ）は数千MB/secレベルなので10倍以上速くなるはずです。

処理時間が変わらなかったのであればおそらく最初からメモリに載っていたのだと
思います。
OSを再起動した直後に普通に一発目でselect count(*) from table_name;
とする場合とcacheに載せてから（alter table...だけではキャッシュには載りません
その後select * from table_nameを行って初めてキャッシュに載ります）
select count(*) from table_nameとするのでは格段の差が生まれると思います。

実際に計測するときにselect * from table_nameでやってしまうとDISKやメモリへの
アクセス速度だけではなく、結果の画面表示の時間がほとんどになってしまって
差は生まれない（隠れてしまう）と思います。

No.1 回答者： whiteline507 回答日時： 2010/07/06 22:39

ハードウェア的にであればいくらでもあるかと思います。

・ストレージのキャッシュ容量を大きくしてそこに予め朝バッチなどで載せておく
（これはストレージのキャッシュではなくBUFFER_CACHE上でも同様ですが）
・ストライピング数を増やす
・ディスク自体の回転数を上げる
・ディスクのインタフェースを見直す SATA＜SAS＜FC＜SSD
・ストレージとのインタフェースを見直す NAS＜iSCSI＜FC
上記はDBサーバローカルでの話しで、
サーバとクライアントの速度を向上したいのであれば
ソフトウェアレベルの対処として
・MTU、SDU、TDUパラメータを見直す
・OCIクライアントキャッシュを使う（11g～）
といった形です。あと、DBサーバ上でチューニングするソフトウェアとしてのパラメータも
非常に色々とあるかと思います。
DB_MULTIBLOCK_READ_COUNT、BUFFER_CACHE_SIZE、DB_BLOCK_SIZE、
テーブルのキャッシュ常駐化などなど．．．

この回答への補足

alter session set db_file_multiblock_read_count=128
とか
alter table hogetable cache
とかが代表的な手段なようだったので試してみましたが、
既にSSD化しているためか余り効果が認められませんでした。

ただし、HDに載せてる場合には、alter session set db_file_multiblock_read_count=128
が強烈に効きました。

後出来ることといえばSSDのデフラグ位かとおもってますが、
intel製のSSDではデフラグ効果は薄いときくし悩ましいところです。


LAN周りはJumboFrameしてみましたが、当方の場合にはあまり効果なかったです。


SSDに載せている場合、FullScanのtuningは余り要らないというか、できないのかも...

補足日時：2010/07/08 22:21

この回答へのお礼

ご解答有難うございます！

一つずつ実行し、うちで有効であった手段についてまた報告をアップします。

お礼日時：2010/07/07 22:37