Di chuyển ứng dụng PHP từ MySQL sang DB2 Phần 4: Triển khai ứng dụng của bạn pdf

Di chuyển ứng dụng PHP từ MySQL sang DB2
Phần 4: Triển khai ứng dụng của bạn
Giới thiệu về triển khai
Bài này trình bày bốn bước chính để triển khai và hỗ trợ ứng dụng và cơ sở dữ liệu
một khi nó đã sẵn sàng cho sản xuất. Nếu cần, hãy tham khảo Phần 1 của loạt bài
này để xem lịch trình các bước ấy trong quá trình di trú tổng thể trước khi tiến
hành triển khai.
Bước 1: Tạo một môi trường sản xuất mới
 Xác định cấu trúc liên kết sản xuất và chiến lược triển khai.
 Cấu hình các máy chủ dữ liệu DB2 chính và bản sao sản xuất.
 Cấu hình máy chủ ứng dụng PHP sản xuất.
Bước 2: Chuẩn bị một chiến lược giám sát ứng dụng
 Thực hiện hay cập nhật cơ chế báo cáo lỗi PHP.
 Xác định các giá trị thích hợp cho các tính năng tự trị trong DB2.
 Xác nhận các giá trị thiết lập sao lưu dự phòng và sao chép cơ sở dữ
liệu.
Bước 3: Triển khai ứng dụng đã cập nhật
 Lập lịch biểu một ngày triển khai để giảm thiểu ảnh hưởng đến công
việc kinh doanh.
 Bắt giữ lại các bản sao lưu ảnh của hệ thống hiện có và hệ thống mới.
 Triển khai dữ liệu DB2.
 Triển khai mã PHP.
 Giám sát hệ thống mới.
Bước 4: Xử lý hỗ trợ liên tục
 Đáp ứng hoặc tránh các vấn đề hiệu năng.
 Cấu hình lại khi kích cỡ của dữ liệu và luồng công việc phát triển
thêm.
Về đầu trang
Hiểu một nghiên cứu sâu ví dụ về cấu trúc liên kết triển khai PTT hiện có
Nhắc nhở
Nếu cần, hãy tự mình tìm hiểu phần Tài nguyên có thể có ích trong việc di trú của

bạn. Các tài nguyên sau có thể đặc biệt có ích cho bước này:
 Chương 9 và 10 trong ấn phẩm Redbooks® của IBM Hướng dẫn chuyển đổi
MySQL sang DB2 (MySQL to DB2 Conversion Guide).
 Bài "Danh sách nên xem: Quản trị cơ sở dữ liệu của DB2 cho Linux, UNIX
và Windows" trên developerWorks.
 Loạt bài "Sử dụng các kỹ năng về MySQL để tìm hiểu DB2 Express" trên
developerWorks.
 Sách trắng "Các hướng dẫn thực hành tốt nhất: Các chiến lược giảm chi phí
với DB2" trên developerWorks .
Một tùy chọn khác là sử dụng đám mây cho quá trình di trú. Bạn có thể sử dụng
các ảnh máy Amazon (AMI) Linux và DB2 của Amazon EC2 hoặc đăng ký dùng
SmartCloud của IBM (trước đây được biết đến với tên gọi Phát triển và thử nghiệm
trên Đám mây IBM) (xem Tài nguyên).
Để có được cấu trúc liên kết triển khai ví dụ trong bài này, hệ thống sản xuất PTT
(Project Tracking Tool - Công cụ dò vết dự án) có một máy Linux chạy máy chủ
web Apache được biên dịch từ mã nguồn với phần mở rộng mod_php được xây
dựng và được nạp như một mô-đun động, một máy Linux chạy cơ sở dữ liệu chủ
MySQL và một máy Linux thứ ba chạy ;một cơ sở dữ liệu MySQL sao chép cho
các phân tích và các truy vấn đặc biệt.
Ứng dụng PTT được sử dụng cho các chức năng khác nhau để hỗ trợ luồng công
việc thông tin được công bố trên trang web của IBM. Hơn 4.000 người dùng trên
toàn thế giới truy cập và sửa đổi cơ sở dữ liệu MySQL thông qua mặt trước của
trang web PHP. Tại bất kỳ thời điểm nào cũng có vài trăm người dùng đang hoạt
động đồng thời trên hệ thống.
Cấu trúc liên kết đơn giản này được hiển thị trong Hình 1.

Hình 1. Cấu trúc liên kết máy chủ và phần mềm ban đầu

Phần lớn người dùng truy cập cơ sở dữ liệu chủ thông qua mặt trước của Apache
và PHP. Một ít người dùng kết nối trực tiếp đến cơ sở dữ liệu sao chép để chạy các

truy vấn SQL đặc biệt hoặc sử dụng Hyperion Brio để tạo ra các báo cáo.
Trong ví dụ triển khai, vẫn duy trì cách bố trí ba máy chủ giống nhau, nhưng các
hệ thống MySQL chính và bản sao đã được thay thế bằng các cá thể của DB2. Cấu
hình Apache và PHP được biên dịch từ nguồn đã được thay thế bằng các phiên bản
đóng gói nhị phân của Apache và PHP (Zend Server với các phần mở rộng DB2).
Bài này mô tả các yếu tố cần xem xét khi lựa chọn một cấu trúc liên kết PHP và
DB2, các bước cần thiết để di chuyển mã vào sản xuất càng trôi chảy càng tốt và
cách duy trì một hệ thống ổn định sau khi triển khai.
Về đầu trang
Chuẩn bị các tài sản triển khai
Để chuẩn bị triển khai các ứng dụng đã cập nhật, hãy bảo đảm rằng một bản sao ổn
định của cơ sở dữ liệu và mã đã sẵn sàng cho sản xuất. Bạn sẽ đạt tới điểm này sau
một số lần lặp lại quá trình di trú và chuyển đổi được mô tả trong Phần 2 và Phần 3
của loạt bài này, xem phần Tài nguyên. Ngoài sự ổn định, hãy chắc chắn rằng chức
năng của ứng dụng nói chung đã được các đại diện của các bên liên quan chấp
thuận.
Bản sao ổn định và được phê duyệt của dữ liệu và cấu trúc cơ sở dữ liệu DB2 được
di trú
Tùy thuộc vào việc liệu môi trường sản xuất của bạn có cùng một nền tảng
như hệ thống phát triển của bạn hay không, ví dụ nếu cả hai đều là các hệ
thống Linux 64-bit, bạn có thể dùng một trong hai cách tiếp cận để di
chuyển dữ liệu của mình vào sản xuất. Nếu chúng có cùng một nền tảng, chỉ
cần sao lưu cơ sở dữ liệu trên hệ thống phát triển của bạn và phục hồi nó như
một bản sao mới của cơ sở dữ liệu trong sản xuất. Trái lại, nếu chúng là các
nền tảng khác nhau, bạn sẽ cần tính đến tập hợp các kịch bản lệnh của ngôn
ngữ định nghĩa dữ liệu (DDL) để tạo ra cấu trúc cơ sở dữ liệu, bao gồm các
đối tượng như khóa và các ràng buộc giá trị được phép, các chỉ mục và các
thiết lập cấu hình. Tập hợp này cũng sẽ bao gồm các kịch bản lệnh nhập
khẩu thường dùng để di chuyển dữ liệu đã di trú vào hệ thống DB2 mới.
Bản sao ổn định và được phê duyệt của mã PHP đã chuyển đổi và các tệp tĩnh khác

