データベース管理者

最近、5億行に近いテーブルにNULL可能ビット列を追加しました。列にはデフォルトはありませんが、すべての挿入で0または1の値が指定されています。1回限りのルーチンを実行して、既存のすべての行に0または1を割り当てます（小さなバッチで行を更新します）。これで、すべての行の列に0または1が表示されます。 ビット列をnull不可にしたいのですがALTER TABLE t1 ALTER COLUMN c1 bit not null、で実行しようとしたときに3分実行され、テーブルへのすべての読み取りをブロックしていたため停止しましたが、完了するまでに時間がかかると思われました。それほど時間がかからない可能性はありますが、利用できないリスクを冒すことはできません。ロールバック自体は6分かかりました。 完了するまでに何時間もかかることなく、列をnull不可にする方法について提案はありますか？ さらに、ALTER TABLE ALTER COLUMN開始してからキャンセルしたステートメントが完了するまでにかかる時間を見積もる方法はありますか？ SQL Server 2017 Web Editionを使用しています。

12 sql-server  sql-server-2017  alter-table  null 

いくつかのNVARCHAR(4000)列でこのテーブルを処理する非常に大きなメモリ許可でパフォーマンスの問題があります。これらの列はより大きいことはありませんNVARCHAR(260)。 を使用して ALTER TABLE [table] ALTER COLUMN [col] NVARCHAR(260) NULL SQL Serverはテーブル全体を書き換えます（ログスペースで2倍のテーブルサイズを使用します）。これは何十億行で、何も変更しないだけで、オプションではありません。列の幅を大きくしてもこの問題はありませんが、小さくすると問題が発生します。 制約を作成しようとしたCHECK (DATALENGTH([col]) <= 520)かCHECK (LEN([col]) <= 260)、SQL Serverがテーブル全体を書き直すことにしました。 列のデータ型をメタデータのみの操作として変更する方法はありますか？テーブル全体を書き換える費用なしで？SQL Server 2017（14.0.2027.2および14.0.3192.2）を使用しています。 以下は、再現に使用するサンプルDDLテーブルです。 CREATE TABLE [table]( id INT IDENTITY(1,1) NOT NULL, [col] NVARCHAR(4000) NULL, CONSTRAINT [PK_test] PRIMARY KEY CLUSTERED (id ASC) ); そして、を実行しALTERます。

12 sql-server  sql-server-2017  alter-table 

<inputbuf>デッドロック拡張イベントセッションによってキャプチャされたデッドロックXMLの要素のサイズを増やす方法はありますか？ アプリケーションコードで問題を特定するのに役立つ完全なクエリが必要です。 1024文字+/-に制限されているようです。増やすことはできますか？ サンプルXMLについては、以下を参照してください。<inputbuf>要素のクエリテキストが選択リストの中央で途切れていることがわかります。 <deadlock> <victim-list> <victimProcess id="processc9c0829848" /> </victim-list> <process-list> <process id="processc9c0829848" taskpriority="0" logused="0" waitresource="PAGE: 5:1:40600276 " waittime="696" ownerId="255115931225" transactionname="SELECT" lasttranstarted="2019-04-24T09:29:25.950" XDES="0xc8dfa8da40" lockMode="S" schedulerid="13" kpid="8480" status="suspended" spid="245" sbid="2" ecid="0" priority="0" trancount="0" lastbatchstarted="2019-04-24T09:29:25.950" lastbatchcompleted="2019-04-24T09:29:25.950" lastattention="1900-01-01T00:00:00.950" clientapp="EntityFramework" hostname="MSR-PRD-BDB02" hostpid="43440" loginname="IUSR_BuildDB" isolationlevel="read committed (2)" xactid="255115931225" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"> <executionStack> <frame procname="adhoc" …

12 sql-server  sql-server-2016  deadlock  extended-events 

データベースSQL Server 2017 Enterprise CU16 14.0.3076.1 最近、デフォルトのIndex RebuildメンテナンスジョブからOla Hallengrenへの切り替えを試みましたIndexOptimize。デフォルトのインデックス再構築ジョブは問題なく数か月間実行されており、クエリと更新は許容可能な実行時間で機能していました。IndexOptimizeデータベースで実行した後： EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 5, @FragmentationLevel2 = 30, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y' パフォーマンスが極端に低下しました。IndexOptimize100ミリ秒かかった更新ステートメントは、その後78.000ミリ秒かかり（同じプランを使用）、クエリのパフォーマンスも数桁悪化していました。 これはまだテストデータベースであるため（Oracleから運用システムを移行しています）、バックアップにIndexOptimize戻り、無効にしてすべてを通常に戻しました。 ただし、この極端なパフォーマンスの低下を引き起こす可能性のIndexOptimizeある「通常」Index Rebuildとは何が異なるのかを理解して、本番環境に移行したときにそれを回避できるようにします。何を探すべきかについての提案は大歓迎です。 遅い場合の更新ステートメントの実行計画。すなわち、 IndexOptimizeの実際の実行計画の後 （できるだけ早く） 違いを見つけることができませんでした。 高速な場合は同じクエリを計画する 実際の実行計画

