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

Postgres 9.2データベースを最適化して、日付制限のあるクエリを高速化しようとしています。 私はtimestamp列を持っていますが、たいていはいつか尋ねているのでtimestamp、date解析するためのインデックスを作成しました： CREATE INDEX foo_my_timestamp_idx ON foo USING btree ((my_timestamp::date) DESC); 次に、パフォーマンスを向上させるために、CLUSTER foo上記のインデックスを使用してテーブルを作成します。 CLUSTER foo USING foo_my_timestamp_idx; SQL-CLUSTERのマニュアルによると、テーブル インデックス情報に基づいて物理的に並べ替えられます テーブルのPKを使用する他のクエリのパフォーマンスに影響があるかどうかを知ります（としましょうid_foo）。欠点はありますか？

8 postgresql  index-tuning  postgresql-9.2  postgresql-performance  storage 

私が理解しているように、SQL Server（または実際には他のRDBMS）のクエリオプティマイザーは、データベースの下のストレージのパフォーマンスを認識せず、すべてのストレージのコストが等しいかのように判断します。それは正確ですか、または考慮に入れられているストレージパフォーマンスの知識はありますか？ 完全に不自然な例で、テーブルの行が瞬時のアクセス時間でSANのSSDドライブに保存されているとしましょう。インデックスは極端に過負荷のSASドライブに保存されているため、ディスクが飽和状態になり、ディスクキューが一定になります。RDBMSが実行プランを生成するとき、インデックス操作よりもテーブルスキャンを優先する可能性が高いですか（または、SASディスクでのIOが少ないため、カバーするインデックスとは対照的に、スキニーインデックスおよび関連するテーブルルックアップ）。 その答えは確かなものだと思いますが、「オプティマイザが賢くなったり、ディスクパフォ​​ーマンスを認識したりする可能性はない」と思いますが、そこにいる誰かが確かに知っているかどうかを確認したかっただけです。SQL Serverを使用していますが、どのデータベースシステムにも興味があります。

8 execution-plan  storage 

当社のSQL Server 2005データベースのデータファイルは、Microsoft Windows 2003のディスクデフラグツールが99％断片化していると報告する別の物理ドライブにあります。 土曜日の午前3時にこのドライブを最適化するタスクをスケジュールしました。ジョブは40分後に完了し、明らかなエラーはありませんでした。ただし、ドライブは非常に断片化されたままです。 デフラグする前にSQL Serverサービスを停止する必要がありますか？ 環境 コンテキストの要求ごと：4 GBのRAMを搭載した2007年頃のDell PowerEdge 2950ハードウェアで32ビットWindows Server 2003（SP2）を実行するMicrosoft SQL Server 2005インスタンス（9.00.5324.00）があります。PowerEdge 2950には、2つの68GB仮想ディスクを作成するためにRAID-1として構成された4つの68GBドライブがあります。（1）C（ブートおよびOS）およびD（ページファイル、その他のその他のデータ）。（2）E（SQLデータ）。私の知る限り、ITスタッフはこれらのドライブのいずれも最適化したことがありません...ディスクデフラグツールは、66％（C）、77％（D）、および99％（E）のファイルの断片化を報告します。パフォーマンスモニターは、次の平均結果を報告します。「ページングファイル：使用率％」= 〜6.8％ ; "SQL Server：バッファマネージャ-ページの平均余命" = 20秒 ; および「PhysicalDisk：平均ディスク秒/書き込み、ドライブE」= 300〜1。数か月後には非常に必要なハードウェアとSQL Serverのアップグレード（つまり、新しいハードウェア、64ビットWindows Server 2012、64ビットSQL Server 2012、12GB RAM）が必要ですが、ユーザーのパフォーマンス、問題をできるだけ軽減したい。したがって、ファイルのデフラグを考えることは、メインのSQLデータドライブであるドライブEに役立つ可能性があります。 余談ですが、先週、2台の故障したドライブを引き出してアレイを再構築しました。サーバーを維持するために別のITチームと契約しているため、機器に直接アクセスすることはできません...私たちの組織はサービスの料金を支払うだけです。 定期的にスケジュールされたメンテナンスウィンドウ（毎週）中のダウンタイムと、必要に応じて夜間の帯域外ダウンタイムを用意できます。

8 sql-server  storage  maintenance 

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 

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

8 sql-server  sql-server-2008-r2  storage  tempdb  disk-structures