INTELSS4000-Eストレージ内のSQLサーバーデータベースファイルにアクセスしたい。それはNASストレージです。SQL Server 2000のストレージとして使用することは可能でしょうか？そうでない場合、最善の解決策は何ですか？
6 に答える
1
私はそれに対して強くお勧めします。
RAIDミラードライブを使用して、データファイルをサーバー自体にローカルに配置します。理由は2つあります。
- SQL Serverは、最小のワークロードを除くすべてのワークロードではるかに高速に実行されます
- NASへのリンクが壊れた場合に備えて、SQLServerが破損する可能性ははるかに低くなります。
NASを使用して、データファイルをホストするのではなく、SQLServerのバックアップを保存します。データベースのサイズや使用パターンがわからないため、必要なものをお伝えすることはできません。少なくとも、実稼働環境で大きな負荷がかかるデータベースの場合は、2つの論理ドライブ（1つはデータ用、もう1つはトランザクションログ用）をお勧めします。各ドライブは、最速のドライブのRAID1アレイで構成されています。買う。それがやり過ぎの場合は、データベースを2つの物理ドライブ（1つはトランザクションログ用、もう1つはデータ用）に配置します。それでも予算を超えている場合は、データを1つのドライブに置き、頻繁にバックアップします。しかし、シングルドライブまたはNASソリューションを選択した場合、IMOは祈りの力に信頼を置いています（これは悪いことではないかもしれませんが、それは悪いことではありません」
NASはSAN（通常、データベースファイルを配置するSAN）と同じものではないことに注意してください。NASは通常、非常に高い信頼性、高速、高度な管理、および低遅延を実現するように設計されたSAN接続よりもはるかに低速で、帯域幅もはるかに狭くなっています。NASは、ネットワークストレージのコストを削減することを目的としています。
于 2008-10-30T03:45:00.150 に答える
1
私の腸の反応-NAS上のデータを危険にさらしているのは気が狂っていると思います。SQLの期待は、ストレージサブシステムへの継続的な低遅延の中断のないアクセスです。NASは、ほぼ確実に、ローカルストレージまたはSANストレージ（パフォーマンス、シンプルさ、したがって優先度の順に）のいずれでもありません。NASをオフラインファイルストレージ/バックアップ用に残します。
次のKBは、SQLでNASを使用しようとすると発生する制約と問題の一部を示しています。KBはSQL 7から2005までをカバーしていますが、多くの情報はSQL2008にも当てはまります。
于 2008-10-30T03:56:20.720 に答える
0
「最高」とは人によって意味が異なりますが、「最高」のパフォーマンスはTMSRAMSANまたはSSDのRAIDなどだと思います。
最高の容量は、大型HDDのRAIDで達成されます...
最高の信頼性/データの安全性は、多くのドライブにわたるミラーリングと定期的なバックアップ（できればオフサイト）で達成されます...
最高の可用性...わかりません...システムのクローンを作成し、いつでもホットバックアップを実行できるようにしてください。
最高のセキュリティには暗号化が必要ですが、インターネットに接続されていない限り、主にマシン（およびそのバックアップ）への物理的なアクセスを制限するだけで十分です。
于 2008-10-30T03:54:28.523 に答える
0
ローカルは、ほとんどの場合、ネットワークストレージよりも高速です。
SQLのパフォーマンスは、オブジェクト、ファイル、およびファイルグループがどのように定義されているか、およびコンシューマーがデータをどのように使用するかによって異なります。
于 2008-10-29T20:42:46.180 に答える
0
他の回答が指摘しているように、ここではパフォーマンスが低下します。
また、I/O パフォーマンスを向上させるために RAM キャッシュを実装する場合があることにも言及する価値があります。その場合、この構成を試してみると、NAS はサーバー ハードウェアと同じ電源保護/UPS にある必要があります。停電の場合、NAS はキャッシュ内のファイルの一部を「失う」可能性があります。ああ！
于 2008-10-30T04:50:33.140 に答える
-1
それは機能しますが、専用のファイバー接続 SAN の方が優れています。
通常、ローカルの方が高速ですが、サイズが制限されており、簡単にスケーリングできません。
私はハードウェアに詳しくありませんが、最初は共有 NAS に倉庫を展開しました。これが私たちが見つけたものです。
私たちは定期的にヘッド ユニットのリソースをめぐって競合していました。処理できる帯域幅は限られていました。大規模なウェアハウス クエリとデータ ロードが深刻な影響を受けました。
ウェアハウス (データ/インデックス/ログ) には 1.5 TB が必要だったので、これらの各リソースを個別の LUN セットに配置しました (接続ストレージの場合と同様)。データはわずか 10 個のディスクにまたがっていました。これにより、あらゆる種類の IO ボトルネックに遭遇しました。より良い解決策は、多数の小さなディスクに 1 つの大きなパーティションを作成し、データ、インデックス、およびログをすべて同じ場所に格納することでした。これにより、処理が大幅に高速化されました。
適度に使用されている OLTP システムを扱っている場合は問題ないかもしれませんが、NAS は面倒な場合があります。
于 2008-10-29T20:57:42.063 に答える