タグ付けされた質問 「database-internals」

ビジネスロジックを含むストアドプロシージャがあります。その中には約1609の変数があります（理由は聞かないでください、これがエンジンのしくみです）。SET変数を他のすべての変数の連結値にしようとしています。結果として、作成中にエラーが発生します。 メッセージ8631、レベル17、状態1、手順XXX、行YYY内部エラー：サーバーのスタック制限に達しました。クエリで潜在的に深い入れ子を探し、それを単純化してみてください。 エラーは、SET操作で使用する必要がある変数の数が原因であることがわかりました。２つに分けて割り当てができます。 私の質問は、この領域にいくつかの制限があるのですか？チェックしましたが何も見つかりませんでした。 このKBに記載されているエラーを確認しましたが、これは私たちのケースではありません。CASEコード内では式を使用しません。その一時変数を使用して、CLR関数を使用して置き換える必要がある値のリストを準備します。SQL ServerをSP3 CU6（最新）に更新しましたが、まだエラーが発生しています。

11 sql-server  sql-server-2012  t-sql  errors  database-internals 

DATALENGTH()テーブル内のすべてのレコードのすべてのフィールドを合計すると、テーブルの合計サイズが得られるという印象を受けました。私は間違っていますか？ SELECT SUM(DATALENGTH(Field1)) + SUM(DATALENGTH(Field2)) + SUM(DATALENGTH(Field3)) TotalSizeInBytes FROM SomeTable WHERE X, Y, and Z are true 以下のクエリを使用して（オンラインから取得してテーブルサイズ、クラスター化インデックスのみを取得し、NCインデックスは含まない）、データベース内の特定のテーブルのサイズを取得しました。請求のために（部門に使用するスペースの量に応じて部門に請求します）、この表で各部門が使用したスペースの量を把握する必要があります。テーブル内の各グループを識別するクエリがあります。各グループがどれだけのスペースを使用しているかを知る必要があります。 1行あたりのスペースVARCHAR(MAX)は、テーブル内のフィールドが原因で大きく変動する可能性があるため、平均サイズ*部門の行の比率を取得することはできません。DATALENGTH()上記のアプローチを使用すると、以下のクエリで使用される合計スペースの85％しか取得できません。考え？ SELECT s.Name AS SchemaName, t.NAME AS TableName, p.rows AS RowCounts, (SUM(a.total_pages) * 8)/1024 AS TotalSpaceMB, (SUM(a.used_pages) * 8)/1024 AS UsedSpaceMB, ((SUM(a.total_pages) - SUM(a.used_pages)) * 8)/1024 AS UnusedSpaceMB FROM sys.tables t with …

11 sql-server  clustered-index  metadata  database-internals  data-pages 

非常に高い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がディスクではなくトランザクションログキャッシュに変更を記録することを指していることを理解しました。トランザクションが完了するか、バッファがいっぱいになると、すべてのレコードがすぐにディスクにフラッシュされます。

11 sql-server  sql-server-2008-r2  sql-server-2012  sql-server-2014  database-internals 

インデックスが無効になると、定義はシステムカタログに残りますが、使用されなくなります。SQL Serverはインデックスを維持せず（テーブルのデータが変更されるため）、インデックスを使用してクエリを満たすことはできません。場合はクラスタ化インデックスが無効になっている、テーブル全体がアクセスできなくなります。 Bツリーを破棄してテーブルから直接データにアクセスできないのはなぜですか？（おそらくテーブルを行ごとにスキャンすることにより）データに完全にアクセス不能にするよりも適切でしょうか？ それは純粋に理論的な質問です-私は実際にはそうしません。それはシナリオでも、やることでもありません。なぜそうなるのかを知りたいのですが、内部的な問題だと考えてください。

11 sql-server  clustered-index  database-internals 

チャットディスカッションで生じた質問： ハッシュ結合の救済が内部で一種のネストされたループに切り替わることを知っています。 SQL Serverはハッシュ集約救済のために何をしますか（それが発生する可能性がある場合）？

10 sql-server  execution-plan  aggregate  database-internals  hashing 

