タグ付けされた質問 「database-tuning」

データベースパラメータまたはデータベースの物理レイアウトを調整することによって行われるパフォーマンスチューニング。

2
学習のためのデータベースチューニングの演習はどこにありますか?
開発者として、多くの場合、DBAはデータベースレベルでパフォーマンスの問題を解決する責任を負うため、クエリの診断、調整、リファクタリングなどの経験はあまりありません。 私は、テーブル、データ、クエリ、トリガー、SPなどが大量にあるデータベースを探しています。このデータベースには、意図的なパフォーマンスの問題があります。理想的には、これはMS SQLサーバー上にあります。 誰でもこの種のことを知っていますか?

4
特定のテーブルへの挿入が遅い理由を知るにはどうすればよいですか?
SQLテーブルでのINSERTには、さまざまな理由で時間がかかることがあります。 テーブル上のINSERT TRIGGERの存在 チェックする必要のある強制された制約の多く(通常は外部キー) テーブルの中央に行が挿入されると、クラスター化インデックスでページが分割される 関連するすべての非クラスター化インデックスを更新する テーブル上の他のアクティビティからのブロック 不十分なIO書き込み応答時間 ...私が見逃したものは何ですか? 特定のケースでどちらが責任があるのか​​をどのように確認できますか?ページ分割と非クラスター化インデックスの更新と他のすべての影響を測定するにはどうすればよいですか? (一時テーブルから)一度に約10,000行を挿入するストアドプロシージャがあり、1万行につき約90秒かかります。他のspidがタイムアウトするので、これは受け入れられないほど遅いです。 実行計画を確認しました。INSERTCLUSTERED INDEXタスクとFKルックアップからのすべてのINDEX SEEKSを確認しましたが、なぜ時間がかかるのか確かではありません。トリガーはありませんが、テーブルには少数のFKey(適切にインデックス付けされているように見える)があります。 これはSQL 2000データベースです。

2
MySQLはディスク上に一時テーブルを作成します。どうすれば止めることができますか?
ユーザーが現在遅いと感じるサイト(Moodle)を運営しています。私は、ディスク上に一時テーブルを作成するMySQLの問題を突き止めたと思います。created_tmp_disk_tablesMysql Workbenchサーバー管理で変数を見ると、その数は約50テーブル/秒で増加します。1日の使用後、created_tmp_disk_tables> 100kです。また、メモリは解放されていないようです。システムがほとんど使用できなくなり、MySQLを再起動するまで、使用量は増加し続けます。私はほぼ毎日それを再起動する必要があり、利用可能なメモリの約30〜35%を使用して開始し、80%で1日を終了します。 データベースにblobがなく、クエリを制御できないため、クエリを最適化することもできません。Percona Confirguration Wizardも使用しましたを使用して構成ファイルを生成しましたが、my.iniでも問題は解決しませんでした。 ご質問 MySQLがディスク上に一時テーブルを作成しないようにするには、何を変更すればよいですか?変更する必要がある設定はありますか?もっとメモリを投入する必要がありますか? MySQLがメモリを使い果たすのを止めるにはどうすればよいですか? 編集 slow_queriesログを有効にすると、クエリのSELECT GET_LOCK()ログが遅いことがわかりました。クイック検索の結果、PHP構成で永続的な接続が許可されていたことがわかりました(mysqli.allow_persistent = ON)。これをオフにしました。これにより、MySQLがメモリを消費する割合が減少しましたが、一時テーブルはまだ作成されています。 また、key_buffer sizeが十分に大きいことも確認しました。変数を見ましたkey_writes。これはゼロでなければなりません。そうでない場合、key_buffer_size.I have zero key_readsand zeroを増やすkey_writesので、key_buffer_sizeが十分に大きいます。 私は増加tmp_table_sizeし、max-heap-table-sizeテーブルがメモリに収まることができないことを示すことがありcreated_tmp_disk_tablesの増加として1024Mに。これで解決しませんでした。 参照:http : //www.mysqlperformanceblog.com/2007/08/16/how-much-overhead-is-caused-by-on-disk-temporary-tables/ 編集2 sort_merge_passesSHOW GLOBAL STATUS出力で1秒あたりの数が多い場合は、sort_buffer_size値を増やすことを検討できます。私はsort_merge_passes1時間で2つ持っていたので、sort_buffer_size十分に大きいと考えています。 参照:Mysqlマニュアル sort_buffer_size 編集3 @RolandoMySQLDBAの提案に従って、ソートバッファーと結合バッファーを変更しました。結果は下の表に表示されていますが、created_tmp_tables_on_diskまだ高いと思います。値を変更しcreated_tmp_tables_on_disk、1日(8時間)後にチェックして平均を計算した後、mysqlサーバーを再起動しました。他の提案はありますか?ある種のコンテナに収まらないものがあるように思えますが、それが何であるかを判断することはできません。 +---------------------+-------------+-------------+--------------------+ | Tmp_table_size, | Sort_buffer | Join_buffer | No of created | | max_heap_table_size | | | tmp_tables …

