ORACLE TECHNOLOGY NETWORK
 
 
   

Oracle Technology Network (OTN) Japan - 掲示板 » データベース(R/O) » Oracle Database 10gの部屋(読取専用)

スレッド: DBサーバ構成について

このスレッドに返信する このスレッドに返信する スレッド一覧へ スレッド一覧へ

Permlink 返信数: 20 - ページ数: 2 [ 1 2 | 次へ ] - 最新投稿 : 2006/06/07 12:47 最新投稿者: jun1017 - スレッド表示形式:
jun1017

投稿数: 24
登録日時: 00/12/12


DBサーバ構成について
投稿時刻: 2006/06/06 15:50
  このスレッドに返信します… 返信

初めて投稿します。

現在、ある製造業の基幹システム(販売管理)のDBサーバ提案・構築を
担当しているのですが、
私なりの考えは妥当なのか?またそれとは別に悩みが3点あり、
アドバイスを頂きたく投稿しました。

[システム要件]
?主要トランザクションデータ(受注・売上)が約6,480万件といった
 大量データとなる。
?バッチ処理が多く、その際大量のトランザクション
 (INSERT、UPDATE、DELETE)が発生する。
?同時接続は10〜50程度。(システム利用者は全体で200人ほど)
?24時間稼動ではなく、深夜(0:00〜6:00)にDBを停止させて
 バックアップ・保守が行える。
?DBサーバ障害時の復旧時間は3時間以内である事。
??〜?までの要件を満たし出来るだけコストをおさえる事。

[私の考え]
・Oracle10g EEを使用する。(?よりパーテション表が必須だと考えています)
・共有ディスク(SAN)を用いてディスクI/O及び、バックアップ/リカバリの
 高速化を図る。
・バッチ処理が多い事、同時接続ユーザーが少ない事から専用サーバ接続を行う。
・アーカイブログ運用を行い、深夜にオフラインバックアップを行う。
・DBサーバと同じサーバをコールドスタンバイさせておき、
 障害発生時はスタンバイサーバにリストア・リカバリを行う。

[悩み]
1.2GB以上のメモリを使用する為にOS、Oracleともに64bitにするべきか?
 (DBサーバはDBのみの利用を考えています。)
 ※32bit、64bitの判断基準を一般論、主観、経験よりアドバイスを下さい。

2.本当に共有ディスク(SAN)を採用すべきか?(コストかなりがかかるので)
 ※DAS、SANの判断基準を一般論、主観、経験よりアドバイスを下さい。

3.ライセンス形態をユーザー or CPUのどちらにするべきか?
 (CPUライセンスにした場合、コールドスタンバイサーバ側が
  もったいないですし、かといってRACにするまでもない…)

申し訳ありませんが、良いアドバイスをお願いします。


imaik

投稿数: 331
登録日時: 05/07/01


RE:DBサーバ構成について
投稿時刻: 2006/06/06 15:57   jun1017 さんへの返信です。 jun1017 さんへの返信です。
  このスレッドに返信します… 返信

こんにちは、
具体的に要件も決まっているようですし、
oracle directで相談されてはいかがでしょうか?


Tipo

投稿数: 3,713
登録日時: 00/03/02


RE:DBサーバ構成について
投稿時刻: 2006/06/06 16:15   jun1017 さんへの返信です。 jun1017 さんへの返信です。
  このスレッドに返信します… 返信

>1.2GB以上のメモリを使用する為にOS、Oracleともに64bitにするべきか?
>※32bit、64bitの判断基準を一般論、主観、経験よりアドバイスを下さい。

DBだけで2G(実質1.7GB)以上のメモリを使用し、
そのサーバではDB以外のアプリを使用しない
場合は 64bit がパフォーマンスと拡張性で
有利です。

32bit でもVLM機能により2GB以上のメモリ空間を
使用できますがその対象はバッファキャッシュだけで
パフォーマンス的にもあまり良くないと聞きます。
すでに 64bit 環境へ移行済みであるUNIX以外の
Windows やLinux でも今が転換期かと。

>2.本当に共有ディスク(SAN)を採用すべきか?(コストかなりがかかるので)
> ※DAS、SANの判断基準を一般論、主観、経験よりアドバイスを下さい。

