タグ付けされた質問 「disk-structures」

4
SQL Server 2008インスタンスのRAIDレベルの組み合わせを選択する
1つのIBM 3400サーバーを最初から再構築します。このサーバーは、Windows 2008 R2で実行されているSQL Server 2008インスタンス専用です。 新しいRAID構成を作成します。マシン内部に6つのSCSI 73 GBドライブとIBM ServerRAID 8Kコントローラーがあります。RAIDレベルを設定する良い方法は何でしょうか?コントローラーに2つ、3つ、または1つのフィールドを配置する必要がありますか? 次のいずれかの解決策を検討しています。 すべてのディスクを使用して、RAID 10プールを作成します。 RAID 1eプールに4つのディスクを使用し、それを使用してデータベースデータとOSを格納し、他の2つのディスクをRAID 0プールに使用して、それを使用してデータベースログを格納します。 他のいくつかの組み合わせ。 ストライプユニットサイズが大きいほど良いですか? このサーバーは、複製されたデータベースのサブスクライバーになります。その主なタスクは、レプリケーションエージェントのみが書き込みを行う、レポートとデータの取得です。データベースのサイズは約90 GBです。

1
ブロックサイズについて
私の質問はPostgresを対象としていますが、回答はデータベースの背景から得られたもので十分かもしれません。 私の仮定は正しいですか: ディスクのブロックサイズは固定ですか? RAIDコントローラーは異なるブロックサイズを持つことができますか?1つのRAIDブロックが複数の実ディスクブロックに分割されますか? ファイルシステムには独立したブロックサイズもあり、RAIDブロックサイズに分割されますか? Postgresは固定の8kブロックで動作します。ここでファイルシステムのブロックサイズへのマッピングはどのように行われますか?Postgres 8kブロックはファイルシステムによってバッチ処理されていますか? システムをセットアップするとき、すべてのブロックを8kにするのが最善ですか?または、設定は重要ではありませんか?クラッシュした場合に、いくつかの「間違った」ブロックサイズ設定がデータの整合性を危険にさらす可能性があるかどうかも疑問に思っていましたか?たぶん、Postgres 8kブロックを複数のディスクブロックに分割する必要がある場合はどうでしょうか。 または、何も一緒にバッチ処理されないため、定義されたブロックサイズ間のすべての不一致によってディスク領域が失われますか?

3
SQL Server:システムテーブルのみのファイルグループ?
私たちの企業標準の1つは、ユーザーテーブル/インデックス用に個別のファイルグループ/ファイルを用意することです。これはデフォルトとして設定されているため、CREATE TABLEステートメントを修飾する必要はありません。 だからこんな感じ fileid 1 =システムテーブル、MDF fileid 2 = t-log = LDF fileid 3 =ユーザーのもの= NDF なぜこれが義務付けられたのか、元の正当性を理解するのを手伝ってくれる人はいますか? 私はそれがブードゥー教だと思う状態できれいに来ます。私は間違っていますか...? 編集:インデックス/パーティション/アーカイブを分離するためにファイルグループを使用する方法と、断片的に復元する方法を知っています。この質問は、システムテーブル専用の同じボリューム上の別のファイルグループの使用についてです。

2
TempDBをCPUの数に等しい複数のファイルに分割する
記事「SQL Server tempdbのベストプラクティスパフォーマンスの向上」ではtempdb、コアの数に等しい数のファイルに分割する必要があることを示唆しています。したがって、4つのコアで4つのファイルを取得します。 ファイル数を増やすことで、SQL Serverが一度にディスクにプッシュできる物理I / O操作の数を増やすことができます。SQL ServerがディスクレベルにプッシュダウンできるI / Oが多いほど、データベースの実行が高速になります。標準データベースでは、SQL Serverは必要な大量のデータをメモリにキャッシュできます。tempdbは書き込みの性質が高いため、メモリにキャッシュする前に、データをディスクに書き込む必要があります。 理論的には良さそうに聞こえますが、それは一般的な最適化として本当にそれでいいのでしょうか IOが非常に高い特定のシステムにのみ適用されるものですか?

2
SQLサーバーでこれらのディスクをBI構成用に構成するにはどうすればよいですか?
一定メモリ(32GB)とCPU(4)、2 xディスクアレイを想定すると、次のディスクがあります 2 x 150(10,000) 6 x 150(15,000) これらはすべてローカルディスクです。 私の要件 私のDBは350GBであり、デフォルトの10%増加に設定されています 私のOSとSQL Serverはサーバー2k8R2です(C:ドライブOS +ページ+アプリケーション= 55Gb) ログ要件は約70GBで、デフォルトの10%の増加に設定されており、定期的に切り捨てられます 私のTempDbは現在約12GBで、デフォルトの10%増加に設定されています 私の問題は、TempDBとOSおよびログをどこに配置すべきかを理解しようとしていることです。私の経験は、これら2つの最適な構成では制限されています これはオンライントランザクションシステムではありません。大量のデータの書き込み(新しいデータ+インデックスの再構築/再編成)と、大量のデータの読み取り(約50/50と見積もっています)処理が約13時間あり、その後は静かです。 私の理解では、TEMPDBはログと比較して通常の処理中に頻繁に使用されます。 私の考えは次のとおりです 2 x 150g(15k)RAID 1 = 150g for OS + TempDB 2 x 150g(10k)RAID 1 = 150g(LOGより遅いディスクに注意) 4 x 150g(15k)RAID 5 = 150g(データ用) これは良い考えのように聞こえますか?その後、必要に応じてLog + TempDBを交換できます。 ページングの問題によりTempDBをOSディスクに配置しない、またはデータよりも遅いディスクにログを配置しないなどの基本的なルールに違反していますか? 編集: また、システムにはSSASがあり、エンドユーザーはキューブにのみアクセスします。上記の50%の読み取りは、SSASデータベースの処理にかかる時間に基づいています。

2
SQLディスクセットアップのアドバイス-TempDB、ログDB、データファイルの配置に関する質問
非常にアクティブなデータベースサーバーがあり、その上でさまざまなアプリケーションが実行されています。最も忙しいのは、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> …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.