Quản lý lưu trữ hiệu quả trong Amazon RDS cho cơ sở dữ liệu Oracle

Tác giả: Radhika Chakravarty, Balaji Salem Balasundram, Deepak Mani, và Narendra Harsha Nimmagadda
Ngày phát hành: 14 JAN 2026
Chuyên mục: Advanced (300), Amazon RDS, Best Practices, RDS for Oracle

Quản lý lưu trữ hiệu quả là rất quan trọng để duy trì hiệu suất, độ tin cậy và hiệu quả chi phí của cơ sở dữ liệu Oracle chạy trên Amazon RDS. Khi dữ liệu của bạn phát triển và khối lượng công việc của bạn thay đổi, việc chủ động giám sát và tối ưu hóa việc sử dụng lưu trữ là điều cần thiết. Trong bài viết này, chúng tôi khám phá các kỹ thuật và phương pháp hay nhất khác nhau để quản lý lưu trữ hiệu quả trong RDS cho cơ sở dữ liệu Oracle.

Amazon Relational Database Service (Amazon RDS) cho Oracle cung cấp một dịch vụ cơ sở dữ liệu được quản lý hoàn toàn, giúp việc thiết lập, vận hành và mở rộng quy mô cơ sở dữ liệu Oracle trong AWS Cloud trở nên đơn giản. Amazon RDS cho Oracle quản lý các tác vụ quản trị cơ sở dữ liệu tốn thời gian để bạn có thể tập trung vào các ứng dụng của mình. Trong khi bạn phát triển và cải thiện các ứng dụng cốt lõi của mình, RDS xử lý các hoạt động backend thiết yếu: cấp phát cơ sở dữ liệu mới, triển khai các bản vá, chạy sao lưu, quản lý quy trình phục hồi, giám sát lỗi và thực hiện sửa chữa. Với việc quản lý cơ sở dữ liệu toàn diện này, bạn có thể dành nhiều thời gian hơn để xây dựng ứng dụng và ít thời gian hơn cho các tác vụ quản trị. Nó cung cấp một loạt các loại instancetùy chọn lưu trữ để đáp ứng các yêu cầu về hiệu suất và chi phí của bạn, đồng thời cung cấp các tính năng sẵn sàng cao tích hợp sẵn như triển khai Multi-AZ (Availability Zone) để tăng cường tính sẵn sàng.

Tổng quan

Trong bài viết này, chúng tôi thảo luận về các cách khác nhau để giám sát, tối ưu hóa và quản lý lưu trữ trống trong Amazon RDS.

1. Giám sát lưu trữ

Amazon CloudWatch cho phép bạn giám sát chặt chẽ tình trạng của các instance RDS và quan sát các thay đổi đối với cơ sở hạ tầng và khối lượng công việc cơ sở dữ liệu bên dưới. Sử dụng CloudWatch, bạn có thể giám sát một loạt các chỉ số trong các khoảng thời gian cụ thể, chẳng hạn như mức sử dụng đĩa, mức sử dụng CPU, mức sử dụng bộ nhớ, I/O đĩa và lưu lượng mạng. Bạn có thể sử dụng khả năng hiển thị toàn diện này để nhanh chóng xác định và giải quyết các vấn đề có thể phát sinh.

Bạn cũng có thể tạo một truy vấn SQL tùy chỉnh tương tự như truy vấn được đề cập trong: Tại sao instance DB Amazon RDS cho Oracle của tôi sử dụng nhiều dung lượng lưu trữ hơn dự kiến? và gửi email đến những người nhận cần thiết bằng cách sử dụng các tính năng của engine như UTL_MAIL như đã đề cập trong: Làm cách nào để gửi email từ instance DB Amazon RDS cho Oracle của tôi?

RDS cho Oracle được quản lý hoàn toàn và bao gồm các volume dữ liệu, volume nhị phân (bin) và volume gốc. Các volume gốc và bin chứa hệ điều hành và các tệp nhị phân của cơ sở dữ liệu Oracle tương ứng. Các volume này được giám sát và duy trì bởi hệ thống tự động hóa nội bộ của Amazon RDS. Với tư cách là khách hàng của Amazon RDS cho Oracle, bạn cần giám sát các volume dữ liệu. Đây là cùng một dung lượng lưu trữ được cấp phát trong thời gian tạo instance Amazon RDS. Các volume dữ liệu cho instance RDS cho Oracle lưu trữ các tệp dữ liệu, tệp redo và archive log, và tệp trace. Đây là vị trí cho thư mục cơ sở dữ liệu và do đó nó sẽ lưu trữ tệp dump cho xuất và nhập data pump, các phần sao lưu RMAN và các tệp được tham chiếu bởi các bảng bên ngoài. Ngoài ra, các bảng bên ngoài có thể được lưu trữ trong Amazon Simple Storage Service (Amazon S3), với tích hợp S3, cung cấp nhiều sự linh hoạt hơn cho các tùy chọn lưu trữ và truy cập dữ liệu.

Chỉ số CloudWatch để giám sát dung lượng lưu trữ trống trên mỗi volume là FreeStorageSpace. Nó cung cấp lượng dung lượng lưu trữ khả dụng trên mỗi volume và được đo bằng byte, như thể hiện trong hình sau.

