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

SQL ServerのDMVは、データベース管理ビュー[&関数]の総称です。技術的にはすべてDMO(データベース管理オブジェクト)ですが、DMVという用語は今でも広く理解され、ほとんどの人に受け入れられています。

1
キャッシュサイズと予約メモリを計画する
実際の実行計画を含むクエリを実行すると、ルート演算子(SELECT)からキャッシュされた計画サイズが32KBであることが通知されます。 sys.dm_exec_cached_plansとを結合するクエリはsys.dm_os_memory_objects、問題のプランを見て、との値が32768(32KB)であり、キャッシュされたプランのサイズと一致するpages_in_bytesと言いますmax_pages_in_bytes。 私が理解していないのは、の値sys.dm_exec_cached_plans.size_in_bytesが49152(48KB)の略であるということです。これらすべてのコラムでBOLを読みました。特に次のようsize_in_bytesに述べています。 「キャッシュオブジェクトが消費したバイト数。」 それが本当に何を意味するのか理解するために、私はパズルの最後の部分を配置することはできません。 すべての演算子(並べ替えとハッシュに使用される追加のメモリ許可については説明しません)は、キャッシュに最適化されたプランで保存される状態の保存、計算の実行などのために、ある程度の固定メモリを必要としますが、どこにありますか? だから、私の質問は: size_in_bytes本当にどういう意味ですか 「キャッシュされた計画サイズ」よりも高い値になるのはなぜですか? すべての演算子/イテレータのメモリの固定量はどこに予約されていますか、「キャッシュされたプランサイズ」(この例では32Kb)ですか、それとも他の場所ですか? 私はそれらが異なる機能を持つ異なるDMVであることを知っていますが、それらは関連しています。でコンパイルされた(キャッシュされた)計画sys.dm_exec_cached_plans参加するsys.dm_os_memory_objects上でmemory_object_addressのカラム。私がここに質問を投稿する理由は、私がこれについて助けを求めて、DMVとそれらのコラムを解釈する方法を理解しているからです。 場合はsize_in_bytes、なぜSQL Serverは、実際の実行計画で別の値をキャッシュされたプランのサイズと言うんですか? 新しいクエリ、新しい番号: 実際の計画 キャッシュされたプランサイズ16KB CompileMemory 96KB DMV: sys.dm_exec_cached_plans.size_in_bytes 24KB sys.dm_os_memory_objects.pages_in_bytes, .max_pages_in_bytes 16KB。 また、このクエリでは、並べ替えおよびハッシュ操作に追加のメモリ許可が必要ないことに注意してください。 Microsoft SQL Server 2012-11.0.5343.0(X64)


2
stats_column_idとindex_column_idは、クラスター化インデックスの物理的な順序が変更されても更新されません
列の目的を誤解していない限り、次のコードは、クラスター化インデックスの構造を変更stats_column_idしてもsys.stats_columns DMVの列の順序位置()が変更されないことを示しています。(AdventureWorks2014、AdventureWorks2008R2でテスト済み) select i.name, c.name, ic.column_id, ic.index_column_id from sys.indexes i join sys.index_columns ic on i.object_id = ic.object_id and i.index_id = ic.index_id join sys.columns c on i.object_id = c.object_id and ic.column_id = c.column_id where i.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID' order by ic.key_ordinal; select sh.name,s.name, c.name, c.column_id, sc.column_id, sc.stats_column_id from sys.stats s join sys.stats_columns …

5
sys.dm_db_index_physical_statsのパフォーマンスを改善する
メンテナンスジョブ中に、断片化されたインデックスのリストを取得しようとしています。しかし、クエリは非常に遅く、実行に30分以上かかります。これはsys.dm_db_index_physical_statsのリモートスキャンによるものだと思います。 次のクエリを高速化する方法はありますか? SELECT OBJECT_NAME(i.OBJECT_ID) AS TableName, i.name AS TableIndexName FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat INNER JOIN sys.indexes i ON i.OBJECT_ID = phystat.OBJECT_ID AND i.index_id = phystat.index_id WHERE phystat.avg_fragmentation_in_percent > 20 AND OBJECT_NAME(i.OBJECT_ID) IS NOT NULL ORDER BY phystat.avg_fragmentation_in_percent DESC 私はDBAではないので、上記のクエリで明らかな間違いを犯している可能性があります。または、役立つインデックスまたは統計があるかもしれません。たぶん、それはデータベースのサイズだけです(約140のテーブルで約20Gb)。 私が尋ねる理由は、夜中にメンテナンスのための非常に小さなウィンドウしかなく、これがほとんどの時間を占めているからです。

