- Timestamp Ordering (TO) { Basic TO
Mô phỏng sự cố giao dịch phân tán (Simulating Distributed Transaction Failure)
Transaction Failure)
Ta có thể buộc sự cố của một giao dịch phân tán vì những nguyên nhân sau:
• Để qsat việc phân giải phần cục bộ của giao dịch RECO một cách tự động.
Tiến trình nền RECO của một thể hiện Oracle phân giải tự động kéo theo các giao dịch phân tán. Ở khoảng thời gian hàm mũ , tiến trình nền RECO của một nút khôi phục phần cục bộ của giao dịch nghi ngờ phân tán .
RECO có thể sử dụng một kết nối đang ttai hay thiết lập kết nối mới liên quan trong giao dịch bị sự cố. Khi một kết nối được thiết lập, RECO tự động phân giải mọi giao dịch nghi ngờ. Các hàng tương ứng đến các giao dịch nghi ngờ bất kỳ được di dời khỏi mỗi bảng giao dịch đang treo của mỗi giao dịch.
Ta có thể cho phep hay vô hiệu RECO dùng lệnh ALTER SYSTEM với các tùy chọn
ENABLE/DISABLE DISTRIBUTED RECOVERY. VD, ta có thể vô hiệu tạm thời RECO để buộc sự cố của chuyển giao 2 pha và phân giải thủ công giao dịch nghi ngờ.
Câu lệnh sau vô hiệu tạm thời RECO:
ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY;
Câu lệnh sau cho phép RECO sao cho các giao dịch nghi ngờ được tự động phân giải :
ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY;Chú ý: Chú ý:
Các thực hiện xử lý đơn (VD,một PC chay MS DOS) không có tiến trình RECO nền riêng rẽ, ta phải phục hồi thủ công dùng câu lệnh trên.
Quản trị tính nhất quán đọc
An important restriction exists in Oracle's implementation of distributed read consistency. The problem arises because each system has its own SCN, which you can view as the database's internal timestamp. The Oracle database server uses the SCN to decide which version of data is returned from a query.
The SCNs in a distributed transaction are synchronized at the end of each remote SQL statement and at the start and end of each transaction. Between two nodes that have heavy traffic and especially distributed updates, the synchronization is frequent. Nevertheless, no practical way exists to keep SCNs in a distributed system absolutely synchronized: a window always exists in which one node may have an SCN that is somewhat in the past with respect to the SCN of another node.
Because of the SCN gap, you can execute a query that uses a slightly old snapshot, so that the most recent changes to the remote database are not seen. In accordance with read consistency, a query can therefore retrieve consistent, but out-of-date data. Note that all data retrieved by the query will be from the old SCN, so that if a locally executed update transaction updates two tables at a remote node, then data selected from both tables in the next remote access contain data prior to the update.
One consequence of the SCN gap is that two consecutive SELECT statements can retrieve different data even though no DML has been executed between the two statements. For example, you can issue an update statement and then commit the update on the remote database. When you issue a SELECT statement on a view based on this remote table, the view does not show the update to the row. The next time that you issue the SELECT
statement, the update is present.
You can use the following techniques to ensure that the SCNs of the two machines are synchronized just before a query:
• Because SCNs are synchronized at the end of a remote query, precede each remote query with a dummy remote query to the same site, for example, SELECT * FROM DUAL@REMOTE.
• Because SCNs are synchronized at the start of every remote transaction, commit or roll back the current transaction before issuing the remote query.
= = =