Chuyển đến nôi dung chính

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

Khi bạn đăng ký với trang developerWorks lần đầu tiên, một tiểu sử của của bạn được tạo ra. Chọn các thông tin về tiểu sử của bạn (tên, nước/vùng, và nơi làm việc) đã được hiện lên màn hình, thông tin này sẽ được hiện kèm với nội dung mà bạn đăng tải. Bạn có thể cập nhật thông tin này bất kỳ lúc nào.

Thông tin gửi đi được đảm bảo an toàn.

  • Đóng [x]

Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

Thông tin gửi đi được đảm bảo an toàn.

  • Đóng [x]

Tận dụng cơ sở dữ liệu dự phòng DB2 HADR

Sử dụng khả năng đọc trên cơ sở dữ liệu dự phòng

Samir Katti, Chuyên gia kiểm định phần mềm, IBM
Ảnh của Samir Katti
Samir Katti làm việc như kỹ sư kiểm định chức năng cho cơ sở dữ liệu quan hệ DB2 từ 3 năm rưỡi nay. Ông là thành viên tích cực của nhóm kiểm định tính năng đọc trên cơ sở dữ liệu dự phòng HADR. Ông có bằng Thạc sĩ khoa học máy tính tại trường Đại học bang Oregon.
Jing Xu, Chuyên viên phát triển phần mềm, IBM
Ảnh của Jing Xu
Jing Xu là nhà phát triển phần mềm đã làm việc về phát triển và kiểm thử DB2 cho hệ điều hành Linux, UNIX và Windows trong phòng thí nghiệm IBM tại Trung Quốc trong 4 năm qua. Ông đã tham gia vào FVT (thử nghiệm kiểm định chức năng) cho tính năng đọc trên cơ sở dữ liệu dự phòng HADR, và hiện đang làm việc trong nhóm phát triển HADR.

Tóm tắt:  Khả năng khôi phục cao sau sự cố (HADR - High Availability Disaster Recovery) là tính năng sao lưu dữ liệu dễ sử dụng của IBM® DB2 cho hệ điều hành Linux®, UNIX® và Windows®, nó cung cấp giải pháp sẵn sàng cao (HA) cho cả sự cố của từng bộ phận hay toàn phần. Kể từ gói vá lỗi 1 của DB2 phiên bản 9.7 1 trở đi, cơ sở dữ liệu dự phòng cho phép truy cập và đọc từ các ứng dụng của người sử dụng. Bài viết này giải thích cách làm thế nào để sử dụng khả năng này cho các ứng dụng đọc và các hạn chế hiện tại là gì. Ngoài ra, nó cũng bao gồm các đề xuất những cách để bạn có thể sử dụng các tiềm năng của cơ sở dữ liệu dự phòng.

Ngày:  07 02 2013
Mức độ:  Trung bình Bản gốc tiếng Anh  tại đây
Hoạt động:  669 lần đọc
Góp ý kiến:  


Giới thiệu và nền tảng

Tính năng khôi phục cao sau sự cố (HADR) của DB2 trên Linux, UNIX và Windows là tính năng sao lưu cơ sở dữ liệu cung cấp giải pháp sẵn sàng cao cho cả sự cố từng bộ phận hay toàn phần. HADR bảo vệ chống mất mát dữ liệu bằng sao lưu các thay đổi dữ liệu từ cơ sở dữ liệu nguồn được gọi là cơ sở dữ liệu chính, đến cơ sở dữ liệu đích được gọi là cơ sở dữ liệu dự phòng.

HADR đã được đưa vào từ phiên bản DB2 8.2. Trước khi phát hành bản vá lỗi 1 của DB2 9.7, máy chủ dự phòng chỉ chuyển tiếp các bản ghi đến từ máy chủ chính, và hoàn toàn cách ly với người sử dụng. Không cho phép bất ký kết nối nào từ người dùng đến cơ sở dữ liệu dự phòng.

Từ bản vá lỗi 1 của DB2 9.7 1 trở đi, tính năng đọc cơ sở dữ liệu dự phòng (HADR RoS) cho phép các ứng dụng read-only được truy cập vào cơ sở dữ liệu dự phòng. Điều này có thể làm được chỉ khi tính năng đọc cơ sở dữ liệu dự phòng được kích hoạt. Với tính năng này, các ứng dụng đọc/ghi có thể truy cập vào cơ sở dữ liệu HADR chính và các ứng dụng read-only có thể truy cập vào cơ sở dữ liệu chính hoặc cơ sở dữ liệu dự phòng. Điều này cho phép bạn chuyển bớt khối lượng công việc read-only đang chạy trên cơ sở dữ liêu chính sang cơ sở dữ liệu dự phòng. Các ứng dụng kết nối với cơ sở dữ liệu dự phòng không ảnh hưởng đến sự sẵn sàng của cơ sở dữ liệu dự phòng trong trường hợp có sự cố.