5
SQL Serverには、実行中のストアドプロシージャに渡されるパラメーターの値を決定する方法があります
実行中のストアドプロシージャを決定する1つの方法は、次のような「動的管理」メソッドを使用することです。 SELECT sqlText.Text, req.* FROM sys.dm_exec_requests req OUTER APPLY sys.dm_exec_sql_text(req.sql_handle) AS sqltext ただし、これはストアドプロシージャのcreateステートメントのテキストのみを表示します。例えば: CREATE PROCEDURE IMaProcedure @id int AS SELECT * FROM AllTheThings Where id = @id 理想的には、問題のあるパラメーターの特定のセットに対して非常に長く実行する原因となっている実行中のプロシージャーのパラメーターを確認したいと思います。 それを行う方法はありますか?(この質問では、 Aaron BertrandがDBCC InputBufferについて言及していますが、この問題には適切ではないと思います。)

3
DMV sys.dm_exec_requestsのtotal_elapsed_timeは完全に不正確ですか?
SQL Server 2012を実行していて、DMVを使用して監視するためにいくつかのクエリをまとめようとしています。ただし、DMV のtotal_elapsed_timeフィールドをsys.dm_exec_requests見ると、数字は途方に暮れています。以下に例を示します。 SELECT session_id, RunTime = CURRENT_TIMESTAMP, start_time, total_elapsed_time FROM sys.dm_exec_requests WHERE session_id = 284; session_id RunTime start_time total_elapsed_time 284 2016-04-07 16:14:03.690 2016-04-07 16:08:14.587 1419976 私の計算*では、経過時間は約1,419,976ではなく、約349,103です。それは4倍以上ずれています。 *現在の時刻とstart_timeの差(ミリ秒単位)から、つまり SELECT DATEDIFF(MILLISECOND, '2016-04-07T16:08:14.587', '2016-04-07T16:14:03.690'); サーバー情報は次のとおりです。 SELECT @@VERSION; Microsoft SQL Server 2012 - 11.0.5592.0 (X64) Apr 17 2015 15:18:46 Copyright (c) Microsoft …

2
sys.allocation_unitsおよびsp_spaceusedのスペース使用量
DMVがページ数と行数に関する正確な情報を保持していないことは既知の事実です。ただし、統計を更新しても、なぜ更新されないのかわかりません。 私は監視ツールに取り組んでおり、各インデックスとデータのディスクサイズなどを知りたいと思っています。最終的には、適切なフィルファクターなどを見つけたいと思っています。 私の関数と古いsp_spaceusedで使用されるスペースは、スペース使用量で少し異なりますが、レコード数では異なりません。 私のセレクトに足りないものがありますか? これはsp_spaceusedです(その後、数値をMBに変換します)。 sp_spaceused 'tblBOrderRelationship' go select 318008/1024.00 AS reserved, 140208/1024.00 AS data, 177048/1024.00 AS index_size, 752/1024.00 AS unused しかし、以下のselect \ codeのコードを実行すると、わずかに異なる数字が表示されます。 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED SELECT schema_name(t.schema_id) as SchemaName, t.NAME AS TableName, t.type_desc, t.is_ms_shipped, t.is_published, t.lob_data_space_id, t.filestream_data_space_id, t.is_replicated, t.has_replication_filter, t.is_merge_published, t.is_sync_tran_subscribed, --t.is_filetable, i.name as indexName, …

2
DMVを読み取るときにREAD UNCOMMITTEDを設定する
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDシステムDMVを読む前に何人かの人が電話するのを見てきました。同じトランザクションでDMVとテーブルへの呼び出しを混在させないと仮定して、これを行う理由はありますか?
12 sql-server  dmv 


1
DMV sys.dm_exec_query_statsのlast_worker_timeとlast_elapsed_timeの違いは何ですか?
DMV sys.dm_exec_query_statsのlast_worker_timeとlast_elapsed_timeの意味は何ですか?それらの違いは何ですか? クエリの下で起動したとき SELECT TOP 20 qs.last_worker_time, qs.last_worker_time/1000000 last_worker_time_in_S, qs.last_elapsed_time, qs.last_elapsed_time/1000000 last_elapsed_time_in_S FROM sys.dm_exec_query_stats qs order by qs.last_worker_time desc 以下のような結果になります。 私が気づいたのは、両方が等しいか、経過時間がワーカー時間よりも長いことです。両方の意味を理解したいので、パフォーマンスのチューニングにも役立ちます。


