1. Vấn đề phân mảnh dữ liệu

Extent trong cơ sở dữ liệu Oracle là một đơn vị lưu trữ bao gồm một hoặc nhiều block dữ liệu liền kề trên đĩa, được phân bổ cho một đối tượng cơ sở dữ liệu như bảng hoặc chỉ mục. Khi một bảng hoặc chỉ mục cần thêm không gian để lưu trữ dữ liệu mới, Oracle sẽ cấp phát một extent mới.

Mối quan hệ segment, extent, block: Một segment chứa nhiều extent, một extent chứa nhiều các block dữ liệu liền kề nhau trên đĩa

Quan niệm sai lầm về phân mảnh và hiệu suất:

• Phân mảnh trong cơ sở dữ liệu có thể ảnh hưởng đến quản lý không gian, nhưng không phải lúc nào số lượng extent (phần mở rộng của dữ liệu trong một segment) cũng gây ảnh hưởng đến hiệu suất.
• Có hai quan niệm sai lầm: một là số lượng extent luôn ảnh hưởng đến hiệu suất, và hai là nó không bao giờ ảnh hưởng. Trên thực tế, ảnh hưởng này phụ thuộc vào tình huống cụ thể và cách quản lý không gian của hệ thống.

Ảnh hưởng của các chỉ mục bitmap với nhiều extent không liền kề:

• Chỉ mục bitmap (một loại chỉ mục đặc biệt trong cơ sở dữ liệu) nếu chứa nhiều extent không liền kề, trải dài qua nhiều tệp dữ liệu khác nhau, có thể gây ra các vấn đề nghiêm trọng về hiệu suất. Việc phân tán dữ liệu khiến việc truy xuất trở nên chậm hơn.

Sử dụng tablespace quản lý cục bộ để giảm thiểu vấn đề extent:

• Tablespace quản lý cục bộ (locally managed tablespace) là một phương pháp lưu trữ có thể giúp giảm thiểu các vấn đề liên quan đến extent. Tablespace này quản lý không gian trong cơ sở dữ liệu theo cách hiệu quả hơn, giúp tránh việc phân mảnh gây ảnh hưởng xấu đến hiệu suất.

Tái tổ chức dữ liệu là cần thiết, nhưng không phải lúc nào cũng cần thiết:

• Việc tái tổ chức dữ liệu để giảm phân mảnh không phải lúc nào cũng cần thiết. Nếu hệ thống lưu trữ đã được thiết lập đúng cách từ đầu, thì các DBA (người quản trị cơ sở dữ liệu) có thể không cần phải thường xuyên tái tổ chức.
• Tuy nhiên, nếu cần thực hiện tái tổ chức, hiện nay có nhiều cách để thực hiện mà không ảnh hưởng quá nhiều đến thời gian hoạt động của hệ thống. Điều này giúp giảm thiểu downtime và tăng cường hiệu suất hệ thống.

Các bước cần thiết để tránh các vấn đề về hiệu suất liên quan đến việc quản lý extent (phần mở rộng dữ liệu trong phân đoạn) trong cơ sở dữ liệu. Dưới đây là phân tích từng ý chính:

Sử dụng tablespace có extent quản lý cục bộ với kích thước đồng nhất:

• Khi biết rõ phân đoạn sẽ phát triển đến mức nào hoặc tốc độ tăng trưởng của nó, việc sử dụng tablespace quản lý cục bộ (locally managed tablespace) với kích thước extent đồng nhất giúp tối ưu hóa việc quản lý không gian lưu trữ. Điều này giảm thiểu sự phân mảnh và cải thiện hiệu suất, vì dữ liệu sẽ được lưu trữ đồng đều mà không gây ra quá nhiều phân tán.

Sử dụng kích thước extent là bội số của kích thước khối cơ sở dữ liệu:

• Việc chọn kích thước extent làm bội số của kích thước khối cơ sở dữ liệu giúp tối ưu hóa việc lưu trữ và truy xuất dữ liệu. Điều này đồng nghĩa với việc các extent sẽ được chia thành các phần tương thích với các khối dữ liệu, giúp tránh lãng phí không gian và giảm thiểu phân mảnh.

Di chuyển các bảng sang các tablespace có kích thước extent phù hợp khi chúng phát triển quá lớn:

