第五回 中国地方DB勉強会
-
- いいね！0
tkt@KIMIKOE&POPIN-Q応援中
@takatayoshitake
トラブルシューティングを行うためには、平常時からデータを取得しておいて変化を確認すると良い #chugokudb
2014-09-21 10:20:07
ぬこ＠大阪 16.1
@nuko_yokohama
seq readが遅いと判断する基準は4msくらい。例示されている8msだと遅いとのこと。 #ChugokuDB
2014-09-21 10:20:54
ぬこ＠大阪 16.1
@nuko_yokohama
OracleはPostgreSQLのautovacuum/analyzeみたいに件数変化の閾値をこえたときに、統計情報の再取得はしないのかな。 #ChugokuDB
2014-09-21 10:22:39
tsuda.a
@tsuda_ahr
ハードパース→SQLの初回コンパイル(実行計画の作成)、ソフトパース→以前のコンパイル結果を使用する。当然ハードパースが多く発生するとパフォーマンスは悪い #ChugokuDB
2014-09-21 10:24:24
ぬこ＠大阪 16.1
@nuko_yokohama
パフォーマンス問題の解決はセンスかキャリアを積むしかない、か・・・やっぱりOracleのようなツールが充実していそうなDBMSそうなのだなあ。 #ChugokuDB
2014-09-21 10:26:27
ISHII Hidenori
@h141gm
#ChugokuDB パフォーマンスチューニングはセンスかキャリアしかない キャリアのためには、きちんと経験したトラブルを記録しておくこと
2014-09-21 10:27:30
ぬこ＠大阪 16.1
@nuko_yokohama
ORA-600, ORA-7445問題。最近、Oracle使ってないから分からないけど、ORA-600って最近のバージョンでも結構発生していたりするのかなあ？ #ChugokuDB
2014-09-21 10:27:48
そーだい@初代ALF
@soudai1025
ORA-00600はサポートがUSになるかすっげぇ時間かかるし現場でどうすることも出来ないんだよなぁ… #ChugokuDB
2014-09-21 10:28:38
tkt@KIMIKOE&POPIN-Q応援中
@takatayoshitake
ORA-00600 内部エラーコード 発生時はこの番号だけでなく後ろの引数が重要なのでメモって合わせて報告が必要 #chugokudb
2014-09-21 10:30:02
ISHII Hidenori
@h141gm
#ChugokuDB ORA-7445は、クライアント側にはセッションが切れた(ORA-3113等)ようにしか見えないので注意。 ログを見ると発生していたことがわかる。
2014-09-21 10:31:54
そーだい@初代ALF
@soudai1025
バックアップは日々絶対取る必要がある。バックアップをとってない状態でデータが壊れても復旧出来る可能性は10%もない。とってない場合は完全にユーザの責任なのでサポートも出来ない。 #ChugokuDB
2014-09-21 10:32:41
そーだい@初代ALF
@soudai1025
アプリの実装する人もクライアントのエラーをログに残してほしい。kライアンとしか出ないエラーログもある。 #ChugokuDB
2014-09-21 10:33:56
Araki3
@akira345
ORA-00600はクライアントPCでCtrl+Alt+Delで強制終了したら共連れで死んだって経験がある・・・ #ChugokuDB
2014-09-21 10:34:22