貧弱な内部データベース-交換するか、ハードウェアをチャックしますか？

だから-私たちは社内のデータベース、通常の種類のものを持っています：クライアント、電話、販売取引、クライアント契約/スキームを管理します。

これは、Access 2000フロントエンドおよびSQL Server 2000 Standardバックエンドです。単一サーバー、デュアルXeon 3.2GHz、2GB RAM、Windows Server 2003は、1日中約40％のCPU負荷を取得し、OS（HT）から見える4つのコアに分散しています。

バックエンドデータベースの設計は不十分であり、10年以上にわたって有機的に成長し、熟練していない個人によって維持されています。それはひどく正規化されており、いくつかの明らかな問題には、主キーまたはインデックスのない数万行のテーブルが含まれます。これらは、システムの最も頻繁に使用される一部のマルチテーブル結合でも頻繁に使用されます（例：全員のセカンドモニターに1日8時間常駐し、数秒ごとに大きな非効率的なクエリを実行するコールマネージャーアプリケーション）。

フロントエンドはあまり良くありません。それは典型的な数百のフォームの混乱、ネストされた保存されたクエリ、VBAコードでの不十分な記述の埋め込みSQL、数十の「奇癖」などです。「十分に」機能する1つのMDBに決着しました。現在、社内にAccessヘビーウェイトがないため（また、いずれも採用する予定もありません）、変更に関するポリシーはありません。

同社は現在ゆっくりと成長しており、クライアント、コールなどの数が増加し、同時ユーザー数がわずかに増加しています。また、最近ではパフォーマンスが著しく悪化しています（フォーム間を移動するのを待っている、リストにデータが入るのを待っているなど） ）

Perfmonより：

• 1秒あたりのディスク転送：0〜30、平均4。
• 現在のディスクキューの長さ：1前後

SQL Serverのプロファイラーは、毎分数十万のクエリを確認します。クライアントのCPU使用率はほとんどゼロであり、サーバー側のクエリの実行を待機していることを示しています。DB Engine Tuning Advisorを使用してこのワークロードを配置し、テストバックアップにその提案を適用しましたが、実際にはそれほど大きな違いはありません。

ちなみに、100MBとギガビットイーサネットが混在しており、すべて1つのサブネット上にあり、2つのフロアに40人のユーザーがいます。

質問に。

私が見るように、この状況を解決/改善するための2つの選択肢があります。

• それを廃棄して、完全に新しいCRMシステム（特注または一部特注）に置き換えることができます
• ハードウェアをチャックすることで、このシステムの寿命を延ばすことができます。

ソフトウェアを交換するよりもはるかに少ないコストで、クレイジーなパフォーマンスを備えたIntel i7システムを構築できます。

最終的に新しいシステムが開発されると、このボックスでホストできるため、無駄なハードウェアはありません。新しいCRMシステムはどんどん消えていきます。少なくとも1年間はそうなるとは思いません。

特に自分がここにいる場合は、この状況についての考えをお寄せください。

ありがとう

私はここにいるすべての人に反対します。それでいくつかのハードウェアをチャックします。安価、高速、簡単で、適切なCRMソリューションの実装に必要な時間を節約できます。このボードだけでなく、StackOverflowのほぼ全員に嫌悪感を抱かせる理由を提唱しているのは、私がプロジェクトマネージャー/マネージャーであり、しばらくの間「ビジネス」側にいたためです。私の言葉に対する嫌悪のために引用符で囲まれています）。ソフトウェアの説明に基づいて、他の何かを再構築するには1年近くかかります。ビジネスルール/癖を発見/文書化するだけで、おそらく2か月かかります。また、開発には信じられないほど高価になります。特に、だまされたサーバーのコストと比較した場合。

まさにその理由で、私は実際に会社のために一連のWebアプリをホストしようとしています。社内のIT部門は、新しいプラットフォームで再開発したいため、より良いハードウェアに移行しません。そのコストは、新しいハードウェアに移行するのにかかるコストの約3倍です。会社が1年で契約を更新しないかもしれないことはあまり言及しません。

どちらかをする必要はないかもしれません。私の提案は、単にいくつかのインデックス/キーをテーブルに追加することです。

主キーまたはインデックスのない数万行のテーブル。これはマルチテーブル結合でも頻繁に使用されます。

多くのお金や時間を費やす前に、数時間かかり、それらの結合に関係するテーブルにインデックス（または、可能であれば主キー）を追加します（特にwhere句で使用される列の場合）。わずか数時間でパフォーマンスを10倍に簡単に改善できます。

ディスクI / Oの欠如は、クエリがほとんどRAMから供給されることを意味します。ホットテーブルがRAMに「突然」収まらず、サーバーがディスクの動作を開始した場合、うまくいかない可能性があります。最近では2GBやRAMはそれほど多くありませんが、SQL2000の時代にはかなりの大きさでした。アプリケーションが通常操作するデータの量は、使用しているRAMよりも少ないと思います。データファイルの「使用済み」スペースの量を確認することをお勧めします。これにより、最悪の場合にデータベースが消費するRAMの量がわかります。SQL Serverは、必要のないデータをRAMに保持しませんが、どのテーブルがいつ使用されるかを知るのは難しい場合があります。

ハイパースレッディングは、SQL Serverで常に役立つとは限りません。オフにすると、パフォーマンスが向上する場合があります。オンとオフを切り替えるには再起動が必要なため、テストするのは難しく、実稼働サーバーでは大きな手間がかかります。

「毎分数十万件のクエリ」は、毎秒数千件のクエリに変換されます。かなり忙しいように聞こえますが、そのトラフィックの多くはAccessによるカーソルフェッチにすぎない可能性があります。アクセスは、SQLから結果セットを効率的に取得するのが特に困難です。SQL Serverの並列化設定をオフにすると、パフォーマンスが向上する場合があります。

また、ブロッキングを探す必要があります。ブロッキングの問題にハードウェアを投げても、期待される劇的な改善が常に得られるとは限りません。ブロッキングがあまりなく、クエリがディスクではなくRAMで満たされる場合、基本的にはプロセッサのうなりと、メモリチャネルを介してデータをプルする機能に依存しています。その場合、より高速なハードウェアが優れた改善を提供するはずです。急いで（この問題を乗り越えるために）ゆっくりと成長している場合は、それで十分かもしれません。

ソリューションとして、ハードウェアを追加しても、データベースの改善だけでなく拡張もできません。成長が急増すると、新しいハードウェアが苦労することがあります。別の考えは、成功したアプリケーションがユーザーを引き付けることです。アプリケーションの応答性が向上すると、ユーザーはレポートの終了を待つ間にコーヒーを飲む必要がある場合よりも、レポートなどを実行する可能性が高くなります。

データベーススキーマが本当に悪い場合は、テーブルのインデックスを見るだけでパフォーマンスが向上する可能性があります。頻繁に照会されることがわかっているテーブルに集中します。プロファイラーを使用して、サーバーに対して実行中のクエリを監視し、大量のデータ（100,000ページなど）を読み取るクエリを検索するように指示し、その後、あまり読み取らないクエリに取り組むことができます。一部のテーブルにはキーがないと述べました。データに自然キーがあり、制約や一意のインデックスによって強制されていないだけですか？

テーブルにはクラスター化インデックスがありますか？クラスター化インデックスの欠如は、あらゆる種類の二次的な影響を引き起こす可能性があります。

多くの列を持つ非クラスター化インデックスがたくさんありますか？これは、多くの場合、より効果的なインデックス作成戦略を実装するのではなく、多くのカバーインデックスを構築する試みです。SQL Serverは、そうすることが理にかなっており、非クラスター化およびクラスター化インデックスをサポートしている場合、クエリ中にカバーインデックスをその場で効果的に構築できます。

最後に、質問する価値があります。テーブルでメンテナンス（インデックスの再作成や統計の更新）が行われていますか？

これは技術的な質問ではなく、ビジネス上の質問です。

ビジネスオーナーとして： システムはビジネスにとってどの程度戦略的ですか？戦略性が低いほど、それを気にかけたり修正したり、費やしたお金は、ビジネスを成長させるために他の場所で使用できるお金になります。

彼らは皆大きな部屋に入り、デザインについて議論し、私に金を払ったので、コンピューターの人々は私を怖がらせます。システムを継続してください！これがパフォーマンスチューニング（再設計なし）またはそれ以上のハードウェアの投入を意味するかどうか、それが動作を停止する場合にのみ優先順位です。