12 sql-server  sql-server-2017  ola-hallengren  index-maintenance 

アプリケーションのスローダウンを診断しようとしています。このために、SQL Server 拡張イベントを記録しました。 この質問では、1つの特定のストアドプロシージャを見ています。 しかし、リンゴからリンゴへの調査として同様に使用できる12個のストアドプロシージャのコアセットがあります。 ストアドプロシージャの1つを手動で実行すると、常に高速に実行されます また、ユーザーが再試行した場合、高速で実行されます。 ストアドプロシージャの実行時間は大きく異なります。このストアドプロシージャの実行の多くは1秒未満で返されます。 そして、その「高速」バケットについては、1秒よりはるかに少ないです。実際には約90ミリ秒です。 しかし、2秒、3秒、4秒待たなければならない長いユーザーがいます。12、13、14秒待たなければならない人もいます。それから、22、23、24秒待たなければならない本当に貧しい魂がいます。 そして、30秒後、クライアントアプリケーションはあきらめ、クエリを中止し、ユーザーは30秒待つ必要がありました。 原因を見つけるための相関 だから私は相関させようとしました： 期間と論理読み取り 継続時間と物理読み取り 期間とCPU時間 また、相関関係を与えるものはありません。原因はないようです 継続時間と論理読み取り：少しでも多くの論理読み取りでも、継続時間は大きく変動します： 期間対物理読み取り：クエリがキャッシュから提供されず、多くの物理読み取りが必要な場合でも、期間には影響しません。 duration vs cpu time：クエリが0秒のCPU時間を使用した場合でも、2.5秒のCPU時間を使用した場合でも、期間の変動は同じです。 ボーナス：Duration v Physical ReadsとDuration v CPU timeが非常に似ていることに気付きました。これは、CPU時間を物理読み取りと相関させようとすると証明されます。 多くのCPU使用率がI / Oに由来することが判明しました。誰かわかったね！ それで、実行時間の違いを説明できるクエリを実行する行為について何もなければ、それはそれがCPUまたはハードドライブとは無関係な何かであることを意味しますか？ CPUまたはハードドライブがボトルネックだった場合。それがボトルネックではないでしょうか？ ボトルネックはCPUであると仮定した場合、このサーバーのCPUの電力が不足していること： その後、より多くのCPU時間を使用した実行に時間がかかりませんか？ 過負荷のCPUを使用して他の人と完了する必要がありますか？ ハードドライブについても同様です。ハードドライブがボトルネックであると仮定した場合、ハードドライブがこのサーバーに十分なランダムスループットを持たないこと： その後、より多くの物理読み取りを使用した実行には時間がかかりませんか？ 過負荷のハードドライブI / Oを使用して他の人と完了する必要があるためですか？ ストアドプロシージャ自体は、書き込みも実行も要求もしません。 通常、0行（90％）を返します。 時折、1行（7％）を返します。 まれに2行（1.4％）が返されます。 そして最悪の場合、2行以上を返しました（一度に12行を返しました） したがって、異常な量のデータを返しているわけではありません。 サーバーのCPU使用率 …

12 sql-server  sql-server-2012 

このクエリをご覧ください。それは非常に簡単です（テーブルとインデックスの定義、および再現スクリプトについては投稿の最後をご覧ください）： SELECT MAX(Revision) FROM dbo.TheOneders WHERE Id = 1 AND 1 = (SELECT 1); 注：「AND 1 =（SELECT 1）は、このクエリが自動パラメータ化されないようにするためのものです。これは問題を混乱させているように感じました。 そして、これがプランです（プランのリンクを貼り付けてください）： そこには「トップ1」があるので、ストリーム集約演算子を見て驚いた。1行のみであることが保証されているので、私には必要ないようです。 その理論をテストするために、この論理的に同等のクエリを試しました。 SELECT MAX(Revision) FROM dbo.TheOneders WHERE Id = 1 GROUP BY Id; これがその計画です（計画のリンクを貼り付けてください）： 案の定、group by planは、ストリーム集約演算子なしで対応できます。 両方のクエリがインデックスの最後から「後方」を読み取り、「トップ1」を実行して最大リビジョンを取得することに注意してください。 ここで何が欠けていますか？ ストリーム集合体は最初のクエリで実際に動作するのですか、それとも排除する必要がありますか（それはオプティマイザーの制限であり、そうではありません）？ ちなみに、これは信じられないほど実用的な問題ではないことを認識しています（クエリは両方ともCPUの0ミリ秒と経過時間を報告します）。 上記の2つのクエリを実行する前に実行したセットアップコードを次に示します。 DROP TABLE IF EXISTS dbo.TheOneders; GO CREATE TABLE dbo.TheOneders …

