Thiết kế Hệ thống Cơ sở Dữ liệu Oracle Phân tán
MỤC LỤC
Sự phát triển mở rộng
Các tổ chức có thể mở rộng bằng cách thêm các đơn vị mới, vừa có tính tự trị vừa có quan hệ tơng đối với các tổ chức khác. Điều đó rất khó tiên định và chịu một phí tổn lớn, mặt khác sự mở rộng này có ảnh hởng lớn không chỉ trên các ứng dụng mới mà còn trên các ứng dụng đang tồn tại.
Làm giảm tổng chi phí tìm kiếm
Khi đó CSDL phân tán hỗ trợ một sự mở rộng uyển chuyển với một mức độ ảnh hởng tối thiểu tới các đơn vị. Với CSDL tập trung, cũng có thể khởi tạo kích thớc lớn cho việc mở rộng trong tơng lai.
Độ tin cậy và khả năng sử dụng đợc nâng cao
Khả năng xử lý tự trị của các vị trí khác nhau tự nó không đảm bảo một tính tin cậy toàn bộ cao của hệ thống, nhng nó đảm bảo một thuộc tính graceful degration. Nói một cách khác, sự cố trong CSDL phân tán có thể thờng xuyên hơn một CSDL tập trung vì có số lợng thành phần lớn hơn, nhng hậu quả của sự cố đợc hạn chế chỉ tới các ứng dụng sử dụng dữ.
Hạn chế của CSDL phân tán
Có nhiều cách khác nhau để thực hiện việc phân chia này: Phân đoạn ngang, phân đoạn dọc, phân đoạn hỗn hợp sẽ đợc trình bày trong các phần sau. Fragments (các đoạn) là các phần logic của quan hệ tổng thể đợc định vị vật lý tại một hoặc nhiều vị trí trên mạng.
Thiết kế hệ thống CSDL phân tán
Khung làm việc chung cho thiết kế hệ CSDL phân tán
TOP-DOWN: Là phơng pháp thiết kế từ trên xuống và đợc chia ra làm nhiều giai đoạn, mỗi giai đoạn đều có nhiệm vụ riêng, giai đoạn này nối tiếp giai đoạn kia, đầu ra của giai đoạn trớc đợc làm đầu vào cho giai đoạn kế tiếp sau nã. Lợc đồ tổng thể mức quan niệm, mẫu truy nhập thông tin và External Schema Definition: Tập hợp kết quả của các bớc trên, sắp xếp các thực thể trên các vị trí của hệ thống phân tán và chuyển tới bớc tiếp theo.
Thiết kế CSDL phân đoạn
Tuy nhiên trong thực tế có một số hệ CSDL đã tồn tại thì nhiệm vụ của ngời thiết kế là liên kết chúng lại thành một thể thống nhât trong CSDL mới, khi đó ngời thiết kế thờng sử dụng phơng pháp BOTTOM_UP. Nh vậy thực chất của quá trình phân đoạn ngang suy diễn là thực hiện phép nửa kết nối từ kết quả của quá trình phân đoạn ngang cơ sở cùng quan hệ mà ta cần kết nối.
GIới thiệu về giao tác
Khi một giao tác bị loại bỏ, quá trình thực hiện của nó bị dừng lại và toàn bộ công việc đã làm đợc loại bỏ để đa CSDL về trạng thái trớc khi thực hiện giao tác, điều này cũng đợc hiểu nh Rollback. Tính nguyên tố của giao tác quy định hoặc là tất cả các hành động, hoặc là không một hành động nào của giao tác đợc thực hiện.
Điều khiển tơng tranh phân tán
Các thuật toán dựa trên nhãn thời gian thì ngợc lại: Các giao tác không đợi khi chúng giữ quyền truy nhập vào các mục dữ liệu, trong quá trình đó nếu xảy ra xung đột bộ lập lịch đợc khởi động lại bởi bộ quản lý giao tác với một nhãn thời gian mới. Các bộ lập lịch cập nhật các DG của mình khi một trong các điều kiện sau đợc thi hành: Một giao tác mới bắt đầu trong hệ thống, một giao tác đọc hoặc ghi nhận đợc bởi bộ lập lịch, một giao tác kết thúc hoặc một giao tác bị loại bỏ. Mỗi sao bản của bảng chính đợc gọi là một Snapshot vì thông tin có đợc tại bất kỳ thời điểm nào có thể định kỳ đợc "làm tơi ", nghĩa là làm cho các Snapshot có trạng thái tơng ứng với trạng thái mới nhất của bảng chính.
Các thao tác chính với Read-Only Snapshot
Sao bản sử dụng một danh mục sao bản thông tin, giống nh các đối tợng đ- ợc sao bản, nơi chúng đợc sao bản và cập nhật nh thế nào cần đợc truyền tới danh mục sao bản , từ đó các bảng dữ liệu có thể quay trở lại và tìm đợc. Tơng tự nh việc tạo cỏc bảng, cỏc SNAPSHOT tạo ra cú thể đợc định rừ sự lu trữ cỏc kớ tự, kích thớc Extent và sự phân phối, Tablespace hoặc Cluster chứa Snapshot, Snapshot sẽ đợc làm tơi và các yêu cầu phân tán nh thế nào. Ta không thể đa câu lệnh INSERT, UPDATE, DELETE khi sử dụng Read-Only Snapshot, nếu sử dụng sẽ có thông báo lỗi, mặc dù các câu lệnh trên vẫn đợc đa ra từ bảng cơ sở tới Snapshot, và làm thay đổi các Snapshot.
Các vấn đề cơ bản về Snapshot log
Tạo các Snapshot log
- Oracle tạo một bảng, đặt tên là MLOG$_tên_bảng_chủ, lu trữ ROWID và các hàng đợc cập nhật trong bảng chủ. - Oracle tạo một Trigger AFTER ROW trên bảng chủ thực hiện việc chèn ROWID và các thay đổi của các hàng vào trong Snapshot log chủ. Nếu tạo Snapshot log cho một bảng trong l- ợc đồ của User khác ta phải có quyền hệ thống là CREATE ANY TABLE và CREATE ANY TRIGGER.
Sửa đổi các tham biến của Snapshot log
Nếu tạo trong bảng chủ của chính mình ta cần phải có quyền CREATE TABLE và CREATE TRIGGER.
4. Xoá các Snapshot log
Quản lý Snapshot log
Oracle tự động theo dừi cỏc hàng trong Snapshot log đó đợc sử dụng trong suốt quá trình làm tơi của các Snapshot, và lọc các hàng từ log để cho log không tăng một cách vô hạn. Vì nhiều Snapshot đơn có thể sử dụng cùng một Snapshot log, các hàng sử dụng trong việc làm toi của một Snapshot vẫn có thể cần đợc làm tơi cho Snapshot khác; Oracle không xoá các hàng trong log trừ khi tất cả các Snapshot đã sử dụng xong. Đặc điểm tự động này có thể dẫn tới sự phát triển vô hạn định một Snapshot log nếu Snapshot kết hợp với nó không bao giờ đợc làm tơi.
Giới thiệu về các nhóm làm tơi Snapshot
DBMS_REFRESH chứa các thủ tục phục vụ cho việc tạo thêm thành viên mới, di chuyển, từ nhóm làm tơi, và sửa đổi tự động làm tơi định kỳ cho một nhóm làm tơi. - Thêm một thành viên mới từ nhóm làm tơi: Để thêm các Snapshot vào nhóm làm tơi, gọi thủ tục ADD trong DBMS_REFRESH. Tơng tự nh vậy ta có thể di chuyển sửa đổi và xoá các nhóm làm tơi tuần tự theo các thủ tục sau: DBMS_REFRESH.SUBTRACT, DBMS_REFRESH.CHANCE, DBMS_REFRESH.DESTROY.
Vấn đề làm tơi các Snapshot
Không có khái niệm về các vị trí chủ trong phơng pháp phân tán này, cũng nh vậy sự tồn tại của vị trí trung tâm để lu trữ toàn bộ CSDL là không cần thiết vì khi cần tổng hợp dữ liệu có thể thực hiện tại bất kỳ vị trí nào trong hệ thống mạng của ứng dụng, dữ liệu sẽ hoàn toàn đợc truyền trực tiếp. + Chọn phơng pháp phân tán Partition: Đây chính là giải pháp phù hợp cho bài toán này, các Khách Hàng sẽ đợc quản lý trực tiếp tại chi nhánh thuộc chính khu vực của Khách Hàng ( Khách Hàng ở Sài Gòn, Gia Định, Chợ Lớn, Thủ Đức sẽ do các chi nhánh tơng ứng Sài Gòn, Gia Định, Chợ Lớn, Thủ Đức quản lý), các ứng dụng khác nh tính hoá đơn cũng đợc thực hiện tơng ứng với. Số lợng các sao bản nhiều hay ít phụ thuộc vào yêu cầu và mục đích của ngời sử dụng cần tra cứu nh thế nào, cho nên tại các vị trí khác nhau có thể có nhiều các bản sao dữ liệu trùng lặp, đây cũng là nguyên nhân khiến cho phơng pháp này có dữ liệu d thừa cao nhất.
Mô hình phân tán dữ liệu tại WSC
Tơng ứng với mỗi phần dữ liệu đó sẽ có một bản sao tại trung tâm, các bản sao của các phần riêng biệt của cùng một bảng tại trung tâm sẽ đợc gộp lại thành một đối tợng duy nhất (bản sao tổng hợp của các chi nhánh) để phục vụ cho quá trình xử lý dữ liệu. Trong khi đó các bảng đợc tạo ra cha chắc đã là các đối tợng truy nhập trực tiếp của các module, mà nó phải kết hợp với các đối tợng mới, do đó các bảng có thể phải đổi tên để cho các đối tợng có thể sử dụng tên đó. - Tại CENTER tạo tất cả các snapshot cần thiết tham chiếu đến các bảng của các chi nhánh theo cách đặt tên ở trên, sau đó tạo các Views tơng ứng tổng hợp thông tin từ các Snapshot.
Phân tán dữ liệu khách hàng trong WSC
REM ACTIVITY_ASSIGN$GD REM AUDIT_TRAILS$GD REM CUSTOMERS$GD REM CUST_NOTE$GD REM DISTRICTS$GD REM STREETS$GD REM SUBAREA$GD. Tơng tự nh vậy các Script Sna_SG.sql, Sna_GD.sql, Sna_CL.sql, Sna_TD.sql sẽ tạo các Snapshot từ vị trí Center tới các chi nhánh tơng ứng. Trớc khi trình bày các Script dùng để tạo các nhóm làm tơi các Snapshot, xin giới thiệu Script: Log_cen.sql là một trong 5 Script thực hiện việc tạo các Snapshot log tại vị trí chủ.