ITコンサルタントとして： システムはレガシーであり、運用コストが隠れています。お客様に最適なシステムを設計し、将来の成長と戦略的優位性のためのプラットフォームを拡張および提供できます。ここにサインしてください。あなたの夢がすべて叶います。

IT従業員として： 私はここでスーパーヒーローになり、この事から地獄を最適化することによって差し迫った災害を回避することで会社を救うことができます！会社を何千人も救うので、マネージャーが贈り物と賞賛を浴びせてくれます。

私は両方とも言います。

今、あなたが言ったCPUの40％程度ですか？あなたはまだユーザーから不満を言っていますか（たくさん）？そうでない場合は、まだ呼吸室があります。しばらくメモリを追加すれば十分です。

行く方法についての質問は、社内にソフトウェア開発者がいますか？答えがNOの場合は、やり直そうとしないでください。あなたは今いるところに正確に行き着くでしょう。

社内開発者がいると仮定すると、社内開発者はプロジェクトを適切に行うことができますか？基本的に顧客のプロジェクトの場合と同じように、完全に、適切に（相対的な）タイムラインで仕様を説明しています。そうでなければ、気にしないでください。さもないと、今いる場所に戻ってしまいます。

企業が彼ら自身もクライアントであり、社内プロジェクトに同じリソースを提供する必要があるまで、あなたはまさにあなたが今いるところに行き着くでしょう。そこに行って、それをして、Tシャツのドレッサーを手に入れました。

もしあなたがそれをきちんとできないなら、あなたは2つの選択肢が箱から出るターンキーです、あなたはあなたが買うシステムの型に合わなければならないのでスタッフは嫌いです。または、カスタマイズ可能であり、プロジェクトのカスタマイズに時間を費やす必要があります。

またはあなたが持っているものをリファクタリングします。新しいものが入ったとき、人々はまったく同じ完全な機能性を期待することを忘れないでください。リファクタリングすると、どのように機能するかを理解する機会が得られ、その後、アドホックな変更ではなく、多くの小さなサブプロジェクトに計画します。

システムを見ることなく、バックエンドでできる限り多くの正規化を行い、SQLの多くをストアドプロシージャに移動することになるでしょう。次に、C＃Formsまたはwebappから新しいフロントエンドを構築します。フロントエンドからビジネスロジックとSQLを取得できれば、後でやり直しやすくなります。あなたが小さなプロジェクトに何をするかを維持することにより、いつでもそれが脇に押しやられたり停止されたりした場合、あなたは使用される進歩を遂げているでしょう。

ここでいくつかの良い回答が既にありますが、（社内の開発者がいると仮定して）比較的少量の作業が大きな影響を与えることを指摘するかもしれません-主キーを追加します（すべてのクエリをそれらを使用します）、使用するフィールドにインデックスを追加し、クエリを少し調整すると、大幅な増加が見られます。今すぐRAMを購入して、修正に必要な時間とヘッドルームを購入し、仕事に取り掛かります。

「それを修正するか、それを捨てる」というテーマで、システムの機能が基本的にあなたのために機能し、必要なことをするなら、ホイールを書き直さないでください。あなたのニーズに合わないためにユーザーが体操をして物を使用しなければならない場合、努力することは意味がありません。

さて...これは少し前ですが、ここで結果を記録すると思いました。

最後に、別の問題に対処するためにVBAを1行ずつステップスルーしました。そのとき、行セットをフェッチする呼び出しが20〜30秒以上ブロックされていることに気付きました。

それらを掘り下げると、行セットがMS Accessクエリに基づいていることがわかりました。

別のAccessクエリからデータを選択していました。

それは、さらに別のAccessクエリからデータを選択していました。

これらはすべて、クエリデザイナーを使用してドラッグアンドドロップされたように見えました。

ユーザーの上位6分の苦痛ポイントを調べたところ、間違いなくすべて同じであることがわかりました。

そのため、チェーンクエリのスタックを完全に削除し、それぞれをT-SQLで記述してサーバーで直接実行できる単一のパススルークエリに置き換えました。

改善はすべての場合において間違いなく広大であり、誰もがクエリを待つことはもうありませんでした。

そして会社を辞めました。まだそこにあるかどうかは分かりませんが...見逃しません。

デイトンの回答に追加するのではなく、回答を投稿する最初の数人によって考慮されていないコストがあるため、別の回答を投稿しています：ユーザーを再訓練するコストとそれに適合するビジネス手順を変更するコスト新しいソフトウェアプログラム。そうでなければ、彼が言ったこと。