12 sql-server  group-by  aggregate  sql-server-2017  database-internals 

短い質問がありますが、なぜuse master;データベースの作成に使用するのですか？ここでの例は、Microsoftのドキュメントからは、 USE master ; GO CREATE DATABASE Sales ON ( NAME = Sales_dat, FILENAME = 'C:\Program Files\...\saledat.mdf', SIZE = 10, MAXSIZE = 50, FILEGROWTH = 5 ) LOG ON ( NAME = Sales_log, FILENAME = 'C:\Program Files\...\salelog.ldf', SIZE = 5MB, MAXSIZE = 25MB, FILEGROWTH = 5MB ) ;

12 sql-server  t-sql  ddl  master-system-database 

コンピューターにSQL Server 2017がインストールされています。これは何をSELECT @@VERSION返します： Microsoft SQL Server 2017（RTM-GDR）（KB4293803）-14.0.2002.14（X64）2018年7月21日07:47:45 Copyright（C）2017 Microsoft Corporation Enterprise Edition（64-bit）on Windows 10 Enterprise 10.0（Build 17134： ） ` 昨日まで問題なく動作していました。突然SQL SERVER Service実行されませんでした。私が手動でサービスを実行したいとき、それは示した3417 error。イベントログを確認すると、次のエラーが表示されました。 アップグレードステップ 'msdb110_upgrade.sql'でエラー200、状態7、重大度25が発生したため、データベース 'master'のスクリプトレベルのアップグレードに失敗しました。これは、通常の操作を妨げる重大なエラー状態であり、データベースがオフラインになります。'master'データベースのアップグレード中にエラーが発生した場合、SQL Serverインスタンス全体が起動しなくなります。以前のエラーログエントリのエラーを調べ、適切な修正アクションを実行し、データベースを再起動して、スクリプトのアップグレード手順が完了するまで実行します。 いくつかのグーグル検索の後、私はそれを実行し/T902 switchて問題を解決しようとすることがわかりました。しかし、解決策はありませんでした。そこで、同じSQL SERVER 2017データベースの別のインスタンスをインストールし、データベースを復元しました。これで、新しくインストールされたインスタンスにも同じ問題が発生します。 何が問題なのでしょうか？ 更新 ここに、SQL Serverの完全なエラーログがあります。 2018-09-17 13：06：47.29 spid6s構成オプション「詳細オプションの表示」が1から1に変更されました。RECONFIGUREステートメントを実行してインストールします。 2018-09-17 13：06：47.29 spid6s構成オプション「詳細オプションの表示」が1から1に変更されました。RECONFIGUREステートメントを実行してインストールします。 2018-09-17 13：06：47.29 spid6s構成オプション 'Agent XPs'が1から1に変更されました。RECONFIGUREステートメントを実行してインストールします。 2018-09-17 13：06：47.29 spid6s構成オプション …

12 sql-server  sql-server-2017  character-set  encoding 

データベースに対するすべての実行アクションを監査するデータベース監査仕様を持つSQL Serverデータベースがあります。 CREATE DATABASE AUDIT SPECIFICATION [dbAudit] FOR SERVER AUDIT [servAudit] ADD (EXECUTE ON DATABASE::[DatabaseName] BY [public]) 一部のクエリは、結果セットのすべての行に対してスカラー関数の使用を監査ログに書き込むことがわかっています。これが発生すると、ログがETLで最終的な休憩場所に達する前にログがいっぱいになり、ログにギャップが生じます。 残念ながら、コンプライアンス上の理由により、すべてのEXECUTEステートメントの監査を停止することはできません。 この問題へのアプローチについて最初に考えたのはWHERE、サーバー監査の句を使用してアクティビティを除外することです。コードは次のようになりました。 WHERE [object_id] not in (Select object_id from sys.objects where type = 'FN' ) 残念ながら、SQL ServerはリレーショナルIN演算子を許可しません（おそらく、監査ログに書き込む必要があるたびにクエリを実行したくないためです）。 私たちは、どのハードコードストアドプロシージャ書き込みを避けたいobject_idにWHERE句が、それは、この問題にアプローチする最良の方法で私たちの現在の考え方です。考慮すべき代替アプローチはありますか？ 再帰CTEでスカラー関数が使用されている場合、結果セット内のすべての行の監査ログにクエリが書き込まれることに気付きました。 ベンダーが提供するいくつかのスカラー値関数がありますが、それらを削除したり、代替データベースに移動したりすることはできません。

12 sql-server  functions  audit  cte  recursive 

私のアプリケーションには、「ファイル」テーブルで検索を実行するクエリがあります。 テーブル "files"は、 "f"。 "created"でパーティション分割されています（テーブル定義を参照してください。クライアント19には〜26,000,000行あります（ "f"。 "cid = 19）。 ここでのポイントは、このクエリを実行する場合です。 SELECT "f"."id" AS "FileId" , "f"."name" AS "FileName" , "f"."year" AS "Fileyear" , "f"."cid" AS "clientId" , "f"."created" AS "FileDate" , CASE WHEN ("vnVE0"."value" is not null AND "vnVE0"."value" != '') THEN CAST("vnVE0"."value" AS decimal(28,2)) ELSE 0 END AS "keywordValueCol0_numeric" …

12 query-performance  azure-sql-database 

可能な限り均等に、一定数のトラックに注文を積むという観点から問題を説明します。 入力： @TruckCount - the number of empty trucks to fill セット： OrderId, OrderDetailId, OrderDetailSize, TruckId (initially null) Ordersは1つ以上で構成されますOrderDetails。 ここでの課題は、TruckId各レコードにを割り当てることです。 1つの注文を複数のトラックに分割することはできません。 トラックは、で測定し、可能な限り均等に*積む必要がありますsum(OrderDetailSize)。 *均等：最小積載量のトラックと最大積載量のトラック間の達成可能な最小のデルタ。この定義により、1,2,3は1,1,4よりも均等に分散されます。役立つ場合は、統計アルゴリズムになり、高さのヒストグラムも作成します。 トラックの最大積載量は考慮されていません。これらは魔法の弾力性のあるトラックです。ただし、トラックの数は固定されています。 明らかに反復的な解決策があります-ラウンドロビンは注文を割り当てます。 しかし、それはセットベースのロジックとして実行できますか？ 私の主な関心は、SQL Server 2014以降です。しかし、他のプラットフォーム用のセットベースのソリューションも興味深いかもしれません。 これは、Itzik Ben-Ganの領土のように感じます:) 私の実際のアプリケーションでは、処理ワークロードを論理CPUの数に合わせて多数のバケットに分散しています。したがって、各バケットには最大サイズはありません。特に統計の更新。チャレンジを組み立てる方法として、問題をトラックに抽象化する方が楽しいと思いました。 CREATE TABLE #OrderDetail ( OrderId int NOT NULL, OrderDetailId int NOT NULL PRIMARY KEY, OrderDetailSize tinyint NOT NULL, …

12 sql-server  sql-server-2014  query 

クエリに特定のプランを使用するようにSQL Serverをだます方法があるかどうかを確認しようとしています。 1.環境 異なるプロセス間で共有されるデータがあるとします。したがって、多くのスペースをとるいくつかの実験結果があるとします。その後、各プロセスについて、使用する実験結果の年/月を特定します。 if object_id('dbo.SharedData') is not null drop table SharedData create table dbo.SharedData ( experiment_year int, experiment_month int, rn int, calculated_number int, primary key (experiment_year, experiment_month, rn) ) go これで、すべてのプロセスについて、テーブルにパラメーターが保存されました if object_id('dbo.Params') is not null drop table dbo.Params create table dbo.Params ( session_id int, experiment_year int, experiment_month int, …

12 sql-server  query-performance  sql-server-2016  functions 

Dynamics AXには、メモリにロードしてキャッシュするようにテーブルを構成できるキャッシュメカニズムがあります。このキャッシュは、メモリの問題を防ぐために一定のKBに制限されています。私が話している設定は呼び出さentiretablecacheれ、単一のレコードが要求されるとすぐにテーブル全体をメモリにロードします。 最近まで、いくつかのスクリプトに依存して、この設定を持つテーブルのサイズを検証し、テーブルサイズがこの制限を超えているかどうかを確認していました。 しかし、今では圧縮が作用し始めており、sp_spaceusedやsys.allocation_unitsのようなものが、圧縮されたデータによって実際に使用されているスペースを報告しているようです。 明らかに、アプリケーションサーバーは圧縮されていないデータを処理しているため、SQL Serverのディスク上のデータサイズは無関係です。非圧縮データの実際のサイズが必要です。 私はsp_estimate_data_compression_savingsを知っていますが、名前が示すように、これは単なる見積もりです。 サイズをできるだけ正確にしたいと思います。 私が考えることができる唯一の方法は、圧縮テーブルと同じ構造の非圧縮テーブルを作成し、そのシャドウテーブルに圧縮データを挿入し、そのシャドウテーブルのサイズを確認する、複雑な動的SQLでした。 言うまでもなく、これは少し面倒で、数百GBのデータベースで実行するには時間がかかります。 Powershellはオプションの可能性がありますが、すべてのテーブルを反復処理しselect *てスクリプトでサイズを確認するのは好ましくありません。 要するに、可能であれば、アプリケーションに提示された方程式から断片化された状態で圧縮されないため、各テーブルのサイズを取得する方法が必要です。私はさまざまなアプローチを受け入れています。T-SQLをお勧めしますが、Powershellや他の創造的なアプローチには反対しません。 アプリケーションのバッファがデータのサイズであると仮定します。bigintは常にbigintのサイズであり、文字データ型は1文字あたり2バイト（ユニコード）です。BLOBデータはデータのサイズも取ります。enumは基本的にintであり、数値データはnumeric（38,12）、datetimeはdatetimeのサイズです。また、NULL値はありません1900-01-01。空の文字列として保存されるか、ゼロになります。 これがどのように実装されているかについてのドキュメントはありませんが、前提はPFEおよびサポートチームが使用するいくつかのテストとスクリプトに基づいています（また、チェックはアプリケーションに組み込まれ、アプリは認識できないため、明らかに圧縮を無視します）基になるデータが圧縮されている場合）、テーブルサイズもチェックします。例のこのリンクは述べています： 大きなテーブルにはEntireTableキャッシュを使用しないでください（AX 2009では128 KBまたは16ページ以上、AX 2012では「テーブルキャッシュサイズ全体」アプリケーション設定[デフォルト：32KB、または4ページ]）–代わりにレコードキャッシュに移動します。

12 sql-server  cache  compression  size 

SQL Serverは、ストアドプロシージャ内で作成された一時テーブルをキャッシュし、プロシージャが終了してその後実行されるときにそれらの名前を変更するだけです。私の質問は、tempdbスペースがいつ解放されるかに関するものです。手順の最後でテーブルが切り捨てられることを読みました。これはセッションごとに処理されることをコメントで読んでおり、クリーンアップが必要かどうかについての質問がMSDNで回答されています。しかし、同じセッションで2回実行されない場合はどうでしょうか？ また、テーブルが範囲外になるとその領域を解放するバックグラウンドガベージコレクションプロセスがあることも聞いたことがあります。 それを作成するストアドプロシージャの最後で一時テーブルを切り捨てると、逆の期待にもかかわらず、truncateステートメントが使用されていない場合よりも、テーブルがtempdbでデータ用に使用するスペースがより速く解放されるようです。どうして？ そのような切り捨てステートメントを使用するかどうかの相対的なパフォーマンスへの影響はどうなりますか？SNAPSHOT分離を使用する場合、tempdbにストレスがかかることがよくあります。tempdbで使用されているスペースをできるだけ大きなtempテーブルからできるだけ早く解放すると、tempdbの不必要な増大を防ぐことができると思います。この潜在的なスペース節約は、パフォーマンスを犠牲にして実現されるでしょうか？ 以下に、問題を再現するためのコードを示します（主に@TheGameiswarから、いくつかの変更を加えたものです）。 SET NOCOUNT ON; GO ALTER PROC usp_test AS BEGIN IF object_id('tempdb..#temp') IS NOT NULL DROP TABLE #temp SELECT * INTO #temp FROM [dbo].[Event_28] -- This is a table with 15313 rows, using 35648 KB according to sp_spaceused --SELECT SUM(user_object_reserved_page_count) AS [user object pages used] …

12 sql-server  stored-procedures  tempdb  temporary-tables  truncate 

Postgres 10の新機能を説明するページには、「トリガー用の移行テーブル」が記載されています。 トリガーの遷移表 この機能はAFTER STATEMENT、必要に応じて古い行と新しい行をクエリに公開することにより、トリガーを有用かつ高性能にします。この機能の前は、AFTER STATEMENTトリガーはこれらに直接アクセスできませんでした。回避策はビザンチンであり、パフォーマンスが低下していました。多くのトリガーロジックをとして記述できるようになりAFTER STATEMENT、FOR EACH ROWトリガーが必要とする各行で高価なコンテキストスイッチを行う必要がなくなりました。 遷移表とは何ですか？

12 postgresql  trigger  table  postgresql-10