Ada 2 cara mas, kita coba pake SQL PLUS juga (* dengan men-set TIMING ON) dan Via aplikasi pak .. jadi capture waktu awal dan capture waktu akhir juga lalu di hitung response timenya dari 2 capture-an tersebut.
Thanks, Tora Fahrudin http://torafahrudin.wordpress.com (-- ^_^ --) --- On Thu, 3/26/09, Yulius Wibowo <[email protected]> wrote: From: Yulius Wibowo <[email protected]> Subject: [indo-oracle] Re: Proses yang dijalankan ketika Truncate Data To: [email protected] Date: Thursday, March 26, 2009, 11:25 PM Tora, Boleh tahu nggak ya, "alat ukur" apa yg Tora gunakan utk mengukur waktu TRUNCATE & DELETE tsb? Apakah menggunakan SET TIMING ON? atau ??? bw --- In indo-oracle@ yahoogroups. com, ** Tora Fahrudin ** <tora_ifstt03@ ...> wrote: > > > Makasih pencerahannya juga mas ujang. Tapi kira kira apa ya yang menyebabkan > truncate pada data yang kecil malah lebih lambat. :) > > Thanks, > > Tora Fahrudin http://torafahrudin .wordpress. com > > (-- ^_^ --) > > > --- On Tue, 3/24/09, Ujang Jaenudin <ujang.jaenudin@ ...> wrote: > > From: Ujang Jaenudin <ujang.jaenudin@ ...> > Subject: Re: [indo-oracle] Re: Proses yang dijalankan ketika Truncate Data > To: indo-oracle@ yahoogroups. com > Date: Tuesday, March 24, 2009, 9:09 PM > > > > > > > > > > > > > create table t10 (a number, b number, c number) tablespace users; > > > > select extent_id,file_ id,block_ id,blocks from dba_extents where > > segment_name= 'T10'; > > > > insert into t10 values(1,1,1) ; > > 6x > > commit; > > > > alter system dump datafile 4 block min 953 block max 961; > > > > Block header dump: 0x010003bd > > Object id on Block? Y > > seg/obj: 0xf839 csc: 0x00.13b5f4 itc: 2 flg: E typ: 1 - DATA > > brn: 0 bdba: 0x10003b9 ver: 0x01 opc: 0 > > inc: 0 exflg: 0 > > > > Itl Xid Uba Flag Lck Scn/Fsc > > 0x01 0x000e.01d.0000024e 0x07000548.00c8. 1e --U- 6 fsc > 0x0000.0013b672 > > 0x02 0x0000.000.00000000 0x00000000.0000. 00 ---- 0 fsc > 0x0000.00000000 > > > > data_block_dump, data header at 0x7700a64 > > ============ === > > tsiz: 0x1f98 > > hsiz: 0x1e > > pbl: 0x07700a64 > > bdba: 0x010003bd > > 76543210 > > flag=------- - > > ntab=1 > > nrow=6 > > frre=-1 > > fsbo=0x1e > > fseo=0x1f50 > > avsp=0x1f32 > > tosp=0x1f32 > > 0xe:pti[0] nrow=6 offs=0 > > 0x12:pri[0] offs=0x1f8c > > 0x14:pri[1] offs=0x1f80 > > 0x16:pri[2] offs=0x1f74 > > 0x18:pri[3] offs=0x1f68 > > 0x1a:pri[4] offs=0x1f5c > > 0x1c:pri[5] offs=0x1f50 > > block_row_dump: > > tab 0, row 0, @0x1f8c > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > tab 0, row 1, @0x1f80 > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > tab 0, row 2, @0x1f74 > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > tab 0, row 3, @0x1f68 > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > tab 0, row 4, @0x1f5c > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > tab 0, row 5, @0x1f50 > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > end_of_block_ dump > > > > truncate table t10; > > > > alter system dump datafile 4 block min 953 block max 961; > > > > Block header dump: 0x010003bd > > Object id on Block? Y > > seg/obj: 0xf839 csc: 0x00.13b5f4 itc: 2 flg: E typ: 1 - DATA > > brn: 0 bdba: 0x10003b9 ver: 0x01 opc: 0 > > inc: 0 exflg: 0 > > > > Itl Xid Uba Flag Lck Scn/Fsc > > 0x01 0x000e.01d.0000024e 0x07000548.00c8. 1e --U- 6 fsc > 0x0000.0013b672 > > 0x02 0x0000.000.00000000 0x00000000.0000. 00 ---- 0 fsc > 0x0000.00000000 > > > > data_block_dump, data header at 0x7700a64 > > ============ === > > tsiz: 0x1f98 > > hsiz: 0x1e > > pbl: 0x07700a64 > > bdba: 0x010003bd > > 76543210 > > flag=------- - > > ntab=1 > > nrow=6 > > frre=-1 > > fsbo=0x1e > > fseo=0x1f50 > > avsp=0x1f32 > > tosp=0x1f32 > > 0xe:pti[0] nrow=6 offs=0 > > 0x12:pri[0] offs=0x1f8c > > 0x14:pri[1] offs=0x1f80 > > 0x16:pri[2] offs=0x1f74 > > 0x18:pri[3] offs=0x1f68 > > 0x1a:pri[4] offs=0x1f5c > > 0x1c:pri[5] offs=0x1f50 > > block_row_dump: > > tab 0, row 0, @0x1f8c > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > tab 0, row 1, @0x1f80 > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > tab 0, row 2, @0x1f74 > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > tab 0, row 3, @0x1f68 > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > tab 0, row 4, @0x1f5c > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > tab 0, row 5, @0x1f50 > > tl: 12 fb: --H-FL-- lb: 0x1 cc: 3 > > col 0: [ 2] c1 02 > > col 1: [ 2] c1 02 > > col 2: [ 2] c1 02 > > end_of_block_ dump > > > > kalau diperhatikan, sebenarnya isi data (row data masih ada) cuman > > oracle hanya set flag pada header object/segment tsb (di block header > > sini antara block id 953-954 karena by default di BMB ini oracle > > allocate 2 block untuk headernya, sedangkan 1 block block id 955 mulai > > digunakan data, indikasinya dari " unformatted: 5 total: 8 > > first useful block: 3 "), supaya block2 yg pernah kepakai > > data bisa direplace. > > > > malah segment yg ditruncate ini bisa direcover dengan bantuan BBED > > asalkan belum keduluan oleh block cleanout (beberapa test case > > sepertinya jalan, not sure in the real world). > > > > 2009/3/25 ** Tora Fahrudin ** <tora_ifstt03@ yahoo.com>: > > > Ok makasih mas bowo, > > > > > > Tapi saya masih bingung kok semakin banyak data justru proses TRUNCATE jadi > > lebih cepat, sedangkan semakin sedikit data malah semakin lambat. Kenapa > > tidak linear dengan jumlah datanya. > > > > > > Makasih mas bowo. > > > > > > > > > Thanks, > > > > > > Tora Fahrudin http://torafahrudin .wordpress. com > > > > > > (-- ^_^ --) > > > > > > > > > --- On Tue, 3/24/09, Yulius Wibowo <yulius_wibowo@ yahoo.com> wrote: > > > > > > From: Yulius Wibowo <yulius_wibowo@ yahoo.com> > > > Subject: [indo-oracle] Re: Proses yang dijalankan ketika Truncate Data > > > To: indo-oracle@ yahoogroups. com > > > Date: Tuesday, March 24, 2009, 6:15 PM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tora san, > > > > > > > > > > > > TRUNCATE: adalah perintah DDL (Data Definition Language). > > > > > > Yg diupdate adalah informasi dari tablenya di dalam data dictionary. > > > > > > - Jumlah extent di reset ke minimum extent. > > > > > > - High Water Mark (HWM) di reset ke bagian depan/awal. Sehingga data yg ada > > di atas HWM dianggap tidak ada/kosong. > > > > > > - Semua bekas extent akan di-release, dan bisa dipakai ulang oleh segment > > ybs atau segment yg lain. > > > > > > > > > > > > DELETE: adalah perintah DML (Data Manipulation Language) > > > > > > - Jumlah extent tetap. > > > > > > - HWM tidak berubah > > > > > > - Yg dihapus adalah record2nya (sesuai dgn kriteria/WHERE clause-nya) > > > > > > > > > > > > Analognya sama dengan kalau kita memformat Floppy Disk: > > > > > > - Format biasa = DELETE > > > > > > ---> Setiap sector dari FD akan dihapus satu persatu > > > > > > ---> butuh waktu lama sesuai dengan jumlah sektor > > > > > > > > > > > > - Quick format = TRUNCATE > > > > > > ---> Yg dihapus hanya FAT-nya saja > > > > > > ---> butuh waktu cepat > > > > > > > > > > > > b...@jp > > > > > > > > > > > > --- In indo-oracle@ yahoogroups. com, ** Tora Fahrudin ** <tora_ifstt03@ > > ...> wrote: > > > > > >> > > > > > >> > > > > > >> Dear all, > > > > > >> > > > > > >> Salam untuk teman teman semua, maaf gak pernah nongol kok tiba tiba nanya > >> :D > > > > > >> > > > > > >> Begini, ada rekan yang tau tidak bagaimana proses Truncate pada sebuah > >> tabel itu? > > > > > >> > > > > > >> Saya agak heran dengan perlakuan truncate pada tabel yang sama dengan isi > >> data 5 baris, 10 baris, 20 baris, 50 baris, 100 baris. > > > > > >> > > > > > >> Yang mengejutkan adalah waktu / response time dari perintah TRUNCATE > >> tersebut menunjukkan bahwa trendnya justru tidak sebanding dengan jumlah > >> data. Justru semakin kecil baris data yang ada, waktu TRUNCATE malah lebih > >> lama. > > > > > >> > > > > > >> Kira kira apa ya penyebabnya. Percobaan sudah di coba berkali kali, bahkan > >> skenario di rubah yaitu jumlah baris 100 d TRUNCATE. 50 baris di TRUNCATE > >> dst tetap menghasilkan response time yang sama -> TRUNCATE lebih lama jika > >> jumlah data semakin sedikit. > > > > > >> > > > > > >> Mohon bantuan rekan rekan semua. Terima kasih ^_^ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Non-text portions of this message have been removed] > [Non-text portions of this message have been removed]
