Tài liệu Mua giấy phép sử dụng các máy chủ DB2 9.7 phân tán trong môi trường sẵn sàng cao (HA) pdf

Mua giấy phép sử dụng các máy chủ DB2 9.7 phân
tán trong môi trường sẵn sàng cao (HA)
Khách hàng chọn DB2 làm cơ sở dữ liệu ưa thích của họ bởi vì thời gian chứng tỏ giá trị (time to
value) rất sớm của nó, khả năng mở rộng và tích hợp trong các môi trường khác nhau của nó,
tính bền chắc của nó, và khả năng thời gian ngừng chạy tối thiểu (cả có kế hoạch lẫn ngoài kế
hoạch). Trong bài viết này, chúng tôi tập trung vào các khía cạnh của tính sẵn sàng cao (HA) của
DB2, không đề cập quá nhiều về chức năng (đã nhiều người viết về vấn đề này), mà về cấp
quyền.
Chúng tôi nghe rất nhiều câu hỏi về cấp phép cho DB2 trong môi trường có tính sẵn sàng cao, đó
là các cấu hình được thiết kế để giải quyết các trường hợp ngừng chạy ngoài kế hoạch (và đôi khi
cả các trường hợp có kế hoạch nữa). Thông thường, cái gây lúng túng nhất là do có sự khác nhau
rất lớn trong việc các nhà cung cấp định giá bán các sản phẩm cơ sở dữ liệu của họ trong môi
trường sẵn sàng cao.
Một nguồn nhầm lẫn khác là từ các thuật ngữ được dùng khi thảo luận liên quan đến tính sẵn
sàng cao. Ví dụ: thuật ngữ các cụm (clusters). Đôi khi ngành công nghiệp CNTT đề cập đến môi
trường tính sẵn sàng cao là các cụm. Chúng tôi không thích tiếp tục sử dụng thuật ngữ này theo
kiểu ấy nữa, vì nó đã trở thành cái gì đó quá tải trong thời gian gần đây, theo đó các cụm có thể
nói đến việc tạo cụm để có khả năng mở rộng (giống như tính năng phân hoạch của cơ sở dữ liệu
InfoSphere Warehouse (DPF) – tính năng này dựa trên DB2) hoặc tạo cụm để có tính sẵn sàng
(Ví dụ: bằng cách sử dụng phần mềm phân cụm của hệ thống tự động Tivoli cho đa nền tảng
(SA-MP), lần đầu tiên được đưa vào trong DB2 9 và sau đó được tích hợp sâu trong phiên bản
DB2 9,5 cho nhóm các máy chủ), hoặc cả hai (như trường hợp cụm của DB2 pureScale, hoặc hệ
thống phân tích thông minh của IBM). Mặc dù không thích thuật ngữ này, nhưng nó đã được sử
dụng, vì thế đối với bài viết này, khi nói đến thuật ngữ cụm, chúng tôi muốn nói tạo cụm để cho
tính sẵn sàng cao (trừ khi có ghi chú khác). Để đơn giản, chúng tôi khuyên bạn nên gắn thêm các
chữ khả năng sẵn sàng cao hay khả năng mở rộng với thuật ngữ này khi thảo luận về các cụm với
các đồng nghiệp hoặc khách hàng của bạn. Tất nhiên, một số giải pháp đề cập đến cả hai, cả khả
năng mở rộng lẫn tính sẵn sàng cao bằng một cụm, vì thế, hãy đảm bảo rằng bạn luôn luôn
truyền đạt những gì bạn đang cố gắng làm khi nói chuyện với đồng nghiệp của bạn.
Một nguồn nhầm lẫn khác phát sinh từ các thuật ngữ sử dụng để mô tả các máy chủ hoạt động
như máy chủ chuyển đổi dự phòng trong trường hợp có sự cố ngừng hoạt động. Ví dụ: Máy chủ

này có thể được nói đến như là máy chủ dự phòng hoặc máy chủ thứ cấp (và nhiều tên gọi khác).
Nếu bạn đã dính líu đến chúng trong khoảng thời gian đủ dài, thì nhiều khả năng là bạn đã gặp
các thuật ngữ mô tả chức năng mà máy chủ này thực hiện. Các thuật ngữ như nhàn rỗi, đang
hoạt động, lạnh, ấm, nóng, và thụ động tất cả đều được dùng trong các cuộc thảo luận về tính sẵn
sàng.
Phần lớn các tài liệu của Tập đoàn phần mềm của IBM (IBM SWG) sử dụng cách phân loại lạnh,
ấm và nóng để mô tả các máy chủ ở chế độ chờ. Trước phiên bản DB2 9.5, mọi thứ trong lãnh
địa của DB2 ("DB2-land") có hơi khác. Tuy nhiên, kể từ phiên bản DB2 9.5 (và các phiên bản
sau này), cách phân loại khả năng sẵn sàng cao (HA) của DB2 và các điều khoản cấp giấy phép
cho nó tuân thủ cách phân loại của IBM SWG và các điều khoản cấp giấy phép tương ứng phù
hợp với chính sách định giá cho khả năng sẵn sàng cao. Ví dụ: Nếu bạn định cấu hình cho cụm
khả năng sẵn sàng cao của DB2 9.1 HA bằng cách sử dụng PowerHA IBM AIX (còn gọi là Đa
xử lý cụm khả năng sẵn sàng cao - High Availability Cluster Multiprocessing - HACMP), sao
cho có một máy chủ nhàn rỗi (và trình quản lý cơ sở dữ liệu chưa khởi chạy), thì bạn cũng phải
mua giấy phép sử dụng một phần máy chủ đó. Kể từ DB2 phiên bản 9.5 trở đi, bạn không phải
trả một xu nào nữa! Tương tự như vậy, nếu bạn đã cài đặt DB2 phiên bản 9.1 tại một máy chủ
không nối nguồn, bạn cũng đã phải mua phép sử dụng một phần cho máy chủ đó. Kể từ DB2
phiên bản 9.5 và các phiên bản sau đó bạn không phải mua mua giấy phép cho máy chủ DB2
không được nối nguồn. Chúng tôi đã cập nhật bài viết cho DB2 phiên bản 9.7 và bất kỳ thay đổi
tạm thời nào như là kết quả của gói vá lỗi để giúp bạn phân loại các quy định cấp phép sử dụng
cho khả năng sẵn sàng cao của DB2 và để bạn nắm được mọi thông tin.
Lưu ý: Bài viết này cũng bàn về công nghệ pureScale DB2 được công bố lần đầu vào tháng 10
năm 2009. Phương tiện để phân phối DB2 pureScale là DB2 phiên bản 9.8; Tuy nhiên, lý do duy
nhất để chạy DB2 phiên bản 9.8 là cho DB2 pureScale. Nói cách khác, nếu bạn đang chạy máy
chủ DB2 phiên bản 9.7 và không có kế hoạch để sử dụng DB2 pureScale, bạn sẽ không phải
chuyển sang DB2 phiên bản 9.8.
Hình 1 mô tả rõ ràng cách phân loại khả năng sẵn sàng cao của DB2 phiên bản 9.7 và cung cấp
một số ví dụ của từng loại cấu hình thuộc từng cách phân loại ấy.

Hình 1. Một số gợi ý hữu ích cho cách phân loại khả năng sẵn sàng cao như là nóng, ấm, và

lạnh của DB2 9.7

Bảng 1 cho thấy các thuật ngữ thường sử dụng nhất để mô tả môi trường sẵn sàng cao được ánh
xạ với cách phân loại DB2 9.7 và các điều khoản cấp phép sử dụng.

Bảng 1. Ánh xạ các thuật ngữ về tính sẵn sàng cao công nghiệp với các điều khoản cấp
phép sử dụng DB2 9.7.
Lạnh Ấm Nóng
DB2 được cài đặt trên máy chủ
nhằm mục đích dự phòng
Phần mềm cơ sở dữ liệu được
cài đặt trên máy ch
ủ nhằm mục
đích dự phòng
Phần mềm cơ sở dữ liệu được
cài đặt trên máy chủ nhằm
mục đích dự phòng
Cá thể cơ sở dữ liệu chưa được
khởi chạy, và sẽ được khởi chạy
chỉ khi chuyển đổi dự phòng xảy
ra.
Cá thể cơ sở dữ liệu được khởi
chạy, và nó cũng có thể nhận
được các thông tin cập nhật từ
cơ sở dữ liệu chính cho mục
đích khả năng sẵn sàng cao.
Không có sự truy cập của
người sử dụng cuối cùng nào
vào cơ sở dữ liệu dự phòng
này.

Đồng thời máy chủ n
ày duy trì
kịch bản đối tác sẵn sàng cao
của của nó, nó cũng phục vụ
các ứng dụng khác nh
ư là máy
chủ dữ liệu chính. Có sự truy
cập của người dùng cuối cùng
vào cơ sở dữ liệu dự phòng
này ngay cả khi không có lỗi
xảy ra.
Thường được sử dụng trong kịch
bản phân cụm khi việc phục hồi
sau thảm họa với khả năng sẵn
sàng cao (HADR) hoặc việc dịch
chuyển bản ghi nhật ký không
được triển khai và trình quản lý c
ơ
sở dữ liệu không được chạy,
chẳng hạn như cho PowerHA cho
cụm AIX (trước đây là HACMP).

Thường sử dụng trong HADR
“vanilla” (không đọc ở chế độ
chờ), trong Q-Replication,
hoặc trong kịch bản dịch
chuyển bản ghi nhật ký.
Thường sử dụng trong HADR
chuyển đổi dự phòng kép (sẽ
nói thêm sau), trong HADR có

