Bài viết này giải thích cách cơ sở dữ liệu Oracle xử lý các câu lệnh DDL để tạo đối tượng, DML để sửa đổi dữ liệu và truy vấn (SELECT) để truy xuất dữ liệu.
Chương này bao gồm các chủ đề sau:
Giới thiệu về quá trình xử lý SQL
Quá trình xử lý SQL là phân tích cú pháp (parse), tối ưu hóa, tạo nguồn row và thực thi câu lệnh SQL. Tùy thuộc vào câu lệnh, cơ sở dữ liệu có thể bỏ qua một số giai đoạn này.
Hình dưới đây mô tả các giai đoạn chung của quá trình xử lý SQL.
Phân tích cú pháp SQL (Parsing)
Giai đoạn đầu tiên của quá trình xử lý SQL là phân tích cú pháp .
Giai đoạn phân tích cú pháp liên quan đến việc tách các phần của câu lệnh SQL thành cấu trúc dữ liệu mà các thủ tục khác có thể xử lý. Cơ sở dữ liệu phân tích cú pháp một câu lệnh khi được ứng dụng hướng dẫn, điều đó có nghĩa là chỉ ứng dụng chứ không phải chính cơ sở dữ liệu mới có thể giảm số lần phân tích cú pháp.
Khi một ứng dụng đưa ra một câu lệnh SQL, ứng dụng sẽ thực hiện một lệnh gọi phân tích cú pháp (parse call) tới cơ sở dữ liệu để chuẩn bị thực thi câu lệnh. Lệnh gọi phân tích cú pháp mở hoặc tạo một con trỏ (cursor), là một bộ điều khiển cho vùng SQL riêng dành riêng (private SQL area) cho phiên chứa câu lệnh SQL được phân tích cú pháp và thông tin xử lý khác. Con trỏ và vùng SQL riêng nằm trong vùng toàn cầu của chương trình (PGA).
Trong cuộc gọi phân tích cú pháp, cơ sở dữ liệu thực hiện các kiểm tra sau:
Kiểm tra cú pháp
Kiểm tra ngữ nghĩa
Kiểm tra shared pool
Các bước kiểm tra trước xác định các lỗi có thể tìm thấy trước khi thực hiện câu lệnh . Một số lỗi không thể được phát hiện bằng cách phân tích cú pháp. Ví dụ: cơ sở dữ liệu có thể gặp phải deadlock hoặc lỗi trong chuyển đổi dữ liệu chỉ trong khi thực hiện câu lệnh.
Xem thêm:
Khái niệm cơ sở dữ liệu Oracle để tìm hiểu về deaclock
Kiểm tra cú pháp
Cơ sở dữ liệu Oracle phải kiểm tra từng câu lệnh SQL để biết tính hợp lệ của cú pháp.
Một câu lệnh phá vỡ quy tắc đối với cú pháp SQL được định dạng tốt sẽ không kiểm tra được. Ví dụ: câu lệnh sau không thành công vì từ khóa FROM bị viết sai chính tả là FORM:
SQL> SELECT * FORM employees;SELECT * FORM employees*ERROR at line 1:ORA-00923: FROM keyword not found where expected
Kiểm tra ngữ nghĩa
Các ngữ nghĩa của một câu lệnh là ý nghĩa của nó. Kiểm tra ngữ nghĩa xác định xem một câu lệnh có ý nghĩa hay không, ví dụ, liệu các đối tượng và cột trong câu lệnh có tồn tại hay không.
Một câu lệnh đúng cú pháp có thể không thực hiện được kiểm tra ngữ nghĩa, như thể hiện trong ví dụ sau về truy vấn bảng không tồn tại:
SQL> SELECT * FROM nonexistent_table;SELECT * FROM nonexistent_table*ERROR at line 1:ORA-00942: table or view does not exist
Kiểm tra Shared Pool
Trong quá trình phân tích cú pháp, cơ sở dữ liệu thực hiện kiểm tra nhóm dùng chung để xác định xem nó có thể bỏ qua các bước xử lý câu lệnh sử dụng nhiều tài nguyên hay không.
Cuối cùng, cơ sở dữ liệu sử dụng thuật toán băm để tạo giá trị băm cho mọi câu lệnh SQL. Giá trị băm của câu lệnh là ID SQL được hiển thị trong V$SQL.SQL_ID. Giá trị băm này là xác định trong một phiên bản của Cơ sở dữ liệu Oracle, do đó, cùng một câu lệnh trong một phiên bản hoặc trong các phiên bản khác nhau có cùng một ID SQL.
Khi người dùng gửi một câu lệnh SQL, cơ sở dữ liệu sẽ tìm kiếm vùng SQL được chia sẻ (share SQL Area trong shared pool) để xem liệu một câu lệnh được phân tích cú pháp hiện có có cùng giá trị băm hay không. Giá trị băm của câu lệnh SQL khác với các giá trị sau:
Địa chỉ bộ nhớ cho câu lệnh
Cơ sở dữ liệu Oracle sử dụng ID SQL để thực hiện đọc có khóa trong bảng tra cứu. Theo cách này, cơ sở dữ liệu có được các địa chỉ bộ nhớ có thể có của câu lệnh.
Giá trị băm của kế hoạch thực hiện (execution plan) cho câu lệnh
Một câu lệnh SQL có thể có nhiều kế hoạch trong shared pool. Thông thường, mỗi kế hoạch có một giá trị băm khác nhau. Nếu cùng một ID SQL có nhiều giá trị băm kế hoạch thực thi, thì cơ sở dữ liệu sẽ biết rằng có nhiều kế hoạch thực thi tồn tại cho ID SQL này.
Các hoạt động phân tích cú pháp thuộc các danh mục sau, tùy thuộc vào loại câu lệnh được gửi và kết quả kiểm tra hàm băm:
Hard Parse
Nếu Cơ sở dữ liệu Oracle không thể sử dụng lại mã hiện có, thì nó phải xây dựng một phiên bản kế hoạch thực thi mới của mã ứng dụng. Thao tác này được gọi là phân tích cú pháp cứng (hard parse) hoặc bỏ lỡ bộ đệm thư viện (library cache miss)
Ghi chú:
Cơ sở dữ liệu luôn thực hiện phân tích cú pháp cứng của DDL.
Trong quá trình phân tích cú pháp cứng(Hard Parse), cơ sở dữ liệu truy cập bộ đệm thư viện (library cache) và bộ đệm từ điển dữ liệu (data dictionary cache) nhiều lần để kiểm tra từ điển dữ liệu. Khi cơ sở dữ liệu truy cập vào các khu vực này, nó sẽ sử dụng một thiết bị tuần tự hóa được gọi là chốt (latch) trên các đối tượng được yêu cầu để các thay đổi DDL không được thực hiện. Tranh chấp chốt (latch contention) làm tăng thời gian thực hiện câu lệnh và giảm tính đồng thời thực hiện câu lệnh/nghiệp vụ.
Soft parse
Phân tích cú pháp mềm (soft parse) là bất kỳ phân tích cú pháp nào không phải là phân tích cú pháp cứng. Nếu câu lệnh đã gửi giống với câu lệnh SQL có thể tái sử dụng trong nhóm dùng chung, thì Cơ sở dữ liệu Oracle sẽ sử dụng lại mã hiện có. Việc sử dụng lại mã này còn được gọi là lần truy cập vào bộ nhớ cache của thư viện (library cache hit) .
Phân tích cú pháp mềm có thể khác nhau về khối lượng công việc mà chúng thực hiện. Ví dụ: việc cấu hình vùng SQL dùng chung cho phiên đôi khi có thể giảm số lượng chốt trong phân tích cú pháp mềm, khiến chúng trở nên "mềm" hơn.
Nói chung, phân tích cú pháp mềm thích hợp hơn so với phân tích cú pháp cứng vì cơ sở dữ liệu bỏ qua các bước tạo nguồn row (row source) và tối ưu hóa, tiến thẳng đến kế hoạch thực thi.
Đồ họa sau đây là một biểu diễn đơn giản hóa kiểm tra shared pool của một câu lệnh UPDATE trong kiến trúc dedicated server.
Hình 3-2 Kiểm tra shared pool
Khi kiểm tra xác định thấy một câu lệnh trong shared pool có cùng giá trị băm, thì cơ sở dữ liệu sẽ thực hiện kiểm tra ngữ nghĩa và môi trường để xác định xem các câu lệnh có cùng ý nghĩa hay không. Cú pháp giống hệt nhau là không đủ. Ví dụ: giả sử hai người dùng khác nhau đăng nhập vào cơ sở dữ liệu và đưa ra các câu lệnh SQL sau:
CREATE TABLE my_table ( some_col INTEGER );SELECT * FROM my_table;
Các câu lệnh SELECT cho hai người dùng giống hệt nhau về mặt cú pháp, nhưng hai đối tượng lược đồ (schema) riêng biệt được đặt tên my_table. Sự khác biệt ngữ nghĩa này có nghĩa là câu lệnh thứ hai không thể sử dụng lại mã cho câu lệnh đầu tiên.
Ngay cả khi hai câu lệnh giống hệt nhau về mặt ngữ nghĩa, sự khác biệt về môi trường có thể buộc phải phân tích cú pháp khó (hard parse). Trong bối cảnh này, môi trường trình tối ưu hóa (optimizer) là toàn bộ cài đặt phiên có thể ảnh hưởng đến việc tạo kế hoạch thực hiện, chẳng hạn như kích thước vùng làm việc hoặc cài đặt trình tối ưu hóa (ví dụ: chế độ tối ưu hóa). Hãy xem xét chuỗi câu lệnh SQL sau đây được thực thi bởi một người dùng:
ALTER SESSION SET OPTIMIZER_MODE=ALL_ROWS;ALTER SYSTEM FLUSH SHARED_POOL; # optimizer environment 1SELECT * FROM sh.sales;ALTER SESSION SET OPTIMIZER_MODE=FIRST_ROWS; # optimizer environment 2SELECT * FROM sh.sales;ALTER SESSION SET SQL_TRACE=true; # optimizer environment 3SELECT * FROM sh.sales;
Trong ví dụ trước, cùng một câu lệnh SELECT được thực thi trong ba môi trường trình tối ưu hóa khác nhau. Do đó, cơ sở dữ liệu tạo ba vùng SQL được chia sẻ riêng biệt cho các câu lệnh này và buộc phân tích cú pháp cứng (hard parse) của từng câu lệnh.
Xem thêm:
Các khái niệm cơ sở dữ liệu Oracle để tìm hiểu về các vùng SQL riêng và các vùng SQL dùng chung (shared SQL area)
Hướng dẫn điều chỉnh hiệu suất cơ sở dữ liệu Oracle để tìm hiểu cấu hình nhóm dùng chung
Khái niệm cơ sở dữ liệu Oracle để tìm hiểu về chốt (latch)
Tối ưu hóa SQL
Trong giai đoạn tối ưu hóa, Cơ sở dữ liệu Oracle phải thực hiện phân tích cú pháp cứng (hard parse) ít nhất một lần cho mọi câu lệnh DML duy nhất và thực hiện tối ưu hóa trong quá trình phân tích cú pháp này.
Cơ sở dữ liệu không bao giờ tối ưu hóa DDL trừ khi nó bao gồm một thành phần DML, chẳng hạn như truy vấn con yêu cầu tối ưu hóa khi đó chúng ta phải rà soát, tối ưu DDL cho phù hợp (tạo lại kiểu partition, tạo lại index, contraint,...)
Tạo nguồn row SQL
Trình tạo nguồn row (row source) là phần mềm nhận kế hoạch thực thi tối ưu từ trình tối ưu hóa và tạo kế hoạch thực thi lặp lại mà phần còn lại của cơ sở dữ liệu có thể sử dụng được.
Kế hoạch thực thi lặp lại là một chương trình nhị phân, khi được thực thi bởi công cụ SQL, sẽ tạo ra tập kết quả. Kế hoạch có hình thức kết hợp các bước. Mỗi bước trả về một tập hợp row(row set) . Bước tiếp theo sử dụng các hàng trong tập hợp này hoặc bước cuối cùng trả lại các hàng cho ứng dụng đưa ra câu lệnh SQL.
Nguồn row (row source) là một tập hợp row được trả về bởi một bước trong kế hoạch thực thi cùng với cấu trúc điều khiển có thể xử lý lặp lại các row. Nguồn row có thể là một bảng, view hoặc kết quả của thao tác join hoặc group.
Trình tạo nguồn row tạo ra một cây nguồn row (row source tree), là một tập hợp các nguồn row. Cây nguồn hàng hiển thị các thông tin sau:
Thứ tự của các bảng được tham chiếu bởi câu lệnh
Một phương thức truy cập cho mỗi bảng được đề cập trong câu lệnh
Một phương pháp join cho các bảng bị ảnh hưởng bởi các hoạt động join trong câu lệnh
Các hoạt động dữ liệu như lọc, sắp xếp hoặc tổng hợp
Ví dụ 3-1 Kế hoạch thực thi
Ví dụ này hiển thị kế hoạch thực hiện của một câu lệnh SELECT khi AUTOTRACE được bật. Câu lệnh chọn họ, chức danh công việc và tên bộ phận cho tất cả nhân viên có họ bắt đầu bằng chữ cái A. Kế hoạch thực hiện cho câu lệnh này là đầu ra của trình tạo nguồn row.
SELECT e.last_name, j.job_title, d.department_nameFROM hr.employees e, hr.departments d, hr.jobs jWHERE e.department_id = d.department_idAND e.job_id = j.job_idAND e.last_name LIKE 'A%';Execution Plan----------------------------------------------------------Plan hash value: 975837011--------------------------------------------------------------------------------| Id| Operation | Name |Rows|Bytes|Cost(%CPU)|Time |--------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 3 | 189 | 7(15)| 00:00:01 ||*1 | HASH JOIN | | 3 | 189 | 7(15)| 00:00:01 ||*2 | HASH JOIN | | 3 | 141 | 5(20)| 00:00:01 || 3 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 3 | 60 | 2 (0)| 00:00:01 ||*4 | INDEX RANGE SCAN | EMP_NAME_IX | 3 | | 1 (0)| 00:00:01 || 5 | TABLE ACCESS FULL | JOBS | 19 | 513 | 2 (0)| 00:00:01 || 6 | TABLE ACCESS FULL | DEPARTMENTS | 27 | 432 | 2 (0)| 00:00:01 |--------------------------------------------------------------------------------Predicate Information (identified by operation id):---------------------------------------------------1 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")2 - access("E"."JOB_ID"="J"."JOB_ID")4 - access("E"."LAST_NAME" LIKE 'A%')filter("E"."LAST_NAME" LIKE 'A%')
Thực thi SQL
Trong quá trình thực thi, công cụ SQL thực thi từng nguồn row trong cây do trình tạo nguồn row tạo ra. Bước này là bước bắt buộc duy nhất trong quá trình xử lý DML.
Hình 3-3 là một cây thực thi (execution tree) , còn được gọi là cây phân tích cú pháp (parse tree), thể hiện luồng các nguồn row từ bước này sang bước khác trong kế hoạch thực thi trong Ví dụ 3-1 . Nói chung, thứ tự các bước thực hiện ngược lại với thứ tự trong bản kế hoạch thực thi, vì vậy bạn đọc bản kế hoạch từ dưới lên.
Mỗi bước trong một kế hoạch thực hiện có một số ID. Các số trong Hình 3-3 tương ứng với cột Id trong sơ đồ được minh họa trong Ví dụ 3-1. Khoảng trống ban đầu trong cột Operation của kế hoạch biểu thị mối quan hệ thứ bậc. Ví dụ: nếu tên của một thao tác được đặt trước bởi hai khoảng trắng, thì thao tác này là con của một thao tác được đặt trước một khoảng trắng. Các hoạt động trước một khoảng trắng là con của chính câu lệnh SELECT.
Hình 3-3 Cây nguồn row
Trong Hình 3-3 , mỗi nút của cây hoạt động như một nguồn row, có nghĩa là mỗi bước của kế hoạch thực hiện trong Ví dụ 3-1 sẽ truy xuất các row từ cơ sở dữ liệu hoặc chấp nhận các row từ một hoặc nhiều nguồn row làm đầu vào. Công cụ SQL thực thi từng nguồn row như sau:
Các bước được chỉ định bởi các hộp đen truy xuất dữ liệu từ một đối tượng trong cơ sở dữ liệu. Các bước này là đường dẫn truy cập (access path) hoặc kỹ thuật truy xuất dữ liệu từ cơ sở dữ liệu.
Bước 6 sử dụng quét toàn bộ bảng để truy xuất tất cả các row từ bảng
departments.Bước 5 sử dụng quét toàn bộ bảng để truy xuất tất cả các row từ bảng
jobs.Bước 4 quét chỉ mục
emp_name_ixtheo thứ tự, tìm kiếm từng khóa bắt đầu bằng chữ cáiAvà truy xuất rowid tương ứng. Ví dụ: rowid tương ứng vớiAtkinsonlàAAAPzRAAFAAAABSAAe.Bước 3 truy xuất từ bảng
employeescác row có rowid được trả về ở Bước 4. Ví dụ: cơ sở dữ liệu sử dụng rowidAAAPzRAAFAAAABSAAeđể truy xuất row choAtkinson.
Các bước được chỉ định bởi các hộp rõ ràng hoạt động trên các nguồn row.
Bước 2 thực hiện hash join, chấp nhận các nguồn row từ Bước 3 và 5, join từng row từ nguồn row của Bước 5 với row tương ứng của nó trong Bước 3 và trả lại các row kết quả cho Bước 1.
Ví dụ: row dành cho nhân viên
Atkinsonđược liên kết với tên công việcStock Clerk.Bước 1 thực hiện một phép hash join khác, chấp nhận các nguồn row từ Bước 2 và 6, nối từng hàng từ nguồn Bước 6 với hàng tương ứng của nó trong Bước 2 và trả lại kết quả cho máy khách.
Ví dụ: hàng dành cho nhân viên
Atkinsonđược liên kết với bộ phận có tênShipping.
Trong một số kế hoạch thực hiện, các bước được lặp đi lặp lại và trong các kế hoạch khác là tuần tự. Phép hash join được hiển thị trong Ví dụ 3-1 là join tuần tự. Cơ sở dữ liệu hoàn thành toàn bộ các bước dựa trên thứ tự join Cơ sở dữ liệu bắt đầu với quá trình quét dải (index range scan) chỉ mục của emp_name_ix. Bằng cách sử dụng các row mà nó truy xuất từ chỉ mục, cơ sở dữ liệu sẽ đọc các row phù hợp trong bảng employees, sau đó quét bảng jobs. Sau khi lấy các row từ bảng jobs, cơ sở dữ liệu thực hiện phép hash join.
Trong quá trình thực hiện, cơ sở dữ liệu đọc dữ liệu từ đĩa vào bộ nhớ nếu dữ liệu không có trong bộ nhớ. Cơ sở dữ liệu cũng loại bỏ mọi khóa (lock) và chốt (latch) cần thiết để đảm bảo tính toàn vẹn của dữ liệu và ghi lại mọi thay đổi được thực hiện trong quá trình thực thi SQL. Giai đoạn cuối cùng của quá trình xử lý câu lệnh SQL là đóng con trỏ.
Cơ sở dữ liệu Oracle xử lý DML như thế nào
Hầu hết các câu lệnh DML đều có thành phần truy vấn. Trong một truy vấn, việc thực hiện một con trỏ sẽ đặt các kết quả của truy vấn vào một tập hợp các row được gọi là tập hợp kết quả (result set) .
Các tập hợp row được tìm nạp như thế nào
Các row của tập kết quả có thể được tìm nạp từng row hoặc theo nhóm.
Trong giai đoạn tìm nạp (fetch), cơ sở dữ liệu chọn các hàng và, nếu truy vấn yêu cầu, sắp xếp các row . Mỗi lần tìm nạp liên tiếp sẽ truy xuất một row khác của kết quả cho đến khi row cuối cùng được tìm nạp.
Nói chung, cơ sở dữ liệu không thể xác định chắc chắn số row sẽ được truy xuất bởi một truy vấn cho đến khi row cuối cùng được tìm nạp. Cơ sở dữ liệu Oracle truy xuất dữ liệu để đáp ứng các lời gọi tìm nạp, do đó cơ sở dữ liệu đọc càng nhiều row thì càng thực hiện nhiều công việc hơn. Đối với một số truy vấn, cơ sở dữ liệu trả về row đầu tiên càng nhanh càng tốt, trong khi đối với những truy vấn khác, cơ sở dữ liệu tạo toàn bộ tập kết quả trước khi trả về hàng đầu tiên.
Đọc nhất quán
Nói chung, một truy vấn truy xuất dữ liệu bằng cách sử dụng cơ chế nhất quán đọc Cơ sở dữ liệu Oracle, cơ chế này đảm bảo rằng tất cả các khối (block) dữ liệu được đọc bởi một truy vấn nhất quán tại một thời điểm duy nhất.
Tính nhất quán khi đọc sử dụng dữ liệu undo để hiển thị các phiên bản trước đây của dữ liệu. Ví dụ, giả sử một truy vấn phải đọc 100 khối dữ liệu trong một lần quét toàn bộ bảng. Truy vấn xử lý 10 khối đầu tiên trong khi DML trong một phiên khác sửa đổi khối 75. Khi phiên đầu tiên đạt đến khối 75, truy vấn nhận ra thay đổi và sử dụng dữ liệu undo để truy xuất phiên bản cũ, chưa sửa đổi của dữ liệu và xây dựng phiên bản khối không hiện hành 75 trong bộ nhớ.
Xem thêm:
Các khái niệm cơ sở dữ liệu Oracle để tìm hiểu về tính nhất quán đọc nhiều phiên bản dữ liệu
Thay đổi dữ liệu
Các câu lệnh DML phải thay đổi dữ liệu sử dụng tính nhất quán đọc để chỉ truy xuất dữ liệu phù hợp với tiêu chí tìm kiếm khi bắt đầu sửa đổi.
Sau đó, các câu lệnh này truy xuất các khối dữ liệu khi chúng tồn tại ở trạng thái hiện tại và thực hiện các sửa đổi cần thiết. Cơ sở dữ liệu phải thực hiện các hành động khác liên quan đến việc sửa đổi dữ liệu, chẳng hạn như tạo dữ liệu làm lại (redo) và hoàn tác (undo).
Cơ sở dữ liệu Oracle xử lý DDL như thế nào
Cơ sở dữ liệu Oracle xử lý DDL khác với DML.
Ví dụ: khi bạn tạo bảng, cơ sở dữ liệu không tối ưu hóa câu lệnh CREATE TABLE. Thay vào đó, Cơ sở dữ liệu Oracle phân tích câu lệnh DDL và thực hiện lệnh.
Cơ sở dữ liệu xử lý DDL khác vì nó là phương tiện xác định một đối tượng trong từ điển dữ liệu. Thông thường, Cơ sở dữ liệu Oracle phải phân tích cú pháp và thực thi nhiều câu lệnh SQL đệ quy để thực thi một câu lệnh DDL. Giả sử bạn tạo một bảng như sau:
CREATE TABLE mytable (mycolumn INTEGER);
Thông thường, cơ sở dữ liệu sẽ chạy hàng chục câu lệnh đệ quy để thực thi câu lệnh trước đó. SQL đệ quy sẽ thực hiện các hành động như sau:
Đưa ra câu lệnh
COMMIT (gọi là implicit commit - commit ngầm đình)trước khi thực hiện câu lệnhCREATE TABLEXác minh rằng người dùng có quyền tạo bảng
Xác định tablespace mà bảng sẽ nằm trong đó.
Đảm bảo rằng hạn ngạch (quota) tablespace không bị vượt quá
Đảm bảo rằng không có đối tượng nào 1 lược đồ (schema) có cùng tên
Chèn (insert) các hàng (row) xác định bảng vào từ điển dữ liệu (data dictionary)
Phát hành
COMMITnếu câu lệnh DDL thành công hoặcROLLBACKnếu không thành công.
Xem thêm:
Hướng dẫn phát triển cơ sở dữ liệu Oracle để tìm hiểu về xử lý DDL, kiểm soát giao dịch và các loại câu lệnh khác
* KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE trực tiếp từ tôi giúp bạn bước đầu trở thành những chuyên gia DBA, đủ kinh nghiệm đi thi chứng chỉ OA/OCP, đặc biệt là rất nhiều kinh nghiệm, bí kíp thực chiến trên các hệ thống Core tại VN chỉ sau 1 khoá học.
* CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
* Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: http://bit.ly/ytb_binhoraclemaster
👨 Tiktok: https://www.tiktok.com/@binhoraclemaster?lang=vi
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhoracle
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty
