14:00多くのデータベースアプリケーションでは、どこかの時点で必ずパフォーマンスが検討課題になります。Anywhere」およびデータベース全般に関する英語ドキュメントを翻訳する形で提供しています。Anywhere自体は完全に日本語化されていますのでご安心ください。パフォーマンス分析は一筋縄ではいかないことが多いのですが、それは可変要素が非常に多く、ハードウェアの特性、ワークロード、物理的データベース設計、およびアプリケーション設計など、あらゆる要素を検討する必要があり、またこれらの要素の間にトレードオフや副作用が存在するからです。これが正解、と言えるものが見つからないのが普通です。Anywhereを遅くする方法)」という記事を書きました。これは今までに読んだ記事のなかでも最大のお気に入りの1つです。Breckはこの記事の中で、パフォーマンスの低下につながる38の異なるデータベース設計、アプリケーション設計、およびサーバ構成設定を列挙しています。この記事を受けて、今後しばらくは「データベースアプリケーションのパフォーマンスにおける7つの大罪」という少々生意気なタイトルの下に、特に説明する値打ちがあると思われる7つの具体的な問題について詳しく書いていこうと思います。「データベースアプリケーションのパフォーマンスにおける7つの大罪」とは次のとおりです。お粗末な物理データベース設計(スキーマ設計問題、テーブルの列の順序、インデクシング、データページサイズ)ロックの競合(ホットロー問題または上位のANSI分離レベルでの実行による)反復的なネスト構造の実行(ネストされたクエリ、ユーザー定義関数、クライアントサイド結合など多数)単一クエリでの処理量が必要以上に多い(アクセス/取得するデータ量が膨大、またはクエリが複雑すぎて最適化が難しいなど)効率の悪いクライアント/サーバインタラクション(フェッチ設定、ワイド挿入またはワイドフェッチ、プリペアードステートメントの使用、同一サーバからの同じ情報の再フェッチなどが要因として考えられる)SELECT文の最適化目標の選択ミストランザクションモデルの選択ミス(特に自動COMMITの使用)次回の記事では、アプリケーションのパフォーマンスにマイナス影響を与える物理データベース設計のトピックを取り上げます。連載通知を行うには会員登録(無料)が必要です。会員の方はログインを行ってください。してクエリ・オプティマイザなどの開発をリードしている。圧縮・解凍UNIX基本講座@CodeZine『CodeZine(コードジン)』の公式アカウントです。【NEW】デブスト2019デブサミ2019福岡・関西デブサミ2019夏デブスト関西デブサミ2019×ログインEメールパスワード※旧SEメンバーシップ会員の方は、同じ登録情報(Eメール&パスワード)でログインいただけます。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。