1. Mở Đầu
Trong thế giới ngân hàng hiện đại, việc thực hiện các giao dịch lớn một cách hiệu quả và an toàn là rất quan trọng. Hãy xem xét một ví dụ đơn giản về giao dịch ngân hàng: giả sử một khách hàng giàu có muốn chuyển 1.000.000 đô la từ tài khoản tiết kiệm sang tài khoản thanh toán của mình. Để hoàn tất giao dịch này, ứng dụng ngân hàng cần thực hiện các bước quan trọng sau:
- Giảm số dư tài khoản tiết kiệm xuống 1.000.000 đô la.
- Tăng số dư tài khoản thanh toán lên 1.000.000 đô la.
- Thực hiện các thao tác liên quan đến giao dịch trong ứng dụng ngân hàng.
Tính chất nguyên tử (atomicity) của giao dịch yêu cầu rằng cả ba bước này phải hoàn tất thành công hoặc hoàn toàn thất bại. Nếu khách hàng nhập sai số tài khoản thanh toán, giao dịch sẽ không thể hoàn thiện. Điều này dẫn đến việc số dư tài khoản tiết kiệm đã bị giảm mà không có sự tăng tương ứng trong tài khoản thanh toán, làm tổn hại đến tính toàn vẹn dữ liệu.
Một ứng dụng ngân hàng tốt sẽ hiển thị thông báo lỗi hợp lý và cho phép khách hàng nhập lại thông tin để tiếp tục giao dịch.
2. Giải Quyết Vấn Đề
Khi tạo ra một giao dịch thao tác với cơ sở dữ liệu, Oracle sẽ tự động tạo ra dữ liệu undo nhằm duy trì trạng thái trước khi giao dịch diễn ra. Dữ liệu này cần được lưu trữ trong các phân đoạn undo cho đến khi người dùng thực hiện commit hoặc rollback. Nếu không còn không gian đủ cho dữ liệu undo trước khi giao dịch kết thúc, bạn sẽ gặp lỗi (như ORA-30036: unable to extend segment...) và thường phải thực hiện rollback, dẫn đến việc tất cả các thao tác đã làm đều bị hủy.
Giả sử bạn có một giao dịch lớn T1 thực hiện 1.000 lệnh SQL, điều này có thể tạo ra nhiều dữ liệu undo. Nếu cơ sở dữ liệu hết không gian undo khi đang thực hiện lệnh SQL thứ 500, bạn sẽ phải rollback và mất tất cả những gì đã thực hiện trước đó.
Để giải quyết vấn đề này, từ góc nhìn của lập trình viên, có một số giải pháp như sau:
- Tối ưu hóa câu lệnh SQL để giảm thiểu tài nguyên tiêu thụ, bao gồm không gian undo cần thiết. Đây là giải pháp tốt nhất và luôn nên được ưu tiên đầu tiên.
- Yêu cầu DBA cấp thêm không gian undo để tránh tình trạng thiếu hụt trong quá trình giao dịch. Đây là phương án chấp nhận được nếu đã tối ưu hóa mà vẫn gặp khó khăn.
- Chia giao dịch thành các phần nhỏ hơn và thực hiện commit gián đoạn để giảm lượng không gian undo cho mỗi giao dịch. Tuy nhiên, đây là cách làm tồi nhất vì nó có thể làm tổn hại tính toàn vẹn dữ liệu và làm phức tạp mã nguồn.
Hãy tưởng tượng nếu bạn thực hiện commit sau các bước mà một bước gặp lỗi, dữ liệu đã được commit sẽ không thể hoàn tác, gây ra tình trạng không nhất quán. Thêm vào đó, việc commit liên tục sẽ làm mã nguồn trở nên phức tạp hơn và làm chậm hiệu suất hệ thống do tạo ra nhiều bản ghi redo-log.
Một ví dụ để bạn hình dung là thực hiện insert 10.000 bản ghi:
- Kịch bản 1: Commit mỗi bản ghi trong vòng lặp.
- Kịch bản 2: Commit một lần cho tất cả các bản ghi.
Kết quả cho thấy kịch bản 1 tiêu tốn khoảng 360% thời gian so với kịch bản 2. Điều này chứng tỏ rằng số lượng dữ liệu tăng lên sẽ làm thời gian thực hiện tăng đáng kể.
3. Kết Luận
Từ những phân tích ở trên, chúng ta có thể khẳng định rằng trong Oracle, việc commit nên dựa trên nhu cầu thực tế của giao dịch chứ không chỉ dựa trên lượng tài nguyên có sẵn. Commit tạm thời không thể tiết kiệm tài nguyên một cách sai lầm, vì điều này có thể làm giảm tính toàn vẹn của dữ liệu, tăng tiêu thụ tài nguyên và dẫn tới việc phát triển mã nguồn phức tạp hơn.
Do đó, hãy điều chỉnh tài nguyên Oracle dựa trên yêu cầu kinh doanh, đồng thời cố gắng sử dụng tài nguyên một cách hiệu quả nhất.
4. Kết Nối Thảo Luận
Nếu bạn muốn trao đổi thêm về bài viết này, hãy kết nối với tôi qua LinkedIn hoặc Facebook:
- LinkedIn: nguyentrungnam
- Facebook: trungnam.nguyen.395
Rất mong được trao đổi và thảo luận cùng bạn!
source: viblo
