SELECT regexp_substr('B 123 CC','[^ ]+', 1, 1) AS KodeWilayah,
regexp_substr('B 123 CC','[^ ]+', 1, 2) AS Nomor,
regexp_substr('B 123 CC','[^ ]+', 1, 3) AS KodeWilayahKab FROM DUAL;
Rabu, 04 Februari 2015
Kamis, 20 November 2014
Virtual Key - Delphi
Virtual Key Code
VK_LBUTTON Left mouse button
VK_RBUTTON Right mouse button
VK_CANCEL Control+Break
VK_MBUTTON Middle mouse button
VK_BACK Backspace key
VK_TAB Tab key
VK_CLEAR Clear key
VK_RETURN Enter key
VK_SHIFT Shift key
VK_CONTROL Ctrl key
VK_MENU Alt key
VK_PAUSE Pause key
VK_CAPITAL Caps Lock key
VK_ESCAPE Esc key
VK_SPACE Space bar
VK_PRIOR Page Up key
VK_NEXT Page Down key
VK_END End key
VK_HOME Home key
VK_LEFT Left Arrow key
VK_UP Up Arrow key
VK_RIGHT Right Arrow key
VK_DOWN Down Arrow key
VK_SELECT Select key
VK_PRINT Print key (keyboard-specific)
VK_EXECUTE Execute key
VK_SNAPSHOT Print Screen key
VK_INSERT Insert key
VK_DELETE Delete key
VK_HELP Help key VK_LWIN Left Windows key (Microsoft keyboard)
VK_RWIN Right Windows key (Microsoft keyboard)
VK_APPS Applications key (Microsoft keyboard)
VK_NUMPAD0 0 key (numeric keypad)
VK_NUMPAD1 1 key (numeric keypad)
VK_NUMPAD2 2 key (numeric keypad)
VK_NUMPAD3 3 key (numeric keypad)
VK_NUMPAD4 4 key (numeric keypad)
VK_NUMPAD5 5 key (numeric keypad)
VK_NUMPAD6 6 key (numeric keypad)
VK_NUMPAD7 7 key (numeric keypad)
VK_NUMPAD8 8 key (numeric keypad)
VK_NUMPAD9 9 key (numeric keypad) VK_MULTIPLY Multiply key (numeric keypad)
VK_ADD Add key (numeric keypad)
VK_SEPARATOR Separator key (numeric keypad)
VK_SUBTRACT Subtract key (numeric keypad)
VK_DECIMAL Decimal key (numeric keypad)
VK_DIVIDE Divide key (numeric keypad)
VK_F1 F1 key
VK_F2 F2 key
VK_F3 F3 key
VK_F4 F4 key
VK_F5 F5 key
VK_F6 F6 key
VK_F7 F7 key
VK_F8 F8 key
VK_F9 F9 key
VK_F10 F10 key
VK_F11 F11 key
VK_F12 F12 key
VK_F13 F13 key
VK_F14 F14 key
VK_F15 F15 key
VK_RBUTTON Right mouse button
VK_CANCEL Control+Break
VK_MBUTTON Middle mouse button
VK_BACK Backspace key
VK_TAB Tab key
VK_CLEAR Clear key
VK_RETURN Enter key
VK_SHIFT Shift key
VK_CONTROL Ctrl key
VK_MENU Alt key
VK_PAUSE Pause key
VK_CAPITAL Caps Lock key
VK_ESCAPE Esc key
VK_SPACE Space bar
VK_PRIOR Page Up key
VK_NEXT Page Down key
VK_END End key
VK_HOME Home key
VK_LEFT Left Arrow key
VK_UP Up Arrow key
VK_RIGHT Right Arrow key
VK_DOWN Down Arrow key
VK_SELECT Select key
VK_PRINT Print key (keyboard-specific)
VK_EXECUTE Execute key
VK_SNAPSHOT Print Screen key
VK_INSERT Insert key
VK_DELETE Delete key
VK_HELP Help key VK_LWIN Left Windows key (Microsoft keyboard)
VK_RWIN Right Windows key (Microsoft keyboard)
VK_APPS Applications key (Microsoft keyboard)
VK_NUMPAD0 0 key (numeric keypad)
VK_NUMPAD1 1 key (numeric keypad)
VK_NUMPAD2 2 key (numeric keypad)
VK_NUMPAD3 3 key (numeric keypad)
VK_NUMPAD4 4 key (numeric keypad)
VK_NUMPAD5 5 key (numeric keypad)
VK_NUMPAD6 6 key (numeric keypad)
VK_NUMPAD7 7 key (numeric keypad)
VK_NUMPAD8 8 key (numeric keypad)
VK_NUMPAD9 9 key (numeric keypad) VK_MULTIPLY Multiply key (numeric keypad)
VK_ADD Add key (numeric keypad)
VK_SEPARATOR Separator key (numeric keypad)
VK_SUBTRACT Subtract key (numeric keypad)
VK_DECIMAL Decimal key (numeric keypad)
VK_DIVIDE Divide key (numeric keypad)
VK_F1 F1 key
VK_F2 F2 key
VK_F3 F3 key
VK_F4 F4 key
VK_F5 F5 key
VK_F6 F6 key
VK_F7 F7 key
VK_F8 F8 key
VK_F9 F9 key
VK_F10 F10 key
VK_F11 F11 key
VK_F12 F12 key
VK_F13 F13 key
VK_F14 F14 key
VK_F15 F15 key
VK_F16 F16 key
VK_F17 F17 key
VK_F18 F18 key
VK_F19 F19 key
VK_F20 F20 key
VK_F21 F21 key
VK_F22 F22 key
VK_F23 F23 key
VK_F24 F24 key
VK_NUMLOCK Num Lock key
VK_SCROLL Scroll Lock key
VK_LSHIFT Left Shift key (only used with GetAsyncKeyState and GetKeyState)
VK_RSHIFT Right Shift key (only used with GetAsyncKeyStateand GetKeyState)
VK_LCONTROL Left Ctrl key (only used with GetAsyncKeyState and GetKeyState)
VK_RCONTROL Right Ctrl key (only used with GetAsyncKeyState and GetKeyState)
VK_F17 F17 key
VK_F18 F18 key
VK_F19 F19 key
VK_F20 F20 key
VK_F21 F21 key
VK_F22 F22 key
VK_F23 F23 key
VK_F24 F24 key
VK_NUMLOCK Num Lock key
VK_SCROLL Scroll Lock key
VK_LSHIFT Left Shift key (only used with GetAsyncKeyState and GetKeyState)
VK_RSHIFT Right Shift key (only used with GetAsyncKeyStateand GetKeyState)
VK_LCONTROL Left Ctrl key (only used with GetAsyncKeyState and GetKeyState)
VK_RCONTROL Right Ctrl key (only used with GetAsyncKeyState and GetKeyState)
VK_LMENU Left Alt key (only used with GetAsyncKeyState and GetKeyState)
VK_RMENU Right Alt key (only used with GetAsyncKeyState and GetKeyState)
VK_PROCESSKEY Process key
VK_ATTN Attn key
VK_CRSEL CrSel key
VK_EXSEL ExSel key
VK_EREOF Erase EOF key
VK_PLAY Play key
VK_ZOOM Zoom key
VK_NONAME Reserved for future use
VK_PA1 PA1 key
VK_OEM_CLEAR Clear key
VK_RMENU Right Alt key (only used with GetAsyncKeyState and GetKeyState)
VK_PROCESSKEY Process key
VK_ATTN Attn key
VK_CRSEL CrSel key
VK_EXSEL ExSel key
VK_EREOF Erase EOF key
VK_PLAY Play key
VK_ZOOM Zoom key
VK_NONAME Reserved for future use
VK_PA1 PA1 key
VK_OEM_CLEAR Clear key
Sabtu, 11 Januari 2014
Aktifkan ping di windows 8
Buka Environment Variable ---> System Variable ---> PATH
Tambahkan C:\Windows\System32
Tambahkan C:\Windows\System32
Sabtu, 10 Agustus 2013
Masalah Index di oracle
Berikut tulisan yang bagus masalah index di oracle, aku kutip dari Evara Syamsiar
===========================================================
Pak yahya,...
Penyebab tidak terpakainya index ada banyak faktor yang mempengaruhi,
dan ini 100% bergantung dari spesifikasi server masing-masing. Salah
satu contoh penyebab tidak terpakainya index adalah statistics dari
table yang kedaluwarsa. Yang ini harus kita perhatikan betul-betul,
dan biasanya setiap periode tertentu kita harus melakukan analyze
table-table yang ada di database. Hal ini akan sangat membantu oracle
dalam membuat execution plan.
Dan, pak yahya tidak perlu khawatir karena tidak terpakainya index.
Karena belum tentu jika menggunakan index performance dapat meningkat
dengan drastis, dan belum tentu juga membaca secara full table scan
performancenya turun. Ini semua tergantung dari statistics masing-
masing table dan oracle sangat tahu betul bagaimana dia melakukan
pembacaan data tersebut.
Berikut ini demo, bagaimana oracle melakukan pembacaan menggunakan
index.
SQL> drop table t1;
Table dropped.
SQL> drop table t2;
Table dropped.
SQL> create table t1 as select * from all_objects;
Table created.
SQL> create table t2 as select * from all_objects;
Table created.
SQL> alter table t1
2 add constraints t1$pk primary key(object_id);
Table altered.
SQL> create index t2_index on t2(object_id,owner);
Index created.
SQL> analyze table t1 compute statistics
2 for table for all indexes for all indexed columns;
Table analyzed.
SQL> analyze table t2 compute statistics
2 for table for all indexes for all indexed columns;
Table analyzed.
Table T1 diatas memiliki primary key pada kolom OBJECT_ID, sedangkan
table T2 hanya memiliki index pada kolom (OBJECT_ID dan OWNER).
Sekarang kita lakukan query join seperti dibawah ini .
SQL> set autotrace traceonly;
SQL> select t1.*, t2.object_id, t2.owner
2 from t1, t2
3 where t1.object_id = t2.object_id
4 and t2.owner = 'SCOTT';
6 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=16 <-- br="" cost="" lihat=""> ini
1 0 NESTED LOOPS (Cost=16 Card=6 Bytes=630)
2 1 INDEX (FAST FULL SCAN) OF 'T2_INDEX' (NON-UNIQUE) (Cost=
3 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=1 Card=1
Byt
4 3 INDEX (UNIQUE SCAN) OF 'T1$PK' (UNIQUE)
Statistics
----------------------------------------------------------
331 recursive calls
0 db block gets
174 consistent gets <-- br="" i="" logical=""> ...
6 rows processed
SQL>
Perhatikan bahwa untuk mendapatkan 6 ROW ( scott mempunyai 6 object
saja ), oracle membaca menggunakan primary key pada table T1. Dan
logical I/O yang dihasilkan sebanyak 174 block dengan nilai cost = 16.
Sekarang bagaimana kalau saya query dengan owner user lain, misalnya
user EVARA seperti dibawah ini.
SQL> set autotrace traceonly;
SQL> select t1.*, t2.object_id, t2.owner
2 from t1, t2
3 where t1.object_id = t2.object_id
4 and t2.owner = 'EVARA';
102 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=52 <-- br="" cost="" lihat=""> ini
1 0 HASH JOIN (Cost=52 Card=103 Bytes=10815)
2 1 INDEX (FAST FULL SCAN) OF 'T2_INDEX' (NON-
UNIQUE)
3 1 TABLE ACCESS (FULL) OF 'T1' (Cost=40 Card=29518
Bytes=28
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
511 consistent gets <-- br="" i="" logical=""> 1 physical reads
...
102 rows processed
Dan ternyata oracle tidak membaca primary key pada table T1, dia
memilih membaca full table scan. Apakah oracle melakukan kesalahan ?
jawabanya TIDAK. Sekali lagi 100% oracle bergantung dari spesifikasi
masing-masing server. Coba perhatikan parameter dibawah ini,
SQL> set autotrace off
SQL> show parameter index_cost
NAME TYPE
VALUE
---------------------------- ----------- -----------------------------
-
optimizer_index_cost_adj integer
100
Default parameter optimizer_index_cost_adj = 100, sampai oracle 9i
sekarang masing bernilai 100. Parameter ini menceritakan kepada
optimizer bahwa membaca menggunakan index atau menggunakan full table
scan cost-nya adalah sama, otomatis oracle akan memilih full table
scan.
Sekarang set nilai parameter = 30
SQL> alter session set optimizer_index_cost_adj=30;
Session altered.
SQL> select t1.*, t2.object_id, t2.owner
2 from t1, t2
3 where t1.object_id = t2.object_id
4 and t2.owner = 'EVARA';
102 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=41 <-- br="" cost="" lihat=""> ini
1 0 NESTED LOOPS (Cost=41 Card=103 Bytes=10815)
2 1 INDEX (FAST FULL SCAN) OF 'T2_INDEX' (NON-
UNIQUE)
3 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2
Card=1
4 3 INDEX (UNIQUE SCAN) OF 'T1$PK'
(UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
314 consistent gets <-- br="" i="" logical=""> 1 physical reads
...
102 rows processed
Lihat sekarang, oracle sudah membaca primary key lagi pada table T1.
Dan tentu saja untuk mendapatkan record sebanyak 102, cost = 41, dan
logical I/O = 314. performance lebih meningkat dibanding dengang saat
membaca menggunakan full table scan.
Apakah kita harus menurunkan nilai optimizer_index_cost_adj setiap
kali kita menemui bahwa ternyata index tidak terpakai ? saya menjawab
tidak selalu. Jika nilai parameter ini terlalu kecil, maka oracle
juga akan salah menentukan plan-nya.
Perhatikan query dibawah ini, saya akan select owner = 'SYSTEM'
sehingga didapatkan jumlah record yang lebih besar.
SQL> select t1.*, t2.object_id, t2.owner
2 from t1, t2
3 where t1.object_id = t2.object_id
4 and t2.owner = 'SYSTEM';
431 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=53 <-- br="" cost="" lihat=""> ini
1 0 HASH JOIN (Cost=53 Card=431
Bytes=45255)
2 1 INDEX (FAST FULL SCAN) OF 'T2_INDEX' (NON-
UNIQUE)
3 1 TABLE ACCESS (FULL) OF 'T1' (Cost=40 Card=29518
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
533 consistent gets <-- br="" i="" logical=""> 3 physical reads
...
431 rows processed
Untuk mendapatkan 431 ROW milik user SYSTEM, oracle lebih memilih
membaca mengunakan full table scan. Mungkin anda akan bertanya loh,
kalau full table scan kan menjadi lambat. ( TIDAK ).
Sekarang saya turunkan parameter optimizer_index_cost_adj menjadi 5.
Ini akan menjadikan oracle semakin agresif dalam pembacaan mengunakan
index.
SQL> alter session set optimizer_index_cost_adj=5;
Session altered.
SQL> select t1.*, t2.object_id, t2.owner
2 from t1, t2
3 where t1.object_id = t2.object_id
4 and t2.owner = 'SYSTEM';
431 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=26 <-- br="" cost="" lihat=""> ini
1 0 NESTED LOOPS (Cost=26 Card=431 Bytes=45255)
2 1 INDEX (FULL SCAN) OF 'T2_INDEX' (NON-
UNIQUE)
3 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1'
(Cost=2
4 3 INDEX (UNIQUE SCAN) OF 'T1$PK' (UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
1009 consistent gets <-- br="" i="" logical=""> 0 physical
reads
...
431 rows processed
SQL>
Dan sekarang berhasil, oracle membaca menggunakan primary key pada
table T1. Tetapi justru ini adalah kesalahan oracle dalam menentukan
execution plan. Lihat nilai cost diatas, membaca menggunakan index
COST menjadi 26 nilai ini turun dibandingkan pada saat membaca
menggunakan full table scan. Sekarang lihat nilai logical I/O-
nya ...? kini menjadi 1009. Nilai ini justru naik. Ketika masih
membaca menggunakan full table scan logical I/O = 533 sedangkan jika
membaca menggunakan index malah naik menjadi 1009. Nilai cost turun
sedang nilai logical I/O naik, berarti oracle salah menentukan
plannya.
Oleh karena itu belum tentu membaca menggunakan index menjadi
alternatif pembacaan data paling cepat. Dan belum tentu membaca
menggunakan full table scan merupakan metode pembacaan paling lambat.
Semua tergantung dari statistics table masing-masing, dan tergantung
dari spesifikasi databasenya.
Mungkin pak yahya bisa di share cara create indexnya dan hasil dari
execution plannya. Dan hati - hati dalam men-setting nilai parameter
optimizer_index_cost_adj , karena oracle bisa sangat agresif sekali
dan kadang oracle justru salah menilai pembuatan plan.
Semoga ini bisa membantu.
Terima kasih
Evara Samsyiar
www.indodba.net ==================================================================
===========================================================
Pak yahya,...
Penyebab tidak terpakainya index ada banyak faktor yang mempengaruhi,
dan ini 100% bergantung dari spesifikasi server masing-masing. Salah
satu contoh penyebab tidak terpakainya index adalah statistics dari
table yang kedaluwarsa. Yang ini harus kita perhatikan betul-betul,
dan biasanya setiap periode tertentu kita harus melakukan analyze
table-table yang ada di database. Hal ini akan sangat membantu oracle
dalam membuat execution plan.
Dan, pak yahya tidak perlu khawatir karena tidak terpakainya index.
Karena belum tentu jika menggunakan index performance dapat meningkat
dengan drastis, dan belum tentu juga membaca secara full table scan
performancenya turun. Ini semua tergantung dari statistics masing-
masing table dan oracle sangat tahu betul bagaimana dia melakukan
pembacaan data tersebut.
Berikut ini demo, bagaimana oracle melakukan pembacaan menggunakan
index.
SQL> drop table t1;
Table dropped.
SQL> drop table t2;
Table dropped.
SQL> create table t1 as select * from all_objects;
Table created.
SQL> create table t2 as select * from all_objects;
Table created.
SQL> alter table t1
2 add constraints t1$pk primary key(object_id);
Table altered.
SQL> create index t2_index on t2(object_id,owner);
Index created.
SQL> analyze table t1 compute statistics
2 for table for all indexes for all indexed columns;
Table analyzed.
SQL> analyze table t2 compute statistics
2 for table for all indexes for all indexed columns;
Table analyzed.
Table T1 diatas memiliki primary key pada kolom OBJECT_ID, sedangkan
table T2 hanya memiliki index pada kolom (OBJECT_ID dan OWNER).
Sekarang kita lakukan query join seperti dibawah ini .
SQL> set autotrace traceonly;
SQL> select t1.*, t2.object_id, t2.owner
2 from t1, t2
3 where t1.object_id = t2.object_id
4 and t2.owner = 'SCOTT';
6 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=16 <-- br="" cost="" lihat=""> ini
1 0 NESTED LOOPS (Cost=16 Card=6 Bytes=630)
2 1 INDEX (FAST FULL SCAN) OF 'T2_INDEX' (NON-UNIQUE) (Cost=
3 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=1 Card=1
Byt
4 3 INDEX (UNIQUE SCAN) OF 'T1$PK' (UNIQUE)
Statistics
----------------------------------------------------------
331 recursive calls
0 db block gets
174 consistent gets <-- br="" i="" logical=""> ...
6 rows processed
SQL>
Perhatikan bahwa untuk mendapatkan 6 ROW ( scott mempunyai 6 object
saja ), oracle membaca menggunakan primary key pada table T1. Dan
logical I/O yang dihasilkan sebanyak 174 block dengan nilai cost = 16.
Sekarang bagaimana kalau saya query dengan owner user lain, misalnya
user EVARA seperti dibawah ini.
SQL> set autotrace traceonly;
SQL> select t1.*, t2.object_id, t2.owner
2 from t1, t2
3 where t1.object_id = t2.object_id
4 and t2.owner = 'EVARA';
102 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=52 <-- br="" cost="" lihat=""> ini
1 0 HASH JOIN (Cost=52 Card=103 Bytes=10815)
2 1 INDEX (FAST FULL SCAN) OF 'T2_INDEX' (NON-
UNIQUE)
3 1 TABLE ACCESS (FULL) OF 'T1' (Cost=40 Card=29518
Bytes=28
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
511 consistent gets <-- br="" i="" logical=""> 1 physical reads
...
102 rows processed
Dan ternyata oracle tidak membaca primary key pada table T1, dia
memilih membaca full table scan. Apakah oracle melakukan kesalahan ?
jawabanya TIDAK. Sekali lagi 100% oracle bergantung dari spesifikasi
masing-masing server. Coba perhatikan parameter dibawah ini,
SQL> set autotrace off
SQL> show parameter index_cost
NAME TYPE
VALUE
---------------------------- ----------- -----------------------------
-
optimizer_index_cost_adj integer
100
Default parameter optimizer_index_cost_adj = 100, sampai oracle 9i
sekarang masing bernilai 100. Parameter ini menceritakan kepada
optimizer bahwa membaca menggunakan index atau menggunakan full table
scan cost-nya adalah sama, otomatis oracle akan memilih full table
scan.
Sekarang set nilai parameter = 30
SQL> alter session set optimizer_index_cost_adj=30;
Session altered.
SQL> select t1.*, t2.object_id, t2.owner
2 from t1, t2
3 where t1.object_id = t2.object_id
4 and t2.owner = 'EVARA';
102 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=41 <-- br="" cost="" lihat=""> ini
1 0 NESTED LOOPS (Cost=41 Card=103 Bytes=10815)
2 1 INDEX (FAST FULL SCAN) OF 'T2_INDEX' (NON-
UNIQUE)
3 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2
Card=1
4 3 INDEX (UNIQUE SCAN) OF 'T1$PK'
(UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
314 consistent gets <-- br="" i="" logical=""> 1 physical reads
...
102 rows processed
Lihat sekarang, oracle sudah membaca primary key lagi pada table T1.
Dan tentu saja untuk mendapatkan record sebanyak 102, cost = 41, dan
logical I/O = 314. performance lebih meningkat dibanding dengang saat
membaca menggunakan full table scan.
Apakah kita harus menurunkan nilai optimizer_index_cost_adj setiap
kali kita menemui bahwa ternyata index tidak terpakai ? saya menjawab
tidak selalu. Jika nilai parameter ini terlalu kecil, maka oracle
juga akan salah menentukan plan-nya.
Perhatikan query dibawah ini, saya akan select owner = 'SYSTEM'
sehingga didapatkan jumlah record yang lebih besar.
SQL> select t1.*, t2.object_id, t2.owner
2 from t1, t2
3 where t1.object_id = t2.object_id
4 and t2.owner = 'SYSTEM';
431 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=53 <-- br="" cost="" lihat=""> ini
1 0 HASH JOIN (Cost=53 Card=431
Bytes=45255)
2 1 INDEX (FAST FULL SCAN) OF 'T2_INDEX' (NON-
UNIQUE)
3 1 TABLE ACCESS (FULL) OF 'T1' (Cost=40 Card=29518
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
533 consistent gets <-- br="" i="" logical=""> 3 physical reads
...
431 rows processed
Untuk mendapatkan 431 ROW milik user SYSTEM, oracle lebih memilih
membaca mengunakan full table scan. Mungkin anda akan bertanya loh,
kalau full table scan kan menjadi lambat. ( TIDAK ).
Sekarang saya turunkan parameter optimizer_index_cost_adj menjadi 5.
Ini akan menjadikan oracle semakin agresif dalam pembacaan mengunakan
index.
SQL> alter session set optimizer_index_cost_adj=5;
Session altered.
SQL> select t1.*, t2.object_id, t2.owner
2 from t1, t2
3 where t1.object_id = t2.object_id
4 and t2.owner = 'SYSTEM';
431 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=26 <-- br="" cost="" lihat=""> ini
1 0 NESTED LOOPS (Cost=26 Card=431 Bytes=45255)
2 1 INDEX (FULL SCAN) OF 'T2_INDEX' (NON-
UNIQUE)
3 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1'
(Cost=2
4 3 INDEX (UNIQUE SCAN) OF 'T1$PK' (UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
1009 consistent gets <-- br="" i="" logical=""> 0 physical
reads
...
431 rows processed
SQL>
Dan sekarang berhasil, oracle membaca menggunakan primary key pada
table T1. Tetapi justru ini adalah kesalahan oracle dalam menentukan
execution plan. Lihat nilai cost diatas, membaca menggunakan index
COST menjadi 26 nilai ini turun dibandingkan pada saat membaca
menggunakan full table scan. Sekarang lihat nilai logical I/O-
nya ...? kini menjadi 1009. Nilai ini justru naik. Ketika masih
membaca menggunakan full table scan logical I/O = 533 sedangkan jika
membaca menggunakan index malah naik menjadi 1009. Nilai cost turun
sedang nilai logical I/O naik, berarti oracle salah menentukan
plannya.
Oleh karena itu belum tentu membaca menggunakan index menjadi
alternatif pembacaan data paling cepat. Dan belum tentu membaca
menggunakan full table scan merupakan metode pembacaan paling lambat.
Semua tergantung dari statistics table masing-masing, dan tergantung
dari spesifikasi databasenya.
Mungkin pak yahya bisa di share cara create indexnya dan hasil dari
execution plannya. Dan hati - hati dalam men-setting nilai parameter
optimizer_index_cost_adj , karena oracle bisa sangat agresif sekali
dan kadang oracle justru salah menilai pembuatan plan.
Semoga ini bisa membantu.
Terima kasih
Evara Samsyiar
www.indodba.net ==================================================================
Selasa, 18 Juni 2013
SQL Decryptor
Didalam database MSSql Server kita dikasih fasilitas untuk melakukan proses encryt pada store procedure yang kita bangun. Tetapi terkadang kita kelupaan apa isi yang ada didalam store procedure tersebut, apalagi jika backupnya tidak ada. yang ada adalah :(.
Jika hal ini terjadi kita bisa membuka store procedure tersebut dengan menggunakan aplikasi yang namanya "dbForge SQL Decryptor". jika tertarik silahkan download langsung ke : http://www.devart.com/dbforge/sql/sqldecryptor/download.html
Rabu, 27 Februari 2013
Cara Dump, Inserrt Data Oracle
Cara dump data dengan Oracle
=====================
exp namauser/password@namaTNS tables=log_transaksi, tabel_lain, tabel_yang_lain file=c:\mydump.dmp
Cara memasukkan data dump jika dengan user dan password sama:
==============================================
imp namauser/password@namaTNS file=mydum.dmp
Cara memasukkan data dump jika user dan password beda, maka harus menggunakan user system
===================================================================
imp system/password_system@namaTNS fromuser=nama_user_dump touser=nama_user_tujuan file=mydump.dmp
Cara memasukkan data dump u/ oracle yg di polda
==================================
Copy file dmp ke direktory "DATA_PUMP_DIR" melihatnya dari toad/plsql di "DIRECTORIES"
impdp dumpfile=nama_file_dump.dmp
jk table spacenya beda dengan tabel space yg baru ginakan perintah berikut
impdp dumpfile=nama_file_dmp.dmp remap_tablespace=nama_table_di_file:nama_table_space_di_oracle_yg_baru
impdp dumpfile=nama_file_dump.dmp remap_schema=schema_asli:schema_tujuan
Cara dump data u/ oracle yg di polda
=========================
expdp dumpfile=nama_file.dmp
expdp dbsifik/passsw directory=data_pump_dir dumpfile=backup_dbsifik_jgj.db
Install Apache, PHP, MySQL
install apache
--------------
yum install httpd
chkconfig httpd on
/etc/init.d/httpd start
install mysql
--------------
yum install mysql mysql-server
install php 5.3
---------------
rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
rpm -Uvh http://repo.webtatic.com/yum/centos/5/latest.rpm
ls -1 /etc/yum.repos.d/epel* /etc/yum.repos.d/webtatic.repo
vi /etc/yum.repos.d/webtatic.repo
edit bagian : enabled=0 menjadi enabled=1
yum install php php-cli php-gd php-mysql php-mbstring
Langganan:
Postingan (Atom)