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

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

6
SQL Serverで可能な限り最小のバックアップ
毎日、WAN経由でSQL Serverバックアップを出荷しています。永久に時間がかからないように、これらのバックアップのサイズを最小化する必要があります。 バックアッププロセスに少し時間がかかるかどうかは気にしません。現状では、30ギガの圧縮バックアップをWAN経由で移動する必要があり、10時間以上かかります。 毎日のより小さなバックアップを取得する必要がある2つのオプションがあります。 ログ配布。これは、DRプロセスを再構築する必要があることを意味します。 データベースから情報を取り除き、反対側で再構築します(非クラスター化インデックスを削除し、クラスター化インデックスを100%でパックします-反対側で再構築します) 両方とも、私たちの側からかなりの量の作業を伴います。SQL Server 2008 proを使用しています。すべてのバックアップが圧縮されています。 オプション(2)と同等のバックアップサイズを提供できる商用製品はありますか? そこにあるの包括的な私たちは(2)を達成することができますそこにスクリプトが?(インデックス付きビュー、フィルター処理されたインデックス、外部キーなどの処理)

4
データベース内のすべての列名をリストまたは検索するにはどうすればよいですか?
データベースにある列の名前の文字列を検索したい。 私はメンテナンスプロジェクトに取り組んでおり、扱っているデータベースの一部には150を超えるテーブルがあるため、これをすばやく行う方法を探しています。 おすすめは何ですか?

10
データベースの依存関係を追跡するにはどうすればよいですか?
内部アプリケーションが数年にわたって進化するにつれて、人々はもはや関連性がなくなったと考え、カリングしたいと考えているテーブルがいくつかあることに気付くでしょう。SQL環境内で、そしておそらくSSISのようなものに進むために、データベースの依存関係を識別するための実用的な方法は何ですか? 私は次のようなかなり残忍な選択肢が取られている場所で働いてきました: 最初にドロップし、後で質問します(存在しないテーブルを抽出しようとすると、データウェアハウスのビルドを強制終了できます) 最初に権限を削除し、エラーが報告されるまで待機します(障害が正しく処理されない場合、サイレントバグが発生する可能性があります) SQL Serverには、そのインスタンス内の依存関係を追跡するツールが付属していることを感謝していますが、異なるインスタンスにデータベースがある場合、これらは苦労しているようです。「この列はどこで使用されますか?」などの質問に答えるなど、依存関係の照会を簡単にするオプションがありますか?「このストアドプロシージャのこの他のサーバーでオーバー」または「このSSISパッケージでオーバー」などの回答がありますか?

2
この特定の場合に、テーブル変数を#tempテーブルの2倍以上高速で使用するのはなぜですか?
ここで、一時テーブルとテーブル変数、およびSQL ServerのパフォーマンスとSQL Server 2008に対する影響についての記事を見て、 2005年に示された結果と同様の結果を再現することができました。 10行のみでストアドプロシージャ(以下の定義)を実行すると、テーブル変数バージョンは一時テーブルバージョンを2回以上実行します。 プロシージャキャッシュをクリアし、両方のストアドプロシージャを10,000回実行してから、さらに4回実行するプロセスを繰り返しました。以下の結果(バッチあたりのミリ秒単位の時間) T2_Time V2_Time ----------- ----------- 8578 2718 6641 2781 6469 2813 6766 2797 6156 2719 私の質問は次のとおりです。テーブル変数バージョンのパフォーマンスが向上する理由は何ですか? 調査を行いました。例:パフォーマンスカウンターを見る SELECT cntr_value from sys.dm_os_performance_counters where counter_name = 'Temp Tables Creation Rate'; どちらの場合も、一時オブジェクトは、最初の実行後にキャッシュされていることを確認し、予想通り呼び出しごとではなく、再びゼロから作成しました。 同様に、トレースAuto Stats、SP:Recompile、SQL:StmtRecompileこれらのイベントのみ(の最初の起動時に一度発生することを示しているプロファイラのイベント(下のスクリーンショット)を#tempテーブルストアドプロシージャ)および他の9,999の実行は、これらのイベントのいずれかを上げていません。(テーブル変数バージョンはこれらのイベントを取得しません) ストアドプロシージャの最初の実行のわずかに大きいオーバーヘッドは、全体的な大きな違いを説明することはできませんが、プロシージャキャッシュをクリアして両方のプロシージャを1回実行するのに数ミリ秒しかかからないため、統計または再コンパイルが原因である可能性があります。 必要なデータベースオブジェクトを作成する CREATE DATABASE TESTDB_18Feb2012; GO USE TESTDB_18Feb2012; CREATE TABLE NUM ( n …

2
外部適用と左結合のパフォーマンス
SQL SERVER 2008 R2を使用しています 私はSQLでAPPLYに出会い、多くの場合にクエリの問題を解決する方法が大好きでした。 結果を取得するために2つの左結合を使用していたテーブルの多くは、1つの外部適用を取得できました。 ローカルDBテーブルに少量のデータがあり、展開後、コードは少なくとも20倍のデータで実行されるはずです。 大量のデータの場合、外部適用は2つの左結合条件よりも時間がかかることが心配です。 誰でも正確に適用がどのように機能し、それが非常に大きなデータのパフォーマンスにどのように影響するかを伝えることができますか?可能であれば、n1 ^ 1またはn1 ^ 2に比例するような各テーブルのサイズとの比例関係... n1はテーブル内の行数です1。 以下は、左結合が2つのクエリです。 select EC.*,DPD.* from Table1 eC left join ( select member_id,parent_gid,child_gid,LOB,group_gid,MAX(table2_sid) mdsid from Table2 group by member_id,parent_gid,child_gid,LOB,group_gid ) DPD2 on DPD2.parent_gid = Ec.parent_gid AND DPD2.child_gid = EC.child_gid AND DPD2.member_id = EC.member_id AND DPD2.LOB = EC.default_lob AND …

1
SQL Server 2017でSNAPSHOT_MATERIALIZATIONを使用してビューを作成するにはどうすればよいですか?
SQL Server 2017には、いくつかの新しいストアドプロシージャがあります。 sp_refresh_single_snapshot_view – @view_name nvarchar(261)、@ rgCode intの入力パラメーター sp_refresh_snapshot_views – @rgCode intの入力パラメーター sys.messagesの新しいエントリ: 10149-ビュー定義にメモリ最適化テーブルが含まれているため、SNAPSHOT_MATERIALIZATIONを持つインデックスをビュー '%。* ls'に作成できません。 10642-SNAPSHOT_MATERIALIZATIONは、ビューのインデックスにのみ適用されるため、 '%。* ls'のインデックス '%。* ls'に設定できません。 10643 – SNAPSHOT_MATERIALIZATIONは、ビューのクラスター化インデックスにのみ適用されるため、 '%。* ls'の '%。* ls'に設定できません。 10648 – SNAPSHOT_MATERIALIZATIONは、 '%。* ls'のパーティションインデックス '%。* ls'に設定できません。 10649-SNAPSHOT_MATERIALIZATIONのクラスター化インデックス '%。* ls'を持つ '%。* ls'には非クラスター化インデックス '%。* ls'を作成できません。 10650 –スナップショットビューを更新するには、データベースでスナップショット分離を有効にする必要があります。 3760 – SNAPSHOT_MATERIALIZATIONを持つビュー '%。* ls'のインデックス …

5
以前に高速なSQLクエリの実行が遅くなった場合、どこで問題の原因を見つけることができますか?
バックグラウンド 私は、約12の異なる「テーブル」を結合および/または左結合するSQL Server 2008 R2に対してクエリを実行しています。データベースはかなり大きく、5000万行を超える多くのテーブルと約300の異なるテーブルがあります。全国に10の倉庫がある大企業向けです。すべての倉庫は、データベースに対して読み取りと書き込みを行います。だから、かなり大きくてかなり忙しい。 私が問題を抱えているクエリは次のようになります: select t1.something, t2.something, etc. from Table1 t1 inner join Table2 t2 on t1.id = t2.t1id left outer join (select * from table 3) t3 on t3.t1id = t1.t1id [etc]... where t1.something = 123 結合の1つが非相関サブクエリ上にあることに注意してください。 問題は、今朝から、システムに変更を加えずに(私または私のチームの誰もが知っている)、クエリの実行に通常約2分かかり、実行に1時間半かかることです。まったく走った。データベースの残りの部分はうまくいっています。私は通常実行するsprocからこのクエリを取り出し、同じスローネスでハードコードされたパラメータ変数を使用してSSMSで実行しました。 奇妙なことに、非相関サブクエリを取得して一時テーブルにスローし、サブクエリの代わりにそれを使用すると、クエリは正常に実行されます。また、このコードをクエリの最後に追加すると、クエリが非常によく実行されます(これは私にとって最も奇妙なことです)。 and t.name like '%' これらの小さな実験から、スローダウンの理由は、SQLのキャッシュされた実行計画の設定方法によるものであると(おそらく間違って)結論付けました-クエリが少し異なる場合、新しい実行計画を作成する必要があります。 私の質問は次のとおりです:高速で実行されていたクエリが深夜に突然遅くなり、このクエリ以外に何も影響を受けない場合、どのようにトラブルシューティングし、今後発生しないようにするのですか? ?SQLが内部で何をして非常に遅くするかを知るには(悪いクエリが実行された場合、実行計画は取得できますが、実行されません-予想される実行計画が何かを与えるでしょうか?)この問題が実行計画に関連している場合、SQLが本当にくだらない実行計画は良いアイデアだと考えないようにするにはどうすればよいですか? また、これはパラメータースニッフィングの問題ではありません。SSMSで変数をハードコーディングした場合でも、パフォーマンスが低下するため、これは以前見たことがありますが、そうではありません。

2
Denaliシーケンスは、ID列よりもパフォーマンスが高いと想定されるのはなぜですか?
どちらが優れているかに対する彼の答え:ID列または生成された一意のID値?mrdennyのコメント: SQL Denaliが登場すると、IDよりも効率的なシーケンスがサポートされますが、より効率的なものを作成することはできません。 私はちょっと確信が持てません。Oracleのシーケンスを知っているので、挿入のトリガーを作成するか、各挿入をストアドプロシージャの呼び出しにカプセル化するか、アドホック挿入を行うときにシーケンスを適切に使用することを忘れないでください。 シーケンスの利点はそれほど明白ではないと思います。


5
SQL Serverがより多くのサーバーメモリを消費するのはなぜですか?
SQL ServerはサーバーRAMの87.5%を消費しています。これは最近、速度低下などの多くのパフォーマンスのボトルネックを引き起こしました。この問題を調査しました。インターネットで見つけることができる一般的な解決策の1つは、SQL Serverの最大制限を設定することです。これが行われ、多くの改善が得られました。最大メモリ値が設定されていない場合、SQL Serverがリソースを消費し続ける理由を知りたい

5
なぜvarcharデータ型がまだあるのですか?
私のデータベースの多くには、varcharとして定義されたフィールドがあります。私はアメリカに住んで働いているので、これはそれほど問題ではありませんでした(存在する唯一の言語は「アメリカ人」です。ahem) 約5年間データベースを操作した後、最終的にvarcharフィールドの性質が限られているという問題に遭遇し、nvarcharとしてデータを保存するためにフィールドを変更する必要があります。テーブルに別の更新を行い、varcharフィールドをnvarcharに変換しなければならなかった後、私は考えました-なぜこのようにまだ行うのですか?私はずっと前から、新しいテキストフィールドをすべてvarcharではなくnvarcharに定義するという精神的な決定をしました。これは、10年前に学校にいたときに教科書から学んだことです。 2011年で、昨年SQL Serverの新しいリリースがありました。代わりにnvarcharを使用できる/すべきであるのに、なぜvarcharデータ型をサポートし続けるのですか? nvarcharsはvarcharsの「2倍」であるとよく言われることを知っているので、varcarを保持するための1つの論点として、ストレージスペースの使用が考えられます。 ただし、今日のユーザーは、ストレージスペースを節約したい場合、デフォルトのUTF-16ではなくUTF-8としてデータを保存するようにnvarcharを定義できます。これにより、主に望ましい場合は8ビットエンコーディングが可能になりますが、DBに挿入される2〜8バイトのまれな文字が何も破損しないことが保証されます。 何か不足していますか?過去15〜20年でこれが変わっていない理由はありますか?

1
SQL Server:CREATE INDEXコマンドの進行状況を追跡する方法は?
SQL Server 2014、標準エド 私は、dm_exec_requestsのpercent_completeがCREATE INDEXで機能せず、実際には、percent_completeが0のままになることを読んだことがあります。 現在、以下の方法を使用しています。これは、少なくとも動きを示しています(インデックス作成がブロックされていないこと)。しかし、プロセスを経て%10であるか、%99であるかはわかりません。 ここで説明した方法を試しました:https : //dba.stackexchange.com/a/102545/6229 しかし、それは明らかに間違ったest完了時間を示しています) どうすれば手掛かりを得ることができますか? SELECT percent_complete, estimated_completion_time, reads, writes, logical_reads, text_size, * FROM sys.dm_exec_requests AS r WHERE r.session_id <> @@SPID AND r.session_id = 58

2
SQL Serverでは、ストアドプロシージャをグループ化する目的は何ですか?
私が対処しなければならなかった最も厄介な問題の1つは、ストアドプロシージャグループに関係しています。ストアドプロシージャを指定するとusp_DoSomethingAwesome、を呼び出すことで別のグループにそのプロシージャを作成できますusp_DoSomethingAwesome;2。 システムによって生成された挿入、更新、および削除のレプリケーションストアドプロシージャの一部で発生したレプリケーションの問題(パブリッシャー:SQL 2000 Ent。、Dist / Sub:2008 R2 Ent。)のトラブルシューティングでこれを発見しました。 この「グループ化」能力を持つ背後にある目的/考え方は何ですか?

2
存在する場合、埋め込みSELECTステートメントよりも時間がかかります
次のコードを実行すると、22.5分かかり、1億6千万回の読み取りを行います。ただし、内側のselectステートメントだけを実行すると、15秒しかかからず、264kの読み取りが実行されます。補足として、選択クエリはレコードを返しません。 なぜIF EXISTSそれが非常に長く実行され、非常に多くの読み取りを行うのでしょうか?select文も変更しSELECT TOP 1 [dlc].[id]て、2分後に殺しました。 一時的な修正として、count(*)を実行し、その値を変数に割り当てるように変更しました@cnt。次に、IF 0 <> @cntステートメントを実行します。しかしEXISTS、selectステートメントでレコードが返された場合、少なくとも1つのレコードが見つかったらスキャン/シークの実行を停止count(*)し、完全なクエリを完了するため、より良いと思いました。私は何が欠けていますか? IF EXISTS (SELECT [dlc].[ID] FROM TableDLC [dlc] JOIN TableD [d] ON [d].[ID] = [dlc].[ID] JOIN TableC [c] ON [c].[ID] = [d].[ID2] WHERE [c].[Name] <> [dlc].[Name]) BEGIN <do something> END


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