1. ホーム
  2. のらマネージャーのブログ
  3. オラクルチューニング

オラクルチューニング

それでも必要。SQLでパワーアップ

2003年4月15日 12:00

へっ。なんでぇ。外すインデックスって外して良いんじゃん。
やれやれ、良い感じになったぞ。
げっ。また、先輩が来たぞ。まためんどくさいこというんじゃないんだろうなぁ。
っちゅうか、自分でやれよ。DBAなんざめんどくさいしな。
「あのさぁ、教えて欲しいんだけど」
お。なんすか?なんでも聞いて下さい。分かる事は分かります。
分からん事は分かりませんが........。
「あのさぁ、インデックスってついたんだよね」
そうですよ。要らないインデックスもはずしましたよ。
「検索させる時に、どういうSQLが効率いいの?」
へ?
「効率の良いSQL。それをなるべく使いたいし」
え.................。


こんな「ざるちゅー」は嫌じゃというあなたへ

今日のポイント(Oracleパワーアップテクニックより)

 ・最適なSQLを探すには:P.132第4章4-3「SQLのコーディングによるパフォーマンス向上」
 ・SQLの利用状況をみる:P.104第3章3-6「チューニング内容のチェック」(V$SQLTEXT)

ここでは、インデックスを付けたんですからインデックスを上手にたたくSQLを 教えるのが良いでしょうね。ただ、メモリ使用量の問題なんかもありますから いくつかのV$ビューを上手に見ながら判断すると良いですよね。
9iであれば、本書にあるもの以外にも、V$SQL_PLANやV$DB_CACHE_ADVICEも あわせて利用するとより優れたチューニングが行えます。

しかし、この人いつになったらまともなDBAになれるんでしょうか。

1+1=2?

2003年3月15日 12:00

やれやれ、SQLってのも奥深いもんだ。
まぁ、この辺の細かいチューニングは先輩に任せちゃおう。
こっちは、大雑把に監視だけしようっと。
「これ以上はつらいかね?」
げ。社長だよ.......。
えええ、まぁ、私の思いつく範囲だとそろそろ限界っぽいですけど。
「このサービスは結構重要なんで、システムを増強しようと思うんだが....」
あー。それはいいですね。この際だから、良いハードをどーんと買っちゃって
「ハードを良くしたら速くなのか?」
あ、いや、サーバのCPUとかメモリ増やすだけでもずいぶん速くなるとは思いますけど。
「そうか。それを買い足すことにしよう」

数日後

あれ?CPUとメモリふやしたけど、そんなに速くならないぞ......。
あ、またメモリのチューニングしないといかんのか。
それでも、いまいちだなぁ...........。
どーしましょ?社長怒っちゃうよ。


こんな「ざるちゅー」は嫌じゃというあなたへ

今日のポイント(Oracleパワーアップテクニックより)

 ・パラメータチューニング:P.91第3章3-4「各パラメータの調整」

CPUとメモリの増加にともなっていくつかのチューニングを行う必要があります。
メモリに関しては、先の「メモリが余ってる」を参考にチューニングすればいいでしょう。CPU増に関しては、本書ではP.96のdb_block_lru_latchesだけしかCPUとの相関を明記していませんが、一般には、P.93のprocesses、open_cursors、db_writersも調整した方がいいでしょう。

インデックスはいんでっくす

2003年2月15日 12:00

「あのさー、検索スピード遅いんだけどインデックスってつけた?」
は?なに言ってんすか先輩。Webページのindex.htmlなら使ってますよ。
「いや、そうじゃなくてさ、インデックス。知らないの?」
そんなこといったってねぇ。昨日今日いきなりDBAになった輩が なんでもかんでも知ってるわけ無いじゃないですか。
しゃーねー。勉強すっか。
(不慣れな読書開始)
ふむふむ。索引っていうんだ。カラムだけの別の表を作るみたいなもんね。
そりゃ、早くなりそうだ。
早速つけてみるか。いやぁ。エンタープライズマネージャって簡単でいいねぇ
なるほど。早くなった気がする。
先輩先輩。つけてみましたよ。インデックス。どうっすか?
「ほう。どれどれ。結構早くなったね。どれにインデックスつけたの?」
え?どれって?めんどくさいから全部につけたんすよ。
「....................。」
あ、なあんかまずかったっすか?


