hikazohのブックマーク - はてなブックマーク

Oracle RAC の投票ディスクについて - ablog

オラクルマスター教科書 ORACLE MASTER Expert 【RAC】編(試験番号:1Z0-048) P.460 投票ディスクの機能 CSSD(Cluster Syncronization Service デーモン)は、インターコネクトを介してほかのノードと通信し、通信状況を投票ディスクに格納します。インターコネクトに障害が発生した場合、共有ディスクに対するI/Oの同期が取れなくなるため、クラスタが分断された状態になります。クラスタが孤立するとほかのノードが使用可能か判断できなくなり、同じデータベースに対して非同期アクセスすることでデータベースの不整合が発生する可能性があります。このような状況は「スプリットブレイン」と呼ばれ、投票ディスクはスプリットブレインを解決するために使用されます。スプリットブレインが発生すると、孤立したノードを削除する必要があります。その際には、通信できるノ

hikazoh 2015/09/13

oracle

リンク

oracle.jdbc.ReadTimeout はソケット読込時のタイムアウト - ablog

Oracle JDBC Thin Diver の oracle.jdbc.ReadTimeout について調べたことをメモ。 Oracle ACE の id:yamadamn さんのスライドがわかりやすいです。 Oracle JDBCドライバプロパティの活用 from Oracle Fusion Middleware P.11 P.12 まとめ Oracle JDBC Thin Diver の oracle.jdbc.ReadTimeout（ミリ秒）はソケット読込時のタイムアウトスレッドがソケット読込み待ちになった時点からの経過時間でタイムアウトする。 ReadTimeout > SetQueryTimeout にする理由 SELECT で少しずつ結果セットを受信するようなケースでは問題ないが、実行時間の長い SELECT で最後まで結果セットが帰って来ないケースや UPDATE や

hikazoh 2015/09/13

oracle
Java

リンク

Linux のページテーブルのサイズの見方と見積式 - ablog

Linux Kernel 2.6 (x86-64) でのページテーブルのサイズの確認方法と見積式を調べてみた。あっているか自信のないところもある＆まだ書きかけ。ページテーブルのサイズの見方 OS全体のページテーブルのサイズ $ cat /proc/meminfo MemTotal: 16158544 kB MemFree: 13134056 kB (中略) PageTables: 34428 kB ★ 34MB プロセス毎のページテーブルのサイズ $ cat /proc/10225/status # 10255 は PID Name: zsh State: S (sleeping) Tgid: 10225 Pid: 10225 PPid: 10222 (中略) VmPTE: 124 kB ★ 124KB ページテーブルのサイズの見積式見積式 (プロセスが使用している物理メモリサイズ

hikazoh 2015/09/03

linux
kernel

リンク

Huge Page の解放について - ablog

ちょっと検証してみたメモ。検証結果 vm.nr_hugepages を設定する [root@yazekats-linux ~]# grep -i hugepage /proc/meminfo AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB [root@yazekats-linux ~]# sysctl -w vm.nr_hugepages=200 vm.nr_hugepages = 200 [root@yazekats-linux ~]# grep -i hugepage /proc/meminfo AnonHugePages: 0 kB HugePages_Total: 200 HugePages_Free

hikazoh 2015/06/10

linux
VM

リンク

is not null で count する SQL を Index Only "Fast Full" Scan で高速化する - ablog

is not null で count する SQL を Index Only "Fast Full" Scan で仕事（計算）量を減らして高速化してみた。インデックスを作成すると、オプティマイザが期待していた仕事（計算）量が少なくなる実行計画を選択してくれた。チューニング結果ビフォー 17:36:30 SQL> alter system flush buffer_cache; System altered. Elapsed: 00:00:00.88 17:36:51 SQL> select count(c2) from test1 where c5 is not null; COUNT(C2) ---------- 100000 Elapsed: 00:00:05.70 17:37:11 SQL> select * from table(dbms_xplan.display_curs