Bài viết này giải thích cách thiết lập tính năng để đọc trên cơ sở dữ liệu dự phòng và thảo luận về những hạn chế của việc đọc từ cơ sở dữ liệu dự phòng hiện tại. Ngoài ra, bài viết bao gồm các đề xuất cho việc sử dụng tiềm năng của cơ sở dữ liệu dự phòng. Bài viết này giả định người đọc đã quen với việc thiết lập một cặp HADR.

Thiết lập tính năng đọc ở cơ sở dữ liệu dự phòng

Cơ sở dữ liệu dự phòng của cặp HADR có thể được sử dụng để hỗ trợ các ứng dụng read-only. Cơ sở dữ liệu dự phòng có thể được cho phép ở trong chế độ đọc bằng cách thiết lập giá trị của biến đăng ký DB2_HADR_ROS. Biến đăng ký được bật lên ON để cho phép đọc cơ sở dữ liệu dự phòng. Việc thiết lập biến đăng ký không theo phương thức động. Nói cách khác, máy chủ dự phòng phải được dừng lại và khởi động lại để việc thay đổi các biến đăng ký có hiệu lực. Nếu trong trường hợp cơ sở dữ liệu dự phòng trở thành chính để tiếp quản hoạt động, biến đăng ký sẽ không có bất kỳ tác dụng nào trên cơ sở dữ liệu chính mới. Khả năng đọc được hỗ trợ cho các chế độ đồng bộ của HADR: ASYNC, NEARSYNC, SYNC và SUPERASYNC. Khả năng đọc không được hỗ trợ khi cơ sở dữ liệu dự phòng ở trạng thái bắt kịp nội tại.

Thực hiện các bước sau để thiết lập DB2_HADR_ROS.

  1. Sau khi thiết lập cặp HADR, kiểm tra xem DB2_HADR_ROS đã được bật chưa.
    db2 => !db2set
  2. Việc kết nối đến cơ sở dữ liệu dự phòng phải đưa ra kết quả SQL1776 rc = 1, như trong liệt kê 1.

    Liệt kê 1. Kết nối tới cơ sở dữ liệu dự phòng
     
    db2 => connect to hadrdb
    SQL1776N  The command is not supported on an HADR standby database or on an
    HADR standby database with the current configuration or state.  Reason code =
    "1".
    

  3. Thiết đặt biến DB2_HADR_ROS, như trong liệt kê 2.

    Liệt kê 2. Thiết đặt biến
     
    db2 => !db2set DB2_HADR_ROS=ON
    db2 => !db2set
    DB2_HADR_ROS=ON 
    

  4. Khởi động lại máy chủ để biến đăng ký có hiệu lực, như trong liệt kê 3.

    Liệt kê 3. Khởi động lại máy chủ
                     
     db2 => deactivate db hadrdb
    DB20000I  The DEACTIVATE DATABASE command completed successfully.
    db2 => !db2stop
    SQL1064N  DB2STOP processing was successful.
    db2 => !db2start
    SQL1063N  DB2START processing was successful.
    

  5. Kích hoạt và kết nối với cơ sở dữ liệu dự phòng, như trong liệt kê 4.

    Liệt kê 4. Kích hoạt và kết nối
     
    db2 => activate db hadrdb
    DB20000I  The ACTIVATE DATABASE command completed successfully.
    db2 => connect to hadrdb
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.5
     SQL authorization ID   = KATTI
     Local database alias   = HADRDB
    

Xác minh thiết lập HADR sử dụng tính năng đọc cơ sở dữ liệu dự phòng (RoS)

Người dùng thường muốn xác minh rằng việc thiết lập HADR đang làm việc như mong đợi và rằng không mất dữ liệu sau khi cặp HADR được định cấu hình. Trước bản vá lỗi 1 của DB2 phiên bản 9.7, bạn phải sử dụng lệnh TAKEOVER để làm cho máy chủ dự phòng trở thành máy chủ chính mới để xác minh thiết lập HADR. Không kết nối nào được phép trên máy chủ dự phòng, vì nó là ngắt tuyến đối với người sử dụng. Vì vậy, rất khó để kiểm tra dữ liệu ở cơ sở dữ liệu dự phòng. Cách duy nhất để đưa cơ sở dữ liệu dự phòng thành trực tuyến là dùng lệnh TAKEOVER.

Cần thực hiện quy trình sau đây để xác minh HADR trước khi RoS đã sẵn sàng.

  1. Về phía cơ sở dữ liệu chính, thực hiện một số thay đổi, chẳng hạn như tạo ra một bảng và chèn các giá trị, như trong liệt kê 5.

    Liệt kê 5. Các thay đổi cho máy chủ chính
    
    [1049] [xjcd@db2eng63] /home/xjcd
    => db2 connect to hadrdb
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.5
     SQL authorization ID   = XJCD
     Local database alias   = HADRDB
    
    [1050] [xjcd@db2eng63] /home/xjcd
    => db2 "create table t1(c1 int)"
    DB20000I  The SQL command completed successfully.
    
    [1051] [xjcd@db2eng63] /home/xjcd
    => db2 "insert into t1 values(123)"
    DB20000I  The SQL command completed successfully.
    
    [1052] [xjcd@db2eng63] /home/xjcd
    => db2 connect reset
    DB20000I  The SQL command completed successfully.
    

  2. Ở phía bên dự phòng, chạy lệnh TAKEOVER HADR và kiểm tra các thay đổi được thực hiện trên máy chủ chính, như trong liệt kê 6.

    Liệt kê 6. Kiểm tra các thay đổi trên máy chủ dự phòng
                        
                        
    [898] [xjcd@db2eng64] /home/xjcd
    
    => db2 takeover hadr on db hadrdb 
    DB20000I  The TAKEOVER HADR ON DATABASE command completed successfully.
    
    [899] [xjcd@db2eng64] /home/xjcd
    
    => db2 connect to hadrdb
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.5
     SQL authorization ID   = XJCD
     Local database alias   = HADRDB
    
    [900] [xjcd@db2eng64] /home/xjcd
    
    => db2 "select * from t1"
    
    C1         
    -----------
            123
    
      1 record(s) selected.
    

Với tính năng đọc cơ sở dữ liệu dự phòng được kích hoạt sau gói vá lỗi 1 DB2 phiên bản 9.7, việc xác minh các thiết lập HADR trở nên dễ dàng hơn nhiều. Kết nối có thể được thiết lập trực tiếp đến cơ sở dữ liệu dự phòng, do đó, không cần phải chạy lệnh tiếp quản.

Thực hiện các bước sau đây để xác minh HADR sử dụng RoS.

  1. Về phía cơ sở dữ liệu chính, thực hiện một số thay đổi đến cơ sở dữ liệu, như trong liệt kê 7.

    Liệt kê 7. Tạo các thay đổi đến cơ sở dữ liệu chính
    
    
    [1049] [xjcd@db2eng63] /home/xjcd
    => db2 connect to hadrdb
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.5
     SQL authorization ID   = XJCD
     Local database alias   = HADRDB
    
    [1050] [xjcd@db2eng63] /home/xjcd
    => db2 "create table t1(c1 int)"
    DB20000I  The SQL command completed successfully.
    
    [1051] [xjcd@db2eng63] /home/xjcd
    => db2 "insert into t1 values(123)"
    DB20000I  The SQL command completed successfully.
    
    [1052] [xjcd@db2eng63] /home/xjcd
    => db2 connect reset
    DB20000I  The SQL command completed successfully.
    

  2. Kết nối với cơ sở dữ liệu dự phòng ngay sau khi RoS được kích hoạt và kiểm tra các thay đổi được thực hiện trên cơ sở dữ liệu chính, như trong liệt kê 8.

    Liệt kê 8. Kiểm tra các thay đổi trên cơ sở dữ liệu dự phòng
    
    [910] [xjcd@db2eng64] /home/xjcd
    => db2 connect to hadrdb
    
       Database Connection Information
    
     Database server        = DB2/LINUXX8664 9.7.5
     SQL authorization ID   = XJCD
     Local database alias   = HADRDB
    
    [911] [xjcd@db2eng64] /home/xjcd
    
    => db2 "select * from t1"
    
    C1         
    -----------
            123
    
      1 record(s) selected.
    


Cửa sổ chỉ chạy lại (replay-only) trên cơ sở dữ liệu dự phòng

Khi cơ sở dữ liệu dự phòng của một HADR đang hoạt động đang chạy lại các bản ghi nhật ký DDL hoặc các hoạt động bảo dưỡng, cơ sở dữ liệu phòng được đưa vào cửa sổ replay-only. Khi đó, các kết nối hiện có tới cơ sở dữ liệu này bị chấm dứt và các kết nối mới đến nó đều bị chặn (mã nguyên nhân số 4 -SQL1776N). Các kết nối mới đến cơ sở dữ liệu dự phòng chỉ được phép sau khi tất cả các giao dịch tạo ra DDL hoặc bảo trì đã hoàn thành. Ứng dụng hiện có bắt buộc phải ngắt ở cửa vào của cửa sổ replay-only và một lỗi được trả về (SQL1224N). Có thể nhận được trạng thái của cửa sổ replay-only bằng cách thực hiện lệnh db2pd -db tên_cơ_sở_dữ_liệu -hadr trên cơ sở dữ liệu dự phòng.

