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

セットアップ カーディナリティの推定値を理解するのに苦労しています。テストのセットアップは次のとおりです。 Stack Overflowデータベースの2010バージョン SQL Server 2017 CU15 + GDR（KB4505225）-14.0.3192.2 新しいCE（互換性レベル140） 私はこのプロシージャを持っています： USE StackOverflow2010; GO CREATE OR ALTER PROCEDURE #sp_PostsByCommentCount @CommentCount int AS BEGIN SELECT * FROM dbo.Posts p WHERE p.CommentCount = @CommentCount OPTION (RECOMPILE); END; GO dbo.Postsテーブルに非クラスター化インデックスまたは統計がありません（にクラスター化インデックスがありますId）。 このための推定プランを要求すると、「推定行」dbo.Postsは1,934.99になります。 EXEC #sp_PostsByCommentCount @CommentCount = 51; 次の統計オブジェクトは、推定プランを要求したときに自動的に作成されました。 DBCC SHOW_STATISTICS('dbo.Posts', [_WA_Sys_00000006_0519C6AF]); そのハイライトは次のとおりです。 統計のサンプルレートは1.81％と非常に低い（67,796 …

14 sql-server  sql-server-2017  statistics  database-internals  cardinality-estimates 

8週間エラーがなかった後、過去数日間でこの奇妙なエラーに3回遭遇しましたが、困惑しています。 これはエラーメッセージです。 Executing the query "EXEC dbo.MergeTransactions" failed with the following error: "Cannot insert duplicate key row in object 'sales.Transactions' with unique index 'NCI_Transactions_ClientID_TransactionDate'. The duplicate key value is (1001, 2018-12-14 19:16:29.00, 304050920).". インデックスは一意ではありません。気付いた場合、エラーメッセージ内の重複キー値はインデックスと一致していません。奇妙なことは、プロシージャを再実行すると成功することです。 これは私の問題がある最新のリンクですが、解決策が見つかりません。 https://www.sqlservercentral.com/forums/topic/error-cannot-insert-duplicate-key-row-in-a-non-unique-index 私のシナリオに関するいくつかのこと： procはTransactionID（主キーの一部）を更新しています-これがエラーの原因であると思いますが、理由はわかりませんか？そのロジックを削除します。 テーブルで変更追跡が有効になっています コミットされていないトランザクションの読み取りを行う 各テーブルには45のフィールドがあり、主にインデックスで使用されるものをリストしました。update文のTransactionID（クラスター化キー）を（不必要に）更新しています。奇妙なことに、先週まで何ヶ月も問題がなかった。そして、それはSSISを介して散発的にのみ発生します。 テーブル USE [DB] GO /****** Object: Table [sales].[Transactions] Script …

14 sql-server  update  sql-server-2017 

SQL Server 2016インスタンスからデータベースのバックアップを作成し、2017年のインスタンスに復元して作業を行う場合。 次に、2017年のインスタンスからそのデータベースを反転してバックアップし、それを使用して2016年のインスタンスの元のバージョンを上書きできますか？

13 sql-server  backup  sql-server-2016  restore  sql-server-2017 

問題 シリアライズ可能な分離の下で、RX-Xロックを引き起こすクエリのペアがあります。ただし、拡張イベントを使用してロックの取得を監視すると、RX-Xロックの取得は表示されず、リリースされるだけです。それはどこから来たのですか？ 再現 私のテーブルは次のとおりです。 CREATE TABLE dbo.LockTest ( ID int identity, Junk char(4) ) CREATE CLUSTERED INDEX CX_LockTest --not unique! ON dbo.LockTest(ID) --preload some rows INSERT dbo.LockTest VALUES ('data'),('data'),('data') ここに私の問題のバッチがあります： SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRAN INSERT dbo.LockTest VALUES ('bleh') SELECT * FROM dbo.LockTest WHERE ID = SCOPE_IDENTITY() --ROLLBACK …