2
ユーザー認証(役割と権利)モジュールの設計
Delphi UIアプリケーションのバックエンドとなるMS SQL Serverデータベースのユーザー認証モジュールをモデル化しようとしています。基本的に、ユーザーが1つのグループにのみ所属するユーザーアカウントが必要です。グループは、「n」個の権利を持つことができます。 また、ユーザーがアプリケーション設定(たとえば、90日ごと)に基づいてパスワードを変更する必要があるため、パスワード履歴をデータベースに追加します。 また、ユーザーがログインおよびログアウトするたびにイベントを記録したいと思います。私はこれを将来の追加イベントに拡張するかもしれません。 以下に、私の最初のクラックを見つけます。これを行うのはこれが初めてなので、改善するための提案があれば教えてください。 役割ベースのセキュリティの追加属性とパスワードルール/有効期限の制約が必要ですか?

3
MySQL table_cacheおよびOpened_tables
MySQLでtable_cacheが小さすぎるかどうかを評価するためにOpen_tablesとOpened_tablesの比較を使用する人々を見てきました。ただし、Opened_tablesはアップタ​​イム全体で累積されるため、これは有効な比較ではありません。唯一の注意点は、おそらくOpened_tablesが失敗した場合にのみバンプされることです。ただし、1秒あたりに開かれるテーブルがまだ小さい場合でも、徐々に大きくなることはおそらく問題ではありません。 Open_tablesとOpened_tablesを比較することが有効でない場合、これに関する測定データを取得する別の方法はありますか? これはMySQL 5.0にありますが、バージョン間の違いも歓迎します。

2
SELECT TOP 1はクエリのパフォーマンスに悪影響を与えます。これを克服するdbaアクセス可能な方法はありますか?
運用アプリケーション(SQL Server 2014 Standardと通信するC#)には、以下のようなクエリがあります。ほとんどの場合、ミリ秒単位で実行されます。ただし、(特定の値の場合@Id)場合によっては非常に時間がかかり、1分ほどかかります。これはアプリのタイムアウトよりも長いため、ユーザーにとってアプリは失敗します。 "goes nuts"の場合、返される結果セットは他のすべてではないが多くの場合にそうであるように、正しく空です。 幸いなことに、これは実稼働環境と開発環境の両方で再現可能です。 開発者は、クエリから「TOP 1」を削除し、アプリが結果セットの余分な行を消費することを確認して、パフォーマンスの問題を解決すると言います。 クエリプランナーは、インデックスTOP 1が存在する場合はインデックスを提案しません。(開発中)。 クエリの変更とアプリの修正が進行中です。ロールアウトには時間がかかります。 私の質問:アプリが新しいクエリで変更される前に、この問題を克服するために、運用SQL Serverインスタンスをチューニングまたは微調整するDBAアクセス可能な方法はありますか? SELECT TOP 1 subscription_id FROM subscription AS sub JOIN billing_info AS bi ON bi.billing_info_id = sub.billing_info_id JOIN person_group AS apg ON apg.person_id = bi.person_id JOIN pplan ON pplan.plan_id = sub.plan_id JOIN product ON product.product_id = [plan].product_id …

2
SQL Server:大規模ページ割り当てのチューニングオプションを使用した人はいますか?
誰でもを使用するチューニングオプションを使用していTF834 large page allocationsますか。私はそれに関するMS記事を読んでいて、誰かがそれを使ってパフォーマンスの向上を見たのではないかと思っていました。注意すべき点、ヒント、落とし穴はありますか? サーバーは、Windows 2008 64ビット、128 GB RAM、4 CPU 8コアのハイパースレッド(合計64コア)SQL2005サーバーです。現在実行されているデフォルトのSQLインストールを使用するだけでなく、サーバーの仕様をより良く使用するようにサーバーを調整したいと考えています。追加のヒントは歓迎します。

3
C#VS SSMSから同じリクエストを実行すると、異なる実行時間が与えられます
このようなリクエストがあります SELECT [EstimateId], [CreationUserId], [EstimateStatusValueId], [LanguageId], [LocationId], [EstimatorUserId], [FilterUnitSystemTypeId], [EstimateNumber], [RevisionNumber], [CreationDate], [ModificationDate], [ProjectDescription], [IsBsdq], [ClosingDate], [ClosingTime], [ClosingUpdatedOn], [DeadLineDate], [IsReceived], [Inclusion], [Exclusion], [Misc], [Note], [WorkDeadLines], [Comments], [Validity], [PlansLocation], [PlansReceivedFrom], [Price] FROM [Estimate].[Estimates] ORDER BY [ClosingDate] ASC, [ClosingTime] ASC SSMSでこのクエリを実行すると、953msの実行時間が得られますが、C#でLinqクエリからこのクエリを実行すると、1813msの実行時間が得られます。 Linqクエリは「.Net SqlClient Data Provider」を使用し、EntityFramework(EDMXファイル)に対して発行されます。これは問題になる可能性がありますか? 同じデータベースの異なるコンテキストから実行されるリクエストの実行時間に大きな違いがある理由を誰もが知っていますか? 両方の要求のすべての実行計画を検証し、それぞれのクエリを満たすために同じインデックスを使用します。 C#リクエストの実行計画を確認するには、SQLプロファイラーを使用してShow Plan XMLイベントをトラップし、それをSSMSの1つと比較します。両方とも同じです。

1
多くのINSERTとbyteaの更新のためにPostgreSQLを最適化します
私たちが持っているもの(ソフトウェア): 基本構成のPostrgeSQL 9.3(変更なしpostgresql.conf) Windows 7 64ビット ハードウェア: インテルCore i7-3770 3.9 Ghz 32 Gb RAM WDC WD10EZRX-00L4HBAtaドライブ(1000Gb、SATA III) したがって、DB aproxにロードする必要があります。bytea列を含む100.000.000行、およびより単純な500.000.000行(LOBなし)。1つ目のテーブルには2つのインデックス(長さ13、19)があり、2つ目のテーブルには2 つのインデックス(長さ18、10)があります。各テーブルのID生成のシーケンスもあります。varcharvarchar 現在、これらの操作は、JDBCバッチサイズ50と並行して8つの接続で実行されています。次の図は、システム負荷を示しています。これはpostgresqlプロセスの負荷がゼロです。24時間のロード後、10.000.000行しかロードしていません。これは非常に遅い結果です。 以下のPostrgreSQL目的で、構成の調整について支援を求めています。 1)この量のデータを超高速でロードする場合、これは1回のみの操作であるため、一時的な構成になる可能性があります。 2)結合やソートを行わずに、インデックスによってこれら2つのテーブルに適度な数のSELECTを実行する本番モードの場合。