Thực hiện các bước sau đây.

  1. Sau khi thiết đặt cặp HADR và thiết lập kết nối đến cơ sở dữ liệu dự phòng, thực hiện lệnh sau, thể hiện trong liệt kê 9, để có được các ứng dụng đang hoạt động trên cơ sở dữ liệu dự phòng.

    Liệt kê 9. Lấy trạng thái của ứng dụng trên cơ sở dữ liệu dự phòng
                      
    db2 => list applications
    Auth Id  Application    Appl.      Application Id            DB       # of
             Name           Handle                               Name     Agents
    -------- -------------- ---------- --------------            -------- -----
    KATTI    db2bp          13         *LOCAL.katti.120305194800 HADRDB   1 
    

  2. Kiểm tra xem cửa sổ chỉ chạy lại đang hoạt động hay không hoạt động trên cơ sở dữ liệu dự phòng, như trong liệt kê 10.

    Liệt kê 10. Checking replay only window
    
    db2 => !db2pd -db hadrdb -hadr
    
    Database Partition 0 -- Database HADRDB -- Active Standby -- Up 0 days 00:05:37 – 
    Date 03/05/2012 11:50:58
    
    HADR Information:
    Role    State                SyncMode   HeartBeatsMissed   LogGapRunAvg (bytes)
    Standby Peer                 Sync     0                  3298
    
    ConnectStatus ConnectTime                           Timeout
    Connected     Mon Mar  5 11:45:26 2012 (1330976726) 120
    
    ReplayOnlyWindowStatus ReplayOnlyWindowStartTime             MaintenanceTxCount
    Inactive                       N/A                                   0
    
    LocalHost                                LocalService
    grebe                                    DB2_katti
    
    RemoteHost                               RemoteService      RemoteInstance
    petrel                                   xkatti             katti
    
    PrimaryFile  PrimaryPg  PrimaryLSN
    S0000001.LOG 13         0x000000000235DFB6
    
    StandByFile  StandByPg  StandByLSN         StandByRcvBufUsed
    S0000001.LOG 13         0x000000000235DFB6 0%
    

  3. Phát giao dịch không cam kết có chứa DDLtrên cơ sở dữ liệu chính, như trong liệt kê 11.

    Liệt kê 11. Phát hành một giao dịch không được giao kết
                         
    db2 => update command options using c off
    DB20000I  The UPDATE COMMAND OPTIONS command completed successfully.
    
    db2 => create table t1(c1 int, c2 int)
    DB20000I  The SQL command completed successfully.
                     

  4. Kiểm tra xem cửa sổ chỉ chạy lại có hoạt động hay không, như trong liệt kê 12.

    Liệt kê 12. Checking the replay only window
     
    db2 => !db2pd -db hadrdb -hadr
    
    Database Partition 0 -- Database HADRDB -- Active Standby -- Up 0 days 00:10:26 
    -- Date 03/05/2012 11:55:47
             
    HADR Information:
    Role    State                SyncMode   HeartBeatsMissed   LogGapRunAvg (bytes)
    Standby Peer                 Sync       0                  1441
    
    ConnectStatus ConnectTime                           Timeout
    Connected     Mon Mar  5 11:45:26 2012 (1330976726) 120
    
    ReplayOnlyWindowStatus  ReplayOnlyWindowStartTime             MaintenanceTxCount
    Active                          Mon Mar  5 11:54:09 2012 (1330977249) 1
    
    LocalHost                                LocalService
    grebe                                    DB2_katti
    
    RemoteHost                               RemoteService      RemoteInstance
    
    petrel                                   xkatti             katti
    
    PrimaryFile  PrimaryPg  PrimaryLSN
    S0000001.LOG 15         0x000000000235FCFC
    
    StandByFile  StandByPg  StandByLSN         StandByRcvBufUsed
    S0000001.LOG 14         0x000000000235EE8A 0% 
    

  5. Kiểm tra xem các ứng dụng hiện tại đã bị ngắt ra hay chưa, như trong liệt kê 13.

    Liệt kê 13. Các ứng dụng hiện tại
                     
    db2 => list applications
    SQL1611W  No data was returned by Database System Monitor.
    

  6. Kiểm tra xem kết nối mới có bị chặn hay không, như trong liệt kê 14.

    Liệt kê 14. Các kết nối mới
     
     db2 => connect to hadrdb
    SQL1776N  The command is not supported on an HADR standby database or on an
    HADR standby database with the current configuration or state.  Reason code =
    "4".
    

