DBMS中的耐久性究竟意味着什麼？

Question

從Durability

一旦用戶發出提交命令，則該事務是寫入到諸如 硬盤，這是在確認到之前進行存儲的非易失性介質上的數據庫文件第一 用戶發現保存 。如果數據庫在保存之前崩潰，則在下次數據庫重新啓動時，事務日誌上的數據仍爲 ，但 任何未提交的更改都會撤消或回滾。

1. 說，我開始交易
2. 消防第一插入語句;
3. 第二次插入聲明;
4. commit;
5. 事務結束

現在，當用戶沒有在步驟4，

1. 所有插入語句在時間T1寫入事務日誌文件系統提交
2. 確認發送到用戶的交易儘管它將在時間T2的步驟3中完成
3. 現在在時間T3異步實現了trasanctions

以上理解正確嗎？如果是，我的問題爲什麼不在第3步之後發送確認？另外如果數據庫機器在T2之前崩潰，那麼事務將不會持久？ 所以原木，我們只是保證如果數據庫崩潰的B/W時間T2和T3那麼我們就可以確保耐久性

第二種理解 我相信所有事務的發言可以儘快日誌寫成的語句被激發，而不是在提交時做這件事。一旦提交完成，事務日誌將被標記爲提交併發送確認。現在即使數據庫確認後崩潰，數據庫將確保從事務日誌寫入數據庫文件。因此，基本上，不是在提交時一次性寫入所有事務語句，而是在它們觸發時在日誌中寫入語句。在提交的時候，它只是標誌着這些交易的承諾，最終將在DB塊寫入原木

這個問題從Oracle的角度

Answer 1

你的第二個認識是密切。

正如你還提及文章說

耐久性現代關係數據庫系統通常是通過交易來實現 日誌 - 可回收文件 - 用來存儲 所有數據庫事務在一個會話文件

沒有提交完成時，

1. 第一個數據庫供應商，標記該會話提交中的所有事務。
2. 然後將這些交易數據永久存儲在數據庫文件中。
3. 然後發送確認給用戶
4. 現在即使dB在步驟1後崩潰，啓動時數據庫供應商可以讀取在日誌中提交的事務，但完成的事務未寫入DB塊。因此，將完成這些交易，並回滾未提交者日誌

不過是如果DB第1步自己之前崩潰，那麼就不會被持久即使其在交易不寫啓動日誌中