Bản sao này bao gồm mã PHP đã chuyển đổi và tất cả các tệp JavaScript,
CSS và hình ảnh cần thiết khác để tạo ra ứng dụng web. Bản sao này cũng
bao gồm các kịch bản lệnh vỏ (shell) được lập lịch biểu và được gọi thông
qua các công việc dựa theo lịch biểu thời gian (cron) để xử lý các thông báo
định kỳ và bảo trì thường xuyên, chẳng hạn như việc thực hiện các quy tắc
lưu giữ dữ liệu hàng đêm.
Dữ liệu đúng thời điểm
Trong hầu hết các trường hợp, hệ thống sản xuất MySQL của bạn sẽ tiếp tục tạo ra
các dữ liệu mới khi bạn tiến hành các bước trong Phần 2 và 3 của loạt bài này, xem
phần Tài nguyên. Nhiều khả năng bạn sẽ cần nhập khẩu dữ liệu mới nhất này vào
bản sao ổn định của mình để di chuyển vào sản xuất như trong Bước 2 của Phần 2.
Xem Liệt kê 3 trong bài đó để thấy cách di chuyển chỉ dữ liệu đã thay đổi kể từ khi
xuất khẩu ban đầu.
Hãy chắc chắn tham khảo các quyết định về cấu hình của bạn và các bài học rút ra
từ các bước ở trên trong loạt bài này để bạn có thể bảo đảm hệ thống sản xuất được
cấu hình đúng khi bạn triển khai. Hãy xem xét việc lưu một ảnh chụp nhanh của cả
hai hệ thống hiện có và hệ thống mới như là các ảnh máy ảo trước khi triển khai tại
các điểm mốc quan trọng để dùng làm các bản sao lưu dự phòng và làm các vạch
chuẩn để so sánh việc cải thiện mã tiếp theo.
Nếu bạn muốn bắt giữ lại một hình ảnh của một cấu hình máy tính vật lý, bạn có
thể làm việc này bằng VMware vCenter Converter (Bộ chuyển đổi vCenter của
Vmware) miễn phí. Có một sự thay thế khác là xem xét dùng đám mây cho những
thay đổi thực hành như vậy. Bạn có thể sử dụng các Ảnh máy Amazon (AMI) DB2
của Amazon EC2 hoặc bạn có thể đăng ký dùng SmartCloud của IBM (trước đây
được gọi là Phát triển và thử nghiệm trên Đám mây của IBM). Với các máy ảo,
bạn sẽ có thể không phải mua sắm phần cứng máy chủ và cài đặt một hệ điều hành
và DB2, để tiết kiệm thời gian, đẩy nhanh quá trình di trú và mang lại cho bạn sự
tự tin hơn để trải nghiệm với cấu hình phù hợp nhất cho nhu cầu của bạn. Có thể
tìm thấy các liên kết đến tất cả những sản phẩm này trong phần Tài nguyên.
Về đầu trang

Bước 1: Tạo một môi trường sản xuất mới
Vì bạn đã di trú dữ liệu và mã trong Phần 2 và 3 của loạt bài này, hãy xem phần
Tài nguyên, bạn đã nắm bắt được các lưu ý về cấu hình để biểu thị kiểu tài nguyên
mà ứng dụng của bạn sẽ cần có trong sản xuất. Bây giờ ứng dụng này đã được thử
nghiệm và được kiểm tra, bạn đã sẵn sàng để xác nhận môi trường có sẵn cho sản
xuất cần thiết để chạy nó.
Trong nghiên cứu sâu này, ứng dụng triển khai sản xuất được chuẩn bị trên các
máy chủ vật lý mới (mặc dù các máy ảo cũng là một tùy chọn), chứ không phải cấu
hình lại các máy chủ hiện có để lưu trữ trên đó hệ thống dựa vào MySQL đã thấy ở
trên trong Hình 1. Bước này liên quan đến các bước con sau đây.
 Xác định chiến lược sản xuất.
 Cấu hình các máy chủ dữ liệu DB2 chính và bản sao.
 Cấu hình máy chủ ứng dụng PHP.
Xác định chiến lược sản xuất
Trong ví dụ này, một cơ sở dữ liệu DB2 mới và một bản sao được cài đặt và dữ
liệu được di trú lên cả hai máy chủ Linux 64-bit. Cả hai máy chủ MySQL chính và
bản sao cũ hơn có bốn lõi xử lý (3,0 GHz) và 8 GB bộ nhớ RAM. Hai máy chủ
DB2 mới có 8 lõi xử lý (2,5 GHz) và 16 GB RAM. Các thông số kỹ thuật mạnh
hơn phản ánh tuổi tác của máy tính chứ không phải là một yêu cầu tiên quyết để có
phần cứng tốt hơn cho DB2. Các kinh nghiệm di trú, chuyển đổi và thử nghiệm của
bạn từ các phần trước của loạt bài này, xem phần Tài nguyên, sẽ giúp bạn phối hợp
đúng các tài nguyên cho tải công việc của mình.
Các cách tiếp cận triển khai
Bạn sẽ cần trả lời những câu hỏi quan trọng sau đây khi bạn chuẩn bị triển khai
ứng dụng mới được cập nhật của mình vào sản xuất.
 Bạn có bắt đầu với một cấu hình mới hay là bạn thay thế phần mềm trên hệ