13 sql-server  locking  sql-server-2017 

physical_onlyオプションを指定してcheckdbを実行していますが、次のような複数のエラーで失敗します。 メッセージ8965、レベル16、状態1、行1 テーブルエラー：オブジェクトID 1557580587、インデックスID 1、パーティションID 72057594088456192、割り当てユニットID 72057594177454080（行データ型）。ページ（1：13282192）、スロット3、テキストID 6370769698816の行外データノードは、ページ（0：0）、スロット0で参照されますが、スキャンでは表示されませんでした。メッセージ8965、レベル16、状態1、行1 テーブルエラー：オブジェクトID 1557580587、インデックスID 1、パーティションID 72057594088456192、割り当てユニットID 72057594177454080（行データ型）。ページ（1：13282192）、スロット5、テキストID 6370769764352の行外データノードは、ページ（0：0）、スロット0で参照されますが、スキャンでは表示されませんでした。 CHECKDBは、テーブル 'TableX'（オブジェクトID 1557580587）で0の割り当てエラーと5255の一貫性エラーを検出しました。CHECKDBは、データベース 'DatabaseX'で0の割り当てエラーと5255の一貫性エラーを検出しました。repair_allow_data_lossは、DBCC CHECKDB（DWH_LAND）によって検出されたエラーの最小修復レベルです。 ただし、完全なcheckdbは成功します。 CHECKDBは、データベース 'DatabaseX'で0の割り当てエラーと0の一貫性エラーを検出しました。DBCCの実行が完了しました。DBCCがエラーメッセージを出力した場合は、システム管理者に連絡してください。 TableXには約20万行があり、クラスター化された列ストアインデックスがあります。 次のバージョンのSQL Serverを使用しています： Microsoft SQL Server 2017（RTM-CU13）（KB4466404）-14.0.3048.4 心配する必要がありますか？

13 sql-server  sql-server-2017  dbcc-checkdb 

これは、この質問のフォローアップです。また、Microsoftからのこの機能要求に関連しています。 しかし、報告されてから長年が経過し、いくつかのメジャーリリースが市場に届きました。 質問： SQL Server 2017には、このエラーの根本原因の特定を容易にするメカニズムがありますか？または、問題が報告された約9年前と同じくらい調査するのは難しいですか？

13 sql-server  sql-server-2017  string  truncation 

SQL Server 2017（CU3）では、TDEデータベースの1つでバックアップ圧縮を有効にすると、バックアッププロセスによってデータベースの特定のページが常に破損します。圧縮せずにバックアップを実行しても、破損しません。この問題を確認して再現するために行った手順は次のとおりです。 データベース「TDE_DB1」でDBCC CheckDBを実行します。すべてが良好で、エラーはありません。 圧縮せずにデータベースを正常にバックアップします。RESTORE VERIFYONLYはすべてが良いと言っています。 データベースを「TDE_DB2」として正常に復元します。すべて良好で、DBCC CheckDBはエラーを表示しません。 「TDE_DB1」データベースを圧縮して正常にバックアップします。「バックアップセットへの損傷が検出されました」と言うVERIFYONLYエラーを復元します。 データベースを「TDE_DB2」として復元しようとします。「データベースでページ（1：92454）でエラーが検出されました」というエラー 手順1〜3を繰り返します。すべてが良いです; DROP "TDE_DB1"および "TDE_DB2"; バックアップから「TDE_DB1」を復元します。すべてが良いです; 手順1〜5を繰り返します。同じ結果が得られます。 要約すると、データベースと通常のバックアップは正常に見え、データベースでCHECKDBを実行し、バックアップでVERIFYONLYを実行してもエラーは報告されません。圧縮を使用してデータベースをバックアップすると、破損が発生するようです。 以下にエラーのあるコードサンプルを示します。（注：TDEデータベースで圧縮を使用するには、MAXTRANSFERSIZEが必要です） -- Good, completes with no corruption; BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM; RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM; RESTORE DATABASE [TDE_DB2] FROM DISK = 'E:\MSSQL\Backup\TDE_DB1a.bak' WITH …

