技術情報
Dec15
これからはハードウェア技術がわかるDBAに
INSIGHT OUT 2011にお越しいただいた方々、ありがとうございました。
"Open Hardwareの夜明け"で、データベース技術者はこれから、
本当にエキサイティングな経験が出来ると思います。
我々も検証で得たナレッジを随時公開させていただきます。
弊社の製品もまもなくリリースできると思います。↓↓↓
世界一速いデータベースを 手の届く価格で！
[INSIGHT OUT 2011] c14 openハードウェアの夜明け前(ssd infiniband検証) View more presentations from Insight Technology, Inc. ...
Dec08
[INSIGHT OUT 2011] C22 RAC buffer sharing の仕組み
こんにちは。
先日開催された INSIGHT OUT 2011 のセッションで使用した資料が
アップロードされましたのでご案内します。
ゆっくり見ていってください。
[INSIGHT OUT 2011] C22 RAC buffer sharing の仕組み(yamashita) View more presentations from Insight Technology, Inc.
...
TPC-Cを遅くしてやったぞ
昨日失敗した原因は、セッション数が少なすぎて目視できるほどパフォーマンスに違いが出なかったからのようです。今日はセッション数を100から500に増やし、特にlatch: shared poolに焦点を絞って見てみました。
まず、latchの回数を確認するために以下のSQLを投げてみます。
[sql]
select * from (
select event, sum(total_waits) num
from v$system_event
where event like...
TPC-Cを遅くしてやりたい！
PIEXの新機能、Crunch Viewerのテストを兼ねて、DBをいぢめていろんなWAITを確認してみる、というのをやっています。
テスト環境ではSSDをストレージとして使用し、HummerOraとSwingBenchという2つのベンチマークツールからTPC-H(DSS:意思決定システムを想定したベンチマーク、ただしSwingBenchのはTPC-Hもどき)を実行しながら変なSQLを投げてみたり、SGAを小さくしてみたりしています。たとえば、TPC-Hを実行しながら以下のSQLを実行してORA-04031を...
Aug11
Audit Trail についての検証 [電子書籍版]
「 おら！オラ！Oracle 」 一番人気コンテンツ
"Audit Trailについての検証" 全8回分のPDF版。
Audit Trailの機能、設定方法の解説からはじまり、
TPCベンチマークを使用したパフォーマンステスト、
ファイングレイン監査の検証と、Audit機能を徹底解剖。
内容はそのまま。本当にまとめただけですが、
PC、タブレット端末、スマートフォンで、
通勤、おやすみ前、食べ歩きのお共に☆
Audit Trailについての検証 [電子書籍版]
[email-download download_id="35" contact_form_id="3"] ...
Aug03
エクスポート/インポートによる基幹データベースの移行3
■計画・実行編
今回の移行は約4か月にわたる立派なプロジェクトでした。結果的に大成功に終わったプロジェクトでしたが、それはマクロミル様のプロジェクト・マネージャ（PM）と関係者の綿密な連携による勝利でした。
●実際のスケジュール
9月：移行スクリプト作成
10月上旬：新環境構築
10月下旬：第1回移行リハーサル
11月：新環境でのアプリケーション動作確認、負荷テスト
12月上旬：第2回移行リハーサル
年末年始：本番移行
前回紹介した移行用スクリプトは最終的には80本以上になりましたが、これらは9月に集中的に作成しました。
そして、10月に新しい環境でDBサーバを構築し、第1回の移行リハーサルを実施しました。
今振り返ってみると、2回のリハーサルを計画・実行したのは非常に大きな成功要因だったと思います。
1回目のリハーサルでは必ず予期せぬ問題が...
エクスポート/インポートによる基幹データベースの移行2
■準備フェーズ編
今回は、データベース移行の準備フェーズで、どのような点に留意したかを述べたいと思います。
前回は「移行方法はテーブル単位のエクスポート/インポートを採用する。」という決定に至る過程を紹介しましたが、次のような課題を挙げました。
● テーブル単位エクスポート/インポートの課題
移行対象オブジェクト数は3万以上。（DBA_OBJECTSによる調査）
全テーブル、インデックスを漏れなく移行すること。
各テーブルにおいてデータの欠損がないこと。
テーブル、インデックス以外...
エクスポート/インポートによる基幹データベースの移行1
● はじめに
巷ではOracle12gがいつリリースされるのかという話題が出始めている今日この頃ですが、国内にはまだまだ多くのOracle9iが現役でバリバリ動いているとも聞いています。
安定しているシステムをわざわざ変更する必要はない。
アプリケーションの動作確認等コストがどれくらいかかるかわからない。
移行に伴うサービス停止や予期せぬトラブル等のリスクが怖い。
10gからルールベースが廃止されたので、実行計画が変わるのは困る。
のような理由や、昨今の景気動向もあってなかなかデータ...
Jun29
OracleをIn-Memoryで使うためには2
（前回の続き）
DB_KEEP_CACHE_SIZEを可能な限り大きく設定した場合のインデックスレンジ検索の振る舞いを見てみます。
主キー項目であるKEY列に与える条件を調整して戻り行数を変化させてみました。（注目ポイントをハイライト表示させています。）
[sql highlight="3,14,20,27,38,48,54,61"]
SQL> select * from LARGE_TBL_KEEP where key < 76501;
76500行が選択されました。
実行計画
----------------------------------------------------------
Plan hash value: 3698628736
-------------------------------------------...
Jun24
OracleをIn-Memoryで使うためには
あるお客様から「頻繁にアクセスされる大きな（というより巨大な）テーブルをメモリ上に常駐させて物理I/Oを削減したいのだけど。」という要望を受けました。
通常、Oracleは（9i以降であれば） 20ブロックもしくはv$buffer_pool.buffers / 50のいずれかより大きなテーブル（long table）は、全件検索時にDB_FILE_MULTIBLOCK_READ_COUNT分のブロックを読み込みながら、どんどんメモリ（キャッシュ）から追い出してしまいます。これは限りあるメモリ資源を有効に活用するための仕組みです。
従って、この場合SGAを単純に大きくすればよいというものではありません。明示的に”KEEP”バッファ・プールを指定して、当該テーブルの属性も”KEEP”に設定しage outされないようにする必要があります。
KEEPバッファ・プールというのは、...