私の質問は、SQL Serverが、利用可能な領域よりも多くのデータをバッファキャッシュにプルする必要があるクエリをどのように処理するかです。このクエリには複数の結合が含まれているため、結果セットはこのフォーマットですでにディスク上に存在せず、結果をコンパイルする必要があります。ただし、コンパイル後でも、バッファキャッシュで使用可能な領域よりも多くの領域が必要です。 例を挙げましょう。合計6GBの利用可能なバッファキャッシュスペースを持つSQL Serverインスタンスがあるとします。7GBのデータを読み取る複数の結合を使用してクエリを実行しますが、SQL Serverはこの要求にどのように応答できますか？tempdbにデータを一時的に保存しますか？失敗しますか？ディスクからデータを読み取り、一度にセグメントをコンパイルするだけですか？ さらに、7GBの合計データを返そうとするとどうなりますか？SQL Serverがデータを処理する方法は変わりますか？ 私はこれに対処するいくつかの方法をすでに知っていますが、SQL Serverがこのように実行されたときに、SQL Serverがこの要求を内部的に処理する方法に興味があります。 また、この情報はどこかにあると思いますが、見つけるのに失敗しました。

10 sql-server  sql-server-2012  memory  database-internals  buffer-pool 

データロードパフォーマンスガイドを読んでも、最小限のログを取得するためにクラスター化インデックスで定義された空の一時テーブルにTABLOCKテーブルヒントを追加する必要があるかどうかはまだわかりません。 一時テーブルは、SIMPLEリカバリモードで動作するTempDBで作成されるのは明らかなので、最小限のロギングの完璧な候補だと思いましたが、確認するための通路が見つかりません。 一時テーブルは最小限のロギングの候補です。そうであれば、永続テーブルに推奨されるTABLOCKヒントを追加する価値はありますか？

10 sql-server  performance  t-sql  import  database-internals 

最大メモリが24GBに設定されたSQL Server 2016 SP1があります。 このサーバーには多数のコンパイルがあり、これらのコンパイルの10％のみがアドホッククエリからのものです。したがって、新しくコンパイルされたプランはプランキャッシュに保存されますが、プランキャッシュのサイズは増加していません（約3.72GB）。 キャッシュからのプランの削除につながるローカルメモリのプレッシャーがあると思います。プランのキャッシュ圧力制限は5GBです。（0-4GBの可視ターゲットメモリの75％+ 4GB-64GBの可視ターゲットメモリの10％+可視ターゲットメモリの5％> 64GB）。キャッシュストアが圧力制限の75％に達したら、プランをキャッシュから削除する必要があります。私の場合、5 GBの75％は3.75GBです。したがって、これが高コンパイルの原因であると考えられます。 キャッシュからの計画からの削除を測定する方法（perfmon、拡張イベントなど）はありますか？だから私は確かにローカルメモリのプレッシャーが高コンパイルの原因であることを確信できますか？

9 sql-server-2016  database-internals  plan-cache 

以下のAdventureWorksサンプルデータベースクエリの場合： SELECT P.ProductID, CA.TransactionID FROM Production.Product AS P CROSS APPLY ( SELECT TOP (1) TH.TransactionID FROM Production.TransactionHistory AS TH WHERE TH.ProductID = P.ProductID ORDER BY TH.TransactionID DESC ) AS CA; 実行計画ショー推定オペレータコストの0.0850383ため（93％）インデックスシーク： コストは、使用中のカーディナリティ推定モデルとは無関係です。 Estimated CPU CostとEstimated I / O Costを単純に追加したものではありません。また、インデックスシークの 1回の実行のコストに推定実行回数を掛けたものでもありません。 このコスト数はどのようにして得られたのですか？

9 sql-server  execution-plan  database-internals 

Itzikの本「Querying Microsoft SQL Server 2012」を読んでいるほか、インターネットでさまざまな教育資料を読んだり見たりしています。私の意図は、データベースの内部がどのように機能するかを理解することです。 IAMページについて解決できなかったことに少し疑問があります。私は理解の非常に早い段階にいるので、それをよりよく理解している人たちからの追加の助けが必要かもしれません。 第15章の「インデックスと統計の実装」では、IAMページの例として次の画像が表示されます。 同じ範囲に関連する16ページと思われるものを赤い矢印で確認できます。そんなことがあるものか？著者/編集者の間違いですか？または、より可能性の高いもの：私が正しく理解していないものはありますか？ 私が持っている他の質問は、ページ間隔に関連しています。なぜ隣接していないのですか？最後のエクステントを例にとると、IDが336から22642のページ、またはその前のページが296から328のページをカバーします。

