開催中のOracle Openworldで、Oracle Exadata Storage Server と Oracle Database Machine が発表されましたね。 実は、このOpenworld、うちの会社からも何名か行っていまして、 私も候補に入っていたのですが、本部内抗争に敗れまして、 いけなくなったのです。ほんと、残念・・・。 今頃サンフランシスコの夜を満喫できてたはずなのに・・・。 ってまぁそんな話はよくってですね、新製品ですよ。 Oracle初のハードウェア製品ですよ。 どんなものかといいますと、 Oracleが今回発表したのは、「Oracle Exadata Storage Server」と「HP Oracle Database Machine」の2機種で、前者のストレージ・システムにOracle Databaseなどのソフトウェア製品を加えたのが後者となる。 ht

RACの運用管理をしていて、セッション情報を定期的に出力しておくシェルなんかを 作ろうとしたけど、v$sessionだと実行インスタンスの情報しか出ないので、 ループまわして、全ノードに対して実行して、無理やり情報を出力させているやつは、 どこのどいつだーい？？ 私だよっ！ っつーわけで、RACだと、v$系のVIEWは実行インスタンスの情報しか出してくれません。 そんなときに、役に立つのがgv$系のVIEW。これ、意外と知らない人が多いので、 ぜひぜひ試していただければと思います。 gv$sessionなんかだと、こういう感じです。 SQL> desc gv$session 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- INST_ID NUMBER SAD

nijimassさ〜ん。電話ですよ〜。 はいはーい。 「もしもし、お電話かわりました。nijimassです。」 「データベースにログインできないんですが・・・。」 「え？」 よくありますね。いやいや、よくはないか。たまにありますね。 優雅な午後の昼下がりを一瞬にして脂汗、男汁まみれにする悪魔な電話。 まぁ、ログイン障害なら、かわいいもんです。 たいていの場合は、インスタンスの再起動で解決！はい楽勝〜！ なんて思ってたら、お客様から、こんな突っ込みが入ります。 「今回起こったことは仕方ないけれど、今後、類似の障害を起こさないために、 原因究明をしっかりやる必要があります。で、原因は？」 はい。脂汗タイムアゲイン！ っつーことで、今日はデータベースがハングしてしまったときの情報収集について、 書いてみましょうか。 # この手順を実行したことによるいかなる損害も私のほうでは責任とれませんので、

昔々、このブログをリニューアルする前は、 リニューアルしたんだから当然なんですけど、違うタイトルでブログを書いてました。 そこにも、Oracle関連の情報を書いてたんですね。 # もううろ覚えだけど、たぶん Oracle Master Silver か Gold 受験のために、 # 自分でまとめたものだったと思う。 で、そこに引っかかったと思われる検索痕が「リンク元」に残ってるんですね。 元ページはもう無くなって、ただのPerfumeバカのブログに成り下がっているというのに・・・。 来た人は「このアイドルオタクめ！」とがっかりしたことでしょう。ごめんなさい。 ということで、罪滅ぼしではないですが、 どういう検索でここに来たかをリンク元アドレスから確認し、 その人が求めていたであろう情報をまとめていこうと思います。 第１弾は「sql_trace」の設定について。 初期化パラメータ「sql_t

需要はほんとにあるんだろうかと思って反省会企画第1弾を書いたところ、 sql_traceパラメータの設定 http://d.hatena.ne.jp/nijimass/20080513/1210688832 「DBMS_SYSTEM」「トレース」なんかでの検索痕が結構ありました。 いろいろ見てくれてるひとはいるんですね。 ということで、トレースを取ってみる第２弾です。 今回は前回の最後でちょっと触れた、「DBMS_MONITOR」。 Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス 10g リリース2（10.2） 60 DBMS_MONITOR http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/appdev.102/B19245-01/d_monitor.htm

なんか、DBMS_MONITORのエントリを書いた時点で これはやらなくて良いような気がしましたが、 いちおう書いとくか。 マニュアル探したけど、DBMS_SYSTEMが見つかりませんでした・・・。 「Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス」に 載ってると思ったのになぁ・・・。 まぁ、とりあえず、お決まりの desc で確認。 Versionは10.2。 SQL> desc dbms_system PROCEDURE DIST_TXN_SYNC 引数名 タイプ In/Out Default? ------------------------------ ----------------------- ------ -------- INST_NUM NUMBER IN PROCEDURE GET_ENV 引数名 タイプ In/Out

