बड़ा .पैच_स्टोरेज

मुझे एंटरप्राइज़ मैनेजर से एक अलर्ट प्राप्त हुआ कि मेरा एक उत्पादन डेटाबेस डिस्क स्थान पर कम हो रहा था। मैंने इसे $GRID_HOME/.patch_storage पर ट्रैक किया जो मेरे 90GB ड्राइव के 30GB की खपत कर रहा था। ओह!

मैंने जो पहला काम किया, वह था ओपच क्लीनअप रूटीन चलाना, जैसा कि मैंने 2013 में यहां दस्तावेज किया था: http://www.peasland.net/2013/03/21/patch_storage/

दुर्भाग्य से, इसने कुछ भी साफ़ नहीं किया।

इस बार, मुझे मैन्युअल सफाई का सहारा लेना पड़ा। ये रहे वो कदम जो मैंने किए।

.patch_storage में फ़ाइलें पैच अणु संख्या और टाइमस्टैम्प से शुरू होती हैं। उदाहरण के लिए: 19582630 _Nov_14_2014_21_43_23

मुझे ओपच से पूछना है कि क्या वह पैच अभी भी इन्वेंट्री में है।

$ORACLE_HOME/OPatch/opatch lsinventory|grep 19582630
20075154, 20641027, 22271856, 20548410, 19016964, 19582630

lsinventory दिखाता है कि पैच इन्वेंट्री में है। मैं अगले पैच पर जाता हूं।

जब मेरा lsinventory कमांड कुछ भी नहीं लौटाता है, तो पैच इन्वेंट्री में नहीं होता है। एमओएस नोट 550522.1 कहता है कि आप उस निर्देशिका को हटा सकते हैं क्योंकि अब इसकी आवश्यकता नहीं है। मुझमें हमेशा सतर्क रहने वाला DBA व्यक्तित्व यह सुनिश्चित करना चाहता है कि मैं एक साधारण "rm -rf dir_name" कमांड से उबर सकूं। इसलिए मैं पहले निर्देशिका को टार और gzip करता हूं, फिर निर्देशिका को हटाता हूं।

टार सीवीएफ 25869825_Jul_3_2017_23_11_58.tar 25869825_Jul_3_2017_23_11_58

gzip 25869825_Jul_3_2017_23_11_58.tar

आरएम-आरएफ 25869825_Jul_3_2017_23_11_58

इसका श्रमसाध्य कार्य प्रत्येक पैच के लिए ऐसा कर रहा है। मुझे यकीन है कि sed और awk और शेल स्क्रिप्टिंग के साथ मुझसे बेहतर कोई व्यक्ति इस प्रक्रिया को स्वचालित कर सकता है।

इन चरणों का पालन करके, मेरी .patch_storage निर्देशिका 30GB से घटकर 11GB हो गई है।

अगली तिमाही में जब मैं अपना सीपीयू फिर से लागू करता हूं, तो क्या ओपैच क्राई फाउल और मांग करनी चाहिए कि इन्हें वापस रखा जाए, मैं जल्दी से टारबॉल को खोल और निकाल सकता हूं और ओपच को खुश होना चाहिए।

मैंने यह ऑपरेशन $GRID_HOME पर किया था लेकिन यह $RDBMS_HOME पर भी काम करेगा। साथ ही, चूंकि यह Oracle RAC है, मैं इसे क्लस्टर के सभी नोड्स पर करना चाह सकता हूं।