貧弱な内部データベース-それを交換するか、ハードウェアをチャックしますか？
つまり、社内データベースがあり、通常の種類のものです。クライアント、電話、販売取引、クライアント契約/スキームを管理します。
これは、Access 2000フロントエンドであり、SQL Server 2000Standardバックエンドです。シングルサーバー、デュアルXeon 3.2GHz、2GB RAM、Windows Server 2003は、OS（HT）から見える4つのコアに分散して、一日中約40％のCPU負荷を取得します。
バックエンドデータベースは設計が不十分であり、10年以上にわたって有機的に成長し、熟練していない個人によって維持されています。これは正しく正規化されておらず、明らかな問題のいくつかには、主キーまたはインデックスのない数万行のテーブルが含まれます。これらは、システムの最も頻繁に使用される部分のいくつかのマルチテーブル結合でも頻繁に使用されます（例：全員の2番目のモニターに1日8時間常駐し、数秒ごとに大きな非効率的なクエリを実行するコールマネージャーアプリケーション）。
フロントエンドはそれほど良くはありません。何百ものフォーム、ネストされた保存済みクエリ、VBAコードへの埋め込みSQLの記述が不十分、数十の「癖」などの典型的な混乱であり、変更が加えられるたびに無関係なものが壊れているようです。 「十分に」機能する1つのMDBを決定しましたが、社内にAccessの大物がいないため、変更なしのポリシーが適用されます（また、MDBを採用する予定もありません）。
会社は現在ゆっくりと成長しており、クライアントや通話などの数が増え、同時ユーザーの数もわずかに増えています。最近、パフォーマンスが著しく悪化しています（フォーム間を移動するのを待っている、リストが読み込まれるのを待っているなど）。 ）
Perfmonは言う：
- 1秒あたりのディスク転送数：0〜30、平均4。
- 現在のディスクキューの長さ：約1ホバリング
SQL Serverのプロファイラーは、毎分数十万のクエリを確認します。クライアントのCPU使用率はほぼゼロであり、サーバー側のクエリの実行を待機していることを示しています。私はこのワークロードをDBEngine Tuning Advisorに通し、その提案をテストバックアップに適用しましたが、これは実際には大きな違いはありません。
ちなみに、100MBとギガビットイーサネットがすべて1つのサブネット上にあり、2つのフロアに40ishのユーザーがいます。
質問に。
私が見ているように、この状況を解決/改善するには2つの選択肢があります。
- 廃棄して、特注または一部特注のまったく新しいCRMシステムに置き換えることができます
- ハードウェアをチャックすることで、このシステムの寿命を延ばすことができます。
ソフトウェアを交換するよりも桁違いに少ないコストで、驚異的なパフォーマンス数値を備えたInteli7システムを構築できます。
最終的に新しいシステムが開発されると、このボックスでホストできるため、ハードウェアを無駄にすることはありません。新しいCRMシステムはどんどん延期され、延期され続けています。少なくとも1年はそうなっていません。
この状況についての考えは、特にあなたが自分でここにいた場合は、最もありがたいです。
ありがとう
さて...これは少し前のことですが、ここに結果を記録したいと思いました。
結局、私は別の問題に対処するためにVBAを1行ずつステップスルーしました。そのとき、行セットをフェッチするための一部の呼び出しが20〜30秒以上ブロックされていることに気付きました。
それらを掘り下げてみると、行セットがMSAccessクエリに基づいていることがわかりました。
それは別のAccessクエリからデータを選択することでした。
それは、さらに別のAccessクエリからデータを選択することでした。
これらはすべて、クエリデザイナを使用してドラッグアンドドロップされたように見えました。
私は上位6ダースのユーザーの問題点を調べたところ、間違いなくすべてこれとまったく同じであることがわかりました。
そこで、チェーンクエリのスタックを完全に削除し、それぞれをT-SQLで記述してサーバー上で直接実行できる単一のパススルークエリに置き換えました。
いずれの場合も間違いなく大幅な改善が見られ、誰に対してもクエリを待つ必要がなくなりました。
そして会社を辞めました。それがまだそこにあるかどうかはわかりません...しかし、私はそれを見逃しません。
私はここのみんなに反対するつもりです。それにいくつかのハードウェアをチャックします。安く、速く、簡単で、適切なCRMソリューションを実装するために必要な時間を購入できます。私がこのボードだけでなく、スタックオーバーフローのほぼすべての人に嫌悪感を与えるものを提唱している理由は、私がプロジェクトマネージャー/マネージャーであり、しばらくの間「ビジネス」側にいたからです（ビジネスみことばに対する私の憎しみのために引用符で囲まれています）。ソフトウェアの説明に基づいて、何か他のものを再構築するのに1年近くかかります。ビジネスルール/癖を発見/文書化するだけで、おそらく2か月かかります。また、開発には信じられないほどの費用がかかります。特に、だまされたサーバーのコストと比較した場合。
まさにその理由で、私は実際に会社のために一連のWebアプリをホストしようとしています。内部IT部門は、新しいプラットフォームで再開発したいので、より良いハードウェアに移行することはありません。そのコストは、新しいハードウェアに移動する場合の約3倍のコストです。同社が1年以内に契約を更新しない可能性があることは言うまでもありません。
どちらもする必要はないかもしれません。私の提案は、単にいくつかのインデックス/キーをテーブルに追加することです。
主キーまたはインデックスのない数万行のテーブル。複数テーブルの結合でも頻繁に使用されます
多くのお金や時間を費やす前に、数時間かかり、それらの結合に関係するすべてのテーブルにインデックス（または可能であれば主キー）を追加します...特にwhere句で使用される列の場合。わずか数時間で、パフォーマンスを10倍に簡単に向上させることができます。
ディスクI/Oがないということは、クエリがほとんどRAMから供給されることを意味します。ホットテーブルがRAMに「突然」収まらなくなり、サーバーがディスクの処理を開始した場合は、問題が発生している可能性があります。 2GBまたはRAMは最近ではそれほど多くありませんが、SQL2000の時代にはかなりの大きさでした。アプリケーションが通常操作するデータの量は、あなたが持っているRAMよりも少ないと思います。データファイルの「使用済み」スペースの量を確認することをお勧めします。これにより、最悪の場合、データベースが消費する可能性のあるRAMの量がわかります。 SQL Serverは、必要のないデータをRAMに保持しませんが、どのテーブルがいつ使用されているかを知るのは難しい場合があります。
ハイパースレッディングは、SQLServerで常に役立つとは限りません。オフにすると、パフォーマンスが向上する場合があります。オフとオンを切り替えるには再起動が必要なため、テストは困難です。これは、運用サーバーでは大きな手間です。
「1分間に数十万のクエリ」は、1秒間に数千のクエリに相当します。それはかなり忙しいように聞こえますが、そのトラフィックの多くはAccessによるカーソルフェッチである可能性があります。アクセスは、SQLから結果セットを効率的に取得するのが特に苦手です。 SQL Serverの並列化設定をオフにすると、パフォーマンスが向上する場合があります。
また、ブロッキングを探します。ブロッキングの問題でハードウェアを投入しても、必ずしも期待される劇的な改善が得られるとは限りません。ブロッキングがあまりなく、クエリがディスクではなくRAMによって満たされる場合は、基本的に、プロセッサのうなり声と、メモリチャネル間でデータをプルする機能に依存しています。その場合、より高速なハードウェアが優れた改善をもたらすはずです。 （この問題を乗り越えるために）急いでいてゆっくりと成長している場合は、それで十分かもしれません。
解決策として、ハードウェアの追加は、データベースの改善と同様に拡張性がありません。成長が急増した場合、新しいハードウェアが苦労していることに気付くかもしれません。別の考えは、成功したアプリケーションはユーザーを引き付けるということです。アプリケーションの応答性が向上すると、ユーザーは、レポートの終了を待っている間にコーヒーを飲みに行く必要がある場合よりも、アプリケーションでより多くのレポートなどを実行する可能性が高くなります。
データベーススキーマが本当に悪い場合は、テーブルのインデックスを確認するだけで、パフォーマンスを向上させることができる場合があります。頻繁に照会されることがわかっているテーブルに集中します。プロファイラーを使用して、サーバーに対して実行されているクエリを監視し、大量のデータ（100,000ページなど）を読み取るクエリを探すように指示してから、あまり読み取らないクエリに進むことができます。一部のテーブルにはキーがないということですが。データに自然キーがありますが、制約や一意のインデックスによって強制されていませんか？
テーブルにはクラスター化インデックスがありますか？クラスター化インデックスの欠如は、あらゆる種類の二次的影響を引き起こす可能性があります。
多くの列を持つ非クラスター化インデックスがたくさんありますか？これは、より効果的なインデックス作成戦略を実装するのではなく、多くのカバーインデックスを作成する試みであることがよくあります。 SQL Serverは、クエリ中にその場でカバーするインデックスを効果的に構築できます。そうすることが理にかなっており、非クラスター化インデックスとクラスター化インデックスをサポートしている場合です。
最後に、質問する価値があります。メンテナンス（統計のインデックスの再作成や更新）はテーブルで行われていますか？
これは技術的な質問ではなくビジネス上の質問です。
事業主として：システムは事業にとってどの程度戦略的ですか？戦略性が低いほど、気にかけたり修正したりすることが少なくなり、費やしたお金は、ビジネスを成長させるために他の場所で使用できるお金になります。
コンピューターの人々は私を怖がらせます。彼らは皆、大きな部屋に入り、デザインについて議論し、私に大金を費やしました。システムを動かし続けてください！これがパフォーマンスチューニング（再設計なし）を意味する場合でも、より多くのハードウェアを投入することを意味する場合でも、動作を停止した場合にのみ優先されます。
ITコンサルタントとして：システムはレガシーであり、運用コストが隠れています。お客様に最適なシステムを設計できます。このシステムは、将来の成長と戦略的優位性のためのプラットフォームを拡張および提供します。ここに署名すると、すべての夢が実現します。
IT従業員として：私はここでスーパーヒーローになり、このことから地獄を最適化することによって差し迫った災害を回避することによって会社を救うことができます！私が会社を何千人も救ったので、私のマネージャーは私に贈り物と賞賛を浴びせてくれます。
私は両方を行うと言います。
今あなたが言ったCPUは40％くらいですか？あなたはまだユーザーの不満を（たくさん）していますか？そうでない場合は、まだ呼吸の余地があります。しばらくの間は、メモリを増やすだけで十分かもしれません。
行く方法についての質問、あなたは社内のソフトウェア開発者がいますか？答えが「いいえ」の場合は、やり直そうとしないでください。あなたは今いる場所に正確に行き着くでしょう。
あなたが社内の開発者を持っていると仮定すると、あなたの社内の開発者はプロジェクトを適切に行う能力を持っていますか？私は、基本的に顧客のプロジェクトであるかのように、完全に、適切に（相対的な）タイムラインを仕様化して話している。そうでない場合は、気にしないでください。そうしないと、現在の場所に戻ってしまいます。
企業が彼ら自身のクライアントでもあることを認め、内部プロジェクトに同じリソースを提供する必要があるまで、あなたは今いる場所に正確に行き着くでしょう。そこに行って、それをして、Tシャツのドレッサー全体を手に入れました。
したがって、適切に実行できない場合は、2つの選択肢があり、すぐに使用できるターンキーがあります。これは、購入したシステムの型に合わせる必要があるため、スタッフは嫌いです。または、カスタマイズ可能であり、プロジェクトのカスタマイズに時間を費やす必要があります。
またはあなたが持っているものをリファクタリングします。新しいものが入ってきたとき、人々はすべて同じ完全な機能を期待することを忘れないでください。そのため、他の方法ですべてを一度に実行する必要があります。リファクタリングすると、それがどのように機能するかを理解する機会があり、アドホックな変更ではなく、多くの小さなサブプロジェクトに計画します。
システムを見なくても、バックエンドでできる限り正規化して、SQLの多くをストアドプロシージャに移動することを考えているでしょう。次に、C＃フォームまたはWebアプリから新しいフロントエンドを構築します。ビジネスロジックとSQLをフロントエンドから取り除くことができれば、後でやり直すのが簡単になります。小さなプロジェクトに対して行っていることを維持することで、いつでもそれが脇に追いやられたり停止したりした場合に、使用される進歩を遂げることができます。
ここにはすでにいくつかの良い回答がありますが、（社内の開発者がいると仮定して）比較的少量の作業が大きな影響を与えることを指摘するかもしれません-主キーを追加します（すべてのクエリを次のように変更する必要はありません）それらを使用してください）、使用するフィールドにインデックスを追加し、クエリを少し調整すると、絶対に大幅な増加が見られます。 RAM今すぐ購入して、修正に必要な時間とヘッドルームを購入してから、作業に取り掛かってください。
「修正するか捨てる」というテーマで、システムの機能が基本的に機能し、必要なことを実行する場合は、ホイールを書き直さないでください。あなたのユーザーがあなたのニーズに合わないのでそれを使うために体操をしなければならないなら、それに努力を払う意味はありません。
デイトンの回答 に追加するのではなく、別の回答を投稿しています。回答を投稿する最初の数人が考慮していないコストがあるためです。ユーザーの再トレーニングのコストと新しいソフトウェアプログラムに適合するようにビジネス手順を変更します。そうでなければ、彼が言ったこと。
企業が独自のソフトウェアを開発する主な理由の1つは、市場に出回っているものと一致しないビジネス手順を持っていることです。これは素晴らしいことです。企業の個々のビジネス手順は、企業がテーブルにもたらす価値の重要な部分であり、企業が他の市場に対して持つ競争上の優位性です。ソフトウェアを一般的なものに置き換えるには、従業員を再トレーニングして競争上の優位性を犠牲にする必要があります。そうでない場合は、ビジネスプロセスに合わせてソリューションをカスタマイズする必要があります。どちらも費用と時間がかかります。ビジネスコンサルタントとして、またシステム管理者として、私はこれらのコストが中小企業を自力で殺すのを見てきました。
あなたの声明から、あなたはほとんどプロセッサ/ソフトウェアに縛られているように見えます。私は2つのことをします-特に現在それらを使用していない列に（制限内で）インデックスを追加します。そして、私はあなたがそれでできる最速のプロセッサのセットをチャックするでしょう、なぜならあなたがピーク時にそれほど多くのドライブ読み取りを持っていないならそれがあなたがバインドしている場所のように見えるからです。
（また、サーバーエディションを可能な限りアップグレードします。これを導入するまでに、Access2000とSQLServer 2000は10年前になります。これは、コンピューターの年では古いものです！）
これには、完全な再構築（再構築）が必要です。システムをゼロから再構築します。これにより、長期的には大幅に節約できます（メンテナンスのオーバーヘッドコスト）。それまでの間、ハードウェアをチャックしてください。この質問は、技術的な質問というよりも「ビジネスケース」だと思います。技術的には、答えは完全に「もっと力を入れて」です。ビジネス面では、新しいシステムを構築してください！
技術的な答え：
主キーとインデックス作成を徹底的に確認する必要があることを示す提案がたくさんあります。 Accessは、各テーブルでSQL Server TimeStamp（別名RowVersion列）を使用することも非常に気に入っています。これにより、レコードの更新に関してAccessがレコードが変更されたかどうかを判断するために費やす時間が大幅に短縮されます。
ビジネスの答え：
新しいCRMソリューションは、人々をトレーニングするための多くの作業であり、ビジネス要件に正確に適合するシステムになってしまうことは決してありません。
SQL Serverにも精通している優れたアクセス担当者を見つけて、テーブルの正規化とユーザーの問題点の修正に3か月から6か月を費やしてもらいます。静かな場所にいて、アクセスしやすい場所にいる場合でも、ユーザーがユーザーとしてセムフロアで作業するようにします。あまりアクセスしにくいですが。開発者は中断が好きではありません。 S
あなたの説明を考えると、まったく新しいオーダーメイドのシステムを作成することは無意味です-あなたはあなたが始めたところからすぐに終わるでしょう、あるいはおそらくあなたが今よりもさらに悪いことになります。したがって、サードパーティのソリューションを購入するように誰かを説得できない限り、最善の策は、可能な限りリファクタリングし、ハードウェアを投入することです。
2つのことを行う必要があると思います。1）SQLサーバーでのパフォーマンス分析。サーバー側をラグの原因として特定したようです。次に、どのクエリがラグしているのか、そしてその理由を知る必要があります。おそらく、大きなメリットをもたらす最適化するためのホットスポットクエリを見つけることができます。ちなみに、数秒ごとに更新するクライアントがある場合は、更新レートを下げることができるかどうかを確認してください（画面上のリストは本当に5秒ごとに更新する必要がありますか？30で十分ですか？そうでない場合は15はどうですか？ ）。リフレッシュタイマーを増やすなどの馬鹿げたものは、それを回避できれば、オーバーヘッドを大幅に節約できます。
2）より多くのハードウェアを投入します。特にそれに大量のラムを投げます。データベースが完全にRAMに収まるほど多くのメモリが必要です。 OSとソフトウェアのバージョンに注意してください（Windowsのバージョンとそれらが実際にサポートするハードウェアにはかなり多くのルールがあります どうやら ）。より多くのコアが役立つと確信できる場合は、できるだけ多くのCPUとコアを投入してください。
RAMとプロセッサについては言及しましたが、ディスクについては言及していません。MSのSQL Serverを扱ってからほぼ10年が経過していることは認めますが、他のデータベースと同じようにディスクにバインドされています。データベース、すべてをメモリに収めることができない場合。
私はおそらく最初にマシンをできるだけ多くのRAMで満たそうとします-次に、ログがテーブルに使用されていないディスクに書き込まれていることを確認しますまたはインデックス。次に、同じスピンドルにインデックスを持つテーブルがないことを確認しようとします。
その後、データベースレベルの調整について心配しますが、それでは、物を壊したりクエリを悪化させたりしないように、テストと最適化の目標を定義する必要があります。主キーはテストデータベースであまり利点を示さないと述べましたが、テスト方法を確認する必要があります。主キーを使用すると、一部のデータベース（MS SQLがそれらの1つであるかどうかは不明）でレコードレベルのロックを使用できます、テーブルレベルのロックではなく、少数のユーザーのみでのテストでは表示されない可能性のある競合を減らすことができます。
まず、Kyle Hodgsonに同意し、PKを追加します。それは安価で（時間のみ）、クエリが後押しされる可能性があります。最も醜いクエリのトップ10の結合列のインデックスはどうですか？テーブルスキャンはどこにありますか？
次に、データベース内のデータをトリミングするのはどうですか？クエリで実際に必要な行よりも多くの行が返されていますか？また、カイルのRAM（さらに2 GB）の提案にも同意します。
将来を計画する際に、暫定的に提案する内容について、これらすべてをあなたの記事（Joseph Kern）に入れてください。現在のCRMアプリがクレーターになっていて利用できない場合、組織に何が起こるかを管理者とユーザーに尋ねます。おそらくそれは彼らに未来について考えさせるのに役立つでしょう。
ハードウェアを入手してください！
Xeon 55xxシリーズのチップを購入した場合、現時点ではスズが非常に安いだけでなく、投げることができるものなら何でも悲鳴を上げるでしょう。
それは単なるリスク/報酬のことです-あなたはDBをより良くするためにお金と多くの時間を費やすか、そこであなたの道をより速くそしてより安く買うことができます。
GBメモリ スイッチを切り替えて、さらに2GBのメモリを追加することを検討してください。
与えられた情報に基づいて、私はシステムを交換します。できれば、他のシステムとの柔軟な統合を可能にする別のCRMを使用してください（これにより、 ERP IS が損なわれます）。
最も難しい部分は、管理者とユーザーにアップグレードが必要になるように説得することです。
管理
技術的な問題、パフォーマンスの低下、ビザンチンの失敗の恐れなどについて懸念を表明します。次に、2つの代替CRMを提示します。ビジネス統合、ビジネスの全体的なERP戦略、そして最も重要なこととして、これが従業員の生産性と収益性を高める方法について話します。ユースケーススタディ。これを15分以内にします（必要な場合を除く）詳細）次に、ユーザーを説得する必要があります。
ユーザー
トレーニング計画（ベンダーが提供する可能性がある[および管理者が承認する必要がある]）、ユーザーの上位20％（パワーユーザー、問題を引き起こすユーザー）との継続的なコミュニケーション、およびシステムを100％運用し続けるための確固たる取り組み最初の月（最初の月は新しいISを作成または中断します）。
そこにはたくさんのCRM製品があります、あなたのビジネスニーズに最も適したものを選んでください。
それでハードウェアを投げると、システムが非常に哀れになり、最新の最高のハードウェアでさえうまく動作しなくなるまで、より貧弱な設計と管理を助長するだけです。より良い実装を検討する時が来ました。まず、何が必要かを分析します。要件を完全に理解して初めて、要件を実装するための最良の方法を検討し始めることができます。要件を理解したら、所有しているものを変更する方が良いか、費用効果が高いか、またはまったく異なるものを使用して最初から始めるかを検討し始めます。
長期的には、データベースをやり直すのがおそらく最善でしょう。より多くのハードウェアを投入することでしばらくの間問題は解決しますが、それを使い続けると、しばらくするとより多くのハードウェアを投入する必要があります。
通常、パフォーマンスの問題がある場合は、ハードディスク/ RAIDのI/Oボトルネック、データベースのシャーディングなどを確認しますが、シャーディングなどの場合は、データベースを適切に設計して、それを利用する必要があります。それの音から、あなたのアプリケーションは決してスケーリングすることができません。
長期的には、データベースとフロントエンドソフトウェアをやり直して、現在のビジネスニーズをより適切に反映することで、長期的にはより効果的に機能します。あなたのユーザーはあなたに感謝するでしょう、あなたのハードウェアは長持ちします、そしてそれは問題で巨大なハードウェアを投げるよりも長い目で見ればはるかに多くのお金を節約するでしょう。