データベース管理者

並列選択クエリのメモリ許可について矛盾することを聞いたことがあります。 メモリ許可はDOPで乗算されます メモリ許可はDOPで除算されます どっち？

9 sql-server  parallelism  memory-grant 

私たちのチームは、アプリケーションと関連するデータベースを継承しています。以前の開発者は、すべてのテーブルのすべてのインデックスにINCLUDE句があり、それ以外の場合はキーの一部ではないすべての列を常に追加するというルールを適用しているようです。これらのテーブルには、平均して2〜5個のインデックスまたは一意の制約と外部キーがあります。 アクセスはデフォルトで（常にではないが）すべての列を取得するORMを介して行われるため、データベースでスローされるクエリに関係なく、SELECTのパフォーマンスを向上させることを目的としています。これの副作用は、ストレージ要件の増加（おそらく大幅に増加する）とINSERT / UPDATE / DELETEの追加のオーバーヘッド時間であると予想されます。 問題は、これは賢明な戦略ですか？私たちのチームにはSQL Serverの履歴がありますが、内部の動作について専門家であると考えるメンバーはいません（ただし、この戦略が最適だった場合、今のところデフォルトではないのではないかという質問が出されました）。他にどのような副作用（データベースサーバーのCPU /メモリ/ TempDBの使用など）が予想されますか、または上記の仮定の一部が正しくありませんか？ さらに、アプリケーションは、オンプレミスのSQL Server（2012年以降のバージョン）とAzure SQLの両方にインストールできます-この結果として、2つの違い、またはAzureへの追加の副作用に備えておく必要があります。アプローチ？

9 sql-server  sql-server-2012  sql-server-2014  sql-server-2016  azure-sql-database 

複数のデータベースを実行している単一のSQL2012 SP4ノードがあります。 サーバーには20 GBのメモリが利用可能で、14 GBがSQLに割り当てられています（他にボックスで実行されているものはありません）。 SQLは数分ごとにバッファキャッシュ全体をダンプします。ページの平均余命はゼロになり、バッファキャッシュ記述子はキャッシュに何もないことを示します。 私はリソースモニターの通知を確認しました。通知は数ミリ秒ごとに高/定常/低から跳ね回っています。 RESOURCE_MEMPHYSICAL_HIGH RESOURCE_MEM_STEADY RESOURCE_MEMPHYSICAL_LOW タイムスタンプが数ミリ秒離れています。PLEは基本的に鋸歯状のパターンです。 これは、SQL2012 SP1とこの質問で以前に発生したのを見たことがあります。 バッファーキャッシュ内のSQL Server 2012空きページが使用されていない 私はすでにSP4に更新していますが、同様の問題のようです。 サービスアカウントのLPIMをオンにして、最大メモリ設定をいじってみました。最大メモリを下げると、バッファキャッシュがより頻繁に空になるようです。 次に確認することについてのアイデアはありますか？ サーバーのワークロードは文字通り何もありません（ERPシステムでアイテムのリストをスクロールしていますが、キャッシュが再び低下するまでに約40〜50 MBに達します）。 SP1からアップグレードしてこれを修正したので興味深いです。キャッシュが約500MBになりました。それ以来、私は最大メモリ設定を14GBに落としました。 Windowsがパニックに陥り、SQLでのメモリプレッシャーに関する誤った通知をスローしているのではないかと思います。つまり、最大メモリが無制限に設定されているサーバーは問題なく動作しているようですが、数百MBを超えるキャッシュを満たしていないようです。やっと50に... 詳細：尋ねた人のために コア数： 4 データベースサイズ： 80GB エラーログは以下を示します： A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 …

9 sql-server  sql-server-2012  memory  cache 

