[B! チューニング] sosukのブックマーク

DB管理者がいますぐ確認すべき3つの設定

DB管理者がいますぐ確認すべき3つの設定：真・Dr. K's SQL Serverチューニング研修（4）（1/3 ページ）管理者の力量があらわれる3つの設定前回、設定された値を見るだけでDB管理者の力量が見える、ということに触れました。今回も必ず押さえておきたいパラメータを、なぜそのように設定すべきかという理由と併せて解説していきます。設定すべきポイントは大変シンプルです。 temp dbの数をCPUコア数にあわせよ x64環境なら「メモリ内のページロック指定」を変えよ OLTP環境では、並列処理の最大限度（Max DOP）はCPUコア数の「4分の1」に設定せよもちろん、これだけ変更すれば、その部分における最低限のチューニングは完了します。しかし1つ上のエンジニアを目指すなら、その理由まできっちり知っておくべきでしょう。その理由を知ることで、監視ツールや動的管理オブジェクトが発する「

sosuk 2018/09/25

リンク

パフォーマンスの監視とチューニング - SQL Server

適用対象: SQL Server Azure SQL Database Azure SQL Managed Instance データベースを監視する目的は、サーバーのパフォーマンスを評価することです。適切な監視には、現在のパフォーマンスのスナップショットを定期的にキャプチャして問題の原因となっているプロセスを特定したり、長期にわたって継続的にデータを採取してパフォーマンスの傾向を追跡する作業が必要です。データベースパフォーマンスの継続的な評価は、応答時間を最小限にし、スループットを最大限にして、最適なパフォーマンスを実現するために役立ちます。パフォーマンスを最大限に高めるには、効率的なネットワークトラフィック、ディスク I/O、および CPU 使用が重要です。アプリケーションの要件を十分に分析し、データの論理構造と物理構造を理解し、データベースの使用状況を評価し、競合する処理

sosuk 2018/07/20

リンク

システム基盤 AtlasBase®｜BIPROGY株式会社

企業情報企業情報トップ BIPROGYについてトップメッセージ会社概要 Purpose,Principles Vision2030・経営方針（2024-2026）コーポレートブランドグループ会社拠点所在地組織図役員一覧企業理念企業行動憲章役職員行動規範 PDF 調達・購買に関する指針等について BIPROGYグループのAI倫理指針 PDF BIPROGYグループの歴史 BIPROGYの企業活動サステナビリティ広告宣伝活動イベント／セミナー出版物デジタルメディア BIPROGY TERASU 別ウィンドウで開く BIPROGYバドミントンチーム東京ディズニーランド「エレクトリカルパレード・ドリームライツ」東京ディズニーシー「フォートレス・エクスプロレーション」 BIPROGYの研究活動 BIPROGY総合技術研究所 Techno logy Foresight

sosuk 2018/07/20

リンク

PostgreSQLの実行計画を読み解くための参考資料集 - ぱと隊長日誌

はじめに PostgreSQLは商用DBに比べて書籍が少なく、まとまった情報が入手しにくいです。また、有志の方がPostgreSQLに関する資料を公開していますが、散在しており、せっかくの有益な情報にアクセスしにくい状況にあります。そこで、本エントリではPostgreSQLの実行計画に焦点を絞り、公開されている有用な資料（書籍含む）をまとめました。読み返したい資料を探しやすくするため、内容のポイントも併せて紹介してます。本エントリをきっかけに、これらの資料がさらに活用されることを願っています。前提各資料の前提としているPostgreSQLのバージョンは異なることにご注意ください。調査対象のPostgreSQLのバージョンが異なれば、状況は変わっているかもしれません。各資料には内容の重複があり、ほぼ同一内容の場合もあります。重複している内容についてはポイントから割愛することがありま

sosuk 2017/09/22

リンク

パフォーマンスセラピー / Oracleのチューニングの基礎知識を身につける

システムのチューニングは、非常に複雑な作業です。設計、開発段階におけるチューニングから、運用開始後の継続的な監視の結果、必要となるチューニングなど様々です。Oracle RDBMSの具体的なチューニング方法に入る前に、チューニングにおける基礎知識を習得します。

sosuk 2017/02/16

リンク

SQLチューニング～お手軽に使えるヒント句まで - Qiita

ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら全般的に共通の考え方で対応できると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく、またインデックスを乱立すると複数の条件がある時などにオプティマイザが誤作動を起こす要因ともなります。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。基本的にルールベースと違いコストベースになるのでオプティマイザによって作成される実行計画が望み通りの計画になっているのかを見ながらチューニングしていく必要があります。今まで見てきた遅いSQLはとんでもない結合順や使用されるインデックスがなんでここから？といった実行計画になっていた事が大半でした。そういう時に正しい実行計画をオプ