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

Chia sẻ: Nhung Nhung | Ngày: | Loại File: PDF | Số trang:17

Thêm vào BST

Báo xấu

89
lượt xem 8
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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,...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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

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 TABLE 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ị Sản xuất và tạo Một tài khoản người dùng với các đặc quyền SYSADM (db2inst1) báo cáo Ứng dụng Một người dùng có quyền truy cập đọc và viết vào cơ sở dữ Sản xuất (pttuser) liệu sản xuất Tạo báo cáo Một người có quyền truy cập chỉ đọc vào cơ sở dữ liệu sản Sản xuất và tạo (read) xuất và tạo báo cá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ả 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 Sao lưu trực 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 tuyến hàng 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 đêm 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. 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 Sao lưu hàng 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 tuần không 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 trực tuyến 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..