データベース管理者

データベースのスキルを向上させ、コミュニティの他の人から学びたいデータベースの専門家向けのQ&A

2
SMO、SSMSは、ローカルホストに接続するときにDockerでのSQL Serverの管理に時間がかかる
TL; DR: IPv6ループバック(::1)に解決される名前でSQL Server Dockerコンテナーに接続すると、SMO呼び出しが非常に遅くなります。を使用すると127.0.0.1、高速になります。 Dockerイメージmicrosoft / mssql-server-windows-developerの使用方法を学習しようとしています。Microsoftのドキュメントによると、このコンテナはポート1433 TCPのみを公開しています。 docker run -d -p 1433:1433 -e sa_password=Passw0rd! -e ACCEPT_EULA=Y -v C:\dockerdb:C:\dockerdb microsoft/mssql-server-windows-developer 私はWindows 10でコンテナーを実行していますが、コンテナーの起動、SQL Server認証による認証、WindowsホストでのsqlcmdおよびSSMS 17.4を使用したインスタンスに対するクエリの実行(localhostまたは「。」に接続)、およびSQL操作に成功しています。 IPで接続する隣のMacのスタジオ。この方法でクエリを実行しても、目立ったパフォーマンスの問題はありません。 SSMSでは、オブジェクトエクスプローラーを参照することもできますが、インスタンスエクスプローラーウィンドウを開いたり、データベースを接続したりするなど、オブジェクトエクスプローラーのオブジェクトで右クリックメニューから何かを行おうとすると、SSMSは約5秒間応答を表示しません-10分。この時点で、要求したウィンドウが表示されるか、次のエラーメッセージが表示されます。 また、SMO Scripterオブジェクトを使用して、このインスタンスに対してPowerShellスクリプトを実行して、同じような動作を確認しようとしています。PSスクリプトは、データベース内のオブジェクトをループしてスクリプトでファイルに保存し、オブジェクトのリストを比較的迅速に収集するように機能しますが、個々のオブジェクトのスクリプト作成には5〜10分かかり、使用するには遅すぎます。 公開された単一のポートでは不十分であり、SMOとSSMSが同様の方法で接続を試みて速度が低下しているのではないかと思います。また、localhostに接続するときに、これらのツールは、通常はファイアウォールで保護されない他の通信チャネルが存在すると想定しているのでしょうか。使用できる追加の接続パラメーターはありますか?SSMSがSMOなどを使用してSQL Serverと通信しているという私の仮定を誰かが検証できますか? 更新:まだ調査中ですが、これはリソースの制約に関するDockerの問題であると考えられます。ほとんどのドキュメントでは、Windowsコンテナにデフォルトのリソース制約がないことを示しているようです(そして、これらはDocker for Windows GUIでは設定できません。Linuxコンテナの場合のみです)が、実際にはWindows Windows 10で実行されているコンテナーは、1 GBのデフォルトのRAM割り当てを取得します。実行中のコンテナーを検査してそのRAMとCPUの割り当てを確認する方法をまだ考えていますが、次にdocker runパラメーターを使用して、デフォルトの値からそれらを増やしてみます。 更なる更新:Dockerから、コンテナに設定されているCPUとメモリの制限を教えてくれる信頼できるメトリックを取得できませんでした。さまざまな調査により、Dockerコンテナーにはデフォルトでメモリ制限がないか、1 GBであることが示されていますが、現時点で確認できるのdocker statsは、SQLコンテナーが750〜850 MBのメモリしか使用していないということです。使用可能なメモリを4 GBに設定する実行パラメータを追加しようとすると、エラーになります。だから私はその問い合わせのスレッドに従うのをやめ、別の腸のチェックに行きました:実行中のコンテナーでインタラクティブなPowerShellセッションを入力してから、コンテナー内から上記のリンクされた私のPowerShellスクリプトを呼び出します。 コンテナー内で実行しても問題はありませんでした。ほんの数分で2780個のオブジェクトを突破しました。これは問題がコンテナー/ホスト境界にあることを確認していると思います。そのため、そのUDPポートを開くことができるかどうかを確認します。更新: UDPポート1434を開いても解決しませんでした。 その他のアップデート—回避策は達成されましたが、リソース制約の問題ではありません。Windowsコンテナに大きなメモリ割り当てを設定することに関連する問題があるようです— 3gと2gでも同様のエラーが発生しましたが、最終的に1.5gでコンテナを起動できました。docker statsコンテナーのの違いを確認しましたが、コンテナーがデフォルトの割り当てである1GBで実行されていることを確認しました(そう思います)。デフォルトの設定では、PRIV WORKING …