Như vậy, các cửa sổ reply-only rõ ràng là có ảnh hưởng đến công việc của người sử dụng trên cơ sở dữ liệu dự phòng. Nếu RoS được bật cho phép tại cơ sở dữ liệu dự phòng, hãy đảm bảo rằng bạn đã làm như sau:

  • Lên kế hoạch để làm cho tất cả các hoạt động sẽ tạo ra các cửa sổ replay-only xuất hiện cùng nhau trong một khoảng thời gian ngắn trên máy chủ chính.
  • Bật cho phép giao kết tự động trên máy chủ chính để cửa sổ replay-only càng ngắn càng tốt.
  • Tắt tính năng bảo trì tự động trên cả máy chủ chính và dự phòng, như trong liệt kê 15.

    Liệt kê 15. Tắt tính năng bảo trì tự động trên cơ sở dữ liệu chính và dự phòng
    
    => db2 UPDATE DATABASE CFG FOR hadrdb USING AUTO_MAINT OFF AUTO_RUNSTATS OFF 
           AUTO_REORG OFF 
    DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
    

Để có danh sách đầy đủ các câu lệnh DDL và các hoạt động bảo trì, xin vui lòng tham khảo liên kết đến DB2 Information Center trong phần Tài nguyên để biết thêm thông tin về bài viết này.


Gắn kết gói package đến cơ sở dữ liệu dự phòng

Thông thường, ứng dụng có chứa SQL cần phải được biên dịch trước thành tệp tin nguồn của ngôn ngữ chủ chứa SQL với các API của DB2, và sau đó kết buộc với cơ sở dữ liệu tương ứng. Bạn có thể sử dụng lệnh trong môi trường dòng lệnh db2 là PREP để biên dịch trước các ứng dụng SQL. Theo mặc định, gói package sẽ được tạo ra tự động tại thời gian trước khi biên dịch. Nếu muốn, bạn có thể chỉ định tùy chọn BINDFILE trong lệnh PREP, để tạo ra tệp tin kết buộc (.bnd), và sau khi biên dịch, tiện ích BIND có thể được sử dụng với tập tin kết buộc để tạo ra gói package trong cơ sở dữ liệu cho ứng dụng này. Khi cấu trúc hoặc số liệu thống kê của các bảng, mà ứng dụng có SQL truy cập, bị thay đổi, thì ứng dụng cần được kết buộc lại một cách tường minh hoặc ngầm.

Thực hiện các bước sau đây để tiền biên dịch và kết buộc.

  1. Chạy lệnh PREP với tùy chọn BINDFILE để tạo tập tin kết buộc (sample.bnd), như trong liệt kê 16.

    Liệt kê 16. Lệnh PREP với tùy chọn BINDFILE
    
    => db2 prep sample.sqc bindfile
    
    LINE    MESSAGES FOR sample.sqc
    ------  --------------------------------------------------------------------
            SQL0060W  The "C" precompiler is in progress.
            SQL0091W  Precompilation or binding was ended with "0" 
                      errors and "0" warnings.  
    

  2. Sử dụng tiện ích BIND để tạo gói package trong cơ sở dữ liệu, như trong liệt kê 17.

    Liệt kê 17. Sử dụng tiện ích BIND
                   
     => db2 bind sample.bnd
    
    LINE    MESSAGES FOR sample.bnd
    ------  --------------------------------------------------------------------
            SQL0061W  The binder is in progress.
            SQL0091N  Binding was ended with "0" errors and "0" warnings.
    

Lưu ý rằng cả lệnh tiền biên dịch và kết buộc yêu cầu bạn phải kết nối với cơ sở dữ liệu.

Như đã thảo luận ở phần trước, không cho phép ghi trên cơ sở dữ liệu dự phòng HADR. Vì vậy, lệnh kết buộc (bind) và tái kết buộc (rebind) không được phép trên cơ sở dữ liệu dự phòng, bởi vì chúng sẽ ghi vào cơ sở dữ liệu. Khi bạn đang cố gắng kết buộc gói package với cơ sở dữ liệu dự phòng, mã nguyên nhân lỗi số 5 là SQL1773N sẽ được báo lại như trong liệt kê 18..


Liệt kê 18. Lỗi khi kết buộc tới cơ sở dữ liệu dự phòng

=> db2 bind sample.bnd 

LINE    MESSAGES FOR sample.bnd
------  --------------------------------------------------------------------
        SQL0061W  The binder is in progress.
        SQL1773N  The statement or command requires functionality 
                  that is not supported on a read-enabled HADR standby 
                  database. Reason code = "5".
        SQL0082C  An error has occurred which has terminated 
                  processing.
        SQL0092N  No package was created because of previous errors.
        SQL0091N  Binding was ended with "3" errors and "0" warnings.
        

