データベース管理者

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

2
トランザクションログを別のボリュームに配置する[ソリッドステート]？
多くの場合、トランザクションログは別のボリュームに分離されます。私が理解しているように、このプラクティスの理論的根拠は、トランザクションログのデータが順次書き込まれることであり、ハードドライブはランダムではなく、はるかに高速で書き込み操作を実行できることです。これは、ランダムな書き込みとは対照的に、データの連続したブロックを書き込むときにドライブ内の小さな針がはるかに短い距離を移動する必要があるためです。 （素朴な解釈はごめんなさい。私が読んだことを理解しようとしています。） これを念頭に置いて…ソリッドステートドライブには、針やプラッターなどが中を動き回らないことがわかります。データベースとトランザクションログの両方が8つのソリッドステートドライブの単一のRAID 5にある場合、トランザクションログを独自の別のボリュームに移動することには本当に利点がありますか？想定される効率の向上が、針が移動してプラッターが回転する距離を減らす連続書き込みの前提に基づいており、ソリッドステートドライブにこれらの可動部分がない場合、ログを分離すると何が得られますか？
4
OracleでNULL可能数を使用しない理由は？
私たちの会社は、共同プロジェクトのために他のソフトウェア会社とインターフェイスをとっており、特定の値を表示しない場合は、-5000（任意のセンチネル値）を渡す必要があると言われました。その理由は、（以前の）Oracle開発者の推奨により、Oracleデータベースの数値列がnull値をサポートしていないためです。また、この会社はコードの大部分をVB6で記述しています（VB.NETへの移行はゆっくりと進んでおり、これもまた別の日のトピックです...）。純粋な好奇心から、この推奨事項の正当な理由はありますか？私の側に何も考えられません。 ---編集 すべてのフィードバックをありがとう。CodeProject.com（link）で同じ質問を投げかけ、非常によく似たフィードバックを受け取りました。この方法が外部キーに関連していることを正当化できる可能性があるのは唯一のようであり、システム内のどこでも外部キーを使用しないと述べることができます。この決定をした開発者（私は以前その会社で働いていた）は、私よりもはるかに多くの経験を持っているので、ris笑が起こる前に、これに対する正当な理由がないことを確認したかった。
4
SQL Server 2012は、テーブル名と列名を[括弧]で囲んでいます
Columnsフォルダーをエディターウィンドウにドラッグすると、列の完全なリストがブラケットなしで追加されます。列を個別にドラッグすると、ブラケットが表示されます。 とにかくそれをオフにする方法はありますか？私はオプションに何も見つけることができず、それらは本当に注意散漫です。
3
1つの列でDISTINCTを選択し、他の列を返しますか？
3つのルックアップテーブルを使用して必要なすべての情報を取得するクエリがあります。私が持っている必要がありますDISTINCTが、私もそれに関連するデータの残りを必要とする、1列の値を。 私のSQLコード： SELECT acss_lookup.ID AS acss_lookupID, acss_lookup.product_lookupID AS acssproduct_lookupID, acss_lookup.region_lookupID AS acssregion_lookupID, acss_lookup.document_lookupID AS acssdocument_lookupID, product.ID AS product_ID, product.parent_productID AS productparent_product_ID, product.label AS product_label, product.displayheading AS product_displayheading, product.displayorder AS product_displayorder, product.display AS product_display, product.ignorenewupdate AS product_ignorenewupdate, product.directlink AS product_directlink, product.directlinkURL AS product_directlinkURL, product.shortdescription AS product_shortdescription, product.logo AS product_logo, product.thumbnail AS …
2
ユーザーが自分のスキーマ内で何でもできるようにするが、スキーマ自体を作成または削除しない
SQL Azureでスキーマを作成し、データベースロールに次のアクセス許可を付与しました。 CREATE ROLE myrole AUTHORIZATION dbo; EXEC sp_addrolemember 'myrole', 'myuser'; CREATE SCHEMA myschema AUTHORIZATION dbo; GRANT ALTER, CONTROL, DELETE, EXECUTE, INSERT, REFERENCES, SELECT, UPDATE, VIEW DEFINITION ON SCHEMA::myschema TO myrole; GRANT CREATE TABLE, CREATE PROCEDURE, CREATE FUNCTION, CREATE VIEW TO myrole; 上記で定義したアクセス許可により、myuser自分のスキーマを作成/削除できるため、問題を克服するために、ALTER ANY SCHEMAアクセス許可を試しました。しかし、この許可はユーザーがテーブルを作成/削除することも拒否します。 ユーザーが自分のスキーマ内で何でもできるが、スキーマ自体を作成または削除できないようにするには、どのような権限が必要ですか？
1
DELETEがSELECTよりもはるかに遅いのに、IDでDELETEするのはなぜですか？
私はかなり忙しいInnoDBテーブルを持っています（200,000行、1秒あたり数十のクエリのようなものだと思います）。バグが原因で、（同じ）無効なメールアドレスが含まれる14行を取得し、それらを削除したいと考えました。 私は単純にしようとしたDELETE FROM table WHERE email='invalid address'と、約50秒後に「ロック待ちタイムアウトを超えて」しまいました。行の列にはインデックスが付けられていないため、これは驚くべきことではありません。 しかし、私はそうしSELECT id FROM table WHERE email='invalid address'、それは1.25秒かかりました。実行DELETE FROM table WHERE id in (...)、コピー、貼り付けSELECTの結果から、IDSは、0.02秒を要しました。 何が起こっている？条件付きのDELETEが非常に遅いためタイムアウトする理由を誰かが説明できますか？ ありがとう。 編集：リクエストに応じて、テーブル構造といくつかのexplain結果を投稿しました。また、このテーブルを参照する外部キーがないことにも注意してください。 しかし、状況は私には簡単に思えます。私が選択しているインデックスのないフィールドがあります。これにはテーブル全体をスキャンする必要がありますが、それほど大きくありません。idは主キーであるため、IDによる削除は非常に高速です。 mysql> show create table ThreadNotification2 \G *************************** 1. row *************************** Table: ThreadNotification2 Create Table: CREATE TABLE `ThreadNotification2` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `alertId` bigint(20) DEFAULT …
3
主キーの代わりにカバー列を持つ一意の非クラスター化インデックスを使用することの意味
私たちは、大きなテーブル持っている[MyTable]現在の両方Aを有しPrimary Key、かつUnique Non Clustered Index同じ列に（[KeyColumn]）。U NCインデックスには、追加のカバー列もあります。 同じ列にPKと一意のNCインデックスの両方があることは冗長に思えるので、主キーを削除し、代わりに参照整合性の目的で一意の非クラスタ化インデックスを使用することを検討していました。 テーブルは別の列によって完全にクラスター化されることに注意してください。 つまり、次のとおりです。 ALTER TABLE [MyTable] ADD CONSTRAINT [PK_MyTable] PRIMARY KEY NONCLUSTERED ([KeyColumn]) GO そして CREATE UNIQUE NONCLUSTERED INDEX [IX_MyTable_SomeIndex] ON [MyTable] ([KeyColumn]) INCLUDE ([Column1], [Column2]) GO 私の知る限り、主キーにカバー列を追加することはできないため、次のことを行います。 依存する外部キー制約の削除 MyTable.KeyColumn 主キーをMyTable.KeyColumn完全にドロップします テーブルに外部キーを再追加します（RIはを介して強制されますMyTable.KeyColumn） これを考えることができる唯一の意味は、ERDダイアグラムに視覚的なキーシンボルが表示されず、列が含まれているため（リーフ）インデックス密度が低くなるということです。 /programming/487314/primary-key-or-unique-indexを読んで、これを行うことの整合性とパフォーマンスの側面に満足しています。 私の質問は次のとおりです。このアプローチには欠陥がありますか？ 私が達成しようとしていることを編集します：パフォーマンス最適化と春の掃除。PKまたはインデックスのいずれかを削除すると、インデックスに必要なページが少なくなり、書き込みが高速になり、さらにメンテナンス/運用上の利点が得られます。 これにいくらかの背景を置くために、私はこれまでに、PKなしで参照されているテーブルを持っていませんでした。ただし、列をカバーするNCインデックスがテーブルに追加されたという事実は、自分の考え方を適応させる必要があることを意味します。
4
CXPACKET待機の処理-並列処理のコストしきい値の設定
Sharepointサイトのトラブルシューティングに関する以前の質問のフォローアップとして、CXPACKETの待機について何かできるかどうか疑問に思いました。 ひざまずく解決策は、MAXDOPを1に設定することですべての並列処理をオフにすることであることを知っています。これは悪い考えのように聞こえます。しかし、別のアイデアは、並列処理が開始される前にコストのしきい値を増やすことです。実行計画のコストのデフォルトの5はかなり低いです。 だから私は、実行計画コストが最も高いクエリを見つけるクエリがすでに書かれているのだろうかと思っていました（実行期間などが最も長いクエリを見つけることができることを知っていますが、実行プランのコストはどこかで取得可能です、また、そのようなクエリが並行して実行されたかどうかも教えてくれます。 誰かがそのようなスクリプトを手元に持っていますか、またはこれを見つけるために関連するDMV、DMFまたは他のシステムカタログビューの方向に私を向けることができますか？
3
ORDER BYが2つのテーブルをEXCEPTの前（遅い）にソートし、後（速い）にソートしないのはなぜですか？
SQL Server 2008 R2クエリオプティマイザーパズル 2つのテーブルがあり、どちらにも900万行が含まれています。70.000行は異なり、他は同じです。 これは高速、13秒です。 select * from bigtable1 except select * from similar_bigtable2 これにより出力がソートされ、13秒も高速になります。 select * into #q from bigtable1 except select * from similar_bigtable2 select * from #q order by sort_column これは非常に遅いですが、 ;with q as ( select * from bigtable1 except select * from similar_bigtable2 ) select …
3
PostgreSQL初期データベースサイズ
私の質問には2つの部分があります。 PostgreSQLのデータベースの初期サイズを指定する方法はありますか？ 存在しない場合、データベースが時間の経過とともに大きくなった場合の断片化にどのように対処しますか？ 最近、MSSQLからPostgresに移行しました。データベースを作成するときにMSSQLの世界で行ったことの1つは、データベースとトランザクションログの初期サイズを指定することでした。これにより、特にデータベースの「通常の」サイズが事前にわかっている場合、断片化が減少し、パフォーマンスが向上します。 サイズが大きくなると、データベースのパフォーマンスが低下します。たとえば、私がそれを実行しているワークロードは通常10分かかります。データベースが大きくなると、この時間が長くなります。VACUUM、VACUUM FULL、およびVACUUM FULL ANALYZEを実行しても問題は解決しないようです。パフォーマンスの問題を解決するのは、データベースを停止し、ドライブの断片化を解消してから、VACUUM FULL ANALYZEを実行すると、テストのパフォーマンスが元の10分に戻ります。これは、断片化が痛みの原因であると疑うことにつながります。 Postgresでテーブルスペース/データベーススペースを予約するための参照を見つけることができませんでした。間違った用語を使用しているため何も見つからないか、Postgresでファイルシステムの断片化を緩和する別の方法があります。 ポインタはありますか？ ソリューション 提供された回答は、私が疑い始めたことを確認するのに役立ちました。PostgreSQLはデータベースを複数のファイルに保存します。これにより、断片化の心配なしにデータベースを拡張できます。デフォルトの動作では、これらのファイルをテーブルデータでいっぱいにパックします。これは、ほとんど変更されないテーブルには適していますが、頻繁に更新されるテーブルには適していません。 PostgreSQLはMVCCを使用して、テーブルデータへの同時アクセスを提供します。このスキームでは、更新ごとに更新された行の新しいバージョンが作成されます（これはタイムスタンプまたはバージョン番号を使用している可能性があります）。古いデータはすぐには削除されませんが、削除のマークが付けられます。実際の削除は、VACUUM操作が実行されるときに発生します。 これは曲線因子とどのように関係しますか？テーブルのデフォルトのフィルファクター100はテーブルページを完全にパックします。つまり、テーブルページ内に更新された行を保持するスペースがないことを意味します。つまり、更新された行は元の行とは異なるテーブルページに配置されます。私の経験が示すように、これはパフォーマンスに悪いです。サマリーテーブルは非常に頻繁に更新されるため（最大1500行/秒）、20のFILL FACTORを設定することを選択しました。つまり、テーブルの20％が挿入行データ用で、80％が更新データ用です。これは過度に思えるかもしれませんが、更新された行のために予約された大量のスペースは、更新された行が元のページと同じページ内に留まり、autovacuumデーモンが古い行を削除するまでにテーブルページがいっぱいにならないことを意味します。 データベースを「修正」するために、次のことを行いました。 サマリーテーブルのFILL FACTORを20に設定します。作成時にこれを行うには、パラメーターをCREATE TABLEに渡すか、ALTER TABLEを介してファクトの後に渡します。次のplpgsqlコマンドを発行しました。ALTER TABLE "my_summary_table" SET (fillfactor = 20); VACUUM FULLを発行しました。これにより、完全に新しいバージョンのテーブルファイルが書き込まれ、含意により新しいフィルファクターで新しいテーブルファイルが書き込まれます。 テストを再実行すると、数百万行のデータベースが必要な大きさであっても、パフォーマンスの低下は見られません。 TL; DR-ファイルの断片化は原因ではなく、表スペースの断片化でした。これは、特定のユースケースに合わせてテーブルのFILL FACTORを調整することで軽減されます。
1
JDBCで明示的なコミットを無効にする、SQLで検出する、またはデータベースを読み取り専用状態にする
背景：私はhttp://sqlfiddle.com（私のサイト）に取り組んでおり、そこで悪用される可能性のある1つの手段を防止しようとしています。私が現在取り組んでいる問題について尋ねることによって、潜在的な虐待を不注意に悪化させないことを望んでいますが、あなたは何ができますか？皆さんを信頼しています。 任意のユーザーが特定のトランザクションブロック内で明示的な「コミット」呼び出しを発行することを防止したいと思います。SQL Fiddleのコンテキストから見ると、トランザクションブロックは右側のパネルで実行されるコードです。基本的に、ループしてプレーンテキストのSQLコマンドのリストを実行し、それらの変更がすべてバッチの最後に確実にロールバックされるようにします。通常、それらの変更はロールバックされますが、テキスト内に明示的な「コミット」ステートメントがある場合があるため、もちろん私のロールバックは機能しません。この明示的なコミットは、SQL Fiddleでスキーマを壊そうとするユーザーによるものである可能性が高いため、他のユーザーがエラーを確認します。 主な望ましい結果：可能であれば、JDBCレベルで明示的なコミットを無効にします。これは、複数のデータベースバックエンドベンダーをサポートする必要があるためです。もちろん、それぞれのベンダーには低レベルの癖があります。 フォールバックオプション：明示的なコミットを無効にするようにJDBCを構成できない場合、SQL Server、Oracle、MySQL、およびPostgreSQLの各バックエンドのバッチを処理中に明示的なコミットを検出するためのソリューションを利用できます。 SQL Serverの場合、このソリューションを考えました。実行する前にステートメントのXMLクエリプランを解析し、このXPathに一致するエントリの存在を確認します。 //*[@StatementType="COMMIT TRANSACTION"] これはSQL Serverでかなりうまくいくと思います。ただし、このアプローチは他のDBタイプでは機能しません。明示的なコミットに関するOracleのXML実行計画の出力は、コミットステートメントを実行しているという事実を参照していません（むしろ、コミットしているクエリから実行計画の出力を単純に繰り返します）。PostgreSQLおよびMySQLは、明示的なコミットに対して実行計画の出力（XMLまたはそれ以外）を一切提供しません。 そのため、「コミット」という単語の実際のステートメントを確認できます。これは機能しますが、可能なすべての種類のバリエーションがある場合を除きます。 declare @sql varchar(50) set @sql = 'com' + 'mit' exec(@sql); 上記はSQL Serverの例です（回避できます）が、Oracle、MySQL、PostgreSQLでも同様のことが可能だと思います。私はその仮定で間違っていますか？たぶん、彼らは「動的な」コミット文を許可しないでしょうか？Oracle、MySQL、PostgreSQLで同様のことができるかどうかを確認するために、SQL Fiddle（できればサンプルスキーマまたは他の誰かが作業している可能性のあるものではない）を自由に使用してください。そうでない場合は、単純な文字列の検出が機能する可能性があります。 さらに別の可能性 別のオプションがありました-これらのデータベースのいずれかを読み取り専用モードに設定する方法を知っている場合、そのモードでは何もコミットできませんが、それも機能します。そのモードで何もコミットできない限り、トランザクションの開始とトランザクション内でのコードの実行を許可する必要があります。それは可能ですか？ 更新 私が最近学んだこと-これは実際にはPostgreSQLの問題ではありません。トランザクションブロック内で発行されたコミットは、その同じブロックが最終的に（Postgresで）ロールバックされた場合には適用されないようです。Postgresの皆さん、ありがとう！ PhilのSO投稿へのリンクのおかげで、DEFERRABLE INITIALLY DEFERREDハックを使用してOracleを達成できると思います（コミットが発行されるとエラーがスローされますが、それを回避できます）。これはOracleに対処する必要があります。（ネストされたトランザクションがここで機能するかもしれないと少しの間考えましたが、Oracleがネストされたトランザクションをサポートしているようには見えませんか？とにかく、このように機能するものは見つかりませんでした）。 MySQLのソリューションはまだありません。ネストされたトランザクションを使用してみましたが、動作しないようです。右側のSELECT以外は許可しない、または各クエリの後にDBを削除/再作成するなど、MySQLのより抜本的なアプローチを真剣に考えています。どちらも良い音ではありません。 解決 したがって、SQL ServerとOracleについて説明したソリューションを実装しましたが、前述したように、これは実際にはPostgreSQLの問題ではありません。MySQLの場合、クエリパネルをselectステートメントのみに制限するというやや不幸なステップを踏んでいます。MySQLのDDLとDMLは、スキーマパネル（左側）で入力するだけです。これがあまりにも多くの古いフィドルを壊さないことを願っていますが、それは単にデータの一貫性を確保するために行わなければならないことだと思います。ありがとう！
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.