1
マスター/詳細テーブル間のハッシュ結合により、カーディナリティの見積もりが低すぎる
マスターテーブルを詳細テーブルに結合するときに、SQL Server 2014が大きい(詳細)テーブルの基数推定を結合出力の基数推定として使用するようにするにはどうすればよいですか? たとえば、10Kのマスター行を100Kの詳細行に結合する場合、SQL Serverで結合を100K行で推定します-詳細行の推定数と同じです。すべての詳細行に常に対応するマスター行があるという事実をSQL Serverの推定器が活用できるようにするには、クエリやテーブル、インデックス、あるいはその両方をどのように構成すればよいですか?(それらの間の結合は、カーディナリティの推定値を決して減らすべきではないという意味です。) 詳細はこちらです。このデータベースには、マスター/詳細のテーブルのペアがありVisitTargetます。販売トランザクションごとに1つの行があり、トランザクションVisitSaleごとに製品ごとに1つの行があります。これは1対多の関係です。VisitTargetの行が1つで、平均で10件のVisitSale行があります。 テーブルは次のようになります(この質問に関連する列のみを簡略化しています)。 -- "master" table CREATE TABLE VisitTarget ( VisitTargetId int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED, SaleDate date NOT NULL, StoreId int NOT NULL -- other columns omitted for clarity ); -- covering index for date-scoped queries CREATE NONCLUSTERED INDEX IX_VisitTarget_SaleDate ON VisitTarget …

1
夏時間
私の環境では、ネイティブバックアップで実行されているサーバーとOla Hallengren計画があります。当社のサーバーは、2008、2012、2014の組み合わせです。すべての完全バックアップは午前12時に行われ、ログバックアップは15分ごとに行われます。 これまでに夏時間を考慮したことがないので、どのような調整を行うべきか教えてください。 午前12時のフルバックアップは影響を受け、ログバックアップはどうなりますか?

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, …

2
クエリのパフォーマンスチューニング
このクエリのパフォーマンスを改善するための支援を求めています。 SQL Server 2008 R2 Enterprise、最大RAM 16 GB、CPU 40、最大並列度4。 SELECT DsJobStat.JobName AS JobName , AJF.ApplGroup AS GroupName , DsJobStat.JobStatus AS JobStatus , AVG(CAST(DsJobStat.ElapsedSec AS FLOAT)) AS ElapsedSecAVG , AVG(CAST(DsJobStat.CpuMSec AS FLOAT)) AS CpuMSecAVG FROM DsJobStat, AJF WHERE DsJobStat.NumericOrderNo=AJF.OrderNo AND DsJobStat.Odate=AJF.Odate AND DsJobStat.JobName NOT IN( SELECT [DsAvg].JobName FROM [DsAvg] ) GROUP …

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のメッセージを処理しました。 物事がバラバラになるずっと前に行ったので、今度はそれを作ると本当に思った。明日は、メッセージを強制的に送信してみます。

2
SSRSは間もなく消滅し、PowerBIは新しいモデルになりますか?
SQL Server 2017にPowerBI Serverが含まれるようになったことを確認しました。また、SSRSを別のインストーラーに移動したため、元のSQL Serverインストールにパッケージ化されていません。これは、Microsoftが最終的にSSRSを廃止しようとすることを意味しますか?私たちのチームは、PowerBIで新しいレポートを作成し、以前のSSRSレポートを移行する必要がありますか?

3
SQLテーブルから数百万行を削除する
2億2000万以上の行テーブルから1600万以上のレコードを削除する必要がありますが、非常に遅いです。 以下のコードをより速くするための提案を共有していただければ幸いです。 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; DECLARE @BATCHSIZE INT, @ITERATION INT, @TOTALROWS INT, @MSG VARCHAR(500); SET DEADLOCK_PRIORITY LOW; SET @BATCHSIZE = 4500; SET @ITERATION = 0; SET @TOTALROWS = 0; BEGIN TRY BEGIN TRANSACTION; WHILE @BATCHSIZE > 0 BEGIN DELETE TOP (@BATCHSIZE) FROM MySourceTable OUTPUT DELETED.* INTO MyBackupTable …



1
sp_cursorprepexecが5300万の読み取りを引き起こしていますか?
SQL Server 2012でDynamics AX 2012のインストールを実行しています。カーソルはもう使用されないはずですが、AXはそれを使用しており、この動作を変更できないため、操作する必要があります。 今日、5300万を超える読み取りと20分を超える実行時間を伴う非常に悪いクエリを見つけました。 私は監視ツールのSentryOneを介してこのクエリを見つけました。 declare @p1 int set @p1=1073773227 declare @p2 int set @p2=180158805 declare @p5 int set @p5=16 declare @p6 int set @p6=1 declare @p7 int set @p7=2 exec sp_cursorprepexec @p1 output,@p2 output,N'@P1 bigint,@P2 nvarchar(5),@P3 bigint,@P4 nvarchar(8),@P5 bigint,@P6 bigint,@P7 bigint,@P8 bigint,@P9 bigint,@P10 bigint,@P11 bigint,@P12 bigint,@P13 bigint,@P14 …

