各クライアントが独自のデータベースを持っているデュアルWeb /内部トランザクションアプリケーションをロールアウトしようとしています。各データベースは非常に小さく、それぞれ50MB未満なので、完全なSQL Serverの代わりにSQL Express 2008を使用するのが理にかなっているのではないかと考えていました。
これは、サーバー全体にディスクI/Oを分散する一方で、大規模な$$$を節約できるという利点があるようです(小型の15Kドライブと使用されるデュアルコアサーバーはどちらも安価なので)。ある時点で必要なサーバーが多すぎる場合は、SQL Serverにアップグレードできますが、内部ユーザーが数十人いるため、これは現在(特にフェールオーバーボックスが必要なため)高すぎるようです。
1 GBのメモリとシングルプロセッサでの4コアの使用は、データベースサイズが小さいことを考えると、それほど制限的ではありません。同時ユーザー数が200を超えることは決してなく、ほとんどの操作はトランザクション処理が多くなります(RAM/CPUの負荷よりも高速ディスクを大量に使用するようです)。
SQL Server Standardの利点のうち、最初に$ 5-20Kの追加投資を正当化できるものがないのですか?
SQLサーバーの他のエディションでは、SQLエージェントなどの機能が利用できるため、データベースのメンテナンスやその他のジョブをスケジュールできます。
データベースがExpressエディションの制限に適合できる限り、問題はありません。
SQLサーバーは多くのRAMを好みます。より良いです。 SQL Serverはデータをキャッシュにロードできないため、ディスクに追加の負荷がかかります。 SQL ServerのWebエディションまたはWorkstationエディションをご覧ください。これらのエディションはExpressエディションよりも制限が高くなっていますが、Standardエディションよりもコストが低くなっています。
Expressエディションから始めた場合は、ライセンスを購入した後でいつでもStandardエディションにアップグレードできます。
Expressエディションで発生したいくつかの生産上の問題と回避策:
スケジュールバックアップ
[〜#〜] ssis [〜#〜]
プロファイリング
SQL Serverライセンスを読んだ場合、パッシブサーバーがフェイルオーバーにのみ使用され、最初のサーバーに障害が発生するまでクエリを提供しない場合、パッシブサーバーの追加ライセンスを購入する必要はありません。
SQL Server Expressをかなり長い間使用してきましたが、以前のMSDEよりも優れており、200以上の擬似接続がありますが、サイズが2GBのデータベースが1つしかなく、すべてがスムーズです。高価な結合を回避し、適切なインデックス作成を行っていれば、問題は発生しませんでした。現在、SQL Standardを使用していますが、データベースのサイズが4GBを超え、ユーザー数が200〜500未満になるまで、SQL Expressを使用できます。
SQL Server Expressが使用するメモリフットプリントはわずか200 MB未満ですが、Standardエディションは1.5 GBを使用しますが、おそらくStandardエディションは大量のキャッシュを実行するためです。 Expressのクエリは、Standardエディションと比較して数ミリ秒で遅くなります。残念ながら、ExpressエディションはマルチコアCPU(制限された機能)を使用しないため、2コアまたは4コアのどちらを使用していても、あまり役に立ちません。
LuckyLindy-少しの間停止して、SQLエージェントが不要であることを確認することをお勧めします。あなたが書いた:
各クライアントが独自のデータベースを持っているデュアルWeb /内部トランザクションアプリケーションをロールアウトしようとしています。各データベースは非常に小さく、それぞれ50MB未満なので、完全なSQL Serverの代わりにSQL Express 2008を使用するのが理にかなっているのではないかと考えていました。
バックアップの計画は何ですか? SQLエージェントを使用する必要はありませんが、DBAの作業が簡単になります。 T-SQL/SMO/PowerShell /バックアップを実行するスクリプトを記述し、スケジュールされたタスクを使用してsqlcmdまたはPowerShellを介して実行できます。
データベースメンテナンスの計画はどのようになっていますか?時間が経つにつれて、これらのデータベースを最適化して整合性をチェックする必要があります。 Standard Editionには、これを実現するためのあらゆる種類の利点がありますが、Expressでは、再び(スクリプトとスケジュールされたタスクで)作業する必要があります。
サーバーで問題が発生した場合、どのように通知されますか?エージェントはここでアラートを使用して、ログがいっぱいになったり、ディスクがいっぱいになったりしたときに通知します。
これらは、SQL ServerのDBAタイプの重要なタスクです。社内アプリでExpressを実行することは1つですが、クライアント向けにホストしていることを私たちに伝え始めると、私は心配になります:)
パート2これは、ローンチ時と1年後の両方で、これをサポートする予定のクライアント数を尋ねています。 「100クライアント」と言った場合、100 MBの50MBデータベースはExpressでは不十分です-十分なメモリがありません。一体-あなたが持っているデルタの量に応じて、あなたは15 DBで最大になるかもしれません、私は知りません。
同時ユーザー数が200を超えることは決してなく、ほとんどの操作はトランザクション処理が多くなります(RAM/CPUの負荷よりも高速ディスクを大量に使用するようです)。
INSERTなどのトランザクション操作は引き続きメモリに書き込まれるため、必要なメモリサポートが少なくなることを期待しないでください。実際、何回のINSERTを実行するかによっては、その数のユーザーの場合よりも多くのメモリが必要になる場合があります。人々が実際に使用しないであろう大量のデータをロードしている場合、それでもメモリを占有します。 「ユーザーが頻繁に照会しているデータ」と「ユーザーがロードしているため、しばらくの間誰も照会しないデータ」の間で競合問題が発生する場合があります。 SQLは、ユーザーがメモリ内でより頻繁にクエリするデータをより長く保持することで私たちを保護しますが、それでも競合が発生します。
この時点で、私はとりとめなく笑っています。また、200人の同時ユーザーは、Expressの場合も私と一緒にはなりません。 64kが平均接続メモリ要件であるとしましょう。アプリはいくつの接続を作成しますか?接続プーリングを使用しますか?
概して、あなたの説明を読んだときの私の直感は、「いいえ-Express Editionは十分に強力ではない」と言っています。そして、私はWorkgroup Editionが嫌いです-それは悪いことだと思います-したがって、Standardは私には正しいようです。
無料のDBMS(MySQL、PostgreSQL ...)の使用を検討しましたか?ライセンスの問題を軽減できますか?
それが選択肢でない場合、SQL Server Expressは良い解決策のようです。
それは確かに重要な生産アプリケーションに使用できます。毎日数百万のトランザクションを処理するために個別のSQL Server Expressインスタンスがインストールされている1500を超える医療クリニックで使用しています。次のいずれかを使用すると、SQL Serverエージェントの欠点を簡単に回避できます。
「本番環境でのSQL Server Expressの使用」に関するMichael Oteyの優れたプレゼンテーション(google it)をご覧ください。