- PR -

Strutsのデータソース

«前のページへ 1|2
投稿者投稿内容
あしゅ
ぬし
会議室デビュー日: 2005/08/05
投稿数: 613
投稿日時: 2006-03-08 01:21
引用:
一時表領域がパンクしたのは、更新処理のときではなく検索画面で検索をしたときなんです。
それでも↑のような対応でも良いんでしょうか？


検索ですか・・・。それだと厳しいですね。
すでにSQLレベルで思いつく限りの最適化をされているのでしたら
まともな対策をするにはDB設計の方から変わってしまうと思います。

複雑で巨大なSELECTを投げているのであれば、PL/SQLのプロシージャに
分割して一時テーブルに結果を出力してみる、なんて手もありますよ。
UNIONしまくりなSQLの場合には有効だったこともありました。
検索条件によって参照先を削減したりもできますし。

どんなところがネックになっているかわかりませんが、末端で数十万件
でしたら多すぎる件数ではないので、テーブル構造そのものは変更せずに
解決できそうな気がします。
NEO
大ベテラン
会議室デビュー日: 2005/10/02
投稿数: 104
投稿日時: 2006-03-08 02:07
該当の画面には一覧を表示するのですが、最大件数は決まっています。
SQLで件数を限定するのと、検索条件に該当するレコード全件抽出してJavaでフィルタするのとではどちらが一時表領域の使用量が少ないでしょうか？
たしかSQLで件数を限定するときは、ROWNUMを使う必要があって、ROWNUMを使うにはORDER BYが必要だったような･･･。
せん
ぬし
会議室デビュー日: 2002/03/04
投稿数: 397
投稿日時: 2006-03-08 02:30
引用:

「Webシステム要件の最大同時接続数」とは「同時にOracleにアクセスできる最大数」のことなのかどうかが判断できずに困っています。

あなたが判断して良い事ではありません。
わからないなら、わからないとはっきりお客さんに聞いて下さい。
「だと思う」で動くと、更なるトラブルを招きますよ？

わたしとしては、同時接続 1000 といわれて、DBへの接続を Max 10 にした
という考えが少々わからんのです。
progman
大ベテラン
会議室デビュー日: 2005/06/08
投稿数: 227
投稿日時: 2006-03-08 09:13
少し前にデータ件数が多すぎて、一時表領域ではなくてVMがOutOfMemoryになるということがありました。
OutOfMemoryになるのはOracleでソート後のデータを表示分づつ持ってくるよう取得法を変更すればいいけど、その処理は検索で普通に一般ユーザが使う機能であり、こんなデータ量（120万件）をソートしたら、一時表領域がもたないということで、絞込みのための条件入力を必須としたことがあります。

同時に走る処理はどの程度必要か計算して必要リソースを確保する。それが現実論でないなら、システム上や運用で制約をつける。しかないのではないでしょう。

StrutsでのＤＢに関する設定と、Oracle上のリソースの話はわけて考えるべきでしょう。

>1000人同時にselect実行を可能にすることが要求のように思えるんですが･･･。
それはここで聞いてもわからない話ですよね。

同時接続は10なんて400MBx10でよい、あとは待機させる。
待機可能であってエラーにはならないから、よいといった考えなのでしょうか？

NEO
大ベテラン
会議室デビュー日: 2005/10/02
投稿数: 104
投稿日時: 2006-03-09 00:09
ユーザが言っているように同時接続1000を実現できるようにするか、
譲歩してもらうよう交渉するかどうかはまだわかりませんが、もう少し調査が必要のようです。
400MBという結果が性能試験で一時表領域がパンクした時に使用した画面とは異なる画面で得られたものだからです。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）