タグ付けされた質問 「tempdb」

TempDBはMS SQL Serverの一部です。これは、一時テーブル、内部オブジェクト、および行バージョンのストレージ領域として機能するシステムデータベースです。

3
varchar(max)が原因で流出をtempdbにソート
32 GBのサーバーでは、最大メモリが25 GBのSQL Server 2014 SP2を実行しており、2つのテーブルがあります。ここでは、両方のテーブルの構造が簡略化されています。 CREATE TABLE [dbo].[Settings]( [id] [int] IDENTITY(1,1) NOT NULL, [resourceId] [int] NULL, [typeID] [int] NULL, [remark] [varchar](max) NULL, CONSTRAINT [PK_Settings] PRIMARY KEY CLUSTERED ([id] ASC) ) ON [PRIMARY] GO CREATE TABLE [dbo].[Resources]( [id] [int] IDENTITY(1,1) NOT NULL, [resourceUID] [int] NULL, CONSTRAINT [PK_Resources] PRIMARY KEY CLUSTERED …

1
tempdbへのハッシュ/ソートの流出の頻度はどのくらいですか?
私たちのエンタープライズアプリケーションは、データストレージにSQL Serverを使用し、主にOLTPシステムです。ただし、アプリケーションの重要なコンポーネントは、重要なOLAPワークロードを生成します。 tempdbへの書き込み待ち時間は約100msです。この傾向は、時間をかけて保持し、ALLOW_SNAPSHOT_ISOLATION投入されるオフ。私たちはこれに関して問題のトラブルシューティングを行っていますが、これまでに見つかった唯一の興味深いことは、tempdbへのハッシュとソートの流出が非常に多いことです。これはOLAPワークロードによるものだと思います。 質問 流出の頻度はどの程度ですか?どれか?1秒あたりの流出回数は?予備データによると、毎秒約2回のハッシュ流出と1分あたり25回のソート流出があります。 この流出の頻度が、tempdbの書き込み待ち時間が長い主な原因である可能性はありますか? その他の情報 コアの数ごとに推奨されているように、tempdbには複数のファイルを使用しています。tempdbファイルはRAID 1 + 0 SAN(高性能SSDを搭載)上にありますが、これはメインのDBデータおよびログファイルと同じデバイスです。tempdbファイルのサイズは、非常にまれに大きくなるほど大きくなっています。トレースフラグ1117または1118は使用していません。別の変数は、このセットアップが、すべて中程度から高い負荷を経験する多くの異なるデータベースで共有されていることです。 100ミリ秒の書き込みレイテンシは、MSDN、SQLスキル、その他のサイトで見つかったtempdb書き込みレイテンシの許容範囲よりもはるかに大きくなっています。ただし、他のデータベースの書き込みレイテンシは良好です(10ミリ秒未満)。他の統計に基づいて、tempdbを特に内部オブジェクトに対して頻繁に使用しているようです。したがって、アプリケーションが内部オブジェクトを非常に多く使用している理由を調べるために掘り下げています。 私たちのプラットフォームには、さまざまな形で現れる実際のパフォーマンスの問題があります。私たちはパフォーマンスカウンターを監視し、DMビューを確認し、アプリの動作を分析して、システムのリソース使用特性を掘り下げようとしています。流出はメモリ内ではなくディスク上で実行されるため、流出は劇的な悪影響をもたらすことがわかっているため、現時点では流出に焦点を当てています。また、流出の数は非常に多いようですが、人々が「高」と見なしていることについて何らかの情報を入手したいと考えていました。

4
TempDBでのDDL競合
過去数か月間、TempDB DDL競合の問題が発生しているSQL Server 2005 Standard x64があります。サーバーは待機リソース2:1:103(待機タイプはPAGELATCH_EX)で競合が発生します。 この問題は、サーバーに適切な負荷がかかっているときに散発的に発生するようです。私は「破壊用の一時テーブル」のレートを監視しており、2:1:103でPAGELATCH_EXの問題が発生しているときに5,000以上にジャンプする可能性があります。私が読んだことから、このカウンターはほとんどの場合0であるはずですが、私たちのカウンターはほとんどの場合300〜1100のどこかにとどまっているようです。システム上のユーザーが非常に少ない場合にのみ、カウンターは0になります。 干し草のスタックで針を探す必要なしに、tempdbのDDL競合の原因を絞り込むにはどうすればよいですか?

2
TempDBは縮小しません。未処理のトランザクションはありません
SQL 2008でTempDBが非常に大きくなり(> 40GB)、それを縮小したいのですが。私は、Management Studioを介してdbccの縮小データベース、dbccの縮小ファイル、および縮小コマンドを使用しました。 次のエラーが発生します。 ページ1:4573184は作業テーブルページであるため移動できませんでした。 DBCC FREEPROCCACHEを実行し、縮小ルーチンの1つを再実行することで、危険を回避するためにいくつかの領域を再利用できましたが、明らかにこれは理想的ではなく、たぶん少し時間を費やすだけです。 私はDBCC OpenTranを実行しましたが、そこには何もぶらさがっていません。 私がインターネット上で読んだところはどこでもSQL Serverのリサイクルに行き着きます...確かにより良い方法が必要です...誰か? おかげで、 トム

3
TempDBのパーティションが破損していると、DBCC CHECKDBで問題が報告されないのはなぜですか。
SQL Serverの1つが最近次のエラーを報告しました: DATE/TIME: 2/25/2013 9:15:14 PM DESCRIPTION: No catalog entry found for partition ID 9079262474267394048 in database 2. The metadata is inconsistent. Run DBCC CHECKDB to check for a metadata corruption. 15分以内にサーバーに接続して実行しました。 SELECT name FROM sys.databases WHERE database_id = 2; これは「tempdb」を返しました。次に実行しました: DBCC CHECKDB ('tempdb') WITH NO_INFOMSGS, TABLERESULTS; 結果は返されず、影響を受けるデータベースに問題がないことを示しています。 データベースが破損すると、上記のエラーメッセージが表示されDBCC CHECKDB、問題が報告されないのはなぜですか。ページのチェックサム計算が失敗し、そのページを参照しているオブジェクトを削除できないと疑われるページがマークされた場合、私は推測しますが、私は間違っているはずです。 …

1
SELECT INTOは、実行前にTempDBで#Object名を予約しますか?
デバッグに役立つQuickieプロシージャをまとめると、コンパイラでエラーのように見えるものに遭遇しました。 create proc spFoo @param bit as begin if @param = 0 begin select * into #bar from [master].dbo.spt_values -- where number between ... end else begin select top 10 * into #bar from [master].dbo.spt_values order by newid(); end; end; 上記を試行すると、次のエラーが返されます メッセージ2714、レベル16、状態1、プロシージャspFoo、行19 データベースにはすでに「#bar」という名前のオブジェクトがあります。 人間が読める意味では、プロシージャは問題ないように見えます。ブロックselect into内にラップされているため、実行されるステートメントは1つだけですif-else。ただし、SQLサーバーは、ステートメントが互いに論理的に除外されていることを確認できません。おそらくもっと混乱するのdrop table #fooは、以下のようにがif-elseブロック内に配置されたときにエラーが残ることです(これにより、オブジェクト名の割り当てを解除するようコンパイラーに指示すると想定されます)。 create proc spFoo …

1
1秒あたりのトランザクション数が非常に多い
本番サーバーは、1秒あたり平均4,000トランザクションで実行されます。過去数日間で、平均は毎秒175,000トランザクションに急上昇しました。これはタイプミスではなく、1秒あたり175Kです。 トランザクションのDMVを見ると、ユーザーセッションに直接リンクすることはできませんが、次のように表示されます。 SELECT NAME, COUNT(*) FROM sys.dm_tran_active_transactions GROUP BY NAME ORDER BY 2 DESC - +------------------------------+-------+ | Name | Count | +------------------------------+-------+ | WorkFileGroup_fake_worktable | 627 | | LobStorageProviderSession | 217 | | workfile | 171 | +------------------------------+-------+ 誰かがこれらのタイプの取引に光を当てることができますか?または、私はここで幽霊を追いかけていますか?

3
sp_MSForEachDBを使用してデータベースをループするときにIFステートメントがTempDBをスキップしない
[SQL Server 2012 SP2 EE] 次のスクリプトでtempdbに関するエラーが発生するのはなぜですか? exec sp_MSForEachDB ' IF ( (select database_id from sys.databases where name = ''?'') > 4) BEGIN ALTER AUTHORIZATION ON DATABASE::? TO [sa]; ALTER DATABASE [?] SET RECOVERY SIMPLE; END' ここに私が得るエラーがあります: Msg 5058, Level 16, State 1, Line 5 Option 'RECOVERY' cannot be set in …

2
tempdbの場所が壊れて回復できない
間違いを犯し、tempdbのデータベース変更コマンドを誤って入力しました。 これでインスタンスは起動しなくなります。tempdbが見つからなかったため、-mを使用してシングルユーザーモードで起動できません。私は使ってみました: net start msqsqlserver /f /t3608 しかし、sqlcmdまたはを使用してインスタンスに実際に接続することはできませんssms。

2
TempDBをCPUの数に等しい複数のファイルに分割する
記事「SQL Server tempdbのベストプラクティスパフォーマンスの向上」ではtempdb、コアの数に等しい数のファイルに分割する必要があることを示唆しています。したがって、4つのコアで4つのファイルを取得します。 ファイル数を増やすことで、SQL Serverが一度にディスクにプッシュできる物理I / O操作の数を増やすことができます。SQL ServerがディスクレベルにプッシュダウンできるI / Oが多いほど、データベースの実行が高速になります。標準データベースでは、SQL Serverは必要な大量のデータをメモリにキャッシュできます。tempdbは書き込みの性質が高いため、メモリにキャッシュする前に、データをディスクに書き込む必要があります。 理論的には良さそうに聞こえますが、それは一般的な最適化として本当にそれでいいのでしょうか IOが非常に高い特定のシステムにのみ適用されるものですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.