13 sql-server  corruption  transparent-data-encryption  sql-server-2017 

最近、5億行に近いテーブルにNULL可能ビット列を追加しました。列にはデフォルトはありませんが、すべての挿入で0または1の値が指定されています。1回限りのルーチンを実行して、既存のすべての行に0または1を割り当てます（小さなバッチで行を更新します）。これで、すべての行の列に0または1が表示されます。 ビット列をnull不可にしたいのですがALTER TABLE t1 ALTER COLUMN c1 bit not null、で実行しようとしたときに3分実行され、テーブルへのすべての読み取りをブロックしていたため停止しましたが、完了するまでに時間がかかると思われました。それほど時間がかからない可能性はありますが、利用できないリスクを冒すことはできません。ロールバック自体は6分かかりました。 完了するまでに何時間もかかることなく、列をnull不可にする方法について提案はありますか？ さらに、ALTER TABLE ALTER COLUMN開始してからキャンセルしたステートメントが完了するまでにかかる時間を見積もる方法はありますか？ SQL Server 2017 Web Editionを使用しています。

12 sql-server  sql-server-2017  alter-table  null 

いくつかのNVARCHAR(4000)列でこのテーブルを処理する非常に大きなメモリ許可でパフォーマンスの問題があります。これらの列はより大きいことはありませんNVARCHAR(260)。 を使用して ALTER TABLE [table] ALTER COLUMN [col] NVARCHAR(260) NULL SQL Serverはテーブル全体を書き換えます（ログスペースで2倍のテーブルサイズを使用します）。これは何十億行で、何も変更しないだけで、オプションではありません。列の幅を大きくしてもこの問題はありませんが、小さくすると問題が発生します。 制約を作成しようとしたCHECK (DATALENGTH([col]) <= 520)かCHECK (LEN([col]) <= 260)、SQL Serverがテーブル全体を書き直すことにしました。 列のデータ型をメタデータのみの操作として変更する方法はありますか？テーブル全体を書き換える費用なしで？SQL Server 2017（14.0.2027.2および14.0.3192.2）を使用しています。 以下は、再現に使用するサンプルDDLテーブルです。 CREATE TABLE [table]( id INT IDENTITY(1,1) NOT NULL, [col] NVARCHAR(4000) NULL, CONSTRAINT [PK_test] PRIMARY KEY CLUSTERED (id ASC) ); そして、を実行しALTERます。

12 sql-server  sql-server-2017  alter-table 

データベースSQL Server 2017 Enterprise CU16 14.0.3076.1 最近、デフォルトのIndex RebuildメンテナンスジョブからOla Hallengrenへの切り替えを試みましたIndexOptimize。デフォルトのインデックス再構築ジョブは問題なく数か月間実行されており、クエリと更新は許容可能な実行時間で機能していました。IndexOptimizeデータベースで実行した後： EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 5, @FragmentationLevel2 = 30, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y' パフォーマンスが極端に低下しました。IndexOptimize100ミリ秒かかった更新ステートメントは、その後78.000ミリ秒かかり（同じプランを使用）、クエリのパフォーマンスも数桁悪化していました。 これはまだテストデータベースであるため（Oracleから運用システムを移行しています）、バックアップにIndexOptimize戻り、無効にしてすべてを通常に戻しました。 ただし、この極端なパフォーマンスの低下を引き起こす可能性のIndexOptimizeある「通常」Index Rebuildとは何が異なるのかを理解して、本番環境に移行したときにそれを回避できるようにします。何を探すべきかについての提案は大歓迎です。 遅い場合の更新ステートメントの実行計画。すなわち、 IndexOptimizeの実際の実行計画の後 （できるだけ早く） 違いを見つけることができませんでした。 高速な場合は同じクエリを計画する 実際の実行計画

