オンラインREDOログ設計 - とあるSIerの憂鬱
オンラインREDOログ(以降は単にREDOログ)の設計について考えた事、Oracleがマニュアルで示している設計方針をメモ。 REDOログ設計で決めること REDOログ1ファイルのサイズ REDOロググループの数 REDOロググループ内のメンバー数 REDOログの物理配置 考える観点 性能 信頼性 コスト Oracleがマニュアルで示している設計方針 『Oracle® Database管理者ガイド 11g リリース2 (11.2) 12.REDOログ管理』 『Oracle® Databaseパフォーマンス・チューニング・ガイド 11gリリース2(11.2) 4.1.3 REDOログ・ファイルのサイズ指定』 REDOロググループ内のメンバー数 あまり悩まずに決まる設計部分。 1個か2個以上か 1個 2個以上 性能 1個にのみ書くため最もI/O量は少なく速い。アーカイブ速度は理論的には2個以上
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