今日はちょっとライト目にExplain Planの使用方法でも書きます。 まぁ、週末だしね、多少簡単げなとこで。 EXPLAIN PLAN ってなに？ Oracle Database パフォーマンス・チューニング・ガイド 10g リリース2（10.2） B19207-01 19 EXPLAIN PLANの使用方法 http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19207-01/ex_plan.html EXPLAIN PLAN文は、SELECT、UPDATE、INSERTおよびDELETE文について Oracleオプティマイザが選択した実行計画を表示します。 文の実行計画とは、Oracleがその文を実行するために行う一連の処理です。 どんなときにつかう？ SQLチューニングに使い

ということで、今日はヒント句について少し。 皆さんよく使うであろう ORDEREDヒント と ちょっとマイナーな LEADINGヒント についてです。 ORDEREDヒント と LEADINGヒント は「結合順序に関するヒント」です。 つまり、これを使用すれば、 FROM句以下に記述しているテーブルの結合順序を ユーザ側で制御できるというわけです。 たとえば、下記のようなSQLがあります。 SQL> explain plan for 2 SELECT EMP2.ENAME ,DEPT.DNAME ,EMP2.JOB 3 FROM EMP EMP1 4 ,EMP EMP2 5 ,DEPT 6 WHERE EMP1.MGR = EMP2.EMPNO 7 AND EMP2.DEPTNO = DEPT.DEPTNO 8 AND EMP1.ENAME = 'TURNER'; 解析されました。 すでに

これもよくありますよね。 速かったり、遅かったりするけど、原因がなぜかわからない・・・。 こういう場合、実行計画がころころ変化してるケースが非常に多いです。 ということで、それの調べ方を。 あ、10gの話になるので、9i以前の方はすみません。 ここでは、例として下記のSQLのパフォーマンスがころころ変わっているとします。 このSQLはOracle内部で発行されているSQLなのですが、 ユーザが発行してるものだと思ってください。 select procedure#,procedurename,properties,itypeobj# from procedureinfo$ where obj#=:1 order by procedurename desc, overload# desc 9iまでは、こういったSQLレベルでの実行計画の変化を確認する場合、 Statspack の Snapsh

前のエントリでこんなことを書きました。 テーブルの結合順序を制御したい！ http://d.hatena.ne.jp/nijimass/20080526/1211806659 LEADINGヒントだと 「ヒント句追加しただけだし、もし間違っててもヒント句なので無視されます！」 とか言うと、実行確認レベルで済む可能性があることです！ # ウソです。コード触ってる以上、ちゃんとテストしましょうね。 ヒント句の特徴として、間違ったヒントを書いてもエラーを返さずに、 無視されて、SQL自体は正常に実行されるというものがあります。 ということで、よく聞く話を。 ヒントの指定で間違いやすいポイントとして、表名の指定があります。 SQL文内で表の別名を使用している場合、 使用している別名でヒントの指定をしないと、 ヒントが有効になりません。 Oracle Database パフォーマンス・チューニング・

続いて、前のエントリで設定した自動取得が実際に動いているかどうか、 Statspackのレポートの取り出し方とあわせて確認していきます。 レポートってさらっといっちゃいましたけど、 Snapshotを取得することによって、格納されているOracleの統計情報を、 人間が見やすい形で様々な観点から分析してくれているものです。 取り方 perfstat(Statspack管理ユーザ)でログインして、 spreport.sql というsqlをたたくだけです。 この sql の実行結果の中に、Snapshotが取得された時間が 情報として出力されますので、前回の自動取得の設定が有効になっているか どうかも確認できます。 さ、実行。 [oracle@test ~]$ sqlplus perfstat/perfstat SQL*Plus: Release 10.2.0.3.0 - Production

