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

SQL Server 2016(メジャービルドバージョン13.00.xxxx)。sql-serverにもタグを付けてください。

1
SQL Server 2016のテーブル命名規則とポリシー管理に関する問題
SQL Server 2012では、テーブル名にスペースを使用できないようにポリシーを設定していました。しかし、SQL Server 2016で同じポリシーを使用すると、エラーが発生します。 条件のコードは次のとおりです。 DECLARE @condition_id INT EXEC msdb.dbo.sp_syspolicy_add_condition @name=N'No Spaces', @description=N'No spaces in table names.', @facet=N'IMultipartNameFacet', @expression=N'<Operator> <TypeClass>Bool</TypeClass> <OpType>NOT_LIKE</OpType> <Count>2</Count> <Attribute> <TypeClass>String</TypeClass> <Name>Name</Name> </Attribute> <Constant> <TypeClass>String</TypeClass> <ObjType>System.String</ObjType> <Value>% %</Value> </Constant> </Operator>', @is_name_condition=4, @obj_name=N'% %', @condition_id=@condition_id OUTPUT SELECT @condition_id ポリシーのコードは次のとおりです。 DECLARE @object_set_id INT EXEC msdb.dbo.sp_syspolicy_add_object_set @object_set_name=N'Table Names_ObjectSet', @facet=N'IMultipartNameFacet', …

3
MAXTRANSFERSIZEおよびCHECKSUMが使用されている場合、TDE対応データベースを復元できません
更新:@AmitBanerjee -Microsoft SQL Server製品グループのシニアプログラムマネージャーは、MSが問題であることを調査することを確認しました。 TDEを有効にし、MAXTRANSFERSIZE> 65536 を使用してSQL Server 2016で作成したバックアップを復元するときに問題が発生しましたか(私の場合、TDEデータベースを圧縮できるように65537を選択しました)CHECKSUM。 以下は再現です: --- create database create database test_restore go -- create table create table test_kin (fname char(10)) go -- Enable TDE use master GO CREATE CERTIFICATE test_restore WITH SUBJECT = 'test_restore_cert' GO SELECT name, pvt_key_encryption_type_desc, * FROM sys.certificates WHERE name = 'test_restore' …

1
アップグレード後、SQL Server AlwaysOnデータベースが同期しないモードまたはリカバリモードでスタックする。エラー:データベース '…'バージョン782を開けません
SQL Server 2014 SP1(12.0.4422.0)からSQL Server 2016 CTP 3.2(13.0.900.73)へのアップグレードをテストしているときに、推奨される更新プロセスに従い、フェールオーバー後にデータベースが古いプライマリで起動しないという問題に遭遇しました更新されたセカンダリに。私たちの設定はプライマリレプリカと単一のセカンダリレプリカであり、私が完了した手順は次のとおりです。 同期コミットセカンダリレプリカの自動フェイルオーバーを削除する セカンダリサーバーインスタンスを新しいバージョンにアップグレードする セカンダリレプリカに手動でフェイルオーバーする 新しいプライマリレプリカでデータベースがオンラインであることを確認する 以前のプライマリレプリカを新しいバージョンにアップグレードする セカンダリのアップグレードとそれをプライマリにするフェイルオーバーは、期待どおりに機能しました。しかし、以前のプライマリレプリカをアップグレードした後、その上のデータベースがSSMSで「同期していない/回復中」としてリストされていることに気付きました。また、それらにアクセスしようとすると、エラーメッセージが生成されます。 データベース...にアクセスできません。(ObjectExplorer) 私が見たSQL Serverログを介してチェック データベース '...'バージョン782を開けません。データベースを最新バージョンにアップグレードしてください。 master..sysdatabasesテーブルをクエリすると、テーブルが確かに古いバージョンであり、アップグレード中に更新されていないことがわかりました。 残念ながら、ログには更新されなかった理由が示されておらず、可用性グループダッシュボードには、一部の可用性データベースのデータ同期状態が正常ではなく、理由がないことを示す一般的な警告しかありませんでした。 TSQLを使用してデータベースをデタッチするか、オフラインに設定して更新を「キック」しましたが、それらはSQL AGの一部であるため、これらのコマンドは機能しません。 SQL AGの一部であるデータベースを最新バージョンにアップグレードするにはどうすればよいですか?

