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 <[email protected]> wrote: From: Ujang Jaenudin <[email protected]> Subject: Re: [indo-oracle] Re: Proses yang dijalankan ketika Truncate Data To: [email protected] 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]
