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

同じ名前、タイプ、およびインデックスキー列を持つ2つのテーブルがあります。それらの1つには一意のクラスター化インデックスがあり、もう1つには非一意があります。 テストのセットアップ いくつかの現実的な統計を含むセットアップスクリプト： DROP TABLE IF EXISTS #left; DROP TABLE IF EXISTS #right; CREATE TABLE #left ( a char(4) NOT NULL, b char(2) NOT NULL, c varchar(13) NOT NULL, d bit NOT NULL, e char(4) NOT NULL, f char(25) NULL, g char(25) NOT NULL, h char(25) NULL --- and a …

40 sql-server  sql-server-2014  join  sql-server-2017  sort-operator 

SQL Server 2014、標準エド 私は、dm_exec_requestsのpercent_completeがCREATE INDEXで機能せず、実際には、percent_completeが0のままになることを読んだことがあります。 現在、以下の方法を使用しています。これは、少なくとも動きを示しています（インデックス作成がブロックされていないこと）。しかし、プロセスを経て％10であるか、％99であるかはわかりません。 ここで説明した方法を試しました：https : //dba.stackexchange.com/a/102545/6229 しかし、それは明らかに間違ったest完了時間を示しています） どうすれば手掛かりを得ることができますか？ SELECT percent_complete, estimated_completion_time, reads, writes, logical_reads, text_size, * FROM sys.dm_exec_requests AS r WHERE r.session_id <> @@SPID AND r.session_id = 58

36 sql-server  sql-server-2014 

一般に、新しい環境で開始するとき、バックアップの場所、最後のフルバックアップが行われた時刻、最後の復元が適用された時刻、およびセキュリティも確認します。 これを行うには、T-SQLを使用します。 バックアップを確認する ;with Radhe as ( SELECT @@Servername as [Server_Name], B.name as Database_Name, ISNULL(STR(ABS(DATEDIFF(day, GetDate(), MAX(Backup_finish_date)))), 'NEVER') as DaysSinceLastBackup, ISNULL(Convert(char(11), MAX(backup_finish_date), 113)+ ' ' + CONVERT(VARCHAR(8),MAX(backup_finish_date),108), 'NEVER') as LastBackupDate ,BackupSize_GB=CAST(COALESCE(MAX(A.BACKUP_SIZE),0)/1024.00/1024.00/1024.00 AS NUMERIC(18,2)) ,BackupSize_MB=CAST(COALESCE(MAX(A.BACKUP_SIZE),0)/1024.00/1024.00 AS NUMERIC(18,2)) ,media_set_id = MAX(A.media_set_id) ,[AVG Backup Duration]= AVG(CAST(DATEDIFF(s, A.backup_start_date, A.backup_finish_date) AS int)) ,[Longest Backup Duration]= …

32 sql-server  sql-server-2014  backup  restore  security 

クラスター化された列ストアインデックスからのデータの削除をテストしています。 実行計画に大きな熱心なスプールオペレーターがいることに気付きました。 これは、次の特性で完了します。 6,000万行が削除されました 1.9 GiB TempDBを使用 実行時間14分 シリアルプラン 1スプールで再バインド スキャンの推定コスト：364.821 見積もりツールをだまして過小評価するようにすると、TempDBの使用を回避するより高速なプランが得られます。 推定スキャンコスト：56.901 （これは推定プランですが、コメントの数値は正しいものです。） 興味深いことに、次を実行してデルタストアをフラッシュすると、スプールは再び消えます。 ALTER INDEX IX_Clustered ON Fact.RecordedMetricsDetail REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON); スプールは、デルタストアにページのしきい値を超えるしきい値がある場合にのみ導入されるようです。 デルタストアのサイズを確認するには、次のクエリを実行して、テーブルの行内ページを確認します。 SELECT SUM([in_row_used_page_count]) AS in_row_used_pages, SUM(in_row_data_page_count) AS in_row_data_pages FROM sys.[dm_db_partition_stats] as pstats JOIN sys.partitions AS p ON pstats.partition_id = p.partition_id WHERE p.[object_id] = OBJECT_ID('Fact.RecordedMetricsDetail'); …

28 sql-server  sql-server-2014  columnstore  sql-server-2016 