thống hiện có và sử dụng lại phần cứng ? Nói cách khác, bạn có cài đặt DB2
và gỡ bỏ cài đặt MySQL như là một phần trong cùng một hoạt động triển
khai không?
 Bạn có triển khai nâng cấp cơ sở dữ liệu và nâng cấp phiên bản PHP cùng

một lúc hay là bạn triển khai mỗi thành phần ở một giai đoạn riêng biệt? Đó
là, nâng cấp môi trường PHP lên Zend Server trong khi vẫn sử dụng
MySQL, sau đó thay thế MySQL bằng DB2?
Không phải lúc nào cũng có một câu trả lời rõ ràng. Trong ví dụ này, việc bắt đầu
từ các thành phần mới được cài đặt và triển khai cấu trúc liên kết hoàn chỉnh có ít
rủi ro hơn vì nói chung mọi thứ đã được thử nghiệm và vì bạn có thể dễ dàng quay
trở lại hệ thống cũ trong lúc triển khai nếu có vấn đề.
Quyết định có nên thay đổi môi trường sản xuất hiện tại của bạn hay bắt đầu bằng
các máy tính mới hay không
Dựa trên những quan sát từ việc thử nghiệm ứng dụng và việc hiểu các đặc tính
hiệu năng của nó trong Phần 2 và Phần 3 của loạt bài này, xem phần Tài nguyên,
phần cứng của bản chính và bản sao MySQL hiện có (hoặc tương tự) có thể đã đủ
cho hệ thống mới dựa trên DB2.
Tuy nhiên, do hệ thống hiện có đã nhiều hơn ba tuổi rồi, nên trường hợp thử
nghiệm này đã bắt đầu với phần cứng mới để vừa mạnh hơn lại vừa tiết kiệm năng
lượng hơn. Bạn có thể muốn đánh giá xem đây có phải là lúc để mua sắm phần
cứng mới không hoặc nếu không thì có phải là lúc để nâng cấp hệ thống của bạn để
đáp ứng tốt nhất với tải công việc cơ sở dữ liệu và ứng dụng của bạn không, dựa
trên bất kỳ sự nghẽn cổ chai nào mà bạn thấy trong quá trình di trú và chuyển đổi.
Quyết định xem có nên thay thế toàn bộ hệ thống sản xuất hay là nâng cấp trong
nhiều giai đoạn
Một vấn đề cần xem xét khác đối với quá trình triển khai của bạn là quyết định
xem bạn sẽ xây dựng một hệ thống hoàn toàn mới tách biệt khỏi bất kỳ các máy
chủ sản xuất hiện tại nào của bạn hay là bạn sẽ thay thế các phần mềm trên các
máy chủ vật lý hay các máy chủ ảo hiện tại của bạn. Một hệ quả tất yếu của quyết
định này là liệu bạn sẽ chuyển hoàn toàn dữ liệu đồng bộ từ hệ thống cũ sang hệ
thống mới cùng một lúc không hay là bạn sẽ thay thế dần dần một số thành phần.
Ví dụ, một tùy chọn đã được xem xét là thay thế một bản xây dựng tùy chỉnh của
Apache và PHP bằng các phiên bản đóng gói trước khi chuyển đổi từ MySQL sang
DB2. Cuối cùng, đã quyết định là thay thế tất cả các thành phần đã được thử

nghiệm tích hợp cùng một lúc, chứ không phải là thực hiện các thay đổi cơ sở hạ
tầng dần dần từng bước theo các giai đoạn.
Cuối cùng, hệ thống mới dựa trên DB2 phản chiếu cấu trúc liên kết triển khai
MySQL hiện có, nhưng nó được xây dựng tách khỏi hệ thống trung gian và hệ
thống sản xuất hiện có. Khi đã đến thời gian bật nguồn cho hệ thống mới, lưu
lượng đã được chuyển hướng đến các máy chủ web mặt trước mới. Điều này cũng
có nghĩa là việc triển khai có thể quay lại hệ thống cũ bằng cách đảo ngược chuyển
hướng.
Lúc đầu, đã lập kế hoạch để chỉ thay thế các cá thể MySQL bằng các cơ sở dữ liệu
DB2, nhưng trường hợp sử dụng này đã tận dụng lợi thế của quá trình di trú để
đồng thời nâng cấp phiên bản đã biên dịch tùy chỉnh của Apache và PHP bằng các
phiên bản đóng gói và dễ bảo trì.
Cấu hình các máy chủ dữ liệu DB2 chính và bản sao
Hãy cài đặt phiên bản 9.7.2 của DB2 Enterprise (Doanh nghiệp DB2) lên hai máy
chủ Linux doanh nghiệp Red Hat 64-bit giống hệt nhau. Như đã lưu ý trong ô đóng
khung bên cạnh đầu tiên trong bài này, các bài báo trên developerWorks là "Quản
trị cơ sở dữ liệu DB2 cho Linux, UNIX và Windows" và "Sử dụng các kỹ năng
MySQL để tìm hiểu DB2 Express: Các nhiệm vụ quản trị và các nhiệm vụ cơ bản
của DB2 so với MySQL" đưa ra một tổng quan rất hay về các nhiệm vụ cài đặt và
cấu hình then chốt và có thể tìm thấy các bài này trong phần Tài nguyên.
Cấu hình máy chủ ứng dụng PHP
Tiếp theo, hãy cài đặt Apache và Server Zend lên máy chủ ứng dụng. Máy chủ này
có thể chia sẻ các đặc tả tương tự như hai máy chủ cơ sở dữ liệu. Trên máy chủ sản
xuất trước đó, Apache đã được biên dịch từ mã nguồn và PHP được xây dựng để
được chạy như là một mô-đun được chia sẻ động.
Đối với hệ thống sản xuất mới, Server Zend đã được sử dụng để thay thế và tiện
ích quản lý gói của hệ điều hành được phép xử lý gói và các bản nâng cấp Apache
(http). Người ta đã chọn cách này vì những lý do sau đây.
 Zend Server là một bản phân phối nhị phân của PHP để tự động cấu hình
máy chủ web Apache. Nó được hỗ trợ và đã được thử nghiệm trên các bản

phân phối Linux mức doanh nghiệp. Việc cài đặt và bảo trì rất dễ dàng theo
một định dạng gói để có thể được quản lý bằng công cụ yum trên Red Hat
Linux.
 Zend Server bao gồm các trình điều khiển DB2 và cung cấp một giao diện
dựa vào Giao diện người dùng đồ họa (GUI) để cấu hình các phần mở rộng
cần thiết.
 Zend Server cung cấp chức năng giám sát, ghi nhật ký và cảnh báo để mang
