キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると
2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster（以下、Oracle RAC）でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか？ 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ
SQLチューニング・アドバイザによるデータベースの事前チューニング
スクリーンショットの表示 このアイコンの上にカーソルを置くと、すべてのスクリーンショットが表示されます。 各項目に関連するスクリーンショットのみを表示する場合は、それぞれのアイコンの上にカーソルを置いてください。 概要 トピック・リストに戻る Oracle Enterprise Managerの新機能であるSQLのチューニングおよび診断機能の特長 Automatic Workload Repository(AWR)は、問題の検出や自己チューニングなどを目的とするパフォーマンス統計を収集、処理、および管理します。 Automatic Database Diagnostic Monitor（ADDM）は、Oracleシステムの診断やチューニングに必要な労力を軽減します。 SQLチューニング・アドバイザの機能を使用して、SQL文を素早く効果的に最適化できます。 データを診断する監視の完了後、パフ
ダイレクト・パス・インサート - オラクル・Oracleをマスターするための基本と仕組み
ダイレクト・パス・インサート （ダイレクト・ロード・インサート） ダイレクト・パス・インサートとは、データベースバッファを経由せずデータファイルへ 直接データを落とし込むという点から、ある特定条件下で非常に優れた処理方法である。 データベースのバッファ処理を経由しないことで高速に処理でき、バッファから他のキャッシュを追い出すことによるキャッシュヒット率の低下を防ぐこともできる。 高速に大量データをインサートさせるための手法 ダイレクト・パス・インサートによる高速のインサート処理にはトレードオフがあるが脅威的な速さを誇る。 数百万件オーダのデータの投入するのに数分とかからない(レコードサイズ、スペックに左右はされる) 通常のパスのローディングに比べて 数分の1 程度の時間で投入できる。 NOLOGGING 状態の場合 REDO ログが出力されない。（高速にはなる一方でフルバックアップするまで
チューニングが必要なSQLを洗い出す
動的パフォーマンスビューを使用したSQLの洗い出し SQLの洗い出しのために使用する動的パフォーマンスビューは、主にV$SQL、V$SQL_TEXT、V$SQL_PLANの3つで、これらは共有SQL領域に保持されているSQLの情報を表示します。この共有SQL領域は、SQLを再利用するための情報がキャッシュされる領域となります。実行されたSQLの情報は必ずこの領域にキャッシュされますが、空き領域が不足した場合、新しいSQLのために、実行頻度が低いSQLの情報が追い出されてしまいます。そのため、この方法は、これまで実行されたすべてのSQLの情報を取得できるわけではない点に注意してください。 必要な情報は、直接SELECT文で確認することもできますし、また、一部の情報は、Oracleが標準で提供しているSTATSPACKユーティリティを使用することでも取得可能です。STATSPACK自体の説明に
文キャッシュ
22 文キャッシュ この章では、Oracle Java Database Connectivity（JDBC）拡張要素である文キャッシュの利点と使用方法について説明します。 この章では、次の項目について説明します。 文キャッシュについて 文キャッシュの使用方法 注意: Oracle9iリリース2（9.2）以上では、Oracle9iリリース1（9.0.1）でサポートされていたApplication Program Interface（API）にかわり、Oracle JDBCによって、新しい文キャッシュ・インタフェースと実装が提供されています。以前のAPIは廃止されています。 文キャッシュについて 文キャッシュにより、繰り返しコールされるループやメソッドなどで何度も使用する実行文がキャッシュされるため、パフォーマンスが向上します。JDBC 3.0では、文キャッシュ・インタフェースが定義されてい
SGAに起因するパフォーマンス障害を発見する
共有プールは全体と使用目的を意識して設定する 共有プールはライブラリ・キャッシュとディクショナリ・キャッシュとして使われる領域で、初期化パラメータファイルのSHARED_POOL_SIZEパラメータで設定されます。2つの用途の合算でメモリが消費されるため（比率は稼働中のインスタンスによって変動します）、それぞれがどのように使用されているか判断して、共有プールのサイズの適合性を確認します。まずは共有プール全体のサイズを確認し、全体として適正かどうか判断します。その後、使用目的（ライブラリ・キャッシュ、ディクショナリ・キャッシュ）ごとに、データベース・バッファ・キャッシュと同様にヒット率を確認し、最適な共有プールサイズを探っていきましょう。 共有プール全体のサイズを確認 V$DB_OBJECT_CACHEは、ライブラリ・キャッシュ内にキャッシュされるデータベース・オブジェクトを示します。オブジ
障害発生！ 問題切り分けはスピード勝負
Oracleのパフォーマンス障害に直面したら、この6つのステップに分類した内容の順に確認を行うことで、効率的に問題解決に近づくことができます。今後は上記のステップに沿って解説していきます。 第1ステップ CPU／メモリの監視 Oracle障害克服の第1ステップはCPU／メモリの監視です。つまりOSマシンが正常に稼働している状態であるかを確認します。Oracleシステム本体だけでなく、OSやメモリチューニングもサーバ稼働には重要な要素となのです。今回はWindows系OSとUNIX系OSでCPU／メモリの監視を行う作業を説明します。 Windows系のOSでは、リアルタイムで継続的に情報を取得するためにはツールや作り込みが必要ですが、ここではOS付属のツールを使った例を紹介します。UNIX系のOSはCPU／メモリ情報を取得するコマンドが用意されています。 Windows系OS 【スタートメニ
＠IT：Oracle SQLチューニング講座（5） SQLチューニングの基盤となる統計情報
本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状で広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。（編集局） 連載目次 前回「チューニングが必要なSQLを洗い出す」では、動的パフォーマンスビューを使用してチューニング対象となり得るSQLを洗い出す方法を説明しましたが、チューニングを行うためには、SQLの実行計画など、より詳細な情報が必要となります。今回は、これらの情報を取得する方法、また収集した情報の分析方法について説明していきます。 SQL詳細情報の取得 SQLチューニングを行う際に重要となる情報としては、SQLの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OTN Japan マニュアル
OTN Japan - 404 Error
サービス終了のお知らせ
パフォーマンスセラピー / Oracleチューニング講座
OTN Japan - 404 Error