2
ドキュメントのsys.dm_exec_query_stats警告の実際的な影響は何ですか?
のドキュメントにsys.dm_exec_query_statsは次のように記載されています。 サーバーで現在実行中のワークロードがある場合、sys.dm_exec_query_statsの最初のクエリで不正確な結果が生成される可能性があります。クエリを再実行することで、より正確な結果を判断できます。 私は時々、アクティブなワークロード中にそのDMVを照会し、正確な結果を好みます。上記の警告を実際に適用する方法がわかりません。DMVを常に2回クエリし、2番目の結果セットを使用する方が正確です。それは少し難しいと感じます。DMVが不正確になる可能性があることに注意して、分析に組み込むことができますか?その場合、行の欠落、古い値、一貫性のない行など、どのような不正確さが表示される可能性がありますか? sys.dm_exec_query_statsアクティブなワークロード中に使用する場合のベストプラクティスは何ですか?
10 sql-server  dmv 

1
sys.dm_exec_sessionsの「reads」列は実際には何を示していますか?
これは非常に基本的な質問のように思えるかもしれませんが、実際にそうである必要があります。ただし、科学的手法のファンとして、私は仮説を立て、それをテストして自分が正しいかどうかを確認するのが好きです。この場合、私はの出力sys.dm_exec_sessions、より具体的には、単一列の「読み取り」をよりよく理解しようとしています。 SQL Server Books Onlineでは、これを次のように明確に指定しています。 このセッション中に、このセッションのリクエストによって実行された読み取りの数。null可能ではありません。 これは、セッションの開始以降、このセッションによって発行された要求を満たすためにディスクから読み取られたページの数を示していると考えられます。これは私がテストしようと思った仮説です。 logical_reads同じテーブルの列は次のように定義されます。 セッションで実行された論理読み取りの数。null可能ではありません。 SQL Serverの使用経験から、この列はディスクとメモリの両方から読み取られたページ数を反映していると思います。つまり、ページがどこにあるかに関係なく、セッションでこれまでに読み取られたページの総数です。同様の情報を提供する2つの別々の列を持つことの差別化要因、つまり価値命題は、特定のセッションでディスクから読み取られたページ()とバッファキャッシュから読み取られたページ()の比率を理解できるように思われるでしょう。readslogical_reads 私のテストリグでは、新しいデータベースを作成し、既知のページ数のデータを含む単一のテーブルを作成してから、新しいセッションでそのテーブルを読み取りました。次にsys.dm_exec_sessions、readsとのlogical_readsコラムがセッションについて何を言っているかを確認しました。この時点で私は結果に困惑しています。おそらくここにいる誰かが私にこれについていくつかの光を当てることができます。 テストリグ: USE master; IF EXISTS (SELECT 1 FROM sys.databases d WHERE d.name = 'TestReads') BEGIN ALTER DATABASE TestReads SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE TestReads; END GO CREATE DATABASE TestReads; GO ALTER DATABASE TestReads SET RECOVERY SIMPLE; …

4
暗号化された/暗号化されたデータを持つSQL Server 2008 R2のすべての列をすばやく見つける方法はありますか?
暗号化された/暗号化されたデータを持つSQL Server 2008 R2のすべての列をすばやく見つける方法はありますか? 開発サーバーの暗号化されたすべての列のデータを(ビジネスルールに従って)無効にする必要があります。私は定期的に使用しているため、ほとんどの列を知っていますが、徹底し、すべての列が見つかったことを証明できるようにしたいと考えています。 私はWebを検索し、INFORMATION_SCHEMAを調べて、有用だと思われるDMVとsys.columnsとsys.objectsを確認しましたが、今のところうまくいきません。

1
DMV sys.dm_os_performance_countersをクエリするとゼロ行が返される
サーバービューの状態のアクセス許可をSQL Server 2014 Standard Edition (RTM)持つSYSADMIN役割を持つユーザーがいますが、DMVを実行しsys.dm_os_performance_countersてもレコードが返されません。 権限の何が問題になっているのでしょうか? @@ Versionの出力: Microsoft SQL Server 2014-12.0.2000.8(X64)Feb 20 2014 20:04:26 Copyright(c)Microsoft Corporation Standard Edition(64-bit)on Windows NT 6.3(Build 9600:)(Hypervisor)

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.