lại sự hiểu biết tốt hơn về cách hệ thống đang hoạt động.
Bài báo "Tạo ra một môi trường phát triển PHP trên đám mây" của Daniel Krook
trên developerWorks cung cấp thêm chi tiết về cách cài đặt và cấu hình DB2 với
Zend Server (xem phần Tài nguyên). Bài này đã đi theo một quá trình giống hệt.
Hình 2 cho thấy hệ thống sau khi đã thay thế MySQL bằng DB2 và hệ thống đã
nâng cấp lên Zend Server. Miếng ghép còn thiếu cuối cùng là cài đặt phần mềm
Cognos Business Intelligence của IBM dựa trên web, để thay thế cho công cụ
Hyperion Brio di sản chạy trên máy tính để bàn, đã được cấu hình để tạo ra các
phân tích từ cơ sở dữ liệu DB2 mới. Bạn có thể tìm hiểu thêm về cách cài đặt
Cognos bằng cách tham khảo các liên kết đến các sản phẩm trong phần Tài
nguyên.

Hình 2. Cấu trúc liên kết máy chủ và phần mềm mới

Về đầu trang
Bước 2: Chuẩn bị một chiến lược giám sát ứng dụng
Nếu bạn đang di trú từ một hệ thống sản xuất hoàn thiện, bạn có thể có một cơ chế
báo cáo lỗi đang tồn tại. Trong trường hợp này, do có sử dụng tầng trừu tượng của
cơ sở dữ liệu PDO trong PHP, nên vẫn có thể tiếp tục sử dụng hệ thống hiện có để
thông báo cho các quản trị viên biết các vấn đề trong mã. Ở mức cơ sở dữ liệu,
DB2 Health Monitor (Bộ theo dõi sức khỏe của DB2) được sử dụng để đưa ra các
cảnh báo dựa vào lúc các ngưỡng cụ thể đã đạt đến hay vượt quá giới hạn quy
định. Bước này liên quan đến các bước con sau đây.

 Cấu hình cơ chế báo cáo lỗi PHP
 Xác định các thiết lập bảo trì DB2
 Xác nhận các thiết lập sao lưu dự phòng và sao chép DB2
Ngoài các hiểu biết sâu hơn do mã báo cáo lỗi tùy chỉnh cung cấp, trường hợp sử
dụng này cũng được hưởng lợi từ việc theo dõi và phân tích chi tiết mịn hơn nhờ
việc chuyển đổi sang Zend Server.
Cấu hình cơ chế báo cáo lỗi PHP
Dù bạn phát triển và thử nghiệm cẩn thận đến mấy đi nữa, thì bạn vẫn có cơ hội
phát sinh các lỗi không lường trước được trong sản xuất. Ứng dụng này đã luôn kết
hợp một tính năng gỡ lỗi tự động hiệu quả. Nếu ứng dụng web gặp một lỗi, nó sẽ
thu thập tất cả các thông tin về bối cảnh lỗi và gửi một email đến những người phụ
trách phát triển để họ có thể ngay lập tức nhận biết và sửa chữa lỗi. Điều này đặc
biệt có ích với một ứng dụng vừa được di trú sang DB2. Bạn có thể tính đến các
mã trạng thái và các mã lỗi SQL của DB2 chi tiết để giúp một nhà phát triển trong
việc gỡ lỗi.
Trường hợp sử dụng này dựa vào cơ chế báo cáo lỗi của ứng dụng được hiển thị ở
trên trong Hình 2 và nhờ vào việc thiết lập các ngưỡng với cơ sở dữ liệu để nó gửi
các thông báo cơ sở dữ liệu cụ thể. Trong trường hợp các ngưỡng này đã bị vượt
qua, DB2 Health Monitor sẽ gửi đi các thông báo email để cho biết có một vấn đề
tiềm ẩn.
Việc thu nhận thông tin về lỗi và hiệu năng kịp thời là rất quan trọng. Ứng dụng
này đã thực hiện hai loại thông báo email sau đây trong mã PHP dùng cho mục
đích này.
 Gửi email cho nhóm bảo trì khi xuất hiện bất kỳ các lỗi SQL nào.
 Gửi email cho nhóm bảo trì khi chạy bất kỳ trang nào kéo dài hơn 60 giây.
Để bắt giữ lỗi SQL, một lớp truy cập cơ sở dữ liệu đã được triển khai thực hiện để
cung cấp một loạt các phương thức thi hành tất cả truy vấn ứng dụng. Tất cả câu
lệnh SQL đã được định tuyến qua lớp này và các phương thức của nó, sao cho có
thể thực hiện các câu lệnh SQL bên trong một khối try/catch. Khi xuất hiện các lỗi,
lớp này có thể thu thập thông tin dò vết đầy đủ và gửi thông tin đó cho nhóm bảo

trì. Trong các email như vậy có các thông tin sau đây: mã lỗi và thông báo lỗi từ
DB2, câu lệnh SQL được thi hành, dò vết ngăn xếp PHP và tài khoản người dùng
cuối đã gọi hoạt động đó. Với thông tin này, nhóm bảo trì có thể cô lập các lỗi và
giải quyết vấn đề.
Liệt kê 1 cho thấy một đoạn mã của lớp truy cập cơ sở dữ liệu PHP, nơi câu lệnh
SQL được thực hiện trong một giao dịch PDO và để bắt giữ bất kỳ các vấn đề nào
qua một PDOException.

Liệt kê 1. Mã PHP ví dụ mẫu để bẫy và báo cáo các lỗi cơ sở dữ liệu khi sử dụng
PDOException

<?php
// Database query or update specified by the application.
// $query =
Database::beginTransaction();