SQL Server 2017実行プランでこの警告を見てきました： 警告：操作によりIOが残りました[sic]。実際に読み取られた行数は（3,321,318）でしたが、返された行数は40でした。 SQLSentry PlanExplorerからのスニペットは次のとおりです。 コードを改善するために、SQL Serverが関連する行にアクセスできるように、非クラスター化インデックスを追加しました。これは正常に機能しますが、通常は（大きな）列が多すぎてインデックスに含めることができません。次のようになります。 インデックスのみを追加し、列を含めない場合、次のようになります。インデックスを強制的に使用すると、 明らかに、SQL Serverは、キールックアップは残りのI / Oよりもはるかにコストがかかると考えています。（まだ）多くのテストデータを含まないテストセットアップがありますが、コードが運用環境に入ると、より多くのデータを処理する必要があるため、何らかの非クラスター化インデックスが必要だとかなり確信しています。 SSDで実行する場合、キールックアップは本当に高価ですが、私は（多くのインクルード列を含む）全脂肪インデックスを作成する必要がありますか？ 実行計画： https : //www.brentozar.com/pastetheplan/?id=SJtiRte2Xこれは、長いストアドプロシージャの一部です。を探しIX_BatchNo_DeviceNo_CreatedUTCます。

9 sql-server  optimization  execution-plan  sql-server-2017  nonclustered-index 

このタイプの質問が行われたのはこれが初めてではありません。 しかし、次のシナリオで永続的な計算列が「非決定的」に作成されるのはなぜですか。答えはいつも同じでしょ？ CREATE TABLE dbo.test (Id INT, EventTime DATETIME NULL, PosixTime INT NOT NULL) GO DECLARE @EventTime DATETIME = '20181001 12:00:00' DECLARE @GPSTime INT = DATEDIFF(SECOND, '19700101', @EventTime) INSERT INTO dbo.Test(Id, EventTime, PosixTime) VALUES (1, @EventTime, @GPSTime) , (2, NULL, @GPSTime) GO SELECT * FROM dbo.test GO ALTER TABLE dbo.test …

9 sql-server  sql-server-2012  computed-column 

Postgresの機能を使用して宣言されている揮発性の分類VOLATILE、STABLEまたはIMMUTABLE。プロジェクトは、組み込み関数のこれらのラベルで非常に厳しいことが知られています。そして正当な理由があります。顕著な例：式のインデックスはIMMUTABLE関数のみを許可し、誤った結果を回避するためにそれらは真に不変でなければなりません。 ユーザー定義関数は、所有者の選択に従って自由に宣言できます。マニュアルは助言します： 最適化の最良の結果を得るには、関数に有効な最も厳密なボラティリティカテゴリで関数にラベルを付けてください。 ...そして、不適切なボラティリティラベルで問題が発生する可能性のあるものの広範なリストを追加します。 それでも、不変性を偽ることが理にかなっている場合があります。あなたがするとき、ほとんど知っている機能は、実際には、あなたの範囲内で不変です。例： PostgreSQLは「アクセントを区別しない」照合をサポートしていますか？ データの整合性に関する考えられるすべての影響はさておき、パフォーマンスへの影響は何ですか？関数の宣言はパフォーマンスにのみ有益であると考える人もいるかもしれません。そうですか？IMMUTABLE 関数のボラティリティIMMUTABLE を宣言するとパフォーマンスが低下しますか？ 現在のPostgres 10でそれを絞り込むと仮定しますが、最近のすべてのバージョンが対象です。

9 postgresql  performance  functions 

2つのpg_trgmインデックスをテーブルに追加しました。これは、ユーザー名、またはサインアップ中にスペルが間違っているメールアドレス（ "@ gmail.con"など）でユーザーを検索する必要があるため、メールアドレスまたは名前によるあいまい検索を可能にします。ANALYZEインデックスの作成後に実行されました。 ただし、これらのインデックスのいずれかでランク付けされた検索を実行すると、ほとんどの場合非常に遅くなります。つまり、タイムアウトを長くすると、クエリが 60秒で返される場合がありますが、15秒という非常にまれな場合もありますが、通常はクエリがタイムアウトします。 pg_trgm.similarity_threshold0.3はのデフォルト値ですが、これを上げて0.8も違いはないようです。 この特定のテーブルには2,500万行以上があり、常に照会、更新、および挿入されます（それぞれの平均時間は2ミリ秒未満です）。セットアップは、汎用SSDストレージと多かれ少なかれデフォルトのパラメーターを備えたRDS db.m4.largeインスタンスで実行されているPostgreSQL 9.6.6です。pg_trgm拡張子はバージョン1.3です。 クエリ： SELECT * FROM users WHERE email % 'chris@example.com' ORDER BY email <-> 'chris@example.com' LIMIT 10; SELECT * FROM users WHERE (first_name || ' ' || last_name) % 'chris orr' ORDER BY (first_name || ' ' || last_name) <-> 'chris orr' …