Khi bạn cần kết buộc hoặc tái kết buộc gói package tới cơ sở dữ liệu dự phòng, bạn phải kết buộc/tái kết buộc với cơ sở dữ liệu chính. Các hoạt động này được chuyển đến và chạy lại trên máy chủ dự phòng vì sẽ có bản ghi nhật ký cho chúng.

Sau khi kết buộc/tái kết buộc, bạn có thể sao chép tệp nhị phân thực thi của ứng dụng đến máy chủ nơi cơ sở dữ liệu dự phòng lưu trú và sau đó chạy ứng dụng. Tuy nhiên, hãy chú ý đến các lệnh kết buộc/tái kết buộc. Chúng sẽ kích hoạt cửa sổ chỉ chạy lại trên cơ sở dữ liệu dự phòng.


Mức cô lập trên cơ sở dữ liệu dự phòng

Những ứng dụng đọc trên cơ sở dữ liệu dự phòng chỉ có thể chạy ở mức cô lập đọc không cam kết (Uncommitted Reads-UR). Lý do của hạn chế này là DB2 HADR dựa trên việc gửi đi bản ghi nhật ký (log shipping). Như bạn biết, giao dịch trên máy chủ chính sẽ sinh ra các bản ghi nhật ký, và các bản ghi nhật ký sẽ được gửi đến cơ sở dữ liệu dự phòng. Cơ sở dữ liệu dự phòng làm lại theo các bản ghi nhật ký, giống như việc chuyển tiếp sau khi khôi phục lại cơ sở dữ liệu, để đảm bảo tính nhất quán dữ liệu với cơ sở dữ liệu chính. Tuy nhiên, các khóa cần thiết cho mức độ cô lập cao hơn UR không được chuyển đến cơ sở dữ liệu dự phòng và ứng dụng đọc sẽ không giành được bất kỳ khóa nào khi chạy lại các bản ghi nhật ký. Nói ngắn gọn thì dữ liệu trên cơ sở dữ liệu dự phòng không được bảo vệ bởi bất kỳ khóa nào, do đó, các ứng dụng trên cơ sở dữ liệu dự phòng chỉ có thể đọc ở mức độ cô lập UR.


Liệt kê 19. Lỗi khi đọc ở mức cô lập cao hơn UR

=> db2 "select * from t1 with RR"

C1         
-----------
SQL1773N  The statement or command requires functionality that is not 
supported on a read-enabled HADR standby database. Reason code = "1".

Nếu một số ứng dụng read-only hiện có được thực hiện ở mức cô lập cao hơn UR và bạn không muốn chúng bị hỏng do lỗi của mức độ cô lập này, bạn chỉ có thể ép buộc chúng chạy ở mức độ cô lập UR một cách ngầm định bằng cách thiết lập biến đăng ký DB2_STANDBY_ISO, như trong liệt kê 20.


Liệt kê 20. Lỗi khi đọc ở mức cô lập cao hơn UR

=> db2set DB2_STANDBY_ISO=UR
# We need to restart DB2 instance here so that this registry variable take effect
=> db2 connect to testdb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.5
 SQL authorization ID   = XJCD
 Local database alias   = TESTDB

=> db2 "select * from t1 with RR"

C1         
-----------
          1
          2
          3

  3 record(s) selected.

Đối với các ứng dụng read-only cần nhiều hơn so với mức độ cô lập UR, bạn chỉ có thể chạy chúng trên cơ sở dữ liệu chính.


Các thống kê trên cơ sở dữ liệu dự phòng

Các thống kê của các đối tượng cơ sở dữ liệu là cần thiết cho trình tối ưu hóa SQL khi tạo ra các kế hoạch truy cập. Nếu bạn không có số liệu thống kê chính xác, trình tối ưu hóa có thể sẽ chọn kế hoạch truy cập không có chi phí thấp nhất và hiệu suất truy vấn sẽ bị ảnh hưởng.

Tiện ích RUNSTATS được sử dụng để thu thập số liệu thống kê trong DB2. Nó sẽ lấy mẫu các đối tượng được quy định (bảng hoặc chỉ mục) và tính toán các số liệu thống kê, sau đó ghi các kết quả vào các bảng danh mục hệ thống có lược đồ là SYSSTAT. Bởi vì hoạt động ghi không được phép trên cơ sở dữ liệu dự phòng HADR, tiện ích RUNSTATS không có sẵn ở cơ sở dữ liệu dự phòng.