2
SELECTでパーティション化された列ストアのデッドロックを防ぐ方法
SQL Server 2016に3つのクラスター化列ストアインデックス(CCI)テーブルがあります。これらのCCIはすべて、テナントIDに基づいて同じパーティションスキームにあります。最近、一貫性のない方法で、結合からこれらのテーブルへの単純な選択ステートメントでデッドロックが発生しています。デッドロックするクエリの例: SELECT TOP 33 r.tenantid FROM Table_r r INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey WHERE r.TenantId = 69 AND pe.TenantId = 69 AND cm.TenantId = 69 エラーメッセージ: トランザクション(プロセスID 56)は、別のプロセスで汎用の待機可能なオブジェクトリソースでデッドロックされ、デッドロックの犠牲者として選択されました。トランザクションを再実行します。 手がかり: クエリがCCI以外の別のインデックスを使用する場合、デッドロックは発生しません。 3つのテナントフィルターのうち2つを削除しても、デッドロックしません。 トップ32以下を選択しても、デッドロックは発生しません。 OPTION(MAXDOP 1)を追加しても、デッドロックは発生しません。 スクランブルされたPRODレプリカ、PROD読み取り専用セカンダリ、およびPROD自体でこれを再現できます。 この動作をDEVまたはINTで再現できません。 3つのテーブル結合すべてにWITH(NOLOCK)を追加すると、依然としてデッドロックが発生します クエリ自体がデッドロックします。他にアクティブなプロセスがない場合はデッドロックします。 並列処理のないクエリプランはデッドロックしない デッドロックxmlはこちら PRODバージョン: …

1
ページ圧縮を使用する場合の行オーバーヘッドは何ですか?
650 Numeric(19,4)列のテーブルを作成しました。実行してページ圧縮をオンにすると ALTER TABLE fct.MyTable REBUILD WITH (DATA_COMPRESSION = PAGE); 私は得る メッセージ1975、レベル16、状態1のインデックス「PK_Mytable」の行の長さが、許容される最大長の「8060」バイトを超えています。 しかし、9バイトの650倍は5850バイトにすぎず、これは指定された制限の8060バイトからはかなりかけ離れています。 サーバーは、SQL Server 2016 SP1 CU2でWindows 2012 r2を実​​行しています ページ圧縮を使用する場合の行オーバーヘッドは何ですか? ここに私が何を意味するかを示すいくつかのコードがあります: /* test script to demo MSG 1975 */ DECLARE @sql NVARCHAR(max)='', @i INT =0 drop table if exists dbo.mytable; SET @sql = 'Create table dbo.Mytable (MyTableID bigint not …