9 postgresql  query-performance  postgresql-performance  postgresql-9.6 

トランザクションと並行性に関する本を読んでいます。1つの段落では、次のように述べられています。 オンプレミスのSQL Serverインスタンスでは、デフォルトの分離レベルはロックに基づいて読み取りコミットされています そして次の文は： SQLデータベースのデフォルトは読み取りです-行のバージョン管理に基づいてコミットされたスナップショット 私の質問は、これらの2つの文で「オンプレミスSQL Serverインスタンス」と「SQLデータベース」の違いは何ですか？ デフォルトの分離レベルとは何ですか？どのようにして見つけることができますか？デフォルトの分離レベルを確認するための特別なクエリはありますか？

9 azure-sql-database  concurrency  sql-server-2017  isolation-level 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、データベース管理者のスタック交換のトピックになるようにします。 6か月前に閉鎖。 S2エディション（50 DTU）でAzure SQLデータベースを実行しています。サーバーの通常の使用では、通常、約10％のDTUがハングします。ただし、このサーバーは定期的にデータベースのDTU使用率を85〜90％に数時間送信する状態になります。その後、突然、通常の10％の使用量に戻ります。 この過負荷状態の間、アプリケーションからのサーバーに対するクエリは、まだ高速に動作しているようです。 サーバーをS2 =>何からでもスケーリングできます（たとえば、S3）=> S2。サーバーがハングしている状態をすべてクリアするように見えます。しかし、数時間後、同じ過負荷状態のサイクルが繰り返されます。私が気付いたもう1つの奇妙なことは、このサーバーをS3プラン（100 DTU）で24時間年中無休で実行した場合、この動作は観察されなかったことです。データベースをS2プラン（50 DTU）にダウンスケールした場合にのみ発生するようです。S3プランでは、私は常に5-10％DTU使用率で座っています。明らかに十分に活用されていません。 不正なクエリを探してAzure SQLクエリレポートをチェックインしましたが、実際に異常なものは見られず、期待どおりにリソースを使用してクエリが表示されます。 ここでわかるように、使用法はすべてData IOからのものです。ここでパフォーマンスレポートを変更して、MAXごとの上位のデータIOクエリを表示すると、次のようになります。 これらの長期にわたる要求を見ると、統計の更新が指摘されているようです。私のアプリケーションから実際には何も実行されていません。たとえば、クエリ16302には次のように表示されます。 SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000] FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS [SC1], [Id] AS [SC2] FROM …

9 sql-server  azure-sql-database  statistics 

.NET Core APIアプリを強化するAzure SQLデータベースがあります。Azure Portalでパフォーマンス概要レポートを参照すると、データベースサーバーの負荷（DTU使用量）の大部分がCPUからのものであり、具体的には1つのクエリが原因であることがわかります。 ご覧のように、クエリ3780は、サーバーのほぼすべてのCPU使用率の原因です。 クエリ3780（下記参照）は基本的にアプリケーションの核心であり、ユーザーから頻繁に呼び出されるため、これは多少意味があります。また、必要な適切なデータセットを取得するために必要な多くの結合を伴う、かなり複雑なクエリでもあります。クエリは、次のようなsprocから取得されます。 -- @UserId UNIQUEIDENTIFIER SELECT C.[Id], C.[UserId], C.[OrganizationId], C.[Type], C.[Data], C.[Attachments], C.[CreationDate], C.[RevisionDate], CASE WHEN @UserId IS NULL OR C.[Favorites] IS NULL OR JSON_VALUE(C.[Favorites], CONCAT('$."', @UserId, '"')) IS NULL THEN 0 ELSE 1 END [Favorite], CASE WHEN @UserId IS NULL OR C.[Folders] IS NULL …

