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

この接続アイテムのサンプルコード バグを示します SELECT COUNT(*) FROM dbo.my_splitter_1('2') L1 INNER JOIN dbo.my_splitter_1('') L2 ON L1.csv_item = L2.csv_item 正しい結果を返します。ただし、次の例では誤った結果が返されます（2014年、新しいCardinality Estimatorを使用） SELECT (SELECT COUNT(*) FROM dbo.my_splitter_1('2') L1 INNER JOIN dbo.my_splitter_1('') L2 ON L1.csv_item = L2.csv_item) L2の結果が共通のサブ式スプールに誤ってロードされ、L1の結果の結果が再生されるためです。 2つのクエリの動作の違いがなぜなのか興味がありました。トレースフラグ8675は、動作search(0) - transaction processingするものが入り、失敗するものが入っていることを示していますsearch(1) - quick plan。 したがって、追加の変換ルールの可用性は動作の違いの背後にあると考えられます（BuildGbApplyまたはGenGbApplySimpleを無効にすると、たとえば修正されるようです）。 しかし、これらの非常によく似たクエリの2つの計画で、異なる最適化フェーズが発生するのはなぜですか？私が読んだことからsearch (0)、少なくとも3つのテーブルが必要であり、最初の例ではその条件は確かに満たされていません。

12 sql-server  optimization  database-internals 

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED私が一般的なSQLクエリの大部分で使用しているのは、主に言語を最初に学習したときにこれがドリルダウンされたためです。 私の理解では、この分離レベルは、WITH (NO LOCK)私が使用する傾向があるのと同じように機能しますSET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED。 私が使用してしなければならないという時間今までありWITH (NO LOCK)オーバーがSET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED。 DOESは SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED私が読んでいていることの表からロックアウトされることから、他のユーザーを停止しますか？ 場合は SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED、ストップロックに使用されているが、私はデータのみを読んでいます、それを使用してのポイントは何ですか？ロックを生成するのはシステム集中型のクエリだけですか？たとえば5〜10秒で返されるクエリを実行するときに使用する価値はありますか。 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDおそらくダーティデータの更新を避けるために、更新で使用されるデータを読み取るときは使用しないように言わ れました。これが唯一の理由でしょうか？ 私が取り組んでいるデータベースのタイプには、実稼働環境とテスト環境があります。実稼働環境にクエリを実行することはほとんどありませんが、必要に応じて、通常SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDはクエリで使用します。これでダーティリードが可能であることを理解しています。最終的にデータベースにコミットされない可能性のあるデータを受信する（そして結果を破棄する）以外に、他の種類の「ダーティリード」は可能ですか？ 大量の質問で申し訳ありません。

12 sql-server  isolation-level 

SQL Serverサービスを再起動せずにtempdbファイルをSQL Serverに追加できるかどうかを確認しようとしています。私はここでデータベース管理者にこの答えを見ました： Tempdbファイルの追加には再起動が必要 そして1つの答えは次のとおりです。 追加-停止は不要です。MicrosoftのSeanが指摘したように、SQLはより低い値のファイルを使用することを好みます。1つのデータファイルから追加する場合、SQLはしばらくの間新しいデータファイルを使用しますが、ファイルが1つしかない場合よりもパフォーマンスは低下しません。ただし、すでに2+があり、もう1つ追加すると、新しいホットスポットにホットスポットが追加され、パフォーマンスが低下します。 ただし、コメントでは次の点に注意してください。 「追加」の部分に補遺を追加します。「追加：いいえ。ただし、不均衡になる可能性が高いため、ホットスポットになり、事態がさら​​に悪化する可能性があります。」 私はそのコメントについて次の質問を持っていますが、その質問の回答のコメントを介してコメンターに質問するのではなく、自分の新しい質問（この質問）で質問するように指示されました。 具体的には： ホットスポットとは何ですか？（Google経由で情報を入手しましたが、ファイルを追加した後にtempdbでホットスポッティングを行うと何が起こるか詳細に説明しませんでした） ホットスポットはtempdbの状況をさらに悪化させますか？ DBのどの特定のものがさらに悪化しますか？