12 sql-server  sql-server-2017  ola-hallengren  index-maintenance 

このクエリをご覧ください。それは非常に簡単です（テーブルとインデックスの定義、および再現スクリプトについては投稿の最後をご覧ください）： SELECT MAX(Revision) FROM dbo.TheOneders WHERE Id = 1 AND 1 = (SELECT 1); 注：「AND 1 =（SELECT 1）は、このクエリが自動パラメータ化されないようにするためのものです。これは問題を混乱させているように感じました。 そして、これがプランです（プランのリンクを貼り付けてください）： そこには「トップ1」があるので、ストリーム集約演算子を見て驚いた。1行のみであることが保証されているので、私には必要ないようです。 その理論をテストするために、この論理的に同等のクエリを試しました。 SELECT MAX(Revision) FROM dbo.TheOneders WHERE Id = 1 GROUP BY Id; これがその計画です（計画のリンクを貼り付けてください）： 案の定、group by planは、ストリーム集約演算子なしで対応できます。 両方のクエリがインデックスの最後から「後方」を読み取り、「トップ1」を実行して最大リビジョンを取得することに注意してください。 ここで何が欠けていますか？ ストリーム集合体は最初のクエリで実際に動作するのですか、それとも排除する必要がありますか（それはオプティマイザーの制限であり、そうではありません）？ ちなみに、これは信じられないほど実用的な問題ではないことを認識しています（クエリは両方ともCPUの0ミリ秒と経過時間を報告します）。 上記の2つのクエリを実行する前に実行したセットアップコードを次に示します。 DROP TABLE IF EXISTS dbo.TheOneders; GO CREATE TABLE dbo.TheOneders …

12 sql-server  group-by  aggregate  sql-server-2017  database-internals 