9 sql-server  query-performance  execution-plan  azure-sql-database  cpu 

Ubuntu 12.04上のMySQL 5.5.28 結果がそれよりも長い場合group_concat_max_len、結果は正常に切り捨てられます。 現在、私は事前に必要な長さをチェックし、group_concat_max_len十分な大きさに設定するスクリプトを持っています。 ただし、このチェックでは余分なクエリが追加されます。group_concat_max_len最大値に設定するだけの欠点はありますか？利点は、クエリが少ないことです。

9 mysql  group-concatenation 

sys.objectsの[Type]列に奇妙な（文書化されていない）値が表示されます。以下に示すように、値は「ST」です（注、dbo.Recordはユーザーテーブルです）。 この「ST」値の意味を誰かが知っていますか？（これはSQL Server 2014 Developer Editionにあります）

9 sql-server  sql-server-2014  datatypes  metadata 

存在する場合、指定されたテーブル名を切り捨てるpsql関数を取得しようとしています。私は複数の機能を試してきましたが、どれも今のところ機能していません。ここにコードがあります： CREATE OR REPLACE FUNCTION truncateIfExists(tableName TEXT) returns void as $$ BEGIN EXECUTE format( 'IF EXISTS ( SELECT * FROM information_schema.tables WHERE table_name =' || tableName || ' ) THEN TRUNCATE tableName; END IF; '); END; $$language plpgsql これで、名前を固定した簡単な手順で機能させることができます。 do $$ begin IF EXISTS (SELECT * FROM information_schema.tables WHERE table_name …

9 postgresql  functions 

少し前に、MySQLデータベースの1つで高いCPUシステム時間を経験し始めました。このデータベースもディスク使用率が高いため、それらが接続されていることがわかりました。また、SSDへの移行をすでに計画していたため、両方の問題を解決できると考えました。 それは役に立ちました...しかし、長くはありませんでした。 移行後の数週間、CPUグラフは次のようになりました。 しかし今、私たちはこれに戻っています： これはどこからともなく発生し、負荷やアプリケーションロジックに明らかな変化はありませんでした。 DB統計： MySQLバージョン-5.7.20 OS-Debian DBサイズ-1.2Tb RAM-700Gb CPUコア-56 ピーク負荷-約5kq / sの読み取り、600q / sの書き込み（選択クエリはしばしばかなり複雑ですが） スレッド-50実行、300接続 約300のテーブルがあり、すべてInnoDB MySQL設定： [client] port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld_safe] pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir …

9 mysql  mysql-5.7 

PostgreSQL 9.2から9.6にアップグレードする必要があります。以下は私が直面している課題です。 ストリーミングレプリケーションのセットアップがあり、ストリーミングレプリケーションモードではPostgreSQLが下位バージョンから上位バージョンへのアップグレードをサポートしていないため、マスターをアップグレードするとスレーブを再構築する必要があり、3時間かかります。その時間はありません。常に1つのスレーブと1つのマスターを使用できる必要があります。ストリーミングレプリケーションを使用して、スレーブを再構築せずにアップグレードする他の方法はありますか？ 論理複製を構築するために、slonyを使用することを考えましたが、slonyは自動的に複製しないという点でいくつかの制限があります。 ラージオブジェクト（BLOB）への変更 DDLコマンドによる変更 ユーザーとロールへの変更 ...そして私たちのアプリケーションには継続的な作成コマンドがあります。したがって、slonyは使用できません。 スレーブの再構築を回避し、最小限のダウンタイムでアップグレードを行い、1つのマスターと1つのスレーブの準備を整えるための提案をしてください。

9 postgresql  upgrade