Di chuyển một ứng dụng PHP từ MySQL sang DB2 Phần 2: Di trú dữ liệu của bạn ppt

Di chuyển một ứng dụng PHP từ MySQL sang DB2
Phần 2: Di trú dữ liệu của bạn
Giới thiệu về loạt bài này
MySQL hiện là máy chủ cơ sở dữ liệu phổ biến nhất được sử dụng với ngôn ngữ lập trình PHP
để xây dựng các ứng dụng web động. Tuy nhiên, DB2 là một cơ sở dữ liệu phổ biến khác được
PHP hỗ trợ đầy đủ và cung cấp các lợi thế hấp dẫn hơn so với MySQL, làm cho nó trở thành một
sự lựa chọn lý tưởng cho nhiều ứng dụng.
Loạt bài này mô tả tại sao việc di chuyển một ứng dụng PHP sang DB2 lại có ý nghĩa, cách
chuẩn bị cho việc di trú, cách thực hiện nó, cách hỗ trợ nó và cách xử lý các rủi ro tiềm năng dựa
trên kinh nghiệm của các tác giả với cuộc di trú mới nhất. Nhiều mẫu mã và mẫu cấu hình được
cung cấp, cũng như các chỉ dẫn tài nguyên để giúp cho dự án chạy trơn tru.
Với các ví dụ và các bài học thu được từ một cuộc chuyển đổi thực tế thành công, bạn sẽ thấy
đây có thể là một dự án đơn giản, có đủ tài liệu và cung cấp các lợi ích hấp dẫn.
Loạt bài bốn phần này chia sẻ các bài học nhận được từ cuộc di trú MySQL-sang-DB2 thành
công cho một ứng dụng mạng nội bộ PHP chủ yếu, cấp độ sản xuất, được 4.000 người dùng toàn
cầu trong IBM sử dụng để hỗ trợ sản xuất nội dung cho ibm.com.
 Phần 1 mô tả các bước cần thực hiện để chuẩn bị cho việc di trú.
 Phần 2 mô tả các bước cần thực hiện để di trú cơ sở dữ liệu.
 Phần 3 mô tả các bước cần thực hiện để chuyển đổi mã PHP.
 Phần 4 mô tả các bước cần thực hiện để triển khai và hỗ trợ ứng dụng.
Bạn sẽ học được điều gì
Mục đích của loạt bài này là cho bạn hiểu những gì 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 để trợ giúp bạn và một nhóm dự án của
IBM đã thực hiện nhiệm vụ này vào đầu năm 2010 như thế nào.
Nếu bạn đã nghiên cứu một cuộc di trú từ MySQL sang DB2, bạn có thể đã thấy những giá trị
mà DB2 cung cấp dựa trên tài liệu sản phẩm, các đánh giá tiêu chuẩn về hiệu năng, các tính năng
mà bạn đã đọc trong tài liệu DB2 hoặc các so sánh trong các Sách Đỏ của IBM (IBM
Redbooks®) dành riêng cho nhiệm vụ này, bao gồm sách Hướng dẫn chuyển đổi MySQL sang
DB2 (xem phần Tài nguyên).
Bạn có lẽ cũng biết rằng DB2 Express-C là một máy chủ dữ liệu quan hệ chức năng đầy đủ, miễn
phí có thể dễ dàng được cài đặt hoặc được đánh giá bằng cách sử dụng IBM Smart Business

Development and Test on the Cloud (Phát triển nghiệp vụ thông minh và Thử nghiệm trên Đám
mây của IBM hoặc Amazon EC2). Các liên kết đến các tài nguyên này có sẵn trong phần Tài
nguyên.
Loạt bài này cung cấp cho bạn một ví dụ cụ thể về cuộc di trú thực tế đã được thực hiện thành
công như thế nào trong năm 2010 cho một ứng dụng mạng nội bộ PHP được sử dụng rất nhiều
trong IBM để hỗ trợ quản lý nội dung hàng ngày được công bố trên nhiều phần của trang Web
ibm.com.
Sau khi bạn đọc xong loạt bài này, bạn sẽ có thể tạo một trường hợp di trú tương tự, hiểu được
thời hạn và các phụ thuộc của các mục công việc cần được thực hiện, dự kiến các rủi ro tiềm
năng và biết nơi để tìm kiếm sự hỗ trợ cho từng bước trên đường đi. Tất cả điều này sẽ cho bạn
sự tự tin hơn để lựa chọn DB2 và sử dụng nó một cách tốt nhất cho các ứng dụng PHP của bạn
hiện đang được phát triển trên MySQL.
Những gì không được trình bày
Loạt bài này nhằm chia sẻ các bài học thu được từ một cuộc di trú nội bộ IBM từ MySQL sang
DB2 và cung cấp cho bạn thông tin về tài nguyên có sẵn để thực hiện một công cuộc tương tự.
Loạt bài này không phải là một hướng dẫn toàn diện về di trú để có thể áp dụng được cho tất cả
các kịch bản.
Để xác định một cách tiếp cận phù hợp với bạn, hãy tham khảo Hướng dẫn chuyển đổi MySQL
sang DB2 hoặc liên hệ với SMPO (Software Migration Project Office - Văn phòng dự án di trú
phần mềm) để đánh giá di trú miễn phí. Các liên kết này được cung cấp trong phần Tài nguyên.
Về đầu trang
Giới thiệu về việc di trú cơ sở dữ liệu
Bài viết này trình bày bốn bước chính để di trú cơ sở dữ liệu từ MySQL sang DB2. Nếu cần
thiết, hãy tham khảo Phần 1 của loạt bài này để xem lịch trình của các bước này trong toàn bộ
quá trình di trú trước khi bắt đầu di trú.
Bước 1: Chuyển đổi cấu trúc cơ sở dữ liệu MySQL sang định dạng DB2
 Tạo một cơ sở dữ liệu mới trong DB2.
 Trích xuất cấu trúc cơ sở dữ liệu MySQL nguồn.
 Kỹ thuật dịch ngược cơ sở dữ liệu để nhận được một sơ đồ quan hệ-thực thể.
 Cải tiến và sửa đổi cấu trúc mô hình dữ liệu.

 Chuyển đổi các đối tượng cơ sở dữ liệu khác.
Bước 2: Di chuyển dữ liệu MySQL vào cơ sở dữ liệu DB2
 Loại bỏ các bảng và dữ liệu không cần thiết.
 Chuyển đổi bất kỳ dữ liệu nào trong cơ sở dữ liệu nguồn có thể không phù hợp
với các kiểu dữ liệu DB2 đích.
 Trích xuất dữ liệu từ MySQL.
 Nạp dữ liệu vào DB2.
 Thiết lập lại các gia số cột mã định danh (ID) đã tạo ra.
Bước 3: Tạo lại các quyền hạn người dùng và cấu hình quản trị cơ sở dữ liệu
 Thiết lập các tài khoản người dùng cần thiết và gán cho họ các các quyền hạn
thích hợp.
 Triển khai sao lưu cơ sở dữ liệu và kế hoạch khắc phục thảm họa.
 Cấu hình sao chép để tạo ra một hệ thống ảnh gương mà cơ chế báo cáo Cognos
