Tôi thấy liên kết Trung tâm thông tin của bạn đi đến LUW 9.7 và bạn đề cập rằng bạn đã lập trình bằng Java, nhưng hầu hết kinh nghiệm tôi có với ràng buộc là với DB2 trên Mainframe với COBOL. Vì vậy, bạn có thể cần điều chỉnh lời giải thích một chút (nhưng nhìn chung, các khái niệm nên giống nhau).
Tôi tin rằng ràng buộc chỉ có liên quan khi bạn biên dịch các chương trình bao gồm SQL nhúng được biên dịch trước (SQL ràng buộc tĩnh). Ví dụ, nếu bạn đang sử dụng JDBC, bạn không cần phải chạy BIND. Trình điều khiển JDBC sẽ PREPAREtuyên bố động.
Khi bạn chạy một chương trình thông qua trình biên dịch trước của DB2, PRECOMPILEchạy qua chương trình của bạn và nếu nó tìm thấy bất kỳ SQL nhúng nào (trong COBOL, thì đây là các khối câu lệnh đi từ EXEC SQLđến END-EXEC.), nó cẩn thận tách SQL ra và thay thế nó bằng một gọi đến giao diện COBOL-DB2. Sau này, có hai kết quả đầu ra PRECOMPILE, nguồn COBOL đã loại bỏ tất cả SQL nhúng ( Akể từ bây giờ) và một đầu DBRMra chứa tất cả SQL đã bị xóa ( B).
Precompile thực hiện một số kiểm tra cú pháp cơ bản, nhưng lưu ý rằng các kiểm tra chỉ dựa trên các khai báo bảng của bạn trong chương trình. Nó không đính kèm với DB2 để xác minh những điều này!
Hai tệp này hoàn toàn riêng biệt và khi bạn chạy chương trình COBOL, nó phải tìm một Avà một tệp Bđược tạo cùng một lúc.
Tại thời điểm này, Ađược biên dịch và liên kết với trình biên dịch COBOL tiêu chuẩn thành một load modulevà được đặt trong thư viện tải để sử dụng sau này.
Tuy nhiên, vẫn còn rất nhiều việc phải làm B, DBRM. Đây là nơi BINDxuất hiện. BINDGiống như một trình biên dịch cho mã SQL nhúng và đầu ra của "biên dịch" là a package.
Để BIND SQL thành một "gói" thực thi, quy trình BIND đính kèm với DB2 và thực hiện một số điều:
- Xác minh rằng AuthID hiện tại được ủy quyền để thực hiện liên kết.
- Kiểm tra cú pháp SQL của bạn, với sự trợ giúp từ dữ liệu trong danh mục DB2.
- Cuối cùng và quan trọng nhất, liên kết sẽ tối ưu hóa SQL của bạn
Trong bước cuối cùng, tất cả SQL của bạn được chạy qua Trình tối ưu hóa, có tính đến tất cả các số liệu thống kê và các đường dẫn khác nhau mà công cụ DB2 có thể thực hiện để lấy dữ liệu của bạn. Sau đó, nó chọn đường dẫn mà nó đưa ra có chi phí thấp nhất đi kèm (với các phiên bản mới hơn của DB2 [DB2 10 cho z / OS] , nó có thể quyết định đi theo con đường "chi phí cao hơn", nhưng "rủi ro thấp hơn"). Khi đường dẫn được chọn, nó được biên dịch và trở thành một gói, được lưu trữ trong danh mục (bạn có thể thấy tất cả các gói hiện tại của mình với SELECT * FROM SYSIBM.SYSPACKAGE(z / OS)).
Cuối cùng, có một mảnh cuối cùng cho phép các chương trình của chúng tôi để đoàn tụ với các gói của họ, PLAN. Bạn tạo một kế hoạch bằng cách thực hiện BIND ( BIND PLAN) khác. Gói là tập hợp các gói mà chương trình được phép xem qua để tìm gói có cùng tên. Với COBOL, bạn chỉ định chương trình nào sẽ tìm kiếm trong JCL của bạn.
Nói tóm lại, mã được biên dịch trải qua các bước sau để tạo ra một ứng dụng BIND PLAN:
Biên dịch trước -> Tạo DBRM (với C [++], bộ biên dịch trước xuất SQL được biên dịch sẵn thành tệp HFS, có thể được gửi qua chương trình liên kết dòng lệnh ) -> DBRM được tối ưu hóa và một bộ đường dẫn truy cập ( a package) được tạo -> Gói được thêm vào a BIND PLAN, đó là một nhóm các gói cho phép bạn tạo một "đường dẫn tìm kiếm" để các chương trình của bạn xem qua.
Vì các chương trình này bị ràng buộc tĩnh, nếu số liệu thống kê bảng của bạn thay đổi mạnh mẽ, thì đường dẫn truy cập mà trình tối ưu hóa đã chọn tại thời điểm liên kết có thể không còn là đường dẫn tốt nhất nữa và liên kết lại sẽ cho phép nó đánh giá lại SQL và có thể chọn một con đường tốt hơn.
Chỉnh sửa (cập nhật để nhận xét): Nếu bạn đang sử dụng bộ xử lý dòng lệnh, bạn có thể chuyển vào một gói liên kết đơn (.bnd) hoặc danh sách tên tệp liên kết (.lst). Nếu bạn vượt qua trong một danh sách, tên tệp phải được thêm vào trước@(ví dụ/path/to/@packages.lst). Trong tệp .lst, bạn có thể đặt từng gói trên một dòng riêng lẻ hoặc bạn có thể tách chúng bằng+:
package1.bnd
package2.bnd
package3.bnd+package4.bnd+package5.bnd