ディスクを共有として使用するかどうかにかかっている
のではないでしょうか。もし共有せずに障害時には
スタンバイ側に移したデータでリカバリ可能な運用なら
SANは必須ではないとだと思われます

>3.ライセンス形態をユーザー or CPUのどちらにするべきか?
> (CPUライセンスにした場合、コールドスタンバイサーバ側が
>  もったいないですし、かといってRACにするまでもない…)

この辺りは Oracle Direct など正規窓口へ相談されることを
お勧めします。コールドスタンバイ構成に合ったライセンス
形態を提案していただけるはずです。


seiten_sora

投稿数: 1,369
登録日時: 03/11/18


RE:DBサーバ構成について
投稿時刻: 2006/06/06 16:29   jun1017 さんへの返信です。 jun1017 さんへの返信です。
  このスレッドに返信します… 返信

>
>2.本当に共有ディスク(SAN)を採用すべきか?(コストかなりがかかるので)
> ※DAS、SANの判断基準を一般論、主観、経験よりアドバイスを下さい。

おそらく BACKUPの時間はSANでなくても停止時間内で収まりそうですね
障害時のリストア時間を考慮するとSAN採用を私なら考えます


>
>3.ライセンス形態をユーザー or CPUのどちらにするべきか?
> (CPUライセンスにした場合、コールドスタンバイサーバ側が
>  もったいないですし、かといってRACにするまでもない…)

Oracle Direct に相談されるのが良いと思います


jun1017

投稿数: 24
登録日時: 00/12/12


RE:DBサーバ構成について
投稿時刻: 2006/06/06 18:04   jun1017 さんへの返信です。 jun1017 さんへの返信です。
  このスレッドに返信します… 返信

※文字が化けていましたので訂正します※
申し訳ありません。

[システム要件]
a.主要トランザクションデータ(受注・売上)が約6,480万件といった
 大量データとなる。
b.バッチ処理が多く、その際大量のトランザクション
 (INSERT、UPDATE、DELETE)が発生する。
c.同時接続は10〜50程度。(システム利用者は全体で200人ほど)
d.24時間稼動ではなく、深夜(0:00〜6:00)にDBを停止させて
 バックアップ・保守が行える。
e.DBサーバ障害時の復旧時間は3時間以内である事。
f.a〜dまでの要件を満たし出来るだけコストをおさえる事。

[私の考え]
・Oracle10g EEを使用する。(a.よりパーテション表が必須だと考えています)


ikegi1

投稿数: 2,378
登録日時: 97/01/20


RE[2]:DBサーバ構成について
投稿時刻: 2006/06/06 18:58   jun1017 さんへの返信です。 jun1017 さんへの返信です。
  このスレッドに返信します… 返信

15396 jun1017 さん、こんにちは。

他の方が書かれていましたが、まさにOracle Direct に聞くべきですよ。
丁寧だそうですし無償ですよ。

ちなみにEEでないと性能を満たせませんか。件数が多くても索引で
乗り切れることもあります。

------
AirWeb 4.3.5 Build.1056 ikegi


jun1017

投稿数: 24
登録日時: 00/12/12


RE[1]:DBサーバ構成について
投稿時刻: 2006/06/06 21:11   imaik さんへの返信です。 imaik さんへの返信です。
  このスレッドに返信します… 返信

アドバイスあるがとうございます!
オラクルダイレクトに確認します。

jun1017

投稿数: 24
登録日時: 00/12/12


RE[1]:DBサーバ構成について
投稿時刻: 2006/06/06 21:18   Tipo さんへの返信です。 Tipo さんへの返信です。
  このスレッドに返信します… 返信

>DBだけで2G(実質1.7GB)以上のメモリを使用し、
>そのサーバではDB以外のアプリを使用しない
>場合は 64bit がパフォーマンスと拡張性で
>有利です。
>
>32bit でもVLM機能により2GB以上のメモリ空間を
>使用できますがその対象はバッファキャッシュだけで
>パフォーマンス的にもあまり良くないと聞きます。
>すでに 64bit 環境へ移行済みであるUNIX以外の
>Windows やLinux でも今が転換期かと。
→私も同様に考えております。今が転換期ですね。
 OSはWindowsでもLinuxでもどちらでも良いと考えていますが
 お客様の運用保守を考えると、Windows技術者しかいない現状を
 考えてWindows2003-64bitを提案します。