企業が独自のソフトウェアを開発する主な理由の1つは、市場に出ているものと一致しないビジネス手順を持っていることです。これは素晴らしいことです。企業の個々のビジネスプロシージャは、企業がテーブルにもたらす価値の重要な部分であり、企業が市場の残りの部分に対して競争上の優位性を持っています。ソフトウェアを一般的なものに置き換えるには、従業員を再教育して競争上の優位性を犠牲にするか、ビジネスプロセスに合わせてソリューションをカスタマイズする必要があります。どちらも高価で時間がかかります。システム管理者であると同時にビジネスコンサルタントとして、私はこれらの費用が小さな会社を殺すのを見たことがあります。

あなたの声明から、あなたはほとんどプロセッサ/ソフトウェアに縛られているように見えます。特に、現在使用していない列にインデックスを（制限内で）追加します。そして、私はあなたができる最速のプロセッサのセットをチャックします。なぜなら、多くのドライブが「ピーク時のセプト」を読まないなら、それがあなたがバインドしているように見えるからです。

（また、サーバーエディションを可能な限りアップグレードします。これを導入するまでに、Access 2000とSQL Server 2000は10歳になります。これはコンピューター時代では古いことです！）

これには、完全な再構築（再構築）が必要です。システムを一から作り直します。これにより、長期的には大幅に節約できます（メンテナンスのオーバーヘッドコスト）。それまでの間、ハードウェアをチャックします。この質問は、技術的な調査というよりも「ビジネスケース」だと思います。技術的には、答えは「それにより多くの力をかける」ことです。ビジネス面では、新しいシステムを構築してください！

技術的な答え：

主キーとインデックス作成を徹底的にレビューする必要があることを示す多くの提案があります。また、Accessでは、各テーブルでSQL ServerのTimeStampまたはRowVersion列を使用することが非常に好きです。これにより、レコードの更新に関して、Accessがレコードの変更を決定するのに費やす時間を大幅に短縮できます。

ビジネス上の答え：

新しいCRMソリューションはトレーニングスタッフの多くの作業であり、ビジネス要件に正確に合ったシステムになることは決してありません。

また、SQL Serverの知識が豊富で、テーブルの正規化とユーザーの問題点の修正に3〜6か月を費やせる優秀なAccess担当者を見つけるでしょう。静かなスペースにいるにも関わらず、ユーザーがユーザーとしてsaemフロアで作業し、アクセスできるようにします。あまりアクセスできませんが。開発者は中断が好きではありません。S

与えられた情報に基づいて、システムを交換します。できれば、他のシステムとの柔軟な統合を可能にする別のCRM（ERP ISを危険にさらす）を使用してください。

最も難しいのは、管理者とユーザーがアップグレードを必要とするように説得することです。

管理

技術的な問題、パフォーマンスの低下、ビザンチンの失敗に対する恐怖などについて懸念を表明します。次に、2つの代替CRMを提示します。ビジネス統合、ビジネスの全体的なERP戦略、そして最も重要なこととして従業員の生産性と収益性を高める方法について話します。ユースケーススタディ。15分以内に作成します（詳細情報が必要な場合を除く）。その後、ユーザーを説得する必要があります。

ユーザー

トレーニングプラン（ベンダーが提供する可能性がある（および管理者が支持する必要がある））、ユーザーの上位20％（パワーユーザー、トラブルを引き起こすもの）への継続的なコミュニケーション、およびシステムを100％稼働状態に保つための確固たるコミットメント最初の月（最初の月は新しいISを作成または中断します）。

そこには多くのCRM製品があります。ビジネスニーズに最適なものを選択してください。

それにハードウェアを投げることは、システムが非常に哀れになり、最新の最高のハードウェアでもうまく動作しないまで、より貧弱な設計と管理を促進するだけです。よりよい実装を検討する時が来ました。最初に必要なものを分析します。要件を完全に理解した場合にのみ、それらを実装する最適な方法を検討できます。要件を理解したら、要件を変更し、所有するものを変更するか、またはまったく異なるものを最初から開始する方が費用対効果が高いかどうかを検討します。

長期的には、おそらくデータベースをやり直すのが最善でしょう。より多くのハードウェアを投入することで問題が少し解決しますが、それを使い続けると、しばらくしてより多くのハードウェアを投入しなければならなくなります。