Hơn nữa, bạn có thể thiết lập [CloudWatch alarms](https://docs.aws.amazon.com/AmazonAmazon CloudWatch%0dCloudWatch/latest/monitoring/ConsoleAlarms.html) để nhận thông báo khi một chỉ số vượt quá ngưỡng được xác định trước. Sử dụng cách tiếp cận chủ động này, bạn có thể hành động kịp thời để giải quyết vấn đề trước khi chúng leo thang và ảnh hưởng đến hoạt động của bạn. CloudWatch metric alarms là các công cụ giám sát mạnh mẽ theo dõi một chỉ số CloudWatch duy nhất hoặc kết quả của một biểu thức toán học được lấy từ nhiều chỉ số CloudWatch. Nó có thể kích hoạt các hành động khác nhau, chẳng hạn như gửi thông báo đến một chủ đề Amazon Simple Notification Service (Amazon SNS), dựa trên giá trị chỉ số hoặc biểu thức liên quan đến một ngưỡng được chỉ định trong một khoảng thời gian xác định. Điều này hỗ trợ giám sát chủ động và nhanh chóng xác định và giải quyết các vấn đề để duy trì độ tin cậy, tính sẵn sàng và hiệu suất tối ưu của môi trường AWS của bạn.

Để giám sát một instance Amazon RDS cho Oracle, hãy sử dụng như sau:

aws cloudwatch put-metric-alarm \
--alarm-name FreeSpace \
--alarm-description "Test Alarm when Space Below 50 GB" \
--metric-name FreeStorageSpace \
--namespace AWS/RDS \
--statistic Average \
--period 60 \
--threshold 50 \
--comparison-operator LessThanThreshold \
--dimensions "Name=DBInstanceIdentifier,Value=testrds" \
--evaluation-periods 2 \
--alarm-actions <ARN of the SNS Topic> \
--region us-west-2

Lệnh AWS Command Line Interface (AWS CLI) trên tạo một CloudWatch alarm có tên “FreeSpace” để giám sát dung lượng lưu trữ trống của một instance cơ sở dữ liệu RDS có tên “testrds” trong AWS Region US West (Oregon). Alarm được đặt để kích hoạt khi dung lượng lưu trữ trống trung bình giảm xuống dưới 50 GB trong hai khoảng thời gian 1 phút liên tiếp. Khi được kích hoạt, nó sẽ gửi thông báo qua một chủ đề Amazon SNS. Thiết lập này giúp bạn chủ động quản lý lưu trữ cơ sở dữ liệu bằng cách cảnh báo trước khi cơ sở dữ liệu sắp hết dung lượng một cách nghiêm trọng. Lệnh sử dụng một hồ sơ AWS được chia sẻ để xác thực, cho phép truy cập tiêu chuẩn hóa trên một nhóm hoặc tổ chức.

Giám sát các Volume lưu trữ bổ sung (ASV)

Để giám sát các volume lưu trữ bổ sung trong CloudWatch, một dimension mới “RDS -> DB Instance Identifier, Volume Name (per-volume metrics)” đã có sẵn.

Từ việc lọc, bạn có thể tiếp tục đi sâu vào định danh cơ sở dữ liệu và tên volume. Tên volume cho các volume lưu trữ bổ sung sẽ tuân theo quy ước đặt tên rdsdbdata trong đó n có thể là 2, 3 hoặc 4 (tối đa 3 volume bổ sung). Volume lưu trữ chính có tên volume là “rdsdbdata” (không có số).

Trong ảnh chụp màn hình sau, chúng ta xem xét các chỉ số của volume lưu trữ bổ sung: rdsdbdata2

Để xem các chỉ số trong Enhanced Monitoring, chọn tùy chọn “Enhanced Monitoring” từ menu thả xuống trong tab Monitoring.

Bạn có thể mở tùy chọn Manage Graphs và chọn các chỉ số cần thiết:

Sau khi bạn chọn lưu, bạn có thể xem các chỉ số volume của tất cả các volume bao gồm bất kỳ volume lưu trữ bổ sung nào. Chỉ số Total Filesystem(/rdsdbdata*) cung cấp tổng hợp của các volume lưu trữ chính và bổ sung.

Để xem các chỉ số trong Database Insights Advanced, hãy truy cập Database Telemetry -> Metrics -> Create Widget

Nhập tiêu đề widget và tìm kiếm “rdsdbdata2” trong phần chọn chỉ số để chọn các chỉ số liên quan cho ASV.

Sau khi bạn tạo widget, bạn sẽ có thể xem chi tiết.

2. Tự động điều chỉnh lưu trữ

Tự động điều chỉnh lưu trữ là một tính năng tiện lợi cho phép Amazon RDS tự động mở rộng lưu trữ của bạn khi nó phát hiện rằng bạn sắp hết dung lượng lưu trữ trống.

Lưu ý: Tự động điều chỉnh lưu trữ giúp ngăn chặn việc lưu trữ đầy bất ngờ ngoài giờ làm việc hoặc cửa sổ giám sát. Nên mở rộng lưu trữ của instance RDS cho Oracle đến kích thước dự kiến cần thiết cộng với không gian đệm. Điều này là để tránh rơi vào trạng thái tối ưu hóa lưu trữ, có thể mất 24 giờ hoặc hơn để hoàn thành.

Bạn có thể kiểm tra xem bạn đã bật tự động điều chỉnh lưu trữ cho instance RDS cho Oracle của mình hay chưa, bằng cách sử dụng AWS Management Console cho Amazon RDS hoặc sử dụng AWS CLI để mô tả instance và kiểm tra xem tham số MaxAllocatedStorage có giá trị hay không. Điều quan trọng là phải hiểu cách tự động điều chỉnh lưu trữ hoạt động và các giới hạn của nó.

Amazon RDS khởi tạo một sửa đổi lưu trữ cho một instance DB được bật tự động điều chỉnh khi các điều kiện sau được đáp ứng:

  • Dung lượng trống khả dụng nhỏ hơn hoặc bằng 10% dung lượng lưu trữ được cấp phát.
  • Tình trạng lưu trữ thấp kéo dài ít nhất 5 phút.
  • Ít nhất 6 giờ đã trôi qua kể từ lần sửa đổi lưu trữ cuối cùng hoặc việc tối ưu hóa lưu trữ đã hoàn tất, tùy theo điều kiện nào dài hơn.

Dung lượng lưu trữ bổ sung được thêm vào theo các bước tăng dần, tùy theo điều kiện nào lớn hơn:

  • 10 GiB
  • 10% dung lượng lưu trữ hiện tại được cấp phát
  • Mức tăng trưởng lưu trữ dự kiến vượt quá kích thước lưu trữ hiện tại được cấp phát trong vòng 7 giờ tới dựa trên chỉ số FreeStorageSpace từ giờ trước.

Hãy nhớ rằng, mặc dù tự động điều chỉnh lưu trữ là một tính năng hữu ích, nhưng không nên chỉ dựa vào nó. Việc biết các giới hạn của tính năng này, triển khai các phương pháp giám sát mạnh mẽ và thường xuyên xem xét các yêu cầu lưu trữ là rất quan trọng để duy trì một cơ sở dữ liệu RDS cho Oracle khỏe mạnh và hoạt động tốt.

Tự động điều chỉnh lưu trữ hiện không khả dụng cho các volume lưu trữ bổ sung. Nếu một instance có các volume lưu trữ bổ sung, bạn vẫn có thể sử dụng tự động điều chỉnh lưu trữ cho volume chính. Tự động điều chỉnh lưu trữ không được hỗ trợ chỉ cho “các volume lưu trữ bổ sung”. Tuy nhiên, bạn có thể giám sát lưu trữ như được mô tả trong Giám sát lưu trữ, thiết lập cảnh báo và tăng thủ công lưu trữ hoặc giải phóng dung lượng như đã thảo luận trong Xóa các tệp không mong muốn.

3. Xóa các tệp không mong muốn

Các hoạt động cơ sở dữ liệu như sao lưu RMAN, data pump, archive log, tệp kiểm toán và trace liên tục tạo ra các tệp có thể nhanh chóng tiêu tốn dung lượng lưu trữ quý giá. Khi không được quản lý, các tệp này có thể dẫn đến suy giảm hiệu suất, các hoạt động thất bại và chi phí không cần thiết vì lưu trữ RDS được tính phí dựa trên dung lượng được cấp phát.

Để xóa một tệp trong thư mục cơ sở dữ liệu như DATAPUMP_DIR, bạn có thể sử dụng gói UTL_FILE.FREMOVE trong RDS cho Oracle. Gói này cung cấp một cách tiện lợi để xóa các tệp khỏi thư mục và giải phóng dung lượng trở lại hệ điều hành. Xem Thực hiện các tác vụ linh tinh cho các instance DB Oracle để biết thêm thông tin về cách quản lý các thư mục cơ sở dữ liệu trong một instance RDS cho Oracle. Nên có một chính sách kiểm toán để theo dõi các hành động được thực hiện bằng gói UTL_FILE cho mục đích bảo mật.

Đối với DATAPUMP_DIR:

-- Using UTL_FILE.FREMOVE
BEGIN
UTL_FILE.FREMOVE('DATAPUMP_DIR', 'filename.dmp');
END;
/

Đối với các tệp trace, tệp kiểm toán và listener log, thời gian lưu giữ mặc định trong Amazon RDS là 7 ngày. Đối với alert log, là 30 ngày. Điều quan trọng là phải xem xét lịch trình lưu giữ và thực hiện các điều chỉnh cần thiết theo yêu cầu của bạn.

Để biết thêm thông tin về việc duy trì các tệp log, xem Các tệp log cơ sở dữ liệu Amazon RDS cho Oracle.

Việc quản lý các tệp archive log trong RDS cho Oracle tuân theo các mẫu lưu giữ cụ thể dựa trên cấu hình instance và thiết lập sao chép. Thời gian lưu giữ mặc định cho archive log trong một instance RDS cho Oracle độc lập được đặt thành 0 giờ, có nghĩa là các log này sẽ tự động bị xóa khỏi hệ thống máy chủ ngay sau khi được tải lên Amazon S3 thành công cho mục đích sao lưu.

Trong RDS cho Oracle, hành vi lưu giữ thay đổi đáng kể trong các kịch bản sao chép khác nhau. Khi các bản sao đọc được triển khai, thời gian lưu giữ mặc định là 2 giờ vì các log phải được giữ cho đến khi chúng được áp dụng cho tất cả các bản sao, dẫn đến tăng yêu cầu lưu trữ. Đối với các bản sao liên Region, RDS cho Oracle giữ các log giao dịch trên instance DB nguồn cho đến khi chúng được truyền và áp dụng cho tất cả các bản sao đọc liên Region. Do đó, điều quan trọng là phải giám sát chỉ số độ trễ bản sao.

Để biết thêm thông tin về việc lưu giữ các tệp archive log, xem Lưu giữ các redo log đã lưu trữ.

Quản lý nhật ký kiểm toán

Điều quan trọng là phải quản lý đúng cách các nhật ký kiểm toán trên cơ sở dữ liệu của bạn để duy trì hiệu suất hiệu quả và sử dụng tối ưu không gian đĩa. Khi các nhật ký kiểm toán trên cơ sở dữ liệu của bạn tăng về khối lượng, việc truy vấn một nhật ký kiểm toán với khối lượng dữ liệu kiểm toán lớn có thể ảnh hưởng đến hiệu suất và dẫn đến các vấn đề về khả năng mở rộng không gian. Tốt nhất là nên lưu trữ các bản ghi cũ và xóa chúng khỏi nhật ký kiểm toán trực tuyến định kỳ.

Để biết thêm thông tin, xem Kiểm toán bảo mật trong Amazon RDS cho Oracle: Phần 1.

4. Tái tổ chức bảng và tablespace

Tái tổ chức bảng trong Oracle là quá trình tái cấu trúc một bảng để cải thiện hiệu suất, thu hồi không gian không sử dụng hoặc sửa đổi cấu trúc của nó. Dưới đây là tổng quan về tái tổ chức bảng và cách thực hiện:

Tái tổ chức bảng

Tái tổ chức bảng trong cơ sở dữ liệu Oracle phục vụ nhiều mục đích quan trọng trực tiếp ảnh hưởng đến hiệu suất và hiệu quả của cơ sở dữ liệu. Động lực chính để tái tổ chức bảng là giải quyết các vấn đề phân mảnh tự nhiên xảy ra theo thời gian khi dữ liệu được chèn, cập nhật và xóa, dẫn đến các khối dữ liệu phân tán và sử dụng không gian không hiệu quả. Thông qua tái tổ chức, không gian không sử dụng có thể được thu hồi, giảm tổng dung lượng lưu trữ và cải thiện hiệu quả không gian. Quá trình này cải thiện đáng kể hiệu suất truy vấn bằng cách tối ưu hóa việc lưu trữ vật lý của dữ liệu, đảm bảo rằng dữ liệu liên quan được lưu trữ liền kề nếu có thể.

Ngoài ra, tái tổ chức cho phép sắp xếp lại dữ liệu để phù hợp hơn với các mẫu truy cập phổ biến, chẳng hạn như sắp xếp dữ liệu dựa trên các cột hoặc khóa chỉ mục được sử dụng thường xuyên. Từ góc độ cấu trúc, tái tổ chức bảng cung cấp cơ hội để sửa đổi cấu trúc bảng, chẳng hạn như thêm hoặc xóa cột, mà không cần các hoạt động riêng biệt có thể ảnh hưởng đến hiệu suất. Cách tiếp cận toàn diện này để bảo trì bảng không chỉ tối ưu hóa hiệu suất hiện tại mà còn chuẩn bị cơ sở dữ liệu cho sự phát triển trong tương lai và các yêu cầu kinh doanh thay đổi.

Tái tổ chức bảng thường xuyên nên là một phần của chiến lược bảo trì cơ sở dữ liệu, đặc biệt đối với các bảng có khối lượng lớn các hoạt động DML hoặc những bảng quan trọng đối với hoạt động kinh doanh.

Kiểm tra phân mảnh bảng

Để biết thông tin về việc kiểm tra phân mảnh bảng, xem Cách tìm phân mảnh cho bảng và LOB (Doc ID KB138882)

Chạy thủ tục sau với tên schema và tên bảng:

SQL> SELECT SUM(bytes)/1024/1024 AS "Table Size (MB)" FROM user_segments
WHERE segment_name='COUNTRIES_1';
Table Size (MB)
---------------
1216
SQL> set serveroutput on
declare
v_unformatted_blocks number;
v_unformatted_bytes number;
v_fs1_blocks number;
v_fs1_bytes number;
v_fs2_blocks number;
v_fs2_bytes number;
v_fs3_blocks number;
v_fs3_bytes number;
v_fs4_blocks number;
v_fs4_bytes number;
v_full_blocks number;
v_full_bytes number;
begin
dbms_space.space_usage ('ADMIN', 'COUNTRIES_1', 'TABLE', v_unformatted_blocks,
v_unformatted_bytes, v_fs1_blocks, v_fs1_bytes, v_fs2_blocks, v_fs2_bytes,
v_fs3_blocks, v_fs3_bytes, v_fs4_blocks, v_fs4_bytes, v_full_blocks, v_full_bytes);
dbms_output.put_line('Unformatted Blocks = '||v_unformatted_blocks);
dbms_output.put_line('FS1 Blocks = '||v_fs1_blocks);
dbms_output.put_line('FS2 Blocks = '||v_fs2_blocks);
dbms_output.put_line('FS3 Blocks = '||v_fs3_blocks);
dbms_output.put_line('FS4 Blocks = '||v_fs4_blocks);
dbms_output.put_line('Full Blocks = '||v_full_blocks);
end;
/
SQL> 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Unformatted Blocks = 0
FS1 Blocks = 0
FS2 Blocks = 951
FS3 Blocks = 969
FS4 Blocks = 78521
Full Blocks = 72475
PL/SQL procedure successfully completed.
Reference:
fs1_blocks : Number of blocks having at least 0 to 25% free space
fs2_blocks : Number of blocks having at least 25 to 50% free space
fs3_blocks : Number of blocks having at least 50 to 75% free space
fs4_blocks : Number of blocks having at least 75 to 100% free space
ful1_blocks : Total number of blocks full in the segment

Các tùy chọn nào có sẵn trong Oracle để tái tổ chức bảng?

Lưu ý: Các phương pháp sau đây nên được kiểm tra trong môi trường ưu tiên thấp hơn trước. Một số phương pháp có thể yêu cầu thời gian ngừng hoạt động và nên được thực hiện trong các cửa sổ bảo trì.

Oracle cung cấp nhiều cách tiếp cận để tái tổ chức bảng, mỗi cách có những ưu điểm và nhược điểm riêng: CTAS, ALTER TABLE MOVE, DBMS_REDEFINITION, xuất/nhập và ALTER TABLE SHRINK SPACE.

Phương pháp CTAS

Tái tổ chức bảng trong Oracle có thể được thực hiện thông qua một số phương pháp, với CREATE TABLE AS SELECT (CTAS) là một trong những cách tiếp cận được sử dụng nhiều nhất. Phương pháp CTAS bao gồm quy trình ba bước:

  1. Tạo một bảng mới với cấu trúc mong muốn và sao chép dữ liệu từ bảng hiện có bằng cách sử dụng câu lệnh SELECT.
    sql CREATE TABLE new_table AS SELECT * FROM old_table;
  2. Xóa bảng gốc.
    sql DROP TABLE old_table;
  3. Đổi tên bảng mới để khớp với tên bảng gốc.
    sql ALTER TABLE new_table RENAME TO old_table;

Mặc dù phương pháp này mang lại những lợi thế như sự đơn giản, dễ hiểu và tính linh hoạt để triển khai các thay đổi cấu trúc nhanh chóng, nhưng nó cũng đi kèm với những cân nhắc và hạn chế đáng chú ý.

Hạn chế chính là yêu cầu gấp đôi dung lượng lưu trữ trong quá trình tái tổ chức, vì cả bảng gốc và bảng mới đều tồn tại đồng thời. Ngoài ra, bảng trở nên không khả dụng cho các hoạt động DML trong quá trình tái tổ chức, điều này có thể ảnh hưởng đến hoạt động kinh doanh trong môi trường sản xuất. Một cân nhắc quan trọng khác là các đối tượng phụ thuộc như chỉ mục, trigger và quyền phải được tạo lại sau khi tái tổ chức, đòi hỏi lập kế hoạch cẩn thận và các bước bổ sung trong quá trình.

Mặc dù có những hạn chế này, CTAS vẫn là một lựa chọn phổ biến cho các bảng nhỏ hơn hoặc trong các cửa sổ bảo trì nơi thời gian ngừng hoạt động được chấp nhận. Dưới đây là cú pháp cơ bản:

Lệnh ALTER TABLE MOVE cung cấp một phương pháp đơn giản để tái tổ chức bảng và thu hồi không gian.

ALTER TABLE table_name MOVE TABLESPACE new_tablespace;

Bằng cách sử dụng cách tiếp cận này, bạn có thể di chuyển các bảng đến các tablespace khác nhau, nén dữ liệu và tái tổ chức cấu trúc lưu trữ của bảng. Hoạt động MOVE có lợi thế về tính trực tiếp trong việc chống phân mảnh không gian, khả năng thay đổi các tham số lưu trữ và tùy chọn di chuyển các bảng giữa các tablespace. Tuy nhiên, nó yêu cầu thời gian ngừng hoạt động vì bảng bị khóa trong quá trình hoạt động và tất cả các chỉ mục phải được xây dựng lại sau đó. Hoạt động có thể được tăng cường với từ khóa ONLINE trong Enterprise Edition để giảm thiểu sự gián đoạn, mặc dù điều này có thể ảnh hưởng đến hiệu suất.

Sau đây là một ví dụ triển khai ALTER TABLE MOVE:

-- Basic move operation
ALTER TABLE table_name MOVE;
-- Move with specific parameters
ALTER TABLE table_name MOVE
TABLESPACE new_tablespace
COMPRESS
NOLOGGING;
-- Online move (Enterprise Edition)
ALTER TABLE table_name MOVE ONLINE;
-- Rebuild indexes after move
ALTER INDEX index_name REBUILD;
BEGIN
DBMS_REDEFINITION.START_REDEF_TABLE(
uname => 'SCHEMA_NAME',
orig_table => 'OLD_TABLE',
int_table => 'INTERIM_TABLE');
END;
/

DBMS_REDEFINITION đại diện cho một cách tiếp cận tinh vi hơn, cho phép tái tổ chức bảng trực tuyến với thời gian ngừng hoạt động tối thiểu. Phương pháp này đặc biệt có giá trị trong môi trường sản xuất nơi tính sẵn sàng liên tục là quan trọng. Sử dụng DBMS_REDEFINITION, bạn có thể thực hiện các thay đổi cấu trúc phức tạp trong khi tự động duy trì các đối tượng phụ thuộc. Quá trình bắt đầu bằng DBMS_REDEFINITION.START_REDEF_TABLE, chỉ định chi tiết bảng gốc và bảng tạm thời. Mặc dù phương pháp này mang lại những lợi thế đáng kể cho các hệ thống sản xuất, nhưng nó yêu cầu triển khai cẩn thận, không gian lưu trữ bổ sung trong quá trình và có thể chậm hơn so với các lựa chọn thay thế ngoại tuyến.

Phương pháp xuất/nhập cung cấp tùy chọn tái tổ chức toàn diện nhất, cho phép tái cấu trúc bảng hoàn chỉnh và di chuyển dữ liệu giữa các phiên bản hoặc hệ thống Oracle khác nhau. Tuy nhiên, cách tiếp cận này đi kèm với những nhược điểm đáng kể, bao gồm yêu cầu thời gian ngừng hoạt động đáng kể, nhu cầu lưu trữ bổ sung cho các tệp xuất và thời gian thực hiện có thể kéo dài đối với các bảng lớn.

Thu hẹp

Lệnh ALTER TABLE SHRINK SPACE cung cấp một phương pháp trực tuyến hiệu quả để thu hồi không gian không sử dụng trong các bảng Oracle và các chỉ mục liên quan của chúng, làm cho nó trở thành một công cụ có giá trị để quản lý không gian cơ sở dữ liệu. Hoạt động này đặc biệt hiệu quả đối với các bảng trải qua phân mảnh không gian đáng kể do các hoạt động DELETE hoặc UPDATE thường xuyên, vì nó hoạt động bằng cách di chuyển các hàng đến đầu bảng hoặc phân đoạn và giải phóng không gian trống ở cuối để trả lại cho tablespace. Trước khi triển khai hoạt động thu hẹp, hãy xác minh tính đủ điều kiện của bảng và bật di chuyển hàng bằng lệnh sau.

ALTER TABLE table_name ENABLE ROW MOVEMENT';

Quá trình thu hẹp thường tuân theo cách tiếp cận hai bước:

  1. Sử dụng tùy chọn COMPACT để chống phân mảnh không gian.
  2. Sử dụng CASCADE để thu hẹp cả bảng và các đối tượng phụ thuộc của nó.

Mặc dù phương pháp này mang lại một số lợi thế, bao gồm hoạt động trực tuyến với sự gián đoạn tối thiểu, không yêu cầu lưu trữ bổ sung và bảo trì chỉ mục tự động, nhưng có những cân nhắc quan trọng cần lưu ý. Hoạt động yêu cầu bật di chuyển hàng, có thể tạm thời ảnh hưởng đến hiệu suất trong quá trình thực hiện và không phù hợp với các bảng có giao dịch chạy dài hoặc một số phân đoạn Large Objects (LOB). Các bảng có trigger hoặc ràng buộc khóa ngoại có thể yêu cầu sự chú ý đặc biệt và nên thực hiện các hoạt động thu hẹp trong thời gian hoạt động thấp. Trình tự triển khai điển hình trông như sau:

ALTER TABLE table_name ENABLE ROW MOVEMENT;
ALTER TABLE table_name SHRINK SPACE COMPACT;
ALTER TABLE table_name SHRINK SPACE CASCADE;

Giám sát hàng tuần mức sử dụng không gian và mức độ phân mảnh có thể giúp bạn xác định thời điểm tối ưu cho các hoạt động thu hẹp, biến nó thành một phần thiết yếu của các chiến lược bảo trì cơ sở dữ liệu chủ động.

Các phương pháp tái tổ chức bảng Oracle: Ưu và nhược điểm

Phương phápƯu điểmNhược điểm
CTAS (Create Table As Select)• Triển khai đơn giản và dễ hiểu
• Linh hoạt để triển khai các thay đổi cấu trúc
• Tốt cho các bảng nhỏ hơn
• Kiểm soát hoàn toàn cấu trúc bảng mới
• Yêu cầu gấp đôi dung lượng lưu trữ trong quá trình
• Bảng không khả dụng cho các hoạt động DML trong quá trình tái tổ chức
• Các đối tượng phụ thuộc (chỉ mục, trigger, quyền) phải được tạo lại
• Gây ra thời gian ngừng hoạt động – tốt nhất cho các cửa sổ bảo trì
ALTER TABLE MOVE• Phương pháp trực tiếp để chống phân mảnh không gian
• Có thể thay đổi các tham số lưu trữ
• Khả năng di chuyển các bảng giữa các tablespace
• Cú pháp đơn giản hơn các phương pháp khác
• Bảng bị khóa trong quá trình hoạt động (yêu cầu thời gian ngừng hoạt động)
• Tất cả các chỉ mục phải được xây dựng lại sau đó
• Các thay đổi cấu trúc hạn chế có thể thực hiện
• Ảnh hưởng đến hiệu suất trong quá trình hoạt động
DBMS_REDEFINITION• Tái tổ chức trực tuyến với thời gian ngừng hoạt động tối thiểu
• Tự động duy trì các đối tượng phụ thuộc
• Cho phép các thay đổi cấu trúc phức tạp
• Lý tưởng cho môi trường sản xuất
• Sẵn sàng liên tục trong quá trình
• Yêu cầu triển khai cẩn thận
• Cần thêm dung lượng lưu trữ trong quá trình
• Phức tạp hơn để triển khai so với các phương pháp khác
• Có thể chậm hơn so với các lựa chọn thay thế ngoại tuyến
• Yêu cầu các tính năng của Enterprise Edition
Export/Import• Tùy chọn tái tổ chức toàn diện nhất
• Có thể tái cấu trúc bảng hoàn chỉnh
• Hỗ trợ di chuyển dữ liệu giữa các phiên bản Oracle khác nhau
• Yêu cầu thời gian ngừng hoạt động đáng kể
• Cần thêm dung lượng lưu trữ cho các tệp xuất
• Thời gian thực hiện dài đối với các bảng lớn
• Gây gián đoạn nhất trong tất cả các phương pháp
ALTER TABLE SHRINK SPACE• Phương pháp trực tuyến hiệu quả với sự gián đoạn tối thiểu
• Không yêu cầu lưu trữ bổ sung
• Bảo trì chỉ mục tự động
• Tốt để thu hồi không gian sau khi xóa hàng loạt
• Có thể bao gồm tùy chọn CASCADE cho các đối tượng phụ thuộc
• Yêu cầu bật di chuyển hàng
• Có thể tạm thời ảnh hưởng đến hiệu suất
• Không phù hợp với các bảng có giao dịch chạy dài
• Hiệu quả hạn chế đối với một số phân đoạn LOB
• Cần cân nhắc đặc biệt đối với các bảng có trigger hoặc khóa ngoại

Hãy nhớ rằng, phương pháp tốt nhất để sử dụng phụ thuộc vào nhu cầu cụ thể của bạn, kích thước bảng, thời gian ngừng hoạt động có sẵn và phiên bản Oracle. Hãy kiểm tra trong môi trường phi sản xuất trước khi triển khai vào sản xuất.

Quản lý và tái tổ chức Tablespace trong Oracle: Một cách tiếp cận toàn diện

Tái tổ chức tablespace trong cơ sở dữ liệu Oracle đại diện cho một khía cạnh quan trọng của việc bảo trì cơ sở dữ liệu nhằm tối ưu hóa việc sử dụng lưu trữ, cải thiện hiệu suất và quản lý không gian hiệu quả. Tablespace, là các đơn vị lưu trữ logic nhóm các phân đoạn dữ liệu liên quan, yêu cầu bảo trì thường xuyên để giúp ngăn chặn phân mảnh và duy trì hiệu suất tối ưu. Các dấu hiệu phổ biến cho thấy cần tái tổ chức bao gồm hiệu suất truy vấn bị suy giảm, tăng phân mảnh không gian và sử dụng không gian không hiệu quả. Oracle cung cấp một số cách tiếp cận để quản lý tablespace, bao gồm di chuyển các tệp dữ liệu, thay đổi kích thước tablespace, thêm các tệp dữ liệu mới và triển khai các tính năng tiết kiệm không gian như nén bảng.

Hoạt động coalesce đại diện cho một cách tiếp cận trong chiến lược bảo trì rộng hơn này. Các hoạt động coalesce tablespace trong Oracle cung cấp một cơ chế để kết hợp các khu vực không gian trống liền kề trong một tablespace để tạo ra các khối liền kề lớn hơn, về cơ bản cải thiện việc sử dụng không gian và giảm phân mảnh. Hoạt động này được thiết kế đặc biệt cho các tablespace được quản lý cục bộ với quản lý không gian phân đoạn tự động, hoạt động bằng cách quét các khối bitmap để xác định và hợp nhất các extent trống liền kề. Hoạt động coalesce mang lại một số lợi thế đáng kể:

  • Nó có thể được thực hiện trong khi tablespace vẫn trực tuyến và khả dụng
  • Không yêu cầu thêm dung lượng lưu trữ để thực hiện
  • Nó có thể được Oracle tự động kích hoạt hoặc được khởi tạo thủ công bằng lệnh
    sql ALTER TABLESPACE tablespace_name COALESCE;

Mặc dù hoạt động này cải thiện hiệu quả việc sử dụng không gian và có thể nâng cao hiệu suất thông qua việc giảm phân mảnh, nhưng nó cũng đi kèm với một số hạn chế. Quá trình này có thể không hiệu quả bằng việc tái tổ chức hoàn chỉnh khi xử lý các tablespace bị phân mảnh 80% trở lên, có thể tiêu tốn tài nguyên hệ thống đáng kể đặc biệt đối với các tablespace lớn và đáng chú ý là không nén hoặc di chuyển dữ liệu hiện có. Để biết thêm thông tin, xem Thay đổi kích thước tablespace, tệp dữ liệu và tệp tạm thời.

Giám sát thường xuyên và bảo trì chủ động các tablespace, bao gồm tái tổ chức định kỳ và các hoạt động coalescing, là những thành phần thiết yếu của một chiến lược quản lý cơ sở dữ liệu toàn diện. Bạn nên phát triển một cách tiếp cận có hệ thống để quản lý tablespace, xem xét các yếu tố như thời gian sử dụng cao điểm, các mẫu tăng trưởng và yêu cầu hiệu suất khi triển khai các hoạt động bảo trì này.

Điều quan trọng cần lưu ý là mặc dù coalesce tablespace có thể giúp tối ưu hóa việc sử dụng không gian, nhưng nó không thay thế cho việc định cỡ và quản lý tablespace đúng cách. Giám sát thường xuyên và quản lý chủ động vẫn cần thiết để có hiệu suất cơ sở dữ liệu tối ưu.

Trong một số trường hợp khi dữ liệu bị xóa khỏi một tablespace Oracle trong cơ sở dữ liệu Amazon RDS, không gian được cấp phát cho tablespace đó không tự động thu hẹp. Cơ sở dữ liệu đánh dấu các khối dữ liệu đã bị chiếm trước đó là không gian trống, cho phép chúng được sử dụng lại cho các lần chèn dữ liệu mới trong cùng một tablespace. Tuy nhiên, kích thước tổng thể được cấp phát của tablespace vẫn không thay đổi. Để thu hồi không gian không sử dụng và giảm dung lượng của tablespace, bạn cần thay đổi kích thước tablespace hoặc các tệp dữ liệu liên quan của nó theo cách thủ công thông qua các quy trình cụ thể.

5. Giảm kích thước tablespace

Để thay đổi kích thước tablespace, xem Làm cách nào để thay đổi kích thước tablespace cho instance DB Amazon RDS cho Oracle của tôi?

Hãy nhớ rằng các hoạt động thay đổi kích thước có thể ảnh hưởng đến hiệu suất, vì vậy nên thực hiện chúng trong các cửa sổ bảo trì hoặc thời gian hoạt động thấp. Hãy sao lưu và kiểm tra các quy trình trong môi trường phi sản xuất trước khi áp dụng chúng cho cơ sở dữ liệu sản xuất của bạn.

Sử dụng SYSAUX

Trong Amazon RDS cho Oracle, việc giám sát chặt chẽ tablespace SYSAUX là rất quan trọng, vì nó có thể phát triển nhanh chóng do nhiều yếu tố như Automatic Workload Repository (AWR), thống kê trình tối ưu hóa hoặc kiểm toán. Theo mặc định, tablespace SYSAUX được đặt là tự động mở rộng, điều này càng làm cho việc giám sát việc sử dụng không gian của nó trở nên quan trọng hơn.

Để quản lý tablespace SYSAUX hiệu quả, hãy thu thập thông tin chi tiết về các thành phần đang tiêu thụ không gian trong tablespace, thời gian lưu giữ của các báo cáo AWR và phân phối phân đoạn. Oracle cung cấp “Mẹo nếu Tablespace SYSAUX của bạn phát triển nhanh chóng hoặc quá lớn (Doc ID 1292724.1)” cung cấp hướng dẫn có giá trị về việc giải quyết các vấn đề tăng trưởng tablespace SYSAUX. Lưu ý rằng nếu kích thước của tablespace AUDIT đầy, bạn có thể không đăng nhập được vào cơ sở dữ liệu nếu audit_sys_operations được đặt thành true.

Các phương pháp được khuyến nghị để tránh hoặc giảm thiểu các vấn đề tăng trưởng SYSAUX:

  1. Đảm bảo không có đối tượng ứng dụng hoặc người dùng nào có mặt trong tablespace SYSAUX, vì nó chỉ dành cho các thành phần do Oracle quản lý.
  2. Nếu kiểm toán được bật, hãy sử dụng một tablespace riêng cho kiểm toán và định cỡ nó một cách thích hợp. Bạn có thể sử dụng lệnh sau để đặt vị trí nhật ký kiểm toán:
    sql exec dbms_audit_mgmt.set_audit_trail_location(audit_trail_type=>DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD,audit_trail_location_value=>'New tablespace');
  3. Do các giới hạn của Amazon RDS, bạn không thể trực tiếp tái tổ chức các đối tượng trong tablespace SYSAUX để giải phóng không gian trống. Tuy nhiên, bạn có thể xem xét các tùy chọn sau:
    a. Tắt AUTOEXTEND cho tablespace SYSAUX, để không gian trống trong tablespace sẽ được sử dụng lại cho các phân đoạn khác.
    b. Sử dụng AWS Database Migration Service (AWS DMS) hoặc Data Pump để di chuyển sang một instance mới và giám sát sự tăng trưởng trong tương lai trên SYSAUX.
  4. Giám sát sự tăng trưởng của SYSAUX thường xuyên để xác định các thành phần góp phần vào sự tăng trưởng của nó và thực hiện các hành động thích hợp, chẳng hạn như điều chỉnh thời gian lưu giữ AWR, xây dựng lại thống kê trình tối ưu hóa hoặc thay đổi kích thước tablespace khi cần.

Bằng cách tuân thủ các phương pháp này và sử dụng tài liệu của Oracle, bạn có thể chủ động quản lý tablespace SYSAUX, giúp ngăn chặn các vấn đề tăng trưởng không mong muốn và duy trì hiệu suất và sự ổn định tối ưu của môi trường cơ sở dữ liệu Oracle của bạn.

Kết luận

Quản lý lưu trữ hiệu quả là điều cần thiết để duy trì hiệu suất, độ tin cậy và hiệu quả chi phí của cơ sở dữ liệu Oracle chạy trên Amazon RDS. Bằng cách triển khai các phương pháp giám sát mạnh mẽ, sử dụng các tính năng như tự động điều chỉnh lưu trữ (cho RDS cho Oracle), xóa các tệp không mong muốn và thực hiện tái tổ chức bảng, bạn có thể tối ưu hóa việc sử dụng lưu trữ và đảm bảo cơ sở dữ liệu của bạn hoạt động với hiệu suất cao nhất.

Xem Làm việc với lưu trữ cho các instance Amazon RDS cho Oracle để biết các bản cập nhật và phương pháp hay nhất mới nhất.


Về tác giả

Radhika Chakravarty

Radhika Chakravarty

Radhika là Kiến trúc sư Giải pháp cấp cao chuyên về công nghệ AI tạo sinh và Cơ sở dữ liệu. Cô hợp tác với các đối tác Nhà cung cấp Phần mềm Độc lập (ISV) của NAMER để kiến trúc các giải pháp AI quy mô doanh nghiệp. Với chuyên môn sâu rộng về cơ sở dữ liệu trải rộng trên các nền tảng quan hệ và NoSQL, Radhika xuất sắc trong việc thiết kế các giải pháp AI được xây dựng trên kiến trúc dữ liệu mạnh mẽ, có khả năng mở rộng, kết nối quản lý dữ liệu truyền thống với các ứng dụng dựa trên AI hiện đại.

Balaji Salem Balasundram

Balaji Salem Balasundram

Balaji là Quản lý Tài khoản Kỹ thuật cấp cao có trụ sở tại Salt Lake City, Hoa Kỳ. Là người chiến thắng giải Gold Jacket, Balaji hợp tác chặt chẽ với khách hàng AWS để tạo điều kiện thuận lợi cho hành trình di chuyển của họ lên AWS cloud. Anh chuyên giúp các tổ chức đạt được sự linh hoạt, quy mô và khả năng phục hồi cao hơn với các dịch vụ cơ sở dữ liệu trong hệ sinh thái AWS.

Narendra Harsha Nimmagadda

Narendra Harsha Nimmagadda

Narendra là Kỹ sư Cơ sở dữ liệu tại AWS, mang đến hơn 17 năm kinh nghiệm lãnh đạo kỹ thuật cơ sở dữ liệu chuyển đổi cho khách hàng doanh nghiệp trên toàn thế giới. Là một chuyên gia được chứng nhận AWS và chuyên gia về RDS Oracle và PostgreSQL, Harsha chuyên kiến trúc và thực hiện các chiến lược di chuyển cơ sở dữ liệu phức tạp mang lại giá trị kinh doanh có thể đo lường và sự xuất sắc trong vận hành.

Deepak Mani

Deepak Mani

Deepak là Kỹ sư Cơ sở dữ liệu Đám mây cấp cao tại AWS. Anh là Chuyên gia về Amazon RDS cho Oracle và Amazon RDS. Deepak có 15 năm kinh nghiệm làm việc với các cơ sở dữ liệu quan hệ.