• Khi các bảng phát triển đến một kích thước lớn hơn dự kiến, cần di chuyển chúng sang tablespace có kích thước extent lớn hơn để đảm bảo rằng các phân đoạn lớn có đủ không gian và không gây ra tình trạng phân mảnh hay truy xuất chậm.

Tránh phân mảnh hàng bằng cách sử dụng Quản lý không gian phân đoạn tự động (ASSM):

• Quản lý không gian phân đoạn tự động (ASSM) giúp tự động phân phối không gian cho các bảng và chỉ mục một cách hợp lý, ngăn chặn tình trạng phân mảnh hàng (row chaining), nơi mà dữ liệu của một hàng bị phân tán ra nhiều extent khác nhau. Điều này giúp cải thiện hiệu suất truy xuất dữ liệu.

Thường xuyên giám sát cơ sở dữ liệu để tìm các phân đoạn phát triển quá lớn:

• Giám sát thường xuyên để phát hiện những phân đoạn có số lượng extent quá lớn (trên 1000) là việc cần thiết. Khi một phân đoạn có quá nhiều extent, việc truy xuất và quản lý nó có thể trở nên chậm và khó khăn. Do đó, quản lý các phân đoạn này một cách thích hợp là điều quan trọng để duy trì hiệu suất tốt cho cơ sở dữ liệu.

TIP

Thường xuyên truy vấn bảng DBA_SEGMENTS để đảm bảo rằng các đối tượng không tích lũy quá nhiều extent (khi không sử dụng ASM). Việc phát hiện sớm các vấn đề là chìa khóa để tránh những vấn đề về hiệu suất sau này (có những lúc tốt hơn là nên để mọi thứ như hiện tại, đặc biệt là khi không có vấn đề gì xảy ra). Mục tiêu là sắp xếp các đối tượng vào đúng tablespace có kích thước extent đồng nhất, phù hợp với sự phát triển dự kiến của các đối tượng đó.

2. Sử dụng kích thước extent phù hợp

Khi dữ liệu được đọc từ một bảng, nó được truy cập thông qua một thao tác ROWID qua một chỉ mục hoặc bằng cách quét toàn bộ bảng (trừ các bảng được tổ chức theo chỉ mục). Trong hầu hết các trường hợp, phương pháp truy cập bằng ROWID là phương pháp được ưu tiên. Phương pháp ROWID cho phép cơ sở dữ liệu xác định chính xác khối chứa bản ghi và do đó bỏ qua mọi thông tin phân bổ extent trong segment. Nói ngắn gọn, các thao tác ROWID không quan tâm đến số lượng extent trong segment. Kích thước block của cơ sở dữ liệu thường dao động từ 4K đến 32K. Vì vậy, bất kể số lượng extent trong một segment, một lần quét toàn bộ bảng luôn thực hiện cùng một số lần đọc miễn là kích thước extent là bội số của kích thước khối cơ sở dữ liệu.

Chúng ta có cần phải lo lắng, quản tâm về số lượng extent nếu đang sử dụng các extent là bội số của kích thước block không? Câu trả lời là có, nhưng không còn bị ảnh hưởng nhiều như trước đây. Hãy nghĩ theo cách này: càng nhiều extent, chúng ta càng phải quản lý nhiều hơn, dù việc này có thể được thực hiện thông qua các phương pháp nhanh hơn. Do đó, nguyên tắc mình có tham khảo được là nếu một segment đang phát triển vượt quá 4096 extent (giả sử bạn đang sử dụng các tablespace quản lý cục bộ), hãy xem xét chuyển nó sang một tablespace với kích thước extent phù hợp hơn với kích thước segment. Nếu chúng ta có một bảng 15GB, việc sử dụng extent có kích thước 200MB có lẽ sẽ hiệu quả hơn so với kích thước 1MB. Về mặt tải dữ liệu, chúng ta sẽ tiết kiệm được thời gian xử lý background vì cơ sở dữ liệu không phải phân bổ quá nhiều extent trong quá trình tải.

3. Tránh hiện tượng chaining bằng cách đặt PCTFREE đúng cách

Khi một hàng được tạo trong bảng, dữ liệu được ghi vào một block và được gán một ROWID. ROWID xác định vị trí của dữ liệu trên đĩa. Nếu một hàng được cập nhật, các thay đổi sẽ được ghi vào cùng vị trí trên đĩa và ROWID của hàng không thay đổi. Hiện tượng chaining có thể xảy ra khi không còn đủ không gian trong các block dữ liệu để lưu trữ một hàng hoặc các thay đổi gần đây nhất của một hàng. Một hàng bị chaining là hàng tồn tại trong nhiều block thay vì một block duy nhất. Việc truy cập nhiều block cho cùng một hàng có thể tốn kém về mặt hiệu suất.