1
欠落している非クラスター化インデックスは既にクラスター化インデックスの一部です
実行速度の遅いクエリをデバッグしています。実行プランでは、非クラスタ化インデックスが推奨され、51.6648の影響があります。ただし、非クラスター化インデックスには、主キー(PK)複合クラスター化インデックスに既に含まれている列のみが含まれます。 これは、インデックス内の列の順序が原因である可能性がありますか?つまり、クラスター化インデックスの列の選択性が最も高いものから低いものへの順序ではない場合、非クラスター化インデックスがパフォーマンスを向上させる可能性はありますか? さらに、非クラスター化インデックスには3つのPK列のうち2つだけが含まれ、3番目の列は包含列として追加されます。あるinclude非クラスタ化インデックスの使用がより最適かもしれないもう一つの理由? 以下は、私が使用しているテーブル構造の例です。 テーブル- Retailers ( RetailerID int PK, name ...) Retailer_Relation_Types ( RelationType smallint PK, Description nvarchar(50) ...) Retailer_Relations ( RetailerID int PK FK, RelatedRetailerID int PK FK, RelationType smallint PK FK, CreatedOn datetime ...) テーブルにRetailer_Relationsは、次の複合PKインデックスと推奨インデックスがあります。 CONSTRAINT PK_Retailer_Relations PRIMARY KEY CLUSTERED ( RetailerID ASC, RelatedRetailerID ASC, RelationType ASC …

1
測定プランの削除
最大メモリが24GBに設定されたSQL Server 2016 SP1があります。 このサーバーには多数のコンパイルがあり、これらのコンパイルの10%のみがアドホッククエリからのものです。したがって、新しくコンパイルされたプランはプランキャッシュに保存されますが、プランキャッシュのサイズは増加していません(約3.72GB)。 キャッシュからのプランの削除につながるローカルメモリのプレッシャーがあると思います。プランのキャッシュ圧力制限は5GBです。(0-4GBの可視ターゲットメモリの75%+ 4GB-64GBの可視ターゲットメモリの10%+可視ターゲットメモリの5%> 64GB)。キャッシュストアが圧力制限の75%に達したら、プランをキャッシュから削除する必要があります。私の場合、5 GBの75%は3.75GBです。したがって、これが高コンパイルの原因であると考えられます。 キャッシュからの計画からの削除を測定する方法(perfmon、拡張イベントなど)はありますか?だから私は確かにローカルメモリのプレッシャーが高コンパイルの原因であることを確信できますか?

1
システムヘルスに「sql_exit_invoked」がある場合、それはどういう意味ですか?
SQL Server 2016 Standardサーバーの1つに問題があります。私は8つの本番サーバーを使用していますが、ログにトレースが記録されずにランダムにクラッシュするのはこのサーバーだけです。 system_healthを有効にしています。「sql_exit_invoked」であるシステムヘルス魔女の行があることに気づきました。 その行の詳細情報を見つけようとしています。どういう意味ですか?インターネットで見つけた唯一の情報は、SQLExit()が呼び出されたときに発生し、SQL 2012以降にのみログに記録されるということです(msdn Webサイトで利用可能なリンク)。 だから私の質問は:これを私のログで見るのを心配するべきですか?これは問題のあるサーバーでのみ見つかり、他の7つのサーバーでは見つかりません。(それらはすべてSQL Server 2016 Standardエディションです) 誰かがこれについてもっと情報をくれますか?

3
有限のコラボレーション距離で行に一意の値を割り当てるためのソリューション
次のコードを作成して入力できるテーブルがあります。 CREATE TABLE dbo.Example(GroupKey int NOT NULL, RecordKey varchar(12) NOT NULL); ALTER TABLE dbo.Example ADD CONSTRAINT iExample PRIMARY KEY CLUSTERED(GroupKey ASC, RecordKey ASC); INSERT INTO dbo.Example(GroupKey, RecordKey) VALUES (1, 'Archimedes'), (1, 'Newton'), (1, 'Euler'), (2, 'Euler'), (2, 'Gauss'), (3, 'Gauss'), (3, 'Poincaré'), (4, 'Ramanujan'), (5, 'Neumann'), (5, 'Grothendieck'), (6, 'Grothendieck'), …

2
msdbでクエリストアを有効にするとどのようなメリットがありますか?
SQLシステムデータベース(master、model、msdb、tempdb)のクエリストアは、msdbでのみ使用できます。msdbのクエリストアに関するドキュメントを探しましたが見つかりませんでした。 GUIには表示されませんが、SQL 2016インスタンスで検証できます クエリストアの検証がオフです USE msdb SELECT * FROM sys.database_query_store_options; クエリストアをオンにする USE [master] GO ALTER DATABASE msdb SET QUERY_STORE = ON GO ALTER DATABASE msdb SET QUERY_STORE (OPERATION_MODE = READ_WRITE , INTERVAL_LENGTH_MINUTES = 30 , MAX_STORAGE_SIZE_MB = 1000 , QUERY_CAPTURE_MODE = AUTO) GO クエリストアの検証がオンになっています USE msdb SELECT * FROM sys.database_query_store_options; …

3
SQL Serverで多対多の結合を示唆する方法は?
1組の列(両方int)で結合する3つの「大きな」テーブルがあります。 Table1には2億行まで Table2には約150万行あります Table3には約600万行あります 各テーブルには、上のクラスタ化インデックスを持っているKey1、Key2して、1つの以上の列。Key1カーディナリティが低く、非常にゆがんでいます。これは常にWHERE句で参照されます。条項でKey2言及されていないWHERE。各結合は多対多です。 問題は、カーディナリティの推定にあります。各結合の出力見積もりは、大きくなるのではなく小さくなります。これにより、実際の結果が数百万に相当する場合、最終的な推定値は数百になります。 CEを手掛かりにしてより良い推定を行う方法はありますか? SELECT 1 FROM Table1 t1 JOIN Table2 t2 ON t1.Key1 = t2.Key1 AND t1.Key2 = t2.Key2 JOIN Table3 t3 ON t1.Key1 = t3.Key1 AND t1.Key2 = t3.Key2 WHERE t1.Key1 = 1; 私が試したソリューション: 上の複数列の統計情報を作成しKey1、Key2 大量のフィルターされた統計を作成するKey1(これはかなり役に立ちますが、ユーザーが作成した何千もの統計がデータベースに残ることになります。) マスクされた実行計画(悪いマスキングのため申し訳ありません) 私が見ている場合、結果には900万行があります。新しいCEは180行を推定します。従来のCEでは6100行と推定されています。 これは再現可能な例です: DROP TABLE IF EXISTS #Table1, #Table2, …

1
Service Broker-会話の有効期間?
ビジネスケースを解決するために、Service Brokerを環境で動作させようとしています。メッセージのタイトルが適切かどうかはわかりませんが、私の質問は以下のとおりです。しかし、それは良い質問ではないかもしれません。そのため、私たちがやっていることと、それが正しい質問だと思う理由がここにあります。 会話を終了する前に、会話でいくつのメッセージを送信する必要がありますか? 結果テーブルを非同期で更新するために、Service Brokerを使用します。結果テーブルは平坦化され、高速です。ベーステーブルに、テーブルと主キーを含むメッセージを送信するトリガーがあります。3つのキューがあります。 低レイテンシ-目標は処理に15秒です。特定のアイテムに関連して変更されるアイテムを処理します。 一括キュー-目標は5分で処理されます。これは、何百(または何千)ものアイテムに影響を与える何かの変更を処理します。影響を受けたアイテムのリストを分割し、それらを遅延低遅延キューにフィードします 遅延低遅延-目標は30分で処理されます。これはアイテムを処理しますが、バルクキューからのみです。 基本的に、クライアントの情報が更新された場合。これは多くの製品に影響を与えるため、処理を遅くするために一括キューに送信されます。ただし、製品が更新されると、それは低遅延キューに送信されます。 Remus Rusanuのブログhttp://rusanu.com/2007/04/25/reusing-conversations/と同様の会話を再利用しますが、主キーの係数に基づいて行う点が異なります。これには、主キーの重複排除を支援するという副次的な利点があります。 そのため、会話を再利用しており、ガイドラインの範囲内です。2つのスレッドで、125メッセージ/秒(数千のメッセージの人為的な低下)を焼き切ることができました。これは、生産(最大15メッセージ/秒)に追いつくのに十分です。 しかし、私たちが経験している問題は、一定の時間が経過すると、4時間または120Kメッセージの後に、sysdesendとキューテーブルでブロックと高い競合が発生し始めることです。ロックはLCK_M_Uであり、KEYロックです。hobtは、sysdesendに解決される場合もあれば、特定のキューテーブル(queue_)に解決される場合もあります。 24時間または30分の非アクティブ状態の後に会話を終了するプロセスが用意されているため、会話が循環するまでの時間を増やすことができます。 SQL 2016 Enterprise(13.0.4001.0)を使用しています トリガーの発火(低遅延または一括送信) 会話ハンドルを検索または作成します。 メッセージを送る キューがアクティブ化された手順 結果テーブルを更新する クリーンアッププロセスは10分ごとに実行され、アイドル状態の会話がないかどうかを確認します。連続して3回以上見つかった場合は、非アクティブとしてマークし、会話を終了します。 有益かもしれない追加の詳細があるかどうか私に知らせてください。Service Brokerの経験があまりないので、メッセージ/秒が低いか、高いか、無関心かはわかりません。 更新 そのため、本日もう一度試しましたが、同じ問題が発生しました。会話の有効期間を2時間に変更しましたが、影響はありませんでした。そこで、150トリックを実装しました。同じ問題がありました。 SEND CONVERSATIONでの大量の待機、sysdesendでの待機。誰か他のアイデアはありますか? アップデート2 今日はさらに長い時間テストを実行し、17分のサンプル期間の1つで、4つの会話ハンドルで41Kのメッセージを処理しました。sysdesendとキューテーブルのロックが大きくなりすぎて停止する前にドリフトし始めたときを除いて、最後まで追いつくことができました。メッセージの処理には問題がないようですが、キューに入らない限り、メッセージを取り出して、少なくともその5倍の速度で処理できます。メッセージの追加に基づいて速度が制限されているようです。 後のテストで、メッセージの80%を占めるトリガーの1つを削除しました。このように負荷が大幅に軽減された場合でも、同じ待機が発生し始めました。 アップデート3 Remusからアドバイスをいただきありがとうございます(この件に関して優れたブログ記事を投稿していただき、ありがとうございました。この点に到達するために役立ちました)。 私たちは今日それをもう一度実行し、より良い結果を出しました(待機を見る前にさらに長くなり、それが私たちを不自由にする前にさらに長くなりました)。だから、詳細。 変更:*スレッドごとに維持される会話の数を1:1から2:1に増やしました。基本的に、4つのスレッドに対して8つの会話ハンドルがありました。 バルクキューを統合し(1つの受信メッセージが数百の送信メッセージを意味する可能性があるため)、少数の大きなメッセージに統合しました。 この試みに関するメモ: ターゲットキューのアクティブ化手順を無効にします。ブロッキングに変更はなく(5分間待機)、メッセージはsys.transmission_queuesに送信されました。 sys.conversation_endpointsのモニタリング。この数は0から13,000まで急速に増加し、その後、1日を通してゆっくりと増加し、約5時間後には約25Kに達しました。ブロックは、16K +/-に達するまで発生しませんでした 私はDACに入り、キューに対してDBREINDEXコマンドを実行しましたが、クエリから、ゴーストレコードが200を超えることはなく、クリーンアップが行われてカウントが0になりました。 テストを終了したとき、sysdesendとsysdercvのカウントは24,932でした。 5時間で〜310Kのメッセージを処理しました。 物事がバラバラになるずっと前に行ったので、今度はそれを作ると本当に思った。明日は、メッセージを強制的に送信してみます。



1
リンクされたSQL Serverにはどのような大きな制限が予想されますか?
当社の製品は、Microsoft SQL Serverに基づいています。現在、3つのデータベースを使用しており、常に1つのSQL Serverインスタンスに展開しています。 3つのデータベースは、OLTP、OLAP、および監査です。OLAPデータベースには、クロスデータベースクエリを使用して、OLTPと監査の両方からのEODに関する大規模な受信データがあります。 ご質問 これらの3つのデータベースを単一の物理サーバー内の3つの別々のStandard Edition インスタンスに展開し、SQL Serverのリンクサーバー機能を使用してそれらをバインドするとします。 アプリケーションコードに対してどの程度透過的ですか?どのくらいの変化を期待できますか? OLAPへのインバウンドデータの量は5万〜10万行で、EODあたりのペイロードは200〜500 MBでした。どのくらいのパフォーマンス低下が予想されますか? 他にどんな大きな制限を期待する必要がありますか? バックグラウンド 現在、最初の潜在的なクライアントを500人以上の同時ユーザーに売り込んでいます。 64コアと256GB RAMを含むサーバー仕様を作成しています。SQL Serverがこれらの豊富なリソースをすべて利用するには、クライアントはEnterprise Editionを購入する必要があります。EnterpriseEditionは、SQL Server 2016ではコア単位のライセンスでのみ利用できます。 ライセンス費用だけ(64 x $ 7400)でそれらが下がることを恐れています。したがって、データベースをStandard Editionの3つのインスタンスに分割し、それらをリンクして、リンク機能がアプリケーションコードから透過的になることを期待しています。

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