通常、パフォーマンスの問題がある場合は、ハードディスク/ RAIDのI / Oボトルネック、データベースのシャーディングなどを調べますが、シャーディングのようなものを利用するには、データベースを適切に設計する必要があります。それの音から、あなたのアプリケーションは決してスケーリングすることができません。

長期的には、現在のビジネスニーズをより適切に反映するためにデータベースとフロントエンドソフトウェアをやり直すことで、長期的にはより良いサービスを提供できます。ユーザーはあなたに感謝します、あなたのハードウェアは長持ちします、そして、それは問題で巨大なハードウェアを投げるより長い目で見ればはるかに多くのお金を節約します。

あなたの説明を考えると、全く新しいオーダーメイドのシステムの作成は無意味です-あなたは、あなたが始めたところにたどり着くか、おそらくあなたが今よりも悪くなるでしょう。そのため、サードパーティのソリューションを購入するように誰かを説得できない限り、最善の策は、できる限りリファクタリングし、ハードウェアを投入することです。

2つのことを実行する必要があると思います。1）SQLサーバーでのパフォーマンス分析。サーバー側が遅延の原因であると特定したようです。そのため、どのクエリが遅れているのか、そしてその理由を知る必要があります。すべての可能性において、最適化するためのホットスポットクエリを見つけることができます。これは大きなメリットをもたらします。さて、数秒ごとに更新するクライアントがある場合、更新レートを下げることができるかどうかを確認してください（画面上のリストは本当に5秒ごとに更新する必要がありますか？30でも大丈夫ですか？ ）。リフレッシュタイマーを増やすなどの愚かなことは、それで済ませるなら、多くのオーバーヘッドを節約することができます。

2）さらにハードウェアを投げます。特に大量のラムを投げます。データベースがRAMに完全に収まるほど多くのメモリが必要な場合。OSとソフトウェアのバージョンに注意してください（Windowsのバージョンとそれらが実際にサポートするハードウェアには、明らかに非常に多くのルールがあります）。より多くのコアが役立つことを確信できる場合は、できるだけ多くのCPUとコアを投入してください。

RAMとプロセッサについて言及しましたが、ディスクについては言及していません。MSのSQL Serverを扱ってからほぼ10年が経ちましたが、メモリにすべてが収まらない場合は、他のデータベースと同様にディスクにバインドされます。

おそらく、最初に必要なだけのRAMでマシンをいっぱいにしてみます。次に、テーブルまたはインデックスに使用されていないディスクにログが書き込まれていることを確認します。次に、同じスピンドル上にインデックスを持つテーブルがないことを確認しようとします。

その後、データベースレベルのチューニングについて心配しますが、それによって、物事を壊したりクエリを悪化させたりしないように、テストと最適化の目標を定義する必要があります。主キーはテストデータベースではあまり利点を示さないと述べましたが、テスト方法を検討する必要があります-主キーは一部のデータベース（MS SQLが 'emの1つであるかどうかは不明）でレコードレベルロックを使用できるようにすることができます、テーブルレベルのロックではなく、少数のユーザーのみのテストでは表示されない可能性のある競合を削減できます。

まず、Kyle Hodgsonに同意し、PKを追加します。安価で（時間のみ）、クエリが大幅に増加する場合があります。あなたのトップ10の最もugいクエリの結合列のインデックスはどうですか？テーブルスキャンはどこにありますか？

第二に、データベース内のデータのトリミングについてはどうですか？本当に必要な数より多くの行がクエリで返されていますか？また、KyleのRAM（2 GB以上）の提案にも同意します。

これらのすべてを、将来の計画を立てる際に暫定的に提案するものについての記事（Joseph Kern）に入れてください。現在のCRMアプリがクレーターになって利用できない場合、組織に何が起こるかを管理とユーザーに尋ねます。おそらくそれは彼らに未来について考えさせるのに役立つでしょう。

ハードウェアを入手してください！

Xeon 55xxシリーズチップを使用する場合、スズは現時点で非常に安価であるだけでなく、投げることができるものは何でも叫ぶでしょう。

それは単なるリスク/報酬のことです-あなたはお金と多くの時間を費やしてDBを改善したり、より速くより安くDBを購入することができます。

3GBメモリスイッチを切り替えて、さらに2GBのメモリを追加することを検討してください。