Shutdown Oracle Database

shutdown

Về cơ bản để shutdown Oracle DB có 4 tuỳ chọn như trên. Ví dụ trong SQL Plus có thể thực hiện lệnh shutdown như sau:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

Ý nghĩa của các Option này là:

ABORT: shutdown target instance

  • Tất cả các câu lệnh SQL từ client sẽ kết thúc ngay lập tức.
  • Các Uncommitted transactions không được rolled back tới lần khởi động tiếp theo.
  • Tất cả các user bị disconnected.
  • Instance recovery sẽ được thực hiện trên db ở lần khởi động tiếp theo

IMMEDIATE: shutdown target database

  • Các câu lệnh SQL từ client sẽ được hoàn thành.
  • Uncommitted transactions được rolled back.
  • Tất cả các user bị disconnected.

NORMAL: shutdown target database, đây là cách shutdown mặc định

  • Không có chấp nhận connections mới .
  • Trước khi shuttdown, database chờ các users thoát khỏi hệ thống
  • Ở lần khởi động tiếp theo database không yêu cầu thực hiện instance recovery.

TRANSACTIONAL: shutdown target database

  • Các transactions sẽ được hoàn thành, có thể commit hoặc kết thúc trước khi shutdown.
  • Không thể khởi tạo transaction mới trên instance; các client cố tạo transaction mới sẽ bị disconnect
  • Sau khi tất cả các transactions kết thúc hoặc commit, các client sẽ bị disconnected.
Advertisements

Các thành phần trong hệ thống BI của doanh nghiệp

Hệ thống Business intelligence (kinh doanh thông minh) trong các doanh nghiệp là hệ thống giúp doanh nghiệp sử dụng thông tin một cách hữu ích cho sự vận hành và kinh doanh của tổ chức. Một hệ thống BI thường có các thành phần chính như sau:

Source ERP

Nguồn thông tin chính được sử dụng trong các hệ thống BI thường lấy từ hệ thống Enterprise Resource Planning (ERP), đây là hệ thống được sử dụng để điều khiển các hoạt động diễn ra trong một doanh nghiệp. Dựa trên các tính năng được sử dụng trong hệ thống ERP có thể lấy các thông tin về việc kinh doanh, tài chính, điều hành, nhân sự, thuế … để đưa vào hệ thống BI. Để lấy các thông tin này có thể tạo ra các API hoặc truy vấn trực tiếp trong hệ thống CSDL của ERP. Việc sử dụng API thường được sử dụng nhiều hơn vì nó sẽ không phụ thuộc vào cấu trúc các bảng trong CSDL, nhưng sẽ phải đầu tư vào vấn đề hiệu năng của hệ thống và việc trích xuất dữ liệu hàng ngày.

Databases

Hệ thống CSDL để lưu trữ dữ liệu. CSDL dùng  trong hệ thống BI gọi là Datawarehouse. Hệ thống này sẽ lấy dữ liệu từ các nguồn khác nhau và thực hiện lọc các thông tin cần thiết cho các BI tool sử dụng. Lưu ý :

  • Các tham số thiết lập trong datawarehouses khác với trong hệ thống transactional database.
  • Phải xác định khả năng sẵn sàng đáp ứng của hệ thống
  • Phải xác định khả năng tải dữ liệu và làm mới thông tin
  • Phải xây dựng hệ thống ODS (Operational Data Storage) giữa datawarehouse và transaction database làm trung gian chuyển tải dữ liệu.
  • Phải xây dựng chiến lược sao lưu dự phòng dữ liệu, căn cứ theo mức độ tải của hệ thống và sự cập nhật dữ liệu thực tế.

ETL

ETL là Extraction, Transformation, Load là quá trình trích xuất, chuyển đổi, truyền tải vào datawarehouse. Thông thường dữ liệu được trích xuất từ cơ sở dữ liệu OLTP, được chuyển đổi để phù hợp với lược đồ kho dữ liệu và được nạp vào cơ sở dữ liệu kho dữ liệu.

Front-End Tool
Front-end là thành phần cho người sử dụng tương tác với dữ liệu trong datawarehouse, là kênh truyền thông tin giữa người dùng và dữ liệu cần thiết, được yêu cầu phải thiết kế thân thiện cho người sử dụng hệ thống.