SQL Server 2014の次のクエリプランを検討してください。 クエリプランでは、自己結合ar.fId = ar.fIdにより1行の推定値が得られます。しかし、これは論理的に矛盾する推定値は、次のとおりar有する20,608行とのちょうど1つの異なる値fId（正確に統計に反映します）。したがって、この結合は行（~424MM行）の完全な外積を生成し、クエリを数時間実行します。 SQL Serverが統計と矛盾していることが非常に簡単に証明できる見積もりを思い付く理由を理解するのに苦労しています。何か案は？ 初期調査と追加の詳細 ここでのPaulの回答に基づくと、結合のカーディナリティを推定するためのSQL 2012とSQL 2014の両方のヒューリスティックは、2つの同一のヒストグラムを比較する必要がある状況を簡単に処理できるようです。 トレースフラグ2363からの出力から始めましたが、それを簡単に理解できませんでした。以下は、SQL Serverがためにヒストグラムを比較していることを意味スニペットないfIdとbIdだけその用途に参加の選択を推定するためにfId？もしそうなら、それは明らかに正しくないでしょう。または、トレースフラグの出力を読み間違えていますか？ Plan for computation: CSelCalcExpressionComparedToExpression( QCOL: [ar].fId x_cmpEq QCOL: [ar].fId ) Loaded histogram for column QCOL: [ar].bId from stats with id 3 Loaded histogram for column QCOL: [ar].fId from stats with id 1 Selectivity: 0 完全な再現スクリプトに含まれ、このクエリをミリ秒にまで下げるいくつかの回避策を思いついたことに注意してください。この質問は、動作の理解、今後のクエリでの動作の回避方法、およびMicrosoftに提出する必要があるバグかどうかの判断に焦点を当てています。 ここで完全なREPROスクリプトは、ここにあるトレースフラグ2363年からフル出力は、ここであなたがすぐにいっぱいスクリプトを開くことなく、それらを見たい場合はクエリとテーブル定義は次のとおりです。 …

27 sql-server  query-performance  sql-server-2014  execution-plan  cardinality-estimates 

以下のクエリでは、両方の実行プランが一意のインデックスで1,000シークを実行すると推定されています。 シークは同じソーステーブルでの順序付けされたスキャンによって実行されるため、一見同じ順序で同じ値をシークする必要があります。 両方のネストされたループには <NestedLoops Optimized="false" WithOrderedPrefetch="true"> このタスクのコストが最初の計画では0.172434で、2番目の計画では3.01702である理由を誰もが知っていますか？ （質問の理由は、明らかにはるかに低い計画コストのために、最初のクエリが最適化として私に提案されたためです。 ） セットアップ CREATE TABLE dbo.Target(KeyCol int PRIMARY KEY, OtherCol char(32) NOT NULL); CREATE TABLE dbo.Staging(KeyCol int PRIMARY KEY, OtherCol char(32) NOT NULL); INSERT INTO dbo.Target SELECT TOP (1000000) ROW_NUMBER() OVER (ORDER BY @@SPID), LEFT(NEWID(),32) FROM master..spt_values v1, master..spt_values v2; INSERT INTO dbo.Staging …

27 sql-server  sql-server-2014  optimization 

について質問がありXTP_CHECKPOINTます。 SQL Server 2014を使用しています。シンプルリカバリモデルモードのデータベースがあります。また、複製されています。 開いているトランザクションはありません。私は実行しDBCC OPENTRAN、それが返されます： 「アクティブなオープントランザクションはありません。」 しかし、テーブルを作成または削除、またはデータを削除しようとするたびに、このメッセージが表示され続けます （実際のデータベース名をに置き換えましたdatabase_name）。 「データベース「database_name」のトランザクションログは、「XTP_CHECKPOINT」が原因でいっぱいです」 なぜこれが起こっているのか誰も知っていますか、そしてもっと重要なことは、どうすればそれを止めることができますか？ そして、はい、データベースは本当に単純復旧モデルモードです。つまり、トランザクションログは自動的に切り捨てられます。 ちなみに、完全復旧モードで使用している別のデータベースは同じことを行い、同じエラーを返し始めました。 データベース 'database_name'のトランザクションログは、 'XTP_CHECKPOINT'が原因でいっぱいです。 ログの増加設定を無制限の増加に変更しようとしましたが、同じエラーが返されてしまいました。 ファイルグループのみを除いて、XTPを一切使用せずに問題を再現できます。方法は次のとおりです。http：//pastebin.com/jWSiEU9U