try {
$res = Database::getRawResource()->prepare($query);
Database::$affectedRows = 0;
foreach ($data as $itemData) {
Database::$queryCount++;
if (!$res->execute($itemData)) {
throw new PDOException("Could not execute query:
$query");
}
Database::$affectedRows += $res->rowCount();
$res->closeCursor();
}

} catch (PDOException $e) {

Database::rollback();
$error = new error("Database error: " . $e->getMessage(), 0, $query);
if (true == Config::get('DB', 'DIE')) {
// Captures full trace error info and sends notification.
$error->nicedie();
return $error;
}
}

Database::commit();

Trong trường hợp thực hiện không tốt mã và các truy vấn, kịch bản lệnh này bắt
giữ lại thời gian thực hiện với mỗi trang. Kịch bản lệnh ghi lại thời gian bắt đầu
trước khi thực hiện logic nghiệp vụ chính và ghi nhận thời gian kết thúc sau khi nội
dung chính được hiển thị, rồi đánh giá toàn bộ giao dịch đã mất bao lâu. Nếu giao
dịch kéo dài hơn 60 giây, thì kịch bản lệnh này sẽ gửi ra thông báo email cùng với
dò vết ngăn xếp PHP, các tham số được gửi cùng với yêu cầu HTTP, thông tin
trình duyệt và tài khoản người dùng cuối đã gọi hoạt động này.
Liệt kê 2 cho thấy kịch bản lệnh PHP có sử dụng hằng số ngưỡng cấu hình (60
giây) và gửi một thông báo đến địa chỉ email của quản trị viên đã định

Liệt kê 2. Mã PHP ví dụ mẫu để bắt giữ lại thời gian thực hiện kịch bản lệnh

<?php
// This static function returns the current UNIX timestamp as microseconds.
function getmicrotime() {
list($usec, $sec) = explode(" ", microtime());
return ((float) $usec + (float) $sec);
}

$starttime = getmicrotime();

// Main PHP code for current page executes here.
//

$endtime = getmicrotime();

if(($starttime - $endtime) >=
$CONFIG['DEBUG']['EXECUTION_THRESHOLD']) {
$message = "Execution time >
".$CONFIG['DEBUG']['EXECUTION_THRESHOLD'].":\n\n";
$message .= Error::createReport();
Mailer::textmail(
$CONFIG['DEBUG']['EXECUTION_MAIL'],
'Execution time greater than '.
$CONFIG['DEBUG']['EXECUTION_THRESHOLD'] .
' seconds', $message
);
}

Xác định các thiết lập bảo trì DB2
Khi bạn chuẩn bị cơ sở dữ liệu của mình, bạn sẽ muốn bảo đảm rằng các thiết lập
bảo trì trong DB2 phù hợp với nhu cầu của mình. Một cấu hình ví dụ được hiển thị
trong Bảng 1. Các thiết lập này giúp cân đối giữa việc tự động hóa nhiều sự thay
đổi cấu hình DB2 thường lệ cho khớp với tải công việc nhưng vẫn mang lại nhiều
quyền kiểm soát sao lưu dự phòng và sao chép hơn.

Bảng 1. Các thiết lập bảo trì DB2
Mô tả Thiết lập Giá trị
Bảo trì tự động AUTO_MAINT On (Bật)

Sao lưu dự phòng cơ sở dữ liệu tự độngAUTO_DB_BACKUP

Off (Tắt)
Bảo trì bảng tự động AUTO_TBL_MAINT On (Bật)

Ghi dữ liệu thống kê tự động AUTO_RUNSTATS On (Bật)

Số liệu thống kê báo cáo tự động AUTO_STMT_STATS

On (Bật)

Lược tả số liệu thống kê tự động AUTO_STATS_PROF

Off (Tắt)
Các bản cập nhật lược tả tự động AUTO_STATS_PROF

Off (Tắt)
Tổ chức lại tự động AUTO_STATS_PROF

On (Bật)


Xác nhận các giá trị thiết lập sao lưu và sao chép DB2
Để sử dụng lại các kịch bản lệnh sao lưu dựa trên lịch biểu thời gian từ hệ thống
MySQL cũ và hệ thống lưu trữ để tuân theo một chính sách lưu giữ dữ liệu tùy
chỉnh, bạn có thể vô hiệu hóa việc sao lưu cơ sở dữ liệu tự động trong DB2 như đã
thấy ở trên trong Bảng 1.
Như đã lưu ý trong Phần 2, bạn có thể cấu hình cơ sở dữ liệu chủ của mình và cơ
sở dữ liệu sao chép để duy trì đồng bộ bằng cách sử dụng SQL Replication (Sao

chép SQL). Chính sách này đã được áp dụng và cơ sở dữ liệu bản sao đã được điền
với các dữ liệu từ cơ sở dữ liệu chủ bằng cách chạy lại các câu lệnh SQL từ bản ghi
nhật ký.
Chương 9 của Hướng dẫn chuyển đổi MySQL sang DB2, trong phần Tài nguyên,
đưa ra nhiều chi tiết hơn về các chiến lược sao lưu, phục hồi và sao chép. Hãy sử
dụng tài liệu này để tìm ra giải pháp phù hợp với bạn.
Về đầu trang
Bước 3: Triển khai ứng dụng đã cập nhật
Trong bước này, bạn đặt những mảnh ghép cuối cùng của việc triển khai vào vị trí
và làm cho hệ thống mới có sẵn cho những người dùng. Khi bạn thực hiện di trú dữ
liệu và mã, bạn sẽ bắt đầu hình thành một ý tưởng về ngày phát hành thích hợp.
Dựa trên kế hoạch dự án ban đầu trong trường hợp sử dụng này, người ta đã ước
tính là nó kéo dài khoảng ba tháng kể từ ngày bắt đầu dự án. Đánh giá này về công
việc còn lại cũng đã phù hợp với các nhu cầu của doanh nghiệp để bảo đảm rằng sự
ra mắt sẽ gây ra gián đoạn ít nhất cho những người dùng toàn cầu. Bước này liên
quan đến các bước con sau đây.
 Lập lịch biểu một ngày triển khai
 Bắt giữ lại các ảnh hệ thống hiện có và hệ thống mới
 Triển khai dữ liệu DB2
 Triển khai mã PHP
 Giám sát hệ thống mới
Lập lịch biểu một ngày triển khai
Để bảo đảm triển khai thành công, hãy chọn một ngày sao cho là tốt nhất với
những người dùng và nhân viên hỗ trợ. Để giảm thiểu ảnh hưởng đến những người
dùng, hãy triển khai vào một ngày cuối tuần, vào quãng thời gian trong năm khi mà
các công việc trọng yếu dự kiến sẽ không xảy ra, chẳng hạn như khi khóa sổ các
báo cáo ở cuối một quý tài chính hoặc trước lúc khởi chạy một sản phẩm chính.
Đối với trường hợp sử dụng này, người ta đã chọn một ngày cuối tuần khi tất cả
các kiến trúc sư, các nhà phát triển và các quản trị viên cơ sở dữ liệu có thể rảnh
rỗi, cùng với một số các bên liên quan chính. Thậm chí nếu bạn đang lạc quan rằng

việc di trú sẽ chỉ mất một vài giờ, thì hãy để dành nhiều thời gian để xử lý các vấn
đề.
Trường hợp sử dụng này đã bắt đầu vào một buổi tối thứ Sáu sau giờ làm việc ở
Mỹ, tương ứng với sáng thứ bảy ở Trung Quốc, nơi đặt trụ sở của nhóm phát triển.
Điều đó hóa ra lại là một ý tưởng tốt, vì có một số vấn đề đã xảy ra và phải mất
một thời gian để giải quyết. Những vấn đề này đã không liên quan đến việc di trú
cơ sở dữ liệu hoặc mã, mà là do người ta đã không để ý đến các bộ phận khác của
hệ thống, ví dụ như các quy tắc tường lửa và các giấy phép của hệ điều hành, vì
người ta đã không nghĩ rằng những thay đổi của môi trường sẽ ảnh hưởng đến
chúng.
Bắt giữ lại các ảnh hệ thống hiện có và hệ thống mới
Như bạn đã thấy trong các phần khác của loạt bài này, xem phần Tài nguyên, điều
quan trọng là bắt giữ lại các ảnh máy ảo thích hợp hoặc các bản sao lưu của cơ sở
hạ tầng hiện có của bạn và để tạo ra các bản sao mà bạn muốn triển khai. Điều này
sẽ làm cho quá trình hỗ trợ việc triển khai của bạn trở nên dễ dàng hơn khi có vấn
đề xảy ra và nó sẽ cho phép bạn nhân bản hệ thống mới, đã trở thành mã sản xuất
của bạn để sử dụng làm vạch chuẩn cho sự phát triển trong tương lai.
Triển khai dữ liệu DB2
Trước hết hãy cài đặt dữ liệu đã cập nhật trên máy chủ dữ liệu chủ bằng cách sao
lưu cơ sở dữ liệu máy chủ phát triển ổn định của bạn và khôi phục lại nó trên cơ sở
dữ liệu sản xuất mới. Hãy trích ra cơ sở dữ liệu từ hệ thống phát triển bằng cách sử
dụng lệnh BACKUP. Liệt kê 3 cho thấy cách tạo ra kho lưu trữ để di trú dữ liệu.

Liệt kê 3. Sao lưu cơ sở dữ liệu để di trú vào sản xuất

db2 BACKUP DATABASE PTT


Liệt kê 4 cho thấy cách tạo ra một cơ sở dữ liệu rỗng trên máy chủ DB2 chính cho
sản xuất. Hãy tham khảo Phần 2 của loạt bài này để tìm hiểu lý do tại sao lại sử

dụng các tùy chọn cấu hình cụ thể này.

Liệt kê 4. Tạo cơ sở dữ liệu DB2 trong sản xuất

db2 "CREATE DATABASE PTT
USING CODESET UTF-8
TERRITORY US
COLLATE USING UCA500R1_S1
PAGESIZE 4096"


Như đã lưu ý ở trên, nếu bạn đang di chuyển qua các nền tảng, phương thức sao
lưu và phục hồi này sẽ không hoạt động. Thay vào đó, bạn sẽ cần tải cấu trúc cơ sở
dữ liệu và các đối tượng thông qua DDL và nhập khẩu dữ liệu riêng biệt. Xem lại
Phần 2 của loạt bài này để tìm hiểu thêm về việc tải dữ liệu.
Sau khi cài đặt ứng dụng và kiểm tra chức năng của ứng dụng, hãy chạy bắt giữ lại
và áp dụng các công việc để thiết lập việc sao chép. Xem lại Phần 2 của loạt bài
này để tìm hiểu thêm về việc cách cấu hình sao chép.
Liệt kê 5 cho thấy cách di chuyển dữ liệu trên máy chủ DB2 sản xuất chính bằng
cách sử dụng lệnh RESTORE.

Liệt kê 5. Phục hồi cơ sở dữ liệu vào sản xuất

db2 RESTORE DB PTT TAKEN AT 20100101090000 INTO PTT REPLACE
EXISTING


Vào lúc này, bạn sẽ có cơ sở dữ liệu chức năng đầy đủ. Hãy kiểm tra xem dữ liệu
có đúng không bằng một số bài kiểm tra chất lượng như đề xuất trong Chương 10
của Hướng dẫn chuyển đổi MySQL sang DB2, trong phần Tài nguyên.

Triển khai mã PHP
Bây giờ đến thời điểm quan trọng. Nếu bạn đã dùng cách tiếp cận tương tự như
trường hợp sử dụng này đã làm, ở đây một hệ thống mới được xây dựng độc lập
với hệ thống cũ, thì việc triển khai gồm có việc chuyển hướng lưu lượng từ một hệ
thống này sang một hệ thống khác và bảo đảm rằng mọi sự truyền thông giữa các
máy chủ ứng dụng và các máy chủ dữ liệu là đúng và hoạt động tốt.
Giám sát hệ thống mới
Những giờ và những ngày sau khi triển khai là quan trọng nhất. Điều vô cùng quan
trọng là cần bảo đảm rằng bạn giám sát các kiểu hoạt động có ảnh hưởng đến cơ sở
dữ liệu. Như với bất kỳ hệ thống cơ sở dữ liệu khác nào, nếu do một lỗi logic nào
đó, bạn đang tạo ra dữ liệu xấu hoặc sửa đổi sai dữ liệu sẵn có, thì có thể rất khó để
phục hồi hoàn hảo khi thời gian trôi qua. Bạn có thể phải tắt mạng của hệ thống để
ngăn không cho mã lỗi gây thêm các vấn đề nữa và bạn có thể phải chạy một số
kịch bản lệnh hiệu chỉnh để sửa chữa dữ liệu đã bị sửa đổi sai.
Vì vậy, nếu bạn chọn một cửa sổ thời gian triển khai vào đêm khuya, hãy chắc
chắn rằng bạn đã phân phối đủ thời gian sau khi triển khai cho nhóm làm việc để
xử lý bất kỳ những vấn đề nào có thể phát sinh. Chẳng có cảm giác nào tệ hơn là
triển khai một bản cập nhật lớn, vội vã gọi nó là thành công, rồi bị đánh thức vào
lúc 3 giờ sáng bằng một cuộc gọi điện thoại hoặc một số email từ những người
dùng đang báo là có các vấn đề cần phải ngừng hoạt động ngoài kế hoạch và cần
nhiều thay đổi sâu rộng để hồi phục lại.
Về đầu trang
Bước 4: Xử lý hỗ trợ liên tục
Điều quan trọng là phải giám sát hệ thống cẩn thận ngay cả sau khi hệ thống đã đạt
được một trạng thái ổn định trong nhiều giờ và nhiều ngày sau khi triển khai thành
công. Bước này liên quan đến các bước con sau đây.
 Đáp ứng với hoặc tránh các vấn đề hiệu năng
 Cấu hình lại khi kích thước của dữ liệu và luồng công việc phát triển
Chương 10 của Hướng dẫn chuyển đổi MySQL sang DB2, trong phần Tài nguyên,
cung cấp thêm các chi tiết về các kỹ thuật chẩn đoán và khắc phục sự cố.

Đáp ứng hoặc tránh các vấn đề hiệu năng
Như đã lưu ý ở trên, việc đáp ứng với các cảnh báo lỗi do hệ thống phát ra rất quan
trọng, cũng như việc chủ động xác định vấn đề và xác định xu hướng thông qua sự
phân tích bản ghi nhật ký. Trong trường hợp này, người ta biết rằng sẽ có một sự
gia tăng đột biến về số người dùng vào mỗi buổi sáng từ 8 đến 10 giờ sáng theo giờ
chuẩn ở miền Đông Bắc Mỹ (EST) và vào những thời điểm tương tự với những
người dùng khác trên toàn thế giới khi một ngày làm việc bắt đầu. Khoảng thời
gian chạy kịch bản lệnh và việc khóa leo thang được giám sát chặt chẽ để bảo đảm
tải công việc được xử lý một cách nhanh chóng và chính xác.
Ví dụ, từ một phân tích, người ta nhận ra rằng một truy vấn chậm khác thường
không cần phải nối nhiều bảng cơ sở dữ liệu đến thế. Trong một truy vấn khác,
việc cô lập sự tranh chấp của nó đã quá cứng nhắc. Bạn có thể tìm thấy vấn đề, nơi
các truy vấn của bạn cho phép đọc ảo hoặc những sự không nhất quán khác. Hãy
chắc chắn để giữ cho những đường dây liên lạc của bạn với những người dùng
luôn mở để cho họ biết khi nào và làm thế nào để báo cáo về các vấn đề đáng ngờ.
Sau đó, bạn có thể áp dụng một số kỹ thuật tương tự để tối ưu hóa hệ thống mà bạn
sử dụng trong Phần 3 của loạt bài này.
Cấu hình lại khi kích thước của dữ liệu và luồng công việc phát triển
Tất cả các ứng dụng đều đi theo một vòng đời chung. Chúng được triển khai,
chúng được duy trì và chúng được gỡ bỏ khỏi dịch vụ. Trong suốt vòng đời này,
chúng cũng đi qua vô số các bước cải tiến dần dần. Tương tự như vậy, các ứng
dụng của bạn sẽ cần được giám sát và cải thiện.
May mắn thay DB2 cung cấp cho bạn nhiều công cụ để giúp bạn trong các nỗ lực
bảo trì của mình. Hãy tìm hiểu chúng, sử dụng chúng và biết cần hỏi ở đâu khi bạn
đang gặp phải một vấn đề. Nhiều khả năng là những người dùng DB2 đồng nghiệp
của bạn đã gặp phải một tình huống tương tự. IBM có thể đưa ra sự hỗ trợ cho bạn
khi bạn gặp phải tình huống đó.
Trong trường hợp này, các nhà phát triển có xu hướng theo dõi các trang web và
các diễn đàn được liệt kê trong mục "Thảo luận" trong phần Tài nguyên. Việc này
giúp họ theo kịp các bản cập nhật bảo mật và các bản vá lỗi cho DB2 và tìm hiểu

về các tính năng mới, có thể phù hợp với các nhu cầu hiện tại của họ.
Về đầu trang
Các kết quả di trú
Đối với trường hợp sử dụng này, ngay sau khi triển khai ứng dụng, người ta đã xác
định rằng nhiều lợi ích được kỳ vọng đã thành hiện thực. Cụ thể là, đã nhận được
các tác động đến quy trình nghiệp vụ đã được cải thiện như dự kiến vì hệ thống cơ
sở dữ liệu có thể cung cấp chính xác các số liệu đo lường quan trọng để dẫn dắt
hướng hoạt động nghiệp vụ. Trường hợp sử dụng này cũng được đặt ở vị trí tốt hơn
để chọn dùng các tính năng cơ sở dữ liệu tiên tiến trong DB2, có tác động đến hiệu
năng và khả năng mở rộng quy mô trong tương lai khi dữ liệu tăng trưởng thêm,
chẳng hạn như khả năng mở rộng quy mô lớn nhất, bảo đảm an toàn mức chi tiết
hơn, lưu trữ XML nguyên gốc và nén dữ liệu.
Lợi ích của Cognos Business Intelligence
Di chuyển sang DB2 cho phép chúng ta bắt đầu sử dụng Cognos để tạo báo cáo.
Điều này cho phép chúng ta tạo ra các báo cáo trên web và kiểm soát những người
dùng nào có thể xem các báo cáo đó. Quá trình tạo báo cáo một tuần một lần trước
đây sẽ cần đến gần 16 giờ để thực hiện một truy vấn, chuyển đổi dữ liệu thành các
biểu đồ trực quan và rút ra các kết luận có ý nghĩa. Đây cũng là một quá trình thủ
công và dễ bị lỗi, thường đe dọa việc phân phối kịp thời các thông tin chính xác lên
ban quản lý cấp trên, dẫn đến làm giảm sự nhanh nhẹn trong việc đáp ứng với các
điều kiện kinh doanh thay đổi.
Với hệ thống mới, các báo cáo chính xác có thể được chạy dưới 6 giờ, do nhà phân
tích nghiệp vụ không cần có một nguồn tài nguyên kỹ thuật chuyên dụng để chạy
báo cáo nữa. Hơn nữa, càng nhiều người dùng có thể xem thông tin liên quan đến
họ với mức kiểm soát truy cập lớn hơn và tác động lên nó để hoàn thành mục tiêu
kinh doanh của họ càng hiệu quả hơn.
Ngoài ra, với hệ thống cũ, những người dùng cuối sẽ phải tải về các tệp báo cáo
lớn, có thể mất 10 phút hoặc nhiều hơn cho mỗi tệp. Và, dữ liệu đó đã chỉ chính
xác cho đến thời điểm khi chạy báo cáo. Với hệ thống mới, người dùng có thể truy
cập các báo cáo một cách nhanh chóng bằng một trình duyệt web. Trong khi một

số báo cáo vẫn còn là các ảnh chụp nhanh ở một thời điểm cụ thể, thì hầu hết các
báo cáo hiện nay là thời gian thực, do đó người dùng có thể thấy thông tin cập nhật
mới nhất bất cứ khi nào họ chọn báo cáo.
Cải thiện chất lượng dữ liệu
Với các quy tắc nghiệp vụ buộc phải thực hiện trong cơ sở dữ liệu bằng cách kiểm
tra những ràng buộc và các mối quan hệ thể hiện qua khóa, bây giờ hệ thống ngăn
không để cho các vấn đề về toàn vẹn dữ liệu làm hỏng cơ sở dữ liệu. Điều này dẫn
đến dữ liệu có chất lượng tốt hơn. Trong quá khứ, việc sửa chữa thủ công vài ba
điểm không nhất quán dữ liệu mỗi tuần là điều bình thường. Hiện nay không có
báo cáo vấn đề hàng tháng, hạ tổng số báo cáo hàng tháng từ 12 xuống 0 trong quý
đầu tiên sau khi triển khai, tiết kiệm nhiều giờ nỗ lực phát triển và cải thiện niềm
tin của người dùng cuối vào hệ thống.
Tác động tối thiểu đến trải nghiệm của người dùng
Việc di trú đã không ảnh hưởng đến những người dùng ngoài cửa sổ thời gian triển
khai vào cuối tuần đầu khi hệ thống vẫn chưa có sẵn. Sự ngừng hoạt động theo kế
hoạch này cũng tương tự như bất kỳ sự ngừng hoạt động khác nào mà họ đã được
thông báo để triển khai các phiên bản ứng dụng mới hoặc xử lý bảo trì và các bản
nâng cấp hệ thống thường kỳ, do đó đạt được một hệ thống chất lượng tốt hơn mà
không cần có sự thỏa hiệp nào từ góc nhìn của người dùng cuối.
Hiệu năng và giám sát tốt hơn
Với mảng rộng lớn các tính năng tự trị có sẵn và bộ công cụ kèm theo với DB2,
bạn có thể nhận biết và giải quyết các vấn đề với ứng dụng của mình nhanh hơn là
trên một hệ thống dựa vào MySQL. Bạn có khả năng để cho chính DB2 tự động
điều chỉnh hoặc cảnh báo cho bạn trước khi chạm đến các ngưỡng quan trọng.
Bảo trì dễ dàng hơn
Đối với trường hợp sử dụng này, khi cần có sự can thiệp của quản trị viên cơ sở dữ
liệu để thêm các chỉ mục mỗi tháng một lần, thì bây giờ người ta đã áp dụng các
bản vá lỗi hiệu năng mỗi quý một lần hoặc ít hơn.
Thêm các tuỳ chọn để sử dụng các giải pháp của IBM
Bên cạnh khả năng sử dụng Cognos Business Intelligence sau khi di trú sang DB2,

có một hướng đi rõ ràng để bắt đầu làm là liệu bao giờ bạn quyết định di chuyển từ
PHP sang một giải pháp Java EE dựa trên WebSphere trong tương lai. Người ta
cũng có thể hy vọng tìm ra sự tích hợp đơn giản với các chồng phần mềm của IBM
khác nhau và các dịch vụ cơ sở hạ tầng và các dịch vụ nền tảng điện toán đám mây
của IBM.
Về đầu trang
Kết luận
Mục đích của loạt bài này là cung cấp một sự hiểu biết về những điều cần thiết nói
chung để di trú một ứng dụng PHP từ MySQL sang DB2, những tài nguyên nào có
sẵn để giúp bạn và nhiệm vụ này đã được thực hiện thành công ra sao đối với ứng
dụng trong một trường hợp sử dụng.
Trong Phần 1 của loạt bài này, bạn đã làm những việc sau.
 Đã học về các động lực, các rủi ro và các lợi ích của một nghiên cứu sâu về
chuyển đổi ứng dụng Intranet của IBM.
 Đã học từ kinh nghiệm về trường hợp sử dụng này để thu thập các tài liệu để
tìm hiểu DB2 và để hiểu những gì cần thiết với một cuộc di trú MySQL.
 Đã học về các công cụ để có thể giúp bạn thực hiện cuộc di trú.
 Đã học về cách có thể tập hợp lại tất cả tài nguyên với nhau để hướng dẫn
bạn qua từng giai đoạn của dự án.
Trong Phần 2 của loạt bài này, bạn đã làm những việc sau.
 Đã học về cơ sở dữ liệu nguồn MySQL mà bạn đã chuyển đổi.
 Đã học cách chuyển đổi cấu trúc cơ sở dữ liệu sang DB2.
 Đã học cách di trú dữ liệu sang DB2.
 Đã học cách thiết lập quản trị cơ sở dữ liệu.
Trong Phần 3 của loạt bài này, bạn đã làm những việc sau.
 Đã học về mã nguồn PHP mà bạn đã chuyển đổi.
 Đã học cách cập nhật ứng dụng cho DB2.
 Đã học cách thử nghiệm và điều chỉnh mã sau khi bạn đã chuyển đổi nó.
Trong phần cuối cùng của loạt bài về triển khai ứng dụng của bạn, bạn đã làm
những việc sau.

 Đã học cách chuẩn bị và triển khai ứng dụng theo cấu trúc liên kết dựa trên
DB2.
 Đã học cách thực hiện sự hỗ trợ liên tục để dò vết các vấn đề trong hệ thống
mới của bạn.
 Đã học về những lợi ích đã thu được từ lúc bắt đầu làm dự án di trú này.
Hy vọng rằng loạt bài này đã giúp bạn lập kế hoạch riêng của mình để di trú
MySQL sang DB2 và đã cung cấp thông tin để hướng dẫn bạn theo từng bước di
trú, với các hiểu biết tốt đã thu được khi thực hiện cuộc di trú trong trường hợp sử
dụng này.
Để giúp xác định một cách tiếp cận phù hợp với bạn, hãy tham khảo bài Hướng
dẫn chuyển đổi MySQL sang DB2, trong phần Tài nguyên hoặc liên hệ với Văn
phòng dự án di trú phần mềm (SMPO) để nhận được một đánh giá di trú miễn phí.
Trong phần Tài nguyên đã cung cấp các liên kết đó.