पीएल/एसक्यूएल से शेल स्क्रिप्ट को कॉल करना, लेकिन शेल को ग्रिड उपयोगकर्ता के रूप में निष्पादित किया जाता है, ऑरैकल नहीं

जैसा कि टिप्पणियों में बताया गया है, मुद्दा यह है कि Runtime.getRuntime().exec EXTPROC के माध्यम से चलता है, और इस प्रकार ग्रिड श्रोता के माध्यम से चलता है। चूंकि हमारे पास हमारे नए कॉन्फ़िगरेशन पर DB और GRID के बीच OS उपयोगकर्ता अलगाव है, इसने FS पर एक अनुमति समस्या खड़ी कर दी।

इसका समाधान निम्न में से एक है:

ग्रिड उपयोगकर्ता को फ़ाइलें लिखने और umask को 774 या 664 जैसी किसी चीज़ में बदलने की अनुमति देने के लिए FS अनुमति को ठीक करें, ताकि ग्रिड और ऑरेकल दोनों उपयोगकर्ता बाद में फ़ाइलों को संशोधित कर सकें;
sudoers फ़ाइल बदलें और ग्रिड को पासवर्ड के बिना oracle के रूप में आवश्यक कमांड निष्पादित करने की अनुमति दें और sudo को शामिल करने के लिए शेल स्क्रिप्ट बदलें;
दूसरे पोर्ट पर डीबी होम पर एक नया श्रोता बनाएं और नए पोर्ट को इंगित करने के लिए TNSNAMES.ORA प्रविष्टि बदलें। फिर extproc को OS उपयोगकर्ता oracle के रूप में निष्पादित किया जाएगा। आपको $OH पर LISTENER.ORA को मैन्युअल रूप से संपादित करना होगा और इसे lsnrctl से शुरू करना होगा, क्योंकि srvctl के साथ पंजीकृत श्रोता हमेशा ग्रिड द्वारा शुरू किए जाएंगे;
मुख्य श्रोता को डीबी होम में बदलें। मैं इसकी अनुशंसा नहीं करता (उपरोक्त आइटम देखें)।

[संपादित करें] जैसा कि @AlexPoole और @jonearles द्वारा बताया गया है, दो अन्य विकल्प हैं जो मेरे मामले के लिए उपयुक्त नहीं थे, लेकिन दूसरों के लिए हो सकते हैं:

यदि आप ORACLE_SID को सेट करते हुए sqlplus पर स्थानीय रूप से स्क्रिप्ट चलाते हैं, तो FS एक्सेस sqlplus चलाने वाले OS उपयोगकर्ता द्वारा किया जाएगा। तो आप ओरेकल, या किसी अन्य उपयोगकर्ता के रूप में चला सकते हैं और एफएस अनुमतियों को ठीक कर सकते हैं;
यदि आप SYS के रूप में dbms_job अनुसूचक पर कार्य शेड्यूल करते हैं, तो कार्य oracle द्वारा निष्पादित किया जाएगा (यह व्यवहार संस्करण पर निर्भर हो सकता है, इसलिए आगे के परीक्षण की आवश्यकता है)।

सादर,

डेनियल स्टोल्फ