12 sql-server  tempdb  troubleshooting 

最近、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 

<inputbuf>デッドロック拡張イベントセッションによってキャプチャされたデッドロックXMLの要素のサイズを増やす方法はありますか？ アプリケーションコードで問題を特定するのに役立つ完全なクエリが必要です。 1024文字+/-に制限されているようです。増やすことはできますか？ サンプルXMLについては、以下を参照してください。<inputbuf>要素のクエリテキストが選択リストの中央で途切れていることがわかります。 <deadlock> <victim-list> <victimProcess id="processc9c0829848" /> </victim-list> <process-list> <process id="processc9c0829848" taskpriority="0" logused="0" waitresource="PAGE: 5:1:40600276 " waittime="696" ownerId="255115931225" transactionname="SELECT" lasttranstarted="2019-04-24T09:29:25.950" XDES="0xc8dfa8da40" lockMode="S" schedulerid="13" kpid="8480" status="suspended" spid="245" sbid="2" ecid="0" priority="0" trancount="0" lastbatchstarted="2019-04-24T09:29:25.950" lastbatchcompleted="2019-04-24T09:29:25.950" lastattention="1900-01-01T00:00:00.950" clientapp="EntityFramework" hostname="MSR-PRD-BDB02" hostpid="43440" loginname="IUSR_BuildDB" isolationlevel="read committed (2)" xactid="255115931225" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"> <executionStack> <frame procname="adhoc" …

12 sql-server  sql-server-2016  deadlock  extended-events 

データベース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 

アプリケーションのスローダウンを診断しようとしています。このために、SQL Server 拡張イベントを記録しました。 この質問では、1つの特定のストアドプロシージャを見ています。 しかし、リンゴからリンゴへの調査として同様に使用できる12個のストアドプロシージャのコアセットがあります。 ストアドプロシージャの1つを手動で実行すると、常に高速に実行されます また、ユーザーが再試行した場合、高速で実行されます。 ストアドプロシージャの実行時間は大きく異なります。このストアドプロシージャの実行の多くは1秒未満で返されます。 そして、その「高速」バケットについては、1秒よりはるかに少ないです。実際には約90ミリ秒です。 しかし、2秒、3秒、4秒待たなければならない長いユーザーがいます。12、13、14秒待たなければならない人もいます。それから、22、23、24秒待たなければならない本当に貧しい魂がいます。 そして、30秒後、クライアントアプリケーションはあきらめ、クエリを中止し、ユーザーは30秒待つ必要がありました。 原因を見つけるための相関 だから私は相関させようとしました： 期間と論理読み取り 継続時間と物理読み取り 期間とCPU時間 また、相関関係を与えるものはありません。原因はないようです 継続時間と論理読み取り：少しでも多くの論理読み取りでも、継続時間は大きく変動します： 期間対物理読み取り：クエリがキャッシュから提供されず、多くの物理読み取りが必要な場合でも、期間には影響しません。 duration vs cpu time：クエリが0秒のCPU時間を使用した場合でも、2.5秒のCPU時間を使用した場合でも、期間の変動は同じです。 ボーナス：Duration v Physical ReadsとDuration v CPU timeが非常に似ていることに気付きました。これは、CPU時間を物理読み取りと相関させようとすると証明されます。 多くのCPU使用率がI / Oに由来することが判明しました。誰かわかったね！ それで、実行時間の違いを説明できるクエリを実行する行為について何もなければ、それはそれがCPUまたはハードドライブとは無関係な何かであることを意味しますか？ CPUまたはハードドライブがボトルネックだった場合。それがボトルネックではないでしょうか？ ボトルネックはCPUであると仮定した場合、このサーバーのCPUの電力が不足していること： その後、より多くのCPU時間を使用した実行に時間がかかりませんか？ 過負荷のCPUを使用して他の人と完了する必要がありますか？ ハードドライブについても同様です。ハードドライブがボトルネックであると仮定した場合、ハードドライブがこのサーバーに十分なランダムスループットを持たないこと： その後、より多くの物理読み取りを使用した実行には時間がかかりませんか？ 過負荷のハードドライブI / Oを使用して他の人と完了する必要があるためですか？ ストアドプロシージャ自体は、書き込みも実行も要求もしません。 通常、0行（90％）を返します。 時折、1行（7％）を返します。 まれに2行（1.4％）が返されます。 そして最悪の場合、2行以上を返しました（一度に12行を返しました） したがって、異常な量のデータを返しているわけではありません。 サーバーのCPU使用率 …