Storage Engines (Phần 3)

Tiếp tục về phần lựa chọn Storage Engines khi xây dựng hệ thống trong phần 2, phần này sẽ tìm hiểu thêm các engines khác trong MariaDB.

Khi xây dựng hệ thống cần dữ liệu có độ nén cao thì xem xét các lựa chọn sau:

  • MyRocks có độ nén cao hơn InnoDB, tốt hơn cho  flash storage  và làm tăng toàn bộ throughput.
  • TokuDB là transactional storage engine đã được tinh chỉnh cho các workloads không phù hợp với bộ nhớ, cũng hỗ trợ tỷ lệ nén tốt.
  • Archive storage engine là lựa chọn tốt nhất cho mục đích archiving.

Khi xây dựng hệ thống cần kết nối với các nguồn dữ liệu khác thì nên chọn:

  • CONNECT Storage Engines hỗ trợ việc truy xuất tới các dữ liệu dạng text files và các remote resources có sử dụng MariaDB tables.
  • CSV storage engine có thể đọc và  thêm các files dạng CSV (comma-separated-values). Từ MariaDB 10.0, CONNECT là một lựa chọn tốt hơn
  • FederatedX sử dụng libmysql để làm việc với các data source, data source trở thành remote RDBMS. Tuy nhiện hiện tại FederatedX chỉ được sử dụng khi làm việc cùng MySQL RDBMS.
  • CassandraSE là storage engine cho phép truy xuất tới version cũ của Apache Cassandra NoSQL DBMS.

Để xây dựng hệ thống có khả năng tìm kiếm tốt thì chọn

  • SphinxSE sử dụng như một proxy  để chạy các câu lệnh trên remote Sphinx database server (hiệu quả cho fulltext searches).
  • Mroonga cung cấp open-source CJK-ready full text searching sử dụng column base.

Ngoài ra còn có một số storage engines khác với tính đặc thù như Sequence engine, BLACKHOLE Storage Engine…

Storage Engines (Phần 2)

Trong quá trình làm việc, đôi khi có sự băn khoăn khi lựa chọn storage engine. Về cơ bản, Mariadb có các storage engine chung như sau:

  • XtraDB là một storage engine mặc định và rất tốt cho tới phiên bản MariaDB 10.1, có hiệu năng tốt hơn InnoDB
  • InnoDB là transaction storage engine. Đây là storage engine mặc định của MySQL, và cũng mặc định trong MariaDB 10.2. Đối với các phiên bản trước, XtraDB vẫn được sử dụng nhiều hơn
  • Aria của MariaDB là kiểu mới của MyISAM
  • MyISAM là phiên bản cũ nhất của MySQL, ít khi được sử dụng trừ khi xây dựng hệ thống có tính kế thừa.

Khi xây dựng các hệ thống có khả năng Scaling, Partitioning thì xem xét các engines sau:

  • TokuDB là transactional storage engine mà nó được optimize cho những workloads chưa phù hợp với memory, nó cung cấp compression ratio tốt.
  • Spider sử dụng cho partitioning để cung câp data sharding qua nhiều servers.
  • ColumnStore sử dụng kiến trúc phân phối dữ liệu song song lớn, được thiết kế cho  big data scaling để xử lý đến petabytes dữ liệu
  • MERGE storage engine là tập hợp các Identical MyISAM tables có thể được sử dụng như một thể thống nhất. “Identical” nghĩa là tât cả các bảng có identical column và index information.
  • Galera sử dụng khi muốn chia tải cho db trên các server khác nhau hoặc muốn thực hiện optimize cho scaling

Storage Engines (Phần 1)

Storage Engines là cơ chế lưu trữ dữ liệu trên máy tính của các hệ thống CSDL, phổ biến là MySQL và MariaDB.

Theo MariaDB, để xem storage engine thực hiện lệnh theo cú pháp:

SHOW [STORAGE] ENGINES

Lệnh này kiểm tra xem storage engine nào được hỗ trợ, engine nào là mặc định. Ngoài lệnh này có thể tìm kiếm thông tin trong bảng information_schema.ENGINES .

