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

SQL Server 2012（メジャービルドバージョン11.00.xxxx）。sql-serverにもタグを付けてください。

1
キャッシュサイズと予約メモリを計画する
実際の実行計画を含むクエリを実行すると、ルート演算子（SELECT）からキャッシュされた計画サイズが32KBであることが通知されます。 sys.dm_exec_cached_plansとを結合するクエリはsys.dm_os_memory_objects、問題のプランを見て、との値が32768（32KB）であり、キャッシュされたプランのサイズと一致するpages_in_bytesと言いますmax_pages_in_bytes。 私が理解していないのは、の値sys.dm_exec_cached_plans.size_in_bytesが49152（48KB）の略であるということです。これらすべてのコラムでBOLを読みました。特に次のようsize_in_bytesに述べています。 「キャッシュオブジェクトが消費したバイト数。」 それが本当に何を意味するのか理解するために、私はパズルの最後の部分を配置することはできません。 すべての演算子（並べ替えとハッシュに使用される追加のメモリ許可については説明しません）は、キャッシュに最適化されたプランで保存される状態の保存、計算の実行などのために、ある程度の固定メモリを必要としますが、どこにありますか？ だから、私の質問は： size_in_bytes本当にどういう意味ですか 「キャッシュされた計画サイズ」よりも高い値になるのはなぜですか？ すべての演算子/イテレータのメモリの固定量はどこに予約されていますか、「キャッシュされたプランサイズ」（この例では32Kb）ですか、それとも他の場所ですか？ 私はそれらが異なる機能を持つ異なるDMVであることを知っていますが、それらは関連しています。でコンパイルされた（キャッシュされた）計画sys.dm_exec_cached_plans参加するsys.dm_os_memory_objects上でmemory_object_addressのカラム。私がここに質問を投稿する理由は、私がこれについて助けを求めて、DMVとそれらのコラムを解釈する方法を理解しているからです。 場合はsize_in_bytes、なぜSQL Serverは、実際の実行計画で別の値をキャッシュされたプランのサイズと言うんですか？ 新しいクエリ、新しい番号： 実際の計画 キャッシュされたプランサイズ16KB CompileMemory 96KB DMV： sys.dm_exec_cached_plans.size_in_bytes 24KB sys.dm_os_memory_objects.pages_in_bytes, .max_pages_in_bytes 16KB。 また、このクエリでは、並べ替えおよびハッシュ操作に追加のメモリ許可が必要ないことに注意してください。 Microsoft SQL Server 2012-11.0.5343.0（X64）
1
マルチステートメントTVFとインラインTVFパフォーマンス
Palindromeの質問に対する回答の一部を比較すると（回答を削除したため、1万人以上のユーザーのみ）、紛らわしい結果が得られています。 複数のステートメント、スキーマにバインドされたTVFを提案しました。これは、標準関数を実行するよりも高速だと思いました。また、以下に示すように、マルチステートメントTVFは「インライン化」されるという印象もありましたが、その点では間違っています。この質問は、TVFのこれら2つのスタイルのパフォーマンスの違いに関するものです。まず、コードを確認する必要があります。 次に、複数ステートメントのTVFを示します。 IF OBJECT_ID('dbo.IsPalindrome') IS NOT NULL DROP FUNCTION dbo.IsPalindrome; GO CREATE FUNCTION dbo.IsPalindrome ( @Word NVARCHAR(500) ) RETURNS @t TABLE ( IsPalindrome BIT NOT NULL ) WITH SCHEMABINDING AS BEGIN DECLARE @IsPalindrome BIT; DECLARE @LeftChunk NVARCHAR(250); DECLARE @RightChunk NVARCHAR(250); DECLARE @StrLen INT; DECLARE @Pos INT; SET @RightChunk = …
1
表の変更中に「許容される最大行サイズ8060より大きいサイズ8074の行を作成できません」
テーブルの列を変更しようとしています。既存のテーブルは次のとおりです。 CREATE TABLE [dbo].[table]( [id1] [int] NOT NULL, [id2] [int] NOT NULL, [id3] [int] NOT NULL, [name] [nvarchar](255) NOT NULL, [id4] [int] NOT NULL, [xmlData] [xml](CONTENT [dbo].[xml_schema]) NULL, [booleanData1] [bit] NOT NULL, [notes] [varchar](4096) NULL, [id5] [int] NULL, [booleanData2] [bit] NULL, [id6] [int] NULL, CONSTRAINT [PK_table] PRIMARY KEY CLUSTERED ([id1] …
3
この結合カーディナリティの推定値が非常に大きいのはなぜですか？
私は、次のクエリのカーディナリティの推定値が非常に高いと思うことを経験しています： SELECT dm.PRIMARY_ID FROM ( SELECT COALESCE(d1.JOIN_ID, d2.JOIN_ID, d3.JOIN_ID) PRIMARY_ID FROM X_DRIVING_TABLE dt LEFT OUTER JOIN X_DETAIL_1 d1 ON dt.ID = d1.ID LEFT OUTER JOIN X_DETAIL_LINK lnk ON d1.LINK_ID = lnk.LINK_ID LEFT OUTER JOIN X_DETAIL_2 d2 ON dt.ID = d2.ID LEFT OUTER JOIN X_DETAIL_3 d3 ON dt.ID = d3.ID ) …
2
AlwaysOn可用性グループの使用中にトランザクションログを圧縮する
私たちは、使用しているAlwaysOn Availability Group2012年の正規完全データベースバックアップとトランザクションログのバックアップがセカンダリデータベース上で毎日行われているSQL Serverの機能を。 私は読んだことが、ここでのプライマリレプリカまたはセカンダリレプリカのいずれかにトランザクションログのバックアップを行うことは、再利用可能なよう両方のレプリカトランザクション・ログをマークします。とにかく、トランザクションログのバックアップサイズは大きく、縮小ファイルを使用して縮小できます。 データベースをローカルに復元し、縮小操作を実行しました。ログファイルのサイズは160 MBに縮小されました。 私の質問は、どのデータベースでトランザクションログファイル（プライマリ、セカンダリ、またはその両方）の縮小操作を実行する必要があるかということです。 過去数年間、ログファイルのバックアップは作成されていなかったため、非常に大きくなりました。実行するDBCC SQLPERF (LOGSPACE)と0.06%、ファイルのみが使用されていることがわかります。このような巨大なサイズのログファイルを保持する意味はありません。で[sys].[database_files]、私はそのことを確認してくださいがmax_sizeに設定されている-1とgrowthする65536ことは、それが得るより多くのスペースを必要とするとき、私は推測するようにします。とにかく、将来の成長を防ぐために、たとえば5％に縮小できます。私はそうすることは悪い考えではないという確認を見つけようとしています。 実際、（データベースとログファイルの）バックアップはセカンダリデータベースでのみ実行されるため、それらのデータベースでシュリンクファイルを実行する方が簡単ですが、プライマリログファイルのサイズも小さくなりますか？
2
SQL Serverが実際に使用しているコアの数を確認するにはどうすればよいですか？
SQL Serverを実行している2つのサーバーがあります。 サーバー1：SQL Server 2008 R2 Express（4コア） サーバー2：SQL Server 2012 Developer Edition（8コア） 私の知る限り、SQL Server 2008 R2 Expressは1つのコアのみを使用する必要があります。 SQL Server 2012 Developerバージョンでは、8つのコアすべてを使用する必要があります。 ただし、SQL Server 2008 R2 ExpressでSQLクエリ内で次のコマンドを実行すると、4つのコアが表示されます。 select scheduler_id, cpu_id, status, is_online from sys.dm_os_schedulers where status = 'VISIBLE ONLINE' 適切なコマンドを使用して使用量を測定していますか？
2
VARCHARからVARBINARYへの変換
パフォーマンスの傾向を監視し、最適化が必要な領域を特定できるように、実行中の高価なクエリのログとクエリプランをテーブルに保存しています。 ただし、クエリプランが多くのスペースを占有するようになります（各クエリに対してプラン全体を保存しているため）。 したがって、QueryPlanHashとQueryPlanを別のテーブルに抽出することにより、既存のデータを正規化しようとしています。 CREATE TABLE QueryPlans ( QueryPlanHash VARBINARY(25), QueryPlan XML, CONSTRAINT PK_QueryPlans PRIMARY KEY ( QueryPlanHash ) ); query_plan_hashin の定義はsys.dm_exec_query_statsバイナリフィールドであるため（また、定期的に新しいデータを挿入します）、VARBINARY新しいテーブルのデータ型に使用していました。 ただし、以下の挿入は失敗します... INSERT INTO QueryPlans ( QueryPlanHash, QueryPlan ) SELECT queryplanhash, queryplan FROM ( SELECT p.value('(./@QueryPlanHash)[1]', 'varchar(20)') queryplanhash, QueryPlan, ROW_NUMBER() OVER (PARTITION BY p.value('(./@QueryPlanHash)[1]', 'varchar(20)') ORDER BY DateRecorded) rownum FROM …
2
SQL Serverの接続権限を制限する
「名誉システム」セキュリティを使用する運用環境に展開するアプリがあります。つまり、すべてのユーザーがSQLユーザー/パスワード資格情報を使用してDBに接続し、アプリ自体が権限を管理します。後者の部分は、接続オブジェクトに埋め込まれた資格情報が含まれており、自由にコピーできるという事実ほど気にしません。接続をより限定的なクライアントのセットに制限する方法を見つけようとしています。もちろん、IPで制限するファイアウォールルールを作成できます。マシンアカウントまたはドメインメンバシップのいずれかでSQLログインを「事前認証」する方法はありますか？
1
クエリプラン「Cardinality Estimate」の警告
create table T(ID int identity primary key) insert into T default values insert into T default values go select cast(ID as varchar(10)) as ID from T where ID = 1 上記のクエリのクエリプランには警告があります。 <Warnings> <PlanAffectingConvert ConvertIssue="Cardinality Estimate" Expression="CONVERT(varchar(10),[xx].[dbo].[T].[ID],0)" /> </Warnings> なぜ警告があるのですか？ フィールドリストのキャストは、カーディナリティの見積もりにどのように影響しますか？
5
テーブルをテキストファイルにエクスポートする最速の方法は何ですか
SQL Server 2012データベースと、300万行、おそらく50列のテーブルがあります。無人のバックグラウンドの.netプロセス（SQLまたはPowershellコマンドを発行する可能性があります）をテキストファイルにエクスポートする最速の方法は何ですか？.netプロセスは、エクスポートがいつ完了したか、またはエラーが発生したかどうかを知る必要があります。データ型はall intまたはになりnvarcharます。 私は、ado.netを使用してselect *コマンドを実行し、データリーダーをループして各レコードのファイルに書き込む純粋なC＃コードは低速であり、これを並列化する方法はないと想定しています。 エクスポートは、SQL Serverマシンのローカルフォルダーではなく、リモート共有ネットワークフォルダーに行うことが理想的です。SQL ServerはHAクラスターになります。SSISはこれに適していますか、データ変換は必要ありませんか？ .NetプロセスはマシンAで実行され、SQL ServerはマシンBで実行され、最終的なファイルの宛先はネットワーク共有です。1つのオプションは、SQLサーバーがファイルをネットワーク共有に直接書き込むことです。もう1つのオプションは、SQL ServerがマシンAに書き込み、ファイルが書き込まれると、.netプロセスがそれをネットワーク共有にコピーすることです。正式なSLAはありませんが、ファイルの書き込みに30分から1時間かかります。
3
特定の列の更新を制限します。ストアドプロシージャによるこれらの列の更新のみを許可する
ストアドプロシージャを通じてのみ更新したい繊細な価格列があります。更新するように設計されたストアドプロシージャを使用していない場合、すべてのコードまたは手動でこれらの価格列の値を変更しようとすると失敗します。 トリガーとトークンテーブルを使用してこれを実装することを検討しています。私が考えているアイデアは、トークンテーブルを持つことです。ストアドプロシージャは、最初にトークンテーブルに値を挿入する必要があります。次に、価格列を更新します。更新トリガーは、更新された行のトークンテーブルにトークンが存在するかどうかを確認します。見つかった場合、続行します。トークンが見つからない場合、例外をスローし、更新トランザクションを失敗させます。 この制限を実装する良い/より良い方法はありますか？
6
SQL Server Management Studio 2012：SSMSプロジェクトにフォルダーを含める方法
SSMS 2012を使用して、使用しているSQL Server 2012およびAzure SQLサーバーと通信しています。私はSQLの専門家ではないので、将来の参考のためにほとんどのSQLスクリプトを保存しています。SSMSプロジェクトで20個ほどの.SQLスクリプトにすぐに遭遇しましたが、それらはすべて同じ「クエリ」フォルダーの下にあります。 プロジェクトに「サブフォルダー」を作成して、スクリプトを適切に整理する方法はありますか？他のほとんどの人はどのようにスクリプトを整理しますか？このバグが私のような初心者であれば、実際の管理者にとっては本当の問題であるに違いありません（潜在的に何百ものスクリプトを使用していますか？）
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.