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

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

1
クラスタ化インデックスシークと非クラスタ化インデックスシークの違い
クラスタ化インデックス(CI)シークと非クラスタ化インデックス(NCI)シークの違いは何ですか?一方が他方よりもパフォーマンスが良いですか? これを尋ねる理由は、5,000万行と150列のテーブルがあるためです。これにはID、クラスター化インデックスとして定義された名前の列があります。同じインデックスキーIDと7つのinclude-d列を持つNCIがもう1つあります。NCインデックスはここでは重複しており、安全に削除できるようです。 安全にドロップできる場合、またはそのままにしておく必要がある場合は、専門家の意見/アドバイスが必要ですか?

1
SQL Server Management Studio(SSMS)内のアクティビティモニターのSQLCLR待機タイプとは何ですか?
SQL Prodサーバーをチェックすると、アクティビティモニターを開くたびSQLCLRに、アクティビティモニターのリソース待機セクションの最初のリストに常に表示されます。それは常に高い数を持っています。何のSQLCLRため?SQLCLRアクティビティモニターでリソース待機数が多いサーバーに問題がありますか?

3
複数のデータベースを同じ時点にバックアップする
通常、バックアップを開始するときは、変更のコミットを許可しないか、データベースにアクセスできなくなります。データベースがシングルユーザーモードになることを意味しますが、バックアップを開始し、データベースを解放して使用します。また、バックアップを開始したら、進行中の変更をバックアップファイルに書き込まないようにします。Microsoft SQL Server 2012でこれを実現する方法を知りたいです。 さて、まず私の問題を説明させてください。現在、バックアップが完了するまで、データベースをシングルユーザーモードに設定しています。このモードは、バックアップの進行中にデータの変更を回避するという私の目的に役立ちます。しかし、私のアプリケーションは複数のデータベースに関連付けられています(各データベースは相互にリンクされており、毎月作成し続けるvar dbsがあります)。そのため、これらすべてのデータベースのバックアップは退屈なプロセスになり、さらに重要なのは、バックアップの進行中は、ユーザーをシステムから除外する必要があることです。 そこで、以下の要件を満たすバックアップメカニズムを探しています。 一度にすべてのデータベースのバックアップを開始し、使用できるようにデータベースを解放します。 データベースは相互にリンクされているので、バックアップファイルでデータの一貫性を維持したいと考えています。したがって、このデータ整合性の要件のため、進行中の変更をバックアップファイルにコミットしたくありません。 必要なのは、ある時点でのすべてのデータベースのバックアップです。

4
特定のSQL ServerにアクセスするすべてのIPまたはユーザーを検索する
SQLサーバーを見つけたが、どのアプリケーションがそれに接続しているかがわからないとします。多分私は1つのアプリケーションを見つけますが、それがそれを使用している唯一のアプリケーションかどうかはわかりません。 すべての異なる接続を見つける良い方法はありますか?

2
バッファプール外のSQL Server 2012メモリ消費
SQL Server 2012 SP2 Enterprise Editionのインスタンスを使用しており、最大よりも20 GB高いメモリを消費しています。メモリ制限。インスタンスは65GBに制限されていますが、以下のクエリで使用中の物理メモリは86GBを示しています SELECT (physical_memory_in_use_kb/1024)/1024 AS [PhysicalMemInUseGB] FROM sys.dm_os_process_memory; GO サーバーは2つのNUMAノードを持つ物理的なものです。バッファプールの外でメモリを消費しているものを見つける方法はありますか(それが起こっていると想定しています)? DBCC MEMORYSTATUSの出力は次のとおりです。 そして、ここに設定されたメモリ制限があります:- 前もって感謝します。 更新:-アーロンが提案したクエリを実行しました SELECT TOP (20) * FROM sys.dm_os_memory_clerks ORDER BY pages_kb DESC これが出力です:- pages_kbの合計は最大60GBになります UPDATE 2: - DBCC MEMORYSTATUSの全出力はここにある: - http://pastebin.com/nGn6kXEc UPDATE 3: -ここでは、Excelファイル内Shankyのスクリプトの出力: - http://jmp.sh/LKRlH4K 更新4:-出力のスクリーンショット:- SELECT (physical_memory_in_use_kb/1024)/1024 AS [PhysicalMemInUseGB] FROM …

