タグ付けされた質問 「sql-server-2014」

SQL Server 2014(メジャービルドバージョン12.0.xxxx)。sql-serverにもタグを付けてください。

1
高PAGELATCH_ *およびWRITELOG待機。それらは関連していますか?
非常に高いPAGELATCH_EXおよびPAGELATCH_SH待機タイプと、高いWRITELOG待機が発生しています。PAGELATCH待機の原因となっているクエリを診断しました。IDENTITY値で定義されたビジーなクラスター化された主キーへの挿入率を下げることで、それらを排除できます。この現象は最終ページ挿入ラッチ競合として知られていると理解しています。 ただし、私の質問は、新しいレコードが挿入されたとき、SQL Serverがバッファーページで排他的なPAGELATCH_EXを取得し、レコードをバッファーページに挿入して、トランザクションログにレコードを書き込み、詳細なhttps://として排他的なPAGELATCH_EXを解放することです。 www.microsoft.com/en-ie/download/details.aspx?id=26665ページ24.または、詳細な「高度に同時実行されているINSERTワークロードでのPAGELATCH競合の解決-背景情報SQLCATのガイド:リレーショナルエンジン レコードがラッチメカニズムの外部のログに書き込まれる場合、PAGELATCH待機が高くなる原因として、ディスクへの遅い書き込みを除外できます。しかし、レコードがログに記録されるまで強化されるまでラッチが保持されている場合は、おそらくWRITELOGを考慮する必要があります。 また、複数の非クラスター化インデックスがあると、PAGELATCH_ *ラッチがより長く保持されます。つまり、テーブルにクラスター化されており、複数の非クラスター化インデックスがラッチに追加され、各インデックスバッファーページに同時に解放されますか? 更新1 confio-sql-server-writelog-waitスライド2と一般的なWALアーキテクチャを 読んだ後。両方のホワイトペーパーで説明されている「行が変更されたログエントリを記録する」手順は、SQL Serverがディスクではなくトランザクションログキャッシュに変更を記録することを指していることを理解しました。トランザクションが完了するか、バッファがいっぱいになると、すべてのレコードがすぐにディスクにフラッシュされます。

2
TSQLを使用してデータベースを動的に変更する方法
SSMSのコンテキストを動的SQLで指定されたデータベースに動的に変更しようとすると問題が発生します。 EXEC sys.sp_executesql N'USE db1 ' ; 正常に実行されますが、SSMSのデータベースコンテキストは変更されません。 上記のように少し変更してみました DECLARE @sql NVARCHAR(100) DECLARE @db NVARCHAR(50) SET @db = N'db1' SET @sql = N'Use ' + @db EXEC sp_executesql @sql 繰り返しになりますが、正常に実行されますが、データベースは変更されません。

1
UPDATE STATISTICS…ROWCOUNTを使用した後に統計をリセットする方法
クエリのチューニングとテストの目的で、を実行して、行数とページ数をテーブルのインデックス統計に手動で割り当てることができますUPDATE STATISTICS。しかし、統計をテーブルの実際の内容に再計算/リセットするにはどうすればよいでしょうか。 --- Create a table.. CREATE TABLE dbo.StatTest ( i int NOT NULL, CONSTRAINT PK_StatTest PRIMARY KEY CLUSTERED (i) ); GO --- .. and give it a thousand-or-so rows: DECLARE @i int=1; INSERT INTO dbo.StatTest (i) VALUES (@i); WHILE (@i<1000) BEGIN; INSERT INTO dbo.StatTest (i) SELECT @i+i FROM dbo.StatTest; …

3
カーディナリティの推定値が低いと、INSERTは最小限のログから除外されますか?
2番目のINSERTステートメントが最初のステートメントより〜5倍遅いのはなぜですか? 生成されたログデータの量から、2番目のログは最小限のログ記録に適していないと思います。ただし、データ読み込みパフォーマンスガイドのドキュメントには、両方の挿入を最小限に記録できることが示されています。では、最小限のロギングが主要なパフォーマンスの違いである場合、2番目のクエリが最小限のロギングに適格ではないのはなぜですか?状況を改善するために何ができますか? クエリ#1:INSERT ... WITH(TABLOCK)を使用して5MM行を挿入する 5MM行をヒープに挿入する次のクエリを考えてみます。このクエリは、によって報告されるトランザクションログデータで実行1 secondおよび生成64MBされsys.dm_tran_database_transactionsます。 CREATE TABLE dbo.minimalLoggingTest (n INT NOT NULL) GO INSERT INTO dbo.minimalLoggingTest WITH (TABLOCK) (n) SELECT n -- Any table/view/sub-query that correctly estimates that it will generate 5MM rows FROM dbo.fiveMillionNumbers -- Provides greater consistency on my laptop, where other processes are running OPTION …