12 sql-server  sql-server-2012 

このクエリをご覧ください。それは非常に簡単です（テーブルとインデックスの定義、および再現スクリプトについては投稿の最後をご覧ください）： 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 

短い質問がありますが、なぜuse master;データベースの作成に使用するのですか？ここでの例は、Microsoftのドキュメントからは、 USE master ; GO CREATE DATABASE Sales ON ( NAME = Sales_dat, FILENAME = 'C:\Program Files\...\saledat.mdf', SIZE = 10, MAXSIZE = 50, FILEGROWTH = 5 ) LOG ON ( NAME = Sales_log, FILENAME = 'C:\Program Files\...\salelog.ldf', SIZE = 5MB, MAXSIZE = 25MB, FILEGROWTH = 5MB ) ;

12 sql-server  t-sql  ddl  master-system-database 

コンピューターに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データベースがあります。 CREATE DATABASE AUDIT SPECIFICATION [dbAudit] FOR SERVER AUDIT [servAudit] ADD (EXECUTE ON DATABASE::[DatabaseName] BY [public]) 一部のクエリは、結果セットのすべての行に対してスカラー関数の使用を監査ログに書き込むことがわかっています。これが発生すると、ログがETLで最終的な休憩場所に達する前にログがいっぱいになり、ログにギャップが生じます。 残念ながら、コンプライアンス上の理由により、すべてのEXECUTEステートメントの監査を停止することはできません。 この問題へのアプローチについて最初に考えたのはWHERE、サーバー監査の句を使用してアクティビティを除外することです。コードは次のようになりました。 WHERE [object_id] not in (Select object_id from sys.objects where type = 'FN' ) 残念ながら、SQL ServerはリレーショナルIN演算子を許可しません（おそらく、監査ログに書き込む必要があるたびにクエリを実行したくないためです）。 私たちは、どのハードコードストアドプロシージャ書き込みを避けたいobject_idにWHERE句が、それは、この問題にアプローチする最良の方法で私たちの現在の考え方です。考慮すべき代替アプローチはありますか？ 再帰CTEでスカラー関数が使用されている場合、結果セット内のすべての行の監査ログにクエリが書き込まれることに気付きました。 ベンダーが提供するいくつかのスカラー値関数がありますが、それらを削除したり、代替データベースに移動したりすることはできません。

12 sql-server  functions  audit  cte  recursive 

可能な限り均等に、一定数のトラックに注文を積むという観点から問題を説明します。 入力： @TruckCount - the number of empty trucks to fill セット： OrderId, OrderDetailId, OrderDetailSize, TruckId (initially null) Ordersは1つ以上で構成されますOrderDetails。 ここでの課題は、TruckId各レコードにを割り当てることです。 1つの注文を複数のトラックに分割することはできません。 トラックは、で測定し、可能な限り均等に*積む必要がありますsum(OrderDetailSize)。 *均等：最小積載量のトラックと最大積載量のトラック間の達成可能な最小のデルタ。この定義により、1,2,3は1,1,4よりも均等に分散されます。役立つ場合は、統計アルゴリズムになり、高さのヒストグラムも作成します。 トラックの最大積載量は考慮されていません。これらは魔法の弾力性のあるトラックです。ただし、トラックの数は固定されています。 明らかに反復的な解決策があります-ラウンドロビンは注文を割り当てます。 しかし、それはセットベースのロジックとして実行できますか？ 私の主な関心は、SQL Server 2014以降です。しかし、他のプラットフォーム用のセットベースのソリューションも興味深いかもしれません。 これは、Itzik Ben-Ganの領土のように感じます:) 私の実際のアプリケーションでは、処理ワークロードを論理CPUの数に合わせて多数のバケットに分散しています。したがって、各バケットには最大サイズはありません。特に統計の更新。チャレンジを組み立てる方法として、問題をトラックに抽象化する方が楽しいと思いました。 CREATE TABLE #OrderDetail ( OrderId int NOT NULL, OrderDetailId int NOT NULL PRIMARY KEY, OrderDetailSize tinyint NOT NULL, …