さて、前のエントリでStatspackのインストールをしましたが、 これだけではダメでして、情報を取得するための、 Snapshotを取得していく必要があります。 Snapshotを取得すると、そのタイミングでの(そのタイミングまでの) Oracleの稼動情報が、Statspackで管理されている表にコピーされます。 Snapshotの取得には、statspack.snap というプロシージャを実行するのですが、 当然、手で毎回たたくわけには行きませんよね。 というわけで、自動取得の方法を。 自動取得の方法はいくつかありますが、代表的なところは下記でしょうか。 Oracleが提供する spauto.sql を使い、OracleのJOBベースで実行する。 DBMS_SCHEDULERに登録する。 cron万歳 1つ目はいろんなところに解説がありますし、 最悪、perfstatユーザ(Stat

とりあえず、次回の実験のために、Statspackのインストールだけ 先にすませておきます。超簡単ですよ。 $ORACLE_HOME/rdbms/admin/spcreate.sql を実行して、プロンプトに従うだけで、インストール完了です。 まず、実行します。 SQL> @?/rdbms/admin/spcreate Choose the PERFSTAT user's password ----------------------------------- Not specifying a password will result in the installation FAILING perfstat_passwordに値を入力してください: perfstat perfstat Statspackの管理用ユーザ「PERFSTAT」が作成されるのですが、 設定するパスワードを聞いてきま

以前、AWRを使用できる環境で、実行計画がころころ変わる場合の 調査方法をエントリしました。 パフォーマンスがころころ変化するSQLの調査 http://d.hatena.ne.jp/nijimass/20080528/1211991024 これ、無理やり自分でSQL組んでますけど、 「awrsqrpt.sql」を使ったほうが早かったですね。確実に。 このSQLの使い方はまた今度ご説明します。 で、このエントリのなかで、 次回は、Diagnostics Pack のライセンス買ってねーよ！ って人のために、Statspackで同じような情報が 簡単に取り出せないか、実験してみたいと思います。 って書いたので今回はそれを説明してみます。 ではどうぞ。 今回は Statspack しか使用できない場合に、 実行計画がどのように変わったかを調査する方法を説明します。 ちなみに、超簡単です。 シナ

またまた一部のマニアックな人しか喜ばないようなエントリで ごめんなさい。とくにMixiから来ていただいている方には、 ほとんどタガログ語を読んでいるのとかわらないような意味不明度でしょう・・・。 ほんとごめんなさい。 さて・・・、 今回はRACのサービスをシェルで監視してみます。 サービスの監視ということで、 たぶんOEMとかを使えばすいすいっといけるんでしょうけど、 既に、社内で標準の監視/通知ツールが入っていて、連携させるのが面倒！とか、 そもそも連携できねー！とか、あと、大きな声では言えないですが、OEMは信用してない！ とかまぁ、いろいろある理由で、OEMは使っていても、 監視/通知の機能を使っていないところは多いんじゃないでしょうか？*1 ならば仕方ない、シェルの出番だ。ということで、 監視/通知シェルを作ることになるわけです。 さて、サービスの監視ということで方法としては、 c

「開発環境と本番環境で実行計画が違うんだけどなんで！？」 今日もこんな問い合わせがありました。 もうね、最近は問い合わせの8割が実行計画と統計情報。 何べん同じことを言ったら良いんだろうね。 そろそろ、社内(といっても常駐先内)での情報共有の仕組みとかにも、 口を出していったほうが良いんだろうか。 っつーか、こんだけブログに書いてて、わりとそれっぽいキーワードで 検索したら、上位に来るようにもなっているのに、それでも聞いてくるってことは、 どんだけ丸投げ体質なんだよと。 まぁ、隣で開発やってるお会社さんは、アクセス禁止サイトへのアクセスを させないために、Webへのアクセスを禁止しています。 なんという前時代的な・・・。 おっと、他の会社をdisってても、仕方ないですね。 とりあえず、タイトルの件に関しては、 自分なりにまとめて回答してみたので、こちらにも共有しますよっと。 さて、冒頭の質

まぁ、なんというか、突っ込むっていうか、記事の文字数制限とかの関係で かけなかっただけだとは思うんですけど、ちょっと違和感があったので、 突っ込んでみます。 では元記事を。 では、ノードを増やした分に比例してパフォーマンスが向上するか？というと、100％そうではありません。RACはシングル構成に比べて、次のようなオーバヘッドがあります。 1つ目が「マスター問い合わせ処理」です。RACでは、各データに対して「どのノードが最新データを持っているか？」を管理しているノードがいます。そのノードをマスターといいますが、アクセスを行うノードはそのマスターに問い合わせを行います。 2つ目が「分散ロック管理処理」です。更新中のデータがほかのノードに更新されないよう、ノード間にまたがって管理されるロックです。 3つ目が「インターコネクト経由のデータ転送処理」で、物理的な転送処理です。 http://www.

さて、今回は多くの人が悩まされる統計情報と実行計画について、 お話していきたいと思います。 なお、基本的に対象のVerは10.2です。 なので、10.1でも通じるものはあると思いますが、 9.2以前の方は他を当たってください。 11.1以降の方もこの絡みだと、SPM(SQL Plan Management)とか新機能があるので、 他(インサイトテクノロジーとか)のサイトを当たってみてください。 では本編へ。長いぞー。 10gR1から、オプティマイザ統計の自動収集という機能が 新たに追加されてまして、デフォルトで動作する状態になっています。 まず、ここから説明しておきたいと思います。 10gから、RBOがサポートされなったため、ユーザはCBOを使用しなければなりません。 CBOは統計情報を元に実行計画を作成するため、ユーザが何も意識しなくても、 統計情報が取られた状態で、CBOが使えるように