Transaksi itu adalah serangkaian logical unit yang berisi satu atau lebih SQL
statement.
Jadi UPDATE account set balx=100; bisa dikategorikan sebuah transaksi menurut
definisi di atas, kalo setelah itu anda commit (artinya anda nyatakan bahwa
transaksi benar) atau anda rollback (artinya anda nyatakan bahwa transaksi anda
salah dan dibatalkan).
Nah pokoknya seluruh query yang kita lakukan dan merubah database yang terdapat
di oracle bisa di katakan sebuah transaksi jika query tersebut di akhiri dengan
commit atau rollback.
Karena dengan commit maka oracle akan menjamin bahwa transaksi yang anda
lakukan pasti direfleksikan ke data file. Berbeda kalo anda rollback, maka
oracle menjamin transaksi yang anda lakukan pasti tidak akan ter-refleksikan ke
data file anda.
Mungkin dibawah ini bisa memperjelas :
Misalkan kita ingin transfer uang dari account A ke B sebesar 1500.
Nah implementasinya seperti ini : (kalo pake sql plus dengan autocommit off)
===============================
update cust_accounts
set balance = balance - 1500
where
account_no = 'A';
update cust_accounts
set balance = balance + 1500
where
account_no = 'B';
commit;
===============================
Jadi transaksi tersebut adalah satu kesatuan walau dieksekusikan 2 kali. Asal
pada saat eksekusi query yang pertama kita tidak langsung commit. (Karena bisa
jadi kalo kita commit pada query yang pertama dan ketika mau mengeksekusi query
yang kedua terjadi crash dan transaksi tersebut error, maka bisa dipastikan
uang akan hilang, karena uang account A sudah berkurang didatabase sedang uang
account B belum bertambah).
Atau cara yang lain mungkin anda bikin dalam sebuah prosedur yang menampung
kedua query diatas lalu setelah itu baru di commit. Maka akan di anggap sebagai
satu kesatuan transaksi juga.
Nah disinilah keindahan dari transaksi tersebut, anda bisa memainkan dan
mengeset semua sesuai dengan yang anda inginkan. Karena yang diketahui oracle
hanya commit dan rollback, tinggal bagaimana anda sendiri yang mengatur agar
transaksi tersebut tetap konsisten dan tidak bertentangan dengan ACID property.
Andalah yang harus mengatur aturan sebuah transaksi tersebut dimulai dari mana
dan sampai mana sebuah transaksi tersebut harus berakhir.
Maaf kalo mungkin belum bisa menjawab pertanyaan. Mohon yang lain bisa
mengevaluasi kalo ada salah.
Heriyanto KO <[EMAIL PROTECTED]> wrote: terima
kasih buat jawabanya,
tapi untuk teknik SQL atau pemrogramanya gimana?
apakah suatu perintah SQL biasa
misalnya
UPDATE account set balx=100;
apakah bisa tergolong transaksi? atau harus ada selbih dari 1 SQL?
trus kalo SQL dg begin dan end; ?? -->
begin
UPDATE account set balx=100;
end;
/
bedanya apa?
tora fahrudin <[EMAIL PROTECTED]> wrote:
Ya mungkin mau ngejawab ... tapi mungkin tidak sempurna banget ya .. entar
biar temen temen yang lain nambahin atau ngeralat kalo saya salah.
Transaksi adalah kasus di mana sebuah resource database di akses oleh banyak
orang .. dan dalam waktu yang bisa jadi dilakukan secara bersamaan ... dimana
dalam kasus ini database harus mampu merepresentasikan transaksi tersebut
seperti kenyataan yang terjadi di dunia nyata.
Transaksi mungkin akan dilakukan dalam sebuah query ... nah contohnya seperti
ini :
A transfer ke B 50 . Rekening A mula mula 100 , B juga 100.
Nah prosedur transaksi yang dilakukan adalah sebagai berikut :
A ||
B
===============================================
read(A); // A = 100 ||
A := A - 50 ; // A = 50 ||
write(A); // A = 50 ||
|| read(B); //
B = 100;
|| B := B + 50;
// B = 150;
|| write(B);
transaksi didalam database harus memenuhi 4 syarat yaitu :
A: Atomicity => Transaksi harus berjalan secara atomik .. kalo
dalam eksekusi sebuah transaksi ada
gagal ... maka lebih baik bagi DBMS untuk
menggagalkan transaksi tersebut .. agar
kondisi database tetap konsisten ..
Dalam kasus di atas terjadi kalo misalkan setelah A
berkurang 50 , ternyata jaringan putus sehingga transaksi
B yang harusnya bertambah 50 tidak di laksanakan .. nah
kondisi seperti ini harus di tanggulangi oleh
DBMS , kalo seperti itu kan nilai rekening B
tetap 100 tetapi rekening A dah jadi 50 .. nah
duit yang 50 kemana ?? he..he.. Oleh
karena itu DBMS harus menjamin kalo transaksi gagal di
tengah jalan lebih baik di gagalkan sekalian .. jadi rekening
si A tetap seperti semula sebelum transfer .. A = 100 dan
B pun tetap 100.
C: Consistency => adalah kondisi dimana database harus konsisten ..
merefleksikan kondisi real yang terjadi di
dunia nyata.
Mungkin dalam kasus di atas ..
konsisten adalah ketika transfer berarti
jumlah A + B sebelum transaksi transfer kan
harusnya sama dengan kondisi jumlah A + B setelah
transfer. jadi A + B sebelum transfer kan 200 (asalnya dari
100 + 100) , nah kondisi setelah transfer harusnya tetep
200 dengan rincian ( A = 50 dan B = 150).
I : Isolation => kalo ini berkaitan dengan transparansi sebuah
transaksi dari pengaruh transaksi lain yang sama
sama mengakses sebuah resource .. pada waktu yang
bersamaan . Nah DBMS memberikan pilihan
bagi kita untuk menset pilihan
transparansi.Macam macamnya read committed , serializable
, read only , repeatable read . Nah penjelasan dari masing
masing bisa di lihat di
http://www.answers.com/topic/isolation-computer-science
Intinya pada saat bertransaksi , sejauh mana kita bisa
melihat perubahan perubahan yang terjadi pada resource
yang kita akses dari perubahan yang sedang dilakukan pada
resource tersebut oleh transaksi yang lain pada
saat itu juga.
D: Durability => Artinya ketika sebuah transaksi dinyatakan lancar dan
sukses , maka effek dari transaksi tersebut
harus di jamin terrefleksikan di database kita .
Jadi dalam kasus di atas kalo misalkan transaksi
transfer tersebut sukses ... maka harus di jamin
data rekening A di databse sudah berubah menjadi 50.
dan rekening B menjadi 150
Dalam kasus distributed database berarti resource di ambil dari lebih dari
satu database server . Nah dalam konsepnya mungkin agak berbeda sedikit dengan
single transaction database .. karena memerlukan pengaturan dari transaction
manajer pada tiap tiap site yang berpartisipasi dalam menjalankan sebuah
transaksi tersebut . Diperlukan pengaturan conncurency dan locking yang
terkoordinasi dengan baik antar site site tersebut agar jalannya transaksi
tetap tidak mengganggu integrasi dari database itu sendiri .
Mungkin temen temen ada yang menambahkan ... maaf bila ada yang salah dan
kurang menjawab pertanyaan .
Heriyanto KO <[EMAIL PROTECTED]> wrote: oh
ya buat sobat-sobat indo-oracle,
g agak bingung nih dgn yg namanya traksanski pada oracle.
sebenarnya transaksi itu apa sih?
bedanya dengan PL/SQL atau SQL apa?
kalo di distributed database transaction menjadi kata nomor 1 yang sering
dibicarakan?
thanks b4
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[Non-text portions of this message have been removed]
Hormat,
Tora Fahrudin
---------------------------------
Groups are talking. We´re listening. Check out the handy changes to
Yahoo! Groups.
[Non-text portions of this message have been removed]
---------------------------------
Get your email and more, right on the new Yahoo.com
[Non-text portions of this message have been removed]
Hormat,
Tora Fahrudin
---------------------------------
Get your email and more, right on the new Yahoo.com
[Non-text portions of this message have been removed]
--
-----------I.N.D.O - O.R.A.C.L.E---------------
Keluar: [EMAIL PROTECTED]
Website: http://indo-oracle.blogspot.com
Mirror: http://indooracle.wordpress.com
-----------------------------------------------
Bergabung dengan Indonesia Thin Client User Groups,
Terminal Server, Citrix, New Moon Caneveral, di:
http://indo-thin.blogspot.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/indo-oracle/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