3
WITH CTEとWITH CTE(<column_names>)の違いは何ですか?
MSDNの共通テーブル式の使用に示すように、CTEを次のように定義できます。 WITH expression_name [ ( column_name [,...n] ) ] AS ( CTE_query_definition ) そしてそれを次のように使用します: SELECT &lt;column_list&gt; FROM expression_name; 次の2つのCTEがあるとします with cte1 as( select name from Table1 ) with cte2(name) as( select name from Table1 ) クエリは、内部クエリが同じであるため、両方のCTEに対して同じ結果を出力します。これら2つの違いは、cte2の(name)宣言で列名()が定義されていることだけです。 両方のCTEを実行しても、実行計画に違いはありません。 私は知りたいだけです: CTE定義で列名を指定しない場合、どのような違いがありますか? CTEの作成時に列名を指定する必要がある/すべきではないのはなぜですか? 万が一クエリ実行プランに影響はありますか?(私が見た限りでは、何の違いもありません。)

1
システム正常性拡張イベントからの誤ったプロセス使用率?
私は最近、システムヘルス拡張イベントイベントファイルに格納されているデータまたはメトリックの理解に取り組んでいます。 ここで提供されているように、システムヘルスを使用してパフォーマンスメトリックのデータコレクションを実装しようとしています という名前のシステムヘルスイベントから収集されるCPU使用率、その他のプロセス使用率などのメトリックを提供するレポートがあります。 scheduler_monitor_system_health_ring_buffer_recorded SQL CPU使用率としてレポートにリストされているフィールド "process_utilization"がほとんどの場合100を超える時間である理由をいくつかのビジーサーバーで理解できません。サーバーアクティビティモニターから確認した場合でも、常に100を超えるCPUが表示されます。 私はGithubでこの問題を提起しましたが、修正または応答がないようです。 したがって、私の質問は 記録されたシステムヘルスリングバッファーを使用して、サーバーのSQL CPU使用率の正確な数値を取得するにはどうすればよいですか? レポートには、レポートごとに計算された2つ未満のフィールドのカウンターも表示されます OtherProcessUtilとしての100-System_idle-process_utilization SystemUtilとしての100-system_idle これらのOtherProcessUtilおよびSystemUtilは何のために必要/役立ちますか? また、毎回メモリ使用率が常に100と表示されています。これも正しくないようです。誰か気づいたことがありますか? Idera&sentry [私がテストしたもの]のような他のツールでは、同じサーバーのCPU使用率が100%を超えていません。同じ負荷に対して並べて比較しました。


1
負の値とゼロの値を含む列の行を乗算する方法は?
クエリでグループ化された特定の列のすべての行の積を取得しようとしています。私は組み合わせ方のポイントに私を見つけたほとんどの例exp、sumおよびlog exp(sum(log([Column A]))) 私が抱えている問題は、列に値のゼロが含まれているため、log関数にゼロが渡されたときにこのエラーが発生することです。 無効な浮動小数点演算が発生しました。 case式を使用してこれを回避できると思いましたが、すべてのケースを評価しているように見えるので、それは私が思っているように機能しません... select Name, Product = case when min([Value]) = 0 then 0 when min([Value]) &lt;&gt; 0 then exp(sum(log(I))) -- trying to get the product of all rows in this column end from ids group by Name SqlFiddle 次の結果セットがあるとします。 Id Name Value _________________________________ 1 a 1 …

