タグ付けされた質問 「san」

通常、毎週の完全バックアップは約35分で完了し、毎日の差分バックアップは約5分で完了します。火曜日以来、デイリーは完了するのにほぼ4時間かかりました。偶然にも、新しいSAN /ディスク構成を取得した直後にこれが起こり始めました。 サーバーは運用環境で実行されており、全体的な問題はなく、スムーズに実行されていることに注意してください-主にバックアップパフォーマンスに現れるIOの問題を除きます。 バックアップ中にdm_exec_requestsを見ると、バックアップは常にASYNC_IO_COMPLETIONで待機しています。ああ、ディスクの競合があります！ ただし、MDF（ログはローカルディスクに保存されます）もバックアップドライブにもアクティビティはありません（IOPS〜= 0-十分なメモリがあります）。ディスクキューの長さも〜= 0です。CPUは2〜3％程度動きますが、問題はありません。 SANはDell MD3220i、6x10k SASドライブで構成されるLUNです。サーバーは2つの物理パスを介してSANに接続され、それぞれがSANへの冗長接続を備えた個別のスイッチを通過します。合計4つのパスで、そのうち2つは常にアクティブです。タスクマネージャーを使用して両方の接続がアクティブであることを確認できます。負荷を完全に均等に分割します。両方の接続が1G全二重を実行しています。 以前はジャンボフレームを使用していましたが、ここでは問題を除外するために無効にしました-変更はありません。他のLUNに接続されている別のサーバー（同じOS + config、2008 R2）があり、問題はありません。ただし、SQL Serverを実行するのではなく、その上でCIFSを共有するだけです。ただし、そのLUNの優先パスの1つは、問題のあるLUNと同じSANコントローラー上にあるため、それも除外しました。 いくつかのSQLIOテスト（10Gテストファイル）を実行すると、問題があるにもかかわらずIOが適切であることが示されているようです。 sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt IOs/sec: 3582.20 MBs/sec: 27.98 Min_Latency(ms): 0 Avg_Latency(ms): 3 Max_Latency(ms): 98 histogram: ms: 0 1 2 3 4 5 6 7 8 9 10 11 …

31 sql-server-2008-r2  backup  network  san 

SQLサーバーはSAN上にあります。多数のOLTPデータベースが含まれており、一部には1m以上のレコードを含むいくつかのテーブルがあります。 私たちは、実行されているオラHallengrenの索引メンテナンススクリプトを毎週、そしてそれは、数時間ごとに実行されます。断片化のしきい値に基づいて、スクリプトはインデックスを再編成または再インデックス化します。インデックスの再作成中にログファイルが膨大になり、ログ配布中に帯域幅が過剰に消費されることが確認されています。 次に、ブレント・オザールからの記事があります。彼はSQLインデックスについて心配するのをやめると言っています。 ハードドライブは、同時にドライブリクエストを行っている他のサーバーと共有されるため、ドライブは常にデータを取得するためにあらゆる場所でジャンプします。インデックスの最適化は、無意味な忙しい作業です。 この質問をググリングすると、さまざまな意見につながりますが、ほとんどが短すぎるか弱すぎると思われる議論でサポートされています。暫定的な計画では、メンテナンススクリプトの断片化のしきい値を調整して、インデックスの再作成よりもはるかに頻繁に再編成するようにします。 最終的な判定は何ですか？毎週のメンテナンスジョブの実行に伴う負担を考慮して、SANでSQLインデックスを最適化することは価値がありますか？

16 sql-server  sql-server-2008-r2  index  database-recommendation  san 

SQL ServerをSANに接続しています。新しいストレージベンダーは、すべてのLUNがディスクアレイ全体（RAID5）にまたがることを推奨しています。通常、SAN管理者に3つの個別のLUN（データ、ログ、TempDB）を要求しますが、新しいベンダーの推奨を考えると、個別のLUNを作成する意味はありますか？それともすべてのディスクにまたがるので、すべてが1つのLUNにある場合、同じパフォーマンスが得られますか？ ここでは素晴らしい記事ですが、私の正確な状況には完全には対応していません：http : //www.brentozar.com/archive/2008/08/sql-server-on-a-san-dedicated-or-shared-drives/

8 sql-server  performance  storage  san 

非常にアクティブなデータベースサーバーがあり、その上でさまざまなアプリケーションが実行されています。最も忙しいのは、1日中ドキュメントスキャンとワークフロー処理を行うLaserficheデータベース（平均2800バッチリクエスト/秒）と、メールをルーティングするブラックベリーサーバーアプリです。他にも約25の小さなアプリケーションデータベースがあります。 私たちは政府機関なので、1つのDBサーバーライセンスの予算しか与えられていません。 最近、ディスク競合の問題に対処するためにSANが提供されました。 現在、TempDBは独自のディスク（RAID 1ミラーペア）で実行されており、トランザクションログとデータファイルをSANに移動しています。トランザクションログは1つの論理的な場所に配置され、データファイルは別の場所に配置されました。物理的には同じアレイですが、RAID 1 + 0構成の合計14個のスピンドル（ディスク）で構成されるアレイです。 かなり頑丈なSAN-そして物事ははるかによく実行されています。キューの長さが半分になりました。 ちょうど今日、私たちは別のオプションも与えられました。現在ファイルサーバーで必要な場合は、4つのディスクアレイを使用することもできます。MDFとLDFを2つの別々のアレイに配置することをお勧めしますが、この状況でこれを行う唯一の方法は、データログまたはトランザクションログをSANからRAID 5として構成された4ディスクアレイに移動することです。現在、別の論理ボリュームにありますが、同じ物理アレイを共有しています。 ヒップからの撮影は、MDFとLDFを14スピンドルRAID 1 + 0アレイに一緒に配置するのが、4スピンドルRAID 5アレイに配置するのと同じくらい良いと思います。しかし、ディスクロジックの専門家であるかどうかは尋ねられません。どちらのオプションも基本的に同一の15k SASディスクを使用しています。つまり、各スピンドルは基本的に同一です。 つまり、本質的には問題です。raid 1 + 0として構成された単一の14スピンドルアレイのMDF / LDFは、データまたはログを独自の4スピンドルraid 5アレイに移動することにより、大幅なマージンで（またはまったく）改善されますか？ 考え？ 更新された情報： また、ログボリュームの現在の平均キュー長は、ほぼ一貫して0.55前後であることに注意してください。データボリュームの平均キュー長が0.01を超えることはほとんどありません（通常は0.00） sys.dm_io_virtual_file_statsクエリ結果： <table> <tr> <td>database id</td> <td>Volume</td> <td>io_stall_read_ms</td> <td>num_of_reads</td> <td>avg_read_stall_ms</td> <td>io_stall_write_ms</td> <td>num_of_writes</td> <td>avg_write_stall_ms</td> <td>io_stalls</td> <td>total_io</td> <td>avg_io_stall_ms</td> </tr> <tr> <td>25</td> <td>h</td> <td>175086</td> <td>1411</td> <td>124</td> <td>69</td> …

8 sql-server-2008  disk-structures  san