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

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

2
フラグの配列(ビットマップ/ビット配列)を格納するためのデータ型
テーブルの各レコードにビット配列を保存し、次の操作をサポートする必要があります。 ビットが設定されているかどうかのテスト、およびビットの設定(SQLを使用) ADO 2.8(ADO.NETではない)を使用した値のクエリと設定 インデックス作成(「カバーインデックス」機能を活用するため) この配列に格納されるビットの最大数は固定されていますが、32を超える場合があります。つまり、単純なint列は常に機能するとは限りません。 これまで見てきたことから、私のオプションは次のとおりです。 複数のint列を使用する bigintを使用します(ビット数が64以下である限り機能します) バイナリを使用 ? 最初のオプションは機能しますが、データにアクセスするコードにかなりのリファクタリングが必要です。2番目のオプションは一時的な救済であり、これまでの検索では、ADOがbigintでうまく機能するかどうかはあまりわかりません。binaryの経験がなく、他のオプションを認識していません。 要件を考慮して、どのデータ型を選択しますか?

3
存在しない場合は、コードによって新しい関数を作成します
データベースにスクリプトで新しい関数を作成したい。スクリプトコードは次のとおりです。 IF Exists(Select * From sys.sysobjects A Where A.name =N'fn_myfunc' and xtype=N'FN') return; CREATE FUNCTION fn_myfunc () returns varchar(10) AS Begin ... End しかし、上記のスクリプトを実行すると、SQL Serverはエラーを返します。 'CREATE FUNCTION' must be the first statement in a query batch.

