<<脱おら宣言>>
二度と使ってやらないYO!
315 :
仕様書無しさん:01/10/23 01:07
like は遅いよ プンプン
>>314 でも正直さ、余程のことがない限りオラクルは避けるのが正しい鴨ね。
良い面もあるんだけど、コストとか、リソースとか、要求スキルとか
高すぎるんだよ、他のと比べると。 俺自身のスキルはおいといて。
客に売るときはこれを逆手にとることもできるけどね。
>>316 > コストとか、リソースとか、要求スキルとか
> 高すぎるんだよ、他のと比べると。
Oracle 以外使ったことないんだけど、確かに高い。
ライセンス 2 ユーザしか買えなくて、アプリケーションでキューイング
したこともあったなあ。
開発キットも高いし。(てゅーか、Pro*COBOL なんか要らんちゅーに)
>>317 ライセンス体系変わったの知ってる?
Oracle9i Database Standard Editionだと、5指名ユーザで16万だよ。
Personal Editionは79,000。
Enterprise Editionは手の届かないところにいっちゃったけど・・・。
319 :
仕様書無しさん:01/10/23 14:17
>318
>Enterprise Editionは手の届かないところにいっちゃったけど・・・。
OTN版、OTN版。
320 :
仕様書無しさん:01/10/23 21:27
体験版ってこと?
使用期限がなかったっけ?
321 :
仕様書無しさん:01/10/24 23:13
今7.3使ってます。
接続に10秒くらいかかるのですが・・・
7.xはこんなに遅いの?
それとも設定をミスったのかなぁ。
と解釈してるけど、許諾書読んでないから本当にそうなのかは知らん。
>>322 期限の制限はないけど、使用目的が限られてるYO!
>>322 思わずダウンロードしました。
でも、Net8ConfigurationAssistantっていうのを立ち上げると死にます。
それはともかく、どうやって使うのかな?チュートリアルとかあるの?
326 :
仕様書無しさん:01/10/26 21:01
質問でっす。
Oracleを使ってます。
ユーザーが5つ程あり全て同じ表領域で設定してあるのですが
表領域は複数作ってユーザー毎違う表領域を指定した方が
処理が早いのでしょうか?
327 :
仕様書無しさん:01/10/26 21:39
>>326 まあ、DISKまで分ければアクセス集中時には若干速くなるでしょう。
でも 容量の管理が面倒になるので、私ならRAID化して一つの表領域のまま
パフォーマンスを上げますね。
>>327 ありがとうございます。
若干速くなる程度なんですね。
もう一つ質問があります。
ずっと前に何かの本でSGAのメモリを増やせばパフォーマンスが
かなり上がるというのを見たのですが
どうやればよいのでしょうか?
またそれは本当の事なのでしょうか?
よろしくお願いします。
329 :
仕様書無しさん:01/10/26 22:13
>>328 shared_pool_sizeなんかを増やすといいよ。
100Gくらい割り当てな。
330 :
仕様書無しさん:01/10/27 01:12
331 :
仕様書無しさん:01/10/27 01:22
>>328 redoログファイルの大きさを増やすと更新は速くなるよ。
だまされたと思って 一個 50Mくらいにしてみて。
332 :
仕様書無しさん:01/10/27 01:46
>>326 表領域を分けるかどうかは、運用面も考えておいたほうがいいよ。
オンラインバックアップは表領域ごとにやるし、表領域単位の管理も
多いので、煩雑にならない程度に分けたほうがいい。
少なくともプロジェクトとかシステムという単位では、分けておいたほうがいいよ。
ム板でしょ
335 :
仕様書無しさん:01/10/27 12:41
>>332 表領域は5つ位でOKですか?
皆の意見をまとめると
1.表領域をユーザー毎に分ける。
2.shared_pool_sizeを50Mにする。
3.REDOログファイルを50Mにする。
4.もっと早くしたければRAID化する。
こんな感じでしょうか?
まだOracleの設定でパフォーマンスを上げる方法があれば教えてください。
336 :
仕様書無しさん:01/10/27 15:22
REDOログファイルってなんて読むの?
レド?
338 :
仕様書無しさん:01/10/27 16:35
昔オラクル社員がレドロクって読んでた。変だと思ったけど・・・。
339 :
仕様書無しさん:01/10/27 16:37
ゴメン
レドロク -> レドログ
昔とある元請け屋が日本語でテーブルのカラム名を書いたとさ。
プログラムの開発作業にかかって数週間下頃いきなりエラーが。。。。。
調べてみると作成中のプログラムに関わるテーブルの
カラムの大部分が変わっている。
聞いたら「名前が○○××△△だと日本語としておかしいので
××○○△△という形に変えました。」だってさ
それでプログラムをすべてそれに合うように書き換えなければ行けなくなって
急いでやってくれとのことなので土日も出ていたのに、それで進捗が遅いだの困りますと言うと柔軟性がないだの。。。。
金輪際日本語カラム名はこりごり。
フィールド名の変更くらいサクっと対応できる作りにしてないの?
まぁ、日本語名は糞だけどさ。
>340
そりは「日本語」を「英語」に置き換えてもいっしょでは
>>335でよろしいですか?
REDOはリドゥーって読むのかあ。
ヤベ、知らなかったよ。
344 :
仕様書無しさん:01/10/27 22:11
>>335 それでいいと思う。
でもパフォーマンス上げたいのであれば作りを見直したらどうでしょうか?
345 :
INFORMIX:01/10/28 01:35
使ってる方っているんでしょうか。DBとしては結構よくできてると
思うんですが、マイナー感が否めない・・・
日本語名は、社内用のちょっとした管理システムには使ってます。
対顧客用では使わないですね。
OS/390とAIXでDB2(UDB)使ってます。レスポンスはそこそこ良いです。
でもAIX上のUDBはちょっと油断するととたんに遅くなったり、トラブルが
出たりで疲れます。OS/390常のDB2の方が、解析ツールとかが充実し
ているので、どこが悪いかの分析結果が早く出ます。
347 :
仕様書無しさん:01/10/29 14:28
テーブル名やらフィールド名は基本的に日本語で作って、
別名として半角アルファベットに変換するViewを作ってるのですが、
パフォーマンスに大きな影響はありますか?
>>6 逆の方がいいんじゃ。
パフォーマンスはRDBMSの実装依存。
でも多分影響はほとんど無い。
350 :
仕様書無しさん:01/10/31 18:53
逆のほうがいいよ。
テーブル名、フィールド名が日本語だと無用なトラブルにまきこまれたりする。
昔の話だけど、sqlload(direct loadの場合)すると無限ループに陥って
停止してしまったりということがあったそうだ。
テーブル名、フィールド名のどっちだったか分からないけど日本語が原因。
>逆のほうがいいよ。
>テーブル名、フィールド名が日本語だと無用なトラブルにまきこまれたりする。
全くその通りなのだが・・・
半角英数だと、エクセルの日本語項目をエクスポートインポート
する時やら日本語表示したいときやら、うまい方法がなくて困っている
酔い方法しらんかえ?
352 :
仕様書無しさん:01/10/31 21:02
データベースは、テキストファイルを使っています
RDBしか知らない人たちにNDBってなんですか?ってきかれた。
あなたならどう答える?
354 :
仕様書無しさん:01/11/01 23:53
>>353 なんですか?
ついでに、CASEツールってなんですか。UMLからDB作ってくれたりするんですか?
安いくて使えるのがあったら教えて。
355 :
仕様書無しさん:01/11/01 23:57
>>353 「しらんでヨシ」とこたえる。
そしてアナルオナニーして寝る。
NDBしか知らない人たちにRDBってなんですか?ってきかれた。
あなたならどう答える?
357 :
仕様書無しさん:01/11/02 00:13
>>356 「ケツの穴に聞いてみろ」とこたえる。
そんなことよりよ。
J2EEについてくるDB動いてくんないんだよ。
おれの乳首デカ過ぎるからかな?
358 :
仕様書無しさん:01/11/02 10:44
>>357 CloudScapeのこと?JAVA_HOMEやJ2EE_HOMEが設定されてないからでは
なくて?
>>358 右乳首は抜いてる。
左乳首は伸ばしてる。
マス大山の影響なんだ。
361 :
仕様書無しさん:01/11/03 10:58
>>263 H○RDB使ってます。
たしかにあのドキュメントはひどいね。
わかりづれーというよりどう読んでいいのかで悩む。
作った人も「これで良し」と思っているのだろうか?
362 :
仕様書無しさん:01/11/11 17:12
>>31 次のpostgreはvaccumが変更になるらしいですが、天下を取れますか?
>>362 vacuumが不必要になるわけではありません。
また、仮にvacuumが不必要になったとしても、天下は取れないでしょう。