Taahhüt edilmemiş işlemler neden geriye dönük olarak geri alınmalıdır?

Bazı işlemlerin kazandığı bir veritabanı günlüğüm var (çökmeden önce işlenirler) ve bazıları kaybeder (henüz taahhüt edilmez). Sınıfta kaybedenlerin hareketlerinin geriye doğru yapılması gerektiğini öğrendik.

Bunu geriye doğru yapmak için herhangi bir neden var mı? Herkes ileri geri alma yanlış sonuçlar verecek bir günlük basit bir örnek verebilir misiniz?

Orijinal işlemler:

1. Kayıt ekle .$r$
2. Bazı alan güncelleyin arasında r .$f$$r$

İleri geri alma:

1. Kaydı sil .$r$
2. Güncellemeyi - oh bekleyin, ters çevir r artık yok! Bu bir hataya neden olur.$r$$r$

DylanSp'nin cevabına eklemek için, mevcut olmayan bir kayıttaki bir alanı güncellemeye çalışmak başarısız olur, ancak sonuç yine de beklenen sonuç olacaktır: r kaydı yok.

Ancak, bir kaydın silinmesinin gerçekten başarısız olacağı bir durumu düşünün:

1. Sipariş O girin.
2. Orderline L.'yi ekleyin

Gerçekçi olmayan bir şekilde, her OrderLine'ın bir Order ile ilgili olması gerektiğini varsayalım .

Şimdi Sipariş'i silmeden başlayarak işlemi geri almak başarısız olacaktır çünkü bu bizim iş kuralımızı ihlal edecektir.

Sonra

1. O. Siparişini Sil (BAŞARISIZ)
2. Ordeline L.'yi sil (BAŞARI)

Mevcut bir Siparişle (Sipariş Hattı olmadan) sonuçlanabilir.

Tabii ki, bu durumda basamaklı bir silme kullanabiliriz, ancak bu, 2. adımın (etki olmadan) başarısız olacağı anlamına gelir. Daha da kötüsü, siparişler üzerinde basamaklı silmelerin uygulanması istenmeyen davranışlar olabilir.

Analoji ile gidelim: akşam yemeğine çıkacağınızı söyle.

1. Çorap giy.
2. Ayakkabı giy.
3. Ayağa kalk.
4. Kapıya yürü.

Sonra bir telefon çağrısı alırsınız. Akşam yemeği planları iptal edildi.

1. Çorapları çıkar.
2. Ayakkabıları çıkar.
3. Otur.
4. Kapıdan uzaklaş.

Orada bir şeyler ters gidiyor. Seyahat edebilir ve kendinize zarar verebilirsiniz. Ya da daha büyük olasılıkla, daha sonra yapılacak işlemler önce geri alınana kadar bazı eylemlerin geri alınamayacağını fark edeceksiniz.

Yaptığınız son şeyi geri almak, sizi son adımın bir sonraki adımında bulunduğunuz yere geri götürür. Sonra hiçbir şey kalmayıncaya kadar bu adımı geri alıp tekrarlayın. Diğer yandan, sonraki adımları izleyen durumlar göz önüne alındığında, ilk adımın tersine çevrilmesi mümkün olmayabilir.

matematiksel olarak konuşursak: eylemler işe gidemeyebilir, bu nedenle ilk veya ikinci adımı attığınız zaman önemli olduğunda, adımları geri alma sırası önemli olacaktır.

Bu doğrudur, çünkü işlemler birbiri üzerine inşa edilmiştir ve bir işlemin sonucu büyük ölçüde işlenmeden önceki duruma bağlıdır.

Finansal işlemlere bakalım:

(başlangıçta, işlemler abana 100 USD borç vermeden önce )

1. a bana 100 USD borçlu (şimdi toplam borç 200)
2. abana olan borcundan% 10 indirim alıyor. (şimdi toplam borç 180)

Diyelim ki iki işlemi iptal etmek istiyorum.

İlk ilkini iptal edersek aşağıdakilerle sonuçlanır:

1. düşük borç 100 (şimdi 80 borç var)
2. % 10 indirimi iptal et (şimdi 80 / 0.9 = 88 borcunuz var)

Bu yanlış, 100 borca ​​geri dönmemiz gerekiyor. İşlemleri ters sırada iptal edersek bu doğru olacaktır.

1. indirimi iptal et - şimdi borç 200
2. düşük 100 borç - şimdi borç 100

Yalnızca bir sütunu olan bir tablo T olduğunu varsayın.

"Geri alma günlüğünün", taahhüt edilmemiş işlemleri içeren bir veritabanı dosyası olduğunu ve "yeniden günlüğün", henüz veri dosyalarına uygulanmayan hem taahhüt edilmemiş hem de kaydedilmiş işlemleri içeren bir veritabanı dosyası olduğunu varsayın.

At 8:00 A.M., Transaction 100 inserts rows with values 101, 102 and 103 into table T. At 8:10 A.M., Transaction 100 is committed and the commit for transaction 100 completes. At 8:15 A.M., Transaction 200 updates row 101 to 201, 102 to 202 and 103 to 203. At 8:20 A.M., Transaction 200 has not been committed and remains in the undo log of the database. At 8:25 A.M., Transaction 300 increments each row by 50, changing row 201 to 251, 202 to 252, and 203 to 253. At 8:30 A.M., Transaction 300 has not been committed and remains in the undo log of the database. At 8:35 A.M., The instance providing access to the database crashes.

              The committed values in T are still 101, 102 and 103.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, if they are written into the "redo
              log" of the database, there is a need to "roll back"
              the transactions AFTER the "redo log" is applied.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, they are in the "undo log"
              of the database.

              The undo log of the database is used BOTH to (1) roll
              back a transaction that is deliberately rolled 
              back in the memory structure of the database instance, 
              and also (2) during the instance recovery at 8:40 A.M.

              The undo log has not yet been applied.

At 8:42 A.M., The undo log is applied in the reverse order: Uncommitted transaction 300 is undone, and Uncommitted transaction 200 is undone.

Neden İKİ taahhütlü ve taahhütsüz işlemler yineleme günlük dosyasına yazılır? Bunun nedeni, zamanında nokta kurtarma sağlamaktır.

Bu, "günlüğü yeniden yap" dosyasının içeriğinin işlemle tutarlı OLMADIĞI anlamına gelir. Bu nedenle, yineleme günlüğü veri dosyalarına işlenen işlemleri uygulamak için her kullanıldığında, "geri alma günlüğü" AYRICA, taahhüt edilmemiş işlemleri geri almak için de KULLANILMALIDIR.

"Geri alma günlüğündeki" işlemler neden ters sırada geri alınır? İşlem 300, her satırın her bir sütununun mevcut değerine 50 ekledi. Bu nedenle, önce işlem 200 geri alınırsa, değerler 251, 252 ve 253'ten 201, 202 ve 203'e değişecektir. İşlem 300 daha sonra en son geri alınırsa, değerler 151, 152 ve 153 olur. orijinal taahhütlü değerler.

REFERANSLAR:

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1670195800346464273

Doğası gereği doğru değil. Geri alma, geri alma günlüğünde önbelleğe alınan blokları yeniden uygulayarak son durumun başlangıç ​​durumuyla aynı olmasını sağlar. Günlük ileriye doğru sırada yazıldığı için geri alma işlemimi ileriye doğru sırada da uyguladım. Günlük dosyası yerleşik olarak işaretlenene kadar geri alma yeniden deneneceğinden, siparişin önemi yoktu.