1
誰が私のワーカースレッドを使用していますか?SQL Server 2014-HADR
最近、SQL Server 2014 HADR環境で問題が発生し、サーバーの1つでワーカースレッドが不足しました。 メッセージを受け取りました: AlwaysOn可用性グループのスレッドプールは、利用可能なワーカースレッドが十分にないため、新しいワーカースレッドを開始できませんでした。 問題を分析するのに役立つ(と思った)ステートメントを取得するために、別の質問を既に開いています(どのSPIDがどのスケジューラー(ワーカースレッド)を使用しているかを確認できますか?)。システムを使用しているスレッドを見つけるためのクエリを取得しましたが、サーバーがワーカースレッドを使い果たした理由がわかりません。 私たちの環境は次のとおりです。 4 Windows Server 2012 R2 SQL Server 2014エンタープライズ 24プロセッサ-&gt; 832ワーカースレッド 256 GB RAM 12個の可用性グループ(全体) 642データベース(全体) したがって、問題が発生したサーバーには次の構成がありました。 5つの可用性グループ(3つのプライマリ/ 2つのセカンダリ) 325データベース(127プライマリ/ 198セカンダリ) MAXDOP = 8 Cost Threshold for Parallelism = 50 電源プランは「高パフォーマンス」に設定されています この問題を「解決」するために、1つの可用性グループをセカンダリサーバーに手動でフェールオーバーしました。そのサーバーの構成は次のとおりです。 5つの可用性グループ(2つのプライマリ/ 3つのセカンダリ) 325データベース(77プライマリ/ 248セカンダリ) 私はこのステートメントで利用可能なスレッドを監視しています: declare @max int select @max = …


2
SQL Server 2014でのフルスキャンによる統計の更新では100%のCPUを使用し、2008 R2では15%を使用します
フルスキャンの更新統計では、SQL Server 2008 R2でCPUの20%を使用しているのに、同じテーブルで同様のハードウェア機能を使用しているのに、SQL Server 2014でCPUの100%を使用するのはなぜですか? 私はMAXDOP他のオプションを検討してきましたが、特に目立つものは何もありません。これを引き起こす可能性のある設定があることは承知していますが、設定は両方のデータベースで非常に似ています(たとえば、MAXDOP両方とも4で、両方に複数のコアがあります)。どちらもEnterprise Editionです。 これを説明できるSQL Server 2014とSQL Server 2008 R2で「異なる」ものはありますか?どちらのサーバーでも、メモリオプションは90%です。何を探すべきかについての考えはありますか? SQL Server 2008 R2 / SP3とSQL Server 2014 / SP2を使用する2台のサーバーで、フル(100%)スキャンによる統計更新を週に1回実行します。データベースの構造は同じです。2008 R2サーバーでは、2つの非常に大きなテーブルの統計の更新に数時間かかりますが、これは予想どおりですが、CPUは使用率全体で20%未満にとどまります。ただし、2014サーバーでは、CPUは約40分間100%になります。2014サーバーではテーブルが少し小さくなっています。SQLモニターの分析メニューを使用してこれを確認します。 2014 SQL ServerのOlaログファイルの出力は次のとおりです。CPUは、約2:10から2:45まで100%になります。 Date and time: 2017-06-24 02:10:20 Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000005_15502E78] WITH FULLSCAN Outcome: Succeeded Duration: 00:07:48 Date and time: 2017-06-24 02:18:08 Date …

1
スーパーセットのみを選択
次のコマンドで作成できる2つのテーブル(非クラスター化インデックスと共に)があります。 CREATE TABLE GroupTable ( GroupKey int NOT NULL PRIMARY KEY, RecordCount int NOT NULL, GroupScore float NOT NULL ); CREATE TABLE RecordTable ( RecordKey varchar(10) NOT NULL, GroupKey int NOT NULL, PRIMARY KEY(RecordKey, GroupKey) ); CREATE UNIQUE INDEX ixGroupRecord ON RecordTable(GroupKey, RecordKey); 技術的にはテーブルが少し異なり、他のいくつかのテーブルに参加していますが、これは私の状況に適したプロキシです。 GroupKeys別のサブセットではないものをすべて選択したいGroupKey。 特定のスーパーセットについて、GroupScoreすべてのサブセット(それ自体を含む)の最大値を取得したいと思います。 a GroupKeyにRecordKeys別のとまったく同じものが含まれている場合GroupKey(s)、そのうちの1つだけGroupKeysが取得されます(どちらを使用してもかまいません)。 別のものとGroupKeyまったく同じであるものはすべて同じになります。RecordKeysGroupKey(s)GroupScore 非関連GroupKeysも同じスコアを持つことができます。 …

