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

Microsoft SQL Serverのすべてのバージョン(MySQL以外)。sql-server-2016のようなバージョン固有のタグも追加してください。これは、質問に関連することが多いためです。

4
テーブルへの大きな変更には何が良いですか:毎回DELETEとINSERTまたは既存のUPDATEですか?
私は毎日1つのテーブルで約36Kレコードを変更する必要があるプロジェクトを作成しています。私は何が良くなるのだろうかと思っています: 行を削除して新しい行を挿入する、または 既存の行を更新する 私にとっては、すべての行を削除して新しい行を挿入する方が簡単ですが、これがテーブルとインデックスを断片化し、パフォーマンスに影響を与える場合、可能な限り更新を行い、必要な場合にのみ削除/挿入することをお勧めします。 これは毎晩のサービスになりますが、プロセス自体の速度を改善するつもりはありません。私は、このテーブルに対するクエリのパフォーマンスについて、私が既に8,900万件のレコードを持っている場合と、この夜間のプロセスがどのように影響するかについてより懸念しています。 この夜間のプロセスのために、レコードを削除/挿入するか、既存のレコードを更新する必要がありますか(可能な場合)?

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

3
SQL ServerはA <> BをA <B OR A> Bに分割し、Bが非決定的である場合に奇妙な結果をもたらします
SQL Serverで興味深い問題が発生しました。次の再現例を検討してください。 CREATE TABLE #test (s_guid uniqueidentifier PRIMARY KEY); INSERT INTO #test (s_guid) VALUES ('7E28EFF8-A80A-45E4-BFE0-C13989D69618'); SELECT s_guid FROM #test WHERE s_guid = '7E28EFF8-A80A-45E4-BFE0-C13989D69618' AND s_guid &lt;&gt; NEWID(); DROP TABLE #test; フィドル s_guid &lt;&gt; NEWID()条件が完全に役に立たないように見えることをしばらく忘れてください-これは単なる最小の再現例です。NEWID()特定の定数値と一致する確率は非常に小さいため、毎回TRUEと評価される必要があります。 しかし、そうではありません。このクエリを実行すると、通常 1行が返されますが、時々(非常に頻繁に、10回のうち1回以上)0行が返されます。私のシステムでSQL Server 2008を使用して複製しました。上記のリンク(SQL Server 2014)を使用してオンラインで複製できます。 実行プランを見ると、クエリアナライザーは明らかに条件をs_guid &lt; NEWID() OR s_guid &gt; NEWID()次のように分割していることがわかります。 ...これが失敗する理由を完全に説明します(最初に生成されたIDが小さく、2番目のIDが指定されたIDよりも大きい場合)。 式の1つが非決定的であっても、SQL ServerはA …

