7

私は職場で非常に特定のパフォーマンスの問題を抱えています!

私たちが使用しているシステムには、現在のワークフロー プロセスに関する情報を保持するテーブルがあります。フィールドの 1 つは、プロセスに関するメタデータを含むスプレッドシートを保持します (理由は聞かないでください!! 変更できません!!)

問題は、このスプレッドシートが SQL Server 2005 (SQL 2000 互換のデータベース セット内) の IMAGE フィールドに格納されていることです。

このテーブルには現在 22,000 行以上あり、次のような単純なクエリもあります。

SELECT TOP 100 *
  FROM OFFENDING_TABLE

Query Analyser でデータを取得するのに 30 秒かかります。

SQL 2005 への互換性を更新することを考えています (アプリがそれを処理できると知らされたら)。

私が考えている 2 番目のことは、列のデータ型を変更することですが、varbinary(max)これを行うとアプリケーションに影響するかどうかはわかりません。

私が検討しているもう 1 つのことは、現在のようsp_tableoptionに を に設定するために使用するlarge value types out of rowことですが、これを行うとパフォーマンスが向上するかどうかについては情報がありません。10

そのようなシナリオでパフォーマンスを向上させる方法を知っている人はいますか?

明確にするために編集

私の問題は、アプリケーションが SQL Server に何を要求するかを制御できないことです。また、いくつかのリフレクションを実行し (アプリは .NET 1.1 Web サイトです)、問題のあるフィールドを、私にはわからない内部的なものに使用します。それは何ですか。

このテーブルの全体的なパフォーマンスを改善する必要があります。

4

4 に答える 4

4

I'd recommend you look into the offending table layout health:

select * from sys.dm_db_index_physical_stats(
       db_id(), object_id('offending_table'), null, null, detailed);

Things too look for are avg_fragmentation_in_percent, page_count, avg_page_space_used_in_percent, record_count and ghost_record_count. Cues like high fragmentation, or a high number of ghost records, or a low page used percent indicate problems and things can be improved quite a bit just by rebuilding the index (ie. the table) from scratch:

ALTER INDEX ALL ON offending_table REBUILD;

I'm saying this considering that you cannot change the table nor the app. If you'd be able to change the table and the app, the advice you already got is good advice (don't use '*', dont' select w/o a condition, use the newer varbinary(max) type etc etc).

I'd also look into the average page lifetime in performance counters to understand if the system is memory starved. From your description of the symptomps the system looks IO bound which leads me to think there is little page caching going on, and more RAM could help, as well as a faster IO subsytem. On a SQL 2008 system I would also suggest turning page compression on, but on 2005 you can't.
And, just to be sure, make sure the queries are not blocked by contention from the app itself, ie. the query doesn't spend 90% of that 30 seconds waiting for a row lock. Look at sys.dm_exec_requests while the query is running, see the wait_time, wait_type and wait_resource. Is it PAGEIOLATCH_XX? Or is it a lock? Also, how is the sys.dm_os_wait_stats in your server, what are the top wait reasons?

于 2010-02-12T18:14:01.483 に答える
2

まず第一に、レポートを作成するかどうかにかかわらず、運用コードを実行しないでください。SELECT *

次の 3 つの基本的な選択肢があります。

  • 常に必要でない場合は、その Blob フィールドを別のテーブルに移動します。スキーマを変更できないと述べているため、おそらく実用的ではありません

  • SELECT本当に必要なフィールドのみを選択し、blob フィールドを省略するようにステートメントに注意してください。

  • 句を含めるようにクエリを制限できるかどうかを確認WHEREし、テーブルに適切なインデックスを追加するなどしてクエリ プランを最適化する方法を見つけます (可能な場合)。

「これを高速化する」という魔法のスイッチはありませんが、クエリを最適化したり、テーブル レイアウトを最適化したりできます。どちらも役立ちます。テーブルのレイアウトも、インデックスの追加も、クエリの変更も、何も変更できない場合は、何も最適化するのに苦労することになると思います....

フィールドを VARBINARY(MAX) に変更するだけでは何も変わりません。データ型を変更しただけではパフォーマンスの向上は期待できません。

于 2010-02-12T17:26:38.517 に答える
1

簡単な答えは、返されたフィールドに問題のある画像フィールドが含まれていない場合、つまり SELECT * がない場合にのみ、複数の行に対して SELECT を実行することです。画像フィールドの値が必要な場合は、ケースバイケースで取得してください。

于 2010-02-12T17:10:18.573 に答える
0

行オプションから大きな値の型を設定すると、パフォーマンスが確実に向上します。行サイズが大幅に小さくなり、SQL Server がテーブルを処理するために実行できる物理読み取りが大幅に少なくなります。

于 2010-02-12T17:12:04.673 に答える