1
PostgresでのWALセグメントのゼロ化
比較的少量のPostgresデータベースがあり、各WALセグメントを圧縮してS3に送信するために継続的なアーカイブがセットアップされています。これはボリュームの少ないシステムであるarchive_timeoutため、10分ごとにヒットし、ほとんど使用されていないWALセグメントをアーカイブします。これは、ほとんどがゼロであったため、非常によく圧縮されていました。 ただし、PostgresはWALセグメントをリサイクルして、各WALスイッチで新しいファイルを割り当てるコストを回避します。これは、高負荷の状況で役立ちますが、通常よりも重いアクティビティのバーストの後、WALセグメントファイルがいっぱいになることを意味します以前のセグメントからのジャンクであり、まったくうまく圧縮されません。私たちはこのジャンクのすべてのコピーをたくさん保存しています。 WALアーカイブを保持するために使用しているスペースの量を減らす方法はありますか?いくつかの次善の可能性: Postgresが何らかの方法でWALセグメントをリサイクルしないようにして、毎回ゼロのファイルから開始します。ドキュメントはこれを行うためのオプションがあることを示していませんが、私はそれを逃したかもしれません。 Postgresが使用を開始/終了するときに、WALセグメントファイルをゼロにするようにします。再び、ドキュメントはこれが可能であることを示唆していないようです。 一部のWALセグメントファイルを使用していない間に外部的にゼロにするか削除します。これがどのファイルかを判別する安全な方法はありますか? からの出力を使用してセグメントをアーカイブする前に、セグメントの未使用部分をゼロにしてpg_xlogdump、ジャンクの開始位置を見つけます。可能ですが、好きではありません。少なくとも、archiveコマンドでこれを行うことにより、Postgresがファイルを再利用しないことを確認できます。 セグメントファイルの使用された部分のみをアーカイブします。これも、pg_xlogdump何らかの方法で出力を解釈し、復元中にゼロで埋めます。あまり好きではありませんが、可能だと思います。

1
パーティションビューで削除を実行すると、クラスター化インデックスが挿入されるのはなぜですか?
以下の挿入トリガーがあるパーティションビューがあります(貧弱なパーティション)。DELETEを実行すると、以下のクエリプランが表示されます。 delete from factproductprice where pricedate = '20170725' ビューのトリガー: ALTER TRIGGER [dbo].[factProductPriceDelete] ON [dbo].[FactProductPrice] INSTEAD OF DELETE AS BEGIN IF @@ROWCOUNT = 0 RETURN; DECLARE @PriceDate DATE SELECT @PriceDate = CAST(PriceDate AS DATE) FROM DELETED IF @PriceDate BETWEEN '20140101' AND '20141231' BEGIN DELETE FROM dbo.FactProductPrice2014 WHERE ProductId IN (SELECT ProductId …

3
主キーの自己結合
N自己結合で構成されるこのクエリについて考えてみます。 select t1.* from [Table] as t1 join [Table] as t2 on t1.Id = t2.Id -- ... join [Table] as tN on t1.Id = tN.Id N個のクラスター化インデックススキャンとN-1個のマージ結合を含む実行プランを作成します。 正直なところ、すべての結合を最適化せずに1つのクラスター化インデックススキャンだけを行う理由はありません。つまり、元のクエリを次のように最適化します。 select t1.* from [Table] as t1 ご質問 結合が最適化されないのはなぜですか? すべての結合が結果セットを変更しないと言うのは数学的に正しくありませんか? テスト済み: ソースサーバーのバージョン:SQL Server 2014(12.0.4213) ソースデータベースエンジンエディション:Microsoft SQL Server Standard Edition ソースデータベースエンジンの種類:スタンドアロンSQLサーバー 互換性レベル:SQL Server 2008(100) クエリは意味がありません。それはちょうど私の頭に浮かんできました、そして私はそれについて今興味があります。 …

2
MySQLはポイントデータ型をLAT LNGまたはLNG LATとして格納しますか?
位置形式を緯度に続いて経度として表示することに慣れていますが、ライブラリを使用すると、MySQLがそれをPOINT(LNG LAT)と逆の順序で格納することを理解していると思います。私のライブラリは間違っていますか、それともこれが実際の形式ですか?MySQLのドキュメントでこの詳細を見つけることができないようです。
9 mysql  spatial 

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