こんな「ざるちゅー」は嫌じゃというあなたへ

今日のポイント(Oracleパワーアップテクニックより)
オラクルのインデックスについて(2章、2-3インデックス P.86~)
インデックスの検討(6章、6-3レスポンス向上のための再チューニング P.164)

常識といえば常識ですが、つければいいってもんでもありません。
特に、オラクルに限りませんが、インデックスのメカニズムを把握して(P165、P51、P54)、その上でメリットデメリットを判断して必要最小限のインデックスの付与だけにとどめるほうが良いでしょう。

毎度のことですが、このヒト相変わらずめちゃくちゃやってますね。
いくらGUIが便利だからって全部はつけるのはめんどくさいでしょうに。

おらくるって?DBAというお仕事

2003年1月15日 12:00

え?またおちたの?あー。そういやこの間パラメータいじったっけ。
こんちくしょー。落ちたり動いたりって、俺ってなんのために こんな面倒くさいことやってるんだっけ?
毎日毎日パラメータいじってるだけだし。
データベースのお守りはめんどくさい。DBAなんかやるんじゃなかった。
そもそも、DBAってなにやるんだ?ちまたのDBAの本を読んでもわけわからん。

開発するときは、SQL使うしか用がなかったんだよな。
オラクルって。SQL使えりゃオラクル使えるてことじゃないのかよ。
DBAやってみたら、オラクル使えるってそういう意味じゃないんだな。
ちょっとは心入れ換えて、わけわからんオラクルの専門書でも読まないかんのだろうなぁ。


こんな「ざるちゅー」は嫌じゃというあなたへ

今日のポイント(Oracleパワーアップテクニックより)

 ・DBAと開発者:P.157コラム
 ・DBAと開発者の役割:P.8第1章1-3「RDBMSに関する理解について」

アプリケーションを構築する側から見た「オラクルを使う」というのと DBAからみた「オラクルを使う」というのは、同じオラクルを使うっていう 言葉で表現されますが、要求されることは全くことなります。

よくオラクルの解説書を手に取る人が「わかりにくい」といいますが たいていそういう本は、DBA向けのもののことが多かったりして、 普通のアプリケーションのソースコードを書くのには不用だったりもします。

やっぱり煩いハードディスク

2002年11月15日 12:00

HDアクセス音がいつまでも変わらないので、次の3つのパラメーターに手を付けることにしました。解説をよく読むと、メモリの使用量に関わるみたいなんですね。

db_block_buffer
shared_pool_size
sort_area_size

まずは、なにも考えず、倍倍ゲームで数字を増やします。おおお!!だんだん 静かになってパフォーマンスがあがって行くぞ!!!これは良い感じだ。

あれ?止まっちゃったぞ。再起動もエラーでできんぞ。やべぇ。
システムごと再起動。助かった。ちゃんと動く。次はもうちょっと慎重に。
動くと思っても時間がたったら、システムダウン。そんなこんなを繰り返しながら数字を変えて、落ちないところでなんとかストップ。しかしサービス提供しながら、ダウンさせるのは問題だよなぁ......。


こんな「ざるちゅー」は嫌じゃというあなたへ

今日のポイント(Oracleパワーアップテクニックより)
オラクルのメモリ領域について(3章、3-3SGA P.86~)

 ・db_block_buffer:P91、P88「データバッファキャッシュ」
 ・shared_pool_size:P91、P86「共有プール」
 ・sort_area_size:P92

この変は結構面倒くさいですが、丁寧に何がどのようにメモリを食っているかを考えながらパラメータ値を決めるほうが結構うまく行きます。 つーか、お話とはいえ、上の人かなりむちゃくちゃですね。

アイリンクへのお問い合わせ

お問い合わせメールフォームはこちら

2016年12月移転 北海道旭川市神楽1条7丁目4−8 お問合わせはメール・SNSアカウントで mail
  • twitter
  • facebook
  • google
  • noimage
  • noimage
  • noimage