Tôi nhận được cảnh báo từ Người quản lý doanh nghiệp rằng một trong những cơ sở dữ liệu sản xuất của tôi sắp hết dung lượng đĩa. Tôi đã theo dõi nó xuống $ GRID_HOME / .patch_storage, tiêu tốn 30GB trong ổ 90GB của tôi. Rất tiếc!
Điều đầu tiên tôi làm là chạy quy trình dọn dẹp opatch như tôi đã ghi lại ở đây vào năm 2013:http://www.peasland.net/2013/03/21/patch_storage/
Thật không may, nó không dọn dẹp được bất cứ thứ gì.
Lần này, tôi phải dùng đến phương pháp dọn dẹp thủ công. Đây là các bước tôi đã làm.
Các tệp trong .patch_storage bắt đầu bằng số phân tử bản vá và dấu thời gian. Ví dụ: 19582630 _Nov_14_2014_21_43_23
Tôi cần hỏi opatch nếu bản vá đó vẫn còn trong kho.
$ ORACLE_HOME / OPatch / opatch lsinventory | grep 19582630
20075154, 20641027, 22271856, 20548410, 19016964, 19582630
lsinventory cho thấy bản vá đang ở trong kho. Tôi chuyển sang bản vá tiếp theo.
Khi lệnh lsinventory của tôi không trả về gì, bản vá không có trong kho. MOS Note 550522.1 cho biết bạn có thể xóa thư mục đó khi không còn cần thiết nữa. Tính cách DBA luôn thận trọng trong tôi muốn đảm bảo rằng tôi có thể phục hồi từ một lệnh đơn giản “rm -rf dir_name”. Vì vậy, tôi tar và gzip thư mục trước, sau đó xóa thư mục.
tar cvf 25869825_Jul_3_2017_23_11_58.tar 25869825_Jul_3_2017_23_11_58
gzip 25869825_Jul_3_2017_23_11_58.tar
rm -rf 25869825_Jul_3_2017_23_11_58
Công việc chăm chỉ của nó thực hiện điều này cho mỗi và mọi bản vá. Tôi chắc rằng ai đó giỏi hơn tôi với tập lệnh sed và awk và shell có thể tự động hóa quá trình này.
Bằng cách làm theo các bước này, thư mục .patch_storage của tôi đã giảm từ 30GB xuống 11GB.
Quý tới, khi tôi áp dụng lại CPU của mình, nếu opatch lỗi và yêu cầu đặt chúng trở lại, tôi có thể nhanh chóng giải nén và giải nén tarball và opatch sẽ rất vui.
Tôi đã thực hiện thao tác này trên $ GRID_HOME nhưng nó cũng sẽ hoạt động trên $ RDBMS_HOME. Ngoài ra, vì đây là Oracle RAC, tôi có thể muốn thực hiện việc này trên tất cả các nút trong cụm.
