Di chuyển từ Oracle sang MySQL / Percona Server không phải là một nhiệm vụ tầm thường. Mặc dù nó đang trở nên dễ dàng hơn, đặc biệt là với sự xuất hiện của MySQL 8.0 và Percona đã công bố Máy chủ Percona cho MySQL 8.0 GA. Ngoài việc lập kế hoạch di chuyển từ Oracle sang Máy chủ Percona, bạn phải đảm bảo rằng bạn hiểu mục đích và chức năng tại sao nó phải là Máy chủ Percona.
Blog này sẽ tập trung vào Di chuyển từ Oracle sang Máy chủ Percona làm cơ sở dữ liệu mục tiêu cụ thể được lựa chọn. Có một trang trong trang web Oracle về Thông tin bổ sung dành cho nhà phát triển SQL cho MySQL Migrations có thể được sử dụng làm tài liệu tham khảo cho quá trình di chuyển theo kế hoạch. Blog này sẽ không đề cập đến quá trình di chuyển tổng thể, vì nó là một quá trình dài. Nhưng hy vọng nó sẽ cung cấp đủ thông tin cơ bản để làm hướng dẫn cho quá trình di chuyển của bạn.
Vì Máy chủ Percona là một nhánh của MySQL nên hầu như tất cả các tính năng đi kèm trong MySQL đều có trong Máy chủ Percona. Vì vậy, bất kỳ tham chiếu nào của MySQL ở đây cũng có thể áp dụng cho Máy chủ Percona. Trước đây, chúng tôi đã viết blog về việc chuyển Cơ sở dữ liệu Oracle sang PostgreSQL. Tôi sẽ nhắc lại một lần nữa lý do tại sao một người sẽ cân nhắc việc chuyển từ Oracle sang RDBMS nguồn mở như PostgreSQL hoặc Percona Server / MySQL / MariaDB.
- Chi phí:Như bạn có thể biết chi phí cấp phép của Oracle rất đắt và có thêm chi phí cho một số tính năng như phân vùng và tính khả dụng cao. Vì vậy, nhìn chung nó rất đắt.
- Cấp phép nguồn mở linh hoạt và tính khả dụng dễ dàng từ các nhà cung cấp đám mây công cộng như AWS.
- Hưởng lợi từ các tiện ích bổ sung nguồn mở để cải thiện hiệu suất.
Chiến lược lập kế hoạch và phát triển
Việc di chuyển từ Oracle sang Percona Server 8.0 có thể là một vấn đề khó khăn vì có rất nhiều yếu tố chính cần được xem xét và giải quyết. Ví dụ, Oracle có thể chạy trên máy Windows Server nhưng Percona Server không hỗ trợ Windows. Mặc dù bạn có thể biên dịch nó cho Windows, nhưng bản thân Percona không cung cấp bất kỳ hỗ trợ nào cho Windows. Bạn cũng phải xác định các yêu cầu về kiến trúc cơ sở dữ liệu của mình, vì Máy chủ Percona không được thiết kế cho các ứng dụng OLAP (Xử lý Phân tích Trực tuyến) hoặc các ứng dụng kho dữ liệu. Máy chủ Percona / MySQL RDBMS hoàn toàn phù hợp cho OLTP (Xử lý giao dịch trực tuyến).
Xác định khía cạnh quan trọng của kiến trúc cơ sở dữ liệu của bạn, ví dụ:nếu kiến trúc Oracle hiện tại của bạn triển khai MAA (Kiến trúc khả dụng tối đa) với Data Guard ++ Oracle RAC (Cụm ứng dụng thực), bạn nên xác định tính tương đương của nó trong Máy chủ Percona. Không có câu trả lời thẳng thắn cho điều này trong MySQL / Percona Server. Tuy nhiên, bạn có thể chọn từ một bản sao đồng bộ, một bản sao không đồng bộ (Percona XtraDB Cluster hiện vẫn đang ở phiên bản 5.7.x) hoặc với Group Replication. Sau đó, có nhiều lựa chọn thay thế mà bạn có thể triển khai cho giải pháp có tính khả dụng cao của riêng mình. Ví dụ:(để chỉ một vài cái tên) bằng cách sử dụng ngăn xếp Corosync / Pacemaker / DRBD / Linux, hoặc sử dụng MHA (Tính khả dụng cao của MySQL), hoặc sử dụng ngăn xếp Keepalived / HaProxy / ProxySQL hoặc đơn giản là dựa vào ClusterControl hỗ trợ Keepalived, HaProxy, ProxySQL, Garbd và Maxscale cho các giải pháp có tính khả dụng cao của bạn.
Mặt khác, câu hỏi bạn cũng phải xem xét như một phần của kế hoạch là "Percona sẽ cung cấp hỗ trợ như thế nào và ai sẽ giúp chúng tôi khi Percona Server gặp lỗi hoặc mức độ khẩn cấp khi chúng tôi cần trợ giúp là bao nhiêu?". Một điều cũng cần xem xét là ngân sách, nếu mục đích chuyển từ cơ sở dữ liệu doanh nghiệp sang RDBMS mã nguồn mở là vì cắt giảm chi phí.
Có nhiều lựa chọn khác nhau từ lập kế hoạch di chuyển đến những việc bạn cần làm như một phần của chiến lược phát triển của mình. Các tùy chọn như vậy bao gồm việc tham gia với các chuyên gia trong lĩnh vực Máy chủ MySQL / Percona và bao gồm cả chúng tôi ở đây tại Somenines. Có rất nhiều công ty tư vấn MySQL có thể giúp bạn giải quyết vấn đề này vì việc chuyển đổi từ Oracle sang MySQL đòi hỏi rất nhiều kiến thức chuyên môn và bí quyết trong lĩnh vực Máy chủ MySQL. Điều này không nên giới hạn ở cơ sở dữ liệu nhưng nó phải bao gồm chuyên môn về khả năng mở rộng, dự phòng, sao lưu, tính sẵn sàng cao, bảo mật, giám sát / khả năng quan sát, phục hồi và tham gia vào các hệ thống quan trọng. Nhìn chung, nó phải hiểu rõ kiến trúc của bạn mà không để lộ tính bảo mật của dữ liệu của bạn.
Đánh giá hoặc Kiểm tra sơ bộ
Sao lưu dữ liệu của bạn bao gồm cấu hình hoặc tệp thiết lập, điều chỉnh hạt nhân, tập lệnh tự động hóa sẽ không bị lãng quên. Đó là một nhiệm vụ hiển nhiên, nhưng trước khi bạn di chuyển, hãy luôn bảo mật mọi thứ trước, đặc biệt là khi chuyển sang một nền tảng khác.
Bạn cũng phải đánh giá rằng các ứng dụng của mình đang tuân theo các quy ước kỹ thuật phần mềm cập nhật và đảm bảo rằng chúng không có nền tảng. Những phương pháp này có thể mang lại lợi ích cho bạn, đặc biệt là khi chuyển sang một nền tảng cơ sở dữ liệu khác, chẳng hạn như Máy chủ Percona cho MySQL.
Hãy lưu ý rằng hệ điều hành mà Máy chủ Percona yêu cầu có thể là một trình dừng hiển thị nếu ứng dụng và cơ sở dữ liệu của bạn chạy trên Máy chủ Windows và ứng dụng phụ thuộc vào Windows; thì điều này có thể là rất nhiều công việc! Luôn nhớ rằng Máy chủ Percona nằm trên một nền tảng khác:sự hoàn hảo có thể không được đảm bảo nhưng có thể đạt được đủ gần.
Cuối cùng, hãy đảm bảo rằng phần cứng được nhắm mục tiêu được thiết kế để hoạt động khả thi với các yêu cầu máy chủ của Percona hoặc ít nhất là không có lỗi (xem tại đây). Trước tiên, bạn có thể cân nhắc kiểm tra căng thẳng với Máy chủ Percona trước khi chuyển khỏi Cơ sở dữ liệu Oracle của mình một cách đáng tin cậy.
Những điều bạn nên biết
Cần lưu ý rằng trong Percona Server / MySQL, bạn có thể tạo nhiều cơ sở dữ liệu trong khi Oracle không có chức năng tương tự như MySQL.
Trong MySQL, về mặt vật lý, một lược đồ đồng nghĩa với một cơ sở dữ liệu. Bạn có thể thay thế từ khóa SCHEMA thay vì DATABASE trong cú pháp MySQL SQL, ví dụ:sử dụng CREATE SCHEMA thay vì TẠO CƠ SỞ DỮ LIỆU; trong khi Oracle có một sự khác biệt về điều này. Một lược đồ chỉ đại diện cho một phần của cơ sở dữ liệu:các bảng và các đối tượng khác do một người dùng sở hữu. Thông thường, có một mối quan hệ 1-1 giữa phiên bản và cơ sở dữ liệu.
Ví dụ:trong một thiết lập sao chép tương đương trong Oracle (ví dụ:Cụm ứng dụng thực hoặc RAC), bạn có nhiều phiên bản của mình truy cập vào một cơ sở dữ liệu duy nhất. Điều này cho phép bạn khởi động Oracle trên nhiều máy chủ, nhưng tất cả đều truy cập vào cùng một dữ liệu. Tuy nhiên, trong MySQL, bạn có thể cho phép truy cập vào nhiều cơ sở dữ liệu từ nhiều phiên bản của mình và thậm chí có thể lọc ra cơ sở dữ liệu / lược đồ nào bạn có thể sao chép sang một nút MySQL.
Tham khảo từ một trong những blog trước đây của chúng tôi, nguyên tắc tương tự áp dụng khi nói về việc chuyển đổi cơ sở dữ liệu của bạn bằng các công cụ có sẵn trên internet.
Không có công cụ nào có thể chuyển đổi 100% cơ sở dữ liệu Oracle thành Percona Server / MySQL; một số trong số đó sẽ là công việc thủ công.
Kiểm tra các phần sau để biết những điều bạn phải biết khi nói đến việc di chuyển và xác minh kết quả SQL logic.
Ánh xạ kiểu dữ liệu
MySQL / Percona Server có một số kiểu dữ liệu gần giống như Oracle nhưng không phong phú bằng so với Oracle. Nhưng kể từ khi xuất hiện phiên bản 5.7.8 của MySQL, được hỗ trợ cho kiểu dữ liệu JSON gốc.
Dưới đây là biểu diễn tương đương kiểu dữ liệu của nó (biểu diễn dạng bảng được lấy từ đây):
Oracle | MySQL | |||
---|---|---|---|---|
1 | NỀN | Con trỏ tới tệp nhị phân, ⇐ 4G | VARCHAR (255) | |
2 | BINARY_FLOAT | Số dấu phẩy động 32 bit | NỔI | |
3 | BINARY_DOUBLE | Số dấu phẩy động 64 bit | ĐÔI | |
4 | BLOB | Đối tượng lớn nhị phân, ⇐ 4G | LONGBLOB | |
5 | CHAR (n), CHARACTER (n) | Chuỗi có độ dài cố định, 1 ⇐ n ⇐ 255 | CHAR (n), CHARACTER (n) | |
6 | CHAR (n), CHARACTER (n) | Chuỗi có độ dài cố định, 256 ⇐ n ⇐ 2000 | VARCHAR (n) | |
7 | CLOB | Đối tượng lớn có ký tự, ⇐ 4G | LONGTEXT | |
8 | NGÀY | Ngày và giờ | DATETIME | |
9 | DECIMAL (p, s), DEC (p, s) | Số điểm cố định | DECIMAL (p, s), DEC (p, s) | |
10 | CHÍNH XÁC ĐÔI | Số dấu phẩy động | CHÍNH XÁC ĐÔI | |
11 | FLOAT (p) | Số dấu phẩy động | ĐÔI | |
12 | INTEGER, INT | số nguyên 38 chữ số | INT | DECIMAL (38) |
13 | INTERVAL NĂM (p) ĐẾN THÁNG | Khoảng ngày | VARCHAR (30) | |
14 | NGÀY CAN THIỆP (p) ĐẾN (s) THỨ HAI | Khoảng thời gian ngày và giờ | VARCHAR (30) | |
15 | DÀI | Dữ liệu ký tự, ⇐ 2G | LONGTEXT | |
16 | NGUYÊN LIỆU DÀI | Dữ liệu nhị phân, ⇐ 2G | LONGBLOB | |
17 | NCHAR (n) | Chuỗi UTF-8 có độ dài cố định, 1 ⇐ n ⇐ 255 | NCHAR (n) | |
18 | NCHAR (n) | Chuỗi UTF-8 có độ dài cố định, 256 ⇐ n ⇐ 2000 | NVARCHAR (n) | |
19 | NCHAR VARYING (n) | Chuỗi UTF-8 có độ dài thay đổi, 1 ⇐ n ⇐ 4000 | NCHAR VARYING (n) | |
20 | NCLOB | Chuỗi Unicode có độ dài thay đổi, ⇐ 4G | NVARCHAR (tối đa) | |
21 | NUMBER (p, 0), NUMBER (p) | số nguyên 8 bit, 1 <=p <3 | TINYINT | (0 đến 255) |
số nguyên 16 bit, 3 <=p <5 | SMALLINT | |||
số nguyên 32 bit, 5 <=p <9 | INT | |||
Số nguyên 64 bit, 9 <=p <19 | LỚN | |||
Số điểm cố định, 19 <=p <=38 | QUYẾT ĐỊNH (p) | |||
22 | NUMBER (p, s) | Số điểm cố định, s> 0 | QUYẾT ĐỊNH (p, s) | |
23 | NUMBER, NUMBER (*) | Số dấu phẩy động | ĐÔI | |
24 | SỐ (p, s) | Số điểm cố định | SỐ (p, s) | |
25 | NVARCHAR2 (n) | Chuỗi UTF-8 có độ dài thay đổi, 1 ⇐ n ⇐ 4000 | NVARCHAR (n) | |
26 | RAW (n) | Chuỗi nhị phân có độ dài thay đổi, 1 ⇐ n ⇐ 255 | BINARY (n) | |
27 | RAW (n) | Chuỗi nhị phân có độ dài thay đổi, 256 ⇐ n ⇐ 2000 | VARBINARY (n) | |
28 | THỰC | Số dấu phẩy động | ĐÔI | |
29 | ROWID | Địa chỉ hàng thực | CHAR (10) | |
30 | SMALLINT | số nguyên 38 chữ số | QUYẾT ĐỊNH (38) | |
31 | TIMESTAMP (p) | Ngày và giờ với phân số | DATETIME (p) | |
32 | TIMESTAMP (p) VỚI KHU VỰC THỜI GIAN | Ngày và giờ với phân số và múi giờ | DATETIME (p) | |
33 | UROWID (n) | Địa chỉ hàng logic, 1 ⇐ n ⇐ 4000 | VARCHAR (n) | |
34 | VARCHAR (n) | Chuỗi có độ dài thay đổi, 1 ⇐ n ⇐ 4000 | VARCHAR (n) | |
35 | VARCHAR2 (n) | Chuỗi có độ dài thay đổi, 1 ⇐ n ⇐ 4000 | VARCHAR (n) | |
36 | XMLTYPE | Dữ liệu XML | LONGTEXT |
Các thuộc tính và tùy chọn kiểu dữ liệu:
Oracle | MySQL |
Ngữ nghĩa kích thước cột BYTE và CHAR | Kích thước luôn tính bằng ký tự |
Giao dịch
Máy chủ Percona sử dụng XtraDB (phiên bản nâng cao của InnoDB) làm công cụ lưu trữ chính để xử lý dữ liệu giao dịch; mặc dù các công cụ lưu trữ khác nhau có thể là lựa chọn thay thế để xử lý các giao dịch như TokuDB (không dùng nữa) và các công cụ lưu trữ MyRocks.
Mặc dù có những ưu điểm và lợi ích khi sử dụng hoặc khám phá MyRocks với XtraDB, nhưng công cụ lưu trữ thứ hai là công cụ lưu trữ thực tế và mạnh mẽ hơn mà Máy chủ Percona đang sử dụng và nó được bật theo mặc định, vì vậy chúng tôi sẽ sử dụng công cụ lưu trữ này làm cơ sở cho việc di chuyển liên quan đến giao dịch.
Theo mặc định, Percona Server / MySQL có biến tự động gửi được đặt thành BẬT, có nghĩa là bạn phải xử lý rõ ràng các câu lệnh giao dịch để tận dụng ROLLBACK để bỏ qua các thay đổi hoặc lợi dụng việc sử dụng SAVEPOINT.
Về cơ bản, nó giống khái niệm mà Oracle sử dụng về cam kết, khôi phục và điểm lưu.
Đối với các giao dịch rõ ràng, điều này có nghĩa là bạn phải sử dụng BẮT ĐẦU GIAO DỊCH / BẮT ĐẦU;
Ngược lại, nếu bạn phải tắt tính năng tự động gửi, bạn phải CAM KẾT rõ ràng mọi lúc cho các câu lệnh yêu cầu thay đổi dữ liệu của bạn.
MySQL có khả năng tương thích kép với Oracle có nghĩa là để tương thích với cơ sở dữ liệu bằng cách sử dụng bảng giả, cụ thể là DUAL.
Điều này phù hợp với việc sử dụng DUAL của Oracle, vì vậy bất kỳ câu lệnh hiện có nào trong ứng dụng của bạn sử dụng DUAL có thể không cần thay đổi khi chuyển sang Máy chủ Percona.
Mệnh đề Oracle FROM là bắt buộc đối với mọi câu lệnh SELECT, do đó, cơ sở dữ liệu Oracle sử dụng bảng DUAL cho câu lệnh SELECT trong đó không yêu cầu tên bảng.
Trong MySQL, mệnh đề FROM là không bắt buộc nên bảng DUAL là không cần thiết. Tuy nhiên, bảng DUAL không hoạt động chính xác như bảng đối với Oracle, nhưng đối với SELECT đơn giản trong Máy chủ Percona, điều này là tốt.
Xem ví dụ sau:
Trong Oracle,
Nhưng trong MySQL:
Lưu ý: MÔ TẢ KÉP cú pháp không hoạt động trong MySQL và kết quả cũng khác với CURRENT_TIMESTAMP (sử dụng kiểu dữ liệu TIMESTAMP) trong MySQL không bao gồm múi giờ.
Hàm SYSDATE của Oracle gần như giống nhau trong MySQL.
MySQL trả về ngày và giờ và là một hàm yêu cầu () (đóng và mở ngoặc đơn không cần đối số. Để chứng minh điều này bên dưới, đây là Oracle và MySQL sử dụng SYSDATE.
Trong Oracle, sử dụng SYSDATE thuần túy chỉ trả về ngày trong ngày mà không có thời gian. Nhưng để lấy ngày giờ, hãy sử dụng TO_CHAR để chuyển đổi ngày giờ sang định dạng mong muốn; trong khi trong MySQL, bạn có thể không cần nó để lấy ngày và giờ vì nó trả về cả hai.
Xem ví dụ bên dưới.
Trong Oracle:
Nhưng trong MySQL:
Nếu bạn muốn định dạng ngày, MySQL có hàm DATE_FORMAT ().
Bạn có thể kiểm tra tài liệu Ngày và Giờ của MySQL để biết thêm thông tin.
Tương đương TO_DATE của Oracle trong MySQL là hàm STR_TO_DATE ().
Nó gần giống với kiểu trong Oracle:nó trả về kiểu dữ liệu DATE, trong khi trong MySQL, nó trả về kiểu dữ liệu DATETIME.
Oracle:
MySQL:
Trong MySQL, không có sự hỗ trợ nào như vậy cũng như không có bất kỳ sự tương đương nào cho SYNONYM trong Oracle.
Có thể có một giải pháp thay thế khả thi với MySQL là sử dụng VIEW.
Mặc dù SYNONYM có thể được sử dụng để tạo bí danh của một bảng từ xa,
ví dụ:
Trong MySQL, bạn có thể tận dụng lợi thế của việc sử dụng công cụ lưu trữ FEDERATED.
ví dụ:
Hoặc bạn có thể đơn giản hóa quy trình bằng cú pháp CREATE SERVER, để khi tạo một bảng hoạt động như SYNONYM của bạn để truy cập một bảng từ xa, nó sẽ dễ dàng hơn. Xem tài liệu để biết thêm thông tin về điều này.
Lưu ý rằng trong Percona Server / MySQL, chuỗi trống không phải là NULL trong khi Oracle xử lý chuỗi trống là giá trị null.
Trong Oracle:
Trong MySQL:
Trong MySQL, không có cách tiếp cận chính xác nào giống với những gì Oracle làm cho SEQUENCE.
Mặc dù có một số bài đăng đang mô phỏng chức năng của phương pháp này, bạn có thể thử lấy khóa tiếp theo bằng cách sử dụng LAST_INSERT_ID () miễn là chỉ mục nhóm trong bảng của bạn, PRIMARY KEY, được xác định bằng <<, có điều gì bị thiếu không?>>
Không giống như Oracle, MySQL / Percona Server có một số hàm chuỗi nhưng không có nhiều hàm hữu ích được tích hợp sẵn trong cơ sở dữ liệu.
Sẽ là quá lâu để thảo luận từng cái một ở đây, nhưng bạn có thể kiểm tra tài liệu từ MySQL và so sánh điều này với các hàm chuỗi của Oracle.
Các câu lệnh Chèn / Cập nhật / Xóa từ Oracle tương ứng với MySQL.
CHÈN TẤT CẢ / CHÈN ĐẦU TIÊN của Oracle không được hỗ trợ trong MySQL.
Nếu không, bạn cần xác định từng truy vấn MySQL của mình.
ví dụ:
Trong Oracle:
2 hàng đã được tạo.
Nhưng trong MySQL, bạn phải chạy chèn từng cái một:
INSERT ALL / INSERT FIRST không so sánh với cách nó được sử dụng trong Oracle, nơi bạn có thể tận dụng các điều kiện bằng cách thêm từ khóa WHEN trong cú pháp của mình; không có tùy chọn tương đương trong MySQL / Percona Server trong trường hợp này.
Do đó, giải pháp thay thế của bạn về vấn đề này là sử dụng các thủ tục.
Trong Oracle, việc sử dụng toán tử + cho các phép nối trái và phải hiện không được hỗ trợ trong MySQL vì toán tử + chỉ được sử dụng cho các quyết định số học.
Do đó, nếu bạn có + toán tử trong câu lệnh Oracle SQL hiện có của mình, bạn cần thay thế toán tử này bằng LEFT JOIN hoặc RIGHT JOIN.
Bạn có thể muốn kiểm tra tài liệu chính thức về "Đơn giản hóa tham gia bên ngoài" của MySQL.
Oracle sử dụng START WITH..CONNECT BY cho các truy vấn phân cấp.
Bắt đầu với MySQL / Percona 8.0, có hỗ trợ tạo kết quả dữ liệu phân cấp sử dụng các mô hình như danh sách kề hoặc các mô hình tập hợp lồng nhau. Đây được gọi là Biểu thức bảng chung (CTE) trong MySQL.
Tương tự như PostgreSQL, MySQL sử dụng WITH RECURSIVE cú pháp cho các truy vấn phân cấp nên hãy dịch CONNECT BY tuyên bố thành VỚI RECURSIVE tuyên bố.
Kiểm tra bên dưới về sự khác biệt của nó với ORACLE và trong MySQL / Percona Server.
Trong Oracle:
Và trong MySQL:
MySQL / Percona RDBMS có cách tiếp cận khác với PL / SQL của Oracle.
MySQL sử dụng các thủ tục được lưu trữ hoặc các hàm được lưu trữ, tương tự như PL / SQL và cú pháp sử dụng BEGIN..END cú pháp.
PL / SQL của Oracle được biên dịch trước khi thực thi khi nó được tải vào máy chủ, trong khi MySQL được biên dịch và lưu trữ trong bộ đệm khi nó được gọi.
Bạn có thể muốn xem tài liệu này như một hướng dẫn tham khảo về cách chuyển đổi PL / SQL của bạn sang MySQL.
Tôi đã thực hiện một số nghiên cứu về bất kỳ công cụ nào có thể là tiêu chuẩn thực tế cho việc di chuyển nhưng tôi không thể tìm thấy câu trả lời chính xác.
Mặc dù vậy, tôi đã tìm thấy các đường vuông và nó trông đơn giản nhưng đầy hứa hẹn.
Mặc dù tôi không đi sâu vào nó, nhưng trang web cung cấp một số thông tin chi tiết, có thể giúp bạn chuyển từ Oracle sang MySQL / Percona Server. Ngoài ra còn có các công cụ trả phí như cái này và cái này.
Tôi cũng đã tìm kiếm thông qua github nhưng không tìm thấy gì hấp dẫn hơn như một giải pháp cho vấn đề. Do đó, nếu bạn đang muốn di chuyển từ Oracle và sang Amazon, họ có Công cụ chuyển đổi lược đồ AWS để hỗ trợ việc di chuyển từ Oracle sang MySQL.
Nhìn chung, lý do tại sao việc di chuyển không phải là một điều dễ dàng thực hiện chủ yếu là vì Oracle RDBMS là một con quái vật với rất nhiều tính năng mà Percona Server / MySQL hoặc MariaDB RDBMS vẫn chưa có.
Nhưng dù sao, nếu bạn tìm thấy hoặc biết bất kỳ công cụ nào mà bạn thấy hữu ích và có lợi cho việc di chuyển từ Oracle sang MySQL / Percona Server, vui lòng để lại nhận xét trên blog này!
Là một phần của kế hoạch di chuyển của bạn, kiểm tra là một nhiệm vụ quan trọng có vai trò rất quan trọng và ảnh hưởng đến quyết định của bạn về việc di chuyển.
Công cụ dbdeployer (một cổng của MySQL Sandbox) là một công cụ rất hữu ích mà bạn có thể tận dụng. Điều này khá dễ dàng để bạn thử và kiểm tra các phương pháp tiếp cận khác nhau và giúp bạn tiết kiệm thời gian, thay vì thiết lập toàn bộ ngăn xếp nếu mục đích của bạn là thử và kiểm tra nền tảng RDBMS trước.
Để kiểm tra các quy trình (hàm hoặc thủ tục), trình kích hoạt, sự kiện được lưu trữ trong SQL của bạn, tôi khuyên bạn nên sử dụng các công cụ này mytap hoặc Khung kiểm tra đơn vị của Google.
Percona cũng cung cấp một số công cụ có sẵn để tải xuống trên trang web của họ. Kiểm tra Bộ công cụ Percona tại đây. Bạn có thể tự chọn các công cụ theo nhu cầu của mình, đặc biệt là cho các tác vụ kiểm tra và sử dụng sản xuất.
Nhìn chung, những điều bạn cần ghi nhớ làm nguyên tắc khi thực hiện kiểm tra Máy chủ MySQL của bạn là:; CAM KẾT; cú pháp. Bảng kép
SQL> DESC DUAL;
Name Null? Type
----------------------------------------- -------- ----------------------------
DUMMY VARCHAR2(1)
SQL> SELECT CURRENT_TIMESTAMP FROM DUAL;
CURRENT_TIMESTAMP
---------------------------------------------------------------------------
16-FEB-19 04.16.18.910331 AM +08:00
mysql> DESC DUAL;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DUAL' at line 1
mysql> SELECT CURRENT_TIMESTAMP FROM DUAL;
+---------------------+
| CURRENT_TIMESTAMP |
+---------------------+
| 2019-02-15 20:20:28 |
+---------------------+
1 row in set (0.00 sec)
SYSDATE
SQL> SELECT TO_CHAR (SYSDATE, 'MM-DD-YYYY HH24:MI:SS') "NOW" FROM DUAL;
NOW
-------------------
02-16-2019 04:39:00
SQL> SELECT SYSDATE FROM DUAL;
SYSDATE
---------
16-FEB-19
mysql> SELECT SYSDATE() FROM DUAL;
+---------------------+
| SYSDATE() |
+---------------------+
| 2019-02-15 20:37:36 |
+---------------------+
1 row in set (0.00 sec)
TO_DATE
SQL> SELECT TO_DATE ('20190218121212','yyyymmddhh24miss') as "NOW" FROM DUAL;
NOW
-------------------------
18-FEB-19
mysql> SELECT STR_TO_DATE('2019-02-18 12:12:12','%Y-%m-%d %H:%i:%s') as "NOW" FROM DUAL;
+---------------------+
| NOW |
+---------------------+
| 2019-02-18 12:12:12 |
+---------------------+
1 row in set (0.00 sec)
ĐỒNG BỘ
CREATE PUBLIC SYNONYM emp_table FOR [email protected]
CREATE TABLE hr_employees (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
INDEX name (name),
INDEX other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=utf8mb4
CONNECTION='mysql://[email protected]_host:9306/federated/test_table';
Hành vi của chuỗi rỗng và NULL
SQL> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
Nul
---
Yes
mysql> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
+-----------+
| Null Eval |
+-----------+
| No |
+-----------+
1 row in set (0.00 sec)
Chuỗi
Các hàm chuỗi ký tự
Tuyên bố DML
SQL> INSERT ALL
INTO CUSTOMERS (customer_id, customer_name, city) VALUES (1000, 'Jase Alagaban', 'Davao City')
INTO CUSTOMERS (customer_id, customer_name, city) VALUES (2000, 'Maximus Aleksandre Namuag', 'Davao City')
SELECT * FROM dual;
2 rows created.
mysql> INSERT INTO CUSTOMERS (customer_id, customer_name, city) VALUES (1000, 'Jase Alagaban', 'Davao City');
Query OK, 1 row affected (0.02 sec)
mysql> INSERT INTO CUSTOMERS (customer_id, customer_name, city) VALUES (2000, 'Maximus Aleksandre Namuag', 'Davao City');
Query OK, 1 row affected (0.00 sec)
Ký hiệu "+" kết hợp bên ngoài
BẮT ĐẦU VỚI..CONNECT BY
SELECT cp.id, cp.title, CONCAT(c2.title, ' > ' || cp.title) as path
FROM category cp INNER JOIN category c2
ON cp.parent_id = c2.id
WHERE cp.parent_id IS NOT NULL
START WITH cp.id >= 1
CONNECT BY NOCYCLE PRIOR c2.id=cp.parent_id;
WITH RECURSIVE category_path (id, title, path) AS
(
SELECT id, title, title as path
FROM category
WHERE parent_id IS NULL
UNION ALL
SELECT c.id, c.title, CONCAT(cp.path, ' > ', c.title)
FROM category_path AS cp JOIN category AS c
ON cp.id = c.parent_id
)
SELECT * FROM category_path
ORDER BY path;
PL / SQL trong MySQL / Percona?
Công cụ di chuyển
Thử nghiệm