データベース管理者

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

1
MERGEデッドロック防止
私たちのデータベースの1つに、複数のスレッドによって集中的に同時にアクセスされるテーブルがあります。スレッドはを介して行を更新または挿入しますMERGE。行を時々削除するスレッドもあるので、テーブルデータは非常に不安定です。アップサートを実行するスレッドは時々デッドロックに悩まされます。この問題は、この質問で説明されている問題に似ています。ただし、違いは、私たちの場合、各スレッドが1行だけを更新または挿入することです。 簡略化されたセットアップは次のとおりです。テーブルは、2つの一意の非クラスター化インデックスを持つヒープです。 CREATE TABLE [Cache] ( [UID] uniqueidentifier NOT NULL CONSTRAINT DF_Cache_UID DEFAULT (newid()), [ItemKey] varchar(200) NOT NULL, [FileName] nvarchar(255) NOT NULL, [Expires] datetime2(2) NOT NULL, CONSTRAINT [PK_Cache] PRIMARY KEY NONCLUSTERED ([UID]) ) GO CREATE UNIQUE INDEX IX_Cache ON [Cache] ([ItemKey]); GO 典型的なクエリは DECLARE @itemKey varchar(200) = 'Item_0F3C43A6A6A14255B2EA977EA730EDF2', @fileName nvarchar(255) …

1
IAMページについて:エクステント間隔
Itzikの本「Querying Microsoft SQL Server 2012」を読んでいるほか、インターネットでさまざまな教育資料を読んだり見たりしています。私の意図は、データベースの内部がどのように機能するかを理解することです。 IAMページについて解決できなかったことに少し疑問があります。私は理解の非常に早い段階にいるので、それをよりよく理解している人たちからの追加の助けが必要かもしれません。 第15章の「インデックスと統計の実装」では、IAMページの例として次の画像が表示されます。 同じ範囲に関連する16ページと思われるものを赤い矢印で確認できます。そんなことがあるものか?著者/編集者の間違いですか?または、より可能性の高いもの:私が正しく理解していないものはありますか? 私が持っている他の質問は、ページ間隔に関連しています。なぜ隣接していないのですか?最後のエクステントを例にとると、IDが336から22642のページ、またはその前のページが296から328のページをカバーします。

2
PostgreSQL Upsertがパーティションテーブルで機能しない
次のようなテーブルがあります。 CREATE TABLE aggregated_master ( "user" BIGINT, type TEXT, date TIMESTAMP, operations BIGINT, amount NUMERIC, PRIMARY KEY ( "user", type, date ) ); このテーブルは、多くのパーティションが継承するマスターです。パーティションは、DATEフィールドのMONTHによって行われます。たとえば、Aug-2017のパーティションはagg_201708で、そのPKはpk_agg_201708になります。挿入を適切なパーティションにリダイレクトする通常のトリガーBEFORE INSERTがあります。 事は私がこのテーブルにUPSERTをしたいということです。DO CONFLICT部分が機能していません。 最初のコードはこのようなものでした INSERT INTO aggregated_master (user, type, date, oeprations, amount) SELECT user, type, date, SUM(ops), SUM(amt) FROM ... WHERE ... GROUP BY USER, TYPE, …

2
複数のユーザーが一時テーブルでストアドプロシージャを同時に実行できないのはいつですか?
最近TechNetで読んだ一時テーブルに関するドキュメントについて質問があります。そのページの一時テーブルセクションの4番目の段落は、次のようになります。 名前付き制約を使用して一時テーブルが作成され、一時テーブルがユーザー定義のトランザクションのスコープ内で作成される場合、一時テーブルを作成するステートメントを実行できるのは一度に1人のユーザーだけです。たとえば、ストアドプロシージャが名前付きの主キー制約を持つ一時テーブルを作成する場合、そのストアドプロシージャを複数のユーザーが同時に実行することはできません。 私は、インデックス化された一時テーブルを使用する少数のストアドプロシージャを大幅に利用する環境で作業しており、ユーザーが次の処理が始まる前に実行が完了するのを待たなければならないという問題に遭遇したことはありません。それが今後も続くことを願っていますが、この警告が適切に理解されていないと問題になる可能性があることを懸念しています。 具体的には、次の点については不明です。 これはグローバル一時テーブルにのみ適用されますか、それともローカル一時テーブルにも適用されますか?(後者の場合のように)セッションの外部に表示されないテーブルが別のセッションの同時実行を妨げるのは奇妙に思われます。 「名前付き制約」とは何ですか?すべての制約に名前が付いているわけではありませんか(システムで生成された場合でも)。これは、ユーザー定義のエイリアスを持つ制約を参照していますか?これは私には言い回しのように思えます。 「複数のユーザー」は実際には複数のセッションを意味しますか?これらの手順は、単一のサービスアカウントを使用してアプリケーションから呼び出されるため、スクリプトへの呼び出しの99.9%はその単一のアカウントによってDBに対して行われます(そして、管理者がバックエンドでときどき呼び出す可能性があるのではないかと心配しています)。サービスアカウントが複数のセッションで同時にsprocを実行できる場合、この問題は私の目的には当てはまりません。

5
相互に排他的な多対多の関係
私はテーブル持っているcontainersいくつかのテーブルに多対多の関係を持つことができる、のは、それらがあるとしましょうplants、animalsとbacteria。各容器は、任意の数の植物、動物、または細菌を含むことができ、各植物、動物、または細菌は、任意の数の容器に入れることができる。 これまでのところ、これは非常に簡単ですが、私が問題を抱えているのは、各コンテナには同じタイプの要素のみを含める必要があるということです。たとえば、植物と動物の両方を含む混合コンテナは、データベースの制約違反になります。 これの私の元のスキーマは次のとおりでした: containers ---------- id ... ... containers_plants ----------------- container_id plant_id containers_animals ------------------ container_id animal_id containers_bacteria ------------------- container_id bacterium_id しかし、このスキーマでは、コンテナーを均一にする必要があるという制約を実装する方法を思いつきません。 これを参照整合性で実装し、データベースレベルでコンテナが同種であることを保証する方法はありますか? これにはPostgres 9.6を使用しています。

3
作成時にデータベース照合を変更するトリガー
トリガーを作成して、作成時にデータベースの照合を変更しようとしていますが、トリガー内で使用するデータベース名をキャッチするにはどうすればよいですか? USE master GO CREATE TRIGGER trg_DDL_ChangeCOllationDatabase ON ALL SERVER FOR CREATE_DATABASE AS declare @databasename varchar(200) set @databasename =db_name() ALTER DATABASE @databasename COLLATE xxxxxxxxxxxxxxxxxxx GO 明らかに、これは機能していません。

6
ストアドプロシージャを並列で実行する
同じストアドプロシージャを、異なるパラメーターを使用して複数回同時に実行しようとしています。 SQL 2014を使用しています これは、手順が完了するまでに約7時間かかるためです。実際には同じプロセスを何度も実行します。したがって、たとえば、ブランチごとに新しいデータベースとテーブルを構築する場合があります。 ストアドプロシージャを分解して、ブランチごとに実行し、各クエリを並行して実行できるようにしたいと思います。私はこれを個別のクエリウィンドウで実行することでテストしましたが、ほぼ80%速く実行されます。 誰かが私にクエリを並行して実行するためのダミーガイドを教えてもらえますか?

1
SQL Serverクエリストアはパラメーター値をキャプチャしますか?
SQL Server 2016で導入された新しいクエリストアは素晴らしいです。これは、以前のプロファイラーツールで行っていた処理の多くを置き換えるのに最適です。ただし、リソースを大量に消費するクエリへの個々の呼び出しに関連するパラメータ値をキャプチャして、それを傍受する方法は見つかりませんでした。これは可能ですか? Query Storeは個別の呼び出しよりも集計データを扱うことを理解しているので、ここでは運が悪いのではないかと思います。遅いクエリを見つけたとき、最も遅い呼び出しの1つに関連付けられたパラメータも持つとトラブルシューティングに便利です。最新の優れたツールを使用してこれを行う方法を知りたいのですが。(プロファイラーの使用をお見逃しなく!) セキュリティの観点から、Query Storeはプロファイラーよりもロックダウンされていますか?集計を計算するには、あるレベルで個々の呼び出しからデータをキャプチャする必要があると思います。それのいずれかが格納されているかどうかはわかりません。

2
PostgreSQLでは、1バイトの「char」型はどの程度正確に機能しますか?
私はよく人が話して"char"いるのを見ます。使ったことがない。それはドキュメントで次のように定義されています: タイプ「char」(引用符に注意)は、1バイトのストレージのみを使用するという点でchar(1)とは異なります。これは、単純な列挙型としてシステムカタログで内部的に使用されます。 そしてさらに、 "char" 1 byte single-byte internal type それで、それが1バイトである場合、ドメインは何であり、どのようにそれを利用しますか?署名されていますか、署名されていませんか?@Erwin Brandstetterによるこの投稿では、彼はそれをレイアウトしていますが、私はまだ混乱しています。彼はand を使用してascii()おりchr()、これを提供しています SELECT i , chr(i)::"char" AS i_encoded , ascii(chr(i)::"char") AS i_decoded FROM generate_series(1,256) i; それは10から11の間で本当に奇妙なことをしています。 i | i_encoded | i_decoded -----+-----------+----------- ... 8 | \x08 | 8 9 | | 9 10 | +| 10 | | -- WTF …

2
一意の組み合わせ行を防ぐためにPostgreSQL制約を作成する
単純なテーブルがあると想像してください: name | is_active ---------------- A | 0 A | 0 B | 0 C | 1 ... | ... 次の状況で失敗する特別な一意の制約を作成する必要があります。異なるis_active値を同じname値に共存させることはできません。 許可される条件の例: 注:単純な複数列の一意のインデックスでは、このような組み合わせは許可されません。 A | 0 A | 0 B | 0 許可される条件の例: A | 0 B | 1 失敗した状態の例: A | 0 A | 1 -- should be prevented, …


2
バッファーページの1/3より大きい値はインデックス付けできません
私はDBがあまり得意ではないので、我慢してください。 非常に長いJSONデータをテーブルに配置しようとしています。このテーブルはDjangoフレームワークによって作成されました。 HerokuでPostgresを使用しています。したがって、データを配置しようとすると、次のエラーが発生します。 File "/app/.heroku/python/lib/python3.6/site-packages/django/db/backends/utils.py", line 64, in execute return self.cursor.execute(sql, params) psycopg2.OperationalError: index row size 3496 exceeds maximum 2712 for index "editor_contentmodel_content_2192f49c_uniq" HINT: Values larger than 1/3 of a buffer page cannot be indexed. Consider a function index of an MD5 hash of the value, or use full text …

2
ID列をINTからBIGINTに変更する
主キーでもあるID列を持つテーブルがあります。現在、5000万行あり、identity列の最高値は148,921,803です。テーブルには多くのがあり、そのテーブルDELETEでINSERTS実行されるため、値が高くなります。 私たちは、からのデータ型を変更したいINTとBIGINT多くの行を追加するための準備します。PK列への参照がないことに注意してください。 最小限のダウンタイムでこれを行うための最良の方法は何ですか?2つのオプションがあります。 PKをドロップして列を変更します。または ここで説明するように、copy-drop-renameメソッド:

3
開発者はLocalDBと「開発」インスタンスの使用を許可する必要がありますか?
以前にここに投稿された「開発者は本番データベースにクエリを実行できるようにする必要がありますか?」という質問の筋によく似ています。 多くの企業は、開発者が開発マシンにSQL Server Expressなどをインストールするのを防ぎ、代わりに集中型開発SQL Serverの使用を促進しています。 具体的には、次のことを確実にするために行われます。 開発サーバーとプロダクション間のパッチレベルの一貫性 上記のパッチを証明および検証する機能 データセキュリティ; 開発サーバー上のデータのみが開発に使用されます 回復性; データは回復可能であり、まだバックアップされています 本番環境に移行すると問題が発生する可能性がある照合順序の違い 私にとって、これらの引数はすべておそらく無効ですが、パッチの引数は例外です。しかし、ローカルマシン上のデータベースがテストではなく開発アクティビティのみに使用されている場合、アプリケーションがテスト/ UATなどを介して本番環境に移行すると、パッチが適用されたことが証明されます。 照合順序は、データベースにとって問題であるかのように、有効な理由ではないようです。作成時に設定する必要があります。私が知る限り、SharePointとSCCMのみがこの問題を抱えています;) ここで、それが開発専用であり、データベースが本番環境に「移動」されず、唯一の移動は次のようになると想定します。 本番環境へのデプロイ用に生成されるデータベースを作成したスクリプト 「本番」サードパーティシステムからのバックアップは、検証と開発に適した場所で復元および切り捨てられます 誰でも何か問題を見ることができますか?何か不足していますか? 最大の懸念の1つは、ローカルのdbインスタンスが古くなってしまうことですが、これはソフトウェア管理の問題であり、DBAのIMOではありません。

