Oracle の B*Tree インデックスの内部構造についてお勉強中（その１）
お仕事のデータベース一式のリース切れ間近ということで、リース延長で耐えることができるのか、それともシステム更改が必要なのかを見極めるため、最近はデータベース周りのチューニングばかりやってます。 当初設計時に、５年間持つ設計をしたのですが、流石に５年目にもなると予定とはそれなりに乖離が発生するものです。テーブル＆インデックス設計をユーザ向けの処理をとにかく高速に処理できるように設計したので、ユーザ向けの処理は速度的に全然大丈夫なのですが、データの肥大化によるバッチ処理のパフォーマンス劣化が顕著です。単純にストレージと CPU パワーが足りていないのでしょう。 しかしながらチューニングの余地はまだまだ十分にありそうです。バッチ向けの最適化を図ることにしました。うまくいけば来年度どころか、後数年はリース延長で延命できるかもしれません。 今回実施したチューニングの１つのポイントとして、バッチ処理向
(続）Oracle データベース復旧手順書とフルバックアップスクリプト
前エントリ Oracle データベース復旧手順書とフルバックアップスクリプト の続きです。 以下のフローチャートの各ステップで実際にコマンドラインおよび SQL *Plus で入力する SQL 文について説明を行います。基本的にこのエントリにページ内リンクを使ってコマンドを実行していくだけでデータベースが復旧できるという超リカバリ術になります。 テスト環境構築を構築するスクリプトも用意しました。dbca で作成した雛形です。 → create_db_scripts.zip 動作確認しながらバックアップ＆リカバリの検証をしてみたい方は、Linux 上の oracle 10g/11g がインストールされている環境で、ダウンロードして圧縮ファイルを展開して testdb.sh を実行してください。テストデータベースが作成されます。既に何かしらの Oracle データベースが動作している環境ではど
JavaScript の要素追加・変更で innetHTML と DOM の速度検証
ちょっと昔に散々でまわったネタなんですけど・・・まぁ自分への備忘録っつーことで。 JavaScript でごにょごにょ動的に見た目を変更する社内ツールがあります。自分が作ったヤツなんですが、最近どうにも動きがモッサリしてきました。解析するまでもなく遅い原因は DOM で要素を追加・削除を大量にやっているのはわかっています。だいぶ前に DOM と innerHTML のどっちが高速化ってのが話題になった時期がありましたが、僕の経験（技を何も使わずに単純に DOM 操作を書く場合。というか普通の人の書き方がココに当てはまると思う。）では圧倒的に innerHTML が高速な場合が多いです。 ※innerHTML vs DOM ネタはこの辺が参考になります。 Javascript - Benchmark - W3C DOM vs. innerHTML 最速インターフェース研究会 :: 日本語テキ
HTML - meta タグの仕様詳細まとめ :: Drk7jp
前エントリ - Internet Explorer のイメージツールバーを無効化する meta タグ で予告したとおり meta タグについて生まれて初めてまじめに調べてみました。改めて調べてみると知らなかったこと満載です。っていうか Web エンジニアたるもの一度は W3C勧告 くらいは一通り目を通しておかなくてはダメだなと思ったりしました。面倒なくらい分量があるけど。ひとまず meta タグ情報としての自分にとって永久保存版まとめという位置づけです。 まずは参考になったサイトの紹介から。 W3C勧告HTML4.01 :: The global structure of an HTML document W3C勧告HTML4.01 私的日本語訳 :: The global structure of an HTML document(ja) rfc2616.txt Another HTML
ワンランク上の負荷対策を Web アプリに実装するには・・・(Sledge編)
最近、お仕事で悩ましいのがデータベース負荷。結局のところ、Web サービスでボトルネックになるのは、バックグラウンドの ＤＢ 処理。特にどうしようもないのが、更新系リクエスト。つまりはマスターＤＢ。 既に多くのところが採用している構成と思いますが、MySQL とかでよくやる手段といえば、 参照系は、レプリケーション機能を使って参照系ＤＢを用意して負荷分散。マシンを増やせば負荷に対応可能。 更新系のクエリーだけは、できる限り高スペックなマシンを用意してマスターＤＢを構築して一手に引き受ける。増設困難で悩ましい。 もうちょい頭をひねれば、機能毎にマスターＤＢを分散させたり、ユーザ ID とかでパーティショニングしたりと、アプリ層で振り分ける。MySQL に限らず、Oracle とかでも同じようなことが言えます。 で、マシン負荷を監視という運用業務が必須な日々を送っていた（いや、実際にはPJのメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