Để kiểm tra xem chúng ta có gặp vấn đề về chaining hay không, hãy chạy tập lệnh utlchain.sql mà Oracle cung cấp để tạo bảng CHAINED_ROWS. Tập tin utlchain.sql đi kèm với Oracle và nằm trong thư mục con /rdbms/admin của ORACLE_HOME. Chúng ta cũng có thể sử dụng Enterprise Manager hoặc kiểm tra mục "Fetch By Continued Row" trong STATSPACK hoặc AWR Report để phát hiện các hàng bị chaining. Chúng ta nên kiểm tra hiện tượng chaining hàng tuần và khắc phục ngay lập tức khi có vấn đề.

Để phân tích mức độ chaining trong một bảng (ví dụ như bảng CUSTOMER), bạn có thể chạy truy vấn sau:

Sau đó, chạy truy vấn sau để truy cập bảng CHAINED_ROWS nhằm kiểm tra bảng CUSTOMER có hiện tượng chaining hay không:

Nếu không có hàng nào được trả về, thì chúng ta không gặp vấn đề về chaining. Nếu có vấn đề về chaining, truy vấn sẽ trả về HEAD_ROWID cho tất cả các hàng bị chaining. Chúng ta cũng có thể sử dụng lệnh SELECT COUNT(*) trên bảng CHAINED_ROWS để tìm số lượng hàng bị chaining. Trong** V$SYSSTAT**, chỉ số "table fetch continued row" cũng là một dấu hiệu cho thấy có hiện tượng chaining.

Để tránh hiện tượng chaining, hãy đặt PCTFREE (lượng không gian được dành trong một block để cập nhật) đúng cách (không thiết lập thông số này khi sử dụng ASSM). Thông số này được thiết lập khi tạo bảng. Giá trị mặc định là 10 (dành 10% không gian cho các bản cập nhật), nhưng cần phải đặt cao hơn nhiều đối với các bảng có tần suất cập nhật cao.

Nhân tiện, nếu chúng ta có một bảng mà hoạt động cập nhật sẽ rất ít hoặc không có, chúng có thể đặt PCTFREE ở mức thấp hơn một chút để đảm bảo có nhiều hàng hơn vừa với block, do đó tiết kiệm không gian trong bảng của bạn.

Tìm các vấn đề về chaining bằng cách truy cập bảng CHAINED_ROWS. Tránh các vấn đề về chaining bằng cách đặt PCTFREE đúng cách hoặc chọn kích thước phù hợp cho cơ sở dữ liệu của bạn.

Ví dụ thực tế cần thay đổi PCTFREE: Bảng có nhiều cập nhật thường xuyên:

• Nếu một bảng có nhiều thao tác cập nhật đối với các hàng hiện có, giá trị PCTFREE cần được tăng lên cao hơn mức mặc định. Ví dụ, nếu chúng ta có một bảng lưu thông tin khách hàng và các thông tin như địa chỉ hoặc số điện thoại thường xuyên thay đổi, chúng ta nên đặt PCTFREE ở mức 20% hoặc 30% để có đủ không gian cho các cập nhật trong khối mà không cần phải chuyển hàng sang khối khác. Điều này giúp giảm tình trạng row chaining hoặc row migration.

Bảng ít hoặc không có cập nhật:

• Ngược lại, nếu bảng chứa dữ liệu ít thay đổi (ví dụ như bảng lưu trữ lịch sử giao dịch tài chính mà dữ liệu không thay đổi sau khi được ghi vào), chúng ta có thể giảm giá trị PCTFREE xuống 5% hoặc 0% để tối ưu hóa không gian lưu trữ và chứa được nhiều hàng hơn trong mỗi khối.

4. Thông tin kết nối

Nếu anh em muốn trao đổi thêm về bài viết, hãy kết nối với mình qua LinkedIn và Facebook:

• LinkedIn: https://www.linkedin.com/in/nguyentrungnam/
• Facebook: https://www.facebook.com/trungnam.nguyen.395/

Rất mong được kết nối và cùng thảo luận!