có thể sử dụng.
Bước 4: Kiểm lại bước khởi đầu di trú cơ sở dữ liệu
 Đảm bảo rằng việc di trú cơ sở dữ liệu đã xong. Nếu không, thực hiện lại các
Bước 1-3 cho đến khi việc di trú hoàn thành, như cho thấy trong Hình 1 của Phần
1.
 Sao lưu hệ thống.
 Chuẩn bị chuyển đổi ứng dụng.
Về đầu trang
Tìm hiểu nghiên cứu sâu về ví dụ cơ sở dữ liệu MySQL PTT hiện có
Nhắc nhở
Nếu cần thiết, hãy tự mình tìm hiểu phần Tài nguyên có thể giúp í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 6, 7 và 9 trong Sách Đỏ của IBM miễn phí (IBM Redbook®) Hướng dẫn chuyển
đổi MySQL sang DB2.
 Bài viết trên developerWorks "Danh sách khuyến khích đọc: Quản trị cơ sở dữ liệu DB2
cho Linux, UNIX và Windows".
 Loạt bài viết trên developerWorks "Sử dụng các kỹ năng MySQL để tìm hiểu DB2

Express".
Tất nhiên, tài liệu sản phẩm cho các công cụ thường dùng để di trú cơ sở dữ liệu là IBM Data
Movement Tool (Công cụ di chuyển dữ liệu của IBM) và Rational Software Architect (Kiến trúc
sư phần mềm Rational) cũng rất quan trọng.
Một lựa chọn khác là sử dụng đám mây cho quá trình di trú. Bạn có thể sử dụng Amazon EC2
Linux và các AMI của DB2, hoặc đăng ký dùng IBM Development and Test on the IBM Cloud
(Phát triển và thử nghiệm của IBM trên đám mây của IBM) (xem phần Tài nguyên).
Để làm cơ sở dữ liệu ví dụ cho bài viết này, chúng tôi sử dụng cơ sở dữ liệu MySQL nguồn cho
PTT (Công cụ theo dõi dự án) chứa 150 bảng, trung bình mỗi bảng có 6 cột và lưu trữ tổng cộng
khoảng 10 GB dữ liệu văn bản. PTT ban đầu được xây dựng dựa trên MySQL phiên bản 3.23 và
đã di trú đến phiên bản 5.0 trong quá trình bảy năm. Tất cả các bảng đã sử dụng kiểu máy
MyISAM mặc định.
Cơ sở dữ liệu PTT được dùng cho nhiều chức năng khác nhau để hỗ trợ dòng công việc công bố
thông tin trên ibm.com. Ứng dụng này xử lý các tệp nhị phân, như các ảnh sản phẩm và tài liệu
chào bán sản phẩm, nhưng các tệp được lưu trên hệ thống tệp với một liên kết logic chứa trong
một cột trong cơ sở dữ liệu chứ không phải lưu trữ tệp trong chính cơ sở dữ liệu đó như là dữ
liệu nhị phân.
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 này thông qua xử lý
trước web PHP. Tại bất kỳ thời điểm nào đều có vài trăm người dùng đang hoạt động đồng thời
trên hệ thống.
Dữ liệu được cung cấp từ chỉ một máy chủ MySQL chính, được sử dụng cho cả đọc và viết. Một
cơ sở dữ liệu bản sao được duy trì đồng bộ và được sử dụng để tạo báo cáo chỉ đọc và các truy
vấn không dự tính trước. Dữ liệu được sao lưu và lưu trữ hàng đêm.
Bài này mô tả cách tạo một cấu hình tương tự trên một hệ thống DB2 mới. Bạn cũng sẽ tối ưu
hóa thiết kế cơ sở dữ liệu của bạn, cải thiện tính toàn vẹn và chất lượng dữ liệu của nó và loại bỏ
các cấu trúc không sử dụng hoặc đã lỗi thời. Điều này sẽ giúp bạn đơn giản hóa việc di trú bằng
cách giảm số lượng các đối tượng được di chuyển, tiết kiệm không gian lưu trữ bằng cách giảm
kích thước của dữ liệu được di trú và làm giảm khả năng nhầm lẫn phát sinh từ sự tồn tại của dữ
liệu không sử dụng.
Về đầu trang

Cài đặt phần mềm di trú
Để chuẩn bị cho việc di trú cơ sở dữ liệu ví dụ, hãy cài đặt các thành phần sau đây trên một máy
trạm Windows được dùng để thực hiện các bước di trú.
Một phiên bản của bản sao MySQL của cơ sở dữ liệu nguồn
Việc di trú cơ sở dữ liệu là một quá trình lặp lại, vì vậy cài đặt một bản sao của cơ sở dữ
liệu MySQL nguồn trên máy trạm để truy cập dễ dàng. Điều này cho phép hiệu năng
trong quá trình di trú tốt hơn so với nếu cài đặt nó trên một hệ thống từ xa và nó cho phép
tự do sửa đổi cơ sở dữ liệu nguồn nếu cần thiết khi bạn thực hiện các bước di trú.
Một phiên bản của DB2
Cài đặt DB2 để tạo ra cơ sở dữ liệu đích mới trên máy trạm. Nói chung, bản cài đặt này
không nhất thiết phải là cùng ấn bản như cơ sở dữ liệu được sử dụng trong sản xuất,
nhưng để tương thích tính năng đầy đủ, chọn cùng ấn bản là một ý tưởng tốt. Để làm theo
các ví dụ trong bài viết này, hãy cài đặt DB2 Enterprise Server Edition (Ấn bản máy chủ
doanh nghiệp DB2) Phiên bản 9.7.2.
Công cụ di chuyển dữ liệu của IBM
Tải về và giải nén phiên bản mới nhất của IBM Data Movement Tool (Công cụ di chuyển
dữ liệu của IBM) (xem phần Tài nguyên), mà bạn có thể sử dụng để trích xuất cơ sở dữ
liệu từ MySQL và nhập khẩu nó vào DB2.
Một môi trường phát triển tích hợp (IDE) dựa trên Eclipse của IBM với một phối cảnh dữ
liệu (tùy chọn)
Bạn có thể sử dụng một bản phân phối Rational® Software Architect hiện có, vì nó là
một công cụ phát triển tất cả-trong-một có thể được sử dụng để hiển thị trực quan và
chỉnh sửa các mô hình cơ sở dữ liệu. Bạn có thể tìm thấy một liên kết đến Rational
Software Architect và các công cụ tương tự như InfoSphere™ Data Architect và Optim™
Development Studio trong phần Tài nguyên.
Hãy chắc chắn ghi lại chi tiết các quyết định cấu hình của bạn và các bài học thu được một cách
cẩn thận để bạn có thể lặp lại các bước khi triển khai. Xem xét việc lưu trữ một bản chụp của hệ
điều hành Windows với một ảnh ảo tại các cột mốc chủ yếu khi đạt được các mục tiêu quan
trọng để dùng như các bản sao lưu cấu hình và các vạch khởi đầu để so sánh cải thiện cơ sở dữ
liệu thêm nữa.

