ओरेकल को लिपि वातावरण-स्वतंत्र बनाते हुए

पहले से ही एक से अधिक सही लेख संस्करण नियंत्रण प्रणालियों (जैसे सीवीएस, एसवीएन, टीएफएस, आदि) में डेटाबेस स्कीमा के स्रोत कोड को संग्रहीत करने की आवश्यकता और लाभों के बारे में लिखा गया है, साथ ही साथ तैनात स्क्रिप्ट को बनाए रखना है।
मैं खुद को नहीं दोहराऊंगा, लेकिन हम इस प्रक्रिया के विशिष्ट पहलुओं में से एक का विश्लेषण करेंगे।

यह कोई रहस्य नहीं है कि सामान्य रूप से निर्धारित विकास प्रक्रिया में स्वयं (देव), आंतरिक परीक्षण (क्यूए), अंत उपयोगकर्ताओं (यूएटी) द्वारा स्वीकृति परीक्षण और सीधे, उत्पादन शामिल हैं। व्यक्तिगत मामलों में जीवन चक्र का विवरण भिन्न हो सकता है, लेकिन यह लेख के विषय के लिए आवश्यक नहीं है।

कभी-कभी (लेखक के अनुभव में) अक्सर ऐसा होता है कि जिन वातावरण पर इस चक्र के विभिन्न चरण होते हैं, वे एक कारण या किसी अन्य के लिए भिन्न हो सकते हैं। मतभेद कुछ भी हो सकते हैं। विभिन्न तालिकाओं से स्कीमा नाम, DBLinks, और अन्य व्यक्तिगत सुविधाओं में अंतर। इस परेशानी को प्रभावी ढंग से कैसे हल करें, हम इस लेख में विचार करेंगे।





मुख्य तैनाती के आगे। एससीएल स्क्रिप्ट (जो सीधे डेटाबेस के स्रोत ऑब्जेक्ट्स के साथ अन्य स्क्रिप्ट्स को कॉल करता है), एक फ़ोल्डर लगाता है जिसमें व्यक्तिगत मापदंडों के एक सेट के साथ प्रत्येक वातावरण के लिए फ़ाइलों का एक सेट - डिफाइन-एस, संग्रहीत किया जाएगा।

DEFINE DATA_TS = DEV_DATA_TS DEFINE INDEX_TS = DEV_DATA_TS DEFINE Some_Source_data_dbl = Dev_dbl_source.world -- ...  .. 

प्रत्येक पर्यावरण के लिए, वह अपना होगा।
आपके डेटाबेस के स्रोत कोड में आगे, सब कुछ है कि उदाहरण के लिए प्रतिस्थापन चर का उपयोग करना है:

  create table my_table (sample_col VarChar(2 char) ) tablespace &DATA_TS; .... select * from dual@&Some_Source_data_dbl; 

इस प्रकार, आपकी स्क्रिप्ट पर्यावरण के प्रति उदासीन होगी, और आप अधिक आत्मविश्वास से कह सकते हैं कि परीक्षण पर्यावरण पर काम करने के बाद, वे UAT (उदाहरण के लिए) पर मज़बूती से काम करेंगे। नतीजतन, आप प्रत्येक विशिष्ट वातावरण के लिए स्रोत कोड को स्वयं नहीं बदलते हैं, जिससे मानव कारक के जोखिम को दूर किया जाता है: टाइपो, विस्मरण, विकर्षण की संभावना।
इसके जोखिम, त्रुटि प्रतिस्थापन पैरामीटर फ़ाइल में ही मिल जाएगी, पर्यावरण संग्रह के 1-2-3 पुनरावृत्तियों के बाद गायब हो जाती है (और आमतौर पर प्रतिस्थापन फ़ाइल को घटाना इतना मुश्किल नहीं है)।

यह केवल सही क्रम में इन सभी लिपियों को सही ढंग से कॉल करने और आगे के समर्थन के लिए न्यूनतम सिरदर्द के साथ बनी हुई है। यहां, पहली नज़र में, एक छोटा सा सवाल आता है: इन सेटिंग्स फ़ाइलों का नाम कैसे दिया जाए। हम उन्हें इस तरह से बुलाते थे:

dev.sql
qa.sql
uat.sql
prod.sql

लेकिन अब हमने इस प्रथा को छोड़ दिया है, और हम इसे पर्यावरण के TNS नाम से पुकारते हैं।
यह क्या देता है? हमारे पास इस तरह की .sh स्क्रिप्ट है (मैं केवल सार छोड़ता हूं):

  # ...     , help,      par_file = ${3//.WORLD/} sqlplus $1/$2@$3 @deploy.sql $par_file # ...      

स्क्रिप्ट इनपुट में तीन पैरामीटर आते हैं (इस सरलीकृत संस्करण में, जब आपके पास केवल एक सर्किट होता है): लॉगिन, पासवर्ड और टीएनएस उपनाम। यह देखते हुए कि कई निर्धारित करते हैं

name.default_domain = दुनिया

तब हम सब कुछ एक प्रारूप में लाते हैं (हमारे मामले में: हम संभावित रूप से प्रदर्शित होने वाले ".WORLD" को काट देते हैं)। नतीजतन, हमारे पैरामीटर फ़ाइल नाम रहता है (TNSalias नाम से) जिसे कॉल करने की आवश्यकता होगी।

यह संपूर्णता के लिए स्वयं को परिनियोजन का एक उदाहरण लिखने के लिए बना हुआ है।

  --    spool _deploy.log --       --  par_file    : @./defines/&1 @../ddl/some_table_create.sql @../data/some_other_deploy_activity.sql @./validate_invalid_objects.sql @./run_post_deployment_checks.sql spool off exit 

अपनी विकास प्रक्रिया में एक समान मानक की शुरुआत करने से, आप एक बार और सभी के लिए अपने वातावरण में अंतर के बारे में भूल जाएंगे, जो, मेरा मानना ​​है, तैनाती के समय - अंतिम समय में "सिरदर्द" को बहुत कम कर देता है।

पुनश्च: मैं कुछ कौशल और सर्वोत्तम प्रथाओं के निवास के साथ साझा करना चाहूंगा जिन्हें मैंने डेटाबेस के साथ काम करने के वर्षों में हासिल किया था। मैं विभिन्न दिलचस्प उदाहरणों के विश्लेषण के साथ लघु लेखों की एक श्रृंखला खोलना चाहूंगा, मेरी राय में, मेरे द्वारा सामना किए गए मामलों, कार्यों और नुकसान।