đọc ở chế độ chờ, trong DB2
pureScale, và trong các kịch
bản tạo bản đúp
Bảng 1 bổ sung thêm một quy tắc ngón tay cái chung cho từng loại; tuy nhiên, sau khi đọc bài
viết này, hy vọng là mọi việc sẽ rõ ràng. Rất đơn giản, bạn mua giấy phép sử dụng máy chủ DB2
trong một môi trường sẵn sàng cao như thế nào là tùy thuộc vào các câu trả lời của bạn cho một
số câu hỏi then chốt sau đây:
Bạn đã cài đặt phiên bản DB2 nào ?
Đó có phải là các phiên bản DB2 Express-C, DB2 Express, DB2 Workgroup, DB2
Enterprise, hoặc DB2 Advanced Enterprise hay không? Ví dụ, một máy chủ DB2 Express
với giấy phép SERVER (Được đưa vào khi DB2 9.7 trở thành phiên bản có sẵn) không
có khái niệm nóng, ấm, hoặc lạnh cho máy chủ dự phòng (sẽ nói thêm sau). Bạn nên lưu
ý là bạn không được cấp phép để định cấu hình cho DB2 Express-C miễn phí thành bất
kỳ loại cấu hình tính sẵn sàng cao nào - Nếu bạn cần khả năng sẵn sàng cao thì bạn cần
tối thiểu là DB2 Express. (Lưu ý rằng giấy phép FTL cho DB2 Express - C chỉ có sẵn
trong DB2 phiên bản 9.5 và không còn có sẵn trong DB2 phiên bản 9.7 nữa. Bây giờ nó
đã có sẵn dưới dạng giấy phép FTL cho DB2 Express: Giá vẫn như cũ với nhiều tính
năng hơn !). (N.D.: FTL là viết tắt của “Fixed term license” – giấy phép ấn định thời
hạn).
Máy chủ dự phòng được sử dụng như thế nào khi lỗi không xảy ra?
Ví dụ, có phải là nó được sử dụng như một máy chủ sản xuất cho giao dịch và truy vấn
của DB2 hay không? Cá thể DB2 trên máy chủ này đã chạy chưa? Có lẽ cá thể đang thực
hiện một số dạng công việc, nhưng chỉ để chủ yếu giúp phục hồi trong trường hợp lỗi, ví
dụ: Trong kịch bản HADR. Có phải bạn đang quản lý cụm DB2 pureScale hay không?
Rất đơn giản, máy chủ dự phòng đang làm gì khi tất cả mọi thứ đang chạy tốt, đó hầu như
là tất cả những gì mà DB2 trên máy chủ đó cần phải được cấp giấy phép sử dụng.
Bạn đã mua phép sử dụng máy chủ DB2, mà bạn muốn đảm bảo rằng nó sẵn sàng cao, như
thế nào ?
Ví dụ: Nếu bạn đã mua phép sử dụng máy chủ DB2 Express với giấy phép SERVER như
đã được đưa vào trong DB2 9.7, thì bạn phải mua giấy phép SERVER bổ sung cho máy

chủ dự phòng bất kể nó đang ở tình trạng hoạt động nào: nóng, ấm, hay lạnh. Nếu bạn
mua giấy phép sử dụng máy chủ DB2 Express của bạn theo mô hình Người dùng được ủy
quyền (Authorized User - AU), thì tức là bạn đã mua phép sử dụng máy chủ dự phòng
trong trạng thái ấm cho 5 người dùng được ủy quyền và không cần mua phép sử dụng
máy chủ dự phòng ở trang thái lạnh nữa. Nếu máy chủ DB2 Express của bạn được cấp
phép sử dụng theo mô hình giá trị đơn vị trình xử lý Processor Value Unit (PVU) thì tức
là bạn đã mua phép sử dụng máy chủ dự phòng ở trạng thái ấm cho 100 PVU (Bất kể
máy chủ đang sử dụng kiến trúc bộ xử lý nào) và thậm chí cũng không cần mua phép sử
dụng máy chủ dự phòng ở chế độ lạnh nữa.
Nếu bạn đang tìm kiếm tổng quan về tất cả máy chủ DB2 9 phân tán và cách mua giấy phép sử
dụng chúng, hãy tham khảo tài liệu "Ấn bản DB2 9.7 phân tán nào là phù hợp với bạn?". Để so
sánh các tính năng, chức năng và lợi ích giữa các phiên bản máy chủ khác nhau của DB2, hãy
đọc tài liệu "So sánh các máy chủ dữ liệu DB2 9.7 phân tán".
Từ DB2 phiên bản 8.2 trở đi, đã có một số cải tiến về giấy phép sử dụng, các cải tiến này giảm
đáng kể chi phí để có tính sẵn sàng cao liên kết với các máy chủ DB2 của bạn. Ví dụ, trong DB2
phiên bản 8.2, nếu bạn muốn mua giấy phép sử dụng DB2Workgroup với HADR, thi bạn phải
mua gói Các tính năng sẵn sàng cao (High Availability Feature Pack) và mua giấy phép sử dụng
gói tính năng này trên cả hai máy chủ. Với DB2 9, điều này đã thay đổi: bạn không còn phải mua
giấy phép sử dụng gói tính năng này trên máy chủ dự phòng nữa. Trong DB2 phiên bản 9.5, IBM
đã miễn phí gói các tính năng khả năng sẵn sàng cao cho các máy chủ DB2 Workgroup. Khá đơn
giản, từ phiên bản này đến phiên bản khác, IBM đã giảm giá thành của môi trường khả năng sẵn
sàng cao dựa trên DB2 của bạn nhờ có các thay đổi sau đây:
 Khi một máy chủ đơn đang hoạt động như một máy chủ dự phòng ấm cho nhiều máy chủ