Nếu bạn muốn chụp một ảnh của một cấu hình máy vật lý, bạn có thể làm như vậy với VMware
vCenter Converter miễn phí. Một cách thay thế khác là xem xét dùng đám mây để làm các thay
đổi năng động này. Bạn có thể sử dụng các AMI DB2 của Amazon EC2, hoặc bạn có thể đăng
ký dùng Phát triển của IBM và thử nghiệm trên đám mây của IBM (IBM Development and Test
on the IBM Cloud). Với các máy tính ảo, bạn sẽ có thể tránh được các cố gắng ban đầu để mua
phần cứng máy chủ và cài đặt một hệ điều hành và DB2. Nó cũng sẽ tiết kiệm thời gian, tăng tốc
độ di trú và cung cấp cho bạn sự tự tin để thí nghiệm với cấu hình phù hợp nhất với các nhu cầu
của bạn. Có thể tìm thấy các liên kết đến tất cả các sản phẩm này trong phần Tài nguyên.
Về đầu trang
Bước 1. Chuyển đổi cấu trúc cơ sở dữ liệu MySQL sang định dạng DB2
Một khi bạn thiết lập phần mềm cần phải có trước trên máy trạm, bước quan trọng đầu tiên là
trích xuất các bảng từ cơ sở dữ liệu MySQL của chúng ta và tạo lại chúng trong cơ sở dữ liệu
DB2 mới. Bước này liên quan đến việc hoàn thành các bước con sau đây:
 Tạo một cơ sở dữ liệu mới trong DB2
 Trích xuất cấu trúc cơ sở dữ liệu MySQL nguồn
 Kỹ thuật dịch ngược cơ sở dữ liệu để nhận được một sơ đồ quan hệ-thực thể
 Cải tiến và sửa đổi cấu trúc mô hình dữ liệu
 Chuyển đổi các đối tượng cơ sở dữ liệu khác
Tạo một cơ sở dữ liệu mới trong DB2
Ứng dụng PTT hỗ trợ những người dùng trên toàn cầu, vì vậy ngay từ đầu điều quan trọng là
đảm bảo rằng cơ sở dữ liệu DB2 mới có thể hỗ trợ một số ngôn ngữ và các bộ ký tự khác nhau.
Để hỗ trợ yêu cầu này, tạo một cơ sở dữ liệu với bộ mã UTF-8.
Cùng với việc lựa chọn một bộ mã, hãy đánh giá thuật toán thứ tự chữ cái nào sẽ thích hợp cho
các mục đích của bạn. Việc thiết lập thứ tự chữ cái xác định cách DB2 sắp xếp và tính toán dữ
liệu văn bản trong cơ sở dữ liệu của bạn, và nó có thể ảnh hưởng đến hiệu năng so sánh chuỗi ký
tự.
Để bảo toàn hành vi không phân biệt dữ liệu chữ hoa chữ thường khi hệ thống dựa trên MySQL
của bạn xử lý dữ liệu, hãy chọn thuật toán thứ tự chữ cái Unicode UCA500R1_S1
(UCA500R1_S1 Unicode Collation Algorithm), xử lý chữ hoa chữ thường và sắp xếp ngang
nhau. Với cấu hình này, các chuỗi ký tự role, Role, và rôle được sắp xếp và so sánh bằng nhau.

Sau khi bạn chọn các yêu cầu bộ mã ký tự và thứ tự chữ cái, lệnh để tạo cơ sở dữ liệu DB2 mới
được hiển thị trong Liệt kê 1. Bạn có thể chạy lệnh này trong bộ xử lý dòng lệnh đi kèm với
DB2. Các ngắt dòng được thêm vào cho dễ đọc.

Liệt kê 1. Lệnh được sử dụng để tạo ra cơ sở dữ liệu DB2 mới

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

Bạn có thể chấp nhận một số giá trị mặc định khi tạo cơ sở dữ liệu, cho phép DB2 tự lo một số
nhiệm vụ bảo trì tự động bằng cách sử dụng các tính năng tự trị dựng sẵn. Ví dụ, lưu trữ tự động
theo mặc định và kích hoạt trình quản lý bộ nhớ tự điều chỉnh.
Có rất nhiều tùy chọn khác mà bạn có thể quy định vào lúc tạo cơ sở dữ liệu. Thật hợp lý để
nghiên cứu các giá trị thiết lập, vì cấu hình đúng cơ sở dữ liệu của bạn ngay từ đầu sẽ sáng suốt
hơn là áp dụng các thiết lập sau đó. Mục 6.2.1 trong Hướng dẫn chuyển đổi MySQL sang DB2
(xem phần Tài nguyên) trình bày chi tiết về nhiều tùy chọn này.
Trích xuất cấu trúc cơ sở dữ liệu MySQL nguồn
Nhiệm vụ tiếp theo là trích xuất cấu trúc cơ sở dữ liệu từ MySQL và nạp nó vào DB2. Nếu bạn
có một cơ sở dữ liệu nhỏ, bạn có thể sử dụng tiện ích mysqldump để trích xuất DDL nguồn của
bạn từ MySQL và sửa đổi nó thủ công để phù hợp với cú pháp DB2 tương đương. Phần 6.1 của
Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên) cung cấp một mô tả về từng
kiểu dữ liệu và một bảng cho thấy cách chúng có thể được ánh xạ với nhau.
Với cơ sở dữ liệu lớn hơn, như ví dụ cho bài này có chứa 150 bảng, hãy xem xét việc tự động
hoá trích xuất cấu trúc cơ sở dữ liệu bằng cách sử dụng Data Movement Tool của IBM. Data
Movement Tool của IBM cung cấp một giao diện người dùng đơn giản được cấu hình để kết nối
với cả hai cơ sở dữ liệu MySQL cục bộ và cơ sở dữ liệu DB2 mới được tạo ra. Xem phần Tài
nguyên để biết các hướng dẫn chi tiết về cách sử dụng Data Movement Tool của IBM để trích

xuất cấu trúc cơ sở dữ liệu trong bước này.
Với ví dụ này, chỉ đánh dấu chọn hộp kiểm tra Data và nhấn vào Extract DDL/Data, như hiển
thị trong .

Hình 1. Trích xuất DDL

