“Scene25 – SGA: allocation forcing Component growth”...
「NoSQLはソーシャルメディアのようなネットアプリケーション向けであり、企業内のデータベースとしては向かない」。これまでNoSQLデータベースは一般にそう思われていました。 しかしオラクルは今月、サンフランシスコで開催した「Oracle OpenWorld 2011」でビッグデータ市場への参入を表明。製品として、企業向けデータベースとしてキーバリュー型データストア「Oracle NoSQL Database」と「Apache Hadoop」を搭載した「Oracle Big Data Appliance」を発表しました。 オラクルは企業が使うデータベースとしてNoSQLやHadoopをどのように位置づけようとしているのでしょうか? 昨日10月25日に都内で開催された日本オラクル主催のイベント「Oracle Database/Exadata Summit」において、米オラクルでデータベース製
本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状で広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。(編集局) 連載目次 パフォーマンス・チューニング概要 前回「パフォーマンス向上の最短コースを知る」で説明したように、SQLのチューニングはOracleインスタンスやデータベースの構成などにも密接にかかわっています。すでに基本的な知識をお持ちの方も大勢いらっしゃると思いますが、それらの知識を「パフォーマンス」と結び付けて考えることが重要なポイントです。 SQLによって取得されるデータが、実際にはどのような形式でファイルの
Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。(編集局) 本連載ではOracleの挙動に問題を発見したとき、どうやって原因を特定し解決策を導き出すかについて解説してきました。最終回となる今回は、領域とディスクに関する障害克服のテクニックを紹介します。 データファイルの物理構造と論理構造 Oracleがデータファイルの内部をどのように利用しているのか、その構造を理解するのは領域の問題解決には欠かせません。 Oracleはデータを階層構造によって管理しています。最上位にある「データベース(Database)」とは、
SQLを実行すると、たまにインデックスを使ったほうが高速であるにもかかわらず全表スキャンが選択され、パフォーマンスが振るわないということがあります。 こういった現象の一因には、オプティマイザがキャッシュ効率を考慮せずに常にI/Oが発生するものとしてコスト計算を行っているということがあるようです。 (インデックスはバッファ・キャッシュに存在する可能性が高いため、実際には見積もりコストよりも高速にアクセスできるケースが多い) このような現象が頻発する場合、OPTIMIZER_INDEX_CACHING、OPTIMIZER_INDEX_COST_ADJ という初期化パラメータの設定を調整すると、インデックス・スキャンのコストを低く計算させ、全表スキャンよりもインデックス・スキャンが選択される可能性を高めることができるようです。 OPTIMIZER_INDEX_CACHING インデックス・ブロッ
システムグローバルエリア(SGA)は共有メモリでありORACLEのサーバープロセス間で 共有される。 メモリにはデータのキャッシング、SQL文の解析結果のキャッシュ等が行われ、 処理を迅速に行うことを目的としている。 適切なメモリを確保しておかなければパフォーマンス劣化につながる。 SQL>SELECT * FROM V$SGASTAT; POOL NAME BYTES ------------- ---------------------------- ---------- fixed_sga 73888 db_block_buffers 524288000 log_buffer 163840 shared pool free memory 390924 shared pool miscellaneous 713720 shared pool PL/SQL MPCODE 7500 sha
本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。読者はOracleデータベースのアーキテクチャを理解し、運用管理の実務経験を積んでいることが望ましい。対象とするバージョンは現状で広く使われているOracle9iの機能を基本とするが、Oracle 10gで有効な情報も随時紹介していく。(編集局) 連載目次 前回「表の結合を極めるチューニング・テクニック」では、絞り込み条件がない結合を含むSQL、絞り込み条件のある結合を含むSQLについて実例を基に最適な結合方法を説明しました。 今回は、Oracleの機能である「マテリアライズド・ビュー」「BITMAP JOIN INDEX」「クラスタ」を利用した結合処理に関するチューニング・テクニックについて説明します。 マテリアライズド・ビューを理解する 結合処理な
データベースが運用段階になると、そのバックアップが重要になる。しかし、その方法はデータベースの運用形態によって異なる。バックアップの方法や仕組みを理解し、運用形態に最適なバックアップ計画を立案しよう。 前回まで、データベースの作成について解説してきました。Oracleのインストール時に作成されるデフォルトデータベースとは一味違う、自分のデータベースが作成できるようになればもう立派なOracleマイスターです。 いよいよデータベースの運用を始めなければなりませんが、それにはバックアップ計画が欠かせません。基本的な運用計画とバックアップ方法を身に付けましょう。 オンラインバックアップとコールドバックアップ データベースのバックアップには、大きく分けて「コールドバックアップ」と「オンラインバックアップ」の2つがあります。 コールドバックアップ データベースをすべて停止(shutdown)した状態
主な内容 --Page 1-- ▼論理バックアップと物理バックアップ ▼エクスポート・ユーティリティによるバックアップ --Page 2-- ▼OSコマンド、バックアップツールによる一貫性バックアップ --Page 3-- ▼OSコマンド、バックアップツールによる非一貫性バックアップ 前回はリカバリに焦点を絞り、どのような仕組みによってデータの整合性が保証され、リカバリが行われているかについて説明しました。今回と次回の2回では、Oracleで一般的に利用されるバックアップ方法の概要について説明します(詳細については、第5回以降にて説明します)。Oracleには、さまざまなバックアップ要件に対応できるように多くのバックアップ方法が用意されていますので、それらの特徴やメリット、デメリットを理解し、適切なバックアップ方法を選択することが大切です。 論理バックアップと物理バックアップ Oracle
SQL チューニング編1 - チューニングの方向、プログラムチューニング Oracle 固有の部分があるかもしれません。SQL-Server、MDB では注意のこと。 ■チューニングの方向 ・RDBMS へのアクセスが LAN に留まるのか、WAN も含むのか、回線速度、デ ータベースサーバのパワーによって、チューニングの方向は変わってくる。 10base-T や 100base-TX の LAN ならば、クライアントの負荷を高めること によってサーバ負荷を軽減すると言うのもひとつの方向である。 また、低速回線を含むシステムでは、非同期アクセスを取り入れると効果が 高い。更にサーバ側カーソルをできるだけ利用した方が良い。 ・データベースそのもののチューニングより、パフォーマンスの高い DB 設計、 無駄のないコードロジックを使用する方が結果としての効果は高い。 ■プログラムチューニング ・
8 April, 1998 Updated PCDN OracleWG S.Yamazaki 普段、SQL文を書いているときは、期待した結果が得られた文が最適であると思いがちです。しかし、果たしてそれが最適かどうかは疑問が残ります。最適なSQL文を書くことはプログラマの責任であり、アプリケーションの応答時間の短縮や、利用する資源の競合の減少を図る上では避けて通れない問題です。 ここで説明することが、SQL文のチューニングの最終到達点である「最適なアクセスパス」を選択できるように少しでもお役に立てれば幸いです。 最適なSQL文とは 最適なSQL文とは何をもって「最適」とするのでしょう。オペレーターが期待するデータ集合をDBから抽出するとき、さまざまなSQLの書き方を想定すると思います。その時、オペレーターはある程度の応答時間を想定してSQLを書くと思います。では、試行錯
CSVファイルからOracleのテーブルへデータを流し込むツール。 大量のinsert文を発行するよりは、断然高速。 データであるCSVファイルや固定長ファイルと、ロード方法を指定するコントロールファイルを用意 して実行する。 (CSVファイルからのロードはこのSQL*Loaderが使えるが、CSV出力には標準的な方法は無いらしくて、select文で加工する方法がよく使われるらしい。 このSQL文をいちいち書くのは少々面倒なので、SQL生成用Excelマクロを作ってみました) コントロールファイル CSVファイルの各項目とテーブルの項目との関連付け等を指定する。 (コントロールファイルをテキストエディタで書くのはけっこう面倒なので、コントロールファイル作成用Excelマクロを作ってみました(CSVファイル用、固定長ファイル用)) 例)emp.ctl: OPTIONS(LOAD=100,SK
Oracle Tips テーブル内のレコードの全削除truncate table テーブル名 DELETE文と異なりトランザクションの対象とならないため大量のレコードも一瞬で削除され、ロールバックセグメントの空き容量を気にする必要もありません。(とーぜん、コミットやロールバックはできません) スキーマに存在しているテーブル名の取得select * from user_tables select * from tab (こっちはビューも取得可能) スキーマ内のオブジェクト名の取得select * from all_objects where owner = 'ユーザ名' order by owner, object_type, object_name ユーザ名は大文字。 USER_OBJECTS でも可。 (こっちはスキーマ内のオブジェクトが対象) テーブル構造の取得describe テーブ
Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。(編集局) SQL処理(インデックス)にかかわる確認 前回「ロックをつぶせ!最初に疑うべき原因」では、SQLにかかわる問題の解決方法としてロックの確認方法を説明しました。データ更新には必ずオブジェクトの処理が行われていることを理解できたと思います。 SQL文をきっかけに更新されるOracleサーバ内のオブジェクトとして、今回はインデックスを取り上げます。SQL文発行時、直接データとのかかわりを意識しづらいオブジェクトなので、データの更新頻度やインデックスの作り方によ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く