コンピューターにSQL Server 2017がインストールされています。これは何をSELECT @@VERSION返します： Microsoft SQL Server 2017（RTM-GDR）（KB4293803）-14.0.2002.14（X64）2018年7月21日07:47:45 Copyright（C）2017 Microsoft Corporation Enterprise Edition（64-bit）on Windows 10 Enterprise 10.0（Build 17134： ） ` 昨日まで問題なく動作していました。突然SQL SERVER Service実行されませんでした。私が手動でサービスを実行したいとき、それは示した3417 error。イベントログを確認すると、次のエラーが表示されました。 アップグレードステップ 'msdb110_upgrade.sql'でエラー200、状態7、重大度25が発生したため、データベース 'master'のスクリプトレベルのアップグレードに失敗しました。これは、通常の操作を妨げる重大なエラー状態であり、データベースがオフラインになります。'master'データベースのアップグレード中にエラーが発生した場合、SQL Serverインスタンス全体が起動しなくなります。以前のエラーログエントリのエラーを調べ、適切な修正アクションを実行し、データベースを再起動して、スクリプトのアップグレード手順が完了するまで実行します。 いくつかのグーグル検索の後、私はそれを実行し/T902 switchて問題を解決しようとすることがわかりました。しかし、解決策はありませんでした。そこで、同じSQL SERVER 2017データベースの別のインスタンスをインストールし、データベースを復元しました。これで、新しくインストールされたインスタンスにも同じ問題が発生します。 何が問題なのでしょうか？ 更新 ここに、SQL Serverの完全なエラーログがあります。 2018-09-17 13：06：47.29 spid6s構成オプション「詳細オプションの表示」が1から1に変更されました。RECONFIGUREステートメントを実行してインストールします。 2018-09-17 13：06：47.29 spid6s構成オプション「詳細オプションの表示」が1から1に変更されました。RECONFIGUREステートメントを実行してインストールします。 2018-09-17 13：06：47.29 spid6s構成オプション 'Agent XPs'が1から1に変更されました。RECONFIGUREステートメントを実行してインストールします。 2018-09-17 13：06：47.29 spid6s構成オプション …

12 sql-server  sql-server-2017  character-set  encoding 

ドキュメントは、 SQL Serverを削除する方法について説明しています。ただし、これにより特定のパッケージが残ります。すべてのトレースを削除してSQL Server 2017をアンインストールするにはどうすればよいですか？

12 sql-server  linux  installation  ubuntu  sql-server-2017 

一部の重複を削除しようとする特定のクリーンアップコードがあります。 これは多くの顧客サイトで完全に実行されます。ログから、このクエリでは少なくとも1秒から45秒が消費されていることがわかります。 DELETE FROM [tbl] WHERE [Id] NOT IN ( SELECT MIN([Id]) FROM [tbl] GROUP BY [IdProject], [IdRepresentative], [TimeStart] ) しかし、私はこのクエリを4時間以上（現在までで、終了しない）実行している顧客がいます！私はDBをチェックしました（DBCC CHECKDB）、統計情報を更新しました（sp_updatestats）もUPDATE STATISTICS [tbl] WITH FULLSCAN変更を示していません。 お客様からDBの元のバックアップがあります。SQL Server 14.0.2002.14で実行しています。Standard Editionを持っていますが、お客様はExpress Editionを使用しています。 他の誰もDBを使用していないことをアクティビティモニターで確認できます。待機時間はなく、CPUは25％使用されています（4つのCPUのうちの1つのみ）。また、この私のテストケースでは、他の誰もDBを使用していません。 私はクエリを再構成し、このステートメントをチェックしました： DELETE FROM [tbl] FROM [tbl] AS t LEFT OUTER JOIN ( SELECT MIN([Id]) AS [IdMin] FROM [tbl] …

11 sql-server  query-performance  execution-plan  sql-server-2017  cardinality-estimates 

実際の実行プランでプラン表示分析（SSMS）を使用して、パフォーマンスの遅いクエリをトラブルシューティングしようとしています。分析ツールは、行数の見積もりが計画のいくつかの場所で返された結果からずれていることを指摘し、さらにいくつかの暗黙の変換警告を与えます。 これらのintからVarcharへの暗黙的な変換を理解できません-参照されるフィールドはクエリのパラメーター/フィルターの一部ではなく、関係するすべてのテーブルで列のデータ型は同じです： 以下のCardinalityEstimate警告が表示されます。 式の型変換（CONVERT_IMPLICIT（varchar（12）、[ccd]。[profileid]、0））は、クエリプランの選択で "CardinalityEstimate"に影響を与える可能性があります-このフィールドは、私のDB内のすべての整数です 式の型変換（CONVERT_IMPLICIT（varchar（6）、[ccd]。[nodeid]、0））は、クエリプランの選択で "CardinalityEstimate"に影響を与える可能性があります-このフィールドは、私のDBのあらゆる場所でsmallintです 式の型変換（CONVERT_IMPLICIT（varchar（6）、[ccd]。[sessionseqnum]、0））は、クエリプランの選択で "CardinalityEstimate"に影響を与える可能性があります-このフィールドは、DB内のあらゆる場所で小さな整数です 式の型変換（CONVERT_IMPLICIT（varchar（41）、[ccd]。[sessionid]、0））は、クエリプランの選択で "CardinalityEstimate"に影響する可能性があります-このフィールドは、DBのすべての場所で10進数です [編集]参照用のクエリと実際の実行計画は次の とおりですhttps://www.brentozar.com/pastetheplan/?id=SysYt0NzN そして、テーブルの定義。 /****** Object: Table [dbo].[agentconnectiondetail] Script Date: 1/10/2019 9:10:04 AM ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].[agentconnectiondetail]( [sessionid] [decimal](18, 0) NOT NULL, [sessionseqnum] [smallint] NOT NULL, [nodeid] [smallint] NOT NULL, [profileid] [int] …

11 sql-server  execution-plan  sql-server-2017  type-conversion  cardinality-estimates