Sau khi Data Movement Tool của IBM trích xuất cấu trúc cơ sở dữ liệu, bạn có một danh sách
các tệp DDL trong thư mục migr. Một số các tệp có thể rỗng. Ví dụ, vì không có hàm nào do
người dùng định nghĩa trong cơ sở dữ liệu MySQL nguồn ví dụ, nên tệp db2udf.sql không có nội
dung nào.
Nạp các DDL vào cơ sở dữ liệu DB2 cục bộ bằng cách thi hành tệp bó db2ddl.cmd nằm trong
cùng thư mục với các tệp DDL.
Kỹ thuật dịch ngược cơ sở dữ liệu để nhận được một sơ đồ quan hệ-thực thể
Một khi các DDL được nạp vào DB2, hãy sử dụng RSA để dịch ngược cấu trúc cơ sở dữ liệu khi
nó tồn tại trong DB2. Kết nối đến cơ sở dữ liệu DB2 mới được tạo ra và trích xuất một mô hình
trực quan của nó bằng cách sử dụng Rational Software Architect. Quá trình này, được gọi là kỹ
thuật dịch ngược, biến đổi cơ sở dữ liệu thành một sơ đồ quan hệ-thực thể (ER), cho thấy các
bảng, các cột của chúng, và các sự liên kết giữa chúng.
Bước này loại bỏ bất kỳ các bảng không sử dụng nào, làm thay đổi các kiểu dữ liệu của một số
cột nhất định, và thêm khóa chính và khóa ngoại. Đây là một nhiệm vụ tùy chọn, nhưng nó mang
lại một cơ hội tốt để tổ chức lại cấu trúc dữ liệu của bạn cho phù hợp tốt hơn với các nhu cầu
hiện tại của bạn.
Một lần nữa, bạn có thể quyết định thay đổi mô hình dữ liệu của bạn bằng cách chỉnh sửa thủ
công DDL cho phù hợp với cú pháp DB2, nhưng việc tạo một mô hình trực quan dưới dạng một
sơ đồ ER là có ích để xem, ghi lại và duy trì cấu trúc dữ liệu của bạn. Sơ đồ ER này có thể dùng
làm tài liệu hướng dẫn cho nhóm kỹ thuật cũng như các bên liên quan của doanh nghiệp.
Bạn có thể tạo sơ đồ và thực hiện các nhiệm vụ liên quan sau đây để đạt được những lợi ích được
liệt kê.
Xây dựng các mối quan hệ giữa các bảng hoặc các khung nhìn
Điều này giúp ích để hiểu cách các bảng trong cơ sở dữ liệu quan hệ làm việc với nhau.

Tô màu các bảng dùng cho một chức năng chung
Trong ví dụ này, các bảng USER, ACL và ROLE làm việc với nhau để xử lý xác thực và
ủy quyền, vì vậy bạn có thể gắn kết lô gic các bảng này bằng cách áp dụng cho chúng
một màu nền chung trong mô hình.
Làm nổi bật các cột đã được sửa đổi trong quá trình di trú cấu trúc dữ liệu và thêm các
chú thích giải thích tại sao chúng đã được thay đổi
Điều này có ích để theo dõi các cột và bảng nào đã được sửa đổi trong quá trình thực
hiện.
Bạn có thể tìm hiểu thêm về kỹ thuật dịch ngược một cơ sở dữ liệu hiện có thành một mô hình
dữ liệu bằng cách đọc xem việc này được thực hiện như thế nào trong InfoSphere Data Architect
(xem phần Tài nguyên). Các chỉ dẫn này là giống nhau khi thực hiện trên bất kỳ các IDE dựa
trên Eclipse nào của IBM được xây dựng trên nền tảng các công cụ dữ liệu của Eclipse (Eclipse
Data Tools Platform). Thay vì sử dụng cơ sở dữ liệu Derby của Apache đã dùng như một ví dụ
trong hướng dẫn, bạn sẽ cần kết nối đến cơ sở dữ liệu DB2 của bạn.
Cải tiến và sửa đổi cấu trúc mô hình dữ liệu
Bất kể bạn đã tạo ra một sơ đồ ER hay chưa, bạn có thể bắt đầu cải tiến cấu trúc dữ liệu tại thời
điểm này. Xem xét việc thực hiện các thay đổi này với cấu trúc được sử dụng trong ví dụ này.
Hãy chắc chắn rằng các kiểu dữ liệu là nhất quán giữa khóa chính và bất kỳ các khóa
ngoại dựa vào chúng
Ví dụ, kiểu dữ liệu của khóa chính là SMALLINT trong bảng USER, nhưng khóa ngoại
USER_ID, tham chiếu logic đến khóa chính này trong bảng khác, lại là một kiểu dữ liệu
số INTEGER lớn hơn. Bạn có thể thường xuyên thấy điều này trong cấu trúc cơ sở dữ
liệu MySQL của bạn, vì kiểu dữ liệu ban đầu đã được tạo ra trong một phiên bản của
MySQL không hỗ trợ việc bắt buộc các khóa ngoại, đòi hỏi hai kiểu dữ liệu phải nhất
quán.
Tăng thêm kích thước tối đa của các cột mã định danh (ID) nếu cần
Nếu ứng dụng của bạn đã chạy trong một thời gian dài, các giá trị trong cột mã định danh
(ID) có thể bắt đầu tiến gần đến giới hạn tối đa đã quy định của chúng. Việc di trú cung
cấp cho bạn một cơ hội tốt để giải quyết vấn đề tiềm năng này. Ví dụ, nếu ID của một
bảng USER được quy định là SMALLINT và số lượng người dùng có thể vượt quá

32.767 trong tương lai, thì bây giờ bạn nên mở rộng ID thành kiểu INTEGER lớn hơn để
hỗ trợ lên đến 2 tỷ người dùng trong tương lai.
Thay đổi các trường TEXT của MySQL từ các kiểu đối tượng văn bản CLOB của DB2
thành các kiểu ký tự VARCHAR mỗi khi có thể
Có một số hạn chế về các CLOB trong DB2. Các CLOB không thể được dùng để tìm các
giá trị DISTINCT và chúng không thể được nạp vào các nhóm bộ đệm. Vì vậy, các
CLOB có thể không làm việc được vì chúng không thể lợi dụng việc nhớ sẵn các trang
(page cache). Nếu có thể, bạn nên xem xét thay đổi các trường TEXT thành các trường
VARCHAR. Vì vùng bảng nằm bên dưới xác định kích thước tối đa của cột VARCHAR,
chỉ có thể lưu văn bản lên đến 32KB.
Xoá cột đã lỗi thời hoặc không sử dụng
Ví dụ, một số ứng dụng có cách tiếp cận khác nhau để lưu trữ các báo cáo, vì vậy bạn có
thể có một số các bảng di sản lớn nắm giữ một khối lượng dữ liệu lớn không còn giá trị
nữa và thường gây nhầm lẫn cho những người phát triển mới của nhóm. Hãy lợi dụng cơ
hội này để lưu trữ dữ liệu này và loại bỏ nó khỏi cơ sở dữ liệu hoạt động.
Thêm các khóa chính hoặc các ràng buộc duy nhất nếu cần thiết
Ngoài tính toàn vẹn dữ liệu mà các ràng buộc khóa mang lại, việc này rất quan trọng để
tạo bản sao DB2. Mỗi bảng đòi hỏi một khóa chính hoặc khóa duy nhất để chuyển giao
các giá trị duy nhất tới cơ sở dữ liệu sao lưu.
Định nghĩa và áp đặt các khóa ngoại mới
Trong cơ sở dữ liệu MySQL ví dụ, không có các khóa ngoại nào vì ứng dụng ban đầu đã
được tạo ra với máy lưu trữ MyISAM mặc định không hỗ trợ chúng. Trong giai đoạn
chuyển đổi dữ liệu, thêm các khóa ngoại cần thiết để cải thiện tính nhất quán của dữ liệu,
ví dụ như duy trì bảng USER được liên kết với bảng TASK_HISTORY, do đó đảm bảo
rằng các bản ghi kiểm toán đang liên kết các thay đổi với những người dùng không bị
ngắt.
Chuyển đổi hoặc thêm các đối tượng khác, như các chỉ mục, các khung nhìn, các thủ tục đã
lưu và các hàm
Việc hiển thị trực quan cấu trúc dữ liệu của bạn có thể giúp ích cho việc hiểu các mối
quan hệ giữa các bảng, tầm quan trọng tương đối của chúng và tần số truy cập của chúng,