12 sql-server  sql-server-2014  query 

クエリに特定のプランを使用するようにSQL Serverをだます方法があるかどうかを確認しようとしています。 1.環境 異なるプロセス間で共有されるデータがあるとします。したがって、多くのスペースをとるいくつかの実験結果があるとします。その後、各プロセスについて、使用する実験結果の年/月を特定します。 if object_id('dbo.SharedData') is not null drop table SharedData create table dbo.SharedData ( experiment_year int, experiment_month int, rn int, calculated_number int, primary key (experiment_year, experiment_month, rn) ) go これで、すべてのプロセスについて、テーブルにパラメーターが保存されました if object_id('dbo.Params') is not null drop table dbo.Params create table dbo.Params ( session_id int, experiment_year int, experiment_month int, …

12 sql-server  query-performance  sql-server-2016  functions 

Dynamics AXには、メモリにロードしてキャッシュするようにテーブルを構成できるキャッシュメカニズムがあります。このキャッシュは、メモリの問題を防ぐために一定のKBに制限されています。私が話している設定は呼び出さentiretablecacheれ、単一のレコードが要求されるとすぐにテーブル全体をメモリにロードします。 最近まで、いくつかのスクリプトに依存して、この設定を持つテーブルのサイズを検証し、テーブルサイズがこの制限を超えているかどうかを確認していました。 しかし、今では圧縮が作用し始めており、sp_spaceusedやsys.allocation_unitsのようなものが、圧縮されたデータによって実際に使用されているスペースを報告しているようです。 明らかに、アプリケーションサーバーは圧縮されていないデータを処理しているため、SQL Serverのディスク上のデータサイズは無関係です。非圧縮データの実際のサイズが必要です。 私はsp_estimate_data_compression_savingsを知っていますが、名前が示すように、これは単なる見積もりです。 サイズをできるだけ正確にしたいと思います。 私が考えることができる唯一の方法は、圧縮テーブルと同じ構造の非圧縮テーブルを作成し、そのシャドウテーブルに圧縮データを挿入し、そのシャドウテーブルのサイズを確認する、複雑な動的SQLでした。 言うまでもなく、これは少し面倒で、数百GBのデータベースで実行するには時間がかかります。 Powershellはオプションの可能性がありますが、すべてのテーブルを反復処理しselect *てスクリプトでサイズを確認するのは好ましくありません。 要するに、可能であれば、アプリケーションに提示された方程式から断片化された状態で圧縮されないため、各テーブルのサイズを取得する方法が必要です。私はさまざまなアプローチを受け入れています。T-SQLをお勧めしますが、Powershellや他の創造的なアプローチには反対しません。 アプリケーションのバッファがデータのサイズであると仮定します。bigintは常にbigintのサイズであり、文字データ型は1文字あたり2バイト（ユニコード）です。BLOBデータはデータのサイズも取ります。enumは基本的にintであり、数値データはnumeric（38,12）、datetimeはdatetimeのサイズです。また、NULL値はありません1900-01-01。空の文字列として保存されるか、ゼロになります。 これがどのように実装されているかについてのドキュメントはありませんが、前提はPFEおよびサポートチームが使用するいくつかのテストとスクリプトに基づいています（また、チェックはアプリケーションに組み込まれ、アプリは認識できないため、明らかに圧縮を無視します）基になるデータが圧縮されている場合）、テーブルサイズもチェックします。例のこのリンクは述べています： 大きなテーブルにはEntireTableキャッシュを使用しないでください（AX 2009では128 KBまたは16ページ以上、AX 2012では「テーブルキャッシュサイズ全体」アプリケーション設定[デフォルト：32KB、または4ページ]）–代わりにレコードキャッシュに移動します。

12 sql-server  cache  compression  size