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

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

1
データベースユーザーとサーバーログイン、およびそれらの間のマッピング
自宅にSQL Server 2008 R2 Express Editionのインスタンスがあり、Accessをフロントエンドとして使用してアプリケーションを開発するために使用しているクライアント構内のサーバーに別のインスタンスがあります。このアプリケーションには、接続文字列で使用できる5つの個別のログインがあります（ユーザーがいるアクセスグループに基づきます）。ホームインスタンスにはいくつかのデータベースがあります-一部はこのアプリケーションとは何の関係もありません 時間の経過とともに、各インスタンスのログインを手動で作成しました（おそらく別の順序で）。 私が作業しているデータベースのホームマシンからバックアップを（複数回）取得し、復元を使用してクライアントプレミスのインスタンスにロードし、バックアップセットのファイルを実際のファイルに移動することを望んでいます復元処理中にこのサーバーで使用されるファイル。私が理解していない部分は、データベースユーザーとログインの間のマッピングです。 名前の対応で十分だと思っていましたが、復元されたデータベースのユーザーがサーバーログインにマップされていないように見える問題を修正しようとして、Transact-SQLのALTER USERステートメント、特にWITH LOGINの使用への言及と「SID」に関する議論。 サーバーのログイン名にはインスタンスごとに異なるSIDがあると思いますが、インスタンス間のバックアップをロードした後、一連のALTER USER WITH LOGINコマンドを使用してマッピングを再接続する必要があるということですか？
1
「select * into targettable from sourcetable from」が「insert into targettable select * from sourcetable」よりも速い理由
このタイトルが問題です。答えを知りたいです。誰かが言った select intoは最小限のログに記録されます単純な復旧モデルデータベース...私はそれにまったく入りませんでした。 Microsoftからの抜粋： SELECT ... INTOのログの量は、データベースで有効な復旧モデルによって異なります。単純復旧モデルまたは一括ログ復旧モデルでは、一括操作のログは最小限に抑えられます。最小限のロギングで、SELECT…INTOステートメントを使用すると、テーブルを作成してINSERTステートメントでテーブルを生成するよりも効率的です。 助けを求める ありがとう
5
SQL Selectの実行に時間がかかりすぎる
これは一時テーブルからの単純な選択であり、既存のテーブルを主キーに結合したままにします。結合されたテーブルを参照するトップ1を使用する2つのサブ選択があります。 コードで： SELECT TempTable.Col1, TempTable.Col2, TempTable.Col3, JoinedTable.Col1, JoinedTable.Col2, ( SELECT TOP 1 ThirdTable.Col1 -- Which is ThirdTable's Primary Key FROM ThirdTable WHERE ThirdTable.SomeColumn = JoinedTable.SomeColumn ) as ThirdTableColumn1, ( SELECT TOP 1 ThirdTable.Col1 -- Which is also ThirdTable's Primary Key FROM ThirdTable WHERE ThirdTable.SomeOtherColumn = JoinedTable.SomeColumn ) as ThirdTableColumn2, FROM …
1
動的SQLのパラメーターの印刷
私は多くのタスクで動的SQLを使用しており、同じ問題に継続的に遭遇しました：動的T-SQLステートメント内で使用される変数の値を出力します。 例えば： Declare @SQL nvarchar(max), @Params nvarchar(max), @DebugMode bit, @Foobar int select @DebugMode=1,@Foobar=364556423 set @SQL='Select @Foobar' set @Params=N'@Foobar int' if @DebugMode=1 print @SQL exec sp_executeSQL @SQL,@Params ,@Foobar=@Foobar 上記のコードの印刷結果は、単に "Select @Foobar"です。実行中のSQLの値と変数名を動的に出力する方法はありますか？または、印刷を行うときに、SQLを再実行できるようにパラメーターを実際の値に置き換えますか？ 同様のことを行うために関数を1つまたは2つ作成しましたが、データ型変換、パターンマッチングの切り捨ての問題、非動的な解決策を試しました。他の開発者がすべての変数を手動で印刷せずにこの問題を解決する方法に興味があります。
2
Oracleに移行するSQL Server開発者向けのリソース
Oracleの基本を学びたいSQL Server開発者にどのようなリソースを推奨できますか？ これらのシステムの違いを説明し、IDENTITY列を作成する方法などの質問に答える包括的なホワイトペーパーまたはブログ投稿を探しています。またはfloatに相当するデータ型は何ですか？。
1
SQL Serverのパフォーマンスを向上させるために、2つ以上のテーブルのJOIN結果にインデックスを付ける方法
私はインデックス作成に慣れていないため、インデックス作成の基本を学びました。対応するテーブルのインデックス部分内にある主キー制約のデフォルトのクラスター化インデックスを見つけることができますが、外部キー制約を作成した後は見つかりません。 これで、パフォーマンスを向上させるためにインデクシングを実装する必要があるという要件があります。JOINの結果のパフォーマンスを向上させるために、外部キーのインデックス付けについて読みました。 外部キー列を追加の非クラスター化インデックスに追加する必要がありますか、それとも外部キーにデフォルトのインデックスがありますか？ SQLテーブルの構造が次のようで、t1_col3を使用してWHERE句を含むJOINクエリを実行している場合、どのようにして効率的にインデックスを実装できますか table1 table2 ------ ------ t1_col1(pk) t2_col1(pk) t1_col2 t2_col2 t1_col3 t2_col3 t1_col4 t2_col4 t2_col1(FK)
3
すべてのSQL Serverを実行する単一のサービスアカウント
同じサーバーアカウントとエージェントアカウントを使用して、SQL ServerとSQL Agentをそれぞれ35サーバーの小規模な会社で実行されているすべてのSQLサーバーインスタンスに対して実行すると、パフォーマンスに悪影響がありますか？最大のデータベースは0.5 GBです。どんな提案も大歓迎です。ありがとうございました。
1
sp_prepexec（sp_execute）とsp_executeSQL
質問の要点：実際のストアドプロシージャは、一時テーブルキャッシュを実装する唯一のメカニズムですか、それともsp_executeSQL/ などのシステムストアドプロシージャsp_executeもそれらを利用しますか？ 私はDBAではないので、少しだけ言葉を使ってください。私たちのアプリケーションは、プロファイラーから、sp_prepexec実行sp_prepareとの両方のシステムプロシージャであるすべてのSQLを実行する準備済みステートメントを送信しますsp_execute。私がやろうとしているのは、一時テーブルのキャッシュから利益を得ているかどうかを判断することです。 このガイドをobject_id（）と一緒に使用して動作を調べています https://sqlkiwi.blogspot.com/2012/08/temporary-tables-in-stored-procedures.html 次に、このブログ投稿のポイント3は、EXECは一時テーブルキャッシュを使用できないことを示していますが、sp_executeSQLができるかどうかは省略しています：http : //blogs.msdn.com/b/turgays/archive/2013/09/18/exec-vs- sp-executesql.aspx クライアント経由で送信されたクエリでは、単純な一時テーブルを作成しました。 DECLARE @foo int; -- set by JDBC, unused but required to force a prepared statement SELECT 1 AS id INTO #tmp SELECT OBJECT_ID('tempdb..#tmp'); プロファイラーで、私は見ることができます： declare @p1 int set @p1=NULL exec sp_prepexec @p1 output,N'@P1 int',N'declare @foo INT = @P1 SELECT 1 …
1
使用されているデータベースミラーリングプロトコルのTCPポート。1つのデフォルト、1つのダイナミック？
SQL Server Always On可用性グループ™のプライマリ/セカンダリレプリカで以下のクエリを実行する場合 SELECT DISTINCT local_tcp_port,protocol_type,num_reads,num_writes FROM sys.dm_exec_connections WHERE local_net_address is not null; 2つのローカルTCPポートは、データベースミラーリングプロトコルに現れ、5022＆63420 Server Name local_tcp_port protocol_type num_reads num_writes ServerName 5022 Database Mirroring 102942598 5 ServerName 63420 Database Mirroring 5 89655349 5022これはミラーリングエンドポイントとして構成された一つであるとポートが、期待されています。 もう1つは動的ポートのようですが、なぜこのポートを使用するのですか。 1つは多数の読み取り（5022）を示し、もう1つは多数の書き込み（63420）を示しているという事実と関係があるのでしょうか。 ビルドバージョン：13.0.5264.1
2
パラメータ付きのこの再帰的CTEがリテラルで行うとき、なぜインデックスを使用しないのですか？
ツリー構造で再帰CTEを使用して、ツリー内の特定のノードのすべての子孫をリストしています。WHERE句にリテラルノード値を書き込むと、SQL Serverは実際にその値にのみCTEを適用し、実際の行数が少ないクエリプランなどを提供します。 ただし、値をパラメーターとして渡すと、CTEが実現（スプール）され、事実の後でフィルター処理されるようです。 私は計画を間違って読んでいた可能性があります。パフォーマンスの問題には気づきませんでしたが、CTEの実現により、特にビジーなシステムでは、より大きなデータセットで問題が発生する可能性があると心配しています。また、私は通常、このトラバーサルをそれ自体で複合します。祖先までトラバースし、子孫まで戻ります（すべての関連ノードを確実に収集するため）。私のデータが原因で、「関連」ノードの各セットはかなり小さいため、CTEの実現は意味がありません。また、SQL ServerがCTEを実現しているように見える場合、その「実際の」数には非常に多くの数値が含まれています。 クエリのパラメーター化されたバージョンをリテラルバージョンのように機能させる方法はありますか？CTEを再利用可能なビューにしたいと考えています。 リテラルを使用したクエリ： CREATE PROCEDURE #c AS BEGIN; WITH descendants AS (SELECT t.ParentId Id ,t.Id DescendantId FROM #tree t WHERE t.ParentId IS NOT NULL UNION ALL SELECT d.Id ,t.Id DescendantId FROM descendants d JOIN #tree t ON d.DescendantId = t.ParentId) SELECT d.* FROM descendants d WHERE …
1
where句で 'contains'と '='を一緒に使用するとクエリが遅くなる
次のクエリは、12kレコードのテーブルで完了するまでに約10秒かかります select top (5) * from "Physician" where "id" = 1 or contains("lastName", '"a*"') しかし、where句を次のいずれかに変更した場合 where "id" = 1 または where contains("lastName", '"a*"') すぐに戻ります。 両方の列にインデックスが付けられ、lastName列にもフルテキストインデックスが付けられます。 CREATE TABLE Physician ( id int identity NOT NULL, firstName nvarchar(100) NOT NULL, lastName nvarchar(100) NOT NULL ); ALTER TABLE Physician ADD CONSTRAINT Physician_PK PRIMARY …
1
DBCC CheckDBの後にパフォーマンスモニターのデータベースキャッシュメモリが大幅に低下する
私たちはいくつかSQLServer: Memory Managerの指標を監視しており、DBCC CheckDB仕事の後、指標が Database Cache Memory (KB) 大幅に低下します。正確には、キャッシュされた140 GBのDBメモリから60 GBに減少しました。その後、週の間にゆっくりと再び増加します。（「Free Memory KB」の量は、直後に20 GBから100 GBになりましたCheckDB） DBCC CheckDB は毎週日曜日に実行されるため、データベースキャッシュメモリは毎週再び増加する必要があります What is the behavior of this ? Why CheckDB pushes database pages out of memory ? 2番目の質問は、「buffer cache hit ratio」がDBCC CheckDB完了後に変更されなかった理由です。 データベースのデータをストレージからRAMに再度読み込む必要があるため、平均して99.99％で、DBCC CheckDBジョブ終了後は約98.00％に低下し、99％にかなり速くbuffer cache hit ratio戻ります。
3
DBテーブルでのSPIDの使用（テーブル変数の代わり）
予約に使用されるトランザクションデータベース... 私たちのベンダーは、＃temptablesを@tablevariablesに置き換えるように依頼されました（コンパイルロックが重いため）。代わりに、SPIDを列として追加する実際のテーブルに置き換えて、ストアドプロシージャが適切な行でのみ機能するようにしました。 この操作方法にリスクはありますか？すべてのトランザクションが独自のトランザクション内に分離される前に...このテーブルを大量にロックしてしまうのではないかと心配しましたが、SQLは行レベルのロックを使用しているため、これ以上のロックは作成されないというのが彼らの意見です。 SQL Serverバージョン：2016 Enterprise-13.0.5216.0 CREATE TABLE dbo.qryTransactions ( ID int IDENTITY (0,1) NOT NULL CONSTRAINT pk_qryTransactions PRIMARY KEY CLUSTERED, spid int NOT NULL, OrderID int, ItemID int, TimeTransactionStart datetime, TimeTransactionEnd datetime, ...other fields ) CREATE INDEX idx_qryTransactions_spidID ON qryTransactions (spid, ID) INCLUDE (ItemID, OrderID, TimeTransactionStart, TimeTransactionEnd)
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.