có thể ảnh hưởng đến hiệu năng. Điều này có thể giúp bạn hiểu rõ hơn các ràng buộc nên
được áp đặt ở đâu và các hành động liên quan nên được nhóm lại với nhau ở đâu để cải
thiện chất lượng và tốc độ đọc dữ liệu.
Nếu bạn có một mô hình cấu trúc dữ liệu mới được định nghĩa trong RSA, thì bạn có thể xuất
khẩu nó như là một tệp DDL đơn lẻ để từ đó xây dựng cơ sở dữ liệu DB2 mới của bạn. Tùy
thuộc vào sự phức tạp của cấu trúc cơ sở dữ liệu của bạn, bạn cũng có thể xem xét việc tạo ra các
tệp DDL riêng cho các kiểu đối tượng khác nhau để giữ mọi thứ được tổ chức hợp lý.
Ví dụ, một cách tiếp cận được khuyến cáo để di trú lặp lại là tạo DDL cho các bảng trong một
tệp, tạo DDL cho các chỉ mục riêng ra và tạo DDL cho các khóa ngoại riêng ra. Cách tiếp cận
này sẽ giúp phân chia một cách logic cấu trúc dữ liệu thành các mảnh có liên quan một cách
logic. Cách tiếp cận này cung cấp tài liệu tham khảo nếu bạn muốn xem danh sách các chỉ mục
hiện tại (thay đổi theo thời gian) hơn là tìm kiếm chúng trong tệp DDL cùng với định nghĩa các
đối tượng khác, cố định hơn ví dụ như các bảng và các khung nhìn.
Cũng giống như nhiệm vụ kỹ thuật dịch ngược trước đó, bạn có thể xem phần Tài nguyên để tìm
hiểu cách chỉnh sửa và xuất khẩu một mô hình dữ liệu bằng các công cụ dựa trên Eclipse của
IBM bằng cách đọc một hướng dẫn về cách chuyển đổi một mô hình dữ liệu vật lý thành DDL
trong tài liệu InfoSphere.
Chuyển đổi các đối tượng cơ sở dữ liệu khác
Data Movement Tool của IBM có thể tự động chuyển đổi hầu hết các đối tượng cơ sở dữ liệu, ví
dụ như các bảng, các khóa, các chỉ mục và các vùng bảng, nhưng có các đối tượng khác bạn cần
chuyển đổi thủ công nếu chúng đã có mặt trong cơ sở dữ liệu MySQL nguồn của bạn. Chúng
gồm các khung nhìn, các thủ tục đã lưu, các hàm do người dùng định nghĩa (UDF) và các tri gơ.
Các đối tượng này không khó để di trú thủ công, vì cả MySQL lẫn DB2 đều tuân thủ cú pháp thủ
tục lưu trữ SQL:2003. Và vì chức năng tri gơ DB2 cung cấp nhiều hơn những gì có sẵn trong
MySQL, bạn có thể dễ dàng tạo lại các tri gơ. Chương 6 của Sách Đỏ IBM về Phát triển các ứng
dụng PHP cho Các máy chủ dữ liệu IBM (Developing PHP Applications for IBM Data Servers)
mô tả chi tiết bất kỳ các khác biệt nào mà bạn cần hiểu rõ.
Như một lựa chọn, để tránh các lỗi trong lúc di trú dữ liệu ở bước 2, bạn có thể lui lại nhiệm vụ
này lại cho đến khi dữ liệu đã được nạp vào DB2 và quay lại với nó trong một lần lặp khác trong
giai đoạn di trú này khi bạn tinh chỉnh cơ sở dữ liệu của bạn.

Về đầu trang
Bước 2. Di chuyển dữ liệu MySQL vào cơ sở dữ liệu DB2
Trong bước này, bạn sẽ trích xuất dữ liệu từ cơ sở dữ liệu MySQL và tải nó vào DB2. Quá trình
này cũng cho bạn một cơ hội để cải thiện chất lượng dữ liệu của bạn. Bước này liên quan đến
việc hoàn thành các bước sau đây:
 Loại bỏ các bảng và dữ liệu không cần thiết
 Chuyển đổi dữ liệu MySQL không hợp với DB2
 Trích xuất dữ liệu từ MySQL
 Nạp dữ liệu vào DB2
 Thiết lập lại các gia số cột mã định danh (ID) đã tạo ra
Loại bỏ các bảng và dữ liệu không cần thiết
Data Movement Tool (Công cụ di chuyển dữ liệu) của IBM tạo ra một tệp tên bảng.tables nói rõ
dữ liệu nào cần trích xuất từ cơ sở dữ liệu nguồn bằng cách chỉ rõ một truy vấn SELECT cho
mỗi bảng cơ sở dữ liệu. Ví dụ, chỉ bao gồm các nhiệm vụ nào dưới bốn năm tuổi. Nói chung bạn
cần phải loại bỏ một số dòng và xác định các dòng khác có đủ điều kiện bằng một câu lệnh
WHERE để lọc số lượng dữ liệu được di chuyển.
Nếu bạn không muốn di chuyển một bảng từ MySQL sang DB2, bạn nên loại bỏ nó hoàn toàn
khỏi tệp này. Nếu bạn muốn di chuyển một tập con dữ liệu, bạn nên sửa đổi mệnh đề SELECT
cho phù hợp. Ví dụ, ngăn không cho bảng WORK_TMP di trú sang DB2 bằng cách xóa các
dòng được hiển thị trong .

Liệt kê 2. Một dòng đã bị xóa khỏi tệp timetrac.tables

"timetrac"."work_tmp":SELECT * FROM "timetrac"."work_tmp"

Trong trường hợp khác, bạn có thể cần chỉ giữ lại dữ liệu trong bảng WORK đã được tạo ra kể từ
năm 2008. Ví dụ, thêm một mệnh đề WHERE như được hiển thị trong .

Liệt kê 3. Một dòng được chỉnh sửa để lọc dữ liệu để di trú theo ngày tháng

"timetrac"."work":SELECT * FROM "timetrac"."work" WHERE ts >= '2008-01-01'