9 sql-server  database-internals  storage-engine 

私の実際の作業クエリは内部結合でしたが、クロス結合を使用したこの単純な例では、ほとんど常に問題が再現されているようです。 SELECT * FROM ( SELECT 1 UNION ALL SELECT 2 ) AA ( A ) CROSS JOIN ( SELECT NEWID() TEST_ID ) BB ( B ) 私の内部結合では、NEWID（）関数を使用して各行にGUIDを追加した多くの行があり、そのような行の約9に対して、2行の仮想テーブルとの乗算により期待される結果が生成されました。同じGUID。10のうち1つは異なる結果を生成します。これは控えめに言っても予想外であり、テストデータ生成スクリプトでこのバグを見つけるのに本当に苦労しました。 非決定的なgetdate関数とsysdatetime関数を使用して次のクエリを見ると、これは表示されません。私はとにかく、両方の最終結果行に常に同じdatetime値を表示しています。 SELECT * FROM ( SELECT 1 UNION ALL SELECT 2 ) AA ( A ) CROSS JOIN ( SELECT GETDATE() TEST_ID …

9 sql-server  sql-server-2008  database-internals 

これはデータベース内部の質問です。私はPostgreSQL 9.5を使用FROMしています。たとえば、これらのコマンドを実行するときのように、句の中でSet Returning Functions（SRF）（テーブル値関数（TVF）とも呼ばれます）の実行速度が低下するのはなぜですか。 CREATE TABLE foo AS SELECT * FROM generate_series(1,1e7); SELECT 10000000 Time: 5573.574 ms それはだ常に、より実質的に遅いです CREATE TABLE foo AS SELECT generate_series(1,1e7); SELECT 10000000 Time: 4622.567 ms ここで作成できる一般的なルールはありますか？たとえば、節の外で常に Set-Returning関数を実行する必要がありFROMますか？

8 postgresql  performance  functions  database-internals  set-returning-functions 

多くのdecimal（26,8）列を含む広い非正規化テーブルを作成する必要があります（1024列の制限より少なく、ほとんどの列はnullまたはゼロになります）。行あたりの制限は8060バイトなので、ページ圧縮を使用してテーブルを作成しようとしました。以下のコードはテーブルを作成し、1つの行を挿入し、行サイズをクエリします。行のサイズが制限をはるかに下回っていますが、テーブルにdecimal（26,8）列を1つ追加しようとすると、エラーが発生し、操作が失敗します。内部オーバーヘッドのバイト。」それだけ多くの列を持つ単一のテーブルを作成する方法はありますか？ drop table t1 GO create table t1(c1 decimal(26, 8) null) with (data_compression = page) GO declare @i int = 2; declare @sql varchar(100); while @i <= 486 begin set @sql = 'alter table t1 add c' + convert(varchar, @i) + ' decimal(26, 8) null'; execute (@sql); set @i += …

8 sql-server  sql-server-2014  database-internals  compression 

SQL Serverでtpchデータベースを作成した後、以下のクエリを試しました。 set statistics io on DBCC DROPCLEANBUFFERS; select top 100 * from dbo.lineitem order by l_partkey; テーブルのlineitemには、l_partkeyに非クラスター化インデックスがあります。上記のクエリを数回発行したところ、論理読み取りが毎回異なることがわかりました。 Table 'lineitem'. Scan count 1, logical reads 1019, physical reads 4, read-ahead reads 1760, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'lineitem'. Scan count 1, logical …

8 sql-server  database-internals 

以下のクエリを考えてみましょう： CREATE PROC dbo.GetPage @orderid AS INT = 0, -- anchor sort key @pagesize AS BIGINT = 25 AS SELECT TOP (@pagesize) orderid, orderdate, custid, empid FROM dbo.Orders WHERE orderid > @orderid ORDER BY orderid; exec GetPage 25,25 上記のクエリに対してSET STATISTICS IOが返されました： (25 row(s) affected) Table 'Orders'. Scan count 1, logical …

8 sql-server  execution-plan  database-internals  sql-server-2016