1
OUTER JOIN内にネストされたINNER JOINの構文とクエリ結果
TLDR; 2つの実行プランを見ると、どちらが良いのか簡単な答えはありますか?意図的にインデックスを作成しなかったので、何が起こっているのかを簡単に確認できます。 異なる結合スタイル(つまり、ネストされたものと従来のもの)の間のクエリパフォーマンスの違いを発見した私の以前の質問をフォローアップして、ネストされた構文もクエリの動作を変更することに気付きました。次の2つのクエリについて考えます。 SELECT a.*, m.*, n.* FROM dbo.Autos a LEFT JOIN dbo.Models m JOIN dbo.Manufacturers n -- <-- Nested INNER JOIN ON n.ManufacturerID = m.ManufacturerID ON m.ModelID = a.ModelID これは、Modelsテーブルにない ModelIDを持つ自動行を含めるために、製造元を結合する必要はありません。 従来の構文を使用して、結合をManufacturesから外部結合に変更する必要があります。ただし、これによりクエリプランが変更されます。 SELECT a.*, m.*, n.* FROM dbo.Autos a LEFT JOIN dbo.Models m ON m.ModelID = a.ModelID LEFT JOIN …


3
SQL Serverでの連続するバックアップごとに.bakファイルのサイズが増加/倍増するのはなぜですか?
SQL Server 2012 Expressで単純なDBを実行しています。 ちょうど今日、データベースをバックアップすると、.bakファイルサイズは、直前のバックアップの数分前の2倍になります。今日、いくつかのバックアップを実行しました(SQL Server Management Studio->バックアップの種類:完全).bak。ファイルごとに2倍になっています。 SQL Server Mgmt Studioで、DBを右クリックすると、[レポート]-> [バックアップと復元のイベント]-> [成功したバックアップ操作]が展開されます。 ここのレポートは、最新のバックアップサイズが55MBと記録されていることを示してい.bakますが、実際のファイルに移動すると260MBです。今日の他の各バックアップも55MBのサイズとして記録されましたが、対応する.bakファイルは数倍大きくなっています(バックアップ操作ごとに増加しています)。 何がうまくいかないのでしょうか?これが始まって以来、データベースに変更を加えていません。

1
SQLHANDLEの無限再コンパイルの可能性が検出されました
私はSQLエラーログで奇妙なエラーメッセージを見つけてきました: Bocss:1時間ごとに同じデッドロックが発生–調査が必要 また、次の例のように、他のSPIDのエラーログに多くの再コンパイルがリストされます。 2015年9月4日14:30:10、spid64、Unknown、SQLHANDLE 0x0200000059631A288882589E0C54B76404CAE1B97E08D3680000000000000000000000000000000000000000 PlanHandle 0x0600040059631A2860A62B654100000001000000000000000000000000000000000000000000000000000000開始オフセット600200000010000000000000000000000000000000000000000000000000000000開始オフセット600200000010000000000000000000000000000000000000000000000000000000開始オフセット600200000010000000000000000000000000000000000000000000000000000000開始オフセット600400000009000000 、spid150、Unknown、SQLHANDLE 0x02000000EF886F018C4E0B163812B8B20150FE8FC7E6A06A0000000000000000000000000000000000000000 PlanHandle 0x06000400EF886F01901A816E0600000001000000000000000000000000000000000000000000000000000000開始オフセット998、最後のオフセット252015終了オフセット2.9 09終了オフセット25209 09終了オフセット25209 09終了オフセット2509 0930:09、spid163、不明、可能無限の再コンパイルがSQLHANDLE 0x02000000E7C7BF0E5D70DE55759C7842860272AD474D69AB0000000000000000000000000000000000000000 PlanHandle検出された可能無限の再コンパイルは、最後の再コンパイルの理由2. 2015年9月4日14れた2652終了オフセット1064オフセット開始SQLHANDLE 0x0200000057C4C632D9052275CFF2B683B80F29501EE91D730000000000000000000000000000000000000000 PlanHandle 0x0600040057C4C63200EAC2BE3000000001000000000000000000000000000000000000000000000000000000検出されました0x06000400E7C7BF0EF0EB68A52C00000001000000000000000000000000000000000000000000000000000000開始オフセット1028終了オフセット2580。最後の再コンパイル理由は2でした。 何が原因でしょうか? キャッシュにプランがもうないようです。 この投稿のアドバイスに従って http://www.sqlservercentral.com/Forums/Topic1479420-146-1.aspx 次に、安全対策によりフルテキストカタログが無効にされたため、これには違いがなかったため、変更を完全にロールバックしました(新しいオブジェクトをドロップしたなど)。これでも違いはありませんでした。結局、SQLインスタンスの再起動がそれを止めるように見えた唯一の事柄であり、これが問題を即座に解決しました。 これも私を整理しました、しかし、私はまだ最初にこの混乱を引き起こした原因を見つける必要がありますか?