Chuyển đổi dữ liệu MySQL không hợp với DB2
Một nhiệm vụ quan trọng khác là xác định tính tương thích giữa các kiểu dữ liệu trong cơ sở dữ
liệu nguồn và cơ sở dữ liệu mới. Vì bạn đã chỉnh sửa cơ sở dữ liệu DB2 trong Bước 1 tổ chức lại
mô hình dữ liệu của bạn, hãy đảm bảo rằng các dữ liệu đã được nhập khẩu từ MySQL tương
thích với các kiểu dữ liệu được định nghĩa trong DB2.
Ví dụ, kiểu dữ liệu TIME tồn tại trong cả MySQL lẫn DB2, nhưng có các phạm vi khác nhau.
Trong MySQL, TIME biểu diễn một đồng hồ có phạm vi, từ -838:59:59 đến 838:59:59. Tuy
nhiên, trong DB2, TIME được biểu diễn là một đồng hồ 24 giờ, có phạm vi từ 00:00:00 đến
24:00:00. Trong các trường hợp mà dữ liệu với kiểu dữ liệu TIME không phù hợp với đồng hồ
24 giờ, hãy chuẩn hóa dữ liệu để tương thích với kiểu dữ liệu DB2 ngay trong MySQL trước khi
di trú. cho thấy một câu lệnh SQL mà bạn có thể sử dụng để thực hiện việc chuyển đổi.

Liệt kê 4. Chuyển đổi dữ liệu TIME trong MySQL để phù hợp với dữ liệu TIME được DB2
công nhận

mysql> UPDATE WORK W SET W.HOUR = SUBTIME(W.HOUR, '24:00:00') WHERE W.HOUR >=
'24:00:00';

Có thể có các kiểu dữ liệu khác yêu cầu phải thay đổi trong cơ sở dữ liệu nguồn của bạn trước
khi chúng được di trú. Phần 6.1 của Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài
nguyên) cung cấp một mô tả về từng loại dữ liệu và một bảng hiển thị tính tương thích dữ liệu.
Trích xuất dữ liệu từ MySQL
Với dữ liệu trong MySQL đã chuẩn bị để di trú, mở lại Data Movement Tool của IBM và đánh
dấu chọn hộp kiểm tra Data và nhấn vào Extract DDL/Data (Trích xuất DDL/dữ liệu), như hiển
thị trong .

Hình 2. Tạo ra các kịch bản lệnh trích xuất

Khi hoàn thành, bạn sẽ thấy bốn tệp trong thư mục migr: geninput, rowcount, timetrac.tables (ở
đây timetrac là tên cơ sở dữ liệu), và unload.
Thay thế tệp timetrac.tables bằng một tệp mà bạn đã chỉnh sửa sau bước trích xuất cơ sở dữ liệu
để hạn chế dữ liệu chỉ còn một tập hợp con. Chạy unload để trích xuất dữ liệu từ MySQL. Sau
khi di trú hoàn tất, kiểm tra các thông báo lỗi trong tệp IBMDataMovementTool.log. Sau khi
unload thành công, có thể nhiều tệp được tạo ra, bao gồm một tệp db2load.cmd và một thư mục
data.
Nạp dữ liệu vào DB2
Chuyển tới thư mục migr và chạy kịch bản lệnh bó db2load.cmd để thực hiện di trú dữ liệu thực
sự vào DB2.
Kiểm tra db2load.log để xem liệu tất cả dữ liệu đã được tải vào DB2 thành công chưa. Data
Movement Tool của IBM cung cấp một kịch bản lệnh để xác minh xem số lượng hàng trong cơ
sở dữ liệu MySQL nguồn có bằng số lượng hàng trong các bảng DB2 không. Bạn có thể chạy
lệnh rowcount (đếm hàng) để xác nhận xem các số lượng có khớp nhau không.
Ngoài điều này, bạn cũng có thể muốn xác minh dữ liệu trong DB2 một cách cẩn thận bằng cách
sử dụng các phương pháp khác, ví dụ như so sánh đầu ra của các truy vấn quan trọng. Mục 7.2.7
trong Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên) trình bày một vài chiến
lược để kiểm tra dữ liệu đã di trú.
Thiết lập lại gia số cột mã định danh (ID) đã tạo ra
Một khi bạn đã di chuyển dữ liệu, bạn có thể cần cập nhật cơ sở dữ liệu của bạn để bắt đầu đánh
số trong cột mã định danh (ID) đã tạo ra tự động, bắt đầu từ một số lớn hơn tất cả các giá trị hiện
có trong dữ liệu đã di trú. Ví dụ, nếu bạn có 3.000 hàng trong dữ liệu mà bạn đã di trú, bạn có thể
muốn thay đổi cơ sở dữ liệu của mình để bắt đầu tạo ra các mã định danh cho các bản ghi mới
mà bạn sẽ chèn vào bằng một số an toàn trên 3.000, chẳng hạn như 5.000, thay vì gán cho các
mã định danh bắt đầu bằng 1 và sẽ gây ra xung đột. cho thấy việc sửa đổi các định nghĩa cột của
bạn để thiết lập lại việc đánh số cột mã định danh đã tạo ra.

Liệt kê 5. Lệnh thiết lập lại các cột mã định danh được tạo ra

ALTER TA

BLE WORK ALTER COLUMN ID RESTART WITH 5000;

Về đầu trang
Bước 3.Tạo lại các quyền hạn người dùng và cấu hình quản trị cơ sở dữ liệu
Với cấu trúc cơ sở dữ liệu và dữ liệu đã nhập khẩu vào DB2, bước quan trọng thứ ba là đảm bảo
rằng việc truy cập vào (và quản trị) các dữ liệu ấy là đúng đắn. Bạn cần thiết lập các tài khoản
người dùng cần thiết và gán cho chúng các quyền hạn thích hợp. Sau đó, bạn sẽ thực hiện cấu
hình sao lưu dự phòng và phục hồi sau thảm họa cơ sở dữ liệu của bạn dựa trên hệ thống hiện có
mà bạn đã xác định cách thiết lập trong DB2 từ việc nghiên cứu và tham khảo ý kiến một chuyên
gia về DB2. Cuối cùng, bạn sẽ cấu hình tạo bản sao để tạo ra một hệ thống ảnh gương sẽ được
một hệ thống tinh thông nghiệp vụ Cognos® sử dụng để tạo các báo cáo.
Bước này liên quan đến việc hoàn thành các bước con sau đây:
 Chuyển đổi mô hình các quyền hạn
 Chuyển đổi thủ tục sao lưu và khôi phục lại
 Chuyển đổi mô hình sao chép tạo báo cáo
Chuyển đổi mô hình các quyền hạn
Khi bạn đã cài đặt DB2, bạn đã tạo ra một ID người dùng db2inst1 là chủ sở hữu cá thể mặc
định. Trong cơ sở dữ liệu MySQL, đã có một người dùng quản trị tương tự là root. Vì vậy, rõ
ràng là bất cứ lúc nào bạn cần thực hiện các chức năng thường được người dùng root chạy, bạn
sẽ sử dụng db2inst1 để thay thế.
Bạn cũng cần tạo ra hai tài khoản người dùng khác. Người dùng pttuser thực hiện các hoạt
động đọc và viết theo yêu cầu của ứng dụng. Người dùng read là cần thiết với cả hai cơ sở dữ
liệu sản xuất và bản sao. Tài khoản này là cần thiết để thực hiện các truy vấn chỉ đọc trên các cơ
sở dữ liệu sản xuất. Cơ chế tạo báo cáo Cognos trên cơ sở dữ liệu bản sao cũng sử dụng tài
khoản read. Các tài khoản này được thể hiện trong .