sản xuất, bạn chỉ phải mua giấy phép sử dụng máy chủ dự phòng ấm (như DB2 8.2) một
lần. Ví dụ: Nếu bạn đã mua giấy phép sử dụng máy chủ DB2 nóng cho số lượng không
giới hạn người sử dụng, thì máy chủ dự phòng ấm sẽ yêu cầu 100 PVU. Nếu 5 máy chủ
mức 400 PVU khác đang chạy DB2 Workgroup, và mỗi máy chủ được cấu hình trong
cụm HADR để dự phòng cho chính máy chủ đó, bạn sẽ chỉ phải mua giấy phép sử dụng
cho 2100 PVU (5 máy chủ x 400 + 100 PVU cho máy chủ dự phòng) chứ không phải là
2500 PVU [(5 máy chủ x 400 PVU) + (5 máy chủ x 100 PVU).

 Bạn không cần phải mua giấy phép sử dụng các gói tính năng trên máy chủ đang hoạt
động như máy chủ dự phòng ấm hoặc lạnh nữa (như trường hợp DB2 9). Ví dụ, nếu bạn
đã mua giấy phép sử dụng gói Tính năng tối ưu hóa lưu trữ (Gói này cung cấp khả năng
nén dữ liệu XML, các bảng, chỉ mục, các bảng tạm thời và nhiều loại khác) cho máy chủ
DB2 Enterprise của bạn và đã định cấu cấu hình cơ sở dữ liệu để tham gia vào cụm
HADR, thì bạn chỉ cần phải mua 100 PVU của DB2 Enterprise trên máy chủ dự phòng.
Không cần mua giấy phép sử dụng thêm đối với gói Tính năng tối ưu hóa lưu trữ.
 HADR được bao gồm trong DB2 Workgroup, không phải trả thêm phí (như DB2 9); nếu
bạn quan sát xung quanh về tình hình cạnh tranh thì thấy không có nhà cung cấp nào khác
cung cấp các chức năng tương tự (không có các hạn chế cho các công nghệ HADR trên
DB2 Workgroup) cho bất kỳ máy chủ hướng SMB nào.
 Bạn nhận được phần mềm phân cụm miễn phí cho hầu như bất kỳ ấn bản nào (đối với
DB2 Express bạn cần sử dụng giấy phép FTL, hoặc giấy phép SERVER, hoặc bạn cần
phải mua gói tính năng), đó là hệ thống tự động Tivoli cho nhiều nền tảng (Tivoli SA-
MP), để tạo ra cụm khả năng sẵn sàng cao cho máy chủ DB2 của bạn (như DB2 9).
 Bạn không cần phải mua giấy phép sử dụng máy chủ dự phòng lạnh (như trường hợp
DB2 9.5). Thực tế, một số nhà cung cấp tuyên bố rằng họ mang lại một số lợi thế bằng
cách tặng 10 ngày sử dụng chuyển đổi dự phòng cho giải pháp khả năng sẵn sàng cao, tuy
nhiên, đối với DB2, điều này thực sự là không giới hạn cho loại cụm tương tự. Hơn nữa,
bạn có được phần mềm phân cụm miễn phí! Trên thực tế, phần mềm phân cụm Tivoli
SA-MP được tích hợp sâu vào DB2 (DB2 9.5) và bao gồm các giao diện quản lý phong
phú giảm bớt tổng chi phí sở hữu của cụm khả năng sẵn sàng cao.
 Bạn có thể định cấu hình hai máy chủ DB2 Express trong một cụm HADR mà không
phải mua gói Tính năng sẵn sàng cao nếu bạn mua giấy phép sử dụng máy chủ DB2
Express của bạn theo giấy phép FTL hoặc giấy phép SERVER (cả hai tùy chọn giấy phép
được đưa vào khi DB2 9.7 trở nên có sẵn một cách rộng rãi).
Lưu ý: Trong bài viết này chúng tôi bàn về mua giấy phép sử dụng máy chủ, tuy nhiên, tất cả các
phiên bản DB2 hỗ trợ giấy phép sử dụng khả năng con, tức là bạn chỉ mua giấy phép sử dụng
khả năng mà máy chủ DB2 đang sử dụng. Nếu chúng ta sử dụng một câu chẳng hạn như giấy
phép sử dụng cho mức PVU của máy chủ, bạn có thể hiểu là mức PVU của một phiên

VMWWare hoặc LPAR, nếu bạn đang sử dụng các công nghệ ảo hóa này. Có một số điều kiện
tiên quyết đối với loại giấy phép sử dụng mà bạn nên biết. Do đó hãy đảm bảo rằng bạn biết tất
cả các chi tiết trước khi triển khai DB2 trong loại môi trường này.
Như bạn có thể thấy, đã có rất nhiều thay đổi để giảm tổng chi phí sở hữu gắn với các cụm khả
năng sẵn sàng cao của DB2 từ cả hai góc độ giấy phép sử dụng và quản trị, điều này thật phấn
khởi nếu xét đến cuộc sống kinh tế của chúng ta hiện nay. Tốt nhất hãy bắt đầu cuộc tranh luận
về các tác động của các cụm khả năng sẵn sàng cao với chế độ giấy phép sử dụng DB2 9.7 là với
các ví dụ so sánh tương quan với cách phân loại khả năng sẵn sàng cao của DB2. Như đã đề cập
ở phần trước, DB2 9.7 định nghĩa 3 loại máy chủ dự phòng, đó là: Nóng, ấm và lạnh.
Về đầu trang
Dự phòng nóng
Cấu hình dự phòng nóng là cấu hình trong đó tất cả các máy chủ có cơ sở dữ liệu DB2 đang hoạt
động phục vụ các giao dịch và truy vấn của người sử dụng. Cấu hình này được gọi là cụm
nóng/nóng (hot/hot - mặc dù nó đôi khi được gọi là cấu hình tích cực/tích cực (active/active) vì
tất cả các máy chủ trong cụm đang thực hiện một số công việc nghiệp vụ ở mức độ sản xuất nào
đó tại mọi thời điểm). Nếu một trong các máy chủ trong cụm khả năng sẵn sàng cao bị lỗi, thì
sau đó phần mềm phân cụm sẽ phân phối lại khối lượng công việc của máy chủ bị lỗi cho một
hoặc nhiều máy chủ đang còn làm việc trong cụm khả năng sẵn sàng cao. Môi trường này giống
như một ứng dụng đơn hoặc một ứng dụng mà mỗi máy chủ chống đỡ cho máy chủ khác, nhưng
nó cũng có thỏa thuận mức dịch vụ riêng (SLA) của mình mà nó phải tuân thủ.
Nếu lỗi xảy ra trong một trong các máy chủ, thì việc chuyển giao tài nguyên có thể thực sự tăng
gấp đôi (tại cụm hai nút) khối lượng công việc trên máy chủ dự phòng nóng (Ví dụ: Máy chủ còn
làm việc duy nhất trong cụm HADR hai nút) vì bây giờ nó phải xử lý khối lượng công việc vốn
là của nó từ ban đầu cộng thêm khối lượng công việc của máy chủ bị lỗi. Đó là những gì mà bạn
cần xem xét khi thiết lập bất kỳ môi trường khả năng sẵn sàng cao nào và không tận dụng các
hình trạng cụm tiên tiến chẳng hạn như DB2 pureScale. Nếu bạn là quản trị viên cơ sở dữ liệu
(DBA) đang sắp đặt mọi thứ để đảm bảo một thỏa thuận mức dịch vụ (SLA) chặt chẽ, bạn phải
đảm bảo rằng bạn đã xem xét chặt chẽ hình trạng khả năng sẵn sàng cao (HA) của mình và lựa
chọn giải pháp HA bạn đang sử dụng.
Tóm lại, trong DB2 máy chủ dự phòng nóng là bất kỳ máy nào đang được sử dụng để phục vụ

các giao dịch và các truy vấn của người sử dụng trong chu kỳ hoạt động bình thường, nhưng nó
hành động như một máy chủ dự phòng cho một máy chủ khác cũng được sử dụng để phục vụ các
giao dịch và các truy vấn của người sử dụng trong chu kỳ hoạt động bình thường. Khi lỗi của
máy chủ trong cụm xảy ra, thì máy chủ dự phòng nóng tiếp nhận công việc của máy chủ bị lỗi
cộng với công việc mà nó vẫn đang làm trong khi hoạt động bình thường. Vì rằng máy chủ dự
phòng tích cực vẫn được sử dụng cho các giao dịch và truy vấn của người sử dụng, thì ngay cả
khi không có lỗi hỏng hóc xẩy ra, nó phải được mua giấy phép đầy đủ. Ví dụ: Bạn hãy tưởng
tượng là bạn có hai cơ sở dữ liệu trên hai máy chủ riêng biệt, một máy chạy ứng dụng đóng gói
hoạch định nguồn lực doanh nghiệp (ERP) và máy kia chạy ứng dụng đóng gói quản lý chuỗi
cung ứng (SCM). Nếu cơ sở dữ liệu SCM bị lỗi, thì máy đang chạy khối lượng công việc của
ERP phải phục vụ tất cả người sử dụng SCM. Kịch bản minh họa cụm khả năng sẵn sàng cao của
máy chủ dự phòng nóng hai nút được mô tả trong Hình 2.

Hình 2. Máy chủ 1 là máy chủ dự phòng nóng cho máy chủ 2 và máy chủ 2 là máy chủ dự
phòng nóng cho máy chủ 1. Tải công việc của máy chủ 2 chuyển sang máy chủ 1 trong
trường hợp lỗi xảy ra và ngược lại.

Trong ví dụ này có một cặp máy chủ mà cả hai đang được sử dụng cho tải công việc giao dịch và
truy vấn trong chu kỳ hoạt động bình thường (các hình hộp tô đặc đại diện cho tải công việc của
từng máy chủ trước khi có lỗi, các hình hộp có đường kẻ chéo song song là nơi công việc diễn ra
trong trường hợp xẩy ra lỗi ở máy chủ tương ứng). Trong tình huống giả định này, máy 2 bị lỗi
và tải công việc của nó được chuyển giao cho đối tác dự phòng của nó, là máy chủ 1. Máy chủ 1
là một máy chủ dự phòng nóng cho máy chủ 2 (và ngược lại khi bạn nhìn kỹ hình này – hãy lưu
ý hình hộp có đường kẻ chéo song song cho máy chủ 1 ở máy chủ 2). Kiểu cấu hình này thường
được gọi là cặp cụm khả năng sẵn sàng cao, cặp chuyển đổi sinh đôi, cặp nóng/nóng hoặc cặp
tích cực/tích cực và rất phổ biến trong bối cảnh công nghệ thông tin ngày nay. Có rất nhiều cách
để thực hiện cụm khả năng sẵn sàng cao nóng/nóng trong DB2 và phụ thuộc vào bạn cần gì trong
giải pháp, bạn có thể sử dụng PowerHA cho AIX, HADR kết hợp với cơ sở dữ liệu trên mỗi máy
chủ chuyển đổi dự phòng sang máy khác, HADR (Với khả năng Đọc trên máy chủ dự phòng
(Read on Standby) được kích hoạt), Q-Replication, bằng cách sử dụng dự phòng nóng cho việc

báo cáo thông qua công nghệ ảnh chụp nhanh hoặc sao ảnh đĩa, hoặc đỉnh cao của việc kết hợp
khả năng mở rộng và khả năng sẵn sàng: hãy sử dụng công nghệ DB2 pureScale.
Một lần nữa, cả máy chủ 1 và máy chủ 2 trong Hình 2 đã được sử dụng cùng nhau cho tải công
việc sản xuất; khi máy 2 gặp lỗi, tải công việc của DB2 của nó được chuyển sang máy chủ 1 một
cách dễ dàng.
Cụm HADR có thể hoạt động như cụm nóng/nóng theo nhiều cách. Ví dụ: Bạn hãy xem xét môi
trường trong Hình 3.

Hình 3. Cụm HADR nóng/ nóng nhờ có cụm chuyển đổi dự phòng lẫn nhau HADR

Trong hình trước bạn có thể thấy rằng máy chủ A chủ chứa cơ sở dữ liệu sản xuất gọi là cơ sở dữ
liệu A cũng như cơ sở dữ liệu dự phòng trong cụm HADR được gọi cơ sở dữ liệu B1. Cùng lúc
đó, máy chủ B chủ chứa cơ sở dữ liệu sản xuất gọi là cơ sở dữ liệu B cũng như một cơ sở dữ liệu
dự phòng trong cùng cụm HADR được gọi là cơ sở dữ liệu A1. Trong trường hợp này, khi không
có lỗi, cả hai máy chủ A và B đều bận phục vụ công việc sản xuất trên cơ sở dữ liệu A và B
tương ứng, và do đó nó được xem là cấu hình nóng/nóng và cả hai máy chủ phải được mua giấy
phép đầy đủ.
Hình 4 là ví dụ về môi trường HADR đang sử dụng khả năng Đọc trong chế độ dự phòng, là một
phần của gói vá lỗi 1 của DB2 phiên bản 9.7 và các phiên bản sau này.

Hình 4. Cụm HADR nóng/nóng nhờ có Đọc trong chế độ dự phòng

Trên hình 4 bạn có thể thấy rằng các trình khách có thể đọc và ghi vào máy chủ chính (làm cho
nó thành nóng); nhưng, vì chúng đang đọc trên máy chủ thứ cấp, máy chủ này cũng là nóng và
do đó cả hai máy chủ phải được mua giấy phép đầy đủ. Khá đơn giản, nếu bạn đọc dữ liệu từ
một máy chủ cho mục đích kinh doanh, đó là một máy nóng.
Cuối cùng, Hình 5 cho thấy một cụm 3 thành viên pureScale DB2 khả năng sẵn sàng cao và co
giãn.

Hình 5. Một cụm DB2 pureScale

Trong hình 5, bạn chỉ mua giấy phép cho DB2 và gói tính năng DB2 pureScale trên các máy chủ
thành viên (các máy chủ xử lý giao dịch). Các máy chủ phương tiện nhớ sẵn (CF- Cluster
Caching Facility) của cụm (mà như bạn có thể thấy thường là hoàn toàn song công) không yêu
cầu bất kỳ giấy phép nào. Trong ví dụ này, vì các giao dịch đang được liên tục cân bằng tải trên
tất cả các máy chủ thành viên, nên tất cả các máy chủ là nóng và do đó tất cả chúng đều phải
được mua giấy phép đầy đủ.
Các xem xét khi mua giấy phép cho một máy chủ dự phòng nóng
Như một quy tắc ngón tay cái chung, cấu hình nóng/nóng cần được mua giấy phép giống như
cách mà bạn mua giấy phép cho từng máy chủ, khi chúng hoàn toàn không được phân cụm để có
tính sẵn sàng cao.
Từ DB2 phiên bản 9.7 trở đi, có năm phương thức mua giấy phép khác nhau (một số chỉ có sẵn
với các phiên bản DB2 cụ thể): đó là SERVER, Giấy phép ấn định thời hạn (FTL), SOCKET,
Người dùng có thẩm quyền (AU), và Giá trị đơn vị bộ xử lý (PVU). Phần sau sẽ chi tiết các cân
nhắc về mua giấy phép khả năng sẵn sàng cao mà bạn cần phải nhận thức được cho mỗi giấy
phép tương ứng trong cụm khả năng sẵn sàng cao nóng/nóng.
Giấy phép SERVER
Giấy phép SERVER là mới đối với DB2 9.7 và chỉ có sẵn cho các máy chủ DB2 Express.
Khi mua giấy phép SERVER cho máy chủ DB2 Express, đơn giản là bạn mua mua giấy
phép cho mỗi máy chủ trong cụm bất kể loại máy chủ dự phòng là gì (nóng, ấm hoặc
lạnh). Rất đơn giản, không cần phải xác định mức độ tích cực của máy chủ DB2 Express
được mua giấy phép SERVER khi liên quan đến giấy phép cho khả năng sẵn sàng cao.
Không có số lượng người sử dụng tối thiểu, và bạn không phải tính toán mức PVU của
máy chủ ở phía dưới hoặc bất cứ điều gì khác: Quá đơn giản! Mặc dù trong một cấu hình
nóng/nóng thì quy tắc này không có ảnh hưởng gì tới việc mua giấy phép (vì cả hai máy
chủ đều là nóng), bạn sẽ thấy trong cấu hình dự phòng ấm, các yêu cầu mua giấy phép
SERVER là khác đi so với các giấy phép DB2 khác.
Ngoài ra, nếu bạn muốn tạo ra một cụm HADR bằng cách sử dụng máy chủ DB2 Express
trong DB2 9.5, bạn phải mua Gói tính năng khả năng sẵn sàng cao của DB2 để có được
các tính năng này cùng với các tính năng khác liên quan đến khả năng sẵn sàng cao.

Trong DB2 9.7, giấy phép SERVER của DB2 Express thực sự có kèm tất cả các tính
năng trong gói tính năng sẵn sàng cao (bao gồm cả HADR) miễn phí, tuy nhiên bạn cần
phải mua gói tính năng này nếu bạn muốn có HADR (hoặc các tính năng khác) cho một
máy chủ DB2 Express với giấy phép có được thông qua hoặc giấy phép PVU hoặc giấy
phép AU. Vì lý do này, và nhiều lý do khác, chúng tôi khuyên bạn nên mua giấy phép
này (hoặc FTL) cho bất kỳ máy chủ DB2 Express nào.
Giấy phép ấn định thời hạn (FTL)
Mặc dù giấy phép ấn định thời hạn (FTL) là mới đối với DB2 Express phiên bản 9.7, nó
có cùng phương thức định giá như giấy phép FTL cho DB2 Express-C phiên bản 9.5 cũ
(không còn nữa). Giấy phép này sẽ cho phép bạn truy cập vào tất cả các tính năng trong
DB2 Express (không giống như phiên bản trước của nó). Một giấy phép FTL của DB2
Express cho phép bạn truy cập vào phần mềm DB2 Express trong thời hạn là một năm -
đó là giấy phép thời hạn, đối lập với giấy phép vĩnh viễn như được cung cấp với các
phiên bản DB2 khác. Khi mua giấy phép FTL cho máy chủ DB2 Express, đơn giản là bạn
mua giấy phép FTL cho mỗi máy chủ trong cụm – cũng giống như giấy phép SERVER
cho máy chủ DB2 Express – bất kể loại máy chủ dự phòng là gì (nóng, ấm hoặc lạnh).
Khá đơn giản, không cần phải xác định mức độ tích cực của máy chủ DB2 Express được
mua giấy phép nếu sử dụng giấy phép FTL khi liên quan đến mua giấy phép cho khả
năng sẵn sàng cao. Không có số người sử dụng tối thiểu, và bạn không phải tính toán
mức PVU của máy chủ ở bên dưới hoặc bất cứ điều gì khác: Quá đơn giản! Mặc dù trong
một cấu hình nóng/nóng thì quy tắc này không có ảnh hưởng gì tới việc mua giấy phép
(vì cả hai máy chủ đều là nóng), bạn sẽ thấy trong cấu hình dự phòng ấm, các yêu cầu
mua giấy phép là khác đi so với các giấy phép DB2 khác.
Một máy chủ DB2 Express được mua giấy phép FTL cung cấp cho bạn khả năng truy cập
vào tất cả các tính năng trong gói tính năng sẵn sàng cao của DB2, bao gồm cả HADR.
(Tuy nhiên, hãy lưu ý rằng bạn phải mua gói này tính năng để kích hoạt HADR, trong số
các tính năng sẵn sàng cao khác, nếu bạn đang sử dụng giấy phép PVU hoặc AU của
DB2 Express). Vì lý do này, và nhiều lý do khác, chúng tôi khuyên bạn nên mua giấy
phép này (hoặc giấy phép SERVER) cho bất kỳ máy chủ DB2 Express nào.
Giấy phép SOCKET (Ổ cắm)

Giấy phép SOCKET là mới đối với DB2 9.7 và chỉ có sẵn cho các máy chủ
DB2Workgroup. Khi mua giấy phép SOCKET cho máy chủ DB2Workgroup, đơn giản là
bạn mua giấy phép cho cùng số lượng ổ cắm như trên các máy chủ chính cho từng máy
chủ vì đây là cấu hình nóng/nóng và tất cả các máy chủ được sử dụng đầy đủ cho các
hoạt động thường xuyên.
Ví dụ: Nếu bạn có máy chủ lõi kép 4 đường Power7 của IBM, bạn sẽ cần mua giấy phép
cho 4 SOCKET DB2Workgroup. Thật ngẫu nhiên, máy chủ này sẽ được tính ở mức 960
PVU và bạn cũng sẽ vẫn cần mua giấy phép cho 4 SOCKET DB2Workgroup. Đối với
cấu hình nóng/nóng, bạn sẽ cần giấy phép cho 8 SOCKET cho DB2Workgroup: 4 ổ cắm
cho máy chủ chính nóng và 4 ổ cắm cho máy chủ dự phòng nóng. Bất cứ khi nào mua
giấy phép cho máy chủ DB2Workgroup, chúng tôi khuyên bạn nên sử dụng giấy phép
này vì các khả năng bộ xử lý trung tâm được bổ sung thêm mà nó cung cấp cho môi
trường của bạn.
Giấy phép đơn vị giá trị bộ xử lý (PVU - Processor Value Unit)
Bất kỳ máy chủ DB2 nào đều có thể mua giấy phép bằng cách sử dụng mô hình PVU.
Trong cấu hình tích cực/tích cực, toàn bộ mức PVU của máy chủ dự phòng nóng (máy
chủ 1 trong ví dụ của chúng ta) phải được mua giấy phép bổ sung. Tất nhiên, bạn sẽ sử
dụng cùng cách tiếp cận này để mua giấy phép cho máy chủ DB2 của bạn ngay cả khi nó
không phải là một phần của cụm khả năng sẵn sàng cao vì dẫu sao, nó vẫn đang phục vụ
công việc sản xuất, do đó không có bất kỳ điều gì ngạc nhiên ở đây.
Nếu các máy chủ trong Hình 3 sử dụng bốn lõi của máy chủ Power7, và giả sử rằng mỗi
máy chủ chạy DB2Workgroup (bị giới hạn với giấy phép này cho các máy chủ với mức
tối đa là 480 PVU như vào quý 2 năm 2008 (2Q08)), bạn sẽ phải mua tổng cộng 960
PVU cho giải pháp này: 480 PVU cho máy chủ 1 và 480 PVU cho máy chủ 2.
Giấy phép người dùng được ủy quyền (AU)
Đối với bất kỳ sản phẩm máy chủ DB2 nào đã mua giấy phép theo mô hình AU, bạn phải
mua giấy phép cho môi trường như vậy bằng cách mua tổng số AU sẽ truy cập vào môi
trường đó trên máy chủ chính nóng, cộng thêm số lượng tương ứng của người dùng sẽ
truy cập vào máy chủ dự phòng nóng nữa (vì chúng cả hai thực sự đều là máy chủ nóng
cho các ứng dụng của riêng mình và các máy chủ dự phòng cho máy chủ kia).

Một AU là một cá thể riêng lẻ (trong một số trường hợp, nó có thể là một ứng dụng hoặc
một thiết bị chừng nào nó không hành động thay mặt cho những người dùng khác) với
một danh tính cụ thể nằm bên trong hoặc bên ngoài công ty của bạn. Những giấy phép
này cũng có thể được sử dụng trên Internet (giống như ứng dụng mua bán trực tuyến)
người sử dụng cuối cùng được biết rõ vì họ phải được xác định danh tính một cách cụ thể
cho giấy phép này. Các giấy phép AU là giấy phép đầy đủ, không cần có giấy phép tách
riêng cho máy chủ như đã từng xảy ra trước đây với DB2 8, lúc đó bạn cần phải mua giấy
phép người sử dụng cùng với giấy phép máy chủ cơ sở. Nếu bạn đang sử dụng ghép kênh
hoặc phần mềm kết nối tập trung, thì những người dùng cần phải được xác định danh tính
và liệt kê trước khi các công nghệ như vậy được áp dụng cho các kết nối được đếm.
Bạn cần một giấy phép AU cho bất cứ ai truy cập vào máy chủ. Tuy nhiên, bất kể số
lượng người dùng truy cập vào máy chủ của bạn là bao nhiêu, có một số tối thiểu người
dùng tùy theo từng ấn bản mà bạn cần phải tính đến. Các ấn bản của DB2Express hoặc
DB2 Workgroup yêu cầu tối thiểu năm giấy phép AU. DB2 Enterprise đòi hỏi tối thiểu là
25 AU cho 100 PVU cho máy chủ bên dưới. Nói một cách khác, cứ mỗi 100 PVU trên
máy chủ, bạn cần một gói 25-AU. Ví dụ: Một máy chủ với 480 PVU sẽ yêu cầu mức tối
thiểu là giấy phép 125 AU vì bạn làm tròn số PVU để xác định số lượng tối thiểu người
dùng. Tất nhiên, nếu bạn đã có 150 người dùng, thì bạn sẽ cần phải mua giấy phép máy
chủ nhiều hơn số lượng tối thiểu để bằng với số lượng thực tế sử dụng, trong trường hợp
này là 150 AU. Giấy phép AU không được chuyển nhượng qua các ca làm việc (mặc dù
chúng có thể được chuyển giao khi thay đổi nhân viên), và chúng chỉ có giá trị cho một
máy chủ cụ thể. Tất nhiên vì hình 3 là một ví dụ về cấu hình nóng/nóng, các quy tắc này
là chưa rõ ràng bởi vì, dù sao đi nữa chúng phải được mua giấy phép như các máy chủ
độc lập.
Trong ví dụ trong hình 3, nếu bạn có 100 người sử dụng cần phải truy cập vào cả hai máy
chủ nóng DB2 Workgroup, bạn sẽ cần phải mua tổng cộng là 200 giấy phép AU của DB2
Workgroup cho 100 người dùng này: 2 máy chủ x 100 AU mỗi máy chủ. Ngay cả khi chỉ
có 12 trong số những người sử dụng này kết nối với một trong hai máy chủ tại bất cứ thời
điểm nào, tất cả 100 người dùng vẫn sẽ phải được mua giấy phép cho mỗi máy chủ (vì
vậy bạn vẫn cần 200 giấy phép AU cho ví dụ này). Nếu bạn đang sử dụng DB2 Express

hoặc DB2Workgroup trong hình 3, và bạn chỉ có 3 người sử dụng trong công ty của bạn,
bạn sẽ cần tổng cộng 10 giấy phép AU cho DB2 Express hoặc DB2 Workgroup (2 máy
chủ x 5 AU tối thiểu) để đáp ứng yêu cầu tối thiểu về AU gắn với các phiên bản này của
DB2.
Nếu các máy chủ được sử dụng trong hình 3 là DB2 Enterprise, như đã đề cập ở phần
trước, mọi thứ khác đi một chút: chúng ta hãy tiếp tục với ví dụ mà chúng ta giả định
rằng mỗi máy chủ là máy chủ dựa trên Power7 4 lõi ở mức 480 PVU. Nếu bạn có 100
người sử dụng tất cả đều cần truy cập vào máy chủ DB2 Enterprise nóng, bạn sẽ cần phải
mua tổng cộng 250 giấy phép AU DB2 Enterprise cho 100 người dùng: 2 máy chủ x 125
AU mỗi máy chủ vì tối thiểu là 25 người sử dụng cho mỗi 100 PVU cho từng máy chủ
DB2 Enterprise. Một lần nữa, ngay cả khi chỉ có 12 trong số những người dùng kết nối
với một trong hai máy chủ DB2 cùng một lúc, tất cả 125 người vẫn phải được mua giấy
phép cho mỗi máy chủ.
Về đầu trang
Dự phòng ấm
Cấu hình dự phòng ấm là một cấu hình trong trong đó có ít nhất một máy chủ trong cụm khả
năng sẵn sàng cao không có một cơ sở dữ liệu DB2 đang phục vụ tải công việc giao dịch hoặc
truy vấn của người sử dụng trong thời gian hoạt động bình thường. Máy chủ này là ấm theo
nghĩa rằng máy chủ không thực hiện các công việc "hữu ích". Công việc được phân loại là
"không hữu ích" (mặc dù trớ trêu thay nó có thể là công việc hữu ích nhất mà máy chủ dự phòng
của bạn thực hiện) bao gồm các hoạt động quản trị hỗ trợ trong kịch bản chuyển đổi dự phòng
chẳng hạn như có một cơ sở dữ liệu ở trạng thái treo chờ cuộn tiến (rollforward) để hỗ trợ dịch
chuyển ghi nhật ký, hỗ trợ dịch chuyển ghi nhật ký mức giao dịch cho môi trường HADR, và
v.v Nếu một trong các máy chủ trong cụm khả năng sẵn sàng cao gặp sự cố, thì sau đó tải công
việc được phân phối lại cho máy chủ dự phòng ấm.
Một quan niệm sai lầm phổ biến mà nhiều người mắc phải về cấu hình chế độ chờ ấm là máy chủ
dự phòng ấm là một sự lãng phí về tài nguyên khi nó chỉ được dành riêng cho hoạt động phục
hồi. Đây là một sự hiểu biết không chính xác về loại cấu hình này. Sự thật là bạn có thể sử dụng
máy chủ dự phòng ấm cho nhiều công việc (công việc liên quan đến DB2 và cả không liên quan
đến DB2) vượt ra ngoài vai trò là máy chủ dự phòng. Ví dụ: Bạn có thể tạo ra một cá thể DB2

riêng biệt trên máy chủ dự phòng ấm (tùy thuộc vào công việc liên quan đến DB2 mà bạn chọn
để thực hiện ở đây, nó có thể kéo theo phải mua giấy phép) và sử dụng nó như một máy chủ thử
nghiệm, hoặc có thể chuyển bớt tải công việc và chức năng khác sang cho nó. Trong trường hợp
sự cố, bạn có thể co bớt lại các khối lượng công việc này (hoặc các nguồn tài nguyên đã phân bổ
cho phân vùng ảo hóa mà máy chủ chạy) và cho phép máy chủ dự phòng ấm sử dụng tất cả tài
nguyên của máy chủ để xử lý tải của máy chủ gặp lỗi và như vậy né tránh được những tính toán
về tải công việc được nêu trong phần thảo luận về dự phòng nóng/nóng trong phần cuối của bài
viết.
Kịch bản dự phòng ấm được thể hiện trong hình 6. Trong hình này, cấu hình HADR “vanilla”
(khả năng Đọc trong dự phòng không được sử dụng) đã được tạo ra cho môi trường OLTP sản
xuất. Trong ví dụ này, trong suốt thời gian hoạt động bình thường, máy chủ 2 đang được sử dụng
cho tải công việc giao dịch và truy vấn (được ghi chú là công việc tích cực - ActiveWork trong
hình), trong khi máy chủ 1 đang chờ như là máy chủ dự phòng ấm cho tải công việc của máy chủ
2. Máy chủ 2 bị lỗi và tải công việc DB2 của nó được chuyển sang máy chủ 1 là đối tác ấm của
nó. Trong kịch bản này, rất có thể xảy ra trường hợp là nếu bất kỳ công việc nào (bất kỳ loại nào)
được thực hiện trên máy chủ 1 trước khi có lỗi, nó sẽ được thu nhỏ lại để xử lý tải công việc mới
sau khi xảy ra lỗi ở máy chủ 2 (hoặc máy chủ 1 ban đầu được định cỡ để hỗ trợ tải công việc của
nó và tải công việc của máy chủ 2 cùng một lúc, nếu không bạn sẽ gặp vấn đề về hiệu năng).

Hình 6. Khối lượng công việc của máy chủ 2 được chuyển giao cho máy chủ dự phòng ấm,
là máy chủ 1 trong cụm HADR điển hình

Bởi vì trong suốt thời gian hoạt động bình thường chỉ có một máy chủ là nóng từ góc nhìn của
DB2 trong hình 6 trong khi máy chủ khác đang làm một số hoạt động ấm như chuẩn bị sẵn sang
làm một đối tác chuyển đổi dự phòng HADR, cấu hình này thường được gọi là nóng/ấm (hoặc
tích cực/nhàn rỗi, trong một số giới chuyên môn). Khái niệm quan trọng cần được lưu ý ở đây là
máy chủ 1 không làm bất kỳ công việc DB2 "có ý nghĩa" nào trước khi sự cố ngừng chạy xảy ra.
Tất nhiên trong kịch bản HADR Đọc trong dự phòng hoặc DB2pureScale, 'máy chủ dự phòng'
(không thực sự là đứng chờ dự phòng nữa vì nó là nóng) đang làm công việc có ý nghĩa và do đó
không công nghệ nào trong các công nghệ này được kết hợp với mức dự phòng ấm hoặc lạnh.

Khách hàng có tất cả mọi loại tiếp cận khác nhau tới máy chủ dự phòng. Chúng tôi khuyên bạn
nên ưu tiên mục tiêu của bạn và các yêu cầu nghiệp vụ liên quan đến máy chủ dự phòng. Ví dụ,
một số khách hàng có thể chọn thiết lập một môi trường khả năng sẵn sàng cao trên một máy chủ
dự phòng và đồng thời sử dụng cơ sở dữ liệu dự phòng cho một dạng phiên bản chỉ đọc hiện
trạng của máy chủ sản xuất - do đó làm lan rộng phân bổ chi phí trên ngày càng nhiều tài
nguyên; bạn có thể làm điều này với HADR kể từ gói vá lỗi 1 của DB2 9.7 hoặc các gói vá lỗi
sau đó. Bạn nên lưu ý rằng nhiều nhà cung cấp giới hạn mô hình này là một trong hai việc trên,
có nghĩa rằng trong khi bạn đang đọc cơ sở dữ liệu, bạn không có thể cuộn tiến về phía trước
thông qua bản ghi nhật ký để giữ cho nó như hiện trạng (nếu không phải là trường hợp chọn một
trong hai, thì sẽ có sự thỏa hiệp về quá trình xử lý làm lại (redo) có thể chạy nhanh đến đâu, chưa
kể những cân nhắc khác). Tiếp theo nữa, việc để cơ sở dữ liệu mở trong thời gian dài hoạt động
chỉ đọc trong môi trường như vậy làm tăng thời gian trung bình để sửa chữa (MTTR - mean time
to repair) trong trường hợp có lỗi: đó chính là vấn đề mà cấu hình này được thiết kế để tránh xảy
ra. Một ví dụ khác là với việc đọc các cơ sở dữ liệu OLTP dự phòng. Nếu bạn nghĩ về nó, thì cơ
sở dữ liệu OLTP được thiết kế để có các chỉ số tối thiểu. Nếu bạn bắt đầu chạy một tải công việc
giống với tạo báo cáo trên máy chủ dự phòng của nó, thì cơ sở dữ liệu dự phòng nhiều khả năng
sẽ trải nghiệm một số lần quét toàn bảng vì không có chỉ số để hỗ trợ nó tra cứu nhanh chóng.
Việc chạy quét toàn bộ bảng trên một máy chủ dự phòng có thể tiêu thụ rất nhiều tài nguyên đến
mức có thể gặp rắc rối khi giữ các cơ sở dữ liệu được đồng bộ.
Tùy thuộc vào yêu cầu về khả năng sẵn sàng, khối lượng công việc của bạn, vân vân, máy chủ
dự phòng ấm có thể hoặc không phải là sự lựa chọn đúng cho môi trường của bạn; tuy nhiên, khi
lập kế hoạch cho các loại dự phòng mà bạn muốn hỗ trợ, đừng bao giờ quên lý do ở vị trí đầu
tiên tại sao bạn lại cần có một môi trường khả năng sẵn sàng cao: đó là để giảm thiểu MTTR khi
có sự cố ngừng chạy. Điểm quan trọng là DB2 cũng có các tùy chọn cho cấu hình nóng/nóng
(bao gồm cả một số công nghệ đọc trong chế độ dự phòng HADR, công nghệ này không phải là
một phần của DB2 9.7, khi nó lần đầu tiên trở nên có sẵn nhưng đã được đưa vào gói vá lỗi 1 của
DB2 9.7) và tất cả các phiên bản DB2 pureScale mới. Ví dụ, nếu bạn đọc từ một máy chủ dự
phòng, trong cấu hình HADR, máy chủ ngay lập tức được coi là nóng. Tóm lại, quan điểm cho
rằng một máy chủ dự phòng ấm (từ quan điểm DB2) chỉ là ngồi chơi và lãng phí nguồn tài
nguyên là một khái niệm thường rất hay bị hiểu lầm khi bạn thực sự nhìn vào nó - nhưng với

DB2, sự lựa chọn tùy thuộc vào bạn, hãy nhớ rằng DB2 có thể cung cấp bất kỳ cấu hình nào bạn
muốn.
Các xem xét khi mua giấy phép cho một máy chủ dự phòng ấm
Từ DB2 phiên bản 9.7 trở đi, có năm phương thức mua giấy phép khác nhau (một số chỉ có sẵn
với các phiên bản DB2 cụ thể): đó là SERVER, Giấy phép ấn định thời hạn (FTL), SOCKET,
Người dùng có thẩm quyền (AU), và Giá trị đơn vị bộ xử lý (PVU). Phần sau sẽ chi tiết các cân
nhắc về mua giấy phép khả năng sẵn sàng cao mà bạn cần phải nhận thức được cho mỗi giấy
phép tương ứng.
Giấy phép SERVER
Giấy phép SERVER là mới đối với DB2 9.7 và chỉ có sẵn cho các máy chủ DB2 Express.
Khi mua giấy phép SERVER cho một máy chủ DB2 Express, đơn giản là bạn mua giấy
phép cho mỗi máy chủ trong cụm bất kể loại dự phòng gì (nóng, ấm, hoặc lạnh). Rất đơn
giản, không cần phải xác định mức độ tích cực của máy chủ DB2 Express với giấy phép
SERVER khi liên quan đến mua giấy phép cho khả năng sẵn sàng cao. Không có số
lượng người sử dụng tối thiểu, và bạn cũng không phải tính toán mức PVU của máy chủ
bên dưới hoặc bất cứ điều gì khác: Quá đơn giản!
Ngoài ra, nếu bạn muốn tạo ra một cụm HADR bằng cách sử dụng máy chủ DB2 Express
trong DB2 9.5, bạn phải mua gói tính năng khả năng sẵn sàng cao của DB2 để có tính
năng này cùng với các tính năng khác liên quan đến khả năng sẵn sàng cao. Trong DB2
9.7, giấy phép SERVER DB2 Express thực sự đi kèm với tất cả các tính năng trong gói
tính năng khả năng sẵn sàng cao (bao gồm cả HADR) miễn phí, tuy nhiên bạn phải mua
gói tính năng này nếu bạn muốn HADR (hoặc các tính năng khác) với một máy chủ DB2
Express có giấy phép nhờ thông qua giấy phép PVU hoặc AU khác. Vì lý do này, và
nhiều lý do khác, chúng tôi khuyên bạn nên sử dụng giấy phép SERVER này (hoặc giấy
phép FTL) cho bất kỳ máy chủ DB2 Express nào.
Trong cụm khả năng sẵn sàng cao nóng/ấm, bạn thực sự phải mua giấy phép SERVER
cho mỗi máy chủ DB2 Express. Nếu bạn muốn tạo cụm HADR bằng cách sử dụng máy
chủ DB2 Express trong DB2 9.5, bạn phải mua gói tính năng khả năng sẵn sàng cao của
DB2 để có tính năng này cùng với các tính năng khác liên quan đến khả năng sẵn sàng
cao. Trong DB2 9.7, giấy phép SERVER của DB2 Express thực sự đi kèm với tất cả các

tính năng trong gói tính năng khả năng sẵn sàng cao (HADR) miễn phí. Bạn phải mua gói
tính năng này nếu bạn muốn sử dụng HADR (hoặc một số công nghệ DB2 tiên tiến khác
liên quan đến khả năng sẵn sàng cao) với một máy chủ DB2 Express có giấy phép nhờ
thông qua giấy phép PVU hoặc AU
Giấy phép ấn định thời hạn (FTL)
Mặc dù giấy phép FTL là mới đối với DB2 Express phiên bản 9.7, nó có cùng phương
pháp định giá như giấy phép FTL cho DB2 Express-C phiên bản 9.5 cũ (không còn nữa).
Giấy phép này sẽ cho phép bạn truy cập vào tất cả các tính năng trong DB2 Express
(không giống như phiên bản trước của nó). Giấy phép FTL DB2 Express cho phép bạn
truy cập vào phần mềm DB2 Express trong thời hạn là một năm - đó là giấy phép ấn định
thời hạn, đối lập với giấy phép vĩnh viễn như được cung cấp với các giấy phép của các
phiên bản DB2 khác. Khi mua giấy phép FTL cho máy chủ DB2 Express, đơn giản là bạn
mua giấy phép FTL cho mỗi máy chủ trong cụm - giống như giấy phép SERVER của
DB2 Express – bất kể máy chủ dự phòng là kiểu gì (nóng, ấm hoặc lạnh). Khá đơn giản,
không cần phải xác định mức độ tích cực của máy chủ DB2 Express với giấy phép FTL
khi liên quan đến mua giấy phép cho khả năng sẵn sàng cao. Không có số người sử dụng
tối thiểu, và bạn không phải tính toán mức PVU của máy chủ ở bên dưới hoặc bất cứ điều
gì khác: Quá đơn giản!
Trong cụm khả năng sẵn sàng cao nóng/ấm, bạn thực sự phải mua giấy phép FTL cho
mỗi máy chủ DB2 Express. Nếu bạn muốn tạo ra một cụm HADR bằng cách sử dụng
máy chủ DB2 Express trong DB2 9.5, bạn phải mua gói tính năng khả năng sẵn sàng cao
của DB2 để có tính năng này cùng với các tính năng khác liên quan đến khả năng sẵn
sàng cao. Trong DB2 9.7, giấy phép FTL của DB2 Express thực đi cùng với tất cả các
thành phần của gói tính năng sẵn sàng cao (bao gồm cả HADR) miễn phí; Thực vậy, giấy
phép FTL của DB2 Express cho phép bạn có tất cả các tính năng có sẵn trong gói tính
năng khả năng sẵn sàng cao của DB2! Bạn phải mua gói tính năng này nếu bạn muốn
HADR (hoặc một số công nghệ DB2 tiên tiến khác liên quan đến khả năng sẵn sàng cao)
với một máy chủ DB2 Express có giấy phép nhờ thông qua giấy phép PVU hoặc AU. Vì
lý do này, và nhiều lý do khác, chúng tôi đặc biệt khuyên bạn nên sử dụng giấy phép này
(hoặc giấy phép SERVER) cho bất kỳ máy chủ DB2 Express nào.

Giấy phép SOCKET
Giấy phép SOCKET cũng là mới đối với DB2 9.7 và chỉ có sẵn cho các máy chủ của
DB2 Workgroup. Khi mua giấy phép SOCKET cho máy chủ DB2Workgroup, đơn giản
là bạn mua giấy phép cho số lượng ổ cắm (sockets) mà DB2 sẽ sử dụng trên các máy chủ
chính. Nếu bạn có máy chủ Power7 lõi kép 4 đường của IBM, bạn cần mua 4 giấy phép
SOCKET cho DB2Workgroup. Đối với các máy chủ dự phòng ấm, bạn chỉ cần mua bổ
sung một giấy phép SOCKET bất kể là ổ nào. Trong ví dụ hình 6, bạn sẽ cần 4 ổ cắm
(cho máy chủ nóng) + 1ổ căm (cho máy chủ dự phòng ấm) = 5 ổ cắm.
Một cách ngẫu nhiên, máy chủ chính sẽ được tính ở mức 960 PVU và bạn vẫn sẽ cần
mua 4 giấy phép SOCKET cho DB2 Workgroup. Bất cứ khi nào bạn mua giấy phép cho
máy chủ DB2 Workgroup, chúng tôi khuyên bạn nên sử dụng giấy phép này vì năng lực
bộ xử lý trung tâm bổ sung mà nó cung cấp cho môi trường của bạn.
Giấy phép đơn vị giá trị bộ xử lý (PVU - Processor Value Unit)
Đối với bất kỳ máy chủ DB2 nào được mua giấy phép bằng cách sử dụng mô hình PVU,
bạn cần mua giấy phép một máy chủ dự phòng ấm cho 100 PVU bất kể kiến trúc lõi xử lý
mà máy chủ dựa trên nó là gì. Nói cách khác, nếu một máy chủ có bốn bộ xử lý AMD lõi
tứ, tương đương với 800 PVU và một máy chủ Power7 với hai bộ xử lý lõi tứ, tương
đương với 960 PVU, với một máy chủ dự phòng ấm, bạn chỉ cần mua giấy phép cho máy
chủ đó với 100 PVU của các phiên bản DB2 tương ứng.
Ví dụ: Nếu máy chủ trong hình 6 chỉ sử dụng bốn lõi của máy chủ Power7, và giả sử mỗi
máy chủ chạy DB2 Workgroup (không còn giới hạn chỉ cho các máy chủ với mức tối đa
là 480-PVU kể từ tháng 6 năm 2011), bạn sẽ phải mua tổng cộng là 580 PVU cho giải
pháp này: (480 PVU cho máy chủ 2 + 100 PVU cho máy chủ dự phòng ấm 1).
Ghi chú: Kể từ tháng 6 năm 2011, mức hạn chế 480 PVU đã được gỡ bỏ. Điều này có
nghĩa là bây giờ bạn có thể cài đặt và sử dụng DB2 Workgroup trên máy chủ vật lý hay
ảo với hơn 480 PVU, với điều kiện là bạn đã mua giấy phép một cách thích hợp cho tất
cả các PVU mà DB2 Workgroup có quyền truy cập, lên đến 16 lõi. Nếu các máy chủ vật
lý hay ảo có hơn 16 lõi, bạn vẫn chỉ trả tiền cho 16 lõi thôi bởi vì đó là tất cả các lõi mà
DB2 sẽ sử dụng. Điều này áp dụng cho phiên bản 9.5 và 9.7.
Giấy phép người dùng được ủy quyền (AU)

Đối với bất kỳ máy chủ DB2 nào đã mua giấy phép theo mô hình AU, bạn phải mua giấy
phép cho máy chủ dự phòng ấm bằng cách mua số lượng AU tối thiểu cho phiên bản đó
để máy chủ đó trở thành một máy chủ dự phòng ấm. Đối với DB2 Express và DB2
Workgroup, bởi vì số lượng tối thiểu AU bạn phải mua giấy phép là 5 cho bất kỳ cài đặt
nào, một máy chủ dự phòng ấm yêu cầu 5 giấy phép AU. Trong hình 6, nếu một máy chủ
của DB2 Workgroup là nóng và đã được định cấu hình để tham gia vào cụm HADR
nóng/ấm, và bạn có 100 người sử dụng, bạn sẽ cần phải mua tổng cộng 105 giấy phép
AU cho DB2 Workgroup cho 100 người sử dụng: 100 AU + 5 AU cho máy chủ dự phòng
ấm. (Tất nhiên, số lượng tối thiểu của giấy phép AU cho máy chủ nóng cần phải được
đáp ứng nếu số lượng người dùng ít hơn số lượng yêu cầu tối thiểu.)
Nếu hình 6 sử dụng DB2 Enterprise, mọi thứ có khác một chút và thừa nhận rằng có một
chút khó hiểu hơn. Trong DB2 Enterprise, số lượng tối thiểu là 25AU cho mỗi 100 PVU
(đã được trình bày chi tiết ở phần trước của bài viết này). Vì bạn phải mua giấy phép tối
thiểu 100 PVU cho máy chủ dự phòng ấm trong mô hình PVU với máy chủ DB2
Enterprise, bạn chuyển đổi 100 PVU tối thiểu thành 25 AU và nó trở thành số lượng AU
tối thiểu cần thiết cho một máy chủ dự phòng ấm của DB2 Enterprise được mua giấy
phép bằng cách sử dụng mô hình AU. Chúng ta hãy làm rõ bằng việc sử dụng ví dụ trong
hình 6. Nếu các máy chủ trong hình 6 là các máy chủ hai ổ cắm lõi kép dựa trên Intel
x86, thì tổng mức PVU cho máy chủ nóng sẽ là 200 PVU. Nếu bạn chỉ có ba người dùng
truy cập vào máy chủ nóng DB2 Enterprise, bạn vẫn sẽ cần tổng cộng 75 AU cho cấu
hình này: (200/100 = 2 x 25 AU) cho máy chủ nóng cộng với 25 AU cho máy chủ dự
phòng ấm của DB2 Enterprise. Tuy nhiên, nếu các máy chủ trong hình 6 là các máy chủ
hai ổ cắm lõi kép Power7 (do đó, có tổng cộng 4 lõi trên máy chủ này), mức PVU tổng
cộng cho máy chủ nóng sẽ là 480 PVU. Nếu bạn chỉ có ba người dùng truy cập vào máy
chủ nóng của DB2 Enterprise, bạn sẽ cần tổng cộng là 150 AU cho cấu hình này:
(480/100 = 4.8 làm tròn lên là 5 x 25 AU cho máy chủ nóng = 125 AU) + 25 AU tối thiểu
cho máy chủ dự phòng ấm của DB2 Enterprise.
Về đầu trang
Dự phòng lạnh
Cấu hình dự phòng lạnh là cấu hình trong đó ít nhất một máy chủ trong cụm không có cơ sở dữ

liệu DB2 đang phục vụ các tải công việc giao dịch hoặc truy vấn của người sử dụng trong thời
gian hoạt động bình thường và nó không thực hiện bất cứ hành động quản trị nào để hỗ trợ kịch
bản chuyển đổi dự phòng chẳng hạn như có cơ sở dữ liệu ở trạng thái treo chờ cuộn tiến
(rollforward) để hỗ trợ HADR, trên thực tế, máy chủ lạnh có thể thậm chí không được cắm
nguồn điện. Kịch bản dự phòng lạnh được thể hiện trong Hình 7.

Hình 7. Máy chủ 1 là máy chủ dự phòng lạnh cho máy chủ 2

Trong ví dụ này, trong thời gian hoạt động bình thường, máy chủ 2 đang sử dụng cho tải công
việc truy vấn và giao dịch (được ghi chú là Active Work – Làm việc chủ động - trong hình),
trong khi máy chủ 1 không có cá thể DB2 đã chạy. Có thể thậm chí là DB2 được cài đặt trên máy
chủ và máy chủ đó bị ngắt điện, trong trường hợp có lỗi, máy chủ 1 được khởi động, được hồi lại
đến một thời điểm nào đó từ ảnh sao lưu, và mở lên cho các giao dịch của người dùng. Cũng có
thể là trường hợp máy chủ 1 được cấu hình để là một phần của cụm Tivoli SA-MP (trong số các
tùy chọn phân cụm khả năng sẵn sàng cao khác, bao gồm cả PowerHA cho AIX), nhưng cá thể
cơ sở dữ liệu không được kích hoạt. Như bạn có thể tưởng tượng, cấu hình dự phòng lạnh không
có gì nhiều của một giải pháp về khả năng sẵn sàng, ở chỗ là MTTR sẽ thường là lâu hơn rất
nhiều cấu hình dự phòng nóng hoặc ấm; tuy nói như thế, nhưng nó có thể phù hợp với nhu cầu
của một số ứng dụng của bạn, và nếu như thế, chi phí của giải pháp này thực sự hấp dẫn trong
DB2 9.5 và mới hơn, vì những lý do trình bày ở phần trên của bài viết này.
Xem xét khi mua giấy phép cho một máy chủ dự phòng lạnh
Máy chủ dự phòng lạnh DB2 không cần phải được mua giấy phép và do đó rõ ràng là không phải
xem xét việc mua giấy phép. Một nguyên tắc ngón tay cái để xác định xem một máy chủ dự
phòng có thể được phân loại là lạnh hay không là hãy xem liệu cá thể DB2 có được khởi động
hay không, tuy nhiên có một số trường hợp ngoại lệ. Ví dụ, nếu bạn lấy ảnh chụp nhanh một máy
chủ sản xuất và khởi động máy chủ dự phòng DB2 cho mục đích duy nhất là thực hiện một bản
sao lưu và sau đó dừng máy chủ lại, chúng tôi coi rằng đó là máy chủ dự phòng lạnh và không
cần mua giấy phép cho máy chủ này.
Do đó đây là một ví dụ hoàn hảo về việc quy tắc mua giấy phép của một số phiên bản mới nhất
trong DB2 giúp bạn tiết kiệm tiền như thế nào và có ai lại không tìm kiếm điều đó trong thời

buổi kinh tế eo hẹp này? Hãy giả sử bạn đang mua giấy phép máy chủ DB2 Workgroup 9 cùng
với gói tính năng pureXML cho ứng dụng dựa trên XML với một số yêu cầu về khả năng sẵn
sàng cao. Trong DB2 9, bạn phải mua giấy phép đầy đủ cho máy chủ nóng (như dự kiến) cho cả
DB2 và gói tính năng của pureXML, ngoài ra, phải mua giấy phép máy chủ lạnh cho 100 PVU
của DB2 Workgroup và 100 PVU của gói tính năng của pureXML. Trong DB2 9.7, bạn chỉ cần
mua giấy phép DB2Workgroup cho máy chủ nóng. Các tính năng của pureXML được miễn phí
trong tất cả các ấn bản của DB2 (từ 09 tháng 2 năm 2009) và máy chủ dự phòng lạnh không yêu
cầu phải mua giấy phép. Bây giờ thêm vào thực tế là bạn có thể mua giấy phép SOCKET cho
DB2Workgroup, và bạn đã tăng gấp đôi khả năng giải pháp sẵn sàng cao dựa trên XML của bạn
và giảm chi phí của mình trên 50%!
Về đầu trang
Vươn lên cao hơn - khả năng sẵn sàng là như thế
Như bạn thấy, bạn có rất nhiều tùy chọn khả năng sẵn sàng cao với DB2. Chúng tôi khuyến nghị
khách hàng tạo ra phân loại nhiều tầng cho các ứng dụng yêu cầu khả năng sẵn sàng cao; ví dụ:
Xếp hạng đồng, bạc và vàng. Đó có thể sẽ là, bất cứ thứ gì được xếp hạng Đồng sẽ sử dụng máy
chủ dự phòng lạnh và cụm được tích hợp của DB2, trong khi giải pháp hạng Bạc sử dụng công
nghệ HADR của DB2, và cuối cùng, giải pháp hạng Vàng sẽ là một cấu hình dự phòng nóng
chẳng hạn như DB2 pureScale. Chúng tôi đã xếp cạnh nhau thành một bản các giải pháp có thể
về khả năng sẵn sàng cao và phân loại tương ứng của chúng trong bảng 2.

Bảng 2. Tiếp cận các yêu cầu khả năng sẵn sàng cao của bạn với giải pháp phân tầng và các
công nghệ DB2 tương ứng có sẵn
Đồng Bạc Vàng
Phân cụm được tích hợp của
DB2
HADR DB2 pureScale
 Nóng/lạnh
 Giải pháp khả năng sẵn
sàng cơ bản
 Miễn phí trong hầu hết

các trường hợp
 Cung cấp chuyển đổi dự
phòng, thông thường
trong chưa đầy 5 phút
 Nóng/ấm (Nóng tùy
chọn với đọc ở chế độ
dự phòng)
 Cung cấp chuyển đổi
dự phòng rất nhanh,
thường dưới 1 phút
 Dễ dàng cài đặt với
khả năng sẵn s
àng chìa
khóa trao tay
 Mua giấy phép tối
thiểu trên máy chủ dự
phòng
 Tùy chọn khả năng
mất dữ liệu bằng
 Nóng/nóng
 Chuyển đổi dự phòng tr
ực
tuyến
 Giao dịch tr
ên các nút còn
hoạt động không bị ảnh
hưởng
 Cung cấp chuyển đổi dự
phòng nhanh nhất, thông
thường dưới 30 giây

 Khả năng dãn nở nhanh
tr
ực tuyến để đáp ứng cao
điểm tải công việc
không
Tại đây chúng tôi muốn lưu ý rằng đây không phải luôn luôn mọi thứ đều cần phải là giải pháp
vàng. Mọi người đều nghĩ rằng họ cần khả năng sẵn sàng 24 giờ/ngày 7 ngày/tuần cho tất cả các
ứng dụng, nhưng trong kinh nghiệm tư vấn rộng lớn của chúng tôi, không phải là như vậy. Ví dụ:
Một khách hàng có một ứng dụng trọng yếu cần phải sẵn sàng 24x7, nhưng các ứng dụng khác
của họ có thể bị ngừng chạy đến hai ngày. Trong những trường hợp này, có nên xử lý tất cả như
nhau dưới góc nhìn khả năng sẵn sàng? Có lẽ thế nếu bạn có một ngân sách không giới hạn. Hãy
chọn giải pháp khả năng sẵn sàng đúng, phù hợp với thỏa thuận cấp độ dịch vụ (SLA) hỗ trợ
công việc của bạn: khả năng sẵn sàng cao trong đường cong chi phí tuyến tính. Ngoài phần mềm,
bạn muốn khả năng sẵn sàng cao càng nhiều, thì bạn thường phải trả chi phí càng cao (hãy nghĩ
đến dư thừa dự phòng, giấy phép, nguồn điện và nhiều thứ nữa). Điểm mấu chốt không phải là
tất cả mọi thứ cần phải là cực kỳ sẵn sàng, hãy thông minh và hãy sử dụng đúng công nghệ cho
các yêu cầu đúng đắn về khả năng sẵn sàng cao.
Mặc dù nằm ngoài phạm vi của bài viết này, để cho đầy đủ, chúng tôi nghĩ rằng chúng tôi sẽ đưa
vào thêm bản quy trình Phục hồi sau thảm họa (DR - Disaster Recovery) "người anh em họ" của
khả năng sẵn sàng cao trong bảng 3. (Các cân nhắc xem xét tương tự mà bạn sử dụng để xác định
mua giấy phép phù hợp cho khả năng sẵn sàng cao cũng áp dụng được cho phục hồi sau thảm
họa):

Bảng 3. Tiếp cận các yêu cầu phục hồi sau thảm họa của bạn với một giải pháp phân tầng
và các công nghệ DB2 tương ứng có sẵn
Đồng Bạc Vàng
Tạo bản sao Q Tạo bản sao vật lý HADR Tạo bản sao lô-gic HADR
 Nóng/nóng
 Truy c
ập không giới hạn

vào cơ sở dữ liệu đích
 Hỗ trợ các phiên bản
DB2 khác nhau ở dữ
liệu nguồn và đích
 Hỗ trợ chia tập con dữ
liệu
 Hỗ trợ nhiều cơ sở dữ
liệu đích
 Chuyển đổi dự phòng
trực tuyến
 Có thể tạo bản sao tới
một hình trạng khác
 Chỉ phi đồng bộ
 Có th
ể phức tạp khi thiết
lập
 Không hỗ trợ DDL
 Nóng/ấm
 Tùy chọn không mất
dữ liệu
 Cung cấp chuyển đổi
dự phòng rất nhanh,
thường dưới 1 phút
 Dễ cài đặt với khả
năng sẵn sàng chìa
khóa trao tay
 Hỗ trợ tạo bản sao
DDL và DML
 Việc sử dụng máy chủ
dự phòng bị hạn chế

 Ch
ỉ hỗ trợ một đích dữ
liệu
 Chỉ tạo bản sao toàn
bộ cơ sở dữ liệu
 Nóng/nóng
 Tùy chọn không mất dữ
liệu
 Chuyển đổi dự phòng tr
ực
tuyến
 Cung cấp chuyển đổi dự
phòng nhanh nhất, thông
thường dưới 30 giây
 Khả năng dãn nở trực
tuyến để đáp ứng cao
điểm tải công việc.
 Truy cập không giới hạn
đến cơ sở dữ liệu đích
 Có thể được định cấu h
ình
để áp dụng chậm.
 Hỗ trợ nhiều cơ s
ở dữ liệu
đích
 Hỗ trợ tạo bản sao DDL
và DML
 Khả năng nâng cấp phiên
bản cuộn
 Có thể tạo bản sao tới

hình trạng khác