Trong trường hợp bạn muốn cập nhật các số liệu thống kê về cơ sở dữ liệu dự phòng để cải thiện hiệu suất truy vấn cho các ứng dụng trên cơ sở dữ liệu dự phòng, bạn có các lựa chọn thay thế sau đây.

  • Chạy RUNSTATS trên cơ sở dữ liệu chính. Đúng vậy, cách thiết yếu nhất và dễ nhất là chạy RUNSTATS trên cơ sở dữ liệu chính. Vì RUNSTATS sẽ ghi các kết quả vào các bảng danh mục của hệ thống, các bản ghi nhật ký tương ứng sẽ được tạo ra và chúng sẽ được chuyển đến cơ sở dữ liệu dự phòng, và sẽ được thực hiện lại. Vì vậy, các số liệu thống kê trên cơ sở dữ liệu dự phòng sẽ được cập nhật.
  • Cập nhật bằng cách thủ công trực tiếp bảng danh mục thống kê. Tuy nhiên, rõ ràng là RUNSTATS trong giải pháp 1 sẽ có một số tác động về hiệu quả trên cơ sở dữ liệu chính. Một số trường trong các bảng danh mục thống kê có thể được cập nhật, vì vậy bạn có thể cập nhật các số liệu thống kê bằng cách thủ công khi bạn cần. Tuy nhiên, sẽ có một số rủi ro để cập nhật các bảng danh mục, do đó, hãy cẩn thận nếu chọn dùng giải pháp này.
  • Sử dụng profile tối ưu hóa để chỉ ra kế hoạch cho trình tối ưu hóa. Đồng thời, có thể là một số điều kiện cho cơ sở dữ liệu chính và cơ sở dữ liệu dự phòng là không giống nhau, mặc dù điều này không được khuyến cáo. Ví dụ: một vùng bảng trên cơ sở dữ liệu chính có hộp chứa với hiệu suất tốt hơn so với cơ sở dữ liệu dự phòng, các số liệu thống kê trên cơ sở dữ liệu chính không áp dụng được ở cơ sở dữ liệu dự phòng. Trong trường hợp này, bạn phải thực hiện kế hoạch truy cập khác trên cơ sở dữ liệu chính so với trên cơ sở dữ liệu dự phòng cho cùng một truy vấn.

Bạn có thể chỉ rõ các hướng dẫn về tối ưu hóa cho các truy vấn, hoặc các hướng dẫn nội dòng hay profile tối ưu hóa. Thông thường, bạn chèn các profile tối ưu hóa (các tập tin XML) vào bảng SYSTOOLS.OPT_PROFILE và sau đó kích hoạt các profile này trước khi thực hiện các truy vấn. Trình tối ưu hóa của DB2 sẽ tạo ra và chọn kế hoạch truy cập theo các profile tối ưu hóa. Để biết thêm chi tiết về sử dụng profile tối ưu hóa, hãy tham khảo bài viết "Chi phối tối ưu hóa truy vấn bằng các lược thảo tối ưu hóa và các khung nhìn thống kê trong DB2 9" trong phần Tài nguyên để biết thêm thông tin.

Vì hoạt động ghi bị chặn trên các cơ sở dữ liệu dự phòng, bạn không thể chèn các profile tối ưu hóa vào bảng SYSTOOLS.OPT_PROFILE trên cơ sở dữ liệu dự phòng. Cách vòng tránh điều này sẽ là chèn vào các profile trên cơ sở dữ liệu chính, và sau đó các bản ghi nhật ký tương ứng sẽ được chuyển đến cơ sở dữ liệu dự phòng. Sau khi bản ghi nhật ký được thực hiện lại, thì các profile tối ưu hóa sẽ có mặt trong cơ sở dữ liệu dự phòng và sẵn sàng để sử dụng.


Xử lý LOBs trên các máy chủ dự phòng

Trước khi bản vá lỗi 5 của DB2 9.7 được phát hành thì không cho phép đọc các đối tượng lớn (LOB) nào chẳng hạn như BLOB, CLOB hoặc DBCLOB trên cơ sở dữ liệu dự phòng. Tất cả các LOB được lưu trữ trong vùng bảng tách biệt khỏi các cột không LOB trước DB2 9.7 . Khi bạn cố đọc LOB, bạn sẽ nhận được một mã trả lại SQL1773N, là mã nguyên nhân số 1, như trong liệt kê 21.


Liệt kê 21. Các LOB không nội dòng bị chặn ở cơ sở dữ liệu dự phòng

=> db2 "select C2 from T"  

C2
-----------------------
SQL1773N  The statement or command requires functionality that is not 
supported on a read-enabled HADR standby database. Reason code = "1".