Bảng 1. Danh sách những người dùng
Người dùng Mô tả Cơ sở dữ liệu
Quản trị
(db2inst1)

Một tài khoản người dùng với các đặc quyền SYSADM
Sản xuất và tạo
báo cáo
Ứng dụng
(pttuser)
Một người dùng có quyền truy cập đọc và viết vào cơ sở dữ
liệu sản xuất
Sản xuất
Tạo báo cáo
(read)
Một người có quyền truy cập chỉ đọc vào cơ sở dữ liệu sản
xuất và tạo báo cáo
Sản xuất và tạo
báo cáo
Có thể tạo ra các tài khoản người dùng trên hệ điều hành Linux và các câu lệnh GRANT (cấp)
được dùng để gán cho chúng các đặc quyền cơ sở dữ liệu đúng đắn. Điều này thường được thực
hiện như một hoạt động riêng rẽ sau khi bạn đã tạo ra cơ sở dữ liệu DB2 và đã di trú dữ liệu từ
MySQL vào nó. Tuy nhiên, khi bạn triển khai vào sản xuất, bạn sẽ bao gồm các câu lệnh
GRANT vào trong cùng DDL khi bạn sử dụng để tạo cấu trúc cơ sở dữ liệu.
Với MySQL, việc cung cấp quyền truy cập thường là ở mức thô, vì bạn có thể cấp phép cho một
người dùng (được xác định đủ điều kiện bởi một tên máy tính chủ (hostname) mà từ đó người
dùng kết nối) các quyền hạn truy cập đọc, viết hoặc quản lý khác đối với toàn bộ cơ sở dữ liệu.
Trong ví dụ này, người dùng pttuser có quyền truy cập đọc và viết vào cơ sở dữ liệu (chỉ từ tên
máy tính chủ (hostname) của máy chủ web) và do đó có thể truy cập và chỉnh sửa mỗi bảng
trong đó.
Với DB2, bạn cấp phép truy cập cho một người dùng, nhưng bạn không chỉ ra tên máy tính chủ
mà từ đó người dùng kết nối. Ngoài ra với DB2, bạn có thể chỉ rõ đó là quyền truy cập để truy
vấn, thêm, hoặc cập nhật dữ liệu như bạn làm trong MySQL. Tuy nhiên, bạn phải cấp phép truy
cập cho một người dùng với mỗi bảng trong cơ sở dữ liệu, vì không có một câu lệnh đơn lẻ nào
để cấp phép truy cập toàn bộ cơ sở dữ liệu (trừ khi bạn đã tạo ra cơ sở dữ liệu và các bảng với tư

cách là người dùng đó, mà điều này được khuyến cáo là không nên làm). Vì vậy, các lệnh
GRANT thường bao gồm trong DDL sau khi các đối tượng, như các bảng, được tạo ra.
cho thấy các quyền hạn để cấp cho bảng WORK trong ví dụ. Người dùng application nhận được
đầy đủ quyền truy cập đọc và viết, trong khi người dùng reporting chỉ có thể đọc dữ liệu.

Liệt kê 6. Các câu lệnh GRANT mẫu

GRANT statements to provide read/write access to the application user
account
GRANT DELETE ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER";
GRANT INSERT ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER";
GRANT SELECT ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER";
GRANT UPDATE ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER";

GRANT statement to provide read only access to the reporting/ad hoc user
account
GRANT SELECT ON TABLE "TIMETRAC"."WORK" TO USER "READ";

Mục 7.1.3 trong Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên) cung cấp
thông tin chi tiết về các khác biệt trong việc quản lý tài khoản người dùng và các tùy chọn mức
chi tiết hơn do DB2 cung cấp.
Chuyển đổi thủ tục sao lưu và khôi phục lại
Bạn đã sẵn sàng thực hiện một kế hoạch khắc phục thảm họa, cân bằng giữa yêu cầu sẵn sàng
cao của ứng dụng với yêu cầu lưu trữ cẩn thận dữ liệu của bạn.
Trong MySQL, bạn có thể sử dụng một lệnh như mysqldump để sao lưu dữ liệu của bạn và chạy
thi hành SQL để khôi phục lại dữ liệu. Trong hệ thống ví dụ, bạn muốn dựa vào các bản sao lưu
hàng đêm bằng cách sử dụng mysqldump và bạn muốn chạy một cơ sở dữ liệu bản sao được đồng
bộ hóa cho mục đích tạo báo cáo chỉ đọc và phục vụ cho nhiệm vụ kép như một hệ thống dự
phòng sống.
Đối với cơ sở dữ liệu mới, hãy lập lịch biểu các lệnh sao lưu và phục hồi bằng cách sử dụng các

công cụ được cung cấp kèm DB2. Bạn có một số lựa chọn cho các lệnh này để cho phép bạn
thực hiện các sao lưu đầy đủ hoặc sao lưu gia tăng, trực tuyến hoặc không trực tuyến. Ví dụ, bạn
có thể muốn thực hiện một sao lưu gia tăng trực tuyến một lần mỗi ngày, và rồi thực hiện một
sao lưu đầy đủ, không trực tuyến một lần cho mỗi tuần trong một cửa sổ bảo trì. cho thấy một ví
dụ về chính sách và lập lịch biểu sao lưu và khôi phục.

Bảng 2. Kế hoạch. sao lưu và khắc phục thảm họa
Nhiệm vụ Mô tả
Sao lưu trực
tuyến hàng
đêm
Thực hiện sao lưu trực tuyến cơ sở dữ liệu DB2 mỗi đêm và lưu trữ nó trên cùng
một máy chủ DB2. Việc sao lưu này cung c
ấp khả năng khôi phục lại nhanh chóng
và dễ dàng khỏi các vấn đề cơ sở dữ liệu đơn giản. Nó không đòi hỏi bạn phải
dừng ứng dụng. Tuy nhiên, nó c
ũng không cung cấp khả năng sử dụng các bản ghi
nhật ký để khôi phục lại giao dịch kể từ lúc sao lưu, có nghĩa là bất kỳ dữ liệu nào
được tạo ra trong thời gian từ lúc thực hiện sao lưu đến lúc có lỗi cơ sở dữ liệu có
thể không còn nữa.
Sao
lưu hàng
tuần không
trực tuyến
Thực hiện sao lưu không trực tuyến cơ sở dữ liệu DB2, mỗi cuối tuần và lưu trữ
nó trên máy chủ khác, tốt nhất ở vị trí khác. Việc sao lưu này tạo ra khả năng khôi
phục lại tin cậy hơn khỏi các vấn đề lớn của máy chủ. Việc sao lưu này đòi hỏi
bạn dừng ứng dụng. Tuy nhiên, nó cũng cung cấp khả năng khôi phục lại các giao
dịch từ lúc sao lưu bằng cách sử dụng các bản ghi nhật ký, có nghĩa là dữ liệu có
thể được khôi phục lại đầy đủ bằng cách sử dụng sao lưu và các hoạt động đã