>ディスクを共有として使用するかどうかにかかっている
>のではないでしょうか。もし共有せずに障害時には
>スタンバイ側に移したデータでリカバリ可能な運用なら
>SANは必須ではないとだと思われます
→アドバイスありがとうございます!


psycholinux

投稿数: 340
登録日時: 01/01/31


RE[2]:DBサーバ構成について
投稿時刻: 2006/06/06 21:22   jun1017 さんへの返信です。 jun1017 さんへの返信です。
  このスレッドに返信します… 返信

バッチ処理が多くてもそのI/Oをディスク分散や
64bitサーバでの大規模メモリ環境でもなんともならないですかね?

「コストを抑える」って「価格」って意味ですよね?
SEとEE+パーティション の価格差ってものすごいですよ…


jun1017

投稿数: 24
登録日時: 00/12/12


RE[1]:DBサーバ構成について
投稿時刻: 2006/06/06 21:23   seiten_sora さんへの返信です。 seiten_sora さんへの返信です。
  このスレッドに返信します… 返信

アドバイスありがとうございます。
お客様の方でSANが壊れたら…という心配の声があったのですが
「それはDASのSCSIでも同じです。」+「出来るだけ安価なSAN」を調査した
上で提案を行います!

ライセンスについては、皆さんが言われるとおり
オラクルダイレクトに確認します。

jun1017

投稿数: 24
登録日時: 00/12/12


RE[3]:DBサーバ構成について
投稿時刻: 2006/06/06 21:32   ikegi1 さんへの返信です。 ikegi1 さんへの返信です。
  このスレッドに返信します… 返信

アドバイスありがとうございます。
オラクルダイレクトに確認してみます。

パーテション表の件ですが、以前10gで同じようなシステムを
構築した際、大量テーブル(私の中では1000万件以上のテーブル)
への抽出でインデックスのグローバルスキャンだけでは満足いく
レスポンスが出せなかった経験(SQLのチューニングはカリカリに
行いました)があるのです。

ちなみに、私はこれまで2GB以上のメモリをオラクルで使用した経験が
なく、巨大なバッファキャッシュを確保する事によって、パーテション表
を使わなくても何処までカバーできるのか、正直分かっていないという事
もあります…。

jun1017

投稿数: 24
登録日時: 00/12/12


RE[3]:DBサーバ構成について
投稿時刻: 2006/06/06 21:34   psycholinux さんへの返信です。 psycholinux さんへの返信です。
  このスレッドに返信します… 返信

アドバイスありがとうございます。

パーテション表の件ですが、以前10gで同じようなシステムを
構築した際、大量テーブル(私の中では1000万件以上のテーブル)
への抽出でインデックスのグローバルスキャンだけでは満足いく
レスポンスが出せなかった経験(SQLのチューニングはカリカリに
行いました)があるのです。

ちなみに、私はこれまで2GB以上のメモリをオラクルで使用した経験が
なく、巨大なバッファキャッシュを確保する事によって、パーテション表
を使わなくても何処までカバーできるのか、正直分かっていないという事
もあります…。
SEにオプションでパーテション表機能だけ購入出来たら良いのですが^^;


U210715869

投稿数: 2,689
登録日時: 00/05/15


RE:DBサーバ構成について
投稿時刻: 2006/06/06 22:39   jun1017 さんへの返信です。 jun1017 さんへの返信です。
  このスレッドに返信します… 返信

> 障害発生時はスタンバイサーバにリストア・リカバリを行う。

3時間以内のリカバリということであれば、スタンバイDBにするよりも
ストレージの高速バックアップのほうが現実的な気がします。
スタンバイDBは、切り戻しが難しくなるのでディザスタ以外はあまり使用し
ないほうがよい気がします。
ストレージもWindows専用であれば、高速バックアップ機能がついていても
安いものもありますよ。

ほた