Các LOB nội dòng được đưa vào DB2 9.7. Những LOB này được lưu trữ trong cùng các vùng bảng như của cột không LOB . Trong phiên bản 9.7 gói vá lỗi 5 và các phiên bản sau đó, các LOB nội dòng được hỗ trợ tại cơ sở dữ liệu dự phòng. Vì vậy, đối với các LOB nhỏ, bạn nên chuyển chúng thành nội dòng nếu có thể. Để kiểm tra xem cột LOB trong một hàng có là nội dòng hay không, có thể sử dụng hàm bảng ADMIN_IS_INLINED, như trong liệt kê 22.


Liệt kê 22. Kiểm tra xem cột LOB có nội dòng hay không


=> db2 "select ADMIN_IS_INLINED(c1) from t2"

1     
------
     1

  1 record(s) selected.


Kết quả truy vấn bằng 1 nghĩa là cột của hàng này là nội dòng, và 0 có nghĩa là không phải là nội dòng.


Kết luận

Kể từ DB2 phiên bản 9.7 với bản vá lỗi 1, DB2 cung cấp khả năng đọc cơ sở dữ liệu dự phòng với tính năng HADR. Bạn có thể đưa các ứng dụng read-only vào cơ sở dữ liệu dự phòng. Khả năng này có thể giúp bạn cân bằng tải công việc trên máy chủ chính. Do có sự chuyển bản ghi nhật ký và cơ chế chạy lại, sẽ có một số hạn chế tại cơ sở dữ liệu dự phòng cho các ứng dụng chỉ đọc. Bài viết này đã mô tả những hạn chế này và cho thấy cách làm thế nào để cho các ứng dụng trên cơ sở dữ liệu dự phòng chạy một cách hiệu quả, bao gồm:

  • Thiết lập biến đăng ký DB2_HADR_ROS = ON để cho phép tính năng RoS.
  • Thực hiện giao dịch có chứa các câu lệnh DDL càng ngắn càng tốt trên máy chủ chính để giảm tác động của cửa sổ chỉ chạy lại trên máy chủ dự phòng.
  • Kết buộc các gói package trên máy chủ chính, và chạy các ứng dụng tương ứng trên máy chủ dự phòng.
  • Sử dụng mức độ cô lập đọc không cam kết (UR) cho các ứng dụng trên máy chủ dự phòng.
  • Biến các LOB ngắn thành nội dòng nếu có thể để chúng có thể được truy cập trên cơ sở dữ liệu dự phòng.

Chúng tôi hy vọng rằng bạn có thể sử dụng các tính năng RoS một cách hiệu quả và dễ dàng hơn sau khi đọc bài viết này.


Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Đôi nét về các tác giả

Ảnh của Samir Katti

Samir Katti làm việc như kỹ sư kiểm định chức năng cho cơ sở dữ liệu quan hệ DB2 từ 3 năm rưỡi nay. Ông là thành viên tích cực của nhóm kiểm định tính năng đọc trên cơ sở dữ liệu dự phòng HADR. Ông có bằng Thạc sĩ khoa học máy tính tại trường Đại học bang Oregon.

Ảnh của Jing Xu

Jing Xu là nhà phát triển phần mềm đã làm việc về phát triển và kiểm thử DB2 cho hệ điều hành Linux, UNIX và Windows trong phòng thí nghiệm IBM tại Trung Quốc trong 4 năm qua. Ông đã tham gia vào FVT (thử nghiệm kiểm định chức năng) cho tính năng đọc trên cơ sở dữ liệu dự phòng HADR, và hiện đang làm việc trong nhóm phát triển HADR.

Hướng dẫn về "Phản ánh nội dung không thích hợp

Phản ánh về nội dung không thích hợp

Cám ơn. Nhận xét này sẽ được báo cho người chủ mục tin.


Hướng dẫn về "Phản ánh nội dung không thích hợp

Phản ánh về nội dung không thích hợp

Gửi phản ánh bị lỗi. Làm ơn thử lại sau.


developerWorks: Đăng nhập


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng (tiếng Anh).

 


Khi bạn đăng nhập lần đầu tiên, một bản trích ngang trên developerWorks sẽ được tạo ra. Chọn các thông tin trong trích ngang của developerWorks để hiển thị công khai, bạn có thể sửa lại thông tin này bất cứ lúc nào. Tên, họ và tên hiển thị sẽ đi kèm với nội dung mà bạn gửi lên.

Choose your display name

Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

(Độ dài phải từ 3 đến 31 ký tự)


Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng (tiếng Anh).

 


Chấm điểm bài này

Bình luận

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Information Management
ArticleID=857566
ArticleTitle=Tận dụng cơ sở dữ liệu dự phòng DB2 HADR
publish-date=02072013