2
SQLエージェント-PowerShellステップ「構文エラー」
実行されていないSQLエージェントジョブステップで次のコードを設定しています。受け取ったメッセージは単純です: ステップ1の実行を開始できません(理由:line(46):構文エラー)。ステップは失敗しました。 ジョブの期間は次のとおりです。 00:00:00 このスクリプトの46行目はhere-string: ,@DriveLetter = '$($c.DriveLetter)' このスクリプトは、SQL Serverエージェントの外部で完全に実行されます。 ServerNamesテーブル: CREATE TABLE ServerTable ( ServerName varchar(50) ) ディスクスペーステーブルは次のようになります。 CREATE TABLE DiskSpace ( ID int IDENTITY(1,1), ServerName varchar(50), DriveLetter varchar(2), DiskSpaceCapacityGB decimal(12,5), DiskSpaceFreeGB decimal(12,5) ) PowerShellスクリプト: This command is to allow SQL Agent job to show failure in event PowerShell …

1
MS SQL ServerのシーケンスにOracleのようなORDERパラメータがないのはなぜですか?
ドキュメントのCREATE SEQUENCET-SQLのため、あなたがいることを確認できCREATE SEQUENCEコマンドには、持っていないORDERパラメータを。 比較のためにCREATE SEQUENCE、ORDER/のNOORDERオプションを示すOracleのドキュメント: ORDER ORDERシーケンス番号が要求順に生成されることを保証することを指定します。この句は、シーケンス番号をタイムスタンプとして使用する場合に役立ちます。通常、主キーの生成に使用されるシーケンスでは、保証順序は重要ではありません。 ORDEROracle DatabaseをReal Application Clustersで使用している場合、順序付けられた生成を保証するためにのみ必要です。排他モードを使用している場合、シーケンス番号は常に順番に生成されます。 NOORDER NOORDER要求順にシーケンス番号が生成されることを保証しない場合に指定します。これがデフォルトです。 Microsoft SQL ServerはSEQUENCEsに強い順序付け制約を提供していますか?それともマイクロソフトはそれを一般的に重要とは考えていませんか?

2
より良いストレージにアップグレードした後のチェックポイント中の待機の増加
古いオールフラッシュアレイから新しいオールフラッシュアレイ(異なるが、確立されたベンダー)に移行すると、チェックポイント中にSQL Sentryで待機が増えることがわかりました。 バージョン:SQL Server 2012 Sp4 私たちの古いストレージでは、待機時間はチェックポイント中の「スパイク」が2,500で約2kでしたが、新しいストレージではスパイクは通常10kで、ピークは50k近くです。歩哨は私たちをPAGEIOLATCHワティスにもっと向けます。独自の分析を行うと、PAGEIOLATCH and PAGELATCH待機の組み合わせのようです。Perfmonを使用すると、一般に、チェックポイントを行うページが増えるほど、待機時間が長くなりますが、フラッシュするのは、チェックポイント中に〜125 MBだけです。私たちのワークロードはほとんどが書き込みです(主に挿入/更新)。 ストレージベンダーは、ファイバーチャネル直接接続アレイがこれらのチェックポイントイベント中に1 ms未満応答していることを証明しています。HBAはアレイの番号も確認します。また、キューの深さが8を超えることはなかったため、HBAキューの問題であるとは考えていません。また、ZIO、実行スロットル、およびキューの深さの設定を無効にして、新しいHBAを試しました。また、サーバーのメモリを500 GBから1 TBに変更せずに増やしました。チェックポイントプロセス中に、2〜4個のコア(16個のうち)が100%に急上昇しますが、全体的なCPUは約20%です。BIOSも高パフォーマンスに設定されています。興味深いことに、CPUがC2スリープ状態になっているのは無効にしたにもかかわらず、通常はC2スリープ状態であるため、スリープ状態がC1を超えた理由を調査しています。 ほとんどすべての待機が、DCMページタイプのPFSが時々発生するデータページで発生していることがわかります。待機はtempdbではなくユーザーDBで行われます。また、待機が複数のデータページにわたって行われ、一部のSPIDが同じページで待機していることもわかります。データベースの設計には、いくつかの挿入ホットスポットがありますが、同じ設計が古いストレージに配置されていました。 このクエリのループを100回実行すると、ディスクとメモリで待機しているSPIDの数を把握できました。 SELECT [owt].[wait_type], count(*) as waitcount FROM sys.dm_os_waiting_tasks [owt] WHERE [owt].[wait_type] LIKE 'PAGE%' group by [owt].[wait_type] order by 1 GO 100 「良い」ことは、同じモデル配列と類似のサーバー仕様を持つパフォーマンス環境で問題を簡単に再現できることです。他にどこを見るべきか、どのように問題を絞り込むかについての考えをいただければ幸いです。現在、次のテストは次のとおりです。新しいマザーボードとより多くのCPUを搭載した新しいサーバー。SIOSデータキーパーを無効にする(これが古いストレージで行われている場合でも)。異なるHBAブランド。 exec sp_Blitz @outputtype = 'markdown' 優先度5:信頼性:-危険なサードパーティモジュール-Sophos Limited-ソフォスのバッファーオーバーラン保護-SOPHOS〜2.DLL-危険と思われるサードパーティモジュールがインストールされています。 優先度200:情報:-クラスターノード-これはクラスター内のノードです。-TraceFlag On-トレースフラグ1117がグローバルに有効になります。-トレースフラグ1118がグローバルに有効になります。-トレースフラグ3226がグローバルに有効になります。 優先度200:ライセンス:-使用中のEnterprise Edition機能* xxxxx-[xxxxxx]データベースは圧縮を使用しています。このデータベースをStandard Editionサーバーに復元すると、2016 …