được ghi lại kể từ lúc sao lưu bằng cách cho chạy lại dựa theo nhật ký.
Chương 9 của Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên) có thể là chìa
khóa để xác định và triển khai một quá trình sao lưu và khôi phục lại mới. Nó cung cấp các lệnh
sao lưu mẫu và các gợi ý về cách lập lịch biểu các lần chạy sao lưu bằng cách sử dụng DB2
Control Center hay Optim™ Development Studio.
Chuyển đổi mô hình sao chép tạo báo cáo
Như đã nói trong Phần 1, việc cải thiện sự tinh thông nghiệp vụ của bạn qua việc chọn dùng một
công cụ như Cognos là một yếu tố quan trọng dẫn dắt bạn di trú sang DB2. Như vậy, cấu hình
một cơ sở dữ liệu bản sao để chạy các truy vấn và trích xuất các báo cáo trên đó phải là một phần
trọng yếu của các nỗ lực di trú cơ sở dữ liệu của bạn.
Nếu bạn cần chạy các báo cáo dựa vào dữ liệu của bạn, thì nhiều khả năng bạn có một cơ sở dữ
liệu bản sao chỉ đọc để giảm tải trên cơ sở dữ liệu sản xuất chính của bạn. Cơ sở dữ liệu bản sao
là một bản sao chính xác của cơ sở dữ liệu vận hành. Bạn chạy ứng dụng của mình để truy cập và
sửa đổi thông tin của cá thể chính của cơ sở dữ liệu, sao chép tất cả dữ liệu vào cơ sở dữ liệu bản
sao, và chạy tất cả các báo cáo của bạn dựa vào cá thể chỉ đọc đó của cơ sở dữ liệu.
Một lần nữa, MySQL và DB2 xử lý các bản sao khác nhau. Với MySQL, bạn có thể thay đổi một
vài tham số cấu hình và sao chép toàn bộ cơ sở dữ liệu từ một máy chủ sang máy chủ khác trong
thời gian thực. Hoặc bạn có thể thực hiện các lần sao lưu và hồi phục không đồng bộ các bản sao
lưu này vào một thời gian sau đó vào trong cơ sở dữ liệu khác.
Với DB2, bạn có sẵn các tùy chọn tương tự, bao gồm sao chép SQL và sao chép Q. Ví dụ, sử
dụng sao chép SQL để tránh sự phức tạp tăng thêm do trình quản lý hàng đợi thông báo dựa trên
kênh, cần phải có để xử lý sao chép Q. Với sao chép SQL, bạn tạo một cấu hình chỉ rõ mỗi bảng
trong cơ sở dữ liệu mà bạn muốn sao chép. Bạn sẽ cần chắc chắn cập nhật cấu hình đó bất cứ lúc
nào bạn thực hiện một thay đổi cho cấu trúc cơ sở dữ liệu của bạn.
Ngoài ra, trước khi thiết lập sao chép trong DB2, bạn sẽ cần đảm bảo rằng tất cả các bảng cơ sở
dữ liệu có một khóa chính hoặc chỉ mục duy nhất. Trong khi đây là một cách thực hành tốt, thì
một số cơ sở dữ liệu có thể thiếu điều này. Hãy nhớ rằng các bảng MySQL ví dụ thiếu các giá trị
này bởi vì chúng đã được tạo ra bằng máy lưu trữ MyISAM cơ bản. Bản sao MySQL sẽ làm việc
mà không cần khóa hoặc chỉ mục. Tuy nhiên, việc sao chép DB2 đòi hỏi có khóa hoặc chỉ mục
để định danh duy nhất các hàng trong một bảng. Nếu một bảng không có một khóa chính hoặc

một chỉ mục duy nhất nào, các bản ghi được cập nhật trong cơ sở dữ liệu vận hành có thể được
xem như các bản ghi mới được tạo ra chứ không phải bản ghi đang có được cập nhật, vì không
có khóa nào để sử dụng để tìm ra bản ghi đang được cập nhật.
Chương 9 của Hướng dẫn chuyển đổi MySQL sang DB2 (xem phần Tài nguyên) là trung tâm của
chiến lược cấu hình tạo bản sao của bạn. DB2 cung cấp các công cụ có thể được sử dụng để quản
lý các thiết lập sao chép, hoặc bạn có thể thực hiện một giải pháp tùy chỉnh dựa trên việc chuyển
đổi các bản ghi nhật ký.
Về đầu trang
Bước 4. Kiểm lại bước khởi đầu di trú cơ sở dữ liệu
Tại thời điểm này sau một lần lặp lại trọn vẹn các bước 1-3, mà bản thân chúng lại bao gồm một
số bước, bạn sẽ phải có một hệ thống cơ sở dữ liệu hoạt động trên một máy trạm Windows và
một số ghi chép về những gì bạn đã thay đổi và những gì đã có vấn đề.
Nếu bạn đã sử dụng máy ảo, bạn lấy một ảnh của hệ thống Windows làm một ảnh chụp, vừa để
lưu trữ như là một điểm lưu làm việc vừa để sử dụng như là một vạch khởi đầu để so sánh các
thay đổi hiệu năng trong tương lai. Một lựa chọn khác, tất nhiên, là sử dụng một ảnh ảo trong
Đám mây của IBM hay của Amazon và sử dụng ảnh đó theo cùng một cách.
Bạn có thể muốn thí nghiệm một số cách thực hiện di trú khác nhau để xem cách nào làm việc
tốt nhất cho môi trường của bạn. Một khi bạn đã hài lòng với hệ thống trên máy trạm Windows
được sử dụng trong các bước 1-3, thì bạn có thể di chuyển cơ sở dữ liệu đến một máy chủ dành
riêng, ở đó bạn sẽ thử nghiệm các bản cập nhật cho ứng dụng PHP trong Phần 3 của loạt bài này.
Về đầu trang
Kết luận
Mục đích của loạt bài này là cung cấp cho bạn một sự hiểu biết về những gì cần thiết nói chung
để di trú một ứng dụng PHP từ MySQL sang DB2, tài nguyên nào có sẵn để giúp bạn, và một ví
dụ về một cuộc di trú thành công.
Trong phần thứ hai này của loạt bài, bạn:
 Đã tìm hiểu về cơ sở dữ liệu MySQL nguồn bạn đã chuyển đổi
 Đã tìm hiểu cách chuyển đổi cấu trúc cơ sở dữ liệu sang DB2
 Đã tìm hiểu cách di trú dữ liệu sang DB2
 Đã tìm hiểu cách thiết lập quản trị cơ sở dữ liệu của bạn

Trong phần tiếp theo của loạt bài này, bạn sẽ tìm hiểu cách chuyển đổi mã PHP.
Lời cảm ơn
Các tác giả cảm ơn Leons Petrazickis và Ambrish Bhargava về việc xem xét và góp ý kiến cho
bài này