3
指定されたネットワーク名は使用できなくなりました
データベースにアクセスするアプリケーションがあります(SQL Server 2014 Enterprise Edition)。アプリケーションは、データベースにアクセスするためのストアドプロシージャを呼び出します。最近、次のエラーの送信を開始してアプリケーションを停止するまで、すべてが正常に機能していました。アプリを再起動すると問題が一時的に解決しますが、同じエラーが発生します。 エラー:サーバーから結果を受信するときに、トランスポートレベルのエラーが発生しました。(プロバイダー:TCPプロバイダー、エラー:0-指定されたネットワーク名は使用できません。) 私は多くの調査を行いましたが、それらのほとんどはネットワークの問題として指摘していますが、実際に問題を解決するためのものが見つかりませんでした。この問題を解決するためにデータベース側で行う必要がある変更を誰かが知っていますか?私は提案を高く評価します。

1
SQL Server-更新ステートメントでウィンドウ関数が許可されないのはなぜですか?
以下のようなupdateステートメントを実行すると、エラーメッセージが表示され、 ウィンドウ関数は、SELECT句またはORDER BY句でのみ使用できます。 UPDATE dbo.Dim_Chart_of_Account SET Account_Order = LAG([Account_Order]) OVER (ORDER BY [Account_SKey]) これは、以下のような更新可能なcteを使用して簡単に回避できることを知っています WITH my_cte AS ( SELECT [Account_Order], LAG([Account_Order]) OVER (ORDER BY [Account_SKey]) AS acc_order_lag FROM Dim_Chart_of_Account ) UPDATE my_cte SET [Account_Order] = acc_order_lag 私の質問は、これがupdateステートメントで許可されていない理由はありますか?回避策として更新可能なcteを使用しないようにすべきですか? 私の懸念は、更新ステートメントでウィンドウ関数を使用するときに問題があるため、これが許容できる方法であるのか、それとも避けるべきなのかを理解したいのです。

2
SQL Serverがすべてのメモリを使用していない
SQL Server 2014で、最大メモリを6GBに設定しています(物理メモリは8GB)。 ターゲットサーバのメモリは、時には6ギガバイトで、その後、バックに落ちるの合計サーバーメモリ(約5.3ギガバイト、6ギガバイトに達することはありません)。私が使用committed_kbをしてsys.dm_os_sys_info SQL Serverが使用するメモリをチェックします。 sys.dm_os_buffer_descriptorsを監視すると、ページがキャッシュから削除されていることがわかりますが、残りのメモリは700MBです。メモリが必要ない場合、ページがキャッシュから削除されるという事実をどのように説明しますか?SQL Serverは、メモリが必要な場合にのみページを削除すると思います。 割り当て解除された一時テーブルは、このサーバーでは問題になりません。私のPLEは3632です。プロシージャキャッシュは2182 MBです。 メモリが残っていない場合にのみページがドロップされると思いますが、700MBの空き容量があるか、これを誤解していますか? 誰かがこの動作を説明してみてください。 SQL Serverもディスクから読み取っているので、必要なすべてのページがメモリにあるとは限らないと思います。 さらに調査を行ったところ、ディスクからメモリに大量のページを読み取り、読み取り中にタスクマネージャに何かがあったことに気づきました。 使用中のメモリは7.0GB-&gt; 7.2GB-&gt; 7.0GB-&gt; 7.2GB-&gt; ... Sqlservr.exeは5.3GB-&gt; 5.5GB-&gt; 5.3GB-&gt; 5.5GB-&gt; ... これは、Windowsがsqlservr.exeを6GBに拡張できないようです。 Shankyから提供されたクエリを実行しました。 select (physical_memory_in_use_kb/1024) Physical_Memory_usedby_Sqlserver_MB, (locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB, (Virtual_address_committed_kb/1024 )Total_Memory_in_MB,--RAM+ Pagefile process_physical_memory_low, process_virtual_memory_low from sys. dm_os_process_memory これにより、次の結果が得られました。 Physical_Memory_usedby_Sqlserver_MB: 5247 Locked_pages_used_Sqlserver_MB: 0 Total_Memory_in_MB: 5625 process_physical_memory_low: 0 process_virtual_memory_low: …

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