4
主キーでソート順が指定されているが、SELECTでソートが実行されている
センサーデータをSensorValuesテーブルに格納しています。テーブルと主キーは次のとおりです。 CREATE TABLE [dbo].[SensorValues]( [DeviceId] [int] NOT NULL, [SensorId] [int] NOT NULL, [SensorValue] [int] NOT NULL, [Date] [int] NOT NULL, CONSTRAINT [PK_SensorValues] PRIMARY KEY CLUSTERED ( [DeviceId] ASC, [SensorId] ASC, [Date] DESC ) WITH ( FILLFACTOR=75, DATA_COMPRESSION = PAGE, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = …

2
SQL Serverの複数のワーカーのFIFOキューテーブル
次のstackoverflowの質問に答えようとしました: 複数のサーバーアプリケーションインスタンスで個々のテーブル行を処理するには、どのSQL Server 2005/2008ロックアプローチを使用する必要がありますか? やや素朴な答えを投稿した後、私は自分の口がどこにあるかを考え、実際に私が提案しているシナリオをテストしました。まあ、それは思ったよりもはるかに難しいことが判明しました(誰にも驚きはありません、確かです)。 ここで私が試し、考えたことがあります: まず、派生テーブル内でORDER BYを使用して、TOP 1 UPDATEを試しましたROWLOCK, READPAST。これによりデッドロックが発生し、アイテムの順序が狂って処理されました。同じ行を複数回処理しようとすることを必要とするエラーを除いて、可能な限りFIFOに近い必要があります。 私は、その後の様々な組み合わせを使用して、変数に所望の次のキューIDを選択しようとしたREADPAST、UPDLOCK、HOLDLOCK、及びROWLOCK排他的にそのセッションによって更新するための行を保存します。私が試したすべてのバリエーションは、以前と同じ問題に悩まされていましたREADPAST。 READ COMMITTEDまたはREPEATABLE READ分離レベルでのみREADPASTロックを指定できます。 READ COMMITTED であったため、これは混乱を招きました。以前にこれに遭遇したことがあり、イライラします。 この質問を書き始めてから、Remus Rusaniが質問に対する新しい回答を投稿しました。私は彼のリンクされた記事を読んで、彼が破壊的な読み取りを使用していることを確認しました。彼は答えで、「Webコールの間、ロックを保持することは現実的に不可能です」と述べた。更新または削除を行うためにロックが必要なホットスポットとページに関する彼の記事の内容を読んだ後、探していることを行うために正しいロックを実行できたとしても、それはスケーラブルではなく、大規模な並行性を処理しません。 今、どこに行けばいいのかわかりません。行の処理中にロックを維持することはできません(高tpsまたは大規模な同時実行性をサポートしていなくても)。私は何が欠けていますか? 私より賢い人と私より経験のある人が助けてくれることを期待して、私が使用していたテストスクリプトを以下に示します。TOP 1 UPDATEメソッドに切り替えられますが、他のメソッドを残し、コメントアウトしてありますので、あなたもそれを調べたいと思います。 これらをそれぞれ別のセッションに貼り付け、セッション1を実行してから、他のすべてをすばやく実行します。約50秒でテストは終了します。各セッションからのメッセージを見て、どのような作業を行ったか(またはどのように失敗したか)を確認してください。最初のセッションでは、存在するロックと処理中のキューアイテムの詳細を2回目に撮影したスナップショットを含む行セットが表示されます。それは時々機能し、他の時間はまったく機能しません。 セッション1 /* Session 1: Setup and control - Run this session first, then immediately run all other sessions */ IF Object_ID('dbo.Queue', 'U') IS NULL CREATE …

2
dboスキーマの下にテーブルが作成されない
SSMSでテーブルを作成するとき、次のステートメントを実行すると気付きました。 CREATE TABLE [tableName]; テーブルは独自のスキーマの下に作成されます(dboではありません)。したがって、dboスキーマの下で作成するには、次のように明示的に宣言する必要があります。 CREATE TABLE [dbo].[tableName]; テーブルを作成するときに[dbo]部分を指定する必要がないように、誰かが方法(サーバー全体の設定など)を知っていますか?

4
大きなインデックスのINCLUDEフィールドはシステムパフォーマンスにどのように影響しますか?
この質問は、とSQL Serverのインデックスのパフォーマンスについてですvarchar(2000)としてINCLUDEの被覆指数インチ 低速で不安定なデータベースアプリケーションのパフォーマンスを改善しようとしています。いくつかのケースでは、データのようなmultple文字列操作を含むクエリで、大VARCHAR列を介してアクセスされるSUBSTRING()、SPACE()とDATALENGTH()。アクセスの簡単な例を次に示します。 update fattable set col3 = SUBSTRING(col3,1,10) + '*' + SUBSTRING(col3,12,DATALENGTH(col3)-12) from fattable where substring(col3,10,1) = 'A' and col2 = 2 スキーマは次のようになります。 CREATE TABLE [dbo].[FatTable]( [id] [bigint] IDENTITY(1,1) NOT NULL, [col1] [nchar](12) NOT NULL, [col2] [int] NOT NULL, [col3] [varchar](2000) NOT NULL, ... 次のインデックスが定義されており、大きなテキスト列にカバーフィールドがあります。 CREATE NONCLUSTERED INDEX [IndexCol2Col3] …

2
SQL Server Frozen Ghost Cleanupの回避策が必要です
行数が5Mから1.5Gのテーブルがいくつかあります 各テーブルにはBLOBフィールドがあり、そのサイズは100バイトから30 Mバイトまで変化し、「行外の大きな値タイプ」= ONとして保存されます。 テーブルは異なるファイルグループに格納され、3〜4個のファイルがそれぞれ異なるディスク@異なるLUN @非常に高速なSAN これらのテーブルは毎日、サイズが5〜100 Gbで、60万〜150万行に拡大します。 2週間から6か月まで変化する一定の時間が経過すると、行の一部が削除されるかアーカイブDBに移動されるため、6か月以上前の作業テーブルには行がありません。 サーバーの現在の構成: SQLサーバーエンジンは2008 R2 SP1 Enterprise @ 24コア、@ 64Gb RAM SQL Serverは、追加の起動フラグを使用して実行されます。 -T 3640; (ストアドプロシージャのステートメントごとにクライアントにDONE_IN_PROCメッセージを送信する必要がありません。これは、SET NOCOUNT ONのセッション設定に似ていますが、トレースフラグとして設定されると、すべてのクライアントセッションがこのように処理されます) -T 1118;(tempDBの割り当てを一度に1pg(最初の8ページ)から1エクステントに切り替えます。) -T 2301;(意思決定支援クエリに固有の高度な最適化を有効にします。このオプションは、大規模なデータセットの意思決定支援処理に適用されます) -T 1117;(すべてのデータファイルを一度に成長させます。それ以外の場合は順番に進みます。) -E; (ファイルグループ内の各ファイルに割り当てられるエクステントの数を増やします。このオプションは、インデックスまたはデータスキャンを実行するユーザーの数が限られているデータウェアハウスアプリケーションに役立ちます) -T 834; (SQL Serverはバッファプール用に割り当てられたメモリのためのWindowsの大きなページの割り当てを使用するようにします http://msdn2.microsoft.com/en-us/library/aa366720.aspx、 http://support.microsoft。 com / kb / 920093) SQL Serverはラージページ拡張機能を使用します SQL Serverは高速ファイル初期化オプションを利用します AUTOSHRINKはすべてのデータベースでオフです 問題がある …

1
クラスター化インデックススキャンの実行回数が非常に多いのはなぜですか?
同じクエリプランを生成する2つの類似したクエリがありますが、1つのクエリプランがクラスタ化インデックススキャンを1316回実行し、もう1つのクエリプランが1回実行することを除きます。 2つのクエリの唯一の違いは、異なる日付基準です。長時間実行されるクエリは、実際には日付基準を絞り込み、引き戻すデータを減らします。 両方のクエリに役立ついくつかのインデックスを特定しましたが、クラスター化インデックススキャン演算子が1回実行するクエリと実質的に同じクエリで1316回実行する理由を理解したいだけです。 スキャンされているPKの統計を確認しましたが、比較的最新です。 元のクエリ: select distinct FIR_Incident.IncidentID from FIR_Incident left join ( select incident_id as exported_incident_id from postnfirssummary ) exported_incidents on exported_incidents.exported_incident_id = fir_incident.incidentid where FI_IncidentDate between '2011-06-01 00:00:00.000' and '2011-07-01 00:00:00.000' and exported_incidents.exported_incident_id is not null この計画を生成します。 日付範囲の基準を絞り込んだ後: select distinct FIR_Incident.IncidentID from FIR_Incident left join ( select incident_id …

5
行を返さないクエリにORDER BYを含めると、パフォーマンスに大きく影響します
単純な3つのテーブルの結合を考えると、行が返されない場合でもORDER BYを含めると、クエリのパフォーマンスが大幅に変わります。実際の問題シナリオでは、ゼロ行を返すのに30秒かかりますが、ORDER BYが含まれていない場合は即座に発生します。どうして? SELECT * FROM tinytable t /* one narrow row */ JOIN smalltable s on t.id=s.tinyId /* one narrow row */ JOIN bigtable b on b.smallGuidId=s.GuidId /* a million narrow rows */ WHERE t.foreignId=3 /* doesn't match */ ORDER BY b.CreatedUtc /* try with and without this ORDER …

2
最適化:プロシージャの最上部への変数宣言の移動
いくつかのストアドプロシージャの最適化に取り組んでいる間、DBAに座って、高いブロッキングおよび/または高い読み取り/書き込みアクティビティでいくつかのストアドプロシージャを実行しました。 DBAが言及したことの1つTABLEは、再コンパイルを回避するために、ストアドプロシージャの最上部ですべての変数(特に変数)を宣言する必要があることです。 これは私がこれを聞いた最初のものであり、私たちが持っているすべての異なるストアドプロシージャを再検討する前に、いくつかの確認を探していました。彼はそれを「コードの遅い表示」と呼び、再コンパイルはブロッキングを説明するスキーマをロックしていました。 すべての変数宣言をストアドプロシージャの先頭に移動すると、再コンパイルが減りますか?

5
SQLサーバーに対する攻撃の可能性
SQL Serverログを確認すると、次のようなエントリがいくつか表示されます。 Date: 08-11-2011 11:40:42 Source: Logon Message: Login failed for user 'sa'. Reason: Password did not match for the login provided. [CLIENT: 56.60.156.50] Date: 08-11-2011 11:40:42 Source: Logon Message: Error: 18456. Severity: 14. State: 8. Date: 08-11-2011 11:40:41 Source: Logon Message: Login failed for user 'sa'. Reason: Password did …

2
「SELECT POWER(10.0、38.0);」が算術オーバーフローエラーをスローするのはなぜですか?
私は更新しています私のIDENTITYオーバーフローチェックスクリプトをのアカウントにDECIMALしてNUMERIC IDENTITY列。 チェックの一環として、すべてのIDENTITY列のデータ型の範囲のサイズを計算します。それを使用して、その範囲の何パーセントが使い果たされたかを計算します。以下のためにDECIMAL及びNUMERIC その範囲のサイズである2 * 10^p - 2場合pの精度です。 私はテストを持つテーブルの束を作成DECIMALし、NUMERIC IDENTITY列を、次のようにその範囲を計算しようとしました。 SELECT POWER(10.0, precision) FROM sys.columns WHERE is_identity = 1 AND type_is_decimal_or_numeric ; これにより、次のエラーがスローされました。 Msg 8115, Level 16, State 6, Line 1 Arithmetic overflow error converting float to data type numeric. IDENTITYタイプの列DECIMAL(38, 0)(つまり、最大精度)に絞り込んだのでPOWER()、その値で直接計算を試みました。 以下のすべてのクエリ SELECT POWER(10.0, 38.0); SELECT CONVERT(FLOAT, (POWER(10.0, 38.0))); …

3
ベストプラクティスのSQL Serverメンテナンスプランはどのようなものですか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 私はアイントホーフェンのフォンティス大学の学生です。現在、SQL Serverツールの開発を支援するために一連のインタビューを実施しています。この分野の専門家からフィードバックをもらいたいと思います。 私の質問の1つは次のとおりです。 ベストプラクティスのSQL Serverメンテナンスプランはどのようなものですか?これにはSQL Serverメンテナンスプランを使用しますか、それともカスタムスクリプトを使用しますか?


10
SQL Serverで発生するパフォーマンスの上位3つの問題は何ですか?
私はアイントホーフェンのフォンティス大学の学生です。現在、SQL Serverツールの開発を支援するために一連のインタビューを実施しています。この分野の専門家からフィードバックをもらいたいと思います。 私の質問の1つは次のとおりです。 SQL Serverインスタンスで発生する上位3つのパフォーマンスの問題と、それらの問題の特定方法を教えてください。 特に、これを測定するために使用されるスクリプトとツールに興味があります。

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