1
同じLOBデータにアクセスする場合、論理読み取りが異なる
同じデータを読み取りながら、非常に異なる論理読み取りを報告する3つの簡単なテストを次に示します。 セットアップ 次のスクリプトは、100個の同一行を持つテストテーブルを作成します。各行には、行外に格納されるのに十分なデータを含むxml列が含まれます。私のテストデータベースでは、生成されるxmlの長さは各行で20,204バイトです。 -- Conditional drop IF OBJECT_ID(N'dbo.XMLTest', N'U') IS NOT NULL DROP TABLE dbo.XMLTest; GO -- Create test table CREATE TABLE dbo.XMLTest ( ID integer IDENTITY PRIMARY KEY, X xml NULL ); GO -- Add 100 wide xml rows DECLARE @X xml; SET @X = ( SELECT TOP (100) …

6
ONとWHEREのインデックスパフォーマンス
私は2つのテーブルを持っています @T1 TABLE ( Id INT, Date DATETIME ) @T2 TABLE ( Id INT, Date DATETIME ) これらのテーブルには、(Id、Date)に非クラスター化インデックスがあります そして、私はこれらのテーブルに参加します SELECT * FROM T1 AS t1 INNER JOIN T2 AS t2 ON t1.Id = t2.Id WHERE t1.Date &lt;= GETDATE() AND t2.Date &lt;= GETDATE() これは次のように書くこともできます SELECT * FROM T1 AS t1 INNER …

2
SQL Server 2014でLEN()関数がカーディナリティを過小評価するのはなぜですか?
文字列列と特定の長さの行をチェックする述語を持つテーブルがあります。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 …

2
テーブルがそれ自体を参照するときにすべての循環参照を見つけるクエリを作成する方法は?
次のスキーマ(名前が変更されています)がありますが、変更することはできません。 CREATE TABLE MyTable ( Id INT NOT NULL PRIMARY KEY, ParentId INT NOT NULL ); ALTER TABLE MyTable ADD FOREIGN KEY (ParentId) REFERENCES MyTable(Id); つまり、各レコードは別のレコードの子です。レコードParentIdがに等しい場合、そのIdレコードはルートノードと見なされます。 すべての循環参照を検索するクエリを実行したい。たとえば、 INSERT INTO MyTable (Id, ParentId) VALUES (0, 0), (1, 0), (2, 4), (3, 2), (4, 3); クエリは返す必要があります Id | Cycle 2 | 2 …

4
CDCを使用して履歴を追跡する場合
SQL Server変更データキャプチャは、SQL Serverトランザクションログから履歴データを読み取り、特別なテーブルに保存する機能です。 特別なテーブル値関数(TVF)を使用することにより、ユーザーはこのデータをクエリすることができ、特定のテーブルのすべての変更を取得するか、特定の時間内の変更に起因するネット変更のみを取得することができます。 CDCには特定の利点があります 特定のテーブルまたは列のみを追跡するように構成できます。 モデルの変更をある程度まで処理できます。 トランザクションログを処理するため、トリガーほどパフォーマンスに大きな影響を与えません。 簡単に有効/無効にでき、追跡する必要のあるテーブルの追加の列は必要ありません。 また、いくつかの欠点もあります。 履歴データの量は非常に速くなる可能性があります。 誰が変更を行ったかを追跡することはできません(少なくとも削除はできません)。 履歴データはトランザクションログに基づいているため、追いつくのに時間がかかります。 SQL Serverエージェントに依存します。エージェントが実行されていないかクラッシュした場合、履歴は追跡されません。 私はCDCについて多くのことを読みましたが、CDCの使い方を知っていますが、それが自分にとって適切なツールかどうかはまだわかりません。 CDCが適切なツールとなるのはどのタスク/シナリオですか?(たとえば、ユーザーがデータオブジェクトを特定の時点に復元できるようにしますか?監査しますか?データの完全な履歴を表示しますか?) いつCDCを使用せず、カスタムトリガーベースのソリューションに頼るべきですか? 運用データベースでCDCを使用し、運用アプリケーション内でCDCデータを利用しても大丈夫ですか?(例:エンドユーザーに表示する)またはこれは明らかにこの機能の誤用ですか? CDCは監査ツールであるとよく聞きますが、SQL Server Auditの目的はそれではありませんか?両方とも同じタスクの異なるツールですか?または、CDCを他のものに使用できますか? 私の現在のシナリオでは、将来の複数のアプリケーションの基礎となる信頼できるデータフレームワークを構築するように求められます。正確な要件はあいまいですが、1つは、データ履歴を追跡し、他のテーブルのすべての関連データとともに古いエントリを復元できる必要があることです。私は現在、CDCをオプションとして評価していますが、推奨されるユースケースが実際には見つからないため、これが進むべきかどうかは不明です。 私は特定のシナリオに対するアドバイスに感謝しますが、回答では、Change Data Captureを使用するタイミングまたは使用しないタイミングに関する一般的なアドバイスを提供する必要があります。

6
多数の行を削除した後、SQL Serverデータベースのサイズは減少しませんでした。
この質問は、データベース管理者のStack Exchangeで回答できるため、スーパーユーザーから移行されました。 7年前に移行され ました。 私はSQLが得意ではありませんが、保守するデータベースがあります。 残っている場所がほとんどないので、たとえば2008年のすべてのデータを削除することにしました。削除クエリ(約100,000行が削除されました)を実行し、トランザクションログを削除した後、アクションはデータベースのサイズには影響しませんでした。他に何かしなければならないことはありますか?

2
ユーザー定義関数の最適化の問題
この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 4年前に移行され ました。 1行のみをフェッチする必要があるにもかかわらず、SQLサーバーがテーブル内のすべての値に対してユーザー定義関数を呼び出すことを決定する理由を理解するのに問題があります。実際のSQLはもっと複雑ですが、問題をこれまで減らすことができました。 select S.GROUPCODE, H.ORDERCATEGORY from ORDERLINE L join ORDERHDR H on H.ORDERID = L.ORDERID join PRODUCT P on P.PRODUCT = L.PRODUCT cross apply dbo.GetGroupCode (P.FACTORY) S where L.ORDERNUMBER = 'XXX/YYY-123456' and L.RMPHASE = '0' and L.ORDERLINE = '01' このクエリでは、SQL Serverは、ORDERLINEから返される推定行数と実際の行数が1(主キー)であっても、PRODUCTテーブルに存在するすべての値に対してGetGroupCode関数を呼び出すことを決定します。 行カウントを示すプランエクスプローラーの同じプラン: テーブル: ORDERLINE: 1.5M rows, …

2
ストアドプロシージャのプロファイル方法
私はSQL Server 2012を使用していますが、ストアドプロシージャをプロファイルする方法を疑問に思っていました たとえば、プロファイラーは、ストアドプロシージャ内の個々のSQLステートメントをキャプチャできますか? マージレプリケーションストアドプロシージャを診断しようとしていますが、これはマージエージェントの完全な実行の一部としてキャプチャする必要があります。パフォーマンスの問題が発生したストアドプロシージャを取得して再度実行することは、その時点では遅くないため不可能と思われます。

2
tempdbの成長の原因となったSQLステートメントを見つける方法
サーバー(SQL Server 2008)のtempdbは、毎月数回500 GB以上に増加します。この問題の原因となったSQLステートメントを見つけることは可能ですか?問題は通常によって引き起こされていないcreate table #temp...; insert into #temp...かselect ... into #temp...が、複合体が結合します。 一部のtempdbファイルの初期サイズも、毎回自動的により大きな値に設定されます。それを防ぐ方法は? キャッシュされたプランがファイルのサイズ変更/縮小を妨げる場合があります。どちらがtempdbを保持しているかを見つける方法は?

3
「Chaos」分離レベルとは何ですか、いつ使用する必要がありますか?
ADO.NETのドキュメントには、SQLトランザクションのトランザクションレベルをChaosに設定する可能性が示されています。不快に聞こえますが、機能が存在する場合は、おそらく正当な使用方法があります。 BOL のSET TRANSACTION ISOLATION LEVELコマンド(ああ!わかりました、GoogleとBOLを使用できます)は何も「カオス」という名前ではないようです。ADO.NETには、「カオス」に加えて文書化されたレベル このカオスのレベルは何ですか?(そして、なぜそれは非友好的な名前を持っていますか?) 参照: ADO.NET列挙型

3
sql-server bakを復元し、同時にログを圧縮することは可能ですか?
問題調査のために開発者オフィスに転送したクライアントからのbakファイルがあります。現在、バックアップは25GBで、復元されたデータベースはほぼ同じサイズですが、復元するには100GBが必要です。これは、データベースが75GBのトランザクションログサイズを持つように設定されているためだと思います。データベースを復元した後、ログファイルを圧縮できますが、復元でこれを行う方法はありますか?

2
マルチテナントデータベースアーキテクチャで増え続けるテナントの処理
アプリケーションのテナントのインスタンスごとに個別のデータベースを持つ共通サーバーで適度な数の顧客(テナント)を処理するのは比較的簡単で、通常これを行う正しい方法です。現在、各テナントが独自のデータベースインスタンスを持つアプリケーションのアーキテクチャを検討しています。 ただし、問題は、このアプリケーションに多数のテナント(5,000〜10,000)があり、かなりの数のユーザー(おそらく単一のテナントでは2,000)があることです。毎週数人のテナントによるシステムの成長をサポートする必要があります。 さらに、すべてのテナントとそのユーザーに共通のログインプロセスが表示されます(つまり、各テナントが独自のURLを持つことはできません)。これを行うには、集中ログインプロセスと、システムにデータベースを動的に追加し、ユーザーを登録する手段が必要です。 登録およびデータベース作成プロセスをどのように堅牢に自動化できますか? システムでテナントのデータベースを作成および登録するプロセスは、パフォーマンスまたはロックの問題を引き起こす可能性がありますか?これが問題になると思われる場合、誰でもそれを軽減する方法を提案できますか? ユーザー資格情報が特定のテナントのデータベースに関連付けられているが、ユーザーは共通のページからログインできる(つまり、すべて同じログインURLであるが、ホームアプリケーションは特定のテナントのデータベースにある)方法で中央認証を管理する方法)。テナントは独自のログインとアクセス許可を維持できる必要がありますが、中央ログインシステムはこれらを認識している必要があります。誰でもこれを行う方法を提案できますか? 複数のデータベースサーバーを追加して「スケールアウト」する必要がある場合、サーバー全体のユーザーIDの管理(なりすましなど)で対処しなければならない問題と、それらの問題を軽減する方法を誰か提案できますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.