26 sql-server  sql-server-2014  transaction-log  memory-optimized-tables 

文字列列と特定の長さの行をチェックする述語を持つテーブルがあります。SQL Server 2014では、チェックする長さに関係なく、1行の推定値が表示されます。実際には数千または数百万の行があり、SQL Serverはこのテーブルをネストされたループの外側に配置することを選択しているため、これは非常に貧弱な計画を生み出しています。 SQL Server 2012で31,622行を見積もる一方で、SQL Server 2014の1.0003のカーディナリティの見積もりについての説明はありますか？良い回避策はありますか？ 問題の簡単な複製を次に示します。 -- Create a table with 1MM rows of dummy data CREATE TABLE #customers (cust_nbr VARCHAR(10) NOT NULL) GO INSERT INTO #customers WITH (TABLOCK) (cust_nbr) SELECT TOP 1000000 CONVERT(VARCHAR(10), ROW_NUMBER() OVER (ORDER BY (SELECT NULL))) AS cust_nbr FROM master..spt_values v1 CROSS …

26 sql-server  sql-server-2014  functions  varchar  cardinality-estimates 

私はLIKE、未知のシナリオのすべての最適化で演算子を使用する場合、レガシーと新しいCEの両方が9％の見積もりを使用するという印象を受けました（関連する統計が利用可能であり、クエリオプティマイザーが選択性の推測に頼る必要がないと仮定）。 クレジットデータベースに対して以下のクエリを実行すると、CEごとに異なる推定値が得られます。新しいCEでは、予想していた900行の見積もりを受け取りますが、レガシーCEでは、241.416の見積もりを受け取りますが、この見積もりがどのように導出されるのかわかりません。誰もが光を当てることができますか？ -- New CE (Estimate = 900) DECLARE @LastName VARCHAR(15) = 'BA%' SELECT * FROM [Credit].[dbo].[member] WHERE [lastname] LIKE @LastName; -- Forcing Legacy CE (Estimate = 241.416) DECLARE @LastName VARCHAR(15) = 'BA%' SELECT * FROM [Credit].[dbo].[member] WHERE [lastname] LIKE @LastName OPTION ( QUERYTRACEON 9481, QUERYTRACEON 9292, QUERYTRACEON 9204, QUERYTRACEON …

24 sql-server  sql-server-2014  optimization  statistics  cardinality-estimates 

MERGEデータベースに対して発行される以下のステートメントがあります： MERGE "MySchema"."Point" AS t USING ( SELECT "ObjectId", "PointName", z."Id" AS "LocationId", i."Id" AS "Region" FROM @p1 AS d JOIN "MySchema"."Region" AS i ON i."Name" = d."Region" LEFT JOIN "MySchema"."Location" AS z ON z."Name" = d."Location" AND z."Region" = i."Id" ) AS s ON s."ObjectId" = t."ObjectId" WHEN NOT …

23 sql-server  sql-server-2014  merge  sql-server-2016 

破損を報告する空間インデックスがありDBCC CHECKDBます： DBCC CHECKDB(MyDB) WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS 空間インデックス、XMLインデックス、またはインデックス付きビュー 'sys.extended_index_xxx_384000'（オブジェクトID xxx）には、ビュー定義が生成するすべての行が含まれていません。これは、必ずしもこのデータベース内のデータの整合性の問題を表しているわけではありません。 空間インデックス、XMLインデックス、またはインデックス付きビュー 'sys.extended_index_xxx_384000'（オブジェクトID xxx）には、ビュー定義によって生成されなかった行が含まれています。これは、必ずしもこのデータベース内のデータの整合性の問題を表しているわけではありません。 CHECKDBは、テーブル 'sys.extended_index_xxx_384000'（オブジェクトID xxx）で0の割り当てエラーと2つの一貫性エラーを検出しました。 修理レベルはrepair_rebuildです。 インデックスを削除して再作成しても、これらの破損レポートは削除されません。なしでEXTENDED_LOGICAL_CHECKSはなくてDATA_PURITYエラーが報告されていません。 また、CHECKTABLECIのサイズは30 MBで、約3万行ありますが、このテーブルには45分かかります。そのテーブルのすべてのデータはポイントgeographyデータです。 この動作はどのような状況でも予想されますか？「これは必ずしも整合性の問題を表しているわけではありません」と書かれています。私はどうしたらいいですか？CHECKDB失敗しています。これは問題です。 このスクリプトは問題を再現します： CREATE TABLE dbo.Cities( ID int NOT NULL, Position geography NULL, CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED ( ID ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, …

23 sql-server  sql-server-2014  spatial  dbcc-checkdb 

私には理解できない状況があります。SQL Serverの実行計画では、テーブルの統計が欠落していると表示されますが、統計は既に作成されています。 しかし、テーブルを見ると、自動的に作成された統計があることがわかります。 誰かがそれがどのようになり得るかを理解するのを助けることができますか？ Auto_UpdateおよびAuto_Create統計は、現在のDBでオンになっています。 SQL Server 2014を使用しています。

23 sql-server  sql-server-2014  statistics 

75億行と5つのインデックスを持つ大きなテーブルがあります。約1,000万行を削除すると、非クラスター化インデックスが格納されているページ数を増やすように見えることに気付きました。 私はdm_db_partition_statsページの違いを報告するためのクエリを書きました（後-前）： インデックス1はクラスター化インデックス、インデックス2は主キーです。その他は非クラスター化され、一意ではありません。 これらの非クラスター化インデックスでページが増えているのはなぜですか？ 数値は最悪でも同じままになると予想していました。 削除中にパフォーマンスカウンターがページ分割の増加を報告するのを見ます。 削除するとき、ゴーストレコードは別のページに移動する必要がありますか？これは「一意性」と関係がありますか？ 私たちはRCSIの展開を進めていますが、現在、RCSIはオフになっています。 これは、可用性グループのプライマリノードです。私はスナップショットがセカンダリで何らかの形で使用されていることを知っています。それが関連していた場合、私は驚くでしょう。これを掘り下げて（dbccページの出力を調べて）詳細を調べる予定です。誰かが似たようなものを見たことを願っています。

22 sql-server  sql-server-2014  nonclustered-index 

私は大きなテーブルのさまざまなアーキテクチャをテストしていますが、私が見た提案の1つは、大きなテーブルを一連の小さな「パーティション」テーブルに分割するパーティションビューを使用することです。 1、2、3、4 このアプローチをテストする中で、あまり意味をなさない何かを発見しました。ファクトビューの「パーティション列」でフィルタリングすると、オプティマイザーは関連するテーブルのみを検索します。さらに、ディメンションテーブルのその列でフィルタリングすると、オプティマイザーは不要なテーブルを削除します。 ただし、ディメンションの他の側面でフィルタリングすると、オプティマイザーは各ベーステーブルのPK / CIを検索します。 問題のクエリは次のとおりです。 select od.[Year], AvgValue = avg(ObservationValue) from dbo.v_Observation o join dbo.ObservationDates od on o.ObservationDateKey = od.DateKey where o.ObservationDateKey >= 20000101 and o.ObservationDateKey <= 20051231 group by od.[Year]; select od.[Year], AvgValue = avg(ObservationValue) from dbo.v_Observation o join dbo.ObservationDates od on o.ObservationDateKey = od.DateKey where od.DateKey …

22 sql-server  sql-server-2014  partitioning 

増分統計を利用する大規模なパーティションSQL Serverデータベースがあります。すべてのインデックスはパーティション分割されています。パーティションごとにオンラインでパーティションを再構築しようとすると、インデックスが再構築された後にすべての統計が消えます。 以下は、AdventureWorks2014データベースを使用してSQL Server 2014の問題を再現するスクリプトです。 --Example against AdventureWorks2014 Database CREATE PARTITION FUNCTION TransactionRangePF1 (DATETIME) AS RANGE RIGHT FOR VALUES ( '20130501', '20130601', '20130701', '20130801', '20130901', '20131001', '20131101', '20131201', '20140101', '20140201', '20140301' ); GO CREATE PARTITION SCHEME TransactionsPS1 AS PARTITION TransactionRangePF1 TO ( [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], …

21 sql-server  sql-server-2014  partitioning  statistics