投稿数: 62
登録日時: 00/01/04


RE[4]:DBサーバ構成について
投稿時刻: 2006/06/07 0:38   jun1017 さんへの返信です。 jun1017 さんへの返信です。
  このスレッドに返信します… 返信

>ちなみに、私はこれまで2GB以上のメモリをオラクルで使用した経験が
>なく、巨大なバッファキャッシュを確保する事によって、パーテション表
>を使わなくても何処までカバーできるのか、正直分かっていないという事
>もあります…。

この部分に関して。

http://otn.oracle.co.jp/cgi-bin/non/msgview_r.cgi?COMMUNITYID=otn-489965&BBSID=1&NO=57420&VIEW=9

以前、上記のような投稿をしましたが、
2GB程度ある表をKEEPバッファに載せたことがあります。
その表に対してINDEXを使ったレンジスキャンが必要な検索があり、
単表検索ですが数十秒掛かっていたものが、1秒以内に返ってくる
ようになりました。

数千万件の表でもサイズがそれほど大きくないのであれば、
バッファに載せてしまう事で検索性能は大きく改善できますよ。


oraoraora

投稿数: 2,961
登録日時: 00/12/14


RE:DBサーバ構成について
投稿時刻: 2006/06/07 1:32   jun1017 さんへの返信です。 jun1017 さんへの返信です。
  このスレッドに返信します… 返信

>[システム要件]
>?DBサーバ障害時の復旧時間は3時間以内である事。
==>>
RACやDataguardは必要ない。

>?主要トランザクションデータ(受注・売上)が約6,480万件といった
> 大量データとなる。
1行100byteとして、6480万件=6480MB
必ずしもパーティショニングが必要なレベルではない

>?バッチ処理が多く、その際大量のトランザクション
> (INSERT、UPDATE、DELETE)が発生する。
 バッチ処理の特性を抑えて、パーティションキーとレンジを
設定した場合、性能面で有利

>?同時接続は10〜50程度。(システム利用者は全体で200人ほど)
 専用サーバー構成でもあまり問題とならない。

>?24時間稼動ではなく、深夜(0:00〜6:00)にDBを停止させて
> バックアップ・保守が行える。
>?DBサーバ障害時の復旧時間は3時間以内である事。


>??〜?までの要件を満たし出来るだけコストをおさえる事。
>
>[私の考え]
>・Oracle10g EEを使用する。(?よりパーテション表が必須だと考えていま
す)
 これは必ずしも必要ないのでは?

>・共有ディスク(SAN)を用いてディスクI/O及び、バックアップ/リカバリの
> 高速化を図る。
 SANを使うと数分でバックアップ可能です。

>・バッチ処理が多い事、同時接続ユーザーが少ない事から専用サーバ接続を
行う。

  同意です。

>・アーカイブログ運用を行い、深夜にオフラインバックアップを行う。
  同意です。

>・DBサーバと同じサーバをコールドスタンバイさせておき、
> 障害発生時はスタンバイサーバにリストア・リカバリを行う。
 OFS(HA)構成ということでしょうか?


>
>[悩み]
>1.2GB以上のメモリを使用する為にOS、Oracleともに64bitにするべきか?
> (DBサーバはDBのみの利用を考えています。)
> ※32bit、64bitの判断基準を一般論、主観、経験よりアドバイスを下さ
い。
  大容量のメモリーを確保する場合
  OS/Oracleとも64bitのほうがよいと考えられます。
(大容量のSGAをVLMと違いあまりオーバーヘッドとならずに
確保できるため)


>
>2.本当に共有ディスク(SAN)を採用すべきか?(コストかなりがかかるので)
> ※DAS、SANの判断基準を一般論、主観、経験よりアドバイスを下さい。
 それはこの業務の重要性によると思います。


>3.ライセンス形態をユーザー or CPUのどちらにするべきか?
> (CPUライセンスにした場合、コールドスタンバイサーバ側が
>  もったいないですし、かといってRACにするまでもない…)
 今はCPUのほうが面倒な計算をせずに済むのでお勧めです。






ウェブサイトのご使用条件 | 個人情報保護基本方針/情報保護基本方針