「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho
ずっと前から積ん読状態だった「SQLアンチパターン」を読みました。 何年積んでたか分からないSQLアンチパターン読み終わったー。噂に違わずいい本ですねー。もっと早く読むべきだった。— @ketancho (@ketancho) 2018年3月6日 噂通りとても良い本で、まさに「エンジニアとしての血肉本」と言えます。1, 2年目の頃に読んでおくべきだったなーと少し後悔しています。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る 読んで終わりだと身につかないと思うので、自分なりのチェックポイントを言語化しておこうと思います。長くなってしまったので、章ごとに4つに分けたいと思います。この記事はその第一弾と
MySQLクエリパフォーマンス改善簡易まとめ - Qiita
数年やってないと記憶の彼方に飛んでいきそうだったので、MySQLのクエリ改善方法のテンプレを自分用に明記。 スロークエリを除去する事。 初めはとにかく観察。スロークエリを出力させて、観察する。 indexが効かないクエリを排除する。 indexが予期できない条件分岐によるクエリを廃止する。 場合によってはソートをさせない。コード側でソートさせる。 JOINをわざとさせないのも一つの手。後にDB分離レベルのシャーディング等が発生する可能性のあるようなシステムでは、JOIN禁止にする事は決して間違ってはいない。 indexを必ず効かせる レコード数に応じて、割当たるindexが異なることがあるので、必ず同じデータ数か実際の運用環境で検証すること。 但し、indexを増やし過ぎると、挿入時に更新対象が増えるため、必要最低限にすること。 explain してindexを確認する 特に注目しなければ
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub｜Webエンジニアのキャリアを考える！
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
「絶対要らないハズだけど、なかなか削除できずにいるもの」を対応した小話 | メルカリエンジニアリング
はじめましてこんにちは。SREの@masartzです。 私は最近joinしたのですが、今回は本番環境に古くからあるテーブルの掃除作業をした案件をご紹介します。 tl;dr; 本番の住所情報テーブルを消したけど問題なかった話 絶対要らないハズだけど、なかなか削除できずにいるもの を対処する話 本番環境の住所情報テーブルをdropするまでの作業 今回、本番環境の住所情報テーブルをdropしました。 と言っても、事故でもうっかりでもなく、既に使われていなかったものの整理という作業でした。 何故使われていなかったかというのは、メルカリの住所情報の保持の仕方の変遷が関係しています。 初期にはuser情報と住所情報は1対1の関係でした。イメージとしては以下です。 CREATE TABLE IF NOT EXISTS users ( id INT UNSIGNED NOT NULL, name VARC
Javaエンジニアに知ってほしいRDBアンチパターン その3 について話して来た #jjug_ccc - そーだいなるらくがき帳
Javaの国内最大カンファレンス、JJUG CCC 2017 springで登壇してきました。 僕の中で先週のオープンセミナー岡山の熱がまだ収まらぬ中の登壇だったのですが、多くの方に聴いていただけて嬉しかったです！ その時の資料がこちら。 RDBアンチパターンについてはPHPカンファレンスやYAPC:Kansaiでも話をしましたが、今回は別バージョンです。 soudai1025.blogspot.jp soudai.hatenablog.com あのときはWeb系の人向けに話をしましたが、今回はエンタープライズな業務系の人向けです。 業務系は僕の印象では制約だったり、RDBの機能を有効活用してる印象があるのですが、逆に過剰になっていることが多い印象があります。 また論理IDなどデータ量が少なかったり、アプリの改修が少ないから死ななかっただけの設計も多く見られる印象です。 そういう点を今回お
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
datapumpを使用するための準備手順 ｜ Oracle使いのネタ帳
datapump とは datapump は、oracle10g より導入されたユーティリティであり、データベースに 格納されているデータやオブジェクトのメタデータのインポートやエクスポートが可能。 従来の export/import ユーティリティと比較すると、処理性能が向上している。 「データポンプ」や「データパンプ」と呼び方はまちまちだが、 Oracle のマニュアルで、カタカナ表記の場合は「データポンプ」となっているので、 正確にはデータポンプなのだろう。 Oracle エンジニア同士の会話では、 「データパンプ」の方が多いけれども。 Oracle9i まで主力であった export/import ユーティリティは、 11g 以降でも利用することは可能だが、非推奨となっている。 将来的に廃止される運命にあるため、これから使うなら datapump を利用した方がよい。 バージョンア
Oracle10g Cost Base Optimizerにまつわる検証 その１１ - InsightTechnology 旧ブログ
＜Oracle10g Cost Base Optimizerにまつわる検証 その１１＞ ～DBMS_STATSの変（？）～ ペンネーム：りん ■おさらい 先週は、コストの計算をしていましたが、I/Oしかフォーカスしていませんで した。つまり、I/Oのコストが算出されただけでした。 GATHER_SYSTEM_STATSを取得して、CPUのコストも… なんて書いていたわりに、CPUが入っていないのはおかしな話です。 では、GATHER_SYSTEM_STATSで取得したCPUSPEEDはどう使われるのでしょうか ■環境 Redhat Linux Advanced Server 2.1 Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 ■検証 先週書いた計算式をまとめると ((Single Block Read x SREADT
複合インデックスの落とし穴 | がっとな日々 | ガットコンピューター
複合インデクスとは、テーブルの複数のカラムを組み合わせて１つのインデクスとするものです。 たとえば、以下のようなカラムを持つ「従業員マスタ」というテーブルに「姓」と「名」で１つのインデクスを作成することを指します。 従業員マスタ 従業員番号 姓 名 性別 住所 生年月日 入社年月日 会社 所属部門 職位 レコード作成日時
OTN Japan マニュアル
お探しのものを見つけるために、以下の項目を試してみてください。 キーワード検索のスペルを確認してください。 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。 新しい検索を開始してください。
門外不出のOracle現場ワザ 第2章 | Oracle 日本
門外不出のOracle現場ワザ 日本オラクル株式会社 コンサルティング統括本部テクノロジーコンサルティング本部 小田 圭二(おだ けいじ) 第2章 万全の予防とテストで致命的トラブルを回避するOracle管理 転ばぬ先の杖 日本オラクル株式会社 コンサルティング統括本部テクノロジーコンサルティング本部 小田 圭二(おだ けいじ) 目次 Part1 監視／検知／対応の最適解 運用時の大トラブルを防ぐポイント 障害の積極的な予防 障害発生の早期検出と初動対応 パフォーマンス障害切り分けの準備 データ損失を防止するために システムの重要性に応じた運用計画を Part2 パフォーマンステストにおける正しい環境作りと統計情報の分析 Part3 障害テストにおける5つの注意点と7つの障害箇所別テスト方法 Part1 監視／検知／対応の最適解 運用時の大トラブルを防ぐポイント システムは、一度構築
データベース・アプリケーションでの索引の使用
4 データベース・アプリケーションでの索引の使用 索引は表およびクラスタと関連付けられているオプション構造で、これによりSQL問合せをより迅速に実行することができます。このドキュメントで、索引の使用により、索引がない場合よりも高速に情報を検索できるように、Oracle Databaseの索引は、表データへのより高速なアクセス・パスを提供します。索引は問合せをリライトすることなく使用できます。結果は同じですが、より高速に得られます。 この章は、次の情報を補足します。 『Oracle Database概要』の索引と索引構成表の説明 『Oracle Database管理者ガイド』の索引の管理に関する情報 『Oracle Databaseパフォーマンス・チューニング・ガイド』の索引およびクラスタのパフォーマンス向上または低下方法の説明 内容は次のとおりです。 索引の管理のガイドライン 索引の管理
「Oracle SQLチューニング講座」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
Oracle SQLチューニング講座（13）： REDOログ・ファイルの設定で更新処理をチューニング 本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状で広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。（編集局）（2005/6/21） Oracle SQLチューニング講座（12）： 更新／挿入／削除のSQLを高速化する3つの技とは？ 本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Life with IT
サービス終了のお知らせ
Amazon.co.jp: 絵で見てわかるOracleの仕組み: アーキテクチャと動作を徹底図解: 小田圭二: 本
https://blogs.oracle.com/oracle4engineer/post/entry/oraclefaq
ALL_INDEXES
OTN Japan - 404 Error
リレーショナル・データベースの世界