2
昇順の主要な問題-「静止」というブランドの主要な列-SQL Server
私はデータベースで実行速度の遅いクエリを調査しており、これが古典的な昇順キー問題であると結論付けました。新しい行がほぼ常に挿入され、DBから最新のデータを引き出すための特定のSQLが30分ごとに実行されるため、30分ごとに統計を更新する最初のオプションは、リソースを浪費する可能性があるようです。 したがって、私はトレースフラグ2389を調べましたが、これは原則的には役立つはずですが、先行列を昇順としてブランド化する必要があり、トレースフラグ2388を使用して(PK)インデックス統計を確認すると、先行列が実際に定常としてブランド化されます-同時に更新される他のテーブルのいくつかのPKインデックスのためです。 Stationaryのブランド化の結果に関するガイダンスはそれほど多くないようですが、KB2952101は、挿入の90%未満が古い最大値よりも大きい場合、それはStationaryとして分類されると述べています。すべての挿入は新しい送信であり、最初の列はbigint IDENTITY列であるため、挿入の100%は以前の最大値より大きくなければなりません。 それで、私の質問は、明らかに昇順であるのに、なぜ列がステーショナリーとしてブランド化されるのでしょうか? 毎日実行中のSQLでこの問題を解決するための以前の試み(これは非常にうまく機能しました)により、このテーブルの統計を毎晩更新するジョブがセットアップされました。更新ではFULLSCANが実行されないため、サンプリングされたスキャンで新しい行が欠落することがあり、常に昇順で表示されるとは限りませんか? これに影響を与える可能性があると私が考えることができる他の唯一のことは、特定の期間を超えて行を削除する舞台裏でアーカイブジョブが実行されていることです。これはブランディングに影響を与える可能性がありますか? サーバーはSQL Server 2012 SP1です。 更新:別の日、別の統計情報の更新-同じ静止したブランド。前回の統計更新以降、28049の新しい挿入がありました。各行には、挿入されたときのタイムスタンプがあるため、timestamp <'20161102'であるテーブルからmax(id)を選択すると23313455が得られます。 これらの違いは28049の新しい挿入です。ご覧のように、すべての新しい挿入には新しい昇順キーが(期待どおりに)与えられています。これは、先頭の列を固定ではなく昇順としてブランド化する必要があることを示しています。 同じ期間に、アーカイブジョブによって213,629行が削除されました(古いデータは徐々に消去されます)。行数の削減が定常的なブランディングに貢献する可能性はありますか?私はこれを以前にテストしたことがあり、それが何かの違いをもたらすようには見えませんでした。 更新2:別の日、別の統計が更新され、列に昇順のフラグが付けられます!これに影響する削除に関する理論に従って、私は削除と比較して挿入である更新のパーセンテージをチェックしました、そして昨日の13%は挿入でしたが、過去2日間の挿入は約12%を占めました。それが決定的なものになるとは思いません。 興味深いことに、このメインテーブルに挿入された各行に対して平均4行が挿入され、同時に統計が更新される関連テーブルで、IDENTITY PK列はまだ静止していますか? 更新3:週末に追加の挿入物を取得します。今朝、リーディングコラムはステーショナリーに戻りました。前回の統計更新では、46840の挿入と34776の削除しかありませんでした。 繰り返しになりますが、興味深いことに、上記で説明した関連テーブルには、昇順というブランドの主要な列があります。これを説明できるドキュメントはありませんか? 更新4:約1週間が経過しました。アーカイブジョブによりバックログがクリアされたため、挿入される行数の約3分の2を一貫して削除しています。統計は、すべて同じように比例して更新されているにもかかわらず、関連するテーブル全体で混合結果を示しています。1つは定常を示し、2つは上昇を示しています。

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