1
データ移動のため、NOLOCKでスキャンを続行できませんでした
SQL Server 2000を実行していると、これらのエラーのいくつかが毎晩発生します。 Could not continue scan with NOLOCK due to data movement このエラーをスローするクエリは、1ダースを超えるテーブルを結合する大きく複雑なクエリです。基礎となるデータは頻繁に更新できます。 文化的な「ベストプラクティス」は、過去にNOLOCKヒントを導入することでパフォーマンスが向上し、同時実行性が向上したことです。このクエリは100%正確である必要はありません。つまり、ダーティリードなどを許容します。しかし、これらすべてのロックヒントがあるにもかかわらず、データベースがこのエラーをスローする理由を理解するのに苦労しています。 誰もがこれにいくつかの光を当てることができます-穏やかに、私は実際にはプログラマーであり、DBAではありません:) PS:以下の修正を以前に適用しました:http : //support.microsoft.com/kb/815008

1
InnoDBテーブルのOPTIMIZE TABLEを安全に強制終了できますか?
kill 警告に関するMySQLのドキュメント: 警告 テーブルに対するREPAIR TABLEor OPTIMIZE TABLE操作を強制終了すると、MyISAMテーブルが破損し、使用できなくなります。そのようなテーブルの読み取りまたは書き込みは、再度(中断することなく)最適化または修復するまで失敗します。 MyISAMについてです。 OPTIMIZE TABLEInnoDBテーブルに対して実行されているプロセスを強制終了することも危険ですか?

1
一時データ用のPostgreSQLの最適化
非常に揮発性の高いデータを保持する整数型の100〜300列のテーブルがいくつかあります。データセットは1つまたは2つの主キーでキー設定され、更新が発生すると、データセット全体が削除され、新しいデータが1つのトランザクションに挿入されます。データセットのサイズは通常数百行ですが、極端な場合には最大数千行になることがあります。更新は1秒に1回行われ、さまざまなキーのデータセットの更新は通常ばらばらであるため、テーブルの削除と再作成は実行できません。 そのような負荷を処理するようにPostgresをどのように調整しますか?違いがある場合は、最新かつ最高のバージョンを使用できます。

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