1
sp_cursorprepexecが5300万の読み取りを引き起こしていますか?
SQL Server 2012でDynamics AX 2012のインストールを実行しています。カーソルはもう使用されないはずですが、AXはそれを使用しており、この動作を変更できないため、操作する必要があります。 今日、5300万を超える読み取りと20分を超える実行時間を伴う非常に悪いクエリを見つけました。 私は監視ツールのSentryOneを介してこのクエリを見つけました。 declare @p1 int set @p1=1073773227 declare @p2 int set @p2=180158805 declare @p5 int set @p5=16 declare @p6 int set @p6=1 declare @p7 int set @p7=2 exec sp_cursorprepexec @p1 output,@p2 output,N'@P1 bigint,@P2 nvarchar(5),@P3 bigint,@P4 nvarchar(8),@P5 bigint,@P6 bigint,@P7 bigint,@P8 bigint,@P9 bigint,@P10 bigint,@P11 bigint,@P12 bigint,@P13 bigint,@P14 …

2
ほとんどのクエリプランは過去4時間に再作成されました
SQL Serverデータベースのパフォーマンスに問題があります。このツールsp_BlitzCacheを見つけました。コマンドの実行後、次のステートメントが得られました。 過去24時間に92.00%のプランが作成されており、過去4時間に92.00%のプランが作成されています。 問題を特定しましたが(SQL Server Profilerを使用して、StmtRecompileイベントの発生を確認しました)、頻繁に再構築される少数の全文検索クエリのみを見つけることができました。ただし、全文検索クエリは、全クエリの約5%にすぎません。 残りの87%のプランを再現する原因となる提案はありますか? SQL Server 2012(バージョン11.0.6567.0)を持っています。 編集:パフォーマンスカウンターを追加しました +---------------------------+--------------------------------+--------------+ | object_name | counter_name | cntr_value | +---------------------------+--------------------------------+--------------+ | SQLServer:Buffer Manager | Background writer pages/sec | 0 | | SQLServer:Buffer Manager | Buffer cache hit ratio | 28436 | | SQLServer:Buffer Manager | Buffer cache hit ratio base …

3
実行プランはINDEXを使用せず、テーブルスキャンを使用します
インデックスまたはテーブルスキャンを使用する場合、SQL Serverは統計を使用してどちらが優れているかを確認します。 2,000万行のテーブルがあります。(SnapshotKey、Measure)のインデックスと次のクエリがあります。 select Measure, SnapshotKey, MeasureBand from t1 where Measure = 'FinanceFICOScore' group by Measure, SnapshotKey, MeasureBand クエリは500k行を返します。したがって、クエリはテーブルの行の2.5%のみを選択します。 問題は、SQL Serverが私が持っている非クラスター化インデックスを使用せず、代わりにテーブルスキャンを使用する理由です。 統計を更新しました。 ただし、クエリのパフォーマンスは良好です。 テーブルスキャン 強制インデックス テーブル/インデックス構造 CREATE TABLE [t1]( [SnapshotKey] [int] NOT NULL, [SnapshotDt] [date] NOT NULL, [Measure] [nvarchar](30) NOT NULL, [MeasureBand] [nvarchar](30) NOT NULL, -- and many more fields …

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