Thêm vào đó, một số thông tin khác có thể tìm thấy trong bảng information_schema.PLUGINS hoặc sử dụng lệnh SHOW PLUGINS .

Một số thông tin cần quan tâm là

  • Engine tên của engine
  • Support chỉ ra engine nào được cài đặt trên server, engine nào là mặc định cho session hiện tại .
  • Comment mô tả ngắn gọn
  • TransactionsXA vàSavepoints chỉ ra transactions, XA transactions và transaction savepointsare có được engine hỗ trợ không

Ví dụ:

SHOW ENGINES\G
*************************** 1. row ***************************
 Engine: InnoDB
 Support: DEFAULT
 Comment: Supports transactions, row-level locking, and foreign keys
Transactions: YES
 XA: YES
 Savepoints: YES
*************************** 2. row ***************************
 Engine: CSV
 Support: YES
 Comment: CSV storage engine
Transactions: NO
 XA: NO
 Savepoints: NO
*************************** 3. row ***************************
 Engine: MyISAM
 Support: YES
 Comment: MyISAM storage engine
Transactions: NO
 XA: NO
 Savepoints: NO
*************************** 4. row ***************************
 Engine: BLACKHOLE
 Support: YES
 Comment: /dev/null storage engine (anything you write to it disappears)
Transactions: NO
 XA: NO
 Savepoints: NO
*************************** 5. row ***************************
 Engine: FEDERATED
 Support: YES
 Comment: FederatedX pluggable storage engine
Transactions: YES
 XA: NO
 Savepoints: YES
*************************** 6. row ***************************
 Engine: MRG_MyISAM
 Support: YES
 Comment: Collection of identical MyISAM tables
Transactions: NO
 XA: NO
 Savepoints: NO
*************************** 7. row ***************************
 Engine: ARCHIVE
 Support: YES
 Comment: Archive storage engine
Transactions: NO
 XA: NO
 Savepoints: NO
*************************** 8. row ***************************
 Engine: MEMORY
 Support: YES
 Comment: Hash based, stored in memory, useful for temporary tables
Transactions: NO
 XA: NO
 Savepoints: NO
*************************** 9. row ***************************
 Engine: PERFORMANCE_SCHEMA
 Support: YES
 Comment: Performance Schema
Transactions: NO
 XA: NO
 Savepoints: NO
*************************** 10. row ***************************
 Engine: Aria
 Support: YES
 Comment: Crash-safe tables with MyISAM heritage
Transactions: NO
 XA: NO
 Savepoints: NO
10 rows in set (0.00 sec)

Giới thiệu về Data Warehouse

Việc phân tích dữ liệu từ databases cần các ứng dụng khá phức tạp. Trong các hệ thống nghiệp vụ của các tổ chức lớn có thể cần tới hàng ngàn bảng trong các hệ thống CSDL khác nhau. Do vậy để có thể thực hiện việc phân tích từ các nguồn dữ liệu này trước tiên cần có sự tổng hợp dữ liệu, cùng với việc đảm bảo chất lượng dữ liệu để việc phân tích có thể sử dụng dữ liệu đã tồn tại trong suốt một thời gian dài.

Một giải pháp phổ biến cho việc phân tích dữ liệu là  tạo ra hệ thống kho dữ liệu – data warehouse (DW). Kho dữ liệu sẽ tập trung dữ liệu từ các nguồn khác nhau, lọc để có dữ liệu tốt và lưu trữ trong thời gian dài. Hệ thống này sẽ phục vụ cho việc sinh ra nhiều báo cáo phức tạp nên chủ yếu là đọc dữ liệu chứ hiếm khi được cập nhật. Việc thiết kế các DW schemas cần đảm bảo sự đơn giản và phù hợp cho mục đích tạo ra các báo cáo chuyên môn hơn là các lược đồ của cơ sở dữ liệu quan hệ thông thường. Cách thiết kế các lược đồ cho DW gọi là Star schema, hoặc Snowflake schema. Tables trong Star hay Snowflake schema goi là các dimension tables và fact tables. Các truy vấn trên các bảng này thường đọc dữ liệu từ một số lượng dữ liệu khổng lồ, vì vậy việc thiết kế cần phải có phương pháp hợp lý.