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

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

1
SQL Server 2008でデータベースを強制的に削除する方法
データベースを強制的に削除しようとしていますが、データベースを削除した後、データベースを再作成しようとするとエラーが発生します ファイルC：\ Program Files ..... [databasename] .mdfは既に存在するため作成できません データベースを強制的に削除するためのクエリを次に示します Use master; ALTER database [databasename] set offline with ROLLBACK IMMEDIATE; DROP database [databasename]; 上記のクエリはデータベースを削除し.ldfてい.mdfますが、and ファイルを削除するわけではないことを理解しました。データベースを徹底的に削除する方法は？ 通常のクエリ Drop database [databasename] ; //deletes the database completely, including the ldf and mdf's. データベースを強制的に削除する方法は、データベース.mdfと.ldfファイルも削除しますか？
4
LEFT JOINまたはNOT EXISTSの使用のベストプラクティス
LEFT JOINまたはNOT EXISTS形式を使用する間にベストプラクティスはありますか？ 一方を他方より使用する利点は何ですか？ 存在しない場合、どちらを優先すべきですか？ SELECT * FROM tableA A LEFT JOIN tableB B ON A.idx = B.idx WHERE B.idx IS NULL SELECT * FROM tableA A WHERE NOT EXISTS (SELECT idx FROM tableB B WHERE B.idx = A.idx) SQL Serverデータベースに対してAccess内でクエリを使用しています。
8
SQL ServerのMAXDOP設定アルゴリズム
新しいSQL Serverをセットアップするとき、次のコードを使用して、MAXDOP設定の適切な開始点を決定します。 /* This will recommend a MAXDOP setting appropriate for your machine's NUMA memory configuration. You will need to evaluate this setting in a non-production environment before moving it to production. MAXDOP can be configured using: EXEC sp_configure 'max degree of parallelism',X; RECONFIGURE If this instance is hosting a …
4
インデックスシークとインデックススキャン
実行速度の遅いクエリの実行プランを見ると、ノードの一部がインデックスシークであり、一部がインデックススキャンであることがわかりました。 インデックスシークとインデックススキャンの違いは何ですか？ どちらがパフォーマンスが良いですか？ SQLはどのように一方を選択しますか？ これは3つの質問ですが、最初の質問に答えると他の質問も説明できると思います。
3
3つの列のうち1つだけがNULLでないチェック制約
FLOAT、NVARCHAR（30）、またはDATETIME（3つの独立した列）の3種類の結果を含む（SQL Server）テーブルがあります。特定の行について、1つの列のみが結果を持ち、他の列がNULLであることを確認したい。これを達成するための最も単純なチェック制約は何ですか？ このコンテキストは、非数値の結果を既存のシステムに取り込む機能を改良しようとしています。行ごとに複数の結果を防ぐために2つの新しい列を制約付きでテーブルに追加することが最も経済的なアプローチであり、必ずしも正しいものではありません。 更新：申し訳ありませんが、データ型はsnafuです。悲しいことに、示された結果の型をSQL Serverのデータ型として解釈するつもりはなく、単に一般的な用語が修正されました。
1
SQL Serverからデフォルトで取得できるイベント情報は何ですか？
特定の事柄が発生したかどうか、いつ発生したか、誰がアクションを実行したかを人々が知りたい質問をよく見ます。多くの場合、SQL Serverはこの情報を独自に追跡しません。例えば： ストアドプロシージャを最後に実行したのは誰dbo.MyProcedureですか？ テーブルのsalary列を更新したのは誰dbo.Employeesですか？ 誰が最後にdbo.OrdersManagement Studioにテーブルを照会しましたか？ ただし、SQL Server がデフォルトで一時的に追跡するイベントは他にもいくつかあり、次のような質問にネイティブに答えることができます。 AdventureWorksデータベースで自動拡張が最後に行われたのはいつで、どのくらいかかりましたか？ 誰がdbo.EmployeeAuditDataいつテーブルを削除しましたか？ 今日、メモリ関連のエラーがいくつ発生しましたか？ この情報を取得するにはどうすればよいですか？
5
varcharとnvarcharの違いを記述する
現在、SQL Server 2012データベースではを使用していますが、これvarcharを変更したいと考えていnvarcharます。そのためのスクリプトを生成しました。 私の質問は、SQL Serverがvarchar列に書き込む方法と列に書き込む方法に違いはありnvarcharますか？私が心配している多くのバックエンド手順があります。 編集： これが役立つかどうかはわかりませんが、列にはインデックス、f / k、またはそれらの制約がありません。
7
簡単な銀行スキーマの作成：残高を取引履歴と同期させるにはどうすればよいですか？
単純な銀行データベースのスキーマを書いています。基本的な仕様は次のとおりです。 データベースは、ユーザーと通貨に対するトランザクションを保存します。 すべてのユーザーは通貨ごとに1つの残高を持っているため、各残高は特定のユーザーと通貨に対するすべてのトランザクションの合計です。 残高をマイナスにすることはできません。 銀行のアプリケーションは、ストアドプロシージャを介してデータベースとのみ通信します。 このデータベースは、1日に数十万件の新しいトランザクションを受け入れ、さらに高いレベルでクエリのバランスを取ることを期待しています。残高を非常に迅速に提供するには、事前に集計する必要があります。同時に、残高が取引履歴と矛盾しないことを保証する必要があります。 私のオプションは次のとおりです。 別のbalancesテーブルを用意して、次のいずれかを実行します。 トランザクションをテーブルtransactionsとbalancesテーブルの両方に適用します。TRANSACTIONストアドプロシージャレイヤーのロジックを使用して、残高とトランザクションが常に同期されるようにします。（Jackによるサポート。） transactionsテーブルにトランザクションを適用balancesし、トランザクション量でテーブルを更新するトリガーを使用します。 balancesテーブルにトランザクションを適用transactionsし、トランザクション量とともにテーブルに新しいエントリを追加するトリガーを使用します。 ストアドプロシージャの外部で変更が行われないようにするには、セキュリティベースのアプローチに頼る必要があります。そうしないと、たとえば、一部のプロセスがtransactionsテーブルにトランザクションを直接挿入し、スキーム1.3の下で関連するバランスが同期しなくなる可能性があります。 balancesトランザクションを適切に集約するインデックス付きビューを用意します。残高はトランザクションと同期するようにストレージエンジンによって保証されているため、これを保証するためにセキュリティベースのアプローチに依存する必要はありません。一方、ビュー（インデックス付きビューでも）にCHECK制約を設定することはできないため、バランスを負以外に強制することはできません。（Dennyによるサポート。） transactionsテーブルだけがありますが、そのトランザクションの実行直後に有効な残高を保存するための追加の列があります。したがって、ユーザーと通貨の最新のトランザクションレコードには、現在の残高も含まれます。（Andrewが以下に提案。garikが提案したバリアント。） この問題に最初に取り組んだとき、私はこれら 2つの議論を読み、オプションを決定しました2。参考のために、ここでそれのベアボーン実装を見ることができます。 このようなデータベースを高負荷プロファイルで設計または管理しましたか？この問題の解決策は何ですか？ 私が正しいデザインを選んだと思いますか？留意すべきことはありますか？ たとえば、transactionsテーブルのスキーマを変更するには、balancesビューを再構築する必要があることを知っています。データベースを小さく保つためにトランザクションをアーカイブしている場合でも（たとえば、他の場所に移動してサマリートランザクションに置き換えることで）、スキーマの更新ごとに数千万のトランザクションからビューを再構築する必要がある場合、展開ごとのダウンタイムが大幅に長くなる可能性があります。 インデックス付きビューを使用する方法がある場合、マイナスの残高がないことをどのように保証できますか？ トランザクションのアーカイブ： アーカイブトランザクションと上記の「サマリートランザクション」について少し詳しく説明します。まず、このような高負荷システムでは定期的なアーカイブが必要になります。古い取引を別の場所に移動できるようにしながら、残高と取引履歴の間の一貫性を維持したいと思います。これを行うには、アーカイブされたトランザクションのすべてのバッチを、ユーザーと通貨ごとの金額のサマリーに置き換えます。 したがって、たとえば、このトランザクションのリスト： user_id currency_id amount is_summary ------------------------------------------------ 3 1 10.60 0 3 1 -55.00 0 3 1 -12.12 0 アーカイブされ、これに置き換えられます： user_id currency_id amount is_summary ------------------------------------------------ 3 1 -56.52 1 …
5
ALTER COLUMN to NOT NULLが大量のログファイルの増加を引き起こすのはなぜですか？
データ用にディスク上に4.3 GBを使用する64m行のテーブルがあります。 各行は約30バイトの整数列に加えて、NVARCHAR(255)テキスト用の可変列です。 data-typeのNULLABLE列を追加しましたDatetimeoffset(0)。 次に、すべての行でこの列を更新し、すべての新しい挿入でこの列に値が配置されるようにしました。 NULLエントリがなくなったら、このコマンドを実行して新しいフィールドを必須にしました。 ALTER TABLE tblCheckResult ALTER COLUMN [dtoDateTime] [datetimeoffset](0) NOT NULL その結果、トランザクションログサイズが大幅に増加しました。スペースがなくなるまで、6GBから36GBを超えました。 SQL Server 2008 R2がこの単純なコマンドでこのような大きな成長をもたらすために一体何をしているのか、誰にもわかりませんか？
6
ウィンドウ関数を使用した日付範囲のローリングサム
日付範囲でローリングサムを計算する必要があります。説明するために、AdventureWorksサンプルデータベースを使用して、次の仮想構文で必要なことを正確に実行できます。 SELECT TH.ProductID, TH.TransactionDate, TH.ActualCost, RollingSum45 = SUM(TH.ActualCost) OVER ( PARTITION BY TH.ProductID ORDER BY TH.TransactionDate RANGE BETWEEN INTERVAL 45 DAY PRECEDING AND CURRENT ROW) FROM Production.TransactionHistory AS TH ORDER BY TH.ProductID, TH.TransactionDate, TH.ReferenceOrderID; 悲しいことに、RANGEウィンドウフレーム範囲は現在SQL Serverで間隔を許可していません。 サブクエリと通常の（非ウィンドウ）集計を使用してソリューションを作成できることを知っています。 SELECT TH.ProductID, TH.TransactionDate, TH.ActualCost, RollingSum45 = ( SELECT SUM(TH2.ActualCost) FROM Production.TransactionHistory AS TH2 …
6
デッドロックの主な原因は何ですか？それを防ぐことができますか？
最近、ASP.NETアプリケーションの1つがデータベースデッドロックエラーを表示し、エラーをチェックして修正するように要求されました。デッドロックの原因は、カーソル内のテーブルを厳密に更新しているストアドプロシージャであることがわかりました。 このエラーを見たのはこれが初めてで、効果的に追跡して修正する方法がわかりませんでした。私が知っているすべての可能な方法を試してみましたが、最終的に、更新されているテーブルには主キーがないことがわかりました！幸いなことに、これはID列でした。 後で、展開用のデータベースを台無しにした開発者を見つけました。主キーを追加し、問題は解決しました。 私は幸せを感じて、私のプロジェクトに戻って、そのデッドロックの理由を見つけるためにいくつかの研究をしました... どうやら、デッドロックを引き起こしたのは循環待機状態だったようです。更新は、主キーの場合よりも主キーなしの方が明らかに時間がかかります。 明確に定義された結論ではないことを知っているので、ここに投稿しています... 主キーの欠落が問題ですか？ （相互排除、保留と待機、プリエンプションなし、循環待機）以外のデッドロックを引き起こす他の条件はありますか？ デッドロックを防止および追跡するにはどうすればよいですか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.