KIẾN TRÚC CƠ SỞ DỮ LIỆU SQL SERVER
CHƯƠNG 1. TỔNG QUAN:SQL Server là hệ quản trị cơ sở dữ liệu quan hệ của Microsoft, có kiến trúc phân lớp rõ ràng, có sự tách biệt trách nhiệm xử lý giao thức, xử lý logic truy vấn và lưu trữ vật lý. Toàn bộ các lớp này vận hành trên nền hệ điều hành ảo hóa nội bộ gọi là SQLOS, cho phép SQL Server tự kiểm soát toàn bộ tài nguyên thay vì phụ thuộc hoàn toàn vào bộ lập lịch của Windows.
Luồng xử lý tổng quát của một câu truy vấn:
- Client Application --> Protocol Layer (SNI) --> Relational Engine --> Storage Engine --> Physical Files (.mdf / .ndf / .ldf)
Hình 1. Sơ đồ tổng quan kiến trúc SQL Server: Protocol Layer, Relational Engine và Storage Engine
Hình 2. Bật/tắt các giao thức kết nối trong SQL Server Configuration Manager
Thực hiện các nhiệm vụ: tiếp nhận yêu cầu kết nối, quản lý kết nối, tối ưu hóa đường truyền dữ liệu, xử lý các giao thức kết nối khác nhau, đóng gói dữ liệu trao đổi theo giao thức TDS
Các giao thức kết nối SQL Server hỗ trợ: có thể linh động bật cả 3 phương thức cùng lúc
- Shared Memory: client - SQL Server chạy cùng một máy, giao tiếp với nhau bằng shared memory protocol
- TCP/IP: client - SQL Server tương tác với nhau ở mạng LAN, WAN, Internet
- Named Pipes: client - SQL Server giao tiếp với nhau thông qua mạng cục bộ (LAN)
2.2. Relational Engine: Bộ xử lý truy vấn
Hình 3. Query Executor nhận dữ liệu từ Access Methods và trả kết quả qua Protocol Layer
Nó thực hiện các truy vấn của người dùng bằng cách yêu cầu dữ liệu từ Storage enging và xử lý các kết quả trả về. Lớp này gồm 3 thành phần chính:
- CMD Parser: có nhiệm vụ kiểm tra câu query có đúng ngữ nghĩa và cú pháp không. Kết quả tạo ra Query Tree (biểu diễn cấu trúc logic của truy vấn Sql dưới dạng tree)
- Optimizer: dùng các thuật toán (exhaustive and heuristic algorithms) để tối ưu tốc độ truy vấn và tạo chiến lược thực thi (scan bảng, index usage, join,...) mục tiêu là tạo ra một Query Plan tiết kiệm chi phí nhất chứ không phải tốt nhất.
- Query Executor: thực thi các bước Query Plan và lấy kết quả truy vấn, nhận dữ liệu từ Storage Engine và trả ra Protocol Layer
Đây là nơi lưu trữ dữ liệu, nơi Query Executor sẽ lấy dữ liệu kết quả và trả về cho người dùng. Nếu mà ở đây không có dữ liệu, nó sẽ truy xuất xuống phân vùng ổ đĩa vật lý để đưa lên.
2.3.1. Cấu trúc file vật lý:
Gồm 2 loại data file và 1 log file:
- Primary file (.mdf): file bắt buộc, duy nhất, do hệ thống tạo ra, chứa metadata nội bộ và có thể chứa dữ liệu người dùng
- Secondary file (.ndf): file tùy chọn do người dùng tạo, được nhóm vào các FileGroup
- Transaction log (.ldf): ghi nhận mọi thay đổi dữ liệu trước khi thay đổi được áp dụng. Là nền tảng cho khả năng khôi phục dữ liệu sau sự cố.
Đóng vai trò điều phối giữa Query Executor và hai thành phần Buffer Manager/Transaction Manager dựa trên loại câu lệnh:
- Truy vấn đọc dữ liệu (Select Statement): truy vấn sẽ được chuyển đến Buffer Manager nếu dữ liệu đã có trong bộ nhớ thì trả kết quả ngay; nếu chưa có thì nạp trang dữ liệu tương ứng từ .mdf/.ndf lên Data cache rồi mới trả kết quả
- Truy vấn ghi dữ liệu (Non-select Statement như INSERT/UPDATE/DELETE): chuyển đến Transaction Manager trước tiên để ghi thông tin thay đổi vào Transaction Log --> sau đó chuyển sang Buffer Manager để nạp dữ liệu gốc lên Data Cache nếu chưa có, thực hiện sửa đổi, đánh dấu trang nhớ thành Dirty Page --> định kỳ được Lazy Writer/Checkpoint ghi xuống đĩa vật lý
Plan Cache: lưu trữ các execution plan của một truy vấn đã được tối ưu hóa để sử dụng lại cho các truy vấn tương tự
Data Cache: phần dữ liệu thực tế đang được xử lý trong Buffer Pool.
Dirty Page: trang dữ liệu trong bộ nhớ đã bị sửa nhưng chưa ghi xuống đĩa.
Buffer Pool: vùng Ram lớn nhất của SQL Server, cache các data page để giảm I/O đĩa
2.3.4. Transaction manager: ghi lại tất cả những thay đổi dữ liệu để hỗ trợ cho việc khôi phục dữ liệu sau này.
Lock Manager: quản lý khóa ở nhiều cấp độ (row, page, table) và nhiều chế độ để tránh xung đột đọc/ghi đồng thời
Checkpoint và Lazy Writers: hai tiến trình nền chịu trách nhiệm ghi Dirty Page xuống đĩa. Checkpoint chạy định kỳ để đồng bộ điểm khôi phục, Lazy Writer chạy khi hệ thống cần giải phóng bộ nhớ
Write-Ahead Logging: đảm bảo mọi thay đổi được ghi vào Transaction Log trước khi áp dụng vào data file.
CHƯƠNG 3. KIẾN TRÚC LOGIC CỦA SQL SERVER
Hình 4. Kiến trúc logic: Server chứa Database, Database chứa Schema, Schema chứa các object
Database: là đơn vị lưu trữ độc lập có thể attach/detach độc lập
Schema: namespace logic bên trong database, mặc định là dbo, dùng để nhóm object và cấp quyền theo nhóm thay vì từng object.
Table: lưu trữ dữ liệu thật, tổ chức theo dòng/ cột
View: bảng ảo, chỉ lưu câu lệnh SELECT, không lưu dữ liệu. Dữ liệu lấy real-time từ Table gốc mỗi khi truy vấn
Stored Procedure, Function: các khối T-SQL được lập trình sẵn.
Index: cấu trúc tăng tốc truy vấn, gắn phụ thuộc vào một Table/View cụ thể, không phải object độc lập ngang hàng.
Synonym: alias trỏ tới object khác cùng database, khác database, hoặc khác server qua Linked Server.
Mỗi database tương ứng với một bộ file vật lý gồm .mdf bắt buộc, có thể có nhiều .ndf, và .ldf, có metadata riêng.
CHƯƠNG 4. CÁC DỊCH VỤ CƠ BẢN:
SQL Server bao gồm hệ thống các dịch vụ cốt lõi, mỗi dịch vụ đảm nhận một nhiệm vụ cụ thể, nhằm mục đích hỗ trợ toàn diện cho việc phân tích và lưu trữ dữ liệu:
- Database Engine (động cơ cơ sở dữ liệu): Dùng để lưu trữ dữ liệu dưới dạng bảng và hỗ trợ các thao tác tự động điều chỉnh
- Integration Services (dịch vụ tổng hợp): Các công cụ đồ họa và đối tượng lập trình thực hiện sao chép, di chuyển, và chuyển đổi dữ liệu
- Analysis Services (dịch vụ phân tích): Cung cấp các dịch vụ phân tích dữ liệu sử dụng các kỹ thuật khai thác hình khối đa chiều và dữ liệu
- Reporting Services (dịch vụ báo cáo): Công cụ tạo, quản lý, và triển khai các báo cáo cho cả máy chủ và máy khách
- Full Text Search Service (dịch vụ tìm kiếm trên toàn văn bản): Chức năng truy vấn và đánh giá các chỉ mục dữ liệu văn bản
- Service Broker (môi trường dịch vụ): Môi trường lập trình tạo ra các ứng dụng sử dụng các dịch vụ
KIẾN TRÚC HỆ THỐNG ORACLE
CHƯƠNG 1. TỔNG QUAN: 1.1. Instance và Database:
1.1.1. Các thực thể cấu thành hệ thống:
Một hệ thống Oracle luôn gồm hai thực thể tách rời nhau về bản chất, dù giao tiếp hằng ngày người ta thường gọi gộp là “database”
Hình 5. Instance (Memory + Process) và Database (các file vật lý trên Storage)
Database: gồm các file vật lý trên Storage, chứa dữ liệu và metadata, nằm trên đĩa và vẫn còn khi hệ thống tắt.
Dữ liệu dưới dạng Storage chỉ là chuỗi bit nhị phân, tự nó không diễn giải được thành các thông tin. Instance chính là lớp làm nhiệm vụ diễn giải đó.
Database tồn tại được mà không cần Instance, nhưng lúc đó không truy vấn được. Instance cũng khởi động được mà chưa gắn database nào. Hệ thống chỉ phục vụ được người dùng khi cả hai kết nối với nhau
1.1.2. Các mô hình gắn kết Instance với Database
Quan hệ giữa hai thực thể này không cố định mà thay đổi theo mô hình triển khai:
- Single Instance: Một Instance phục vụ đúng một Database (mô hình cơ bản nhất)
- RAC (cụm nhiều node): Nhiều Instance trên nhiều máy chủ cùng gắn vào một database duy nhất đặt trên shared storage.
- Multitenant (từ 12c): Một Instance gắn với một Container Database; bên trong chứa nhiều Pluggable Database độc lập về dữ liệu.
2.1. Kiến trúc Memory
2.1.1. Program Global Area (PGA): vùng nhớ riêng
Là vùng nhớ private, cấp cho đúng một Oracle process, không chia sẻ với process khác, giải phóng khi process kết thúc.
Hình 6. PGA là vùng nhớ riêng của từng Server Process / Background Process
- Private SQL Area: dữ liệu riêng của câu lệnh đang chạy trong phiên, tiêu biểu là giá trị các bind variable
- Cursor và SQL Area: thông tin về các con trỏ đang mở để duyệt tập kết quả.
- Session Memory: biến phiên, thông tin đăng nhập, trạng thái phiên làm việc.
- Work Area: không gian cho thao tác nặng như sắp xếp (ORDER BY, GROUP BY), băm (hash join), tạo bitmap.
2.1.2. SGA (vùng nhớ chung):
Là vùng nhớ shared của Instance, mọi Server Process và Background Process đều truy cập được do đó dữ liệu một phiên nạp lên, phiên khác dùng lại được, từ đó giảm số lần phải đọc đĩa.
Hình 7. Cấu trúc SGA: Database Buffer Cache, Redo Log Buffer, Shared Pool, Large Pool, Java Pool, Streams Pool
Cần truy xuất dữ liệu sẽ kiểm tra Buffer Cache, data block đã có, lấy trực tiếp từ Memory và trả kết quả.
Nếu data block chưa có sẽ đọc từ Datafile trên Disk, sau đó nạp vào Buffer Cache, tiến hành xử lý và trả kết quả, từ đó lần sau sẽ lấy được ngay từ Memory
Mỗi buffer trong vùng nhớ này nằm ở một trong bốn trạng thái và trạng thái đó quyết định buffer có được phép tái sử dụng hay không:
- Free: chưa chứa dữ liệu, sẵn sàng nhận block mới
- Clean: nội dung giống hệt bản trên đĩa, có thể ghi đè bất cứ lúc nào
- Dirty: đã bị sửa trên Memory nhưng chưa ghi xuống đĩa, bắt buộc DBWn ghi xuống trước khi tái sử dụng.
- Pinned: Đang có tiến trình sử dụng, không được phép thay thế.
2.1.2.2. Shared Pool
SQL gửi đến sẽ được Shared Pool tiếp nhận sau đó Library Cache kiểm tra câu lệnh đã tồn tại chưa, nếu tái sử dụng được thì dùng lại Execution Plan có sẵn.
Nếu chưa tồn tại phân tích cú pháp, kiểm tra object và quyền truy cập qua Data Dictionary Cache, tính ra Execution Plan tối ưu lưu cả câu lệnh và Plan vào Library Cache lần sau tái sử dụng
Hai khoang bên trong Shared Pool đảm nhiệm hai loại thông tin khác nhau:
- Library Cache: lưu văn bản câu lệnh và Execution Plan tương ứng. Tổ chức theo cặp Parent Cursor (giữ văn bản câu lệnh) và Child Cursor (giữ Plan cùng môi trường biên dịch), một câu lệnh có thể sinh nhiều Child Cursor khi chạy trong các môi trường khác nhau.
- Data Dictionary Cache: lưu metadata (định nghĩa bảng, cột, kiểu dữ liệu, quyền của user). Gần như câu lệnh nào cũng phải tra cứu tới nên việc cache lại là bắt buộc để tránh đọc đĩa liên tục.
Khi thực hiện INSERT/UPDATE/DELETE Oracle sẽ tạo Redo Information mô tả thay đổi lưu tạm vào Redo Log Buffer LGWR ghi xuống Online Redo Log File phục vụ Recovery khi cần.
Vùng nhớ này có dung lượng nhỏ hơn hẳn các vùng khác, vì nội dung liên tục được LGWR đẩy xuống đĩa nên không bao giờ tồn đọng lâu.
2.1.2.4. Large Pool
Oracle thực hiện tác vụ cần cấp phát bộ nhớ theo khối lớn dùng Large Pool thay vì Shared Pool để tránh làm phân mảnh Shared Pool phục vụ RMAN Backup/Restore, Parallel Execution, Shared Server
2.1.2.5. Java Pool và Streams Pool
Java Pool: cấp bộ nhớ cho Java stored procedure và JVM chạy bên trong Oracle.
Streams Pool: cấp bộ nhớ cho các hoạt động streaming và replication dữ liệu.
2.2. Kiến trúc Process
2.2.1. Các loại Process
User Process do người dùng hoặc ứng dụng tạo ra để gửi yêu cầu kết nối và câu lệnh SQL, nằm phía Client, không thuộc Instance, không chạm trực tiếp vào dữ liệu
User Process kết nối tới Instance sau đó Oracle tạo hoặc gán một Server Process. Server Process dùng PGA riêng, đồng thời truy cập SGA dùng chung thực thi câu lệnh và trả kết quả về User Process
Background Process chạy nền liên tục từ lúc Instance khởi động không gắn với phiên làm việc nào, đảm nhiệm ghi dữ liệu, ghi redo, recovery, giám sát giữ cho Instance hoạt động ổn định
2.2.2. Các Background Process quan trọng
2.2.2.1. Database Writer (DBWn)
Buffer Cache chứa data block đã đọc từ Datafile, block bị thay đổi trở thành dirty block sau đó DBWn ghi dirty block từ Buffer Cache xuống Datafile làm cho dữ liệu trên Memory và trên Disk đồng bộ với nhau
DBWn không ghi liên tục mà chỉ được kích hoạt khi có điều kiện phù hợp:
- Số lượng dirty block trong Buffer Cache tích lũy quá nhiều.
- Cần giải phóng buffer để nạp block mới nhưng không còn buffer trống.
- Xảy ra Checkpoint (CKPT ra tín hiệu cho DBWn ghi các dirty block liên quan).
- Hết thời gian chờ định kỳ.
DML làm thay đổi dữ liệu, Oracle tạo Redo Information sau đó lưu vào Redo Log Buffer để LGWR ghi xuống Online Redo Log File.
Transaction thực hiện Commit sau đó LGWR ghi Redo liên quan xuống đĩa, Redo đã an toàn thì Oracle mới xác nhận Commit thành công cho người dùng.
Ngoài thời điểm Commit, LGWR còn được kích hoạt khi Redo Log Buffer đạt khoảng một phần ba dung lượng, theo chu kỳ thời gian, và bắt buộc phải ghi trước khi DBWn được phép ghi dirty block tương ứng.
Online Redo Log hiện tại đầy xảy ra Log Switch, Oracle chuyển sang Redo Log Group kế tiếp. LGWR tiếp tục ghi vào group mới.
Nguyên tắc quan trọng: LGWR luôn ghi Redo xuống đĩa trước khi DBWn được phép ghi dirty block tương ứng xuống Datafile đây chính là cơ chế Write-Ahead Logging.
2.2.2.3. Checkpoint (CKPT)
Checkpoint xảy ra, CKPT ghi Checkpoint SCN vào Control File và Datafile Header đồng thời báo DBWn ghi các dirty block cần thiết xuống Datafile tạo ra một mốc đồng bộ
Khi Instance khởi động lại sau sự cố, Oracle chỉ cần xử lý lượng Redo phát sinh kể từ Checkpoint gần nhất chứ không phải toàn bộ lịch sử.
Checkpoint càng dày thì phục hồi càng nhanh nhưng tốn I/O lúc vận hành; Checkpoint càng thưa thì ngược lại.
2.2.2.4. Process Monitor (PMON)
Server Process hoặc kết nối bị ngắt bất thường PMON phát hiện sẽ tiến hành rollback giao dịch dang dở, giải phóng khóa và tài nguyên phiên đó chiếm giữ. Instance tiếp tục hoạt động bình thường
Ngoài chức năng dọn dẹp, PMON còn tham gia đăng ký thông tin Instance với Listener trong cơ chế Dynamic Service Registration
2.2.2.5. System Monitor (SMON)
Instance shutdown bất thường, database khởi động lại sau đó SMON thực hiện Instance Recovery dùng Redo Roll Forward khôi phục mọi thay đổi, dùng Undo Roll Back các giao dịch chưa commit đưa Database trở về trạng thái nhất quán
Hai giai đoạn này bổ sung cho nhau: Roll Forward dựng lại tất cả những gì đã xảy ra, kể cả giao dịch dở dang; Roll Back sau đó loại bỏ phần chưa được xác nhận. Ngoài Instance Recovery, SMON còn dọn dẹp temporary segment không còn dùng và gộp các vùng trống liền kề trong tablespace
Tóm gọn: Instance Failure --> Database Startup --> SMON --> Roll Forward rồi Roll Back --> Database nhất quán trở lại
2.2.2.6. Archiver (ARCn)
LGWR ghi Redo lần lượt vào các Online Redo Log Group nếu group hiện tại đầy xảy ra Log Switch chuyển sang group kế tiếp
Nếu Database ở ARCHIVELOG mode, group cũ cần được lưu lại trước khi bị ghi đè. ARCn đọc Online Redo Log sau đó sao chép sang Archived Redo, Log group cũ được giải phóng để tái sử dụng
VD: Group 1 đầy --> Log Switch --> chuyển sang Group 2 --> ARCn archive Group 1 --> Group 1 được đánh dấu có thể tái sử dụng sau khi đáp ứng điều kiện cần thiết. Tương tự, Group 2 đầy --> Log Switch --> chuyển sang Group 3 --> ARCn archive Group 2 --> quá trình tiếp tục luân phiên.
2.2.2.7. Manageability Monitor (MMON)
Database hoạt động, MMON thu thập performance metrics và số liệu thống kê, ghi nhận lại để hỗ trợ AWR và các cơ chế theo dõi hiệu năng
2.3. Kiến trúc Storage
2.3.1. Cấu trúc lưu trữ logic
Hình 8. Quan hệ giữa Data Block, Extent, Segment và Datafile
Extent là nhóm Data Block liên tiếp được cấp phát cùng lúc. Khi một Segment cần thêm chỗ, Oracle cấp nguyên một Extent thay vì từng block lẻ, nhờ đó giảm được chi phí quản lý.
Segment là tập hợp các Extent thuộc về một object cụ thể, đại diện cho toàn bộ không gian mà object đó đang chiếm dụng.
Tablespace gom nhiều Segment lại và ánh xạ xuống một hoặc nhiều Datafile. Đây cũng chính là đơn vị mà quản trị viên thao tác mỗi khi cần mở rộng không gian lưu trữ.
Tóm gọn: đi từ logic xuống vật lý, thứ tự là Tablespace, rồi Segment, rồi Extent, cuối cùng là Data Block.
2.3.1.1. Các loại Segment
- Data Segment: dữ liệu của bảng.
- Index Segment: dữ liệu của chỉ mục.
- Undo Segment: ảnh dữ liệu trước khi thay đổi, phục vụ rollback.
- Temporary Segment: kết quả trung gian khi sắp xếp tràn khỏi Work Area của PGA.
- SYSTEM: chứa Data Dictionary, tức metadata của toàn database. Đây là tablespace bắt buộc phải có.
- SYSAUX: chứa dữ liệu phụ trợ của các component như AWR, qua đó giảm tải cho SYSTEM.
- UNDO: chứa Undo Segment.
- TEMP: chứa Temporary Segment.
- USERS: lưu dữ liệu người dùng, là tablespace mặc định khi tạo object mới.
2.3.2. Các loại file trong Oracle Database
Hình 9. Các loại file vật lý cấu thành Oracle Database
Parameter File lưu các tham số cấu hình của Instance như kích thước vùng nhớ, số process tối đa hay vị trí Control File. Vì vậy mỗi lần Instance khởi động, việc đầu tiên là đọc file này để biết cách tự khởi tạo.
Tóm gọn: Parameter File cung cấp thông tin cấu hình, và từ đó Instance mới được khởi tạo.
2.3.2.2. Password File
Password File lưu thông tin xác thực dành cho administrative user, phục vụ các kết nối với quyền SYSDBA hoặc SYSOPER.
Lý do file này phải nằm tách biệt nằm ở chỗ: khi Database chưa OPEN thì không thể xác thực dựa trên chính Database được. Trong khi đó, đây lại đúng là lúc quản trị viên cần đăng nhập để startup, mount hoặc open hệ thống. Password File chính là cơ chế xác thực nằm ngoài Database để giải quyết tình huống này.
2.3.2.3. Control File
Control File chứa metadata quản lý Database gồm tên Database, DBID, đường dẫn tới các Datafile và Redo Log File cùng thông tin Checkpoint. Có thể xem đây là tấm bản đồ của cả hệ thống.
Trình tự khi khởi động cũng cho thấy vai trò của nó: Instance đọc Parameter File trước để biết Control File nằm ở đâu, sau đó đọc Control File và nhờ vậy nắm được toàn bộ cấu trúc vật lý của Database
2.3.2.4. Datafile
Datafile là file vật lý lưu dữ liệu trên đĩa, bên trong chứa các Data Block. Những block này được đọc lên Buffer Cache để xử lý trên Memory, và sau khi bị sửa đổi thì được ghi trở lại dưới dạng dirty block.
Datafile lưu dữ liệu lâu dài trên đĩa, còn Buffer Cache chỉ giữ bản sao tạm thời của những block đang được sử dụng.
2.3.2.5. Redo Log File
Mỗi khi Database phát sinh thay đổi, Oracle tạo Redo Information đưa vào Redo Log Buffer, rồi LGWR ghi tiếp xuống Online Redo Log File. Toàn bộ thông tin này về sau phục vụ cho công tác Recovery
2.3.2.6. Archived Log File
Khi một Online Redo Log Group đầy và xảy ra Log Switch, nếu hệ thống đang ở ARCHIVELOG mode thì ARCn sẽ sao chép group cũ để tạo ra Archived Redo Log, qua đó lưu lại lịch sử Redo lâu dài.
Archived Log không đơn thuần là "bản sao Redo Log File" — nó là bản sao nội dung của Redo Log Group đã được archive, lưu trữ lâu dài hơn, phục vụ Media Recovery, Backup và Point-in-Time Recovery.
2.3.2.7. Backup File
Khi cần sao lưu, quản trị viên dùng RMAN hoặc công cụ tương đương để tạo ra Backup File, trong đó lưu bản sao của Database, Control File và Archived Log. Bộ file này sẽ được sử dụng mỗi khi cần Restore hoặc Recovery.
2.4. Trạng thái khởi động Database
Oracle không mở toàn bộ hệ thống cùng lúc mà đi qua bốn trạng thái, mỗi trạng thái mở thêm một lớp truy cập dựa trên nền của trạng thái trước.
SHUTDOWN --> NOMOUNT --> MOUNT --> OPEN
2.4.1. SHUTDOWN
Ở trạng thái này Instance chưa hoạt động, SGA chưa được cấp phát và Background Process cũng chưa chạy, do đó Database hoàn toàn chưa mở.
2.4.2. NOMOUNT
Khi thực hiện lệnh STARTUP NOMOUNT, Oracle đọc Parameter File để lấy thông tin cấu hình cùng vị trí Control File, rồi cấp phát SGA và khởi động các Background Process. Đến đây Instance đã hình thành, nhưng vì chưa đọc Control File nên Database vẫn chưa được Mount.
2.4.3. MOUNT
Từ trạng thái NOMOUNT, Oracle dùng đường dẫn đã lấy được từ Parameter File để tìm tới Control File và đọc nội dung file này. Nhờ vậy Instance biết được Datafile và Redo Log File nằm ở đâu, và Database chuyển sang trạng thái Mount.
Ở trạng thái này Oracle đã nắm toàn bộ cấu trúc vật lý của Database, tuy nhiên vẫn chưa cho phép người dùng truy cập dữ liệu
2.4.4. OPEN
Từ trạng thái MOUNT, Oracle mở Datafile cùng Redo Log rồi đối chiếu SCN giữa Control File và Datafile Header. Nếu hai giá trị khớp nhau, hệ thống mở bình thường; còn nếu lệch nhau, SMON phải thực hiện Instance Recovery trước đã. Sau khi hoàn tất, Database chuyển sang OPEN và người dùng bắt đầu truy cập được dữ liệu.
Sửa lần cuối: