SQL Server 2000に最適なストレージは何ですか？
https://stackoverflow.com/questions/248327
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
INTEL SS4000-Eストレージのsqlサーバーデータベースファイルにアクセスしたい。 NASストレージです。 SQL Server 2000のストレージとして使用できますか？そうでない場合、最良の解決策は何ですか？
解決
反対することを強くお勧めします。
RAIDミラードライブを使用して、データファイルをサーバー自体にローカルに配置します。理由は2つあります：
- SQL Serverは、最小のワークロードを除くすべてに対して非常に高速に実行されます
- NASへのリンクが切断された場合、SQL Serverの破損ははるかに少なくなります。
NASを使用して、データファイルをホストするのではなく、SQL Serverのバックアップを保存します。データベースのサイズや使用パターンがわからないので、何を持たなければならないのかわかりません。実稼働環境で大きな負荷がかかるデータベースの場合は、最低でも2つの論理ドライブ（データ用、トランザクションログ用）をお勧めします。各論理ドライブは、最速のドライブのRAID 1アレイで構成されます買う。それが過剰な場合は、データベースを2つの物理ドライブ（トランザクションログ用とデータ用）に配置します。それだけでも予算を超えている場合は、データを単一のドライブに入れて、頻繁にバックアップしてください。しかし、シングルドライブまたはNASソリューションを選択した場合、IMOは祈りの力に信頼を置いています（これは悪いことではないかもしれませんが、データベースを設計するときはそれほど効果的ではありません）。
NASはSANと同じものではないことに注意してください（一般的にはデータベースファイルを配置します）。通常、NASは、非常に高い信頼性、高速、高度な管理、および低遅延のために設計されたSAN接続よりもはるかに低速で、帯域幅がはるかに小さくなります。 NASは、ネットワークストレージのコストを削減することに重点を置いています。
他のヒント
私の腸の反応-あなたはNAS上のデータを危険にさらしていると思います。 SQLの期待は、ストレージサブシステムへの継続的な低遅延で中断のないアクセスです。 NASは、ほぼ確実にそれらのものではありません-ローカルストレージまたはSANストレージ（パフォーマンス、単純さ、および優先順位の順）-NASをオフラインファイルストレージ/バックアップ用に残します。
次のKBは、SQLでNASを使用しようとする際に遭遇する制約と問題の一部をリストしています-KBはSQL 7から2005をカバーしていますが、多くの情報はSQL 2008にも適用されます。
localは、ネットワークストレージよりもほとんど常に高速です。
SQLのパフォーマンスは、オブジェクト、ファイル、およびファイルグループの定義方法、およびコンシューマーによるデータの使用方法に依存します。
まあ＆quot; best＆quot;人によって意味が異なりますが、「最高」だと思います。パフォーマンスは、TMS RAMSANまたはSSDのRAIDなどです
大容量HDDのRAIDを使用すると、最高の容量が得られます...
最高の信頼性/データの安全性は、多くのドライブでのミラーリングと定期的なバックアップ（オフサイトが望ましい）で達成されます...
最高の可用性...分からない...多分システムのクローンを作成し、いつでもすぐに使えるホットバックアップを用意している。
最高のセキュリティには暗号化が必要ですが、インターネットに接続されていない限り、マシンへの物理的アクセス（およびそのバックアップ）を主に制限するだけで十分です。
他の回答が指摘しているように、ここではパフォーマンスが低下します。
これらのものは時々I / Oパフォーマンスを改善するためにRAMキャッシュを実装することも言及する価値があります。その場合、この構成を試用する場合、NASはサーバーハードウェアと同じ電源保護/ UPSにある必要がありますそうでなければ、停電の場合に、NASはキャッシュ内のファイルの一部を「緩める」可能性があります。痛い！
機能しますが、専用のファイバー接続SANの方が優れています。
ローカルは通常高速ですが、サイズが制限されており、簡単にスケーリングできません。
私はハードウェアに精通していませんが、最初に共有NASに倉庫を展開しました。これが見つかりました。
定期的にヘッドユニットのリソースを奪い合っていました。処理できる帯域幅しかありませんでした。大量のウェアハウスクエリとデータロードが大きな影響を受けました。
ウェアハウス（データ/インデックス/ログ）に1.5 TBが必要でした（これらの各リソースを個別のLUNセットに追加しました（接続ストレージの場合と同様））。データは10個のディスクにまたがっていました。これにより、あらゆる種類のIOボトルネックが発生しました。より良い解決策は、多数の小さなディスクに1つの大きなパーティションを作成し、データ、インデックス、ログをすべて同じ場所に保存することでした。これは物事をかなりスピードアップしました。
中程度に使用されるOLTPシステムを扱っている場合は、問題ないかもしれませんが、NASは面倒です。
